PLC Execution: Tasks, Scan Cycles, I/O Images & Remote I/O

A PLC runtime is a temporal contract between physical I/O, application logic, and outputs. The important question is not merely “does this rung evaluate true?” but which input version did it see, when can another task change shared state, and when does the resulting output reach the field? The classic scan gives one good answer; modern runtimes provide several others.

The canonical scan #

In the simplest cyclic executive, the controller repeats:

1. copy physical inputs into an input process image;
2. execute application logic against that stable image;
3. copy the output process image to output modules;
4. perform diagnostics and communications, then begin again.

This snapshot prevents a long program from seeing one contact as false near the top and true near the bottom merely because the field changed mid-scan. The cost is latency. A change just after the input copy waits almost one cycle to be sampled, then the program executes, then the output waits for publication and module transport.

For a cyclic task with period $T$, an approximate end-to-end delay is

$$D \approx D_{\text{input transport}} + \phi_{\text{sample}} + D_{\text{queue}} + C_{\text{task}} + D_{\text{output publication}} + D_{\text{output transport}},$$

where sample phase $\phi_{\text{sample}}$ lies between nearly zero and nearly $T$. Quoting only the average scan time hides the worst phase and every network/module delay around it.

Process image versus physical I/O #

An address such as %I0.0 or a symbolic input may name a memory image, not an electrical terminal sampled at that instruction. Likewise, assigning an output variable usually changes controller memory first. The hardware module updates at the runtime's defined boundary or fieldbus cycle.

Tasks, priorities, and watchdogs #

IEC 61131-3's software model allows tasks to trigger programs or function blocks periodically or on an event. Commercial controllers also commonly provide continuous/background, periodic, and event tasks. A higher-priority task may preempt a lower-priority task, so its response improves at the expense of jitter and completion time below it.

For each task, measure or bound:

• release period and phase;
• worst observed and justified worst-case execution time;
• preemption and blocking from higher priorities or shared resources;
• deadline and tolerated jitter;
• watchdog action after an overrun.

CPU utilization below 100% does not prove schedulability. A 2 ms event task can repeatedly preempt a 10 ms control task at exactly the wrong phase. Nor does a watchdog “fix” an overrun: it detects that the temporal contract has already failed and transfers control to a configured fault policy.

Shared data and execution order #

Within one task, program order often supplies determinism: later logic sees values written earlier in the same invocation. Across tasks, a shared variable can be read while another task is updating a related group of fields. Use a single owner for each output and state machine; exchange coherent structures at explicit boundaries; and include sequence counters or timestamps when readers must detect a new publication.

Double buffering is a useful pattern:

1. a producer writes an inactive buffer completely;
2. it increments a sequence and atomically publishes the buffer identity;
3. the consumer snapshots the identity and reads only that buffer;
4. a changed sequence during the read invalidates the snapshot.

The exact atomic operations remain runtime-specific, but the invariant is portable: the consumer never interprets a half-old, half-new control object.

Remote I/O is a sampled networked system #

Remote I/O adds producer cycles, network scheduling, gateway queues, module filtering, and loss/recovery behavior. The controller's input image may be internally coherent yet already too old for the process. Preserve at least:

• raw value and engineering value;
• source or acquisition timestamp when available;
• quality/status and substitution state;
• expected update period and staleness limit;
• module and network diagnostic state.

A Boolean without age or quality cannot distinguish “false now” from “last false value retained after the remote rack disappeared.” For a permissive or trip input, that difference is part of the control requirement.

Startup, restart, and retained state #

Cold start, warm restart, program download, transition to RUN, and task fault are different events. Define which variables initialize, which retain their value, how output modules behave before the first valid publication, and whether a sequence may resume automatically. Retaining a motor's Running state across power loss is not equivalent to proving that the motor is running; physical feedback must re-establish reality.

Timing trace for one input #

Suppose a 10 ms periodic task executes for at most 2 ms, an input module publishes every 4 ms, and the output fieldbus publishes every 4 ms. Ignoring phase alignment, a physical change can wait almost 4 ms for input transport, almost 10 ms for task release, 2 ms for execution, and almost 4 ms for output transport: nearly 20 ms. The average may be about half that. Both numbers are more useful than “the scan is 2 ms,” because the 2 ms covers only computation.

Commissioning checks #

Measure input acquisition-to-image delay, task release jitter, execution high-water mark, output-image-to-terminal delay, and behavior under communication loss. Force a controlled task overrun and verify the watchdog path. Power-cycle a remote rack and the controller separately. Confirm that stale quality reaches both control logic and HMI. Finally, prove that every physical output has one software owner or an explicit arbitration block; multiple writers make scan order an undocumented control policy.