.. _sardana-overview: ============ 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 :ref:`sardana-macros-howto` 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 :ref:`sardana-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 :ref:`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 :ref:`motor ` and scanned with the same generic procedures. .. _sardana-devel-global-overview: 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 :term:`client-server ` based distributed control system. The communication protocols between servers and clients are :term:`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 :term:`GUI` and :term:`CLI`) can connect to the sardana server through the high level sardana client :term:`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 (:term:`SDS`) ---------------------------- The sardana server consists of a sardana tango device server (:term:`SDS`) running a sardana kernel engine. This server runs as an :term:`OS` :term:`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 :ref:`sardana-pool-overview`. - a **Macro Server** object which manages the execution of macros (procedures) and client connection points (called doors). See :ref:`sardana-macroserver-overview`. - 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 :ref:`sardana-door-overview`. .. figure:: /_static/sardana_server.png :width: 400 :align: center 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: .. figure:: /_static/pool_server.png :width: 256 :align: center 1 - Sardana configured to be a single Pool DS (no MacroServer present) .. figure:: /_static/macroserver_server.png :width: 256 :align: center 2 - Sardana configured to be a single MacroServer DS (no Pool present) .. figure:: /_static/macroserver_pool_server.png :width: 256 :align: center 3 - Sardana configured with a MacroServer DS connecting to an underlying Pool DS .. figure:: /_static/sardana_pool_server.png :width: 512 :align: center 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. .. image:: /_static/sardana_sketch.png :align: center :width: 500 The user will normally not be concerned with these implementation details. It is presented here to allow appreciating the modularity of the system. .. _ALBA: http://www.cells.es/ .. _Tango: http://www.tango-controls.org/ .. _Taurus: http://packages.python.org/taurus/ .. _Qt: http://qt.nokia.com/products/ .. _Python: http://www.python.org/ .. _SPEC: http://www.certif.com/