Just imagine for a moment—imagine you’re a 23-year-old, just one year out of college. By some act of God, you convince an industrial automation company that you are a competent writer and they agree to hire you to write blog content. Fast forward, it’s your second Monday at the company. Your boss is approaching. Quick! Look busy! You leap into action, closing out of your solitaire game. “I have a very important task for you,” he says, “I need you to write an article…” Oh my gosh, this is the crowning moment of my fifty-hour long tenure! “…on Modbus.”
What the hell is Modbus?
A Brief History
In the early days of industrial automation, factories needed a way for the first Programmable Logic Controllers (PLCs) to communicate with one another. The first PLC was developed by Modicon in 1968 at the request of General Motors. After demonstrating success at GM, they named the device the Modicon 084 and began mass production. Come the end the 1970s, new competitors like Allen-Bradley entered the market and PLCs were common in factories. But information still couldn’t be communicated between PLCs and it became an arms race to see who could innovate their technology to be able to communicate between these devices. Around the same time that Allen-Bradley released Data Highway, Modicon created Modbus. But again, what the hell is Modbus?
Modbus can be described as the grandfather of industrial communications protocols. It is the most common method of connecting automated electronic devices in industrial settings. When Modicon released Modbus, they did so without keeping their standard proprietary. This allowed for any developer to implement Modbus into their products. It is a universal standard that can be supported by many devices. In fact, one Modbus RTU master device can support up to 247 Modbus slave devices. It is also very simple to set up and understand—even by non-engineers like myself. Here are four things you should know about Modbus as told by somebody learning about Modbus.
#1: Modbus RTU vs. Modbus TCP
The Modbus RTU transmission protocol uses a “master-slave” technique to communicate between devices. What this means is that this protocol requires at least one Modbus master device and at least one Modbus slave device. The Modbus master acts almost as a supervisor to the slave devices by running software that communicates action requests. Modbus RTU messages can be transported via multiple transport layers. When Modbus RTU was originally released, RS-232 was used as the norm. That being said, RS-232 is not often used in today’s factories and is thus considered outdated. RS-232’s successor, RS-485, is capable of sending Modbus messages to up to thirty-two devices. Modbus can also be communicated via Ethernet—this is known as Modbus TCP. Prior to using Ethernet as a transport protocol, devices using Modbus could only communicate if they were within a couple hundred feet apart. With the help of Ethernet, Modbus-enabled devices can communicate information even if they are miles apart—and quickly too, as Ethernet can support greater bandwidth.
#2 Modbus Data Representation
The reason why Modbus is so simple to read and understand is that it only has two different data types: registers and coils. Coils are simply single bits. These bits are either 0s or 1s—0 for OFF and 1 for ON—simple enough! Some coils represent inputs and outputs that describe the state of a discrete input or output (e.g., Is the light on or off? Is the conveyer belt moving?). Registers are nothing but 16-bit unsigned register data. There are two different types of registers, input and holding registers. Input registers report the state of an external value and are quite literally a digital representation of an analog signal. For example, the voltage of an electrical current or the temperature of a machine will get assigned a value between 0 and 65535 which tells the receiving machine exactly what is going on with the sender. Holding registers were originally used to temporarily store program data for Modbus devices. Today, they are used to store data.
#3 Modbus Messaging Components
Each Modbus message begins with a Function Code, which identifies the request to the slave or server device. 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 into the coils 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. The Bit Length specifies how many data bytes to read or write and the Word Count specifies the number of registers to read or write. Following this is the Byte Count, which indicates the number of bytes included in the request or response. Lastly, we have the response code, which indicates the completion of the request. The Exception Response is indicated by combining the Response Code of the original Modbus function request with 80 hexadecimals.
#4 Modbus Message Encoding
The two protocols of encoding Modbus messages are RTU and ASCII. The RTU protocol is made up of big-endian binary encoding of machine data. It is also the newer and more common method of encoding Modbus messages. As we know, Modbus is communicated in 16-bit registers. These messages cut right to the chase having the Most Significant Byte encoded first, and their Least Significant Byte encoded after. Modbus ASCII is a little different. Instead of sending binary messages, ASCII assigns numbers, letters, and other characters to 256 slots in an 8-bit code. Makes sense, right? This might be why ASCII can only be found in very old Modbus devices.
Now, in case you haven’t figured it out by now, the above story was about me, the author. I have to credit this article to the amazing team at Real Time Automation who have already written all that there is to know about Modbus. I have since been able to copy and paste their work as my own while changing a few words around so it appears that I have a vast array of knowledge on industrial automation. My boss now thinks I’m a genius and I am expecting a raise.
If you would like a more comprehensive look into Modbus, I would recommend the book The Everyman’s Guide to Modbus. I would be lying if I told you I could have written this article without it. Give it a read—it’s the perfect book for beginners like myself.