"Auto-ack" alarms

Hey everybody, I’m using 8.1.5 perspective, and on two seperate projects I keep having alarms that will trigger a “clear” pipeline even though an alarm never engages. It shows it was “auto-acked” in the alarm history. End user just gets a bunch of “alarm clear” notifications and no alarms and they didn’t care for being woke up at 3 AM for this stuff.

The signal will jump outside of the alarm setpoints but will return to normal before the active delay expires, so it never fully engages as an alarm. However I still get a clear notification.

Support has no solution at this time. I’ve had to disable clear notifications for these two projects (not ideal).

Notify Initial Events is set to false.

My thought was to filter out auto-acked alarms from the clear filter, but I don’t know if that’s possible.

I can’t imagine I’m the only one dealing with this but thought I would throw it out to see what you all think.

Just a thought, but what about having your PLC decide when something is in alarm, and just pass a Boolean to Ignition? My work is exclusively in discrete I/O and this is how i handle all alarms.

1 Like

That’s an incredibly time intensive work around for something that should work out of the box. I certainly hope it doesn’t come to that. I have at least 400 alarms so this doesn’t feel like a direction I’d like to head. Most of my alarms are analog, so that’s most of the problem.

I would hope Ignition can handle a non-discrete alarm properly.

That's...unusual. That's not how I would expect the active delay property to work, and that's not how it's working on a test tag I set up. If I'm not at the alarm setpoint for at least the active delay, I don't get any events on the alarm.

Auto-ack events are coming from the 'live event limit' in your alarm settings, and you can't have a clear event without a corresponding active event - it's fundamental to how our alarming works. I would go back to support and ask for clarification.

2 Likes

I’ve increased the live event limit before and it delayed the symptom. It filled up the larger buffer then stared happening again.

Hi toughautomation, I'm having the same problem with the auto-ack. Exactly the same problem, with the clear pipeline emails. The alarm triggers the clear pipeline but there is no a corresponding activation alarm or event.

Did you find any solution to this problem?

Hey there's somebody else out there with this problem! NO! There has been no solution from IA. My customers have been living without clear notifications for almost 2 years. I have a new system that I can't tell the difference on that doesn't do it. Can you share any details about your system/how you handle alarms, maybe the PLC driver you use?

Did either of you call support and create a support ticket? If not, I highly recommend that you do. This forum is great, but not an official means of support.

Yes, multiple times.

Not sure if this helps, but I see the 'Auto-Ack' clear event if an alarm is disabled for a while and then re-enabled or when it is enabled for the first time.

This sounds like a similar thread I read last month:

Nowadays you can probably do this with an expression block checking either the Ack'ed By or Ack'ed By Name property (not sure which) against "Auto-Ack" and just leaving the true branch disconnected so it drops the alarm from the pipeline.

1 Like

Filtering out Auto-ack was my first thought but I was told it wasn't possible at the time, but that was almost 2 years ago. I didn't notice that they added this, I'll give it a shot, I hope this works!

1 Like

For some reason I can't find this list in the 8.1 docs, but the SystemAck property might be another one to try to filter on as an alternative to Ack'ed By.

https://docs.inductiveautomation.com/display/DOC80/Alarm+Event+Properties+Reference#AlarmEventPropertiesReference-AlarmRuntimeProperties