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: "Kasemir, Kay" <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS core-talk <[email protected]>, "Chen, Xihui" <[email protected]>
Date: Thu, 30 May 2013 14:07:20 -0400
Hi:

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.

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.


Sooo…: Leave it as is?

-Kay




On May 30, 2013, at 1:48 PM, Andrew Johnson <[email protected]> wrote:
> Hello Kay,
> 
> On 2013-05-30 Kasemir, Kay wrote:
>> At the SNS, we've decided to learn about the basics of EPICS ;-)
> 
> Cool, tell me if you find out anything interesting!
> 
> (Quoting everything for core-talk's benefit...)
> 
>> Records have one status/severity. It's really tied to the value field of
>> the record, but you get the same STAT/SEVR-based status and severity when
>> you monitor other fields of the record. This resulted in some surprise
>> when displaying both the VAL and for example HIGH in a user interface
>> where by default everything is alarm-sensitive:
>> 
>> Record goes into alarm
>> -> widget that displays VAL indicates the alarm state, but widget that
>> displays the HIGH value stays as is.
>> 
>> Re-open the display
>> -> now both the widget for VAL and HIGH may be in alarm state if this
>> resulted in a newly established connection. If those PVs remained
>> connected because some other display uses the same PVs, you could still
>> get HIGH-without-alarm.
>> 
>> You can get the same behavior with 'camonitor' on the command line, at
>> least for R3.14.12.2.
>> 
>> I think we understand why it's behaving this way, see Matt's explanation
>> below.
>> 
>> Still, it's a bit unexpected because the monitor is for value and alarm
>> (DBE_VALUE  |  DBE_ALARM). Should a DBE_ALARM update monitors on any field
>> whenever the alarm state changes? Is this a bug, or a feature?
> 
> This is certainly a feature; if it's a bug I suspect it's really a problem in 
> the design rather than the implementation.  To change the behavior would 
> require the server to send an update for every alarm monitor on a record (no 
> matter what field it is monitoring) whenever a call to db_post_events() has an 
> event mask with the DBE_ALARM bit set.
> 
> Hmm, I'm looking at db_post_events() where I see this code; the comment is 
> interesting...
> 
>    for (pevent = (struct evSubscrip *) prec->mlis.node.next;
>        pevent; pevent = (struct evSubscrip *) pevent->node.next){
> 
>        /*
>         * Only send event msg if they are waiting on the field which
>         * changed or pval==NULL and waiting on alarms and alarms changed
>         */
>        if ( (dbChannelField(pevent->chan) == (void *)pField || pField==NULL) 
> &&
>            (caEventMask & pevent->select)) {
>            db_field_log *pLog = db_create_event_log(pevent);
>            pLog = dbChannelRunPreChain(pevent->chan, pLog);
>            if (pLog) db_queue_event_log(pevent, pLog);
>        }
>    }
> 
> I read this to mean that if a record were to call db_post_events() with a NULL 
> for the field pointer, it would trigger updates on all subscriptions that have 
> matching event mask bits, no matter what field they're monitoring, which I 
> think is what you're asking for...
> 
> None of the standard record types (that I know of) pass a NULL pField pointer 
> into db_post_events().  Testing... make a quick change to aiRecord::monitor...  
> it works!  
> 
> Ok, so this really is a bug in all of the standard record types (and probably 
> in all external record types too).  The issue now is how to change all the 
> standard record types to fix it.  That's going to take some work to get right, 
> and because it's a behavior change it will have to happen on the 3.15 branch. 
> For now I think Xihui's solution is probably the right one, but I will file a 
> bug report for this and put it on my mental list of things that need working 
> on.
> 
> Hmm, I wonder if I can use that for DBE_PROPERTY changes as well, it does 
> simplify the task significantly...
> 
> Thanks,
> 
> - Andrew
> 
>> On May 29, 2013, at 5:40 PM, "Pearson, Matthew R." <[email protected]> 
> wrote:
>>> Hi,
>>> 
>>> I took a look at the ai record. Think I know what's happening….
>>> 
>>> If I set LOW to cause an alarm condition:
>>> 
>>> Step 1) When I set LOW field in the record, the IOC monitor task notices
>>> that the field has changed and sends a channel access monitor update. The
>>> camonitor client then sees a change to LOW, with no alarm because that
>>> record is not in alarm state yet.
>>> 
>>> Step 2) The record processes with a new LOW limit. It goes into alarm
>>> state, and does a db_post_event on the value. It doesn't update the LOW
>>> field. So any monitors on the VAL will see the new alarm state. Any
>>> monitors on the LOW won't see anything.
>>> 
>>> Step 3) The record processes again for some reason. The monitor task sees
>>> that the alarm state on LOW has changed. So it sends out the new alarm
>>> state over channel access.
>>> 
>>> Step 4) The LOW field is changed again, to cause the record to go out of
>>> alarm state. The monitor task sees that LOW has changed, so sends out
>>> updates (still the record is in alarm state). The record hasn't processed
>>> yet, so a monitor on VAL has not seen any change.
>>> 
>>> Step 5) The record precesses. It goes out of alarm state, and posts an
>>> update on VAL (but not LOW).
>>> 
>>> So I think it's correct. Xihui said it's probably wrong to have an alarm
>>> sensitive widget on a limit field anyway, and I agree with that.
>>> 
>>> Cheers,
>>> Matt
> -- 
> It is difficult to get a man to understand something, when his salary
> depends upon his not understanding it. -- Upton Sinclair



Replies:
Re: alarm lag Pearson, Matthew R.
Re: alarm lag Andrew Johnson
References:
Re: alarm lag Andrew Johnson

Navigate by Date:
Prev: Re: alarm lag Andrew Johnson
Next: Re: alarm lag Pearson, Matthew R.
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: Re: alarm lag Pearson, Matthew R.
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 ·