Re: recDynLink.c for R3.14.1 ?

[Tim Mooney <mooney@aps.anl.gov>]

Kate, re...,

> > Jens Eden converted recDynLink to EPICS 3.14, and I've made a
> > few trivial modifications from the code he sent me.  I don't know
> > on what platform(s) the code has been run, or even if it has been
> > run.  I'm converting most of synApps (which includes recDynLink with
> > modifications to support ca_put_callback links), but I haven't tested
> > anything yet.
> 
> Interesting, I am converting most of the stdApp and motorApp, which might be
> overlapping with your work.  I got scaler and bitIO working on the RTEMS
> platform.

Great.  Can I have the code you're converted?  Right now, I have code that
compiles for all the mca stuff, recDynlink, the busy, swait, transform,
sCalcout, epid, and sscan records, kohzuCtl.stt, hr_Ctl.stt, aiCvtDouble,
fGetDateStr, sCalcPostfix, sCalcPerform, and saveData, and I'm pretty close
with dbrestore and save_restore.  I'll send you whatever you want, or post
it on our web pages when I get back from vacation, next Tuesday.

> Time Mooney wrote :
> 
> >For the record, recDynLink was the original implementation (by Marty
> >Kraimer) of retargetable links.  Now that all EPICS links are
> >retargetable,
> >it's probably preferable to use standard links, unless you want a
> >(putNotify) callback when the execution your link started completes.
> 
> 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.

-- 
Tim Mooney (mooney@aps.anl.gov; 630-252-5417)
Advanced Photon Source
APS Operations Division
Beamline Controls & Data Acquisition Group