Modbus RTU vs TCP: Differences, Use Cases, and When to Choose Each

Modbus background

Modbus was created by Modicon (now Schneider Electric) in 1979 for communication between its Modicon 084 PLC and peripheral devices. It was one of the first industrial communication protocols and was placed in the public domain, which is the primary reason it remains so widely supported almost 50 years later. Today you will find Modbus in VFDs, power meters, temperature controllers, PLCs, flow computers, weigh scales, and hundreds of other device categories from virtually every manufacturer.

The protocol has two main serial variants (RTU and ASCII) and one Ethernet variant (TCP). A fourth variant, Modbus Plus, was a proprietary token-passing network also from Modicon and is now legacy. This article covers RTU and TCP — the two variants you will encounter in virtually all current work.

The Modbus data model

Before comparing RTU and TCP, it helps to understand the data model they share. Every Modbus device (called a "server" in the 2012 specification, historically called a "slave") has up to four data tables:

Modbus registers are 16-bit unsigned integers. Multi-register data types (32-bit floats, 32-bit integers) occupy two consecutive registers. The byte order within each register (big-endian) and the word order for multi-register values (high word first or low word first) vary by device — always consult the device's register map documentation.

Register addresses are 0-based in the actual protocol PDU (Protocol Data Unit) but are commonly written as 1-based addresses in documentation (so holding register 40001 is transmitted as address 0x0000). Many configuration tools accept both forms; verify which convention a tool uses before setting register addresses.

Modbus RTU: physical layer

Modbus RTU most commonly uses RS-485 (EIA-485) as its physical layer. RS-485 is a balanced differential serial standard that provides noise immunity and supports multi-drop bus topologies. Key RS-485 characteristics:

• Topology: Daisy-chain (bus) topology. All devices share a two-wire differential pair (+ and –, sometimes labelled A/B or D+/D–). A third wire (GND/common) should always be connected — it provides a reference for the common-mode voltage and is required to avoid exceeding the common-mode input range of the receivers.
• Maximum cable length: 1200 m (4000 ft) at 9600 baud; approximately 100 m at 115200 baud. Cable capacitance, termination resistance, and stub lengths all affect the practical maximum.
• Maximum devices: The RS-485 standard supports up to 32 unit loads per segment. Most modern RS-485 transceivers are ¼-unit-load, allowing up to 128 devices per segment electrically. Modbus RTU adds an addressing limit of 247 slaves (addresses 1–247; address 0 is reserved for broadcast).
• Termination: A 120 Ω terminating resistor must be placed at each end of the bus (the two most distant points from each other). Missing termination causes reflections that corrupt data at higher baud rates.
• Baud rate: Common values are 9600, 19200, 38400, 57600, and 115200 baud. All devices on the same RS-485 segment must use the same baud rate, data bits (usually 8), and parity (none, even, or odd).

Modbus RTU can also use RS-232 (EIA-232) for point-to-point connections between two devices. RS-232 is limited to approximately 15 m cable length and does not support multi-drop — useful for local device configuration but not for plant-floor networks.

Modbus RTU frame structure

A Modbus RTU frame has the following structure:

| Device Address | Function Code | Data bytes | CRC-16 |
|   1 byte       |   1 byte      | 0–252 bytes| 2 bytes |

Example — Read 5 holding registers from device 3, starting at address 0 (register 40001):
Request:  03 03 00 00 00 05 84 0B
           ^  ^  ^--^  ^--^  ^--^
           |  |  Start  Count  CRC
           |  FC 03 = Read Holding Registers
           Device address 3

Frame boundaries are determined by silent intervals — gaps in transmission of at least 3.5 character times. There are no start/stop bytes in RTU framing; the silence is the only frame delimiter. This means the master must wait at least 3.5 character times after the last byte of a response before sending the next request, and a single-character error can corrupt frame synchronisation until the next silence.

The CRC-16 (16-bit Cyclic Redundancy Check) covers the address, function code, and all data bytes. It provides error detection for transmission errors. If the CRC does not match, the receiver discards the frame silently — there is no automatic retransmission. The application must implement a timeout and retry mechanism.

Modbus TCP: transport layer

Modbus TCP was standardised by the Modbus Organisation in 1999. It encapsulates Modbus PDU frames in TCP/IP packets, allowing Modbus devices to communicate over standard Ethernet infrastructure without dedicated serial hardware.

Modbus TCP servers (slaves) listen on TCP port 502 (IANA-assigned). Modbus TCP clients (masters) initiate connections to port 502 on the target server's IP address. TCP provides reliable, ordered, error-checked delivery — so Modbus TCP does not need a CRC in the application layer (TCP's own error checking handles it).

Multiple clients can simultaneously connect to a single Modbus TCP server (the server must support concurrent connections — check the device specification). A single client can have multiple simultaneous transactions in flight using different Transaction Identifiers.

Modbus TCP frame structure

A Modbus TCP frame (called an ADU — Application Data Unit) consists of a 6-byte MBAP (Modbus Application Protocol) header followed by the same PDU (function code + data) used in RTU:

MBAP Header (6 bytes):
| Transaction ID | Protocol ID | Length  | Unit ID |
|   2 bytes      |   2 bytes   | 2 bytes | 1 byte  |

