Ran TFs on H1-SRM last night, see attached plots. Results showed rubbing, suspected as being on the Top Mass side. A check of the suspension found both the left side EQ stops were touching the mass, which we backed off. We rechecked all other EQ stop and adjusted as necessary. We centered the Tablecloth, BOSEMs, and reset to 50% light. The TFs are setup to run tonight starting at 18:00.

PT343B never "fired" following a previous power failure -> closing this valve isolates PT343B from the beam tube (pump) which may result in a large enough rise in pressure "seen" by the gauge to support discharge

daqd process died, final messages include 
"start net-writer 1034523398 17204 { long list of channels", 
"->4 kill net-writer 0", 
"connection on fd 15 closed", 
"read(seq_num) from NDS failed; errno=0", 
"connection closed on fd=16", and 
"Ask for retransmission of 20 packets; port 7097" which was repeated many times, then 
"Have to skip 22 packets (retry limit exceeded)" as the last entry.

Restarted daqd process.

Mark B.

After Filiberto and Betsy had poked around on MC3, Betsy was able to start a yaw TF with DTT and see coherence, so the electronics is better off than it was.

To see where we're not at, I started a suite of Matlab TFs at about 16:20 and will check on it from home tonight.

As of 10:35, the measurement has failed twice with the USER DACKILL (but not the WATCHDOG) tripping. Trying one more time…

USER DACKILL found tripped at 06:35, after end of third attempt - giving up for now.

• Kyle visited Y-End station to open RGA volume into vacuum system, also visited MID-X to soft close valve for PT343A/B, see his entries.
• Rick and Craig, visited both Mid stations.
• Hugh and company at HAM02.
• Filiberto worked on MC03 issues at H1CDS-ER.
• Betsy visited MC02 and PR02, earthquake stop gap issue.
• Cheryl at PSL room, as of this entry she continues there.

With my help, Ed & Zach of Apollo, installed and attached the HEPI Actuators on WHAM2.  We did have a few mechanical issues as the positioning of the chamber (and hence the Support Tubes and HEPI Housings) drifted from the Initial alignment baseline.  We had to increase the size of a few slots to allow travel of connecting components.  Still all attached and it appears we have no motion issues.   We'll see for sure when we make range of travel measurements after the HEPI plumbing has us back operating.

B. Bland, F. Clara, J. Kissel

At the request of Betsy, given the confusion on the inability to drive MC3 (see LHO aLOG 4462), I took a quick look through the software side of things to be sure all was well, and indeed I see nothing out of the ordinary. 

Here's my assessment:
- There have been software changes involving the IOP model (modifying the IOP watchdog) on Oct 09 (see LHO aLOG 4402), and also hardware changes (swapping out MC3-only, T3LFRTSD quadrapuss cable) on Oct 11 (see LHO aLOG 4423), before Mark attempted to take transfer functions on Oct 12-13 (see LHO aLOG 4432) which show no coherence (again, according to LHO aLOG 4462).
- Filiberto reports that 
     - He can see drive going into (from the AI chassis) the coil driver chassis (though I didn't catch exactly to which cables he was referring), implying the that software checks out, i.e.
          - The BIO I/O is functional (arranged/routed properly in software, traveling well across shared memory)
          - The IOP watchdog is allowing signals to flow
     - He cannot see anything coming out of either the COIL or TEST outputs (going towards the SatAmp on the way to in vacuum).
- Betsy reports that 
     - MC1 is able to drive and transfer functions look normal, implying that
          - the shared cable between MC1 and MC3 remains functional
          - The BIO I/O is functional and allowing drive
          - The IOP watchdog is allowing signals to flow
     - She's cranked on the centering knobs for each OSEM involved with the T3LFRTSD and confirms correct sensor response implying that signal chains are connected to the right OSEM

From we conclude that something is awry with the drive signal chain between the input to the coil driver from the DAC / AI chassis to the tip of the in-vacuum quadrupuss cable for T3LFRTSD. This leaves the following possibilities:
- Coil driver board has malfunctioned
     - Can we see anything coming out the coil driver monitor boards in either TEST or COIL configuration? Looks like the noise monitor channels are white -- does this model not exist yet / is it not running?
- The Binary I/O switch chain had failed
     - (though the monitor bits indicate that the chain is functional, both in the TEST/COIL switch and LP switch)
- The rest of the ex-vac chain has failed somehow (Coil Driver to SatAmp cable, SatAmp pass-through, SatAmp to fake-feedthrough)
- The rest of the in-vac chain has failed (the quadrupuss has been swapped, but how about the D0900225?)

Good luck!

(iLIGO RGA was valved out month(s) ago) 

Also, energized iLIGO RGA filament

Medm overview showed white fields for h2nds0.

Found daqd process on h2nds0 had problems - last log message indicated "couldn't create interpreter thread; pthread_create() err=11" and "connection dropped on port 38943 from ; fd=17"

Two nds processes were running, one with an uninterruptible sleep state.  

Then the processes disappeared.

Restarted nds and daqd processes.

I am now running the modified dust monitor code at end Y.

I am now running the modified dust monitor code at end Y.

Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot. The data was taken from approximately 6 AM to 6 PM.

Betsy, Travis

This afternoon, we swapped the metal MC1 dummy mass out and replaced it with the IMCF09 mode cleaner flat optic.  Using the auto optical lever to look at the prisms on each side, we set the roll of the mass to within ~0.1mm.  We then noticed a small pitch error by eye which we corrected for using the top mass sliding pitch mass.  This brought the 6 top BOSEMs back into range, as set during the build phase across the street.  We'll continue to tally and align all 6 DOF errors tomorrow.

JimB, DaveB, HugoP,

HAM3-ISI used to have temporary medm screens for payload state monitoring. We rebuilt the HAM3-ISI model with a call for the create_hamisi_payload post-build script. This script automatically creates unit-specific medm screens for payload state monitoring. The call for create_hamisi_payload was set in the block properties of the HAM3_PAYLOAD block, in the simulink model of HAM3-ISI (see attachement #1).

We did the same for HAM2-ISI.

make install would then return an error due to issues with CDS. These issues were corrected.

I updated the HAM-ISI overview screen so it automatically points to the new payload screens. The unit-specific payload monitoring screens now work for both HAM2-ISI and HAM3-ISI (see attachement #2)

I removed the shutter alarms from the PSL alarm configuration file and added alarms for the power watchdogs on the amplifier and oscillator.

We almost have the 6th of eight Actuators in place.  We had to make a few mods to brackets given the large translation East for this platform.  These last attachments should finish mid-morning.

Updated the userapps-user-env scripts on h1, then modified perl environment setup scripts to correct errors of looking in the wrong directory.  This was done to support post build scripts.

• Snovalley, Ace porta-potty, UniFirst, Paradise water, fire department on site
• One LN2 delivery to CP5 today
• Ski at MY checking on equipment
• Kyle at EY looking for pump cart
• Filiberto at HAM2 pulling cables

Looked at MC1 (Bottom stage) UL channel, which showed low counts ~9000 compared to the expected 24,000 counts. Traced problem to IO Chassis (h1sush2a). Replaced ADC card SN110201-04 with SN110203-20. Problem still persisted, replaced ADC Adapter Board (D0902006 SN S1102390) and cabling inside IO chassis with a spare (no SN number). Have requested a replacement from CIT. Will replace sometime next week, but SUS is able to continue transfer functions on MC3.

Filiberto Clara