g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  Index 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Re: proposed RTYP field
From: jemian@arev.uni.aps.anl.gov (Pete Jemian)
To: mrk@aps.anl.gov
Cc: tech-talk@aps.anl.gov
Date: Thu, 8 Jan 98 15:11:11 CST
Regarding the proposed RTYP field for dbCommon:

Marty Kraimer wrote:
> With regards to accessing the record type via channel access, Matthais
> Clausen asked for this a long time ago. I have it on my 3.13 TODO list. 

In fact, I believe I first proposed this (November 1996).

A lengthy discussion ensued which branched in many directions.
It was not clear from the discussion what path would be taken.
It appeared to me that the purpose of this field was lost during
the discussion.  That purpose was to allow a Channel Access
client to determine the type of a given PV.

> 
> Your proposal is one way to handle the problem (yet another dbCommon
> field???). It does, however, require that the client take a channel
> name, strip off the field, append "RTYP", and do a search and get. Maybe
> this is an OK interim solution. Another possibility is too see if some
> changes to dbAccess and ca can make it possible to just ask CA directly
> for the record type just like you can now ask for native type, native
> count, etc.

How is this simpler for the end user?  Seems like this makes more
work.  Better to provide a record field, then end users can access the
.RTYP field through a caget call.

> 
> Ultimately we should allow full dynamic discovery of record type, field
> names, field types. This will NOT happen until at least CA V4.
> 
> By the way this is the next item on my epics 3.13 TODO list. Thus
> comments are welcome. Maybe William's suggestion is what we should do
> for 3.13. It is certainly simple. The static database access library
> could fill in the name. Thus no other code needs to be modified.

Excellent approach.  One vote for ASAP.

Pete Jemian




Navigate by Date:
Prev: Re: EPICS r3.13 field DESC length William Lupton
Next: Re: EPICS r3.13 field DESC length Tim Mooney
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: RE: EPICS r3.13 field DESC length Jeff Hill
Next: RE: proposed RTYP field Jeff Hill
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·