CERN Accelerating science

LHC Beam Dump 

Commissioning stuff - December 2007

Input: Etienne Carlier, Brennan Goddard

Version one - XPOC requirements July 2007

For further discussion of POC and PM see
http://proj-lbds.web.cern.ch/proj-lbds/documents/Relatedmeetings/POC%20and%20postmortem/POC_01.htm

• Expert app IPOC - resp EC
• Tracking - expert ap - resp EC
• State control - OP - impement FSM to cover operational states - invoked by sequencer (state transtions - mode, beam type, history dependent - have to be carefully defined. Validation dump with pilot if necessary etc.
• No settings.
• Post-mortem - pushing to PM server whenever...
• Look up table - hardware versus database source
• XPOC
• Logging - standard stuff
• Alarms - standard
• Fast waveform acquisition IPOC - sbs logging + OASIS channels
• Monitoring/surveillance

System components

• Pulsed extraction kicker magnets (MKD) between Q4 & Q5 - fast horizontal deflection. Kicker strength has to track energy, calibration established during set up and then locked in. No possibility for operations to adjust. Is there tracking during ramp down? What if sector 6-7 quenches?
• DC septum magnets - middle of IR6 vertical deflection into beam dump channel. Driven by standard power converter control. Ramp functions down loaded in normal operational sequence, however, current surveyed, out of tolerance will provoke beam dump. Expected values established during set-up and then locked in.
• Pulsed dilution kickers
• LHC Beam Dump block (TDE) - passive - some monitoring
• Q4 adds to kick into Septum, current monitored and interlocked. Current in Q4 fixed - watch this.
• TCDS - static, presumably some monitoring
• TCDQ: to track collimators, settings, & control dealt with elsewhere, monitoring of position, temperature
• BI - pickups, screens, BLMs, BCT in extraction line, vacuum....
• Orbit feedback: vital that orbit is controlled within tolerance, beam dump otherwise. Orbit reference to be established with safe beam. Swath of issues addressed elsewhere.

Interfaces

• Machine protection
• Beam/bunch structure - BPM - only during phasing - once a year - cable delays etc
• Revolution frequency from RF -   - synchronisation with abort gap    can adjust delay with respect to arrival of client request but not OP
• Beam energy - critically important, to be provided by BEM. Not controls' responsibility.

Controls:

• PLCs for slow controls
• VME/fieldbus for fast acquisition
• VXE, waveform acquisition, OASIS...
• Synchronized acquisition of measurements
• Timing: dump events, inject and dump events, timestamp

Actors

• Dump specialist
• Operator
• Piquet

Use Cases

1. Dump fired by Beam Interlock System
2. Dump fired at operator request. via BIC, or via dedicated channel.
3. Simultaneous dump request
4. Dump throws beam permit before injection
5. Inject and dump immediately, inject and dump after x turns demanded by operator
6. Diagnose faults
7. Power cut, recovery from power cut. UPS, surveillance.
8. Dump fires correctly but POC finds a a fault.  Redo dump?

Alternative Use Cases (more the concern of Machine Protection)

1. Beam dump doesn't fire, loses energy tracking
2. Orbit excursion at IP6 get too big.
3. Beam in abort gap
4. Loss of computer facilities - BLM front-end down? FGC?

Operations: controls requirements

Dedicated setting up process.

• Standard application for basic control and diagnostics - kicker and septa & settings management
• Kickers: Status Synchronisation, strength, no trim possibilities for operators.
• Septa  FGC plus all associated functionality but current tracked again. Septum: current reference dealt with by us. No trimming outside tolerances.
• Inject and dump application with variable delay - not too close to the next injection to give beam dump a chance to re-arm.
• On, reset, check, validation dump.
• Access: into zone, re-close, check, validation dump, after zone access,
• Record all manipulations
• Test sequences.
• View POC results - check kicker pulse against extracted beam etc. What is the exact sequence of required checks?
• Extraction channel instrumentation monitoring
• BT group confirms that resetting the beam dump at injection takes only 10 to 15 seconds. POC required always?

POC etc [cut from link above]

• Internal (BT) checks - IPOC. Needed for beam permit. Checks done in BT equipment Front-Ends after Beam Dump action, comparing equipment state and measurements with references. No beam required.
• External (CO) checks (needed for beam permit) - XPOC. Needed for beam permit. Checks done by Control System after Beam Dump action, comparing equipment states and beam measurements with references. Beam required for full functionality
• On-request Post-Mortem - PM. Full Post-Mortem performed by Control System following a problem.
• Logging. Periodic storing of key data, or of digested PM data after a dump action.
• Alarms. Intelligent messages to the PCR, with machine-mode and state conditioning.

IPOC

Checks that BT stuff is OK, to enable beam permit (BT responsibility)

– Fault detection in the redundant branches

– Fault detection in the pulsed power circuits

- Raise alarms if things aren't OK

XPOC

Checks that LBDS is OK, to enable beam permit (CO responsibility)

– Impact position and shape of the beam on the absorber block

– Check of the synchronization with the particle free gap

– Losses in extraction channel

– Dumped intensity

– All LBDS system status

– Controls system readiness

– Origin of the dump request

– Operation, beam loss monitor, quench, …

3. What happens where?

- IPOC - BT equipment Front-Ends

- XPOC - Control system process - acting on subset logged or PM data

- PM - Control system process - to be triggered after every beam dump.

Post-Operation Check [XPOC]

After every firing of the beam dump, a series of checks must be performed. Until these are successful the beam dump can not be re-armed.

• What provoked the dump?
• Internal checks
• Check orbit, profiles, synchronisation

The purpose of it is:
– Fault detection in the redundant branches
– Fault detection in the pulsed power circuits
– Check of the impact of the beam on the absorber block
– Check of the synchronization with the particle free gap
– …

For POC information of a dumping action:
– the position of the impact of the beam on the absorber block
• All beam monitors in the extraction and beam transport channel -- For the BIC->TTC pathway, is the latency fixed (e.g. always 2 turns) or
does it vary? Who is looking after this?  I.e. How do we trigger the extraction line beam instrumentation??
• A absolute precision of 1 �s is needed
– the origin of the dump request
• Operation, beam loss monitor, quench, …
• A absolute precision of 1 �s is needed

For POC of a dumping action:
– the voltage levels and status in the Dump Kicker System
• ~ 650 words, 16 bits
– the waveforms of the currents in kicker magnets, pulse
generators and trigger systems
• ~ 300 channels
• A 1 �s resolution is needed for the shape
• A 10ns precision is needed for the rise time

Inject and dump might not require full POC, but before the full monty - fully revalidate the system.

beam dump trigger buffer freeze. - -  levels of PM, intensity dependence, beam permit?

Logging

Logging via CMW publish.

• Waveforms
• Orbit in ring before dump
• Extraction Trajectory in beam dump channel losses and other BI.
• Dump beam profile
• TCDQ settings
• Septa currents etc. etc.
• Kicker voltages etc. etc.
• Diluter parameters
• Vacuum
• Energy, abort gap, RF frequency
• Beam dump - temperatures - thresholds - ready over pressure of Nitrogen - cooling.

With a full set of appropriate correlation and extraction utilities.

Post-mortem

The information returned for a post-operation check will also make up the data fed to the post-mortem system in the event of an external system failure. For an internal system failure the full list of post-mortem data needs to be established.

Distinguish between PM operator (PMO) and PM expert (PME)

Waveform acquisition

• (15) Magnet current waveform - synchronisation checks. Automatic checks plus perusal possible.
• Beam,
• Lots of signals from high voltage generators: magnet. diodes. switches.
• Waveforms: one property logged. Standard pathway - see Andy/RF who have the same problem/solution
• Operator interference on waveform acquisition settings - to be avoided.

Orbit Feedback

Transient orbit - windows on based on BSFlag... feedback ain't going to be on all the time... setup, establish circulating beam etc.

Retriggering (c/o Jan) [red herring]

Following the discussions in the LHC collimation Working Group here some more details on the re-trigger delay of the LHC beam dump kickers MKD (thanks to Etienne who gave me the information):

Detailed measurements of the re-trigger time were made about 1 year go, since then the system has been changed but this is only going to affect the re-trigger time at the lower energies. For energies above about 3.0 TeV Etienne is willing to guarantee a maximum re-trigger time between two generators of 700 ns. Below 3.0 TeV this delay is likely to increase up to a maximum of 1200 ns at 450 GeV – detailed measurements should be made before the summer. For the collimators it is probably the delay at high energies of 700 ns which is the most important and is well known.

The delay measurements were made with a cable length of 40 m between two generators, this is the maximum re-trigger cable length between two generators for the final installation. The delay for the cable is about 5 ns/m, so between two adjacent generators the delay can assumed to be 40 * 5 / 14 = 14 ns. The worst case is probably MKD no. 1 producing an erratic, MKD 2 will then re-trigger after 500 + 14 = 514 ns, MKD 3 at 528 ns etc.