Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: scanRecord for 3.14
From: Marty Kraimer <mrk@aps.anl.gov>
Cc: tech-talk@aps.anl.gov
Date: Mon, 08 Dec 2003 07:57:10 -0600
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  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
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  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019 
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 ·