Experimental Physics and Industrial Control System
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
<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: 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
<2003>
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024