Modbus Protocol Explained: RTU, TCP, and Register Addressing
Updated: Oct 3
Modbus is a client/server communication protocol for reading and writing coils and registers. RTU and ASCII use serial framing; Modbus TCP uses TCP/IP. Check the device's register map and the client's address convention before configuration.
At a retrofit site, a controller may expose Modbus RTU over a serial link while an upstream system expects Modbus TCP. The word “Modbus” alone does not tell you whether a gateway will bridge those frames or how a register label maps to a request.
This guide separates the data model from transport and message framing. It compares RTU, ASCII, and TCP. It also explains why a register reference such as 40001 is not always the address a client expects. Use the final section to build a short setup map before configuring a client or gateway.
Start With the Data Model
Modbus defines requests and responses between a client and a server. The application protocol organizes data into four groups:









Data group | Data unit | Typical access |
|---|---|---|
Coils | Single bits | Read and write |
Discrete inputs | Single bits | Read |
Input registers | 16-bit words | Read |
Holding registers | 16-bit words | Read and write |
The protocol defines function codes for operations such as reading coils, reading registers, and writing values. A device may implement only a subset of these operations. Its manual supplies the device-specific map: which function codes it accepts, what each address represents, whether it can be written, and how the value is encoded.
A 16-bit register does not define the engineering meaning of a value by itself.
A device may represent a larger number across multiple registers. Its manual may specify signedness, byte order, word order, scale, and units. Record those conventions alongside the register reference.
The Modbus Application Protocol Specification defines the protocol data model and function-code behavior. It does not supply a particular product’s register map.
RTU, ASCII, and TCP Use Different Framing
RTU and ASCII are serial message formats. Modbus TCP carries the application request over TCP/IP and adds a different header. RS-485 is a common physical layer for serial Modbus, but it is not itself a Modbus message format.
Variant | Message framing | Details to confirm |
|---|---|---|
Modbus RTU | Binary serial frame with a device address, function code, data, and CRC | Serial interface, device address, baud rate, parity, stop bits, and the device’s timing requirements |
Modbus ASCII | Serial frame containing ASCII-encoded hexadecimal data, with a start character, LRC, and line terminator | Whether the device actually supports ASCII and which serial settings it requires |
Modbus TCP | Modbus application request inside a TCP message with an MBAP header | Server IP, TCP port, client/server role, and whether a gateway uses the Unit Identifier to select a downstream device |
The Modbus Serial Line Protocol and Implementation Guide describes the serial framing and link requirements. The Modbus TCP/IP Implementation Guide describes the TCP message envelope and MBAP header. TCP deployments commonly use port 502, but confirm the configured port in the device documentation.
The function code and data model may be familiar across variants, but the frames are not interchangeable. A serial master cannot send an RTU frame directly to a TCP server and expect it to become Modbus TCP automatically. That conversion requires a gateway or device mode designed to perform it.
Treat Register References as Labels Until You Confirm the Request Address
Many manuals and engineering tools show references such as 00001, 10001, 30001, or 40001. These labels often indicate a data group and a human-facing register number. A Modbus request carries a numeric address field; the displayed reference is not necessarily the exact number a client should enter.
For example, 40001 is commonly used to label the first holding register, while the request address for that location is often zero. This is a common convention, not a safe assumption for every manual, driver, or gateway. Some tools ask for a reference number; others ask for a zero-based offset or a one-based address.
Before configuring a read, record all of the following:
The data group: coil, discrete input, input register, or holding register.
The function code required by the device.
The exact register label shown in its manual.
The address or offset expected by the client software.
The value type, signedness, byte and word order, scale, and units.
Do not subtract one from every address by habit. Compare the manual’s example with the client or gateway’s own address convention, then verify the result with one known, read-only value. The address field and function-code definitions are covered in the Modbus Application Protocol Specification.
Separate IP Routing From Protocol Conversion
An IP router forwards IP traffic between network interfaces. That does not mean it reads Modbus registers or changes a serial RTU frame into a Modbus TCP request. Protocol conversion happens at the application layer and requires a gateway or another device mode designed for it. RFC 1812 describes the forwarding responsibilities of an IPv4 router.
The distinction matters when a PLC is connected over serial but the monitoring client is on an IP network. A serial server may transport serial bytes over an IP connection while preserving the serial protocol.
A protocol gateway can instead terminate one Modbus variant and create requests in another. Confirm which mode is in use, where polling occurs, and how device identifiers and register maps are handled.
No router, serial interface, or conversion capability should be inferred from the words “industrial router” or “Modbus compatible.” Check the exact product and firmware manual before selecting equipment.
Build a Small Modbus Map Before Commissioning
Before writing configuration, make a one-page map for the devices and values involved:
Item | Record |
|---|---|
Endpoint | Device model, firmware, and whether it is the client or server |
Variant | RTU, ASCII, or TCP |
Link | Serial settings and device address, or IP address and configured TCP port |
Data point | Data group, function code, manual reference, and client address/offset |
Interpretation | Data type, signedness, byte/word order, scale, and unit |
Access | Read-only or writable, based on the device manual |
Use a documented read-only point first. Confirm the response and the interpreted value before adding more points or permitting writes. If the response arrives but the displayed value is wrong, recheck the map and data representation before changing the network path.
If a PLC, drive, or SCADA value is timing out or stale, use the separate PLC/Modbus troubleshooting guide.
FAQ
Are Modbus RTU and Modbus TCP the same protocol?

They use related Modbus application data and function codes, but their message framing and transport differ. RTU is a serial frame; Modbus TCP adds an MBAP header and travels over TCP/IP.
Does register 40001 always mean address zero?
No. 40001 commonly labels the first holding register, which is often represented by address zero in a request. Manuals, drivers, and gateways can display or accept addresses differently. Confirm the convention for both the device and the client.
Can an ordinary industrial router convert Modbus RTU to Modbus TCP?
Not by default. IP routing and Modbus conversion are different functions. The exact device must provide a gateway or protocol-conversion mode, and its manual must describe how that mode maps the serial device and register requests.
What should I have before asking for help with a Modbus connection?
Provide the device and firmware, RTU/ASCII/TCP mode, client/server roles, serial or IP settings, device identifier, register map, requested function code, address convention, and value encoding. Include a short request/response capture if the equipment makes one available.




