-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathmanual.doxy
169 lines (127 loc) · 8.82 KB
/
manual.doxy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
/*!
\mainpage
\li \subpage umanual
\li \subpage lofmod
\li \subpage lofplug
*******************************************************************************
\page lofmod List of Modules
\section ifmod Interface Modules
\li \ref sis3100if
\li \ref sis3150if
\section daqmod Data Acquisition Modules
\li \ref caen775mod
\li \ref caen785mod
\li \ref caen792mod
\li \ref caen820mod
\li \ref caen1290mod
\li \ref sis3350mod
*******************************************************************************
\page lofplug List of Plugins
\section cacheplgs Cache Plugins
\li \ref cachehistogramplg
\li \ref cachesignalplg
\section dspplgs Signal Processing Plugins
\li \ref dspadcplg
\li \ref dspcalfilterplg
\li \ref dspcfdplg
\li \ref dspclippingdetectorplg
\li \ref dspcoincplg
\section packplgs Data Packing Plugins
\section visplg Visualization Plugins
\section outplgs Data Output Plugins
\section auxplg Auxiliary Plugins
\li \ref fanoutplg
\li \ref inttodoubleplg
*******************************************************************************
\page umanual GECKO User's Manual
\section overv Overview
GECKO (Generic Experiment Control Kit with Online analysis) is a modular platform for data acquisition.
Its modularity allows for easy adaption of the data acquisition process and post-processing of the gathered data to new experimental setups.
\dot
digraph {
dev [shape=component, label="DAQ\nDevices"];
intf [shape=oval, label="Interfaces"];
daq [shape=oval, label="DAQ\nModules"];
plg [shape=oval, label="Plugins"];
core [shape=box, label="GECKO Core", rank=0];
dev -> daq -> plg [style="dashed"];
intf -> dev;
daq -> intf;
core -> intf;
core -> daq;
core -> plg;
}
\enddot
GECKO consists of an application core, acquisition modules and post-processing plugins.
The core provides the necessary facilities for configuring an acquisition setup and for starting and controlling runs.
Modules are the only means of getting data into GECKO.
They are comprised of interface and DAQ modules.
Interface modules provide a path of communication between DAQ modules and the physical data acquisition devices.
DAQ modules gather data from these devices and process (decode) it so it can be passed on to the post-processing stage.
This stage consists of a tree of plugins without any loops.
Currently there are plugins for signal processing (eg. pileup correction, discrimination), data analysis (eg. histogram building) and for saving the generated information to a file.
The GECKO main window is divided into two parts:
\image html geckomain.png "The GECKO main window"
\image latex geckomain.png "The GECKO main window" width=.6\textwidth
On the left-hand side a tree view containing all interfaces, modules and plugins of the current configuration is shown.
In addition to that there are two entries in the tree view for controlling the execution of acquisition runs.
The right-hand side contains information about the currently selected item from the tree view, eg. if a plugin is selected in the tree view the right hand side will contain a panel with the plugin's connectors and information about which plugin they are connected to alongside a panel for configuring the plugin itself.
GECKO organizes data collected during runs and auxiliary run data into folders.
These folders reside in a user-defined directory (default is \c /tmp) and are named like the run.
When starting a run GECKO creates the run folder and a start file containing the time and date of the run start along with some other information and a user-supplied comment.
Data collected during a run will be placed in files inside the run directory, their names are configurable from the configuration panel of the plugin that creates them.
An end file is created after a run ended, containing the time of the run end and the number of processed events.
\section nconf Creating a new configuration
A GECKO configuration is built layer-wise from input to output:
\li Define interface modules
\li Create DAQ modules
\li Create plugins
At least one interface module has to be defined before any DAQ modules may be added because it is impossible to create a DAQ module that is not associated with an interface (this association may be changed later).
All interface and daq modules can be created by using the corresponding menu bar item or by right-clicking onto the respective category item inside the tree view and selecting "Add Module...".
\image html add_dropdown.png "The context menu for adding modules and plugins"
\image latex add_dropdown.png "The context menu for adding modules and plugins"
This brings up a dialog where the type of the module to be created can be selected.
The module also has to be uniquely named and, for DAQ modules, assigned a VME base address and an interface over which the corresponding VME module is accessible.
\image html add_module.png "The Add Module dialog"
\image latex add_module.png "The Add Module dialog"
Plugins may be added using a similar procedure: using the "Plugin" menu or right-clicking on the "Plugins" item and selecting "Add Plugin..." will bring up a dialog similar to the one used for adding modules.
A unique name has to be assigned to each plugin an a drop-down menu lists all available plugin types.
There is a box at the bottom of the dialog where additional options may be set for some plugins.
The values entered can not be changed later on, only by destroying and recreating the plugin.
All the plugins and DAQ modules can be connected to form a (possibly multiply-rooted) tree through which data flows from the roots to the leaves.
Every plugin features two lists of its input and output connectors at the top of its configuration page:
\image html plugin_conn.png "Plugin connector panel"
\image latex plugin_conn.png "Plugin connector panel"
Each line is comprised of the connector name followed by the plugin/daq module and connector it is connected to (or \c \<none\> if it is unconnected).
Right-clicking on an item brings up a list of compatible counterparts, sorted by plugin/daq module name.
Each connector accepts only a single data type (\c uint32 and \c double at the moment) and can only be connected to another connector that produces the same data type.
\note A double-click on any connected connector jumps to the connected plugin.
There are two important auxiliary plugins for creating plugin trees: \c fanout and \c int-\>double.
\c fanout takes in an arbitrary signal and outputs a given number of copies of it, each on one connector.
\c int-\>double provides explicit type conversion from uint32 to double, eg. to directly feed raw data to a histogram builder.
\attention Special care must be taken not to create any loops in the plugin graph or GECKO may lock up. At the moment there is some rudimentary loop checking done, but it is not certain that all types of loops are correctly recognised.
After building the plugin graph the DAQ modules and plugins must be configured. Documentation for the configuration pages is accessible via the \ref lofmod and the \ref lofplug respectively.
\section srun Starting a run
After the configuration is built a run may be started.
\attention The configuration should be saved before starting a run in case anything unexpected happens.
First, a trigger setup has to be created. The trigger setup defines the DAQ module connectors that should contain data before data may flow into the plugin tree.
It also defines which DAQ modules trigger an acquisition cycle when signalling data available.
The trigger setup is done via the "Run Setup" panel:
\image html run_setup.png "The Run Setup panel"
\image latex run_setup.png "The Run Setup panel"
The box at the top contains a list of all DAQ modules with checkboxes in front.
If, during a run, any of the checked modules signal that data is available, an acquisition cycle commences and data is collected from all DAQ modules.
A data available signal from an unchecked module is simply ignored.
The second box controls the start of a post-processing cycle.
It contains a list of all DAQ module connectors.
All of the checked connectors must contain data for a post-processing round to start.
At the bottom of the panel, the user may decide whether or not to run in single event mode.
In single event mode only the first event is collected from the DAQ modules, any remaining events are discarded.
This allows for better synchronicity between different DAQ modules by not allowing different modules to have different amounts of events recorded.
Now, a run may be started from the "Run Control" panel:
\image html run_control.png "The Run Control panel"
\image latex run_control.png "The Run Control panel"
This panel contains the location where the runs will be stored, the name of the current run and a comment field that is stored in the run start file.
During a run useful information like the start time and the current number of events processed are shown.
The Start/Stop button is situated at the bottom right.
*/