J. Kissel, H. Paris, A. Pele, S. Ballmer, C. Wipf

Yet again today we battled with the HEPI and ISI systems in the ITMY (BSC1) chamber trying to get them back after the weekend's power outage. HEPI is up and running again, but I don't think at the same alignment. The ISI cannot make the final transitions to awesome without its watchdog tripping. Details below. 

I'm leaving the entire ITMY (BSC1) and BS (BSC2) chambers OFF for the evening so DetCharians can follow up on a study of the 10 [Hz] HEPI pier amplification *AHEM* Laura Nuttall *AHEM*. 
Ground STS2 Channels          ITMY HEPI L4C Channels              BS HEPI L4C Channels
H1:ISI-GND_STS_HAM2_X_DQ      H1:HPI-ITMY_BLND_L4C_X_IN1_DQ       H1:HPI-ITMY_BLND_L4C_X_IN1_DQ
H1:ISI-GND_STS_HAM2_Y_DQ      H1:HPI-ITMY_BLND_L4C_Y_IN1_DQ       H1:HPI-ITMY_BLND_L4C_Y_IN1_DQ
H1:ISI-GND_STS_HAM2_Z_DQ      H1:HPI-ITMY_BLND_L4C_Z_IN1_DQ       H1:HPI-ITMY_BLND_L4C_Z_IN1_DQ
H1:ISI-GND_STS_HAM5_X_DQ      H1:HPI-ITMY_BLND_L4C_RX_IN1_DQ      H1:HPI-ITMY_BLND_L4C_RX_IN1_DQ
H1:ISI-GND_STS_HAM5_Y_DQ      H1:HPI-ITMY_BLND_L4C_RY_IN1_DQ      H1:HPI-ITMY_BLND_L4C_RY_IN1_DQ
H1:ISI-GND_STS_HAM5_Z_DQ      H1:HPI-ITMY_BLND_L4C_RZ_IN1_DQ      H1:HPI-ITMY_BLND_L4C_RZ_IN1_DQ
H1:ISI-GND_STS_ITMY_X_DQ      H1:HPI-ITMY_BLND_L4C_HP_IN1_DQ      H1:HPI-ITMY_BLND_L4C_HP_IN1_DQ
H1:ISI-GND_STS_ITMY_Y_DQ      H1:HPI-ITMY_BLND_L4C_VP_IN1_DQ      H1:HPI-ITMY_BLND_L4C_VP_IN1_DQ
H1:ISI-GND_STS_ITMY_Z_DQ 
which I've confirmed are in the frames. Chris is going to do a few more things with the IFO, but things should be off by 00:00 PDT, 07:00 UTC Oct 1 2013, 1064646016.

--------
HPI-ITMY

The goal here was to get HPI to the same alignment we had during HIFO-Y (see LHO aLOG 6566). However, the biases had been reported in the Colocated basis and we want to progress forward, sticking these biases in the Cartesian basis in calibrated units. After a few unsuccessful attempts, we finally

- Turned the position isolation loops OFF
- Turned the input to the IPSINF banks OFF
- Inserted the desired input readings as offsets in the IPSINF bank
- Read off the corresponding values at the input to the blend filter bank (letting the front end do the appropriate basis conversion and calibration for us [thanks Stefan!])
- Turned the IPSINF offsets OFF
- Turned the input to the IPSINF banks ON
- Turned the 100 [mHz] UGF "position" lock isolation loops ON (watching as the inputs meander off to some weird location)
- Installed the desired Cartesian values and a 10 sec ramp into the DCBIAS bank, turned them ON.


For the first few minutes, the plan worked like a charm; inputs to the IPSINF moved to exactly where we wanted them. However, after those few minutes and currently, the location has drifted to some other location, mostly in horizontal DOFs. Other commissioners were not as successful at restoring light this far into the interferometer, so we never got the chance to test whether this alignment is good enough. Out of frustration, we'll leave it as is.

