EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  <19961997  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  Index 1994  1995  <19961997  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 
<== Date ==> <== Thread ==>

Subject: Hardware Configuration
From: Marty Kraimer <[email protected]>
To: [email protected]
Date: Fri, 08 Nov 1996 14:25:43 -0600
Some more thoughts on hardware configuration. These thoughts
result from previous "grief" about hardware configuration
and the RAWL/RAWH E-mail discussion. This has been a topic
of discussion for several years but we could never develop
a consensus about what to do.

The following gives some thoughts on a possible approach
 
The existing 3.13 format for defining a recordtype is quite
adaquate for defining hardware specific values,
including configuration, diagnostic, and alarm info.
It should not be necessary to develop another syntax.
 
For the following discussion I use the term "hardware record".
I assume it has same syntax as existing 3.13 recordtype definition.
(We may have to add something to allow different levels of support.
Will ignore details like this for now.)
 
I think that the main issue to be decided before real progress can be made is:
 
What purposes does a hardware record serve?
 
One way to answer this question is to ask who
has access to a hardware record. I think only the following
should be considered:
 
1) Device/Driver support. This is why we are having this discussion!!!
2) Database Configuration Tools. Using the existing recordtype
   syntax should allow all 3.13 DCTs to also process hardware records.
3) Channel Access/Database Access clients.
   This is the root of the problem!!! The following are possible uses:
   a) Provide device status.
   b) Display raw values and other diagnostic information.
   c) On line hardware add/delete/modification
 
The solution I have been advocating is to provide a full fledged
record support module for each device. This causes loud screams from
everyone who is responsible for implementing device/driver support.
I maintain that to provide all of the functions listed above it is
necessary to provide almost all the dbCommon fields and also almost all the
RSET functions. (We could, of course, invent an entirely new way of
handling hardware confuration. To get the functionality desired I bet
it will be at least as complicated to use as existing RSET methods).

Let me summarize:

dbCommon Fields:
  NAME          needed
  DESC          ?
  scan fields   Needed if want record to be scanned. Often not needed.
                NOTE THAT THIS IS REALLY MANY MANY fields
  alarm fields  Needed if CA client
  Lock Set
  CA Pvt        "
  Access Sec    "
 
RSET
  report                Probably not needed
  init                  Sure seems nice
  init_record           Mandatory
  process               Often not needed. If not needed removes MUCH code.
  special               If want to know about changes. Needed for run time mods
  get_value             Obsolete
  cvt_dbaddr            If using arrays (Think of 16 channel adc)
  get_array_info        "
  put_array_info        "
  get_units             ? I think not necessary
  get_precision         Dont get me started about precision
  get_enum_str          Normally not necessary
  get_enum_strs         Normally not necessary
  put_enum_str          Normally not necessary
  get_graphic_double    ? I think not necessary
  get_control_double    ? I think not necessary
  get_alarm_double      ? I think not necessary
 
 
Now I will make a suggestion.
 
If we provide four types of run time support for hardware records
maybe we can satisfy all concerns:
 
Level 0: Just what we have today. Can only be used for devices that
need no configuration info except that provided by existing link types.
A caviot is that DCTs will not have "nice" access to this info.

Level 1: No run time support occurs. A record can still be created for
each device instance for configuration purposes. Note that even
simple VME devices will require such records because they need VME
resources.  In addition such records must be provided if DCTs are needed to
report hardware configuration.
 
Level 2: CA run time support but no processing.
 
Level 3: Full blown RSET support just like now.
 
Comments?

Marty Kraimer



Replies:
Re: Hardware Configuration Ralph Lange

Navigate by Date:
Prev: Re: RAWL/RAWH Marty Kraimer
Next: Re: Using g++ with 3.13 beta2 Jeff Hill
Index: 1994  1995  <19961997  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: RAWL/RAWH Marty Kraimer
Next: Re: Hardware Configuration Ralph Lange
Index: 1994  1995  <19961997  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·