g+
g+ Communities
Argonne National Laboratory

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  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014 
<== Date ==> <== Thread ==>

Subject: RE: put callback queuing
From: <matthew.pearson@diamond.ac.uk>
To: <mooney@aps.anl.gov>
Cc: daron.chabot@gmail.com, tech-talk@aps.anl.gov
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:mooney@aps.anl.gov]
> Sent: 21 June 2012 22:17
> To: Pearson, Matthew (DLSLtd,RAL,DIA)
> Cc: tech-talk@aps.anl.gov; 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" <matthew.pearson@diamond.ac.uk>
> To: mooney@aps.anl.gov, "daron chabot" <daron.chabot@gmail.com>
> Cc: tech-talk@aps.anl.gov
> 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: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> > bounces@aps.anl.gov] 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" <mooney@aps.anl.gov>
> > To: "Daron Chabot" <daron.chabot@gmail.com>
> > Cc: "EPICS" <tech-talk@aps.anl.gov>
> > 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" <daron.chabot@gmail.com>
> > To: "EPICS" <tech-talk@aps.anl.gov>
> > 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 (mooney@aps.anl.gov) (630)252-5417
> > Software Services Group (www.aps.anl.gov)
> > Advanced Photon Source, Argonne National Lab
> >
> >
> > --
> > Tim Mooney (mooney@aps.anl.gov) (630)252-5417
> > Software Services Group (www.aps.anl.gov)
> > Advanced Photon Source, Argonne National Lab
> 
> --
> Tim Mooney (mooney@aps.anl.gov) (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 
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 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·