This guidance technical document includes the Modbus application layer protocol and service specifications used in two communication procedures - Modbus over serial link Modbus serial link is based on TIA/EIA standards: 232-F and 485-A. - Modbus over TCP/IP Modbus TCP/IP is based on IETF documents: RFC 793 and RFC 79l. Modbus over serial link and Modbus over TCP/IP are two communication procedures described according to the corresponding ISO layered model. The figure below highlights the main parts of this guidance technical document. Dark boxes represent specifications, and light boxes represent existing international standards (TIA/EIA and IETF standards). GB/Z 19582.1-2004 Industrial Automation Network Specifications Based on Modbus Protocol Part 1: Modbus Application Protocol GB/Z19582.1-2004 Standard download decompression password: www.bzxz.net

ICS25.040
National standardization guidance technical documents of the People's Republic of China GB/Z19582.1-2004
Industrial automation network specification based on Modbus protocol Part 1: Modbus application protocol
Modbus industrial automation network specification-Part 1 : Modbus application protocol2004-09-21 release
General Administration of Quality Supervision, Inspection and Quarantine of the People's Republic of China Standardization Administration of China
2005-03-01 implementation
GB/Z19582.1—2004
Normative references
Abbreviations
Background summary
Overall description
Protocol description
Data encoding
Modbus data model
Modbus addressing model
5.5 Definition of Modbus transaction processing||tt| |6 Function code classification
6.1 Common function code definition
7 Function code description
7.101 (0x01) Read coil
7.202 (0x02) Read discrete input
7.303 (0x03) Read holding register
7.404 (0x04) Read input register
7.505 (0x05) Write single coil
7.606 (0x06) Write single register
07 (0x07) Read abnormal status (only for serial link) 7.808 0x08) Diagnosis (only for serial link) 7 .9
11 (0x0B) Get communication event counter (only for serial link) 12 (0x0C) Get communication event record (only for serial link) 15 (0x0F) Write multiple coils
16 (0x10) Write multiple registers
17 (0x11) Report slave ID (only for serial link): 20/6 (0x14/0x06) Read file record
21/6 (0x15/0x06) Write file record
22 (0x16) Mask write register
23 (0x17) Read/write multiple registers
24 (0x18) Read FIFO queue
43(0x2B) Encapsulation interface transmission
43/14（0x2B/0x0E） Read device identification7.20
8Modbus abnormal response
Appendix A (Informative Appendix) References
GB/Z19582.1--2004
This guidance technical document includes Modbus application layer protocols and service specifications used in two communication procedures: Modbus on serial link
Modbus serial link is based on TIA/EIA standards: 232-F and 485-A. -Modbus on TCP/IP
Modbus TCP/IP is based on IETF documents: RFC793 and RFC791 Modbus on serial link and TCP/IP are two communication procedures described according to the corresponding ISO layered model. The following figure highlights the main parts of this guidance technical document. Dark boxes represent specifications, and light boxes represent existing international standards (TIA/EIA and IETF standards).
Modbus
Application protocol
Modbus protocol
Implementation on a single link
refers to
TIA/EIA-232-FTTAEIA-485-A
Industrial automation network specifications based on Modbus protocol are divided into three parts. Part 1: Modbus Application Protocol
Part 2: Modbus Protocol Implementation Guide over Serial Links - Part 3: Modbus Protocol Implementation Guide over TCP/IP Ethernet Physical Layer
Moabus Protocol
Implementation Guide over TCPIPE
Part 1 describes Modbus transaction processing; Part 2 provides reference information to help developers implement Modbus application layer over serial links; Part 3 provides reference information to help developers implement Modbus application layer over TCP/IP. Appendix A of this part is an informative appendix.
This part was proposed by China Machinery Industry Federation. This part is under the jurisdiction of the National Technical Committee for Industrial Process Measurement and Control Standardization. Drafting units of this part: Comprehensive Technical and Economic Research Institute of Machinery Industry Instruments, Modern Communications Research Institute of Beijing Jiaotong University, Shanghai Automation Instrument Co., Ltd., Schneider Electric (China) Investment Co., Ltd., China Metallurgical Industry Iron and Steel Research Institute, Baosteel Group Shanghai Baosight Software Co., Ltd.
The main drafters of this part are Ouyang Jinsong, Sun Xin, Liu Tiezhui, Feng Xiaosheng, Wang Yong, Zhang Rongsheng, Cong Liqun, Duan Yongkang. 1
1 Scope
GB/Z19582.1—2004
Industrial automation network specification based on Modbus protocol Part 1: Modbus application protocol
Modbus is an application layer message transmission protocol on layer 7 of the OSI model, which provides client/server communication between devices connected to different types of buses or networks, as shown in Figure 1. Since 1979, Modbus has been the de facto standard for industrial serial links, enabling thousands of automation devices to communicate. Currently, support for the simple and elegant Modbus structure is still growing. Internet users can access Modbus using the reserved system port 502 on the TCP/IP stack.
Modbus is a request/response protocol and provides services specified by function codes. Modbus function codes are elements of Modbus request/response PDUs. This section describes the function codes used within the Modbus transaction framework. Modbus is an application layer messaging protocol used for client/server communication between devices connected via different types of buses or networks.
Currently, Modbus communication is implemented via: TCP/IP over Ethernet.
Asynchronous serial transmission over various media (wired: EIA/TIA-232-F, EIA-422, EIA/TIA-485-A; fiber optic, wireless, etc.).
-ModbusPLUS, a high-speed token passing network. Modbus application layer
Modbus based on TCP
2 Normative references
MODBUS-HDLC
Physical layer
Master/slave
EIA/TA-232 or
BLA/TIA-485
Figure 1 Modbus communication stack
Ethernet118023
Ethernet
Physical layer
The following documents have become the terms of this part through reference in this part of GB/Z19582. For any dated referenced document, all subsequent amendments (excluding errata) or revisions are not applicable to this part, however, parties to an agreement based on this part are encouraged to study whether the latest versions of these documents can be used. For any undated referenced document, the latest version applies to this part.
GB/T15969 Programmable Controller
RFC791,InternetProtocol,Sep81DARPA**References[1].
GB/Z19582.1-2004
3Abbreviations
ADU(ApplicationData Unit)
HDLC(High Level Data link control)HMI(Human Manchine Interface)IETF(Internet Engineering Task Force)I/O(Input/Output)
IP(Internet Protocol)
LSB(Least Significant Bit)
MAC(Medium Access Control)
MB(Modbus Protocol)
MBAP(MODBUS Application Protocol)MEI(MODBUS Encapslated Interface)MSB(Most Significant Bit)
PDU(Protocol Data Unit)
PLC(Programmable Logic Controller)RFC(RequestFor Comment)
TCP(Transport Control Protocol)4 Background Overview
Application Data Unit
High-Level Data Link Control
Human-Machine Interface
Internet Engineering Working Group
Input/Output
Internet Protocol
Least Significant Bit
Media Access Control
Modbus Protocol
Modbus Application Protocol
Modbus Encapsulation Interface
Most Significant Bit
Protocol Data Unit
Programmable Logic Controller
Request for Comment
Transmission Control Protocol
The Modbus protocol can easily communicate within various network architectures, as shown in Figure 2. M
Inverter
Modbus based on MB+
Mc based on TCP/IP
Modbus based on RS232
Modbus based on RS485
Modbus based on RS485
Figure 2 Example of Modbus network architecture
Each device (PLC, HMI, control panel, inverter, motion control, I/O device...) can use the Modbus protocol to enable remote operation.
The same communication can be carried out on serial link and Ethernet TCP/IP network. The gateway can realize the communication between various buses or networks using the Modbus protocol. 2
5 General description
5.1 Protocol description
GB/Z19582.12004
The Modbus protocol defines a simple protocol data unit (PDU) that is independent of the basic communication layer. The Modbus protocol mapping on a specific bus or network can introduce some additional fields on the application data unit (ADU), see Figure 3. ADU
Additional Group
Function Code
Figure 3 Generic Modbus Frame
Parity Check
The client that initiates the Modbus transaction creates a Modbus application data unit. The function code indicates to the server which operation is to be performed. The Modbus protocol establishes a request format for client initiation. The function code field of the Modbus data unit is encoded in bytes. The valid codeword range is decimal 1 to 255 (128 to 255 is reserved for exception responses). When a message is sent from the client to the server device, the function code field tells the server which operation to perform. Sub-function codes are added to some function codes to define multiple operations. The data field of the message sent from the client to the server device includes additional information that the server uses to perform the operation defined by the function code. This field also includes discrete and register addresses, the number of items to be processed, and the actual number of data bytes in the field. In certain requests, the data field may be absent (0 length), in which case the server does not need any additional information. The function code only describes the operation.
If no error related to the requested Modbus function occurs in a correctly received Modbus ADU, the data field of the response from the server to the client includes the requested data. If an error related to the requested Modbus function occurs, the field includes an exception code, which the server application can use to determine the next operation to be performed. For example, the client can read the on/off status of a group of discrete outputs or inputs, or the client can read/write the data content of a group of registers.
When the server responds to the client, it uses the function code field to indicate a normal (error-free) response (see Figure 4) or a certain error (called an abnormal response), see Figure 5. For a normal response, the server simply copies the original function code. Client
Start request
Function code data request
Receive response
Server
Execute operation
Start confirmation
Function code data response
Figure 4 Modbus transaction processing (no error)
For abnormal response, the server sets the most significant bit of the original function code to logic 1 and returns. 3
GB/Z19582.1-2004
Start request
Function code
Client
Xinjiao according to fine request
Receive response
Server
Detect error in operation
Start error
Exception function code
Body code
Figure 5 Modbus transaction processing (abnormal response) Note: Timeout management is required to avoid waiting indefinitely for a response that may not appear. The original implementation of Modbus on the serial link (maximum RS485ADU = 256 bytes) limits the length of the ModbusPDU. Therefore, for serial link communication, ModbusPDU = 256-server address (1 byte)-CRC (2 bytes) = 253 bytes.
Thus:
RS232/RS485ADU=253 bytes+server address (1 byte)+CRC (2 bytes)=256 bytes. TCPModbusADU=253 bytes+MBAP(7 bytes)=260 bytes. The Modbus protocol defines three types of PDUs. They are: -Modbus request PDU, mb_req-pdu; -Modbus response PDU, mb_rsp-pdu;
Modbus exception response PDU, mb_excep_rsp_pdu. Define mb_req_pdu as:
mb_req_pdu=（function_code，request_data）, where function_code:［1 byte］Modbus function code request_data:［n bytes］, this field is related to the function code and usually includes information such as reference variables, variable counts, data offsets, sub-function codes, etc.
Define mb_rsp_pdu as:
mb_rsp-pdu=（function_code，response_data）, where function_code: [1 byte] Modbus function code. response_data: [n bytes], this field is related to the function code and usually includes information such as reference variable, variable count, data offset, sub-function code, etc.
Define mb_excep_rsp_pdu as:
mb_excep_rsp_pdu={function_code，request_data)，where function_code: [1 byte] Modbus function code+0x80. exception_code: [1 byte], Modbus exception codes are defined in Chapter 7. 5.2 Data Encoding
Modbus uses the most significant byte to store at the lower address to represent addresses and data items. This means that when sending multiple bytes, the most significant byte is sent first. For example: Register size
0x1234
Note: For more detailed information, see [1].
5.3Modbus data model
The first byte sent is
Then 0x34
The data model of Modbus is based on a set of tables with different characteristics. The four basic tables are shown in Table 1: 4
Basic table
Discrete inputwww.bzxz.net
Input register
Holding register
Object type
Single bit
Single bit
16-bit word
16-bit word
Access type
GB/Z19582.1—2004
I/O system can provide this type of data
This type of data can be changed by the application programI/O system can provide this type of data
This type of data can be changed by the application programThe distinction between input and output and between bit-addressed and word-addressed data items does not mean a difference in application characteristics. If all 4 tables overlap each other, this is the most natural interpretation for the target machine, which is completely acceptable and common. For each basic table, the protocol allows 65536 data items to be selected individually, and its read and write operations are designed to span multiple consecutive data items up to the data size specification limit, which is related to the transaction processing function code. Obviously, all data (bits, registers) handled by Modbus must be placed in the device application memory. However, the physical address of the memory should not be confused with the register number. It is only required to link the register number with the physical address. The Modbus register logical number used in the Modbus function code is an unsigned integer index starting with 0. -Examples of Modbus model implementation
The following examples show two ways to organize data in a device. There are many ways to organize data, which are not all described in this section. Each device has its own way of organizing data according to its application. Example 1: Device with 4 independent blocks
Figure 6 shows the data organization in a device containing digital and analog quantities, input quantities and output quantities. Since the data in different blocks are not related, each block is independent of each other. Each block can be accessed through different Modbus function codes. Device application memory
Modbus access time
Input discrete
Input register
Holding register
Modbus server device
Modbus request
Figure 6 Modbus data model with independent blocks Example 2: Device with only 1 block
In the example of Figure 7, the device has only 1 data block. The same data can be obtained through several Modbus function codes, either through 16-bit access or through 1-bit access.
GB/7.19582.1—2004
5.4Modbus addressing model
Device application memory
Modbus server device
odhus access
Input discrete quantity
Input register
Holding register
Figure 7 Modhus data model with only 1 block The Modbus application protocol precisely defines the PDU addressing rules. In the MUDBUS PDU, each data is addressed from 0 to 65535. Modbus request
The Modbus application protocol also clearly defines the Modbus data protocol consisting of 4 blocks, each block consisting of several elements numbered 1 to n.
In the Modbus data model, each element in the data block is numbered from 1 to n. Then, the Modbus model must be combined with the device application (GB/T15969). The mapping between the Modbus data model and the device application is completely device-specific. Device Application
Specific Application
Modbus Data Model
Discrete Input
Input Register 2
Holding Register
Modbus PDU Address
Read Input 0
Read Coil 4
Read Register Guard
Read Register 54
Modbus Standard
Figure 8 Modbus Addressing Mapping
Figure 8 shows the Modbus data numbered X being addressed using X-1 of the Modbus PDU. 5.5 Definition of Modbus Transaction Processing
Figure 9 is a state diagram that describes the general processing of Modbus transaction processing on the server side. 6
Send Modbus
Exception Response
Wait for the MB's
Exception Code.
Exception code_2
Exception code
Exception code_456
Receive MB indication】
Valid function code
【Valid】
Valid data
[Invalid]
[Valid]
Valid data value
[Valid
(Execute MB function
[Invalid]
{Valid
Send Modbus
Figure 9 State diagram of Modbus transaction processing| |tt||GB/Z19582.1--2004
Once the server processes the request, it uses the appropriate Modbus server transaction to establish a Modbus response. Depending on the processing results, two types of responses can be established: a normal Modbus response: response function code = request function code. an abnormal Modbus response (see Chapter 8): 1) used to provide the client with information related to the errors found during the processing; 2) abnormal function code = request function code + 0x80; an abnormal code is provided to indicate the cause of the error. 3)
6 Function Code Classification
There are three types of Modbus function codes, see Figure 10. They are: Public Function Codes
1) Function codes that are well defined;
guaranteed to be unique;
confirmed by Modbus.org;
publicly documented:
conformance testing available;
archived in MBIETFRFC;
contains defined public function codes and function codes reserved for future use. 7)
-User Defined Function Codes
There are two areas for user defined function codes, namely decimal 65 to 72 and 100 to 110. 1)
Users can select and implement a function code without any approval from the Modbus organization. 2)
The use of the selected function code is not guaranteed to be unique. 3)
If a user wishes to set a certain function as a public function code, the user must initiate an RFC to introduce the change 4)
into the public category and assign a new public function code. Reserved function code
Function codes currently used by some companies on traditional products are not for public use. 7
GB/Z19582.12004
Public function code
User-defined function code
Public function code
Function code defined in GB
Public function code
Figure 10 Modbus function code classification
Note: In the public area of ​​function codes, some function codes can be reserved. 6.1 Public function code definition
See Table 2.
Physical discrete input
Bit access
Internal bits or physical coils
16-bit access
Input registers
Internal memory or physical output memory
File record access
Read discrete inputs
Read coils
Write single coil
Write multiple coils
Read input registers
Read multiple registers
Write single register
Write multiple registers
Read/write multiple registers
Mask write registers
Read FIFO queue
Read file record
Write file record
Read exception status
Get common event counter
Get common event record
Report slave ID
Read device identification code
Encapsulate interface transmission
Function code
(hexadecimal)1 Public function code definition
See Table 2.
Physical discrete input
Bit access
Internal bit or physical coil
16-bit access
Input register
Internal memory or physical output memory
File record access
Read discrete input
Read coil
Write single coil
Write multiple coils
Read input register
Read multiple registers
Write single register
Write multiple registers
Read/write multiple registers
Mask write registers
Read FIFO queue
Read file record
Write file record
Read exception status
Get common event counter
Get common event record
Report slave ID
Read device identification code
Encapsulate interface transmission
Function code
(hexadecimal)
Tip: This standard content only shows part of the intercepted content of the complete standard. If you need the complete standard, please go to the top to download the complete standard document for free.