Modbus RTU Timing Calculator

This free Modbus RTU timing calculator estimates how long one full polling cycle takes on an RS-485 Modbus RTU network — and how often your data actually refreshes. Enter the baud rate, serial format, slave count, registers read per device, and a typical device response time; it builds the cycle from character time, the mandatory inter-frame gap, one read request and response per device, and the time each device takes to answer. It's for controls and automation engineers commissioning a Modbus segment, checking whether added slaves will slow a SCADA or PLC poll beyond its scan budget, or setting a defensible master timeout. No account, no spreadsheet — the model and its assumptions are shown below.

The formula

Modbus RTU is a half-duplex, one-conversation-at-a-time protocol: the master sends a request, the line goes quiet, one device answers, the line goes quiet again, and only then does the next device get polled. The cycle time is that transaction, repeated for every device:

One character on the wire
  B      = 1 start + 8 data + P parity + S stop     bits per character
  T_char = B ÷ baud × 1000                          ms

Inter-frame gap (t3.5 — the silence that separates frames)
  T_gap  = 3.5 × T_char           at 19,200 baud and below
  T_gap  = 1.75 ms                above 19,200 baud (fixed value)

One transaction per device
  Request  = 8 bytes        T_req  = 8 × T_char
  Response = 5 + 2R bytes   T_resp = (5 + 2R) × T_char
  T_device = T_req + T_gap + T_delay + T_resp + T_gap

Whole network
  T_cycle   = T_device × N
  Refresh   = 1000 ÷ T_cycle                        Hz

Suggested response timeout
  T_timeout = (T_delay + T_resp + T_gap + 50 ms) rounded up to the next 50 ms

Why the request is 8 bytes and the response is 5 + 2R: a standard read request carries a device address, a function code, a two-byte start address, a two-byte quantity, and a two-byte CRC — 8 bytes, whatever you're reading. The response carries the address, function code, and a byte count (3 bytes), two bytes of data per register, and the CRC (2 bytes) — so response size, and response time, grow with the register count while request time stays fixed.

One structural consequence worth internalising: the wire terms (request, response, gaps) shrink as baud rate rises, but the device processing delay does not. On slow networks the wire dominates the cycle; on fast ones, the delay does — which is why doubling the baud rate never quite halves a real polling cycle.

What each input means

Every field below is exactly as it appears in the live calculator (labels, options, and defaults verified in source).

Worked example

Scenario: a typical mixed-vendor RS-485 segment — meters, drives, and remote I/O polled by a PLC. The inputs below are the calculator's own starting values, so you can reproduce this example exactly by opening the calculator and pressing "Calculate polling" without changing anything.

