DISTRIBUTED TIMING DIAGNOSTIC APPLICATIONS

The CERN timing system delivers events to the accelerator complex via a distribution network to receiver modules located around the laboratory. These modules generate pulses for nearby equipment and interrupts for the local host. Despite careful planning, hardware failure and human error can lead to anomalies within the control system. Diagnosing such errors requires a formal description of the logical and topological timing layout. This paper describes the design and implementation of a suite of timing diagnostic software applications which allow users to quickly diagnose and remedy faults within the CERN timing system. TIMING SYSTEM OVERVIEW At the heart of the timing system is the Central Beam and Cycle Manager [1] CBCM which may be considered as a scheduler for the CERN accelerator network. The CBCM distributes timing events over a network of cables to timing receiver cards located near end user equipment. On start up, each card is configured with control values which specify actions that should be performed for each accelerator cycle and which events trigger them. Examples of control values are the counter delay, start, clock, mode, output channel, output enable state etc. A counter output may in turn be used to start other counters forming multiple chains of dependencies before finally triggering end user equipment. These counter chains depend on the physical cabling, on static and dynamic configuration data and on the machine cycles being executed. An example of equipment that relies on such a chain is an extraction kicker. For a given accelerator cycle with the beam destination the kicker sends the beam to, the kicker must pulse, but in other cycles with a different destination it does not. In this example, a counter might be loaded and started by a CBCM extraction timing event. Its output may be used to start timing chains in the extraction process of an accelerator and elsewhere. The next counter in the kicker extraction chain may be programmed to count revolution frequency ticks. Its output may in turn start a third counter counting RF ticks, before finally pulsing the extraction kicker. This is typical of the situation found in extraction and injection timing systems.