MODBUS RTU

A Little History

You might call the Modbus protocol the grandfather of industrial networking. It truly is as old as the hills and has the whiskers to prove it. In today’s age of internet connectivity and Web Services, Modbus’ unconnected message and simple request-response communication structure are almost quaint. The original protocol is nearly as old as the first Programmable Logic Controller, the Modicon 084, which was originally called a PC for Programmable Controller (PLC).

The RTU version is an open standard, meaning that manufacturers can build it into their equipment without having to pay royalties. It is the most pervasive communications protocol in industrial automation and is now the most commonly available means of connecting industrial electronic devices.

Many manufacturers across various industries widely use Modbus. Typically, it transmits data from control instrumentation to a logic controller or system for archiving. For instance, in building automation, it often communicates temperature and humidity data to a computer for long-term storage. The protocol is frequently used to connect a supervisory computer with a Remote Terminal Unit (RTU) in Supervisory Control And Data Acquisition (SCADA) systems.

Why Is Modbus so Popular?

Simplicity is the reason the Modbus protocol is so widespread. It also helped that Modbus was created by one of the largest PLC manufacturers at the time and made widely available as an open standard. It also requires very little in the way of processor code space or RAM. While this isn’t as important today, given the powerful processors and technology available to us, it 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.

Message checking is another reason why the protocol has been so popular. Cyclic Redundancy Checks (CRC) and Longitudinal Redundancy Checks (LRC) ensure that transmission errors are detected with 99% accuracy.

Modbus Communication

The RTU version uses a client/server technique to communicate between devices. Meaning, any application that utilizes the RTU protocol will have a client and at least one server. A client is typically a host supervisory computer running software that will communicate with one or more server devices.

Modbus enables client/server communication between devices connected through buses or networks. On the OSI Model, Modbus is positioned at Level 7. It is intended to be a request/reply protocol and delivers services specified by function codes. The function codes of the protocol are elements of its request/reply Protocol Data Unit.

In order to build the Modbus application data unit, the client must initiate a Modbus transaction. It is the function that informs the server as to which type of action to perform. The application protocol defines the format of a request initiated by a client. 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 exception responses. When the client sends a message to the server, it is the function code field that informs the server of what type of action to perform.

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.

Modbus RTU Data Representation

Like everything else about Modbus, the data representation is simple. In fact, data is represented more simply in Modbus than in any other industrial protocol you’ll ever find. The bit of least importance is sent and received first. All devices within the network must interpret each transmitted byte analogously in this manner.

There are no methods for automated recognition of baud rates. The same baud rate must be utilized by the server(s) and client connected to the bus. No specific baud rate is specified by the protocol: typical baud rates are 9600 or 19200.

There are only two data types in Modbus: coils and registers. Coils are simply single bits. The bits can be ON (1) or they can be OFF (0). Some coils represent inputs, meaning they contain the status of some physical discrete input. Or they represent outputs, meaning that they hold the state of some physical discrete output signal. Registers are simply 16-bit unsigned register data. Registers can have a value from 0 to 65535 (0 to FFFF hexadecimal). There is no representation for negative values, no representation for values greater than 65535 and no representation for real data like 200.125.

Registers are grouped into Input Registers and Holding Registers. Like Input Coils, Input Registers report the state of some external input as a value between 0 and 65535. The original intent of an Input Register was to reflect the value of some analog input. It is a digital representation of an analog signal like a voltage or a current. Most Modbus devices today are not I/O devices and Input Registers simply function identically to Holding Registers.

Holding Registers were originally designed as temporary program storage for devices like controllers. Today, Holding Registers function as data storage for devices.

Modbus RTU packets are only intended to send data; they do not have the capability to send parameters such as point name, resolution, units, etc. If the ability to send such parameters is needed, one should investigate a BACnet, EtherNet/IP or other modern protocols.

Modbus RTU Address Requirements and Station Identification

Standard RTU node addresses range from 1 to 255, with 0 reserved for broadcast messages and write-only functions. However, the 0 address is rarely used because it lacks confirmation of proper receipt at the server node. This limitation is less significant for RS-232, where only one node can be implemented anyway. RS-485 limits the number of nodes to 32, though some drivers will allow you to extend the amount.

Serial Modbus server devices are identified by a station number that precedes the general message structure. Typically, up to 32 stations are supported due to limitations imposed by most RS-485 serial drivers. There is no software limit on the number of stations that can be supported. Valid server addresses range from 1 to 255, with station number 0 reserved for broadcast messages processed by all servers.

Transport Layers

There are several standard transports used to move Modbus protocol messages: RS-232 and RS-485. You can use others, but these are the most common.

RS-485 is a successor to RS-232. It works in a similar fashion regarding the synchronizing bits that coordinate the transfer of bits from a sending station to a receiving station. There are, however, two defining characteristics that make RS-485 different from RS-232. The first is the ability to drive multiple destinations. RS-485 transmitters can electrically signal up to 32 destination devices. That makes RS-485 the preferred way to serially transport Modbus messages.

Another defining characteristic of RS-485 is its enhanced noise immunity. RS-485 does not use the electrical common as the reference for its electrical signal. Instead, RS-485 uses a pair of wires and drives a signal by setting a voltage potential across the pair. By doing that, any environmental electrical noise affects both wires equally and the potential across the two wires isn’t changed.

Modbus RTU Data Encoding

An encoding mechanism describes how bit patterns are created from the control and data values that are incorporated into the packet. Both the sender and the receiver must use the same encoding to correctly understand the contents of the data. There are two mechanisms for encoding Modbus messages: ASCII and RTU.

RTU encoding is the much more common encoding mechanism used on Modbus. RTU means that values are encoded in standard big-endian binary format. For 16-bit values, this 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. A 16-bit value like decimal 300 (12C hex) is encoded as 0000 0001 0010 1100, with the MSB (01) transmitted before the LSB (2C).

Modubus RTU Memory Map

The Difference Between Modbus RTU and Modbus TCP

The most basic difference between Modbus RTU and Modbus TCP (also known as Modbus IP, Modbus EtherNet, and Modbus TCP/IP) is that TCP runs on an Ethernet physical layer and RTU is a serial level protocol. TCP also uses a 6-byte header to allow routing.

An RTU client is a single client bus. It sends a message to an RTU server device and gets an answer. RTU is limited to a single client. Only one set of signals can be on the RS-485 link at any one time. Either the single RTU client is transmitting or one of the RTU client devices is transmitting.

With the introduction of TCP, everything was simplified and made easier. Controllers could much more efficiently use the bandwidth on Ethernet to be the client to hundreds of TCP devices. And, TCP allows for multiple clients. Where RS-485 had an electrical limitation of 32 devices, Ethernet is unlimited. Operating RAM is the only practical limitation. There is the ability for a network designer to use multiple clients if they so choose with Modbus TCP.

To use TCP (Ethernet), you need to involve an expensive switch. You can just daisy chain all the devices together with RTU (serial). Devices with old 8-bit processors and a tiny bit of memory can easily implement Modbus serial but you’ll need a more expensive platform to implement Ethernet.