Dec 2, 2014 - 4.7.3 SARDANA - Instrumentation and data acquisition control system ...... 1available under the terms of the GPLv2 license and down-loadable at [11] ...... a door, acting as a command line interface MacroServer client. 5.
ELI-BL-4400-REP-00000067-2
Document No:
00000067
Edition:
2
Process:
REP
No. of pages:
127
Report
Tango EPICS report
Approved
Position
Name
Signature
Alejandro Vazquez-Otero
Prepared
Date
Bruno Le Garrec 12.02.2014
Ondrej Janda Karel Spalenka Accary Jean-Baptiste Roman Trunecek
E L I - B L - 4 4 0 0 -
1 | 127
R E P - 0 0 0 0 0 0 6 7
·
2
ELI-BL-4400-REP-00000067-2
Contents I
Qualitative analysis
9
1 Introduction
10
1.1
Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.2
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2 Tango vs EPICS at a glance
13
2.1
TANGO
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2
EPICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.3
Testing both
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Discussion
II
15
3.1
Developers opinions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Summary
16
3.3
CS group general conclusions
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Technical analysis
18
21
4 TANGO
22
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2
Setup description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2.1
Hardware development platform
. . . . . . . . . . . . . . . . . . . .
22
4.2.2
Software and platform . . . . . . . . . . . . . . . . . . . . . . . . . .
23
The Tango device architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
4.4
4.5
4.3.1
Attributes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.3.2
Commands
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.3.3
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3.4
State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Design using the POGO glue
. . . . . . . . . . . . . . . . . . . . . . . . . .
27 28
4.4.1
The POGO graphical environment
. . . . . . . . . . . . . . . . . . .
28
4.4.2
Code Architecture description . . . . . . . . . . . . . . . . . . . . . .
31
4.4.3
Memory management in Tango . . . . . . . . . . . . . . . . . . . . .
35
4.4.4
Working with Tango variables . . . . . . . . . . . . . . . . . . . . . .
36
Running the Tango Device Server . . . . . . . . . . . . . . . . . . . . . . . .
38
4.5.1
Implementing the T-LSR300A device . . . . . . . . . . . . . . . . . .
38
4.5.2
Starting the Tango Server . . . . . . . . . . . . . . . . . . . . . . . .
41
4.5.3
Testing the Tango Server with Tango Device Class
. . . . . . . . . .
41
. . . . . . . . . . . . . . . . . . . . .
42
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.6
Tango Control System test conclusion
4.7
Interfaces 4.7.1
Tango Application Toolkit
4.7.2
Tango ATK viewers
. . . . . . . . . . . . . . . . . . . . . . .
43
. . . . . . . . . . . . . . . . . . . . . . . . . . .
43
2 | 127
ELI-BL-4400-REP-00000067-2
4.7.3
SARDANA - Instrumentation and data acquisition control system open source project
4.8
4.9
. . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.7.4
Taurus - Tango Graphical User Interface Library open source project
46
4.7.5
TaurusGUI - A taurus-based rapid GUI creation framework . . . . .
48
4.7.6
Summary for PyTango, Taurus and SARDANA . . . . . . . . . . . .
50
4.7.7
QTango - Qt for Tango
4.7.8
MANGO
4.7.9
Summary for Tango GUI tools
. . . . . . . . . . . . . . . . . . . . . . . . .
50
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
. . . . . . . . . . . . . . . . . . . . .
51
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.8.1
Hardware description . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.8.2
LImA - A Library for Image acquisition
. . . . . . . . . . . . . . . .
52
4.8.3
ProcessLib (submodule of LImA) . . . . . . . . . . . . . . . . . . . .
56
4.8.4
Ccd1394 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
4.8.5
Practical tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data acquisition
Archiving
57
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.9.1
Tango Control System Archiving (Backup) Possibilities . . . . . . . .
59
4.9.2
Database Direct Archiving (Backup) . . . . . . . . . . . . . . . . . .
59
4.9.3
Historical (HDB) and Temporary (TDB) Database Archiving using GUI named MAMBO
. . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.9.4
HDB++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
4.9.5
Snapshots (SNAP) Database Archiving using the GUI BENSIKIN
62
.
5 EPICS
64
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
5.2
Setup description
64
5.3
5.4
5.5
5.6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1
Hardware development platform
. . . . . . . . . . . . . . . . . . . .
5.2.2
Software/platform
64
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
EPICS base and support modules installation . . . . . . . . . . . . .
64
EPICS device implementation . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3
67
5.3.1
Possible approaches to implement device
. . . . . . . . . . . . . . .
67
5.3.2
Creating support module and EPICS application for T-LSR300A . .
67
Interfaces
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
5.4.1
MEDM - Motif Editor and Display Manager . . . . . . . . . . . . . .
72
5.4.2
MEDM T-LSR300A GUI
. . . . . . . . . . . . . . . . . . . . . . . .
72
5.4.3
Database con guration graphical tools . . . . . . . . . . . . . . . . .
73
5.4.4
Control System Studio . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.4.5
Control System Studio T-LSR300A GUI . . . . . . . . . . . . . . . .
74
Data acquisition
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.5.1
EPICS implementation . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.5.2
rewireDCAM
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.5.3
AravisGigE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.5.4
Practical tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
Archiving
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.6.1
Channel Archive Tools . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.6.2
The newest development in EPICS v4
82
3 | 127
. . . . . . . . . . . . . . . . .
ELI-BL-4400-REP-00000067-2
6 FURTHER TOPICS 6.1
6.2
6.3
6.4
6.5
Multi-Threading
84 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
6.1.1
EPICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
6.1.2
Tango
85
6.1.3
Threading in device servers
6.1.4
Threading in clients. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pooling
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87 88 89
6.2.1
EPICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
6.2.2
Tango
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
Event driven approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.3.1
EPICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
6.3.2
Tango
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
Logging and status system . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
6.4.1
EPICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
6.4.2
Tango
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
Exception handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
6.5.1
EPICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
6.5.2
Tango
99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 EPICS 4
101
7.1
The reasons behind EPICSv4
. . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.2
Status of EPICSv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 7.2.1
The objectives for EPICSv4 . . . . . . . . . . . . . . . . . . . . . . . 101
7.2.2
Out of scope
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3
EPICSv4 at a glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.4
The EPICS new architecture
7.5
The pvData (C++ version)
7.6
7.7
. . . . . . . . . . . . . . . . . . . . . . . . . . 103 . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.5.1
Example: creation of the pvData
7.5.2
Example: usage of the pvData
7.5.3
Memory management
. . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . 106
The pvAccess protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.6.1
Example: starting the pvAccess service . . . . . . . . . . . . . . . . . 107
7.6.2
Example: pvAccess client
. . . . . . . . . . . . . . . . . . . . . . . . 107
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8 A FEW TECHNICAL REMARKS
110
8.1
Supported platforms and programming languages . . . . . . . . . . . . . . . 110
8.2
Client-server communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
8.3
Addressing
8.4
Critical services redundancy
8.5
Synchronization and time-stamping . . . . . . . . . . . . . . . . . . . . . . . 111
8.6
Simulated devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.7
Logging
8.8
Parallel Processing
8.9
Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 . . . . . . . . . . . . . . . . . . . . . . . . . . 111
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4 | 127
ELI-BL-4400-REP-00000067-2
8.10 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9 BINDINGS FOR COMMERCIAL PRODUCTS
113
9.1
LabVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.2
MATLAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.3
IGOR Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
10 TANGO EPICS TRANSLATORS 10.1 Using an EPICS device in Tango
115 . . . . . . . . . . . . . . . . . . . . . . . . 115
10.2 Using a Tango device in EPICS . . . . . . . . . . . . . . . . . . . . . . . . . 118
III
10.3 Summary
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Appendix
120
11 List of facilities consulted and/or visited for the elaboration of this report. 120 12 Glossary
122
13 Acronyms
124
References
126
5 | 127
ELI-BL-4400-REP-00000067-2
List of Figures 1
The motorized linear slide and the Basler acA1300-30gm CCD camera (image from Basler homepage) used for testing Tango and EPICS.
2
. . . . . . .
14
Relations between the Tango Class attached to the physical device, the Tango Server in which the Tango Class is registered, and the client program that access to device's functionality.
. . . . . . . . . . . . . . . . . . . . . .
T-LSR300A class
22
3
POGO main menu. Full implementation of the
. . . . .
29
4
Class de nition options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5
Creation of a command
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
6
Output generation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
7
Order of command method execution . . . . . . . . . . . . . . . . . . . . . .
35
8
Order of read attribute method execution
. . . . . . . . . . . . . . . . . . .
37
9
Order of write attribute method execution . . . . . . . . . . . . . . . . . . .
39
10
T-LSR300A implementation structure
. . . . . . . . . . . . . . . . . . . . .
40
11
Create server window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
12
Testing of T-LSR300A attributes
42
13
Example of Tango ATK viewers with ATK attibute and command viewers [1]. 44
14
Simple panel made with ATK to permit to control the position of the motor.
44
15
Conceptual design of SARDANA [2].
. . . . . . . . . . . . . . . . . . . . .
46
16
Taurus logo
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
17
Screenshots of what TAURUS can achieve [3].
18
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
Schematics representation of the two parts of the Taurus library and its interaction with the rest of the control system [3].
19
47
. . . . . . . . . . . . . .
47
Screenshot of the graphical tool, taurus Designer, used to make interface to control the motor. On the left side is the set of available widgets already made. In the middle is the the graphical interface to be made and on the right there is all the properties and actions about or oer by the widget.
.
49
. . . . . . . . . .
49
21
Representation of QTango underlying layers [4]. . . . . . . . . . . . . . . . .
50
22
On the left, the Design phase used during the design of the panel and on
20
Simple panel made with taurus to permit to control the position of the motor.
It has been produced both with Taurus and taurusGUI. Taurus
Designer (Qt Designer with widgets dedicated to be used with Tango) oers a large choice of widget to be added to the panel control.
the right, the Run phase which is the corresponding running control panel [5]. 51 23
Basler acA1300-30gm (image from Basler homepage) . . . . . . . . . . . . .
52
24
Lima overview (source: LImA homepage)
. . . . . . . . . . . . . . . . . . .
53
25
The Lima control panel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
26
Tango camera implementation GUI . . . . . . . . . . . . . . . . . . . . . . .
57
27
MySQL Workbench Data Export settings
60
28
MAMBO HDB sample screenshot . . . . . . . . . . . . . . . . . . . . . . . .
61
29
MySQL HDB Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
30
BENSIKIN sample screenshot . . . . . . . . . . . . . . . . . . . . . . . . . .
63
31
List of the MySQL
63
32
StreamDevice architecture (taken from EPICS web site)
SNP Data
. . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
6 | 127
. . . . . . . . . . .
68
ELI-BL-4400-REP-00000067-2
33
MEDM GUI for T-LSR300A . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
34
Control system studio logo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
35
Control system studio architecture.
. . . . . . . . . . . . . . . . . . . . . .
74
36
Working with the OPI BOY . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
37
T-LSR300A GUI created in CSS
38
areaDetector architecture (source: areaDetector homepage)
. . . . . . . . .
77
39
The ImageJ viewer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
40
The medm GUI with started plugins. . . . . . . . . . . . . . . . . . . . . . .
81
41
RDB Archiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
42
CSS DataBrowser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
43
Pooling in Jive
91
44
The EPICSv3 architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
45
The EPICSv4 architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
46
The pvData hirearchy
47
Bridge from the T_LSR300A EPICS support module to Tango
48
EPICS to Tango translator (image from [6]) . . . . . . . . . . . . . . . . . . 118
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7 | 127
. . . . . . . 116
ELI-BL-4400-REP-00000067-2
List of Tables 1
Connection speci cations for the T-LSR300A
. . . . . . . . . . . . . . . . .
23
2
Speci cations of TangoBox . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
3
Speci cations of TangoBox . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4
Implemented instructions
25
5
Implemented methods for "position" attribute . . . . . . . . . . . . . . . . .
26
6
Implemented commands
27
7
List of les generated by POGO
8
Command speci c methods
9
Read attribute speci c methods
. . . . . . . . . . . . . . . . . . . . . . . .
36
10
Read attribute speci c methods . . . . . . . . . . . . . . . . . . . . . . . . .
38
11
Installed EPICS development software
. . . . . . . . . . . . . . . . . . . . .
65
12
ASYN created les . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
13
EPICS script created les
14
The implemented
15
LibCom/osi implementations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
. . . . . . . . . . . . . . . . . . . . . . . . . . .
34
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
T_LSR300A
commands.
69
. . . . . . . . . . . . . . . . .
70
. . . . . . . . . . . . . . . . . . . . . . . . . .
86
16
ORB libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
17
Summary of facilities that have been visited, or contacted via email, with their choice of Tango or EPICS for the control system. . . . . . . . . . . . . 120
18
Summary of facilities that have been visited, and use a CS software dierent from Tango or EPICS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8 | 127
ELI-BL-4400-REP-00000067-2
Part I
Qualitative analysis
9 | 127
ELI-BL-4400-REP-00000067-2
1
Introduction
Control System
1.1
CS)
Although the contemporary de nition of a Control System (
diers from the original
approach of a device that manages the behavior of other devices, in its basic meaning the idea is still valid. However, since a modern insight about the CS de nition entails the use of
integration, the purpose of such controlling
device has nowadays a wider scope.
The integration of many devices into an upper entity constitutes the cornerstone of the building of a CS. And it comprises several topics closely tied to the transport of information, and therefore to the network.
scalable, redundant, and monitored from the point of view
A CS has to be
must be built following a global design suitable to be
of processes. This set of prerequisites leads to the concept of hierarchy, and more precisely, to the concept of hierarchy of information in a
network distributed system
.
Among the many advantages of the hierarchy of information it provides a layer of abstraction were the logic of an operation (or process) can be encapsulated. Such paradigm can be understood in terms of a tool that gives the possibility to adapt to situations that cannot be envisaged in advance (i.e.
exibility).
Indeed, all modern CS software packages
are being engineered following this trend. Summarizing, the number and complexity of chores that an actual modern facility has to perform makes essential an approach that should be based on the following keywords:
distributed hierarchy of processes. Requirements
1.2
As the main rule, before evaluating a software a list of requirements must be written. Not always as a de nitive list of constraints (as not all of them are always vital but desirable), but rather for being used as a set of guidelines in the evaluation of the available candidates, and the subsequent decision-making. This report deals with two software packages intended for CS. Therefore a classic list of high-level requirements for CS can be enumerated as follows:
·
Flexible alarm system
·
Rational database archiving ability.
Logging and noti cation system
·
Best if event based.
Debugging and reporting system. Severity levels. Multiple receivers system ( les, database, console, other devices, etc.).
Threading support
Thread logic at library/CS level.
10 | 127
ELI-BL-4400-REP-00000067-2
·
Transparent system.
Application Programming Interface (API )& Architecture
·
Thread safety at library/CS level.
Multi-platform. Developers friendly architecture, best hierarchical architecture. Possibility of extensions, best in one architecture. Following modern trends. Support of the task speci c formats. Documentation, documentation, documentation... Multiple GUI's development tools support (graphical user interface).
Openness
Tested, open-source, mature, long-term solution. Well established community, possibility of training. Acceptable learning curve.
But herein must be emphasized that these two software frameworks have undergone no less than one decade of active development, reaching a level of maturity that makes them capable of ful lling the traditional set of requirements (though both solutions do not provide the same level of compliance).
This statement is reasonably demonstrated by the
fact that large physics facilities all over the world have been running under their control for many years. Consequently, the list of preferences for deciding which one is the most suitable option for designing the CS of the future ELI Beamlines laser facility should come from a dierent source. This reasoning explains why the herein survey will not focus on the basic options that can be expected for any kind of Control System software, though they will be named and properly analyzed in the right place along this document. On the contrary, these remarks have lead to split the original list of requirements into two main groups:
usability
and
manpower.
From the usability point of view, in the present context it can be understood not only as a de nition of how friendly is the framework regarding the developer, but also as a measure of the capability in term of development costs:
·
is that feature already implemented?
·
how complicated it would be to implement the desired feature?
·
is it even possible in regards of the provided development framework?
Thus one main argument for deciding which software is the best possible candidate is the high level (in the meaning of user-level) feature already provided out-of-the-box, while another argument could rely on the available manpower, and more precisely, on their personal skills and interests. Despite it may look irrelevant at rst glance, an example of
11 | 127
ELI-BL-4400-REP-00000067-2
its importance is the reason why
P ython
is being consolidating as the main programming
language at many facilities using the TangoCS:
in the jobs market.
the lack of available C + + developers
Besides, a team of Computer Scientists will develop slightly dierent
approaches to solve the same problem than a team of electrical engineers (or physicists,
etc ), and therefore their predisposition for one or another development environment does matter and has a mensurable impact in the nal result.
In other words, the technical
background of the people in charge of using the software should be a top level requirement.
12 | 127
ELI-BL-4400-REP-00000067-2
2
Tango vs EPICS at a glance
2.1
TANGO
The TAco Next Generation Objects (TANGO) control system is an Open Source object oriented control system for controlling accelerators, experiments and any kind of hardware or software. It has being actively developed by a consortium of synchrotron radiation institutes: Alba, Anka, Desy, Elettra, ESRF, FRM II, MAX-IV, Solaris and Soleil. The rst draft of TANGO (at that time named TACO) was proposed at the ESRF facility in 1989. It has been successfully used as the heart of the ESRF Control System. In June 2002, Soleil and ESRF o cally decide to collaborate to develop this renewal of the old TACO control system. Soleil is a French synchrotron radiation facility close to Paris. In December 2003, Elettra joined the club. Elettra is an Italian synchrotron radiation facility located in Trieste. Then, beginning of 2005, ALBA also decided to join. ALBA is a Spanish synchrotron radiation facility located in Barcelona. The new version of the Alba/Elettra/ESRF/Soleil control system was named TANGO and its development is based on technologies and principles used in facilities like
NIF (National Ignition Facility) at Livermore.
Currently more
than 30 facilities and companies deploy TANGO as a framework for Control System. The latest version of TANGO is the version 8.1.2. released in June 2013.
2.2
EPICS
The acronym EPICS means Experimental Physics and Industrial Control System, and it is a set of Open Source tools, libraries, and applications developed collaboratively and used worldwide to create distributed control systems for scienti c instruments, such as particle accelerators, telescopes and other large scienti c experiments.
EPICS is three things at once: an architecture for building scalable control systems; a collection of code and documentation comprising a software toolkit; and a collaboration of major scienti c laboratories and industry. EPICS is primarily the work of the Accelerator Technology (AT-8) group at Los Alamos National Lab, and the Advanced Photon Source (APS) at Argonne National Lab.
The Computer Systems Group at Lawrence Berkeley
National Lab, the now-defunct Superconducting SuperCollider Lab, and the Continuous Electron Beam Accelerator Facility were early participants. Now many laboratories, universities, and industrial facilities worldwide use EPICS for implementing the Control System of physics accelerators, detectors, telescopes, and various industrial processes.
Two
industrial partners have signed technology transfer agreements. Thus EPICS comprises a full collaboration, with shared, tested and documented releases (co-ordinated by APS); a supported, but no-cost product by some; and a collection of source code to be used as a starting point by others. The latest version of EPICS is version 3.15.x from 2013 but the base package is marked as not meant for operational use. Instead of EPICS 3.15.x, the version 3.14.12.3 from December 2012 is considered as the standard for production. In addition a new version of EPICS (v4) is under development. This version will oer a completely new architecture and philosophy consistent with current trends in the Control System design.
13 | 127
ELI-BL-4400-REP-00000067-2
2.3
Testing both
To evaluate and compare how both control system (CS) software work, a basic implementation was carried out. The decision was made based on the available tools at the time this report was written (and also based on the available amount of time), though it provides a ground for a general understanding of both approaches for CS. Therefore, a Motorized Linear Slide using a serial port, and a Basler CCD camera (see gure 1) were used.
Figure 1: The motorized linear slide and the Basler acA1300-30gm CCD camera (image from Basler homepage) used for testing Tango and EPICS.
14 | 127
ELI-BL-4400-REP-00000067-2
3
Discussion
3.1
Developers opinions
Till this point we have gained some vocabulary (and/or acronyms) regarding Tango and EPICS software, so before starting a general discussion about advantages/drawbacks of both CS options, it does make sense to take a quick look at what developers say about both solutions. Thus, a set of relevant (and perhaps also representative) opinions coming from developers that works in physics-oriented facilities that have been extracted from dierent Internet forums, are presented: 1. The way Tango is packaged and used seems to assume a programming background, although this is becoming less so. EPICS does not require any programming backgroung for basic operation, and has more of a 'industrial controls' rather than 'computer science' feel to it.
So if you have a team of programmers you might prefer
TANGO, if your systems will be built by your equipment specialists you might prefer EPICS. 2. The way to see things is dierent between Tango and EPICS. EPICS manages Process Variable (PV) which are elementary piece of information coming from the controlled equipment.
In Tango, the basic element is a "device".
Within a device, you will
nd commands, attributes and states. As far as I know, EPICS does not have this notion of device in which: - You can group informations (the attributes) - You also have commands (to do action on the controlled equipment) - You have a device state allowing you to build state machine. Therefore using Tango, you are able to create hierarchy of information. 3. Tango sees system at a more abstract level than EPICS where you have a set of distributed object providing services, commands and states and you can de ne hierarchies between them.
Whereas EPICS presents the information at elementary
levels ( records ai, bi .. ) and present as process variable. Although, in next version of EPICS ( EPICS > v4.0 ) there is thinking of grouping data into higher level of entities. Based on these opinions it seems that all of them agree that Tango is a Computer-Scienceoriented product intended to be a full package for CS.
15 | 127
ELI-BL-4400-REP-00000067-2
3.2
Summary
The presented survey have lead us to conclude that the Tango CS framework is the optimal solution, as it ts within all our requirements for building the Control System of the ELIBL facility. To support this decision we rely upon two type of arguments: technical and nontechnical (although the last may be named political reasons, we strongly think they are at least as important as their technical counterpart). Therefore we can rstly enumerate the technical arguments: 1. Below (see section 3.3) you will nd a collection of technical reasons that our team has written after experimenting with both, Tango and EPICS. 2. For data analysis and archiving Tango provides some default applications, while EPICS doesn't provide any. 3. Not competition for designing a central control system, instead of EPICS is at. 4. Tango is more likely to be used in complex systems where a lot of loop processes are involved (see for example ERAS: European MaRs Analog Station for Advanced Technologies Integration project which is an extension of the Mars Analog Research Station program spearheaded by the Mars Society). Concerning the political reasons, the following statements seems to tip the balance in favor of Tango:
·
The three pillars will decide to use Tango in common agreement. Opening the door to:
Ease of manpower exchange, along with know-how within the three pillars. The possibility of reusing the software solutions implemented in one facility in the others.
In general, the sharing of resources across the three pillars.
How lasers in Tango (Thales, Apollon) and ELI will push National Instruments ·
Tango is an European Software project, and therefore we can apply for European grants related with software development in future.
·
The European community of Synchrotron uses Tango, thus receiving any kind of training becomes simple, either at home or elsewhere in Europe.
·
The possibility of joining the Tango development consortium assures that any facility interested in steering the future development of this CS software to cover their future needs can do it. This hardly can be done in EPICS.
·
National instruments has con rmed its willingness to provide o cial support for LabView in Tango.
Either making o cial the link between both frameworks, or
directly providing the required device drivers encapsulated in Tango Classes. When a driver for a speci c device is encapsulated in a Tango Class, the majority of the work is already done.
16 | 127
ELI-BL-4400-REP-00000067-2
·
Some other companies, Cosylab, Nexeya, are supporting Tango.
·
The whole European community of Synchrotron is waiting for our decision.
·
With Tango we will join the Tango consortium as ELI ERIC. With EPICS we will
be alone and what about ERIC if we can not decide the others to follow us.
17 | 127
ELI-BL-4400-REP-00000067-2
3.3
CS group general conclusions
The following section constitutes a set of opinions coming from our team. Each subsection corresponds to the opinion of a dierent team member. It is noteworthy that each team member have worked in a speci c topic during the elaboration of this report.
General It can be stated that the most important piece in any development process is the people - the team doing the job. So if in the end it is the team who de nes the quality of the nal output it should be the team who decides how to reach the goal. As a group of software developers, database specialists and hardware programmers, our team expertise is very close to software solutions based on the following modern programing trends:
·
Object Oriented Model.
·
Modern
·
Unit testing.
·
Agile development.
API'S (STL, C++11).
Considering both CS frameworks (especially the architectures, data model and the way they are deployed), it is clear that the
TangoCS
is the ideal solution for us. Now let us
take a look from a dierent point of view: what do we expect from a CS?, what is a CS? If we include in the de nition that it is a software based solution using topnotch programing techniques that covers everything from resources management (lasers), distribution, postprocessing, data analysis, storage and monitoring, again in our opinion the TangoCS oers the best tools for achieving such goal, as it comes with a consistent framework in which everything can be developed using the same programming
API.
For the last couple of months we have been working with both frameworks EPICS and TangoCS without any previous knowledge. In the end both systems are capable of doing what we were expecting, but there was a huge dierence in how to reach the goal. Clearly, EPICS was designed to be used with a set of already supported devices (lot of devices are supported) in situations where some advanced features (data storage, processing, analysis...) are not part of the main CS core (but later added through additional layers). Tango follows a completely dierent approach. It relies on the programing capabilities, so the
CS
engineer must have a programing background, and as a result it oers all the possibilities of the modern programing paradigms.
And the most important is that everything is in
one consistent architecture which uses the same framework. In view of this (group oriented on programing, concept of CS taking care of everything, Tango CS becomes an easy choice.
Data acquisition Taking into account the number of facilities that are successfully using one or another of the herein discussed systems for their reliable day to day operation, it is clear that both are mature enough, thus both can approach the data acquisition task satisfactorily. There exist various solutions for dierent type of buses (Gigabit Ethernet and re-wire are used in this report) and some solutions have also built-in features intended for post-processing data.
The speed is a priority here, and hence further (and deeper)
processing will be done afterwards when the data is safely stored in a long term storage.
18 | 127
ELI-BL-4400-REP-00000067-2
The evaluated EPICS solutions are based on
areaDetector,
a module that provides
a uni ed way how to access the detector data, and should also improve the creation of he new plug-ins and drivers, making it a relatively easy task. Nevertheless the whole process of interconnecting all parts together needs quite a deep knowledge of inner working of the whole EPICS system and has a very steep learning curve. This requires huge amount of searching in the manuals, mail archives and eventually asking the community. For Tango the presence of the
LImA
library greatly simpli es the process of adding
a new camera to the hierarchical model of the facility. Such an uni ed approach makes it possible to operate the cameras via a common control interface. Solutions for dierent buses exist as well as development of new code is much simpli ed thanks to dedicated support tools like POGO. One important (but predictable) experience has been gathered from the evaluation process.
Since for every module exists a number of camera models which are not fully
supported by the particular piece of software, it should be also considered as a parameter for choosing the right device to the speci c task aside from just pure technical parameters and price. Although any problem can usually be solved, sometimes the price is too high or the required time too large. As for a newbie in both systems the Tango system is easy to install, con gure and even start development of new software.
The documentation is in authors experience easier
to nd for Tango system. During various stages was necessary to ask the community in both systems and the feedback is almost immediate for both of them - so the community support is very good in both of them. At the end of the section, the author would like to point out that this short comparison doesn't have the ambition to be comprehensive overview of all features of Tango and EPICS data acquisition possibilities but best eort result of research done in limited amount of time and knowledge.
Archiving
Both frameworks have their own data archiving base concepts and principles,
which are quite similar (time intervals, thresholds). The Tango archiving system allows to
MySQL or Oracle databases while EPICS works with simple data les. It includes Oracle, MySQL or PostgreSQL databases, or even the newly HDF5 format les. Tango by default implement some common GUI's (Mambo,
store the control information in
Bensikin) for operating the archiving system which are used at many facilities.
On the
other hand, the facilities that uses EPICS have implemented their own development, due to the lack of a common tool. Therefore some examples of GUI's:[7], [8] , Masar, etc. The use of common archiving tools in the TangoCS framework is also much easier because the manuals for both options (Mambo and Bensikin) are already nished, and available on the TangoCS public web page ([9]).
Interfaces
GUI's),
From the point of view of the graphical interfaces (
Control System
Studio, designed to work with EPICS, and Taurus, designed for Tango, have both already proven their abilities to be used in large facilities. Both are able to provide status indication, alarm reporting, operator intervention and data storage. The platform independence means that at least Windows and Linux have to be supported. For this point, the use of Java (MEDM and CSS) in EPICS and Java (ATK) or Python (Taurus) in Tango gives them the possibility to interact with dierent platforms.
19 | 127
ELI-BL-4400-REP-00000067-2
It has also to be noted that on one hand tool like Control System Studio initiated by DESY, Deutsches Elektronen-Synchrotron, and improved by CosyLab depends then strongly on the development of a private company. On the other hand Taurus, especially Taurus GUI framework, as part of the SARDANA environment, made an intensive use of the
Qt library which is an open source framework specialized in graphical interfaces, and
hence developed by a large community, assuring a sustainable development. Hence, the use of the Tango package, including SARDANA, which uses CORBA and which takes advantage of the many opportunities oered by a framework dedicated to graphical interface appears as the most coherent.
Further topics
Content of the chapter Further topics can be somewhat controversial.
The reason for this is a complete dierence in philosophy of both
CS frameworks.
The rst one - EPICS is intended for professionals with small programing background that want to con gure CS. In this case the implementation of functionality is hidden from the developer and the system (or environment -
CSS)
takes care of everything but
the device related properties and settings. The user just con gure the CS. The second is looking for.
CS
framework - TANGO on the other hand oers what a programmer
And that means a complete freedom regarding the implementation and
control over the CS execution.
This brings us back to an already discussed question:
who is developing the CS? This facts are also re ected in the amount of documentation provided for both frameworks.
For EPICS a detailed documentation is di cult to nd
while in TANGO all the documentation is quite accessible.
20 | 127
ELI-BL-4400-REP-00000067-2
Part II
Technical analysis
21 | 127
ELI-BL-4400-REP-00000067-2
4
TANGO
4.1
Introduction
This section is devoted to the implementation of a motorized linear slide [10] using the Tango framework. The goals can be enumerated as follows:
·
Create the Tango server associated with the device, which will provide the support for the Tango clients that want to retrieve information from it.
·
Write the Tango device class: this is the piece of code where the device driver will be embedded, and the desired functions for connecting with the device will be written.
·
Implement all necessary features (functions) in order to control the device.
·
Register the device class in the Tango server, in order to make it available from the network.
·
Create a simple Tango client application (
GUI)
which provides basic controls for
handling the device.
Figure 2: Relations between the Tango Class attached to the physical device, the Tango Server in which the Tango Class is registered, and the client program that access to device's functionality.
4.2
Setup description
4.2.1 Hardware development platform The Selected hardware to run the TangoCS is a notebook HP EliteBook 8470p with 8GB ram, the available physical connections are serial ports and The Motorized Linear Slide is:
T-LSR300A
22 | 127
USB
ports (vs. 2.0 and 3.0).
ELI-BL-4400-REP-00000067-2
Provided by the rm Zaber tech. inc, which is embedded with a serial port (the particular communication requirements are described in table 1). This device has a 300mm long rail, a build-in controller, the ability to be chained with other
T-series products using a serial
line, and also a ne pitch lead screw. No other special hardware was used to connect or control this device.
Communications setting
Communications setting
Baud speed
9600
Flow control
No hand shake
Data bits
8
Parity
No
Stop bits
1
Table 1: Connection speci cations for the T-LSR300A
4.2.2 Software and platform In order to focus on testing the Tango system and skip the installation and con guration process we decided to use the Tango Box virtual machine, what is an already pre-installed and con gured Tango Linux system, available for download at the the o cial TangoCS
OS) installed on HP EliteBook 8470p is Windows VMware virtual machine software solution was chosen to run the Tango Box. VMware provides two products to virtualize an OS. Because of snapshots and cloning restrictions of VMware Player we have chosen the WorkStation version, as virtualization servers. The default operating system (
7, therefore a
platform. This con guration comes with Ubuntu Linux and contents the whole set of Tango software packages. In addition, an extra set of preinstalled packages (not related with the project Tango, but necessary for development purposes) is listed in table 2. Before starting the virtual machine the serial port connected to the laptop, has to be bridged to the virtual computer, this can be easily done in the VMware settings. Optionally, the performance of the Tango Box can be improved adjusting the adequate amount of
RAM and the number of dedicated core-processors in the settings.
In this report the preferred development language is C++ along with the standard template Library (
STL), as it is fully supported by the TangoCS and by POGO.
Finally, in order to establish the communication with any place on the serial port (on the virtual machine side) the library
LibSerial
1
is used. In particular, few items must be
accomplished: 1. It is required for the user to have the rights of using the serial port, for this purpose the user should be in the group dialout. The common address is /dev/ttyS*, and it can be checked issuing the command:
1
1
ls -l / dev / ttyS *
available under the terms of the GPLv2 license and down-loadable at [11]
23 | 127
ELI-BL-4400-REP-00000067-2
Installed software (Related to CS our development) GCC 4.5.2
Description
The GNU Compiler Collection
OmniORB 4.1.4
OmniORB is a robust high performance CORBA ORB for C++ and Python
Eclipse
A multi-language Integrated development environment (IDE)
Java 6
A general-purpose, concurrent, class-based, object-oriented computer programming language Table 2: Speci cations of TangoBox
Installed Tango software Description Tango 7.2.6
O cial Tango source code release
AtkPavel
ATKPanel is a generic application which displays panels allowing you to execute any device commands or to read/write any device attributes
Jive
The Tango database browser and device testing tool. Can be used to create Tango servers
POGO
Java based software to create/update Tango device classes in C++ Table 3: Speci cations of TangoBox
2. In order to check if the required
libSerial.so
(/usr/lib/ ) and SerialStream.h (/us-
r/include/) are in the right directories. 3. When a proper communication is established, a set of instructions consisting of 6 bytes can be used to perform I/O operations with the device. For the sake of simplicity only the set of instructions listed in table 4 were implemented. Further description of the
LibSerial library and associated instructions for communi-
cating with the device is beyond the scope of this report, and are available in corresponding web sites [11].
4.3
The Tango device architecture
The three basic concepts of the TangoCS are:
·
Tango class :
a standard
OOP
class which encapsulates the associated functions
(interface) and implements the device control.
24 | 127
ELI-BL-4400-REP-00000067-2
Instruction Description Renumber
Assigns new numbers to all the devices in the order in which they are connected.
Firmware
Retrieves the version of the rmware installed on the device
Home
Moves to the home position and resets the device's internal position
Move Absolute Return Current Position
Moves the device to the speci ed position Returns the current absolute position of the device in microsteps
Table 4: Implemented instructions
·
Tango Device :
the basic entity of the
CS
under the Tango implementation.
consists of an instance of a Tango class (an object in the
OOP
It
terminology), and
provides the associated services of the particular class to any client that wants to inter-operate with it.
It has an interface composed of commands, attributes and
properties.
·
Tango Device server :
a process in which one or more Tango classes are executed.
It must be noticed that the Tango class can implement even a software process, therefore is not limited to the implementation of physical devices, as it may contain, just for instance, a graphical processing algorithm. Besides, a single device server can host several Tango classes, and each class can be instantiated several times. But the programmer should be careful with the sharing of libraries (thread safety) especially third-party libraries with unknown implementation.
4.3.1 Attributes The label attributes correspond to the physical quantities carried by the (Tango) device. Any value intended to be available on the TANGO network is labeled as attribute. For
T-LSR300A) it does make sense to implement a position
example, in the present case (
attribute expressed in micro-steps. The main purpose of an attribute is to replace methods like getters and setters. For
position) contrary
instance, the position is retrieved by reading the associated attribute (
to the most common process of running a command like get_position. The Tango attribute is split in three types: Write, Read, and Read/Write . The attributes have a group of settings called Attribute properties, that can be considered as meta-data for enhancing the semantics and describe the data. used by
They can be
GUI clients for con guring their viewers in the best manner and to display extra
information.
Static meta-data It corresponds with the rst set of Attribute Properties, and describe the kind of data
carried by the Tango Attribute.
The static meta-data includes some properties like the
25 | 127
ELI-BL-4400-REP-00000067-2
name, the type, the dimension, if the attribute is writable or not, etc. This data is hardcoded (de ned for the whole life of the attribute and cannot be modi ed).
Dynamic
The second set of Attribute Properties describes more precisely the meaning of the data and some associated behaviors. They are used by
GUI
viewers for internal con guration
purposes, and can be modi ed at runtime. From a programmer point of view each attribute is an instance of the Attribute class and all mentioned meta-data is hosted in the class itself. Meta-data can be set by the programmer or by con guring the Tango database. The major part of the implementation of the attributes is done by the
POGO,
and only the
methods related to the hardware have to be implemented by the tango programmer. For attribute position of
T-LSR300A linear slide we implemented (detailed description later
in document) these methods table 5.
Attribute method Description read_attr_hardware
A generic method used to read all the attributes. It is not necessary to use this method
read_Position
A method for reading, tight to the attribute position. The command for reading HW properties is called here
write_Position
A method for writing, tight to the attribute position. The command for writing HW properties is called here
Table 5: Implemented methods for "position" attribute
4.3.2 Commands A command is associated with an action. Herein the implemented commands are listed in table 6, though a detailed description is provided later in this document. A TANGO default command contains, optionally, ONE input argument and ONE output argument. The TangoCS commands operate over the following types of data:
·
void, boolean, short, long, long64, oat, double, string, unsigned short, unsigned long, unsigned long64.
· 1D
array of the followings types : char, short, long, long64, oat, double, unsigned
short, unsigned long, unsigned long64, string.
· State: ·
enumeration, representing the dierent states.
Two particular types: longstringarray and doublestringarray. These are structures that contains one array of long/double and one array of string.
It is not possible to add or de ne new types, as this list is xed (for example is not possible to de ne unsigned long64 array). In the same way than the attributes, the command are instances of Command class de ned in tango
namespace.
commands must be implemented .
26 | 127
Notice that all non inherited
ELI-BL-4400-REP-00000067-2
Command Description State
A number that represents the state of the device. Inherited command
Status
A string that describes in plain text the device state and any additional useful information. An inherited command
SetDevLineName
Used to set the DeviceLineName property
ReadDevLineName
Used to read the DeviceLineName property
ReadFromDevice
Command for reading the output of the serial port
WriteToDevice ReadWriteToDevice
Command for writing to the serial port Command for write and read to/from the serial port
Table 6: Implemented commands
4.3.3 Properties By default TangoCS is based on a relational database (
MYSQL) in which the con guration
data for all devices is stored, designated as properties. From this interface a device can be con gured without changing the TANGO class code. An example based on the
T-LSR300A consists in a serial line address that have to be
con gured in order to communicate with the device. For that purpose the DeviceLineName property was implemented, and thus the associated con guration properties can be of the following data types:
·
boolean, short, long, oat, double, unsigned short, unsigned long, string.
·
array of: short, long, oat, double, string.
4.3.4 State A TANGO device has a
state, understood as a nite state machine.
The device state is a
key element in its integration into the control system. Therefore, the programmer have to be careful in the management of the state transitions in the device implementation:
·
It must, at any time, re ect the internal state of the system it represents.
·
It should represent any change made by a client's request. Indeed, the clients will primarily, or only, use this information to determine the internal state of a system.
The the key concept relies upon ensuring a predictable device behavior regarding the state transitions.
27 | 127
ELI-BL-4400-REP-00000067-2
4.4
Design using the POGO glue
POGO is a Java-based TangoCS class generator: all the speci c code needed to connect any
*.cpp source code class, with the TangoCS is automatically generated by this application. Therefore the programmer can focus only in the details concerned with the device implementation. The approach followed by POGO consists in a graphical interface in which the available properties/variables appears as text elds to be lled, as it is shown in gure 3 and table 7 (notice that as expected from the present context the output from POGO is a 2
C++
class).
The process of building a TangoCS class using POGO can be divided into the following steps (that are based on the previous descriptions):
.
·
Class de nition (Class name, inheritances... )
·
Properties de nition
·
Commands de nition
·
Attributes de nition
·
States de nition
. .
.
.
It should be pointed out, that before starting designing Tango class some previous requirements are expected:
·
At the Tango (POGO) level:
To know in advance the expected tasks the device will perform - important for commands.
·
To decide in which states the device can be.
At the hardware (device) level:
Some understanding of the device itself (capabilities, limitations, etc). To be able to control the device on the targeted platform (drivers). To understand the communication protocols for the particular bus from which the device is connected to the computer.
4.4.1 The POGO graphical environment The following set of gures illustrates the POGO environment. Firstly, in main menu for the
T_LSR300A
gure 3
the
project is shown, where all the available properties,
commands, attributes and states are visible. The goal was to test the possibilities, and to evaluate how the TangoCS works. For this reason only one property (DeviceLineName ) representing the address of the serial port in the OS was implemented. In order to read/set the DeviceLineName, the commands: Set(Read)DeviceLineName, were introduced.
2
Since POGO 8.1.0 a Java or Python output is also possible.
28 | 127
ELI-BL-4400-REP-00000067-2
Figure 3: POGO main menu. Full implementation of the
T-LSR300A class
The commands State and Status are inherited from the Tango Device_4Impl class (this is the basic Tango class skeleton that all devices implement) these commands provide info about the current status of the devices. The purpose of ReadFromDev, WriteToDevice and
ReadWriteDevice commands is clear from their names. These commands provide access to physical device.
Then, only a single attribute (Position ) is implemented, along with
several states (ON, OFF, MOVING, FAULT, INIT ). This attribute represents the basic knowledge about the
T-LSR300A
device - its position. Selected statuses were selected
to cover all possible states the device can gain. Before creating a new class, some speci c informations have to be entered (selected), for details see gure 4.
Figure 4: Class de nition options
29 | 127
ELI-BL-4400-REP-00000067-2
When the class is ready you can insert all the desired commands, attributes and states by performing a right-click on each sub-folder and selecting add command. For example, on the
gure 5
there is a form that allows to create a new command.
Figure 5: Creation of a command
In order to create all the Tango related les, the user has to click the generate command of POGO environment. This process is shown on
gure 6, where several options of what
to generate are possible:
·
Project *.xmi (POGO uses the *.xmi format to save/load projects).
·
Source code les (*.cpp,*.h) - the code architecture is described in the next chapter.
·
Documentation.
·
Speci c les for Linux (Make le) and Windows (Visual Studio project).
POGO is capable to reload and modify an existing project by using the Re-Load Project function in the File menu. Inside POGO, the generated source code are code blocs marked as PROTECTED REGION (see Listing 1) this regions are intended for the programmer's code and will not be modify/remove by the POGO reload/generate function. This means that if some changes to the Tango class are required, then the already implemented code will not be lost, when the new attributes/commands/properties will be added (generated).
30 | 127
ELI-BL-4400-REP-00000067-2
Figure 6: Output generation
Listing 1: Protected regions of a source code 1
Tango : : DevLong T_LSR300A
2
{
3 4 5 6
/
::
read_from_dev ( )
Tango : : DevLong argout ; DEBUG_STREAM
