We are having an issue with a remote location regarding the communication through a VPN tunnel.
What we are finding is any and all "Value Change" scripts that are based on OPC tags changing value are re-triggered upon gateway restoration. This is causing some issues with accurate data logging from the remote site as well as some extra database writes that are not valid.
We are using a basic script:
def valueChanged(tag, tagPath, previousValue, currentValue, initialChange, missedEvents):
system.tag.writeBlocking(["[.]../Recipe Misc/Trigger"], [1])
Until we figure out why the VPN tunnel is not rigid enough for the site is there anyway we could look at the tag data to not allow to fire unless a stable connection is made? We tried using the previous value in the script but it did not work either.
The setup is as follows:
Server + Gateway + Database in Location A
VPN Tunnel to Location B
Location B has the PLC that all OPC tags are being brought from.
What have you tried so far?
We tried:
def valueChanged(tag, tagPath, previousValue, currentValue, initialChange, missedEvents):
if previousValue != currentValue:
system.tag.writeBlocking(["[.]../Recipe Misc/Trigger"], [1])
But it still fires even though the value did not in fact change.
This makes me think that you are making an OPC connection through the tunnel to a PLC that has its own OPC server, or to an OPC server in Location B.
But your symptoms sound like you are using a native driver in the gateway in Location A and polling through the VPN. If so, then you are unlikely to succeed. PLC branded query-response protocols have no state associated with them, so will always give bad quality when disconnected/interrupted (and will perform dramatically slower than a local connection). You should fix this first, perhaps with a base install of Ignition Edge.
You are correct we are polling through the VPN as of right now.
We have a full ignition sever going into Location B but unfortunately that has been a slow process. This was an attempt to get data tracking started with what we have now.
Log the qualified values and see what is going on. I'd expect a quality change, if nothing else, when the connection is lost.
If the situation is temporary, I'd not bother expending labor to work around the pathological case. Just clean up the data in batches until the other server is deployed. Perhaps use this information to justify a faster deployment.
Thanks for the quick responses, I will log the values to see what they are doing as Kevin mentioned but also going to push this to IT.