SERIAL TIMING

How to calculate a useful Modbus RTU timeout

An RTU timeout must be long enough for the request, device processing, response, and serial scheduling—but short enough to make missing devices visible. Copying one timeout between 115200 baud bench tests and a 9600 baud multidrop bus hides the real timing budget.

Modbus RTU request, turnaround, response, and inter-frame timing on a serial timeline
A useful timeout budget includes wire time in both directions, device turnaround, and a margin for the installation.
01

Calculate bits per character

One RTU byte includes a start bit, eight data bits, optional parity, and stop bit or bits. A common 8E1 frame therefore uses 11 bits per character. Character time is bits per character divided by baud rate.

02

Include the response you actually expect

An FC03 response grows with quantity: address, function, byte count, two bytes per register, and CRC. A maximum-sized read takes materially longer than a one-register probe. Include gateway forwarding time when RTU is reached through TCP.

03

Measure before increasing retries

Capture normal and slow response latency over the real adapter and topology. Set a timeout above the observed upper range with a defensible margin, then test a missing Unit ID. Retries multiply that budget; they should address occasional loss rather than compensate for a systematically short timeout.

The serial-line guide defines inter-character t1.5 and inter-frame t3.5 timing below or at 19,200 baud, and recommends fixed 750 μs and 1.75 ms timers above 19,200 baud.

04

Calculate request and response lengths explicitly

An ordinary RTU read request is eight bytes: server address, function, four bytes of start and quantity, and two CRC bytes. The response is five bytes of overhead plus two bytes per returned register. A ten-register FC03 response is therefore 25 bytes, not the same timing problem as a one-register response. Write the expected length into the estimate instead of using a single magic timeout for every operation.

Writes have different response shapes. FC06 echoes the address and value, while FC16 acknowledges the start and quantity rather than returning the written payload. Exception responses are shorter, but the timeout still has to allow the server enough time to decide and respond.

05

Add turnaround and scheduling after wire time

Wire time is only the lower bound. Add the silent interval required for RTU framing, server processing time, adapter and driver buffering, operating-system scheduling, and any gateway forwarding delay. Measure these components on the real route where possible. A USB adapter and virtual machine can introduce latency that is absent on a direct embedded UART.

Use a margin above the slow end of successful observations, not above the average. If normal responses cluster around 40 ms but occasional valid responses take 120 ms during internal device work, a 60 ms timeout will manufacture intermittent failures.

06

Validate both success and absence

Test the proposed timeout against the slowest legitimate operation and against a Unit ID that does not respond. The first test catches false timeouts; the second shows the actual failure-detection cost. Multiply that cost by retries, addresses, and Unit IDs before using the setting for discovery.

Keep polling interval separate from response timeout. The interval controls how often work is scheduled; the timeout controls how long one unanswered attempt owns the route. A polling interval shorter than the worst-case request lifecycle can create backlog or continuous bus occupancy.

QUESTIONS

Before you connect.

Is 1000 ms always safe?+

It may avoid false timeouts, but it can make discovery and failure handling unnecessarily slow. Base the value on the real frame length, baud rate, turnaround, and measured latency.

Do retries replace a correct timeout?+

No. A retry repeats an expired attempt and multiplies the worst-case wait. Fix the base timing first.

Should every source use the same timeout?+

Not necessarily. Routes and operations can have different response budgets, but keep differences documented so a slow setting does not hide degradation.

KEEP THE EVIDENCE

Use the reference beside the live protocol.

Browse documentation→