Protocols & device control
Modbus TCP Unit ID Through a Gateway: Route to the Right Serial Device
Distinguish a gateway IP address from its downstream Unit Identifier and validate routing without issuing writes to the wrong serial node.
A Modbus TCP gateway's IP address identifies the gateway, while the Unit Identifier can select a downstream serial device. Configure both from the gateway's routing documentation. A working TCP connection to the right gateway does not prove that the request reached the intended endpoint.
This distinction is especially important when several identical devices share the same register map. Reading a plausible value from the wrong unit can pass a casual test and lead to incorrect control later.
Make the route visible in the asset record
The Modbus TCP Messaging Implementation Guide describes the MBAP header and the Unit Identifier's routing role. Native TCP devices may use or ignore that field according to their implementation; a serial gateway needs an explicit mapping. Never assume one global Unit ID suits both arrangements.
| Layer | Example engineering field | Verification evidence |
|---|---|---|
| Network destination | Gateway address and service port | Connection to the intended gateway |
| Routing selection | Unit Identifier | Gateway route or configuration |
| Serial endpoint | Slave address and physical location | Device label and read-only identity |
| Application data | Register table and offset | Manufacturer register map |
The worksheet intentionally avoids prescribing a universal numeric Unit ID. Device and gateway manuals determine valid values and special cases.
Commission one downstream node first
Confirm serial communication using one known endpoint and a harmless read. The Modbus serial implementation guide describes serial addressing and request handling. Match baud rate, parity, wiring and address before introducing a large group of nodes.
Then configure the TCP client with the gateway destination and the Unit Identifier that routes to this node. Read a value that distinguishes the endpoint from another identical unit, such as a documented identity or locally observable measurement.
Add the remaining nodes individually and retain a route table. Duplicate downstream addresses can produce confusing behavior, so record changes whenever a replacement unit is commissioned. Do not copy an old gateway profile without checking its route assumptions.
Diagnose partial success
If the TCP connection works but every routed read fails, inspect the gateway's serial-side status and Unit ID interpretation. If one node works and another does not, compare address, wiring branch and endpoint settings before blaming the network path common to both.
A gateway may serialize downstream transactions. Keep the client's concurrency and timeout policy consistent with that behavior. Increasing the number of simultaneous reads can create queue delay rather than improve refresh speed.
Distinguish a gateway exception from complete silence. A protocol reply reporting a target failure is evidence that the gateway processed the request. Log that separately from failure to establish TCP or receive any bytes.
Protect writes during route changes
Disable automatic writes while editing gateway routes or replacing serial nodes. Verify the endpoint identity again before enabling control. A correct register address on the wrong unit is still the wrong control action.
For installations with multiple gateways, use readable route names rather than relying on a bare numeric slave address in the UI. Include gateway identity and physical destination in support logs so two Unit 1 entries cannot be confused.
Acceptance should prove destination identity
Have a second engineer select each route from the worksheet and reproduce the expected read-only value. Disconnect one node and confirm only the expected route fails. Reconnect it, restart the gateway and verify the client recovers without applying stale commands.
Label the downstream equipment with the route name used in the worksheet. During service, compare that label and a read-only identity before restoring writes. A spare may arrive at an address already used elsewhere, so assign its address according to the vendor's procedure. Treat assignment as part of replacement rather than assuming an identical enclosure has an identical logical destination. Recheck the gateway's saved mapping after reboot before returning the installation to unattended operation.
Save routing configuration with firmware and register-map revisions. The RTU and TCP comparison provides system context. Review the exact gateway behavior with SoftControl partners before treating a routed serial installation as equivalent to a native TCP device.
Source documents
- www.modbus.org — / file / secure / messagingimplementationguide.pdf
- www.modbus.org — / file / secure / modbusoverserial.pdf
Use the source applicable to your model, firmware and operating-system edition. Read our editorial method.