EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: alarm lag
From: Andrew Johnson <[email protected]>
To: "Kasemir, Kay" <[email protected]>
Cc: EPICS core-talk <[email protected]>, "Chen, Xihui" <[email protected]>
Date: Thu, 30 May 2013 14:17:53 -0500
Hi Kay,

On 2013-05-30 Kasemir, Kay wrote:
> This might really be a tricky issue.
> 
> The naive meaning of DBE_ALARM is: Notify me when the alarm changes.
> 
> But do we want an update on the alarm of that very field that we're
> monitoring? EPICS can't do that for anything but VAL, so the meaning of
> DBE_ALARM is somewhat undefined for anything but VAL, and we could leave
> it at that.

When you ask for a DBR_STS_xxx type you currently get the alarm information 
for the record as a whole, no matter which field you're asking about.  The 
meaning of such a request is not actually undefined at all in my mind.

If we wanted the design to be that non-VAL fields don't support alarms at all, 
we would have arranged to provide some default (probably no-alarm) status when 
fetching non-VAL field data using the DBR_STS_xxx types.  We didn't do that 
though, and whoever wrote db_post_events() obviously saw the need to support 
updating the alarm status of many monitor subscriptions at once; the code 
comment mentions this exact issue.

> Or do we declare this shortcoming of EPICS records to be a feature, so now
> we mean: Send me an update when the primary, one and only alarm state of
> the record changes, because I know that's a shortcoming of EPICS, and I
> really want that alarm update for any field, even if it doesn't really
> apply to the field I'm monitoring? Maybe that's going too far, because in
> the future we may support per-field alarms, and then this 'feature' would
> really be a bug.

I think you're confusing (or conflating) the record's alarm status with some 
kind of error status for the field.  That's not what the alarm status means, 
although it would obviously be nice to be able to support those semantics.  
However I believe the current code would need quite a lot of changes to 
support per-field status & severity, so I don't think there's much danger of 
us adding that to the existing IOC for a while at least.

Now Marty's V4 Java Database can support multiple alarm regions per record if 
I've understood it properly, but even there you have the fundamental question 
what it means to ask for the alarm severity of a field that sets its own alarm 
severity?

> Sooo…: Leave it as is?

I filed this as Launchpad bug 139024.  Since it's not going to be that hard to 
trigger alarm monitors on non-VAL fields I think doing so will seal up a few 
more cracks in the model that the IOC provides to the world.  I will talk to 
Tim Mooney though to get his opinion, and listen to anyone else who comments 
here.

- Andrew
-- 
It is difficult to get a man to understand something, when his salary
depends upon his not understanding it. -- Upton Sinclair


References:
Re: alarm lag Andrew Johnson
Re: alarm lag Kasemir, Kay

Navigate by Date:
Prev: Re: alarm lag Pearson, Matthew R.
Next: Re: alarm lag Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: alarm lag Andrew Johnson
Next: [Merge] lp:~anj/epics-base/udf-severity into lp:epics-base noreply
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·