Modbus RTU explained: frames, registers and function codes

Modbus RTU is the serial form of Modbus, a protocol that Modicon published in 1979 for its PLCs and that the rest of the industry adopted because it was simple and open. One device, the master, sends a short binary request to one other device by its address; that device answers; nothing else on the line speaks. The requests read and write numbered 16-bit registers and single bits, and every frame ends with a CRC so a corrupted message is thrown away. Energy meters, flow meters, variable speed drives, temperature controllers, solar inverters and PLCs all speak it. This article explains how a network is organized, what a frame looks like byte by byte, how the data is laid out, which function codes matter, how RTU differs from Modbus TCP, and what to check when connecting it to an IoT system.

Modbus RTU, Modbus ASCII and Modbus TCP

Modbus is now maintained by the Modbus Organization, which publishes the specifications free of charge. Two documents matter: the application protocol specification, which defines the data model and the function codes, and the serial line specification, which defines how messages are framed on a serial cable. The same function codes are used in three framings:

• Modbus RTU sends each message as raw binary bytes, separated by gaps of silence, with a 16-bit CRC at the end. It is compact and by far the most common serial form.
• Modbus ASCII sends the same content as readable hexadecimal characters, starting with a colon and ending with a carriage return and line feed, checked by a simpler LRC. It takes about twice as long to send and is rare in new equipment.
• Modbus TCP carries the same requests inside TCP/IP packets over Ethernet, usually on port 502, with a short header in place of the address byte and no CRC, because TCP already checks the data.

Modbus RTU says nothing about voltages or cable. It most often runs over RS-485, which lets one cable connect many devices over long distances, and occasionally over RS-232 for a single device. The RS-485 article covers the wiring, termination and biasing that most Modbus RTU faults turn out to be.

How a Modbus RTU network works

A serial Modbus network has exactly one master and up to 247 slaves. The current specifications call them the client and the servers; equipment manuals and software still mostly say master and slave, and this article uses those terms because that is what the configuration screens show.

Each slave has an address from 1 to 247, set on the device by switches, a front panel or software, and each address must be unique on the line. Address 0 is a broadcast: every slave acts on it and none replies, so it is only used for writes. Addresses 248 to 255 are reserved.

The master does all the talking. It sends a request to one address, waits for the answer or for a timeout, then moves on to the next request. A slave never sends anything unprompted, so there is no way for a device to report an alarm the moment it happens; the master finds out on its next poll, a trade-off the SCADA guide compares with report by exception. This polling model is what makes the protocol predictable and easy to implement, and it is also why a busy network feels slow.

The Modbus RTU frame

Every RTU message has four parts:

1. Address, one byte: which slave the request is for, or which slave is answering.
2. Function code, one byte: what to do, such as read holding registers.
3. Data, up to 252 bytes: the details of the request, or the values in the answer.
4. CRC, two bytes: a 16-bit cyclic redundancy check over everything before it, sent low byte first.

The whole frame is at most 256 bytes. There is no start byte and no length field. Instead, frames are separated by silence: the line must be quiet for at least 3.5 character times before a frame starts and after it ends, and inside a frame the gap between two bytes must not exceed 1.5 character times. A receiver that sees a long enough silence treats the next byte as the start of a new message. Above 19,200 baud the specification fixes these gaps at 1.75 milliseconds and 750 microseconds instead of scaling them with the character time.

Each byte is sent as 11 bits: a start bit, eight data bits, a parity bit and a stop bit. The specification’s default is 19,200 baud with even parity, and every device must also support 9,600 baud. When no parity is used, the specification calls for two stop bits so the character stays 11 bits long; many devices ship set to 8N1, eight data bits, no parity and one stop bit, and the only rule that really matters is that every device on the line uses the same setting.

Here is a real request and its answer, decoded. The master asks device 1 for two holding registers starting at address 0, and the device replies with the values 230 and 100.

Note the byte order. Register addresses and values are sent high byte first, but the CRC is sent low byte first. Hand-written drivers often get the CRC backwards, and the device then ignores every request without saying why, because a slave that sees a bad CRC discards the frame silently.

The data model: coils, discrete inputs and registers

Modbus describes every device as four tables of numbered items. What each item means is entirely up to the manufacturer, who publishes it in a register map: register 0 might be voltage in tenths of a volt on one meter and a serial number on another.

The last column causes more confusion than anything else in Modbus. The leading digit is a convention from old Modicon documentation that says which table an item is in, and the numbering starts at 1. On the wire there is no leading digit and numbering starts at 0. So “register 40001” in a manual means holding register address 0, sent with function code 03 and a start address of 00 00, and “40108” means address 107. Some manuals use six digits, such as 400001, to fit more than 9,999 registers; some give the zero-based address directly; some give it in hexadecimal. When a value comes back as the reading next to the one you wanted, the map and the software disagree about which convention is in use, and the fix is to shift the start address by one.

