A Modbus RTU master (PLC, HMI or PC program) usually has settings for «response timeout», «retries», «delay between requests» and «polling interval». Too short a timeout makes a healthy device look dead; too long, and one powered-off device slows updates for the whole bus. This guide shows how to compute the minimum from baud rate and frame length.
1. Character time — how long is one byte
A serial line sends each byte framed by a start bit, data bits, parity and stop bits. The Modbus RTU character is 8 data bits with even parity and 1 stop bit (the default), or 2 stop bits when no parity is used. Either way it is 11 bits, so character time = 11 ÷ baud rate.
| Baud | Char time | t1.5 | t3.5 | Max bytes/s |
|---|---|---|---|---|
| 9600 | 1.146 ms | 1.719 ms | 4.010 ms | 872 |
| 19200 | 0.573 ms | 0.859 ms | 2.005 ms | 1745 |
| 38400 | 0.286 ms | 0.75 ms (fixed) | 1.75 ms (fixed) | 3490 |
| 115200 | 0.095 ms | 0.75 ms (fixed) | 1.75 ms (fixed) | 10472 |
RTU frames carry no length field, so receivers split them by silence. The specification discards a frame when a gap between bytes exceeds 1.5 characters (t1.5) and ends a frame after 3.5 characters (t3.5) of silence. Above 19200 bps these times get so short that the specification recommends fixed values: t1.5 = 750 µs, t3.5 = 1.75 ms.
2. Frame length — how many bytes go each way
An RTU frame is address 1 + function 1 + data + CRC 2 bytes. Read requests are always 8 bytes; the response grows with the quantity read.
| Function | Request | Normal response | Quantity limit |
|---|---|---|---|
| 03/04 read registers | 8 | 5 + 2N | 125 |
| 01/02 read coils/inputs | 8 | 5 + ⌈N ÷ 8⌉ | 2000 |
| 05/06 write single | 8 | 8 | 1 |
| 10 write multiple registers | 9 + 2N | 8 | 123 |
| Exception response | — | 5 | — |
Reading 125 holding registers at once produces a 255-byte response, which takes about 292 ms on the wire at 9600 bps 8E1. Bigger blocks mean fewer requests but longer responses, so the timeout must grow with them.
3. How long one transaction takes
Reading 10 registers (FC03) at 9600 bps 8E1: the 8-byte request takes 9.2 ms, the 25-byte response 28.6 ms and t3.5 4.0 ms. With 10 ms of slave processing one transaction takes about 51.8 ms, and polling 5 devices in turn takes about 259 ms per cycle. A shorter polling interval will not make it faster — there is only one bus.
Slave processing time differs by device. Use the «response time» or «response delay» setting from the manual if there is one; otherwise measure the gap between request and response in a traffic log. Many devices take longer to process than to transmit, so raising the baud rate shortens the cycle less than you might expect.
4. Choosing the response timeout
- Floor: slave processing time + response transmission time — about 38.6 ms in the example above. Anything shorter times out while the response is still arriving.
- With a USB-serial adapter, received bytes reach the PC in batches (FTDI default 16 ms); add that.
- The specification's guidance: at 9600 bps the response timeout is typically 1 s to several seconds, and the turnaround delay after a broadcast (address 0) typically 100–200 ms.
- Set the real value well above the floor, but remember that a dead device stalls the bus for «timeout × (1 + retries)». With 10 devices, one powered off, a 1 s timeout and 2 retries add 3 s to every cycle.
5. Symptoms of wrong settings
| Symptom | Suspect |
|---|---|
| Occasional no response; the next reply looks like the answer to the previous request | Timeout shorter than processing + response time — the late reply lands in the next request's slot |
| Only large block reads fail, small reads work | Response transmission time (5 + 2N bytes) exceeds the timeout |
| Responses split in two with CRC errors | USB adapter latency, or the device leaves gaps longer than t1.5 between bytes |
| One device off stalls all updates for seconds | Timeout × retries is large |
| Some back-to-back requests get no reply, or exception 06 (busy) | Too little rest between requests for the device — increase the delay between requests |
In PortDock
- «Serial Timing Calculator» web tool: enter baud, parity, function, quantity and processing time to get t3.5, request/response times, transaction and cycle time, and the minimum timeout.
- Modbus Master: set the response timeout (default 1000 ms), retries and delay between requests (default 20 ms) under «Communication details», and a read interval per table. The line above each table shows average and maximum response time, measured from sending the request until the whole response has arrived (transmission and USB latency included).
- Modbus Slave's «fault injection» adds response delays or no reply, so you can see how a master's timeout and retries behave before any hardware is connected.
- Serial's «Modbus RTU» framing splits replies whose length is known from the function code at once and others by the 3.5-character time (at least 3 ms).
Published 2026-10-23