We had a few tricky things to overcome today, in order to get the IFO relocked. 

• IFO needed careful initial alignment after TMSX motion today

  • Symptom:  Although we were able to run through the initial alignment, and get so far as DRMI locked, we were repeatedly failing the SWITCH_TO_QPDS step of the carm offset reduction sequence.  The SRC ASC loops looked happy and converged in the state just before this, but some component of this state was causing the SRC ASC loops to start to go crazy, and then we'd lose the lock. 
  • Solution: Sheila pointed out that this can happen if the alignment isn't good enough (even though DRMI locked), and since the TMSX moved today as a result of the beam diverter closing (see aLog 22286), we went back and redid the initial alignment.  The INITIAL_ALIGNMENT state of the individual arms' ALS guardians can take a long time (today we waited 15-20 minutes for full convergence), but it was worth the wait.  After we finished the alignment sequence, we were able to fully reduce the CARM offset on the first try through the lock sequence.

• OMC ASC outputs needed histories to be cleared. 

  • Symptom:  ISC_LOCK seemed to not be able to finish the DC_READOUT_TRANSITION state, which was because the OMC_LOCK guardian was getting reset to DOWN.  In the OMC_LOCK log, there was a notification that there was no light on the OMC QPDs, so it was going to DOWN. 
  • Solution:  The outputs of the OMC ASC ANG servos (on the OMC_CONTROL screen) were stuck at their limiter values of 1000. First, we asked the ISC_LOCK guardian to stay at DC_READOUT_TRANSITION, so that it wouldn't go any farther while we were fixing this.  We then turned the MASTER GAIN (vertical blue bar to the left of the servos, on that screen) of the OMC ASC to zero, and pressed the "graceful clear history" button below the ASC servos.  This seems to have fixed things. 
  • Cause: I think this was happening because the OMC ASC was getting swapped over to the dither lines before the OMC was truely locked.  We may need to put in a check to ensure that the OMC is locked before allowing the DITHER_ON OMC state to run.  I suspect that we haven't seen this before because it's taking a bit longer to find the OMC resonance, since we're now starting from much farther away (see aLog 22268). 

• OMC locked on the wrong mode

  • Symptom: This isn't a new one, but the OMC Trans camera was quite dim, even though the OMC_LOCK guardian said everything was good to go.  There was only ~1.4mA of light on the OMC_DCPD_SUM_OUTPUT (top right of OMC_CONTROL screen), when it should be ~14mA at this stage.
  • Solution: We re-selected the READY_FOR_HANDOFF state, and it found the correct mode on the second try.  Maybe the OMC guardian needs a check for this, and it should at least put up a notification that it's not in a good state.

To get to Observation mode, we had a few SDF diffs to take care of.

• Accepting the FM8 bounce and roll notches that Sheila mentioned in aLog 22273.  Easy.
• Some TRAMPs in TMSX had differences.  We suspect that the dither alignment that Ed ran earlier today (which we very rarely run, since the TMSs don't move that much that often) set the TRAMPs to some value, and didn't put them back to the original values.  We reverted these to the values in the observe.snap.  This script should probably be modified to reset the TRAMPs appropriately, at the end of the script.