Almost every PLC works in a repeating loop called the scan cycle. It is simple enough to describe in a sentence, and important enough that many “mystery” faults come straight from misunderstanding it.

What happens in one scan

  1. Read inputs. The state of the physical inputs is copied into an input image in memory.
  2. Execute the program. The logic runs from start to finish using that frozen snapshot of the inputs.
  3. Write outputs. The results are copied from the output image to the physical outputs.
  4. Housekeeping. Communications, diagnostics and other background tasks are serviced, and the cycle starts again.

Why it matters

  • Response time. A signal that arrives just after the inputs were read waits for the next scan, then the program runs, then the outputs are written. In the worst case the response is roughly two scan times, plus input filtering and output delays.
  • Missed pulses. A signal shorter than the scan time can come and go between two reads and never be seen by the program.
  • The watchdog. If a scan takes longer than the configured limit, the CPU declares a fault and usually stops. A heavy calculation or an unexpectedly long loop can trigger this.
  • Control quality. PID loops assume a consistent sample time. A scan that varies from 5 ms to 40 ms makes the loop behave differently from one moment to the next.
Scan time is not a constant. It changes with the logic path taken, with communications load and with what the CPU is doing in the background. The number you see on a quiet bench is rarely the number you get on a busy plant.

How to measure it properly

Most platforms expose the last and the maximum scan time in their diagnostics. Watch the maximum, and watch it under the worst realistic conditions: many alarms active, communications busy, a recipe download in progress, every sequence running at once. Leaving a comfortable margin below the watchdog setting is far cheaper than finding out in production.

When the scan is too slow

Before reaching for a faster CPU, find out what is consuming the scan:

  • Move time-critical logic out of the main scan. Fixed-interval or interrupt-driven tasks — cyclic organisation blocks on Siemens, periodic tasks on Rockwell — run at a steady rate regardless of how long the main program takes.
  • Use the hardware. High-speed counters, fast inputs and outputs, and motion modules handle events far quicker than any scan can.
  • Spread heavy work across scans. Large array copies, string handling and big calculations can run in slices, driven by a simple state machine, instead of all at once.
  • Keep communications off the critical path. Do not make control logic wait for a slow device to answer.
Know your worst-case scan time before it introduces itself.