no restarts reported. Conlog frequently changing channels report attached.

With both WFS and tidal running on both arm, we quickly tried DIFF. It failed.
We took out the clearing of the drivealign filters, which was the first culprit.

But it still failed.
Some more work is needed on DIFF.

COMM however worked just fine.

The green slow and tidal servos have been engaged. This is done through the arm guardian which in turn select a corresponding state from the ALS auto-locker. These states are "End Locked", "Slow Engaged", "Transition" and "Red Locked". With "End Locked" neither the slow nor tidal servo are engaged. With "Slow Engaged" they are both on, tidal feedback only in "Transition" and tidal and common mode feedback in "Red Locked". These three new feedback paths use the new integrator filter module. When the green PDH is not locked, the integrators are bled off.

The feedback topology is as follows:

• The PDH slow signal is fed into an ARM_ERR standard filter module followed by the ARM_CTRL integrator. This signal is added to the output of the common path, send through the ARM_DRIVE filter and then to the suspension controller, where it is added to the L1 stage.
• If the slow path is engaged and if "Frequency Servo" is enabled in the PDH auto-locker, the VCO servo is engaged. This should keep the VCO frequency near nominal.
• The control signal of the L1 suspension stage constitutes the input of the TIDAL_ERR filter. Its output is routed through the TIDAL_CTRL integrator to the HEPI length input.
• The common path consists of a COMM_ERR filter and a COMM_CTRL integrator which is added to the arm drive. Currently, the input to the common path is just an EPICS value, but will be replaced with the IMC-MC_F signal later.

The "Red Locked" state triggeres on the transmitted red power. Once in this state, it no longer matters whether green is locked. It can only transition back, when the red lock is lost.

Evan, Stefan

Did some more WFS/camera loop work on both arms:
 - Added a 0.3Hz LP with a notch at the main pendulum modes into the WFS output filter modules. This allows for a ~3-5 times higher gain.
 - Carefully measured the output matrix for the camera loops (X and Y arm, yaw and pitch) by dragging the ETM around and letting the WFS follow.
   The new output matrix values are in the snaphots #3 below. With them the camera loop no longer relies on gain hierarchy - it's gain was increased ~x10.
 - Some gains were redistributed - see the attached snaps.
 - Cleaned up the arm Guardian. Removed all old slow feed-back stages, and instead added a state commanding Daniel's new setup.
 - Added a WFS relief step to the Guardian.

model restarts logged for Fri 12/Dec/2014
2014_12_12 11:11 h1iscex
2014_12_12 11:14 h1iscex
2014_12_12 11:26 h1iscey
2014_12_12 11:28 h1fw1
2014_12_12 13:41 h1fw0

two unexpected restarts. ISC code changes at end stations (no daq restart needed). Conlog frequently changing channels report attached.

AlexaS, TravisS, RickS

Yesterday (Friday) afternoon, we re-focused the Y-end Pcal beam localization camera for green light in preparation for next week's efforts to clean the ETM surface.

The attached image was taken after re-focusing the camera, with the green light resonating in the Y-arm.

[Mackenzie, Evan, Paul]

Today we improved the alignment of the aux laser into HAM2, and after some searching around with the aux laser temperature control were able to observe the beat signal on the RFPD. The beat signal amplitude was around -45dBm at best, when we had 1.5V DC on the PD. I didn't check the difference between DC and AC gains for that pd, but we expect we should be able to get a significantly larger beat signal. We adjusted the aux laser alignment trying to improve the beat signal amplitude, but weren't able to get a big improvement. At this point we think that we are limited by the mode matching of the two beams: it's clear just looking at the card that there's at least a factor 2 in beam sizes at the IM4 forward trans beam path. Next step will be to make some quick mode measurements on the table and either adjust the lens currently in place or add some more to the path to get a better overlap.

Evan, Daniel, Stefan

We duplicated the full WFS + camera auto-alignment scheme on the y-arm. In particular we

 - Restarted h1iscey.mdl to include the CAM.mdl change (SVN revision 9393)
 - Set the Y Green WFS autocentering UGF's to 10Hz.
 - Re-phased Y Green WFS using a 55Hz length dither.
 - Closed all loops with the same scheme as the x-arm (WFSA-->ITMY, WFSB-->TMSY, ITMY camera-->ETMY). The camera loop relies on gain hierarchy through the WFS loops.
 - The overall gain is slightly lower on the y-arm, but all seems to work.
 - Did a from-scratch baffle-PD alignment of TMSY, aligned the y-arm to it, updated the camera config file and took a camera reference.
 - All this again seemed to work fairly reliably.
 - All medm setting are shown in the attached snapshot (the PIT and YAW output matrices are identical).


  Still TBD: Same tweaking as for the x-arm:
   - Fine-tune the output matrix - in particular the DoF3 (camera path) should be set to move all 3 optic in the right way - this would avoid having to go through a gain hierarchy.
   - Increase the loop UGF: main pendulum notches are needed to avoid a 2nd unity gain crossing.

