baseline and monitor streams about bluesky-queueserver HOT 9 CLOSED

Possibly, wrap each supported plan with @baseline_decorator and/or @monitor_during_decorator and accept those devices & signals as arguments to the custom plan.

Is this the way to proceed with the standard bluesky.plans?

from bluesky-queueserver.

I am not sure I fully understand the question. Typically there is a fixed set of baseline devices defined in startup code using either @baseline_decorator or SupplementalData (e.g. https://github.com/NSLS-II-SRX/profile_collection/blob/db111a44608e19aa08f46e444051c042ffe9e1d2/startup/95-baseline.py#L6) I think it is possible to write a plan that accepts a device name as a parameter and adds this device to a baseline or monitor for a wrapped plan if there is a use case for it (e.g. https://github.com/NSLS-II-SRX/profile_collection/blob/db111a44608e19aa08f46e444051c042ffe9e1d2/startup/62-flyscans.py#L422)

So far I considered baseline devices or monitors as part of bluesky functionality that is not controlled by the Queue Server.

@tacaswell Do you have any thoughts?

from bluesky-queueserver.

Thanks for the link. I'm stumped on how my startup code imports the RE object so that it can call: RE.preprocessors.append(sd). The link does not show.

from bluesky-queueserver.

In my opinion, in production systems it is best not to rely on RE created automatically by the Queue Server, but instead instantiate RE in the startup code. Built-in RE is definitely useful for demos or simple use cases, but defining RE in the startup code allows full customization.

If you run start-re-manager with --keep-re, the Queue Server will use RE (and db) instantiated in the startup code.

The traditional approach at NSLS-II is to call nsls-ii.configure_base (https://github.com/NSLS-II/nslsii/blob/fd25bddfcabc3d9d3312c4e68dd7989cb9f36ba6/nslsii/__init__.py#L30), which instantiates and configures RE (as it is done here https://github.com/NSLS-II-SRX/profile_collection/blob/db111a44608e19aa08f46e444051c042ffe9e1d2/startup/00-base.py#L57). The code was developed for IPython-based workflow and relies on user_ns. The Queue Server patches IPython-style startup code to allow limited use of user_ns, but I would avoid it if possible.

from bluesky-queueserver.

That is exactly the beast with which I am wrestling, the separation of our rich setup of a console or notebook experience from the startup of the queueserver which may not be able to undo all of our console planning. I'll proceed with the --keep-re option and continue extracting the other UI features (such as BestEffortsCallback and what commands are added to the user's interactive experience). I'm rather attached to our custom logging, implemented with features requested by our beam line users. Maybe that can be preserved, maybe not.

from bluesky-queueserver.

In startup scripts you can use conditional statements based on bluesky_queueserver.is_re_worker_active() to enable/disable blocks of code when it is running in RE worker.

from bluesky-queueserver.

I think custom logging should work with the Queue Server. RE Worker should be able to run any reasonable code.

from bluesky-queueserver.

https://github.com/wright-group/bluesky-in-a-box/blob/main/re-manager/startup.py#L37-L50

This is what we do, just wrap all of our plans with baseline decorator

from bluesky-queueserver.

My questions are answered. Thanks.

from bluesky-queueserver.