Modbus troubleshooting

Troubleshooting Modbus can be broken into two parts

1. MODBUS TCP/IP

2. MODBUS Serial 

The problems with the TCP/IP Modbus involve network troubleshooting: This means that the TCP/IP ethernet packets should start and reach the destination with no error and perform the required transaction. Ethernet is basically an IT function. Troubleshooting the data transaction when it is inside the target device it is typically the same as in a Modbus serial.

In Modbus serial link if the Modbus type, RTU/ASCII, baud rate, start characters, parity, end characters, timing between messages, termination resistors in place, etc. are probably correct then this allows the troubleshooter to concentrate on what has changed on the link, such as peripheral devices, modified or changed wiring, new wiring or the existing wiring, etc. If the installation is a new one, the wiring and the Modbus configuration for all the Modbus devices on the link should be double-checked, and made sure it lines up with the Modbus link manual and documentation. It is a common problem for Modbus serial to have the signal wires reversed.

The common indications that the MODBUS is having a problem are I/O timeout (eg before receiving the reply of the sent message the interface just timed out), receiving an error code from the slave/server device. This would probably display a bad process variable PV or an I/O timeout indication on the DCS. Most Modbus devices have communication lights which blink when the device is communicating, and also colored LEDs are used to provide some troubleshooting capability. When a Modbus slave/server detects a problem with a request, it responds to the master/client with an exception code. The meanings of the exception codes can be found in “MODBUS Application Protocol Specification V1.1b3” on Modbus.org. It may not be possible to determine what is causing the problem from the DCS and we can have a look at the actual Modbus transaction.