How machines communicate: Modbus protocol

How machines communicate: Modbus protocol



The Modbus protocol is the most common industry protocol for M2M interaction. It is a de facto standard and is supported by almost all manufacturers of industrial equipment.

Due to its versatility and openness, the standard allows the integration of equipment from different manufacturers. Modbus is used to collect readings from sensors, control relays and controllers, monitoring, etc.

In the article we will analyze the implementation of the Modbus protocol, data formats, software for working with the protocol. Let's try to read the data from the device in practice.

Modbus history


Modbus was introduced in 1979 by Modicon (now Schneider Electric). It was an open standard working on the RS-232 interface. Later, a protocol implementation for RS-485 and Modbus TCP interfaces appeared. The protocol quickly gained popularity, and many manufacturers began to implement it in their devices.

Later, the rights to the protocol were transferred to the non-profit organization Modbus Organization , which still owns the standard.

The Modbus standard description uses terminology inherited from the relay logic languages. For example, some registers are called coils (English coil).

Physical Level




  • RS-232/422/485 - serial interfaces widely used in industry. RS-422/485 interfaces provide signal range up to 1200 meters. Modbus RTU/ASCII protocols are used
  • TCP/IP networks - any ethernet interfaces can be used as physical data transfer channels. Modbus TCP protocol used

Logic Level



Differences between Modbus protocols

Modbus ASCII


The data is encoded with characters from an ASCII table and transmitted in hexadecimal format. The beginning of each package is indicated by a colon, and the end by a carriage return and line break. This allows the protocol to be used on high-latency lines and equipment with less accurate timers.

Modbus RTU


In the Modbus RTU protocol, the data is encoded in binary format, and the time slot is used as a packet delimiter. This protocol is critical for delays and cannot work, for example, on modem lines. In this case, the overhead of data transmission is less than in Modbus ASCII, since the length of the messages is less.

Modbus TCP


The packet structure is similar to Modbus RTU, the data is also encoded in binary format, and packed into a regular TCP packet, for transmission over IP networks. The integrity check used in Modbus RTU does not apply, as TCP already has its own integrity control mechanism.

Package Format



Formats of a package of various Modbus implementations

All Modbus devices interact by following the master-slave model. Requests can be initiated only by a master device, slaves can only respond to requests, and cannot start data transmission on their own. Depending on the implementation of the protocol, the packet headers differ. Here are the main components of the package, which is important to know:

The ADU (Application Data Unit) is the entire Modbus package, with all the headers, PDUs, checksum, address, and markers.It differs, depending on the implementation of the protocol.

The PDU (protocol data unit) is the main part of the packet, the same for all protocol implementations. Contains payload itself.

Device Address is the address of the receiver, that is, the slave device. Up to 247 devices can be located in one segment of the Modbus network. Only slaves have different addresses, the master has no addresses. The address “0” is used for broadcast requests from master, and slaves cannot respond to these broadcast packets.

Checksum - packet integrity checking algorithms. Modbus RTU and ASCII use 2 bytes of checksum. The Modbus RTU uses the CRC16 algorithm, while the Modbus ASCII uses a simpler and less reliable LRC8. In Modbus TCP, the checksum is not added to the ADU, since integrity is checked at the TCP level.

We will not analyze additional headers specific to each individual implementation of the protocol, since this is not significant when working with the protocol at the application level.

Modbus Registers and Functions


In simplified form, the Modbus request structure consists of a function code (read/write), and data that must be read or written. At the same time, function codes are different for different data types. Let us examine what are the registers, and functions for working with them.

< br/>
  • Discrete Inputs - discrete inputs of the device, available only for reading. The range of addresses of registers: from 10001 to 19999. They have the function "02" - reading a group of registers
  • Coils - discrete device outputs, or internal values. Available for reading and writing. The range of addresses of registers: from 20001 to 29999. It has functions: “01” - reads a group of registers, “05” - writes one register, “15” - writes a group of registers
  • Input Registers - 16-bit device inputs. Read only. The range of addresses of registers: from 30001 to 39999. They have the function: "04" - reading a group of registers
  • Holding Registers - 16-bit device outputs, or internal values. Available for reading and writing. The address range of registers: from 40001 to 49999. Have

Despite the names, the inputs and outputs can actually be internal variables, store counters, flags, or be control triggers. There are also other register ranges, but in the vast majority of devices they are not used, so we will look at four basic types of registers. Different ranges of registers can be used in different devices, or all at once.

Work Examples


For an example of working with the Modbus TCP protocol, we will use the simplest console utility modbus-cli , written in the Ruby language. It makes it easy to read and write data in the Modbus registers.

