Milesight UC100 Konverter für Modbus RTU mit RS485-Klemmen A und B auf einer Werkbank

What Is Modbus RTU? How the Modbus Protocol Works

An energy meter in the utility room has two terminals labeled A and B, and its datasheet says “Modbus RTU, 9600 baud, 8N1.” You want its readings in your monitoring system, but what does that mean? The short answer: Modbus RTU is a simple, open protocol that lets one device read or write the registers of other devices over a serial line, almost always RS485. Every message is a compact binary frame made of a device address, a function code, data and a checksum.

That simplicity is why Modbus RTU has been the common denominator in building automation, energy metering and industry for decades. Once you know who asks, who answers, what a frame looks like and which settings have to match, you can track down most commissioning problems on your own.

Milesight UC100 Modbus RTU converter with RS485 A and B terminals on a workbench
A Modbus RTU converter such as the Milesight UC100 polls devices through its RS485 A and B terminals and passes the values on to a higher-level system.

What is Modbus?

Modbus was developed by Modicon in 1979 for its own programmable logic controllers. Because it was openly documented and royalty-free, other manufacturers adopted it quickly. The Modbus Organization now maintains the specifications.

It helps to separate the layers. “Modbus” itself only defines what is exchanged: a simple data model and a handful of commands for reading and writing. How the bytes travel depends on the variant. The main ones are Modbus RTU (binary, serial), Modbus ASCII (text characters, serial) and Modbus TCP (over Ethernet and IP networks). RTU stands for Remote Terminal Unit and is by far the most common serial variant.

The data model has four areas. Coils are read/write bits, such as a relay output. Discrete inputs are read-only bits, such as a switch contact. Input registers are read-only 16-bit values, holding registers are 16-bit values you can read and write. Which information lives in which register is defined by the manufacturer’s register map, not by the protocol. One vendor’s energy meter might put active power at register 12, another at register 52 as a 32-bit float spread across two registers. Without the register map, the numbers on the wire mean nothing.

How does the Modbus RTU protocol work?

Modbus follows a strict request-response pattern. One device sends a request, exactly one addressed device replies, then the next request follows. Even an alarm only shows up when the controller reads the matching register. This cyclic querying is called polling.

Every request carries a function code: 03, for example, reads holding registers, and 06 writes a single register. It also includes a starting address and the number of values wanted. The device returns either the data or an exception response. In an exception, the function code’s highest bit is set, so 03 becomes 83, followed by a reason code, such as invalid register address. The full list of function codes is a topic of its own.

This sets a practical limit. At 9600 baud, transmitting a short request and its response takes almost 20 milliseconds, plus the gaps between frames and the device’s processing time. With twenty devices and several requests each, a polling cycle easily takes seconds. That is fine for meter readings, temperatures or operating states, but not for fast control loops.

What does a Modbus RTU frame look like?

A Modbus RTU frame has four parts: the slave ID (1 byte), the function code (1 byte), the data field (0 to 252 bytes) and the CRC checksum (2 bytes). A frame is at most 256 bytes and has no start or end character. Instead, silence separates frames: the line must stay quiet for at least 3.5 character times between frames, and inside a frame no more than 1.5 character times may pass between two characters. At 9600 baud, 3.5 characters are about 4 milliseconds. Above 19200 baud, the specification recommends fixed values of 1.75 milliseconds and 750 microseconds.

For example, the controller wants to read one holding register starting at address 0 from device 1, so it sends eight bytes, in hexadecimal: 01 03 00 00 00 01 84 0A. 01 is the slave ID, 03 is the function code “read holding registers,” 00 00 is the starting address, 00 01 is the number of registers and 84 0A is the CRC. The device answers with 01 03 02 00 ED 78 09: address, function code, the number of data bytes that follow (02), the register value 00 ED and another CRC. 00 ED is 237 in decimal. If the register map says “temperature, scale 0.1 °C,” that means 23.7 °C. The example is generic; your device’s address and scaling are in its documentation.

