Fix “Number of Registers Returned Does Not Match” in QModMaster
When QModMaster asks a slave for N registers, it sanity-checks the reply: for function codes 03 and 04, the response’s Byte Count field must equal exactly 2 × N (two bytes per 16-bit register). When it doesn’t, QModMaster reports: “number of registers returned does not match number of registers requested.” Your request was fine — the frame that came back over the wire was wrong. The fix depends on why the reply was wrong, and there are four usual suspects.
This error has a well-documented real-world cousin: in a public issue thread, a user reading through a TCP multiplexer proxy saw QModMaster log “Error: Invalid data” because responses kept arriving stamped with the previous request’s transaction ID (Tx 0x0002 answered by Rx 0x0001, and so on). Late, shifted, or truncated responses are exactly what produces a register-count mismatch — so start by suspecting the path and the slave, not QModMaster.
The Four Causes
1. RTU-over-TCP Gateway Delay: Response Misalignment
The most common cause when a gateway or proxy sits between QModMaster and the device. The gateway takes longer to answer than QModMaster waits, so the response to request k arrives after request k+1 has already gone out. QModMaster pairs the late reply with the wrong request, and the register counts (or transaction IDs) don’t line up. This gets worse with short scan intervals and slow links — cellular modems, VPNs, and busy serial-to-Ethernet gateways are classic triggers.
2. Slave Firmware Bug: Short Frames
Some devices — often low-cost sensors or early firmware revisions — simply return fewer data bytes than requested, or miscalculate the Byte Count field. Signature: small reads always work, and one specific larger read always comes back short, even with a direct serial connection and generous timeouts. If you see that pattern, check the vendor’s site for a firmware update.
3. Reading More Registers Than the Slave Supports
The Modbus spec allows up to 125 holding registers (or 2000 coils) per request — but many devices cap out much lower: 32, 64, or some other vendor-specific limit. Instead of raising an exception, some slaves just truncate the reply. Signature: reads up to a certain size work, anything bigger fails with the mismatch error at exactly the same cutoff every time.
4. Holes in the Register Map
If your read block spans addresses the device doesn’t implement, some slaves return a short frame — or an exception response — instead of full data. Always read against the vendor’s register map and keep each request inside a contiguous implemented range. A mismatch that appears only for one specific address range, while neighboring ranges read fine, is the telltale sign.
Verify with the Bus Monitor
Open the Bus Monitor from QModMaster’s View menu and send a single read. The raw frames tell you which of the four causes you’re dealing with:
- Step 1: find the
Txrequest line and note the Quantity — the last two bytes of the request frame. That is N, the number of registers you asked for. - Step 2: find the matching
Rxresponse and check its transaction identifier against theTx. If the reply carries an earlier request’s identifier, you have response misalignment — cause 1 (gateway delay). - Step 3: read the response’s Byte Count byte. For N registers via function 03/04, it must equal exactly 2 × N. A smaller value means the slave truncated the frame — causes 2, 3, or 4.
- Step 4: shrink Number of Registers to a small value (2–10) and read again. If the small read succeeds, you are dealing with a device read-size limit or a register-map hole — split the original read into smaller blocks inside implemented ranges.
Fix for Each Cause
| Cause | Fix |
|---|---|
| Gateway delay / response misalignment | Slow the scan rate so each reply arrives before the next request; update the gateway firmware; test QModMaster connected directly to the device to confirm the gateway is the culprit |
| Slave firmware bug (short frames) | Update the device firmware; work around with smaller reads; report the bug to the vendor with a Bus Monitor capture |
| Read exceeds the slave’s limit | Split the read into chunks within the device’s documented maximum per request |
| Register-map hole | Read only implemented, contiguous address ranges per the vendor register map; treat exception 0x02 (Illegal Data Address) as the map telling you “nothing here” |
Frequently Asked Questions
Is this a QModMaster bug?
No. QModMaster is reporting what it measured on the wire: it asked for N registers and the reply didn’t contain 2 × N data bytes. The mismatch is in the response frame — produced by the slave, the gateway, or the path — and QModMaster is correctly refusing to show you misaligned data as if it were valid.
Small reads work but a large read fails. Why?
You’ve hit the device’s per-request read limit (cause 3) or a hole in the register map (cause 4). Find the cutoff by halving the request size until it succeeds, then check the vendor docs for the documented maximum. Split large reads into chunks that stay under the limit and inside implemented address ranges.
I only see this error through my gateway or proxy. What does that mean?
Almost certainly response misalignment from gateway latency (cause 1). The Bus Monitor will show replies arriving with stale transaction identifiers. Slow the scan interval, and if possible test QModMaster with a direct connection — if the mismatch disappears, the gateway’s timing is the problem, not your register addresses.
What exactly is the “Byte Count” field?
In a Modbus read response (function codes 01–04), Byte Count is the single byte right after the function code, stating how many data bytes follow. For holding/input registers (FC 03/04) it must equal twice the requested register count; for coils/discrete inputs (FC 01/02) it equals the number of bytes needed to pack the requested bits. QModMaster compares it against your request — any disagreement triggers this error.