J. Driggers, J. Kissel, N. Lecoeuche, T. Shaffer

After the most recent lock loss, we noticed the the Beam Splitter suspension was constantly saturating. We found that it was the optical lever damping loops saturating the DAC, and then going unstable. It was not until we got some part of the way through the lock acquisition sequence again that we understood why: the beam splitter's M2 coil driver state is not set back to high range (state 2) from low noise (state 3) until the ISC_LOCK manager requests the ISC_DRMI subordinate to "PREP_DRMI." With the coil driver analog filter in low noise, the digital compensation filters are boosting the digital request such that the overall transfer function to optic is flat, and thus saturating the DAC, when otherwise, in state 2, the optical lever damping control signal is well within the DAC range.

The attached time series shows 
    - the optical lever damping control request, prior to the compensation filters,
    - the request after the compensation filters
    - the coil driver state
    - the ISC_LOCK and ISC_DRMI state number.
from the initial lock loss from NOMINAL_LOW_NOISE, and then the trickle through the sequence as TJ was commissioning the ALS automation, and then once ISC_LOCK hits 101 (which is ACQUIRE_DRMI_1F) and asks ISC_DRMI to go to 10 (PREP_DRMI), the coil driver state changes from 3 back down to 2, and the DAC output returns to acceptable levels.

Also, in our finding of this switch back to state 2 in ISC_DRMI PREP_DRMI, we see that in August 2019, the *collection* of coil driver switches back to high range with PRM, SRM, and BS were moved from ISC_DRMI's DOWN state (where, honestly, we expected it to be today), to PREP DRMI because of some occasional confusion when initial alignment is run (see LHO aLOG 51325). 

We don't want to move the request to go to high range for PRM and SRM out of the PREP DRMI guardian, because later in the ISC_DRMI, they are switched to an even more different state (state 1), and if we're in a situation where we're only using the DRMI guardian *and* we loose the DRMI lock, then we want these SUS to have their states reverted back to acquire.

However, the beam splitter state is 
    - NOT changed anywhere else in ISC_DRMI, 
    - only changed to the low noise state in the ISC_LOCK guardian state LOWNOISE_COIL_DRIVERS, *and* 
    - it's got an optical lever loop constantly driving the M2 stage, where the SRM and PRM don't
so we've pulled *specifically* and *only* the beam splitter's switch back to state two out of ISC_DRMI, and put it in to the DOWN state of ISC_LOCK, right around where the QUAD's states are reverted from the changes made in the LOWNOISE_COIL_DRIVERS state, such that things are happily self-consistent. 
The PRM and SRM switches remain in ISC_DRMI's PREP_DRMI.

Upon saving the changes, we:
    - ran guardutil print ISC_LOCK for a crude check to see if we've made any python syntax errors
    - loaded these guardian changes in to both guardians
    - committed the changes to the SVN

This was also a useful command when looking through guardian logs for a given time:
    zot$ guardctrl log -a 1259618520 ISC_DRMI -n 500 | grep DOWN | grep REQUEST
    2019-12-05_22:02:17.950865Z ISC_DRMI REQUEST: DOWN
    2019-12-05_22:09:40.903001Z ISC_DRMI REQUEST: DOWN
    2019-12-05_22:23:27.785163Z ISC_DRMI REQUEST: DOWN 
    zot$
where the "-a GGGGPPPPSSS" flag is the GPS after which you want to start looking, the "-n NNN" flag specifies how many lines you want, and then you specify the guardian node. In this particlar command, I then grepped that out put for when a request was made for DOWN, but, of course, you don't have to do that.