Modbus RTU vs Modbus TCP: a practical guide

Modbus has survived since 1979 by being brutally simple: a master asks, a slave answers. No discovery, no browsing, no security — just reads and writes against numbered registers. Nearly every PLC, drive, meter, and sensor speaks it, which is why "just use Modbus" remains the default answer for brownfield integration. The two forms you will actually meet are RTU and TCP, and mixing them up is the most common source of broken integrations.

RTU: Modbus on a serial wire

Modbus RTU runs over RS-485 (sometimes RS-232), carrying binary frames: one address byte, one function byte, data, and a two-byte CRC. Timing is part of the protocol — a silent gap of 3.5 character times marks the end of a frame — which means RTU over sloppy USB converters or congested links fails in confusing ways.

The rules that matter: one master per segment (slaves never speak unprompted), unique slave addresses 1–247, matching baud rate/parity/stop bits everywhere, correct byte order for 32-bit values (there is no standard — check the device manual), and termination resistors on long RS-485 runs. Get any of these wrong and you get timeouts or garbage instead of errors, because RTU has no diagnostics beyond the CRC.

TCP: Modbus on Ethernet

Modbus TCP wraps the same protocol data unit in a lightweight MBAP header and sends it over TCP port 502. No CRC (TCP handles integrity), no timing dependence, and multiple masters can query the same device. Addressing stays identical — coils, discrete inputs, holding registers, input registers — so documentation and data maps transfer directly from RTU projects.

The catch is that "Modbus TCP" describes the wire format, not the network behavior. Polling hundreds of devices from one client needs connection management and sane poll rates; a 100 ms poll loop against a serial gateway with thirty RTU slaves behind it will simply queue up and time out. Size the gateway segment first, then the Ethernet side.

RTU/TCP gateways and common mistakes

Most real projects mix both: RTU multidrop segments for field devices, gateways translating to Modbus TCP for SCADA and edge systems. When it breaks, check in this order:

1. Unit identifier vs slave address. Modbus TCP's unit-ID field routes to the RTU slave behind the gateway. Wrong ID, no answer.
2. 0-based vs 1-based addressing. "Register 40001" is protocol address 0 on most stacks — and some vendors mean 1. Off-by-one reads return the neighbor's value with no error.
3. Byte and word order. A float read as ABCD vs CDAB looks like a plausible but wrong number — the hardest fault to catch.
4. Function code support. Not every device implements every function; write-multiple-registers on a read-mostly meter fails silently on some firmware.

Where Modbus fits today

Modbus is a polling protocol for simple data exchange — ideal for meters, drives, and legacy PLCs, inadequate for alarming, discovery, or secure communication. Use it at the device edge, terminate it at a gateway or edge node, and carry the data upstream over OPC UA or MQTT/Sparkplug where modeling, buffering, and security exist. It will outlive most of the protocols competing to replace it, precisely because it does so little.

References

• Modbus specifications and resources — the Modbus Organization
• Instrumentation Tools — practical Modbus and PLC tutorials
• ACC Automation: Master PLC & Industrial Automation — free PLC training with Modbus examples