What Is Modbus? Protocol Basics for Industrial Networks

Modbus is a serial communication protocol that connects a master device — usually a PLC, an HMI, or a SCADA system — to slave devices such as sensors, variable frequency drives, and power meters. Modbus RTU is the protocol’s most common implementation: it packs every message into a compact binary frame and moves it over an RS-485 or RS-232 line, which is why it still runs underneath most low-cost industrial hardware decades after Modicon introduced it in 1979. Modbus’s appeal was never speed — it is that the standard is open and royalty-free.

This guide covers the Modbus RTU master-slave communication model, the RS-485 physical layer, how a Modbus RTU message frame is structured, the standard function codes, and how Modbus RTU compares to Modbus TCP/IP. It’s written for system integrators and maintenance engineers who need to wire, poll, or troubleshoot a Modbus network on the plant floor.

What Is Modbus RTU?

Modbus RTU is a serial version of the Modbus communication protocol that encodes every message as raw binary data instead of readable text. A master device — typically a PLC or a SCADA computer — sends a request over a shared serial line, and one addressed slave device responds. RTU stands for Remote Terminal Unit, a reference to the field devices the protocol was originally designed to poll.

What makes Modbus RTU different from a proprietary fieldbus is that it costs nothing to implement. Modbus is an open standard: any manufacturer can build support for it into a sensor, drive, or controller without paying a royalty or licensing fee. That is the main reason it became the default communication protocol for low-cost industrial devices — a sensor vendor gains nothing by inventing a private protocol when Modbus RTU already ships free in most microcontroller libraries. The tradeoff is that Modbus RTU is not self-describing: a device’s register map (which address holds which value) is defined by the manufacturer, not by the protocol itself, so integrators always need the device’s Modbus map document before they can read anything meaningful off the line.

How Does the Modbus Master-Slave Model Work?

Modbus RTU runs on a master-slave model, sometimes called client-server. One master polls one or more slave devices, and a slave only ever speaks when it has been addressed directly — it never initiates communication on its own.

Every slave device on a Modbus RTU network holds a unique address between 1 and 247. Address 0 is reserved for broadcast messages that every slave accepts but does not acknowledge. Because only the master initiates a request, and the addressing scheme just needs to identify one target on a shared line, no separate bus-arbitration mechanism is required — the master’s polling sequence already guarantees only one device transmits at a time.

• Master (client):typically a PLC or a SCADA/HMI computer, responsible for polling servers and issuing commands
• Slave (server):typically a sensor, a variable frequency drive, a power meter, or an I/O block — in more complex systems a PLC can even be configured to act as a slave to a higher-level master

A single RS-485 segment supports up to 32 slave devices, which is the practical ceiling for how many field instruments one Modbus RTU master can poll on a single wire pair before the network needs a repeater or a second segment.

Which Physical Layer Does Modbus RTU Use: RS-485 or RS-232?

Modbus RTU does not define its own wiring standard — it rides on top of whichever serial physical layer the hardware provides, and in practice that is almost always RS-232 or RS-485.

RS-232 was the original transport for Modbus RTU, but a 50-foot range and a hard one-to-one connection limit meant it only worked inside a single control cabinet. RS-485 solved both problems: its differential signaling drives a pair of wires rather than referencing a common ground, so environmental electrical noise affects both conductors equally and cancels out — which is why RS-485 tolerates the electrical interference of a factory floor far better than RS-232. That noise immunity, combined with the ability to daisy-chain up to 32 devices over 4,000 feet on a single wire pair, is why RS-485 is the physical layer nearly every multi-device Modbus RTU deployment uses today.

What’s Inside a Modbus RTU Message Frame?

A Modbus RTU frame packs a request or a response into four fields, transmitted as one continuous stream of binary data with no gaps in between. The four fields are:

1. Server/slave address (1 byte)— identifies which device on the line the message is for; only the matching device responds
2. Function code (1 byte)— tells the slave what to do: read a set of registers, write a coil, and so on
3. Data field (variable length)— carries the starting address and quantity for a read request, or the values to write for a write request
4. CRC (2 bytes)— a cyclic redundancy check that lets the receiver confirm the message arrived intact

Read the frame as a request’s lifecycle rather than four unrelated fields: the address gets the message to the right device, the function code tells that device what to do, the data field supplies the specifics, and the CRC is the last check before the slave acts on any of it. The CRC-16 calculation is the only error-detection layer Modbus RTU has — the protocol runs on raw serial wiring with no built-in retransmission the way TCP has, so if electrical noise flips even one bit anywhere in the frame, the CRC the receiver calculates will not match the CRC that was sent. The master then discards the response and re-polls. That is why a wiring or grounding fault on a Modbus RTU line tends to show up as intermittent timeouts on specific slave addresses rather than corrupted register values — the CRC catches the bad frame before it is ever acted on.

Modbus RTU is one of two encoding modes defined by the protocol; the other is Modbus ASCII, which represents the same fields as readable hexadecimal characters framed by a leading colon and a trailing carriage-return/line-feed pair, and checks errors with an LRC instead of a CRC. ASCII is easier to read on a terminal during troubleshooting, but its character-based encoding roughly doubles the bits needed per message, so RTU remains the faster and more common of the two on active networks.

