On a Modbus network, something has to say which device a request is meant for, and that job falls to a single identifying byte. On a serial bus it is called the slave address; in a Modbus TCP frame it is called the Unit ID. They look like the same field and often carry the same number, but they play subtly different roles, and understanding the difference is what lets a serial-to-Ethernet gateway route one IP address to a whole string of chained field devices at a tank battery.
Modbus Unit ID / Slave Address in one line: The slave address is the number, from 1 to 247, that identifies a device on a serial Modbus RTU bus, so that on a shared RS-485 line only the addressed device answers. The Unit ID is the equivalent identifying byte in a Modbus TCP frame's header. On a native TCP device the IP address already identifies the device and the Unit ID is often ignored, but on a serial-to-Ethernet gateway the Unit ID is essential: the gateway uses it to decide which chained serial device behind a single IP address the request should be forwarded to.
RS-485 lets many devices share one pair of wires, all listening to the same electrical signal, so there must be a way to address just one of them at a time. That is the slave address. Every device on the multidrop bus is assigned a unique address, and every request the master sends begins with the address of the intended device. All devices hear the request, but only the one whose address matches responds; the others ignore it. This is how a single master can talk to a dozen transmitters and controllers on one twisted pair without their replies colliding.
The address space runs from 1 to 247 for individually addressed devices, with address 0 reserved for broadcast - a request every device acts on but none answers. Because the bus is shared, two devices with the same address are a fault: both would try to answer the same request and their responses would collide, corrupting the reply. Commissioning an RS-485 multidrop bus therefore includes assigning each device a distinct address, usually by a switch or a configuration setting on the device, and recording those addresses so the master knows which number reaches which physical instrument.
The slave address is thus a property of the serial network's topology. It exists because the medium is shared and unaddressed on its own, so the address is the only thing distinguishing one device's traffic from another's on the same wires. Everything about the address - its uniqueness requirement, its range, the broadcast reservation - follows from the fact that a multidrop bus is one conversation that many devices share, and the address decides whose turn it is to speak.
Modbus TCP wraps the same Modbus messages in an Ethernet frame with a small header, and that header includes a Unit Identifier byte in the same position the slave address occupied on serial. On a device that speaks Modbus TCP natively, the situation is different from serial in an important way: the IP address already uniquely identifies the device, because each device has its own IP, so the Unit ID is often redundant. Many native TCP devices simply ignore the Unit ID or expect a placeholder value, since routing is already handled by the IP layer.
This is why the Unit ID can seem unimportant when talking to a pure Modbus TCP device - point the master at the right IP and the Unit ID barely matters. But the field did not vanish from the frame; it was kept precisely because Modbus TCP was designed to coexist with serial Modbus through gateways. In that role the Unit ID recovers its original meaning as a device selector, carrying the identity of a specific serial device across the Ethernet portion of the path so it can be applied once the message reaches the serial side.
So the Unit ID is best understood as the slave address in TCP clothing. When the destination is a native TCP device, the IP does the addressing and the Unit ID is often along for the ride. When the destination is a serial device reached through a gateway, the Unit ID becomes the crucial piece of information, because the IP only gets the request as far as the gateway - something still has to say which device beyond the gateway the request is for, and that something is the Unit ID.
A tank battery commonly has several serial field devices - level transmitters, a flow computer, a controller - chained on one RS-485 bus, each with its own slave address, but no individual IP address of its own. To bring them onto a cloud SCADA IP network, a serial-to-Ethernet gateway is installed with a single IP address facing the network and the RS-485 bus facing the field. The cloud SCADA then reaches every device at that one IP, and the Unit ID is what distinguishes them from each other across that shared address.
The routing works because the gateway maps the Unit ID in each incoming TCP request onto the slave address it places on the serial bus. A poll aimed at the gateway's IP with Unit ID 3 is forwarded to serial slave address 3; a poll to the same IP with Unit ID 7 goes to slave address 7. The gateway strips the TCP framing, issues the serial request to the matching address, waits for that device's reply, wraps it back up, and returns it over Ethernet. From the cloud SCADA's view it is talking to many logical devices at one IP, distinguished purely by Unit ID, while on the wire it is one serial conversation the gateway conducts on its behalf.
This is exactly how a platform such as Merobix collects data from a tank battery full of serial instruments without giving each one its own network connection. The integrator configures one IP for the gateway and a tag set per Unit ID, and each Unit ID corresponds to a physical device's serial address on the bus. Getting those Unit IDs to match the serial addresses is the crux of the setup - a mismatch means the SCADA reaches the gateway fine but polls the wrong instrument, so the tank level tag might return the flow computer's registers because the Unit ID pointed at the wrong device behind the same IP.
They occupy the same role - identifying which device a request is for - but in different transports. Slave address is the term on a serial RS-485 bus, where it selects one device among many sharing the wire. Unit ID is the equivalent byte in a Modbus TCP frame's header. On a native TCP device the IP does the addressing so the Unit ID is often ignored, but through a gateway the Unit ID carries the serial device's address, making the two effectively the same thing.
Because on a native TCP device the IP address already uniquely identifies the device - each has its own IP - so there is nothing left for the Unit ID to select. Many such devices therefore ignore the field or accept a placeholder value. The Unit ID field is still present in the frame because Modbus TCP was designed to interoperate with serial devices through gateways, where the Unit ID does the real addressing work.
A serial-to-Ethernet gateway presents one IP address to the network but connects to a chain of serial devices, each with its own slave address. The gateway maps the Unit ID in each incoming TCP request onto the matching serial slave address, forwards the request to that device, and returns its reply. So a poll to the gateway's IP with Unit ID 3 reaches serial device 3, letting one IP serve many chained devices at a tank battery.
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.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.