Troubleshooting PLC110/160 M02 Modbus TCP Sockets Guide

A PLC110[M02] socket client can establish TCP communication and still fail to exchange useful data if it does not construct the required Modbus request. The available evidence also identifies two implementation risks: repeatedly creating sockets causes the 32-bit hClientSocket value to increase, and uncontrolled read/write calls may delay or interfere with each other.

Separate TCP Transport from Modbus Messaging

SysLibSocket provides the transport connection; it does not create the application-layer Modbus request. After opening the TCP connection, construct the request expected by the server, transmit it, receive the response, and validate that response before starting another transaction.

Control the Socket Handle Lifecycle

The reported hClientSocket value increased when the program repeatedly created connections. A later revision stopped continuously cycling through handles. The evidence states that a closed-handle counter can wrap through its numeric range, but it gives neither the simultaneous-socket limit nor manufacturer-confirmed rollover behavior. Do not use the numeric handle value as a connection-health indicator.

Keep one handle associated with each active connection, reuse it while the connection remains valid, and close it once when leaving the connected state. Recreate the socket only after the prior handle has been closed or declared unusable. Verify resource control by confirming that a stable connection no longer produces a new handle every PLC cycle.

Serialize Reads, Writes, and Multiple Devices

Use a transaction sequence so a write and read do not operate on the same socket concurrently. The evidence reports perceived read/write slowing but provides no measurements, timeout values, or confirmed root cause; measure transaction completion before attributing the delay to socket scheduling.

1. Open or retain the socket assigned to the target device.
2. Construct the required Modbus request and send it only when no earlier transaction is pending.
3. Wait for and validate the corresponding response before enabling the next read or write.
4. For multiple modules, maintain separate connection state and handle storage for each target so one device cannot overwrite another device's transaction state.
5. On a communication failure, close that device's socket before creating its replacement.

For the reported MK302 case, an intermittently flashing Eth1 indicator accompanied by an alarm LED flashing in the opposite phase proves only that Ethernet activity occurred; the evidence does not define those LED states or establish successful Modbus communication. Verify success from a valid application-layer response rather than LED activity alone.

FAQ