The CRC (cyclic redundancy check) is a 16-bit check value that the sender calculates over all preceding bytes and the receiver checks. If it does not match, the device silently discards the frame and does not answer. One quirk: the CRC is sent low byte first, while register values are sent high byte first. Values spanning two registers add another trap: some manufacturers send the high-order register first, others the low-order one. If a float comes out absurdly small or huge, word order is the first suspect.

Does Modbus RTU always use RS485?

No, but in practice it nearly always does. The Modbus serial line specification treats two-wire RS485 as the normal case and also allows four-wire RS485 and RS232. RS232 only works point to point over a few meters, for example from a laptop to a single device. RS485 is a bus: several devices share one twisted pair, and data travels as a voltage difference between the A and B wires, which makes it resistant to noise. Cable runs of up to about 1,000 meters are possible at typical baud rates.

Milesight UC100 for Modbus RTU with a green terminal block for power and RS485 A/B next to a twisted wire pair
RS485 uses a twisted wire pair on the A and B terminals, separate from the power terminals. The exact pinout is in each device’s manual.

A few rules keep the bus reliable. Wire the devices in a daisy chain, from one device to the next, not in a star. Put a termination resistor, often 120 ohms, at both ends of the line; some devices have one built in behind a DIP switch or jumper. A shielded twisted pair is the right cable. The most common startup mistake is still a simple one: A and B swapped, because manufacturers label the wires inconsistently. Some print D+ and D−, others reverse A and B. If a device stays silent, swapping the two wires is the quickest test.

Keep in mind that RS485 is only the electrical interface. A device with RS485 terminals does not automatically speak Modbus RTU; BACnet MS/TP, DMX and proprietary protocols run on the same hardware. When choosing a device, look for “Modbus RTU” in the specs and a published register map.

Modbus master and slave: who asks and who answers?

A Modbus RTU bus has exactly one master and up to 247 slaves. The master, such as a PLC, gateway, building management system or converter, sends every request. The slaves, such as meters, sensors or drives, reply only when addressed by their slave ID. Since 2020, the Modbus Organization has used the terms client and server instead: the client corresponds to the master and the server to the slave. Datasheets use both pairs.

The slave ID is a number from 1 to 247. Address 0 is reserved for broadcasts: a write command to all devices at once, to which none replies. Every device on the same bus needs its own unique slave ID. This is a classic source of trouble, because many devices ship with address 1. Two new energy meters on one bus then reply simultaneously, their signals collide, the CRC fails, and the master reports intermittent timeouts. Assign addresses one device at a time before connecting them together.

Also, two masters on one bus do not get along, because Modbus RTU cannot coordinate them. If you plug a laptop with a USB-to-RS485 adapter into a running bus and start a polling tool, its requests collide with the controller’s. Disconnect the real master briefly, or let the laptop listen only.

Modbus slave ID, baud rate and parity: what must match?

Four serial parameters must be identical on every device on the bus: baud rate, number of data bits, parity and number of stop bits. The slave ID, by contrast, must be unique, and the master must know it for every device.

The baud rate is the transmission speed in bits per second. According to the specification, devices must support 9600 and 19200 baud, with 19200 as the intended default. In practice, 9600 baud is common on meters, and many devices also offer 2400 to 115200 baud. In RTU mode, each character is 11 bits long: one start bit, eight data bits, one parity bit and one stop bit. The specification makes even parity the default. If no parity is used, a second stop bit is supposed to fill the 11 bits instead. Many manufacturers ship with 8N1 anyway, no parity and one stop bit, which works as long as every device matches.

Datasheets use shorthand such as 9600 8E1 or 19200 8N2. If even one parameter is off, the receiver misreads characters, the CRC check fails, and you simply get no reply. So when a device stays silent, check in this order: wiring and A/B polarity, slave ID, baud rate, parity and stop bits. Record every device’s address and parameters; it saves time when a unit is replaced later.

Modbus RTU vs Modbus ASCII: what is the difference?

