I’m currently building a Modbus gateway using a B&R PLC (X20CP0484-1), and I would like some clarification on the use of Modbus TCP Any as a server.
B&R Hardware : X20cp0484-1 X20cs1030 Use
[B&R PLC]
↳ Modbus RTU (X20CS1030Module) → Receives data from slave devices
↳ Modbus TCP (Server, via ETH port) → Should expose processed data to TCP clients ( Modbus Poll)
In short: The B&R PLC is acting as a Modbus RTU Master and a Modbus TCP Server simultaneously.
The RTU communication is already working well — I can read and process the data from Modbus RTU slaves without issues.
Now I want to forward that internal data to Ethernet clients using Modbus TCP Any.
My question is:
Can Modbus TCP Any be used as a Server (Slave) to respond to Modbus TCP clients like Modbus Poll?
Or do I need to implement the MbTcpServer function block instead?
I’ll also attach my current Modbus TCP Any configuration, as well as the PLC-side mapping of FLOAT and DINT values.
Any help from those with experience using Modbus TCP Any in a server context would be highly appreciated.
I’m not sure if I got your use-case completely right, but I’ll try to share what I know about it.
The serial part (Modbus RTU) I think I understood and it’s clear.
But I think we have to separate the topics “ModbusTCP” and “TCP (as transport protocol)” a bit more:
a ModbusTCP master acts as a TCP client connection → the master opens a TCP client connection to the slave, and queries data from the slave → that means, that the ModbusTCP master has to know the IP address from all of the slaves he wants to communicate with, and actively initiates the TCP connection.
a ModbusTCP slave acts as a TCP server → the slave just opens a TCP server and waits passively for incoming TCP client requests → that means, that the ModbusTCP slave has not to know who will query him, it “waits for being connected”.
The ModbusTCP_any device is for defining ModbusTCP slaves, so that the PLCs ModbusTCP driver has all information needed to manage the TCP client connections to the ModbusTCP slaves.
If the controller is acting as a ModbusTCP slave and therefore as a TCP server (“waiting for queries, just having the data”), the ModbusTCP_any device isn’t needed.
In a nutshell:
As I understood your gateway use-case (“transforming” a serial slave to a tcp-based slave), I think you want to act as a ModbusTCP slave, therefore the ModbusTCP_any device isn’t needed / suitable.
You have to use the “controller-as-ModbusTCP-slave” setup described in the following help link
As additional information: if you don’t want to use the Automation Runtime integrated ModbusTCP master/slave, there’s also a open-source implementation of ModbusTCP available, based on “pure” AsTCP functionality.
I hope this information helps a bit,
best regards!
Thank you for your valuable time and the insightful guidance you provided earlier.
Following your recommendation, I was able to successfully verify Modbus TCP Slave communication using the ETH Modbus Slave configuration with Modbus Poll. Your proposed solution worked excellently, and I agree that a proper gateway should transmit 16-bit data as-is between Modbus RTU and TCP.
However, the reason I initially mentioned ModbusTCP_any is because the Modbus TCP client on the receiving side of the gateway wants to receive processed data — specifically in types like REAL, DINT, or LREAL.
In the past, I have used ModbusTCP_any as a TCP client, and I successfully received 32-bit REAL data directly via Modbus TCP.
What I am currently trying to test is this:
Can ModbusTCP_any be used to serve processed data like REAL, DINT, or LREAL when a Modbus TCP client sends a read request?
In other words:
Is ModbusTCP_any strictly for use in client (master) configurations only?
Or is there a way to utilize it for server (slave) behavior to serve structured 32-bit data types?
I would highly appreciate your clarification on this matter.
Thanks to the guidance I received here, I was able to successfully set up Modbus TCP communication between my PLC and Modbus Poll. I used Octet-based mapping to assign a REAL type variable, and the project compiles and downloads successfully.
The project compiles and runs without any errors, and the Modbus TCP communication appears to be working correctly — Modbus Poll receives responses from the PLC.
[Modbus TCP Communication Established, but “Not Available” Error When Reading REAL Value]
“Hello, I had forgotten that I needed to use Input Registers to output values. Thanks to your help, I was able to solve the problem. I really appreciate your support.”
