Sheila, Evan
Running the dc-coupled oplev servo on SR3 for long periods of time seems to be causing us grief (LHO#20519).
As an alternative, we are trying out a cage servo which feeds the witness sensor in pitch back to M2:
ezcaservo -r H1:SUS-SR3_M3_WIT_PMON -g -300 -s
The step response of this loop has a time constant of 30 s or so.
Jenne and I put this cage servo into a new guardian, called SR3_CAGE_SERVO. One hick up in this process was the fact that the gain setting that works for ezcaservo is opposite to the one that works for cdsutils.servo
This guardian is managed by the ISC_DRMI guardian, which doesn't turn it off but does make sure that it is turned on after DRMI locks. There are states to run the servo, turn it off, and to clear the history (clear offset). We've added this guardian to the list of guardians in IFO guardian. (That is the guardian who checks that the state of other guardians), and set the nominal state to CAGE_SERVO_RUNNING.
We've also added it to the ISC guardian overview screen.
If misaligning SR3, this servo needs to be off. The guardian will go to CAGE_SERVO_OFF if SR3 is misaligned.
Did you guys add this new node to the overview screen? Please let me know when you add new nodes. All nodes have to be tracked in the infrastructure, so we need to know all nodes that are running and are being depended upon by other nodes.