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  <20112012  2013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: When a record is changed twice very fast, camonitor only detects first change
From: Andrew Johnson <anj@aps.anl.gov>
To: tech-talk@aps.anl.gov
Cc: Mikel Rojo <mikelrojo5@hotmail.com>
Date: Mon, 23 May 2011 12:02:55 -0500
Hi Mikel,

On 2011-05-23 Mikel Rojo wrote:
> I don't understand how camonitor can say that a pv has one value, while
> with caget we can see that it has a different one. I tried stopping the
> monitor before clearing the variable and then starting the monitor again
>  afterwards but it does not change anything. I am using the latest
> version of base (3.14.12.1) and sequencer (2.0.13). I would really
> appreciate any help. Thank you in advance.

In addition to the comments Matthieu made about your pvGet() being unnecessary 
and possibly even harmful, I recommend that you never change the value or use 
pvPut() on a variable that has a monitor set on it.  There is a known race 
condition in the sequencer such that a monitor event can arrive and change a 
variable's value while the sequencer is still processing the action statements 
from a previous state transition.  If you want to update the value of a PV 
that you're monitoring, create a second variable assigned to the same PV and 
use that variable for all pvPut() operations.  Your code also needs to allow 
for the fact that the pvPut() can cause another monitor to be queued and thus 
set your event flag again.

There is another issue that you might also be hitting, although I don't think 
so in this case: A ca_monitor() of a string PV that changes often is not 
guaranteed to always send the actual character string that caused the monitor, 
it might skip one or more values from a very busy record.  Here's why:

When a record processes and triggers a monitor, the code pushes an event 
object onto the send queue for each client, but to save memory we don't copy 
string or array values into that object (it only has enough space for scalars 
up to size double).  When the client's send thread later executes to forward 
that value it will lock the record and copy the string value out of the record 
field into the TCP socket buffer, but if the record has processed since the 
original value was queued it will be given the newer string instead.

- Andrew
-- 
Optimization is the process of taking something that works and
replacing it with something that almost works, but costs less.
-- Roger Needham

References:
When a record is changed twice very fast, camonitor only detects first change Mikel Rojo

Navigate by Date:
Prev: Re: vxWorks network problems Steven M. Hartman
Next: RE: When a record is changed twice very fast, camonitor only detects first change Mikel Rojo
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: When a record is changed twice very fast, camonitor only detects first change Tim Mooney
Next: Windows XP Cygwin difficulties for building EPICS base Cid, Florencio A
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  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 ·