Here're the final results:
Colocated Channel             Value [ct]  |  Cartesian Channel               Value [nm or nrad]    CART Bias Channel              [nm or nrad]    
H1:HPI-ITMY_IPSINF_H1_INMON    -873.2     |  H1:HPI-ITMY_BLND_IPS_X_INMON    -7156.64              H1:HPI-ITMY_DCBIAS_X_OFFSET  = 7156
H1:HPI-ITMY_IPSINF_H2_INMON    -822.083   |  H1:HPI-ITMY_BLND_IPS_Y_INMON    -33425.1              H1:HPI-ITMY_DCBIAS_Y_OFFSET  = 33425
H1:HPI-ITMY_IPSINF_H3_INMON   -2786.58    |  H1:HPI-ITMY_BLND_IPS_RZ_INMON   -4374.85              H1:HPI-ITMY_DCBIAS_RZ_OFFSET = 4374
H1:HPI-ITMY_IPSINF_H4_INMON   -3773.34    |  H1:HPI-ITMY_BLND_IPS_HP_INMON   -1073200              H1:HPI-ITMY_DCBIAS_HP_OFFSET = 1073200
H1:HPI-ITMY_IPSINF_V1_INMON   -6121.07    |  H1:HPI-ITMY_BLND_IPS_Z_INMON    -71553.4              H1:HPI-ITMY_DCBIAS_Z_OFFSET  = 71553
H1:HPI-ITMY_IPSINF_V2_INMON   -1038.65    |  H1:HPI-ITMY_BLND_IPS_RX_INMON   -46597.7              H1:HPI-ITMY_DCBIAS_RX_OFFSET = 46597
H1:HPI-ITMY_IPSINF_V3_INMON    2772.24    |  H1:HPI-ITMY_BLND_IPS_RY_INMON   +72672.               H1:HPI-ITMY_DCBIAS_RY_OFFSET = -72672
H1:HPI-ITMY_IPSINF_V4_INMON   -2990.78    |  H1:HPI-ITMY_BLND_IPS_VP_INMON   +75188.8              H1:HPI-ITMY_DCBIAS_VP_OFFSET = -75188 

      
-------
ISI-ITMY

The goal was to get the ISI in as best-performing state in order to use the GS13s (our best sensors of the isolation system at this point) to measure whether the 6.18 [Hz] feature had been reduced as much as had been shown by Arnaud in LHO aLOG 7919. As Hugo had stated earlier (see LHO aLOG 7915), he and Arnaud got things most of the way up, but not nearly as good as Vincent's work during the original discovery (see 7747) because the configuration Vincent outlines has just enough typos to be confusing.

So, I tried my hand at it, having had a few more conversations with Vincent about the configuration but to no avail. My attempts failed at various points along the way, but most often because the watchdog would trip on the actuators as I'd tried to switch in the T240s to the ST1 blend filters. I'm too tired to dig in deeper, but we'll try again tomorrow.

Here's what I found broken / frustrating / interesting along the way:
- The ISI-ITMY model must not have been restored to a good time (or not at all). The damping loops were OFF entirely (inputs, outputs, gains, and filters). I restored them by hitting the "damp ITMY" command script.
- The damping loop status lights are red when functioning nominally. The "correct state" is set to 0x6000034, when the current state is 0x1401 and the loops are running as designed. This should be an easy fix.
- ctrlDown of the isolation loops is now a part of the front end, so one no longer needs to remember hit the command button before restarting the isolation process.
- The ST0 to ST1 feed forward is not a part of the ctrlDown or isolate command scripts. One has to manually remember to SLOWLY ramp them off (or on).
- The Sensor correction is not part of the ctrlDown or isolate command scripts. One has to manually remember to SLOWLY ramp them off (or on).
- The Sensor Correction overview screen is grouped by degree of freedom instead of by instrument source -- and otherwise it looks identical. These should be at least *colored* differently. It's tough to tell whether I'm turning on the ST0 L4C sensor correction (which I shouldn't) or the GND STS2 sensor correction (which I should).
- The TRAMP for the MATCH banks on the Sensor Correction overview screen is missing. I had to dive into the MATCH banks internal screen to get to the TRAMP.
- The full filter bank sub-screens for anything on the Sensor Correction overview screen are not obviously accessible. You can do it by just clicking around blindly and landing on a hidden link, but there's no obvious button like there are for most other sub-screens.
- The FULL command script for "isolate ITMY lvl3" froze several times in the middle of ramping up ST2. I didn't diagnose why, but it fails in the middle of ramping up the ST2 RX and RY loops. I had to run ctrlDown and run each of the Stages (and at one point each of the degrees of freedom) separately.
- The "isolate ITMY lvl3" script turns on the "Boost_2" filters.

Here're some good philosophical discussions that came up:
[Kissel with himself]
- "There's a 'switch all' screen on the blend filter screen for each stage. Vincent at one point [a month ago now] had set it up that -- even though not all of the blends were the same for each DOF -- the Y DOF's filter characteristics defined the name of all the DOF's filter names for that level of button. This way, the user knew 'I get the best performance if I hit the "T40mHz_NO.44' button on the switch all' screen." This is opposed to having to know the best blend for each of the 6 DOFs and in which order to switch them in. 
I prefer the "one-button switches in all the right blends." Much better for configuration control.

[Ballmer with Kissel]
- Instead of writing in Perl, Python, or folding it into the Guardian structure, we should now have the ability (thanks to the cdsCtrlFilt2) to move the entire isolation loop turn on dance into the front end as a c-code state machine. This, if coded correctly
(1) shouldn't take more than a month off offsite development, 
(2) removes all reliance on the EPICs network and interaction with scripts,
(3) makes the user/guardian interface a more straightforward state-machine, and
(4) removes flexibility to mess things up.
I think we should do it.