bluesky / bluesky-cookbook

Documentation for various use cases, ideas and "recipes" within the bluesky framework

Bluesky — An Experiment Specification & Orchestration Engine

Source	https://github.com/bluesky/bluesky
PyPI	pip install bluesky
Documentation	https://bluesky.github.io/bluesky
Releases	https://github.com/bluesky/bluesky/releases

Bluesky is a library for experiment control and collection of scientific data and metadata. It emphasizes the following virtues:

• Live, Streaming Data: Available for inline visualization and processing.
• Rich Metadata: Captured and organized to facilitate reproducibility and searchability.
• Experiment Generality: Seamlessly reuse a procedure on completely different hardware.
• Interruption Recovery: Experiments are "rewindable," recovering cleanly from interruptions.
• Automated Suspend/Resume: Experiments can be run unattended, automatically suspending and resuming if needed.
• Pluggable I/O: Export data (live) into any desired format or database.
• Customizability: Integrate custom experimental procedures and commands, and get the I/O and interruption features for free.
• Integration with Scientific Python: Interface naturally with numpy and Python scientific stack.

Bluesky Documentation.

The Bluesky Project enables experimental science at the lab-bench or facility scale. It is a collection of Python libraries that are co-developed but independently useful and may be adopted a la carte.

Bluesky Project Documentation.

See https://bluesky.github.io/bluesky for more detailed documentation.

bluesky-cookbook's Issues

Look through existing codebases for good cookbook examples

NSLS-II repos
Hyperion?

Document strategies for coping with a flaky control layer

Sometimes a point of control, like a given EPICS PV, is flaky. The best solution is to fix the underlying system, but sometimes a pragmatic workaround is needed.

Strategies:

• Implement retries.
• Cache the monitored value of a PV and skip sending a PUT if the value is already set to the desired value.

Create initial recipes

The actual recipes should not be categorised by module but should tell the story of stepping through the stack

Simplified explanation of what each repo does

ophyd

How to set up logging - how do I turn up logging on one device
How to I make a dummy device
I have a really simple EPICS IOC, how do I make an ophyd device?
How do I combine motors into a device (slits)
Write an AD ophyd device with specific filestore
How do unit test my ophyd device

bluesky (this is probably already there - need to think about how to avoid duplication)

How to set up logging
How to publish to a message bus + stream out of process
How do I add metadata to a scan / what metadata should I put in a scan
How do unit test my bluesky device
How do a parallelize X
Why do I have to write commas/brackets

How to deploy mongo db for bluesky - link to install but then copy paste that will work
How do I do adaptive scans - internal to scan/RE vs. external using a scheduler?
How do I cleanup and error handling?

Explanations

Logic in ophyd devices or bluesky plans?

Document which repo-review guidelines we intend to follow

repo-review

This seems as good a place as any to record a first pass at deciding which repo-reivew guidelines we want to ignore for now.

We have questions about whether PP302 can ever fail.

Also, move to ruff.

[ran of out time, to be continued]

Demonstrate Bluesky in a single process

Show how to run Tiled and RunEngine in a single process.

Pull cookbook examples out of the bluesky tutorials

Create end-to-end recipe example

An End-to-End Example for Building a Bluesky Experiment

A rough outline for such a tutorial may look like:

1. Simulating a multi-axis stage controller that has locations for users to put custom communication protocols. This provides a good starting point for someone incorporating Bluesky with a non-EPICS setup lab.
2. Simulating detectors. This is very domain specific and easy to patch as a user so a fast example of a 0d, 1d, 2d detectors would suffice.
3. Setting up custom plans. While almost every common plan is given as a builtin, many users may want to customize this. One or two examples (perhaps directly from the current plans source code) would suffice.
4. How to properly incorperate saving the data through tiled and/or suitcase.
5. How to setup a quick widget to display live views of the incoming data (of the 3 types in part 2).

---

Most of this information is already available in fragmented form in the documentation. As such, seeing all of the pieces play nice together would be a valuable resource for new users of Bluesky.