A Unified Matlab API for TINE and DOOCS Control Systems at DESY

At the European XFEL, MATLAB will play an important role as a programming language for high level controls. We present a standard MATLAB API which provides a unified interface for TINE and DOOCS control systems. It supports a wide variety of datatypes as well as synchronous and asynchronous communication modes

WRITING TINE SERVERS IN JAVA

Abstract The TINE Control System [1] is used to some degree in all accelerator facilities at DESY (Hamburg and Zeuthen) and plays a major role in HERA. It supports a wide variety of platforms, which enables engineers and machine physicists as well as professional programmers to develop and integrate front-end server software into the control system using the operating system and platform of their choice. User applications have largely been written for Windows platforms (often in Visual Basic). In the next generation of accelerators at DESY (PETRA III and VUV-FEL), it is planned to write the TINE userapplications primarily in Java. Java control applications have indeed enjoyed widespread acceptance within the controls community. The next step is then to offer Java as a platform for front-end servers. In this paper we present the TINE Java server API and first results using TINE Java servers. In particular we shall discuss the pros and cons of using Java as a platform for front-end and middle-layer servers and present timing results concerning Java servers using native Java, Java plus JNI, and native TINE servers. The TINE Control System is a distributed, objectbased system which runs on most platforms (legacy as well as modern) offers numerous services (both central and distributed) and enjoys a widespread use in the accelerator facilities at DESY. The TINE protocol offers high performance under extreme circumstances, such as transmitting large video frames at many hertz to multiple clients via multicast. Historically, no matter what platform or what language is being used for TINE clients or servers, the core TINE kernel has been written in C. Thus clients and server using say Visual Basic in WINDOWS make use of ActiveX controls (or VBX controls) or direct DLL calls which themselves call into the TINE kernel. Likewise, clients or servers written in LabView make use of VIs which interface to either TINE DLLs or shared TINE libraries, and so on. The Java TINE client API on the other hand interfaces to tine.jar, which is written entirely in Java. Certain aspects of the TINE C kernel were ported to Java, but to a larger extent, the TINE kernel was simply rewritten in Java, taking full advantage of the Java language where possible. All efforts were made to maintain as many similarities in the basic TINE API as possible. This does not mean that they are identical. Calls such as "AttachLink()" and "ExecLink()" are represented by the methods "attach()" and "execute()" of the representative TLink Object. Note that the TINE protocol does not deal so much with 'puts' and 'gets' as with data 'links'. One's first inclination when offering Java in the Control System's portfolio is to say that we don't need to worry about a Java Server API since front-end servers will always have to access their hardware and that is best left to code written in C. Furthermore, if there are realtime requirements, Java would not be an acceptable platform owing to Java's garbage collection kicking in at indeterminate intervals. Nevertheless, Java is a powerful language and offers numerous features and a wonderful framework for avoiding and catching nagging program errors. Thus there does in fact exist a strong desire to develop control system servers using Java. If these are to be middle layer servers, which manage and interpret data from front end servers, then the hardware issue is moot. Even front end servers can be written in Java when the hardware IO is made available by other means, such as a JNI or a CNI interface to the C libraries which do the 'dirty work'. It still remains to clarify whether issues of performance or garbage collection preclude writing effective servers in Java. A first effort has now been made to include the TINE server API within the tine.jar Java archive, so that we can make the initial performance tests. We shall report on these below. The current Java TINE server prototype offers approximately 75 percent of the functionality of a standard TINE server. Missing are such subsystems as the local alarm system and the local history system. Furthermore the current prototype does not offer initialization via a configuration database. For our purposes at this juncture however, these are trivial points. The server developer will not deal directly with these aspects in any case. The fundamental server management kernel and API are available, and it is primarily these which we present here. We first compare several Java Virtual Machines (JVMs) with regard to fairly general concerns, not specifically related to a TINE server. Then we shall turn our attention to the performance of our TINE server prototype. collection might have on our test server application by having a look at the repetitive instantiation of objects. By instantiating objects in a tight loop we notice that there are occasional delays on the order of 10 to 100 milliseconds, depending on the Java Virtual Machin

Fast Image Analysis for Beam Profile Measurement at the European XFEL

At the European XFEL, images of scintillator screens are processed at a rate of 10 Hz. Dedicated image analysis servers are used for transversal beam profile analysis as well as for longitudinal profile and slice emittance measurement. This contribution describes the setup and the algorithms used for image analysi

Taskomat & Taskolib: A Versatile, Programmable Sequencer for Process Automation