What Are Modbus Function Codes?

The function code is the single byte in a Modbus RTU frame that tells the slave which operation to perform. The eight function codes below account for nearly all Modbus RTU traffic on a typical industrial network:

Coils and discrete inputs are single bits — on or off — while registers hold 16-bit values, which is why a temperature or pressure reading is always read through a holding or input register rather than a coil. Function codes above 127 (0x80) are reserved for exception responses: when a slave cannot process a request, it echoes the function code back with the high bit set and adds an error code the master can use to diagnose the failure, such as an illegal function or an invalid data address.

Summary So Far: Modbus RTU Wiring, Frames, and Function Codes

Modbus RTU connects one master to up to 247 addressed slave devices over a serial line, almost always RS-485 for anything beyond a single point-to-point link, because RS-485 daisy-chains up to 32 devices over distances up to 4,000 feet with strong noise immunity. Every message travels as a four-field frame — slave address, function code, data, and a CRC-16 checksum — and the CRC is what catches a corrupted frame before a bad value ever reaches the master. Eight function codes cover nearly all traffic: four read operations (coils, discrete inputs, holding registers, input registers) and four write operations (single coil, single register, multiple coils, multiple registers). With the wiring and frame mechanics established, the next question is how this serial protocol relates to its Ethernet counterpart, Modbus TCP/IP.

How Does Modbus RTU Compare to Modbus TCP/IP?

Modbus RTU and Modbus TCP/IP share the same command structure and function codes — the difference is the transport underneath them.

If your hardware only needs to reach across a control panel or a single production line, RS-485 wiring and Modbus RTU keep the bill of materials to two wires per device. If the network needs to span a facility, integrate with IT infrastructure, or be reachable over a router, Modbus TCP/IP’s Ethernet transport and star topology fit better — and because Modbus TCP/IP devices are addressable, a single network can support more nodes than the 247-address ceiling RTU imposes on one serial segment. Field instruments such as pressure transmitters and flow meters more often ship as Modbus RTU-only because RS-485 hardware is cheaper to embed than a full Ethernet stack, while PLCs and control-room software increasingly default to Modbus TCP/IP because they already sit on the plant’s Ethernet backbone.

What Is a Modbus Gateway?

A Modbus gateway translates Modbus RTU serial frames into Modbus TCP/IP packets, and back again, so devices on the two different transports exchange data without either side needing to support both protocols natively.

That translation function exists because of the same cost-versus-topology tradeoff covered above: a field instrument’s RS-485 interface is inexpensive to embed, but it cannot join an Ethernet network on its own, and a PLC or SCADA platform built around Modbus TCP/IP has no serial port to poll it directly. The gateway sits between the two, terminating the RS-485 line on one side and joining the Ethernet segment on the other — which lets a facility keep specifying low-cost RTU field devices while its control-room software talks Modbus TCP/IP exclusively. A gateway can act as a Modbus TCP/IP client, a Modbus RTU master, or both at once, depending on which side of the translation it needs to initiate.

Where Does Modbus RTU Fit in a Malaysian Plant Network?

On a typical Malaysian manufacturing line — semiconductor, food and beverage, or rubber and glove processing — Modbus RTU usually appears at the field layer. A PLC Malaysia polls a chain of industrial sensors Malaysia and one or more variable frequency drives over a single RS-485 run, and the readings then pass up to an HMI or SCADA screen. That RS-485 chain is what keeps wiring simple on a line with a dozen or more field devices — one twisted pair instead of a dedicated cable back to the control panel for every sensor and drive.

Where the network needs to reach a plant-wide SCADA system, or where a maintenance engineer wants to pull VFD status onto an Ethernet-connected dashboard, a gateway bridges that RS-485 segment to the facility’s Modbus TCP/IP or Ethernet backbone without rewiring the field devices themselves. Selecting the right VFD Malaysia or sensor model up front — one that already speaks Modbus RTU natively — is usually simpler than adding a protocol converter at every device later.

Modbus RTU FAQ

These are the questions that come up most often when engineers are speccing a new Modbus RTU installation or troubleshooting an existing one — device counts, gateway requirements, the ASCII/RTU distinction, and cabling.

How many devices can a Modbus RTU network support?

A single Modbus RTU network supports up to 247 slave addresses, though the RS-485 physical layer itself caps a single wire segment at 32 devices before a repeater is needed to extend the count further.

Do Modbus RTU and Modbus TCP/IP devices talk to each other directly?

Modbus RTU and Modbus TCP/IP devices do not talk to each other directly — a gateway is required to translate between the two protocols. A Modbus gateway converts Modbus RTU frames into Modbus TCP/IP packets and back, which is the standard way to bridge a serial field network to an Ethernet-based control system.

What’s the difference between Modbus RTU and Modbus ASCII?

Modbus RTU encodes data as raw binary, which is denser and faster to transmit; Modbus ASCII represents the same data as readable hexadecimal characters, which is slower but easier to read directly on a terminal during troubleshooting. RTU checks errors with a CRC; ASCII uses an LRC.

What cable does Modbus RTU use?

Most Modbus RTU deployments run over a shielded or unshielded twisted-pair cable for the RS-485 connection, terminated with resistors at both ends of the daisy chain to prevent signal reflections on longer runs.