Modbus TCP vs Modbus RTU: Same Protocol, Different Cables

TL;DR: Modbus RTU is the original form — binary messages over a two-wire RS-485 serial bus, with one master polling up to 247 slaves at baud rates from 9600 to 115200. Modbus TCP carries the same register model and function codes over a standard Ethernet connection using TCP/IP on port 502. The data you read from a Modbus holding register is identical in both variants. What differs is the transport: serial wire vs Ethernet cable, CRC error detection vs TCP checksums, and a thin wrapper called the MBAP header that replaces RTU's slave address and CRC. If you already understand one variant, you understand 90% of the other.

This is the question that comes up every time a controls engineer moves from a serial Modbus install to an Ethernet-based system — or when they try to connect a TCP gateway to an RTU device. The confusion is understandable: most documentation and most PLC configuration screens say "Modbus" without specifying which variant. Getting it wrong means no communication at all.

The Shared Foundation

Both Modbus RTU and Modbus TCP use the same data model and the same function codes. If you know one, the other is a short upgrade.

The data model organises device memory into four tables:

• Holding registers (40001–49999): 16-bit read/write values — the most commonly used table. Motor speed setpoint, process setpoints, mode commands.
• Input registers (30001–39999): 16-bit read-only values — measured process values, fault codes, running totals.
• Coils (00001–09999): single-bit read/write — start/stop commands, output states.
• Discrete inputs (10001–19999): single-bit read-only — limit switch states, alarm bits, ready signals.

The function codes are identical in both variants:

| Function Code | Operation | |---|---| | 01 | Read Coils | | 02 | Read Discrete Inputs | | 03 | Read Holding Registers | | 04 | Read Input Registers | | 05 | Write Single Coil | | 06 | Write Single Register | | 15 | Write Multiple Coils | | 16 | Write Multiple Registers |

This shared foundation means a PLC ladder rung written for Modbus RTU — reading register 40001 from device address 5 — works identically over Modbus TCP, connecting to the same device at its IP address.

Modbus RTU

Modbus RTU runs over a serial bus — almost always RS-485 two-wire differential wiring. It is a master/slave protocol: one master (the PLC) initiates all transactions; slaves only respond when addressed.

The RTU frame

| Slave Address | Function Code | Data | CRC (2 bytes) |
|     1 byte    |     1 byte    | N×2  |               |

• Slave address (1–247): which device is being addressed. Address 0 is broadcast (write-only, no response expected).
• Function code: what operation to perform.
• Data: register start address, quantity, and (for writes) data values.
• CRC: 16-bit cyclic redundancy check — the receiver recomputes the CRC and discards the frame if it does not match.
• Framing: RTU uses silence gaps — a gap of at least 3.5 character times before and after each frame signals a new message. There are no start/stop delimiters; timing is the delimiter.

RTU characteristics

• Speed: 9600–115200 baud in the field. Speed and distance trade off — 9600 baud works reliably at 1200 m; 115200 baud is practical only under 100 m with good cable.
• Bus topology: daisy-chain — all devices share the same two-wire bus. One device transmits at a time; the master grants the turn by polling.
• Devices per bus: 32 unit loads (256 with 1/8-unit-load transceivers). Modbus addresses up to 247 slaves.
• Response time: add up polling time for each slave. At 9600 baud with 10 devices, a full scan takes 200–400 ms.

Modbus TCP

Modbus TCP carries Modbus function codes over standard Ethernet using TCP/IP on port 502. Each device has an IP address. There is no bus — each connection is a point-to-point TCP socket.

The TCP frame — the MBAP header

Modbus TCP wraps each request and response with a 6-byte header called the MBAP (Modbus Application Protocol header):

| Transaction ID | Protocol ID | Length | Unit ID | Function Code | Data |
|     2 bytes    |   2 bytes   | 2 bytes| 1 byte  |    1 byte     | N×2  |

• Transaction ID: a sequence number assigned by the client, echoed by the server. Allows pairing requests and responses when multiple transactions are in flight.
• Protocol ID: always 0x0000 for Modbus TCP.
• Length: number of bytes following the length field (Unit ID + Function Code + Data).
• Unit ID: equivalent to the RTU slave address. Typically 1 or 255 for a standalone device; used when a gateway bridges to a serial Modbus bus behind the TCP endpoint.

Notice: no CRC. TCP/IP provides its own error checking at the transport layer, so Modbus TCP does not add a CRC.

TCP characteristics

• Speed: limited by Ethernet latency (typically 1–10 ms per transaction), not baud rate. Response times are much faster than serial for equivalent polling.
• Topology: star (via Ethernet switch). Any number of devices on the same network.
• Concurrent connections: a Modbus TCP server typically supports multiple simultaneous client connections.
• Devices: no inherent device limit. Limited by network infrastructure and server capability.

Side-by-Side Comparison

| | Modbus RTU | Modbus TCP | |---|---|---| | Transport | RS-485 serial bus | Ethernet TCP/IP | | Port | COM port (baud rate, parity, stop bits) | TCP port 502 | | Addressing | 1-byte slave address (1–247) | IP address + Unit ID (1 byte) | | Frame header | None (silence-delimited) | 6-byte MBAP header | | Error detection | 16-bit CRC at end of frame | TCP/IP checksum (no CRC) | | Speed | 9600–115200 baud | 10/100/1000 Mbit Ethernet | | Typical response time | 5–50 ms (baud rate dependent) | 1–10 ms | | Max devices per segment | 32 unit loads (RS-485 physical limit) | No practical limit | | Concurrent requests | No — strict request/response | Yes — transaction ID enables parallel | | Cable | Shielded twisted pair, 120 Ω | Cat 5e / Cat 6 Ethernet | | Distance | Up to 1200 m at 100 kbit/s | 100 m per segment (switch extends) |

