Experimental Physics and Industrial Control System
This is a reply to all who responded to my message.
scanRecord will be back in the next 3.14 release.
It will be changed to use dbCaPutCallback instead of recDynLink
Tim Mooney is changing synApps so that it uses dbCaPutCallback instead of
recDynLinks.
I few other changes are also being made so that dbCaPutCallback is easy to use.
calcoutRecord will have associated device support. The default will be
compatible with existing databases.
The following new device suport modules will be available as part of devSoft.dbd
device(ao,CONSTANT,devAoSoftCallback,"Async Soft Channel")
device(bo,CONSTANT,devBoSoftCallback,"Async Soft Channel")
device(calcout,CONSTANT,devCalcoutSoftCallback,"Async Soft Channel")
device(longout,CONSTANT,devLoSoftCallback,"Async Soft Channel")
device(mbbo,CONSTANT,devMbboSoftCallback,"Async Soft Channel")
device(mbboDirect,CONSTANT,devMbboDirectSoftCallback,"Async Soft Channel")
device(stringout,CONSTANT,devSoSoftCallback,"Async Soft Channel")
Each of these does the following:
If the OUT field is a channel access link then dbCaPutCallback is called instead
of dbCaPut. The record stays active until the put completes.
A brief note about recDynLink. It was written before 3.13, which was the first
release that allowed links to be modified at run time. Synapps made extensive
use of it and also modified it to use ca_array_put_callback. When 3.14 became
available, synapps stll needed recDynLink because of the ca_arry_put_callback
feature. A great deal of effort has been spend getting the dbCa code to work
reliably when a link is modified while asynchronous records are active. I
suspect that recDynLink suffers from the same defects that were fixed in dbCa.
dbCaPutCallback was implented so that synapps can remove the use of recDynLink.
In case you wonder why dbCaPutCallback is usefull here is an example.
A put causes a set of actions to be performed. The set may contain processing of
asynchronous records, e.g. I/O to GPIB instruments. The user want to make sure
that ALL actions are complete before continuing on to some other action.
If dbCaPutCallback is not available then the application must monitor all
actions to see that they have completed. If dbCaPutCallback is available it can
just have a record with something like:
record(...)
{
field(DTYP,"Async Soft Channel")
field(OUT,"<name> CA")
field(FLNK,"<next action>")
}
Marty Kraimer
- References:
- RE: scanRecord for 3.14 Redman, Russell O.
- Navigate by Date:
- Prev:
Re: scanRecord for 3.14 Tim Mooney
- Next:
Re: Novice EPICS questions re yet another port Marty Kraimer
- 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: scanRecord for 3.14 Tim Mooney
- Next:
"assert (this->exitWait ( DBL_MAX ))" failed Kate Feng
- 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