Omron FINS Driver - Intermittent Drop Out

I am currently trialing the Omron FINS driver on a new project.

Ignition V8.0.9
OPC UA V8.0.9
Omron Driver 3.0.9

I have set up the Omron Device using the UDP connection. It connects fine and shows ‘Bound’.

I have set up a single ‘hello world’ tag to trial communication to an Omron CP1L-E PLC.

Tag is addressed to ns=1;s=[TestPLC]D47

This works fine. The tag reports the correct value, and I can write new values to the PLC.

Issue: intermittently the tag quality goes bad and stays bad. I cannot read/write the value. The device connection continues to show ‘bound’. To reestablish the communication I can disable the device, wait a minute or so, and re-enable the device. The tag communication is then immediately ‘good’ for several minutes to many hours.

Other Notes:

  • These problems could be due to the fact that this connection is across a VPN, something which we have been doing with Kepware for many years. The VPN itself doesn’t appear to exhibit any issues and the whole time we are having problems we are using the same VPN to access another NX Series Omron PLC via the Ethernet/IP driver no problem. I am also using the VPN to access designer/client sessions from the gateway with no problems at all.
  • I have been able to establish a TCP connection the PLC, however have not been successful at any time to communicate with a test tag.

I will try to set up a wireshark trace which may give a few clues. Will also have a look in the gateway logs…

Any ideas ?

Thanks

Yeah, Wireshark while this is happening, plus turning the logger you find searching for “FinsReadRequest” to DEBUG will help.

What local address are you binding to?

Thanks Kevin,

I am binding to the local (gateway running the Omron Driver) NIC IP Address which is 192.168.187.11

Installed wireshark, running OK at the moment, will wait until it next drops out (may take a few hours). Image shows good read/response frames right now.

Have set the logger to ‘Debug’ for finsread

Tim

So has dropped out at the moment.

Omron PLC Device still shows ‘bound’. Tag is bad quality with no response from PLC on FINS request.

Logger has timeouts:

Wireshark shows no response. Outgong FINS request looks valid to me. I am not sure it is reaching the PLC, ICMP Ping works OK.

I can connect to the PLC using CX-Programmer (using UDP) no problem. I have reset the PLC Ethernet Port with no effect, have also cycled the PLC power with no effect. However if I disable the device in the Ignition Gateway, and re-enable the PLC then responds OK and works fine until the next stop. It appears the device connection goes stale, or is broken.

Any suggestions will be appreciated.

Tim

Sorry, I really don’t have any suggestions.

In my experience so far using UDP protocols over VPN hasn’t been very reliable. My setup is a little different though, where I’m binding to the virtual adapter / IP assigned to my VPN connection, and when the connection goes down the adapter is destroyed.

Maybe your VPN connection is going down and up though, and this when the problem starts?

Thanks for your fast response.

I still have a few other things to try, so will report back in a day or so.

Tim

Is Cx-Programmer running on the same machine as the gateway?
What driver is Cx-Programmer using?
I have had issues with another scada both fighting for local port 9600 when using fins/udp
Have you tried changing the bind port on the fins/udp driver on the gateway?

No, CX Programmer is not running on the same machine. It is running on a different machine on the Local PLC network. Was just testing to make sure the PLC itself was responsive. (the Gateway running the Omron Driver is on a remote network via a VPN).

Nothing should be competing for the UDP9600 port on the Gateway machine. (that i am aware of)

I have configured a TCP connection to the PLC on the Gateway with some test tags also in tandem with the UDP connection, both running fine the last couple of hours. Will wait and see …

OK, the PLC communications ran fine for a couple of hours, then I suspect the VPN had a short drop out.

Following this I cannot re-establish the TCP connection for some reason. It is showing this error:

It reports it is ‘already connected’ but it shows ‘reconnectwait’ on the device status.

“Already connected” is an error code coming from the PLC. It thinks you already have a connection from this node and it’s denying the connect attempt.

Reconnect_Wait is the state your’e catching the driver in as it attempts to (re)connect and then waits to try again.

Does it eventually connect if you leave it like this?

Not sure … after 10 minutes I reset the PLC Ethernet port and it connected immediately. It appears the PLC is holding the connection whilst the SCADA had communications interrupted. I will do some reading about the PLC end. Will start with looking at the keep alive functionality and under what conditions the PLC will release a TCP connection.

Here’s something else to try, but only with the TCP connection mode: set your local/source/driver node address to 0. This allows the PLC to assign us one when we connect rather than using a fixed value.

If the logical connection from the old node is still alive in the PLC then maybe when you reconnect you’ll get assigned a new one and everything will work.

Thanks Kevin,

I think we may be on to something. I agree with you above, this may allow us to get another connection, this model of PLC has 3 available. Some of the bigger PLC’s have 16 from memory.

Some reading on the ‘Keep Alive’ function has caused me to turn on this feature, which should reset the TCP connections after 1 minute of no activity with the settings I have made. This was turned off by default in the PLC and I suspect it may have been locking up connections ‘indefinitely’ … !

image|536x170