• Flurry of activity continues around BSC8
• Apollo is surveying/laying foundation for Mode Cleaner Tube display
• Vern/Vincent physically disconnected power cables from ISI Coil Chasis for continuing diagnosis
• Dave implemented a model change for ISI and this required a DAQ reboot
• Brazing of refrigerant lines is taking place in Kyle's Mechanical shop
• Have had Dust Monitor #15 Major Alarms (nothing over 500 counts this morning)

Attached are plots of dust counts > .5 microns. The dust monitor in the clean room over BSC8 (H0:PEM-LVEA_DST15_5) was momentarily disconnected, but this does not really show up in the included plot of H0:PEM-LVEA_DST15_MODE.

I and Dan confirmed that shells of ALL in-vac cables that are connected to CDS side are grounded to the metal parts of ISI and TMS. I'm talking about all cables related to ETMY, ERMY and TMSY. There is a huge potential risk of ground loop(s).

The cause of this is NOT in four ISC cable chains (picomotor, beam diverter, and two QPD cables). This was confirmed by disconnecting all ISC cable chains from the CDS side at the moc feedthrough: When we did this, the shells of disconnected in-vac cables were isolated from the metal parts of ISI/TMS.

We haven't exonerated the two BOSEM cables of TMS yet, as well as all ETMY and ERMY cables.

What is likely happening here is:

• There is one or more crappy cable clamp which physically grounds the cable shielding to the metal in-vac parts.
• Cable shields are connected to pin 1 in-vac, which is connected to pin 13 out-of-vac.
• Pins 13 are connected to each other on CDS side.
• Thus, the shell of any good cable is connected to the metal in-vac parts via CDS and crappy cable.

Even though there seems to be no DC-coupled "loop" as far as ISC table/cable is concerned in the above picture, basically the ISC cable shields on the ISC table are within 1/32 inches or so of the table surface for the entire length and there certainly is a capacitive coupling. And if there are two crappy cables, they form DC-coupled loop, even though that's not ISC. This is bad.

One crappy cable might be the cause of the entire thing.  I can continue testing the remaining two TMS cables, but if we're unlucky we might need to check each and every in-vac cable including ETMY, ERMY, TCS and ISI cables, and I need cooperation from all parties.

After pulling back the ACB and removing a few panels of flooring, QUAD vibration absorbers, sleeve and Fiber Guards we made more inspections of the ITMy weld horns.  The following collection on ResourceSpace is of the shortest broken horn:

https://ligoimages.mit.edu/?c=1002

We do not see any cracks further down into the horn or ear.  We used a swab wipe to brush away some of the debris on this ear in order to facilitate further inspection, hence why some of the pictures may look a little different when compared.

HEPAs are installed, ceiling and several wall panels have been left off for electrical inspection. Gang plates were installed. Gerbig has left but will be coming back in late March.

Brian, Fabrice and I have found that there is an odd discrepancy between the value of the watchdog recorded by the framebuilder and the value recorded by EPICS. The EPICS value reads 4, while the framebuilder value reads 0. These should be reading the same value, since they are both a part of the same filter module (H2:ISI-ITMY_ST1_WDMON_STATE). 

In the attached plot, you can see the discrepancy in the top two charts (all full data). The top left is the DQ channel, which says the watchdog is 0 (??), while the top right is the EPICS channel, which says the watchdog is at 4 (fully tripped). The watchdog C code has no '0' state, so it's odd that this value would be recorded at all when the model is running.

We show that the model is running by showing the GPS time as recorded from the model in the bottom right. The value for the GPS time drops to 0 when the model is killed (1014668665) and comes back when the model is started again (1014668677). 

We also get full data from CPS H1 at the bottom left when the model is restarted. The data from 1014668665-677 in this channel is not 'real' - it is reflections of previous data at 1 second intervals. This can be casually observed by the apparent aliasing effect from 1014668655-70 in what look like dark diagonal stripes. We can see the CPS signal grow when the model starts.

Brian and I have plotted the beginning of the (bad) excitation in dataviewer in both the ISI and IOP models. We have also plotted the GPS time according to the ISI model (DCU_ID 75). As you can see, the GPS time drops out when the model is being off, but comes back up shortly thereafter. This data is for the 11:42 UTC restart when the excitation starts. 

We plot the same for the second restart, twenty minutes after which the fiber break occurs. We see the same thing - the model is shut down, then starts again. We see a similar drop in the GPS time to 0 before the model restarts. The excitations also stop when the model stops, and start again when the model restarts. We see a growth in the amplitude of the coil drive signal as well as the DAC signal from the IOP.

This is not inconsistent with a loop instability within the model.

Yesterday, we measured the resistances of the 12 actuators on ISI-BSC8. The table below shows the measured resistance when the ISI was:

- in the staging building

- on the teststand in the LVEA

- in the chamber (March 6, 2012)

Field cables in the LVEA are about 1 ohm. Resistances measured after the important drive are similar to those measured when the ISI was on the LVEA teststand. There are no obvious signs of damage on these actuators.

Betsy B. Travis S. Thomas V.

After reinstalling the swing back plate and support brackets, we swung the ACB back so that SUS can access the quad somewhat freely.

200W beam

35W beam

The plots in the document attached show calibrated motion and velocity of the ISI when it reaches the steady state regime that will last for hours and lead to the fiber braking.

Ed (Apollo), Michael R

Ducting for the exhaust air path was installed yesterday. Installation is not complete, as we are waiting on some parts, and I still need to caulk the penetration into the enclosure.

After swapping the picomotor cable, I and Dan Hoak proceeded to check the grounding. To our disappointment, the ISC table is grounded to three of the four cable shells.

We disconnected all four cables connecting the ISC table to the bracket on the ISI table, and tested the grounding of the ISC table to the on-ISC-table cable shells (there are four), and they're fine.

Somewhere downstream, shielding of one or more cables should be touching the metal part of the TMS or ISI, and of course the ISC table is electrically grounded to any of these structures. We need to check cable clamps and copper wires used for bundling the cables.

• Originally pin1, 6, 7 and 13 were all connected (in-vac side) on Mar 02.
• It was divided into two groups, 1-13 and 6-7 when I wiggled the cable on the cable bracket on ISI on Mar 02.
• Then somehow pin 6 and 7 were disconnected from each other when I disconnected and reconnected the cables on ISI on Mar 02.
• Through this process and other measurements, we identified that pin1-13 problem was in D1000223-S1104079, but could not identify the source of pin6-7.
• On Mar 06 morning, before the cable was swapped, we repeated the test. We've found that pin6 and 7 were again connected. Something apparently crept  back, though we don't know what.
• After swapping the cable, everything was fine on Mar 06.
• There's still some chance that pin6-7 will creep back to bad status (if the problem was not in the swapped cable). Pin 6 and 7 are used for red QPD picomotors, which are not used for one arm test.

Late entry from Monday morning.

We had a network disconnect from the LX vacuum controls system. This was tracked to a bad ethernet cable in the LVEA and it was replaced. The data gap was of the order of an hour. Only h0velx was affected.