Closed ZLLentz closed 6 years ago
@teddyrendahl any opinions on this?
Can I be a 🍑and say I suggested this back at the beginning? 😝
I like this. The result is that you can just pass the DAQ
in as a detector which seems the most intuitive thing for me. The only thing that is awkward is the stage
unstage
thing. If I want to have all my steps be different runs do I stage / unstage on every per_step
hook? I guess that isn't crazy...
Sorry for not remembering! Time has shown that using this a flyer is "correct" mechanically but unintuitive. IIRC stage_wrapper
puts itself at every open_run
and close_run
, which I why I suggested that. So as long as you use the stage_wrapper
and start/stop your runs at the right times, the daq
will know how to partition the runs!
Memory was bad, this is not how stage_wrapper
works. Oh well.
Two ideas then:
closed by #27
Expected Behavior
I can't remember why we opted against this, but I'm imagining something like:
Where:
daq.stage
would start a new rundaq.trigger
would start acquiring for the configured time, and mark triggering as done when we've stoppeddaq.read
would show information about how many events have passed (and maybe we'd find a good way to extract live feedback into here)daq.read_configuration
would also show us the run numberdaq.unstage
would end the runI feel like this would be much simpler for the purposes of LCLS. We'd be able to use most of the built-in tools as-is.
As an aside, this makes it easier to implement scan PVs (it is revealed, the true reason I'm suggesting this...)
Current Behavior
Only usable as a flyer, instead of as both a flyer and a reader