Architecture

Sardana is a software suite for Supervision, Control and Data Acquisition in scientific installations. It was initially developed at the ALBA synchrotron with the following mission statement:

Produce a modular, high performance, robust, and generic user environment for control applications in large and small installations. Make Sardana the generic user environment distributed in the Tango project and the standard basis of collaborations in control.

Control applications in large installations have been notoriously difficult to share. Inspired by the success of the Tango collaboration, ALBA decided to create a generic tool which enlarges the scope of the Tango project to include a standard client program - or better, a standard generic user environment. The user environment consists of a highly configurable graphical user interface, a command line interface understanding SPEC commands, and a standard way to compose new applications either by programming or with a graphical tool. It further consists of a standard macro executor, a standard set of macros, a standard range of common hardware types (like motors, counters, cameras and so on) and a configuration editor to set all this up. The origin of the Sardana name comes from a Catalan dance, honoring the region where the ALBA synchrotron is built. The toolkit to build Sardana has been C++, Python, Qt and Tango.

What Sardana provides

Users judge a control system on the ease of use of the final interfaces, their robustness and the features they offer. Sardana’s claim is that by building the user environment out of reusable lego components in a collaborative environment, higher quality software is obtained with much higher efficiency:

Standard reusable procedures (macros). At the heart of the Sardana system are procedures, written as Python functions or classes and executed in a controlled, central environment. From the description of a macro’s parameters, both the command line interface (with tab completion) and generic graphical interfaces are constructed automatically: a new procedure becomes immediately visible in all clients without any extra programming. See Writing macros for how to write them.
A command line interface: Spock. Users familiar with SPEC will immediately recognize the way procedures are invoked. Most of the standard SPEC commands (including many diffractometer geometries) are provided as standard macros. See Spock.
A GUI toolkit: Taurus. The graphical layer of Sardana is built with Taurus, a Python/Qt toolkit originally developed within the Sardana project. It can be used in conjunction with, or independently from, the rest of the system, to create custom panels inside a generic GUI or to build stand-alone applications. Generic applications can often be created by configuration alone, following one of the Sardana design guidelines: always provide a generic interface which can be specialized for an application.
A hardware adaptation layer. Since Sardana was conceived to be used at different institutes, no assumption about the hardware could be made. A plug-in mechanism (the controller) adapts Sardana to any hardware. The same abstraction also provides pseudo elements: anything which can be changed — a temperature set point, an insertion device gap, or a calculated value like the gap of a slit — can be treated as a motor and scanned with the same generic procedures.

Client-server architecture

Sardana consists of a software library which contains the sardana kernel engine, a server and a client library which allow sardana to run as a client-server based distributed control system. The communication protocols between servers and clients are plug-ins in sardana. At this time, the only implemented protocol is Tango. In earlier versions, sardana was tightly connected to Tango. This documentation is therefore centered in the Tango server implementation.

Client applications (both GUI and CLI) can connect to the sardana server through the high level sardana client API or through the low level pure Tango channels. Client applications can be built with the purpose of operating an existing sardana server or of configuring it.

Sardana server (SDS)

The sardana server consists of a sardana tango device server (SDS) running a sardana kernel engine. This server runs as an OS daemon. Once configured, this server acts as a container of device objects which can be accessed by the outside world as tango device objects. Typically, a sardana server will consist of:

a low level Pool object which manages all the server objects related to motion control and data acquisition (controllers, motors, counters, experiment channels, etc.). See The Device Pool.

a Macro Server object which manages the execution of macros (procedures) and client connection points (called doors). See The Macro Server.

a set of low level objects (controllers, motors, counters, experiment channels, etc.) controlled by the Pool object

a set of Door objects managed by the macro server. A Door is the preferred access point from a client application to the sardana server. See Door.

../_images/sardana_server.png — A diagram representing a sardana server with its objects

A sardana server may contain only a Pool object or a Macro Server object or both. It may NOT contain more than one Pool object or more than one Macro Server object.

If necessary, your sardana system may be split into two (or more) sardana servers. A common configuration is to have a sardana server with a Pool (in this case we call the server a Device Pool server) and a second server with a Macro Server (this server is called MacroServer server).

The following figures show some of the possible alternative configurations:

../_images/pool_server.png — 1 - Sardana configured to be a single Pool DS (no MacroServer present)

../_images/macroserver_server.png — 2 - Sardana configured to be a single MacroServer DS (no Pool present)

../_images/macroserver_pool_server.png — 3 - Sardana configured with a MacroServer DS connecting to an underlying Pool DS

../_images/sardana_pool_server.png — 4 - Sardana configured with a Sardana DS connecting to another underlying Pool DS

Why Tango

Tango provides the distributed object model on which Sardana relies: every sardana element (motor, experimental channel, measurement group, controller, Pool, Macro Server, Door) is exposed as a Tango device with attributes, commands and properties. This brings several benefits for free:

a mature, language independent network protocol with a central configuration database;
an event system which allows clients to be notified about changes (e.g. position updates during a motion) instead of polling;
interoperability with the large ecosystem of Tango tools and with other Tango based control systems already present in most institutes of the collaboration.

At the same time, the sardana kernel is written against an internal, protocol independent model, so the Tango layer remains a (currently the only) communication plug-in.

Symbolic sketch

The following symbolic sketch shows the different subsystems in Sardana and how they relate to each other.

The user will normally not be concerned with these implementation details. It is presented here to allow appreciating the modularity of the system.