Series measurements, arming issues after 10 minutes

[antoninomiceli]

Byeongdu Lee (@byeongdu) and Xiaobing Zuo at 12-ID at APS with an Eiger2 S 9M food this issue...

In a series measurement, after 10mins since the detector is armed, the detector is not triggered at the exact time of the trigger signal. and the time delay increase with time.

The problem always start after 10 minutes since armed.

[byeongdu]

It is 6 mins (about 360 seconds), not 10 mins. When we start a new series measurement, the detector is triggered on time, again for 6mins. The time delay can be as short as sub-micro seconds but it can grow to a significantly long time (proportional to the time after 6mins of arming)

[MarkRivers]

Please provide more details:

• Is this in External Series or External Enable mode?
• If is it External Series what is NumImages, i.e. how many images are you collecting per trigger?
• I believe you observed that the total intensity on the detector is constant for 6 minutes and then falls, correct?
• Do you have evidence like a scope trace that this is actually due to a delay between the trigger and when it starts acquiring? How do you know the problem is not starting at the correct time, but is counting for less time than it should?

[byeongdu]

1. External Series mode, where each image is triggered by an external pulse (we do one exposure for an image).
2. NumImages: 2000 (can be any number). NumExposures: 1 (always)
3. Yes, that is, we found out, due to the fast shutter. Our fast shutter opens for about 10 ms longer than the exposure time. So, when the detector is triggered with a 10ms or more delay, the detector count would start to decrease. We tested the same measurement with leaving the shutter open. Then, the detector count did not decrease. The 6 minutes may come from 10ms extra shutter opening time. But, Time Stamp on the HDF plugin seems not to show any time delay.
4. We send the same trigger signal to Eiger, Pilatus, and struck (for inhibition and channel advance) at the same time. Pilatus and struck work fine as expected.

[byeongdu]

I monitored the trigger signal (an input signal to the detector, yellow) and detector output signal (a signal that the detector generates for data acqusition, cyan) on an oscilloscope video. Exposure time 0.8 secs and periodicity 1 secs. As soon as the measurement starts, the time delay shows up and increases with time (see the video from 50 seconds).

[MarkRivers]

I think you need to send this to Dectris. You are sending the data over the Stream interface while this is happening correct? Each frame is 9M pixels * 4 bytes/pixel = 36 MB/s. The network to your IOC should be able to handle that no problem, even at 1 Gbit/s, so it should not be a problem with queuing in the DCU. I don't understand what could be causing that, but Pascal or Zachary may know.

[MarkRivers]

This was due to operator misunderstanding. ExternalSeries mode was being used with NumTriggers=1 and NumImages=N. In this mode only the first external trigger has any effect, and causes N images to be acquired with the desired AcquireTime and AcquirePeriod, using the internal clock. This will this not be synced to the external trigger sequence.

The correct settings to collect one image for every external trigger is NumTriggers=N, NumImages=1.