Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Thu, 30 May 2013 12:48:11 -0500

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System