bluesky / bluesky-enhancement-proposals

0 stars 4 forks source link

OEP-2: read-mode #7

Closed mrakitin closed 4 years ago

mrakitin commented 5 years ago

xref https://github.com/bluesky/ophyd/pull/528

danielballan commented 5 years ago

This has been salvaged from an old ophyd issue so it was not forgotten. Needs significant work before soliciting wide review from collaborators.

awalter-bnl commented 5 years ago

I think this has some real merit, I think it could make some of the recent work at IOS much simpler.

As a refresher, there we sometimes want to generate a 'spectra' at each point, which involves scanning the photon energy over a range of values to produce a 'spectra'. This spectra would then be what we want to take at each 'step' in a larger scan. This is currently done using 'per_step' functions, but I think this mechanism provides a better solution. The current method employs 'per_step' functions that perform the spectra at each point.

If I understand the suggestion here correctly we could, for some devices, have a 'spectra' mode, similar to the 'streaming' mode. This would result in a single det1.trigger(read_mode='spectra') function that performs the function of scanning the photon energy and collecting the readings. The photon energy 'motor' itself could have Eph.read_mode('spectra: 'on_demand') as would any other detectors that we want to 'scan' simultaneously. I like this solution as the decision about how to scan can be done prior to a scan by setting a det1.read_mode['spectra']='always and Eph.read_mode['spectra']='on_demand', as well as a few attributes on det1 regarding the spectra (start energy, end energy, step size etc.).

multiple spectra at each point can be done in a similar method to ophyd.areadetector.MultiTrigger where a dict indicates what gets 'changed' between triggers and each 'spectra' is saved to a different 'stream'.

tacaswell commented 5 years ago

There are two different thing there, one is configuring what trigger does (which may also change what comes out of read), the other is to control what is returned by read() separately from read_attrs.

For example, the fly_next machinery at SRX is in the first camp (which flips between returning resource documents for per-point or per-row).

For an example of the second, CHX wanted to be able to call read(mode='streaming') before the data collection is done so they can point a SWMR client at the correct file and start processing on the fly. At the end, they want to the call read(mode='normal') and get all of the stats values etc that they can not know at the beginning. Their per_steps would look something like

yield from trigger(cam, group='cam')
yield from create()
yield from read(cam, mode='streaming')
yield from save()
yield from wait(group='cam')
yield from create()
yield from read(cam)
yield from save()