Polling is the classic way a SCADA system gets data: it asks each device 'what is your value now?' on a repeating timer. The poll rate is how often it asks. Get the poll rate right and your data is fresh without overloading the network; get it wrong and you either miss events or saturate your links. This guide explains polling, how to choose a poll rate, and how it compares to report by exception.
What Is Poll Rate? in one line: Poll rate is how frequently a SCADA system requests fresh data from a device - for example, once per second or once per minute. Polling is the request/response method itself: the SCADA host cyclically queries each device and each device replies with its current values.
In a polled architecture the SCADA host is the master and each field device is a slave. On a fixed cycle the host sends a request - read these registers, this many devices - and each device replies with the requested values. The host works through its poll list, then starts again. The total time to cycle through every device is the scan time, and the interval at which any given point is refreshed is its poll rate.
Protocols like Modbus are inherently poll-based: nothing happens on the link until the master asks. This makes polling simple and deterministic - you know exactly when each value will be refreshed - but it also means the host must reach every device directly, and bandwidth is consumed on every cycle whether or not the data changed. On a serial multidrop line, devices are polled one at a time, so more devices means a longer scan and slower refresh for each.
The right poll rate follows the physics of the process, not habit. Fast-moving, control-relevant values - a compressor discharge pressure, a fast flow loop - may warrant sub-second or one-second polling. Slow variables - a tank that fills over hours, an ambient temperature - are fine at one-minute or five-minute rates. Polling everything at one second because you can is a common mistake that saturates links and inflates cellular bills for no operational benefit.
Poll rate also interacts with the number of devices and the link speed. On a slow radio or a busy serial line, too many fast-polled points stretch the scan until 'one-second' data is really arriving every several seconds. The discipline is to poll each point only as fast as its process changes and your links can sustain, and to group registers efficiently so each request reads as much useful data as possible.
Polling and report by exception are the two answers to 'how does data get from the field to SCADA.' Polling is host-driven and periodic - predictable and simple, but constant in bandwidth. Report by exception is device-driven and event-based - efficient on quiet processes but unevenly timed. Many real deployments mix both: poll a local PLC over Modbus on a fast LAN, while remote RTUs report by exception over cellular.
A capable SCADA platform lets you set poll rates per device or per point rather than one global rate, so you spend bandwidth where the process actually moves. Merobix polls Modbus, OPC UA, EtherNet/IP, and Siemens S7 devices at configurable rates while also ingesting report-by-exception data from DNP3 and MQTT sources, so each source runs at the cadence that fits it.
It depends entirely on the process. Fast, control-relevant values may need one-second or sub-second polling; slow variables like tank levels are fine at one to five minutes. Match the poll rate to how quickly each value actually changes and to what your links can sustain, rather than polling everything at one rate.
They are closely related. Poll rate is how often a specific device or point is queried. Scan rate or scan time usually refers to how long it takes the host to cycle through its entire poll list once. On a busy link, a long scan time can stretch out the effective poll rate of every point.
Neither is universally better. Polling is simple and predictable and suits local devices on fast links (like Modbus over a LAN). Report by exception is far more bandwidth-efficient for remote sites on cellular or satellite. Many systems use both - polling near devices and exception reporting from the far edge.
This page references the standards, specifications, and official documentation published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.