directory

1. Brief Introduction to the Agreement

2. Protocol format

3. Data model

1. Brief Introduction to the Agreement

Modbus has enabled thousands of automated devices to communicate since the advent of the de facto standard for industrial serial links in 1979. Modbus is an application-layer packet transport protocol at Layer 7 of the OSI model that provides client/server communication between devices connected to different types of buses or networks. Modbus application layer protocols and service specifications mainly include two types: One is Modbus over serial links (Modbus serial links depend on TIA/EIA standards: 232-F and 485-A), and Modbus over TCP/IP (Modbus TCP/IP depends on the IETF standard: RFC793 is related to RFC791). The schematic diagram of Modbus communication stack is as follows:

The Modbus protocol allows simple communication within a variety of network architectures. Every device (PLC, HMI, control panel, driver, motion control, input/output device) can use Modbus to initiate remote operations. The same communication is possible on Modbus based on serial links and Ethernet TCP/IP networks, and some gateways allow communication between several buses or networks using the Modbus protocol. An example of Modbus network architecture is shown below:

2. Protocol format

Modbus protocol is essentially the same as our usual custom protocol. It is a data transmission format, which is also composed of start frame, data frame, check frame, etc. Modbus protocol is more standardized.

Modbus protocol defines a simple protocol data unit (PDU) independent of the basic communication layer. Modbus protocol mapping on a specific bus or network enables the introduction of additional domains on the application Data Unit (ADU). The common Modbus frame protocol is shown below:

Specific analysis is as follows:

  • Address domain: address information of child nodes.

  • Function code: specify the server to perform the action, the effective is a decimal code word range 1-255 (128-255 reserved for abnormal response), when the device from the client to the server to send a message, what kind of operation function code domain notification server performs (function code content more, suggest to consult the Modbus protocol instruction manual, clearly described above).

  • Data: The content of the transmitted data, in some request, the data can be nonexistent (0 length), in which case the server does not require any additional information, work

    The energy code only describes the operation.

  • Error check: verify whether the data received and sent are correct.

If there are no errors associated with requesting Modbus functionality in a properly received Modbus ADU, the server-to-client response data field includes the request data. If there is an error related to requesting Modbus functionality, the field includes an exception code that the server application can use to determine the next operation to be performed. Modbus transaction status diagram is shown below:

Once the server processes the request, Modbus response is established using the appropriate Modbus server transaction. Depending on the result of processing, two types of response can be established:

  • A correct Modbus response: Response function code = request function code;
  • A Modbus exception response: Used to provide the client with information related to the error detected during processing, providing an exception code to indicate the cause of the error. Response function code = Request function code + 0x80

Breaking down the above diagram, for example, the client and server execute the Modbus communication protocol, and when the server responds to the client, it uses a function code to indicate either a normal (error-free) response or some kind of error (called an exception response).

For a normal response, the server responds only to the raw function code, and Modbus transactions (error-free) are as shown below:

For abnormal response, the server returns a code equivalent to the original function code and sets the most significant bit of the original function code as logic 1. Modbus transaction processing (abnormal response) is shown in the figure below:

Modbus uses a big-endian to represent addresses and data items. This means that when transmitting multiple bytes, the most significant bits are sent first. Such as:

Register data 0x4001 0x1234Copy the code

The first byte sent is 0x12 and the first byte is 0x34.

3. Data model

Modbus is based on a series of data models on tables with different characteristics. The four basic tables are shown in the following table:

For any one of the basic tables, the protocol allows 65536 data items to be selected individually, and the read and write operations of those items can be designed over multiple consecutive data items up to the data size limit, which is related to the transaction function code.

The concept of a data model is a limited abstraction, so let’s take a look at the following two examples.

Example 1: A device with four separate blocks

Example Description: A data structure in a device containing digital and analog quantities, inputs and outputs. Because the data in different blocks is not related, each block is independent of the other. Modbus data model is used to access each block according to different Modbus function codes. The implementation principle is as follows:

Example 2: A device with only one block

Example Description: A device has only one data block. Using Modbus data model, the same data may be obtained through several Modbus function codes, or through 16-bit access or one access bit. The implementation principle is as follows: