EPICS Home

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  2021  2022  2023  2024  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  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Proposed change in asyn - request for comments
From: "Kim, Kukhee" <[email protected]>
To: Mark Rivers <[email protected]>, "Hill, Bruce" <[email protected]>, "[email protected]" <[email protected]>
Date: Wed, 30 May 2012 18:53:03 -0700
Hi Mark;

I just read this mail thread. 

> - 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


I like your idea to handle the TSE=-2 for the driver layer. Here is some used case for the TSE=-2.

Our embedded iocs for BPMs and RF PADs do not have EVR, it gets trigger from EVR in master ioc, and sends the acquired data to the master ioc through the dedicated Ethernet. The communication layer in the master ioc tags data with the timestamp which comes from the EVR. We are sure, the process from data acquisition to the times tamping by the communication driver satisfies the real-time requirements. But, we could not sure about the following processing: for example record processing. The communication layer has higher priority than HIGH PRIORITY CALLBACK for the record processing. There is more threads in between the communication layer and HIGH callback. The thread do some local feedback algorithm for the RF system. Thus, there is uncertain delay between data receiving and record processing.
We put TSE=-2 for the record and the device support gets timestamp from the communication layer and puts it into the TIME field in the record. This timestamp is a critical part of Beam Synchronous Acquisition (BSA), Stephanie already explained it in the previous. That is how we are using the TSE=-2. 
I think, ASYN user could have similar situation and they also need to use TSE=-2.

If somehow, we need to change event number for the PADs trigger, we don't need to change the TSE field to reflect the new event number. That is another good point for the TSE=-2.


Hi Bruce;

I am confusing in your previous email.

> We do risk some confusion for users, as EPICS has event numbers for use in triggering record processing, but they aren't the same event numbers as used by the EVR drivers to select which EVG events will generate triggers.


The event number which generated by the EVR and the epics event is exactly same. Actually there are event records which are correspond to the EVR event numbers. If we enable the soft event, then the event module proceeds the event record which is corresponded to the EVR event. Thus, the EVR event number n generates the epics event number n.

Probably, I mis-understand your message. Would you advice me?

Thank you.
Best regards,
Kukhee
--------------------------------------------
Kukhee Kim
SLAC National Accelerator Laboratory
2575 Sand Hill Rd, MS 64
Menlo Park, CA 94025
Email: [email protected]
Phone: (650)926-4912


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Hill
Sent: Wednesday, May 30, 2012 2:56 PM
To: [email protected]
Subject: Re: Proposed change in asyn - request for comments

I think we could make this work if TSE = Event Number, but it would require some changes to some existing modules including our EDT drivers, as they rely on TSE == -2.

We'd need to have the TSE value available to pasynUser, and set the image record's TSE field either in the db files or via db links.

We do risk some confusion for users, as EPICS has event numbers for use in triggering record processing, but they aren't the same event numbers as used by the EVR drivers to select which EVG events will generate triggers.

Re Mark's question about buffered image processing in the driver, I can see how that would be an issue if you were using EPICS for data acquisition and wanted to trigger a new image acquisition immediately
after collecting the prior image.    We generally don't try to capture an
image each pulse, setting our EVR event code to only trigger on 1 out of N pulses, leaving ample time for adjusting shutter durations which gives us plenty of time to process the image before the next image is triggered.

Thus, when we call epicsTimeGetCurrent(), the timestamp for the event code which triggered the camera contains the appropriate pulse ID, which we stuff into the lower 17 bits of the timestamp's nsec field.

Regards,
- Bruce

On 5/30/2012 9:03 AM, Mark Rivers wrote:
>> 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:[email protected]]
> 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?
>>


Replies:
Re: Proposed change in asyn - request for comments Eric Norum
Re: Proposed change in asyn - request for comments Bruce Hill
References:
Proposed change in asyn - request for comments Mark Rivers
Re: Proposed change in asyn - request for comments Ernest L. Williams Jr.
Re: Proposed change in asyn - request for comments Eric Norum
RE: Proposed change in asyn - request for comments Mark Rivers
Re: Proposed change in asyn - request for comments Bruce Hill

Navigate by Date:
Prev: Re: calc VAL field not updating from bi VAL field Andrew Johnson
Next: errro running "ibtest" tzk6s
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  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Proposed change in asyn - request for comments Bruce Hill
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  2021  2022  2023  2024