The PLC scan cycle — explained, with examples

The PLC scan cycle is the single most important concept that separates someone who writes ladder logic that runs from someone who writes ladder logic that works. PLCs are not event-driven. They do not wake up when an input changes. They run a loop — top to bottom, again and again, thousands of times a second — and every input, every output, every contact and coil and timer in your program lives inside that loop. Until you internalise this, ladder logic looks like it should work and then quietly does not, and you spend an afternoon staring at a rung that reads correctly to a human and misbehaves on the chassis.

One opinion stated outright. Anyone who cannot sketch the four phases of the scan cycle on a napkin is going to write a bug they cannot explain. The most common bugs in industrial code — duplicate coils, missed pulses, race conditions between two rungs that look independent — all trace back to scan-cycle ignorance. You can write working code without understanding it the way you can drive a car without understanding the differential. You will eventually break something you cannot diagnose.

Why the scan cycle matters

A PC programmer reads "when the button is pressed, turn on the light" and writes an event handler. A PLC programmer reads the same sentence and writes a rung that says "if the button input is currently true on this scan, then on this scan, write true to the output." The difference matters. The PC version executes once when the operating system delivers the button event; the PLC version executes every scan, forever, whether the button changed or not.

That distinction shows up the first time you try to debounce a switch with a rung that says "if button is on and last-button was off then increment counter." On a PC that latches the count once per press. On a PLC, depending on how last-button is wired, you can latch once, latch on every scan that the button is held, or never latch at all. The bug is not in the rung's logic. The bug is in not understanding that the rung runs every scan.

The scan cycle also explains why force values work the way they do, why two coils with the same address produce a "last write wins" effect, why a timer that should pulse for 100 ms can fire for 0 ms or for an entire second, and why your program seems to "miss" inputs that you saw flicker on the LED. Every one of those behaviours is the scan cycle doing exactly what it is documented to do, in an order that surprises programmers who learnt event-driven thinking first.

The four phases — input scan, program scan, output scan, housekeeping

The PLC scan, in order, is four phases:

   ┌────────────────────────────────────────────────────────┐
   │                                                        │
   │  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐   │
   │  │  1. Input   │   │ 2. Program  │   │  3. Output  │   │
   │  │    Scan     │──▶│    Scan     │──▶│    Scan     │   │
   │  │             │   │             │   │             │   │
   │  │ field → PII │   │ PII → logic │   │ PIO → field │   │
   │  └─────────────┘   │   → PIO     │   └─────────────┘   │
   │                    └─────────────┘                     │
   │                                                        │
   │                  ┌─────────────────┐                   │
   │                  │ 4. Housekeeping │                   │
   │                  │   comms · WDT   │◀──────────────────┤
   │                  │  diagnostics    │                   │
   │                  └─────────────────┘                   │
   │                                                        │
   └────────────────────────────────────────────────────────┘
            (loop repeats — typically 1–50 ms per scan)

PII is the Process Image of Inputs (Siemens calls it the Prozessabbild der Eingänge; Rockwell calls it the input data table). PIO is the Process Image of Outputs. The process image is the key. Your program does not read the field. Your program reads a snapshot of the field that was taken at the start of the scan. Your program does not write the field. It writes a buffer that gets copied to the field at the end of the scan.

Every phase has a duration. The four added together — input scan time, program scan time, output scan time, housekeeping time — is the scan time, and the scan time is the heartbeat of the controller.

Phase 1 — input scan

At the start of every scan, the CPU asks each input module on the backplane (and each remote IO drop on the network) for the current state of every input channel. The values get copied into the process image of inputs in CPU memory. From this moment until the start of the next scan, the program will read those copied values, not the live field values.

This is the source of the "I changed the sensor mid-rung and nothing happened" bug. You watch the sensor LED on the input card go on. You expect the rung to react immediately. But the rung had already evaluated against the old PII value before the sensor changed; the change will only be reflected on the next scan, after the next input scan reads the new state.

For 99 percent of industrial applications this is invisible — scans are short, inputs are slow, and a one-scan delay is irrelevant. The cases where it bites are the high-speed ones. A part counter looking at a photoelectric sensor that is triggered for 5 ms by a passing bottle, on a controller running a 12 ms scan, will miss bottles. A safety circuit that reacts to a 10 ms light-curtain interruption on a 25 ms scan will not see every interruption. The rule of thumb is the Nyquist criterion restated for PLCs — your scan must be at least twice as fast as the shortest pulse you need to catch, and in practice you want a comfortable margin beyond that.