Many devices also do not keep the tables separate, and serve the same values whether you read them as input registers or holding registers. Others put everything in holding registers. Follow the register map rather than the table descriptions above.

Function codes and exception responses

The function code says which table to touch and whether to read or write. These eight cover nearly all field use:

When a slave receives a valid frame it cannot carry out, it replies with an exception response: the function code with its top bit set, so 03 becomes 0x83, followed by one byte saying why. Code 01 means the device does not support that function, 02 means the address is not valid on that device, 03 means a value in the request is not allowed, and 04 means the device failed while trying. An exception is good news while debugging, because it proves the wiring, the baud rate, the address and the CRC are all correct; only the request is wrong. For example, 01 83 02 C0 F1 from device 1 means “illegal data address”: the register you asked for does not exist on that device.

Data types: getting real numbers out of 16-bit registers

A register holds 16 bits and nothing else. Everything bigger, smaller or more precise than an integer from 0 to 65,535 is an arrangement the manufacturer chose and documents in the register map.

Signed values use the same 16 bits read as a two’s complement number, so 65,535 might mean minus 1. Scaled values store a decimal as an integer: a temperature of 21.5 degrees sent as 215 with a scale of 0.1. 32-bit integers and floating-point numbers take two consecutive registers. Modbus itself does not define which register holds the high half, and manufacturers differ, so the same pair of registers can decode to a sensible reading or to nonsense depending on word order. Gateway software usually offers the options as big-endian, little-endian and their byte-swapped versions; reading one value whose real figure you know, such as the voltage on a meter you can also read on its display, settles which one the device uses. Strings, where a device offers them, are packed two characters per register.

Modbus RTU vs Modbus TCP

Modbus TCP keeps the function codes and data model and changes the framing. The address byte and CRC are replaced by a seven-byte header that carries a transaction number, so a client can match answers to requests, a length field, and a unit identifier. Devices are found by IP address, several clients can talk to one server, and requests to different devices can be in flight at once.

A Modbus gateway converts between the two. It accepts Modbus TCP requests on Ethernet, uses the unit identifier as the RTU slave address, forwards the request onto its RS-485 port and returns the answer. That is a common way to bring a cabinet of serial meters onto a plant network. It does not make the serial side any faster: every request still waits its turn on the bus.

Speed and timing in practice

At 9,600 baud, one 11-bit character takes about 1.15 milliseconds. The request in the example above is 8 bytes and a response carrying ten registers is 25 bytes, so one such exchange spends around 40 milliseconds on the wire, plus the silent gaps, plus however long the device takes to prepare its answer, which ranges from a few milliseconds to more than a hundred on some meters. Polling 30 devices for a block of registers each therefore takes a second or more per round, and a device that does not answer costs the full timeout every time.

That shapes how a system should poll. Read contiguous blocks of registers in one request rather than one register per request. Poll fast-changing values often and slow ones, such as energy totals and configuration, rarely. Set the timeout to suit the slowest device rather than the default. And if a round takes too long, raise the baud rate where every device supports it, or split the devices across two buses with their own masters.

Security

Modbus RTU has no authentication and no encryption. Any device that can transmit on the bus can read or write any register on any slave, including setpoints and run commands. On a serial bus that is contained by physical access to the cable. The exposure grows when a gateway bridges the bus to a network, because anything that can reach the gateway’s Modbus TCP port can then do the same. The Modbus Organization has published a secure variant of Modbus TCP that adds TLS, but serial devices do not support it. Keep gateways on a segmented plant network, give upstream systems read-only access where the gateway allows it, and leave writes to the control system that owns the process, as discussed in the article on what a PLC is.

Getting Modbus RTU data into an IoT system

An edge gateway with an RS-485 port is the usual bridge. It acts as the bus master, polls each device for the registers on a list, decodes them using the register map into named values with units, and publishes them, usually over MQTT to a broker or through an OPC UA server. The overview of an industrial IoT system shows where that gateway sits, and the OPC UA and MQTT article covers the layer above. If a PLC already masters the same bus, read the values from the PLC instead of adding a second master; two masters on one RTU line corrupt each other’s messages.

Before wiring anything in, collect for each device its slave address, baud rate, parity and stop bits, the register map for the exact model and firmware, and a list of the registers you need with their table, data type, scale and word order. For the first connection, read one register whose value you can confirm on the device’s display. Once that matches, the rest of the list is configuration; until it does, the problem is in the wiring or the settings, and the RS-485 troubleshooting checklist is the place to start.