The short answer
The PLC Scan Cycle
The PLC scan cycle is the repeating sequence a controller executes: it copies input states into memory, solves the program top to bottom using that frozen copy, writes the resulting output states to the output modules, then handles communications and diagnostics. Scan time is how long one full pass takes, typically a few milliseconds. Logic sees inputs as they were at the start of the scan, not as they change during it.
Key points
- Inputs are frozen into an image table at the start of the scan, so logic sees a consistent snapshot.
- Outputs are written at the end of the scan, not the instant a rung solves true.
- Rung order matters: a later rung sees the result of an earlier one in the same scan.
- A signal shorter than one scan can be missed entirely unless you latch it or use a high-speed input.
- The watchdog faults the processor if a scan runs longer than its configured limit.
The four phases
- 1
Input scan
The processor reads every input module and copies the states into an area of memory usually called the input image table. From this moment until the next scan, the program sees this frozen copy. If a field contact changes state one microsecond later, the program will not know until the next scan.
- 2
Program scan
The controller solves the logic, normally from the first rung to the last, in order. Each instruction works against the input image table and against internal memory that other rungs may have already changed during this same pass.
- 3
Output scan
The output image table, which the program has been writing to, is copied out to the physical output modules. This is the moment a coil in software becomes 24 volts on a terminal.
- 4
Housekeeping
Communications are serviced, diagnostics run, memory is checked, and the watchdog is reset. Then the cycle repeats.
Why rung order matters
Because the program solves top to bottom in a single pass, a bit set on rung 5 is already set when rung 60 examines it. A bit set on rung 60 will not be seen by rung 5 until the next scan. Most of the time this is invisible. It becomes very visible when someone reorders routines during a cleanup and a sequence that always worked starts taking an extra scan to advance.
Order A Order B
Rung 1: Start_PB --> Run Rung 1: Run --> Pump_Out
Rung 2: Run --> Pump_Out Rung 2: Start_PB --> Run
Order A: pressing the button energizes Pump_Out in the SAME scan.
Order B: pressing the button energizes Pump_Out one scan LATER,
because rung 1 examined Run before rung 2 set it.Scan time and what moves it
Scan time is not a fixed number. It varies with how much of the program executes on a given pass, how much communication traffic is being serviced, and how much remote I/O has to be gathered. A controller that scans in 6 ms with everything idle may scan in 15 ms during a heavy SCADA poll.
| What increases scan time | Typical impact | What to do about it |
|---|---|---|
| Large amounts of always-executing logic | Proportional and predictable | Condition routines so unused sections do not execute |
| Remote I/O over a network | Adds network update time, not just scan time | Match the requested packet interval to what the process actually needs |
| Heavy message instructions | Bursty, can spike scan time | Stagger messages, trigger on change rather than every scan |
| Large loop and array operations | Can be significant | Break work across scans or move to a slower periodic task |
| Excessive SCADA polling | Shows up as housekeeping time | Poll on change of state where the protocol supports it |
Tasks: when the simple model stops being enough
Modern controllers let you split a program into tasks. A continuous task runs whenever nothing else needs the processor. A periodic task runs on a fixed interval, such as every 50 ms, which is how you get a PID loop to execute at a consistent rate regardless of what the rest of the program is doing. An event task runs in response to a trigger.
Pulses shorter than a scan
A flow meter pulse, a fast limit switch, or a brief contact bounce can occur and clear entirely between two input scans. The program never sees it. This is not a defect; it is the direct consequence of sampling. If you need to count fast pulses, use a high-speed counter input, which counts in module hardware and hands the program a total. If you need to catch a brief event, latch it in the field device or use an input module with a latching feature.
The watchdog
Each scan resets a watchdog timer. If a scan takes longer than the configured watchdog value, the processor faults and, in most configurations, drops its outputs to a safe state. The usual causes are an unbounded loop, a routine calling itself, or a message instruction waiting on a device that stopped answering. A watchdog fault is telling you the program did not finish, which is a very different problem from a program that finished with the wrong answer.
Frequently asked questions
- What is a typical PLC scan time?
- For a small to medium water or wastewater application, 5 to 20 milliseconds is typical. Large plant controllers with heavy communications may run 30 to 80 milliseconds. What matters is not the number itself but whether it is stable and comfortably under the watchdog setting.
- Why did my output not turn on immediately when the input closed?
- Because outputs are written at the end of the scan and inputs are read at the beginning. Depending on where in the scan the input actually changed, the response takes between one and two full scans plus input filter time and output device switching time.
- Does putting logic in a subroutine make the scan faster?
- Only if the subroutine is conditionally called and is often not called. Moving code into a routine that runs unconditionally every scan changes nothing except organization.
- What causes a watchdog fault?
- A scan that did not complete within the configured watchdog time. Look for loops without a bounded exit, recursive routine calls, a message instruction blocking on an unresponsive device, or an unexpectedly large array operation.
Related topics
- What Is a PLC?A programmable logic controller is a ruggedized industrial computer that reads field inputs, solves a control program, and drives outputs on a repeating, deterministic cycle.
- Tasks and Execution PriorityHow a controller schedules its work: the continuous task, periodic tasks at a fixed rate, event tasks triggered by something happening, how priority preempts, and where each kind of logic belongs.
- The Watchdog TimerWhat the scan watchdog protects against, why it faults the controller instead of pausing it, what makes a scan run long, and why raising the limit is the wrong first response.
- Logic Not Executing As ExpectedThe rung looks right and the plant does something else. The scan-order, duplicate-output, unscheduled-routine, and data-type traps behind it, and how to find which one you are in.
- PLC ArchitectureHow a programmable logic controller is physically organized: the chassis, backplane, processor, I/O modules, remote racks, and what those choices mean for wiring, expansion, and failure.
- The PLC ProcessorWhat the processor module does on every scan, how its memory is organized, what the mode switch and status lights mean, and how it faults and recovers.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.