The gateway's IP address reaches the serial link and the unit ID picks the RTU slave behind it, so every HMI tag uses one IP address while each slave keeps a unique address from 1 to 247. Set a 1 s response timeout for reads of 100 registers at 9600 baud, and prove one point before adding the rest.
An HMI polls Modbus RTU slaves through a gateway with its ordinary Modbus TCP driver: enter the gateway's IP address once, and let the unit ID in each device entry pick the slave behind it. Valid slave addresses run from 1 to 247, each one unique on its serial link. The driver choice is rarely the problem. A unit ID that does not match the address set on the slave, or a register reference built on the wrong offset convention, produces exactly the same blank tag that a broken driver would. No driver swap fixes either. The steps below set the fields in the right order, the example sizes the timeout at 9600 baud, and the checks separate an address problem from a wiring problem.
What decides which RTU slave answers through a gateway?
The gateway's IP address selects the serial link. The 1-byte unit ID in the request selects the device on it. So every tag points at one IP address while each RTU slave keeps its own address from 1 to 247.
The Modbus TCP request carries a unit identifier field of exactly 1 byte. Its documented job is to identify a server that lives on a network other than TCP/IP, which here means a serial link behind a gateway. When a gateway bridges TCP to RTU, that unit ID maps to the RTU slave address on the serial side. The address plan has two layers: the IP address reaches the gateway and its link, and the unit ID reaches the one slave that should answer. A wrong IP and a wrong unit ID fail in different places. The wrong IP stops the connection before any slave sees a request. The wrong unit ID sends the request to a slave that ignores it. Neither wrong survives a driver change.
What do you need before you configure anything?
Collect four things before you open the HMI software: the gateway's IP address, each slave's serial address from its DIP switches or menu, the serial link's baud rate and character format, and the register list for every point you plan to show.
Read all four from the equipment, in this order:
- The gateway's IP address and subnet come from its network configuration, or from whoever commissioned it.
- Each slave's serial address is set on its rotary switch, DIP switches or front menu. Confirm it on the device, because two slaves shipped at address 1 answer nothing.
- The serial link's baud rate and character format must match on the gateway's serial port and on every slave. One link at 9600 baud and one slave at 19200 baud never exchanges a frame.
- The register list comes from each device's manual. Note the reference convention it prints, because the 40001-style display convention and the zero-based protocol offset differ by one.
The gateway manual matters too: it states how unit IDs map to serial ports on multi-port models.
How do you configure the HMI to poll through the gateway?
Create one Modbus TCP device entry per RTU slave, all pointed at the gateway's IP address on port 502. Give each entry its own unit ID so the fields, not the driver, decide which slave answers.
- Add a device in the HMI project and pick the generic Modbus TCP driver.
- Enter the gateway's IP address and port 502, the standard Modbus TCP port.
- In the device's unit ID field, enter the address set on the first RTU slave. HMI software labels this field differently: unit ID, slave address or slave ID, and some libraries call it MB_UNIT_ID. It fills the same 1-byte identifier in every request.
- Duplicate that device entry for each further slave. Change only the unit ID between copies; the driver and the IP address stay the same.
- Map each tag to its register with the offset convention: the request's register offset is zero-based, while the 40001-style reference counts from one, so holding register 40001 is offset zero in the request.
- Set the response timeout before download; the example below sizes it.
- Download the project and test a single point before building screens.
Which unit ID does each RTU slave get?
Give each RTU slave a unique unit ID from 1 to 247 that matches the address set on the device. Modbus serial addressing reaches 247 devices on one link, and address zero is broadcast, which a read request cannot use.
The space above 247 is reserved, so a polled device takes an address between 1 and 247. On a link with three slaves at addresses 3, 4 and 5, three HMI device entries carry those same numbers as unit IDs, all pointing at the gateway's IP. A duplicate on the same link is the failure to avoid: both slaves at address 4 receive the frame and both try to drive the RS-485 line, so the answer corrupts or the gateway reports an error. Many gateways forward the ID to the serial side unchanged. A multi-port model may map ranges of unit IDs to ports, and its manual states that mapping.
Example: what timeout does a 100-register poll at 9600 baud need?
At 9600 baud with one RTU slave, a read of 100 holding registers needs about 250 ms end to end. Set the HMI response timeout to 1 s and give the poll a cycle of at least 1 s.
Scenario: one HMI entry polls slave 1 through the gateway, reading 100 holding registers in a single request, on an RTU link at 9600 baud with 8 data bits, no parity and 1 stop bit, so each byte takes 10 bits on the wire.
- Request frame: slave address 1 + function code 1 + start offset 2 + register count 2 + CRC 2 = 8 bytes.
- Response frame: address 1 + function 1 + byte count 1 + 100 registers × 2 bytes + CRC 2 = 205 bytes.
- Traffic per poll: 213 bytes × 10 bits = 2130 bits.
- Wire time: 2130 ÷ 9600 bit/s = 0.22 s, about 220 ms.
- Modbus RTU requires a silent gap of 3.5 characters between frames: 2 gaps × 3.5 × 10 bits = 70 bits, about 7 ms.
- Add the slave's processing time and the whole transaction lands near 250 ms.
Set the response timeout to 1 s, four times the 250 ms transaction, so a lost frame still has room for one retry inside the window. Poll that group no faster than once per 1 s.
Five slaves of 100 registers each overrun that cycle: 5 × 250 ms = 1250 ms. Split each read into 50-register requests and the transaction drops to about 130 ms (113 bytes × 10 bits = 1130 bits, 1130 ÷ 9600 = 118 ms on the wire, plus processing), so five slaves fit inside 5 × 130 ms = 650 ms. Either split the reads that way or widen the poll cycle to 2 s.
For how the timeout setting and the poll interval interact inside the HMI, see what HMI timeout time and poll time each do.
How do you check the poll before you trust it on the floor?
Prove the path with one slave and one known value, then add devices one at a time. A wrong unit ID, a wrong offset and a dead serial link all show the same thing on the screen: no value.
- Ping the gateway's IP address. A reply proves the Ethernet side only; the serial link behind it is still unproven.
- Poll one register whose value you can verify at the slave, such as a status word visible on its own display, and read only. If the HMI value matches the device, the IP, the unit ID, the offset and the function are all right in one shot.
- Bring up the second slave under its unit ID and repeat, then the rest, one at a time.
- A slave that never answers points at three places, in this order: the address on the device, the gateway's serial settings, the RS-485 wiring and termination. Fixing Modbus RTU no-reply and address errors walks those checks.
- An exception code instead of a value means a slave did answer, so the wiring is fine and the request itself is wrong.
- Values that arrive but look implausible usually come from a register reference read with the wrong convention, an off-by-one from mixing the 40001-style reference with the zero-based offset. For devices whose manuals print nothing usable, determining valid register addresses beyond the documentation covers how to find what a slave really holds.
For a deeper commissioning pass on the converter itself, see test a Modbus TCP gateway before you trust the data.
The polled values can also reach people away from the panel on a shop-floor notice screen; how that screen gets its content is a separate decision from this gateway setup.
Can a gateway poll a PLC that does not speak Modbus?
It cannot: a Modbus gateway forwards Modbus requests only. A PLC whose serial port speaks its maker's own protocol stays unreachable until the HMI has a documented driver for that protocol and the maker documents that it works through a serial bridge.
The request a gateway forwards carries a Modbus function code and a zero-based offset, nothing else. A PLC built for a native serial protocol ignores those bytes, and the HMI logs a timeout. Adding a gateway to the network never converts the addresses. The conversion is either a driver the HMI maker documents for that PLC, or a mapping you build yourself, point by point. If the driver list includes a native-protocol driver, treat it as unproven through a serial bridge until one test point reads correctly, and let the driver's documentation and that test decide.
When you convert addresses yourself, prove one point per data type on a test screen first, reads before writes, and keep the released project untouched until each value matches the PLC. Mapping a PLC's native addresses to Modbus for an HMI panel shows that conversion work tag by tag.
Recommendation: Use the HMI's generic Modbus TCP driver aimed at the gateway's IP, one device entry per RTU slave with a unique unit ID from 1 to 247, a 1 s response timeout for reads of up to 100 registers at 9600 baud, and either a 2 s poll cycle or 50-register split reads once more than four slaves share one serial link. Keep native-protocol PLC drivers out of the gateway path until a single-point test proves them.
Questions
Can two RTU slaves share the same unit ID behind different gateways?
Yes. The IP address selects the gateway and its serial link, so the unit ID only has to be unique on the link it belongs to. Two slaves both set to address 5, each behind its own gateway, never receive the same request. The two HMI entries simply point at different IP addresses with unit ID 5.
What does a Modbus exception code in place of a value tell you?
The serial path works and a slave answered, so the problem is in the request. Exception 01 means the slave does not support the function code in the request. Exception 02 means the slave holds no register at that address, which usually points at an offset one out or a register the device does not have. Exception 03 means a value in the request, often the register count, sits outside what the slave accepts. Check the function and offset before touching any wiring.
Does the unit ID still matter when the gateway serves one slave only?
Usually it does. Many gateways pass the unit ID through to the serial side whatever hangs on the link, so a request carrying unit ID 1 reaches a slave configured as address 5 and goes unanswered. A smaller number of models offer a fixed one-slave mode that ignores the field. The gateway manual names that mode, and it usually sits next to the baud rate in the serial settings.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.