Modbus RTU vs Modbus TCP: Frames, Timing and Wiring

• Modbus RTU frames are delimited by silent intervals; Modbus TCP frames rely on TCP for delimiting and integrity.
• Both protocols carry the same data model; the transport and error checking are what change.
• RS485 decides distance, node count and termination, while Modbus RTU defines the byte format on top.
• Modbus TCP removes the silent-interval timer but adds TCP latency, jitter and a gateway hop.
• Most field faults trace back to baud rate, parity, termination or timeout settings, not the protocol choice.

1. What Is Modbus RTU?

Modbus RTU is a master-slave serial protocol that encodes Modbus requests and responses as binary frames with a CRC-16 check.

It was designed for slow serial links, so every frame stays short. A request is a handful of bytes: the unit ID, the function code, an address, a quantity and a two-byte CRC. Nothing is sent as text, which is why it still runs comfortably at 9600 bps over a long twisted pair.

Core characteristics

• Binary encoding with a CRC-16. Values travel as raw bytes and a two-byte CRC closes each frame. The compactness buys bandwidth on slow links, while the CRC catches the bit errors a long serial line produces.
• Silent-interval framing. There is no start or end delimiter byte; a gap of at least 3.5 character times marks the boundary. Framing depends on timing, which is why an adapter that buffers or reshapes the byte stream can break it.
• Master-slave access. One master polls, up to 247 unit IDs can be addressed, and the addressed slave replies. The model is predictable, and it serialises all traffic onto one pair.
• Register-based data model. Coils, discrete inputs, input registers and holding registers are the four object types. That uniformity lets one client read a meter, a drive and a PLC without device-specific drivers.
• Runs over RS232 or RS485. Multidrop installations use RS485, normally with 120 ohm termination at both physical ends. The protocol sets no distance limit; the electrical layer does.

2. How Does Modbus RTU Work?

A Modbus RTU exchange is a strict request-response cycle: one master, one addressed slave, one reply.

1. The master builds the request. It assembles the unit ID, function code, starting address, quantity and data, then appends a CRC-16. Because the CRC adds two bytes, the frame stays small and suits a low-bandwidth link.
2. The bus goes silent first. The master waits at least 3.5 character times so every slave can recognise a frame boundary. A device that transmits outside its turn corrupts the frame for everyone.
3. Every slave reads the unit ID. The addressed slave processes the request; the others discard it silently. Two slaves sharing one unit ID is a common commissioning error, and a broadcast to address 0 returns no reply.
4. The addressed slave verifies the CRC. A failed CRC drops the frame without a response, so the master cannot tell a corrupted request from a powered-down slave unless it tracks timeouts separately.
5. The slave executes and answers. A valid request produces a reply in the same format, while an illegal register or unsupported function returns an exception code. Reading that code beats guessing at the wiring.
6. The master times out and retries. The master expects a reply inside a configured window. A reply that arrives late can make a write function look lost, so write retries deserve application-level care.

3. What Is Modbus TCP?

Modbus TCP is the same Modbus protocol carried over TCP/IP, where the protocol data unit is wrapped in a seven-byte MBAP header instead of a CRC-16 trailer.

In the stack, Modbus TCP is an application-layer protocol that relies on TCP, IP and Ethernet beneath it. Modbus RTU is also an application-layer protocol, but it relies on a serial link and, at the electrical layer, RS485. The two differ in transport, not in what a request means.

Core characteristics

• MBAP header instead of a CRC. The header carries a transaction identifier, a protocol identifier, a length field and a unit ID. No CRC is transmitted, because TCP already handles integrity checking and retransmission.
• Ethernet and IP addressing. A slave is reached by IP address and, by convention, TCP port 502. The unit ID is still used to address devices behind a gateway.
• TCP behaviour applies. Connections can be held open, several clients may connect at once, and lost segments are retransmitted by the stack. That retransmission is also a source of timing jitter.
• No bus distance of its own. Reach is set by the network - a switch, a router or a VPN - rather than by a bus specification, so the limits move to cabling and infrastructure.

