Online editing is the ability to change a PLC's program while the controller keeps scanning and the process keeps running, rather than stopping the machine to load a new program. It is what lets an engineer add a rung, adjust a comparison, or fix a piece of logic on a producing well or a flowing pipeline without shutting anything down. This guide explains the test-assemble-accept workflow that makes a live edit possible, the real risks of changing code on a running controller, and how it differs from a full offline download.
Online Editing in one line: Online editing means modifying the logic in a running PLC in place, so the controller continues executing its program throughout the change instead of being stopped and reloaded. The edited logic is prepared, tested against the live process, and then accepted so it takes over on the next scan, all without interrupting control. It contrasts with an offline download, where a complete program is compiled separately and transferred to the controller, typically requiring the process to stop.
Online editing is deliberately staged so a change is never dumped straight into a running controller. The engineer first enters the edits - new rungs, changed instructions, adjusted logic - into a pending version that the controller holds alongside, but does not yet execute, the code that is actually running the process. Nothing about the running behavior changes while the edits are merely entered.
The next step tests the edits. In test mode the controller executes the pending logic instead of the original for the affected rungs, so the engineer can watch the new code operate against the live process and confirm it does what was intended - while retaining the ability to cancel and revert to the original if it does not. This is the safety valve of the whole workflow: it lets the change be observed working before it is made permanent. When the edits prove out, the assemble and accept steps commit them, replacing the original logic with the tested version so the controller runs the new code from then on. If the test reveals a problem, the edits are untested and discarded, and the controller carries on with the code it was always running.
The exact command names differ by platform, but the shape is universal: prepare, test against the live scan, then commit. That staging exists because there is no separate rehearsal environment on a running controller - the process is the test bench, and the workflow is designed to let you try a change on it reversibly before you are stuck with it.
The reason online editing exists is that some processes cannot simply be stopped. A producing well, a pipeline moving product under contract, a compressor keeping pressure on a system - taking any of these offline to reload a program has real cost and real consequence, and sometimes safety implications of its own. Online editing lets control be adjusted on equipment that must keep running, which is often the difference between fixing a problem now and waiting for a shutdown window that may be weeks away.
That capability carries genuine risk, because the edited logic executes on the running process the instant it is accepted. A mistake in the change - a wrong comparison, an inverted contact, a rung that energizes an output under conditions the engineer did not anticipate - can move a valve or start a motor on the very next scan, on live equipment, with product flowing. The forgiving offline habit of loading a program and then carefully bringing the process up does not apply; here the process is already up.
A subtler hazard is the partial or half-finished edit. If a change spans several rungs and only part of it is committed, or if an edit is left in a pending state and the wrong action finalizes it, the controller can end up running an inconsistent version of logic that was never meant to execute as a whole. Discipline - completing edits fully, testing before accepting, and knowing exactly which version is live - is what keeps online editing a precision tool rather than a way to break a running plant faster than an offline download ever could.
Nowhere is online editing more valuable than on remote RTUs and controllers scattered across an oilfield. A full offline download often means restarting the controller, and a restart on a remote site can drop communications, reset counters and totals, or interrupt the very production tracking the site exists to perform. When the fix is a small logic tweak, forcing a restart to deliver it is a heavy price for a light change. An online edit avoids that entirely: the logic changes, the scan never stops, and the production data keeps accumulating.
This becomes especially important when the change is being made from far away. In a cloud SCADA context such as Merobix, an engineer may be nowhere near the pad, watching a remote controller through the dashboard, and the last thing anyone wants is to bounce a controller they cannot physically see or reach. Editing online lets a control adjustment land on a distant RTU while the site keeps reporting, so the effect of the change can be observed on the live trend immediately rather than after a nerve-wracking restart and reconnect.
The remote setting also raises the stakes on the discipline. If a bad edit misbehaves on a controller you can drive to, you can intervene locally; on an unmanned site hours away, your only handle on the problem may be the same remote connection you edited through. That is why careful engineers test online edits against the live process and confirm the intended behavior on the trend before accepting, treating the reversible test step as the real safeguard when the equipment is out of arm's reach.
Online editing is changing a PLC's program while the controller is still running and executing logic, rather than stopping it to load a new program. The edits are prepared, tested against the live process, and then accepted so they take effect on the next scan without interrupting control. It is how logic is adjusted on equipment that cannot be shut down.
In an offline download, a complete program is compiled separately and transferred to the controller, which usually requires stopping the process and often restarting the controller. Online editing modifies logic in place on a running controller, so the scan never stops and production continues. Online edits suit small, targeted changes on live equipment; large or structural changes are often still done offline.
Yes, because accepted edits execute on the running process on the very next scan, so a mistake can move a valve or start a motor on live equipment immediately. Partial or half-committed edits can also leave the controller running inconsistent logic. The test step, which runs the new logic reversibly before it is committed, is the main safeguard, along with the discipline of completing and verifying edits before accepting.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.