Modbus is a communication protocol commonly used in industrial automation systems, smart home systems, automated networks of small objects (warehouses, greenhouses, etc). The protocol serves for connecting equipment of various types to a home computer as well. The development of such projects as Arduino and Raspberry Pi has significantly increased interest in tasks related to robotics and automation. All this ensures the growth of Modbus popularity among amateurs and professionals.
In this article, we'll cover the key features of the existing software and hardware solutions for testing and debugging devices and networks based on Modbus protocol.
If you are familiar with the architecture of the protocol, you can jump right to the description of Modbus software. If not, below you will find a short introduction into Modbus.
- About Modbus protocol
- Developing and testing Modbus devices
- Debugging of automation systems based on Modbus devices
About Modbus protocol
Modbus is a common protocol used in automation systems at the middle and lower (field) levels. The middle level is the level of controllers - devices that collect data and control the technological process. The field level is the level of interaction between sensors and controllers or sensors and the server. More details about the levels in automation systems can be found here.
The typical structure of an automation system that uses Modbus as its basic protocol is shown below.
The standard 'environment' for Modbus protocol is RS-485/422/232. Modbus RTU or Modbus ASCII work over it. In TCP/IP networks, however, the higher level protocol is TCP transport protocol and this variant is called Modbus TCP. In this article, we'll talk about Modbus RTU transmission mode.
Modbus protocol is implemented using a master-slave relationship. That means communication is always initiated by one device, the master, which sends a request to a slave (server) and waits for a response. There is always one master on the network and from 1 to 247 slaves. (More information about Modbus devices can be found on the Modbus official website).
The master interacts with slave devices in the request-response format. The request contains a sequence of bytes, called a frame, in which the time between bytes is standardized depending on the data transfer rate and is no longer than the interval during which 1.5 bytes of data can be transmitted. In RTU mode, messages start with a silent interval of at least 3.5 character times.
A request message is sent in the following format:
ID - device address (1 byte),
FN - Modbus function (1 byte),
[args] - function arguments (N bytes, depending on the function),
CRC - a checksum CRC-16 (2 bytes).
The format of a response message:
As you can see, the response and request frames have similar constructions, except for the Data field, which provides different content depending on the function performed.
In case the requested function is not supported by the slave device or the arguments in the [args] field of the request are incorrect for this server, in the FN field of the response the high bit will be set to 1 and the Data field will contain additional information on the error occurred.
Also, particular slave devices can have specific registers with additional information.
The types of registers referenced in Modbus devices include the following:
|Discrete Inputs||used as inputs|
|Coils Outputs||used to control discrete|
|Input registers||used for input|
|Holding registers||used for a variety of things including inputs, outputs, configuration data, etc.|
The full description of the Modbus RTU protocol is provided in its functional specification.
When setting up a Modbus network, a point to consider is that the protocol enables the transmission of data from multiple devices that are to be received by a single server or controller that has a Modbus driver installed. A serial app can control a server’s communication port (ex. COM1) as it receives Modbus data from multiple sensors.
Unfortunately there is a limitation, as opening the receiving port in multiple applications simultaneously can pose a significant challenge.
There is a solution to this dilemma. Virtual COM Port Driver PRO by Eltima allows the creation of virtual RS485 ports and the splitting of Modbus data so multiple ports can receive the data at the same time.
You can now duplicate the data stream coming into one physical port to multiple virtual ports. By connecting several applications to virtual copies of your COM1 port, all of the apps can achieve shared access to your physical port.
Developing and testing Modbus devices
When developing and debugging Modbus RTU devices, experts use specialized software and hardware tools. As for hardware devices, the simplest solution will be RS-485/USB converter. Of all the devices of this type, probably the most efficient solution is MOXA UPORT 1130/UPORT 1150. The device is designed to be easy to use and requires minimal skills to be assembled. There are also more complex solutions like Ethernet/RS-485 (for example, NPORT from MOXA).
In practice, when it comes to the development of Modbus RTU devices, slave function is implemented more often. Slave devices include various sensors, controlled relays, I/O modules, etc. Master devices are created less often. In automation networks, the master function is usually performed either by a controller, which already has a Modbus stack implemented, or an OPC Server/SCADA system equipped with a Modbus driver.
We won't consider the development of Modbus stack right in this article. The only thing worth mentioning is the FreeMODBUS library, on the basis of which it is quite easy to build a device supporting Modbus slave functions.
Efficient software for Modbus testing
Testing can be performed on different levels of Modbus device development. The Modbus test software and hardware solutions differ depending on the stage of development and the purpose of testing.
One of the most convenient tools used in the initial stages of device testing is Modbus terminal. This solution helps manually create a request, send it, and analyze the response.
During the development process, a situation may arise when a device receives a request and responds to it (this can be either indicated by the packet reception/transmission LEDs, if such elements are provided in the design, or detected by using a debugger and setting a breakpoint) but the data is not displayed in the terminal or another specialized program. In this case, you will need a dedicated serial port sniffer.
Serial Port Monitor is one of the best Modbus monitoring software available today. This Modbus solution can easily read and record any serial data going through system's COM ports. The advanced functionality of the app allows capturing data in real time so that a developer can resolve all problems once they have been detected.
Serial Port Monitor is able to work in the terminal mode that is emulate transferring data from a monitored COM port to a device inserted into it. This option is especially convenient for Modbus communication test, as it allows observing the reaction of a particular device to a specific command and data.