Overview of available documentation

Please have a look at https://blueskyproject.io as first stop for documentation on bluesky, Please note: *Bluesky* is used for the collection of experiment orchestration and for one of its core libraries. This page provides further links to different Bluesky documentation.

Code repository

Bluesky is developed in public: Please have a look to https://github.com/bluesky for the different repositories of its different components.

Installation

Binary packages are provided by https://pypi.org or for conda https://pypi.org/project/bluesky/. See e.g. bluesky tutorial for details.

Learning bluesky.

Bluesky is structured in a set of different components that cover different aspects of the implementation. A user of a well setup experiment will only require to know basic Bluesky functionality. Implementating a complex device will require a bit more insight into the architecture and its different componets. Thus the required learing investment depends on the role one fulfills.

Using bluesky

If using bluesky in an already setup environment the background of the https://blueskyproject.io/bluesky/tutorial.html should cover nearly any aspect.

Experiment setup

Setting up an experiment will require to interface some actuators or motors. The access to devices is encapsulated by Ophyd devices (https://blueskyproject.io/ophyd/). It exposes the functionality of the device in a simple and consistent manner. Ophyd comes with predifined devices for motor records. It supports positioners. Devices can contain subdevices. Many customisation can be made, implementing dedicated methods for set or trigger. (Have a look to ophyd's architecture).

The predefined plans will fit many common experiments. These plans can be adapted by defining per_step stub plans. If you need to implement your own plan, have a look to the implementation of the standard plans as an example.

Liveplots are implemented as callbacks. These receive the event stream and typically extact and visualise the data the user needs to see.

Collection of documentation

Here links are provided to different parts of the documentation or to tutorial notebooks

• Overview: The central repository of documentation is found at https://blueskyproject.io/. The entry points listed here follow the learning style of the author of this page.
  • A general overview of bluesky and all its functionality is given at https://blueskyproject.io/bluesky-slides/
  • Dan Allen gave an overview of bluesky and its development at the EPICS Collaboration Fall Meeting 2020 based on the slides mentiond above.
• Software components: ample documentation is provided for the different software components.
  • Bluesky is based on an event model, data model
  • Devices are abstracted by Ophyd. Please have a look to their architecture.
  • Bluesky "takes a plan and executes it". See its tutorial section for a first start
  • Data brokers facilitate storing data in database. Typically one will register a databroker with the RunEngine.
  • Device drivers: examples are provided in the tutorials repository as Ipython notebooks. The following ones cover different aspects of devices
    • Anatomy of a device
    • Epics signal
    • Device
    • Flyer basics: i.e. devices that take data will triggered by an "external signal". Typical use example: a frame grabber that is triggered by the encoder which is mounted on a moving axis

Checklist for learing bluesky

Learning bluesky is like learning LaTeX: The start is much easier, if you have a mate next door that you can ask for help when you are stuck As soon as you gain knowledge, it gets much easier to create sophisticated devices or complex measurement plans.

• Do you know the event model /data model.
• For implementing your own plans:
  • Have a look to the per_step keyword of many standard plans. This allows using the predefined plan but modify what is done at each step
  • Concept of plans which are based on generators.
  • yield and yield from statements
  • Bluesky stub plans and plan decorators
• For writing complex devices:
  • Concept of status object
  • python scope and the nonlocal statement
  • Building devices:
    • Devices with subdevices
    • Pseudo positioners
    • Formatted component
    • Dynamics Device Component

Data storage

The databroker typically then uses care to store the data. At BESSYII a mongo database is used for storing data acquired during accelerator comissioning. Data brokers are available for many different back ends. A typical user will only need to know how his databroker is named and register it with the runengine using RE.subscribe(broker.insert)

Chat

See https://gitter.im/NSLS-II/DAMA