jenne.driggers@LIGO.ORG - posted 17:25, Friday 11 January 2019 (46361)
Friday AM locking
- Another lockloss at ENGAGE_SOFT_LOOPS.
- Symptom: POP18 dropped when we did engage asc for full IFO, and it didn't come back up with the soft loops (even though the carrier PRG was increasing as we expect).
- The SOFT loops and dither loops seem to converge fine, but then an oscillation starts that we were not able to tame down.
- 3.4 Hz was the oscillation frequency.
- A problem in the engagement of ASC loops was found and fixed. PRC1 was being engaged with some DC gain, but it should be AC coupled since the DC part will be taken care of with the dither loop. The dither part doesn't get engaged until ENGAGE_SOFT_LOOPS, but we still don't want to be servoing to the pointing on POP_A right now, since the setpoint isn't set to handle that. Later in the engagement script PRC1 was being AC coupled, but by then our pointing is all weird.
- TVo moved the AC coupling filter (FM5 in PRC1 P and Y) to PREP_ASC, so that we are certainly engaging PRC1 with AC coupling.
- ISS second loop setpoint needs to be adjusted. When the second loop comes on (AC coupled) after DRMI locks, the diffracted power is jumping from 1.5% to 3%. Not causing trouble immediately, but needs to be addressed sometime when we're sitting in IMC-only.
- Lost lock in PREP_ASC_FOR_FULL_IFO
- It seems like DHARD and MICH control signals start walking off, although the error points don't seem to have changed. So, why do DHARD and MICH feel the need to push??
- Found another wrong setting with the dither loops - YAW3 had 2 bandpasses engaged, so the PRM Yaw loop wasn't really doing anything. But, it's been set incorrectly since Jan 4th, and we've been living. Maybe PRM Yaw wasn't so far away in past locks, but now it needs to move farther, so the loop not engaging is causing problems??
- Something is wrong with the OMC locking. When OMC_LOCK gets to LSC_ON, I can see the OMC trans camera oscillate a lot, then the OMC loses lock.
- Trying different ASC engagement:
- SOFT loops: going to try engaging CSY, DSP, DSY with the DC dither loops only, and only have CSP have both dither DC and the ASC-CSOFT AC coupled portions of the loop.
- CHARD Yaw gain increase (FM1 on, +30dB) causes things to seem to go unstable. PRC1 Yaw sees osc. CHARD Pit and Yaw sees osc. PRG looks more hash-y. Leaving FM1 off for now.
- Turned on rest of ASC, then tried CHARD Yaw again. Rest of ASC was fine, but turning up CHARD Yaw gain made CSOFT Pit oscillate. Leaving CHARD Yaw FM1 still off for now.
- New lock, the above ASC engagement is in the guardian (with an IF True to make it easy to put back in if needed).
- Able to power up to 30W in this state. CHARD Y OLG is in the low bandwidth state measured in attachment 1 for the power-up (measurement was done at 2W, while fighting a violin mode).
- After power-up, CHARD Yaw started to ring up slowly. We increased the CHARD Yaw gain from the 0.6 value that is set in LownoiseASC to be 3.0. But, the +30dB FM1 is still off, so we're overall a factor of 6 lower than previous CHARD Yaw NomLowNoise gain.
- Lost lock trying to move SRM for cavity pole improvements.
- Next lock, seems like SRC1 P more gain (SRC1 Y was given more gain a few days ago). Also, giving CHARD_Y 5x more gain in the engage_soft state, rather than the full 30x of FM1.
- Factor 3x for SRC1 P now in guardian, near the place where SRC1 Y gets +20dB.
- Tried putting in offsets to the SRC1 pit and yaw loops, to see if the DARM cavity pole would react. It's a little tricky to see what's going on in the attached ndscope figure since the IFO was still thermalizing, and there are a few times in here that Stefan was also changing DARM whitening and offsets. But, I think that my conclusion is that the SRC1_P offset of zero is the best, and a SRC1_Y offset of negative values isn't better than zero offset. Next lock we need to check if SRC1_Y positive offsets are helpful.
- The big jump in cavity pole around -1000 seconds is a "regular" glitch. The jump around -400 sec is Stefan changing the OMC DCPD whitening condition. Then, a few tens of seconds later he undid that change. We lost lock on a DARM offset change.
Images attached to this report
