Why does industrial automation need a “language”? With the advent of Industry 4.0, various automated factories have emerged, where different machines collaborate to perform high-intensity tasks with minimal errors. So how do these numerous industrial devices “understand” each other’s language? When a conveyor belt transports materials to a loading point, how does the gripper hear the sound of the conveyor belt and grab the materials? The secret lies in the communication protocol. What is a communication protocol? It is like our language; we agree to speak Chinese, so we can communicate. If you speak English and I speak Chinese, communication issues arise. Today’s protagonist, the ModBus communication protocol, is known as the “king of languages”. Through today’s study, we will gradually unveil its mysterious veil.1. Definition: MODBUS is an industrial communication protocol developed in 1979 by the American company Modicon (now part of Schneider Electric) for programmable logic controllers (PLCs). It is based on a master-slave communication model, allowing a master device (such as a PLC) to exchange data with multiple slave devices (such as sensors and frequency converters).2. Development History:
-
MODBUS RTU (1979):
-
Based on serial communication (such as RS-232 or RS-485), using a compact binary data format.
-
Features: High transmission efficiency, suitable for early industrial scenarios, such as equipment control in small factories.
-
Application scenarios: Early data interaction between PLCs and instruments.
-
MODBUS ASCII (contemporaneous):
-
Uses readable ASCII characters to transmit data, making messages easier to debug, but with larger data volume and lower efficiency than RTU.
-
Features: Suitable for scenarios requiring manual debugging, but due to lower efficiency, its usage range is narrower.
-
MODBUS TCP (1999):
-
With the popularity of Ethernet, MODBUS adapted to the TCP/IP protocol, operating on modern networks.
-
Features: No need for serial ports, supports remote communication, compatible with modern industrial Ethernet architectures.
-
Application scenarios: Smart manufacturing, remote monitoring, interconnection of geographically dispersed factories.
3. Why has it endured for so long?
A protocol’s longevity must have its unique advantages. Modbus boasts simplicity, ease of use, openness, cross-platform compatibility, reliability, and low cost, which have allowed it to stand firm in the industrial communication field for over forty years.
4. ModBus Architecture
First, let’s introduce what architecture is. In industrial automation and communication protocols, architecture refers to the structure and organization of the system or protocol, i.e., how each part is divided, connected, and collaborates to achieve specific functions. In simple terms, it is like a blueprint that defines the “rules of the game” for devices, data, and communication.
What is the architecture of ModBus? Here, I will quote a slide from a ModBus PPT I previously created.
From the above, we can see the master-slave architecture of ModBus, which is the first step in unveiling its mysterious veil. Next, let’s look at one of the most commonly used transmission protocols of ModBus—RTU.
4. ModBus-RTU
Just like we speak Chinese, the standard format is subject-verb-object. Similarly, communication protocols must have such a format, known as frame format. Since we are transmitting data with ModBus, this frame format refers to the data frame format. What does this frame format look like? Let’s refer to my previous PPT again.
From the above image, we can see that it is divided into four parts. Let’s break down each part frame by frame.
-
Slave Address
ModBus’s architecture is master-slave, so when the master sends data to the slave, we need the slave’s address. This is similar to sending a package; you need to know the recipient’s address to send it. This slave address occupies one byte.
-
Function Code
Now that we know the slave’s address, we need to tell the slave what we want to do. The function code lets the slave know what you are here for. For example, if the master wants to read data, it sends the corresponding function code to inform the slave of its intention.
-
Data Field
The function code has already informed the slave of the purpose, and this data field specifies what exactly the master wants to do. For instance, if the master sends a function code to read a register, the data field will specify which register’s data to read.
-
CRC Check Code
CRC is a commonly used check method in industry, used to verify if there were any errors in the preceding transmission.
5. ModBus-ASCII
Similar to RTU, ASCII also has four parts, but you will notice that it combines the address, function code, and data field into one. Let’s see how ASCII differs from RTU.
- Start CharacterFixed value is a colon (:), ASCII code 0x3A.Function: Marks the beginning of the frame, making it easier for the receiver to identify.
- Slave Address (2 bytes)Range: 1-247 (0 for broadcast), represented by 2 ASCII characters for one hexadecimal byte.Broadcast address “00” indicates all slave devices receive but do not respond.
- Function CodeSpecifies the operation type, common function codes are the same as RTU (e.g., 03: read holding registers, 05: write single coil).Represented by 2 ASCII characters.
- Data FieldContent is determined by the function code, such as register address, data amount, write value, etc.Each byte is represented by 2 ASCII characters (hexadecimal format).Data field length varies with operation, maximum limited by protocol (usually total frame length does not exceed 510 ASCII characters).
- LRC CheckLongitudinal Redundancy Check, covering from the slave address to the data field.Calculation method: Sum all bytes from the address to the data field (in hexadecimal value), take the two’s complement, and represent the result with 2 ASCII characters.The receiver verifies the LRC; if it does not match, the frame is discarded.
- End CharacterFixed as carriage return and line feed (CRLF), ASCII code 0x0D 0x0A.
In comparison, ASCII is less efficient, suitable for debugging or low-speed scenarios, while RTU is more compact and suitable for high-reliability industrial environments.6. ModBus-TCP/IP
Although it appears to have only two parts, it is comparable to RTU. Let’s take a look at its content.
- MBAP Header (7 bytes)Transaction ID (2 bytes) + Protocol ID (2 bytes) + Length (2 bytes) + Unit ID (1 byte)
- Transaction ID
Generated by the client, used to identify the request-response pair, preventing confusion in multi-threaded communication.For example, 0x0001, incremented with each request.
- Protocol IDFixed as 0x0000, indicating the MODBUS TCP protocol.
- Length (2 bytes)Indicates the number of bytes from the unit ID to the end of the data field (including unit ID, function code, and data field).
- Unit ID (1 byte)
Similar to the slave address in RTU, range 1-247, 0 for broadcast.In a single device scenario, often set to 0xFF or consistent with the RTU address.For example, 0x01 indicates slave device 1.
- Function Code (1 byte)
Same as the function codes mentioned above, which will be provided later.
- Data Field (0-n bytes)
- Request frame (e.g., read register): starting address (2 bytes) + number of registers (2 bytes).
- Response frame: byte count (1 byte) + actual data (n bytes).
- Content is determined by the function code, such as register address, data amount, write value, etc.
- Similar to RTU, but without serial port limitations, allowing for slightly larger data volumes.
- Maximum data field length is limited by the protocol (the entire frame does not exceed 260 bytes).
OK, that concludes the introduction of the three transmission modes. If you look closely, you will notice three familiar terms—register, function code, and slave address. What exactly are they? Let’s take a look together.7. Registers
ModBus protocol specifies four types of registers as shown in the following image.
This is something to remember. If anyone has questions about input registers and holding registers: since holding registers can read data, why do we need input registers?
This question can be understood with the example in the last line of the image. One is to read the temperature of a sensor, and the other is to set a target temperature value. Some data can only be read and not written. If you were to write data to a temperature sensor, that would be quite absurd.
8. Function Codes
These are codes you need to remember, commonly used ones include 0x01, 0x03, etc.
9. Address
Why did I leave the first address bit of the frame format to discuss last? Is there something different about it? No, I just forgot to mention it earlier… but it is also very important, so let’s take a look.
From the above two images, we can see that there are two types of addresses: one is for human readability, like 00001, 30002, and the other is the logical address, which is the actual value used in the ModBus protocol. How is it calculated? It is the human-readable address minus the address prefix, for example, 40003-40001 gives the holding register address of 0x0002.
10. Slave Response Format
Earlier, we only discussed the format of the master sending frames to the slave. If the master sends a read function, how does the slave respond to the master? Let’s look at the slave response format.
Let’s not look at the exception example for now; the normal response actually has the same frame format as the master sending frame, except that the data field contains the data to be read from the register.
11. Exception Response
Earlier, we saw that there could be an exception response from the slave. Let’s see what that is about.
I have listed four commonly used exception response codes. How are these exception response codes used? Let’s take the exception response in item 10 as an example.
01 83 02 C0 F1
In the same response format, 01 is the slave address. When an exception occurs, the slave will prepend 0x80 to the function code, so here the exception response is 0x83. The following 0x02 indicates the specific reason for the exception. From the above image, we can see that 02 indicates that the register does not exist or the range is incorrect. What does that mean? For example, if I have sensor register addresses only from 0x0000 to 0x006f, and now the master sends a message to the slave to read data from register 80, the slave will respond with the exception code 02.
12. Dialogue Example
Using the above as an example, let’s analyze how a normal dialogue works.
01 03 00 00 00 02 C4 0B
The master sends to slave 01 that it wants to read holding register data (03) from 0x0000 to 0x0002, with a CRC check code of C4 0B.
01 03 04 00 19 00 00 8A 44
Slave 01 responds with 03 holding register data totaling 4 bytes (04), which are 0x0019 0x0000, with a CRC check code of 8A 44.
Below is an example you can try yourself; feel free to leave your analysis in the comments.
Master: 04 03 00 10 00 02 45 C9
Normal response from slave: 04 03 04 00 32 00 64 EC AE
Exception response from slave: 04 83 02 B0 F6
Finally, I wish everyone happiness every day