“This is the first day of my participation in the Gwen Challenge in November. Check out the details: The last Gwen Challenge in 2021”

1. What is Modbus

Basically, Modbus is an application layer protocol used for communication between devices for exchanging data typical of automation.



At this level, Modbus is a stateless client-server protocol (much like HTTP, for example) based onThe transaction, it is composed ofrequest(issued by the client) andThe response(sent by the server). In the area where this protocol is commonly applied, there is the concept of one of the possible modes for controlling lower-level communication behavior on a network using shared signal cables: master slave. To prevent confusion, the following directed relationships describe master and slave according to the client-server paradigm:

Master

The primary site corresponds to —-> client

Slave Slave corresponds to —–> server

2. Modbus protocol parsing

Stateless communication is based on a simple packet called a protocol data unit (PDU). The protocol specification defines three types of PDUs:

  • Request PDUs, including:

    1. The specifiedFunction code(Function code, 1 byte)
    2. And function-specific data (Functional data, variable number of bytes)

  • Response to PDU, including:

    1. Request corresponding function code (Function Code, 1 byte)
    2. And response specific data (The response data, variable number of bytes)

  • Abnormal responses to PDUs include:

    1. Request function code +0x80 (128), (Error code, 1 byte)
    2. As well as the specifiedException code(Exception code, 1 byte)

2.1 Modbus function

Each function is assigned a specific function code. They range from 1-127 (decimal), because 129 (that is, 1+128) to 255 (that is, 127+128) represents the range of error codes. Function codes are part of the protocol. Function codes are classified into the following three types: one is the function specified in the protocol. Users can also customize functions

  • Public

    Are guaranteed to be unique and specify clearly defined functions for public records. These are verified by the community and conformance tests exist.
    • Read discrete input
    • Read and write the coil
    • Read input register
    • Read/write hold register
  • User-defined can be used for user-defined functions, so their code may not be unique. The specification defines code ranges 65-72 and 100-110 for user-defined functions.
  • These are currently used by some companies for legacy products and cannot be used publicly

The documentation for the function includes:

  1. A description of the function (its purpose), its arguments, and return values (including possible exceptions).
  2. Assigned function code
  3. Request the PDU
  4. Response PDU
  5. Abnormal response PDU

2.2 Modbus data model

Modbus functions are based on these data models

Discrete input

  • type

    a

  • Right to use

    read-only

  • visual

Discrete output (coil)

  • type

    a

  • Right to use

    Read and write

  • visual

Input register

  • type

    A 16-bit word

  • Right to use

    read-only

  • visual

Keep Register

  • type

    A 16-bit word

  • Right to use

    Read and write

  • visual

3. Modbus implementation

3.1 Serial Modbus implementation

Modbus began its life as an implementation of asynchronous serial network communication. Application layer protocols run directly on top of serial interfaces and serial communication standards. The most common (via wire) are:

  • RS232 (EIA232) : See rs232@ Wikipedia
  • RS422: See eia422@wikipedia
  • RS485: see EIA 485 @ Wikipedia **

The EIA422 is a bi-directional extension of RS232 for point-to-point communication over short distances in industrial environments, and also supports longer distances. EIA485 can be used for multipoint communication (that is, multiple devices connected to the same signal cable) in master-slave mode (one master station and N fixed address slave stations).

Figure 4 shows the possible network Settings.

To enable the actual communication of this setting, the implementation extends the PDU with additional fields, or better yet, it wraps the PDU in a package with a header and error checksum (see Figure 5). The resulting package is defined by the protocol specification as an application data unit (ADU) with a maximum package size of 256 bytes.

notes
The maximum package size limit of 256 bytes applies to all existing Modbus protocol implementations (traditional)!

The header consists of the address field (1 byte) and the tail is the error checksum for the entire package, including the address field (that is, the header). For transmission, Modbus messages, or ADU, are put into a frame with known start and end points, allowing detection of the start and end of the message, and thus detection of parts of the message. There are two transport modes that differ in encoding, framing, and checksum:

  1. ASCII

    Frames are encoded as two ASCII characters per byte, representing the hexadecimal representation of the byte (that is, characters 0-9, A-f). Error check sum by longitudinal redundancy check (LRC; 1 byte) indicates that the message begins with a colon (‘:’, 0x3A) and ends with a carriage return – newline character (” CRLF “, 0x0D0A). There may be a one-second pause between characters.

  2. RTU

    Frames are transmitted in binary to achieve higher densities. The error check sum consists of cyclic redundancy check (16-bit CRC; 2 bytes) indicates that the message starts and ends with a silent interval of at least 3.5 character times. This is most easily implemented as a multiple of the character time of the baud rate being used on the network. The maximum pause that can occur between two bytes is 1.5 characters.

Jamod is designed to support two transport modes, using an implementation based on the Javax.com M API.

warning
RTU implementation supports only Master side. It shall, in accordance with thebestPrinciple works, which means it may not work in a reliable manner in a low-latency real-time environment.

It is indeed possible to implement serial transfers based on other serial stack implementations (alternatives to Java Comm API implementations), such as SerialPort (www.sc-systems.com/products/se…) It supports about 20 platforms, according to product information, and has been successfully used to implement two serial transport modes in Java (Master only, see Field Talk/Java, Focus Engineering’s commercial Master protocol package).

3.2 Ip-based Modbus implementation

A TCP/ IP-based Modbus protocol implementation (Modbus/TCP) has recently been submitted to the IETF as a draft RFC. It communicates using the TCP/IP stack (registered port 502) and extends the PDU with ip-specific headers (see Figure 6).

Possible network Settings are not constrained by the specification; Multiple master systems can be established or two-way communication (that is, simultaneous master and slave nodes) can be achieved. However, users should be well aware that deviations from master/slave patterns can have an impact.

The IP specific header (called MBAP in the specification) is seven bytes long and consists of the following fields:

  1. It’s used for trading matchesCall id(2 bytes); Formerly known asTransaction identifier
  2. The ModbusProtocol identifier(2 bytes), is 0 for Modbus default; Reserved for future extensions
  3. messageThe length of the(2 bytes), the byte count of all subsequent bytes
  4. Used to identify a remote unit on a non-TCP /IP networkUnit identifier(1 byte)

4, summarize

This article translated from Modbus Java version of the official document jamod official document at http://jamod.sourceforge.net/kb/protocol.html