Alarm cleared event with Auto-Ack as user

Hi everyone,

Is there a case scenario where an alarm has a cleared status with "Auto-Ack" as user? All alarms are set to Manual acknowledgement mode.

This thread seems to be the best information I can find on how that works, but I don't see how an Auto-Ack could be the user unless the tag was configured to auto acknowledge.

In case it can help you solve this mystery, here is the documentation on Ack User alarm property.

1 Like

It's not configured to auto acknowledge.

Active to clear is capturing a user. I'm not sure why and it's happening with many alarms. The project shouldn't have any alarms to auto acknowledge and as far as I checked, it doesn't have. So I'm a bit confused.

You're probably hitting the live event limit for your alarm(s)?

1 Like

Yes, the client is not acknowledging repetitive alarms. But those events are yellow and it has a message like "Live Alarm Limit".. or something like that.

So, I can explain to the client about having maximum 5 active events before hitting the limit. But I don't know the reason of "Auto-Ack" showing up on a clear event. Plus the label is the static name instead of the dynamic label that it has.

Some transition has to happen. As mentioned in that other thread, there are exactly four states that define every alarm in Ignition. So if you hit the live event limit, and you want new alarms to be generated, the old ones must be cleared. So the system does that, generating a 'clear' event.

It could be a bug that it doesn't capture the label and other info; I don't know the alarm system well enough to say that for sure. But the behavior of the live event limit is pretty clear.

1 Like

I will post some screenshots from the journal when I get access to a client PC again. There are events where it's acknowledged but others are just cleared with that Auto-Ack.

Maybe a big screenshot has the final clue.

Edit 1:
Adding screenshots. I didn't asked for permission so I erased their text.

Source Path 1:

Source Path 2:

Source Path 3:

Source Path 4: This list was longer so I just grabbed a piece of it

From 8.1 Manual


Each active event has to be acknowledge with a default limit of 5.

What happens if an active event cannot be acknowledged anymore? (Regardless the 5 limit) Let's say, a Gateway restart. That could be a case where an event was active & unacked, then cleared & unacked but never cleared & acked. There may be other normal cases that I cannot think of, and then we can have abnormal cases or behaviors.

I'm happy if I can pinpoint a normal scenario.

Im pretty sure the only reason i get auto-ack is when im installing large windows updates on the gateway and gateway downtime is exciding the "Continuous Event Detection Window (min)". Then all alarms that are not active will get auto-ack on startup.

Are you sure all of the alarms are in manual mode and not auto?

I submitted bug on this the other week. Alarm Journal does not use "lable" on live event limits. Even with static config enabled.

Yes, I'm sure. A colleague checked as well in case I'd miss something.

In my case it's using it. Does it supposed to? That static text is just "alarm".

If you leave the alarm name "Alarm 1" and specify the label like the picture below.
The Label column will show "Alarm 1" instead of "Pressure super duper high" when live event limit is reached.

image
You need to go config->Alarming->Journal->static config=enable. If not it will use name instead of label on all of them: active, cleared, and acknowledged.

Id recommend making a test alarm tag with a different display path so you can filter it away from the live system and use it for testing and investigation.

example:


I think I figure out what you mean.

I'd say that the difference is that your label is static, that's why you would need "static config = True"
It is clear when you look at the database directly.

This point is still interesting though, as Live Event Limit is catching a static value when it's set by default not to.

Edit 1:

After further checking I can see that display path is not being stored when there is a System Acknowledgement. It also doesn't have an entry in the alarm_event_data table.