Calculate your poll interval and bus load

Your Modbus polling interval is the answer to a sum you can do in five minutes, not a number you guess. Work out how long one full round of reads takes, then give that round at least twice as much room. After this lesson you can calculate the cycle time of your own installation, see where separate reads are burning bus time, and defend the interval you set.

How long does one read take?

At 9600 baud, reading ten holding registers costs about 46 milliseconds of bus time, and that number falls straight out of the frame. This is the request the client puts on the line: ten holding registers from PDU address 0 on server 1.

01 03 00 00 00 0A C5 CD

Eight bytes, always. An FC03 request has no variable part. The response does:

01 03 14 00 0A 00 0B 00 0C 00 0D 00 0E 00 0F 00 10 00 11 00 12 00 13 29 D6

Twenty-five bytes, which is exactly 5 + 2N with N = 10. Now the clock. An RTU character is always 11 bits on the line, so at 9600 baud one byte costs 11 / 9600 = 1.1458 ms. Between two frames sits at least t3.5 of silence, 4.010 ms at 9600 baud, and you need that silence twice: once between request and response, once before the next request. Seven character times together.

t_transaction = (request bytes + response bytes + 7) x 11 / baud rate + server processing time

Filled in: 8 + 25 + 7 = 40 character times, times 1.1458 ms, is 45.83 ms. On top of that comes the time the server needs to assemble its answer, and that figure is rarely in a datasheet. Where the 11 bits and the two silences come from is covered in the lesson on baud rate, parity and RTU timing.

Why block reads make such a difference

Because the overhead per transaction is fixed. Eight bytes of request, five bytes of response envelope and seven character times of silence are always 20 character times together, whether you ask for two registers or twenty-four. Each extra register adds only 2 bytes after that, so it is the same request as above with only the quantity changed:

At two registers per transaction, 83 percent of your bus time goes into asking rather than answering. At twenty-four registers it is 29 percent, so the overhead per measured value drops by nearly an order of magnitude. Doubling the baud rate halves both columns and leaves those shares untouched: merging reads changes the ratio, going faster does not.

The cycle time of your whole installation

Count the transactions, that is all there is to it. Take ten energy meters on one RS485 bus at 9600 baud, twelve float32 values per meter, so 24 registers each.

About 0.98 second against 5.7 seconds, a factor of 5.8. Same data, same bus, only asked differently. Which meter needs how many registers per reading is listed in the comparison of Modbus energy meters for installers.

At 19200 baud the same block-read cycle becomes 589.6 ms instead of 979.2 ms. Roughly half, but not exactly half, because the assumed 20 ms of processing per request does not scale with the baud rate. Long blocks therefore gain a lot from a faster line, while with many short reads the server is the bottleneck.

From cycle time to poll interval

Bus load is your cycle time divided by your poll interval. For the block-read cycle of 0.98 s that gives:

Stay under 50 percent, so pick an interval of at least twice your cycle time. That is a rule of thumb of this course, not a requirement from the specification, but above half there is no room left for a retry, a slow answer, or a second function on the same bus. Your client decides that interval: ModbusCloud Diagnostics polls from 500 ms to 10 s.

What the manufacturer allows

The specification lets you read 125 registers in one FC03 or FC04 request, but the device usually stops you sooner, and the smallest limit that applies sets your block size.

Those limits cut both ways. An Eastron block read at its maximum of 80 registers is 8 + 165 + 7 = 180 character times, which is 206.25 ms at 9600 baud for one request, so ten meters at that block size cost well over two seconds per round. And the NIBE ceiling is a budget rather than a block size: 60 registers once per second already spends 60 percent of it. What you are allowed to read is also not the same as what exists: a block that runs over a gap in the register map can come back as exception 02.

What a dead device does to your cycle

One meter loses its fuse and the cycle stops being yours. Nine meters still answer in about 881 ms, and the tenth costs you the full response timeout: 881 + 1000 = 1,881 ms with a timeout of 1 second, so 0.98 s becomes 1.88 s. Allow three retries before the client gives up and it is 881 + 3000 = 3,881 ms.

