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  2015  2016  2017  2018  2019  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 
<== Date ==> <== Thread ==>

Subject: RE: put callback queuing
From: <matthew.pearson@diamond.ac.uk>
To: <mooney@aps.anl.gov>, <daron.chabot@gmail.com>
Cc: tech-talk@aps.anl.gov
Date: Thu, 21 Jun 2012 17:56:59 +0000
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


Replies:
Re: put callback queuing Tim Mooney
References:
Re: put callback queuing Tim Mooney
Re: put callback queuing Tim Mooney

Navigate by Date:
Prev: Re: Is it possible to create a cross-compile environment using cygwin and vxWorks on Windows XP Andrew Johnson
Next: Re: put callback queuing Tim Mooney
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 
Navigate by Thread:
Prev: Re: put callback queuing Tim Mooney
Next: Re: put callback queuing Tim Mooney
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 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·