A Step-by-Step Process for Solving Modbus TCP Communication Issues

Modbus TCP problems are rarely caused by the protocol itself. They are usually the result of configuration mistakes, network segmentation, firewall rules or register mismatches that hide in different communication layers. This article outlines a practical, layer-by-layer process for isolating and resolving Modbus TCP issues between an HMI and a PLC.

The Headache: Bridging an HMI to a PLC using Modbus TCP

A factory floor engineer was experiencing Modbus TCP communication issues in a relatively simple application. He had an HMI that acts as a client (master) device and a PLC that acts as a server (slave) device. For unknown reasons, he was struggling. He couldn’t even set a discrete bit in the PLC and was extremely frustrated. He asked, “How do I solve a problem like this?”

Common Causes of Modbus TCP Communication Failure

There are a few typical reasons for Modbus TCP communication issues:

• Firewall Issues – If the HMI and the PLC are separated by a firewall, it could be that the firewall is blocking Ethernet Port 502 messages.
• Subnet Issues – Often, an engineer, especially one not well-versed in Ethernet, will think that two devices are on the same subnet when they are not. When the subnets are different, the two devices can’t communicate.
• VLAN Issues – Unknown to the engineer, ports on the Ethernet switch may be assigned to a VLAN. If that’s the case, the devices will not be able to communicate. There is no way to determine what ports are assigned to which VLAN without accessing the switch configuration.
• Configuration Issues – It’s happened to many of us that we simply mistype the IP address of the other device. A simple error, but brutally important.
• Register Issues – Many times, a Modbus TCP Client will try to access a set of registers in a coil or a device that isn’t available. In devices that don’t follow the Modbus TCP specification, the device may simply not respond to the message rather than replying with an error.

A Step-by-Step Process for Solving Modbus TCP Communication Issues

Here’s the step-by-step action plan I provided to this engineer:

1. Get all your documentation in order. Get the register map for the PLC, the instructions for configuring the HMI and document the IP address and subnet mask for each device.
2. Confirm physical connectivity. Put your laptop on the same switch as your PLC and HMI. From your laptop, ping the PLC and then ping the HMI. This ensures that there isn’t a physical Ethernet communications issue. If this doesn’t work:
   • Validate each subnet mask. The subnet mask on one of the devices is incorrect.
   • Investigate the switch port assignments. A port on the Ethernet switch is assigned to a VLAN.
   • Communications on one of the devices is disabled or failed (device failure)
3. Validate PLC communications. Take the HMI offline and configure your laptop with the HMI’s IP address. Configure a Modbus tool (see list below) as a Modbus TCP Client. Configure the PLC as its Modbus TCP Server device. From your PLC software, write values into registers and set/reset a few coils. Try reading these registers and coils from the PLC with the Modbus tool.
   • If successful, write registers in the PLC. Verify with your PLC software that the values were successfully written. Verify that the registers and coils used by the HMI can be read and written successfully.
   • If you can’t communicate with the PLC, contact the manufacturer’s support representative.
4. Validate HMI communications. Execute a similar test with the HMI and the PLC. This time, configure the Modbus tool as a Modbus TCP Server using the PLC’s IP address. Use the HMI to read and write registers in the Modbus TCP Server tool. If that doesn’t work, work with the HMI vendor to determine why.
5. Retry HMI to PLC communication. Disconnect your laptop. The HMI should now be able to read and write those same registers in the PLC.

Modbus TCP Troubleshooting Tools and Resources

There are many free tools for Modbus network integrators. They include:

• ModScan (client) / ModSim (server) – https://www.win-tech.com/
• Modbus Poll (client) / Modbus Slave (server) – https://www.modbustools.com/
• Simply Modbus (client) – https://simplymodbus.ca/TCPclient.htm

For inexperienced users, get the book “Modbus: The Everyman’s Guide to Modbus.”

The Bottom Line: Isolate the Layer, Solve the Problem

Modbus TCP communication problems are rarely “Modbus problems.” They are almost always layering problems. You must isolate the issue one layer at a time:

• First, confirm physical and network connectivity.
• Then validate TCP/IP configuration.
• Then confirm the Modbus client and server roles.
• Finally, verify the register addresses and data handling.

When you break the problem into layers and resolve each one independently, even the most frustrating Modbus TCP problems become predictable and solvable.