CERN Accelerating science

Slow timing - requirements

Issues

• Need to establish how many events we should allow for
• Slot size 1 ms. 10 ms was discussed but didn't engender much enthusiasm.
• No of events per slot. 3 per slot was just about OK for K-modulation at LEP... for the LHC?
• Latency - is 100 ms (LEP) good enough?
• Reliability - can we tolerate missing event delivery (NO). Do we need acknowledgment of receipt?
• Separate events for both rings?
• Do we need to synchronise the millisecond tick with the SPS?

Events

• Key requirement: The system shall allow the manual asynchronous send of events... we need an interface either to the CTG or the CBCM to allow us to send events (and or telegrams) as and when required. This could be a start ramp event or a synchronous set event for the power converters, RF or whatever. The interface should be very reliable and the latency should be low and predictable.
• Events should be programmable. At injection and in the ramp, for example, events should be sent out according to a pre-defined sequence (or table). E.g. events to RF, events to instrumentation  for synchronous measurements in ramp or squeeze.

Events shall include:

• start ramp
• injection warning - RF, BPM
• start, stop, suspend, resume squeeze
• RF events during filling, ramp (200-400 MHz) and before physics to synchronise rings. In general a lot simpler than the SPS (Philippe). The SPS has something like 400 events defined (dampers, 100, 200, 400 MHz systems etc..). Will trigger functions controling transverse feedback and longitudinal feedback functions during the injection process.
• stop ramp - possibly obsolete, suspend ramp, ramp abort, power abort
• synchronised set + perhaps repeat, step back functions
• synchronised collimator set
• beam dump
• post mortem freeze, note need for different timescales depending on equipment...
• measurement acquisition - measure orbit, measure beam loss synchronised measurements acquisition
• communication with experiments
• K-modulation
• wake-up calls

c/o JL

Enable LHC Injection. API call.
The default behaviour is NOT to send the beam to the LHC. The HLLSA does the requesting of the CPS Batches, Bucket Ring etc but that is not all.
After making the final measurements on the SPS flat top it then can do either nothing and the SPS beam is dumped, or, it can enable the LHC
injection timing and the beam is delivered. The SPS BEAM-OUT event clears all requests so that in the Next SPS super-cycle, if you want the
beam you must repeat the whole process of requesting the Ring Bucket etc. The way that the beam is dumped in the SPS can have two variants
that need to be decided ...

Variant 1: The SPS cycle always starts with the dump destination, and only when the API call is made to enable the LHC transfer is the
destination changed to LHC.

Variant 2: The SPS cycle starts with destination set LHC. If the Injection forewarning has not been sent to the LHC (Because you didn't call the API routine to enable it), and the SPS extracts towards the LHC, the BIC will dump it.

In the second variant its simpler for me, but we run into the BIC interlock. In the first variant we avoid running into the BIC interlock by having another layer that dumps the beam in the SPS.