Plan A: Make configured lambda2m HDF plugin optional

[prjemian]

Similar to #8, switch back to Plan A and apply lessons learned regarding how to configure (or disable) the HDF5 plugin for data acquisition. As appropriate, generalize the procedures to enable/disable use of any area detector file writing plugin when it is configured as an ophyd Device Component (includes consideration of staging and the kind attribute).

[prjemian]

As part of this work, make sure the advice is documented about the sequence in which certain settings must be configured.

... configuring the area detector HDF5 file writing plugin is trickier than we have thought. Some parameters must only be set after others (such as the HDF5 Capture button. Some must be set before acquisition (such as CreateDirectory, and some require this to be set properly (such as FilePath). We already know that FilePath must have a trailing / (the IOC will provide this if missing but ophyd will have problems since it expects the IOC to report the value ophyd tried to set). Summary: Most, if not all, of the status timeouts we experience have been due to our own code, not knowing about each of these patterns to configure the HDF5 (or the other) file writing plugin.

[prjemian]

@qzhang234 asked (on Teams):

Regarding Plan A, if I understand correctly, the goal is to create an Ophyd class with detector attributes that encompass every detector under the sun, and then the users will selectively load the attributes that will be used for their operation?

[prjemian]

Not reaching that far. No need to connect with lots of different of PVs that will never be used. Instead, only configure the plugins that might be used (such as HDF & PVA, in addition to CAM, CODEC, IMAGE, ... as named in the plugin chain in the IOC). Then, using a command (yet to be created), enable/disable them selectively from your plan.

The problem I was facing last week with this last bit was I did not easily identify the additional parts to unconfigure when the HDF plugin should be disabled. This was complicated because the IOC kept crashing and I have no access to the GUI for the configuration. I believe I have resolved that now.

Here is my version of the HDF5 plugin for ophyd. It allows the beam line to control the HDF5 file name. What is new is that the code allows for the HDF5 plugin to be disabled. The plugin support:

class MyAD_EpicsFileNameHDF5Plugin(AD_EpicsFileNameHDF5Plugin):
    """Remove property attribute not found in BDP."""

    _asyn_pipeline_configuration_names = None

    @property
    def _plugin_enabled(self):
        return self.stage_sigs.get("enable") in (1, "Enable")

    def generate_datum(self, *args, **kwargs):
        if self._plugin_enabled:
            super().generate_datum(*args, **kwargs)

    def read(self):
        if self._plugin_enabled:
            readings = super().read()
        else:
            readings = {}
        return readings

    def stage(self):
        if self._plugin_enabled:
            staged_objects = super().stage()
        else:
            staged_objects = []
        return staged_objects

    def trigger(self):
        if self._plugin_enabled:
            trigger_status = super().trigger()
        else:
            trigger_status = Status(self)
            trigger_status.set_finished()
        return trigger_status

[prjemian]

To enable and make the HDF5 plugin return the correct information when it is used, set the plugin's kind attribute:

detector.hdf1..enable_on_stage()
detector.hdf1.kind = Kind.config | Kind.normal

This will make the plugin appear in the detector's read_attrs list (list of attributes which are read as data during acquisition). To disable and remove the plugin from that list, use:

detector.hdf1..disable_on_stage()
detector.hdf1.kind = Kind.omitted