Experimental Physics and
Industrial Control System

Hi Mark,
I'm not sure that we would use this feature for LCLS.    The way we
get pulse related timestamps is to use our event module to register
as a new time provider.    The event module is our driver for the
MRF Event Receivers, and keeps a timestamp including pulse id
for each event number.   The non-standard part is that the camera
driver needs to know which event code was used to trigger the
camera.   Currently, we have two EDT based drivers, one for RTEMS
and the other for linux, and they use different ways to specify the
event code.    The records set TSE to -2 and the drivers then call
epicsTimeGetEvent() to get their timestamp.

We don't have this working yet for areaDetector, but I don't see how
this proposal would help.   As I see it, adding pasynUser->timeStamp
allows a slightly earlier call to epicsTimeGetCurrent() from the asyn
driver as opposed to waiting till recGblGetTimeStamp() grabs it.
Compared to shutter durations, this delay is miniscule.

What I think we'll need to do is to modify the areaDetector driver
to call epicsTimeGetEvent() instead of epicsTimeGetCurrent()
or relying on the vendor lib as the prosilica currently does.

To make this backward compatible and more general purpose
than our EDT driver implementations, we could extend areaDetector
to add a PV for the timeStampEventNumber, which could default
to epicsTimeEventCurrentTime, which when passed as the event
number to epicsTimeGetEvent() defaults to calling epicsTimeGetCurrent().

If your proposal would result in the areaDetector camera drivers
relying on asyn for the current time stamp when the record TSE is -2,
then we may have a slight conflict.    The camera driver would probably
need to check timeStampEventNumber and only use pasynUser->timeStamp
if timeStampEventNumber was set to epicsTimeEventCurrentTime.

Another way to proceed would be to extend your proposed change so
that the asyn module had support for timeStampEventNumber and
could call epicsTimeGetEvent() instead of epicsTimeGetCurrent().

Regards,
- Bruce

On 5/28/2012 9: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.  Are there changes to the proposal that would make it more useful, but still general?

Cheers,
Mark

References:

Proposed change in asyn - request for comments Mark Rivers

Navigate by Date:

Prev: Re: ether_ip problem reading DINT arrays Bob Gunion

Next: Re: calc VAL field not updating from bi VAL field J. Lewis Muir

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: Proposed change in asyn - request for comments Mark Rivers

Next: Problems with SIS38XX and scaler record AutoCount in MCA R7-1 Mark Rivers

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