Displaying report 1-1 of 1.
Reports until 08:03, Thursday 20 October 2016
LHO General
patrick.thomas@LIGO.ORG - posted 08:03, Thursday 20 October 2016 - last comment - 09:38, Thursday 20 October 2016(30688)
Ops Owl Shift Summary
Lost lock 3 times briefly after reaching NLN. Possibly ASC related. No PI modes seen ringing up on striptool. Decided to try an initial alignment and have not been able to get past ENGAGE_DRMI_ASC since.
At different times both H1:LSC-TR_X_QPD_B_SUM_OFFSET and H1:LSC-TR_Y_QPD_B_SUM_OFFSET got bad values that hindered finding and fine tuning IR.

07:18 UTC Terra turning on ETMY ring heater for PI test later today (Thursday)
09:15 UTC NLN
09:18 UTC Lock loss. EY saturated and ASC signals (mostly DHARD pitch?) started ringing up before lock loss.
10:02 UTC NLN
10:06 UTC Lock loss. Again ASC signals started ringing up before lock loss.
10:48 UTC NLN
10:52 UTC Lock loss. Again ASC signals started ringing up before lock loss.
10:56 UTC Starting initial alignment.
11:56 UTC Initial alignment done. Kept losing IMC lock. Had to redo input align. SRC also had trouble locking.
12:22 UTC Despite initial alignment had to check MICH fringes and lock on PRMI. Locking on PRMI took moving PRM around. PRMI to DRMI transition worked, but lost lock before DRMI_LOCK state.
12:36 UTC Stopped at DRMI_ASC. Signals fell and loss lock again.
Happened again. Stopping at LOCK_DRMI_1F. Seems stable here. Definitely ASC.
13:54 UTC Still can't get past DRMI_ASC. Starting another initial alignment.
14:09 UTC Peter to LVEA to take dark noise measurements and needs PMC unlocked. Stopping initial alignment after INPUT_ALIGN_OFFLOADED and set ISC_LOCK to DOWN.
14:57 UTC Peter done
Comments related to this report
kiwamu.izumi@LIGO.ORG - 09:38, Thursday 20 October 2016 (30690)ISC, OpsInfo

Jim W, Kiwamu,

As pointed out by Patrick, DRMI ASC was causing the locklosses. It was due to the PRC1 loops (POP A QPD -> PRM loop) which had too large misalignment. Here is what we did to work around it.

  1. Proceed to ENGAGE_DRMI_ASC
  2. Manually disable the PRC1 loops by zeroing the gains for PRC1_P and PRC1_Y. Disabling them should not unlock DRMI as long as the ramping time is slow enough (~ 5 sec).
  3. Let the rest of the control loops settle for 30 sec or so.
  4. Prepare for re-engagement of PRC1 by doing the followings. Switch off the input and clear the history for PRC1_P and PRC1_Y. Then, set the gains to a sufficiently small number e.g. 0.01.
  5. Re-engage PRC1 with the small gain by switching on the inputs. And let them settle until the input values start crossing zero.
  6. Ramp back up the gains to 1 by doing the followings. Switch off the inputs once again, then toggle FM2. This slowly zeros the outputs. Once the outputs becomes zero, clear the histories and set the gains back to the nominal value of 1. Finally switch back on the inputs.
  7. Done.

Though, we don't know why we ran into this situation at this point.

Displaying report 1-1 of 1.