blaise-blog/bluesky-for-the-rest-of-us


This is a work-in-progress post.

Bluesky is an awesome Python package for hardware orchestration. Really, it's amazing. It's an abstraction layer allowing scientists to easily define and carry out almost any experiment. The abstractions it defines are well thought-out. A whole ecosystem of Bluesky-compatible tools exist that could replace much of the software you're building yourself.

You really should be using Bluesky...
But...

How do I "use Bluesky" anyway? I'm just a graduate student in a small lab building a humble instrument. The Bluesky developers work for large national labs that have teams of staff scientists setting up their instrumental infrastructure! Where is my hardware enablement software? What the heck is Ophyd? How do I store my data to a simple text file? What are the concrete benefits of this ecosystem anyway?

I'm right there with you. That's what this blog post is all about. It's my attempt at a beginners guide to Bluesky, written for "the rest of us" humble instrumentalists who are just trying to make our experiments work without reinventing the wheel. It's everything I wish someone had told me when I started. This is a huge ecosystem with a lot of complexity, so think of this as a "bird's eye view". This is also just my (Blaise's) opinion. I am not a Bluesky developer.

I hope that, with this introduction, you can join me in the growing community of small instrumentation developers benefiting from and contributing to the Bluesky Community. If you are currently maintaining a small Python hardware orchestration or enablement package feel free to reach out to me directly---I'm happy to help build a bridge between your current package and Bluesky. The more we can start to build in the same direction, the less we will have to duplicate each-other's effort.

table of contents

big picture

...

hardware enablement

The core Bluesky developers are principally interested in EPICS. EPICS is a mature and sophisticated control layer with a huge existing library of hardware support. Bluesky interfaces with Ophyd and Ophyd interfaces with EPICS via PyEpics and Caproto. I won't pretend to know any more than that, and if you're one of "the rest of us" you probably don't need to know anything more either. Unfortunately EPICS' sophistication and age bring complexity that is out of reach for most small labs.

Luckily Bluesky uses a very simple abstraction for interfacing with hardware. This means that it's actually very simple to write your own Python class for your own hardware. To prove it, I'll write a simple interface for an imaginary linear translation stage.

status object
device

Of course, several existing hardware enablement projects are already "Bluesky ready". Unlike EPICS, these projects are accessible to small labs.

If you have a particular piece of hardware you are looking to control via Bluesky, I recommend starting by seeing if any of the projects above already support your device. Importantly, it's fine to mix and match devices from a variety of packages. If your hardware isn't supported by an existing project, you can either write your own interface class or try to contribute hardware support. I'm a yaq core developer, so I'd be especially happy to see you add hardware to the yaq ecosystem---feel free to get in touch.

Bluesky basics

Events

Plans

Run engine

Data storage

data storage

clients

happi

PyDM

the ecosystem


built 2024-03-29 05:00:03

CC0: no copyright (source)