The H1 workstations in the control room now have a controls account.  Use caution, the controls account is the same home directory for H1 and H2, but the environment will be set up for H1 on the H1 workstations and H2 for the H2 workstations.  So, even though the controls account looks the same on H2 and H1 workstations, you cannot do H2 work on an H1 workstation, or H1 work on an H2 workstation.  Confused?  The H1 workstations are labeled as such with a tag on the upper left corner of the display.

The background of the controls account screen will no longer indicate it is "H2".

	HSTS MC1 has been moved to the testing bench and cabled to the test stand. The offsets and gains have been entered into the MEDM screens and the OSEMs have been positioned to 50% light. We will recheck and adjust the 50% light positions in the morning, if necessary. This suspension should be ready for Phase 1 testing. 
	
 M1 BOSEMs
 T1 S/N 578 OL = 25960.0 Offset = -12980 Gain = 1.156
 T2 S/N 436 OL = 29277.9 Offset = -14639 Gain = 1.025
 T3 S/N 440 OL = 27858.1 Offset = -13929 Gain = 1.077
 LF S/N 433 OL = 27758.7 Offset = -13879 Gain = 1.081
 RT S/N 424 OL = 24529.4 Offset = -12265 Gain = 1.223
 SD S/N 658 OL = 25139.5 Offset = -12570 Gain = 1.193

 M2 AOSEM
 UL S/N 453 OL = 27359.6 Offset = -13680 Gain = 1.097
 LL S/N 320 OL = 24780.7 Offset = -12390 Gain = 1.211
 UR S/N 228 OL = 25117.9 Offset = -12559 Gain = 1.194
 LR S/N 438 OL = 25521.6 Offset = -12761 Gain = 1.175

 M3 AOSEM
 UL S/N 227 OL = 28354.2 Offset = -14177 Gain = 1.058
 LL S/N 353 OL = 26509.5 Offset = -13255 Gain = 1.132
 UR S/N 276 OL = 27920.9 Offset = -13960 Gain = 1.074
 LR S/N 299 OL = 28435.2 Offset = -14218 Gain = 1.055
  

The login scripts have been modified for the controls account to allow use of the account for either H1 or H2.  This should have minimal impact on H2 users.  Let me know if there are problems with the environment for controls.

Jim & Greg adjusted the level of the HAM3 ISI Table using HEPI Springs.  It was a little slower than expected.  We are ready for IAS to take another look before we continue with the HEPI Actuator installation.

• EY Gate Valve closed (John, Kyle)
• Installation of EY Oplev Housings (Thomas, Mark D.)
• Lots of One-Arm work  (which was being coordinated with SEI/SUS measurements & the oplev work)
• EX Weather Station re-started (Patrick)
• H1 iLIGO EY Oplev beam enclosure removed from viewports (Gerardo)

As of around 4pm, sounds like the Gate Valve (GV18) will be opened tonight for OAT work.

John W. observed that actuating GV18 for 4 minutes and 18 seconds did not hard-close the valve, i.e. is a good value to use for soft-closing GV18.  

History:  The individual actuation times resulting in a hard closure of the beam-tube valves (electric) was observed and recorded early on.  This value is used to determine the actuation time to soft-close a given (electric) beam-tube valve.  We are now wanting to record the actuation times of all of the electric valves.  

Rebooted h2pemeyaux at 17:55 PDT July 10 to set IPMI address to correct value after reassigning the IP address of the computer, following dcuid value changes to the models running on the machine.

I started the evening shift with calibration of the VCO + Frequency divider used for the ALS PLL (S1200570 and S1000748).  The objective was to measure the response of the VCO output to its Tune input, which is used for locking the arm cavity and thus provides a good calibration point for the arm cavity signal.

I set up the DC calibration measurement with a signal generator (output displayed on a scope to be sure), and a frequency counter.  I took 6 samples between -1V and 1V, which resulted in an excellent linear relationship: f = 39.6MHz + 139 kHz/V * V_tune.  For example, at V_tune = 1V, I measured f = 39.739 MHz.  This is not the expected result of 50kHz/V given the nominal 100kHz/V from the VCO and the division by 2 which takes us from 80MHz to 40MHz.

