Experimental Physics and
Industrial Control System

"Feng, Shuchen" <[email protected]> · Mon, 14 Apr 2003 22:37:58 -0400

Tim Mooney wrote: 

> 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.

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.

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) ?  

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.

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.

>In any case, I'm sending you the recDynLink code in a separate
>email.  (I don't think the whole list needs a copy of this code
>right this minute.  It will be included in the first 3.14-compatible
>version of synApps.)

It is highly appreciated.  However, maybe you and Bob can  clarify my above
questions better.

Thanks,
Kate

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System