Control
PLC scan cycle and data sampling error
Before reading a PLC tag for AI, know where in the scan cycle the value was produced and which timestamp describes it.
What is a PLC scan time, and how is it measured?
Short answer
PLC scan time is the time one cycle takes to read inputs, run the program and write outputs, measured in milliseconds. It determines the controller's response time, its deterministic behaviour and what a data collector can see. The value is usually read from the CPU diagnostics screen.
How the scan cycle works
Most PLCs run in a continuous loop. In each cycle, the input image is read first, then the user program runs from start to end, and finally the output image is written. Communication, diagnostics and internal tasks also take part of each cycle. The total time of one cycle is the scan time.
Scan time depends on program length, branches, communication load and the number of I/O points. It is better thought of as a distribution than as a single fixed number. Fast tasks can run outside the main scan as periodic or interrupt tasks. A watchdog timer catches a cycle that runs much longer than expected.
Example: scan time and response delay
Suppose a PLC has a scan time of 25 ms (hypothetical). A sensor changes just after the input image has been read. In that cycle, the program sees the old value. In the next cycle, the new input is read, the program runs and the output is written. In the worst case, the output therefore changes about 2 × 25 = 50 ms later. The input module's delay and the response time of the valve or relay add to that.
As a rule of thumb, expect a response somewhere between one and two scan times. For the exact figure, check the documentation for your PLC and task configuration.
Measuring and common mistakes
On most PLCs, scan time is visible in the programming software or on the CPU diagnostics screen. Track the minimum, maximum and average values, since the average hides sudden spikes. The most common mistake is treating scan time as response time; response time also includes input delay and I/O. A second mistake is setting a data collector's or SCADA's polling period equal to the scan time. A third is trying to catch pulses shorter than a scan in program logic. For such events, a hardware input or an interrupt should be considered.
Follow-up questions
Why does scan time vary?
Program branches, executed or skipped blocks, communication traffic and diagnostic work can each take a different time in each cycle. For that reason the maximum value may matter more than the average. To find problem moments, match the scan time log against an event log.
How can scan time be reduced?
Removing unnecessary blocks, reducing frequent communication, avoiding reads of large data blocks that are not needed, and splitting long routines can all help. But every change can affect timing and safety functions. Test before commissioning, and measure the scan time again under the new conditions.
Sources
Example numbers are hypothetical, not measured field results.