Bottom Line--When using Guardian, engaging the RZ loop twists the MICH too far. It may be doing the CPS Offset zeroing in a weird method. When the loops are engaged with the old Command Scripts, the RZ input does not get driven off and no bad RZ twist occurs.
Further, with MICH locked, the X & Y ST2 ISO loops are not stable--they ring up and trip. Without Mich Locked, the loops are stable.
Details: Let's start with the first attachment; it is 25 minutes of second trends. The Guardian turns on the Z loop after first LOAD_CART_BIAS_FOR_ISOLATION so this is the first thing to do. Manually one can do this on the CART_BIAS screen (Reset CPS offsets button.) In outward appearances, there is a difference in how this button and Guardian perform this operation; however, Jamie says no it doesn't. Maybe it is the slow ramping of the new setpoint. Anyway, my observation is that the residuals for this platform are always small. After the CPS offsets are Reset, the Guardian turns on the Z dof. The gain steps and the ramp times are the same for the Command Scripts and Guardian.
Using the Command Scripts, engaging the Z dof ISO is seen at point 1. Notice how at point 2, the RZ INMON is not doing anything awful while the Z loop is turned on and the RZ loop turns on (point 3) nicely and well behaved. However, when Guardian does this...
When Guardian turns things on at point 4, look at what happens to the RZ INMON. The Z_OUT16 is much larger when Guardian turns it on and the RZ_INMON is driven way off. And, even though the RZ_INMON is much lower by the time the RZ loop comes on, turning on the RZ loop at point 5 produces a too large an output--The RZ_OUT16 looks just like the OpLev Yaw.
You can see that the manual turn on of the Z then RZ loop was repeated a few times with the same result; like wise the Guardian turn on was similarly consistent. Of course, Guardian also turns on the X & Y DOFs when it engages the RZ loop and as I allude to in the summary above, these loops may be unstable. However, at this point I return you to the point of how the Z_OUT is so different for Guardian and how that impacts RZ_INMON all before the X Y & RZ loops are engaged.
I left the ST2 in fully isolated and later Ellie locked the MICH. After a minute or so, it didn't look stable and MICH was turned back off. Shortly after that the ISI tripped. So then we tested things. Ellie locked MICH and then I engaged the ST2 ISO Loops. Things were fine with the Command script turn on of Z and RZ but the ISI slowly rang up and tripped on either X or Y DOF even without the boost on.
Solution--Identify why the Command Script and Guardian do something different at the CPS Reset stage. Identify the loop instability.
This might be the MICH controllers beating on the ISI. I've attached a 4 page pdf, taken at t=0 is at GPS=1109443997 I think what is happening is: 1) ISI st2 X and Y ISO loops are off 2) MICH control gets turned on, and starts injecting lots of noise onto the ISI table 3) ISI isolation loop X (or Y) gets turned on, much higher BW than damping loop. 4) ISI iso loop tries to suppress the ISI motion. but the high freq motion is too big, and the actuators start saturating 5) after a few seconds, the WD trips. evidence: pg 1) The H1 actuator drive signal, it starts ramping up at ~T=65 seconds. the drive is getting bigger, but not in a classic oscillation sort of way. It grows to about T=72, then sort of levels off, until it gets tripped about T=82. pg 2) The WD state, at about T = 82. pg3) the GS-13 for X, pretty noisy, doesn't change as the loop comes on or when it turns off. - Implies that the main driver for the GS-13X is not the X isolation loop. pg4) Detail of the drive signal. not like a classic oscillation.
