This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.
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
- Dump fired by Beam Interlock System
- Dump fired at operator request. via BIC, or via dedicated channel.
- Simultaneous dump request
- Dump throws beam permit before injection
- Inject and dump immediately, inject and dump after x turns demanded by
operator
- Diagnose faults
- Power cut, recovery from power cut. UPS, surveillance.
- Dump fires correctly but POC finds a a fault. Redo dump?
Alternative Use Cases (more the concern of Machine Protection)
- Beam dump doesn't fire, loses energy tracking
- Orbit excursion at IP6 get too big.
- Beam in abort gap
- 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.