08:50 Start of 2nd cleaning at BSC10
08:52 Bubba to end Y to turn on purge air
08:53 Filiberto to beer garden to pull cables, may bump piers on BSC3
09:08 Jeff and Andres putting together contamination control kits in the LVEA
09:20 Bubba turning on purge air compressor at end Y
09:51 Cleaning crew leaving end station
10:16 Corey to squeezer bay
11:38 Jeff and Andres back
12:04 Filiberto and Aaron done
12:05 Krishna to end Y to check on BRS
12:34 Krishna back
12:53 Jeff to end Y, setup for vent
12:58 Travis and Rick to end Y for PCAL checkout
13:21 Jeff back
13:45 Corey done
14:25 Rick and Travis back

I though I would try sensor correction again on HAM3 and I've figured out from whence comes the .6hz peak on that chamber. I don't know why, but turning on the Z sensor correction causes it. X&Y sensor correction still don't perform well on this chamber either, so I'll leave both HAM2 and HAM3 with sensor correction off and in a state that my script (previous post) won't turn on. Attached plot shows Z CPS, correction on(blue) and off(red), .6hz peak is pretty obvious. This contaminates other dofs, too.

I've written another python script to turn on seismic sensor correction. The plan is to eventually put this under Guardian control, but I wanted to make a simple 1 button turn on tool for the commissioners. It lives in the same location as the other scripts: /ligo/svncommon/SeiSVN/seismic/BSC-ISI/H1/Common/Misc/Test_Configuration_Scripts. Just cd into the fold run: ./Senscor_On.py or ./Senscor_Off.py as appropriate. This script turns on all the sensor correction on all of the chambers (ISI on HAM, HEPI and ISI on BSC), so it's more of a sledge hammer, not a scalpel.

Alexa, Daniel, Sheila, Stefan

From yesterday:
 - We re-entered and re-focused the ITMX Green camera (#22). The picture is now good enough for feed-back use.
 - Updated the camera config file (attached).

Today:
 - Updated the CAM.mdl library in isc/common/models/ - it had normalized and non-normalized inputs switched.
 - SVN Committed revision 9393
 - Dave's script now copies the camera values into the H1:ALS-X_CAM_ITM_PIT_POS and H1:ALS-X_CAM_ITM_YAW_POS fields (see alog 15587)
 - With the X Green WFS running (feed-back to ITMX and TMSX, auto-centering running) we engaged the feed-back loop to ETMX, relying on gain hierarchy through the WFS loops.
 - All this seemed to work fairly reliably, although the WFS and camera gain are extremely low - it takes about 3 minutes for pulling in the alignment.
 - With that in place, we did a from-scratch baffle-PD alignment of the whole X-arm, and noted the Green ITMX camera position: PIT: 236.78, Yaw: 354.8. For this we used the following script:
     asc/h1/scripts/ditherAlign.py TMSX
 - All medm setting are shown in the attached snapshot (the PIT and YAW output matrices are identical).


  Tweaking that could still be done:
   - Fine-tune the output matrix - in particular the DoF3 (camera path) should be set to move all 3 optic in the right way - this would avoid having to go through a gain hieararchy.
   - Increase the loop UGF: main pendulum notches are needed to avoid a 2nd unity gain crossing.

I've tried turning on ISI sensor correction at HAM 4 and 5, it seems to be working. At first I thought HAM5 was not working as well, but there must have been somebody out on the floor near the chamber, because now both chambers are performing similarly. Attached plots show only the CPS_X side of things, but the GS-13 plots weren't as clear and I'm not sure how to calibrate their signals so they line up with the STS, but GS-13's seem to agree in spirit. Correction also is working similarly in all degrees of freedom. I did this a while ago at HAM6 as well, but I don't think I saved the data. HAM's all use the same configuration with the Hua filters in X&Y and Mittleman's Z filter.

J. Kissel

I've solved the loose wires in the software problem indicated a bit ago in in LHO aLOG 15571, with the sledge hammer solution of restarting all of the front end processes. Unfortunately this is now quite an arduous process. Details of exactly what I did are below, but the problem is now solved.

This is another data point on Integration Issue 931, which remains open, because these errors happen only once every month or so -- enough time for other CDS fires to overwhelm this one. 

Curiously, it took two starts of the IOP process in order to get the AWG light to behave. Another mystery.

--------
Restart process

(1) Turn off all sensor correction, because this is not yet under guardian control. Set H1:ISI-*_ST1_SENSCOR_GND_STS_?_MATCH_GAINs to 0, and turn off OUTPUT switch for good measure
(2) Request Manager SEI GUARDIANs to take the chambers to OFFLINE (noting the state from whence they came. Beam Splitter is ISOLATED_DAMPED, ITMs are FULLY ISOLATED)
(3) Save any alignment offsets on the SUS for the current state they're in, if GUARDIAN is warning you they're not saved
(4) Request the SUS GUARDIANs to take the SUS to SAFE (noting the state from whence they came AND the EPICs values of the alignment offsets)
(5) Take the opportunity to grab a updated safe.snap file, and commit to userapps repo.
jeffrey.kissel@operator1 ]$ makeSafeBackup sus h1susbs
(6) Log into the h1susb123 front end as controls
(7) Kill all USER front-end processes
controls@h1susb123 / 0$ killh1susitmx
controls@h1susb123 / 0$ killh1susitmy
controls@h1susb123 / 0$ killh1susbs  

