An Introduction to

MODBUS RTU

A Brief History of the Modbus RTU Protocol

You might call the Modbus protocol the grandfather of industrial networking. It is nearly as old as the Modicon 084, widely regarded as the first commercially produced programmable logic controller (PLC). Originally, these devices were simply called programmable controllers (PCs), but the industry later adopted the term “PLC” to avoid confusion with personal computers.

Before the Modbus protocol arrived on the scene, it was nearly impossible for a central controller to talk to machines and devices from different manufacturers.

The Mobus Protocol

The Modbus protocol was developed by Modicon (now Schneider Electric) in 1979 and created a universal, open language that allowed PLCs to communicate with other devices, regardless of their manufacturer. It included two transmission modes, Modbus ASCII and Modbus RTU.

Modbus ASCII

The ASCII transmission mode encodes each 8-bit data byte as two hexadecimal ASCII characters (0–9, A–F). While this makes messages twice as large as Modbus RTU, it offers greater timing flexibility because it used specific “start” and “stop” characters to mark the beginning and end of a message. This made it a popular choice for older, less reliable communication links where message gaps might otherwise be mistaken for the end of a transmission.

Modbus RTU

The Modbus RTU format utilized a binary data format that quickly became the dominant industrial standard due to three major advantages:

• Faster Data Throughput: By sending 8-bit values in a single byte (rather than 2), Modbus RTU can transfer twice as much data as Modbus ASCII in the same amount of time.
• 99%+ Accurate Error Checking: Modbus RTU uses a Cyclic Redundancy Check (CRC) that ensures transmission errors are detected with greater than 99% accuracy versus ASCII’s Longitudinal Redundancy Check (LRCs), which was prone to electrical interference.
• Lower Message Overhead: Modbus RTU’s time-based framing uses dead time to signal the start and end of a message versus the start (colon) and stop (carriage returns) characters used by ASCII, removing “container” bytes that consume bandwidth.

Modbus Today

Despite the widespread adoption of industrial ethernet-based protocols like Modbus TCP, Modbus RTU is supported by all commercial SCADA, HMI, OPC server and data acquisition software available in the marketplace. This makes it very easy to integrate Modbus-compatible equipment into new or existing monitoring and control applications.

In addition to its simplicity, it also helped that Modbus RTU was created by one of the largest PLC manufacturers at the time and made widely available as an open standard.

Modbus RTU also requires very little in the way of processor code space or RAM, making it a popular choice for device manufacturers. All OEMs need is a serial port and a Modbus driver to make their devices ready-to-use within large, existing Modbus RTU networks.

While this isn’t as important today given the powerful processors and technology available to us, Modbus RTU was very important in the early years of industrial automation when processors used 8-bit technology and resources like RAM and ROM were extremely expensive and scarce.

Since 2004, the Modbus RTU protocol has been managed by the Modbus Organization, of which Real Time Automation is a proud member.

Modbus RTU Communication Model

Modbus RTU operates on a master/slave architecture, now called client/server. In this structure, the client (master) sends instructions to or requests data from one or more server (slave) devices. The servers sit passively, only speaking when addressed to acknowledge a task or provide the requested data.

Modbus RTU Node Addressing and Polling

In a client/server model, each server has a unique address or number that allows the client to send commands to specific devices. Messages sent by client devices include the server address, and only the corresponding server can respond.

Standard Modbus RTU node addresses range from 1 to 247, with “0” reserved for broadcast write messages and write-only functions to all servers on the network. In practice, the 0 address is rarely used because it lacks confirmation of proper receipt at the server node.

Since servers do not broadcast their information, a client must request, or poll, them for information. In an RS-485 network, the client sequentially polls servers one by one, waiting for a response before moving on to the next device. Only one device can talk on the RS-485 network at a time.

While RS-232 hardware is capable of full-duplex communication, the Modbus protocol still operates in a request-response fashion.

Common Modbus RTU Devices

• Client (Master): Typically a high-level controller such as a PLC or supervisory computer running SCADA or HMI software. Its job is to coordinate the network by polling servers for data or sending commands.
• Server (Slave): Typically peripheral devices such as sensors, variable frequency drives (VFDs), power meters, or I/O blocks. In some complex systems, a PLC can be configured to act as a server. In a Modbus RTU network, up to 32 server devices are supported due to limitations imposed by most RS-485 serial drivers.
• Gateways: In modern industrial networks, Modbus RTU gateways can act as either a client or a server, or both simultaneously. Its primary role is to act as a translator, allowing Modbus RTU devices to communicate with different protocols like Modbus TCP, EtherNet/IP, BACnet or PROFINET.

Modbus RTU Physical Layers

