jenne.driggers@LIGO.ORG - posted 11:19, Monday 14 January 2019 - last comment - 11:19, Monday 14 January 2019(46391)
Monday AM locking
IFO was in ENGAGE_ASC_FOR_FULL_IFO when I arrived - this is awesome!
Tried hand-engaging SOFT loops, but PRC2 yaw started running away, as mentioned by TVo in alog 46387. Turned off all ADS loops and CSOFT Pit, lock still okay.
Only engaged Pit3 and Yaw3 (PRM to ITM spot), seems fine. Error signal on Yaw4 is really far off, which is probably why PRC2 is needing to follow so far.
Engaged Pit5 and Yaw5 (Yarm), which had error points close to zero, seems fine.
Moved Yaw4 line frequency back to 22.3Hz, and switched to the old bandpass, and the ADS error signal agrees on the direction that Yaw4 is off.
Moved Yaw4 line frequency back to the new value of 8.65Hz (according to bandpass name, and Georgia's alog 46385), and the ADS error signal is of opposite sign. The guardian puts the Yaw4 frequency to 8.70Hz, which has almost exactly 180deg difference in the bandpass phase from the correct frequency of 8.65Hz. This is now fixed in the guardian.
The ADS OSC overview screens need to have more digits of precision on the displayed freqs. We often set the freqs to 2 digits, but since the screens are only showing 1, perhaps the guardian-writer assumed that the correct value was 8.7Hz. I have now done this for the ADS overview screen, and the oscillator locking screens.
With the corrected Yaw4 freq, everything converges just fine.
There is a *huge* comb in all of the length degrees of freedom (MICH, PRCL, SRCL, DARM). The ASC monitor lines that are not used in-loop are too large. I had turned them off by hand (they'll still come on in guardian), but we need to turn them down. The comb isn't from those lines. The dithers are engaged right now (later lock), but no comb. The comb is from the weird MCL signals that you can see in the LocklossA.png below.
Got to Nom LowNoise just fine, but lost lock after 4 min. Fast lockloss, need to look into this one.
Looks like maybe a fast DARM ringup, but what is going on with the CARM / MCL signals?? See attached LocklossA.png.
The little spikes were there for the whole lock.
Next lock, acquiring easily. Just a little PRM / SRM alignment tweaking after DRMI had caught lock (took ~5 min).
This time, lost lock after 13 min. The spike things showed up in MCL_OUT_DQ at least once during this lock, but very briefly, then went away. No sign of them being there long-term.
May want to freeze ADS loops during COIL_DRIVERS state, looks like they get a kick while the transitions are happening.
Running WFSreliefPast to the time last lock when we were at 2W DC readout, SOFT loops all converged.
Another fast lockloss, but while powering up.
Later lock, looked at how long it takes the ADS loops to converge. The answer is a really, really long time. See attached ADS_slow_Convergence.png. We should be able to speed this up by ~an order of magnitude. We can have this low freq once we're locked, but we should get to our final pointing faster than 20 min.
Images attached to this report
Comments related to this report
daniel.vander-hyde@LIGO.ORG - 11:04, Monday 14 January 2019 (46400)
Double checked that the YAW 4 dither frequency mentioned is set in guardian and is at the center of the bandpass filter. It checks out. Also double checked this for YAW 4, YAW 5, PIT 3, PIT4, and PIT5 dither frequencies.