Skip to content

Why redsun exists

Acquiring scientific data means controlling many devices, coordinating measurements, and managing the data and metadata they produce. The Bluesky ecosystem gives you a common way to talk to hardware and a model for the data, but turning them into a complete application with a usable interface is still hard work.

redsun fills that gap. It's a toolkit for building your own acquisition software out of small, separate components that work together by sending each other signals.

What redsun is made of

redsun is both the software development kit (SDK) you write components with and the application shell that runs them. Point at a shape to read more:

From your components to an application
redsun as SDKThe patterns you write components in: devices, presenters and views, and the signals, slots and shared values they exchange, so every package is written the same way.your componentsin your code or a pluginThe classes you write, or install from a plugin. Devices describe your hardware, presenters hold the application logic, and views show it on screen.a sessionclass or session fileA session is one running application. You declare its components in a Python class or list them in a session file.redsun as application shellDiscovers plugins, builds their components into a session, connects them, and launches the application.your applicationwindow, plans, data you write with itdeclared inbuilds and connectsThe patterns you write components in: devices, presenters and views, and the signals, slots and shared values they exchange, so every package is written the same way. The classes you write, or install from a plugin. Devices describe your hardware, presenters hold the application logic, and views show it on screen. A session is one running application. You declare its components in a Python class or list them in a session file. Discovers plugins, builds their components into a session, connects them, and launches the application.
redsun as SDKThe patterns you write components in: devices, presenters and views, and the signals, slots and shared values they exchange, so every package is written the same way.your componentsin your code or a pluginThe classes you write, or install from a plugin. Devices describe your hardware, presenters hold the application logic, and views show it on screen.a sessionclass or session fileA session is one running application. You declare its components in a Python class or list them in a session file.redsun as application shellDiscovers plugins, builds their components into a session, connects them, and launches the application.your applicationwindow, plans, data you write with itdeclared inbuilds and connectsThe patterns you write components in: devices, presenters and views, and the signals, slots and shared values they exchange, so every package is written the same way. The classes you write, or install from a plugin. Devices describe your hardware, presenters hold the application logic, and views show it on screen. A session is one running application. You declare its components in a Python class or list them in a session file. Discovers plugins, builds their components into a session, connects them, and launches the application.

A component is a device, presenter or view, and a plugin is an installed package that offers components; a session is where you put them together.

Design philosophy

Three ideas shape how redsun is built:

  1. It builds on tools that already exist: redsun uses the hardware protocols of bluesky, ophyd-async for devices and Qt for the window, rather than writing its own. What it adds is what you need to put them together into one application.
  2. You take only what you need. Each component stands on its own, so a session holds only the ones you declare, and a plugin that offers a motor controller works without one that offers a camera.
  3. Your data stays yours. redsun gives every file a place and a name, but your devices write the data, in the formats they choose, and what the data means and how you organize it is up to you.

Why not use Bluesky directly?

bluesky runs acquisitions, but it leaves the application around them to you: you drive the RunEngine from a command line or IPython, and the rest is expected to exist already. Step through where that rest comes from at a large facility and on a bench:

What surrounds a bluesky acquisition

The RunEngine runs an acquisition, but it needs hardware control, something that keeps it running, and something to show the user.

bluesky RunEngineruns the acquisitionhardware controlkeeping it runningwhat the user sees
bluesky RunEngineruns the acquisitionhardware controlkeeping it runningwhat the user sees

At a large facility, a control system, its staff and separate display programs are already there around the RunEngine.

bluesky RunEnginefrom a command lineor IPythona control systemsuch as EPICS or Tangofacility staffseparate programsshow the instrument
bluesky RunEnginefrom a command lineor IPythona control systemsuch as EPICS or Tangofacility staffseparate programsshow the instrument

On a bench, redsun brings them: services that speak EPICS, starting and stopping those services, the window, and a place for the data.

bluesky RunEnginein one applicationservices thatspeak EPICSredsun starts andstops the servicesA service you declare with Launch runs while the session does. One you declare with Attach already runs elsewhere, and redsun only connects your devices to it.the windowredsun buildsredsun decideswhere data goes A service you declare with Launch runs while the session does. One you declare with Attach already runs elsewhere, and redsun only connects your devices to it.
bluesky RunEnginein one applicationservices thatspeak EPICSredsun starts andstops the servicesA service you declare with Launch runs while the session does. One you declare with Attach already runs elsewhere, and redsun only connects your devices to it.the windowredsun buildsredsun decideswhere data goes A service you declare with Launch runs while the session does. One you declare with Attach already runs elsewhere, and redsun only connects your devices to it.

At the facilities bluesky was developed at, a control system such as EPICS or Tango, its staff and the display programs already exist. A bench setup, one instrument driven by one person through a window as with Micro-Manager, has none of that, so redsun supplies it, still speaking EPICS through the services your devices talk to.

Coming from Micro-Manager

If you've used Micro-Manager, many ideas in redsun will feel familiar, although the pieces are divided differently. These are the closest matches:

Micro-Manager redsun
device adapter a device, preferably with a service to reach the hardware
hardware configuration file session file
multi-dimensional acquisition plan
live mode a plan that runs until it is stopped, see Plans
plugin a plugin providing components

What redsun leaves to you

redsun gives you the framework, and everything specific to your instrument comes from you or from a plugin:

Not included Where it comes from
hardware drivers the devices and services you write or install
an image viewer a view you write
a writer for acquisition files the device or its service, see Where a device writes

For common tasks, redsun ships built-in components you can use instead of writing your own. When you do write a panel of your own for your plans, redsun still builds the plan widget of each one; see Qt widgets.

redsun also doesn't restart a service that crashes, and a program can run only one frontend. Limitations explains both.