EPICS Controls 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  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: Proposed change in asyn - request for comments
From: "Allison, Stephanie" <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Date: Wed, 30 May 2012 09:36:18 -0700
Hi,

> When using TSE=event# do be aware that there are several potential
> races.  One is that the data update from your digitizer driver may
> arrive and be processed before the updated event timestamp from the EVR.

At LCLS, we minimize this race condition by having all event codes come to the EVR well before beam (~1msec before beam) and thus well before most triggers.  We also have the thread that captures timestamps (and inserts pulse ID in lower 17 bits) running at a higher priority that the epics callback tasks.  But you are right in that there is a potential race condition, especially for devices with a short timing delays.  There are timestamp checks in the LCLS beam-synchronous-acquisition (BSA) software that catch these kind of things.  If the event timestamp hasn't changed since the last processing time or if the event timestamp doesn't match the expected global BSA timestamp, the data is not used and the appropriate error counters are incremented.  

Stephanie

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Michael Davidsaver
> Sent: Wednesday, May 30, 2012 9:03 AM
> To: [email protected]
> Subject: Re: Proposed change in asyn - request for comments
> 
> On 5/30/2012 11:23 AM, Eric Norum wrote:
> > ... Also, I don't think that TSE=-2 is the right choice for this setup
> > -- the digitizers don't supply the time stamp. I think that you'd be
> > better off setting the waveform record TSE=<the number of some event
> > in your timing system event receiver associated with the pulse>.
> 
> When using TSE=event# do be aware that there are several potential
> races.  One is that the data update from your digitizer driver may
> arrive and be processed before the updated event timestamp from the EVR.
> 
> This should be avoidable in an RTOS if the interrupt and thread
> priorities for the two drivers (digitizer and EVR) are picked appropriately.
> 
> 
> Michael



References:
Proposed change in asyn - request for comments Mark Rivers
Re: Proposed change in asyn - request for comments Ernest L. Williams Jr.
Re: Proposed change in asyn - request for comments Eric Norum
Re: Proposed change in asyn - request for comments Michael Davidsaver

Navigate by Date:
Prev: Re: calc VAL field not updating from bi VAL field J. Lewis Muir
Next: RE: Proposed change in asyn - request for comments Allison, Stephanie
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: Re: Proposed change in asyn - request for comments Michael Davidsaver
Next: RE: Proposed change in asyn - request for comments Mark Rivers
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 
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 ·