Reports until 17:31, Tuesday 28 May 2019
H1 ISC (GRD, ISC, SUS)
georgia.mansell@LIGO.ORG - posted 17:31, Tuesday 28 May 2019 - last comment - 15:24, Wednesday 29 May 2019(49520)
BS top mass LOCK_L_GAIN setting issues, fixed with a small change to guardian

When we got to NLN today Jenne noticed that the beamsplitter M1 LOCK_L gain was zero (nominally 0.1), she turned off the integrator and slowly ramped the gain back on, and all was well. I looked into why this was turned off.

In the PREP_FOR_MICH state of initial alignment the BS_M1_LOCK_L_GAIN is set to zero. The gain only gets turned back on when the ISC_DRMI guardian runs through its down state from the top. In initial alignment ISC_DRMI is already in its down state, so this gain wasn't getting reset until after we lose lock and reacquire again.


To fix this we added a line to the INITIAL_ALIGNMENT state of ISC_LOCK, which will request that ISC_DRMI be in IDLE instead of DOWN. That way, straight after initial alignment, the beamsplitter will be back to nominal configuration.

 

When we next lose lock or drop out of observing can someone load the ISC_LOCK and ISC_DRMI guardians.

Comments related to this report
georgia.mansell@LIGO.ORG - 13:58, Wednesday 29 May 2019 (49531)

This change caused several locklosses from DRMI_TO_POP today. The new edge case from DOWN to IDLE, allowed a shorter path from DRMI_3F_LOCKED to IDLE (through DOWN, not a thing we wanted to do). I've removed this edge, and instead moved the beam splitter top mass gain setting to the PREP_DRMI state.

jenne.driggers@LIGO.ORG - 15:24, Wednesday 29 May 2019 (49537)

And the reason that the guardian thought that it would be shorter to go through DOWN to IDLE is that we weren't actually sitting in the state right before IDLE, DRMI_3F_W_ASC_READY.  This is because the counter in ISC_LOCK's OFFLOAD_DRMI_ASC wasn't quite right.  There were two "if self.counter == 5" statements, and so only one of them was being run, and it happens that the one that *wasn't* being run is the one that requested ISC_DRMI guardian to go to that DRMI_3F_W_ASC_READY state.  So, I have fixed the counter statements in ISC_LOCK's OFFLOAD_DRMI_ASC state, so now we should normally have the ISC_DRMI guardian sitting in what was supposed to be the final state.  So, I think that if we needed to, we could reimplement Georgia's edges.  But, the new version of just putting things in the PREP state is also fine, so for now we will leave ISC_DRMI guardian as-is.