search

epics-modules / xspress3

EPICS areaDetector xspress3 module
GNU Lesser General Public License v3.0
4 stars 18 forks source link

add 'EraseOnStart' option to for runtime switch of whether Acquire does an Erase #26

Closed newville closed 3 years ago

newville commented 3 years ago

This adds det1:EraseOnStart PV that controls whether ERASE is done on det1:Acquire (to satisfy existing usage) or whether det1:Acquire does not ERASE, matching ancient usage and also allowing det1:ERASE to be executed well before data acquisition, as part of an "arm" process.

This is a work-in-progress, ready for comment and discussion.

I think this is the simplest solution to #24 that can satisfy all use cases. But, just to be clear, it is not quite ready for merging. For example, not all the screens are updated.

oksanagit commented 3 years ago

Thanks @newville ! Let me test this.

newville commented 3 years ago

@oksanagit Okay, I've made a few more updates, including auto-converting (but not much testing!) the display screens so that the main display windows now show "Erase on Start?" (with a default of Yes, set with a dbpf() in the startup script). I think this working correctly, though I have not been testing with X-rays yet.

For me, asyntraceFlow confirms that when EraseOnStart is Yes, the call to xsp3->histogram_clear() takes between 0.35 to 0.4 seconds (7-element Xspress3, not mini Xspress3). With EraseOnStart as No, there is still a bit of delay (~0.05 second) between "Starting Data Collection" and "Started Data Collection", almost certainly from xsp3->histogram_stop() and setupITFG(). This delay is probably unavoidable. Even though it is pretty small, it emphasizes to me that these electronics really should be used in triggered-acquisition / on-the-fly scanning mode.

I intend to use this branch in production during our beam run starting next week. For most of the data collection, I'll be setting EraseOnStart to No and explicitly doing and ERASE as part of an "arm detector" step, so that other things can happen during that 0.35 to 0.5 second "Erase time", but I'll keep setting it back to Yes when data collection is complete so that a simple "Acquire" will first erase and then start collecting new data. So, we should be exercising this option quite a bit over the next few months.

Anyway, I think this should be able to meet everyone's needs. If you get a chance to try this out, please let me know how you think this will work for you.

oksanagit commented 3 years ago

@newville, I have build this PR, set EraseOnStart to No. Default was yes. Did not have much opportunity to take timing on calls, but it looks good. User is running an experiment over night and intends to use this code for the rest of the cycle. Lets give some more testing opportunity before merging. I will take a look a screens in the nearest future.

newville commented 3 years ago

@oksanagit Thanks - yes it is working for me without trouble, but I've only started using it with actual beam today myself.

newville commented 3 years ago

@oksanagit Is this still working OK for you? It is working for us, and I'm wondering if we should merge this in the master branch. Thanks.

oksanagit commented 3 years ago

@newville . Yes we are using it in production on one beamline and they are happy. Merging sounds good to me. Thank you.

newville commented 3 years ago

@oksanagit OK, great, I'll merge this.