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: Andrew Johnson <[email protected]>
To: [email protected]
Cc: Daron Chabot <[email protected]>
Date: Thu, 21 Jun 2012 10:42:55 -0500
Hi Daron,

On 2012-06-21 Daron Chabot wrote:
> 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

...

> 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...

That's how the putNotify code works inside the IOC; there can only be one 
putNotify operation outstanding on any record at a time, basically because 
there is only one field in each record that stores the putNotify status 
information, it's too hard to try and keep track of multiple operations at 
once, and it's questionable what that would actually mean.  The putNotify 
functionality has to keep track of the putNotify state through asynchronous 
record processing and across PP database links, which makes it pretty 
complicated.  There is an enhanced version of the putNotify code called 
process-get which Marty wrote in 2008 that will be in the 3.15.0 release, but 
it doesn't change the 'one notify per record' limit that you've hit.

Thus you should *not* use put-callback for writing to the .STOP field, for 
exactly this reason, use a regular put:

caput test:motor1.STOP 1

HTH,

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte

Replies:
RE: put callback queuing Hill, Jeff
References:
put callback queuing Daron Chabot

Navigate by Date:
Prev: put callback queuing Daron Chabot
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  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: put callback queuing Daron Chabot
Next: RE: put callback queuing Hill, Jeff
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