Modbus is one protocol with several ways of putting its messages on the wire, and the two most common - RTU and TCP - differ not in what they say but in how they package it. RTU is compact binary over a serial line, protected by a checksum; TCP is the same message wrapped in an Ethernet header and carried over an IP network, with the checksum dropped because the network provides its own. This guide compares Modbus RTU, Modbus TCP, and Modbus ASCII, and shows how a gateway bridges a legacy serial RTU device onto a cloud SCADA IP network.
Modbus TCP vs Modbus RTU in one line: Modbus RTU is the serial form: compact binary messages sent over RS-485 or RS-232, each ending in a CRC checksum that lets the receiver detect corruption on the line. Modbus TCP carries the same Modbus messages over Ethernet, wrapped in an MBAP header and relying on TCP/IP's own error checking, so it drops the CRC. Modbus ASCII is an older serial form that encodes messages as readable characters with a simpler checksum. A gateway bridges serial RTU devices onto an IP network by translating between the RTU framing and Modbus TCP.
Modbus RTU is the original and still most common serial form. It sends each message as compact binary - a slave address, a function code, the data, and a two-byte CRC - directly over a serial physical layer, most often RS-485, which allows many devices to share one bus. The CRC, or cyclic redundancy check, is calculated over the whole message so the receiving device can detect if any bits were corrupted in transit and discard a damaged frame rather than act on bad data. On a serial line with no other error protection, that CRC is essential.
RTU has no addressing beyond the slave address byte, because a serial bus is a single shared medium where that address is all that is needed to pick out one device. Framing relies on timing: a gap of silence on the line marks the boundary between messages, so an RTU device knows a frame has ended when the wire goes quiet for long enough. This makes RTU efficient - very little overhead per message - but tied to the characteristics of the serial link, including its timing and its one-master, many-devices topology.
Legacy wellsite RTUs and older field instruments very commonly speak Modbus RTU, because it long predated cheap industrial Ethernet and matched the serial wiring already run to remote sites. A device installed years ago at a well pad or tank battery is far more likely to offer an RS-485 port speaking Modbus RTU than a native Ethernet port, which is exactly why bridging RTU to modern IP networks is such a routine part of connecting older field equipment to a cloud SCADA.
Modbus TCP carries the same Modbus protocol data - the function code and data that define the request - but wraps it in an MBAP header and sends it over a TCP/IP connection on an Ethernet network. The MBAP header adds fields such as a transaction identifier, a protocol identifier, a length, and a unit identifier, replacing the serial addressing and framing with something suited to a packet network where multiple requests can be in flight. Crucially, Modbus TCP drops the RTU CRC, because TCP/IP already provides its own checksums and reliable delivery, so a redundant Modbus-level CRC would add nothing.
The practical gains of Modbus TCP are those of Ethernet generally: each device has an IP address, many masters and devices can coexist on the same network, and the reach is no longer limited to a serial bus. The trade is that the addressing model shifts - the IP identifies the device, and the unit identifier in the MBAP header becomes meaningful mainly when a gateway sits between the IP network and serial devices. A native TCP device is reached by its IP, while the unit identifier often carries a placeholder.
Modbus ASCII is a third, older serial form that sits alongside RTU. Instead of compact binary, it encodes each message as human-readable ASCII characters, with a longitudinal redundancy check rather than a CRC and explicit start and end characters framing each message. This makes ASCII easier to read and debug and more tolerant of timing gaps, but roughly doubles the message size compared to RTU and is slower, so it is far less common today. Most serial Modbus in the field is RTU, with ASCII encountered mainly on legacy or specialized equipment.
Because so many field devices speak Modbus RTU over serial while cloud SCADA lives on IP networks, a gateway that translates between the two is the standard connection. The gateway presents a Modbus TCP interface with an IP address to the network side and drives an RS-485 bus of RTU devices on the field side. Incoming Modbus TCP requests are stripped of their MBAP header, reissued as RTU frames with the appropriate slave address and a freshly calculated CRC onto the serial bus, and the RTU replies are wrapped back into Modbus TCP for the return trip.
The gateway therefore does more than change connectors - it converts framing and error checking between the two forms, adding the CRC on the way to the serial devices and relying on TCP on the way back to the network. The unit identifier in the Modbus TCP frame is what tells the gateway which serial slave address to target, so one gateway IP can front a whole chain of RTU devices, each addressed by its unit identifier. This is how a legacy serial RTU that has no concept of Ethernet ends up readable by a platform on the far side of the internet.
For a cloud SCADA such as Merobix, this bridging is what makes older field equipment visible without replacing it. The platform polls the gateway's IP over Modbus TCP, addressing each serial device by its unit identifier, while the gateway handles the RTU conversation on the RS-485 bus. The result is that a wellsite RTU speaking decades-old serial Modbus and a modern cloud SCADA end up in the same data flow, with the gateway absorbing the difference between binary-plus-CRC serial framing and Ethernet-framed Modbus TCP.
They carry the same Modbus messages but package them differently. RTU sends compact binary over a serial line, most often RS-485, and ends each message with a CRC checksum for error detection. TCP wraps the same message in an MBAP header and sends it over an Ethernet TCP/IP network, dropping the CRC because TCP/IP provides its own error checking. RTU suits shared serial buses, while TCP suits IP networks where each device has an IP address.
Because the underlying TCP/IP layer already provides error detection and reliable delivery through its own checksums and retransmission. The RTU CRC exists to catch corruption on a raw serial line that has no other protection, but on an Ethernet network that protection is redundant. So Modbus TCP replaces the serial framing and CRC with an MBAP header and lets TCP/IP guarantee the data's integrity.
A serial-to-Ethernet gateway presents a Modbus TCP interface on the network side and an RS-485 bus of RTU devices on the field side. It strips the MBAP header from incoming TCP requests, reissues them as RTU frames with the right slave address and a fresh CRC on the serial bus, and wraps the replies back into Modbus TCP. The unit identifier in each TCP frame tells the gateway which serial device to reach, so one IP can serve many RTU devices.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.