4. Modbus RTU vs Modbus TCP: What Is the Difference?

Modbus RTU and Modbus TCP are the same protocol with different framing and transport, so the differences that matter are timing, topology and wiring.

The decision rule: choose Modbus TCP when both ends share one Ethernet network and several clients or fast scans are needed; choose Modbus RTU when the devices are serial, the run is long, or existing RS485 wiring must be reused.

5. Modbus RTU Configuration and Key Parameters

The settings below most often break a Modbus RTU link in the field, and each fails in a recognisable way.

• Baud rate: 9600, 19200, 38400 and 115200 bps cover most devices. Both ends must match exactly; a mismatch usually produces framing errors or silence, because the receiver samples bits at the wrong instants.
• Data bits, parity and stop bits: 8-N-1 is the default for almost every Modbus RTU device. A parity mismatch shows up as a steady stream of parity or framing errors, not as an outright stop.
• Inter-frame silence: at least 3.5 character times per the Modbus Application Protocol specification. An adapter or radio that buffers bytes can merge or split frames, and the symptom is a CRC error on a request that looks well formed.
• Maximum devices per segment: the protocol allows 247 unit IDs, but an RS485 segment carries about 32 standard unit loads. The electrical limit is reached long before the address limit.
• Termination: 120 ohm at both physical ends of the trunk and nowhere else. Missing termination shows up mainly at higher baud rates or longer cable, while double termination loads the bus.
• Timeout and retries: one round trip plus slave processing, then two or three retries. A timeout inherited from a wired bus is too short once a radio or gateway is in the path.
• Gateway latency: every TCP-to-RTU conversion adds a round trip and queuing time. Polling several slaves through one gateway raises the cycle time, so the client needs a longer response timeout.

6. When to Use Modbus RTU and When Not To

Good fit for Modbus RTU

• Field devices that offer serial ports rather than Ethernet: energy meters, drives, temperature controllers and older PLCs.
• Cable runs of tens to hundreds of metres, where pulling Ethernet to each node is not practical.
• Many small nodes with low data volume, where one twisted pair costs less than switches and cable trays.
• Radio or 4G extension of an existing serial bus into a remote cabinet.

Good fit for Modbus TCP

• Devices that already expose an Ethernet port and a TCP stack.
• Multi-client access, where several SCADA or historian instances read the same registers at once.
• Faster scans and larger register blocks, where a 9600 bps serial link becomes the bottleneck.
• Sites with structured cabling and managed switches already in place.

Poor fit for Modbus RTU

• Event-driven or full-duplex messaging; the master-slave poll model serialises everything.
• Very high node counts on one segment without a repeater.
• Long cable runs at high baud rates, since distance and speed trade against each other.
• Networks where several clients must read the same device at once.

Poor fit for Modbus TCP

• Field devices with no Ethernet interface, unless a gateway is added.
• Deterministic motion or interlock loops, where TCP jitter and retransmission are unacceptable.
• Remote sites with no reliable network infrastructure.
• Installations exposed to the public internet without a VPN or firewall.

7. Real-World Applications

In factory automation and energy monitoring, Modbus RTU is the usual protocol on the field bus, while Modbus TCP appears where devices already sit on Ethernet. The two meet at gateways and at radio or cellular links that extend a serial bus beyond cable reach.

Ebyte devices follow that split. On the serial side, the MA01-AACX2220 is an EMC and RoHS compliant RS485 Modbus RTU I/O network module with 2 digital inputs, 2 analog inputs and 2 digital outputs, a serial port for a PLC or touch display, 2 switch outputs and a watchdog.

