How to silence "No reply from outstation" alarm

[tnash44]

Trying to find where I can edit my analog output point to stop the working 1 redirections action list once an alarm has been acknowledged. 

Every other alarm I get, silences and stops the redirection action list once acknowledged except for one analog output point. I get an alarm reading "Control to... request failed - No reply from outstation" which makes sense, the outstation signal is bad, but when I acknowledge the alarm I would expect it to quit sending alarms. This one doesn't. It continues to send a text alarm as if no one has noticed. 

I've disabled the alarm, but would rather understand why this one works differently. 

Any ideas where to look? 

Thanks, 

[BevanWeiss]

You'd need to show us the redirections you have configured on the Point (Properties -> Redirection) and at each higher level Group up the hierarchy (including the $Root object).

It is possible to configure redirections to occur on Acknowledged alarms.. so that seems like the likely cause.

Or you have Abort state set to something 'not good' in which case if it's Unack+Active that initiated the redirection timing, then even if it's Ack'd it won't abort the timer... the redirection will happen regardless.

Normally 'Always' is the setting I use (I can't say I've reviewed my decision for correctness lately however... so a pinch of salt to that recommendation).

[tnash44]

Thanks for the help! 

I've dug into those redirections in each higher level group beyond the analog input point and can only see one folder that has it's redirections enabled. The one called "points" in the attached picture. It's abort state is set to Always. 

This is where I'm confused; we can acknowledge all other alarms for points with the "points" folder, how could this one be different if there aren't any redirections set up for that particular point?

I might be missing something when you're referring to $Root object. Beyond the higher level group folders I've shown in the picture , I have looked at Outstation, Outstation Set, and Channel (if this is what's meant by $Root) and none of those have redirections enabled either. 

[AndrewScott]

A control failed alarm is a fleeting alarm, see https://tprojects.schneider-electric.com/GeoSCADAHelp/Geo%20SCADA%202020/Default.htm#AlarmsGuide/Fle....

When a fleeting alarm is acknowledged it is cleared and therefore removed immediately. This means if you issue another control to the point and it also fails then it will raise a new alarm for this second control.

What specifically do you mean by "It continues to send a text alarm …"? Are you referring to a redirection sending emails or text messages or something else?

NB. The root group is just the top most group in the database tree, represented by the system name in ViewX.

[tnash44]

So it didn't seem to raise a separate alarm. Attaching a picture from the events screen that tracks the alarm redirections for "control to 76% request failed" alarm raised at 4:00 AM (this doesn't show up in picture).

Picture isn't in chronological order, rather alphabetical but I'll jot down steps chronologically:

4:00:33 - 30 Seconds after it's raised it redirects to email action 

4:00:43 - Emails (received as a text) Tyler and Doug 

4:00:53 - Emails managers

4:02:02 - Doug acknowledges the alarm from clear scada mobile 

4:04:33 - Emails 1293 (texts Doug) 

4:08:33 - Emails 1293 (texts Doug)

Continues to text Doug every 4 mins until there are no more redirections 

[AndrewScott]

The first screenshot only (partially) shows a single redirection called "Calendar" in the parent group, but these events show multiple other redirections.

Can you share the full configuration of the "E-Mail Action - Critical - 7-1293" and "E-Mail Action - Critical - 7-1211" redirections that are executed after the alarm has been acknowledged and cleared? The abort states are of particular interest.

[tnash44]

Here is a screen shot of the Calendar -> Working 1 Redirections, where we email the alarm to a few different email address every 4 minutes or so, all of which have their abort state set to Acknowledged. 

Also included in shot is the Email action properties folder for both Critical 7-1211 and Critical 7-1293.

All alarms go to one or both of these email addresses once redirected to the calendar. As far as I know, all alarms can be acknowledged and will abort the calendar's redirections other then this one point that did not abort once acknowledged. 

I appreciate the help, Thanks!

[AndrewScott · Accepted solution]

I suspect this issue is related to the "Abort State" of Acknowledged as a fleeting alarm is immediately cleared when it is acknowledged, unlike an 'ordinary' alarm.

[BevanWeiss · Accepted solution]

I concur.

Normal alarms would go:

Unacknowledged Uncleared -> Acknowledged Uncleared

a fleeting alarm goes

Unacknowledged Cleared -> No alarm instance

For a Fleeting alarm, having Always may not be desirable, since you wouldn't ever get a redirection for it.

I suspect that this is a 'tricky one', that perhaps the alarm state handling may need to 'force' in a transition to Acknowledged Cleared (a state that I'm not sure really exists currently) before it finally disappears.

Or the Redirections needs to somehow handle this Acknowledgement of fleeting/already cleared alarms.

[tnash44]

That was it. You guys were saying it along and somehow I missed the redirections weren't set to "always" way up at the Calendar settings under Email Alarms. Made the change this morning and had the alarm clear and silence as soon as we acknowledged it. 

Thanks for the help!!