RE: Proposed change in asyn - request for comments

["Allison, Stephanie" <saa@slac.stanford.edu>]

Hi,

> Wouldn't it be useful to have the TSE be accurate for such PVs even if they
> don't finish processing until 1 or more events later?

Sure, this would be useful (not for LCLS BSA, which has already marked the old pulse as missing, but perhaps for other tools and other kinds of BSAs).

So the idea is that the TSE field of the record is set to -2 so that when the record is processed, normal record processing won't override what asyn set.  But the event code then has to be input to asyn in an alternate way and it has to be changeable on the fly.  And the data acquisition end of things does the epicsTimeGetEvent if a non-zero event code is available and then gives that timestamp to asyn device support later on.  Would be nice to let TSE be the event code but tell record processing not to use it (ie, by something unique in TSEL that doesn't resolve to a PV).    

Thanks for thinking about timing,
Stephanie

> -----Original Message-----
> From: Mark Rivers [mailto:rivers@cars.uchicago.edu]
> Sent: Wednesday, May 30, 2012 10:24 AM
> To: Allison, Stephanie; 'Eric Norum'; Williams Jr., Ernest L.
> Cc: EPICS Techtalk
> Subject: RE: Proposed change in asyn - request for comments
> 
> I'm not sure I understand this.  I am supposing that the areaDetector acquisition can keep
> up, but that there is a pipeline delay.  If the image frames are tagged at the moment they are
> acquired the TSE should be valid, even though by the time the records process it may not be
> the same pulse.  Wouldn't it be useful to have the TSE be accurate for such PVs even if they
> don't finish processing until 1 or more events later?
> 
> Mark
> 
> 
> -----Original Message-----
> From: Allison, Stephanie [mailto:saa@slac.stanford.edu]
> Sent: Wednesday, May 30, 2012 11:48 AM
> To: Mark Rivers; 'Eric Norum'; Williams Jr., Ernest L.
> Cc: EPICS Techtalk
> Subject: RE: Proposed change in asyn - request for comments
> 
> Hi,
> 
> > Let's assume these are images being collected
> > with an areaDetector camera.  They may be buffered in the driver and plugins for a few
> LCLS
> > pulses before the waveform record finally processes.
> 
> LCLS beam-synchronous-acquisition won't work in this case.  It is critical that BSA data be
> processed before the next triggering event code, even if it means processing data (and
> giving it to BSA) outside of such "slow" record processing.  When processing can't keep up
> with triggers, we recommend that a "rate-limited" event code be used to trigger the device.
> Also, we recommend that data going to BSA be processed in records with PRIO=HIGH
> and any threads processing the data run at a high priority (but of course not higher than the
> thread processing EVR-related activities).
> 
> Stephanie
> 
> > -----Original Message-----
> > From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf
> Of
> > Mark Rivers
> > Sent: Wednesday, May 30, 2012 9:03 AM
> > To: 'Eric Norum'; Williams Jr., Ernest L.
> > Cc: EPICS Techtalk
> > Subject: RE: Proposed change in asyn - request for comments
> >
> > > 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>.
> > > The waveform record would then get its time stamp from the event receiver.
> >
> > I agree that they should set TSE=Event number.  But the question is, how to get the
> correct value
> > for TSE into the waveform record in a robust way.  Let's assume these are images being
> collected
> > with an areaDetector camera.  They may be buffered in the driver and plugins for a few
> LCLS
> > pulses before the waveform record finally processes.  If the waveform record then tries to
> read the
> > current event number it will not be correct.
> >
> > It seems to me that the low-level camera driver should be collecting the bunch number the
> instant
> > the image is collected, and attaching it to the image.  That information should make it
> back with the
> > image in the callback to the waveform device support.  So maybe it makes sense to not
> only have
> > a timeStamp passed in the pasynUser, but also a TSE?
> >
> > Mark
> >
> >
> > -----Original Message-----
> > From: Eric Norum [mailto:eric@norum.ca]
> > Sent: Wednesday, May 30, 2012 10:24 AM
> > To: Ernest L. Williams Jr.
> > Cc: Mark Rivers; EPICS Techtalk
> > Subject: Re: Proposed change in asyn - request for comments
> >
> > On May 30, 2012, at 8:07 AM, Ernest L. Williams Jr. wrote:
> >
> > >>
> > >
> > > 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?
> >
> > I don't see how GTR and ASYN would go together very easily.    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>.  The waveform record would then get its time
> stamp
> > from the event receiver.  If other records associated with the pulse use the same TSE field
> then
> > they and the waveform record will have exactly the same time stamp for each pulse.
> >
> > > 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?
> > >
> >
> > --
> > Eric Norum
> > eric@norum.ca
> >
> >
> >
> >