The Device Pool

The Pool object is the sardana server object which manages all other hardware level sardana objects related with motion control and data acquisition. This object is exposed to the world as a Tango device. Its API consists of a series of methods (Tango commands) and members (Tango attributes) which allow external applications to create/remove/rename and monitor the different hardware level sardana objects.

The Pool could be seen as a kind of intelligent device container to control the experiment hardware. It has two basic features which are:

  1. Hardware access using dynamically created/deleted devices according to the experiment needs

  2. Management of some very common and well defined actions regularly done on a laboratory/factory (motion control, data acquisition, etc.)

The element model

Most of the time, it is possible to define a list of very common objects found in most of the experiments. Objects commonly used to drive an experiment usually fit in one of the following categories:

  • Moveables

    • Motor

    • Pseudo motor

    • Group of moveables

    • IORegister (a.k.a. discrete motor)

  • Experimental channels

    • Counter/Timer

    • 0D (Multimeter like)

    • 1D (MCA like)

    • 2D (CCD like)

    • Pseudo Counter

  • Communication channels

Sardana calls these objects elements. Each element type defines a stable, hardware independent interface — e.g. every motor has a position and can be moved, regardless of which hardware actually moves — so that generic procedures (like scans) can act on any element of a given category without knowing the underlying hardware. The individual element types are described in Pool elements.

Each different controlled hardware object is also exposed as an independent Tango class. The sardana device server embeds all these Tango classes together. The pool Tango device is the “container interface” and allows the user to create/delete classical Tango devices which are instances of these embedded classes.

Controllers and elements

Elements never talk to the hardware directly. Each element belongs to a controller: a plug-in software object which maps the communication between a set of elements (e.g. motors) and the underlying hardware (e.g. a motor controller crate). The controller owns its elements, identified by an axis number, and the Pool dispatches every element operation (state readout, motion, acquisition) to the corresponding controller. This separation is what makes Sardana hardware independent: supporting new hardware means writing a new controller plug-in, while the element interfaces — and everything built on top of them — stay unchanged. The concept is developed in Controllers.

Instruments

An instrument in sardana is a group of sardana elements e.g. motors, counters. Its general role is to group elements that are somehow related, this relation reflects in most of the cases the element association to a laboratory instrument.

Two features use this information: NeXus data storage and the TaurusGUI panel population.

Instruments are created in the Pool and populated from the elements that want to be added to it. Example how to configure instruments from Spock:

Pool_demo1_1.CreateInstrument(['/slit','NXcollimator'])
mot01.instrument = '/slit'
mot02.instrument = '/slit'
gap01.instrument = '/slit'
offset01.instrument = '/slit'
Pool_demo1_1.CreateInstrument(['/mirror','NXmirror'])
mot03.instrument = '/mirror'
mot04.instrument = '/mirror'
Pool_demo1_1.CreateInstrument(['/monitor','NXmonitor'])
ct01.instrument = '/monitor'

See also

PoolInstrument

the instrument class API