1 / 8

Muon Piquet Report Week 31/32

Muon Piquet Report Week 31/32. Burkhard Schmidt July 31 to August 6, 2012. Muon system summary week 31. Mon day/Tuesday night : Short in chamber M2A 19B Gap C (R3), f use had to be blown. In trying to do so, Matsusada for the A-side tripped

asis
Download Presentation

Muon Piquet Report Week 31/32

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Muon Piquet Report Week 31/32 Burkhard Schmidt July 31to August 6, 2012

  2. Muon system summary week 31 • Monday/Tuesday night : • Short in chamber M2A 19B Gap C (R3), fuse had to be blown. • In trying to do so, Matsusada for the A-side tripped (the wrong HV cable has been disconnected. Lengthy recovery (1 ½ h) .) • It took in total 3 ½ hours to solve the problem, lost about 5/pb of data. • Rolf, Giovanni and BS assisted Andrea (who was piquet) • Wednesday evening: • Communication problem with OPC server/SYSTEC on M23C side. • Difficult to find the culprit – despite great help of Alessandro. • The problem could be traced down the following day to a faulty ELMB, leading to crashes of the OPC server. Took data ignoring the M23C DAQ configuration. • Lost about 45min of data-taking or 1/pb, mainly due to the rebooting of the PC. • Friday, August 3: • Wrong timing for chamber M3A 18A3 – the chamber which has communication problems. Could be fixed in reconfiguring this chamber. • Saturday to Monday: • Smooth running, just some HV channels had to be reset/included.

  3. Short in chamber M2A 19B Gap C (R3) • A short in M2R3Q1 chamber 19B gapCwas tripping a channel in the master module Q1_M23 channel 2. • As a consequence 8 chambers of M2R3 were down: 17B-24B • Corresponding inefficiency: 1/6 of a region = 1/24 inefficiency ~ 5%. • Since it was tripping the RDM we had to blow the fuse of channel 26 of module 2 of master module Q1M23 (corresponds to GAPC of M2A chamber 19B). • We followed the procedure described in the Twiki, which was clear. • Unfortunately, due to a confusion of counting (I forgot the HV channel for transmission of the HV to the other Master boards), we first disconnected the wrong cable and the Matsusada tripped. • It took a good hour extra to ramp back up the Matsusada.  The instructions were not very clear in the TWIKI. • After this had been fixed, we went down to blow the fuse again. • Only after pushing the DISCONNECT button twice, it wouldn't light anymore. Then the HV came up OK.

  4. ELMB problem of Wednesday night • The problem was difficult to spot: • It seemed to come from M23C Q4, as the configuration was stuck there. • Power-cycling the M23C Q4 SB crate didn’t help, neither the restarting of the OPC server, the resetting of the SYSTEC, nor rebooting the MUDAQC03Ww PC. • In order to take physics data, we run with ignoring the status of the DAQ in M23C, which was stuck in CONFIGURE. • On the nest morning the problem could be traced down to a bad ELMB communicating with the SYSTEC on CAN line 3 of Q3. • Power cycling the M23C Q3 SB-crate cured the problem. Lesson learned: • In case of such problems, always reset the SB crates in both quadrants connected to the same SYSTEC. • Better monitoring of ELMBs, and resetting of individual ELMBs would be helpful.

  5. ELMB problem of Wednesday night Running the system ignoring the configuration of M23C let to some holes. Effect has been estimated To be on the 1% level.

  6. ELMB problem of Wednesday night: Remedies • Clara has added a PVSS ctrl manager in the MUSIDES project, which monitors the OPC servers in: MUDAQA01W, MUDAQA23W, MUDAQA45W, MUDAQC01W, MUDAQC23W, MUDAQC45W, MUODEA01W, MUODEA02W, MUODEC01W, MUODEC02W • If the OPC server goes into the loop crash/restart, it sends the following alarm message: "OPC Server Looping! Probably problem with a CAN bus“ • Severity: ERROR (red) • Origin: will say MUON and which project/machine. • ATLAS uses an updated version of the OPC server. • Davide will try to implement the new version also for the Muon project.

  7. Reminder:Communication problem with M3C 18A3 • FEBs on I2C line 2 (FEBs 4 to 9) are not configurable and it is not possible to apply any recipe, even if the communication seems to work properly. Problem was noticed on Friday June 1. • The ECS cable has been checked during an access this morning. Also the ELMB has been changed. These actions didn’t cure the problem. Needs to be followed.

  8. Configuration lost for chamber M3C 18A3 (R2)(Friday afternoon around 17:30) Before After Did a reset just for DU concerned. Re-configuring took only 1 min

More Related