Login

HI-ECN3 Machine Protection #3

→ Europe/Zurich
30/6-019 (CERN)

30/6-019

CERN

20
Show room on map
Hide

A. Colinet, D. Nisbet, I. Romera, T. Zickler, J. Bernhard, F. Velotti, F. Metzger, M. Saccani, D. Belohrad, M. Fraser, J. Ridewood, F. Stummer, N. Charitonidis, A. Gorn, K. Li, M. Parkin, C. Zamantzas, A. Huncikova, A. Goldblatt, D. Wasik, R. Mompo, F. Roncarolo

 

Review list of actions

ACTION: Kevin + James: Fix user and destination names for operation post-LS3

ACTION: MF/FV to start a draft of BLM requirements and share it around

ACTION: OP to add BLMs and BSI to SIS, discussed in adhoc meeting https://indico.cern.ch/event/1528744/

ACTION: Francesco to provide list of PCs where fast response is required from the WIC

H8 protection

  • It is confirmed that there will be no parallel operation of SFTSHIP and SFTPRO to H8. This requires a reconfiguration of the DC wobbling magnets.
  • The consequence of a failure would be damage to BEND1
  • A BLM on the H8 beam line will be added. Action: MF/FV/LN: add it to the BLM requirements + validate with integration team + BLM team (difficult access if replacement is needed). Action Luigi: check sensitivity to this failure mode
  • LOKN (personnel protection) does not know about SPS beam intensity, it does not implement intensity limitation. Also LOKN does not know about the beam energy.

LSS4 bumpers failure

  • David confirms that the PC regulates at the last played value if no LSA settings are defined for a given user. In this case the PC continues providing the user permit to the BIS. This assumes a test in these conditions: no LSA settings + PPM regulation + non-PPM threshold
  • The requirement for multiple thresholds along the cycle triggers new questions: how would the non-PPM thresholds work in these conditions. Action: OP+ABT+EPC see how this issue can be solved, and write specifications in EDMS 3253361

TT23/TT25 PCs on SFTSHIP cycles

  • David stressed that if no LSA settings are defined for a user, then the PC regulates at the last known value, which might not be Imin.
  • The failure case is an SFTSHIP beam that would be mistakenly steered to TT23 or TT25 and reach the targets.
  • It is proposed to add Imin interlocks on 2 more PCs: one in TT23 and one in TT25. Is this really bringing added value?

 

BID limits and the need for BSI interlocks

  • Rui compiled BID intensity limits in a table. Action Rui+Miguel: confirm information about the TAX
  • Federico and David confirmed that the BSI could publish data at 100ms post-LS3. This required a configware update. Testing this feature before LS3 is not feasible. Nevertheless it is proposed to check the validity of the data using logged data. Action Kevin: to check the logged BSI data. Federico confirmed that scripts might be reused.
  • Action Matt: to write requirements for BSI post-LS3
  • Action OP: check SIS latency
  • It is proposed to add 2 BLMs next to T2 and T6 as part of NACONS. Action Matt: follow-up with Christos to confirm requirements, and allow BI to finalise cabling requests.

 

Timing user mapped to wrong timing destination

  • Requirements agreed upon between MPE/ABT/OP/EPC and described in EDMS 3253361.
  • Christos proposed to also used the first three running sums of the BLMs to cover the user/destination error. Action Matt: Follow-up with Christos to understand how that would work.

 

BLM specifications 

  • BLM requirements needed by BI to freeze the cabling requests and functional specifications.
  • Action Matt, Francesco, Laurie: Finalise the requirements

 

Timing failure

  • GMT monitor interlock connector to SPS ring BIS
  • Watchdog feature on BLMs is configurable, not necessarily 1.2s.
  • BIS can use default failsafe value in case no timing is received for a certain amount of time.
  • David explained that timing is received by a gateway that then propagate information to tens of FGCs. In case of timing failure, it's unlikely that a single PC would stop receive timing. Instead multiple PCs would be on hold and regulate at the last known value. In this case, no interlock is raised by the power converter. The dump is likely to be triggered by beam losses.

Energy Error

  • Not presented, though discussed in smaller committee here: https://indico.cern.ch/event/1556124/

 

 

There are minutes attached to this event. Show them.
Powered by Indico v3.3.7-pre