SCADA / HMI

Version 2026.20

Industry

Modbus TCP vs RTU

What stays the same, what changes on the wire, and the mistakes that make a new Modbus device stay silent.

Modbus TCP and Modbus RTU speak the same language and differ in how the words are packaged and carried. The data model and function codes are shared. The wrapper and the wire are not, and most trouble when moving between them comes from that gap.

For a plant manager or integrator, the short version: RTU runs on a twisted-pair serial cable and TCP runs on Ethernet. Both read and write the same numbered registers. Pick by what the device has on its back, then read on for the places where people lose an afternoon.

Two documents define the details: the MODBUS Application Protocol Specification V1.1b3 (requests and data model) and the MODBUS over Serial Line Specification and Implementation Guide V1.02 (RTU framing and RS-485 wiring).

What is the same

Modbus keeps data in four tables:

Table Access Typical use Read Write
Coils Bit, read/write Outputs, run commands FC 01 FC 05, FC 15
Discrete inputs Bit, read only Status contacts FC 02 none
Input registers 16-bit, read only Measurements FC 04 none
Holding registers 16-bit, read/write Setpoints, configuration FC 03 FC 06, FC 16

FC 05 and 06 write one coil or register; FC 15 and 16 write many. A register map in a drive manual works the same on either variant. Nothing in the table says what a register means: names, scaling, units and data types live in the device manual, not on the wire.

What changes on the wire

Modbus RTU

RTU is serial, most often two-wire RS-485. One client (the master in older documents) polls up to 247 servers (slaves), each with a unit ID from 1 to 247. Address 0 is a broadcast that nobody answers.

A frame is binary: unit ID, function code, data, then a CRC-16. There are no start or end markers. The receiver finds frame boundaries by silence: at least 3.5 character times between frames. A gap longer than 1.5 character times inside a frame makes the receiver discard it, which is why a cheap USB adapter that stalls mid-frame produces CRC errors.

Every node must share baud rate, parity and stop bits. The serial line specification recommends even parity with one stop bit (two stop bits with no parity), 8 data bits, an 11-bit character either way.

RS-485 has a physical side too. Wire one daisy-chained trunk, not a star. Put a 120 ohm termination resistor at each end of the trunk and nowhere else. Add bias resistors, usually at one point, so the line has a defined state when nobody is transmitting.

Modbus TCP

TCP runs over Ethernet, normally on port 502. The unit ID and CRC are replaced by the seven-byte MBAP header: a transaction ID (2 bytes) to match answers to requests, a protocol ID (2 bytes, always 0), a length (2 bytes) and a unit ID (1 byte). The same function code and data follow. No CRC is needed, because TCP has its own checksum. Several clients can talk to one server at once, which RTU cannot do: two masters on one RS-485 trunk collide.

The unit ID matters again behind a gateway. The gateway has Ethernet facing you and RS-485 facing a string of serial devices, and it uses the unit ID in your request to pick which serial device gets the message. Many native TCP devices ignore the unit ID or want a fixed value such as 1 or 255. Check the manual.

The trap: Modbus RTU over TCP

Many serial device servers tunnel a serial port through a TCP socket. Often the result is raw RTU frames, unit ID and CRC included, inside TCP. People call it Modbus RTU over TCP, and it is not Modbus TCP: there is no MBAP header. A driver set to Modbus TCP gets silence or an unreadable answer from a tunnel expecting RTU, and the reverse is just as broken. A converter setting such as "Modbus TCP to RTU gateway" versus "transparent serial tunnel" decides which driver you need.

Addressing traps shared by both

Reference numbers vs protocol addresses

Documentation often lists holding register 40001. The protocol counts from zero inside each table, so 40001 is address 0 on the wire. The leading 4 only names the table: 0xxxx coils, 1xxxx discrete inputs, 3xxxx input registers, 4xxxx holding registers. Five-digit notation runs out at 9999, so larger devices use six digits (400001).

Tools disagree on whether they subtract the one for you. If your driver returns the neighbour's value, shift the start address by one and see whether the data lines up.

Values that span registers

A 32-bit integer or float takes two registers, and vendors disagree on which comes first. The float 1.0 is 0x3F800000. A device may send 3F80 then 0000 (big-endian word order) or 0000 then 3F80 (little-endian). Byte order within each word can differ too, giving four combinations. If a temperature reads 2.3e-41, suspect word order.

Request size

One FC03 or FC04 read returns at most 125 registers, because the response must fit in a frame of 256 bytes on RTU or 260 on TCP. FC01 and FC02 allow up to 2000 bits, and FC16 writes up to 123 registers. Many devices set lower limits of their own.

