EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: put callback queuing
From: <[email protected]>
To: <[email protected]>
Cc: [email protected], [email protected]
Date: Fri, 22 Jun 2012 09:06:37 +0000
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  <20122013  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024