Last night, I moved the PRM coil driver switching to happen before the CARM offset reduction (21321 ) with the idea that this would make the locklosses it causes less painfull as they would happen earlier in the sequence.  We tried it this way once and things seemed fine, but then Travis later had a hard time locking.  Many of his locklosses were due to PRM coil driver switching.  This morning TJ and I moved this back to the DRMI on POP state (after CARM ofset reduction)  and we also had locklosses caused by it, although we were able to make it to full lock sometimes.  

This afternoon TJ and I looked into this a bit.  We looked at the amplitude of the glitches as seen by noisemon, and they are the same today as they were August 30th.  We also looked at how the PRM dirves respond to this glitch. Two weeks ago, we were nearly saturating PRM M3 each time we switched, in the past few days we have been nearly saturating M1 as well.  This is not suprising with the higher offloading gain intended to help us lock durring high ground motion (alog 21216)

I put an elliptic low pass at 10 Hz in PRM M1, this reduces the glitch in M1 by an order of magnitude.  We've survived the switching 3 times since we did this, and it is in the DRMI guardian.  In the two screenshots you can see an example of the glitch with switching this morning, and the second one shows the glitch with the new low pass engaged.  We are still in danger of saturating M3, so it would still be a good idea to look at tuning the delay if we get a chance.