Inputs (the calculator's defaults):

• Baud rate: 19200
• Parity: Even / Odd
• Stop bits: 1
• Slave devices: 20
• Registers / device: 10
• Typical device response: 15 ms

Step by step:

1. Bits per character: 1 start + 8 data + 1 parity + 1 stop = 11 bits
2. Character time: 11 ÷ 19,200 × 1000 = 0.573 ms
3. Inter-frame gap: 19,200 baud is not above 19,200, so the gap is 3.5 character times: 3.5 × 0.573 = 2.005 ms
4. Request time: the read request is always 8 bytes: 8 × 0.573 = 4.58 ms
5. Response time: 5 + (2 × 10) = 25 bytes: 25 × 0.573 = 14.32 ms
6. Per-device transaction: 4.58 + 2.01 (gap) + 15 (device response) + 14.32 + 2.01 (gap) = 37.92 ms
7. Full polling cycle: 37.92 × 20 devices = 758 ms — the amber band (above 500 ms, within 2,000 ms)
8. Refresh rate: 1000 ÷ 758 = 1.32 Hz — each device's data updates about once every three-quarters of a second
9. Suggested timeout: 15 + 14.32 + 2.01 + 50 = 81.33 ms, rounded up to the next 50 ms = 100 ms

The calculator's verdict for these inputs reads: "Suggested starting response timeout: 100 ms. Tune against real slave response behavior and retry policy."

What the example shows: the three levers behave very differently. Holding everything else at the defaults:

Two lessons fall out of that table. First, halving the baud rate does not double the cycle (758 → 1,217 ms, not 1,516 ms), because the 15 ms device processing delay is a fixed cost that baud rate can't touch — and at 115,200 baud that same delay is already about 69% of each transaction, so faster devices would buy more than more baud. Second, device count is the ruthless lever: it multiplies everything, and combined with a slow baud rate it pushes a modest segment past the 2-second red band, where values are over three seconds old by the time the poll comes back around.

What the result tells you

The result panel shows four figures (labels as displayed by the live calculator), followed by a colour-banded verdict line:

• Character time — how long one framed character (start bit, 8 data bits, parity, stop bit) occupies the wire, in milliseconds. Every other wire figure in the result is this number multiplied by a byte count, so if it surprises you, check the baud rate and serial format first.
• Minimum inter-frame gap — the t3.5 silence that must separate frames: 3.5 character times at 19,200 baud and below, a fixed 1.75 ms above it. It looks like dead time, but the cycle pays it twice per device — at 9,600 baud the two gaps alone cost about 8 ms of every transaction.
• Full polling cycle — one transaction for every device, in milliseconds. This is your data's worst-case age: a value that changes just after its device was polled waits almost a full cycle before the master sees it. Compare it against the scan or update rate your application actually needs.
• Estimated full-network refresh — the same cycle expressed as a rate (1000 ÷ cycle, in Hz). It is the update frequency your HMI, SCADA, or historian will actually see for every device on the segment — 1.32 Hz in the worked example, not the "fast" update rate the baud rate might suggest.
• The verdict line and its colour — the verdict always names a suggested starting response timeout: the entered device delay, plus the response's time on the wire, plus one gap, plus 50 ms of allowance, rounded up to the next 50 ms. The colour bands the cycle time: green at 500 ms or below (comfortable for most monitoring and control), amber up to 2,000 ms (fine for trending and slow supervision — check it against your application's tolerance), red above 2,000 ms (supervision only; values are seconds old, and a device failure plus retries will stretch scans much further). The timeout is a starting point for a single transaction — not the cycle time — and the verdict itself says to tune it against real slave behaviour and your retry policy.

Common mistakes

1. Pricing only the bytes. It is tempting to divide the total bytes by the baud rate and call that the cycle. That skips the two t3.5 gaps in every transaction — at 9,600 baud each gap is 4.01 ms, so the "dead time" is about 8 ms per device, over 160 ms across a 20-device segment. The gaps are part of the protocol, not overhead you can configure away.
2. Assuming devices answer instantly. The device processing delay doesn't appear in any frame, so it gets forgotten — but it is paid on every transaction, and unlike the wire time it doesn't shrink when you raise the baud rate. At 115,200 baud it is roughly 69% of the worked example's transaction. Enter a realistic delay (ideally measured), or the estimate describes devices that don't exist.
3. Reading tags a few at a time. Polling 2 registers here and 4 registers there multiplies transactions, and every transaction pays a full 8-byte request, two gaps, and a device delay. Consolidating each device's values into one block read — up to the 125-register single-request limit — is usually the single biggest cycle-time win available, and it costs nothing.
4. Setting the timeout from the cycle time. The response timeout guards one wait for one device's answer. Set it anywhere near the full cycle time and a single dead device — times the master's retry count — stalls the entire segment for seconds on every pass. Set it too short and slow-but-healthy devices get retried constantly, which also burns cycle time. Start from the suggested figure and tune against observed behaviour.
5. Cranking the baud rate on a marginal segment. Higher baud shortens wire time on paper, but it can't fix long stubs, missing termination, or cable capacitance smearing the signal — frames arrive corrupted, CRC errors trigger retries, and the real refresh ends up slower than a clean lower baud rate would have given. This calculator prices time only; signal integrity is a separate check, and it gates whether the calculated time is achievable at all.

FAQ

Related tools and reading