The PLC Scan Cycle: Why Your Logic Sees a Frozen Snapshot

Legacy context

The old industrial league grounds still hum with a particular rhythm—a twelve-page thickness of playbooks, layered formations, and zero outside interference. That was the era of pure control, where every down was measured, every adjustment deliberate, and the clock dictated everything. The sideline operated like a closed loop: call, execute, reset, repeat. There was no room for wasted motion, only the steady cadence of a system built to run itself into the ground, then run again.

That same discipline now finds a quieter home in the language of modern machinery. The plc scan cycle is the heartbeat of that old playbook—a fixed interval where inputs are read, logic is processed, and outputs are updated, all within a rigid, repeating frame. It is the industrial equivalent of a huddle breaking cleanly, a snap count that never varies. The heritage of thick, self-contained systems lives on in this scan, where every millisecond is accounted for and no external noise breaks the sequence. The field has changed, but the principle remains: control the cycle, and you control the game.

The Three-Phase Scan

A programmable logic controller (PLC) executes its control program in a repeating cycle called the scan. The scan proceeds through three distinct phases: input image update, program solve, and output write. During the input image update, the PLC interrogates sensors within the plant process and copies their states into an internal memory table called the input image [1]. The program solve phase then executes the user logic—the rungs of ladder logic or other programming languages—using only the data in that image table. Finally, the output write phase copies the results from the output image table to the physical output modules, which drive actuators such as valves, motors, and solenoids.

This three-phase structure is fundamental to how PLCs behave. The scan is continuous: after the output write completes, the next scan begins with a fresh input image update. The entire cycle repeats as long as the controller is in the Run mode.

Why Logic Sees a Snapshot, Not Live Field State

The most important consequence of the scan structure is that the program solve phase does not see live field conditions. When the input image update completes, the states of all inputs are frozen in memory. During the program solve, even if a physical sensor changes state, the logic continues to evaluate against the old snapshot. The new value will not appear until the next scan's input image update.

This snapshot behavior is intentional. It provides a consistent, repeatable view of the process for the duration of one program solve. Without it, a rung evaluated early in the program could see a different input state than a rung evaluated later, making the logic nondeterministic and nearly impossible to debug. The snapshot also decouples the logic execution from the timing jitter of field wiring and network communication.

Scan Time and Its Variability

Scan time is the total duration of one complete cycle. It varies with several factors. Each scan places a load on the device, and the applied load depends on the number of devices scanned, the protocols used, the processing and memory capabilities of the device, and the complexity of the rules being applied [1]. A small program with a few dozen rungs may scan in under a millisecond, while a large program with thousands of rungs, complex math, and extensive communication blocks may take tens of milliseconds or more.

The latency distribution of packets between the plant and controller determines what sensors are scanned and what actuators are updated successfully [1]. If the field network is slow or congested, the input image update phase can dominate the scan time. Communication protocols differ in their overhead; a non-routable protocol such as DeviceNet behaves differently from a routable protocol such as EtherNet/IP in terms of timing and determinism [4].

Interrupts also affect scan time. Many PLCs support interrupt routines that execute asynchronously—for example, on a timed interval or on a fast input transition. When an interrupt fires, the normal scan is suspended while the interrupt routine runs, then the scan resumes. This adds unpredictable time to the overall cycle. Engineers must account for this when setting timing budgets for time-critical processes.

Race Conditions and One-Scan Delays from Rung Ordering

Because the program solve uses a snapshot, the order of rungs matters. Consider two rungs that both write to the same output coil. The rung that executes last determines the final state of that output for the scan. If the first rung sets the output on and the second rung sets it off, the output will be off at the end of the scan, regardless of the first rung's intent. This is a race condition in the logic: the result depends on execution order, not on process conditions.

A related effect is the one-scan delay. If a rung reads an input and a later rung in the same scan writes an output based on that input, the output update occurs in the same scan. But if the logic requires feedback from an output—for example, a seal-in circuit that reads its own output contact—the feedback is not available until the next scan. The output image is updated only during the output write phase, so a rung that reads an output coil sees the value from the previous scan's output write. This creates a one-scan delay that can be significant in fast processes.

Rung ordering also affects intermediate values. If rung A computes a value into a memory word and rung B uses that value, rung B must come after rung A in the program. If the order is reversed, rung B uses the stale value from the previous scan. This is a common source of subtle logic bugs.

Watchdog Timeouts

PLC processors include a watchdog timer that monitors the scan. If the scan time exceeds a configured limit, the watchdog trips and the processor faults, typically forcing outputs to a safe state. The watchdog limit is set by the programmer or by the manufacturer's default. It exists to catch runaway conditions such as an infinite loop in the logic, a corrupted program, or an excessive interrupt load.

The watchdog limit must be set above the worst-case normal scan time, including the effect of interrupts. If the limit is too tight, the processor will fault during normal operation. If it is too loose, a genuine fault may go undetected for too long. Engineers should measure the actual scan time under worst-case conditions—all inputs active, all communication blocks executing—and set the watchdog with appropriate margin.

When Immediate Input and Output Instructions Are Justified

Most PLCs offer immediate input and immediate output instructions. An immediate input instruction reads the physical input directly during the program solve, bypassing the input image. An immediate output instruction writes directly to the physical output during the program solve, bypassing the output image. These instructions break the snapshot model and provide faster response.

Immediate instructions are justified in specific situations. They are appropriate for safety interlocks where a one-scan delay is unacceptable—for example, an emergency stop that must de-energize a motor within the same scan. They are also useful for high-speed counting or pulse capture where the input changes faster than the scan rate. However, immediate instructions have costs. They increase scan time because the processor must wait for the physical I/O bus transaction. They also reintroduce the nondeterminism that the snapshot model was designed to eliminate: a rung using an immediate input sees a different value than a rung using the image, and the timing of the physical read depends on the position in the scan.

The evidence does not provide specific numerical guidance on when to use immediate instructions or on typical scan-time limits. In practice, the decision is a trade-off: use immediate instructions sparingly, only where the process demands it, and document their use carefully. For most control logic, the standard snapshot scan provides adequate performance and far better predictability.