QModMaster via Modbus TCP Gateway: Multiple Slaves Unit ID Guide

Your Modbus TCP gateway answers on its IP address, QModMaster reads slave 1 just fine, but slaves 2, 3 and 4 all time out. Or worse — every slave you query returns slave 1’s data. This is the single most common gateway problem in the Modbus world, and it comes down to one byte in the TCP frame: the Unit ID.

Real-world evidence this is a live problem: a SourceForge review of QModMaster states it plainly — “TCP messages do not include the slave address, so this cannot work with modbus TCP gateway that had several slaves attached.” The review is half right: Modbus TCP frames do carry a slave address, but in a different place than RTU users expect. Once you know where it lives, the fix is usually a one-field change in QModMaster.

Where the slave address hides in Modbus TCP: the MBAP Unit ID

In Modbus RTU, the slave address is the first byte of the serial frame — every device on the RS-485 bus sees every frame and only the addressed one answers. In Modbus TCP, the serial frame is wrapped in a 7-byte MBAP header (Modbus Application Protocol header):

Transaction ID (2 bytes) | Protocol ID (2 bytes) | Length (2 bytes) | Unit ID (1 byte)

That final Unit ID byte is the Modbus TCP equivalent of the RTU slave address. A gateway sitting between your Ethernet network and the RS-485 bus reads the Unit ID from each incoming TCP request, rebuilds an RTU frame addressed to that slave number, waits for the reply, wraps it back in an MBAP header, and sends it to you. The whole multi-slave trick lives or dies on this one byte.

Setting the Slave ID in QModMaster (TCP mode)

QModMaster’s TCP connection mode has a Slave ID field in the connection dialog. In TCP mode this field is written into the MBAP Unit ID byte — it is the exact same setting RTU users know, just transported differently. To poll several slaves through one gateway:

• Connect QModMaster in TCP mode to the gateway’s IP address and port (usually 502).
• Set Slave ID = 1 and read your registers. Confirm the first slave responds.
• Duplicate your register list (or your QModMaster session setup) with Slave ID = 2, 3, 4… — one Unit ID per physical slave on the RS-485 side.
• Make sure the Unit IDs match the slave addresses configured on the devices themselves (DIP switches, device menus, or vendor software), not the order you plugged them in.

If slave 1 reads and the others time out even though you’re sure the Unit IDs are right, the gateway — not QModMaster — is almost always the culprit. Read on.

The common pitfall: gateways that only forward Unit ID 1

Not all gateways forward the Unit ID faithfully. The most reported failure mode:

• The gateway ignores the MBAP Unit ID and always talks to the RTU slave wired as address 1 (or to a fixed, pre-configured address). Result: Unit ID 2/3/4 time out, or — sneakier — every Unit ID returns slave 1’s data.
• The gateway has a “unit ID mapping” table in its web interface that must be filled in: which incoming TCP Unit ID maps to which RTU slave address. If the table is empty or only has row 1, the other slaves are unreachable no matter what QModMaster sends.
• The gateway is in transparent/bridge mode instead of protocol-conversion mode. In transparent mode the gateway is a dumb pipe — there is no MBAP parsing at all. (See our Waveshare gateway modes guide for how the two modes differ and what QModMaster supports.)

Fix order: (1) open the gateway’s web UI and look for “Modbus gateway”, “unit mapping”, “slave mapping” or “protocol conversion” settings; (2) confirm the gateway is in Modbus TCP ↔ RTU conversion mode (not transparent); (3) verify each Unit ID maps to the correct RTU slave address; (4) re-test from QModMaster with Slave ID set per device. Also confirm all slaves share the same serial settings (baud rate, parity, data bits) — the gateway talks to every one of them on the same RS-485 line.

Quick troubleshooting checklist

• Ping the gateway IP — is the Ethernet side even reachable?
• Slave ID 1 reads OK? Then QModMaster’s TCP setup is fine; the problem is Unit ID forwarding.
• All Unit IDs return the same data? The gateway is pinning everything to one RTU address.
• Some slaves read, others time out? Check DIP-switch addresses on the silent devices, and the gateway’s mapping table.
• Nothing reads? Verify the gateway’s serial settings match the slaves (one mismatched baud rate silences the whole bus), and check A/B wiring.