Here is a block diagram of the signals that go into the summing node board, the IFO common mode board and the IMC common mode board during the CARM handoff.  It can be used as a reference when following the recent commissioning alogs.

7:30? Karen, Cris - LVEA

8:15 Elli - To EX and EY

8:20 Corey - To Squeezer Bay and around LVEA

8:32 Mitch - To W. Bay

8:41 Sudarshan, Thomas - To EY

8:46 P. King - To H2 Enclosure

8:47 Mitch - Back

9:10 R. McCarthy - To EY

9:17 Greg - To LVEA

9:27 Greg - Back

9:34 Corey - Back

9:58 R. McCarthy - Back

~10 J. Kissel, Hugh - To Pump Room setting the pump servo to manual

10:59 J. Kissel, Hugh - Back for meetings, pump servo still on manual.

12:23 R. McCarthy - To EX and EY

12:48 J. Kissel, Hugh - To HEPI Pump

13:02 Alastair, Elli - To LVEA to work on TCSY table

14:05 Alastair, Elli - Back

14:05 J. Kissel, Hugh - Back

15:40 Jodi - To MY

15:44 P. King - Back from H2 Enclosure

Earlier today, with Ryan's encouragement, I turned on more of the I/ETMY isolation loops. Currently these 2 ISI's are running a configuration like LLO's, with all DOFs engaged on St1 and X,Y,Z,RZ running on St2. The St1 RZ loop is running a high (750mhz) blend with no T240. St2 is running the same 250mhz blend on Z and RZ as it was previously running on X and Y. The Stage Guardians for these two chambers have also been modified to turn on these loops, in case we have some traumatic event.

FF is now running on all test mass chambers as well with X&Y running on ETMY, Y on ITMY and X on E/ITMX.

Alastair, Elli, Jamie

We're working on Guardian today, and wanted to install a beam dump at the output of the Y-arm table so that we can play with that laser without injecting power to the CP.  While doing this we discovered the laser was running only at 1/2 power.  The history to this is that a few months ago the same laser was running at half power, and after swapping in a different driver, went back to full power.  The "not working" driver was sent to Caltech where it was found to be working fine.  So this new episode was actually quite useful in finding that a problem still exists.

We went out to the LVEA and found that the power connector at the patch panel is badly connected.  We couldn't effect a permanent solution in the 1hr window we had, but were able to get the laser back to full power again.  These connectors will likely need replaced long term, and we'll start working on a solution to that.

The ouput of the table was found to be dumped to a beam dump already (it has been like this since installation of the table was completed).

Minor changes to the drift monitor threshold updater script:

The log files are now recorded to: "/opt/rtcds/userapps/release/sus/common/medm/sus_driftmon_logs/", and have the following file name structure: SUSDRIFT_{OPTIC NAME}_{START_TIME}-{DURATION}.log (e.g. SUSDRIFT_ALL_1107199664-15.log, SUSDRIFT_MC1_1107199664-15.log)

no restarts reported.

Kiwamu, TJ, Elli

This morning while EY plugging HWS cables into the ISCTEY feedthrough panel, I touched the fiber bringing the red PLL reference  signal to EY.    This changed the fiber wrong polarization (see chanel H1:ALS-Y_FIBR_LOCK_FIBER_POLARIZATIONPERCENT) from 1% to 32%, which is above the maximum allowable value of 30%.  This fiber is also connected to ISCTEY feedthrough panel, and then some of the fiber is sitting on a coil on top of ISCTEY.  All I did to change the polarization was to gently move the coil on top of the table.  When Kiwamu and TJ noticed the polarization had changed, I nudged the fiber coil on top of the table around a bit untill the fiber polarization returned to 8%. It seems it is very easy to bump the fiber and change the polarization.

We had another lock of about 40 seconds, durring which all the signals seemed more stable than last night.  It was knocked out by an oscillation that showed up in boh the MICH WFS and MICH length loops.  We added an extra boost (2 poles at 0.1 and 2 zeros at 2Hz) to the CARM path, which seems to have made things more stable.  The lockloss time was 11:56:32 UTC Feb 5th.  

Today we saw that our alingment was drifting much more quickly than we had seen in the last few weeks.  Without ASC we could only lock DRMI for a few minutes before MICH would get misaligned.  The attached screenshot shows the slow drift of ITMX pitch, the red trace, which is about 1.5urad over the last 3 hours.  We are not sure if this is real or just OpLev drift.   Wspent some time on the MICH ASC loops.  We phased ASB 36 so that the BS shows up in Q, and saw that this is a better signal for the WFS throughout the CARM offset reduction, which is what Ryan says they saw at LLO as well.  They come on with a bandwidth of about 1 Hz, and hold the DRMI buildup is stable.  

We also ran into difficulty tonight with the PSL rotation stage, it stopped responding to the command button for several hours.  We need some code that checks if the input power is really the requested power, or we could try running through the whole sequence at the same power. 

This is the conlog replica.

It appears to have started around 5:00 PM and repeated each hour after. I had to restart the database replication, it appears that the database has been crashing in response. It may not be a coincidence that the search for frequently changing channels also runs every hour, so I have disabled it.

cdsadmin@h1conlog3:/var/log$ grep error syslog
Feb  4 17:04:08 h1conlog3 kernel: [2335398.323116]          res 51/40:0a:16:e8:88/00:00:00:00:00/0b Emask 0x9 (media error)
Feb  4 17:04:08 h1conlog3 kernel: [2335398.323407] ata3.00: error: { UNC }
Feb  4 17:04:08 h1conlog3 kernel: [2335398.344358] Add. Sense: Unrecovered read error - auto reallocate failed
Feb  4 17:04:08 h1conlog3 kernel: [2335398.344367] end_request: I/O error, dev sda, sector 193521686
Feb  4 17:04:11 h1conlog3 kernel: [2335401.397976]          res 51/40:02:16:e8:88/00:00:00:00:00/0b Emask 0x9 (media error)
Feb  4 17:04:11 h1conlog3 kernel: [2335401.398264] ata3.00: error: { UNC }
Feb  4 17:04:11 h1conlog3 kernel: [2335401.420344] Add. Sense: Unrecovered read error - auto reallocate failed
Feb  4 17:04:11 h1conlog3 kernel: [2335401.420352] end_request: I/O error, dev sda, sector 193521686
...

(Peter K, Richard M, , Filiberto C, Daniel S)

We noticed that the fast channels corresponding to H1:IMC-PWR_IN and H1:IMC-PWR_EOM were never hooked up. This required installing the PD interface box in the PSL enclosure, running the DAQ cable into the PSL and installing a tee in the photodetector readback. (These channels have previously been hooked up to the EtherCAT system, so they that they are available to the rotation stage.) The EOM channel is currently railed and needs an adjustment of the PD gain.

EPICS updates:

• Added buttons for these channels to the IMC overview screen.
• Fixed the screen for the PSL rotation stage in the sitemap.
• Added rotation stage button to the IMC overview screen.