This contribution introduces the Taskolib library, a powerful framework for automating processes. Users can easily assemble sequences out of process steps, execute these sequences, and follow their progress. Individual steps are fully programmable in the lightweight Lua language. If desired, sequences can be enhanced with flow control via well-known constructs such as IF, WHILE, or TRY. The library is written in platform-independent C++17 and carries no dependency on any specific control system or communication framework. Instead, such dependencies are injected by client code; as an example, the integration with a DOOCS server and a graphical user interface is demonstrated

Collimator Performance Study at the European XFEL

Beam halo collimation is of great importance for the high repetition rate operation at the European XFEL and for the future CW machines. At the European XFEL several different types of collimators are installed at different locations of the beam line, which include the gun collimators, the bunch compressor collimators, and the main and supplementary collimators in the collimation section. Beam halo measurements have been performed using the wire scanners downstream of the main linac, which show that large part of beam halo is collimated by the gun collimator. Remaining losses in the collimation section are mainly due to misalignment. Alignment using orbit bumps in the collimation section is performed and presented in this paper

First Measurements with the K-Monochromator at the European XFEL

Hard X-ray free-electron lasers (XFELs) generate intense coherent X-ray beams by passing electrons through undulators, i.e. very long periodic magnet structures, which extend over hundreds of meters. The SASE1 and SASE2 undulator systems of the European XFEL consist of 35 segments with variable-gap planar undulators which are initially tuned to precise on-axis magnetic field strengths in a magnetic measurement laboratory to keep an important quality parameter – the K-value variation from segment to segment – below a certain limit (3 × 10−4 for 12 keV photon energy). After tunnel installation only photon-based methods can determine the K-values of undulator segments with a similar accuracy. The synchrotron radiation from a single or a few segments can be spectrally filtered by a dedicated crystal monochromator (K-monochromator) and recorded with a photodiode or with an imager that provides 2D information, tuned for high sensitivity to detect low photon densities from distant single undulator segments. This instrumentation is applied for electron orbit analysis and optimization, and adjustment of individual undulators in terms of their central magnetic axis with respect to the electron beam. Single undulator segments were analysed by scanning the monochromator crystal angle and detecting the steepest slope of a photodiode signal. Alternatively, in the imaging method, an imager recorded the radiation cone of electrons passing through the undulator segment. From the spatial distribution of the radiation, the K-parameter was determined with a sufficiently high relative accuracy

High Level Controls for the European XFEL

The European X-Ray Free-Electron Laser (XFEL) will generate extremely short and intense X-ray flashes from the electron beam of a 2.1 km long superconducting linear accelerator. Due to the complexity of the facility and the sheer number of subsystems and components, special emphasis needs to be placed on the automatization of procedures, on the abstraction of machine parameters, and on the development of user-friendly high-level software for the operation of the accelerator. The paper gives an overview of the ongoing work and highlights several new tools and concepts

The Virtual European XFEL Accelerator

The ambitious commissioning plans for the European XFEL require that many of the high-level controls are ready from the beginning. The idea arose to create a virtual environment to carry out such developments and tests in advance, to test interfaces, software in general and the visualisation of the variety of components. Based on the experiences and on the systems that are already in operation at the FLASH facility for several years, such a virtual environment is being created. The system can already simulate most of the key components of the upcoming accelerator. Core of the system is an event synchronized data acquisition system (DAQ). The interfaces of the DAQ system towards the device level, as well as to the high-level side is utilising the same software stack as the production system does. Thus, the software can be developed and used interchangeably between the virtual and the real machine. This allows to test concepts, interfaces and identify problems and errors at an early stage. In this paper the opportunities arising from the operation of such a virtual machine will be presented. The limits in terms of the resulting complexity and physical relationships will also be shown

High Level Software for the Commissioning of the European XFEL

The European X-Ray Free-Electron Laser (XFEL) will generate extremely short and intense X-ray flashes from the electron beam of a 2.1 km long superconducting linear accelerator. The commissioning and operation of the accelerator relies heavily on high level software for the automatization of measurements and procedures. The paper gives an overview of the ongoing work and highlights some new measurement techniques

The Evolution of the DOOCS C++ Code Base

This contribution traces the development of DESY's control system DOOCS from its origins in 1992 to its current state as the backbone of the European XFEL and FLASH accelerators and of the future Petra IV light source. Some details of the continual modernization and refactoring efforts on the 1.5 million line C++ code base are highlighted