J. Kissel, A. Staley

The H1 HAM2 ISI consistently trips using the guardian on the GS13s, right as the X, Y, Z, RZ isolation filters begin to turn on, just after the RX and RY alignment biases are slewed. I had thought it might have been because I found the GS13s in high gain mode (why? because of a restart of the guardian process maybe?), but I switched them back to low gain mode (with dewhitening ON) and things still trip because we're trying to engage horizontal GS13s that that just been yanked around in tilt. I confess, we *didn't* reset the CPS offsets and store them in the target before getting started and I don't know the difference between the equilibrium state and the current target, nor do I know the last time they were reset and stored, so it might be fine if I just do that.

I'm surprised to see the RX and RY alignment biases being ramped in between turning on each of the isolation filters already. We have certainly discussed doing this, but I would have expected more testing to iron out these bugs. Jamie's update aLOG doesn't mention anything about it, other than nodes have been restarted with some minor bug fixes.

For the evening, I left the requested state in damping, and brought up the isolation loops using the commands script. That works because it doesn't play with the biases until the isolation filters are completely engaged. Also note, that if you manual put the ISI into the HIGH ISOLATED state, and then switch the request to such, it turns the isolation loops off and starts from scratch. Not desirable, but may be tough to code up / or insure that you're actually in high-isolated.

I post to examples of the GS13 trip, but it's clear what's happening, as I describe above.