Modbus RTU is an open serial protocol derived from the master/slave architecture (now client/server) originally developed by Modicon (now Schneider Electric). It is a widely accepted serial level protocol due to its ease of use and reliability. Modbus RTU is widely used within Building Management Systems (BMS) and Industrial Automation Systems (IAS).
Modbus RTU messages are a simple 16-bit structure with a Cyclic-Redundant Checksum. The simplicity of these messages ensures reliability. Due to this simplicity, the basic 16-bit Modbus RTU register structure can be used to pack in floating point, tables, ASCII text, queues, and other unrelated data.
This protocol primarily uses an RS-232 or RS-485 serial interfaces for communications and is supported by every commercial SCADA, HMI, OPC server and data acquisition software program in the marketplace. This makes it very easy to integrate Modbus-compatible equipment into new or existing monitoring and control applications.
Subscribe to our Automation Education email series to learn the ins and outs of Modbus and the top industrial protocols in a byte-size weekly format!
The Everyman’s Guide to Modbus
Want to get chapters 1 – 3 free? Download now
RTA is a proud member of the Modbus Organization. For more information, visit their site: modbus.org
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 almost as old as the first Programmable Logic Controller, the Modicon 084, which in those days was 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.
Modbus is used widely by many manufacturers throughout many industries. It is typically used to transmit data from control instrumentation to a logic controller or a system for archiving data. In building automation, for example, temperature and humidity are often communicated to a computer for long-term storage. The protocol is often used to connect a supervisory computer with a Remote Terminal Unit (RTU) in Supervisory Control
And Data Acquisition (SCADA) systems.
Simplicity is the reason Modbus is so widespread. It also didn’t hurt that Modbus was created by one of the largest PLC manufacturers at that time and made it widely available 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. The Cyclic-Redundant Checksums and Longitudinal Redundancy Checks mean that transmission errors are checked to 99% accuracy.
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 format of a request initiated by a client is established by the application protocol. The function code field is then coded into one byte. Only codes within the range of 1 through 255 are considered valid, with 128-255 being 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.
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.
Standard RTU node addresses are 1-255, with 0 being reserved for broadcast messages and write only. However, the 0 address is rarely used since there is no confirmation that the message was properly received at the server node. This doesn’t have much effect if your physical layer is RS-232 as 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. Generally, up to 32 stations are supported as that is the limit imposed by most RS-485 serial drivers. There is no software limit to the number of stations that could be supported. Valid server addresses are assigned in the range of 1 to 255 with station number 0 reserved for broadcast messages, messages processed by all servers.
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.
The other defining characteristic of RS-485 is 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.
An encoding mechanism describes how bit patterns are formed from the control and data values that are encoded 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 simply means that values are encoded as standard big-endian binary. That means that in the case of 16-bit values, the Most Significant Byte (MSB) is encoded prior to the Least Significant byte (LSB). An 8-bit value like decimal 41 (29 hex) is encoded simply as 0010 1001. Whereas a 16-bit value like decimal 300 (12C hex) is encoded as 0000 0001 0010 1100. The MSB of 01 is encoded and transmitted prior to the LSB of 2C.
|Modbus RTU Data Type||Common Name||Starting Address|
|Modbus Coils||Bits, binary values, flags||00001|
|Digital Inputs||Binary inputs||10001|
|Analog Inputs||Binary inputs||30001|
|Modbus Registers||Analog values, variables||40001|
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.
You need to get an expensive switch involved with TCP (Ethernet). 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.