The configuration scripts are executed on ExperimentPCs (ExpPC). The term ExpPC refers to a PC used to conduct measurements, i.e. runs spock or online, etc. ExpPCs have the file names /online_dir/online.xml. A beamline can have one or more ExpPCs.
Each ExpPC runs a Pool, exporting one Pool device, and a MacroServer, exporting one MacroServer device, with three Doors. To have more than one Door available allows the beamline staff to assign certain tasks to Doors, e.g. p09/door/haspp09.01 could be used for general beamline operations, whereas the other Doors are used for specific purposes.
ExpPCs have separate Tango DBs, thereby separate Tango name spaces. Pools is populated with devices contained on /online_dir/online.xml. This file contains references to Tango devices from several Tango DBs. The file /online_dir/online.xml serves two purposes:
<device> <name>chi</name> <type>stepping_motor</type> <module>oms58</module> <device>p99/motor/exp.04</device> <control>tango</control> <hostname>haspp99mono:10000</hostname> </device>
The alias chi refers to a Pool device which operates the Tango motor haspp99mono:10000/p09/motor/exp.04. The Pool device is created by SardanaAIO.py.
Aliases are important. They unambiguously identify devices in a Tango DB. Each ExpPC has a Tango DB, therefore its own name space. A beamline may have several ExpPCs creating several separate name spaces. To clarify this: assume that a beamline has two ExpPCs: PC-A and PC-B. Our configuration allows to use the alias 'theta' on PC-A for some motor and on PC-B for a different motor.
The following table gives an overview of the scripts:
Motors which are offline are ignored, i.e. no corresponding pool device is created. A motor is considered offline, if state() cannot be evaluated of if the state is FAULT or ALARM.
If called with the -c option, SardanaDiag.py will not be invoked, i.e. no core dumps will be created.
Tags: If called with the -t option (tags), SardanaAIO.py selects devices from online.xml according to their tags field. The following rules apply:
Devices are selected, if
<tags>
field matches a tag specified on the command line.
Consider this example:
... <device> <name>d1_mot01</name> <tags>expert,standard</tags> <type>stepping_motor</type> <module>oms58</module> <device>p99/motor/d1.01</device> <control>tango</control> <hostname>haspp99:10000</hostname> </device> ... <device> <name>d1_mot02</name> <tags>expert</tags> <type>stepping_motor</type> <module>oms58</module> <device>p99/motor/d1.02</device> <control>tango</control> <hostname>haspp99:10000</hostname> </device> ... <device> <name>pilatus</name> <tags>pilatus</tags> <type>DETECTOR</type> <module>pilatus300k</module> <device>p99/pilatus/exp.01</device> <control>tango</control> <hostname>haspp99:10000</hostname> </device> ...
If we use the SardanaAIO.py -x -t standard all devices having the
standard
tag will be selected, d1_mot02
, the Pilatus and the Eiger detectors will be ignored.
To select the standard devices and the Pilatus, we issue
SardanaAIO.py -x -t standard,pilatus. Notice that there is no
blank space between standard
and pilatus
.
The Macroserver environment variable AIO_INFO is created which keeps track of the tags.
$ SardanaAIO3.py -x -t user,expert p09/door/haso107d10.01 [1]: lsenv AIO_INFO Name Value Type ---------- --------------------------- ------ AIO_INFO {'TAGS': "'user,expert'"} dict
It is possible to use the tags that have been selected before:
$ SardanaAIO3.py -x -t default
To inspect the default tags:
$ SardanaAIO3.py -t display
In general, SardanaAIO.py -x is executed after /online_dir/online.xml has been edited.
If called with the -c option, SardanaDiag.py will not be invoked, i.e. no core dumps will be created.
If called with the -c option, SardanaDiag.py will not be invoked, i.e. no core dumps will be created.
haspp09:~> SardanaStatus.py Local DoorNames(s): ['p09/door/haspp09.01', 'p09/door/haspp09.02', 'p09/door/haspp09.03'] MacroServer p09/macroserver/haspp09.01 state ON Related Pools: --- Pool ( local) p09/pool/haspp09 state ON MG: [u'mono_t01', u'exp_c01'] MacroServer p09/macroserver/haspp09.02 state ON Related Pools: --- Pool ( local) p09/pool/haspp09 state ON MG: [u'mono_t01', u'exp_c01'] MacroServer p09/macroserver/haspp09.03 state ON Related Pools: --- Pool ( local) p09/pool/haspp09 state ON MG: [u'mono_t01', u'exp_c01']
If the script is invoked using the -f parameter, information about the Pool controllers and Pool devices are displayed:
haspp09:~> SardanaStatus.py -f Local DoorNames(s): ['p09/door/haspp09.01', 'p09/door/haspp09.02', 'p09/door/haspp09.03'] --- Pool ( local) p09/pool/haspp09 state ON ControllerList am_gap ON, 1 devices: gap am_tga ON, 1 devices: tga_off analyzer_eh1 ON, 1 devices: analyzer atto300_exp ON, 2 devices: atto1, atto2 dcm_energy ON, 1 devices: energyfmb dcm_motor_mono_01 ON, 1 devices: dcm_bragg dgg2_exp_01 ON, 1 devices: exp_t01 dgg2_exp_02 ON, 1 devices: exp_t02 dgg2_mono_01 ON, 1 devices: mono_t01 dgg2_mono_02 ON, 1 devices: mono_t02 e6cctrl ON, 8 devices: e6cctrl_psi, e6cctrl_h ... e6cctrl_qperpar2 mca8701_exp ON, 1 devices: exp_mca01 mult_mono_01 ON, 1 devices: multiplemotormono1 ...
The command files mentioned so far are most important. The follwing may also be helpful now and then: