Experimental Physics and
Industrial Control System

"Ernest L. Williams Jr." <[email protected]> · 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System