A SCADA channel and a PLC both run on a repeating clock: a scan or poll cycle is supposed to finish and start over on a fixed schedule. A scan overrun is what happens when the work does not fit inside the time allotted - the current cycle is still running when the next one was due to begin. It is not a crash and often not even an alarm at first; it is a quiet slide into stale data and missed updates. This page explains what a scan overrun is, why an overloaded channel causes it, and how to diagnose one.
Scan Overrun in one line: A scan overrun occurs when a poll loop or PLC scan cannot complete before its next scheduled cycle is due to start, so cycles begin to run late or get skipped. On a SCADA channel it usually means too many devices, too many points, or slow responses have made the round of polls longer than the configured scan interval. The result is that data updates arrive later than the requested rate, and in the worst case some polls are dropped entirely.
Both a SCADA poll loop and a PLC program are designed around a target period. A channel set to poll every second is meant to send its whole round of requests, collect the replies, and be idle before the next second begins. A scan overrun is the condition where that round takes longer than the period - the loop is still finishing the previous pass when the clock says it is time to start again. The system then either delays the next cycle until the current one ends or, depending on configuration, skips a scheduled cycle to catch up.
On a SCADA channel the usual cause is arithmetic. Each device on a shared link takes some time to poll - the request goes out, the device turns the reply around, and the response comes back - and those times add up. Put enough devices, or enough points, or slow-responding devices on one link, and the sum of all the round trips exceeds the scan interval you asked for. A single sluggish or partially failing device that eats its full timeout on every poll can push an otherwise healthy channel into overrun by itself.
In a PLC the mechanism is the same but the cause is internal: a program that grew too large, a communication instruction that blocks, or a loop that iterates too many times can stretch the program scan past its watchdog limit. The distinction matters because a PLC watchdog typically faults the processor to a safe state when the scan overruns, whereas a SCADA channel usually just degrades silently, delivering older data at an effective rate slower than the one on the screen.
The clearest symptom of SCADA scan overrun is a gap between the requested poll rate and the actual update rate. The channel is configured for one-second updates, but the timestamps on incoming values show they are really refreshing every three or four seconds. Many SCADA packages expose this directly as a measured scan time or cycle time per channel; when that measured value creeps up to or beyond the configured interval, the channel is at or over capacity. Rising communication statistics - longer average response times, growing queue depth, retries - point the same way.
The most productive first move is to find the device that is costing the most time. A single station that is timing out or retrying on every poll can dominate a channel's total cycle, so isolating or temporarily disabling a suspect device and watching the cycle time drop tells you where the load is. If no single device is at fault, the channel is simply carrying more devices or points than its round-trip budget allows, and the total number, not any one member, is the problem.
It helps to separate overrun caused by volume from overrun caused by faults. Volume overrun is steady and predictable: the cycle time is consistently a little over budget because the poll list is too long for the link speed. Fault-driven overrun is spiky: the cycle time is fine until one device starts failing and its repeated timeouts blow the budget. The two need different fixes, so watching whether the overrun is constant or correlated with a specific device's comm errors is the key diagnostic split.
In cloud SCADA for oil and gas, scan overrun tends to show up on the slowest links - cellular and radio sites where each round trip is expensive and a long poll list quickly saturates the available time. Rather than pushing every point through one fast channel, well-designed deployments split points by how quickly they actually need to update: a fast group for values that drive alarms and control decisions, and a slower group for daily totals and diagnostics. Spreading the load across those groups keeps any single cycle inside its budget.
A platform such as Merobix surfaces the effective update rate and communication health per device, which is what makes overrun visible before it becomes a data-quality complaint. Instead of discovering after the fact that a trend has been quietly stale, an operator can see that a channel's cycle time is climbing and act - moving low-priority points to a slower schedule, splitting a crowded link into two channels, or replacing a device that has started timing out. The goal is to keep the promise the poll rate makes: if the screen says one-second data, the data really is one second old.
Overrun also shapes how many sites a single link can carry as an operation grows. Adding one more well to an already busy shared radio channel can be the addition that tips it from comfortable into chronic overrun, so capacity planning treats the round-trip time budget as a hard constraint, not an afterthought. Watching cycle-time headroom as sites are added is how remote operations avoid the trap of a channel that worked fine at ten devices and silently degrades at fifteen.
It happens when the total time to poll every device and point on a channel exceeds the configured scan interval. Too many devices on one link, too many points, slow-responding stations, or a single device that times out on every poll can each push the cycle past its budget. The result is that updates arrive slower than the requested rate, and some polls may be skipped.
Slow scan time just means each cycle takes a while but still finishes before the next is due, so updates arrive on schedule at a modest rate. A scan overrun means the cycle cannot finish in time at all, so cycles start running late or get dropped and the effective update rate falls below the one you configured. Overrun is the point where the channel has run out of headroom.
Start by finding the most expensive device, since a single station timing out on every poll can dominate the cycle; isolate or replace it if that is the cause. If the load is spread evenly, reduce it by moving low-priority points to a slower poll group, splitting the channel into two, or upgrading a slow link. The aim is to bring the measured cycle time back under the configured scan interval with some margin to spare.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.