Both variants use the same serial line, the same data model and the same function codes. They differ in how bytes are encoded. RTU sends each byte as an 8-bit binary value. ASCII splits each byte into two readable hexadecimal characters, so the byte 03 becomes the characters “0” and “3.” An ASCII frame starts with a colon, ends with carriage return and line feed, and uses a simpler LRC checksum instead of the CRC. The table compares both variants using the example request from above.

Feature Modbus RTU Modbus ASCII
Encoding binary, 8 bits per byte 2 hex characters per byte
Frame boundaries silence of 3.5 character times start “:”, end CR LF
Checksum CRC, 16-bit LRC, 8-bit
Data bits per character 8 7
Length of the example request 8 characters 17 characters
In the specification mandatory optional

This shows why RTU won: at the same baud rate, roughly twice as much data fits through the line, and the CRC catches transmission errors more reliably than the LRC. ASCII had one advantage that used to matter: up to one second may pass between two characters without invalidating the frame, which helped with modems and slow radio links. RTU and ASCII devices cannot share a bus; all must use the same mode.

Where is Modbus RTU used?

Wherever many simple devices need to deliver readings reliably. The biggest area is energy metering: many DIN-rail energy meters for submetering come in a Modbus version, as do power analyzers, solar inverters and battery storage systems. In buildings, heat pumps, ventilation units, room controllers and heat meters often speak Modbus RTU. In industry, variable frequency drives, flow meters and level sensors join the list.

A typical project: a building wants to collect readings from ten submeters centrally. The meters already share an RS485 line, but the meter room has no network jack. Here a converter acts as the master, polls the registers and forwards the values over another network. The Milesight UC100 is one such converter: it polls Modbus RTU devices over RS485, can read up to 64 registers and sends the values via LoRaWAN in the EU868 band to an IoT platform. It also supports a passthrough mode, simple IF-THEN rules on the device and local storage of readings during outages. The honest limit: LoRaWAN suits values that update every few minutes, not polling every second or control tasks.

Modbus RTU’s own limits are just as clear: high data rates, instant event reporting, and encryption or authentication. The protocol has no built-in security at all; anyone with access to the bus can read and write. Once data goes to the internet, the higher-level system must provide that protection.

Where can you buy Modbus RTU converters?

Before picking a converter or controller, start with the devices: do your meters and sensors really speak Modbus RTU, and is there a register map for each one? Next, check the interface. The converter should offer two-wire RS485 and support the baud rates, parity and stop bit settings your devices use. Count how many devices and registers you want to poll and compare that with the converter’s capacity. Look at the supported data types: 16-bit values, 32-bit values, floating-point numbers and a choice of word order. The target network matters too: LoRaWAN for scattered measurement points without network cabling, Ethernet or cellular for shorter polling intervals. Finally, check how the converter reports a failed request, so a stale value never shows up as a current reading. If you are looking for a converter for your Modbus RTU devices, you can find our models in the Modbus category.

Modbus RTU FAQ

Is Modbus RTU still relevant?

For reading meters, sensors and simple field devices, yes. The protocol is open, robust, well documented and built into countless devices that will stay in service for years. For high data rates, event-driven messages or encryption there are newer options, so Modbus RTU is often paired with a converter or gateway that forwards values into IP or wireless networks.

How many devices can you connect to a Modbus RTU bus?

You can address up to 247 slaves. Electrically, however, an RS485 segment without repeaters allows only 32 standard unit loads. Many modern transceivers draw only a quarter or an eighth of a unit load, so more devices fit on one segment. Repeaters can extend the bus further, but the limit of 247 addresses remains.

What is the difference between Modbus RTU and Modbus TCP?

Modbus RTU runs over a serial line such as RS485, while Modbus TCP runs over Ethernet and IP networks, on port 502 by default. TCP drops the CRC because the network layers already handle error detection. Instead, each message starts with a header containing a unit ID that takes the role of the slave ID. Gateways translate between the two variants.

Our latest news

Scroll to top