Baixe Comunicação Industrial Modbus e outras Notas de estudo em PDF para Mecatrônica, somente na Docsity!
Modbus-IDA
MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1b
- 1 Introduction CONTENTS
- 1.1 Scope of this document
- 2 Abbreviations
- 3 Context
- 4 General description
- 4.1 Protocol description
- 4.2 Data Encoding
- 4.3 MODBUS Data model
- 4.4 MODBUS Addressing model
- 4.5 Define MODBUS Transaction
- 5 Function Code Categories ............................................................................................
- 5.1 Public Function Code Definition ...........................................................................
- 6 Function codes descriptions .........................................................................................
- 6.1 01 (0x01) Read Coils ...........................................................................................
- 6.2 02 (0x02) Read Discrete Inputs............................................................................
- 6.3 03 (0x03) Read Holding Registers .......................................................................
- 6.4 04 (0x04) Read Input Registers ...........................................................................
- 6.5 05 (0x05) Write Single Coil ..................................................................................
- 6.6 06 (0x06) Write Single Register ...........................................................................
- 6.7 07 (0x07) Read Exception Status (Serial Line only) ..............................................
- 6.8 08 (0x08) Diagnostics (Serial Line only) ...............................................................
- 6.8.1 Sub-function codes supported by the serial line devices ...........................
- 6.8.2 Example and state diagram ......................................................................
- 6.9 11 (0x0B) Get Comm Event Counter (Serial Line only) .........................................
- 6.10 12 (0x0C) Get Comm Event Log (Serial Line only) ...............................................
- 6.11 15 (0x0F) Write Multiple Coils ..............................................................................
- 6.12 16 (0x10) Write Multiple registers ........................................................................
- 6.13 17 (0x11) Report Slave ID (Serial Line only) ........................................................
- 6.14 20 (0x14) Read File Record .................................................................................
- 6.15 21 (0x15) Write File Record .................................................................................
- 6.16 22 (0x16) Mask Write Register .............................................................................
- 6.17 23 (0x17) Read/Write Multiple registers ...............................................................
- 6.18 24 (0x18) Read FIFO Queue ................................................................................
- 6.19 43 ( 0x2B) Encapsulated Interface Transport .......................................................
- PDU .................................................................................................................... 6.20 43 / 13 (0x2B / 0x0D) CANopen General Reference Request and Response
- 6.21 43 / 14 (0x2B / 0x0E) Read Device Identification ..................................................
- 7 MODBUS Exception Responses ...................................................................................
- MEI TYPES .................................................................................................................. Annex A (Informative): MODBUS RESERVED FUNCTION CODES, SUBCODES AND
- Annex B (Informative): CANOPEN GENERAL REFERENCE COMMAND .............................
1 Introduction
1.1 Scope of this document
MODBUS is an application layer messaging protocol, positioned at level 7 of the OSI model, that provides client/server communication between devices connected on different types of buses or networks.
The industry’s serial de facto standard since 1979, MODBUS continues to enable millions of automation devices to communicate. Today, support for the simple and elegant structure of MODBUS continues to grow. The Internet community can access MODBUS at a reserved system port 502 on the TCP/IP stack.
MODBUS is a request/reply protocol and offers services specified by function codes. MODBUS function codes are elements of MODBUS request/reply PDUs. The objective of this document is to describe the function codes used within the framework of MODBUS transactions.
MODBUS is an application layer messaging protocol for client/server communication between devices connected on different types of buses or networks.
It is currently implemented using:
y TCP/IP over Ethernet. See MODBUS Messaging Implementation Guide V1.0a. y Asynchronous serial transmission over a variety of media (wire : EIA/TIA-232-E, EIA- 422, EIA/TIA-485-A; fiber, radio, etc.) y MODBUS PLUS, a high speed token passing network.
TCP
Modbus on TCP
MODBUS APPLICATION LAYER
IP
Ethernet Physical layer
Ethernet II /802. EIA/TIA-232 or EIA/TIA-
Master / Slave
Physical layer
MODBUS+ / HDLC
Other
Other
Figure 1: MODBUS communication stack
References
- RFC 791, Internet Protocol, Sep81 DARPA
2 Abbreviations
ADU Application Data Unit
HDLC High level Data Link Control
HMI Human Machine Interface
IETF Internet Engineering Task Force
I/O Input/Output
Additional address Function code Data Error check
ADU
PDU
Figure 3: General MODBUS frame
The MODBUS application data unit is built by the client that initiates a MODBUS transaction. The function indicates to the server what kind of action to perform. The MODBUS application protocol establishes the format of a request initiated by a client.
The function code field of a MODBUS data unit is coded in one byte. Valid codes are in the range of 1 ... 255 decimal (the range 128 – 255 is reserved and used for exception responses). When a message is sent from a Client to a Server device the function code field tells the server what kind of action to perform. Function code "0" is not valid.
Sub-function codes are added to some function codes to define multiple actions.
The data field of messages sent from a client to server devices contains additional information that the server uses to take the action defined by the function code. This can include items like discrete and register addresses, the quantity of items to be handled, and the count of actual data bytes in the field.
The data field may be nonexistent (of zero length) in certain kinds of requests, in this case the server does not require any additional information. The function code alone specifies the action.
If no error occurs related to the MODBUS function requested in a properly received MODBUS ADU the data field of a response from a server to a client contains the data requested. If an error related to the MODBUS function requested occurs, the field contains an exception code that the server application can use to determine the next action to be taken.
For example a client can read the ON / OFF states of a group of discrete outputs or inputs or it can read/write the data contents of a group of registers.
When the server responds to the client, it uses the function code field to indicate either a normal (error-free) response or that some kind of error occurred (called an exception response). For a normal response, the server simply echoes to the request the original function code.
Function code (^) Data Request
Client Server
Initiate request
Perform the action Initiate the response
Receive the response
Function code Data Response
Figure 4: MODBUS transaction (error free)
For an exception response, the server returns a code that is equivalent to the original function code from the request PDU with its most significant bit set to logic 1.
Client Server
Initiate request
Error detected in the action Initiate an error
Receive the response Exception Function code Exception code
Function code Data Request
Figure 5: MODBUS transaction (exception response)
) Note : It is desirable to manage a time out in order not to indefinitely wait for an answer which will perhaps
never arrive.
The size of the MODBUS PDU is limited by the size constraint inherited from the first MODBUS implementation on Serial Line network (max. RS485 ADU = 256 bytes).
Therefore:
MODBUS PDU for serial line communication = 256 - Server address (1 byte) - CRC ( bytes) = 253 bytes.
Consequently:
RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC (2 bytes) = 256 bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.
The MODBUS protocol defines three PDUs. They are :
- MODBUS Request PDU, mb_req_pdu
- MODBUS Response PDU, mb_rsp_pdu
- MODBUS Exception Response PDU, mb_excep_rsp_pdu
The mb_req_pdu is defined as:
mb_req_pdu = {function_code, request_data}, where function_code = [1 byte] MODBUS function code, request_data = [n bytes] This field is function code dependent and usually contains information such as variable references, variable counts, data offsets, sub-function codes etc.
The mb_rsp_pdu is defined as:
mb_rsp_pdu = {function_code, response_data}, where function_code = [1 byte] MODBUS function code response_data = [n bytes] This field is function code dependent and usually contains information such as variable references, variable counts, data offsets, sub-function codes, etc.
The example below shows data organization in a device having digital and analog, inputs and outputs. Each block is separate because data from different blocks have no correlation. Each block is thus accessible with different MODBUS functions.
Input Discrete
MODBUS access
Device application memory
MODBUS SERVER DEVICE
Coils MODBUS Request
Input Registers
Holding Registers
Figure 6 MODBUS Data Model with separate block
Example 2: Device having only 1 block
In this example, the device has only 1 data block. The same data can be reached via several MODBUS functions, either via a 16 bit access or via an access bit.
Device application memory
MODBUS SERVER DEVICE
MODBUS Request
Input Discrete
MODBUS access
Coils
Input Registers
Holding Registers
R W
R
W
Figure 7 MODBUS Data Model with only 1 block
4.4 MODBUS Addressing model
The MODBUS application protocol defines precisely PDU addressing rules.
In a MODBUS PDU each data is addressed from 0 to 65535.
It also defines clearly a MODBUS data model composed of 4 blocks that comprises several elements numbered from 1 to n.
In the MODBUS data Model each element within a data block is numbered from 1 to n.
Afterwards the MODBUS data model has to be bound to the device application ( IEC- object, or other application model).
The pre-mapping between the MODBUS data model and the device application is totally vendor device specific.
Discrete Input
Coils
Input Registers
Holding Registers
Device application MODBUS data model
MODBUS PDU addresses
Read Registers 54
Read Registers 1
Read coils 4
Read input 0
Application specific MODBUS Standard
Mapping
Figure 8 MODBUS Addressing model
The previous figure shows that a MODBUS data numbered X is addressed in the MODBUS PDU X-1.
4.5 Define MODBUS Transaction
The following state diagram describes the generic processing of a MODBUS transaction in server side.
5 Function Code Categories
There are three categories of MODBUS Functions codes. They are :
Public Function Codes
- Are well defined function codes ,
- guaranteed to be unique,
- validated by the MODBUS-IDA.org community,
- publicly documented
- have available conformance test,
- includes both defined public assigned function codes as well as unassigned function codes reserved for future use.
User-Defined Function Codes
- there are two ranges of user-defined function codes, i.e. 65 to 72 and from 100 to 110 decimal.
- user can select and implement a function code that is not supported by the specification.
- there is no guarantee that the use of the selected function code will be unique
- if the user wants to re-position the functionality as a public function code, he must initiate an RFC to introduce the change into the public category and to have a new public function code assigned.
- MODBUS Organization, Inc expressly reserves the right to develop the proposed RFC.
Reserved Function Codes
- Function Codes currently used by some companies for legacy products and that are not available for public use.
- Informative Note: The reader is asked refer to Annex A (Informative) MODBUS RESERVED FUNCTION CODES, SUBCODES AND MEI TYPES.
User Defined Function codes
User Defined Function codes
PUBLIC function codes
PUBLIC function codes
PUBLIC function codes
Figure 10 MODBUS Function Code Categories
5.1 Public Function Code Definition
Function Codes code Sub code
(hex) Section
Physical Discrete Inputs
Read Discrete Inputs 02 02 6.
Read Coils 01 01 6. Write Single Coil 05 05 6. Write Multiple Coils (^) 15 0F 6.
Bit access
Internal Bits Or Physical coils
Physical Input Registers
Read Input Register 04 04 6.
Read Holding Registers 03 03 6. Write Single Register 06 06 6. Write Multiple Registers (^) 16 10 6. Read/Write Multiple Registers 23 17 6. Mask Write Register 22 16 6.
16 bits access Internal Registers Or Physical Output Registers Read FIFO queue (^) 24 18 6. Read File record 20 14 6.
Data Access
File record access (^) Write File record 21 15 6. Read Exception status 07 07 6. Diagnostic 08 00-18,20 08 6. Get Com event counter (^) 11 OB 6. Get Com Event Log 12 0C 6. Report Slave ID 17 11 6.
Diagnostics
Read device Identification 43 14 2B 6. Other Encapsulated Interface Transport
43 13,14 2B 6.
MB Server Sends mb_exception_rsp (^) EXIT
MB Server receives mb_req_pdu
ExceptionCode = 01 YES
NO
NO
ExceptionCode = 02 YES
NO
ExceptionCode = 03 YES
ENTRY
ReadDiscreteOutputs == OK
MB Server Sends mb_rsp
NO
YES
0x0001 ≤ Quantity of Outputs ≤ 0x07D
Function code supported
Starting Address == OK AND Starting Address + Quantity of Outputs == OK
ExceptionCode = 04
Request Processing
Figure 11: Read Coils state diagram
6.2 02 (0x02) Read Discrete Inputs
This function code is used to read from 1 to 2000 contiguous status of discrete inputs in a remote device. The Request PDU specifies the starting address, i.e. the address of the first input specified, and the number of inputs. In the PDU Discrete Inputs are addressed starting at zero. Therefore Discrete inputs numbered 1-16 are addressed as 0-15.
The discrete inputs in the response message are packed as one input per bit of the data field. Status is indicated as 1= ON; 0= OFF. The LSB of the first data byte contains the input addressed in the query. The other inputs follow toward the high order end of this byte, and from low order to high order in subsequent bytes.
If the returned input quantity is not a multiple of eight, the remaining bits in the final data byte will be padded with zeros (toward the high order end of the byte). The Byte Count field specifies the quantity of complete bytes of data.
Request
Function code 1 Byte 0x Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Inputs 2 Bytes 1 to 2000 (0x7D0)
Response
Function code 1 Byte 0x Byte count 1 Byte N * Input Status N * x 1 Byte
- N = Quantity of Inputs / 8 if the remainder is different of 0 ⇒ N = N+ Error
Error code 1 Byte 0x
Exception code 1 Byte 01 or 02 or 03 or 04
Here is an example of a request to read discrete inputs 197 – 218: Request Response Field Name (Hex) Field Name (Hex) Function 02 Function 02 Starting Address Hi 00 Byte Count 03 Starting Address Lo C4 Inputs Status 204-197 AC Quantity of Inputs Hi 00 Inputs Status 212-205 DB Quantity of Inputs Lo (^) 16 Inputs Status 218-213 (^) 35
The status of discrete inputs 204–197 is shown as the byte value AC hex, or binary 1010
- Input 204 is the MSB of this byte, and input 197 is the LSB.
The status of discrete inputs 218–213 is shown as the byte value 35 hex, or binary 0011
- Input 218 is in the third bit position from the left, and input 213 is the LSB.
) Note : The two remaining bits (toward the high order end) are zero filled.
MB Server Sends m b_exception_rsp (^) EXIT
MB Server receives m b_req_pdu
ExceptionCode = 01 YES
NO
NO
ExceptionCode = 02 YES
NO
ExceptionCode = 03 YES
ENTRY
ReadDiscreteInputs == OK
MB Server Sends m b_rsp
NO
YES
0x0001 ≤ Quantity of Inputs ≤ 0x07D
Function code supported
Starting Address == OK AND Starting Address + Quantity of Inputs == OK
ExceptionCode = 04
Request Processing
Figure 12: Read Discrete Inputs state diagram
MB Server Sends mb_exception_rsp EXIT
MB Server receives mb_req_pdu
ExceptionCode = 01 YES
NO
NO
ExceptionCode = 02 YES
NO
ExceptionCode = 03 YES
ENTRY
ReadMultipleRegisters == OK
MB Server Sends mb_rsp
NO
YES
0x0001 ≤ Quantity of Registers ≤ 0x007D
Function code supported
Starting Address == OK AND Starting Address + Quantity of Registers == OK
ExceptionCode = 04
Request Processing
Figure 13: Read Holding Registers state diagram
6.4 04 (0x04) Read Input Registers
This function code is used to read from 1 to 125 contiguous input registers in a remote device. The Request PDU specifies the starting register address and the number of registers. In the PDU Registers are addressed starting at zero. Therefore input registers numbered 1- are addressed as 0-15.
The register data in the response message are packed as two bytes per register, with the binary contents right justified within each byte. For each register, the first byte contains the high order bits and the second contains the low order bits.
Request Function code 1 Byte 0x Starting Address 2 Bytes 0x0000 to 0xFFFF Quantity of Input Registers 2 Bytes 0x0001 to 0x007D
Response Function code 1 Byte (^) 0x Byte count 1 Byte (^) 2 x N * Input Registers N * x 2 Bytes
- N = Quantity of Input Registers
Error Error code 1 Byte 0x Exception code 1 Byte 01 or 02 or 03 or 04
Here is an example of a request to read input register 9: Request Response Field Name (Hex) Field Name (Hex) Function (^) 04 Function (^) 04 Starting Address Hi (^) 00 Byte Count (^) 02 Starting Address Lo 08 Input Reg. 9 Hi 00
Quantity of Input Reg. Hi 00 Input Reg. 9 Lo 0A Quantity of Input Reg. Lo 01
The contents of input register 9 are shown as the two byte values of 00 0A hex, or 10 decimal.
MB Server Sends mb_exception_rsp EXIT
MB Server receives mb_req_pdu
ExceptionCode = 01 YES
NO
NO
ExceptionCode = 02 YES
NO
ExceptionCode = 03 YES
ENTRY
ReadInputRegisters == OK
MB Server Sends mb_rsp
NO
YES
0x0001 ≤ Quantity of Registers ≤ 0x007D
Function code supported
Starting Address == OK AND Starting Address + Quantity of Registers == OK
ExceptionCode = 04
Request Processing
Figure 14: Read Input Registers state diagram
6.5 05 (0x05) Write Single Coil
This function code is used to write a single output to either ON or OFF in a remote device.
The requested ON/OFF state is specified by a constant in the request data field. A value of FF 00 hex requests the output to be ON. A value of 00 00 requests it to be OFF. All other values are illegal and will not affect the output.
The Request PDU specifies the address of the coil to be forced. Coils are addressed starting at zero. Therefore coil numbered 1 is addressed as 0. The requested ON/OFF state is specified by a constant in the Coil Value field. A value of 0XFF00 requests the coil to be ON. A value of 0X0000 requests the coil to be off. All other values are illegal and will not affect the coil.
The normal response is an echo of the request, returned after the coil state has been written. Request Function code 1 Byte (^) 0x Output Address 2 Bytes 0x0000 to 0xFFFF Output Value 2 Bytes 0x0000 or 0xFF
MB Server Sends mb_exception_rsp (^) EXIT
ExceptionCode = 04
MB Server receives mb_req_pdu
ExceptionCode = 01 YES
NO
NO
ExceptionCode = 02
YES
NO
ExceptionCode = 03 YES
ENTRY
WriteSingleOutput == OK
MB Server Sends mb_rsp
NO
YES
Output Value == 0x OR 0xFF
Function code supported
Output Address == OK
Request Processing
Figure 15: Write Single Output state diagram
6.6 06 (0x06) Write Single Register
This function code is used to write a single holding register in a remote device.
The Request PDU specifies the address of the register to be written. Registers are addressed starting at zero. Therefore register numbered 1 is addressed as 0.
The normal response is an echo of the request, returned after the register contents have been written.
Request Function code 1 Byte 0x Register Address 2 Bytes 0x0000 to 0xFFFF Register Value 2 Bytes 0x0000 to 0xFFFF
Response Function code 1 Byte 0x Register Address 2 Bytes 0x0000 to 0xFFFF Register Value 2 Bytes 0x0000 to 0xFFFF
Error Error code 1 Byte 0x Exception code 1 Byte 01 or 02 or 03 or 04
Here is an example of a request to write register 2 to 00 03 hex: Request Response Field Name (Hex) Field Name (Hex) Function 06 Function 06 Register Address Hi 00 Register Address Hi 00 Register Address Lo 01 Register Address Lo 01 Register Value Hi (^) 00 Register Value Hi (^) 00 Register Value Lo (^) 03 Register Value Lo (^) 03
MB Server Sends mb_exception_rsp EXIT
ExceptionCode = 04
MB Server receives mb_req_pdu
ExceptionCode = 01 YES
NO
NO
ExceptionCode = 02
YES
NO
ExceptionCode = 03 YES
ENTRY
WriteSingleRegister == OK
MB Server Sends mb_rsp
NO
YES
0x0000 (^) ≤ Register Value (^) ≤ 0xFFFF
Function code supported
Register Address == OK
Request Processing
Figure 16: Write Single Register state diagram
6.7 07 (0x07) Read Exception Status (Serial Line only)
This function code is used to read the contents of eight Exception Status outputs in a remote device.
The function provides a simple method for accessing this information, because the Exception Output references are known (no output reference is needed in the function).
The normal response contains the status of the eight Exception Status outputs. The outputs are packed into one data byte, with one bit per output. The status of the lowest output reference is contained in the least significant bit of the byte.
The contents of the eight Exception Status outputs are device specific.
Request Function code 1 Byte 0x
Response Function code 1 Byte (^) 0x Output Data 1 Byte 0x00 to 0xFF
Error Error code 1 Byte 0x Exception code 1 Byte 01 or 04
Here is an example of a request to read the exception status: Request Response Field Name (Hex) Field Name (Hex) Function (^) 07 Function (^) 07 Output Data 6D
