AG88 Engineeringnotes
← all notes

Scan time is a contract, not a statistic

2026-06-21 · PLC

Ask about scan time and you usually get an average: "about 8 milliseconds". The average is close to meaningless. What the process cares about is the longest scan that can happen while it is doing the thing you are trying to control, and averages hide exactly that.

Where the long scans come from

Measuring the worst case honestly

Most controllers expose maximum scan time in a system status word, but many clear it on mode change or power cycle, so the value you read is often "the worst since the last time someone restarted it". Latch it yourself into a retentive tag, timestamp it, and reset it deliberately. Then create the conditions that produce long scans — go online, start a batch, force a fault — and watch the number rather than hoping.

What I put in every program
  MaxScan      retentive, updated when current > stored
  MaxScanTime  timestamp of that maximum
  MaxScanCause word set by whichever conditional block was executing

The third one takes ten minutes to add and turns "we saw 40 ms once" into "the purge sequence costs 30 ms", which is a sentence you can act on.

The number that matters downstream

For a discrete input to be caught reliably, the signal must persist longer than one scan plus input filter time — and by "one scan" I mean the worst case, not the average. When someone asks whether a 25 ms pulse from a proximity switch will be seen, the answer depends on that maximum, and answering with the average is how you get an intermittent fault that nobody can reproduce.