So measure the answer time of your slowest device and set the response timeout to about three times that, not to a default of 3 or 5 seconds. Let the client back off a silent device, for example once a minute after three failed cycles, and alarm on device does not answer separately from value out of range. How you divide devices over a bus and address them is covered in the lesson on multiple devices on one bus.

On TCP the maths is different

On Modbus TCP the frame time largely stops being the constraint: no mandatory silence between frames, 7 bytes of MBAP header instead of 1 address byte plus 2 CRC bytes, and the standard allows a client to send 1 to 16 requests to one server without waiting for a confirmation. What is left are device limits. SolarEdge accepts one connection at a time and closes an idle session after 2 minutes, SMA still wants its 10 seconds between transfers over ethernet as well, and NIBE still allows 100 registers per second. Behind an RTU-over-TCP gateway nothing changes at all, because the bus on the far side is still running at 9600 baud, as the lesson on choosing between RTU and TCP shows at byte level. That holds even when the link to the gateway runs over 4G, worked out in the guide to 4G Modbus gateways. What a cloud platform adds on top of your own cadence is covered in remote Modbus monitoring over the internet.

Common mistakes

Reading every register separately. One request per value looks tidy in the configuration and wastes the bus: at two registers per read, 83 percent of your bus time is envelope and silence. Group consecutive registers into one block read and the same data arrives about six times sooner.

Polling as fast as possible just in case. At 97.9 percent bus load there is no room for a retry, so one slow answer already leaves a gap. An interval of at least twice the cycle time buys that room back.

Ignoring the limit in the datasheet. SMA asks for at least 10 seconds between data transfers. Polling faster does not give you fresher data, only less consistent data. Look up the smallest limit per device.

Leaving a dead device in the cycle. A meter that no longer answers eats a full timeout every round, and with three retries it costs more time than all nine working meters together.

Get hands-on

Work out your own installation, then change one thing based on the outcome.

1. 1

   Count what you actually read

   Per device, note how many registers you need and how many separate read requests your client sends to get them.

2. 2

   Work out one transaction

   Take 20 character times of fixed overhead, add 2 per register, and multiply by the character time of your baud rate: 1.1458 ms at 9600 baud, 0.573 ms at 19200 baud.

3. 3

   Add them up into a cycle time

   Sum the transactions of all devices and add a processing time per request. Write next to the total that this last figure is an assumption until you have measured it.

4. 4

   Divide by your current interval

   Cycle time divided by poll interval is your bus load. Above 50 percent, there is work to do.

5. 5

   Merge reads and recalculate

   Combine consecutive registers into block reads within the limit of the device, run the sum again, and note what you won.

6. 6

   Measure instead of trusting the sum

   Let mbpoll keep polling for a minute without -1 and divide that minute by the number of poll cycles it reports. mbpoll is free to use, including commercially.

mbpoll -m rtu -a 1 -b 9600 -P none -t 4 -r 1 -c 24 /dev/ttyUSB0

No hardware to hand. Recalculate the worked scenario: ten meters, 24 registers each, 9600 baud. Do you land on about 0.98 s, and then on about 0.59 s at 19200 baud? Expected result: a calculated cycle time, a poll interval you can justify, and at least one place where separate reads have become a single block read.

Summary

• One FC03 transaction costs 20 character times of fixed overhead plus 2 per register, and at 9600 baud a character time is 1.1458 ms.
• Ten meters of 24 registers each take about 0.98 s per cycle as block reads and about 5.7 s as twelve separate reads per meter, a factor of 5.8.
• Bus load is cycle time divided by poll interval, and the rule of thumb of this course is to keep it under 50 percent.
• The block size you may use comes from the device, not from the 125 register limit in the specification.
• One device that stops answering pushes a cycle of 0.98 s to about 1.88 s with a 1 second timeout, and to about 3.88 s with three retries.