Blog

Show all
modbus logo

This article describes steps to troubleshoot various Modbus TCP communication issues with the Kolver K-DUCER controller, although the methods are generically applicable to any Modbus TCP device.
The troubleshooting methods are listed in increasing levels of complexity.


Failure to establish a Modbus TCP connection


General settings verification

1. Verify that the protocol on the K-DUCER is set to “Modbus TCP” (if using a combination protocol containing “MB TCP”, switch to “Modbus TCP” alone while troubleshooting and return to the combined protocol after resolving the issue).

2. Make sure the K-DUCER controller is on the main working screen, outside all menus, when attempting to connect.

3. Enable the option “LOCK IF NOT CONNECTED” on the General Settings menu of the KDU controller, then return to the main working screen. A blocking popup message will appear on the screen if there is no active Modbus TCP connection to the K-DUCER.

4. Does the popup from step 3 appear? If so, continue. If it does not appear, this means that there is already an active Modbus TCP connection to the K-DUCER controller. The KDU-1A, KDU-NT, and K-TESTER controllers can only connect to one Modbus TCP client at a time.

Are you aware of any other devices opening a Modbus TCP connection to the Kolver controller?
Please note that the Kolver software K-Link, K-Graph, K-Expand, and K-Torque-Analyzer, all use a Modbus TCP connection to communicate with the Kolver device. Close those programs, if active.
K-Link is a windows service, if you installed it, you’ll need to pause it from the windows services app, or simply uninstall it. You can also simply change the IP address of the Kolver controller: this will prevent the culprit / other client device from stealing the Modbus TCP connection.

Ping

5. Does the Kolver device respond to ping? On a PC, open the command prompt (CMD) and type “ping 192.168.100.101” without quotes, and change the 192.168.100.101 IP address with the one you assigned to your Kolver device. If the output does not show “reply from 192.168.100.101 […]” like in the picture below, then the device is not responding to ping. This usually means that the IP address settings are not properly configured either on the Kolver device or on the Modbus TCP client device. See section below on how to properly configure an IP address.

modbus_Immagine1?>
Refer to this Microsoft article if unsure how to use the ping command on Windows.

Test the connection with K-Expand or other Kolver software 

6. If the Kolver device responds to ping, and the “LOCK IF NOT CONNECTED” popup error is displayed from step 3 above, then try connecting to it using one of Kolver’s free PC software such as K-Graph (KDU-1A and KDU-NT) or K-Torque-Analyzer (K-TESTER). If you are not able to connect, then there might be a misconfiguration of the IP address, or there may be a firewall blocking the connection. Review with someone responsible for your network infrastructure.

Verify that the IP address configuration is appropriate

7. If connecting the PC directly to the K-Ducer, or directly to an ethernet switch where multiple K-Ducers are also connected:

    • Configure the IP address of the PC to static (manual). Refer to this Microsoft article if unsure.
    • Set the IP address of the Kolver device so that it uses the same subnet mask of the PC, and an IP address that is identical in the first three groups of digits, and different in the last group of digits
    • If your network configuration uses a gateway, make sure to enter its IP on the Kolver device IP settings screen. Otherwise, make sure the gateway IP address is set to 0.0.0.0
    • Example with static IP addresses:

 modbus_Immagine2?>

8. Connection via router or DHCP server (automatic or static IP):

If connecting the PC and the K-Ducer controllers to a LAN network with a router or other DHCP server:

    • Your router (or other DHCP server) must allow a range of addresses to be used with static IP, with room for at least one address per K-Ducer controller
      • Only for KDU-1A v38 (or other DHCP-enabled controllers): you can activate the automatic assignment of an IP address to the KDU-1A by enabling the corresponding DHCP option on the controller. However, you will still have to reserve an IP address for each KDU on your DHCP server, so that the same IP address is always assigned to the same controller and K-Link can reliably connect to it
    • Configure your PC for either automatic (DHCP) or manual IP address. Refer to this Microsoft article if unsure. If choosing manual (static) IP, ensure you’re using an address that is outside the DHCP address range of your router or DHCP server
    • Configure the IP address of the Kolver device so that it uses the same subnet mask of the PC, and an IP address outside of the DHCP address range of your router or DHCP server, identical in the first three groups of digits to the DHCP range, and different in the last group of digits
    • If your network configuration uses a gateway, make sure to enter its IP on the Kolver device IP settings screen. Otherwise, make sure the gateway IP address is set to 0.0.0.0
    • Example with dynamic IP addresses:

 modbus_Immagine3?>

