MP3 weekly summary - LHC commissioning

Download Report

Transcript MP3 weekly summary - LHC commissioning

MP3 weekly summary
– issues and follow-up
6th April 2010
M. Zerlauth for the MP3-CCC shift crew
0v1
Summary of the events during past weeks
• Few additional issues discovered and solved by interventions done during
the week
• Dominating issue is still with unexplained RQD/F trips in S12 and S78
Circuit(s)
Problem
Intervention in field Remarks
RCO/RCD.A56B2
Tripped again 3 times during
the week (total of 8 now!)
Not yet done…
In all 8 events RCO goes first, FGC buffer
indicating an overvoltage trigger (1st level)
RQD/F in S12 and S78
Total of 4 (yet unexplained)
trips
NO
Analysis still ongoing
RQT12.R4B1
Problem with output stage of
power supply
DONE
Trip due to a failure of PC. TRG
OUTPUT STAGE POWER SUPPLY
RB.A34 / MB.A24R3
Heater Power supply
discharging
DONE
Problem appeared on Saturday but
repair postponed to Sunday
RQX/RTQX2.L5
Temperature sensor problem
YES, but not fixed?
Sensor DXEX02_03L5_TT891A faulty,
no repair but only ‘touching’ cables
RB.A78
Broken micro-switch after
opening of EE
YES
Opening of switches to accelerate
current decay after loss of CRYO
RQX R8, L8 and L1
Tripped when going from
stand-by to OFF
NO
Known ‘feature’, could maybe be solved
through procedure by EPC
RQTD/F
Tune correction currently
limited by lower QPS
thresholds >= 50A
QPS firmware / YES
Superimposition with B2 correction;
proposal to increase 50A -> 75A
[email protected]
RCO.A56B2 /RCD.A56B2
•
•
RCO.A56B2 (and consequently RCD.A56B2) tripped another 3 times during the
week, total of 8 trips now in the past 2 weeks
Power supply module of RCO.A56B2 to be exchanged (indicating a trigger
through over voltage (1st level) -> Thursday?
[email protected]
Summary of the RQD/F events so far
• During past days 4 yet unexplained trips on RQD/F circuits of sectors 12
and 78 were observed as shown in the summary below (completed by
the two trips on Tue 30th of March due to the SPS main power supply)
Event time
Sector
Circuit current
PIC history
Switch
timestamps
Other QPS buffers
30/03 at 08h49m45s
S81
Ramp with
beam @1900A
RQF AND RQD @
08.49.45.949
RQF @ 947
RQD @ 947
DQAGMD @ 08.49.46.404
DQAGMD @ 08.49.46.499
30/03 at 08h51m17s
S12
Ramp with
beam @2100A
RQF @ 08.51.17.735
RQD @ 08.51.17.736
RQF @ 731
RQD @ 731
01/04 at 05h05m03s
S12
Flat top with
beam @ 5300A
RQF @ 05.05.03.176
RQD @ 05.05.03.178
by GPM
RQF @ 173
RQD @ 173
01/04 at 08h43m06s
S12
Injection, no
beam @ 750A
RQF AND RQD @
08.43.06.141
RQF @ 137
RQD @ 137
02/04 at 18h49m13s
S12
Standby, no
beam @ 350A
RQF AND RQD @
18.49.11.362
RQF @ 357
RQD @ 358
04/04 at 02h49m48s
S78
Flat top with
beam @ 5300A
RQF @ 02.49.48.756
RQD @ 02.49.48.757
RQF @ 754
RQD @ 753
DQAGMD @ 02.49.49.290
DQAGMD @ 02.49.49.290
[email protected]
‘Typical’ event sequence
All 4 events have an (almost identical) event sequence, ie
● PIC receives a Quench/FastPA signal from QPS (event sequence in PIC is
the typical signature of an event originating within QPS)
● RQD/F trip simultaneously (but for 1 event where the GPM is ‘faster’
than the RQD quench signal)
● RQD and RQF switches open simultaneously and typically 3-5 ms
BEFORE the PIC records the quench signal, ie confirming that the QPS
quench loop is broken (common QPS quench loop for RQD/F circuits!)
● No indication of changes in Discharge Request Loop, thus trip must be
internal to QPS (no other means of opening the switches from outside)
● No other QPS PM buffers (apart from global busbar for 2 events and
nQPS buffers which are well after the initial trip and a result of switch
OFF of circuits) – Trip of 2nd QPS board?
[email protected]
The RQD/F.A12 ‘hump’
● Available data and event sequence seem to indicate triggers to origin within
the QPS system, reason after loads of analysis however still unclear
● In sector 12 (where we had 3 oo 4 trips), busbar detector is showing
repetitive noise patterns, some peaks up to 1.1V/550ms
● Further investigation with help of QPS experts needed as to the real origin of
the trips…
[email protected]
FIN
Machine Interlock Systems
[email protected]