COLDEX New Data Acquisition Framework - CERNTechnology Department Vacuum, Surfaces and Coatings...

15
Technology Department Vacuum, Surfaces and Coatings Group COLDEX New Data Acquisition Framework Redesign, implement, test and operate a brand new data acquisition framework based on direct communication with the experiment’s PLCs using LabVIEW Author: Christian Grech (TE/VSC) Supervisor: Roberto Salemme (TE/VSC) Co-supervisor: Cristovao Andre Dionisio Barreto(EN/ICE) July-August 2015

Transcript of COLDEX New Data Acquisition Framework - CERNTechnology Department Vacuum, Surfaces and Coatings...

  • Technology DepartmentVacuum, Surfaces and Coatings Group

    COLDEX New Data Acquisition FrameworkRedesign, implement, test and operate a brand new data acquisition frameworkbased on direct communication with the experiment’s PLCs using LabVIEW

    Author:Christian Grech (TE/VSC)

    Supervisor:Roberto Salemme (TE/VSC)

    Co-supervisor:Cristovao Andre Dionisio Barreto(EN/ICE)

    July-August 2015

  • Christian Grech

    Abstract

    COLDEX is an experiment of the TE-VSC group installed in the Super Proton Synchrotron(SPS) which mimics a LHC type cryogenic vacuum system. In the framework of the HighLuminosity upgrade of the LHC (HL-LHC project), COLDEX has been recommissioned in2014 in order to validate carbon coatings performances at cryogenic temperature with LHCtype beams. To achieve this mission, a data acquisition system is needed to retrieve and storeinformation from the different experiment’s systems (vacuum, cryogenics, controls, safety) andperform specific calculations. This work aimed to completely redesign, implement, test andoperate a brand new data acquisition framework based on communication with the experi-ment’s PLCs for the devices potentially available over network. The communication protocolto the PLCs is based on data retrieval both from CERN middleware infrastructures (CMW,JAPC) and on a novel open source Simatic S7 data exchange package over TCP/IP (libnodave).

    1

  • Christian Grech CONTENTS

    Contents

    Abstract 1

    1 Introduction 31.1 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Software Development Environment . . . . . . . . . . . . . . . . . . . . . . . . 3

    2 Application Design and Implementation 52.1 Interface to data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

    2.1.1 Communication Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 CERN controls Middleware (CMW) . . . . . . . . . . . . . . . . . . . . 62.1.3 JAPC framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.4 PLC Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.5 Serial Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    2.2 Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Main processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    2.4.1 Configuration Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Acquisition module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Logging module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    3 Conclusion and Future Developments 133.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Future Developments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Project schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

    4 References 14

    2

  • Christian Grech 1 INTRODUCTION

    1 Introduction

    1.1 Project Overview

    COLDEX is an experimental sector installed in the CERN Super Proton Synchrotron (SPS),that mimics a Large Hadron Collider (LHC) type cryogenic vacuum system. In the frameworkof the High Luminosity upgrade of the LHC (HL-LHC project), the mitigation of the electroncloud phenomenon in specific parts of the LHC machine, is being investigated. Amorphouscarbon (a-C) coating of the beam screen surface have been identified as baseline to reduceelectron cloud build-up. COLDEX has been re-commissioned in 2014 in order to validate theperformance of this kind of coatings at cryogenic temperature with LHC type beams. Toachieve this mission, a data acquisition system is needed to retrieve and store informationfrom the different experiment’s systems (vacuum, cryogenics, controls, safety) and perform, insome cases, specific calculations.

    The previous architecture of the acquisition system of the experiment can be seen in Figure1 below. Communication to the central PC retrieving data is mainly through serial commu-nications, which provide slow and dispersive access to devices for data retrieval. The newacquisition architecture does not abolish serial communication completely, but tries as muchas possible to make use of network (TCP/IP) connections to the experiment’s field controllers(PLC). The communication protocol to the PLCs is based on data retrieval both from CERNmiddleware infrastructures (CMW, JAPC) and on a novel open source Simatic S7 data ex-change package over TCP/IP (libnodave).

    1.2 Software Development Environment

    The integrated development environment (IDE) National Instruments (NI) LabVIEW waschosen as a readily available and widely used CERN standard software which enables itsusers to quickly add new features and develop elementary GUI applications on demand. Abroad range of driver libraries and data acquisition modules were provided, as well as CERNdeveloped tools aimed at rapid development of data acquisition software.

    3

  • Christian Grech 1 INTRODUCTION

    Figure 1: Previous architecture

    4

  • Christian Grech 2 APPLICATION DESIGN AND IMPLEMENTATION

    2 Application Design and Implementation

    2.1 Interface to data sources

    2.1.1 Communication Layout

    The envisaged data acquisition architecture for this project is shown in Figure 2 below. Datais collected from three PLCs (Vacuum PLC, Cryogenic PLC and COLDEX PLC), the SPSBCT (Beam Current Transformer), two RGAs (Residual Gas Analysers), two Keithley 2410(High-Voltage Sourcemeter) and other devices which are not available on network, such ascapacitancee gauges. The NI PXIe-1082 acts as the system controller, as it is the central pointto all the data being acquired from all the different devices.

    Figure 2: Conceptual schematics of the device communication layout

    The Vacuum PLC manages the readings from several pressure gauges such as Pirani, Penningand Bayard-Alpert gauges. These gauges cover different ranges of pressure values. The Cryo-genics PLC manages the readings from the cryogenic installation devices, belonging to the pro-cess (cold box, storage dewar) and to the COLDEX cryostat (colde bore vessel, beam screen,buffer, thermal shield). The COLDEX PLC monitors data on the status of the COLDEX mov-able stage and acquires analog inputs, such as the thermocouples of the WAMPAC calorimeter.

    The Rapid Application Development Environment (RADE) framework based on LabVIEWwas used in this project as the main communication framework tool. RADE was developed at

    5

  • Christian Grech 2 APPLICATION DESIGN AND IMPLEMENTATION

    CERN to satisfy the need to create applications in a light and easy-to-learn tool, while havingfull integration into the CERN accelerator control software infrastructure, such as middleware,databases and file systems, with their associated protections. [1] The following sections willdescribe each communication model’s integration in this project.

    2.1.2 CERN controls Middleware (CMW)

    The CERN controls Middleware (CMW) provides a common software communication infras-tructure for the CERN accelerator controls. The LabVIEW CMW Wrapper provides accessto scientific equipment software components based on FESA and other CMW devices fromLabVIEW applications. The CMW Wrapper is a software layer between LabVIEW and theCMW RDA (Remote Device Access) client package. It comprises a component palette forLabVIEW and some DLLs which are copied into accessible for operating system directory [2].

    CMW has been selected, whenever applicable, for acquisition of the all variables belonging tothe COLDEX vacuum system. CMW subscription to COLDEX experiment’s vacuum relatedvariables, published by the vacuum SCADA Application, is operated. Figure 3 below showsthe VI used to subscribe data from the Vacuum PLC using CMW.

    Figure 3: CMW subscription

    After carefully checking each measurement using LabVIEW, a test was made on the perfor-mances of the CMW subscription. A LabVIEW VI to continuously poll a single COLDEXvariable from CMW was created and a minimum communication time of 15 ms was noticed,corresponding to a sampling rate of 66Hz. The test involved operating a step-like tran-sient on one of the COLDEX experiment variables. The pressure measured by the deviceV GHB_41752 was noted while triggering a sudden big pressure rise injecting hydrogen in thevacuum system without (faster) or with (slower) vacuum pumping. The results, which werelogged in a text file, showed that a variation in the acquired data was visible only after 66datapoints. Being this systematic, it was concluded that this was a limitation in the publishing

    6

  • Christian Grech 2 APPLICATION DESIGN AND IMPLEMENTATION

    rate by the vacuum SCADA application.

    After discussion, the 1 Hz bottleneck was identified on the VAC PLC publication to theSCADA application. In fact, this is the time it takes for PLC to be able to publish a wholearray containing the values he acquired communicating to all the device (pressure gauges)controllers via Profibus loop.

    2.1.3 JAPC framework

    JAPC (Java API for Parameter Control) is a framework to build Java applications that controlaccelerator devices. Its central concept is a parameter, which typically represents a controlsvalue of an accelerator device (also known as device property) but actually can provide accessto everything accessible (equipments, databases, timing events, intermediate servers, simula-tion). Client programs can access JAPC parameters with set and get interactions, and theycan wait to be notified of value changes using subscription [3]. It communicates to an Apacheserver through HTML.

    The LabVIEW to JAPC bridge provides access to accelerator devices, through JAPC per-sistence layer. It is comprised of a component palette for LabVIEW and one DLL which iscopied into the system DLL directory. The JAPC subscription process is identical to that inFigure 3 above, but the CMW blocks are replaced with their JAPC counterparts. JAPC wasused to access data from the SPS BCT, and was also a backup for the CMW communicationmodel.

    2.1.4 PLC Library

    The communication to the PLC is written in standard LabVIEW using the wrapper for LIBN-ODAVE, an open source library to access Siemens PLCs. A “wrapper” written in C was usedas the layer between LabVIEW and the Libnodave library. Figure 4 below shows the VI usedfor reading values from PLCs in this manner. Direct acquisition of data managed by theCryogenics PLC and the COLDEX PLC was achieved in this manner through simple pollingover TCP/IP.

    7

  • Christian Grech 2 APPLICATION DESIGN AND IMPLEMENTATION

    Figure 4: The PLC Read function

    2.1.5 Serial Communication

    The communication to the COLDEX RGAs follows an analog protocol, whereas the capac-itance gauge and the Keithley 2410 employ a serial communication method. Due to timeconstraints, the communication to these devices was not set up but several considerationswere made so that they can be appended to the framework at a later stage.

    8

  • Christian Grech 2 APPLICATION DESIGN AND IMPLEMENTATION

    2.2 Design Pattern

    The data acquisition framework is based on the LabVIEW design pattern of a Queued MessageHandler, which provides a flexible and extendable programming. This design pattern is anextension of the producer-consumer pattern in which data is produced by an independentlyrunning loop, then sent via a message queue to a consumer loop which can handle the incomingdata at its own pace. This allows modularization of the tasks performed by the software.

    The implementation of the data acquisition console uses four loops running in parallel, eachperforming a dedicated role within the application. Figure 5 illustrates an overview of thisdesign. Four loops are running in parallel, each performing a dedicated task within the soft-ware. The loops communicate via control events and data messages. The individual loopfunctions are described in more detail in the following sections. The console User Interfacewas developed following the client specifications, which are available in [4].

    Figure 5: The data acquisition console loops

    9

  • Christian Grech 2 APPLICATION DESIGN AND IMPLEMENTATION

    2.3 Main processor

    The Graphical User Interface consists of several tabs, each of which contains different functionssuch as configuration, waveform display and calculating several parameters. In this project,the main focus was on the Configuration tab, where the user inputs the parameters to bemeasured, and the Experimental Display, where the user can view numeric and graphicaldisplays of the results. The Main processing loop was the master loop, issuing commandsbased on events from the user in the GUI. Using queues, commands are sent to the other threeloops.

    Figure 6: Main processing loop and Display loop

    2.4 Display

    The task of the display loop in the main GUI loop is to perform all data operations necessary formanaging and restructuring the acquired data into a suitable format for LabVIEW’s built-ingraphical display indicators. When the display loop receives the message from the Acquisitionloop, it restructures the contained values into a nested data structure that can be acceptedby the XY graph display indicator. In order to plot multiple points, a buffer appends data tocreate an array which grows with every value acquired. A graph displays value pairs, whichin this case consist of a timestamp and a value.

    10

  • Christian Grech 2 APPLICATION DESIGN AND IMPLEMENTATION

    Figure 7: Experimental data display tab

    2.4.1 Configuration Table

    The Configuration Table (Figure 7)is used to acquire the necessary parameters to perform therequired data retrieval. This table can be edited manually, or loaded from a pre-existing Excelfile. Consequently, the table can be exported to an Excel file for future reference. In the table,the user chooses which parameters to store, and from these parameters which values to display.When the ’Store’ button is clicked, the values which are not to be stored are filtered out, andthe parameters of the values to be stored are passed on using queues to the Acquisition Loop.Data is passed as a an array of clusters.

    Figure 8: The device configuration tab

    11

  • Christian Grech 2 APPLICATION DESIGN AND IMPLEMENTATION

    2.5 Acquisition module

    The acquisition loop consists of a tool, which performs a subscription to a specific data sourceaccording to the method specified in the Configuration table and the data type of the mea-surement to be retrieved. This tool is placed in a for loop which is executed in a parallelmanner when the input parameters are received. The subscription methods were described inthe previous section. A timestamp is added on each subscription and appended to the valueand property name of the measurement. On acquisition, data is then sent to the Logging loop,and filtered to be sent to the Display loop.

    Figure 9: Acquisition module

    2.6 Logging module

    The logging loop is called asynchronously from the main loop, so that the log can be initialisedwith a header containing the property name and its unit before data is retrieved. It runsparallel to the main loop, and its main functions are initialising the log file, storing data andclosing the log file. A comment line was added in the GUI to enable operators to annotatedata while it is being recorded. These comments are written into a separate log runningparallel to the data log,and each comment is marked with a unique timestamp to enable aneasy association to the data in post-analysis.

    Figure 10: Logging loop

    12

  • Christian Grech 3 CONCLUSION AND FUTURE DEVELOPMENTS

    3 Conclusion and Future Developments

    3.1 Conclusions

    The system design at its current state, as of the end of August 2015, was such that multiplenumber of variables can be retrieved using CMW, JAPC and two PLCs simultaneously. Aftertesting trials with over 35 inputs from different sources, continuous updates were observed. Adebugging and optimisation phase will follow.

    3.2 Future Developments

    When starting the project, it was emphasized that the biggest priority was not completing anddisplaying data from all the devices incorporated in the experiment, but to lay a solid foun-dation by creating a modular system, so that more devices can be added easily in the future.Based on the current status and continued testing, the following suggestions for enhancing theCOLDEX data acquisition framework have been identified:

    • Complete error handling within the software.

    • Improve the code for PLC data retrieval to simplify adding more data blocks and PLCsin the future.

    • Include analog communication functionality, required for the COLDEX RGAs data ac-quisition.

    • Include serial communication functionalities (RS-232, RS-488 and GPIB), required fordevices not available through CMW, or in general through network (e.g. capacitancegauges, Keithley sourcemeters).

    • Improve the waveform display tab with better use of space by investigating alternativesother than using Mixed Signal Graphs.

    3.3 Project schedule

    This project was assigned as part of my CERN Summer Studentship which lasted for eightweeks. This period included two weeks of training in LabVIEW and getting familiar withthe hardware involved in the COLDEX experiment. The third and fourth weeks were spenttesting the data from the PLCs and creating suitable tools to capture this data in the least in-trusive manner possible. Several options were considered for every communication path whichneeded to be introduced. The last four weeks were spent building the LabVIEW console it-self, and making sure that the criteria of scalability and modularity were being included inevery possible way. Testing of the framework ensued, which led to a final presentation of theproduct. First deployment of the product will follow in the next COLDEX experimental run,

    13

  • Christian Grech 4 REFERENCES

    planned in September 2015, and will run initially alongside the existing the data acquisitiontool, providing a performance test and comparison and further debugging.

    3.4 Acknowledgements

    I would like to thank all the people who involved themselves in some way in this project. Iowe the success of this project to my supervisors Roberto Salemme (TE/VSC) and CristovaoBarreto (EN/ICE), who gave me all the necessary training and support. My thanks also goto all the EN/ICE MTA section members, especially Adriaan Rijllart, Cedric Charrondiereand Odd Øyvind Andreassen who took a special interest in this project and to the TE/VSCmembers. A special thanks also goes to the TE/CRG members who helped in setting up PLCdata retrieval.

    4 References

    [1] NI Week 2010 Document at: https://decibel.ni.com/content/docs/DOC-12031

    [2] R. Sorokoletov, "CMW wrapper for LabVIEW User Manual"

    [3] O. Ø. Andreassen, D. Kudryavtsev, A. Raimondo, A. Rijllart, V. Shaipov, R. Sorokoletov,"The LabVIEW RADE Framework Distributed Architecture"

    [4] R. Salemme, "Specification of the new COLDEX data acquisition User Interface"

    14