New machine programming, logic changes on equipment that can't go offline, and migrations off hardware Rockwell stopped making. Allen-Bradley and Siemens, remote or on-site, done by the engineer who answers the phone.
New machine or a new cell, I write the PLC program from scratch. I/O mapping, sequence logic, interlocks, safety, alarms, and the HMI that sits on top. I write the code, commission it on the machine, and stay through startup until it runs the way the mechanical and electrical drawings say it should.
Most of it is ladder logic, because that's what your maintenance team can read at 2am when the line is down and I'm not there. Structured text where it actually earns its place, like recipe handling or math that would otherwise turn into 400 rungs for no reason. Function blocks for the loops. The point is code the next person can follow, not clever code.
A new-build engagement usually covers:
Most calls aren't a blank project. Someone has a machine that runs today and needs it to do something different tomorrow. A new part number, a faster cycle, an added station, a sensor that keeps nuisance tripping, an interlock that fires when it shouldn't. I go into the existing program, figure out how the last person built it, and make the change without breaking the three things it was already doing.
Online edits to a live processor are normal work, but they aren't casual. Before I touch a running ControlLogix or S7, I pull a verified backup, read the logic until I understand it, and plan the edit so a bad download doesn't take the line down. On anything with real risk, we schedule it for a window and I bring a rollback. Think adding a station to a running packaging line, or changing pump sequencing at a municipal water plant without taking the process offline.
Working in code you didn't write is half the job. Undocumented rungs, magic numbers, tags named BIT_47. I read it before I change it, so the fix doesn't become the next person's mystery.
Most of what I touch in Central Florida is Rockwell. ControlLogix and CompactLogix in Studio 5000 for current work, RSLogix 5000 on older firmware, RSLogix 500 for the SLC 500, and RSLogix 5 for PLC-5. PanelView and PanelView Plus on the HMI side, in FactoryTalk View.
I also do the migrations, because a lot of Florida plants are still running hardware Rockwell no longer makes. The PLC-5 line is discontinued and the SLC 500 is end-of-life. When one of those finally dies, or before it does, I move the program to CompactLogix or ControlLogix, convert the logic, and match the machine's behavior rung for rung so operators don't have to relearn it.
Allen-Bradley platforms I program regularly:
On the Siemens side I work in TIA Portal with the S7-1200 and S7-1500. A lot of Florida machinery, especially anything built in Europe, showed up with Siemens controls and no local support. If the OEM is overseas and slow to answer, I'm the engineer who can open the project, read it, and change it.
I write to the platform instead of fighting it. Siemens rewards structure: proper blocks, a real tag architecture, symbolic addressing that survives the next revision. If your S7 program is a wall of undocumented networks, I'll clean it up as I go and leave you something the next person can actually maintain. Same discipline on a backup and download to a running S7-1500 as on any live processor, verified backup first, rollback ready.
This trips up a lot of plants, so it's worth being plain about. Your electrician runs conduit, pulls wire, lands terminals, swaps a contactor, and gets power to the machine. That's licensed electrical work and you need it. A PLC programmer works inside the processor: the logic, the tags, the HMI screens, the sequence that decides what turns on and when. Different job, different tool.
The overlap is where it gets fuzzy. A control panel has both, and when a machine misbehaves the honest first question is whether it's a wiring fault or a logic problem. Those two get blamed on each other constantly. I can read the code and meter the panel, so I can tell you which side of the line the problem is actually on before you pay anyone to chase the wrong one.
If it turns out to be a straight electrical fix, I'll say so, and you're better off with your electrician. If it's in the program, that's my work.
Code you can't read is a liability even when it runs fine. Every job leaves with commented logic, a real tag database, an updated I/O list, and a verified backup of the program exactly as it runs on the processor, not the version somebody assumes is current.
If your plant already has a programming standard, I follow it. If it doesn't, I write to a sane one: consistent tag naming, routines grouped by function, rungs commented in plain English, alarms that mean something when they fire. The test is simple. Could a controls engineer you hire two years from now open this project and understand it in an afternoon? That's what I build toward, and you own every file when it's done.
Some work doesn't need me in the building. A logic tweak, an alarm fix, a backup pull, a fault I can watch over a secure remote session. If you've got a VPN or a cellular gateway on the line, I can be in your processor in minutes instead of driving two hours.
Commissioning, wiring faults, and any machine that has to be watched while it moves, that's on-site. I'm based in Melbourne on the Space Coast, so most of Central Florida is a drive, not a flight. I end up doing a lot of both on the same job: remote for the small stuff between visits, on-site when the machine has to run in front of me. Either way it's one engineer. The person on the remote session is the same person who shows up in the plant.
Tell me what it's running and what you need it to do. Allen-Bradley, Siemens, or something older, a new build or a change to a line that can't go down for long. Fifteen minutes with the engineer who'd actually do the work, no deck. Call (321) 378-0424.