PDU (same as RTU, without CRC):
| Function Code | Data         |
|   1 byte      | 0–252 bytes  |

Transaction ID: Used by the client to match responses to requests (0x0000–0xFFFF)
Protocol ID:    Always 0x0000 for Modbus
Length:         Number of bytes following (Unit ID + FC + Data)
Unit ID:        Modbus slave address (for TCP-to-RTU gateways; use 0xFF if not applicable)

Example — Read 5 holding registers, starting at address 0:
00 01  00 00  00 06  01  03  00 00  00 05
^---^  ^---^  ^---^  ^   ^   ^---^  ^---^
Txn ID Proto  Length Unit FC  Start  Count
       =0     =6     ID=1 =03 =0     =5

The Unit ID byte (formerly called the Slave ID) is used when a Modbus TCP-to-RTU gateway is involved — it allows the gateway to address a specific RS-485 slave. For direct Modbus TCP devices, the Unit ID is typically set to 0xFF or 0x01 — check the device's documentation.

Side-by-side comparison

Which to choose for new installations?

For new installations where you are selecting both the master and slave devices, Modbus TCP is almost always the better choice:

• Standard Ethernet infrastructure is cheaper to install than dedicated RS-485 runs for multi-node networks.
• No baud rate configuration — Ethernet auto-negotiates speed and duplex.
• No termination resistors, no bias resistors, no cable stubs to manage.
• Multiple HMI, SCADA, and logging clients can connect simultaneously.
• Easier to integrate with cloud systems and higher-level software.

Choose Modbus RTU when:

• The device only supports RS-485 (many VFDs, power meters, temperature controllers, and loop controllers still only offer RS-485 Modbus).
• The application is in a location where Ethernet infrastructure is unavailable or impractical (long cable runs to remote instruments).
• You are adding a device to an existing RS-485 segment.
• Cost or simplicity is paramount for a small number of devices.

Neither variant is appropriate for real-time motion control or high-speed I/O. For those applications, use PROFINET, EtherNet/IP, or EtherCAT.

RTU-to-TCP gateways

A common scenario is an existing RS-485 Modbus RTU field network that needs to be integrated into an Ethernet-based control system or SCADA. A Modbus RTU-to-TCP gateway (also called a serial device server or protocol converter) solves this without replacing field devices.

The gateway has one or more RS-485 serial ports and one Ethernet port. On the TCP side, it presents each RTU slave as an addressable Modbus TCP server — typically using the Unit ID byte in the MBAP header to route requests to the correct RTU slave address. The TCP master sends requests to the gateway's IP address with the appropriate Unit ID; the gateway converts them to RTU frames and polls the correct slave.

Important: the gateway introduces additional latency (the RTU poll must complete before the TCP response is returned). For SCADA polling at 1-second intervals this is irrelevant; for tight control loops, it is not acceptable.

Security considerations

Modbus was designed before industrial cybersecurity was a concern. Neither RTU nor TCP has built-in authentication, encryption, or access control. Anyone with access to the RS-485 bus can inject commands; anyone with network access to TCP port 502 can read or write any register.

For Modbus TCP, the minimum security measures are:

• Firewall rules: Restrict access to port 502 to authorised source IP addresses only. Do not expose Modbus TCP servers directly to untrusted networks.
• Network segmentation: Place Modbus TCP devices in a dedicated industrial VLAN or subnet, separated from the corporate IT network by a firewall or industrial DMZ.
• Read-only access where possible: If a SCADA system only needs to read data, configure firewall rules to allow only read function codes (01–04) from SCADA IP addresses.

For applications requiring authenticated, encrypted, and audited access across network boundaries, OPC UA is the appropriate alternative — it has built-in security from the protocol level.

Common troubleshooting tips

Modbus RTU troubleshooting

• No response from any slave: Check that all devices are set to the same baud rate, data bits, and parity. Verify termination resistors are present at both ends of the RS-485 bus. Check the GND/common wire is connected.
• Intermittent CRC errors: Usually caused by cable stubs too long, missing termination, or electromagnetic interference. Shielded twisted pair (STP) cable with drain wire connected to ground at one end reduces EMI. Reduce baud rate to test.
• One slave does not respond: Verify the slave's Modbus address matches what the master is polling. Confirm the slave is not set to Modbus ASCII mode. Check for address conflicts (two devices with the same address).
• Wrong data values: Check register byte order and word order — many devices use big-endian byte order but little-endian word order for 32-bit values. Verify you are reading the correct register number and that 0-based vs 1-based addressing is consistent between master and slave.

Modbus TCP troubleshooting

• Connection refused: The server is not listening on port 502, the IP address is wrong, or a firewall is blocking the connection. Use ping to confirm IP connectivity, then telnet <ip> 502 to test port access.
• Exception response 02 (Illegal Data Address): The requested register address does not exist on this device. Check the device's register map — some devices use 0-based addresses, some 1-based.
• Exception response 03 (Illegal Data Value): The requested quantity of registers exceeds the maximum allowed per request (typically 125 for FC03, 2000 for FC01).
• Timeouts: Check that the server is not receiving too many simultaneous connections or is overloaded. Some embedded Modbus TCP stacks support only one or two simultaneous connections.

Frequently asked questions