Modbus Polling Too Fast? Slow Slave Overload Fix

Everything works for a while — then the device stops answering, the link drops, and only a restart brings it back. If that pattern sounds familiar, you may not have a wiring problem at all. You may be polling a slow device faster than it can cope with, and it’s collapsing under the load. This page explains why it happens and how to fix it at the system level.

This is the theory companion to QModMaster Scan Rate: Fix Timeouts on Slow Devices, which covers the hands-on QModMaster settings (scan control, bus-load estimates, chunking your reads). Read that one to tune the client; read this one to understand the failure — and to fix it permanently.

A real case: the Sungrow inverter that dropped its link

This isn’t hypothetical. The Sungrow SHX inverter Home Assistant FAQ documents exactly this failure: the Modbus connection works, then drops after running for a while. The documented fixes are adding a Modbus proxy and reducing the poll frequency — in other words, the inverter’s Modbus stack couldn’t sustain the request rate, and slowing down the interrogation fixed it. The same thread is why a SourceForge user asked QModMaster for a “Changeable scan rate from 10ms up to minutes”: aggressive polling is a known device-killer across vendors.

Why slow slaves collapse under fast polling

• Modbus is a background task. On an inverter, meter, or PLC-adjacent controller, the CPU’s real job is power conversion or metering. The Modbus server gets leftover cycles. Hammer it and responses get slower — which makes the master retry sooner — which makes it worse. It’s a feedback loop.
• Tiny buffers overflow. Cheap slaves have small UART buffers. A new request arriving before the old reply finished transmitting overwrites or interleaves data — the device locks up or starts answering with garbage until rebooted.
• Watchdogs bite. Some devices run a communication watchdog: sustained abnormal traffic patterns trigger a protective reset of the comms stack, which looks exactly like a “link drop”.
• Half-duplex collisions. On RS-485, if the master transmits while the slave is still answering, both frames are destroyed. Faster polling shrinks the safety margin to zero.

The fixes, from easiest to most robust

1. Lower the poll rate. The obvious one, and the Sungrow FAQ’s first recommendation. Poll every few seconds instead of several times per second — most process values (temperature, power, energy totals) don’t change fast enough to justify aggressive polling anyway.

2. Stagger polling across devices. Don’t poll all slaves in a tight burst. Spread requests evenly across the cycle so each device gets idle recovery time between its turns.

3. Poll fewer registers. A 100-register block read keeps a slow slave busy far longer than the wire time suggests — it has to gather every value. Split big blocks; skip registers you don’t actually use.

4. Add a Modbus proxy. The Sungrow FAQ’s structural fix: one proxy polls the fragile device at a gentle, fixed rate and caches the results; QModMaster, Home Assistant, and your SCADA all read from the proxy’s cache as fast as they like. The slow device sees exactly one polite client. This is the correct architecture once more than one master needs the same data.

5. Separate fast and slow devices. If one sluggish inverter shares a bus with snappy sensors, give the slow device its own poll loop (or its own bus segment) so it never holds up — or gets trampled by — the fast traffic.