Modbus TCP Slave problem

[BC SYSTEMS]

Hi,

I have a problem with some FMD16 PLC's. We have 15 of them controlling pumps around a site and all of them are a little temperamental when responding to Modbus TCP requests.

We frequently have communication errors that require re-booting the PLC's to get the communication going again only for it to fail at some point in the future, this can be 1 day or 1 month...

We use the web server function also and this works fine so I don't think the issue is with the connection more the PLC.

All the PLC's are connected via wifi aerials and generally respond to a ping in less than 100-250 ms so I'm wondering if this is a latency issue on the modbus protocol??  

Can this response time be adjusted??

The TCP master is a SCADA program with polling set to 1000ms for each register / device, with a timeout set to 5000ms.  We only read two registers from each PLC.

The SCADA has a re-connect function that upon connection failure tries to re-connect, this is set to 10000ms.

All of the above work fine when the PLC has been power cycled (a online reset does not help get the communication going ) until the comms error returns.

Can I use a set system command on port 4 to set the protocol to modbus without affecting the webserver connections?

The connections are as default 3 server and 3 Modbus connections.

Running out of ideas  
 

[support]

The ping time latency problem probably has to do with your aerial wi-fi connection (weak signal? Noise?). If you connect the PLC direct via Ethernet and ping it you will see a much lower latency.

Wi-Fi connection also tend to have more errors due to collision. What you experience could be due to Modbus packet out of sync caused by lost connection. i.e. the sender receive a modbus response packet that belong to the last command. Since Modbus TCP has a packet ID the sender only accept a response of the same ID, and if the command and response packets are out-of -sync the communication may not recover properly. In this case a reboot may be necessary to clear the out-of-sequence error.

You can automate the reboot by having the SCADA program periodically clears a timer running inside the PLC. If the SCADA program lost communication with the PLC it will retreat long enough for the timer inside the PLC to time out and the PLC can then go through an orderly shutdown and reboot. The PLC can save the important data or registers into the FRAM and execute a REBOOT command and then load the data back from the FRAM after it boots up. Re-booting time is quite fast - typically under 2 seconds and shouldn't impact the system performance especially if such error may occur only once in a long while.

Note: Continuous improvements have been made to PLC with the newer firmware version to handle potential problems that can caused by bad packets received from the TCP/IP network.  You can write to support@tri-plc.com and provide the firmware version of your all the PLCs involved, which we can check against our knowledge base to see if there are other workaround.

[BC SYSTEMS]

Ok I'll send over the details.

Cheers

[TravisB]

We are having a similar problem to what BC Systems describes, with the exception that when the SCADA/MODBUS connection is lost we also loose the FServer connection. The other difference is that eventually the PLC communication returns for awhile, even without reset/reboot. Since we are remote, when we loose communication we cannot do anything but wait.

Is the solution the same? Do we build a REBOOT trigger into the code or should I start elsewhere?

System Description:
Single f1616-BA connected via Ethernet to onsite PC
SCADA software is hosted on that same PC, uses network to communicate with PLC.
We view the SCADA and PLC Online Monitoring on the onsite PC via Remote Desktop Connection to the onsite PC.

I'm not sure how to find the firmware version of the remote/onsite PLC.

[TravisB]

I also can't find any documentation for the REBOOT command. I think it is different than the REFRESH command, which I do have documentation for.

[BC SYSTEMS]

Hi,

You can view the FW version once connected to the PLC from one of the top menus, something like " check hardware info"

I think I had a problem with FW version 78A. I will check and come back to you.

Cheers Marcus.

[support]

REBOOT command is supported on newer version of i-TRiLOGI. You are probably running a very old version that did not have the REBOOT command. You can upgrade to the latest version (currently 6.45 build 08) by following the " Upgrade TRiLOGI" link in the "Help" menu of your current version of i-TRiLOGI.

You mention that the communication eventually return - does it stay good for a long time or only briefly? Are you using wi-fi bridges to connect the PLC to the network?  It could well be the networking issue in the Wi-Fi bridge. If it is hardwired switch and you lose connection then a reboot will be the cleanest way to clear any build up memory corruption in the TCP/IP stack that could be caused by bad packets.

[TravisB]

When the PLC regains connection it's typically for less than an hour before dropping off again for longer than an hour.
Our setup is not using WiFi, it is hard wired, so we will proceed with the REBOOT option. I was saying I can't find any documentation explaining how to use REBOOT, even looking in the manual available for download on the TRi website.

[BC SYSTEMS]

Hi,

Version 78A was a problem for me.

How are you thinking of triggering the reboot command?

Cheers.

[TravisB]

Sorry for the late reply BC, got tied up in some other details. My problem ended up originating from another system (other contractor) using the same IP and port as we were using. Once we changed the port number communication has been great. We're still a bit doubtfull, so I'm going to add code similar to what the REBOOT would have done.

I will increment the value of a DM field every second. When the SCADA connects it will read the counter, then zero the counter. Nice routine communication means the counter should get zeroed more than once a second. If there is an outage then the counter will keep increasing.

If the PLC DM field reaches one minute it will "make note" and could also REBOOT if that's what you need.

I will also add code to my SCADA that will "make note" if the DM value is greater than 15 seconds.

I havn't written the code yet, but that will be the strategy. If there is a more elegant solution I'd like to learn about it because I think this bit of code is a valuable addition and it will find it's way into future projects as well.