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

Noticed IP11 and IP9 were still outputting 5000V even though their surrounding pressures were < 1 x 10-8 torr -> Made slight corrective adjustments to the pump current values at which point these pumps switch from 5000V to 3000V outputs.  As found, they were programmed to change at pump currents of 5 x 10-5 amps.  This value of current corresponds to a pressure which is lower than 1 x 10-8 torr which is the point they should be switching to result in the most efficient pump speed.  The new value is 1.5 x 10-4 amps.  

Restarted all models on h1seih23, h1sush2a, and h1sush34 to clear timing issues for the IOP models and to restart dead models.  Appears as if the dolphin network got glitched due to front-end computer restarting without being disconnected.

For the 200W beam. The modescan script could only get 8 seconds in before it crashed.

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

Hugh, Jim, Hugo,

We measured the level of stage 1 this morning. Results are attached. Stage1 appeared tilted by ~170 µrad. This result is beyond the 100 µrad of the acceptance criteria used during the assembly-validation phase.

We recently changed the shim thickness on locker D. In order to make sure that it is not the cause of the mis-levelling, we measured the level on stage1, just above the locker D when the ISI is locked, and compared it to the same measurement when only the locker D is unlocked. The shift in level is less than 1mil. Hence, the adjustement we made on locker D is not the cause of the mis-levelling we observed.

Changing the shim of locker D is the only serious mechanical modification we made on HAM3-ISI after the suspensions (MC2 and PR2) were approved. We then conclude that the suspensions were tested under the current configuration without being affected by it in a noticeable manner.

We measured the level of stage 0 around the lockers. We did not detect such a mis-levelling there (see attachement).

The assembly validation testing is performed with a ~600lbs pounds on top of the ISI. The mass distribution is very different now that the ISI is loaded with suspensions, optics, and 10kg masses. We currently suppose the new mass repartition would have affected the flatness of the optical table, and thus the level measurement which is performed along its edges.

  Jeff B & G2

  We released the Intermediate Mass EQ stops on MC2 and PR2, so Seismic can continue testing the HAM-3. All masses on both suspensions are now free.  

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