Hi Tim,
Just checked my notes...
I was using an Asyn motor driver that was doing callbacks to device support everytime the controller position changed. So, typically at the end of a move there is some settling time after DMOV=1. So there can be 2 or 3 callbacks after DMOV=1, and each one causes the motor record to process, triggering the forward link each time.
So it was more a driver issue than a motor record issue.
Here are some debug print statements I added. This was a typical short move:
devMotorAsyn::asynCallback(). Calling dbProcess().
devMotorAsyn::statusCallback(). Calling dbProcess().
devMotorAsyn::statusCallback(). Calling dbProcess().
devMotorAsyn::statusCallback(). Calling dbProcess().
devMotorAsyn::statusCallback(). Calling dbProcess().
devMotorAsyn::statusCallback(). Calling dbProcess().
devMotorAsyn::statusCallback(). Calling dbProcess().
motorRecord::process: calling recGblFwdLink(pmr).
drvPmacThread: Process mp49:geo:A:flink
devMotorAsyn::statusCallback(). Calling dbProcess().
motorRecord::process: calling recGblFwdLink(pmr).
drvPmacThread: Process mp49:geo:A:flink
devMotorAsyn::statusCallback(). Calling dbProcess().
motorRecord::process: calling recGblFwdLink(pmr).
drvPmacThread: Process mp49:geo:A:flink
Where mp49:geo:A:flink was the record attached to the motor record via the FLNK. I think the print statement in the motor record was only happening if DMOV=1, so I had:
If (dmov==1)
Print motorRecord::process: calling recGblFwdLink(pmr).
And I had TPRO turned on for mp49:geo:A:flink.
Cheers,
Matt
> -----Original Message-----
> From: Tim Mooney [mailto:[email protected]]
> Sent: 21 June 2012 22:17
> To: Pearson, Matthew (DLSLtd,RAL,DIA)
> Cc: [email protected]; daron chabot
> Subject: Re: put callback queuing
>
> Hi Matt,
>
> I don't recall noticing that, and so far I haven't found a way to make
> it happen with the device type I have handy (VME58). Do you remember
> any other details?
>
> Tim
>
> ----- Original Message -----
> From: "matthew pearson" <[email protected]>
> To: [email protected], "daron chabot" <[email protected]>
> Cc: [email protected]
> Sent: Thursday, June 21, 2012 12:56:59 PM
> Subject: RE: put callback queuing
>
> Hi,
>
> Just a note about motor record forward links. I seem to remember
> recGblFwdLink is called several times after the end of a move, because
> the record is processed several times after DMOV=1. So you may see 2 or
> 3 processes of records linked using FLNK.
>
> The calcout method should work though. I think we use that to detect
> the end of a move too.
>
> Cheers,
> Matt
>
>
> > -----Original Message-----
> > From: [email protected] [mailto:tech-talk-
> > [email protected]] On Behalf Of Tim Mooney
> > Sent: 21 June 2012 17:30
> > To: Daron Chabot
> > Cc: EPICS
> > Subject: Re: put callback queuing
> >
> > Daron,
> >
> > By the way, if there is an actual need for a "stop" put_callback that
> > completes only after the motor has decelerated to a stop, you could
> > implement it in the database. (We did something similar with the mca
> > record, for a user who needed to start acquisition with a
> put_callback,
> > and then, during acquisition, periodically issue put_callbacks to
> read
> > mca data, with the "read" commands not completing until the read
> > operation actually had posted data.)
> >
> > You need a separate record to which the "stop" put_callback is
> written.
> > Here's one way to do it:
> >
> > record(motor, "motor1") {
> > ...
> > field(FLNK, "declare_done")
> > }
> > record(busy, "stop_motor1") {
> > field(OUT, "motor1.STOP CA")
> > }
> > record(bo, "declare_done") {
> > field(DOL, "0")
> > field(OUT, "stop_motor1.VAL CA")
> > }
> >
> > If you write 1 to "motor1_stop" with a ca_put_callback, it'll cause
> the
> > motor to stop, and you won't get a callback until the motor really
> has
> > stopped.
> >
> > If you can't commandeer the motor's FLNK, you could use something
> like
> > this instead of "declare_done":
> >
> > record(calcout, "detect_done") {
> > field(SDIS, "stop_motor1.VAL NPP")
> > field(DISV, "0")
> > field(INPA, "motor1.DMOV CP")
> > field(CALC, "a?0:1")
> > field(OOPT, "Transition To Zero")
> > field(OUT, "stop_motor1.VAL CA")
> > }
> >
> > Tim
> >
> > ----- Original Message -----
> > From: "Tim Mooney" <[email protected]>
> > To: "Daron Chabot" <[email protected]>
> > Cc: "EPICS" <[email protected]>
> > Sent: Thursday, June 21, 2012 10:48:20 AM
> > Subject: Re: put callback queuing
> >
> > Daron,
> >
> > It intends to do that, because even if a record were capable of
> keeping
> > track of more than one completeable command, it has no way to tell
> > EPICS which command just completed. All it has is its forward link,
> > which communicates an unqualified "done". So there wouldn't have
> been
> > a reason to implement a mechanism that could track more than one
> > putNotify on a record at a time.
> >
> > Tim
> >
> > ----- Original Message -----
> > From: "Daron Chabot" <[email protected]>
> > To: "EPICS" <[email protected]>
> > Sent: Thursday, June 21, 2012 9:50:40 AM
> > Subject: put callback queuing
> >
> > Hi,
> >
> > Recently at BNL, we've been investigating a report of unexpected
> > behavior found when using put-callbacks to a Motor Record (verified
> > using a simulated motor). After initiating a long-running motion with
> >
> > caput -c -w 100 test:motor1 <some large value>
> >
> > trying to stop the motor in the following way fails:
> >
> > caput -c -w 100 test:motor1.STOP 1
> >
> > After observing that the 2nd put-with-callback to stop the motion is
> > not seen by the Motor Record, a look through
> > $EPICS_BASE/src/rsrv/camessage.c reveals that concurrent put notifies
> > are queued in the IOC server:
> >
> > /******************************/
> > if ( pciu->pPutNotify ) {
> >
> > /*
> > * serialize concurrent put notifies
> > */
> > /******************************/
> >
> > I can understand serializing put-callbacks on a per-channel basis,
> but
> > the implementation appears to serialize _per-record_.
> >
> > What am I missing? A little help please...
> >
> >
> > -- dc
> >
> > --
> > Tim Mooney ([email protected]) (630)252-5417
> > Software Services Group (www.aps.anl.gov)
> > Advanced Photon Source, Argonne National Lab
> >
> >
> > --
> > Tim Mooney ([email protected]) (630)252-5417
> > Software Services Group (www.aps.anl.gov)
> > Advanced Photon Source, Argonne National Lab
>
> --
> Tim Mooney ([email protected]) (630)252-5417
> Software Services Group (www.aps.anl.gov)
> Advanced Photon Source, Argonne National Lab
- References:
- RE: put callback queuing matthew.pearson
- Re: put callback queuing Tim Mooney
- Navigate by Date:
- Prev:
Re: put callback queuing Tim Mooney
- Next:
Re: Re: Is it possible to create a cross-compile environment using cygwin and vxWorks on Windows XP 송영기
- 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: put callback queuing Tim Mooney
- Next:
Re: Re: Is it possible to create a cross-compile environment using cygwin and vxWorks on Windows XP 송영기
- 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
|