Why is my Modbus reading slow or unreliable?

Short answer

Five usual causes. A slow serial chain behind a gateway, where every request costs tens of milliseconds of wire time. Asking for too many registers in one request, which some devices truncate or refuse. Reading one register at a time instead of in blocks, which multiplies the cost by the number of readings. Another system polling the same equipment and colliding with you. And stale replies, where a late answer to a timed-out request makes every subsequent value one register out of step — the nastiest of the five, because every number shown is a real number from the wrong place.

Serial is genuinely slow

At 9600 baud a request and its reply take something like 20–50 milliseconds of wire time, plus whatever the device takes to think. Reading forty values one at a time is therefore a visible wait of a couple of seconds, and that is with everything working. If the equipment is behind a gateway, every request crosses that serial wire regardless of how fast the network side is.

The fix is to read in blocks. One request for registers 0 to 31 costs roughly what one request for register 0 costs, because the overhead dominates. Grouping a screenful of readings into one or two requests is frequently a tenfold improvement.

Blocks that are too big

The specification permits 125 registers per request. A lot of equipment, especially inexpensive gateways, does not manage that: it truncates the reply, returns exception 3 (illegal data value), or stops answering altogether.

If reads work one register at a time but fail in blocks, lower the block size. 32 is a safe starting point and 16 works almost everywhere. It is worth finding the largest size that works reliably rather than settling for one at a time.

Connection limits

Many Modbus TCP devices accept one connection. Some accept three or four and then silently stop answering new ones — the symptom being that it worked this morning and does not now. Close other software, and if a building management system is polling the same device, expect to be sharing badly.

Collisions with another poller

On an RS-485 chain there is one wire and one conversation at a time. If the BMS polls every five seconds and you poll at the same moment, requests collide and both sides see intermittent failures. This shows up as values that appear and disappear for no visible reason, and it gets worse the more you poll.

A quiet gap between requests helps more than it sounds like it should — 35 milliseconds is a reasonable default for anything behind a serial gateway.

Stale replies: the one to be suspicious of

Suppose a request times out, and the device's answer arrives a moment later anyway. If the tool does not discard it, the next request reads that leftover answer instead of its own, and from then on every value is one reply behind.

The symptom is values that are individually plausible but clearly belong to the wrong registers — the supply temperature showing what the return should say. If readings look shuffled rather than wrong, this is the first thing to suspect. Closing and reopening the connection clears it.

A checklist when it is unreliable

Lower the block size to 16 and see if it becomes reliable.
Raise the timeout. 1.5 seconds is fine for native Ethernet; a serial gateway often needs 3 seconds or more.
Add a gap between requests, 35 ms or so.
Make sure nothing else is talking to the device.
On a serial chain, check for duplicate unit IDs, missing termination, and total cable length.
If values look shuffled rather than wrong, reconnect.

All four of the first three settings are adjustable per device in Easy Modbus, which also groups nearby readings into single block requests automatically.