OPCUA AB Contrologix driver taking time to drop subscription

Ignition
1

Hi

I am running Ignition 7.5.6 on a Windows 2003 R2 SP1 virtual server.

I have a allen bradley controllogix device added to the Ignition OPC UA server.

I have 37 transactions with block data items totalling 17641 tags on this device. All transaction groups have the same execution frequency.

The problem is when i stop these groups or make a change and save those changes, firstly the device takes like 10 minutes to drop the items from subscription as i can see from the diagnostics and the wrapper log is filled with messages like

INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,207]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4465]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,207]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4466]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,207]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4467]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,207]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4468]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,207]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4469]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,207]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4470]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,347]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4471]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,347]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4472]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,347]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4473]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,347]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4474]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:51 | WARN [SamplingRateProvider ] [08:10:51,347]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4475]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:52 | WARN [SamplingRateProvider ] [08:10:51,347]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4476]”, using fallback of 1000ms.
INFO | jvm 1 | 2013/04/02 08:10:52 | WARN [SamplingRateProvider ] [08:10:51,488]: Could not find any MonitoredItems for NodeId “[BH45LogHandling]Global.LTLogNos.LTLogNos[4477]”, using fallback of 1000ms.

Once the messages end, the items are slowly dropped from subscription. This process is taking like a good 10 minutes, means 10 minutes of data loss.

2

So basicaly, if i edit the transaction and restart them, first the subscription items in the device diagnostics slowly decrease from 17000 to 0 and during this time, the values in the transactions are all zero.

Once it is zero, it quickly becomes 17000 again and valid values only then start coming in the transactions.

Anyway to improve this behaviour.

3

Can you export the logs.bin.gz from the Console and post it here or send it to the support inbox?

I think that the cause of that message has been fixed in the OPC-UA module 1.5.7 beta code, but I’m not certain if it’s related at all to the unsubscribe of a large quantity of tags being as slow as you’re seeing. I’ll have to see if I can reproduce that.

4

Well the log file just had 17000 messages of what i pasted in my first post. nothing else which caught my attention.

Ofcourse if you can test by subscribing a large quantity of tags on a single device and then just try restarting the transaction group and see the device diagnostics, you will be able to see.

I am attaching the logs.bin file. Check the messages on 2nd April, 2013 8:00 AM onwards.

I tried the same transactions using an OPC Dcom Server and the behaviour was much better i.e. the group was able to start again after stopping with the correct data within 30 seconds.
Copy of logs.zip (305 KB)

5

Deleting 25,000 tags at once on a VM here only takes ~22 seconds.

I would take a look and see if the VM you’re running on is under-provisioned, has high cpu usage, or Ignition is using a high percentage of the memory allocated to it. It should not be taking anywhere near 10 minutes.

That being said, I’ve done a little work to improve the performance that will be available in the next 7.5.7 beta and the 7.5.7 release.

6

i have my tags on a controllogix device. The time to reduce the tags was like between 4-5 minutes always, not less and not more but still the behaviour is a problem for us. Thankyou for your response and hopefully in the next version this behaviour is taken care of.