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  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 
<== Date ==> <== Thread ==>

Subject: Re: Proposed change in asyn - request for comments
From: "Ernest L. Williams Jr." <ernesto@slac.stanford.edu>
To: Mark Rivers <rivers@cars.uchicago.edu>
Cc: Eric Norum <eric@norum.ca>, EPICS Techtalk <tech-talk@aps.anl.gov>
Date: Wed, 30 May 2012 08:07:12 -0700
On 05/28/2012 09:40 AM, Mark Rivers wrote:
Folks,

Eric Norum and I are proposing a change to asyn to enable standard asyn device support to set record timestamps based on time stamp information from an asyn driver.  The change is backwards compatible.  Here is the proposal:

- Add a timeStamp field to the asynUser structure

- Drivers can optionally set the timestamp field in the asynUser that is passed in interface read() operations and in callbacks to device support for input records.

- asyn device support sets the record timestamps based on pasynUser->timeStamp if the following are both true:
   - The record TSE field is set to epicsTimeEventDeviceTime (-2)
   - pasynUser->timeStamp is non-zero

The idea is that the asyn driver can determine the time stamp very close to the time that the I/O operation completed.  The record timestamp can thus be set much closer to the "true" time than if the time is determined with recGblGetTimeStamp later on when the record processes.

Before we commit this change I'd like to hear if this would be useful to others.  I'm particularly interested if this would help the LCLS and other FEL folks who want to timestamp areaDetector and other asyn driver records with the pulse identification.

Hi Mark,
I apologize for the late response.
Here at the LCLS we are indeed interested in this.

We rely on our pulseID or "beam flavor" for correlation on a pulse by pulse basis. This will be useful for any piece of data acquisition hardware which has an asyn driver. For example, if I wanted to use your ip330-asyn driver for beam synchronous acquisition (BSA)

I hope to encourage more asyn-based drivers here at LCLS but we do need the capability to grab the pulseID
with the "TSE = -2" technique.  :)

At this time, there are 2 waveform digitizer VME boards that we have started to work on:
(1) Struck SIS3350
(2) Struck SIS3302
Can we make these asyn drivers and still integrate with GTR? Eric any comments? If the driver is indeed asyn, we like the proposal for getting the pulseID that you mention above. :)

I wonder how Jeff Hill (LANL) will correlate his data at LANSCE?


Cheers,
Ernest


  Are there changes to the proposal that would make it more useful, but still general?

Cheers,
Mark




Replies:
Re: Proposed change in asyn - request for comments Eric Norum
References:
Proposed change in asyn - request for comments Mark Rivers

Navigate by Date:
Prev: Re: Problem when caput to waveform record Andrew Johnson
Next: Re: Proposed change in asyn - request for comments Eric Norum
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 
Navigate by Thread:
Prev: Proposed change in asyn - request for comments Mark Rivers
Next: Re: Proposed change in asyn - request for comments Eric Norum
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 
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 ·