The Unit ID on Modbus TCP Gateways

The Unit ID field in the MBAP header is frequently misunderstood. When you connect directly to a device that supports Modbus TCP natively — a modern VFD, a power meter, a flow computer with an Ethernet port — the Unit ID is usually 1 or 255, and you can ignore it.

The Unit ID becomes critical when you use a Modbus TCP gateway — a device that has an Ethernet port on one side and an RS-485 serial bus on the other. The gateway listens for Modbus TCP requests and forwards them as Modbus RTU messages to the serial bus. The Unit ID in the TCP MBAP header maps to the slave address on the RTU bus. So:

• TCP request: IP address = 192.168.1.50, Unit ID = 3 → Gateway forwards RTU frame to slave address 3.
• TCP request: IP address = 192.168.1.50, Unit ID = 7 → Gateway forwards RTU frame to slave address 7.

If your PLC shows "slave not responding" when connecting through a gateway, check that the Unit ID in your PLC communication configuration matches the RTU slave address on the serial bus behind the gateway.

Decision Guide

Use Modbus RTU when:

• The device has only an RS-485 serial port (older VFDs, energy meters, sensors, I/O modules, PLCs).
• The existing bus wiring is already installed and working.
• The cable run is short enough for the required baud rate.
• You need to add one more device to a working serial bus.

Use Modbus TCP when:

• The device has an Ethernet port.
• You need sub-10 ms response times.
• You are connecting across a building network rather than a panel-local cable run.
• You need a SCADA server to poll more than 30–40 serial devices simultaneously — a TCP architecture with managed switches handles concurrency far better than a serial bus.
• You are building a new system: Ethernet infrastructure is cheaper and more available than RS-485 specialist cabling.

Migrate from RTU to TCP using a gateway when:

• Existing RS-485 serial devices do not have Ethernet ports.
• You want to connect those devices to an Ethernet-based SCADA or PLC system.
• The gateway is transparent to the function codes — you just reconfigure your PLC to use TCP to the gateway IP, matching Unit IDs to existing slave addresses.

Troubleshooting

Modbus RTU troubleshooting checklist:

1. Baud rate, parity, and stop bits match on master and all slaves.
2. Termination resistors (120 Ω) are at the two physical ends of the cable only — not at intermediate slaves.
3. Slave address in PLC configuration matches the dip switch or parameter setting on the device.
4. A and B polarity is consistent — reversed polarity gives no communication at all.
5. Only one device is transmitting at a time — if two devices share the same slave address, both will respond and corrupt the bus.

Modbus TCP troubleshooting checklist:

1. Device IP address, subnet mask, and gateway are correct and reachable (ping first).
2. PLC is connecting to port 502.
3. Unit ID in PLC configuration matches the expected value for the device (usually 1 or 255 for a native TCP device; matches RTU slave address for a gateway).
4. Firewall or switch ACL is not blocking port 502.
5. Only one SCADA or PLC client is connected at a time if the device only supports one concurrent session (many older devices with Ethernet bolt-on modules have this limit).

Frequently Asked Questions

Q: Is Modbus TCP faster than Modbus RTU?

A: Yes, substantially. Modbus RTU at 9600 baud takes roughly 3–5 ms per transaction for a typical register read. Modbus TCP over a local Ethernet switch takes 1–3 ms. More importantly, Modbus TCP supports concurrent transactions (multiple requests in flight simultaneously using transaction IDs), which makes large poll lists much faster. A SCADA system polling 20 Modbus TCP devices simultaneously is far faster than polling 20 RTU devices on a serial bus sequentially.

Q: Can I run Modbus TCP and Modbus RTU at the same time on a PLC?

A: Yes. Most PLCs with both an RS-485 serial port and an Ethernet port can run Modbus RTU master on the serial port and Modbus TCP client on Ethernet simultaneously. The two communication stacks are independent — the PLC program uses different instructions or communication blocks for each.

Q: What port does Modbus TCP use?

A: TCP port 502 is the official IANA-assigned port for Modbus TCP. Some devices allow this to be changed, but port 502 is the default you should configure unless the device documentation says otherwise.

Q: What is the difference between Modbus RTU and Modbus ASCII?

A: Modbus RTU encodes data in binary — compact and fast, the standard field choice. Modbus ASCII encodes data as printable hexadecimal characters — 2× the bytes per message, but readable with a terminal and easier to debug by eye. Both run over serial (RS-485 or RS-232). ASCII is rarely seen in new installations; RTU is the field standard.

Q: Can a Modbus TCP client connect to more than one device at the same IP address?

A: Yes, if the device is a gateway. A Modbus TCP-to-RTU gateway at a single IP address routes requests to multiple RS-485 slave devices using the Unit ID field. Each Unit ID routes to a different RTU slave address on the serial bus behind the gateway.

---

Practise reading and writing Modbus holding registers in a PLC program with the Modbus register read scenario — it simulates a Modbus slave device and auto-grades your function code against real register values. The RS-485 wiring lab covers termination, polarity, and bus diagnostics on the physical layer that Modbus RTU depends on.

Try the Modbus scenario →