QModMaster Scan Rate: Fix Timeouts on Slow Devices

Your device answers every manual read in QModMaster, but the moment you enable Scan mode — continuous polling — it starts timing out, drops off the bus, or needs a power cycle to come back. The device isn’t broken. You’re just asking it questions faster than it can answer. This guide covers where the scan control lives in QModMaster, what “slave response time” actually means, and how to estimate whether your RS-485 bus is overloaded.

This is the practical, QModMaster-settings companion to our deeper dive Modbus Polling Too Fast? Slow Slave Overload Fix, which explains the physics of why slow devices collapse under fast polling (with a real Sungrow inverter case).

Where the scan control lives in QModMaster

In the QModMaster main window, the Scan checkbox (near the read controls) switches from single-shot reads to continuous polling — QModMaster re-issues your read request over and over, updating the values live. That’s the feature timing out your slow device.

An honest caveat before you go hunting for a dial: QModMaster’s built-in scan control is basic, and users have been asking for more. A SourceForge feature request literally asks for a “Changeable scan rate from 10ms up to minutes” — because the stock behavior can be too aggressive for slow hardware. If you can’t slow the scan enough inside QModMaster, the workarounds below are the real fix, not a different checkbox.

Understand slave response time

Every Modbus slave needs a moment between receiving your request and having an answer ready. Cheap microcontrollers, solar inverters, and energy meters often need tens to hundreds of milliseconds to service a Modbus request — they’re busy running their actual job (inverting power, metering energy) and Modbus is a background task.

If QModMaster fires the next request before the slave finished the previous one, three bad things happen: the slave ignores the new request (timeout on your side), it answers late and the reply collides with your next request (CRC errors), or its tiny receive buffer overflows and the device locks up until rebooted. All three look like “the device is flaky” when the real problem is your poll rate.

Rough RS-485 bus load estimate

You don’t need lab equipment to sanity-check your bus — a back-of-the-envelope estimate is enough to see if you’re asking the impossible. The rough math:

• Every serial byte costs 10 bits on the wire (8 data bits + start + stop, at 8N1).
• A Modbus RTU request for N registers is about 8 bytes; the response is about 5 + 2×N bytes.
• Wire time per poll ≈ (request bytes + response bytes) × 10 ÷ baud rate, plus the slave’s response time, plus the mandatory 3.5-character silent gap between frames.
• Multiply by your number of slaves to get the minimum time for one full scan cycle.

Example of the shape of the problem (do your own numbers for your setup): five slaves, 20 registers each, at 9600 baud, with each slave taking 100 ms to respond — the wire time alone is well over half a second per cycle, and with response times it’s closer to a full second. If your scan is set (or defaults) to something much faster than that, you’re permanently behind: requests pile up, collide, and time out. Rule of thumb: your scan interval must be longer than one full cycle through every slave, with margin.

Practical fixes in QModMaster

• Turn Scan mode off and poll manually while debugging — confirm the device is healthy before blaming the poll rate.
• Read fewer registers per poll. Two small reads that succeed beat one big read that times out. Split a 50-register block into chunks.
• Poll fewer slaves per cycle, or poll the slow device less often than the fast ones (stagger them).
• Slow the baud rate down if the line is long or noisy — counterintuitively, a slower, clean bus beats a fast, error-prone one.
• Check the hardware first. Timeouts that look like “slow device” are often a marginal RS-485 adapter. Rule out the cable before redesigning your poll strategy — see our USB-to-RS485 adapter notes.
• For a permanent multi-client setup, put a Modbus proxy between QModMaster and the bus (covered in the companion theory page).