A scan rate, or poll rate, is how often the SCADA system asks a device for a tag's current value, and it is one of those quiet settings that people leave at the default until it causes a problem. Set every tag to scan as fast as possible and you flood the device and, on a cellular or radio link, the data plan, with traffic that buys you nothing for values that barely change. Set everything slow and the process feels sluggish and important events are noticed late. The craft of setting scan rates is matching each value's poll rate to how fast it actually needs to be seen, which almost always means sorting tags into a few groups rather than tuning them one by one. This guide covers how to choose and apply scan rates: grouping tags into scan classes, balancing responsiveness against the load you put on the PLC and the bandwidth you spend, and using report-by-exception and deadband to cut traffic without losing the events that matter.
How to set scan rates in SCADA in one line: To set scan rates in SCADA, sort your tags by how quickly each one actually needs to be updated and assign them to a few scan classes rather than tuning every tag individually, a fast class for values an operator is actively controlling and slow classes for values that change gradually or are only logged. Match each class's poll rate to real need, because faster scanning loads the PLC harder and, on cellular or radio links, spends more data and money. Where the protocol supports it, use report-by-exception with a deadband so a value is only sent when it changes by a meaningful amount, which cuts traffic dramatically for slowly moving points.
Setting a scan rate on every tag individually is both tedious and unnecessary, because most tags fall naturally into a few speed categories. The standard approach is the scan class, sometimes called a scan group or poll group, which is a named poll rate that many tags share. You define a handful of classes, and then assign each tag to the class that suits it, so instead of setting a thousand individual rates you set a few classes and drop tags into them. This also makes the system far easier to understand and adjust later, since changing the fast class's rate updates every tag in it at once rather than requiring a thousand edits.
The right way to divide tags into classes is by how quickly the value genuinely needs to be seen, which usually comes down to what a person does with it. A value an operator is actively watching and controlling, a pressure they are adjusting, a flow they are trimming, needs a fast scan so the screen responds and they can close the loop in real time. A value that changes slowly and is mostly there for context, a tank level that moves over hours, an ambient temperature, is perfectly well served by a much slower scan. A value that is only logged for reports or rarely looked at can scan slowest of all. Sorting tags this way, by the speed the human or the control genuinely requires, is the whole basis of good scan-class design.
It helps to resist the temptation to make everything fast just in case. A common instinct is that faster is always better, so people push every tag to the quickest rate available, but this is exactly the mistake that causes overloaded devices and blown data plans. Fast scanning is only valuable for values where the speed is actually used, and for the large majority of points that a person glances at occasionally or that change gradually, a slow scan is not a compromise but the correct choice. A well-tuned system typically has a small number of tags in the fast class and the bulk of tags in slower classes, which is the shape that keeps both the device and the network comfortable.
Every scan is a request the device has to answer, so faster scanning puts more load on the PLC or RTU, and there is a real limit to how much a device can serve. A controller busy answering a flood of poll requests has less time for its actual control job, and a device or its communication port can simply be saturated, at which point scans start taking longer than their interval and the whole system falls behind. This is why fast scanning is a resource to spend deliberately rather than a free upgrade. The device's capacity is finite, and scan rates are how you allocate it, so you spend the fast scans on the values that need them and let everything else run slow so the device stays responsive where it counts.
On wired plant networks bandwidth is usually cheap enough that the device load is the main constraint, but the calculation changes completely on cellular, radio, or satellite links, where data itself costs money and is often metered. On those links, every scan of every tag is bytes over the air on a plan you pay for, and scanning a large tag list quickly can run up a surprising monthly bill or exhaust a data allowance for values that never needed watching that closely. This is a real operational cost that scan rates directly control, and it is one of the strongest reasons to scan slowly wherever fast updates are not genuinely needed. A tag that scans every second over cellular sends sixty times the data of the same tag scanned every minute, for information that in most cases is no more useful.
The practical balance, then, is to give a small set of critical, actively controlled values a fast scan and keep the great majority of tags on slower classes, especially on any metered link. This is not about starving the system of data; it is about spending both the device's capacity and the data plan where they produce value. The right test for any tag is simple: would anyone actually use a faster update, would an operator act sooner or would a control loop close tighter. If not, the faster scan is pure cost, more load on the device and more bytes on the bill, in exchange for information nobody uses. Getting this balance right is the difference between a system that stays snappy and affordable and one that is either sluggish or expensive.
The most powerful tool for cutting traffic without slowing anything down is report-by-exception, where instead of the value being polled and sent on every scan, it is only sent when it actually changes. Paired with a deadband, a threshold of how much the value must move before it counts as a change, this becomes report-by-exception with a deadband: a pressure that is holding steady sends nothing, and only when it moves by more than the deadband does a new value go out. For values that sit still most of the time, which is a lot of process values, this collapses the traffic from a steady stream of identical readings to an occasional update only when something happens, while still catching every real change.
The deadband is the setting that makes this work, and choosing it is a balance between traffic and resolution. Too small a deadband and ordinary noise on the signal counts as a change, so the value chatters and you lose most of the savings. Too large a deadband and you miss real, meaningful movements because they did not cross the threshold, so the reported value lags reality. A well-chosen deadband is just larger than the signal's noise and just small enough to catch the changes that matter, so it filters the jitter while faithfully reporting genuine movement. Tuning the deadband per value, or per class of similar values, is where report-by-exception goes from a blunt instrument to a precise one.
This combination is exactly what makes cloud monitoring of remote sites over cellular links practical rather than ruinously expensive. In a cloud SCADA platform such as Merobix, a remote RTU can be configured to report values by exception with a deadband, so a well or tank that is running steadily sends only occasional updates and consumes almost no data, yet a real change, a pressure climbing, a level dropping, is reported promptly and reaches the operator right away. This lets a single data plan cover a fleet of remote sites that would be unaffordable if every tag were polled on a fast fixed interval. The scan-rate and deadband decisions in this guide are, in the end, what determine whether monitoring a spread-out field operation costs a fortune in data or almost nothing, so they are worth setting with real care rather than leaving at defaults.
A scan class, also called a scan group or poll group, is a named poll rate that many tags share, so instead of setting an individual scan rate on every tag you define a few classes and assign each tag to the one that suits it. This makes the system far easier to manage, since changing a class's rate updates every tag in it at once. The classes usually reflect how fast each value genuinely needs to be seen, with a fast class for actively controlled values and slower classes for values that change gradually.
Yes, in two ways. Every scan is a request the device must answer, so fast scanning loads the PLC or RTU harder and can saturate it, leaving less capacity for control and slowing the whole system. On cellular, radio, or satellite links it also costs data, since every scan is bytes over a metered plan, and a tag polled every second sends sixty times the data of the same tag polled every minute. So fast scanning is a resource to spend deliberately on values that actually need it, not a free upgrade.
With report-by-exception, a value is only sent when it changes rather than on every scan, and the deadband sets how much it must move to count as a change. A pressure holding steady sends nothing and consumes almost no data, while a real movement larger than the deadband is reported promptly. This collapses the traffic for values that sit still most of the time, which is a lot of process data, and it is what makes monitoring a fleet of remote cellular sites affordable instead of ruinous.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.