PLC Scan Cycle Explained: How a PLC Executes Your Program
The PLC scan cycle explained — input scan, program execution, output update, and housekeeping, scan time, and why the scan affects your logic and timing.
What Is the PLC Scan Cycle?
The PLC scan cycle is the continuous, repeating loop that a programmable logic controller executes to read inputs, run your program, and write outputs. Every PLC — regardless of manufacturer, model, or programming language — operates on this fundamental principle. Understanding the scan cycle is not optional background knowledge. It is the single most important concept for writing correct, reliable PLC logic.
A PLC does not respond to inputs the moment they change. It reads all inputs at once, processes your entire program from top to bottom (or rung to rung in ladder logic), then writes all outputs at once — and immediately starts over. This happens hundreds or thousands of times per second in a healthy system. That repeating loop is the scan cycle.
If you are new to PLC programming, the complete PLC programming introduction and the PLC programming basics guide provide the hardware and software context that makes this article easier to follow. For those already comfortable with the fundamentals, read on — the scan cycle governs behavior that trips up even experienced programmers.
The Four Phases of the PLC Scan Cycle
Every scan consists of four distinct phases, executed in order, repeatedly, for as long as the PLC is in Run mode.
Phase 1: Input Scan
At the start of each scan, the PLC reads the physical state of every digital and analog input connected to its input modules. It stores those values in a dedicated memory area called the input image table (also called the process image input or input image register, depending on the manufacturer).
This snapshot is what your program actually reads during execution. The physical inputs are not read again during program execution — only the image table is consulted. If a sensor changes state halfway through your program, that change is invisible until the next scan's input scan phase.
This snapshot behavior is intentional. It ensures that your entire program sees a consistent, coherent view of the real world for the duration of one scan. Without it, a fast-changing input could affect some rungs but not others within the same scan, producing unpredictable, non-deterministic behavior.
Phase 2: Program Execution (Logic Scan)
With the input image table freshly populated, the CPU works through your program. In ladder logic, it evaluates rungs from top to bottom, left to right. In structured text or function block programs, it follows the defined execution order of your program organization units (POUs).
As the CPU evaluates each instruction, it reads from the input image table and writes intermediate results to the output image table (the process image output). Coils and output bits are written to this output image — not to the physical output terminals. The physical outputs have not changed yet.
This means that within a single scan, if Rung 1 sets a bit and Rung 50 reads that same bit, Rung 50 will see the new value. Rung order therefore has a direct effect on program behavior, a point covered in detail below.
Phase 3: Output Update (Output Scan)
Once program execution is complete, the CPU copies the output image table to the physical output modules. This is the moment the real world changes: relays close, transistor outputs switch, analog modules update their signal levels.
All outputs update simultaneously from the perspective of the controlled system — the update happens in one burst at the end of the scan, not incrementally as each rung is processed. This is why you can have a coil energized in the output image long before the physical output actually switches.
Phase 4: Housekeeping and Communications
The final phase handles overhead tasks that keep the PLC functioning correctly:
- Watchdog timer service — the CPU resets an internal timer to confirm the scan completed normally (more on this below)
- Communications processing — the CPU handles requests from HMIs, SCADA systems, programmer terminals, and peer controllers over Ethernet, Profibus, or other networks
- Diagnostics and self-checks — the CPU checks memory integrity and module health
- Special function execution — some manufacturers process certain system tasks or interrupt-driven functions here
The housekeeping phase adds to total scan time and can vary depending on network traffic, diagnostic load, and the number of active communication connections.
Scan Time: What It Is and What Affects It
Scan time is the elapsed time for one complete pass through all four phases. It is measured in milliseconds. The total scan time determines how quickly your PLC can respond to a change in the real world.
Typical Scan Time Values
| Application Type | Typical Scan Time |
|---|---|
| Simple discrete I/O logic | 1–5 ms |
| Mixed discrete and analog | 5–20 ms |
| Complex math, motion, large programs | 20–100 ms |
| Safety PLCs (redundant checking) | 10–30 ms |
| High-performance servo applications | <1 ms (with dedicated motion tasks) |
These are representative ranges, not specifications. Your actual scan time depends on your specific hardware, program size, and communication load.
Factors That Increase Scan Time
- Program size — more rungs, more instructions, more execution time
- Floating-point math — substantially slower than integer arithmetic on most CPUs
- Analog I/O processing — analog modules take longer to scan than discrete modules
- Communication traffic — heavy SCADA polling or many active connections increase housekeeping time
- Indirect addressing and loops — complex addressing modes and FOR/NEXT loops add cycles
- Function block complexity — PID blocks, communication function blocks, and data conversion routines carry real execution overhead
Most PLCs have a status register or diagnostic display that shows the current, minimum, and maximum scan time. Monitor maximum scan time, not average — the worst-case scan time determines your worst-case response latency.
Why the Scan Cycle Matters: Practical Consequences
The Input Image Table and Mid-Scan Changes
Because the input image table is a snapshot taken at the start of the scan, a physical input that changes state during program execution is invisible to that scan. The change will be captured in the next scan's input scan phase.
Consider a push button wired to an input. If an operator presses that button 2 milliseconds into a 10 ms scan, the program running in that scan will not see the press. The CPU is already working from the snapshot taken before the button was pressed. The press will be reflected in the next scan — at most one full scan time of latency for a held input.
For inputs that are held high or low for longer than one scan time (nearly all industrial process inputs), this is completely transparent. For very short pulses — signals narrower than one scan time — you risk missing the event entirely. This is where hardware high-speed counter inputs and interrupt routines become necessary.
Response Latency
The worst-case response time from a physical input change to a physical output change is approximately two full scan times: one scan where the input change might arrive just after the input scan phase (so it is captured in the next scan), plus one more scan for program execution and output update.
For a 10 ms scan, worst-case latency is approximately 20 ms. For a 50 ms scan, it is approximately 100 ms. This is adequate for most industrial process control applications but completely inadequate for motion control, high-speed counting, or safety-critical timing where milliseconds matter.
Rung Order and Order of Execution
Rung order in ladder logic determines program behavior, not just program organization. The CPU processes rungs sequentially from top to bottom within each scan. This creates a within-scan data dependency that you must understand to write correct logic.
Rung Order Example
Imagine three rungs:
- Rung 1: Contact
Sensor_Acontrols coilInternal_Flag - Rung 2: Contact
Internal_Flagcontrols coilOutput_1 - Rung 3: Contact
Sensor_BresetsInternal_Flag
In this order, if Sensor_A is on and Sensor_B is also on in the same scan:
- Rung 1 sets
Internal_FlagON - Rung 2 sees
Internal_FlagON and energizesOutput_1 - Rung 3 resets
Internal_FlagOFF
Output_1 fires for one scan. If you move Rung 3 above Rung 2:
- Rung 1 sets
Internal_FlagON - Rung 3 immediately resets
Internal_FlagOFF - Rung 2 sees
Internal_FlagOFF —Output_1never energizes
Same logic, different rung order, completely different behavior. This is not a bug — it is a designed characteristic. Understanding it lets you write predictable logic; misunderstanding it produces intermittent faults that are very difficult to debug.
The Double-Coil Problem
A double coil is when the same output coil (or internal bit coil) appears in more than one rung. In ladder logic, the last rung wins. If Rung 5 energizes Output_Y and Rung 80 de-energizes Output_Y, the physical output will be OFF at the end of the scan regardless of what Rung 5 computed. This is a common source of difficult bugs and is flagged as an error or warning by most programming environments.
Use internal flags and control the physical output from a single coil at the end of your logic flow, or use the Set (latch) and Reset (unlatch) instruction pair to manage state explicitly. For toggle and pulse behavior, see the related article on one-shot / rising edge instructions.
One-Shot Instructions and Scan-Sensitive Timing
A one-shot (OSR in Allen-Bradley, P in IEC 61131-3, DIFU in Omron) detects the rising edge of a signal and produces a single-scan pulse. The instruction stores the previous scan's bit state internally and compares it to the current scan. When it detects a 0-to-1 transition, the output bit is ON for exactly one scan — no more, no less.
Because the one-shot relies on comparing the current scan state to the previous scan state, it requires one scan to detect the transition. If you need a one-shot on a very fast pulse, you must ensure the pulse lasts at least one full scan time — otherwise the PLC may see the input already gone and never generate the edge output. For signals faster than your scan time, a hardware latch or interrupt input is the correct solution. See also normally open vs normally closed contact behavior as it relates to signal conditioning.
The Watchdog Timer
The watchdog timer is a hardware timer inside the PLC CPU that must be reset by the CPU at the end of every successful scan. If the scan takes longer than the configured watchdog timeout (typically 100–500 ms, configurable), the watchdog timer expires, the CPU declares a fault, forces all outputs to their safe state (usually OFF), and halts program execution.
The watchdog timer prevents a stuck or infinite-looping program from holding outputs energized indefinitely — a critical safety feature. If you write a FOR loop or a communication instruction that hangs, the watchdog will catch it before machinery is damaged.
Never deliberately stretch the scan time to create a delay. Use timer instructions (TON, TOF) for timing within your program. Delays created by scan manipulation are unpredictable, non-repeatable, and can trip the watchdog.
If your scan time approaches the watchdog threshold, investigate immediately. Common causes are infinite or very long loops, communication timeouts, and runaway recursive logic.
Synchronous Scan vs. Event-Driven and Interrupt Tasks
The standard scan cycle described above is a synchronous, periodic task — it runs continuously at whatever rate the hardware supports. Most PLC programs live entirely in this synchronous task. But modern PLCs also support event-driven and periodic interrupt tasks that run outside the normal scan cycle.
Interrupt Routines (ISRs / Event Tasks)
An interrupt routine is a program block that executes immediately when a specific hardware or software event occurs, pausing the main scan at its current point. Common interrupt triggers include:
- High-speed counter interrupts — fires when a counter reaches a preset value
- Timed interrupts — fires every N milliseconds, independent of main scan time
- I/O interrupts — fires immediately on a specific input state change (not all hardware supports this)
- Communication interrupts — fires on receipt of a specific message
Interrupt routines execute in microseconds (ideally) and return control to the paused main scan. They are the correct solution for events that outrun the scan: counting high-frequency encoder pulses, responding to safety inputs within microseconds, or executing high-speed positioning moves.
Variables shared between the main task and an interrupt routine must be treated carefully. A mid-scan interrupt that modifies a variable your main program is also writing creates a race condition. Most platforms provide disable-interrupt instructions or atomic semaphore mechanisms to protect shared data.
High-Speed Counter Inputs
A dedicated high-speed counter (HSC) input bypasses the input image table entirely. The hardware counter increments on each pulse, independent of the scan cycle. Your program reads the accumulated count value from a status register. This is how PLCs reliably count encoder pulses at tens or hundreds of kilohertz — a scan-cycle-dependent approach would miss pulses the moment the pulse rate exceeded 1/(2 × scan time).
Periodic Motion Tasks
Servo and motion control axes typically run in a dedicated high-priority periodic task with a fixed execution rate (often 1 ms or 2 ms) that preempts the main scan on its schedule. From the perspective of the main scan, the motion task appears to run asynchronously. The main scan communicates with the motion task through shared data structures, not direct coil writes.
Frequently Asked Questions
What is the PLC scan cycle? The PLC scan cycle is the continuous repeating loop that a PLC executes: read all inputs into the input image table, execute the program logic top to bottom, write the output image table to physical outputs, then perform housekeeping and communications — and immediately start over.
What are the steps of the PLC scan cycle? The four steps are: (1) input scan — snapshot all physical inputs into the input image table; (2) program execution — run all logic using the image tables; (3) output update — copy the output image table to physical output modules; (4) housekeeping — service the watchdog timer, handle communications, and run diagnostics.
What is PLC scan time? Scan time is the elapsed time for one complete scan cycle, measured in milliseconds. Typical values range from 1 ms for simple programs to over 50 ms for large programs with heavy communication loads. Scan time sets the worst-case response latency of your PLC to a physical input change.
Why does rung order matter in ladder logic? Because the CPU executes rungs sequentially within each scan, internal bits set by an early rung are immediately visible to later rungs in the same scan. If you place a rung that reads a bit before the rung that sets that bit, the reading rung uses the previous scan's value. Rung order therefore determines within-scan data flow and must be planned deliberately.
Summary
The scan cycle is not an implementation detail — it is the architectural heartbeat of every PLC system. Inputs are snapshots, outputs are deferred, and your program executes in a strict sequential order. Write logic that works with these characteristics rather than against them.
Key takeaways:
- The input image table is a frozen snapshot; mid-scan changes are not visible until the next scan
- All outputs update at the end of the scan, not rung by rung
- Rung order controls within-scan data flow — the last coil write wins
- Double coils produce the last-rung result and should be avoided
- Scan time sets your worst-case response latency; monitor maximum scan time, not average
- Events faster than one scan time require hardware interrupts or high-speed counter inputs
- The watchdog timer protects machinery if your program hangs or runs too long
- Interrupt tasks and periodic motion tasks run outside the main scan when determinism demands it
For a deeper look at the programming constructs that run inside the scan, the ladder logic tutorial and the PLC programming languages guide are the recommended next steps.
