search

xpdAcq / mission-control

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

Shutter problem #128

Closed jmbai2000 closed 5 years ago

jmbai2000 commented 6 years ago
The streamline randomly shows flat plots with intensity about 100x lower. This happens during tseries or Tramp scans.
CJ-Wright commented 6 years ago

@jmbai2000 Thank you for reporting!

CJ-Wright commented 6 years ago

Is it possible that the shutter was closed for part of the acquisition? How much time was there for the shutter to open and close?

sbillinge commented 6 years ago

@jmbai2000 we need more info from you before we can diagnose this. Please let us know when you have the info. Thanks so much.

jmbai2000 commented 6 years ago

Ji Li set a PV tracking to see the status of the fast shutter. So if the "flat plot" happens again, we will be able to see if the shutter was open during the counting from the time stamps.

On Thu, Aug 2, 2018 at 1:01 PM, Simon Billinge notifications@github.com wrote:

@jmbai2000 https://github.com/jmbai2000 we need more info from you before we can diagnose this. Please let us know when you have the info. Thanks so much.

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

CJ-Wright commented 5 years ago

@DanOlds is this similar to the problem you were working on?

DanOlds commented 5 years ago

Maybe? Either way, having the ability to put a longer delay in before acquisition is looking important for any kind of in situ study where the shutter is opening and closing. I haven't had a chance to explicitly test the shutter speed, but this explains a lot of the behavior we've been seeing.

CJ-Wright commented 5 years ago

If possible I think it would be better to fix the shutter's reporting system. We rely on the various devices on the beamline to properly report their state. Since this is a device by device problem, it may be better to solve it on the device level.

DanOlds commented 5 years ago

I will follow up on details of why this might not be the case (I think there is an inherent variable delay), but it's too don't have the option to fix this quickly by changing the delay. It's going to be months before the fast shutter can be repaired, and this issue is corrupting data until then.

On Tue, Nov 20, 2018 at 10:28 AM Christopher J. Wright < notifications@github.com> wrote:

If possible I think it would be better to fix the shutter's reporting system. We rely on the various devices on the beamline to properly report their state. Since this is a device by device problem, it may be better to solve it on the device level.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/xpdAcq/mission-control/issues/128#issuecomment-440313561, or mute the thread https://github.com/notifications/unsubscribe-auth/AMQJYf24pdP7gEFNr041oDvbchG07l2yks5uxB-VgaJpZM4VrXTz .

-- Daniel Olds Phone : 517-282-8009

CJ-Wright commented 5 years ago

I think this has been addressed with the shutter_sleep global setting.