Front-end Computing in the LEP2 RF System
L. Arnaudon, A. Butterworth, E. Ciapala
CERN, CH-1211 Geneva, Switzerland
Abstract
Since 1996 the Large Electron Positron Collider (LEP),
has been running at beam energies above the W+- production threshold, following the LEP2 energy upgrade which
involved the installation of a large superconducting (SC)RF system. Much of the intelligence required to run thisRF system resides in the front-end machines of the RF
control system, and many enhancements have been madeto meet the increasingly complex requirements of the newSC cavity equipment. A large number of G64-based crates
containing the equipment interfaces are connected to alayer of VME machines which are in turn connected to theaccelerator control system via the LEP machine Ethernet.
New hardware and software has been installed in theVME systems to monitor rapidly-changing parameterssuch as oscillations in cavity fields and vacuum outbursts
in the cavities' main power couplers. A closed loop system
has been implemented for automatic RF conditioning ofcavities and couplers. The VME/G64 communications
interface has been upgraded, leading to improved
reliability. A new touch-screen operator interface has been
implemented using the MGR window manager.

controller is either a Z80 MPU with no operating system,
running a single interruptible task, or a 68030 single
board computer (SBC) running OS-9. Both types of EC
are ROM-based.
2.2 Front-end machines
Each SC RF unit has up to 27 ECs, depending on its
exact configuration. These ECs are linked via a General
Purpose Instrumentation Bus (GPIB) to the "Data Manager"(DM), a VME chassis with a 68040 SBC running
disk-based OS-9. The DM performs message passing
between the ECs and the UNIX application software
running on workstations in the control room. It also hosts
numerous local applications, such as the unit switch-on
procedure, which are usually launched via remote
procedure calls (RPCs) from the control room software.

1 Introduction
The LEP2 superconducting cavity RF system [1]consists presently of 240 accelerating cavities powered by
32 klystrons, each capable of delivering 1.3 megawatts at
a frequency of 352 MHz. Power is supplied to these klystrons by 16 high voltage power converters.
Each klystron drives up to 8 cavities, mounted incryostat modules each of which contains 4 cavities. An
assembly of 2 klystrons and their cavities, a high voltage
power converter and all the associated high and low
power electronics is termed an "RF unit". There are 18
such SC cavity units (including 4 "half-units" which share
2 power converters) in addition to the 6 remaining roomtempera-ture copper cavity units of the LEP1 RF system[2].
2 Controls structure
2.1 Interfacing to equipment
The fact that each type of RF equipment is replicatedmany times imposes a similar layout for the controlsystem (Fig. 1). Each equipment (cavity, cryomodule,klystron, etc.) has an associated "Equipment Controller"(EC) chassis which contains the interface electronics
connected to the equipment. Each EC is a G64 system
whose function is limited to reading and setting values
and surveillance of its associated equipment. The crate

Fig. 1 Structure of the RF control system
3 Data manager hardware
The DM is a VME chassis with an Eltec E17 single
board computer connected to the LEP machine network
via its on-board Ethernet interface. Two Greenspring IP488 GPIB interfaces provide communications with theEquipment Controllers. A battery-backed SRAM board
gives non-volatile storage for certain configuration
parameters. Two ADC boards provide 64 differential
analogue inputs for fast acquisition (1 ms sample rate) ofcertain signals. A local hard disk is used for booting andfor storage of program binaries and data.
4 Operating system and network
The DM uses the OS-9/68000 operating system fromMicroware. All program source code is resident on aUNIX fileserver and accessed via the Network File
System (NFS). File access between DM local disks isfacilitated by using the OS9-NET system.

response cycle, and so are implemented as backgroundprocesses run under control of a task handler. These
include tasks for switching various parts of the unit on andoff, which may take many seconds or minutes, and tasks
for changing the settings of high voltage and accelerating
field. There are also slow functions to start and stop RF
conditioning of the unit and to adjust the cavity tuning tocounteract ponderomotive oscillations in the cavities [5].
6 Surveillance
Two background processes survey continuously thestatus of the RF unit: a local survey task and a fault
diagnostic task.
6.1 Local survey

Fig. 2 Data Manager software layout
5 Communications and command execution

The local survey process loops continuously, retrieving
survey data from the ECs, storing it locally in sharedmemory in the DM and sending it via RPC to a dataserver resident on a UNIX workstation in the control
room, from where it is made available to logging andfixed display applications.

5.1 GPIB

6.2 Fault diagnostics

