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