(8) Restart IOP front process, make sure to have GDS_TP screen open, to hit the BURT button once EPICs comes back
controls@h1susb123 / 0$ starth1iopsusb123 
h1iopsusb123epics H1 IOC Server started
Burt restored /opt/rtcds/lho/h1/target/h1iopsusb123/h1iopsusb123epics/burt/safe.snap
Old : H1:FEC-28_BURT_RESTORE         1
New : H1:FEC-28_BURT_RESTORE         1
 * WARNING:  awgtpman_iop has already been started.
controls@h1susb123 / 0$
(9) Restart USER front-end processes, make sure to have GDS_TP screen open, to hit the BURT button once EPICs comes back
controls@h1susb123 / 0$ starth1susitmx    
h1susitmxepics: no process found
h1susitmxepics H1 IOC Server started
Burt restored /opt/rtcds/lho/h1/target/h1susitmx/h1susitmxepics/burt/safe.snap
Old : H1:FEC-29_BURT_RESTORE         1
New : H1:FEC-29_BURT_RESTORE         1
 * Starting h1susitmx awgtpman ...                                                                                                                                                                [ !! ]
controls@h1susb123 / 0$
(rinse and repeat for the other two SUS)
(10) Reset all watchdogs on SEI, SUS, and IOP (there's about 30).  << --- It's only at this step d'you know if you've actually fixed the problem
(11) Request SUS GUARDIANs to return to original state (whether it be aligned or misaligned, make sure alignment offsets have been restored properly)
(12) Request SEI Manager GUARDIANs to return to original state
(13) Go through CDS OVERVIEW Screens and hit "DIAG RESET" in the upper left corner of any GDS_TP screens which show an IPC Error in the CDS STATE WORD. The IPCs glitch on start up, and the error latches, so it just needs to be cleared. If it goes red again after a few seconds, then there's *actually* a problem.
(14) Turn sensor correction back ON by first turning ON the MATCH OUTPUT, and then ramping up the gain back to 1.0, with a ramp time of something like 10 to 15 seconds. 



I've turned on the following sensor correction configuration configuration for all three BSC chambers:
- Ryan's IIR filters, SC-rdr, FM2 for X & Y with a gain of 1.0. Only the BS has a "MATCH" filter (just a gain of 1.03), which I've left ON as I'd found it.
- Rich's IIR filters, Mitt_SC, FM6 for Z with a gain of 1.0.

For the record, both the ISI and HEPI Sensor Correction Screens still suck:
- The filters that we actually use in the GND sensor correction are not visible on the sensor correction overview
- The links to sub-screens are ambiguous locations on the SC overview. Thus, one can pull up different screens -- that don't look different at first glance -- depending on where you click
- In the HEPI sensor correction overview, there's no link for the full MATCH filter bank, so you have no control over / knowledge of important things like the ramp time
- Remove ST0 to ST1 HEPI L4C Feed forward path, it's currently not used and there's scientific motivation (pending) that it should never be used.

Looking at the sensor readbacks they seem to work.