Let's try to read the state of the transmitted packet counters on the Advantech EKI-5524SSI industrial switch. First you need to determine the addresses of registers that store the necessary information. To do this, look in the documentation devices. Register descriptions are in the “Modbus Mapping Table” section:


For a description of the register values ​​in the EKI switch documentation

It can be seen that the value of the transmitted packets for one port is stored in four registers, and for the first port it is registers from 38193 to 38197. A description is also given of the data storage format, from which it follows that an integer number of transmitted packets is stored in hexadecimal format, and the value of 11223344 packets will be written as 0xAB4130, from right to left.

Make a query:

  $ modbus read 192.168.0.17 38193 4
 38193 0x0000
 38194 0x0000
 38195 0x0000
 38196 0x3459
  

read is a read command. The program itself understands what specific read command to use depending on the register address, in our case the “04” command will be used to read 16-bit registers.

192.168.0.17 —The device’s IP address.

38193 is the starting address of the register.

4 is the offset from the starting address. We read four registers for port 1, as follows from the datasheet.

We receive the answer containing values ​​of four registers. We see that the number of packets is small: 0x3459, that is, 13401, - the switch has been switched on recently.

Modbus protocol flaws


In fairness, it is worth mentioning the shortcomings of the protocol. Since it was developed over 40 years ago, when the processor performance was significantly lower and the protocols were developed without considering data protection, it has a lot of minuses:

  • The protocol does not provide for authentication and encryption of transmitted data. Therefore, when using Modbus TCP, you must use additional VPN tunnels.
  • The slave cannot initiate data transfer, so the master must constantly poll the slaves
  • Slave device cannot detect loss of communication with Master. This problem follows directly from the previous one.

However, despite all the shortcomings, Modbus is still the most common industrial protocol, and due to its openness, makes it easy to combine devices from different manufacturers. Low demand for resources allows integrating the protocol into the most low-power devices.

Equipment with Modbus support


Advantech offers a wide range of industrial equipment with Modbus protocol support for any tasks: automation, control, data collection and transmission.

ADAM-6000 and WISE-4000 - remote input-output modules <>.

ADAM-6000 and WISE-4000 allow you to remotely control digital and analog I/Os using the Modbus TCP protocol. Used to control peripheral devices and collect data in slave mode. Can work together with a programmable logic controller, or connect directly to a SCADA server. ⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀


To convert Modbus RTU/ASCII protocols to Modbus TCP, Modbus gateways are used. Series devices
EKI-1200 are on the control board modat & modbus & amp; -232/422/485, and two Ethernet ports. They allow you to combine devices with different protocols into one network, for example, connect a slave device that supports only Modbus RTU via an RS-485 interface to a Modbus TCP network segment.



Application Examples


Greenhouse Monitoring System


The Advantech monitoring solution integrates the TPC-1070H, ADAM-6024, ADAM-6050, ADAM-6060 devices and WebAccess software in an enclosure near agricultural land. By connecting to various sensitive devices, the ADAM-6000 modules can obtain real-time environmental data and control equipment switching to ensure that the greenhouse is in an optimal environment for plant growth. Thanks to Advantech’s special feature — graphical condition logic (GCL), users can define their own control logic rules and load these rules into the ADAM-6000 Ethernet I/O modules, and then the modules automatically execute the logic rules as stand-alone modules. controller. Another feature - Peer-to-Peer (P2P) uses the most open and flexible Ethernet network to not only simplify the implementation process without a controller, but also save hardware costs.

All received data is then transmitted via Ethernet to a computer with a TPC-1070H touch panel. Thanks to the cooling system without a fan and a front panel that complies with the IP65 standard, the TPC-1070H is a robust and compact design suitable for a variable operating environment, and its powerful computing capabilities are capable of processing large amounts of data. To manage devices, Advantech WebAccess allows engineers or managers to view, control, and configure a monitoring system via an intranet or the Internet using a standard web browser from any device, including tablets and smartphones.



Monitoring of solar water heating systems


The engineering company had to be able to control the amount of solar energy, temperature and water consumption in the solar water heating system for an Olympic-sized pool provided by their newly developed solar panel. They should also be able to directly monitor these values ​​and their alarms on LCD panels and save these values ​​for future use.

Advantech's Adam modules provided a solution to the customer that used data acquisition modules connected via RS485 and a two-wire bus to transfer data from all sensors. This system architecture has two main advantages: first, it allows you to add more sensors of data acquisition modules to the system at any time, and, second, it is very easy to add additional tags to the software for monitoring and recording these values ​​on a PC.

Source text: How machines communicate: Modbus protocol