A long-standing issue at beamlines that take long exposures (e.g. CHX, CSX) is that the relevant documents for accessing the data are not emitted until the end of the exposure. This has two separate consequences. First, if the acquisition is interrupted, the (partial) data file written by the detector, which is incomplete but may be useful nonetheless, is not referenced by any documents. Second, it is not possible to beginning processing/analyzing data until the acquisition is complete.
One possible approach is to add complexity to read(), described in #7. However, it is possible to do this without adding more complexity to that interface.
Custom Plans
A custom plan that knows something about the device(s) it will be used with can employ the following special trigger-and-read logic:
Trigger the whole detector.
Without waiting, read the image field and emit it in a special Event stream.
Wait for the triggering to finish.
Read the fields, such as the stats from the processing plugin, that don't have meaningful data until the acquisition is complete, and emit those in the normal 'primary' Event stream.
This approach does not require any changes to bluesky or ophyd. It does introduce tight coupling between specific plans and specific detectors, but at beamlines that only ever employ a small set of plans (and combinations thereof) this is not a burdensome requirement.
Trying to make count do the same thing at every beamline was part of the vision when we started working on bluesky. As the project has evolved, we've learned that the useful unit of reuse is the Msg and the executor that processes them (RunEngine). The specific sequencers that assemble them can and should be tuned to respective beamlines' workflows.
RunEngine asks Device what to monitor
To solve this problem in a more general way, we could add a new optional method to the ophyd--bluesky interface, which bluesky can use to ask a Device, "What about you should I monitor?" Then , the Device can provide back a collection of Signals that, for example, emit an update every time the image counter is incremented.
The _monitor coroutine would have to be updated to employ collect_asset_docs().
A long-standing issue at beamlines that take long exposures (e.g. CHX, CSX) is that the relevant documents for accessing the data are not emitted until the end of the exposure. This has two separate consequences. First, if the acquisition is interrupted, the (partial) data file written by the detector, which is incomplete but may be useful nonetheless, is not referenced by any documents. Second, it is not possible to beginning processing/analyzing data until the acquisition is complete.
One possible approach is to add complexity to
read(), described in #7. However, it is possible to do this without adding more complexity to that interface.Custom Plans
A custom plan that knows something about the device(s) it will be used with can employ the following special trigger-and-read logic:
This approach does not require any changes to bluesky or ophyd. It does introduce tight coupling between specific plans and specific detectors, but at beamlines that only ever employ a small set of plans (and combinations thereof) this is not a burdensome requirement.
Trying to make
countdo the same thing at every beamline was part of the vision when we started working on bluesky. As the project has evolved, we've learned that the useful unit of reuse is theMsgand the executor that processes them (RunEngine). The specific sequencers that assemble them can and should be tuned to respective beamlines' workflows.RunEngine asks Device what to monitor
To solve this problem in a more general way, we could add a new optional method to the ophyd--bluesky interface, which bluesky can use to ask a Device, "What about you should I monitor?" Then , the Device can provide back a collection of Signals that, for example, emit an update every time the image counter is incremented.
The
_monitorcoroutine would have to be updated to employcollect_asset_docs().