There is one architectural escape hatch. Most modern controllers support immediate-input instructions (IIN on Rockwell, :P qualifier on Siemens addresses, e.g. %I0.0:P) that bypass the process image and read the channel directly when the rung executes. Use them for genuine high-speed inputs and accept that they have higher per-scan cost. The standard PII handles the rest.

Phase 2 — program scan

This is the part everyone thinks of as "the program running". Top of the program to the bottom. Rung by rung. Every rung evaluates against the input process image (frozen at the start of the scan) and writes its outputs to the output process image (which sits in memory, not yet on the field).

In a routine-based architecture — Studio 5000 with its Tasks, Programs, and Routines, or TIA Portal with its Organisation Blocks, Function Blocks, and Functions — the program scan is the orderly traversal of every routine that the active task has scheduled. Subroutine calls happen during the program scan. Function blocks evaluate during the program scan. Structured text loops execute during the program scan. None of it touches the field directly; all of it touches the process images.

The implication that catches programmers out — references to outputs do not read the field, they read the PIO. If you have a coil at %Q0.0 on rung 12, and rung 47 reads contact %Q0.0 to make a decision, rung 47 reads the value rung 12 just wrote into the PIO half a millisecond ago. The field has not seen anything yet. This is normally what you want — it makes the program internally consistent within a scan — but it occasionally surprises someone who expected to read the actual contactor state.

The program scan time is the largest single contributor to overall scan time on most programs. A short program of two hundred rungs on a CompactLogix or S7-1200 might take under a millisecond; a complex program with dozens of function blocks, motion calculations, and recipe handling on the same hardware might take five to fifteen milliseconds. Scan-time profiling — built into Studio 5000's Tasks Monitor and TIA Portal's CPU online view — tells you where the milliseconds go. Most are in three or four heavy routines; the rest of the program contributes microseconds.

Phase 3 — output scan

When the last rung finishes, the CPU copies the output process image to the physical output channels. Every relay, transistor, and analog DAC on every output module on the chassis (and on every remote IO drop) gets updated to match the PIO. The field sees the change here, not during program execution. A coil that was energised on rung 1 and de-energised on rung 200 only ever produces one transition on the field — the final state at the end of the scan, written during the output scan.

That detail is what causes the "two coils same address" bug to behave the way it does. If rung 1 writes %Q0.0 to true and rung 200 writes %Q0.0 to false, the PIO ends the scan as false. The output scan copies false to the contactor. The contactor never sees the true. There was no glitch on the field; there was no pulse; the only evidence anything happened lives in the PIO trace, which most programmers never look at.

Phase 4 — housekeeping

The bit nobody pays attention to until it eats their scan time. Housekeeping is everything that is not input, program, or output — communications, online programming requests, diagnostic updates, watchdog refresh, system clock servicing, and on some platforms the periodic refresh of HMI tag tables.

Communications is the big one. A controller talking to three HMIs over PROFINET, two drives over EtherNet/IP, and a remote IO chassis over Modbus is doing a lot of work between scans. Every protocol stack has to service its messages — receive, parse, queue, respond — and the time it takes scales with how chatty your network is. On a quiet network, housekeeping might be 200 microseconds. On a busy network with twenty HMI clients all polling overlapping tag groups, housekeeping can climb past five milliseconds and start dominating the scan.

The watchdog refresh happens here too. Every scan, the CPU pets its own watchdog timer. If the program scan takes too long and the watchdog never gets fed, the timer expires and the CPU faults — see the next-but-one section.

Scan time — the number that matters

Scan time is the duration of one full cycle through phases 1 to 4. It is the headline number every PLC vendor publishes for every controller. Typical numbers, with the caveat that "your mileage will vary":