From there I moved on to measure the AC response.  I did this by rigging up a frequency to voltage converter with some bubble gum and duct tape I found nearby.  The output of the converter was 725mV / V_tune.  With the help of an SR785 and a lot of patience I turned this into a response measurment between 0.5Hz and 10kHz.  I saved the curves on the SR785 floppy, which is a lot like throwing them into a black hole, so I also wrote down a few points: {-30.7dB, 178dg} at high frequency, {-27.7dB, 138dg} at 40Hz, {-16.8dB 112dg} at 8Hz, {-5.8dB, 136dg} at 1.6Hz and {-3.26dB, 136dg} at 5.62Hz.  These are well fit by the measured DC response and the expected 1.6Hz pole and 40Hz zero.

Lastly, in preparation for using this calibration for the arm cavity, I cabled up an SR560 to the IR_PWR_MON channel.  The SR560 is AC coupled with a gain of 10, and the tabletop interface gain is set to 10.  From the output of the SR560 to counts of IR_PWR_MON, I measured 32060 counts/V.  Just to be sure, I checked the gain of the SR560 and appears to be very close to the stated value of 10, so we should expect 320.6 counts/mV refered to the SR560 input, which is attached to V_tune.  Assuming the above VCO calibration is correct, this converts to 0.434Hz/count as seen at IR_PWR_MON.  The cavity should lock should convert length to frequency as L_cavity / f_laser = 3995m / 5.635e14Hz = 7.09 pm/Hz, so we will be left with 3.07pm/count as our length calibration.   (To relate this to the number found with the OSEMS in 3363, we should remove the gain of the SR560, the TTIF box, and another factor of 10 for the FMON signal filtering.  This would give 3nm/count instead of the 1nm/count found with the BOSEMS, so somewhere we're missing a factor of 3, not unlike the 139kHz/V vs. 50kHz/V discrepence... to be investigated tomorrow in the light of day.)

On a side note: I found the PLL unlocked and no beatnote evident.  On closer inspection there was no light coming from the fiber, so I went to the optics lab and found the laser in Standby.  I have no idea why it would be left in this state, since this clearly makes cavity work impossible.  That should have been enough to make me leave it as I found it, but instead I turned it back on and relocked the reference cavity.  From the trend data, it looks like it unlocked about 15 hours ago (at 16:20 UTC, see figure).

Short story: I created a manual burt backup and burt restore script to back up the PLL and PDH common mode board settings in the EY Beckhoff system. You can find them in /ligo/home/controls/bram.slagmolen/burt/h2etcatey and are called h2ecateyBurtbackup and h2ecateyBurtrestore. They use a local autoBurt.req and safe.snap file.

Long story: Every time the beckhoff system in EY breaks all settings are losts, this greatly inconvience the the locking of the PLL and the PDH system.

Patrick T. generated an autoBurt.req file from Beckhoff system h2ecatey at EY with all the epics channels.

With help from Dave we created and place the autoBurt.req file in the target directory and created a safe.snap file in the burt/ direcotry (burtrb -f autoBurt.req -o safe.snap).

> controls@opsws5:burt 0$ pwd
> /opt/rtcds/lho/h2/target/h2ecatey/h2ecateyepics/
 

I edited the autoBurt.req file adding 'RO' infront of some channel names, this prevented some errors while creating the .snap file.

When trying to restore from the .snap file, not all settings are restored correctly. With some digging around, it seems that when we added and set '.ZNAM Off ' and '.ONAM On' to the variable names it seemed to work. In addition in the autoBurt.req file I added .VAL to the same channel names. I only did this to few required channels in the PLL and PDH CM path. After a burtrb the burtwb worked correctly.

This is seemed only required for the toggle swithces. Why this is required I don't know, although this doesn't happen with the QPD whitening channels. I think the OPC database may need some work.

When the Beckhoff system is rebooted all the .ZNAM and .ONAM addition are lost. I made a little script set_ZNAM_ONAM_records to add these again (not tested but should work). 

A listing of the directory follows:

controls@opsws5:h2etcatey 0$ pwd
/ligo/home/controls/bram.slagmolen/burt/h2etcatey

controls@opsws5:h2etcatey 0$ ls -al
total 156
drwxrwxr-x 2 controls controls  4096 2012-07-10 18:44 .
drwxrwxr-x 3 controls controls  4096 2012-07-10 15:53 ..
-rw-rw-r-- 1 controls controls 28005 2012-07-10 17:39 autoBurt.req
-rw-rw-r-- 1 controls controls 27971 2012-07-10 16:17 autoBurt.req~
-rwxrwxr-x 1 controls controls   241 2012-07-10 18:20 h2ecateyBurtbackup
-rw-rw-r-- 1 controls controls    38 2012-07-10 16:55 h2ecateyBurtbackup~
-rwxrwxr-x 1 controls controls   225 2012-07-10 18:21 h2ecateyBurtrestore
-rw-rw-r-- 1 controls controls 34666 2012-07-10 18:23 safe.snap
-rw-rw-r-- 1 controls controls 31283 2012-07-10 17:01 safe.snap~
-rwxrwxr-x 1 controls controls   716 2012-07-10 18:44 set_ZNAM_ONAM_records
-rw-rw-r-- 1 controls controls   703 2012-07-10 18:09 set_ZNAM_ONAM_records.txt
-rw-rw-r-- 1 controls controls   498 2012-07-10 18:07 set_ZNAM_ONAM_records.txt~
controls@opsws5:h2etcatey 0$

 

Attached are plots of dust counts > .5 microns in particles per cubic foot.

Work resumed following yesterday's "Stop Work" and today's subsequent "Stop Work Release"

The first thing I found in the morning was that Beckhoff was dead.

On Windows computer that runs Beckhoff, both of two PLCs showed an error message dialog box ("connection error" or some such) and it was not talking to the hardware.

Alexa did several attempts to make it work without rebooting Windows, but eventually Patrick rebooted Windows.

This did the trick, but it had a side effect of wiping the settings for OPC variables (again).

Bram is working on a sad implementation of burt restore.

Jim Jason & Hugh
The Initial Alignment Subsystem(IAS) crew gave us the bad news late morning and we translated East 5mm shortly after lunch.  Given all the initial movement we saw on the Dial Indicators when we first floated & further when we tweaked the level yesterday, I'm not surprised by this shift requirement.  And you all have heard my spiel about from where our initial position originated.  Anyway, after the East shift we were almost bang on N-S & rotationally with ~.5mm & 300urad to correct.  That done, East-West checked again and still good.
Now back to level and elevation: our runout on the table level is 0.3mm and we are ~0.4mm low in elevation.  Tomorrow we will bring this back in and attempt to equalize the load cell readings while we are at that and finally followed by a revisit of the table position by IAS.

The attached pdf plots the first transfer function measurements completed on the H1SUSMC2 triple suspension slated for the HAM3 install in the LVEA (chamber-side). The suspension has been cabled and powered by the H1 Production electronics. After the assessment of the BIO switch cabling by Richard M., the CDS crew were able to configure the CDS network to allow awgstream excitations to the H1 electronics.

The measurements were run on a newly-configured H1 workstation in the Control Room named "opsws0".  The results are postitive with excellent coherence on all DoFs.  The resonances are clearly visible and match reasonably well with measurements from the Staging Building. 

---------------------------------------------------------------------------------------------------------------
As a note to other users of DTT on the new H1 workstations:

To open a DTT session with the correct server configuration settings, special command line arguments must supplement the usual "diaggui" command.  The H1 channel lists are now grabbed from the "h1nds1" server. 

To open DTT on H1:
>> diaggui -n h1nds1 -m 8088
----------------------------------------------------------------------------------------------------------------

	DTT XML files: /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM1/Data/


	2012-07-10_H1SUSMC2_M1_WhiteNoise_L_0p01to50Hz.xml
	2012-07-10_H1SUSMC2_M1_WhiteNoise_T_0p01to50Hz.xml
	2012-07-10_H1SUSMC2_M1_WhiteNoise_V_0p01to50Hz.xml
	2012-07-10_H1SUSMC2_M1_WhiteNoise_R_0p01to50Hz.xml
	2012-07-10_H1SUSMC2_M1_WhiteNoise_P_0p01to50Hz.xml
	2012-07-10_H1SUSMC2_M1_WhiteNoise_Y_0p01to50Hz.xml

	Individual (by DoF) and coalesced PDF files are located in:
	/ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM1/Results/

	2012-07-10_H1SUSMC2_M1_WhiteNoise_All_DOFs_0p02to50Hz.pdf

Round 1 of HAM 3 table axial positioning, translation setting, rotational positions are dialed in. A second alignment will be done tomorrow after ISI crew completes their installation and we re-level the table.
Alignment tooling worked well an is simple to set.

Craning work in the LVEA in the morning hours
End-Y Optical Lever cover installation
Richard M. at End-Y to cable WFS and Beckhoff system
Rebooting of H2 machines by CDS during the Tuesday morning maintenance hours (8:00AM - 12:00PM)
Closing of Gate Valve 5 by Kyle 
Transfer function measurements on H1SUSMC2 by Jeff G.

J. Kissel, P. Fritschel,

Curious about the various features seen in Matt's spectra of the cavity length, Peter and I grabbed some data during the long stretch of cavity lock that Matt mentioned.

Attached are the results:
We show the ASDs of
- (What we believe to be) Ground Seismometer at IY, (we think) Y direction [(we think) uncalibrated]
- (What we believe to be) Ground Seismometer at EY, (we think) Y direction [(we think) uncalibrated]
- Input to the Isolation Filters of Stage 2 of BSC8-ISI (ITMY), Y direction in [nm/rtHz]
- Input to the Isolation Filters of Stage 2 of BSC6-ISI (ETMY), Y direction in [nm/rtHz]
- The input to the cavity control loop at the TOP / M0 of the H2 SUS ETMY, in L [uncalibrated]

and the coherence between all of the above with respect to the cavity length signal.

A couple of things that we can tell from these plots:
- The 0.12 Hz peak in the cavity L signal is most likely indeed just the micro-seism (even though it's incoherent with these Y direction sensors), because the frequency content of the ASD is roughly the same.
- The 1.05 Hz peak in the cavity L signal, which we believe is the second L/P mode of the QUAD, is NOT present in the ISIs or on the GND.
- The 0.43 Hz peak in the cavity L signal, which we believe is the first L/P mode of the QUAD, is also not terribly present in the the ISIs or the GND
- The BSC8-ISI (ITMY), which (we believe) has HEPI displacement sensor loops and high-blend ISI isolation loops, is directly, coherently transmitting ground motion into the cavity, as told by the coherence, between ~0.4 and 1.0 Hz -- and BSC6-ISI (ETMY) is not. I convinced myself that this made sense for BSC8-ISI (ITMY), because both the HEPI displacement sensor loops and the high-blend, mostly displacement-sensor-up-to-0.75 Hz, ISI loops are actively "locking" the platforms to the ground. The only sensible thing we could come up with for why the GND and ISI at the end were not coherent would be if the GND Y was not actually, as in the sensor was rotated, or we picked the wrong channel, or it was poorly labeled, or whatever. BUT that doesn't explain why the BSC6-ISI (ETMY) sensor was incoherent with the cavity length...
- It's confusing as to why the micro-seism is incoherent with everything.

Food for thought!

-------
Data is stored and committed to
/ligo/svncommon/SusSVN/sus/trunk/Common/Data/2012-07-10_H2OAT_ASDs.xml

HAM-ISI Unit #6 was balanced, and CPS readouts were within acceptable range, on 07/03 when we left it for long TF measurments. When checked this morning, CPS readouts featured an offset of approximately +/-3000 counts:

There is no drive/offset on MEDM channels.

Coil drivers were turned off. The CPS readouts remained unchanged.

CPS interface chassis were turned off, and then turned back on. The CPS readouts remained unchanged.

Dataviewer plots are attached. They show the drifting of the CPS readouts.

We experienced high temperatures over the last few days.