EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: DA property hierarchy for interfacing to the DBR_XXXX types
From: "Jeff Hill" <[email protected]>
To: "'EPICS core-talk'" <[email protected]>
Date: Thu, 13 Sep 2007 17:23:41 -0600
All,

Here is a latest revision of how DBR types might be mapped to DataAccess
property space. There are two points to bear in mind here. First, this must
map to preexisting DBR_XXXX functionality. Second, this needs to be the core
elements of an interface safely carrying us forward in the future - serving
as a scaffolding on which to hang all future PV properties. Therefore the
initial names and the depth of the hierarchy might be quite important. 
I am not at this time defining the properties that do not map to preexisting
DBR_XXXX functionality.

I am open to any suggestions on how this might better be arranged and or
named. In particular, the alarm acknowledgement part may still need some
work.

PS: I am aware of and have been referring to the following wiki page. My
primary divergence is a tendency towards more hierarchy in what I have
defined below. The increased hierarchy seems to be desirable from my
perspective because.

1) The implementation of a catalog indexing a property container can be
quite efficient even without a hash table - if there are relatively few
properties in each bucket in the hierarchy. It does appear at this time that
CA will make a regular and heavy use of random access to a property
container using the property identifier as an index. 

2) The property names can be in most situations single words, and that
appears to be a cosmetically hygienic approach when property names start to
appear in the source code.

3) It's easier to include sufficient hierarchy up front, and relatively
harder to add hierarchy later when more parameters start showing up.

http://www.aps.anl.gov/epics/wiki/index.php/V4_Standard_Properties_and_Event
s

// DBR Property Hierarchy
// ----------------------
// value
//   time
//   precision
//     decimalDigits
//   units
//   limits
//     control
//       upper
//       lower
//     display
//       upper
//       lower
//     alarm
//       major
//         upper
//         lower
//       minor
//         upper
//         lower
//   alarm 
//     condition
//       severity
//       status
//     acknowledgement
//       pending (is a transient alarm pending acknowledgement)
//       severity (the highest unacknowledged alarm severity)
//   stateSet
//     labels
//   class
//

Thanks in advance for any comments.

Jeff
______________________________________________________
Jeffrey O. Hill           Internet     [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107



Replies:
Re: DA property hierarchy for interfacing to the DBR_XXXX types Ralph Lange

Navigate by Date:
Prev: Re: osdWireConfig.h Andrew Johnson
Next: Re: DA property hierarchy for interfacing to the DBR_XXXX types Ralph Lange
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: osdWireConfig.h Andrew Johnson
Next: Re: DA property hierarchy for interfacing to the DBR_XXXX types Ralph Lange
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·