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