We did a test of using a master FMD1616-10 PLC to connect to 4 slave PLCs (a nano-10, a FMD88-10, an F2424 and an F1616-BA). The master PLC uses Modbus/TCP connection to each slave PLC and will write to the outputs to turn on an output, then close the connection. It goes through all 4 PLCs rapidly, then left-shift the output by one bit and repeat the write to each PLC. The output are shifted within 4 output bits so that they are always visible.
A source code for this round robin test master can be downloaded below for reference:
http://www.tri-plc.com/trilogi/MBTCPRoundRobinTest.zipThe slaves are running their own simple programs but they don't control their physical outputs, so the master can force their output to whatever states it wants.
The 4 slave PLCs are configured with the following IP addresses and IDs:
1) Nano-10: 192.168.1.11 ID = 01
2) FMD88-10: 192.168.1.12 ID = 02
3) F1616-BA: 192.168.1.13 ID = 03
4) F2424: 192.168.1.14 ID = 04
What we observed, as expected was that each PLC was running a blinking light pattern from output 1 to 4 (output 1 to 2 only for Nano-10 and output 5 to 8 for F1616-BA to avoid the relay contact noise). The master PLC runs the round robin of activating each PLC output as fast as possible and in fact we estimated that on average every second more than 10 Modbus/TCP open/close connections and WRITEMODBUS were made to these slave PLCs. Occasionally a modbus/TCP connection may fail but it will recover automatically the next time a reconnection is attempted.
We ran the whole setup over the past 1 week with the intention of checking if any potential failure to close the Modbus/TCP connection could lead to the all the TCP socket being occupied. But it did not happen and we are still able to connect to each slave as well as the master PLC via the network anytime we attempted to connect.
Note that we have connected all 5 PLCs to the same 100Mbps Ethernet switch so our connection is a best case scenario. If your slave PLCs are connected to different switches in the same LAN then network congestion issue may reduce the throughput but the program should still work.
You may also want to check if your network switch itself is giving problem? You can try to ping all the slave PLCs as well as the master PLC just to check if the master PLC in your network is the only one that is not responding.