search

xpdAcq / mission-control

Releases, Installers, Specs, and more!
0 stars 4 forks source link

Fast shutter delay #154

Closed DanOlds closed 5 years ago

DanOlds commented 5 years ago

The beamlines request an adjustable delay at the start of collecting data for xrun to fully allow time for the fast shutter to open. This is considered a high priority by the beamline staff, as the issue is corrupting data integrity from in situ measurements on both XPD and PDF.

Current Behavior

Currently, xrun expects that when a 'shutter open' signal is received, the fast shutter is fully open. Unfortunately, the epics signal to open the fast shutter is ferried from the network to the hardware of the shutter itself via the EPS system, which is not instantaneous (and in fact, can have a small variable delay).

This has led to the situation where xpdacq seems to believe the fast shutter is open before it actually is, if only by a second. Unfortunately, this 'closed shutter' data is merged into the full 'light' image that is collected, polluting the data. I have tested this by measuring single-frame exposures on both beamlines, and found it leads to an effectively blank detector (dark-like image).

Users would be unaware of this issue in most cases, as the majority of images are composed of multiple exposures. Several short-exposure (10-5 Hz) in situ measurements over the last month have seen seemingly random-drops in intensity over the course data collection. It appears to be related to this shutter issue.

Possible Solution

In the long term, we will seek to modify the fast shutters to accurately report open/closed status. However, in the interim, a variable delay could be introduced to xrun, which allows time for the shutter to fully open (e.g. glbl['fast_shutter_delay'] = .5).

This would also allow for testing and verification of the future shutter modifications.

CJ-Wright commented 5 years ago

We've added a delay time in the most recent release. However, I'll leave this issue open so that we can use it as a reminder to fix this on the hardware side ASAP.

CJ-Wright commented 5 years ago

This is implemented and at XPD and PDF the key is shutter_delay

DanOlds commented 5 years ago

I'm not sure the key 'shutter_delay' is correct. However, there is an entry for 'shutter_sleep' in the glbl list. Something seems not correct in the current version of xpdacq on PDF.

CJ-Wright commented 5 years ago

Do we still need the delay?

CJ-Wright commented 5 years ago

I think this prototype version of this may have had inconsistent names across the beam lines and this repo. They'll be consistent once this is released.

DanOlds commented 5 years ago

Yes, we still need this. Unfortunately, the hardware issue (fast shutter readback) is not yet resolved on PDF.

On Wed, Jan 30, 2019, 9:21 PM Christopher J. Wright < notifications@github.com wrote:

I think this prototype version of this may have had inconsistent names across the beam lines and this repo. They'll be consistent once this is released.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/xpdAcq/mission-control/issues/154#issuecomment-459189486, or mute the thread https://github.com/notifications/unsubscribe-auth/AMQJYXqrw5P9rkSh9WZNeSU8jCCRcYfEks5vIlMSgaJpZM4Ytrm9 .