Why Polling a SCADA Tag Faster Won't Catch That One-Scan Pulse
A one-scan reject pulse lives for 20 ms. Poll every 250 ms and SCADA never sees it. Matching polling rates to PLC scan time, driver and historian.
The complaint usually arrives like this: "the HMI missed a machine fault, so make the tag faster." Someone drops the poll rate from 500 ms to 250 ms, the number on the screen twitches a little quicker, and everyone feels better until the fault is missed again. It gets missed because the fault was a one-scan pulse — true for maybe 20 ms — and a 250 ms poll is still 12× too slow to land on it. You can't out-poll a pulse the PLC never held.
Faster is the wrong knob. The right question is which of three clocks you're actually fighting:
- The PLC scan or task period that produces the value.
- The driver poll period that reads it into SCADA.
- The HMI / alarm / historian period that consumes it.
A tag can look rock-steady only because all three happen to sample at the same unlucky moment. Until you know all three, you're tuning blind.
The pulse problem is a PLC problem, not a poll-rate problem
If a bit is true for one scan — a reject kick, a bad-part flag, a momentary interlock — no SCADA poll rate saves you. A 10 ms scan means the bit exists for 10 ms; a poll every 250 ms samples it roughly once every 25 scans. SCADA isn't watching the pulse, it's occasionally glancing at the spot where the pulse happened.
The fix is in the PLC, and it's one of four moves:
- Latch it until SCADA reads and clears it (a handshake bit). Safest for anything you can't afford to miss.
- Count it with a totalizer, so you read an accumulated value instead of chasing edges.
- Stretch it — a TON/TOF one-shot that holds the flag for, say, 500 ms so a normal poll catches it.
- Timestamp it in the PLC and pass a sequence-of-events record up, so the event time survives even if the poll is late.
Before you touch any SCADA rate, find out where the value is born: continuous task, a periodic task (and at what period), or a comms task? Is it copied into a separate communication buffer on its own interval? Are there produced/consumed tags, a gateway, or a protocol conversion in the path? On a redundant hot-standby pair, measure worst-case scan time with the pair synchronized — the crossload inflates it, and that's the number your poll competes with.
One global rate is a smell
Setting the whole project to a single poll rate is the tell of a project nobody grouped. A pump-running bit on an overview screen and a one-scan reject pulse are not the same animal, and they don't want the same treatment. Rough starting points I use, then tune from measurement:
| Tag type | Starting rate | The catch |
|---|---|---|
| Operator status / feedback | 500 ms – 2 s | Fast enough to feel live; never fast enough to prove a sequence |
| Analog process values | 1 s – 5 s | Match the loop dynamics, not the screen frame rate |
| Alarms | Event-driven if the protocol allows | Confirm delay/latch logic before trusting the rate |
| Totals / counters | 1 s – 10 s, or event-based | Trust a totalizer, never a short pulse |
| Maintenance diagnostics | 5 s – 60 s | Don't burn bandwidth on data nobody opens |
| Historian-only | Whatever the analysis needs | Decouple entirely from HMI refresh |
The configured rate is a request, not a promise
The poll interval you type is what SCADA asks for. What you get depends on driver scheduling, packet size, route latency, retries, and how many tags share the group. A Modbus TCP device with 40 tags scattered across non-contiguous registers can be slow on a gigabit switch, because each gap forces a separate read transaction — packing them into contiguous blocks usually helps more than shrinking the interval ever will.
So during commissioning, don't trust the config screen — read the driver's own numbers:
- Actual group scan time, under normal load and with every real HMI client connected, not just your engineering laptop.
- Missed polls, timeout counts, reconnect counts.
- PLC comms CPU load, if the platform exposes it (many do).
- The whole path: remote I/O, serial gateways, radio links, VPN hops all live in the timing budget.
I've watched a gateway go unstable the day someone moved every tag into the "fast" group. The tags didn't get faster; the gateway got slower for everyone.
Screen refresh and data acquisition are different jobs
Operators want the screen to feel current. That doesn't mean every value gets read from the PLC at display frame rate — the HMI can render from the last known value while acquisition runs on its own schedule. So split it:
- Fast group — command feedback, permissives, the sequence state you're actively driving.
- Normal group — overview indicators, routine analogs.
- Slow group — maintenance counters, nameplate data, config echoes.
- On-demand / screen-active — detailed diagnostic pages that only poll while open.
One trap with screen-active polling: if an alarm or interlock depends on a tag, it must not drop out of acquisition just because someone closed the diagnostic screen. Alarms don't get to stop being monitored when nobody's looking.
The historian gets its own decision — stop conflating it with polling
Historian collection and SCADA polling get treated as one setting constantly, and they aren't. The historian can only store what it receives, but storing every polled sample is rarely what you want. Decide separately: how often the connector reads the source, and how it stores — exception, deadband, swinging-door compression, or fixed interval.
For energy, flow, and production totals, a reliable accumulated value beats a fast sampled rate every time — you want the counter, not a stream of instantaneous readings you'll have to integrate later and argue about. For state timelines, record clean transitions with timestamps rather than praying a periodic sample lands on every change. And if reports do boundary math at shift or day rollovers, decide up front whether they interpolate — that mismatch is why historian totals and MES totals disagree.
When it goes wrong, it looks like something else
Polling problems almost never announce themselves as polling problems:
- HMI misses a brief fault → the PLC didn't latch it.
- A trend draws square steps → the value updates slower than the chart period.
- Commands feel laggy → feedback sits in a slow group.
- Alarm timestamps don't match the PLC's SOE record → SCADA stamped the poll, not the event.
- Historian and MES totals disagree → reset timing and sample timing got mixed.
The only way through is real timestamps from each layer, side by side: PLC event time, driver update time, alarm time, historian time, report time. When those line up you've found nothing; when one drifts, that's your layer.
If your design can't answer, for any given signal, "is this sampled, event-based, or latched by the PLC?" — that's the gap to close first. Answer it per tag and the next performance complaint stops being an excuse to make everything faster.