The PLC Scan Cycle: How a PLC Actually Thinks

A PLC (programmable logic controller) — the industrial computer that runs most automated machines — does not execute your program the way a PC runs software. It runs one rigid loop, forever, from power-on until power-off:

Read all inputs → execute the whole program → write all outputs → repeat.

One trip around that loop is called a scan, and the loop itself is the scan cycle. It is the single most important concept in PLC programming: once you understand the scan, ladder logic quirks, timing behavior, and "why doesn't my output fire?" mysteries all start making sense.

The four phases of every scan

1. Input scan

The PLC reads the electrical state of every physical input — every sensor, button, and switch terminal — in one sweep, and copies the results into a memory area called the input image table. For the rest of this scan, the program does not look at the real terminals again; it works entirely from this frozen snapshot.

2. Program scan

The CPU executes your logic — ladder logic, function block, or structured text — top to bottom, left to right, rung by rung. Results are written to the output image table (another memory area), not to the real output terminals yet. A rung near the bottom can use a result computed near the top in the same scan; a rung near the top uses the bottom rung's result from the previous scan. Rung order matters.

3. Output scan

The PLC copies the output image table to the physical output terminals in one sweep. Motor starters energize, valves shift, lights change — all updated together at this moment, not scattered through the scan.

4. Housekeeping and communications

Before looping back, the PLC services its own overhead: communication requests (the HMI/SCADA polling for data, messages from other controllers over networks like Modbus), internal diagnostics, and the watchdog timer — a hardware safety check that faults the processor if a scan ever takes longer than its allowed limit (a sign of a program stuck in a loop).

Scan time: how fast is this loop?

Typical scan times run from well under a millisecond on small, fast programs to tens of milliseconds on large ones. Scan time depends on program length and complexity, instruction types (math and file operations cost more than contacts and coils), I/O count, and communication load. Every PLC platform reports its current, minimum, and maximum scan time in system status data — worth checking on any machine you maintain.

Why the scan cycle matters in practice

Fast pulses can be invisible

An input pulse shorter than one scan can begin and end entirely between two input scans — the program simply never sees it. This bites hardest with fast-moving parts and short sensor pulses. The fixes exist precisely because the scan exists: high-speed counter hardware, interrupt/event tasks, and input latching, which catch fast events independently of the scan loop.

Response time has a floor

Worst case, an input that changes just after an input scan waits almost a full scan to be read, plus a scan for logic, plus output hardware delay. Machine designs that need faster reactions than the scan allows use event-driven tasks or dedicated hardware rather than hoping the scan is quick enough.

Rung order is logic

Because execution is strictly top-to-bottom, moving a rung can change behavior. Classic beginner bug: writing the same output coil on two different rungs — the last rung executed wins every scan, and the earlier rung appears "broken." (One coil, one rung; use branch logic instead.)

Outputs freeze between scans

Physical outputs only change during the output scan. Whatever your logic computes mid-scan, the outside world sees one clean update per cycle — which is exactly what makes PLC behavior deterministic and repeatable.

A concrete example

Say a start button is pressed while the PLC is mid-way through executing its program:

1. This scan's program phase does not see it — the input snapshot was taken before the press.
2. The next input scan captures the button as ON.
3. That scan's program phase runs the start logic and sets the motor output in the output image.
4. That scan's output phase writes the terminal; the starter energizes.

Total delay: a scan or so — typically a few milliseconds. Invisible to a human pressing a button, but absolutely central to how engineers reason about machine timing.

Modern wrinkles worth knowing

The classic single loop is still the default mental model, but modern controllers layer options on top of it: periodic tasks that run at fixed intervals regardless of main-scan length, event tasks triggered by inputs, and (on some platforms) immediate I/O instructions that bypass the image tables for one critical read or write. All of these are best understood as deliberate exceptions to the scan cycle — which is why the scan itself is the thing to learn first.

Frequently asked questions