The number of devices allowed on a Modbus RTU network, how far communication can travel and at what speed is determined by the serial physical layer. While other interfaces exist, the overwhelming majority of Modbus RTU applications rely on either RS-232 or RS-485.

RS-232

RS-232 is designed for point-to-point connections over a short distance (50 ft) at speeds up to 115.2 kbps (115,200 bps), though often lower to ensure stability. In an RS-232 network, a single client communicates with exactly one server device.

RS-485

RS-485 is a successor to RS-232. It works in a similar fashion, however, there are three defining characteristics that make it different from RS-232.

• Multi-Drop Networking: RS-485 clients can electrically signal up to 32 server devices via a daisy chain over a single pair of wires. This makes it the industry standard way to serially transport Modbus messages. On an RS-485 daisy chain network, termination is required on the two ends of the network.
• Enhanced Noise Immunity: RS-485 does not use a common ground wire as the reference for its electrical signal. Instead, it uses differential signaling where a signal is driven by voltage over a pair of wires. Because any environmental electrical noise affects both wires equally, the voltage potential across the two wires remains unchanged, allowing the signal to remain intact even in high-interference factory settings.
• Distance and Speed: RS-485 can communicate over distances up to 4,000 ft. While the hardware can support up to 10 Mbps at very short distances, Modbus RTU applications typically operate between 9,600 bps and 115,200 bps.

RS-485 is the preferred way to serially transport Modbus RTU messages.

Modbus RTU Data Representation

Modbus RTU data is organized into two primary formats: coils and registers.

Coils

Coils are simply single bits. The bits can be ON (1) or OFF (0). Some coils represent inputs, meaning they contain the status of some physical discrete input. Others may represent outputs, meaning that they hold the state of some physical discrete output signal.

Registers

Registers are simply 16-bit memory locations and can have a value from 0 to 65535 (0 to FFFF hexadecimal) if unsigned, or -32768 to 32767 if signed. There is no representation for real data like 200.125. To handle “real” data like decimals or larger numbers, modern systems simply combine two consecutive 16-bit registers to create a 32-bit Floating Point or Long Integer.

Registers are grouped into two types based on their function and access permissions: input registers and holding registers.

Input Registers

Input Registers (and their single-bit equivalents, Discrete Inputs) are read-only. A client can request their values but cannot write to them.

Like Discrete Inputs, Input Registers report the state of some external input as a value between 0 and 65535, if unsigned. The original intent of an Input Register was to reflect the value of some analog input — a digital representation of an analog signal like a voltage or a current.

Holding Registers

Holding Registers (and their single-bit equivalents, Coils) are read/write. A client can both request their current values and write new values to them.

Holding Registers were originally designed as temporary program storage for devices like controllers, while Coils represented physical discrete outputs that could be turned on or off. Today, both serve as the primary means of sending commands and configuration data to a Modbus device.

In practice, since most modern Modbus devices are not pure I/O devices, the distinction between Input Registers and Holding Registers has blurred. Many devices expose all of their data through Holding Registers alone. However, understanding the read-only versus read/write distinction remains important when working from a device’s Modbus map.

Modbus RTU Frame Structure

A Modbus RTU frame is a continuous stream of binary data that relies on precise timing and a specific sequence of information to ensure the message is understood. In addition to a “start” and “stop” indicator – either specific ASCII characters (Modbus ASCII) or dead time intervals (Modbus RTU) – a standard Modbus RTU frame has four main components:

• A Server Address that identifies the target device
• A Function Code that tells the server what to do such as read or write data
• A Data Field that contains the payload of the message, defining number of registers to read (starting at a specified number) and the data to be written
• A Cyclic Redundancy Check (CRC) field that verifies all data is sent

Server Addresses

A server address is a unique identifier (1 – 247) assigned to each device in the Modbus RTU network that allows clients to directly communicate with it. Only the server with this address will respond, while all others will ignore the message.

Function Codes

Function codes tell servers which coil or register to access and whether to read or write to it. The Function Code field is encoded into one byte, with valid codes ranging from 1 to 255. Codes from 128 to 255 are reserved for the exception responses.

Each function code corresponds to specific operations:

• Read function codes allow clients to request data from servers. Common read function codes include:
  • 01 – Read coils
  • 02 – Read discrete inputs
  • 03 – Read holding registers
  • 04 – Read input registers
• Write function codes allow clients to send data to servers. Common write function codes include:
  • 05 – Write single coil
  • 06 – Write single holding register
  • 15 – Write multiple coils
  • 16 – Write multiple holding registers

To define multiple actions, some functions will have sub-function codes added to them. For instance, the client can read the On/Off states of a group of discreet outputs or inputs. It could also read/write the data contents of a group of registers.

