Shopfloor

Modbus polling and timeout budget: calculate the slow path

Estimate serial transaction time, include silent intervals and device response, and prevent offline devices from consuming the entire polling cycle.

A polling schedule must fit healthy traffic and a bounded amount of failure handling. The fastest successful read is a weak basis for promising an update interval: an offline device can hold a serial bus until its timeout and retries expire.

FIG. 02From machine to data
Connect. Transport. Record. A gateway, a switch and a recorder: separate jobs along a connected machine’s data path. The equipment arrangement is illustrative.

Start with byte transmission time

For an illustrative Modbus RTU exchange at 9,600 bit/s using 11 bits per character, an eight-byte request and 25-byte response occupy 33 × 11 / 9,600 = 0.0378125 seconds of wire time. That is about 37.8 ms, before silent intervals, device processing and gateway overhead.

The character count depends on the configured format. Do not use an eight-data-bit count as if start, parity and stop bits consume no time. The response length also depends on the function and quantity read, so calculate it for the actual register block.

Add a realistic response boundary

Measure successful response times under representative load. Account for inter-frame timing required by the protocol and for any configured turnaround delay. Avoid combining several independently minimal observations into a cycle that no real device can sustain.

Group contiguous registers only when the register map and device limits allow it. A larger read can reduce transaction overhead but may include unsupported gaps or trigger exception responses. The CRC and frame helper checks frame arithmetic; it does not establish a device's supported map.

Budget the unavailable-device path

Suppose a configured transaction timeout is 300 ms and the policy makes one retry after the first attempt. An unresponsive device can consume roughly 600 ms before any extra backoff, request-transmission time or gateway overhead, depending on where the timer starts. Multiply that behavior by the number of unreachable devices, not by the normal response time.

Use bounded retries and an offline-device backoff policy appropriate to the process. Keep last successful timestamp and communication quality visible to consumers. A gateway that republishes an old register value every second has not produced a fresh process measurement.

Test both timing and meaning

CaseEvidence to collect
All devices healthyCycle duration and response distribution
One device unavailableTimeout, retries and healthy-device delay
Several devices unavailableMaximum cycle and backoff behavior
Exception responseClassification and retry decision
ReconnectRecovery time and stale-value handling

Verify register datatypes and word order separately with the Modbus register decoder. Timing cannot fix a value decoded in the wrong format. Record the polling contract in the industrial data worksheet and continue through the connectivity path.

Primary reference

Modbus Organization: specifications provides the serial-line guide and application protocol resources. Consult the applicable guide and device manual for framing, timing and supported limits. The byte and timeout examples above are illustrative budgets, not universal update guarantees.

Cite this page: Modbus polling and timeout budget: calculate the slow path, Shopfloor, 2026-10-11. https://shopfloor.space/articles/modbus-polling-timeout-budget/

Related