Serial Port Monitor by Eltima is a Modbus RTU software. It is a comprehensive and full-featured application that enables the monitoring and analysis of all Modbus RTU interface activity on your system. Any devices supporting the RS232, RS485, and RS422 protocols can have their transmissions monitored and analyzed to assist in debugging or development tasks.
This software tool has been designed with a flexible and user-friendly interface, built-in terminal, and data exporting capabilities. It is a valuable resource for diagnosing Modbus RTU communication issues in the Windows environment. Here are some highlights from the list of features that are part of Serial Port Monitor.
- Analysis of Modbus RTU activity. This serial port sniffer can open any serial port, even those already opened by another application, and immediately begin monitoring all activity moving through that interface. Real-time data collection lets you quickly track down issues and problems. The monitored data can be redirected to files or copied to the clipboard to be used for later analysis.
- Monitor multiple serial ports simultaneously. Using this feature lets you watch your applications interacting with multiple ports or devices within the same monitoring session. The captured data is presented in a first-in-first-out basis in a central log file to simplify its analysis.
- Choose between multiple data views. There are four views that can be used separately or seen all at the same time. They are the table, line, dump, and terminal modes and they can each offer a different insight into your data. The dump view lets you investigate port settings, and you can employ monitoring filters to reduce screen clutter and concentrate on the events that are important.
- Emulation of data transmission. You can send data to serial devices in various formats such as string, binary, decimal, and hex to monitor the reaction of the serial device to specific commands or data strings.
- Session playback option. You can repeat a transmission to a serial port to obtain more precise monitoring information. Sessions can be compared with each other and differences automatically highlighted for easy analysis.
- Export monitored data in various formats. You can export your data to a file in HTML, ASCII text, UNICODE text or Exсel CSV format and can have currently monitored data appended to a previously saved file.
- User-friendly interface. Serial Port Monitor is designed to allow access to serial ports and interfaces without the need for any programming skills. Filters to control the data displayed are easily customized in the application’s toolbar.
- Track input/output control codes. You can obtain the complete details and parameters of all serial input/output control codes (IOCTLs) using Serial Port Monitor.
This Modbus RTU protocol analyzer should be in the toolbox of anyone who works extensively with serial devices and the Modbus protocol. You can use it in either RTU or ASCII mode, making it a versatile software utility. It is an efficient solution that allows you to monitor all of the serial interfaces on your system with no additional hardware requirements. Eltima’s Serial Port Monitor runs on the Windows 10 operating system as well as Windows Server 2012 and 2016.
How does Modbus RTU work?
The Modbus protocol is basically a system that processes requests and responses from electronic devices. The master/slave architecture is used with the master making requests that are responded to by the slave devices.
What is a Modbus RTU master?
A Modbus RTU master is the central device that makes requests for information from the connected slave devices. A central controller in an automated production system can play the role of a Modbus RTU master. A Modbus implementation has one master. Master devices obtain information from the slaves and can also write to the registers of the slave devices.
What is a Modbus RTU slave?
The Modbus RTU slave is the device that responds to the request made by the master device. It cannot initiate information transfers and is in a holding pattern until responding to a request made by the master.
As stated, there is one master device in a Modbus RTU implementation and there can be up to 247 slave devices. Each slave device is identified by a slave address of from 1 to 247.
At the heart of the Modbus protocol is the component known as the Protocol Data Unit (PDU). The PDU consists of a function code and data and is constructed consistently regardless of the Modbus transmission mode used. The function code specifies what data is being requested by the master.
In the Modbus RTU transmission mode, additional information is wrapped around the PDU to create the full Application Data Unit (ADU). In the signal stream and before the function code, in Modbus RTU mode a slave ID of 1 byte is sent to identify the slave device that should satisfy the request. Appended to the PDU is a 2 byte CRC which makes sure that the right amount of bytes were sent and received.
Modbus devices support four data tables which are used to facilitate communication between devices. They are Discrete Inputs, Discrete Outputs (Coils), Input Registers, and Holding Registers. The registers perform different functions and are not all included in every device. In some cases, only the holding registers are used for I/O functionality.
|Field ||Access ||Size ||Description |
|Discrete Inputs ||only reading ||1 bit ||used as inputs |
|Coils Outputs ||reading/writing ||1 bit ||used to control discrete |
|Input registers ||only reading ||16 bit ||used for input |
|Holding registers ||reading/writing ||16 bit ||used for a variety of things including inputs, outputs, configuration data, etc. |
Function codes indicate how the master interacts with the slave device specified in the slave ID. Based on the function code sent, the master device may read one of the slave’s registers, or write to them.
Slaves return error codes when they receive a packet that contains an error in the request. Error codes are returned for issues such as the request for an illegal function, illegal register addresses that cannot be reached by the specified slave, and messages indicating that the slave device is busy or has experienced a failure.
Modbus RTU requires that you know or define parameters such as baud rate, character format (8 bits no parity, etc), and slave ID when initiating communication. A mismatch in any of these parameters will result in the failure of your communication attempt.
Modbus RTU vs TCP
Modbus RTU is one of the original transmission modes that were defined in the Modbus protocol. Modbus TCP is a recently developed extension to the protocol that allows Modbus protocols to be carried over TCP/IP networks. The inherent latency and other aspects of communicating over a network, necessitated some modification over how to keep requests and responses in synch with each other, and ensure that the wrong data is not received from a slave device.
Modbus TCP exhibits a difference in how the PDU is wrapped when compared to Modbus RTU. The TCP frame that contains the PDU begins with a MODBUS Application Protocol (MBAP) transaction identifier of 2 bytes rather than the slave ID. There is also no need for the CRC to perform error checking as the TCP layer handles that function.
Modbus RTU vs ASCII
Since they were both parts of the original Modbus protocol specification, you might be wondering what's the difference between Modbus ASCII and Modbus RTU. Modbus RTU employs binary coding and CRC error-checking. These choices were made for the sake of efficiency and are the main reason that the RTU mode is the one most commonly used in industrial settings. As you might have guessed, Modbus ASCII uses ASCII characters when sending messages.
The use of ASCII characters make the messages more human-readable but are a less efficient means of transmission. Another major difference is in the level of error checking that is performed. Modbus ASCII uses the less effective LRC method of error-checking rather than the stronger CRC of the RTU mode.
Though both Modbus RTU and Modbus ASCII are designed to be used with serial devices and protocols, they are incompatible with each other due to the differences outlined above. If you work with serial devices, you should be prepared to make use of the Modbus protocol.