I have about 17 tags that have been deleted from my tag gateway, yet they still show up in my OPC Connections subscriptions. I have verified they do not exist amongst any of my other device connections. Is there a method to completely flush these from the system?
So far I have attempted restarting my OPC-UA Module, I've disabled and enabled the specific device connection, and I've completely deleted the device connection and rebuilt. Yet, these 17 tags are still there.
I should clarify that my screen capture is not showing ALL 17 tags, simply a subset. The way these were originally configured, each tag results in about 66 tag reads (subscriptions), which is why I'm trying to remove them.
Then something other than a tag is creating those subscriptions. The only likely culprit would be one or more SQL Bridge transaction groups, which can make direct OPC subscriptions.
Or, perhaps, you've exposed your OPC server to external clients, and one of those clients is make these subscriptions.
Thanks, Phil. Interesting as I had not considered any SQL items. I'll investigate and see if I find anything.
After disabling all existing SQL connections, the tags still exist in the device subscription, so that doesn't appear to be the culprit.
Database connections and transaction groups aren’t the same thing.
Hello, Kevin. I'm not sure I follow what you mean by transaction groups?
Transaction groups are supplied by the SQL Bridge module. Do you have that installed? If so, do you have any transaction groups showing in the designer for any projects?
https://docs.inductiveautomation.com/pages/viewpage.action?pageId=58597803
Looking under my System->Modules section on the gateways, I do not see anything for SQL Bridge. I assume that's where I'd see it?
Yes. So those aren't causing the problem. Is your OPC server exposed to external clients?
Are these tags hiding in another tag provider maybe?
Our system uses the Ignition OPC-UA module. How would I check for exposure to external clients?
We utilize redundancy, both on the back end tag gateways and the front end vision gateways. I thought that maybe the secondary back end tag gateway was out-of-sync, so I did force a re-sync there, but no change for these tags.
To give more context, the previous engineer(s) configured "Module" tags within each of our tag providers, which are all separate ControlLogix PLCs (about 12 in total). So, for every 1756 I/O module physically installed in a rack, information can be monitored, such as faults, status, etc. But, the manner which the Ignition tags were configured results in a HUGE amount of unnecessary concurrent tag subscriptions. For a single 1756-IA32 module, there are 66 subscriptions. I figured out a way to reduce this to 2 subscriptions for every IA32 and after implementing my change, these 17 tags associated with IA32 modules are still subscribed in the old UDT format (1,122 subscribed tags!!), but I can't find how or from where.
Just as a curiosity test, I deleted all module tags from this specific tag provider (PLC). Every other tag is gone except these 17. Oddly enough, there is a single IA32 tag that did disappear completely, which I think was the very first one that I reconfigured. On that one, I deleted the original tag and then built an identically named tag but used a new UDT. For the remaining, I simply changed the underlying UDT type and then made the necessary tag config changes.
It's as if these 17 are stuck in limbo.
You should probably give support a call and let them poke around.
Will do, thanks.
I would look at the OPC Server Settings, Bind Address and make sure it is "localhost". Note the port number. Then run netstat -npt in a root terminal (or the Windows equivalent). You should find pairs of entries with localhost (aka 127.0.0.1) and that port in the list, one with the port as local, the other as remote, but all with Ignition's PID w/ java as the program. One of my VMs looks like this:
netstat -npt
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:32000 127.0.0.1:31000 ESTABLISHED 813/ignition-gatewa
tcp6 0 0 192.168.19.88:46210 192.168.19.1:5434 ESTABLISHED 916/java
tcp6 0 0 192.168.19.88:38306 192.168.19.1:5434 ESTABLISHED 916/java
tcp6 0 0 127.0.0.1:31000 127.0.0.1:32000 ESTABLISHED 916/java
tcp6 0 0 127.0.0.1:56844 127.0.0.1:4096 ESTABLISHED 916/java
tcp6 0 0 127.0.0.1:4096 127.0.0.1:56844 ESTABLISHED 916/java
tcp6 0 0 127.0.0.1:56846 127.0.0.1:4096 ESTABLISHED 916/java
tcp6 0 0 127.0.0.1:4096 127.0.0.1:56846 ESTABLISHED 916/java
{ Pruned the non-relevant entries. }
Thanks, Phil.
That's exactly what I see for my server.
Updating to notify that my issue has been resolved, but I'm not exactly certain on how or why.
I had to perform some maintenance on my master tag gateway this morning, which required a fail over to our redundant backup tag gateway. Upon completing my maintenance and rebooting, once the master took control back from its partner, my remnant tag subscriptions were gone. The subscribed tag count is also as it should be now that my tags are using a new UDT.