8.3.10 UDT disabling triggering alarm... odd one

Ignition
1

So working on a 8.3.10 system, with about 116k tags in one provider (so far - it's going to increase a bunch more).
Loaded about 800 udt instances today for AIs that have alarm udts as childern.

Alarm UDTs have a "stat" tag that handles the actual alarm. And an "ALMEN" tag that handles enable/disable (referenced by the actual alarm config). The alarm config's enable is an expression: if(isGood({[.]ALMEN}),{[.]ALMEN},True).

All the UDT instances have the ALMEN = false

So I went and disabled some of the UDTs, and AFTER I disable them, I'm getting an alarm (on some of the tags, not all. And only generally on 1 of the alarms. So then I have to re-enable the UDT, acknowledge the alarm (which throws an error saying it's trying to ack an alarm that is no longer active). If I then go and disable the UDT again, the alarm pops back up. Rinse-and-repeat.

UNLESS - after acking the false alarm, I disable the STAT tag first and apply.. THEN disable the UDT. Then I don't get an alarm.

To me, it seems like while disabling the entire UDT, the ALMEN tag is getting disabled before the STAT, and the STAT is then interpreting the disabled ALMEN as "bad", so enabling the alarm.

Annoying as can be since I just disabled a few hundred UDTs and now have to go renable individually to clean up the mess.

2

What if you add an extra condition to your expression to check the quality of the STAT tag also? This way if there is a race condition, maybe that will catch it.

3

Maybe. It's just weird and I've never seen it before. I'm wondering if it's got anything to do with the fixes they put in place to resolve the regressions on the alarm Querystatus stuff. Because what's really odd-- the alarm shows as Active in the Status Table, even though it's not. Even the Alarm Metrics rollup doesn't show any active alarms.