Sheila, Camilla.
After this morning's windy lockloss from TRANSISITON _FROM_ETMX, we continued previous 77366 troubleshooting.
Sheila manually stepped though TRANSISITON _FROM_ETMX:
- We found that only the L1 history was cleared, giving unwanted outputs when we turned on L2 and L1 gains.
- Sheila added a line to clear L2 history (line 5115: ezca['SUS-ETMX_L2_LOCK_L_RSET']=2).
- We then lost lock when turning off two DARM1 filters (ezca.switch('LSC-DARM1', 'FM1', 'FM2', 'OFF')). This seems the cause of our glitch, attached shows this DARM1_SWSTAT change at the same time as the glitch on a successful lock.
- FM1 "8^2:2^2" has a 20dB gain at low frequency and 10s ramp, but FM2 "MadHatter" has a 40dB gain and 0.09s ramp so is probably to blame.
- Sheila notes that "MadHatter" used to be left on during the transition (74798, 75451). To check this, I see that FM2 was kept on though a successful transition from 75631, plot attached.
- Sheila edited ISC_LOCK to leave DARM1 FM2 on during TRANSISITON _FROM_ETMX but turn it off during the next state: LOWNOISE_ESD_ETMX, once we are already on NewDarm and effect of this low frequency filter is suppressed.
- After these changes, our locking was successful with no glitches: plot attached.
[RyanS, TJ, Jenne]
We've had 2 locklosses today that seem to be about when that MadHatter Darm FM2 gets turned off. But, since Sheila and Camilla moved the filter turning off, now the locklosses are happening a little later.
As Camilla points out, the ramptime of that filter inside Foton is very short. I've increased it to 3 seconds and we're about to give it a try (since I don't have a better plan to try right now). Something we haven't seen (since we're already locked right now) is whether increasing the ramp of that filter inside Foton causes trouble for the engagement of that filter, in DARM_OFFSET.
EDIT: Indeed we made it through the turning-off of the MadHatter filter with this 3 second ramp time (rather than the previous 0.1 sec ramp). I am hopeful that it won't matter for the turning-on of the filter, since that happens in a quite stable part of the locking sequence. But, we'll just have to see over the next few lock acquisitions.
Also EDIT: If we are unable to relock with this ramp time, attached is a screenshot of the previous ramp time, that we should revert to.
We've now relocked twice with the longer ramp time in the MadHatter filter in place for the turn-on and turn-off actions of that filter, so it seems fine to leave in place.