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
- Replies:
- RE: put callback queuing matthew.pearson
- References:
- Re: put callback queuing Tim Mooney
- Navigate by Date:
- Prev:
RE: put callback queuing Hill, Jeff
- Next:
Re: Is it possible to create a cross-compile environment using cygwin and vxWorks on Windows XP Andrew Johnson
- 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: 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
|