How to Fix Modbus TCP Unit-ID Confusion at a Gateway
Your Modbus TCP poll reaches the gateway's IP address, the connection is up, but the reply is an exception, a timeout, or data from the wrong device. On a native Ethernet device the unit ID barely matters, but the moment a serial-to-Ethernet gateway sits behind that IP, the unit ID becomes the address that decides which downstream serial device answers. This guide untangles that confusion: what the unit ID does at a gateway versus a native device, and how to set it correctly so each poll reaches the device you meant.
Fix Modbus TCP unit-ID confusion in one line: At a Modbus TCP gateway, the unit ID in each request selects which serial device behind the gateway's single IP should answer, so getting it wrong routes your poll to the wrong device or nowhere. Fix it by setting each tag's unit ID to the serial slave address of the target device, not to 1 or 255 by default. On a native TCP device the IP identifies the device and the unit ID is usually ignored, but a gateway needs it to route correctly.
Determine Whether You Are Polling a Gateway
The fix depends entirely on whether the IP you are polling belongs to a native Modbus TCP device or to a serial gateway, so establish that first. A native device - a PLC or transmitter with its own Ethernet port - is fully identified by its IP address, and the unit ID field in the request is often ignored or accepted at any value. A gateway, by contrast, is one IP fronting a serial RS-485 bus with several devices on it, and it uses the unit ID to decide which of those serial slaves to forward the request to. The distinction is drawn under a Modbus unit ID and slave address.
Tell them apart from the site drawing or the device itself: if the IP terminates at a box that also has RS-485 terminals with field devices wired to it, you are polling a gateway. If it terminates at a single self-contained device, it is native. This matters because the same symptom - right IP, wrong or missing data - has different causes. On a native device it points at addressing or register mapping; on a gateway it usually points straight at the unit ID, and the mechanism of that routing is explained under a Modbus gateway unit ID remap.
Set the Unit ID to the Target Serial Address
For a gateway, set each tag or device entry's unit ID to the slave address of the specific serial device you want, as documented for that device on the RS-485 bus behind the gateway. If a flow meter sits at serial address 3 on the gateway's bus, poll the gateway's IP with unit ID 3, and the gateway forwards the request to that meter and returns its reply. Every serial device behind the gateway needs its own tag entries at its own unit ID, all pointed at the one gateway IP - the pattern for setting this up is the same as mapping a Modbus device in SCADA.
The common mistake is leaving the unit ID at a default of 1 or 255. A default of 1 accidentally routes every poll to whatever device sits at serial address 1, so all your tags read one device regardless of which you meant. A value of 255 or 0 has special meanings some gateways treat as address-any or broadcast, and neither reliably reaches a specific device. Set the unit ID deliberately per device to its real serial address, and never rely on the driver's default when a gateway is in the path.
Handle Colliding Serial Addresses
A harder case is two serial devices behind the gateway that share the same slave address - two identical meters both factory-set to address 1, for instance. The unit ID alone cannot tell them apart, because both would answer unit ID 1. Resolve it at the source by changing one device's serial address so each is unique on the gateway's bus, which is the clean fix and lets a single unit-ID-to-slave mapping work. Re-addressing a device on a shared bus is covered under adding a Modbus node to a live RS-485 bus.
Where you cannot re-address the devices, the gateway itself must disambiguate, either by a remap table that assigns each physical device a distinct virtual unit ID, or by giving each device its own TCP port or IP alias. The gateway's remap capability is exactly what the gateway unit ID remap exists for. Whichever route you take, the end state is that every physical device is reachable by a unique combination of IP, port, and unit ID from your SCADA, with no two devices answering the same request.
Verify Each Device Answers as Itself
Confirm the routing by polling each unit ID and checking you get that device's data, not a neighbor's. The strongest test is a value that differs between devices - a serial number, a distinct process reading, a device-specific register - so you can prove unit ID 3 really returns the meter at address 3 and not the one at address 1. If two unit IDs return identical data, you have an unresolved address collision and need to go back to the remap or re-addressing step.
Watch for gateway-specific exceptions that pinpoint routing failures. Exception 0A, gateway path unavailable, means the unit ID maps to no downstream device; exception 0B, target device failed to respond, means the gateway routed the request but got no serial reply - these are diagnosed under Modbus gateway exceptions 0A and 0B. Receiving either proves the TCP path and gateway are alive and that the problem is the unit ID or the serial side, which is exactly the confusion this procedure resolves. Every device answering as itself, cleanly, is the finished state.
Frequently Asked Questions
What unit ID should I use for Modbus TCP?
It depends on the target. For a native Modbus TCP device the IP identifies it and the unit ID is usually ignored, so any value or the driver default works. For a serial gateway, set the unit ID to the slave address of the specific downstream device you want, because the gateway uses it to route the request. Never leave it at a blind default of 1 when a gateway is in the path, or every poll goes to whatever sits at address 1.
Why does my Modbus TCP poll reach the IP but get the wrong device?
There is a gateway behind that IP and the unit ID is routing your poll to a different serial device than you intended, usually because it is left at a default. Set each tag's unit ID to the target device's serial slave address. If two devices behind the gateway share an address, re-address one or use the gateway's remap or separate ports so each device is reachable by a unique identifier.
Is unit ID 255 valid in Modbus TCP?
The specification allows 255 as a value meaning the request is for the device at the IP address itself, which native TCP devices accept. But at a gateway, 255 and 0 have special handling and do not reliably reach a specific downstream serial device. When polling through a gateway, set the unit ID to the real serial slave address of the target rather than 255 or 0, so the gateway can route the request correctly.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.