Vacuum controls and interlocks

The vacuum control system is, in most cases, a subset of the general control system of an accelerator. As such, it shares the architecture and communication infrastructure of the main control system. Considered as a ‘slow process’ to control in the frame of accelerators, the vacuum control system can be built using commercial industrial controllers (PLCs). A data driven approach allows for changes in configuration without changing the software code but at the expense of a solid database. Modelling the equipment allows for easy adaptation of a variety of control units with the same functionality but different physical interfaces. It also allows for a uniform display of the available data and status values. Interlocks are required to protect the vacuum equipment itself against abnormal conditions, but also to protect other systems, like RF, which need a good vacuum to operate. They are an integral part of any vacuum control system

A survey of the use of database management systems in accelerator projects

The International Accelerator Database Group (IADBG) was set up in 1994 to bring together the people who are working with databases in accelerator laboratories so that they can exchange information and experience. The group now has members from more than 20 institutes from all around the world, representing nearly double this number of projects. This paper is based on the information gathered by the IADBG and describes why commercial DataBase Management Systems (DBMS) are being used in accelerator projects and what they are being used for. Initially introduced to handle equipment builders' data, commercial DBMS are now being used in almost all areas of accelerators from on-line control to personnel data. A variety of commercial systems are being used in conjunction with a diverse selection of application software for data maintenance/manipulation and controls. This paper reviews the database activities known to IADBG

First Experience with Control and Operational Models for Vacuum Equipment in the AD Decelerator

Control and Operational models for Vacuum Equipment have been studied at CERN for several years [1]. A prototype implementation was tried out on ion gauges in LEP followed by a full-scale implementation for all vacuum equipment to be controlled in the newly built AD ring. In order to meet the tight time schedule, the existing hardware and software infrastructure of the PS complex has been used. The model server was built on top of this infrastructure. This has introduced some restrictions with respect to a full implementation of the models, but made the server available for all vacuum equipment already installed in the various accelerators which are connected to this control system. In order to test the server, a simplified man-machine interface has been created. This interface presents the available acquisition and control values in a very homogeneous way to the operator, making the advantage of the chosen model approach evident. It also makes additional diagnostic information, previously unavailable, accessible to the vacuum operators

Control and operational models for vacuum equipment

perational models which describe the behaviour and the physical values associated with the vacuum equipment as seen by an operator have been studied for some time at CERN. Recently, they have been completed by control models, which define in a formal way the data structures required to access the physical values described in the operational model. The control models also define the operations that an application program has to send to the vacuum equipment to modify its state. Object Modelling Techniques (OMT) have been used to formalise the description of the models. In order to test the validity of the concepts, we have made a working prototype in the LEP accelerator. This prototype is being built on top of the CERN SL-Equip equipment access package and uses the "cdev" C++ library, developed at TJNAF, for the interface to application programs. SL-Equip is used for data transmission between front-end computers and vacuum equipment. We use the "cdev" networking facilities to communicate between the workstation and the front-end computers, and the "cdev" generic server as the framework for implementing the vacuum controls software. These packages were used in order to minimise the required software investment, but also to prove that these models are hardware and software independent

The AD Vacuum System: Construction and Commissioning

CERN has built a new experimental facility, called the Antiproton Decelerator (AD), by transforming two existing machines: the "Antiproton Collector" (AC) and the "Antiproton Accumulator" (AA). To achieve adequate beam performance once the antiproton beam is decelerated to its final value of 0.1 GeV/c, it was necessary to lower the average pressure by nearly two orders of magnitude. For this purpose, a large number of additional pumps were installed and a very careful preparation was applied to a variety of special machine equipment which, in its original construction, was not designed for ultra-high vacuum operation. An important improvement in the outgassing rates was achieved through an extended, mild bake-out of tanks and vacuum vessels containing large amounts of ferrite material and multi-layer thermal insulation. This paper describes the necessary modifications of the vacuum system and in more detail the various steps taken to obtain the required pressure in the low 10-10 mbar range. It will also report on the unexpected difficulties which were encountered by re-using vacuum components that were not initially designed for bake-out

DESIGN AND FIRST IMPLEMENTATION OF A VACUUM DATABASE FOR LHC MAIN RING AND TRANSFER LINES

Abstract During the construction of LHC, much information about vacuum equipment is scattered at different levels and activities have to be shared and not duplicated. To gather this data, a completely new database is designed, in relation with other existing databases and personal data storage. An inventory and analysis of the data required by the users has been done. Disparate types like history of existing equipment, coming from an existing Oracle Database, test results, drawings and studies need to be stored. Different groups of people are involved and a user interface will provide access to an overview of LHC activities for the vacuum group. This paper presents the results of the analysis of the user requirements and some ideas how to implement them