9. If after following the above recommendations, you are still unable to connect using a Kolver software, it usually means that there is a firewall or some network infrastructure feature that is blocking or preventing the connection. Review with someone involved with your network / IT infrastructure.

10. If you are able to connect to the Kolver device using Kolver software, but not using a PLC or other device, then follow troubleshooting steps for the other device, and/or review the Wireshark troubleshooting section below. Make sure the Modbus TCP connection you are attempting to establish uses TCP port 502 (the standard Modbus TCP port) and the IP address of the Kolver device.

11. If your PLC (or other device) briefly connects (the “NOT CONNECTED” popup message on the Kolver device disappears momentarily) and then disconnects, there could be two possibilities:

    • Your PLC is connecting, exchanging the desired message, then closing the connection. Identify a setting on your device that allows the connection to persist and remain open in-between messages, this will also significantly improve the response time
    • Your PLC might be connecting, attempting to exchange a message, receiving a “Modbus Exception”, and closing the connection. Review the section below.



Modbus Exception Messages

If your Modbus device is indicating failure to exchange messages due to a Modbus exception, it's usually one of the following two exceptions.

Server Busy Exception

→ This error occurs when the PLC attempts to write to a holding register while the screwdriver motor is running.

Fix by:
Waiting for the fastening cycle to complete then re-attempt the write.

→ It can also occur if someone is navigating the configuration menus on the Kolver device.

Fix by:
Returning to the main working screen on the control unit.

 

Illegal data address or Illegal data value

→ This error occurs when the PLC is writing or reading a register that does not exist on the Kolver device.

Fix by:
Reviewing the Modbus Map of the Kolver device.
Ensuring you are using the correct function code (are you reading holding registers or input registers?).
Ensuring you are referring to the Modbus Map for the Kolver device that you have (download it from the corresponding product page www.kolver.com).
There could also be a mismatch between the Modbus Map and the software version running on your Kolver device.
Contact Kolver to verify this and receive a free software update (or the back-dated Modbus Map compatible with your version).

→ This error can also occur if the PLC is writing a data value that is outside the allowed range.

Fix by:
Review the Modbus Map as in the bullet point above. If you are sure that the data value is in range, and you are writing a 16bit or 32bit word, review the endianness settings of your PLC (try swapping it)

 

Other issues

To troubleshoot other issues, it may be necessary to utilize a network packet analyzer software, such as Wireshark.

Wireshark is a free, open-source network protocol analyzer that captures and displays network traffic in real-time. For industrial network troubleshooting, it’s an invaluable tool because it allows you to see exactly what’s happening on the wire—every request, response, and error—making it possible to diagnose issues that would otherwise be invisible.

Knowing at least the basic usage of Wireshark (or similar tools) is a very valuable skill to have when working in the industrial automation world.

Even if you do not have the expertise or time to analyze the network traffic with Wireshark, recording and sharing the packet capture file with a member of Kolver’s engineering team will help immensely with troubleshooting and getting to the root cause of the issue quickly.

For more information, see our blog post on using wireshark to troubleshoot industrial network protocol issues.


Why Use Wireshark for Modbus TCP?

In industrial environments, Wireshark helps you:

    • Verify communication between client and server devices
    • Identify network issues like dropped packets or timeouts
    • Decode Modbus messages to see actual function codes and data
    • Spot error responses that might not be properly reported by your PLC
    • Analyze timing issues between requests and responses

 

Even if you do not have the expertise or time to analyze the network traffic with Wireshark, recording and sharing the packet capture file with a member of Kolver’s engineering team will help immensely with troubleshooting and getting to the root cause of the issue quickly.


Capturing Modbus TCP Traffic

1. Start a Capture

    • Select the network interface connected to your industrial network
    • Click “Start” to begin capturing packets

2. Filter by IP Address

    • To focus on K-DUCER communication, use display filters:

ip.src == 192.168.1.100 or ip.dst == 192.168.1.100

Replace 192.168.1.100 with your K-DUCER’s actual IP address.

Remember to stop the capture when you are finished recording, to enable saving the captured data (File > Save As).

Example of a filtered wireshark packet capture:

modbus_Immagine4?>

Capturing traffic between two external devices

If the PC running wireshark is not the device that’s connecting to the Kolver controller, you might wonder how you can capture the traffic.

Simply connecting to the same ethernet switch or network won’t work, because the traffic between the PLC and the KDU will not be forwarded and made visible to the PC.

You will need to use a managed ethernet switch that allows mirroring traffic on at least one port. One of the least expensive of such devices is Netgear model GS105E:

    • Connect the ethernet cable that’s currently connected to the KDU, to the Netgear switch instead
    • Connect another ethernet cable from the Netgear switch to the KDU controller
    • Connect an ethernet cable from your PC running wireshark to the special port on the Netgear GS105E that you have configured for traffic mirroring (refer to the GS105E manual for how to do this)
    • Now you will be able to see all traffic going to and from the KDU controller with wireshark

 

Identifying Common Modbus TCP issues in Wireshark

Server Busy Exception

Look for Modbus exception responses with exception code 06:

    • In the packet details, expand: Modbus → Exception Code
    • Code 06 indicates “Server Device Busy”
    • See section above for more information on this exception

Example Wireshark Analysis

A typical Modbus request/response sequence looks like:

    1. Client → Server: Read Holding Registers (Function Code 03)
    2. Server → Client: Response with data OR Exception Response

If you see an exception response, check the exception code:
→ 01: Illegal Function
→ 02: Illegal Data Address
→ 03: Illegal Data Value
→ 06: Server Device Busy


Timing Analysis

Wireshark’s time column helps identify:

  • Slow responses: Large gaps between request and response
  • Timeout issues: Requests with no response
  • Network congestion: Delayed packet delivery


Practical Wireshark Tips for Modbus

1. Save Capture Filters
Create a capture filter to reduce file size:
host 192.168.1.100 and port 502

2. Use Color Coding
Set up coloring rules to highlight:
Modbus requests (green)
Successful responses (blue)
Exception responses (red)

3. Export Modbus Data
Stop the packet recording to enable selecting and saving packets
Click File > Save As to export the capture


Best Practices for Reliable Modbus TCP Communication

1. Network Design
→ 
Use dedicated industrial Ethernet networks when possible
→ Implement proper network segmentation
→ Consider managed switches for critical applications

2. IP Address Management
→ Document all device IP addresses
→ Use static IPs for industrial devices
→ Implement a clear addressing scheme

3. Error Handling
→ Implement retry logic for transient errors
→ Log communication failures for troubleshooting
→ Set appropriate timeout values

4. Performance Optimization
→ Read multiple registers in a single request when possible
→ Use a polling frequency appropriate for the application. Polling frequencies greater than 50ms (20 Hz) are rarely useful when working with a smart torque controller, because the motor control algorithms live inside the torque controller and are not controlled directly via Modbus. If unsure, start with 100ms.
→ Wait for the Modbus response before issuing another Modbus request. Kolver devices will queue multiple incoming requests, but this is rarely useful or necessary.


The full Wireshark user guide can be found here: https://www.wireshark.org/docs/wsug_html_chunked/ 
If you still need help, please don't hesitate to contact our team.