Making Online PLC Edits Without Tripping the Running Process

A contractor once asked me to "just add one rung" to a running Logix processor driving a wastewater lift station. The rung looked harmless — a permissive for a new flush valve. He assembled the edit, and the lead pump dropped out for about 400 ms. Long enough for the check valve to slam and the operators to call. Nothing in his new rung touched the pump. The problem was scan order: his rung read a tag that a later rung wrote, so for one scan the pump's seal-in saw a stale zero.

Online editing is the part of PLC work with the least documentation and the highest pucker factor, because you're modifying logic while it controls real equipment. It's routine and it's fine — until it isn't. Here's how I approach it.

Online edit is not a download

First, get the two operations straight, because people use "download" to mean both.

A download sends the entire project to the processor. On a ControlLogix or CompactLogix, that forces the controller to Program mode — every output goes to its configured Program-mode state (usually de-energized) for the duration. You never do a full download on a running process unless you've stopped the process first. On Siemens S7-1500, a full download to a stopped CPU is the equivalent.

An online edit modifies logic while the processor stays in Run. In Studio 5000 the workflow is Start Pending Edits → Test Edits (both the original and your new version compile and the test version executes) → Assemble Edits (your version becomes the running logic, original discarded) → then finalize/accept. You can Cancel at Test stage and the original keeps running the whole time. Siemens TIA Portal calls it "download in RUN," and it's far more restricted: you can change existing logic, but adding a block interface, changing a data-block structure, or altering the tag table generally forces a stop. Rockwell is more permissive, which is exactly why it's easier to hurt yourself.

The traps that actually bite

Scan order. The lift-station story above. Ladder solves top to bottom, left to right. If you insert a rung that consumes a value produced further down, that value is one scan old on the first pass after Assemble. For a fast-latching seal-in or a one-shot, one stale scan is enough. Insert the rung after the logic that produces its inputs, or add a first-scan guard.

Seal-in and OTE glitches during Assemble. When you delete a rung containing an OTE and re-add it modified, there's a window during Assemble where the output's rung condition is re-evaluated. If your edit changes the branch that holds a motor's seal-in, the OTE can drop for a scan. Motors on a seal-in with a hardware contactor usually ride through a single-scan blip; a solenoid or a fast VFD enable may not. When the output must not glitch, latch it with OTL before the edit and unlatch after — or don't edit that rung online at all.

Forces are still live. Online edits and forces are independent. If someone left an output forced from a previous troubleshooting session, your edit does nothing to that output and you may not notice. Before editing, check the force status — the FORCE LED and the I/O Forces dialog. I clear stale forces before I touch logic, every time.

Uninitialized tags. Add a new tag and reference it in a comparison and it's zero until something writes it. A GRT against a new setpoint tag reads "0 > 0 = false," which might be the safe state or might not. Pre-load new setpoint and configuration tags — either in the edit itself with a first-scan MOV, or from the HMI — before the logic that uses them goes active.

HMI write races. If the HMI writes a tag that your new rung also writes, you now have two masters. Decide which one owns it and make the other read-only. This is the same discipline as any command-arbitration problem, just introduced mid-flight.

Keyswitch and mode

On ControlLogix the keyswitch has to be in REM (remote) to do online edits — in the RUN position the processor rejects edits, which is the whole point of that position for a locked-down plant. Getting yelled at for a rejected edit usually means someone turned the key to RUN after the last change as a lockout. Don't force it back without asking why it's there.

On a redundant chassis (ControlLogix Redundancy, or Hot Standby), an online edit crossloads to the secondary automatically as part of Assemble — but only if the secondary is synced and qualified. Edit while it's disqualified and you've split your program versions; the next switchover runs old logic. Confirm "Synchronized" before and after.

Safety logic is a different rulebook

None of the above applies casually to a safety instrumented system. If the logic lives in a SIL-rated safety controller (GuardLogix, S7 F-CPU, HIMA), online editing of the safety task is governed by IEC 61511 — you follow a documented bypass/override procedure, you record the change under management-of-change, and you re-validate the affected safety function before removing the bypass. "Just add one rung" is not a phrase that belongs anywhere near a logic solver. Standard (non-safety) tasks in the same GuardLogix can be edited normally; the safety task cannot.

The pre-edit checklist I actually run

Before I touch a running processor:

1. Upload and save the current program with a dated filename. If the edit goes wrong, the fastest recovery is a known-good file, not an undo.
2. Check forces — clear stale ones, note any that are intentional.
3. Confirm the keyswitch is REM and, on redundant systems, that the secondary is synced.
4. Know the process state. Is a pump running? A batch in a hold step? Editing the active step of a running SFC or a batch phase is how you strand a reactor. Wait for a safe state if you can.
5. Read the rung's neighbors — what writes its inputs, what its outputs seal in. Plan the insertion point for scan order.
6. Have an operator watching the equipment, not just the screen. A 400 ms drop shows up as a bang in the field before it shows on the trend.

After Assemble, watch the outputs you touched for a full minute of live scans before you call it done — and only then finalize/accept edits so the change survives a power cycle. Test Edits that never get accepted vanish on the next full download, and that surprise arrives weeks later when someone else pushes a project.