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
- Replies:
- RE: put callback queuing matthew.pearson
- References:
- RE: put callback queuing matthew.pearson
- Navigate by Date:
- Prev:
RE: put callback queuing matthew.pearson
- Next:
RE: put callback queuing matthew.pearson
- 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 matthew.pearson
- Next:
RE: put callback queuing matthew.pearson
- 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
|