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: Attribute events; was: Alarm Limits
From: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Fri, 20 Mar 2009 22:53:28 +0100
Hi Andrew

I agree with almost everything you say. The more principled approach is, I 
think, to add a new field property to the dbd syntax. Something like

	field(HIHI,DBF_DOUBLE) {
		...
		attribute(VAL)
		attribute(OVAL)
	}

That is, the argument to 'attribute' names another field for which this one 
influences (or directly provides) a CA attribute.

(I am not at all wedded to the concrete syntax, something like 
attribute(VAL,OVAL,...)  would serve as well. Another variant is to make 
this a field property of VAL, OVAL, etc. as in

	field(VAL,DBF_DOUBLE) {
		...
		attribute(EGU,HIHI,LOLO,...)
	}

However, depending in how exactly properties are parsed and stored 
internally, it may be simpler to implement the former version in such a way 
that one has quick access to the 'master fields' for a given 'attribute 
field'.

I also don't care about 'attribute' vs. 'property' naming.)

Base (dbAccess) takes care of querying this field property and posts events 
for all 'master fields' with DBE_ATTRIBUTE as mask whenever the field in 
question gets written to from outside of the record. This means adding a 
few lines of code at a handfull of places in dbAccess.c, maybe a short 
routine for retrieving the 'master fields'.

Of course, there may be (some few) record types that internally change 
fields that serve as (or influence) CA attributes. These record supports 
would have to be adapted to take the new field property into account when 
posting events.

> > If I have overlooked some serious drawback in this proposal I'm sure
> > someone will point it out soon...
>
> Just the question about how we get db_post_events() called for the right
> fields.
>
> The mbb[io] records already mark their *ST and *VL fields as special in
> order to recalculate the SDEF field, so for my experiment above I was
> able to easily hook into this code and post a DBE_ATTRIBUTE event on the
> VAL field at the same time.  Unfortunately MEDM doesn't monitor ENUM
> fields using a DBR_CTRL_ENUM type; it only requests the graphical data
> whenever the channel connects, so while it is encouraging, my experiment
> is a long way from being useful.

Yes, of course. Effectively using this feature needs changes to the CA 
clients, mostly the display managers.

Cheers
Ben

References:
Alarm Limits Pierrick Hanlet
Re: Alarm Limits Benjamin Franksen
Re: Attribute events; was: Alarm Limits Andrew Johnson

Navigate by Date:
Prev: Motor problems(RBV can't update itself) Xu, Huijuan
Next: Re: epics GUIs (update) Matthias Clausen
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: Attribute events; was: Alarm Limits Andrew Johnson
Next: edm crashing in execute mode Pierrick Hanlet
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 ·