stefan.ballmer@LIGO.ORG - posted 21:17, Friday 15 May 2015 - last comment - 02:00, Saturday 16 May 2015(18470)
Some OMC work - early night due to winds
Dan, Keita, Stefan - Updated the OMC model with correct math and enough monitor points to be useful. - We tried commissioning the model sitting off fringe at 23W, but confused ourself a bit. Everything started to make sense when Keita pointed out that we have a fringe offset when sitting at zero digital offset, which manifests itself as different OMC trans DC power levels on the left and right side of the fringe. - With the nominal 1e-5 DARM ERR counts offset (about 14pm), we observed 18mAmp, while -1e-5 gives 15mAmp. Thus we have about 0.6pm fringe offset when the RF length signal is zeroed. - With that we laid out the strategy for setting up the parameters: 0) Set H1:OMC-READOUT_SIMPLE_GAIN to 0 (Turns off simple path.) 1) Estimate the minimum power at zero DARM offset to get a number for the contrast defect. It turns out this is close to 0, so 0 will do. 2) Pick the transition point. In our case 14pm. Thus set both XF (fringe length) and X0 (fringe offset) to 0. 3) Adjust H1:OMC-READOUT_PREF_OFFSET until H1:OMC-READOUT_STEP2 is equal to one on average. (H1:OMC-READOUT_STEP2 is the power normalized by the power at the transition point.) 4) Set H1:OMC-READOUT_X0OFFSET_GAIN to 1 now the .H1:OMC-READOUT_ERR_INMON signal is zero on average. 5) Use H1:OMC-READOUT_ERR_GAIN to match the gains in the RF sensor (H1:LSC-DARM_IN1) and the OMC path (H1:OMC-READOUT_ERR_OUT). 6) Set H1:LSC-OMC_DC_OFFSET to minus the H1:LSC-DARM_OFFSET. Now the offsets are matched. 7) Transition the input matrix. 8) Ramp H1:LSC-OMC_DC_OFFSET and H1:LSC-DARM_OFFSET to 0 (at the same time) - We had high winds for about two hours. But after that successfully tested the script that follows this logic.
Here's the MEDM screen Stefan built for the new handoff code.
The OMC guardian and the ISC_lOCK guardian have been updated to follow the above script. After the transition to DC readout, the DARM offset is offloaded to the "fringe offset" in the OMC-READOUT path.
We were able to transition to DC readout at 2.2W, 3e-5 DARM offset, and increase the power to 22W while decreasing the DARM offset to 1e-5. This was done with only a casual regard for ramp times; the process was very robust. We have coded a step in INCREASE_POWER that changes the fringe offset to maintain 20mA in DCPD sum. Eventually, we will juggle the states in the ISC_LOCK guardian so we transition to DC before the power up, and then smoothly adjust the fringe offset during the power up sequence. We tested this once and it works well, but we didn't have the energy to perform a shuffling of guardian states. For now, we have left the guardian as usual, but the handoff from the OMC to DARM is performed using the new normalization path. It worked once, before we left.
We never reached low noise tonight, we lost lock a few times in the coil driver switching step. At least one of these locklosses was due to what appeared to be a guardian error, in which the ISC_LOCK guardian skipped the COIL_DRIVERS state, went to the ETMY ESD handoff, and then ran the ETMY ESD handoff *again* before losing the lock. See the second screenshot attached.
Here's my interpretation of what happend with the ISC_LOCK guardian (see comments in the screen shot below):
This is all kosher (i.e. no bug) assuming there was indeed a second request for LOWNOISE_ESD_ETMY at 7:20. If there wasn't, and the second request truly came out of nowhere, then that's weird. Where could it have come from?
If the second request was legitimate, i.e. it came from the operator, it might have been accidental, or the operator was maybe un-aware of the intended behavior (not unlikely given that behavior is probably not widely known). However, it might also indicate that the behavior is non-intuitive and/or problematic and should maybe be re-examined.
ECR 746).) I'm not sure how widely this behavior is know or taken advantage of. It's not actually being used in the SUS guardians anymore. Given the current crappy MEDM UI, it's also quite easy to accidentally re-request the same state.
The same-state redirect behavior was added early in commissioning the SUS guardians. (It was actually added in response to some of the problems we've had handling the DC alignment biases, which is actually slated to change (
My intention was that all REQUESTable states be idempotent, e.g. it would never hurt anything to simply re-run them again. If we were to make sure that all requestable states really were idempotent, then the behavior is probably fine as is. This is actually quite easy to accomplish in this case by simply making the relevant non-idempotent action state
request=False, and adding a new requestable idle state right after it.If this is too cumbersome, the we need to do some or all of the following: