MOCOAAB03, http://accelconf.web.cern.ch/AccelConf/ICALEPCS2013/papers/mocoaab03.pdfInternational audienceThe commissioning of the first phase of the Spiral2 Radioactive Ion Beams facility at Ganil will soon start, so requiring the control system components to be delivered in time. Yet, parts of the system were validated during preliminary tests performed with ions and deuterons beams at low energy. The control system development results from the collaboration between Ganil, CEA-IRFU, CNRS-IPHC laboratories, using appropriate tools and approach. Based on Epics, the control system follows a classical architecture. At the lowest level, Modbus/TCP protocol is considered as a field bus. Then, equipment are handled by IOCs (soft or VME/VxWorks) with a software standardized interface between IOCs and clients applications on top. This last upper layer consists of Epics standard tools, CSS/BOY user interfaces within the socalled CSSop Spiral2 context suited for operation and, for machine tunings, high level applications implemented by Java programs developed within a Spiral2 framework derived from the open-Xal one. Databases are used for equipment data and alarms archiving, to configure equipment and to manage the machine lattice and beam settings. A global overview of the system is therefore here proposed

Denis, J.F.

F. Gournay, J.

Gillette, P.

Gougnaud, F.

Graehling, P.

Haquin, C.

Hosselet, J.

Lemaitre, E.

Lussignol, Y.

Lécorché, E.

Maazouzi, C.

Normand, G.

Patard, C.H.

Philippe, L.

Touchard, D.

HAL-CEA

