Is alarm deadband factored into an alarm's active delay?

Ignition
1

I am trying to understand why an alarm was triggered in the following scenario.

I have an alarm to detect when a motor is stalling when its output speed is <20% of its commanded speed. Because it can look like it's stalling while starting and stopping, there is a 60 second active delay and is also only triggered when the motor is active. To clear, the speed needs to be >80% of its commanded speed or stopped for 10 minutes.

In the image below, I have a case of where an alarm was triggered on the right x trace. The bottom grey line corresponds to the alarm setpoint and the top grey line corresponds to the deadband upper limit. In this case, the motor has its speed capped at 60Hz by drive parameters despite being commanded at 90Hz, which is above the alarm setpoint, but within the deadband. It only makes sense that the alarm would trigger if this time within the deadband is counted as part of the active delay, as total time <20% speed is well below 60 seconds.

However, I am also unable to manually reproduce the alarm under these conditions, so it seems there is a special timing to things, though I have had these alarms tripped under the same conditions multiple times.

alarm
alarm990×837 31.1 KB

Alarm settings:

alarm2
alarm2796×201 16 KB

Version: 8.1.38

2

Looks perfectly normal to me.

Value < low deadband boundary starts the timer. Value never gets above high deadband boundary, so timer continues until complete. :man_shrugging:

3

Is this alarm configured on an expression tag? Can you share the expression?

4

It is. This is the expression:

if({[.]Active}, {[.]FreqDiffPercent}, 1)

and FreqDiffPercent is another expression tag:

if({[.]CommandedFreq} > 0, abs({[.]OutputFreq} / {[.]CommandedFreq}), 1)

5

Elaborating a bit more on what @pturmel said:
From your post, it looks like Ignition opted to evaluate the deadband (latch) as part of the alarm active condition (timer input), not as part of the alarm active state (post timer).

For reference on Output Frequency setpoints based on 90Hz Commanded Frequency (I assume these are the calcs for your horizontal markers...):
90Hz * 0.2 = 18Hz (OutFreq @ Alarm Active)
90Hz * (0.2+0.6) = 72Hz (OutFreq @ Alarm Clear)

At the moment the motor starts, so should the alarm active delay timer (as output freq < 18Hz). Since alarm condition (<=20%) was met, alarm clear condtion (>=80%) must then be met prior to delay timer elapsing or alarm will become active.
I.e. If motor takes > 60 seconds to ramp to 72Hz, alarm goes active. Every time.

This worries me... Seems like this should be very repeatable. Would be worth setting up a set of memory tags with this logic and verifying that you can reproduce the outcome reliably.