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  2020  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  2020 
<== Date ==> <== Thread ==>

Subject: Re: recDynLink.c for R3.14.1 ?
From: Kate Feng <feng1@bnl.gov>
To: tech-talk@aps.anl.gov
Date: Tue, 15 Apr 2003 10:41:06 -0400
Hi Tim,

Tim Mooney wrote:

> -- snip --

>
> > Did you mean not to process the next link untill the triggering link
> > completes ? I thought I could get this done in the R3.13 using the
> > FLNK options, which perhaps called the original recDynLink.c or others.
> > Maybe I misunderstand what you meant for the putNotify callback.
>
> You can get pretty far in this direction with FLNK's, but that's not what
> the seq record does.  It just does db or ca puts to its output links, and
> fires those links on a schedule. It doesn't know or care whether processing
> started by a link is finished before it fires the next link.
>
> The FLNK-based solution doesn't wait for completion of work started by a CA
> link, so it's restricted to a single ioc.
>
> > However, Bob Dalesio wrote earlier :
> >
> > > If all this record allows is the ability to change address links
> > > dynamically, it is no longer needed. Since 3.13, all address fields can
> > > be changed dynamically. I do not recall what else that it did.
> >
> > It tells me that the capability of the dynamic link is not done
> > in the file recDynLink.c. Can someone please tell me what files
> > implement the dynamic link in R3.14 ? Where is the up-to-date
> > document for using the dynamic link in R3.14 (even R3.13) ?
>
> Marty and Bob, and maybe others, wrote the EPICS dynamic links, and those
> links don't use recDynLink.  recDynLink still exists only because there is
> no other convenient way for a database to do a ca_put_callback.  (Note that
> this is not a capability solely of the link; the record must also have a
> callback routine, and its process() routine must know what to do when that
> callback comes in.  Also, the record must handle the possibility that an
> expected callback will not come in, that ca_put_callback () might fail
> because another ca_put_callback is already in progress, etc.)
>
> > Tim wrote :
> >
> > >Note that the version of recDynLink in base has never had this
> > >capability, so if you've been using the version from base, you
> > >can switch to standard links.  We still need recDynLink for the sscan
> > >and
> > >swait records, because they must wait for processing they start to
> > >finish,
> >
> > Tracing tech-talk, I got the impression that the
> > swait and wait records should be replaced by sCalcout and Calcout
> > records, which seems to be true for my motor test so far.  However,
> > I am new to the stdApp and motor application.  The sscan record is
> > what I am pondering for its (motor) application of the dynamic link.
>
> Here's my understanding of all the EPICS calculation records:
>
> wait      -- retired, replaced by calcout
> calcout   -- use for calculations unless you have a specific reason to use
>              something else
> swait     -- use only if you need a ca_put_callback link
> sCalcout  -- use only if you need string expressions--for example, to
>              program dynamic links, or to talk to a serial device.
> transform -- use only if you need to evaluate several expressions, or
>              a very complicated expression, or if you need multiple
>              inputs/outputs.
>
> The sscan record is altogether different from any of calculation record.
> It's job is to make a change, wait for the change to complete, make a
> measurement, wait for the measurement to complete, and loop.
>
> > Tim wrote:
> >
> > >and I plan to write a version of the seq record with the option of
> > >waiting
> > >until processing started by one link has finished before firing the next
> > >link
> > >in the sequence.  We've been doing this with sequences of swait records
> > >often
> > >enough to know that the capability will get used.
> >
> > Hmm.  I thought this was done in EPICS already.
> > However, I have to admit that I never used seq record yet for my
> > application.
>
> No.  To my knowledge, nothing available to an EPICS database programmer
> ensures in every case that processing started by link A will finish before
> link B fires, except a callback link.
>

The issu is really to do a ca_put_callback.  In the past, I used other ways  of
programming to get around that for simpler applications.    However,  you had
your reason to write the scaler and motor records in a fashion that you
needed the ca_put_callback.  Considering the complication of beamline
applications,  it is better to  port  recDynLink.c  and swait.c to R3.14.


Many Thanks,
Kate




Replies:
Re: recDynLink.c for R3.14.1 ? Benjamin Franksen
References:
RE: recDynLink.c for R3.14.1 ? Feng, Shuchen
Re: recDynLink.c for R3.14.1 ? Tim Mooney

Navigate by Date:
Prev: Re: NI1014 GPIB controller Marty Kraimer
Next: Re: NI1014 GPIB controller Till Straumann
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  2020 
Navigate by Thread:
Prev: Re: recDynLink.c for R3.14.1 ? Tim Mooney
Next: Re: recDynLink.c for R3.14.1 ? Benjamin Franksen
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  2020 
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 ·