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…
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.
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.
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?
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 …
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.
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’ … !
@tjcorbin
Sorry for bringing up an old topic, I am experiencing similar issues currently and the image you had attached to your post isn't loading anymore.
First, did this solution resolve the problem with the reconnect wait message?
Secondly, I assume you don't still have the screenshot of the setting, but do you recall where you found the option at? Was it inside of CX-Programmer or on the Web Interface for the ethernet card?
