Hello, I wanted to know how the live event limit works, I have looked at the help but it is not very clear.
what does it give us?
can it be deactivated?
thanks
Hello @lachguerabdallah ,
Have you got any answers?
I don't understand very well either, because in the life of an alarm that is unique to a TagPath/Alarm, I don't get the meaning of generating multiple Active-ACK-Cleared flows. Other SCADAs only have a single lifecycle for the same alarm and I don't see the functionality, I would like to disable it so as not to always filter the alarm listings.
Thank you
The live event limit comes into play in a scenario like:
- An alarm is generated.
- The alarm condition clears.
- Before someone has acknowledge it, the alarm condition is triggered again.
If you did not have multiple 'stacked' events, then the fact that the first alarm was never acknowledged is lost. If you want to emulate that behavior, then set the live event limit for your system to 1.
Thanks @PGriffith,
I understand the proccess, but what I don't understand and I think that @lachguerabdallah neither is that as other SCADA, with no this Live Event Limit, when this case ocurs :
- Alarm Activated
- Alarm Cleared
- Alarm Activates again
- Alarm Acknowledged
- Alarm Cleared
You don't lose the NOT ack event between 2 and 3 step, because as the alarm is unique with its path, you can follow in the journal that after the step 2, the alarm is triggered again and nobody acknowledged it.
Then the problem is that every alarm has a "System AutoACK" that we need to filter and without any functionality for us.
I understand that there are many hours of programming behind this parameter and there must be some reason, but we are not able to see an advantage.
And since we are talking about it, I take the opportunity to ask for the possibility of disabling it completely, for example by setting it to "0", thus avoiding the System AutoACK.
Thanks
I didn't add the feature, it long predates my involvement with Inductive Automation and I am not an expert in alarming in the first place.
In Ignition, alarms are uniquely identified by a UUID. That is, the path will be unique, but also each time an alarm is generated, that alarm gets a unique identifier, so that acknowledgement is paired with that specific alarm event. That's strictly more information than what you're proposing. I'm not aware of any ability nor plans to change the functionality of alarming in the way you're proposing, but I would encourage you contact our Support or Sales Engineering department to outline your concerns more formally; I'm just a developer who spends (too much) time on the forum, not someone who can give you official responses.