Timing

Serial: the baud rate sets the ceiling

An RTU character is 11 bits, so at 9600 baud it takes about 1.15 ms. Take a request for 10 holding registers: 8 bytes out (ID, FC, start, quantity, CRC) and 25 bytes back (5 of overhead plus 20 of data). That is 33 bytes, 363 bits, about 38 ms at 9600 baud. Add two 3.5 character gaps (about 4 ms each) and the device's turnaround, often 5 to 20 ms, and one poll takes 50 to 65 ms. Ten such devices make a scan of 0.5 to 0.65 seconds before any retry. A timeout on a missing node adds a second or more per cycle, so one dead device slows the line.

TCP: different limits

Small devices often accept only a few simultaneous connections, sometimes one, so a second client, or a restarted driver that has not closed its old socket, gets refused. Set sensible timeouts and reuse one connection. Behind a gateway, the serial side is still the bottleneck: a fast Ethernet link in front of a 9600 baud trunk does not speed the devices up, and many gateways serialize requests from all clients.

Security

Neither version authenticates or encrypts. Any node that can reach a device can read it and, with a write function, change it. That is a network design problem: isolate the devices, put a firewall in front, allow only known clients. The Modbus Organization publishes a Modbus/TCP Security specification that runs the protocol over TLS. Check a device's manual before assuming it supports it.

Which one to use

  • RTU when the device only has a serial port, the run is long and noisy (about 1000 m at 9600 baud per the serial line guide), or you have a bus of simple meters.
  • TCP when the device has Ethernet, more than one system must read it, or you poll many devices quickly.
  • A gateway for a serial trunk of older devices on an Ethernet network. Know whether it converts protocols or tunnels raw serial.

When a new device will not answer

Work down this list; the cheapest causes come first.

  1. Match the transport. Modbus TCP, RTU, or RTU over TCP? Match the driver.
  2. Check the physical layer. Serial: A and B wires (swap them if nothing answers), ground, termination, bias. Ethernet: can you ping it, and is port 502 open?
  3. Match serial settings. Baud, parity, stop bits and data bits, on both ends. Nothing auto-negotiates.
  4. Check the unit ID. The right number for a serial device, and the right value (often 1 or 255, or ignored) for a native TCP one.
  5. Read something simple. One holding register the manual lists, FC03, count 1. Try address 0 and 1 for the off-by-one.
  6. Check the table and limits. The value may be in input registers (FC04); lower the count per request.
  7. Look at the traffic. A serial analyser or packet capture shows whether the request arrives and whether the device returns an exception code (01 illegal function, 02 illegal address, 03 illegal value, 04 device failure).

Where Raylux fits

Raylux's Nexus gateway has drivers for Modbus TCP and Modbus over a serial line, with unit ID, word order and byte order set per device. See the Modbus compatibility page and the full driver list. To weigh Modbus against OPC UA, read OPC UA vs Modbus; for the bigger picture, What is SCADA?.

Frequently asked questions

What is the difference between Modbus TCP and Modbus RTU?

They carry the same requests and the same function codes. RTU sends them over a serial line, usually RS-485, in a binary frame that ends with a CRC-16. TCP sends them over Ethernet on port 502, with a seven-byte MBAP header in front and no CRC, because TCP already checks the data.

Is Modbus RTU over TCP the same as Modbus TCP?

No. Modbus RTU over TCP puts raw RTU frames, address and CRC included, inside a TCP connection. Modbus TCP uses the MBAP header instead. The two look alike in a device menu but differ on the wire, and a driver set to one gets no useful answer from the other.

Why is Modbus holding register 40001 address 0?

The 4xxxx numbers are a reference convention that adds a table prefix. The protocol counts from zero inside each table, so the first holding register is address 0. Some tools subtract the one for you and some do not, which is the usual cause of values that are off by one register.

How many registers can I read in one Modbus request?

Up to 125 holding or input registers in a single FC03 or FC04 request, a limit set by the size of the response frame. A device may allow fewer, so check its manual. A 32-bit value takes two registers.

Is Modbus secure?

Not by itself. Neither Modbus TCP nor RTU authenticates the sender or encrypts anything, so any node that can reach the device can read and write it. Protection comes from network design: isolation, firewalls and access control. The Modbus Organization also publishes a Modbus/TCP Security specification that wraps the protocol in TLS.

Related posts

  • Industry7 min read

    OPC UA vs Modbus

    Modbus and OPC UA compared on data model, polling, quality, security and setup cost, with guidance on when each is the right choice.