search

APS-USAXS / usaxs-bluesky-ended-2023

Bluesky instrument for USAXS
0 stars 0 forks source link

Bluesky AD support suggestion: a dynamically-configured AD Device? #562

Open jilavsky opened 1 year ago

jilavsky commented 1 year ago

May be I do not understand this right... But I understand that BS needs to have predefined all plugins used and controls those settings in BS code (sets to what BS has in configuration). This is great for stability but not for what we are used to when users may need to add/remove plugin to get something done. We rely on epics backup/restore and for ADs ( mainly from Detector pool but even beamline specific) we have tools which store specific configuration for AD at specific instrument and let us reload this later. This tool designed by DP staff is simply collection of all possible PVs for AD and it saves a state of AD ioc when told and restores when asked. Could BS do the same on start or when told to do so? Like when we trigger data collection - reload any changes to AD ioc which user may have done. Read current setting of AD ioc and use that as configuration for collecting the sequence of data. Logically, this would need to be under staff control.

And then find some smart way of not trying to change any PVs which did not change, unless BS needs to set new value there.

prjemian commented 1 year ago

Similar suggestion from other APS instruments (such as XPCS).

Your description of what happens is pretty much correct. An ophyd Device for an area detector includes the cam and any plugins that are used in the complete processing chain in the IOC (even internal ones such as scatter and gather).

If your AD will use different plugin configurations, then you might create an ophyd Device that includes and configures all possible plugins you might use. In this case, you'd need to control which are enabled or disabled (via the ad.PLUGIN.stage_sigs["enable"] dictionary key.

An alternative, and this is the recommendation of the ophyd authors, is to minimize the number of PV connections at any one time. By creating an ophyd Device which only includes the plugins you will use at any one time. If you plan to use different combinations of plugins, their recommendation is that you create separate Devices, one for each combination. (I think this is unwieldy since you'd need to know about multiple detector objects -- a confusing situation). But the justification is to keep the number of active PV connections low.

prjemian commented 1 year ago

To have an auto-configuration of an area detector device, based on inspection of the current IOC, we'd need new code, with a clear description of how to configure. But this might just simplify the process (while removing some flexibility at the same time). Needs thought. Usually, ophyd Devices are pre-planned so that code is written out. Proposed here is some step that first asks the IOC to describe itself (the IOC will not describe itself directly but can answer a series of questions), then creates an ophyd Device to match the current conditions. Interesting to test that out...

prjemian commented 1 year ago

This is really something for the apstools package to develop.

prjemian commented 1 year ago

And then find some smart way of not trying to change any PVs which did not change, unless BS needs to set new value there.

Not specific to area detector. General for any ophyd.EpicsSignal, don't caput the same value to a PV (unless a force=True option overrides).