On the Ethernet side, the ME31 family speaks both protocols. The ME31-AXXX8000 provides 8-way dry contact input over Modbus TCP or Modbus RTU with RJ45 and RS485 interfaces and a DC 8-28 V working voltage, and it can act as a simple Modbus gateway. The ME31-XAXX0600 covers the analog case with 6 analog inputs (0-20 mA / 4-20 mA), and the ME31-AAAX4220 combines 2-way A-type relay output, 2-way analog input and 4-way dry contact input over Modbus TCP or Modbus RTU.

Wireless links extend the same bus. The E95-DTU(400F20-485) offers a transparent RS485 interface on 410-510 MHz (default 433 MHz) at 20 dBm with a 1 km range in a DIN-rail plastic housing, while the E95-DTU(433L20-485)-V8 raises transparent transmission to 3 km on 410-441 MHz at 20 dBm with an 8-28 V DC input. The E150-400T30S is a LoRa module on 410.125-493.125 MHz at 30 dBm with an IPEX antenna, a 10 km figure, Modbus RTU support and 4 digital inputs and outputs over a UART interface. Where the transport must cross the internet, the E840-DTU(EC05-485)E-V2 is an industrial LTE Cat-1 4G RS485 modem for the Asia-Pacific market with TCP, UDP, MQTT and HTTP support, an 8-28 V DC input and DIN-rail mounting.

Every range figure above assumes a clear line of sight and correct termination at both ends of the RS485 trunk.

8. FAQ: Modbus RTU in Practice

Q1: What is the difference between Modbus RTU and Modbus TCP?

Modbus RTU sends the same protocol data unit as a binary serial frame over RS485 or RS232, delimited by a silent interval and protected by a CRC-16. Modbus TCP carries that unit inside an Ethernet frame and lets TCP handle framing and integrity. The function codes and register model stay identical.

Q2: Why is my Modbus RTU device not responding?

On a correctly wired bus, no response normally points to serial parameters or addressing rather than the protocol itself.

• Silence on the whole bus → check A and B polarity, termination and the master timeout.
• Framing or parity errors → confirm 8-N-1 matches the slave manual, not a saved profile.
• One node missing while others answer → verify its unit ID and that two slaves do not share an address.

Q3: What is the silent interval in Modbus RTU and how long is it?

The silent interval is the idle gap that separates one Modbus RTU frame from the next, because the protocol has no start or end delimiter byte. Per the Modbus Application Protocol specification it must be at least 3.5 character times, and both ends must agree on how long silence lasts.

Q4: Can I convert Modbus RTU to Modbus TCP with a gateway?

Yes. A Modbus gateway holds a TCP server on the Ethernet side and a Modbus RTU master or slave on the serial side, translating register reads and writes between the two. The conversion is transparent to the data model, but it adds latency, so timeout settings usually need to be relaxed.

Q5: How many devices can I put on one Modbus RTU RS485 segment?

Modbus RTU addresses devices with a one-byte unit ID, so the protocol allows 247 addresses, with address 0 reserved for broadcast. The practical limit is the RS485 electrical layer: about 32 standard unit loads per segment, which low-power transceivers can extend.

Q6: Should I use Modbus RTU or Modbus TCP for a new installation?

Choose Modbus TCP when devices already have Ethernet ports, the scan rate is fast, or several clients must read the same data. Choose Modbus RTU when the field devices are serial, cable runs are long, or existing RS485 wiring must be reused.

9. Pre-Flight Checklist Before You Wire a Modbus RTU Bus

1. Write the protocol map first. List every node with its unit ID, baud rate, parity and register range, and confirm no two slaves share an ID.
2. Match the four serial parameters before blaming hardware. Baud rate, data bits, parity and stop bits, in that order, read from each device manual rather than a copied profile.
3. Terminate both physical ends of the trunk, once. 120 ohm at each end, nothing at intermediate nodes, short stubs throughout.
4. Give the silent interval a timing budget. If an adapter, radio or gateway reshapes the byte stream, verify that frame boundaries survive end to end before commissioning the bus.
5. Set the timeout for the slowest path. Size master timeouts and retries around the worst-case gateway or radio hop, then confirm that repeated writes cannot double-apply.