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

[email protected]

August 2014

Supervisor: Prof. Dr. D. Richter (HSRM)

Local Supervisor: Dr. S. Rothe (CERN)

mailto:[email protected]

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



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



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.



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.



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



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



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.



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.



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)



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)



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 …

… … … … … … …



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.



- 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



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)



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.



Fig

ure

8 -

So

urc

e co

de

of

the

data

acq

uis

itio

n l

oo

p.



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.



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



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:



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 )



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.



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.



Fig

ure

14 -

Sou

rce

code

of

the

ave

rage

da

ta l

ogg

ing

lo

op

.



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.



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.



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.



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].

Network Distributed Data Acquisition, Storage, and ...shown connected to the BOOSTER and Proton...

Documents

Transcript of Network Distributed Data Acquisition, Storage, and ...shown connected to the BOOSTER and Proton...