Modbus RTU & TCP Overview, Debugging, & Troubleshooting.

Understand the basic principles and practicalities of Modbus RTU & Modbus TCP. Characteristics of the communications protocol and some debugging tips & tricks. Modbus is used throughout industry and this video aims to help engineers and technicians resolve Modbus issues with some helpful advice.

-------

What if Modbus RTU (serial) communications are not working? Debugging quick guide…

1. Always the first step, check communications wiring, double check, triple check. RS485 wiring is usually the culprit, check against the wiring details/drawings. Be beyond doubt that the wiring is correct! Polarity matters.

2. Ensure on systems which span large distance or operate at high data rate that 120Ω termination resistors are installed at the two line ends. This can be ‘roughly’ confirmed by measuring across data+ with respect to data- with the system inactive and expect to measure 60Ω (two resistors in parallel). Although this usually does not result in a system failure, it is important to confirm. You may detect a short circuit between data lines - maybe this is the fault.

3. Biasing resistors (to the order of 10kΩ) may be required to make sure that the RS-485 lines remains in a known, non-fluctuating state when no devices are transmitting. Biasing the entire network requires a single pair of resistors: a pull-up resistor to +5V attached to the data+ signal line, and a pull-down resistor to ground attached to the data- signal line. RS-485 networks typically have biasing resistors at the primary node.

4. Are communications settings, including baud rate, data bits, parity, stop bits, delay between polls (ms), and response timeout (ms) configured correctly and consistent between master & slave devices? Confirm this beyond doubt. If using a USB-485 adapter, is the ‘latency timer’ device manager setting at its lowest value of 1ms, if not, this can cause intermittent Modbus errors.

5. When polling a slave device from master (PC/PLC), is the correct Modbus slave id being used? Are the correct Input & Holding register addresses being polled? Is the register addressing using base0 or base 1? Can the slave device handle the number of registers being polled in any one request (Modbus standard is 125 registers per request, but other devices may have lower limits!)

Having been through these steps, your system should be working… In summary…
- First, Check wiring
- Second, Check communications port settings
- Third, Check Modbus message parameters

If all of these are correct, there is no reason a system should fail to operate.

-------

What if Modbus TCP (ethernet) communications are not working? Debugging quick guide…

1. Always the first step, check communications connections, is the ethernet cable used for Modbus communications connected to the correct ethernet port on the device, connection lights on?

2. Is the slave (server) IP address known, correct, and able to be 'pinged' ? If you cannot 'ping' the device IP address you won't be able to get Modbus communications working. Is your PC/master configured with correct fixed IP address? (Check firewall settings !?)

3. Are Modbus TCP communications settings, including server port (502), connection timeout (ms), delay between polls (ms), and response timeout (ms) configured correctly and consistent between master & slave devices? Confirm this beyond doubt.

4. When polling a slave device from master (PC/PLC), is the correct Modbus slave id being used? Are the correct Input & Holding register addresses being polled? Is the register addressing using base0 or base 1? Can the slave device handle the number of registers being polled in any one request (Modbus standard is 125 registers per request, but other devices may have lower limits!)

Having been through these steps, your system should be working… In summary…
- First, Check ethernet connections
- Second, Check communications port settings
- Third, Check Modbus message parameters

If all of these are correct, there is no reason a system should fail to operate.