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
<2013>
2014
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
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|