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  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: wrong timestamps in monitors
From: Andrew Johnson <[email protected]>
To: Dirk Zimoch <[email protected]>
Cc: EPICS tech-talk <[email protected]>
Date: Fri, 30 Jan 2009 17:30:05 -0600
On Friday 30 January 2009 02:30:05 Dirk Zimoch wrote:
> Andrew Johnson wrote:
> ...
>
> > I believe it is well-recognized that the status and severity of a PV
> > reflect the state of the record containing that PV rather than the state
> > of PV value itself.
>
> This is not fully true.
> * The "pseudo fields" RTYP and VERS report random (?) status and severity.

That's a bug that I wasn't aware of which I'll try to fix for R3.14.11.  It 
might be tricky to return the record's status and severity for these (I 
haven't found the relevent code yet), but the results ought not to be random 
in any case.

> * When using monitors on fields, lets say EGU, status and severity are not
> updated when they change and thus do not reflect the state of the PV.

We only post monitors when the named value changes, not as a result of any 
attributes changing.  I think it would be possible to create a record type 
that did that, but I'm not sure I'd like the result:

 * It would have calls to db_post_events() for every field in the record that 
could be monitored through CA.
 * Every writable field that is used as an attribute would have to be marked 
special, so it can catch external puts to that field.
 * An appropriate set of db_post_events() calls would have to be made whenever 
one of the record's attribute fields was changed.

The record doesn't know whether any of its fields are being monitored at all, 
so it has to post monitor events for every observable field and let the CA 
server ignore the ones that aren't currently connected to any clients.

I'm not sure how useful the result would be in practice; I'd be interested to 
hear if anybody actually tries it.

> BTW: Many records have a general problem reporting correct attributes to
> any field but VAL. For example, reporting the EGU field as the units of the
> PREC field is obvious nonsense.

I agree this is a long-standing issue in most record types which could be 
fixed.  For your specific example most records currently return the EGU field 
contents for any request to their get_units() routine, which is obviously 
wrong.  This can be fixed pretty easily, it just requires modification of one 
record support routine to only return the EGU contents for those fields that 
actually contain values in that unit.

I'll see what I can do.  I'm going to assume that returning an empty string is 
better than the wrong string, but it's not obvious what to do for the A-L 
fields of the CALC or SUB records for example — there are probably databases 
in use right now that rely on the current behavior to supply EGU as the unit 
string for one or more of these fields, so I will avoid breaking them.

The PREC field value is currently returned as an attribute of only the VAL 
field for most analog record types; I think it should be used for the alarm 
and display limit fields too.

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte


Replies:
RE: wrong timestamps in monitors Dalesio, Leo
References:
wrong timestamps in monitors Benjamin Franksen
Re: wrong timestamps in monitors Andrew Johnson
Re: wrong timestamps in monitors Dirk Zimoch

Navigate by Date:
Prev: Open Source Software For Experimental Physics? Matthieu Bec
Next: Re: EDM text control for password entry John Sinclair
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: wrong timestamps in monitors Dirk Zimoch
Next: RE: wrong timestamps in monitors Dalesio, Leo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 31 Jan 2014 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·