When the client receives the server response, the function code field is used by the server to indicate either an error-free response or an exception response. The server echoes to the request of the initial function code in the case of a normal response.

Data Field

The data field is the payload of the message. It contains the specific details required to execute a Function Code. In a standard client request, the data field is comprised of two primary components:

• A starting address which identifies the first coil or register the client wants to access
• A quantity that identifies the total number of consecutive coils or registers to be processed

For write commands, the data field expands to include the value to be written to the server’s memory.

The structure of the data field changes based on the direction of the communication and the specific task:

• Client commands specify the starting address and the quantity of coils or registers to be retrieved or written. Write commands also contain the values to be sent to the server.
• Server responses contain the incoming byte count followed by the actual values requested or confirmation that the data was written successfully.

Starting Address

Starting addresses identify the first coil or register the client wants to access. There is a critical distinction between how the starting address is identified in device documentation versus how it is addressed in the Modbus RTU message frame.

Register Numbers (Documentation)

Documentation uses human-readable register numbers to categorize data. The first digit acts as a prefix to identify the data table:

• 0xxxxx: Coils (000001 – 065536)
• 1xxxxx: Discrete inputs (100001 – 165536)
• 3xxxxx: Input registers (300001 – 365536)
• 4xxxxx: Holding registers (400001 – 465536)

Data Addresses (Modbus Protocol)

The Modbus protocol itself relies on the Function Code to select the correct table and a 16-bit data address to find the specific location within that table. The addresses are sent in the message as hexadecimal values.

Offsets

An offset is used to mathematically bridge device documentation and the protocol encoding. Because Modbus addresses start at 0, the first register in any table is always addressed as 0000 in the message frame. To translate a register number to a data address, subtract the table’s starting offset.

• Coil offset – 000001
• Discrete input offset – 100001
• Input register offset – 300001
• Holding register offset – 400001

Subtracting these offsets effectively removes the table prefix and shirts the range to start at 0. For example, if you want to read holding register 400108:

• The prefix “4” tells the client to use Function Code 03 (Read Holding Register)
• Subtract the offset to get the protocol address: 400108 – 400001 = 107
• The data address sent in the message frame is 107, or 0x006B in Hex

Quantities

The quantity value makes the client/server model efficient by specifying the number of locations to be read or written in a single request. For example, rather than sending five separate requests for five different values, a client can request a starting address with a quantity of five to retrieve all data in a single transmission.

Cyclic Redundancy Check (CRC)

Modbus RTU uses a mathematical algorithm called a cyclic redundancy check (CRC), specifically the CRC-16 algorithm, to detect errors in data transmission. It calculates a checksum value derived from the message content and appends it to message. The client performs the same check and compares the value to the one received.

Matching values means that data was transmitted correctly. In the event of failure, the client can request retransmission. This method ensures errors are detected with greater than 99% accuracy.

Modbus Maps

While Modbus is a universal, open protocol, the way data is organized within a device is not. Unlike modern protocols, Modbus RTU is not self-describing, meaning networks cannot discover what data a Modbus device has. Device manufacturers publish Modbus maps, or register lists, which are unique to specific devices or product families.

Real Time Automation has a library of over 400 Modbus device templates from over 70 vendors to automatically map registers to PLC tags, including Modbus templates for Allen-Bradley PLCs and Modbus to BACnet data mapping templates.

Modbus RTU Data Encoding

Encoding describes how data values are converted into bit patterns for transmission. For a client and server to communicate, they must use the same encoding language. There are two mechanisms for encoding Modbus messages, ASCII and RTU, of which RTU is the most common.

In Modbus RTU, each transmitted byte is coded as an 8-bit binary value (Hex 0-9 and A-F). This byte is wrapped in an 11-bit character frame to ensure the hardware can synchronize the data.

As shown in the diagram, the Least Significant Bit (LSB) is sent and received first. While this bit-level “Little-Endian” order is handled automatically by the hardware (UART), it is a fundamental rule of the protocol.

Big-Endian Binary Format (Byte Level)

Modbus RTU uses a Big-Endian format for its 16-bit registers. This means that when a numerical value is broken down into two bytes for transmission, the encoding places the Most Significant Byte (MSB) before the Least Significant Byte (LSB).

For example, an 8-bit value like decimal 41 (29 hex) is encoded as 0010 1001. Since this fits into a single 8-bit byte, it is transmitted as a single unit.

When a number is larger than 255, like a 16-bit value of decimal 300 (012C hex), it is encoded as 0000 0001 0010 1100. Following the big-endian format, the MSB (01 hex, representing the first 256) is transmitted before the LSB (2C hex, representing the remaining 44).

Modbus RTU FAQs