CompactLogix Driver Issues? [wrapper.log info inside]

Ignition
1

Our customer told us they saw some ‘false alarms’ in their alarm log. The log entries are added to the MySQL database via Gateway tag change scripts. We are using Ignition 7.6.6 and the AB Drivers version 1.6.6 (b2014040112) with a CompactLogix 1769-L24ER-QB1B, Revision 20.13.

I am very confused as to why this happened. My insert statement only executes if the following condition is true:

if (not initialChange) and (tagQuality == "Good") and (tagValue == 1):

Long story short, we monitor 3-7 sensors in each of the customer’s rooms. The data in the PLC is formatted as follows. The highlighted tags are the two in question that triggered the tag change scripts:

The strange thing is that all of these tags read by ignition are part of the same data structure in the PLC, but this only happened for one of the sensors in that UDT array. I should also clarify that the value of the tags were 1 (alarm state) at the times listed in the log below. So, the sensors were already in alarm, but somehow the script two additional times roughly 2 hours after the original alarm. The temperature did not go above our LoLo setpoint (and then back down below it to add new recors to the log), which is why they found this to be strange. It was already in alarm when this happened.

I found the following entries in the wrapper.log file which corresponded to the times of the false alarms. There were no other entries in wrapper.log similar to these.

INFO   | jvm 1    | 2014/04/25 05:15:33 | INFO  [CompactLogixDriver[ParRoomMonitoring_CLGX]] [05:15:32,774]: Processor info: Vendor=1, Product Type=14, Product Code=149, Revision=20.13, Product Name=1769-L24ER-QB1B/A LOGIX5324ER
INFO   | jvm 1    | 2014/04/25 05:15:33 | INFO  [CompactLogixDriver[ParRoomMonitoring_CLGX]] [05:15:33,018]: [ParRoomMonitoring_CLGX] Using cached tag data, processor edit number(1536) matches cached edit number(1536).

INFO   | jvm 1    | 2014/04/25 05:26:19 | INFO  [CompactLogixDriver[ParRoomMonitoring_CLGX]] [05:26:18,982]: Processor info: Vendor=1, Product Type=14, Product Code=149, Revision=20.13, Product Name=1769-L24ER-QB1B/A LOGIX5324ER
INFO   | jvm 1    | 2014/04/25 05:26:19 | INFO  [CompactLogixDriver[ParRoomMonitoring_CLGX]] [05:26:18,983]: [ParRoomMonitoring_CLGX] Using cached tag data, processor edit number(1536) matches cached edit number(1536).

Please let me know if I can add any information to make this clearer.

2

Anything?

3

If you have the entirety of the logs from that period of time it might be helpful.

One example that could cause this would be that your tag change script doesn’t guard against the value going 1 -> null -> 1, which is what would happen if the connection to the device went down/up at some point. It also doesn’t guard against the quality going good -> bad -> good, which could happen if comms got slowed down or a big rebrowse happened and the tags happened to get marked stale temporarily.

4

How would one modify the script to deal with such a scenario? Do I need to monitor the “oldValue” to make sure it wasn’t null? Is that possible in a gateway tag change script?

5

You’d have to figure out some way to reliably store the old value (DB? memory tags? Yuck…). It’s a bit outside the scope of what tag change scripts are meant to handle.

That being said… Ignition 7.7 introduces some improvements to the tag change scripts, including the ability to choose whether to execute on just V or VQ/VQT changes, as well as a ‘lastValue’ magic variable that can be accessed.