What is
MODBUS?
The Modbus communications protocol is the networking granddaddy of the industry. Modbus has stood the test of time and is still being used in a wide range of applications, including industrial automation, process control, building automation, transportation, energy and remote monitoring.
You can find virtually every type of sensor and controller device incorporating Modbus networking, including programmable logic controllers (PLCs), process controllers, process instruments, process sensors, PID controllers, motor drives, energy meters, Supervisory Control and Data Acquisition (SCADA) systems, programmable automation controllers (PACs), discrete sensors, valves and many other embedded devices.
In simple terms, Modbus is a method used for transmitting data over serial lines between electronic devices. Originally intended for communications between programmable logic controllers (PLCs) and computers, it has become a de facto standard communication protocol for connecting a wide range of industrial electronic devices.
Modbus is an extremely compact and flexible protocol that continues to prove it can be adapted for use in a wide range of applications and media. It is popular for remote applications that communicate over almost any means, including wired and cellular telephone, licensed and unlicensed radios and satellite.
Modbus resources
Want to learn more about Modbus?
Subscribe to our Automation Education email series to learn the ins and outs of Modbus and other top industrial protocols in byte-size nuggets bi-weekly to your inbox!
Organizations/Memberships
RTA is a proud member of the Modbus Organization. For more information, visit their site: modbus.org
History of Modbus
The Modbus serial communication protocol was developed by Modicon (now Schneider Electric) and published in 1979 for use with its Programmable Logic Controllers (PLCs). The early roots of Modicon started in 1968 with a core group of engineers led by Dick Morley that invented the first programmable logic controller.
Modbus 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 the most commonly available means of connecting industrial electronic devices.
Modbus introduced the concept of data on the factory floor. Modbus made it possible to connect an entire group of devices using only two wires on the controller. That alone saved a massive investment in wire, labor and installation time. Instead of miles and miles of wire connecting hundreds of devices, a simple two-wire pair could be daisy-chained from one device to the next to the next. It was revolutionary for its time.
Modbus has found its way into hundreds of thousands—if not millions—of devices. You can find it in everything from valve controllers and motor drives to HMIs and water filtration systems. It would be difficult indeed to name a product category in industrial automation or building automation that doesn’t use Modbus.
Why Modbus Has Flourished
Why did Modbus have such an impact on the Industrial Automation industry that it still survives to this day as one of the leading industrial networks of the 21st century? Here are the three primary keys to its success:
- Modbus Is an Open Standard: Modicon did not keep the standard proprietary. They released it as a non-proprietary standard and welcomed developers, even competitors, to implement it. They rightly assumed that it would be best for everyone, including them if Modbus became successful in the marketplace. Because of this thinking, Modbus became the first widely accepted Fieldbus standard.
- Modbus Uses Standard Transports: The transport layer for Modbus RTU commands is also simple to understand. Modbus RTU uses RS-232, RS-422, and RS-485. Modbus TCP/IP uses Ethernet.
- Modbus Uses a Simple Protocol: Modbus is very easy to understand. Its primary purpose is to simply move data between an RTU client device and an RTU server device. There are only two kinds of data to move: registers and coils. Registers are 16-bit unsigned integers. Coils are single bits. The simplicity of Modbus has also led to many companies expanding the message structure, data representation and transports.
Another reason Modbus was so successful was that it could be readily understood by non-programmers. Simplicity has led to an incredible amount of activity and propagation of Modbus into many different industries around the world.
Modbus Protocol Message Structure
The standard structure of a Modbus request and a Modbus response is identical for all forms of Modbus messages. That structure begins with a byte indicating the function the server should perform and ends with the last byte of data in the message.
The general components of a Modbus message follow:
| Function Code (FC) | The Function Code identifies the request to the Modbus server. There are a large number of possible message requests, but about eight that are commonly used. |
| Starting Address | The Starting Address is the index into the data area in the Modbus device. If the function code targets coils, this field specifies the index the coils (bits) of the coil address space. If the function applies to registers, this field specifies the index into the registers for that part of the address space. Note: Modbus address spaces are one based—the first register or coil is one. The Modbus protocol is zero-based. The first register or coil is zero. The address on the wire is always one less than the address in the Modbus data request. |
| Bit Length | The number of bits to read or write. |
| Word Count | The number of registers to read or write. |
| Byte Count | The number of data bytes of data included in the message request or response. |
| Response Code | This byte indicates the successful completion of the message request. It is identical to the original message request. |
| Exception Response (FC) | An exception response is indicated by combining the Response Code of the original Modbus Function Request with 80 hexadecimal. For example, a Modbus exception response to Function Code 3 is 83 hexadecimal. A single data byte value with the Modbus Error Code always follows the exception response byte. |
Modbus Data Representation
Like everything else about Modbus, the data representation is simple. There are only two data types in Modbus: coils and registers.
- Coils: 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: 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. Any application can organize and treat register data in any way it may want, but there is no way for any other Modbus device to automatically know what that representation is. A Modbus application that reads registers from a Modbus server device must have some prior knowledge of how particular registers are treated to process them correctly.
Modbus Transport Layers
How we move a message from one station to another is called the Transport Layer. Now, the Transport Layer can be complicated. You can use any transport you want. The Modbus message sequence is a Modbus message sequence regardless of whether you send it on Ethernet, RS232, or RS485. The transport is simply the mechanism you use to move the message from the sender to the receiver.
There are several standard transports used to move Modbus protocol messages: RS-232, RS-485, and Ethernet. You can use others, but these are the common ones.
RS-232
RS232 stands for Recommend Standard number 232. This is the old serial port that we used to find on computers several (okay, more than several) years ago. The full RS-232C standard specifies a 25-pin “D” connector. Now, if we find a serial connector, it uses the 9-pin D type connectors often referenced as a DB9.
RS-485
RS485 is a successor to RS-232. It works in a similar fashion regarding the synchronizing bits that synchronize 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 doesn’t change.
Ethernet
Modbus communications over Ethernet is known as Modbus TCP. Modbus took a huge step forward when it began using Ethernet as a transport protocol. Now with the increased speed of Ethernet, there is much more bandwidth for sending many more messages. You can connect thousands of devices in a Modbus TCP network, not just the 32 devices like in RS-485, and you can also support multiple Clients, not just a single Client.
Modbus Certifications
Most trade organizations specify a protocol test that must be successfully executed to get a certification statement or logo that a device vendor can use to indicate that the device conforms to the specification of the technology. For many years, there was no conformance test for Modbus products. A developer would create something, test it in some fashion and ship it. It was left to the user to figure out what worked and what didn’t work.
The Modbus Organization eventually remedied this problem. They not only established a test procedure, but they also contracted with the University of Michigan to implement it. There are now two options for certification of your Modbus server Modbus TCP server device.
- You can self-certify. That means that you download the test and execute it yourself. You pledge that your products meet the minimum functionality of a Modbus device as specified by the test.
- You can purchase testing from the Modbus Organization. The test lab at the University of Michigan will perform the test for you and validate your device. That, of course, is going to cost you some cash and some time. But you do get a second set of eyes and third-party testing.
Another thing to note about testing Modbus is that only your Slave or Server device can be tested. There is no test for client devices. The reasoning behind this is that it is much more difficult to validate the operation of the client side. Besides that, only Modbus TCP server devices now can be tested. The Modbus Conformance test is designed for Modbus TCP Ethernet devices, not Modbus serial devices.
Modbus Security
If you are new to Modbus or new to security, you already know everything there is to know about Modbus security: nothing. There is no security in Modbus, Modbus RTU or Modbus TCP. It doesn’t exist.
Many people think that just because they have their Modbus controller behind a firewall they’re protected. True, the controller is not on the Internet, but that doesn’t mean it’s protected. Moving behind the firewall merely moves your vulnerability up one level. Now, any server that’s on the other side of the firewall authorized to access that controller is vulnerable.
Modbus was not built for security. It has no passwords, no authorizations, no facility to pass certificates or anything else that would be required if you were building it today. Strangely enough, the Modbus RTU protocol is seeing continued use due to security concerns.
The Difference Between Modbus RTU and Modbus TCP
The most basic difference between Modbus RTU and Modbus TCP (also known as Modbus IP or Modbus TCP/IP) is that Modbus TCP runs on an Ethernet physical layer and Modbus RTU is a serial level protocol. Modbus TCP also uses a 6-byte header to allow routing and removes the CRC.
A Modbus RTU client is a single client bus. It sends a message to an RTU server device and gets an answer. Modbus 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 Modbus TCP, this limit was removed. With Modbus TCP, controllers can much more efficiently use the bandwidth on Ethernet to be the client to hundreds of Modbus TCP devices. Where RS-485 had an electrical limitation of 32 devices, Ethernet is unlimited. Operating RAM is the only practical limitation. With Modbus TCP, a network designer can use multiple clients if they so choose. Modbus TCP allows for multiple clients.
With Modbus TCP, you need to get network switches involved. With Modbus RTU (serial), you can just daisy chain all the devices together. 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.
The Difference Between Modbus RTU and Modbus ASCII
There are two basic transmission modes found in serial Modbus connections, ASCII and RTU. These transmission modes determine the way in which the Modbus messages are coded. In ASCII format, the messages are readable, whereas in RTU the messages are in binary coding and cannot be read while monitoring. The trade-off is that the RTU messages are smaller, allowing for more data exchange in the same time span. One should be aware that all nodes within one Modbus network must be of the same transmission mode, meaning Modbus ASCII cannot communicate with Modbus RTU and vice versa.
In Modbus ASCII, messages are encoded with hexadecimal value, represented with comprehensive ASCII characters. The characters used for this encoding are 0…9 and A…F. For every byte of information, two communication-bytes are used because every communication-byte can only define 4 bits in the hexadecimal system. Modbus RTU, however, exchanges data in a binary format where each byte of data is coded in one communication-byte.
The Modbus messages on a serial connection are not broadcast in plain format. They are constructed in a way that allows receivers an easy way to detect the beginning and end of a message. The characters start and end a frame when in ASCII mode. To flag the start of a message, a colon ‘:’ is used, and each message is ended with a Carriage Return/Line Feed combination.
Modbus RTU uses a different method. In RTU, framing is constructed by measuring gaps of silence on the communication line. Before each message, there must be a minimum gap of 3.5 characters. To prepare for new messages, the receiver clears the buffer when a gap of 1.5 characters is detected. One of the main differences between Modbus ASCII and Modbus RTU is that ASCII allows gaps between the bytes of a message with a maximum length of 1 second. With Modbus RTU, continuous streams of messages must be sent.
Modbus Ethernet or Modbus Over Ethernet
While Modbus TCP/IP is a fully formed technical specification for the vast adoption of Modbus, the loose certification standard and early movers to Ethernet led to a number of non-standard implementations that are still present in the market. If you see Modbus Ethernet or Modbus over Ethernet listed on a product it, may warrant some additional verification. There are still several products that feature standard Modbus RTU packets encapsulated inside of a TCP/IP packet. These devices will not work in typical Modbus TCP/IP implementations.
