The PLC scan cycle is the fundamental execution model that underpins all PLC-based control systems. Understanding it is not optional for automation engineers — scan cycle behaviour determines whether your control logic will respond to process events in time, whether timers will be accurate, and whether your program will behave predictably under all load conditions. This article explains the scan cycle in depth, covers the determinism requirements that separate PLCs from general-purpose computers, and identifies the common pitfalls that cause programs to behave unexpectedly.

The Four Phases of a PLC Scan

A PLC scan cycle has four sequential phases that repeat continuously:

  1. Input scan: The PLC reads all physical input values (discrete and analogue) and copies them into an internal memory area called the input image table (or process image input, in Siemens terminology). This snapshot is what the logic sees during the entire program execution phase. Field inputs changing during program execution do not affect the current scan — they are captured in the next scan.
  2. Program execution: The PLC executes the control program from start to finish, reading input values from the input image table and writing output values to the output image table. In Ladder Diagram, rungs are executed sequentially from top to bottom, left to right. In Structured Text, statements execute in textual order. Execution time depends on program complexity and instruction count.
  3. Output scan: The PLC copies all values from the output image table to the physical outputs. This is when control valves, motor contactors, and indicators actually change state. Outputs do not change during program execution — only at the end of each scan.
  4. Housekeeping: Internal communications (peer-to-peer messaging, HMI data exchange, diagnostic updates), self-diagnostics, and operating system tasks. Duration varies based on communication load.

Scan Time: What Determines It

Scan time is the total duration of one complete scan cycle. It consists of:

  • Input scan time: Typically 0.1-2 ms, depending on I/O count and I/O bus speed
  • Program execution time: The dominant variable. Proportional to program size and instruction types. Mathematical operations (floating-point division, trigonometry) consume more time per instruction than simple bit logic.
  • Output scan time: Similar to input scan time
  • Housekeeping time: Highly variable. Heavy communication loads or enabled diagnostic features can add 5-20 ms

Typical scan times range from 5 ms to 50 ms for standard process control applications. Motion control PLCs may run scan times of 0.5-2 ms. A PLC with a 20 ms scan time updates its outputs at most 50 times per second — control loops faster than this require interrupt-driven tasks or dedicated motion controllers.

Determinism: Why PLCs Are Not PCs

Determinism means that a control system produces the same output within a guaranteed time for a given input. A PLC is designed to be deterministic. A general-purpose computer (running Windows, Linux) is not.

PLCs achieve determinism through several mechanisms:

  • Fixed execution order: The scan cycle always executes in the same sequence. There are no background processes that pre-empt control logic execution (unlike Windows, where any process can pre-empt any other based on priority).
  • Watchdog timer: Every PLC has a watchdog timer — a hardware timer that triggers a fault if the scan cycle does not complete within a defined maximum time. If the scan overruns (due to a program loop, excessive communication load, or hardware fault), the watchdog trips the PLC into a safe state (outputs to de-energised defaults) rather than letting the program run indefinitely.
  • Real-time operating system (RTOS): Modern PLCs run an RTOS that provides guaranteed scheduling of the scan cycle task. The RTOS ensures the scan always starts within a bounded interval, regardless of communication or diagnostic load.

PC-based control systems (Beckhoff TwinCAT, Rockwell SoftLogix, Siemens WinAC) achieve similar determinism by running the control task on an RTOS partition isolated from the Windows operating system. The real-time kernel gets CPU priority; Windows runs in the background when real-time tasks are not executing.

Periodic Tasks and Interrupt-Driven Tasks

Most modern PLCs support multiple task types beyond the basic cyclic scan:

  • Periodic tasks: Execute at a defined interval (e.g., every 100 ms), independent of the main scan. Used for slower, non-critical monitoring tasks that would otherwise consume scan time in the main program.
  • Event-driven (interrupt) tasks: Execute immediately when a hardware interrupt occurs — typically a rising edge on a discrete input or a motion encoder position. Used for high-speed position capture, fast conveyor counting, and emergency interlock response faster than one scan time.
  • Background tasks: Execute only when the CPU has spare cycles after completing all periodic and event tasks. Used for data logging, report generation, and communications. Not suitable for any time-critical logic.

In Siemens TIA Portal, these correspond to OB1 (cyclic program), OB3x (periodic interrupt OBs), OB4x (hardware interrupt OBs), and OB90 (background OB). In Rockwell Studio 5000, they are Continuous, Periodic, and Event tasks.

The Impact of Scan Time on Control Loop Performance

PID control loops are sensitive to scan time. The scan time is effectively a delay in the feedback path — the controller does not see the effect of its output change until the process has responded and the transmitter reading has been captured in the next input scan. For stable, slow processes (temperature, level), a 500 ms scan time has negligible impact. For fast processes (pressure, flow in fast loops), scan times above 100 ms introduce noticeable control degradation.

The practical rule: the scan time should be at least 5-10 times faster than the fastest closed-loop time constant in the control programme. For a flow loop with a 2-second process time constant, a 200 ms scan time is adequate. For a compressor surge control loop with a 100 ms time constant, you need a scan time of 10-20 ms and likely a dedicated high-speed task.

Avoiding Scan Cycle Problems in Practice

  • Monitor scan time continuously: All PLC platforms provide a scan time monitor. Set a high-scan-time alarm at 80% of the watchdog timeout. Investigate any sustained increases in scan time — they indicate growing program complexity or communication overload.
  • Avoid long loops in scan-sensitive programs: A FOR loop that iterates 10,000 times in a single scan extends scan time proportionally. Move long-running calculations to periodic tasks with generous time allocations.
  • Test under full communication load: SCADA polling, historian data collection, and peer-to-peer messaging all consume housekeeping time. Test scan time performance with all communications active, not just with the PLC running alone.
  • Understand your watchdog configuration: Know your watchdog timeout and what happens when it trips. Verify that watchdog-triggered outputs fail safe (de-energised, control valves fail to their safe position) and that operators receive a clear alarm indicating the PLC fault mode.