[FB] Decision on controller API

[jacopoabramo]

I imagined that controllers can do 3 things in Redsun:

1. render information (they simply collect documents from the run engine, shuffle/modify them a bit) and then send it to the UI;
2. ship plans (construct message generators that can be customized via functools.partial and via the UI re-built whenever a parameter they have in their signature is changed);
3. monitoring a workflow that is not bound to the overall acquisition;
   • a good example is having a separate channel for maintaining a stable lock on the current focus plane where a detector continously acquires data points (the detector being an area or point detector).

The first point is easily managed: the run engine provides a subscription systems via callbacks and each callback can filter on the type of received document. What the user can do is:

• emit a psygnal to the engine handler to register a subscription;
• when the callback is invoked, emit a signal connected to the virtual bus to be forwarded to the upper layers, or alternatively connect via another signal to a separate thread, perform a computation and then send it to the upper layers.

The second point is more challenging: what happens if an user wants to execute multiple plans from different controllers? Can these be dynamically built and executed? The run engine right now can only execute one plan at a time; it has the possibility to have nested plans and the documentation is quite extensive on the possibilities (see here for reference). But at the same time executing two plans concurrently doesn't seem to be supported (see this issue). I think that for a starting point, for safety reasons, the plans should be shipped and executed singularly. Since the controllers are anyway to be customized for specific purposes it's a good starting point.

The third point somewhat relates to the second. A starting approach would be to execute the plan in a separate thread which implements a similar mechanism of the run engine but with limited capabilities. This section of Bluesky's documentation gives some insights on how to build a custom engine, since the important part is keeping consistency with the message protocol functionalities.

ExEngine would be a solution (also to replace the original run engine and use it as a possible alternative), but at this time it implements a different approach which is not compatible with Bluesky's message protocol and event model. Since the project is still somewhat a work in progress it could be adapted to Bluesky somehow - if the authors would like to do so.

[jacopoabramo]

PR #9 changed a bit the controller API

• the base controller is now a protocol instead of an abstract class;
• changed the way the plans are registered in the device handler.