• Compact PLCs (S7-1200, Micro820, FX5U) on simple programs (under 500 rungs): 1 to 10 ms per scan.
• Mid-tier PLCs (S7-1500 standard, CompactLogix, NX1P2) on production programs (1000 to 5000 rungs with motion and PID): 5 to 30 ms per scan.
• High-end controllers (S7-1500F, ControlLogix 1756-L8, Mitsubishi iQ-R) on heavy programs: 1 to 20 ms, with periodic tasks running at sub-millisecond intervals on top.
• Specialised process controllers (S7-410, ControlLogix Process): scan times can stretch to 50 to 100 ms; the application is slow enough not to care.

The scan time matters because of pulse-catching. Any input that pulses faster than twice the scan time can be missed entirely. A 5 ms pulse on a 12 ms scan: missed often. A 50 ms pulse on a 10 ms scan: caught reliably. The math is the Nyquist criterion applied to discrete sampling, and it applies whether you want it to or not.

The other reason scan time matters is determinism. If a control engineer commits to "the safety output will deactivate within 50 ms of the safety input opening", that 50 ms is a budget — input filter time plus one scan plus output settling time has to fit inside it. A programmer who does not know their scan time cannot make that promise. Vendors document worst-case scan time alongside typical scan time for exactly this reason; on a safety calculation, you size against the worst case.

The watchdog timer

Every PLC has a watchdog. It is the controller's last line of defence against an infinite loop or a stuck program. The configuration sets a maximum scan time — typically 50 ms or 200 ms on factory defaults, configurable on most platforms up to a few seconds — and the CPU faults if any single scan exceeds it.

The most common cause of a watchdog trip is an unbounded WHILE loop in structured text. A junior programmer writes WHILE x < 10 DO ... and forgets to increment x. The loop runs forever. The scan never finishes. The watchdog fires; the CPU goes to STOP; the chassis lights go red; the line stops. On Siemens platforms, the diagnostic buffer logs an OB80 (time error) event with the scan time that exceeded the watchdog. On Rockwell, the major fault record shows a Type 6 fault, "Task Watchdog Expired", with the offending task name. The cause is almost always discoverable in the structured text or the function-block diagram of the routine that was running when the timeout occurred.

The other common cause is recursion in function blocks. Rockwell allows it; Siemens allows it; both will let you watchdog-trip yourself if the recursion has no base case. The fix is the same as for the WHILE loop — find the bug, fix the bug, re-download.

A subtle third cause is communication blocking. A MSG instruction on Rockwell that is configured to wait synchronously for a reply, when the target controller is offline, can pause the scan for hundreds of milliseconds while the message stack times out. Siemens BSEND/BRCV blocks have the same property if not configured asynchronously. The fix is to ensure communications are non-blocking — set MSG.EW (enable wait) appropriately, use the asynchronous variant of the comm instruction, and check the done/error bits on subsequent scans rather than blocking the current one.

The Siemens watchdog defaults are documented in the S7-1500 system manual on support.industry.siemens.com; the Rockwell ControlLogix watchdog defaults and configuration live on rockwellautomation.com under the Logix5000 Tasks, Programs, and Routines manual. Read the relevant chapter for whichever platform you ship to; the defaults are sensible but not universal.

Periodic vs continuous tasks

Modern PLCs do not make you fit everything into a single cyclic loop. They let you split work across multiple tasks, each with its own scan model.

A continuous task runs as fast as possible. The four phases happen, the cycle ends, the next cycle begins immediately. Whatever scan time falls out is whatever scan time falls out.

A periodic task runs on a fixed interval. Configure it for 100 ms and the controller schedules it every 100 ms regardless of what the continuous task is doing. If it does not finish inside its window, you get an overlap fault — same family of fault as the watchdog. PID loops are the canonical use case; a temperature loop wants a steady sample rate, not whatever the continuous task happens to deliver.

An event task runs in response to a trigger — a hardware input edge, a network message, a software call. Useful for high-speed counting and for tightly-coupled responses to specific events.

Vendor terminology, for cross-reference. Allen-Bradley / Rockwell uses Tasks containing Programs containing Routines; tasks are typed Continuous, Periodic, or Event. Siemens uses Organisation Blocks; OB1 is the cyclic task (continuous), OB30–OB38 are cyclic interrupts (periodic, configurable interval), OB40–OB47 are hardware interrupts (event), OB80–OB87 are error handlers. Omron uses primary periodic and priority periodic tasks. Codesys-based platforms use the IEC 61131-3 task model directly.

