A shared serial or radio link can only carry one conversation at a time, yet a master may need current data from dozens of devices on it. Poll scheduling is how the master decides which device to talk to next and how often each gets its turn. The simplest and most common scheme is round-robin, where devices take turns in order, but real systems layer priorities and rates on top of it. This page explains how a master orders and paces its polls across many devices on one link.
Poll Scheduling (Round-Robin) in one line: Poll scheduling is the mechanism a SCADA master uses to sequence and pace its requests across all the devices sharing a single communication channel, since only one poll can be in flight at a time. In its basic form, round-robin, the master polls each device in turn and then starts the list over, giving every device an equal, repeating slot. More advanced schedules add priority tiers and per-device rates so critical or fast-changing devices are polled more often than slow ones within the same rotation.
On a multidrop serial line or a shared radio channel, the medium is half-duplex and single-conversation: the master sends one request, waits for that device to answer, and only then can it address the next. There is no way for two devices to reply at once without collision, so the master must impose an order. That order is the poll schedule - a list, and a set of rules for walking it, that turns a crowd of devices into an orderly sequence of one-at-a-time exchanges.
Round-robin is the default because it is fair and simple. The master keeps a poll list, sends a request to the first device, processes its reply, moves to the second, and so on to the end of the list, then loops back to the top. Every device is guaranteed a turn each pass, and the time between two polls of the same device - its effective update interval - is simply the time it takes to service the whole list once. This makes behavior predictable: add a device and the whole rotation gets slightly longer for everyone.
Pure equal round-robin, though, wastes effort. A wellhead pressure that must drive fast alarms and a battery-voltage reading that barely moves in a day do not deserve the same share of a scarce link. That mismatch is why practical schedulers depart from strict equality and let the engineer weight the rotation, so the link spends its limited time where fresh data actually matters.
The common refinement is to attach a rate or priority to each device or each group of points. A high-priority device might be polled on every pass, while a low-priority one is polled every third or tenth pass. The scheduler interleaves these so the fast devices appear repeatedly in the sequence and the slow ones appear occasionally, all within one shared rotation. The net effect is that critical data stays fresh without the slow data consuming turns it does not need.
Some masters also distinguish routine polls from on-demand or event-driven traffic. A control command an operator just issued, or an integrity poll after a device reconnects, can be allowed to jump the queue ahead of the routine rotation so it is not stuck waiting behind a full pass of ordinary reads. Well-behaved schedulers cap how much this preemption can starve the routine polls, so an operator action gets prompt service without a burst of commands freezing the background data flow.
Whatever the weighting, the fundamental budget never changes: the sum of all the round trips in a full rotation is the floor on how often the least-frequently-polled device gets updated. Priorities redistribute the link's time, they do not create more of it. When a schedule cannot deliver the required freshness even after prioritizing, the honest answer is fewer devices per link, a faster medium, or splitting the poll list across more channels - not a cleverer rotation.
In field operations, poll scheduling is what lets one cellular or radio channel serve a cluster of nearby wells or tanks economically. Rather than dedicating a link to each site, the master round-robins through them, and the engineer tunes the rotation so a site with active production or a live alarm condition is polled more often than a dormant one. The schedule becomes a lever for spending communication budget where the operation needs eyes right now.
A cloud SCADA platform like Merobix carries this idea forward by letting points be grouped by how quickly they need updating and mapping those groups onto the poll rotation, so fast values and slow totals share a link without competing on equal terms. Because the platform also reports per-device communication health, an engineer can see when the rotation has grown long enough that low-priority devices are falling behind their target rate, which is the signal to rebalance or split the channel.
Scheduling also interacts directly with growth. Each new site added to a shared rotation lengthens the pass for everyone already on it, so capacity planning treats the rotation time as a shared resource that thins as devices are added. Understanding the schedule is what lets an operator predict, before adding the twentieth well to a radio channel, whether the first nineteen will still get the update rate they were promised.
Round-robin polling is the scheme where a master addresses each device on a shared link in turn, from the top of its poll list to the bottom, then starts over. Every device gets an equal, repeating slot, and the time to service the whole list once sets how often each device is updated. It is the simplest fair way to share a link where only one conversation can happen at a time.
Poll rate is how often a device or point is supposed to be read, expressed as a target interval. Poll scheduling is the sequencing and pacing that actually delivers those rates across many devices sharing one link, deciding the order in which devices are polled and how priorities interleave. The schedule is the mechanism; the poll rate is the goal it tries to meet.
Priorities let some devices appear more often in the rotation than others, so a critical device is polled on every pass while a low-priority one is polled only occasionally. This redistributes the link's limited time toward fresh, important data without adding capacity. Priorities cannot make the total rotation faster; they only change who gets the available turns.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.