Detailed explanation of Modbus protocol
Communication protocols refer to the rules and agreements that entities on both sides must follow to complete communications or services. For example, in order to achieve communication between people, we need to agree on a unified language, unified text, prescribed speaking speed, etc.
For devices, the protocol defines the format used by the data unit (such as big-endian and little-endian modes, encoding and decoding methods, encryption and decryption rules), the information and meaning that the information unit should contain, the connection method, and the timing of information transmission and reception. This ensures smooth transmission of data to the other party.
1 Introduction
Modbus is a serial communication protocol. It was published by Modicon (now Schneider) in 1979 for programmable logic controller PLC communication, so now you know why it starts with Mod. It is not only used by PLC, but has actually become an industrial field. The standard of communication protocol is a commonly used connection method between modern industrial electronic equipment. Modbus is publicly available and copyright-free, making it easy to deploy and maintain.
Let's take a look at the details related to the Modbus protocol and how the Modbus protocol is applied.
Parallel communication: Data is transmitted simultaneously.
Serial communication: Data is transmitted bit by bit in sequence.
2. Physical interface
The Modbus protocol is an application layer protocol. The protocol itself does not SPIdefine the physical layer I2C, TCP/IPbut only defines the common format of the data packet organization structure and content. Therefore, it does not have its own dedicated data link layer and physical layer, so it needs to rely on other available physical layers and data link layers to transmit data.
For example, you can choose a serial port (such as RS232, RS485 and RS422) or an Ethernet port, but most current applications use the serial port RS-485 as the physical layer, as shown in the figure below.
In fact, it is not limited to the above physical interfaces. Since Modbus is an application layer protocol, the protocol itself communicates regardless of the network through which the data is communicated. Therefore, data can also be transmitted using USB, Bluetooth, WiFi and other buses that can transmit data serially as the physical layer and data link layer.
The standard Modbus port uses an RS-232C compatible serial interface, which defines the pins, cables, signal bits, transmission baud rate, and parity of the connection port, so that the controller can be networked directly or via a Modem.
3. Protocol version
The Modbus protocol currently defines rules for data transmission based on serial ports and Ethernet. Among them, there are two types of serial port rules: Modbus RTU and Modbus ASCII, and one type of Ethernet rule is Modbus TCP/IP.
The Modbus RTU and Modbus ASCII protocols are used for serial links (RS232, RS485, RS422, optical fiber, wireless), and the Modbus TCP/IP protocol is used for Ethernet links.
Modbus also has an extended version, Modbus PLUS (also called Modbus+ or MB+), but this protocol is proprietary to Modicon and is different from Modbus. It requires a specialized coprocessor to handle high-speed token rotation like HDLC.
We don't use MB+, so we don't understand it in depth. We only need to understand the three modes of Modbus-TCP/IP, Modbus-RTU, and Modbus-ASCII.
4. Working mode
Modbus protocol is a master-slave (Master/Slave) communication protocol. Among all nodes, one is the Master node and the rest are Slave nodes. There is at least and only one Master node in the entire communication network.
Master-slave communication is mainly based on request/response . In each communication, the master station first sends an instruction (which can be a broadcast instruction or a unicast instruction to a specific slave station). The slave station responds to the instruction and responds as required, or reports abnormal. When the master station does not send a request, the slave station will not send data by itself, and the slave stations cannot communicate directly with each other (that is, the slave stations cannot send instructions or access each other).
Regardless of whether the master station sends a broadcast command or a unicast command, in fact all slave devices will receive the command completely. However, the device will execute and respond to the unicast command only if the number/address specified in the command is the same as the device number/address . If the number/ address is different from the number/address specified in the command, the slave will discard all the received content. All devices that receive the broadcast command will execute the command, but will not respond to the host.
half duplex communication
Modbus cannot communicate synchronously due to the request/response mechanism (synchronous communication requires both the sender and the receiver to send and receive data at the same rhythm). Only one frame of data is transmitted on the bus at a time, which is half-duplex communication.
Modbus does not support busy mechanism processing. For example, the host sends a command to the slave. If the slave is processing other tasks, the slave will not be able to respond to the host at this time, so software needs to be used to determine whether it is received normally.
5. Agreement Overview
(1) The controller communication uses the master/slave mode, that is, only the master device can send query and operation commands, and other slave devices respond accordingly according to the master device query/operation commands.
(2) The master device can communicate with the slave devices individually or with all slave devices in a broadcast manner. If communicating alone, the slave device must return a message as a response to the host. If the query is broadcast, the slave device will not respond.
(3) The Modbus protocol establishes a protocol format for master device query, which includes: slave device (or broadcast) address, function code, all data to be sent, and error detection field (protocol check code).
(4) The response message from the device must also follow the Modbus protocol, including the field to confirm the action, any data to be returned, and the error detection field (protocol check code). If an error occurs during message reception, or the slave device cannot execute its command, the slave device needs to generate an error message and send it to the master device as a response. After the master device receives it, it will know that an error has occurred in the slave device, and can know What error occurred.
6. Message format
The basic format of the Modbus protocol message (or frame) is:
协议头(Header) + 功能码(Function Code) + 数据区(Data) + 校验码(Checksum)
Function code (Function Code) and data area (Data) are fixed in different types of networks.
The protocol header (Header) and checksum (Checksum) differ depending on the implementation of the underlying network. The protocol header contains the address of the slave station, the function code tells the slave station what function to perform, and the data area is the specific data content.
The message defines a protocol data unit (PDU for short) that is independent of the physical layer. The PDU protocol fields are composed as follows:
PDU = 功能码(Function Code) + 数据域(Data)（功能码 1 Byte，数据域不确定）
For different types of networks, the protocol layer implementation of Modbus is the same. The difference lies in the implementation of the lower layer. The two common ones are TCP/IP and serial communication .
As shown in the figure above, the physical layer of Modbus serial transmission is RS-485/422 or RS-232, and the data link layer is the serial transmission protocol of Modbus.
The transmission 1-4layers of Modbus TCP are the same as the Ethernet and Internet we use daily, which are physical layer, data link layer, network layer and transport layer. At the same time, the standard stipulates that the default TCP port number used by Modbus-TCP is 502.
6.1 Modbus-TCP/IP
In Modbus TCP mode, the master station is called the client and the slave station is called the server (Server) because the Modbus master station always queries the Modbus slave station for operating data, which is the same as the operation mode of the client and server. identical.
6.1.1 Data frame
For TCP/IP communication, the Modbus protocol introduces some additional fields mapped into application data units (ADU), and the ADU can be divided into two parts: MBAP and PDU. The relationship between the two parts is as follows:
PDU = 功能码(Function Code) + 数据域(Data)（功能码 1 Byte，数据域长度不确定）。
ADU = MBAP+PDU
The data frame consists of the following figure:
Among them, MBAP (message header) occupies 7 Bytes, function code 1 Byte, and the length of the data field is uncertain and determined by the specific function, as shown below:
| Transaction ID | protocol identifier | length | unit identifier |
|---|---|---|---|
| 2 Byte | 2 Byte | 2 Byte | 1 Byte |
The transaction identifier can be understood as the sequence number of the message. Generally, 1 is added after each communication to distinguish different communication data messages.
Protocol identifier , for example 00 00represents the Modbus-TCP/IP protocol.
Length , indicating the length of the next data, in bytes.
The unit identifier can be understood as the device address.
The ADU message is expanded in detail as shown below:
6.1.2 Data frame changes
(1) The check digit is cancelled, and the CRC-32 check is performed on the data link layer of the TCP/IP protocol. At the same time, TCP/IP is a connection-oriented reliability protocol, so there is no need for the application layer to add Check Digit.
(2) The Slave address becomes a unit identifier. When all devices in the network use the TCP/IP protocol, the address is meaningless, because the IP address can be used for routing. If there is serial communication in the network equipment, you need to use a gateway to implement protocol conversion from Modbus-TCP/IP to Modbus-RTU/ASCII. At this time, use Unit Identifier to identify each serial communication device behind the gateway.
(3) The length refers to the total number of bytes that follow. In fact, the length of the data area can be determined. Some function codes can determine the length of the data area (such as the register read function code). Although some function codes cannot determine the data Area length, but the Modbus protocol data area contains a byte count (this will be explained later). The increased length of the header is to cope with scenarios where the TCP/IP protocol unpacks and transmits application layer data.
(4) The transaction identifier and protocol identifier are generated by the Client, and the Server's response will copy these parameters.
6.1.3 Port number
The Internet Assigned Numbers Authority (IANA) assigns the TCP port number to the Modbus protocol 502. This is currently the only port number assigned to Modbus in the instrumentation and automation industry.
6.1.4 Communication process
When using TCP/IP communication, the master station is the Client and actively establishes a connection with the server. The slave station is the server side, waiting for the client to connect.
Note that a TCP connection needs to be established before using Modbus communication. When the communication task is completed, the TCP connection needs to be closed. This is the same rule as the PC client connecting to the server.
6.2 Modbus-Serial
When Modbus uses asynchronous serial link transmission, you can choose either of the two transmission modes: ASCII or RTU. When using asynchronous serial transmission, you need to ensure that the serial communication hardware configuration parameters (baud rate, verification method, etc.) of each device are the same.
6.2.1 Modbus-ASCII
In Modbus ASCII mode, the master station is Master and the slave station is Slave.
| start bit | Device address | function code | Data quantity | data | LRC high byte | LRC low byte | terminator |
|---|---|---|---|---|---|---|---|
| : | 2*8 Bit | 2*8 Bit | n | n*8 Bit | 8 Bit | 8 Bit | CR, LF (carriage return, line feed) |
Modbus communicates in ASCII mode, and each 8-bit byte in the message is sent as two ASCII characters, that is to say, two characters are used to represent the hexadecimal value of 1 byte, so what you see is what you get.
For example, to represent hexadecimal, 35you need to use the two characters 3and 5, and each character occupies 1 byte. The 3actual value of the character is hexadecimal 33, and the 5actual value of the character is 35, so in order to represent it, 3016 Bits data needs to be used, so the actual value The data sent is 00110011, 00110101, but this is not the final data used. The receiving end needs to convert it into the original value before it can be used.
ASCII frame interval
Using ASCII mode, the message starts with :a colon character (ASCII code 3A) and ends with a carriage return and line feed character 0D, 0A.
Other characters that the field can use to express hexadecimal values are 0-9, A-F. Devices on the network continuously detect :colon characters. When each node device receives a :colon, each device decodes the next field (device address field) to determine whether it is addressed to itself.
The maximum time interval between characters in the message sent cannot exceed 1 second, otherwise the receiving device will consider the transmission error. A typical ASCII message frame is as follows:
| start bit | Device address | function code | data | LRC check | terminator |
|---|---|---|---|---|---|
| 1 character | 2 characters | 2 characters | n characters | 2 characters | 2 characters |
6.2.2 Modbus-RTU
In Modbus RTU mode, the master station is Master and the slave station is Slave.
| start bit | Device address | function code | Data quantity | data | CRC low byte | CRC high byte | terminator |
|---|---|---|---|---|---|---|---|
| none | 8 Bit | 8 Bit | n | n*8 Bit | 8 Bit | 8 Bit | none |
Modbus communicates in RTU mode, and the byte data it sends is the original byte data, and the receiving end does not need to convert it again after receiving it.
For example, to transfer hexadecimal 35, the actual data sent is the raw value 0011, 0101.
RTU frame interval
Using RTU mode, message sending must begin with a pause interval of at least 3.5 characters. This is easiest to achieve with various character times at network baud rates (as shown in the figure below T1-T2-T3-T4). The first field transferred is the device address. The transmission characters that can be used are hexadecimal 0-9, A-F. Network devices continuously monitor the network bus, including during pause intervals. When the first field (the address field) is received, each device decodes it to see if it is destined for itself. After the last transmitted character, a pause of at least 3.5 characters marks the end of the message. A new message can be started after this pause.
The entire message frame must be transmitted as one continuous stream. If there is a pause of more than 1.5 character times before the frame is completed, the receiving device will flush the incomplete message and assume that the next byte is the address field of a new message. Likewise, if a new message begins within less than 3.5 characters of the previous message, the receiving device will consider it a continuation of the previous message. This will cause an error because the value in the last CRC field cannot be correct. A typical RTU message frame looks like this:
| start bit | Device address | function code | data | CRC check | terminator |
|---|---|---|---|---|---|
| T1-T2-T3-T4 | 8Bit | 8Bit | n 8Bits | 16Bit | T1-T2-T3-T4 |
character time
The so-called character transmission time refers to the time it takes to transmit an ASCII character. An ASCII character contains 1 byte (8 bits), so it takes 8 data bits to transmit a character (so the character transmission time here is not really literally means transmitting characters, but refers to transmitting bytes).
However, it actually takes more than 8 bit times to transmit 1 byte of data, because in addition to transmitting the inherent 1 byte data, some auxiliary function bits also need to be transmitted. For example, to send 1 byte, you need to fix 1 start bit, 8 data bits, 1 parity bit (optional), and 1 stop bit. Among them, 8 data bits are the real valid data, so it is as follows Formula to calculate character time.
Character time = 1 s baud rate × total number of characters. Character time = \frac{1s}{baud rate} \times total number of characters.character time=baud rate1 s×Total number of characters.
For example: 1 fixed start bit, 8 data bits, 1 odd/even parity bit, 1 stop bit, baud rate is 9600 bps, calculate the transmission time of a single character as:
Character time = 1000 ms 9600 × ( 1 + 8 + 1 + 1 ) = 1.145833 ms Character time = \frac{1000ms}{9600} \times (1+8+1+1)=1.145833mscharacter time=96001000ms×(1+8+1+1)=1.145833ms
7. Frame field analysis
7.1 Address field
Possible slave device addresses in the address field of the message frame are 0-247. The address range for a single device is 1-247.
The master device gates the slave device by placing the address of the slave device it wants to contact in the address field in the message. When the slave device sends a response message, it needs to put its own address into the address field of the response so that the master device knows which device is responding.
The address 0is used as a broadcast address to be known to all slave devices. When the Modbus protocol is used in higher level networks, broadcasting may not be allowed or otherwise replaced.
7.2 Functional domain
The possible code range of the function code field in the message frame is decimal 1-255. Of course, some code applies to all controllers, some apply to certain controllers, and some are reserved for later use.
When a message is sent from the master device to the slave device, the function code field tells the slave device what actions it needs to perform. For example, to read the input switch status, read the data content of a set of registers, read the diagnostic status of the slave device, allow calling, recording, and verifying the program in the slave device, etc.
When the slave device responds, it uses the function code field to indicate whether it responded normally (no error) or if some kind of error occurred (called an exception response). For normal responses, the slave device only responds with the corresponding function code. In response to the objection, the slave device returns a code that is equivalent to the normal code, but the most significant bit (the highest bit of the function code) is set to logic 1.
For example: a message sent from the master device to the slave device requires reading a set of holding registers, and the following function code will be generated: 0000, 0011(Hex 03) For a normal response, the slave device only responds with the same function code. In response to objections, it returns: 1000, 0011(hex 83).
In addition to the function code being modified due to the objection error, the slave device places a unique code in the data field of the response message, which can tell the master device what error occurred.
After the master device application receives a response to the objection, it will resend the message or diagnose the message sent to the slave device and report it to the device administrator.
7.3 Data field
The data field is composed of two hexadecimal number sets, and the value range of each byte data is 00-FF.
The data field of the message from the master to the slave contains additional information: the slave must be used to perform what is defined by the function code. This includes things like discrete register addresses, the number of items to be processed, and the actual number of data bytes in the field.
example
If the master device needs to read a set of holding registers (function code 03) from the device, the data field specifies the starting register and the number of registers to be read (here is not equivalent to the number of bytes).
If the master device writes a set of slave device registers (function code 10), the data field specifies the starting register to be written and the number of registers to be written (this is not equivalent to the number of bytes). The number of data bytes in the data field, The data to be written to the register.
If no error occurs, the data field returned from the slave device contains the requested data. If an error occurs, this field contains an exception code that the host device application can use to determine the problem and take next steps.
The data field may be absent (ie 0 length) in certain messages. For example, the master device requires the slave device to respond to the communication event record (function code 0B), and the slave device does not require the master device to provide any additional information.
7.4 Error detection domain
The standard Modbus network has two error detection methods, and the content of the error detection field depends on the selected detection method.
ASCII mode, the error detection field contains two ASCII characters. This is calculated using the LRC (Longitudinal Verbosity Detection) method on the message content, excluding the starting colon and carriage return and line feed characters. The LRC character is appended to the carriage return and line feed character.
In RTU mode, the error detection field contains a 16Bits value and is split into two bytes, divided into high byte and low byte. The content of the error detection field is obtained by performing a cyclic verbosity detection method on the message content. The CRC field is appended to the end of the message, low byte first and then high byte. Therefore, the high-order byte of the CRC is the last byte of the sent message.
7.4.1 LRC verification
The LRC field detects the content in the message field except the starting colon and the ending carriage return and line feed. The LRC field is a byte containing an 8-bit binary value. The LRC value is calculated by the transmitting device and placed in the message frame. The receiving device calculates the LRC during the process of receiving the message and compares it with the LRC value in the received message. If the two values are not equal, it means there is an error.
The LRC method is to continuously accumulate the 8-bit bytes in the message, and discard the accumulation carry bit during accumulation.
unsigned char LRC(unsigned char * auchMsg, unsigned short dataLen)
{
unsigned char authLRC = 0; /* LRC 字节初始化 */
while (dataLen--) {
/* 传送消息 */
authLRC += (*auchMsg)++; /* 累加 */
}
return ((unsigned char)(-authLRC));
}
7.4.2 CRC check
The CRC field detects the contents of the entire message. The CRC field is two bytes and contains a 16-bit binary value. It is calculated by the transmitting device and added to the message. The receiving device recalculates the CRC of the received message and compares it with the value in the CRC field of the received message. If the two values are different, there is an error.
When the CRC is added to a message, the low byte is added to the message first, then the high byte.
8. Data model
The Modbus protocol was first used in PLC communication. In order to abstract the accessible data in the PLC, the Modbus protocol defines the concept of data model . The data model defines four accessible data types, which are:
(1) Output coils (Coils), the size is only 1 Bit, belong to the switching value, the value range is ONor OFF, the authority is 可读可写, it can be either an output output point or a digital input point.
(2) Input discrete quantity (Discrete Input), it is a discrete quantity, the size is only 1 Bit, the value range is ONor OFF, the authority is 只读, that is, the digital output point.
(3) Input Registers (Input Registers) are 16-bit registers with permissions that 只读can be used as analog quantities or 16-bit packed input points.
(4) Holding Registers (Holding Registers), 16-bit registers, permissions 可读可写, can be either an analog or 16-bit packed input point, or an analog or 16-bit packed output point.
In fact, the above data types all belong to the terminology in programmable logic controller (PLC), so the expression is always inconsistent with our intuition, making it difficult to understand when we use MCU microcontroller thinking.
9. Data address model
The data model is an abstraction that must be mapped to real physical storage before it can be accessed.
The Modbus protocol allows the device to map four types of data to different storage blocks. Each block is independent of each other. Different values can be read using different function codes, as shown in the figure below:
Each data type in the data model allows a maximum of 65536 elements (numbers 1-65536). The address numbers of elements 0start from , so the range of addresses is: 0-65535.
It should be noted that: 65536 is the maximum element range allowed by the Modbus protocol, but it does not require us to implement all of them. The Modbus protocol allows the device to implement some elements according to its actual situation, and does not even require the implementation of all four types of data in the model (for example, only the reading and writing of holding register type data).
In order to simplify the correspondence between the data model and the device storage area, an address model is introduced. This model distinguishes different types of data by numbering. Please see the table below for the address number of each data:
| address model | Modbus address number |
|---|---|
| Coils | 0 |
| Discrete Input | 1 |
| Input Registers | 3 |
| Holding Registers | 4 |
The number of the Modbus address model starts from 1. Since each type of data supports a maximum of 65536 elements, we can get the address range of the following four data types (the first one is the address 0number):
(1) Output coils (Coils), their address range is: 000001-065536.
(2) Discrete Input, its address range is: 100001-165536.
(3) Input Registers (Input Registers), their address range is: 300001-365536.
(4) Holding Registers, whose address range is: 400001-465536.
However, since 65536is a relatively large value, such a large storage area is generally not needed in practical applications. Therefore, PLC manufacturers generally use an 10000address range within , so we can get the address ranges of the following four data types:
(1) Output coils (Coils), their address range is: 00001-09999.
(2) The address range of discrete input (Discrete Input) is: 10001-19999.
(3) The address range of the input registers (Input Registers) is: 30001-39999.
(4) The address range of Holding Registers is: 40001-49999.
Microcontroller mapping method
For the microcontroller we use, we can map the Modbus virtual address in the following way, define an array, define the starting address of the register, the number of registers, the number of registers can be up to one, but in our actual situation we usually don’t have so many, according to the actual number 9999used To define, for example, I defined 9 here (that is, 9999 - 9000).
#define COILS_ADDR_START (1)
#define COILS_COUNT (9999 - 9000)
#define DISCRETE_INPUT_ADDR_START (10001)
#define DISCRETE_INPUT_COUNT (9999 - 9000)
#define INPUT_REGISTERS_ADDR_START (30001)
#define INPUT_REGISTERS_COUNT (9999 - 9000)
#define HOLDING_REGISTERS_ADDR_START (40001)
#define HOLDING_REGISTERS_COUNT (9999 - 9000)
bool coilsBuf[COILS_COUNT];
bool discreteInputBuf[COILS_COUNT];
unsigned short inputRegistersBuf[COILS_COUNT];
unsigned short holdingRegistersBuf[COILS_COUNT];
According to the read address or write address provided by the host minus the register starting address we defined, it can be converted into an array index of the corresponding data, and then according to the number of reads or writes provided by the host (note that the number is the number of registers, not words number of sections) to know the array index range.
10. Function code
Earlier we learned that the master device can access or modify the data stored in the slave device. In order to facilitate the master device to use the Modbus protocol to access and modify the data stored in the slave device, the Modbus protocol has developed a series of function codes based on the data model and functions. , the function code and description are shown in the table below.
| function code | name | Function description |
|---|---|---|
| 01 | Read coil status | Read bits (read N bits) read slave coil register, bit operation |
| 02 | Read input discrete quantity | Read bits (read N bits) read discrete input register, bit operation |
| 03 | Read multiple registers | Read integer type, character type, status word, floating point type (read N words), read holding register, byte operation |
| 04 | Read input register | Read integer type, status word, floating point type (read N words) read input register, byte operation |
| 05 | Write a single coil | Write bit (write 1 bit)—write coil register, bit operation |
| 06 | Write to a single holding register | Write integer type, character type, status word, floating point type (write a word), write holding register, byte operation |
| 07 | Read exception status | Obtain the on-off status of 8 internal coils. The addresses of these 8 coils are determined by the controller. User logic can define these coils to indicate the status of the slave. Short messages are suitable for quickly reading the status. |
| 08 | echo diagnostic check | Send the diagnostic verification message to the slave machine to evaluate the communication processing. |
| 09 | Programming (484 only) | Make the host simulate the function of the programmer and modify the PC slave logic |
| 0A | Control query (only for 484) | It allows the host to communicate with a slave machine that is executing a long program task and inquire whether the slave machine has completed its operation task. This function code is only sent after the message containing function code 9 is sent. |
| 0B | Read event count | Allows the host to issue a single query and then determine whether the operation was successful, especially if the command or other responses cause a communication error |
| 0C | Read communication event records | However, the master retrieves the ModBus transaction communication event records for each slave. If a transaction is completed, the error will be logged |
| 0D | Programming (184/384/484/584) | The host simulation programmer function can be used to modify the PC slave logic |
| 0E | Inquiry (184/384/484/584) | It allows the host to communicate with the slave that is executing the task, and periodically queries whether the slave has completed its program operation. This function code must be sent only after the message containing function 13 is sent. |
| 0F | Write multiple coils | You can write multiple coils to force the on and off of a series of continuous logical coils. |
| 10 | Write multiple holding registers | Write multiple holding registers to load specific binary values into a series of consecutive holding registers |
| 11 | Report slave ID | 可使主机判断编址从机的类型及该从机运行指示灯的状态 |
| 12 | （884 和 MICRO84） | 可使主机模拟编程功能，修改 PC 状态逻辑 |
| 13 | 重置通信链路 | 发生非可修改错误后，是从机复位于已知状态，可重置顺序字节 |
| 14 | 读取通用参数（584L） | 显示扩展存储文件中的数据信息 |
| 15 | 写入通用参数（584L） | 把通用参数写入扩展存储文件 |
| 16~40 | 保留做扩展功能备用 | |
| 41~48 | 保留以备用户功能所用 | 留作用户功能的扩展编码 |
| 49~77 | 非法功能 | |
| 78~7F | 保留 | 留作内部作用 |
| 80~FF | 保留 | 用于异常应答 |
Modbus 定义了大量的功能代码，但是更为常用的功能代码只有如下部分功能代码。
| 功能码 | 名称 | 功能 | 对应的地址类型 |
|---|---|---|---|
| 01 | 读线圈状态 | 读位（读 N 个 bit）读从机线圈寄存器，位操作 | 0x |
| 02 | 读输入离散量 | 读位（读 N 个 bit）读离散输入寄存器，位操作 | 1x |
| 03 | 读多个寄存器 | 读整型，字符型，状态字，浮点型（读 N 个 word）读保持寄存器，字节操作 | 4X |
| 04 | 读输入寄存器 | 读整型，状态字，浮点型（读 N 个word）读输入寄存器，字节操作 | 3x |
| 05 | 写单个线圈 | 写位（写 1 个 bit）写线圈寄存器，位操作 | 0x |
| 06 | 写单个保持寄存器 | 写整型，字符型，状态字，浮点型（写一个 word）写保持寄存器，字节操作 | 4x |
| 0F | 写多个线圈 | 写位（写 N 个 bit）强置一串连续逻辑线圈的通断 | 0x |
| 10 | 写多个保持寄存器 | 写整形，字符型，状态字，浮点型（写 N 个 word）把具体的二进制值装入一串连续的保持寄存器 | 4x |
11. 错误码
前面说过当主从设备通信出现错误后，从设备可以将一个独特的代码放入到回应消息帧的数据域中，主设备接收到消息后能够大致判断从设备发生了什么错误，Modbus 定义的常用错误代码如下表所示。
| 异常码 | 名称 | 描述 |
|---|---|---|
| 01 (01H) | 非法功能 | 在请求中接收的功能代码不是从设备的一个授权操作。从设备可能处于错误状态，无法处理特定请求。 |
| 02 (02H) | 非法数据地址 | 从设备接收的数据地址不是从设备的一个授权地址。 |
| 03 (03H) | 非法数据值 | 指定的数据超过范围或者不允许使用。 |
| 04 (04H) | 从站设备故障 | The slave failed to perform a requested operation because an unrepairable error occurred. |
| 05 (05H) | confirm | The slave device has accepted the request and is processing the request, but requires a long duration to perform these operations. Returning this response prevents a timeout error from occurring in the client (or master). The client (or host) can continue to send polls. Program completion message to confirm whether processing is complete. |
| 06 (06H) | slave device busy | The slave device is busy processing another command. The master device must send the request after the slave device is idle. |
| 07 (07H) | negative confirmation | The slave device cannot execute the request sent by the master device. |
| 08 (08H) | storage parity error | The slave device detected a parity error from memory while trying to read extended memory. |
| 10 (0AH) | Unavailable gateway path | Used with a gateway to indicate that the gateway cannot assign the input port value to the internal communication path of the output port for processing requests. Usually means the gateway is misconfigured or overloaded. |
| 11(0BH) | Gateway target device failed to respond | Used with a gateway to indicate that no response was obtained from the target device, usually meaning the device is not on the network. |
We will continue to update and improve the content related to the Modbus protocol in the future. This article is long, so other content such as how to use the Modbus debugging tool will be expanded on in the next article.
If the content of the article is helpful, please give me a like and give me some encouragement. If there is any problem with the content, please leave a message.