THE SPIRAL2 CONTROL SYSTEM PROGRESS TOWARDS THE COMMISSIONING PHASE C. Haquin, P. Gillette, E. Lécorché, E. Lemaître, G. Normand,  C. H. Patard, L. Philippe, D. Touchard, Ganil, Caen, France  J. F. Denis, F. Gougnaud, J. F. Gournay, Y. Lussignol, CEA-IRFU, Saclay, France P. Graehling, J. Hosselet, C. Maazouzi, CNRS-IPHC, Strasbourg, FranceAbstract The commissioning of the first phase of the Spiral2 Radioactive Ion Beams facility at Ganil will soon start, so requiring the control system components to be delivered in time. Yet, parts of the system were validated during preliminary tests performed with ions and deuterons beams at low energy. The control system development results from the collaboration between Ganil, CEA-IRFU, CNRS-IPHC laboratories, using appropriate tools and approach. Based on Epics, the control system follows a classical architecture. At the lowest level, Modbus/TCP protocol is considered as a field bus. Then, equipment are handled by IOCs (soft or VME/VxWorks) with a software standardized interface between IOCs and clients applications on top. This last upper layer consists of Epics standard tools, CSS/BOY user interfaces within the so-called CSSop Spiral2 context suited for operation and, for machine tunings, high level applications implemented by Java programs developed within a Spiral2 framework derived from the open-Xal one.  Databases are used for equipment data and alarms archiving, to configure equipment and to manage the machine lattice and beam settings.  A global overview of the system is therefore here proposed. INTRODUCTION The Spiral2 project [1] in construction at Ganil is considered within two phases as shown on Fig. 1:  Figure 1: The Spiral2 project layout. Phase one is composed of an accelerator stage for deuterons, protons and heavy ions in a wide range of energies and intensities, with two new experimental halls, NFS (Neutrons For Science) and S3 (Super Separator Spectrometer). The acceleration is first given by a RFQ providing a beam at medium energy then followed by a superconducting Linac to reach the required power (200 kW for a deuterons beam).   To save time when commissioning the whole installation, preliminary beam production tests were performed at Saclay (CEA-IRFU) and Grenoble (CNRS-LPSC) with the deuterons and ions sources followed by their associated low energy beam transfer line temporarily installed. The building construction is still in progress (expected building turnover in mid 2014) but the installation of the accelerator itself already started when the first blocks became available (low energy beam lines area).  The planning objective aims to install and test the whole accelerator for the first experiments with NFS and S3 in 2014-2015. Phase 2 is the Radioactive Ion Beam production process from the phase 1 outgoing primary beams. It integrates a new low energy DESIR experimental room and the transfer line to the existing Ganil facility for post acceleration and use of the experimental switchyard.  The control system for these two phases will be built according to the same concepts and architecture. Nevertheless, this paper focuses on the Spiral2 phase 1 control system having now to be delivered quite soon progressively from the beginning of next year. CONTROL SYSTEM OVERVIEW According to the project strategy, the control system development is seen as a collaborative work between three institutes: Ganil (Caen), CEA-IRFU (Saclay) and CNRS-IPHC (Strasbourg), with a tight distribution of the work packages under the Ganil coordination [2], [3]. The main options for the Spiral2 control system [4] were taken at the beginning of the project in late 2006, resulting from technical and organisational considerations as well as from previous experiences and skills: x The control system is Epics based with a classical architecture federating VME IOCs (Emerson MVME5500 CPU) running VxWorks and soft IOCs on Linux PC (RHEL, CentOs under evaluation now). x Pieces of equipment are handled either directly from VME boards: most of them from Adas-Nexeya are addressed through Epics drivers provided by CEA-IRFU. So, standard I/Os are performed using ADC (ICV 150 32 channels*16 bits), binary I/Os (ICV 196 96 channels), DAC (ICV 714 16 channels*12 bits).   A specific configuration mentioned later in this paper is dedicated for fast ADC acquisition. x The Modbus-TCP protocol is extensively used (power supplies, diagnostics, PLCs ...) thanks to the Mark Rivers’s driver from University of Chicago. x Linked to the control system, Siemens S7 PLCs are in charge of slow security related controls or handle specific devices. Phase 1Phase 2MOCOAAB03 Proceedings of ICALEPCS2013, San Francisco, CA, USAISBN 978-3-95450-139-78Copyrightc ○2014CC-BY-3.0andbytherespectiveauthorsProject Status Reportsx GUIs are either Epics standard tools (EDM at the beginning, CSS/BOY for later developments) or Java programs based on an adaptation for Spiral2 of the open-Xal package [5]. x Database needs such as equipment configuration, alarms handling and machine modelization are managed within the Relational Database Management System Ingres. Later, MySql was introduced with the RDB archiver. x To enhance the software engineering process, the UML modeling language was progressively adopted during the control system development cycle. CENTRAL SERVICES The basic services to be provided within the control system are implemented according to different strategies: x For equipment configuration, an important objective since the very beginning is to provide a tool for end users, even not Epics aware, for configuring equipments with their operational characteristics (addresses, thresholds, software and hardware limits, scaling factors ...).  Data are stored in a database from which the so-called genIOC program extracts data to generate the Epics substitutions and dbs, connections and sequencer files.    Fig. 2: Automated generation of Epics files from database. x Machine modelization:  A specific database stores all data required for tuning the machine by high level applications: it implements the accelerator lattice according to a hierarchy, associating beam optics able to be applied. Therefore, a gateway program extracts data to generate .xdxf Xal compliant files for on-line use.  The database also integrates for each beam accelerated different set of values: theoretical (exported from the CEA-IRFU TraceWin code), provisional (either from theory or extrapolations from previous tunings), archived (prior settings) A specific GUI tool has been developed for the off-line management of this machine modelization paradigm. x Alarms management is a homemade specific development to be coherent with the existing tool already in use at Ganil. Alarms configuration is stored in an Ingres database which also archives alarm occurrences. During operation, a Java monitor program catches events from the Channel Access monitoring mechanism and formats the alarm messages. Then, a Java server archives these alarms in the database, also dispatching the messages to different Java/Xal programs for display as a continuous stream.  x The archiving service is the standard RDB archiver with the archive engines feeding a Mysql database, clients being the CSS databrowser for data retrieving. To enhance performances, two databases instances replicated are used (one for insertion and one for consultation). x The implementation of an e-logbook for operation makes use of the j5 suite from  Saint-James J5 software company, first evaluated within the Ganil operational environment and now used in production. EQUIPMENT INTEGRATION First Validations Beam tests performed at Saclay gave the opportunity to validate the first equipment interfaces, as presented in [6]:  x Power supplies communicate with the control system using the Modbus-TCP protocol. x Acquisition of beam current using Faraday cups (as well DCCTs) is performed either using a slow ADC or a set of two units for “fast” acquisition up to 1,2 MSamples/sec (VME ADC Adas ICV 178 coupled with the synchronization and buffering VME Adas ICV 108). x Slits as well as beam profilers are handled using the Modbus-TCP protocol and then a gateway to Modbus-RTU for accessing the devices. x The deuterons source control implies a set of different specific devices: magnetron (VME ADC and binary inputs/outputs), impedance adaptation (VME ADC, DAC and binary inputs/outputs), pulse generator (stream device above TCP-IP), gaz injection (stream device above RS232). x Transverse emittance measurement is handled by a specific VME crate. Besides standard ADC, fast ADC, binary and DAC boards, it integrates dedicated controls for high voltage ramping (ISEG 202 M) and pod motion (OMS MaxV 4000s).  Current Developments x Handling of equipment addressed through PLCs:since the early beginning, Siemens PLCs are interfaced with the control system using the Modbus-TCP protocol, so allowing controlling the vacuum and beam interlocks for the deuteron beam production tests. Within a wider scope, the objective of this development is to provide a tool able to generate PLCs based devices from the PLCs data bloc description, according to predefined types of equipment (insertion devices, vacuum gauges, motor controls ...).This tool, genAuto, coupled with the genIOC generation program is currently under test within a prototyping environment. Proceedings of ICALEPCS2013, San Francisco, CA, USA MOCOAAB03Project Status ReportsISBN 978-3-95450-139-79 Copyrightc ○2014CC-BY-3.0andbytherespectiveauthorsx Time of flight measurement: specific pick-up devices developed at Ganil will allow calculating the beam energy from the time of flight inside the high energy beam line after the Linac (through phase measurement). The system is interfaced to the controls using a Modbus/TCP link and the development is in its final phase. x Beam Losses Monitors: the IFIN-HH laboratory (Bucarest) is in charge of the work package for the Spiral2 BLMs while the controls are jointly managed with Ganil [7]. For activation prevention (out of the scope of the control system), beam stops can be generated from signals coming from the 32 detectors; for the thermal protection of the machine, signals are also sent to a VME crate housing a Caen V1495 FPGA board. It runs an Epics IOC to calculate losses, handle thermal thresholds and scaling coefficients according to the beam to be currently accelerated. The development of the VxWorks and Epics drivers are sub-contracted to Cosylab.    x In order to measure the bunch length and to set the bunchers upstream the Linac, a fast coaxial Faraday cup will be installed. Signals are sent to an Agilent DS9404A oscilloscope running Windows interfaced from an IOC using the asyn driver. A CSS/BOY operator interface allows getting a remote control and displaying the computed values resulting from the measurements. Data will be also read by high level applications for the cavity tuning. Figure 3: CSS/BOY based remote oscilloscope interface. x  Controls of the RF solid state amplifiers: the RF rebunchers and Linac cavities will be driven by 20 kW solid state amplifiers provided by Sigmaphy company. The 32 amplifiers are interfaced with the control system by a PLC gateway centralizing all interfaces and command. Two major use cases are defined, one for the operation to provide a global view of all the amplifiers and the second for RF specialists ; as this last one requires to read a lot of data, a special mechanism able to dynamically launch IOCs has been set. The GUI interface is written in CSS/BOY. x RF controls will imply amplifiers, PLCs for security care and a low level RF VME based specific subsystem for regulating the accelerator field and tuning the frequency within a closed feedback loop [8]. A first prototyping environment was installed at Ganil in June 2012 around one buncher cavity and allowed to get a first feedback on the architecture and then to improve performances. A second test period is under consideration for a deeper investigation within the control system up to the high level application software interfaces. OPERATOR INTERFACES Definition of a GUI Chart To provide as much as possible a coherent user interface independently from the relying technology, a graphical chart was edited, with both implementations for CSS/BOY and Java/XAL applications. The chart first specifies the use of colours, fonts. Then, it defines the display of editable/no editable text fields, alarm borders representation, menus, behaviour when PVs are disconnected.  Furthermore, representation of defaults and status words are standardized, based on the software layer implementation previously defined in [9]. Lastly, “good practices” are advised and an implementation is proposed within an .opi (CSS/BOY) and an .app example (Java) files.  Use of CSS/BOY The first supervision screens developed for the project were in EDM. Therefore, it allowed providing GUIs for the beam production tests performed at Saclay with the deuteron source and low energy beam line controls; also, specific developments for beam diagnostics were delivered within this tool. As the CSS development environment was emerging, it was decided to evaluate this technology and first applications based on CSS/BOY were prototyped within different contexts such as the RFQ amplifier test bench. Coming from the first promising feedback, it was decided to go further this way and the investigation was extended to provide to the project the so-called CSSop suited for the Spiral2 operation, with a dedicated configuration and environment as well as restricted limitations for operators.  Figure 4:      CSS/BOY LEBT 1  synoptic,      within     a  predefined framework with the ability of displaying  either a status/default tab or a command purpose one.  MOCOAAB03 Proceedings of ICALEPCS2013, San Francisco, CA, USAISBN 978-3-95450-139-710Copyrightc ○2014CC-BY-3.0andbytherespectiveauthorsProject Status ReportsCSS/BOY synoptic will be considered as supervision GUIs for operation, in an interactive way. Beside of that, a prototype is currently envisioned for providing a general synoptic of the whole accelerator, spread out over four TV screens in the main control room. Xal Integration Tuning such a complex machine requires high level applications for algorithms implementation with reference data stored in a coherent and structured design. The first choices for these developments were to perform them in Java and, according to the existing Xal environment developed by SNS, to define a Spiral2 suited framework derived from Xal, now OpenXal based. It is now used not only for high level applications, also for control and command of equipment when the scope of the application goes further than the supervision needs. Figure 5: Xal based application for beam analysis. The first applications developed within this schema are now operational and some of them were successfully tested at Saclay with the deuteron beam:  general purpose handling tool, beam optimization, analysis at the beam source output, beam emittance limitation, profilers display, on-line management of sets of values and configuration of beam optics...  A major application still in development is the cavity tuning application interacting with the RF components whose settings are defined from different diagnostics measurements (position, bunch length ...). Also a set of several GUIs related to the Machine Protection System [10] is under development: general control and consistency between the beam settings and the MPS based PLC system [11], beam power progressive increase, beam losses display, interlocks interface, macro pulse handling, beam trajectory visualization. To structure developments, software tools have been defined: pdf viewer integration, Xal node selection, implementation of swing components (slider, alarm, textfield, toggle button, button, check box label...) associated with a Channel Access name, panels to implement basis elements (profilers, magnet power supplies, slits, Faraday cups ...). Java applications adopt the Nimbus look and feel and are compliant with the Spiral2 GUI chart. NETWORK The network architecture defined by the global computing infrastructure group integrates the different needs among which one concerns the control system. Therefore, different vlans have been considered : general controls (central server, GUIs, IOCs), PLCs, power supplies, general field bus, profilers and a last one gathering PLCs in charge of the cryogenic of the cavities and LLRF VME based systems (to provide the frequency tuning system within a quite autonomous environment). On the VME IOCs, this configuration is implemented using the two Ethernet ports of the MVME 5500 CPU, one being on the general controls vlan while the second one is attached to the appropriate dedicated vlan. CONCLUSION Most of the components of the Spiral2 control system are either now available or under development. The objective remains to be on time with the project milestones, having also to move from the development and preparatory phases to the installation and then commissioning ones, and this is surely the difficult but exciting challenge to aim for the coming times. REFERENCES [1] R. Ferdinand et al. “Process of construction and installation of the Spiral2 accelerator”, Ipac 2013, Shangai, China, May 2013. [2] D. Touchard et al, “The Spiral2 command control software organization and management“, Icalepcs 2009, Kyoto, Japan, October 2009.  [3] E. Lécorché et al, “A Small but Efficient Collaboration for the Spiral2 Control System Development”, this conference. [4] E. Lécorché et al. “Overview of the Spiral2 control system progress“, Icalepcs 2011, Grenoble, France, October 2011. [5] L. Philippe et al, “Spiral2 control command: first high level applications based on the Open XAL library“, Icalepcs 2011, Grenoble, France, October 2011. [6] F. Gougnaud et al. “The implementation of the injector Spiral2 control system“, Icalepcs 2011, Grenoble, France, October 2011. [7] C. Haquin et al. “Development of the thermal beam loss monitors of the Spiral2 control system“, this conference.  [8] D. Touchard et al. “The Spiral2 radiofrequency command control“, Icalepcs 2011, Grenoble, France, October 2011. [9] C. Haquin et al. “Spiral2 control command: a standardized interface between high level applications and Epics IOCs”, Icalepcs 2011, Grenoble, France, October 2011. [10] L. Philippe et al, “User interfaces for the Spiral2 Machine Protection System”, this conference. [11] C. Berthe et al, “Machine Protection System for the SPIRAL2 facility”, this conference.  Proceedings of ICALEPCS2013, San Francisco, CA, USA MOCOAAB03Project Status ReportsISBN 978-3-95450-139-711 Copyrightc ○2014CC-BY-3.0andbytherespectiveauthors

