Always-running bluesky plans (?)

[stan-dot]

Keeping some value continuously minimized / maximized for the state of the beamline.
Is it a DAQ area or Controls? Even if Controls, this could be theoretically accomplished with bluesky and there have been questions raised about this possibility from the scientists.

Acceptance Criteria

• Specific criteria that will be used to judge if the issue is fixed

[callumforrester]

I think the biggest problem doing this in bluesky is that it involves a constantly-running plan in the background, with the user invoking specific plans to run for a short time.

While there has been discussion about making bluesky run concurrent plans (bluesky/bluesky#1652) this is not a use case we would want to support. We would want to execute a finite, top-level plan that can execute sub-plans with restricted capabilities (see reasoning: bluesky/bluesky#1652 (comment)).

This may be a case of someone prescribing a solution rather than stating the problem, @stan-dot are you able to provide any concrete use cases?

[stan-dot]

This may be a case of someone prescribing a solution rather than stating the problem

this very well might be

this was about i18 to preserve maximization of electron flow on detectors [detector_name] by auto-moving motors [motor_names] while other motors [motor_names_2] move to change property of the whole instrument

[callumforrester]

But is there a particular reason why that should be done over the top of a data collection plan rather than just inside it?

[stan-dot]

because data collection is a specific collection a user runs and the preservation of electron flow is the instrument property, the users would like this done for them

[callumforrester]

But what is wrong with the optimisation occurring automatically as-and-when the user requests a collection, rather than constantly in the background? Is it too slow?