How to force a PLC input or output, and how force differs from modify

Forcing is the most useful and the most dangerous test tool in a PLC. This article explains what a force does, how it differs from a modify, how the main platforms show it, the discipline around it, and how to practise on a simulator. Nothing here is a procedure for your plant: follow your site's rules.

What a force does in the I/O image

A force replaces a value at the edge of the I/O image. A forced input replaces what the program reads, whatever the field sends. A forced output replaces what the field receives, whatever the program writes. The program's own value is left alone, which is what makes forcing confusing.

Recall the scan cycle: inputs are copied into an image at the start, the program works on the image, and the output image is copied out at the end. A force sits on those two copies, as the drawing shows.

Two consequences follow. With an input forced to 1, the real sensor can be off and every rung that depends on it behaves as if the part had arrived. With an output forced to 0, the program can set the coil all day and the contactor stays open, so online the coil shows on while the field is off. Check the field, not the screen.

CODESYS documents the order inside each cycle: read inputs, write forced values, run the program, write forced values again, write outputs. Code that changes a forced variable mid-cycle cannot make it stick.

Force versus modify

A modify (Siemens' term; "write values" in CODESYS) writes a value into memory once. The program is then free to change it again on the next scan, and a physical input is overwritten by the next input update. A force holds the value until it is released.

The Siemens CPU 1517-3 manual lists status and modify tags covering inputs, outputs, bit memories, data blocks, timers and counters (up to 200 per job), and force tags covering inputs and outputs (up to 200). CODESYS puts it plainly: writing sets the value once and the program can overwrite it, while forcing sets it permanently.

Use modify to push a setpoint or reset a counter while testing. Use force only when a point must stay where you put it.

Why forces persist

A force is stored in the controller as a job, and a restart does not necessarily remove it. You have to release it.

• CODESYS. Forcing continues until you release it with the unforce command, release it in the prepare-value dialog, or log out. If forced variables remain at logout, CODESYS asks whether to lift forcing for all of them, and answering no reapplies the forced values at the next login.
• Siemens S7-1500. The CPU's LED table lists an active force job as MAINT lit yellow while RUN/STOP is green: a lamp on the front of the CPU, where someone at the cabinet will see it.
• Rockwell Logix. The Online bar in Studio 5000 shows whether forces exist and whether they are enabled or disabled, controller-wide, not per module or tag.

The safety discipline

Forcing can defeat the logic that protects people. These habits are general good practice, not a regulation, and your site's procedure overrides them.

1. Get authorisation. Forcing on live plant is done under a permit to work or the site's equivalent, by someone competent for that machine.
2. Know what can move. Before forcing an output, decide what it will start, open or release, and who is in reach. CODESYS warns that unusual changes on a running controller can endanger plant and people.
3. Never force to bypass protection. A guard, light curtain or emergency stop input is not something to hold healthy so the machine will run. Follow your safety procedure for any test of safety I/O.
4. Keep a force log. Write down the tag, the value, why, who, when. A force with no entry cannot be reviewed.
5. Release outputs deliberately, one at a time, and expect the machine to react when you do: the program's real demand is applied the moment an output force is removed.
6. Remove all forces before handover and check the indicator, then check the log against the controller.
7. Treat a surprise as a force until proved otherwise. If an output ignores its coil or an input will not change, check for forces before you touch the wiring, as the troubleshooting method says. The commissioning checklist should include removal.

Vendor terms

Practising on LADV

The Wartens LADV virtual PLCs let you practise forcing with no hardware. The lab's I/O and forcing table lists every I/O point with buttons for force 1, force 0 and release, a numeric field for analog points, and Release all forces. The watch table offers modify: click a value and type a new one. LADV is a behavioural simulator for learning and testing logic, not for controlling machinery.

Download this motor station program, press RUN, and work through the exercises.

VAR_GLOBAL
  Start_PB AT %IX0.0  : BOOL; (* Start pushbutton, normally open *)
  Stop_PB  AT %IX0.1  : BOOL; (* Stop pushbutton, normally closed, 1 when healthy *)
  EStop_OK AT %IX0.2  : BOOL; (* Emergency stop, normally closed, 1 when healthy *)
  Motor    AT %QX0.0  : BOOL; (* Motor contactor *)
  Run_Lamp AT %QX0.1  : BOOL; (* Running indicator *)
END_VAR

PROGRAM Main
  (* Start with a seal-in. Stop_PB and EStop_OK are normally closed, *)
  (* TRUE while healthy, so a broken wire stops the motor too.       *)
  Motor := (Start_PB OR Motor) AND Stop_PB AND EStop_OK;
  Run_Lamp := Motor;
END_PROGRAM

Exercise 1: force an input

Set the stop and emergency stop inputs healthy, then force Start_PB to 1. Motor turns on and the MAINT lamp lights. Release the force: Motor stays on, because the seal-in held it. That is the kind of thing that surprises people on a real machine.

Exercise 2: hide a fault with a force

Press stop (set the Stop_PB input to 0): Motor drops. Now force Stop_PB to 1 and press start. The motor runs although stop is pressed, because the program is told everything is healthy. Release it and the motor stops.

Exercise 3: the program and the field disagree

With the motor running, force Motor to 0. The field output goes off, but the watch table still shows Motor as TRUE, because that is the program's value, and Run_Lamp stays on, because the lamp is a different, unforced output. Release the force and the motor comes back immediately, with nobody pressing start. Hold that thought next to the release rule above.

Exercise 4: modify is not force

Write Start_PB TRUE in the watch table. The field overwrites it on the next scan. Now write Motor TRUE with the motor off: it stays on, because Motor seals itself. A modify can start a seal-in but cannot hold an input.

Exercise 5: restarts

Force an output, press STOP, then RUN. The force and the MAINT lamp are still there. Restoring a saved controller brings them back too, in STOP, because a force that silently vanished would be worse.

Exact behaviour in LADV

These come from the controller source.

• Forces apply to I/O points only. A plain variable is refused with a message that it is not an I/O point; modify those in the watch table.
• A forced output applies only in RUN. In STOP or FAULT every output is off, force or not, and the force is kept for when you go to RUN.
• Analog forces are whole numbers from -32768 to 32767. Outside that range the force is refused. Digital forces are 1 or 0.
• Each action is logged: W400 when a force goes on (with the value), I401 when one is removed, I402 when all are removed, I410 when a value is modified.
• The MAINT lamp stays lit while anything is forced.

The tank level process has an analog level input to force too.

Removing forces and handing over

Before you leave a controller: release all forces, check the indicator is off, read the log against what the controller says, and note it. On LADV, Release all forces does it and writes I402. If you find a force you did not set, find out who did before you remove it.

For the memory side of restarts see PLC memory and retentivity. To practise the rest of testing in the same lab, the online PLC simulator and how a virtual PLC works are the next reads.

How we tested

On 2026-11-01 we ran the motor station reference program on the LADV controller model CPU 110 and drove the exercises through the controller's force, unforce and modify calls: a forced start sealing in, a forced stop input hiding a pressed stop, a forced output holding the field at 0 while the program value stays TRUE, outputs off in STOP with the force kept, forces restored after a save and restore, and a modify of Motor holding through the seal-in. Every Structured Text program on this page compiles on the LADV compiler, checked automatically in the site's test suite.

Not tested: forcing on any Siemens, Rockwell or CODESYS system, or the analog force on the tank level process. Siemens and CODESYS points come from the linked pages, which we read; the Siemens LED table is from a 2014 edition of the CPU 1517-3 manual, so check yours. Rockwell's pages could not be fetched automatically, so its points are summarised from their published description: check your version.