Skip to content

Statement of need

Scientific data acquisition means controlling many devices, coordinating measurements, and managing the data and metadata they produce. The Bluesky ecosystem provides a hardware abstraction layer and a data model, but turning them into a complete application with a usable interface is still hard work.

redsun fills that gap with a modular, event-driven framework for building acquisition applications.

graph TD
    redsun -->|provides SDK for| components
    components -->|loaded by| redsun
    redsun -->|assembles| application

The role of each part

  • redsun as SDK provides base classes and communication patterns (devices, presenters, views, and a shared container through which components exchange signals and data), so every package is written the same way.
  • Components are packages users write: hardware drivers, logic and interfaces built on the redsun SDK.
  • redsun as application shell discovers plugins, wires them together through its container, and launches the application.

Design philosophy

redsun follows three principles:

  1. Don't reinvent the wheel. Use existing tools, such as the bluesky hardware protocols and Qt for the interface, and ship the tools to build the wheel.
  2. Be modular. Users pick only the components they need. A plugin providing a motor controller works without one providing a camera interface.
  3. Give users control. Users own their data and metadata. The framework gives structure but does not decide what data means or how it is organized.

Why not use Bluesky directly?

bluesky was designed for interactive use: the user drives the RunEngine from a command line or IPython. That fits where it was developed, large facilities with many devices behind a central control system such as EPICS or Tango.

redsun adds a lab-bench experience on top of bluesky, for setups controlled through a graphical interface, as with Micro-Manager.