M. Todd, J. Driggers, J. Kissel, S. Dwyer, T. Sanchez, D. Sigg
For posterity's sake, I thought it would be nice to record some of the actions and efforts the locking team was doing this morning.
Sheila noticed we were losing lock at START_TR_CARM, and so we relocked DRMI and tried again but going back to PREP_TR_CARM and making sure things were reset. Upon trying to advance to START_TR_CARM, the ALS-C_REFL_DC_BIAS_GAIN was set before losing lock again.
This raised suspicion about the IMC_COMM_CARM path, and it was thought that the changes to Bekhoff over the last few days could have caused some of these problems. To double check everything in this path is set to the values that are being "reported", Jenne went through and toggled every button and slider in the path as a "sticky slider" approach to solving this. The chassis work involved corner 4 and 5, but Jeff narrowed these issues down to corner 5 chassis -- here is a wiring diagram of the chassis: D1100683.
We called in Daniel to see what his thoughts were on these issues.
We eventually lock TR_CARM by going through the guardian steps slowly. We noticed that when we stepped through slowly, the ALS COMM VCO would pull the mode cleaner away causing the TR_CARM path to rail. We disabled the VCO internal servo that uses the frequency comparator to keep the VCO at a fixed frequency. This has been used in the past for our sucsesful transitions, but seemed to be railing each time this morning.
We left the ALS not shuttered, and ran the QPD servos while ASC and soft loops were engaged, with Tony acting as a SRC1 servo. After all the ASC had engaged, the camera set points still looked good, I set the QPD offsets back to their values from SDF, and the camera offsets still looked good. The guardain has been reset to shutter ALS as normal next time we relock. The POP A yaw offset was off slightly, I set it to -0.43 rather than -0.4.
We then transitioned to DC_READOUT using the guardian without any intervention, or known fixes for the problems we were having.
We are able to turn on the SRC1 yaw loop, but the SRC1 pitch loop pulls the side band build ups off. I've added the SRC1 yaw loop back into ENGAGE_ASC_FOR_FULL_IFO.
Re: Matt's alog this morning, I was worried that we had a sticky slider situation after the beckhoff work (which apparently isn't really a thing here, but was a thing at the 40m). We moved sliders and flipped switches on the IMC common mode board, the IFO REFL common mode board, and the summing node. Probably that wasn't the issue.
After a few other TR_Carm unsuccessful attempts, I trended and it turns out that the time we had been successful doing things by hand that Sheila mentions, we had forgotten to turn off the H1:ALS-C_COMM_PLL_BOOST, so we did the whole transition with the boost left on. I have now set in the guardian to leave the boost on, and we have now gotten through this several times without any intervention. I also added turning off the ALS COMM VCO by clicking the Ext button (and resetting it to Int in PrepForLocking), however it's possible that that wasn't necessary, since guardian already had changing the On/Off switch as part of these states. The real key seems to be leaving on the H1:ALS-C_COMM_PLL_BOOST.
As Sheila said, DC readout seems to just be working fine, no intervention needed. Total mystery why it hadn't been working on Tuesday.
We have now powered up to 25 W two times! Even if we're not able to get farther than this, there are very few items left that would need to be checked using the full IFO (eg, the ISS second loop can be checked using IMC-only).
SRC1 P is still out of the guardian. One time I was able to close it using the offset from lownoise ASC, at Elenna's suggestion. But, we still lost lock in MoveSpots. The other time I was by-hand watching SRM pitch. No need to move it up to 25W, and I think I picked the wrong direction during move spots, so we still lost lock.
We got up past 25W a third time. This time, rather than doing MOVE_SPOTS, I manual-ed and did RF9 and then RF45 modulation depth reduction. Both of those were fine, although the 45 MHz reduction did confuse my Jenne-in-the-loop SRM alignment loop. At some point, it became clear that SRC1 yaw was pulling us away, so we turned that off and I started dealing with SRM yaw alignment as well as SRM pit alignment. We then did move spots with both SRC1 pit and yaw open and me watching them. That seemed fine. We then started going to MAX_POWER. I think we got up to 50W, but then we got a nasty ASC ringup and lost lock.
The only analog things that we haven't tested yet are (I think) coil driver switching, ESD switching, and OMC whitening switching, and ISS Second loop engagement. Tony had checked PCals earlier in one of our locks, and they were fine.
It sounds like there will be some folks around to perhaps try locking again tomorrow. However, as Betsy pointed out, now we have a pretty small list of things that *haven't* been tested, so even if we aren't able to get to full NLN we have very few things to be suspicious of when relocking next calendar year after the vent. ISS second loop we can test using IMC-only. Anamaria and Jeff were thinking through how could we check (using, eg, the IMON channels) the sus actuator switching. I think that we could also try OMC whitening switching using a single-bounce OMC.
Due to it giving Jenne trouble and pulling alignment away, I have commented out SRC1_Y from ENGAGE_ASC. This means the "human servo" will need to be in-use for now for SRM, especially during powerup and the spot move.
I've attached the ASC trends around where the ringup happened during the powerup. Looks like this is the known ~0.45 Hz instability and it's possible we were just unlucky.
The plan for tomorrow is to start locking just like we did this last time (fully auto with someone monitoring SRM alignment) and see how far we can get. If we're unable to fully reach low noise, there are ways we can check certain systems for functionality before we plan to close the arm gate valves mid-afternoon.