PLC scan cycle and data sampling error

What the scan cycle does

A conventional PLC reads inputs, executes program logic, writes outputs and repeats. A tag inside the program can hold the same value until the next scan. When a monitoring system reads those values, the physical event time and the recorded time can differ.

Tie sampling rate to process speed

To capture a fast change, the read interval must be clearly shorter than that change. If it is too long, a fast vibration or pressure pulse disappears or shows up as a misleading slow oscillation. This is aliasing. Establish the process speed limit first, then choose the monitoring rate.

Timestamp at the source

Where possible, generate the timestamp in the PLC or at the collector nearest the source. The arrival time of a packet is not the time of the event. Store source time, receive time and latency as separate fields. Without clock synchronization, do not interpret two machines’ records as an ordered sequence of events.

Prepare model data against these limits

When engineering features, record the window length, the sampling interval and the behaviour on missing reads. Training on 100 ms data and running on 1 s data turns the same model into a different problem. These steps are a suggested workflow; the real scan time of a specific PLC family must be verified in its product documentation.

Frequently asked