When a SCADA master sends a poll, it cannot wait forever for a reply - some replies never come. Two settings decide how it copes: the timeout that says how long to wait before declaring a poll failed, and the retry count that says how many failed attempts to tolerate before giving up on the device. Tune them too tight and healthy devices get flagged offline; too loose and a dead device drags the whole channel. This page explains how a master decides a poll failed and how that decision ripples into data quality.
Comm Retries and Timeouts in one line: A communication timeout is the maximum time a master waits for a device's response before treating that poll as failed. The retry count is how many additional attempts the master makes on a failed poll before it marks the device as offline or communication-failed. Together they define the master's patience: they set how quickly a genuinely broken device is detected and how tolerant the system is of occasional dropped messages, and they directly affect both channel throughput and the quality flags on the affected tags.
A poll fails in one of two ways. Either no response arrives within the timeout window, or a response arrives but is malformed - a bad checksum, a wrong length, an unexpected address. The timeout handles the silent case: the master starts a clock when it sends the request, and if the clock expires before a valid reply lands, that attempt is counted as failed. Setting the timeout well means allowing for the real round-trip time of the link, including the device's processing delay, plus a margin, so a slow-but-healthy device is not wrongly judged dead.
A timeout set too short is a classic self-inflicted problem. On a cellular or satellite link where round trips are genuinely long, an aggressive timeout will expire before the perfectly good reply arrives, and the master will register failures on a device that is answering normally, just slowly. Set too long, the opposite happens: the master wastes the whole timeout on every poll to a device that is actually gone, stretching the channel's cycle and slowing everyone else. The right value is anchored to the measured behavior of the specific link, not a generic default.
Once a single attempt fails, retries decide whether that failure matters. Occasional dropped messages are normal on wireless links, so masters retry a failed poll a configured number of times before concluding anything. If any retry succeeds, the value comes through and the device is considered healthy; the momentary glitch is invisible except in the comm statistics. Only when the attempt plus all its retries fail does the master escalate to declaring the device offline.
The retry count is the threshold between a hiccup and a fault. A low count makes the system twitchy - a couple of dropped packets flips a device to offline and back, which produces noisy comm alarms and repeatedly bad-flags the tags. A high count makes the system patient - it rides through transient losses smoothly, but it also delays the moment a truly failed device is recognized, because the master keeps re-attempting before it gives up. Choosing the count is a balance between fast fault detection and stability against normal wireless noise.
When the threshold is finally crossed and the device is marked offline, the consequence is not just an alarm; it is a change in data quality. The tags fed by that device stop receiving fresh values, and a well-behaved system flags them as bad or stale rather than leaving the last-known value on screen looking live. That quality flag is important: it tells operators, alarms, and any downstream calculations that these numbers are frozen and must not be trusted or acted on as if current. A value that is merely old but unflagged is far more dangerous than one that is honestly marked bad.
Retry behavior also interacts with channel throughput. Every retry consumes a slot on a shared link, so a device that is failing but not yet declared offline can eat several full timeouts worth of channel time on each pass, slowing the polls to every other device. This is why some masters apply a backoff - after a device is declared offline, they poll it far less frequently, checking only occasionally whether it has come back, so a dead station stops stealing time from the living ones until it recovers.
On remote oil and gas sites, retry and timeout tuning is where link reality meets operational tolerance. A cellular site with variable latency needs a timeout generous enough to survive a slow round trip and a retry count high enough to ride through the occasional dropped packet, so operators are not paged for comm faults that clear themselves. A hardwired, reliable local link can afford a tighter timeout and fewer retries, detecting a genuine failure quickly because false failures are rare.
A cloud SCADA platform such as Merobix makes these settings meaningful by pairing them with honest quality handling: when a device crosses its retry threshold, its tags are flagged and its trend shows a gap rather than a flat line masquerading as live data. That distinction lets an operator instantly tell the difference between a stable reading and a lost device, and it keeps alarms and calculations from firing on stale numbers. The retry and timeout values decide when that transition happens; the quality model decides what everyone downstream sees when it does.
The practical goal is to make offline detection both trustworthy and quiet. Well-tuned settings mean a real outage is recognized within a sensible, predictable window and clearly flagged, while normal wireless noise never generates a nuisance comm alarm. Getting there is iterative - watch how a link actually behaves, count its genuine losses, and set the timeout and retries so the master's patience matches the medium rather than a one-size default.
A poll fails either when no valid response arrives before the timeout expires, or when a response arrives corrupted - a bad checksum, wrong length, or unexpected address. The master starts a clock when it sends the request and counts the poll as failed if a good reply does not land in time. It then decides whether to retry or, after enough failures, to mark the device offline.
Once a poll and all its allowed retries fail, the master declares the device offline or communication-failed. Its tags stop updating and should be flagged as bad or stale rather than shown as live values, so operators and downstream calculations know the data is frozen. Many masters then poll the failed device less often until it recovers, so it stops consuming channel time.
Base it on the link's actual round-trip time, including the device's processing delay, plus a margin, since cellular latency is variable and often long. A timeout that is too short will expire before a healthy but slow reply arrives and cause false failures, while one too long wastes channel time on genuinely dead devices. Watch how the link really behaves and set the value to fit that, not a generic default.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.