MODBUS is an application layer messaging protocol, positioned at level 7 of the OSI model that provides client/server communication between devices connected on different types of buses or networks.
The industry’s serial de facto standard since 1979, MODBUS continues to enable millions of automation devices to communicate. Today, support for the simple and elegant structure of MODBUS continues to grow. The Internet community can access MODBUS at a reserved system port 502 on the TCP/IP stack.
The Modbus protocol has two different types of interaction: ASCII/RTU. In ASCII mode data is wrapped into the packet and transmitted as an ASCII string. The first byte of packet is used for identification – its value should be equal to 0x3A. Packet ends with two special bytes - 0x0D and 0x0A.
MODBUS View visualizer is compliant with MODBUS APPLICATION PROTOCOL SPECIFICATION V1.1a. There are several different implementations of Modbus Protocol. Different companies implement and document their own specific extensions to Modbus Protocol. Function and command names could vary: for example, Preset Single Register command in one implementation equals to Write Single Register command in the standard.
MODBUS View visualizer parses MODBUS protocol requests and responses, while the MODBUS Send Module can be used to construct and send MODBUS requests and responses. The visualizer is part of the monitoring infrastructure, which you can use it to monitor the existing connection between the application and a serial device. The MODBUS Send Module, on the other hand, allows you to control the MODBUS-compliant device without the need of any third party controlling application. In this case, the MODBUS View visualizer, if configured, can be used to see the requests sent by the MODBUS Send Module and packets the device responds with.
You can set the filtering on Tools » Settings, Filtering Tab page.
The following settings govern the behavior of the visualizer (they all are controlled from the Tools » Settings, General Tab):
Truncate register/coil/request list if it is too long - if there are many items in a request, only several first items will be displayed and others omitted.
Add base offsets for registers, discrete inputs, etc. - in some implementations index of input register, holding register or discrete input is interpreted by a device like an offset. In this case, the value is appended to a so-called “base address” by the device. For example if you specify holding register 5 in your request, it can be parsed as register 40005 by a device (for a base address of 40000). The visualizer can be configured to account for this case using this option.
Parse request on WRITE (responses on READ) direction – set this option for standard parsing – requests will be parsed as if they sent from host to device (“write” direction) and responses are parsed as if they are received from device (“read” direction). However, in some cases for debugging, it is useful to “revert” the flow. Deselect this option if you want request be parsed on the “read” way and responses on “write” way (host is responding to the device).
Concatenate packets - set this option if packets are sent split (for example one packet with 8 bytes of payload is split into two packets: 2 + 6 bytes). The visualizer will try to concatenate blocks of data. Collected packet will be parsed and displayed when LRC/CRC of collected data is valid.
RTU mode - set this option if you have enabled “Concatenate packets” option (see above) and is using RTU mode. Visualizer can't automatically determine the mode when packets are sent split. When “Concatenate packets” option is disabled, this option doesn't affect the visualizer behavior.
MODBUS View visualizer supports Generic Filtering platform.