The SPIRAL2 control system progress towards the commissioning phase

HAL-IN2P3

THE SPIRAL2 CONTROL SYSTEM PROGRESS TOWARDS THE COMMISSIONING PHASE C. Haquin, P. Gillette, E. Lécorché, E. Lemaître, G. Normand,  C. H. Patard, L. Philippe, D. Touchard, Ganil, Caen, France  J. F. Denis, F. Gougnaud, J. F. Gournay, Y. Lussignol, CEA-IRFU, Saclay, France P. Graehling, J. Hosselet, C. Maazouzi, CNRS-IPHC, Strasbourg, FranceAbstract The commissioning of the first phase of the Spiral2 Radioactive Ion Beams facility at Ganil will soon start, so requiring the control system components to be delivered in time. Yet, parts of the system were validated during preliminary tests performed with ions and deuterons beams at low energy. The control system development results from the collaboration between Ganil, CEA-IRFU, CNRS-IPHC laboratories, using appropriate tools and approach. Based on Epics, the control system follows a classical architecture. At the lowest level, Modbus/TCP protocol is considered as a field bus. Then, equipment are handled by IOCs (soft or VME/VxWorks) with a software standardized interface between IOCs and clients applications on top. This last upper layer consists of Epics standard tools, CSS/BOY user interfaces within the so-called CSSop Spiral2 context suited for operation and, for machine tunings, high level applications implemented by Java programs developed within a Spiral2 framework derived from the open-Xal one.  Databases are used for equipment data and alarms archiving, to configure equipment and to manage the machine lattice and beam settings.  A global overview of the system is therefore here proposed. INTRODUCTION The Spiral2 project [1] in construction at Ganil is considered within two phases as shown on Fig. 1:  Figure 1: The Spiral2 project layout. Phase one is composed of an accelerator stage for deuterons, protons and heavy ions in a wide range of energies and intensities, with two new experimental halls, NFS (Neutrons For Science) and S3 (Super Separator Spectrometer). The acceleration is first given by a RFQ providing a beam at medium energy then followed by a superconducting Linac to reach the required power (200 kW for a deuterons beam).   To save time when commissioning the whole installation, preliminary beam production tests were performed at Saclay (CEA-IRFU) and Grenoble (CNRS-LPSC) with the deuterons and ions sources followed by their associated low energy beam transfer line temporarily installed. The building construction is still in progress (expected building turnover in mid 2014) but the installation of the accelerator itself already started when the first blocks became available (low energy beam lines area).  The planning objective aims to install and test the whole accelerator for the first experiments with NFS and S3 in 2014-2015. Phase 2 is the Radioactive Ion Beam production process from the phase 1 outgoing primary beams. It integrates a new low energy DESIR experimental room and the transfer line to the existing Ganil facility for post acceleration and use of the experimental switchyard.  The control system for these two phases will be built according to the same concepts and architecture. Nevertheless, this paper focuses on the Spiral2 phase 1 control system having now to be delivered quite soon progressively from the beginning of next year. CONTROL SYSTEM OVERVIEW According to the project strategy, the control system development is seen as a collaborative work between three institutes: Ganil (Caen), CEA-IRFU (Saclay) and CNRS-IPHC (Strasbourg), with a tight distribution of the work packages under the Ganil coordination [2], [3]. The main options for the Spiral2 control system [4] were taken at the beginning of the project in late 2006, resulting from technical and organisational considerations as well as from previous experiences and skills: ? The control system is Epics based with a classical architecture federating VME IOCs (Emerson MVME5500 CPU) running VxWorks and soft IOCs on Linux PC (RHEL, CentOs under evaluation now). ? Pieces of equipment are handled either directly from VME boards: most of them from Adas-Nexeya are addressed through Epics drivers provided by CEA-IRFU. So, standard I/Os are performed using ADC (ICV 150 32 channels*16 bits), binary I/Os (ICV 196 96 channels), DAC (ICV 714 16 channels*12 bits).   A specific configuration mentioned later in this paper is dedicated for fast ADC acquisition. ? The Modbus-TCP protocol is extensively used (power supplies, diagnostics, PLCs ...) thanks to the Mark Rivers’s driver from University of Chicago. ? Linked to the control system, Siemens S7 PLCs are in charge of slow security related controls or handle specific devices. Phase 1Phase 2MOCOAAB03 Proceedings of ICALEPCS2013, San Francisco, CA, USAISBN 978-3-95450-139-78Copyrightc ○2014CC-BY-3.0andbytherespectiveauthorsProject Status Reports? GUIs are either Epics standard tools (EDM at the beginning, CSS/BOY for later developments) or Java programs based on an adaptation for Spiral2 of the open-Xal package [5]. ? Database needs such as equipment configuration, alarms handling and machine modelization are managed within the Relational Database Management System Ingres. Later, MySql was introduced with the RDB archiver. ? To enhance the software engineering process, the UML modeling language was progressively adopted during the control system development cycle. CENTRAL SERVICES The basic services to be provided within the control system are implemented according to different strategies: ? For equipment configuration, an important objective since the very beginning is to provide a tool for end users, even not Epics aware, for configuring equipments with their operational characteristics (addresses, thresholds, software and hardware limits, scaling factors ...).  Data are stored in a database from which the so-called genIOC program extracts data to generate the Epics substitutions and dbs, connections and sequencer files.    Fig. 2: Automated generation of Epics files from database. ? Machine modelization:  A specific database stores all data required for tuning the machine by high level applications: it implements the accelerator lattice according to a hierarchy, associating beam optics able to be applied. Therefore, a gateway program extracts data to generate .xdxf Xal compliant files for on-line use.  The database also integrates for each beam accelerated different set of values: theoretical (exported from the CEA-IRFU TraceWin code), provisional (either from theory or extrapolations from previous tunings), archived (prior settings) A specific GUI tool has been developed for the off-line management of this machine modelization paradigm. ? Alarms management is a homemade specific development to be coherent with the existing tool already in use at Ganil. Alarms configuration is stored in an Ingres database which also archives alarm occurrences. During operation, a Java monitor program catches events from the Channel Access monitoring mechanism and formats the alarm messages. Then, a Java server archives these alarms in the database, also dispatching the messages to different Java/Xal programs for display as a continuous stream.  ? The archiving service is the standard RDB archiver with the archive engines feeding a Mysql database, clients being the CSS databrowser for data retrieving. To enhance performances, two databases instances replicated are used (one for insertion and one for consultation). ? The implementation of an e-logbook for operation makes use of the j5 suite from  Saint-James J5 software company, first evaluated within the Ganil operational environment and now used in production. EQUIPMENT INTEGRATION First Validations Beam tests performed at Saclay gave the opportunity to validate the first equipment interfaces, as presented in [6]:  ? Power supplies communicate with the control system using the Modbus-TCP protocol. ? Acquisition of beam current using Faraday cups (as well DCCTs) is performed either using a slow ADC or a set of two units for “fast” acquisition up to 1,2 MSamples/sec (VME ADC Adas ICV 178 coupled with the synchronization and buffering VME Adas ICV 108). ? Slits as well as beam profilers are handled using the Modbus-TCP protocol and then a gateway to Modbus-RTU for accessing the devices. ? The deuterons source control implies a set of different specific devices: magnetron (VME ADC and binary inputs/outputs), impedance adaptation (VME ADC, DAC and binary inputs/outputs), pulse generator (stream device above TCP-IP), gaz injection (stream device above RS232). ? Transverse emittance measurement is handled by a specific VME crate. Besides standard ADC, fast ADC, binary and DAC boards, it integrates dedicated controls for high voltage ramping (ISEG 202 M) and pod motion (OMS MaxV 4000s).  Current Developments ? Handling of equipment addressed through PLCs:since the early beginning, Siemens PLCs are interfaced with the control system using the Modbus-TCP protocol, so allowing controlling the vacuum and beam interlocks for the deuteron beam production tests. Within a wider scope, the objective of this development is to provide a tool able to generate PLCs based devices from the PLCs data bloc description, according to predefined types of equipment (insertion devices, vacuum gauges, motor controls ...).This tool, genAuto, coupled with the genIOC generation program is currently under test within a prototyping environment. Proceedings of ICALEPCS2013, San Francisco, CA, USA MOCOAAB03Project Status ReportsISBN 978-3-95450-139-79 Copyrightc ○2014CC-BY-3.0andbytherespectiveauthors? Time of flight measurement: specific pick-up devices developed at Ganil will allow calculating the beam energy from the time of flight inside the high energy beam line after the Linac (through phase measurement). The system is interfaced to the controls using a Modbus/TCP link and the development is in its final phase. ? Beam Losses Monitors: the IFIN-HH laboratory (Bucarest) is in charge of the work package for the Spiral2 BLMs while the controls are jointly managed with Ganil [7]. For activation prevention (out of the scope of the control system), beam stops can be generated from signals coming from the 32 detectors; for the thermal protection of the machine, signals are also sent to a VME crate housing a Caen V1495 FPGA board. It runs an Epics IOC to calculate losses, handle thermal thresholds and scaling coefficients according to the beam to be currently accelerated. The development of the VxWorks and Epics drivers are sub-contracted to Cosylab.    ? In order to measure the bunch length and to set the bunchers upstream the Linac, a fast coaxial Faraday cup will be installed. Signals are sent to an Agilent DS9404A oscilloscope running Windows interfaced from an IOC using the asyn driver. A CSS/BOY operator interface allows getting a remote control and displaying the computed values resulting from the measurements. Data will be also read by high level applications for the cavity tuning. Figure 3: CSS/BOY based remote oscilloscope interface. ?  Controls of the RF solid state amplifiers: the RF rebunchers and Linac cavities will be driven by 20 kW solid state amplifiers provided by Sigmaphy company. The 32 amplifiers are interfaced with the control system by a PLC gateway centralizing all interfaces and command. Two major use cases are defined, one for the operation to provide a global view of all the amplifiers and the second for RF specialists ; as this last one requires to read a lot of data, a special mechanism able to dynamically launch IOCs has been set. The GUI interface is written in CSS/BOY. ? RF controls will imply amplifiers, PLCs for security care and a low level RF VME based specific subsystem for regulating the accelerator field and tuning the frequency within a closed feedback loop [8]. A first prototyping environment was installed at Ganil in June 2012 around one buncher cavity and allowed to get a first feedback on the architecture and then to improve performances. A second test period is under consideration for a deeper investigation within the control system up to the high level application software interfaces. OPERATOR INTERFACES Definition of a GUI Chart To provide as much as possible a coherent user interface independently from the relying technology, a graphical chart was edited, with both implementations for CSS/BOY and Java/XAL applications. The chart first specifies the use of colours, fonts. Then, it defines the display of editable/no editable text fields, alarm borders representation, menus, behaviour when PVs are disconnected.  Furthermore, representation of defaults and status words are standardized, based on the software layer implementation previously defined in [9]. Lastly, “good practices” are advised and an implementation is proposed within an .opi (CSS/BOY) and an .app example (Java) files.  Use of CSS/BOY The first supervision screens developed for the project were in EDM. Therefore, it allowed providing GUIs for the beam production tests performed at Saclay with the deuteron source and low energy beam line controls; also, specific developments for beam diagnostics were delivered within this tool. As the CSS development environment was emerging, it was decided to evaluate this technology and first applications based on CSS/BOY were prototyped within different contexts such as the RFQ amplifier test bench. Coming from the first promising feedback, it was decided to go further this way and the investigation was extended to provide to the project the so-called CSSop suited for the Spiral2 operation, with a dedicated configuration and environment as well as restricted limitations for operators.  Figure 4:      CSS/BOY LEBT 1  synoptic,      within     a  predefined framework with the ability of displaying  either a status/default tab or a command purpose one.  MOCOAAB03 Proceedings of ICALEPCS2013, San Francisco, CA, USAISBN 978-3-95450-139-710Copyrightc ○2014CC-BY-3.0andbytherespectiveauthorsProject Status ReportsCSS/BOY synoptic will be considered as supervision GUIs for operation, in an interactive way. Beside of that, a prototype is currently envisioned for providing a general synoptic of the whole accelerator, spread out over four TV screens in the main control room. Xal Integration Tuning such a complex machine requires high level applications for algorithms implementation with reference data stored in a coherent and structured design. The first choices for these developments were to perform them in Java and, according to the existing Xal environment developed by SNS, to define a Spiral2 suited framework derived from Xal, now OpenXal based. It is now used not only for high level applications, also for control and command of equipment when the scope of the application goes further than the supervision needs. Figure 5: Xal based application for beam analysis. The first applications developed within this schema are now operational and some of them were successfully tested at Saclay with the deuteron beam:  general purpose handling tool, beam optimization, analysis at the beam source output, beam emittance limitation, profilers display, on-line management of sets of values and configuration of beam optics...  A major application still in development is the cavity tuning application interacting with the RF components whose settings are defined from different diagnostics measurements (position, bunch length ...). Also a set of several GUIs related to the Machine Protection System [10] is under development: general control and consistency between the beam settings and the MPS based PLC system [11], beam power progressive increase, beam losses display, interlocks interface, macro pulse handling, beam trajectory visualization. To structure developments, software tools have been defined: pdf viewer integration, Xal node selection, implementation of swing components (slider, alarm, textfield, toggle button, button, check box label...) associated with a Channel Access name, panels to implement basis elements (profilers, magnet power supplies, slits, Faraday cups ...). Java applications adopt the Nimbus look and feel and are compliant with the Spiral2 GUI chart. NETWORK The network architecture defined by the global computing infrastructure group integrates the different needs among which one concerns the control system. Therefore, different vlans have been considered : general controls (central server, GUIs, IOCs), PLCs, power supplies, general field bus, profilers and a last one gathering PLCs in charge of the cryogenic of the cavities and LLRF VME based systems (to provide the frequency tuning system within a quite autonomous environment). On the VME IOCs, this configuration is implemented using the two Ethernet ports of the MVME 5500 CPU, one being on the general controls vlan while the second one is attached to the appropriate dedicated vlan. CONCLUSION Most of the components of the Spiral2 control system are either now available or under development. The objective remains to be on time with the project milestones, having also to move from the development and preparatory phases to the installation and then commissioning ones, and this is surely the difficult but exciting challenge to aim for the coming times. REFERENCES [1] R. Ferdinand et al. “Process of construction and installation of the Spiral2 accelerator”, Ipac 2013, Shangai, China, May 2013. [2] D. Touchard et al, “The Spiral2 command control software organization and management“, Icalepcs 2009, Kyoto, Japan, October 2009.  [3] E. Lécorché et al, “A Small but Efficient Collaboration for the Spiral2 Control System Development”, this conference. [4] E. Lécorché et al. “Overview of the Spiral2 control system progress“, Icalepcs 2011, Grenoble, France, October 2011. [5] L. Philippe et al, “Spiral2 control command: first high level applications based on the Open XAL library“, Icalepcs 2011, Grenoble, France, October 2011. [6] F. Gougnaud et al. “The implementation of the injector Spiral2 control system“, Icalepcs 2011, Grenoble, France, October 2011. [7] C. Haquin et al. “Development of the thermal beam loss monitors of the Spiral2 control system“, this conference.  [8] D. Touchard et al. “The Spiral2 radiofrequency command control“, Icalepcs 2011, Grenoble, France, October 2011. [9] C. Haquin et al. “Spiral2 control command: a standardized interface between high level applications and Epics IOCs”, Icalepcs 2011, Grenoble, France, October 2011. [10] L. Philippe et al, “User interfaces for the Spiral2 Machine Protection System”, this conference. [11] C. Berthe et al, “Machine Protection System for the SPIRAL2 facility”, this conference.  Proceedings of ICALEPCS2013, San Francisco, CA, USA MOCOAAB03Project Status ReportsISBN 978-3-95450-139-711 Copyrightc ○2014CC-BY-3.0andbytherespectiveauthors

The SPIRAL2 control system progress towards the commissioning phase

Abstract

Similar works

Full text

Available Versions

HAL-CEA

HAL-IN2P3