Network Distributed Data Acquisition, Storage, and ...shown connected to the BOOSTER and Proton...
Transcript of Network Distributed Data Acquisition, Storage, and ...shown connected to the BOOSTER and Proton...
CER
N-O
PEN
-201
5-00
504
/08/
2014
Hochschule RheinMain
University of Applied Sciences
Wiesbaden Rüsselsheim
Faculty of Design, Computer Science and Media
Computer Science (M.Sc.)
Master Project Documentation
Network Distributed Data Acquisition,
Storage, and Graphical Live Display Software
for a Laser Ion Source at CERN
Ralf Erik Rossel
August 2014
Supervisor: Prof. Dr. D. Richter (HSRM)
Local Supervisor: Dr. S. Rothe (CERN)
Abstract
This project documentation outlines the requirements and implementation details for the
measurement data recording software currently in development for the Resonance Ionisation
Laser Ion Source (RILIS) at CERN. The software is capable of acquiring data from multiple
laser parameter monitoring devices and associating the gathered values to represent qualitative
and quantitative measurements. The measurement data is displayed graphically within the
program and recorded to files for later analysis. The main application of the software is the
acquisition coordination and recording of measurement data during spectroscopy experiments
performed by RILIS and collaborating experiments. This document describes the design
concept and detailed program implementation status at the end of July 2014 and provides an
outlook to future developments in RILIS spectroscopy data acquisition.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 1 of 26
Table of Contents
1. Introduction ........................................................................................................................ 2
1.1 Experiment Overview: CERN - ISOLDE - RILIS ...................................................... 2
1.2 Motivation for developing a RILIS data recorder ....................................................... 3
1.3 Existing laboratory infrastructure ................................................................................ 4
1.4 Software development environment ............................................................................ 6
2. Requirements Analysis ...................................................................................................... 7
2.1 Live data display ......................................................................................................... 7
2.2 Value association ......................................................................................................... 8
2.3 Data storage ................................................................................................................. 9
3. Application Design and Implementation ......................................................................... 11
3.1 Interface to data sources ............................................................................................ 11
3.2 Fundamental programming concepts ........................................................................ 11
3.3 Implementation design pattern .................................................................................. 13
3.3.1 Data acquisition loop ......................................................................................... 14
3.3.2 Graphical user interface loop ............................................................................. 16
3.3.3 Timing loop ........................................................................................................ 17
3.3.4 Processing loop .................................................................................................. 17
3.3.5 Display loop ....................................................................................................... 20
3.3.6 Logging loops .................................................................................................... 21
3.4 Prototype development .............................................................................................. 23
4. Future Developments and Outlook .................................................................................. 25
5. References ........................................................................................................................ 26
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 2 of 26
1. Introduction
1.1 Experiment Overview: CERN - ISOLDE - RILIS
The CERN accelerator complex shown in Figure 1 consists of many different facilities
dedicated to specific fields of fundamental nuclear research. The Isotope Separator On-Line
DEtector (ISOLDE) [1] user facility is dedicated mainly to the production of ion beams of rare,
short lived radioactive elements and the study of their fundamental properties. ISOLDE is
connected directly to the Booster building. The Protons received from there impinge on a target
material and produce a multitude of different elements through fragmentation, fission, and
spallation. [2]
Figure 1 - Schematic view of the CERN accelerator complex. [3] [4] The ISOLDE facility is highlighted and
shown connected to the BOOSTER and Proton Synchrotron link.
The Resonance Ionisation Laser Ion Source (RILIS) within ISOLDE is a specialized setup
which complements the magnetic separation of isotopes of interest with selective excitation of
specific elements to increase the overall selectivity of the requested ion beam. The working
principle of RILIS, illustrated in Figure 2, is based on stepwise excitation of the outermost
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 3 of 26
electron of the element of interest. Up to four laser beams have to be overlapped in time and
space while kept precisely tuned to isotope specific wavelengths and at optimal power.
Figure 2 - RILIS principle illustration. The stepwise excitation and detachment of the outermost electron is
performed by precisely tuned overlapping laser beams.
1.2 Motivation for developing a RILIS data recorder
Apart from providing beams for user experiments, RILIS is also conducting in-source
spectroscopy work, laser ionization scheme development, and reference measurements to
develop and improve future ionization setups. Several dedicated spectroscopy measurements
are also performed in conjunction with other experiments which can serve both as data sources
and as recipients for RILIS operation data.
The operation of RILIS requires constant monitoring and control of a multitude of different
hardware devices. The main laser parameters to be monitored are the wavelengths, power
levels, beam positions, and the timing. In addition to these values, a set of auxiliary parameters
such as temperatures, flow rates and air quality levels are monitored to ensure safe operation.
Additional information about the overall device control concept is given in [5]. The need for
extensive monitoring and control capabilities led to the development of a distributed data
acquisition infrastructure for RILIS. The data recorder will make use of the existing
infrastructure and enable RILIS operators to extract, display and store data from a subset of
crucial devices during set-up or when performing laser scans. These laser scans are both used
as a reference in standard operation to confirm optimal power levels and correct tuning to the
required electron excitation wavelength as well as in in-source spectroscopy and scheme
development applications to scan for relations of the resulting ion signal to the current laser
tuning wavelength.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 4 of 26
1.3 Existing laboratory infrastructure
The hardware setup of RILIS consisting of network distributed asynchronous data sources
requires a similarly structured software design approach to allow for rapid integration of new
devices and to quickly exchange data sources. To deal with the diversity of required
communication protocols and the necessity of running proprietary device driver software
supplied by the manufacturers, a major concept is the development of a specific read-out driver
for each device. This driver exposes data obtained from the device via a common interface,
namely network shared variables. These variables act as an asynchronously running data source
which can be exchanged or modified on demand. This concept also allows for independent
implementation of different devices by either RILIS operators or external developers.
The current requirement scope of the RILIS data recorder project comprises the acquisition of
wavemeter data, ion beam intensity data, and power data during the course of a measurement
session. An important aspect of the measurement setup is that the data sources are running
asynchronously and in some cases, such as the wavemeter, may not generate data at regular
time intervals due to differing exposure or integration times. This has to be taken into account
during data acquisition and value association. A conceptual illustration of the modular network
distributed data sources is given in Figure 3. Devices pictured on the left run asynchronously
and produce measurement data. Some devices can be accessed directly while others may
require a proprietary driver software running or a middleware to extract data. This readout is
performed by dedicated LabVIEW programs which publish the values to network shared
variables. These variables act as an interface to the RILIS data recorder software where the
user can select the sources to be displayed. The relevant properties of the data sources used are
listed in Table 1.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 5 of 26
Figure 3 - Conceptual illustration of the device communication layout used for RILIS.
Table 1 – List of device properties relevant for the current scope of the data recorder project.
Device Parameter Sample Rate Channels Units Limits Protocol
Wavemeter
HighFinesse
WS6
Wavenumber 10 to 1000 ms 4 cm-1 10000 to
20000
.dll library
Wavemeter
HighFinesse
WS7
Wavenumber 10 to 1000 ms 8 cm-1 10000 to
20000
.dll library
ISOLDE
Faraday Cups
Ion beam
current
400 to 800 ms 1 Ampere 10-16 to 10-3 RADE,
JAPC, …
Powermeter
Gentec TPM300
Power 250 ms 1 Watt 0 to 100 RS232
Multi-
Powermeter
Optometer
P-9801
Power 100 ms 8 Watt 0 to 0.5 GPIB
ProprietaryDriver
Software
LabVIEW Readout Program
CERNMiddleware
LabVIEW Readout Program
LabVIEW Readout Program
USB .dll
RS 232
Network Shared
Variables
Data Recorder
Graphical User
Interface
AcquisitionProcessing
DisplayStorage
Network Shared
Variables
Network Shared
Variables
Devices Protocols, Libraries, and Drivers Interface Application
WavemetersLaser Wavelength (nm)
Rate: 10 to 1000 ms
PowermetersLaser Power (W)
Rate: 250 ms
Faraday CupIon Beam Current (pA)
Rate: 400 to 800 ms
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 6 of 26
1.4 Software development environment
The integrated development environment (IDE) National Instruments (NI) LabVIEW is chosen
as a readily available and widely used CERN standard software which enables its users to
quickly add new features and develop elementary GUI applications on demand [6]. A broad
range of driver libraries and data acquisition modules are provided, as well as a CERN-
developed framework aimed at rapid development of data acquisition software. LabVIEW is a
graphical, high level programming language. Programs are called Virtual Instruments (VIs)
and consist of a front panel, resembling the graphical user interface, and a block diagram,
resembling the graphical source code. Major concepts are the flow of data through colour coded
virtual wires and inherent parallel execution of independent portions of code. Figure 4 shows
a small example VI for adding and subtracting two numbers to illustrate these concepts. In the
front panel on the left, the graphical input controls and output indicators are visible. They are
represented by corresponding block diagram icons on the right. Graphical data flow is
represented by virtual wires, connecting to the ‘add’ and ‘subtract’ function nodes which can
run in parallel. Extensive additional information about LabVIEW concepts can be found in [7].
Figure 4 – Example VI front panel and block diagram for performing an addition and subtraction of two numbers.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 7 of 26
2. Requirements Analysis
2.1 Live data display
The RILIS data recorder should allow for displaying incoming shared variable data versus time.
This allows the assessment of the data quality prior to performing a specific measurement or
laser scan.
Due to the different acquisition rates of the measurement devices, noise levels and possible
drift detection and correction in post analysis, it is a requirement to include the possibility to
calculate the average and the standard deviation of the incoming signals. This calculation has
to be performed under the following ‘trigger’ modes:
- Manual start/stop – When the operator presses a button, the individual incoming
values from the data sources are averaged. Pressing the button again disengages the
averaging process and signals the software to write the averaged data to a file. This
then represents one user-defined measurement.
- Average over n samples – The operator can select one of the data sources to act as
a trigger signal. All other sources are averaged individually until this trigger value
is registered n times. Usually, the slowest data source should be chosen as the
trigger. This serves as a synchronization mechanism to asynchronous values. A
typical use case is the averaging of several wavelength values incoming at a rate of
typically 50 ms while waiting for a Faraday cup reading every 400 ms
- Timer window – The averaging process is controlled by an operator-definable
auto-resetting Timer. When the operator presses a latching button, the averaging
process and the timer is started. Once the set time is elapsed, the current averaged
values are written to a measurement file, the timer is reset to the target time and the
process starts over again until the operator unlatches the button.
Figure 5 shows a sketch view of the intended graphical live display to illustrate the
measurement process. The user can select one of the data sources to act as a trigger signal
according to the modes described above. When a ‘start trigger’ is registered, the incoming
values of each channel are accumulated, calculating the moving average with each new value.
These results are also displayed live on their corresponding plots during the run-time of the
program. This process continues until a ‘stop trigger’ is registered. The most recent average
values are then marked on the corresponding plots to indicate the measurement value which is
simultaneously recorded into a file. The timestamp is taken from the machine where the data
recorder is running.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 8 of 26
Figure 5 - Sketch view of the graphical live display. Three colour coded data source plots are visible. At a start
trigger depending on the chosen operation mode, the averaging process is initiated and visualized on the
corresponding plot in a lighter colour. When a stop trigger is registered, the recorded values are marked on the
plot and written to a file.
2.2 Value association
The main requirement for the RILIS data recorder is the association of data points and to
display them live in an XY graph. A typical use case is the display of ion beam current
information obtained from an ISOLDE Faraday Cup versus the wavemeter data during a
defined measurement period. Since the data sources run asynchronously and at a different
sample rate, the averaging process described previously is used to perform the value association
necessary for generating the measurement plot. A sketch of this graph is given in Figure 6. The
user is able to select which input signal to display on the horizontal and the vertical axes. The
resulting averages of the associated values are displayed as round dots. Depending on the
trigger mode, if more than one value contributed to the average, the error bars represent the
recorded standard deviation of the measurement.
From previous experiences the ability to display a scan history of previously recorded data has
proven to be useful. The software should be able to display this history data for the current
session and the user should be able to clear both the current data and the history data
individually and independently.
Wavelength (nm)from Wavemeter
(X value)
Ion Beam Current (pA)from Faraday Cup
(Y value)
Laser Power (W)from Powermeter
(scaling reference)
Start Trigger Stop Trigger
Time (s)
Time (s)
Time (s)
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 9 of 26
Figure 6 - Associated data display on an XY graph. During setup of the laser system for a specific element or
when performing in-source spectroscopy, the tuneable lasers are scanned over a certain wavelength range to
confirm or revise the excitation wavenumber value given in literature. This graph allows for an estimation of the
signal relation during run-time.
2.3 Data storage
At run-time a folder structure is created to store relevant data for the current measurement. The
folder name should contain a human-readable timestamp prefix and a user-definable session
info text. All incoming values should be saved to a raw acquisition file as ‘comma separated
values’ (.csv) of which an excerpt is shown in Table 2. Due to the asynchronous data inputs,
the time-association of the values can only be performed when all input values have been
registered. An averaging file is generated to store only the processed data according to the
averaging method applied.
The operator should be able to press a button to generate a screen shot of the current graph
view which is saved to the measurement session folder.
An .ini file should hold any configuration data required to run the program such as input
variable configuration. This file could then be loaded at a later time to perform a comparative
measurement.
An operation logbook text file is to be generated to save any noteworthy events that have
occurred during the session. This logbook file holds both text typed by the operator as well as
system status string outputs.
Ion
Bea
m C
urr
ent
(pA
)
Wavelength (nm)
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 10 of 26
The folder and file structure could be similar to the following outline:
Laser Scan Recorder (root folder)
<YYYY-MM-DD HH.mm.ss.uuu> – Session Info (session folder)
Raw Values.csv
Average Values.csv
Screenshots (screenshot folder)
Time Graph<nnn>.jpg
XY Graph<nnn>.jpg
Configuration Data (configuration folder)
SV inputs.ini
Program Settings.ini
Table 2 - Example structure of a measurement file in .csv format, containing averaged data. The first column
contains a measurement number count. The second column holds the timestamp values at which the line was
written to the disk. The next three columns contain the average, the standard deviation, and the number of samples
from which the values were calculated. These three columns are repeated accordingly for each of the selected
input signals.
Count Write
Timestamp
Wavenumber
Average
Wavenumber
Std.Deviation
Wavenumber
Samples
Ion Beam Current
Average
…
1 2014-06-12 11235.4342 0.0233 27 1.256e-12 …
… … … … … … …
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 11 of 26
3. Application Design and Implementation
3.1 Interface to data sources
To cope with the diversity of different hardware instruments and to ensure a modular
configuration, individual LabVIEW read-out programs for each instrument class were
implemented. This software architecture design decision required the creation of several
LabVIEW projects, which can be designed, implemented and tested according to the
requirements for each device. A necessity resulting from this concept is that all individual read-
out programs have to be started prior to launching the data recorder application. The advantage
of this distributed approach is the ability to exchange data sources without large modifications
in the code for the data recording software but rather changing the path of the data source.
Certain devices such as wavemeters will require a fair amount of processing power and are
recommended to run on a computer dedicated to handling this task. Thus the RILIS computer
infrastructure consists of several machines to balance the processing load and to enable
independent operation where required.
As a common interface for data transfer between the different read-out programs and other
applications, network shared variables (SV) are used. A network shared variable acts as a First
In - First Out (FIFO) buffered container that can hold any of the data types provided by
LabVIEW [8]. This enables the programmer to develop and run different programs as modules
of a distributed application using the SVs as a method to exchange data over the network. In
the use case for RILIS, each read-out program defines its own set of shared variables to publish
the measurement values obtained from the corresponding device. Other programs can then
connect to these variables and further process the data. This concept resembles a client-server
architecture comprised of publisher and subscriber programs and allows for flexible adaptation
to changing needs of the RILIS laboratory infrastructure.
3.2 Fundamental programming concepts
LabVIEW VIs use comparable structures and fundamental data type constructions as textual
programming languages do. However, most of these concepts are represented graphically
within the block diagram. The following selection outlines some of the most common
programming concepts and composite structures available in LabVIEW and depicts a
comparison to a textual programming language analogy where applicable.
- While loop – A while loop executes any code placed inside until a stop condition
is met. Data can be propagated between loop iterations by using shift register
terminals. The textual analogy would be a do-while loop with local variables for
data storage.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 12 of 26
- Case structure – A case structure allows for selection of different portions of
source code placed inside according to an input selector terminal. The textual
analogy would be a switch-case structure where a variable acts as the input selector.
- State machine – A combination of the two basic structures mentioned above can
be used to implement a state machine. Here, a case structure is placed inside a while
loop. The input selector of the case structure determines the next state to be
executed. This state selector variable can be a string or an enumerated data type
which is propagated through each loop iteration by a shift register.
- Event structure – An event structure is capable of reacting to specific events
throughout program execution. Most of these events are preconfigured to originate
from the front panel as the graphical user interface of the VI. However, dedicated
events can also be defined by the programmer to allow for event based program
flow control. This concept could be compared to interrupt handling routines in other
programming languages.
- Queue – A queue is a First In – First Out (FIFO) buffered memory area that can act
as a mechanism to transport data within an application instance [9]. When a queue
is obtained within a LabVIEW program, a reference to this memory segment can
be passed to different sections of the code which then can perform read or write
operations. A comparison to other programming languages could be shared memory
operations, whereas LabVIEW queues already represent a defined access control
mechanism through enqueue and dequeue nodes.
- Functional Global Variable (FGV) – A FGV is a VI which stays in memory
during the run-time of the application and uses the same basic structure as the state
machine concept described above. However, there are the following differences:
The while loop is only executed for one iteration at a time, so only a specific
function is performed on each call. The shift registers of the while loop are not
initialized when the code segment is executed, which allows the FGV to store data
that can then be accessed at a later time. A common use case for a FGV is to store
program data and settings in a globally accessible memory location. Access control
to avoid race conditions is provided through specific calling conventions named
‘non-reentrant execution’. More details on this concept can be found in [10].
- Clusters – A LabVIEW cluster data type is a collection or ‘bundle’ of data which
can generally be composed of different data types. The textual equivalence would
for example be a ‘struct’ in the C/C++ programming language.
- Classes and Objects – A LabVIEW class represents an encapsulated cluster type
definition. Associated subVIs are used as methods to act upon the enclosed member
data. An object is the instantiation of such a class. This concept comparable to
similar constructions in object oriented textual languages
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 13 of 26
3.3 Implementation design pattern
With the goal to develop a flexible and extendable program, the RILIS data recorder is based
on the LabVIEW design pattern of a Queued Message Handler (QMH). This design pattern is
an extension of the producer-consumer pattern in which data is produced by an independently
running loop, then sent via a message queue to a consumer loop which can handle the incoming
data at its own pace. This is beneficial for example in decoupling relatively fast and regular
data acquisition from slower disk operations. The QMH design pattern extends this concept by
introducing a dedicated message handling loop which acts as a coordinator and dispatcher for
program flow control messages. This allows to further modularize the tasks to be performed
by the software and extend the implementation to perform additional functionality at a later
time.
The implementation of the RILIS data recorder uses seven loops running in parallel, each
performing a dedicated role within the application. Figure 7 illustrates an overview of this
design. Seven loops are running in parallel, each performing a dedicated task within the
software. The loops communicate via control events and data messages. The individual loop
functions are described in more detail in the following subsections.
Figure 7 - Queued Message Handler design pattern used for the RILIS data recorder.
TIMERGUI
DISPLAY
LOGGINGPROCESSDAQ
CONTROL
CONTROL
DATACONTROL
DATA
CONTROLDATA
2x (live & averages)
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 14 of 26
3.3.1 Data acquisition loop
The Data Acquisition (DAQ) loop makes use of the LabVIEW Data logging and Supervisory
Control (DSC) module. This module provides additional subVIs which allow to register for
network shared variable change event notifications. Whenever a value of a selected shared
variable is changed by a remote host computer, this event is registered programmatically by a
LabVIEW event structure. Here, the newly received value is extracted from the control event
data and indexed to identify the shared variable source. The dataset thus created is then sent
via a data message queue to the processing loop to collect the data and to evaluate the program
flow accordingly. Figure 8 shows the source code of the data acquisition loop. The data flow
is described from left to right: On the left side the input terminals of the subVI are visible. They
transport references to the message queues, shared variables used, error inputs, and a stop event
into the loop to be accessed during program flow. In the next steps, the shared variable change
notifications are enabled and requested for the specified input array. The resulting reference is
registered along with the stop event so that the event structure within the loop can react on
these events. Once a shared variable change event is registered within the loop, the value of the
shared variable is extracted, combined with its corresponding index from the shared variable
input array and the timestamp when the change was registered. This data cluster is then sent to
the processing loop, after the initial set of shared variables which were registered during start-
up have been ignored. When a stop event is registered, the event structure will stop the loop
(not pictured) and then proceed to close the event reference, cancel and disable the shared
variable change notifications.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 15 of 26
Fig
ure
8 -
So
urc
e co
de
of
the
data
acq
uis
itio
n l
oo
p.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 16 of 26
3.3.2 Graphical user interface loop
The Graphical User Interface (GUI) loop handles input actions performed by the user such as
pressing buttons and changing settings. This task is performed well by an event structure, as
each control from the front panel can be specified as an event source. If no input is registered,
the corresponding program thread will lay dormant and not consume any CPU resources. The
following events and user inputs are handled:
- Clear Averages – Sends a message to the display loop to clear the associated
averages, displayed in blue, on the XY Graph.
- Clear History – Sends a message to the display loop to clear the associated
history averages, displayed in grey, on the XY Graph.
- Reset Time Graph – Sends a message to the display loop to clear the graphical
live display.
- Horizontal Axis Selection – Writes the current selection index of which value to
display on the horizontal axis of the XY graph to the functional global settings
variable and sets the name of the axis appropriately.
- Vertical Axis Selection – Writes the current selection index which value to
display on the vertical axis of the XY graph to the functional global settings
variable and sets the name of the axis appropriately.
- Manual Start/Stop - Depending on the selected averaging mode and the
associated button input state (TRUE/FALSE), this event sends a message to the
processing queue to log the currently accumulated averages (manual mode) or
sends a message to both the processing and timer loops to start the (timed)
averaging process.
- Open Log Folder – Executes the windows operating system command
‘explorer.exe’ to open the folder where the current session data is stored.
- Timer Event Data – Registers and processes the control event that the timer has
elapsed and sends a message to the processing loop to log the currently
accumulated averages.
- Stop – Sends a message to the processing loop when the user has clicked the stop
button, which will then be propagated to all other loops from there.
- Averaging Trigger Signal – Writes the averaging signal source index selected by
the user to the functional global settings variable.
- Averaging Trigger Count – Writes the number how often the selected trigger
signal should occur to the functional global settings variable.
- Averaging Mode – Writes the selected averaging mode to the functional global
settings variable and sends a message to the processing loop to reset the
accumulated data.
- Timer Target Value Change – Writes an updated value for the timer to the
functional global settings variable and sends a message to the timer loop to reset
the timer to the new value.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 17 of 26
3.3.3 Timing loop
Since all loops present in the program rely on either data messages or control events for
execution, they will wait and release the CPU for other processes to execute if no messages are
received. This wait time is generally arbitrary and depends on whether shared variable change
events are received or user input is registered. Thus, to perform timing operations, a decoupled,
dedicated timing loop was implemented, which sends a specific wait message to itself in order
to execute at given time intervals. The source code is shown in Figure 9. In the pictured case,
the current time is compared to the set time target and a corresponding timer control event is
sent to notify other event loops of the current timer value and status. If the time has not elapsed,
a message is sent to the own timing queue to wait for a certain amount of time until the next
status check takes place. If the time has elapsed, the timer will reset itself to start a new timing
cycle. The basis for this implementation is a queue based state machine similar to a state
machine described in subsection 3.2. It consists of a while loop and an enclosed case structure.
Instead of a pre-programmed state order, the execution order can be influenced by either a
queue message from outside the loop, or by internally sending a message to the next iteration,
determining the next state to be executed.
Figure 9 - Timer loop source code with “Check Status” case displayed.
3.3.4 Processing loop
The processing loop takes the role of the central message handler and dispatcher. All acquired
data is received and collected at this point by making use of LabVIEW object oriented
programming: An array of collector class object instances is created prior to entering this loop.
The array size corresponds to the number of selected shared variable signals to be monitored.
These collector objects consist of a cluster representing member data or ‘fields’ and a set of
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 18 of 26
subVIs which represent methods capable of performing data manipulation and data access
within the object instances. An overview of the collector class structure used within the RILIS
data recorder is given in Figure 10. As an exemplary method subVI, the ‘Calculate Average.vi’
source code is pictured in Figure 11. The collector member data input and the error cluster
input is shown on the left. In the „No Error“ case, the array of collected values is accessed and
used as an input to the existing math library function to calculate the average, standard
deviation and variance from the complete input value array. The results are both saved as a
current value by a bundle operation on the left as well as collected within a corresponding array
by the subsequent method call „Add Element to Collected AVGs and SDEVs.vi“. No operation
is performed in an error case. The main advantage of this object oriented concept is that as
many collector objects can be instantiated as needed according to the size of the shared variable
input array. This allows for recording as many additional channels as needed for a specific use
case. The use of subVI methods for the collector objects encapsulates and modularizes code
that can be called for each object instance individually. Thus the averaging calculation and data
recording is performed by the object itself rather than by a central program routine.
Figure 10 - Collector class structure. The file ‘Collector.ctl’ holds a description of the member data or ‘fields’.
The five subVIs represent different methods to operate on the member data.
Figure 11 – ‘Calculate Average.vi’ method subVI of the collector class.
The processing loop also makes use of the queue message based state machine in order to allow
for flexible arrangement of processing steps according to the commands sent by other loops.
Figure 12 illustrates the flow diagram of the implemented state machine. Program execution is
suspended at the START node, which is represented as a ‘dequeue message’ node within the
source code. As soon as a message is received, the next state to execute is chosen according to
the contained message string. Several partly overlapping branches can be executed:
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 19 of 26
If a stop message is received, this message
will be propagated further to the display
and logging loops, signalling them to
execute their own stop state and
performing any clean-up routines
necessary such as flushing remaining data
to disk. If a “New Data” message is
received, the data is first collected and sent
to the live logging loop. Then the display
is immediately updated and the next state
is evaluated according to the selected
averaging method. In ‘manual mode’, the
processing loop returns to the start
position, as in this case the message to log
averages will be sent by the GUI loop. In
the case of the ‘Average over n samples’
averaging method, the currently collected
signal states are evaluated in the “Check
Trigger” case. If the appropriate conditions
are met, the processing loop will send a
“Log Averages” message to the logging
loop, and reset the collector array to clear
the values for the next acquisition cycle.
This method of dynamically scheduled
execution states allows for both
modularization of the code to enhance the
readability and maintainability as well as
for easier integration of new processing
features such as reacting to different
trigger signals or other forms of signal
conditioning prior to storing data to the
disk.
Figure 12 – State machine flow diagram of the
processing loop. Multiple partly overlapping
branches can be executed according to messages
received either by other sections of the application,
such as the GUI or timing loops. If a stop message
is received, the processing loop will propagate this
message to the display and logging loops and then
stopping its own while loop.
New Data
Retrieve incoming data from queuePut data into corresponding collector instances.Message to self: "Update Display"Payload: Changed signal indexMessage to live data logging loop: "New Data"Payload: Live data collector array
Update Display
Retrieve incoming data from queueMessage to display loop: "New Data"Payload: Average data collector array and indexMessage to self: "Evaluate Averaging", No Payload
Evaluate Averaging
Read averaging mode from seetings functional global varaiableEvaluate next state accordingly and send corresponding message to self, no payload.
Evaluate Averaging
Check Trigger
Read trigger signal conditions from FGV:- Is signal change index within array range?- Has the set trigger count been reached?- Do all associable average values exist?
Case Manual start/stop => Wait for next message
Case Average over n samples => Check Trigger
Trigger conditions
met?
Log Averages
Message to display loop: "Average"Message to average logging loop: "New Data"Payload: Average data collector arrayMessage to self: "Reset Collectors"
Case Yes => Log Averages
Reset Collectors
Execute 'Reset the Collector Data' method on all collector instances.
Case No => Wait for next message
START
Reset Collectors
Stop (from GUI loop)
STOP
Stop
Message to display loop: "Stop"Message to live and average logging loop: "Stop"
(wait for message) New Data
Update Display
Averaging method?
Waitfor
next message
Log Averages(from GUI loop:
manual start/stop or timer elapsed )
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 20 of 26
3.3.5 Display loop
The task of the display loop is to perform all data operations necessary for managing and
restructuring the acquired data into a suitable format for LabVIEW’s built-in graphical display
indicators. Two reasons to decouple these processes from the GUI and other loops are: A large
amount of data to be displayed simultaneously on the screen could slow down other program
actions up to a point that the user interface becomes slow to respond. The GUI loop is event-
based while the display loop makes also use of a queue message-based state machine in order
to be controllable from e.g. the processing loop.
When the display loop receives the message and payload “New
Data” from the processing loop, it will execute the ‘Read
Collector Values’ on the message payload and restructure the
contained values into a nested data structure that can be
accepted by the XY graph display indicator (see Figure 13). An
XY graph displays value pairs, which in this case consist of a
timestamp and a value. They are bundled as a ‘point’ cluster as
they are of different fundamental data types. These point
clusters are arranged as an array of points. This array has to be
encapsulated into a cluster again, resembling one plot to be
displayed on the graph. Since there is more than one signal
source, the individual plots have to be combined into an array
again to allow for the display of several channels in one plot. In
the current implementation there are three channels per input
signal: Live values, According live averages and the recorded average. This nested data
structure allows the display of plots of different lengths on the same graph. As the common
horizontal reference value is the time, this allows for the visual comparison of the signals as
well as association in time.
The XY graph display of the associated average values is updated when an “Average” message
is received and the corresponding case is executed. In this case the currently collected average
values are read out from the collectors and saved into a 2D array. The rows of this array
represent the measurement ‘slice’ while the columns of the array represent the channels. The
X and Y axis designation of the graph can thus be easily selected by indexing the corresponding
columns within the array.
Messages to stop the loop execution are received by the processing loop while messages to
clear the graphs and to reset the display data structures are received from the GUI loop.
Figure 13 – Multi XY graph
nested data structure. The graph
consists of an array of clusters of
an array of clusters of values.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 21 of 26
3.3.6 Logging loops
The incoming live and calculated average values are recorded independently due to their
different update rates. Thus, the implementation contains two logging loops running in parallel.
As hard disk operations take a relatively long time to complete in comparison to data
acquisition and display updates, it is recommended to perform this logging task in separate
loops, which can then de-queue elements at their own pace during program execution without
blocking other portions of the program. Logging loops receive new data via their designated
logging queues which transport a message of what to do and a data payload consisting of the
current array of collector objects. The live data logging loop is similar structured as the average
logging loop with the exception that it keeps the log file reference open during run-time of the
program in order to be able to better cope with the fast data input and not clog up the queue.
This sacrifices safety in writing for speed. The average logging loop uses the ‘Write To
Spreadsheet File.vi’ routine provided by LabVIEW which performs file open and close
operations internally. Figure 14 shows the source code of the average data logging loop which
acts a consumer for the data being sent by the processing loop. The data flow is described from
left to right: On the left side the input terminals of the subVI are visible. They transport
references to the message queues, error inputs, and the log file path into the loop to be accessed
during program flow. Inside the loop, the messages are read from the queue. If no message is
received, execution will pause here and release the CPU for other processes to run. When new
data arrives, the payload containing a snapshot of the collector array is decoded and sent into a
FOR loop. In here, the ‘read’ method of each data collector object is executed which extracts
the accumulated values. The values are then put into an array which represents one line to be
written to a spreadsheet file. Prior to writing the data to the file, the current write timestamp is
recorded for the current measurement. After a stop message is received (not pictured) the
reference to the logging queue is released by this consumer loop to ensure that all data is
written.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 22 of 26
Fig
ure
14 -
Sou
rce
code
of
the
ave
rage
da
ta l
ogg
ing
lo
op
.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 23 of 26
3.4 Prototype development
In order to test the functionality and performance of the software during development, a set of
simulation data value generators was written to provide data within similar ranges as the real
data sources described in section 1.3. An exemplary VI of the wavenumber value generators is
shown in Figure 15. The ability to generate test data at varying rates and intervals as well as
the built-in debugging tools such as data flow execution highlighting, wire probes, and single
stepping into subroutines have been a valuable instrument for testing individual program units.
Figure 15 – Value generator example VI. The chart on the front panel displays how the waveform should look
like in the time graph. On the block diagram, a typical wavenumber value is offset by a random number and then
published as a shared variable, indicated by the blue symbol of the waveform chart icon. The loop pace is specified
by a LabVIEW wait function node to in this case 53 ms.
The front panel of the current RILIS data recorder development prototype is shown in Figure
16. In the current state, the data recorder performs the required tasks of acquiring, displaying
and recording data as specified in the requirements analysis. Within this testing phase it has
been very valuable to regularly test and check the program performance as well as to get
feedback from the users to identify issues and change requests. An exemplary challenge was
to precisely determine how live values should be recorded into one common .csv file. Since
new values arrive asynchronously, each value is registered at a different time which in principle
requires the program to write a single line. The current implementation writes a zero value for
all unchanged channels, which the user will have to filter in post analysis. Another solution
could be to associate the previously recorded value, resulting in referencing redundant data.
Further tests within the real environment are currently underway resulting in suggestions for
improvement towards better usability.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 24 of 26
Fig
ure
16
- F
ront
panel
vie
w o
f th
e R
ILIS
da
ta r
eco
rder
, sh
ow
ing
th
e li
ve d
ata
dis
pla
y ve
rsu
s ti
me
gra
ph
. T
he
pic
ture
res
emb
les
sam
ple
da
ta
acq
uir
ed i
n t
he
manual
start
/sto
p m
od
e a
nd
in
dic
ate
s th
e li
ve d
ata
, a
vera
ged
da
ta, a
nd
th
e sa
ved
ave
rag
es.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 25 of 26
4. Future Developments and Outlook
Based on the current state of development and continued testing, the following requests for
enhancements of the RILIS data recorder have been identified:
- The following additional averaging modes have to added during the next
development steps:
o Supercycles – The CERN Proton distribution is organised into periodic
supercycles to allow for a controlled distribution and fair usage of the pre-
accelerated beam. Thus some experiments rely on the data acquisition to be
synchronized to the supercycle and will require also RILIS data averaged over
this period. A software add-on will allow the RILIS data recorder to synchronize
to this supercycle
o Proton Pulses – Each supercycle is split into several Proton Pulses which are
distributed to different experiment areas. The need for synchronization to
Proton Pulses is similar to the supercycle requirement explained above.
o Remote Trigger – To facilitate collaboration with other experiments in
ISOLDE, a communication mechanism is implemented to enable external
triggering of the averaging process. An external trigger could be anything from
a TTL Signal to external software making use of communication protocols such
as Ethernet or RS232.
o Laser Scan Tables – During a Laser Scan, a certain wavelength range is being
set by the control software of the different Lasers. This means that an optical
element is moved periodically to tune the laser over the specified range. The
Laser Scan Recoding software can be synchronized to the periodic movements,
allowing to relate a certain value read-out period to a certain wavelength
reading.
- Future versions of the XY graph display could include a peak fitting routine to get
a live qualitative indication of the measurement status when performing a laser scan.
This may aid in early estimation of necessary beam time allocation during in-source
spectroscopy.
- A comment line was requested to enable operators to annotate data while it is being
recorded. These comments should be written into the live value file to enable an
easy association to the measurement in post-analysis.
- Acquired data on the graphical displays could be exported to a mobile device by
using shared variables and the National Instruments Data Dashboard application
which is available for iOS and Android devices. These could act as a wireless
display for live data near the operated laser when tuning the laser beams.
- History scan data could be loaded from a file and provide the ability to compare
the current measurements to results obtained earlier under similar circumstances.
- Similarly the acquired data will be published live to other experiments making
use of the RILIS ion beams to enhance their dataset with additional laser status
information.
HSRM Master Project Documentation August 2014
Ralf Erik Rossel Laser Ion Source Data Acquisition Page 26 of 26
5. References
[1] “Archives of Isotope Separator On Line-DEtector, ISOLDE,” CERN, [Online].
Available:
http://library.web.cern.ch/archives/CERN_archive/guide/experimental_physics/SC/isai
solde. [Accessed 22 06 2014].
[2] E. Kugler, “The ISOLDE facility,” Hyperfine Interactions, vol. 129, no. 1-4, pp. 23-
42, 2000.
[3] “Cern Accelerator Complex Image,” CERN TE-EPC Department, [Online]. Available:
http://te-dep-epc.web.cern.ch/te-dep-epc/machines/pagesources/Cern-Accelerator-
Complex.jpg. [Accessed 22 06 2014].
[4] “The Accelerator Complex,” CERN, [Online]. Available:
http://home.web.cern.ch/about/accelerators. [Accessed 22 06 2014].
[5] R. E. Rossel, “RILIS Equipment Acquisition and Control Tool (REACT),” 10 2 2014.
[Online]. Available: EDMS 1354779. [Accessed 22 06 2014].
[6] “Intuitive Development Interface,” National Instruments, [Online]. Available:
http://www.ni.com/labview/why/user-interface/. [Accessed 22 06 2014].
[7] “Introduction to NI LabVIEW,” National Instruments, [Online]. Available:
http://www.ni.com/gettingstarted/labviewbasics/. [Accessed 23 06 2014].
[8] “Using the LabVIEW Shared Variable,” National Instruments, [Online]. Available:
http://www.ni.com/white-paper/4679/en/. [Accessed 14 06 2014].
[9] “What is a Queue?,” National Instruments, [Online]. Available:
http://digital.ni.com/public.nsf/allkb/DD7DBD9B10E3E537862565BC006CC2E4.
[Accessed 22 06 2014].
[10] “LabVIEW Forums: Basic Functional Global Variable Example,” [Online]. Available:
https://decibel.ni.com/content/docs/DOC-2143. [Accessed 22 06 2014].
[11] “Why LabVIEW?,” National Instruments, [Online]. Available:
http://www.ni.com/labview/why/. [Accessed 23 06 2014].