QModMaster ‘No Response’ Timeout: 9 Fixes That Actually Work
“No response” is the most common thing QModMaster ever tells you — and the least informative. It means a request went out (or didn’t) and nothing usable came back within the timeout. The cause is almost never QModMaster itself. Work through these nine fixes in order; one of them resolves the large majority of cases.
Fix 1 — A/B lines swapped or loose
RS485’s A/B pair reversed is the single most common wiring fault, and it produces exactly this symptom: total silence. Power down, verify A goes to A and B goes to B at both ends, and re-seat every terminal — screw terminals vibrate loose over time.
A multimeter settles wiring arguments fast: with the bus idle, measure the differential voltage between A and B — a healthy bus shows a small non-zero voltage, while 0 V usually means no driver is active or the pair is shorted. Keep one on the bench: digital multimeters.
Fix 2 — Baud rate, parity, or stop bits mismatch
Both ends must agree exactly — 9600 8N1 on the PC against 19200 8E1 on the device is silence. When in doubt, set both sides to 9600 baud, 8 data bits, no parity, 1 stop bit (the closest thing Modbus has to a universal default) and retest before restoring the device’s configured rate.
Fix 3 — Wrong slave ID
The slave ID in QModMaster must match the device’s configured address (1–247). Check the device’s display, DIP switches, or configuration software — and remember that on Modbus TCP gateways the Unit ID often maps to the downstream serial slave.
Fix 4 — Wrong COM port selected
Windows loves to re-enumerate USB adapters on a different COM port after a reboot or a different USB socket. Open Device Manager, confirm which port your adapter is on right now, and select exactly that port in QModMaster.
Fix 5 — RTS control not enabled (manual-direction adapters)
If your USB-RS485 adapter lacks automatic direction control, the request never makes it onto the bus without RTS toggling. Enable RTS toggle in the RTU settings — the full explanation is in the RS485 RTS control guide.
Fix 6 — Missing termination on long runs
On cable runs longer than a few dozen meters, signal reflections corrupt the frame. Fit a 120 Ω resistor across A/B at both physical ends of the bus — not at every device, just the two ends.
Fix 7 — Device not powered, or not in Modbus mode
Obvious but common: the device is off, or its Modbus slave mode is disabled in its own configuration. Some instruments need a menu setting or DIP switch flipped before they answer Modbus at all.
Fix 8 — Register address off by one
If the device answers some requests but your target register times out or throws exception 02, you are likely hitting the 0-based vs 1-based addressing trap — the manual says 40001, the wire wants 0. See the addressing guide and try a ±1 offset.
Fix 9 — Modbus TCP: firewall, wrong IP, or wrong port
For TCP, “no response” is a network problem until proven otherwise: ping the device, confirm you are connecting to the right IP and port 502, and check that no firewall is dropping the connection. Then verify the Unit ID.
A 5-minute diagnostic routine
- Confirm the COM port in Device Manager and select it in QModMaster.
- Set 9600 8N1 and take the slave ID straight from the device’s nameplate or configuration.
- Open the bus monitor — if your request bytes appear there, the PC side (port, RTS timing) is working and the fault is downstream.
- If the bus is long or noisy, temporarily test with a short cable at 9600 baud to isolate the physical layer.
When bytes leave the PC but come back corrupted — or never come back — seeing the electrical truth helps. A USB logic analyzer captures the raw frames so you can compare them against the bus monitor: USB logic analyzers.
Frequently asked questions
QModMaster times out but the vendor’s own software talks to the device. Why?
Almost always a serial parameter the vendor tool sets silently — RTS direction control, or a non-default parity/stop-bit combination. Mirror every serial setting from the working software, including the RTS mode, and QModMaster will talk too.
What timeout value should I use?
1000 ms is a sane starting point for RTU. Slow devices, radio modems, or very long runs may legitimately need 2000–3000 ms. If you find yourself wanting more than that, stop stretching the timeout and fix the underlying cause instead.
No response over Modbus TCP — where do I start?
Ping the device’s IP, confirm port 502 is reachable and not blocked by a firewall, then check the Unit ID — on gateways it usually selects the downstream serial slave.
Timeouts are intermittent — sometimes it works. What’s wrong?
Intermittent faults point at the physical layer: electrical noise, missing termination, loose terminals, or a marginal power supply. If replies arrive but consistently fail their CRC check, the cause is frame corruption rather than silence — check baud rate and noise sources next.
Related Guides
- RS485 RTS Control in QModMaster: When to Enable It — fix 5 in detail
- Modbus Addressing: 0-Based vs 1-Based (The 40001 Trap) — fix 8 in detail
- QModMaster Tutorial: Your First Poll in 10 Minutes — from install to live data
- Download QModMaster — free, open-source (LGPLv3), Windows and Linux
