What Is Scan Time?
The PLC's Repeating Cycle

Back to Blog

What Happens in One Scan

A classic PLC scan cycle has three main steps that repeat endlessly. First, the input scan: the PLC reads the state of every input and copies it into an internal image table, so the whole program works from a consistent snapshot. Second, the program (logic) scan: the PLC executes its control logic top to bottom, using the input image to compute new output values. Third, the output scan: the computed results are written out to the physical outputs. Housekeeping tasks - communications, diagnostics, self-checks - run around these steps.

Then it starts over. The scan time is the duration of one complete pass. For a small program it may be one to a few milliseconds; a large program with many instructions or heavy communications takes longer. Because outputs only update once per scan, an input that changes has to wait, on average, part of a scan before the program even sees it.

Why Scan Time Matters, and Poll Rate vs Scan Time

Scan time sets the controller's responsiveness. If a shutdown input must be caught reliably, its signal has to persist longer than one scan, and the total response time includes the scan plus input filtering and output actuation. For fast events, engineers keep programs efficient, use interrupts or high-speed inputs, and avoid bloated logic that stretches the scan. A consistent, short scan time is a sign of a healthy controller; a scan time that grows unexpectedly can signal a problem.

Scan time is often confused with SCADA poll rate, but they are different layers. Scan time is how fast the local controller runs its own logic - milliseconds. Poll rate is how often the SCADA host requests data from that controller over the network - often seconds or longer, especially over cellular or radio to remote oil-and-gas sites. Control decisions happen at scan speed in the field; SCADA sees a slower sampled view of the results, which is exactly why time-critical control lives in the controller and not in the SCADA host.

What Makes Scan Time Grow

Scan time is not a constant - it is the sum of whatever the processor did on that pass. The instruction mix matters: floating-point math, string handling, and file or array operations cost far more per rung than simple contacts and coils. Communications servicing grows with the number of connected clients and the size of their requests, so adding one more polling master can visibly stretch the scan. Online edits, indirect addressing, and loops whose iteration count depends on process conditions all make scan time vary from pass to pass rather than sit at one steady figure.

Symptom	Likely cause
Scan time stepped up after a change	New logic or a new communications client
Scan time varies widely pass to pass	Conditional loops or event tasks preempting
Slow creep over months	Accumulating message load or added logic
Sudden spike, then controller fault	Watchdog exceeded - runaway loop or blocked task

Controllers expose current, minimum, and maximum scan time in their diagnostics. Trending that value in the historian alongside communication counters turns 'the PLC feels slow' into an answerable engineering question instead of a hunch.

Tasks, Interrupts, and the Watchdog

Modern controllers rarely run one monolithic scan. Logic is split across continuous, periodic, and event tasks: the continuous task loops as fast as it can, periodic tasks run on a fixed interval regardless of what else is happening, and event tasks fire on a trigger such as an input change. Time-critical logic - a PID that must execute on a consistent interval, or a fast permissive check - belongs in a periodic task so a bloated continuous scan cannot starve it.

The watchdog timer is the safety net: if a scan fails to complete within its configured limit, the controller declares a fault rather than keep running with half-updated logic. What happens next - outputs driven to a safe state, and optionally a fault routine that logs the cause or attempts recovery - is a deliberate design decision, and for anything safety-related it is made per the site's safety philosophy by qualified people, not left to defaults.

Will the Scan Catch It? A Bounding Exercise

A quick symbolic check answers most 'is the PLC fast enough' questions. Call the scan time T and the input filter time F. An input pulse is guaranteed to be seen only if it stays present longer than T plus F - anything shorter can fall entirely between two input scans. On the response side, the worst case from input change to output change approaches two scans plus the filter time plus the output device's own actuation time, because a change that arrives just after the input scan waits nearly a full pass before the program even reads it.

Run that bound whenever pulses are involved. If a turbine meter's pulse train at maximum flow is faster than the scan can guarantee, counting in ordinary logic will silently miss pulses - the fix is a high-speed counter input that captures pulses in hardware, independent of the scan. The same bounding logic applies one layer up: a host polling slower than values change misses excursions entirely, the phenomenon described in the guide to scan overrun at the SCADA layer.

Frequently Asked Questions