The DM GPIB interface has recently been completely
revised and now uses Greenspring IP-488 IndustryPackboards, with the IBF file manager software from ArkSystems, instead of the slave processors originally used in
the LEP1 DMs [3]. GPIB requests from all processes arequeued before being passed to a GPIB handler process
which performs the command-response transaction, detecting and clearing error conditions and ultimately rebooting
ECs if necessary. These modifications have led to a considerable improvement in overall reliability.

A background process acquires readings of the cavity
fields via an ADC card in the DM chassis. The fault
diagnostic task monitors continuously these fields, alongwith the data collected by the local survey task. Any
abnormal status or drop in cavity field triggers adiagnostic procedure which sends an alarm to the CERN
central alarm system [6] and optionally launches a task
handler comm-and to restart the unit. The field readings
are taken at a sampling rate of 1kHz, allowing any
ponderomotive field oscillations (which in the LEP2
cavities have a frequency of around 100Hz) to bemonitored and an alarm generated if excessive oscillations
are observed.

5.2 Access from LEP operations software
The primary entry point for communications between
the UNIX control room software and the DM is a serverusing the CERN SL-EQUIP package [4]. A server is also
provided for older applications using direct TCP/IP socketconnections. Three command interpreter processes handle
different types of command-response transactions:• Equipment accesses: the message is passed directly to
one or more ECs. This interpreter also executes somemore complicated equipment access procedures whichmust, however, execute quickly enough to return
within the time allowed for a single commandresponse transaction.
• Data manager commands: the command is processedin the DM itself without accessing any EC.
• Task handler commands: commands to start, stop or
query the status of local tasks ("slow functions").
5.3 "Slow functions"
The "slow functions" are command procedures whichtake more time than is acceptable for a single command-

7 RF conditioning of cavities and power couplers
Before being put installed in LEP, and at the start ofeach year's running period, the cavities and other highpower RF components must undergo RF conditioning toelimina-te any contamination present in the cavities which
would lead to bad vacuum and the risk of dangerous
electrical discharges. The conditioning procedure consistsof slowly increasing the RF power while ensuring that thevacuum in the cavities does not deteriorate beyond acertain threshold. The procedure used is shown in Fig. 3.
RF conditioning is characterised by rapid vacuum
outbursts caused by the onset of resonant electron emission known as "multipacting". In conjunction with the fast
cryopumping action of the large cold surfaces inside
the cavities, this leads to short vacuum "spikes" with agrowth time of the order of a few milliseconds. In order tocatch these transients, the vacuum signals are sampled at
a rate of 1kHz by the same background acquisition processthe cavities, and must handle any fault condition which
occurs due to interlocks on the vacuum or cryogenicsystem.
8 Touch screen interface
A new touch screen interface for local operator control
has been implemented using the MGR window manager[7]. MGR is a client/server system which enables theconstruction of simple graphical user interfaces with alook and feel similar to that of X/Motif. The touch screeninterface can also be run on a remote OS-9 station since
all its equipment accesses pass via the socket commandresponse server. MGR also has the facility to display on aremote X-terminal. A sample screen is shown in Fig. 5.

Fig. 3 Procedure for conditioning of RF modules
which is used for the cavity fields (Fig. 4). Since theconditioning program loops much more slowly than this, a"peak hold" is performed inside the acquisition task.

Fig. 5 Example panel from touch screen interface
References

Fig. 4 RF conditioning software
The conditioning program must also take into accountmany other parameters, such as field and power limits,and radiation measurements from ionisation chambers
attached to the cavity modules to monitor dark currents in[1] C. Wyss (ed.), LEP Design Report, Vol. III: LEP 2,
CERN-AC/96-01 (LEP2) (1996) p. 61.
[2] The LEP RF Group (eds. G. Geschonke, S. Hansen),Status and performance of the LEP RF system, Proc.
XIV Internat. Conf. On High Energy Accelerators,
Tsukuba, Japan, 1989 (Gordon and Breach, NewYork, 1990), p. 779 and CERN-LEP-RF/89-53.
[3] E. Ciapala and P. Collier, A Dedicated Multi-Process
Controller for a LEP RF Unit, Proc. 1989 Particle
Accelerator Conf., Chicago (1987) pp. 1583-1585.
[4] P.Charrue, Accessing equipment in the SPS-LEP
controls infrastructure, SL/Note 93-86 (CO), (CERN,1993).
[5] D. Boussard, P. Brown, J. Tückmantel, Electroacoustic instabilities in the LEP2 superconducting cavities,
CERN-SL/95-81 (RF) (1995).
[6] C. A. Cameron, User Interaction with the CERN
Alarm System, SL/Note 93-48 (CO), (CERN, 1993).
[7] W. Ocker, "SYSTEM-PAK I/MGR", Reccoware
Systems, Rapperzell (1995).