MBTCP Master

[BC SYSTEMS]

Evening all.

I have some questions regarding the MBTCP functions within the PLC.

We are using seven nano's to control some pumps in different locations around one of our customer?s site.

The master is also connected to the site SCADA system which views the system status via the web page in the nano.

The topology is one master connected to a tank level sensor and six slave pump panels.

Each panel communicates using a WiFi gateway and the communication is good between all PLC?s.

The master PLC reads the tank level and if the level is above or below the set point, it uses a writemodbus function 1 or a 0 to a DM value in each of the slaves ? simple as that.  Each of the slaves reacts depending on the DM value.

The first question I have is about the number of connections limit.  Is this six for incoming and outgoing connections?

We have set the MBTCP connections to 2 and Server connections to 4. Were assuming the web traffic comes in via the server connection allocation but you know what they say about assumptions!

As described above we have six slaves, when we attempt to connect to a slave, if the connection is successful we call the modbus function above, if the MB write is good we close the connection and move on to the next panel.

We have some error detection code that recalls the function 3 times for both the TCP connection and the MB write before we move on anyway to avoid hanging up the system if one of the slaves is off-line etc.  Every time there is an error or before we connect to the new slave the TCP connection is closed.

This way we are only using one connection to connect to all the slaves which was necessary as there will hopefully be more slaves (panels) in the future.

Second question, when we close the TCP connection does this close all TCP connections in and out?

Third question, is this the best / most efficient way of communicating to each of the slaves?

We have considered using the host link commands but we would still need to open / close the connections as we move around so we thought we would stick with the devil we know. 

The problem we have is the panel locks up completely randomly, sometimes hours, sometimes weeks after a power cycle and I can?t seam to pinpoint the failure because the PLC does not accept any TCP communications and we are not local enough to go in via the RS485.

Any thoughts or wise words greatly appreciated.


Cheers

[support]

The limit is 6 server socket that can accept incoming connection, and only 1 client socket which can be used to make connection to other servers.

If the master is the only device that communicate with the slave using Modbus/TCP protocol, then your definition of 4 F-server connections and 2 Modbus connection should be OK. But if there could be more than one Modbus/TCP master that connect to the slave devices then you may want to define 3 Modbus connection and 3 F-server connection.

Since there is only one client socket, you are correct that the master should only open a connection to one slave (server) at a time to transfer data to it and then close the connection before proceeding to the next device. This obviously is not very efficient since the connection is constantly open and closed, even though Modbus/TCP works best if it is a persistent connection between two devices for regular data transfer between the two devices.

When the client closes a connection it inform the server that it is closing the connection and the server will then close the connection as well. But if for whatever reason the server did not receive the close instruction from the client (lost packets, for example), then the server connection is left "half-open". The next time a client attempts to connect to the server again it will use another available socket to accept the connection from the client (until all sockets are used up). Fortunately, the server will close an idling connection after several minutes if every works properly.

If all you want to do is to write to a single DM and then close the connection, you may want to consider using the web query method to send a single hostlink command to the slave using PRINT #4 "GET /HOSTLINK/WVDxxxxxxxx" command after making a "<TCPCONNECT> to the slave PLC's server. The server will send a hostlink response to the client and then close the connection. The client will also close the connection using the PRINT #4 "</>" tag. Both client and server in this case always close the connection and the socket would not be left half-opened even if close command sent by the client is lost.

When the PLC execute a PRINT #4 "</>", it only closes the client connection. It does not affect the currently opened server connection from other clients.

[BC SYSTEMS]

Thank you for clearing up some of my misunderstandings!

Regarding the hostlink command from the client.  Will the client close the connection automatically or do P still need to close the connection?

I will try the Hostlink commands and report back my findings.

Cheers

[support]

Your client function will still need to execute PRINT #4 "</>" to cleanly close the connection.

[support]

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.zip

The 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.

[BC SYSTEMS]

Thank you for the example.  I will compare this with my code and see if the reliability improves!

[BC SYSTEMS]

Evening,

I have re-arranged some of my functions in-line with your example and changed my function call structure a little which appears to help.

Interestingly, when the master tries to connect to each slave, the connection fails twice before a successfully connection is made pretty much every time to every slave?

The panels are connected via WiFi gateways so there will be a little more latency than your hard wired test rig however the delay is minimum.  The average ping time to each panel from my office 450 miles away is around 150ms.

I will see how the system performs over the next few days.

Thanks for the assistance.

[support]

That doesn't sound like normal. You shouldn't need to re-connect 3 times in order to make a connection. Please check that your program did perform a proper disconnection from the server (using the PRINT #4 "</>" command tag) so that its single client socket is freed up before attempting the next connection.

You may want to do single connection at a time (manually turn on an input to start the connection) and check the returned code after the connect attempt to see what's the error message. You may then take appropriate actions if you know what errors you have encountered.
 

[BC SYSTEMS]

Hi,

Your right, the problem was the location of a line of code, move the line, problem gone!

Cheers.