The standard that defines all of this — Tasks, Programs, POUs, the cyclic execution model itself — is IEC 61131-3. Every vendor's task model is a flavoured implementation of the same underlying spec; learning one well makes the others readable inside an afternoon.

The discipline. Push slow, important work (PID, recipe management, alarm logging) onto periodic tasks at appropriate intervals. Leave the continuous task for high-throughput discrete logic that benefits from the fastest possible response. Use event tasks for the half-dozen cases where you need sub-scan response to a single signal. Most production programs end up with one continuous task, two or three periodic tasks at different rates, and zero or one event tasks — anything more elaborate is usually overengineering.

Two scan-cycle bugs that bite everyone

Bug A — two coils, same address. A programmer adds a feature and writes a new rung to drive %Q0.5 based on the new condition. They forget there is already a rung earlier in the program driving the same %Q0.5 based on the old condition. Both rungs run every scan. Both write to the PIO. The output scan copies whatever the PIO holds at the end of the scan, which is whatever the second rung wrote, regardless of what the first rung did. The first rung has been silently overridden. The contactor responds only to the second rung. The original feature has stopped working and nobody has noticed because the test the operators run does not exercise the original condition.

The worked example. Rung 12 — IF Auto_Mode AND Start_Pressed THEN %Q0.5 := TRUE. Rung 89 — IF Manual_Override THEN %Q0.5 := FALSE. In automatic mode with the manual override switch on (a perfectly normal idle-line state), rung 12 sets %Q0.5 to true and rung 89 immediately sets it back to false. The contactor does not pull in. The operator presses Start, the program "runs" — the diagnostic light briefly flickers — and the conveyor stays still. A duplicate-destination check on the cross-reference report would have caught this in five seconds. Most engineering tools have one; most programmers run it after the third time they get bitten.

Bug B — timer expecting a field-level pulse but program-image-level holding. A 100 ms pulse from a high-speed sensor arrives on the input card. The card sees the pulse. The program does not — the input scan happened either side of the pulse and the PII never recorded the change. Equivalently, the card sees the pulse and the PII does record it for one scan, but the timer that was supposed to detect the rising edge is on a periodic task running every 250 ms, so it polled the PII at a moment when the pulse had already cleared.

The fix depends on the cause. If the pulse is genuinely shorter than the scan, immediate-input addressing or a hardware-input event task will catch it. If the pulse is longer than the scan but shorter than the periodic-task interval, move the detecting logic into the continuous task or shorten the periodic interval. If the pulse is occasionally arriving and occasionally not — classic intermittent — investigate whether the input filter time on the card (50 ms is a typical default on digital input modules) is filtering the pulse out before it ever reaches the PII. The filter is configurable per channel; reduce it or move the input to a high-speed counter input that bypasses the filter entirely.

Practice it in the simulator

The scan cycle becomes intuitive only after you have watched it run, paused mid-cycle, inspected the process image, and seen exactly which rung wrote which value at which moment. Reading about it gets you to the point where you know the four phases exist; watching one execute, step by step, is what makes the picture stick.

Our simulator's scan visualiser steps through one cycle at a time. The PII and PIO are visible side by side; the rung being evaluated is highlighted; the field side of the chassis updates only at the output scan boundary. Force a state, see how it propagates. Add a duplicate coil, watch the second rung overwrite the first. Add a tight WHILE loop in structured text, watch the watchdog fire and the diagnostic buffer log the OB80. The visualisation removes the magic. After an hour of stepping through cycles, scan-cycle bugs become diagnosable on sight — you read the rung, picture the PII state, picture the PIO state at the output scan, and the bug surfaces before you have powered up a real chassis.

The cert pack at the end of the curriculum tests this directly. A program is supplied with a scan-cycle bug; you have ten minutes to identify it from the symptom. Half the bugs are duplicate coils, a quarter are pulse-catching failures, the rest are watchdog trips and periodic-task overruns. The pattern recognition that comes from running the cert pack twice covers the great majority of scan-cycle bugs that show up in production code.

The next tutorial in the curriculum returns to ladder logic — specifically, the latching patterns (sealing-in coils, set/reset, master control reset) that depend on scan-cycle behaviour to work correctly. With the scan cycle internalised, those patterns stop being mysterious recipes and become obvious consequences of how the program image works.