Displaying report 1-1 of 1.
Reports until 07:35, Thursday 06 June 2024
LHO General
ryan.short@LIGO.ORG - posted 07:35, Thursday 06 June 2024 - last comment - 09:55, Thursday 06 June 2024(78274)
Ops Day Shift Start

TITLE: 06/06 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 5mph Gusts, 4mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.26 μm/s
QUICK SUMMARY: H1 has been unlocked since 10:21 UTC this morning. It's been able to relock up to PREP_DC_READOUT_TRANSITION, but the OMC is not locked; OMC_LOCK is stuck in the SET_WHITENING state with a notification reading "DCPD gains not equal after whitening switch -- yikes!" (I've not seen this before; will start troubleshooting)

Comments related to this report
ryan.short@LIGO.ORG - 09:55, Thursday 06 June 2024 (78275)ISC, OpsInfo

Looking into why the OMC couldn't lock this morning, it seems to me like the sequence of events went as follows (all times in UTC):

  • 12:17:27 - ISC_LOCK, at the end of DARM_OFFSET, requests OMC_LOCK to READY_W_NO_WHITENING (to lock the OMC)
  • 12:17:31 - OMC_LOCK enters the SET_WHITENING state
  • 12:17:32 - OMC_LOCK ramps entirely to DCPDA to switch whitening on DCPDB
    • DCPD_A0 gain goes to 2 while DCPD_B0 gain goes to 0
  • 12:17:36 - With the DCPDB whitening set, OMC_LOCK now ramps entirely to DCPDB to switch whitening on DCPDA
  • 12:17:37 - DCPD_A0 gain goes to 0 while DCPD_B0 gain goes to 2
    • While waiting for gains to ramp, ISC_LOCK (now in PREP_DC_READOUT_TRANSITION) sees the OMC is not ready and requests OMC_LOCK to DOWN so the OMC can try locking again
  • 12:17:38 - OMC_LOCK is redirected to DOWN before all the whitening change steps are finished; DCPD gains are not reset
  • 12:17:43 - OMC_LOCK reenters the SET_WHITENING state
  • 12:17:44 - OMC_LOCK ramps entirely to DCPDA to switch whitening on DCPDB
    • DCPD_B0 gain goes to 0
  • 12:17:48 - OMC_LOCK ramps entirely to DCPDB to switch whitening on DCPDA
    • DCPD_B0 gain goes to 4 (since the value the agin is found at is simply doubled)
  • 12:17:52 - OMC_LOCK sets DCPD gains back to what they were at the start of the state
    • DCPD_A0 gain goes to 0 while DCPD_B0 gain goes to 2
  • 12:17:53 - OMC_LOCK enters the PREP_OMC_SCAN state to continue locking the OMC
  • OMC_LOCK is unsuccessful in locking the OMC, it cycles back through DOWN and tries to relock
  • 12:19:29 - Back in SET_WHITENING, this time OMC_LOCK sees that whitening is already off and that the gains of the DCPDs are not the same
    • OMC_LOCK shows a notifcation that says "DCPD gains not equal after whitening switch -- yikes!" and stops

H1 sat in this position for several hours (owl operator wasn't notified, separate issue) until Sheila manually set the DCPD gains to what they should be (1), then the OMC was able to lock without issue and the IFO followed suit.

I believe this interaction happened because now that the DARM_OFFSET state has been moved to after all the ASC states, the OMC doesn't have as long to lock before we reach PREP_DC_READOUT_TRANSITION, and the OMC_LOCK DOWN state request happened in a bad spot. If we want to keep DARM_OFFSET where it is, we might want to change ISC_LOCK to give OMC_LOCK more time to lock the OMC before having it try again.

Displaying report 1-1 of 1.