Modbus TCP Issue

I have an industrial product (designed to view PLC data) that can communicate both ModbusTCP and Ethernet/IP.

This device was originally a ModbusRTU Master however, the manufacturer added a module to enable Modbus TCP.
The new module connects to the original serial port and is the SLAVE on the serial side. I believe it is then a Master/Client on the TCP side.
This device is designed to communicate with any PLC (programmable logic controller) having the Modbus TCP protocol.

The problem is that the device does not see data unless the PLC is polling or the data is changing in the PLC.
Also, there are no Device Configuration Parameters available such as “Timeout”, “Retries” and “Inactivity Timeout”.
Only within the PLC are there parameters related to the port for communication.

My question is…, since the PLC appears to do the polling, is it possible to have a CLIENT in the Modbus TCP world depend on the SERVER to poll before it will capture the data?

Thank you in advance,

No. In the Modbus protocol, both serial and TCP, the client must poll. The server only responds.

Hey Thank You!

Yep, I found out that although it looks like I’m communicating via ModbusTCP, I’m actually communicating via ModbusRTU with an Ethernet/IP protocol converter that behaves as an Ethernet/IP adapter where the Ethernet/IP scanner resides in the PLC.

Thereby, the PLC is required to poll its data tags in order for the adapter to receive it.

Thank you,


In Modbus world:

Master -----> Client
Slave --------> Server

Client polls the Server
Master polls the Slave.

Check who is Master and who is slave.

I think you are using an RTU, not a PLC. Your RTU is configured as a Master and it updates the slave upon change.

The RTU (remote terminal unit) is the dialer which requires/consumes the DATA from the PLC. This dialer has the ModbusRTU Master as it protocol.
Communication to the Modbus RTU Slave is via a serial cable.

The Modbus RTU slave device was the issue.

This device is a Gateway/Protocol converter where the back end is the Modbus RTU slave and the front end is an Ethernet/IP Adapter designed to communicate via CIP to an Allen Bradley PLC.
In this case the PLC is the scanner and communicates EXPLICITLY to any 3rd party adapters on the network.

This only issue with this Gateway is it’s designed for AB PLC’s and will work with other PLC’s provided they PUSH the data, and not act as a typical SERVER.

Thank you,