Alarm escalation alternatives


My client would like Alarms to escalate if they are not acknowledged or cleared for some amount of time. They were hoping to be able to change the alarm priority in realtime, which i’ve discovered we can’t do (alarm needs to clear and be active again before priority is re-evaluated).

Has anyone come up with alternatives to the Alarming Notification Profiles? We don’t really want to send out emails or texts for escalation, would prefer something more based in the Ignition client, like a new (higher priority) alarm activating, however i can see that getting messy.

I was listening in on a “Coffee with Kevin” webinar session last month, and asked the question.
It was recommended to add a binding to the alarm priority utilizing the AlertActiveTime, something like this:

if(dateDiff({[.]Value.AlertActiveTime},now(),"sec") < 30 , 1,3)

So if the alert has been active for less than 30s, it will be low priority (1), else it is escalated to high priority (3).

However this doesn’t work, and there are several problems with it.

  1. Alarm priority binding only seems to evaluate once, presumably when the alarm condition evaluates true.
    The AlertActiveTime value is NULL when alarm is inactive, and seems to update too slow, resulting in the above expression always evaluating to 3, because the dateDiff in seconds is calculated to something like ‘1,515,699,522.974’.

  2. Even a manual binding of a dropdown menu to the alarm priority doesn’t work, as a change to the priority will only show up once the alarm has re-evaluated (cleared and gone active again). Which isn’t really valid escalation.

Has anyone got something to work in this regard? I thought it was a simple task but it’s doing my head in!

Hi Richard,

I think I have something that works, using a UDT. Attached is a project and tags you can feel free to modify, whack, hack, puree, bury for three days, dig it up, chuck into the neighbor’s dumpster… whatever.

JC Alarm Test Tags.xml (4.0 KB)
JCAlarmElapsed_2018-01-11_1731.proj (12.0 KB)

EDIT Files updated to reflect (hopefully) correct stuff…

1 Like

Hi Jordan,

Thanks for the reply. Look forward to checking that out.
Looks like the .xml export doesn’t contain a UDT definition for UDTParentType “AlarmTest” though, just a definition for “Andon Assembly” tag UDT.

Whoops! :open_mouth: File should be okay now…