EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: CA monitoring weirdness for status/severity
From: "Johnson, Andrew N." <[email protected]>
To: "Hogben, Colin H" <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Mon, 7 Aug 2017 18:22:05 +0000
Hi Colin,

On Aug 7, 2017, at 3:32 PM, Hogben, Colin H <[email protected]> wrote:
> On 07/08/17 14:22, Mark Rivers wrote:
>> However, the HIGH field does not have Rec Proc Monitor, so writing to the HIGH field does not cause monitor events to be posted.  So your original camonitor program does not get an event.  However, if you run camonitor again it connects to the channel and does get the new timestamp and status.
> 
> Well, I do get an update for the monitoring of the HIGH field, but the status/severity passed in the update are the previous state - I'm guessing the update of HIGH is sent out before the record gets processed.

Correct, IIRC as long as the field isn't the VAL field the monitor update gets posted before the record's process() routine is called as a result of the PP flag on the field's definition.

> My aim of my bridge is: given an arbitrary PV name, monitor the PV to obtain its value and/or an indication as to whether the value is invalid or unavailable.  Based on my experiments and what you guys have said, my current understanding is thus:
> 
> * If the PV represents the VAL field. then the status & severity in updates may be used; in effect, this is effectively a short-cut to getting the VAL, STAT and SEVR fields at the same time.
> 
> * If the PV represents any other field, the status and severity in an update are meaningless noise and should be disregarded.
> 
> Is that a reasonable approximation?

Yes. You could also use the presence of a '.' in the PV name to switch behaviors since .VAL is the default field if none is specified. Note that IOC PVs are likely to behave differently from those from other kinds of servers (CAS-based), and these rules only apply to IOCs.

You should probably only subscribe to non-VAL fields using the basic DBR_DOUBLE etc. data types, not the ones with the extra metadata (DBR_TIME_DOUBLE etc.) so you won't see the potentially invalid information.

- Andrew

-- 
Sent from my iPad

Replies:
Re: CA monitoring weirdness for status/severity Hogben, Colin H
References:
CA monitoring weirdness for status/severity Hogben, Colin H
Re: CA monitoring weirdness for status/severity Johnson, Andrew N.
Re: CA monitoring weirdness for status/severity Hogben, Colin H
RE: CA monitoring weirdness for status/severity Mark Rivers
Re: CA monitoring weirdness for status/severity Hogben, Colin H

Navigate by Date:
Prev: Re: CA monitoring weirdness for status/severity Hogben, Colin H
Next: Re: Debian packages for debian 9 (stretch) ? Bo Jakobsen
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: CA monitoring weirdness for status/severity Hogben, Colin H
Next: Re: CA monitoring weirdness for status/severity Hogben, Colin H
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·