Forcing is the deliberate act of telling a PLC to pretend an input or output has a value you choose, regardless of what the field wiring or the program logic is actually doing. It is one of the most useful commissioning and troubleshooting tools a controller offers - and one of the most dangerous if a force is left behind. This guide explains what forcing does at the scan level, why controllers make a running force impossible to ignore, and the discipline of removing every force before walking away from an unmanned site.
Forcing I/O in one line: Forcing I/O means manually overriding the value of a physical input or output point in a PLC so it holds a state you set, ignoring the real field signal or the logic that would otherwise drive it. A forced input feeds the program a value the field is not sending; a forced output drives a device to a state the logic is not commanding. It is intended as a temporary commissioning and diagnostic measure, and a forgotten force is a recognized safety hazard because it silently defeats the control the operator believes is in place.
A PLC runs a repeating cycle: it reads the physical inputs into memory, solves the logic, and writes the results to the physical outputs. Forcing inserts an override into that cycle. When an input is forced, the controller substitutes your chosen value in place of the value it read from the terminal, so the logic solves as though the field device were in that state even if it is not. When an output is forced, the controller ignores whatever the logic decided and drives the physical point to the state you commanded, so a valve can be opened or a motor started directly, independent of the program.
That override is exactly why forcing is powerful during commissioning. To prove a shutdown valve strokes and closes correctly, an engineer can force the output that commands it and watch the valve move, without having to recreate the process conditions that would trip it naturally. To test a rung of logic before the field sensors are even connected, an input can be forced high and low to confirm the program responds. Forcing lets a person exercise wiring and logic on their own schedule rather than waiting for the process to cooperate.
The same power is what makes forcing hazardous. A force does not respect the logic that was carefully written to keep equipment and people safe. Force a safety input to its healthy state and the protective logic downstream believes all is well, even as the real condition it guards against develops. The controller does exactly what it was told - which is the point of forcing, and the trap in it.
The classic incident is not a force that was applied - it is a force that was never removed. Picture a commissioning crew that forces an emergency shutdown input to its normal state so nuisance trips do not interrupt their testing, intending to clear it before startup. If that force survives to production, the ESD input is defeated: the very signal meant to stop the process in an emergency is pinned to healthy, and the shutdown will not fire when it is needed. A forced valve is the same story - a drain left forced closed, or a bypass left forced open, that no longer answers to the logic.
What makes forgotten forces so insidious is that everything looks normal. Screens read plausible values, the process runs, and nothing draws attention to the override until the exact moment the defeated protection was supposed to act. The gap between applying a force and needing the thing it defeated can be days or weeks, long after the person who set it has left the site and forgotten it existed.
This is why controllers make forces loud. A PLC with active forces typically flashes a force indicator on its faceplate, sets a status bit that programs and screens can watch, and refuses to let the condition go quiet. The signal exists precisely because a force is invisible in the process itself; the only reliable reminder is the controller shouting that an override is in place. Treating that indicator as an alarm, not a nuisance light, is the difference between catching a forgotten force and being caught by one.
On a staffed plant, a forgotten force stands a chance of being noticed on the next round. On a remote, unmanned oil and gas site, nobody is standing in front of the panel to see the flashing light, so the discipline has to be built into procedure and into the monitoring system. The standing rule is simple and non-negotiable: no force leaves with the technician. Before locking the gate, every force applied for testing is removed, and the removal is verified rather than assumed.
Remote monitoring closes the visibility gap the empty site creates. Because the controller sets a status bit whenever any point is forced, a cloud SCADA such as Merobix can surface that condition as an alarm on the dashboard, so a force still active after a crew has left becomes visible to whoever is watching the fleet, not just to a faceplate nobody is looking at. That turns the controller's local warning into a fleet-wide one that reaches people who can act on it.
Good practice pairs that with a written record. A force log - what was forced, why, by whom, and when it was cleared - makes the last step of any site visit a deliberate reconciliation: every force on the list is either gone or explained. On unmanned infrastructure, where the next human visit might be far off, that habit is what keeps a convenient testing shortcut from quietly becoming a defeated safety function running for weeks.
Forcing means manually setting a physical input or output to a value you choose, so the controller ignores the real field signal or the logic that would normally drive that point. A forced input feeds the program a state the field is not actually sending, and a forced output drives a device regardless of what the logic commands. It is a deliberate override, used mainly for commissioning and troubleshooting.
Because a force silently defeats the control or protection the operator believes is active, and everything looks normal until the defeated function is needed. A forced-healthy emergency shutdown input, for example, will not trip the process in a real emergency, and a forced valve no longer answers to the logic. The danger is greatest on unmanned sites, where no one sees the controller's force warning.
Use the controller's force table to review every active force, clear each one deliberately, and then confirm the force-active indicator has gone out. Best practice is to keep a written log of every force applied during a job so the last step before leaving is reconciling that list to zero. On remote fleets, a SCADA alarm on the controller's force status bit provides a backstop in case a force is missed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.