EPICS Controls 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  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  <19981999  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: Re: EPICS r3.13 field DESC length
From: [email protected] (Tim Mooney)
To: [email protected]
Date: Thu, 8 Jan 1998 15:20:15 -0600
re...


>         field(VERS,DBF_DOUBLE) {
>                 prompt("Version Number") 
>                 promptgroup(GUI_DISPLAY) 
>                 special(SPC_NOMOD)
>                 interest(1)
>                 initial(<version>)
>         }                
> 
> The record developer changes <version> whenever he/she modifies the
> record support.
> Thus the version will be available automatically. If this is done we
> can't put the field in dbCommon.

I think it would be a bad idea to set the record's version number in the .dbd
file anyway.  (It might not be so bad for the .dbd file to have its own version
number, so record-support could verify that it wasn't compiled against an
outdated header file.)

Anyway, I'm in favor of every record having a VERS field.  I think the device
support's version number should also be available via channel access.  I don't
care whether or not version numbers are in dbCommon.

> 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. 
> 
> 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.

It would be better, I think, to have the RSET function get_description(), which
would allow custom record support to tell clients anything it wants, including
record type and even application-specific information and on a field-by-field
basis (assuming you put extra description fields in your custom record).  This
might give clients directly the information they'd otherwise have to infer from
RTYP, without forcing them to know the details of any record type, and it could
still allow an app developer to change the way things are implemented without
having to rewrite clients.

Tim Mooney

Replies:
Re: EPICS r3.13 fields RTYP/VERS Ralph Lange

Navigate by Date:
Prev: Re: proposed RTYP field Pete Jemian
Next: Re: EPICS r3.13 fields RTYP/VERS Ralph Lange
Index: 1994  1995  1996  1997  <19981999  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: EPICS r3.13 field DESC length William Lupton
Next: Re: EPICS r3.13 fields RTYP/VERS Ralph Lange
Index: 1994  1995  1996  1997  <19981999  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 ·