PLC scan cycle: what actually happens every millisecond

A programmable logic controller is often described as “running the program.” That shorthand hides the timing contract that makes a PLC useful. Most PLCs repeatedly sample inputs, execute logic, update outputs, and perform housekeeping inside a scan cycle. The important question is not only how quickly one scan completes, but whether the cycle remains bounded and understandable when the plant is busy.

The four parts of a scan

The exact order varies by platform, but a useful mental model has four phases:

1. Input image update copies physical inputs and communication values into memory. The main program then reads this stable image rather than a signal that can change halfway through a calculation.
2. Program execution evaluates tasks, routines, function blocks, and state machines. A contact or condition that becomes true during this phase is normally reflected in the next output update.
3. Output update copies the output image to modules or the network. The actuator sees a coherent result of the completed logic.
4. System work handles diagnostics, communications, motion services, and lower-priority tasks.

This means a change at a sensor is not necessarily visible at an output in the same instant. The input may wait for the next image update, the logic may wait behind a long-running task, and the output may wait for the next update. Designing around that sequence is safer than assuming every rung is continuously watching the wire.

Scan time is a budget

The total scan time is the sum of all work scheduled in that cycle. Large data copies, string operations, dynamic allocation, excessive communications, and poorly bounded loops can turn a stable program into a timing risk. A program that usually scans in 4 ms but occasionally takes 40 ms can be worse for a fast interlock than one that consistently takes 8 ms.

Track at least the minimum, typical, and maximum scan times. Set a watchdog with enough margin for normal bursts but little tolerance for an infinite loop. Put genuinely time-critical work in a high-priority periodic task only when the controller can prove it will fit. A higher priority does not make an algorithm cheaper; it simply delays other work.

Practical design rules

• Keep fast control logic small and deterministic. Put reporting, recipe preparation, and non-critical calculations in slower tasks.
• Treat communication data as asynchronous. Validate freshness, quality, and sequence before using a remote value in control logic.
• Debounce noisy discrete inputs in logic or hardware, but document the added delay.
• Make one owner responsible for each output. Multiple routines writing the same actuator create an order-of-execution bug that is hard to see in a cross-reference.
• Expose scan time, watchdog state, task overruns, and I/O quality to the HMI or diagnostic layer.

The IEC 61131-3 PLC languages guide covers how the same timing model appears in ladder, function block, and structured text. For feedback loops, also see the PID loop glossary entry.

For a wider systems view, Understanding the Shop Floor is a practical ebook companion for connecting controllers, networks, data systems, and the decisions they support.