Experimental Physics and Industrial Control System
William Lupton wrote:
> > Note also that the warning message is telling the application engineer
> > that he/she has given a value that will not appear as specified in the
> > database. It really is a database configuration error.
>
> I had assumed that the default DESC strings were somehow in base, but in
> fact I think this is not the case: the defaults are in the Capfast symbols.
> Perhaps we should at least ensure that none of the default DESC strings in
> the symbols exceeds the limit and triggers the warning?
I will let all of you Capfast folks figure this out.
> Finally, I can't help following Andy's lead and asking why there is no
> record field that indicates the record type. I believe that this could
> often be useful. What about RTYP?
I think Andy was proposing something different. He was asking for a
field that gives the version of the record. He said
field(VERS,DBF_DOUBLE) {
prompt("Version Number")
promptgroup(GUI_DISPLAY)
special(SPC_NOMOD)
interest(1)
}
If this is used then the record support module is responsible for
setting the version value.
In this case we could put this new field in dbCommon (yet another
dbCommon field???)
This would mean that all existing record support would have to be
modified to set the version number.
Now if this is changed to
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.
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.
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.
Marty Kraimer
- References:
- Re: EPICS r3.13 field DESC length William Lupton
- Navigate by Date:
- Prev:
Re: EPICS r3.13 field DESC length William Lupton
- Next:
Re: EPICS r3.13 field DESC length William Lupton
- Index:
1994
1995
1996
1997
<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: EPICS r3.13 field DESC length William Lupton
- Next:
Re: EPICS r3.13 field DESC length William Lupton
- Index:
1994
1995
1996
1997
<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