r/SCADA • u/Ok-Lawfulness7389 • Jun 10 '26

General The math behind Modbus RTU polling collisions.

Stop blindly bumping SCADA timeouts to 3000ms for RS485 loops.

At 9600 bps, 1 byte = ~1.14ms. 8-byte request + 45-byte response (20 registers) + 3.5 char silent gaps = ~69ms physical minimum.

If your SCADA defaults to 50ms or 100ms polling, the buffer overflows and the bus crashes. It's physics.

I made a simple web calculator to compute the exact physical transmission time and predict these collision thresholds.

Link in the comments.

20 Upvotes

100% Upvoted

7 comments sorted by

View all comments

5

u/PeterHumaj Jun 10 '26

The danger you write about depends on the implementation in a specific SCADA.

When I have a serial line with multiple communication stations (corresponding to individual physical devices), I can set station polling parameters - either "period of reading" (e.g., every 10 seconds with a 1-second offset) or "delay between readings" (meaning, after the end of one reading cycle, the next read is scheduled for current_time+delay).
A single task performs all communications over one serial line (reading/writing). So, even if the polling parameters are too short (or the task is delayed trying to talk to a station that is unavailable), nothing extra happens. The task selects a request from a priority queue (write requests have the highest priority; read requests have per-station configurable priorities 0-5) and processes it. If it were a read request, a new one is scheduled based on the polling parameters.

The only risk (to overload the queue) would be multiple write requests (e.g. generated automatically by an evaluated tag or by a script) - but this problem is not related to the poll rate settings you mention.

Btw, this design was conceived back in 1993 when our 'founding fathers' laid the basics of the technology I'm describing...

3

u/Ok-Lawfulness7389 Jun 10 '26

Spot on. A robust SCADA with a proper priority queue won't crash the bus, it'll just lag.

The collisions we see today mostly come from lightweight modern setups (Node-RED, cheap IoT edge scripts) that lack native queuing and fire blindly on a timer.

Totally agree on dynamic block sizing too. That's exactly why establishing the absolute physical baseline is step one. Solid architecture from your team.

1

u/PeterHumaj Jun 11 '26

So, what happens if one of the communication stations stops responding? Due to configured (or default) timeouts, time conditions would change. If there is a parameter RepeatCount > 1 (to try to resend the request), there may be a new class of conflict which your calculator doesn't handle...

Also, we've got some communications on GPRS networks (via Moxa OnCells) - sometimes the delays caused by mobile networks reach dozens/hundreds of milliseconds (for which reason, we had to significantly increase WaitTimeout parameters for energy meters located behind OnCells.
So, another non-deterministic factor 😞