Attached are plots of dust counts > .3 microns and > .5 microns in particles per cubic foot.
Dave Barker and I checked the status of HAM3-ISI's test points this morning. We noticed they were overloaded. Dave restarted H1-DAQ and they came back to normal. It seems like H1-DAQ was not restarted as it should have been after the model changes of last week.
Spectra measured on HAM3-ISI make sense again. I tried most combinations of ISO/blend filters on HAM3-ISI today. I attached a sum-up plot of HAM3-ISI isolation performance in the following configurations:
1- No control
2- Damping only
3- Damping + "old" blend* 250mHz + "old" ISO level 2
4- Damping + "newer" blend** 250mHz + "old" ISO level 2
5- Damping + "newer" blend** 250mHz + LLO HAM5 ISO level 2
ISO=Isolation filters
*: old blend filters - SVN revision 6036
**: newer blend filters - SVN revision 6187
Note, prior to this set of measurements, I:
1) yawed the right side of R0 CW in order to alleviate the rubbing that the guys saw (and reported) last Friday.
2) Then, I moved 100g of mass from the front to the back of the M0 UIM in an effort to correct some pitch that Jason observed. I then recentered the pitch adjuster bars bringing the pitch error down to the number cited above.
3) Lastly, I yawed the M0 CW to reduce the yaw error to what Jason reports above.
BOSEMs need to be centered and then damping will hopefully work.
Temporary air compressor intended to be used today needed to be fixed first
F. Clara, J. Kissel. T. Sadecki
We reconnected and reinstalled the BOSEMs to the TOP stages of what-is-now H1 SUS ITMY (but is still being run on H2 SUS ITMY electronics), gathered and installed new open light current values (as the resistance of the long temporary cables significantly reduced the voltage at the ADC, see table below), and aligned them by-eye laterally, and by and axially by speed dials.
After resurrecting the sensor diagonalization templates
${SusSVN}/sus/trunk/QUAD/H2/ITMY/SAGM0/Data/
20110803_ITMY_Diagonalize_1p3_Yaw.xml
20110803_ITMY_Diagonalize_2p2_Vert.xml
and finding that the isolation between expected and unexpected degrees of freedom was not-so-hot, we took a few averages of M0 P to P and V to V TFs using
${SusSVN}/sus/trunk/QUAD/H2/ITMY/SAGM0/Data/
2012-02-15_1802_H2SUSITMY_M0_Mono_V_WhiteNoise.xml
2012-02-01_H2SUSITMY_M0_Mono_P_WhiteNoise.xml
(which are sorely out of date) and found both to be crap (really noisy, low amplitude, little-to-no visible resonances). After a few tweaks here and there, we found that the bump stops on the reaction chain were rubbing against the main chain. What's worse, is that we saw the top bump stop rubbing first ("sweet! we'll just tweak up the pitch"), but then noticed the -Y bump stop was also rubbing ("that requires adjusting yaw, that's hard, let's go home instead").
So, indeed, we will leave further alleviation of rubbing for Monday.
Welcome back to QUADs everybody!
%%%%%%%%%%%%%%%%% Open Light Current Values %%%%%%%%%%%%%%%%%
BOSEM Production Test Stand % Drop
Name OLC [cts] OLC [cts] [%]
M0 F1 30805 29529 4.14
M0 F2 30164 28758 4.66
M0 F3 30160 28942 4.04
M0 LF 28050 26914 4.05
M0 RT 26205 25128 4.11
M0 SD 31046 29590 4.69
R0 F1 25530 24943 2.3
R0 F2 26272 25238 3.93
R0 F3 27538 26342 4.34
R0 LF 29513 27787 5.85
R0 RT 25210 24760 1.79
R0 SD 27113 26124 3.65
(Note, I gathered the previous OLC values from what was installed in the offset/gain fields; I couldn't find a report of them in the log [though I didn't try that hard]. For M0, I gathered to offsets and gains before I started entering in the new values, hence I trust their accuracy. For R0, I entered in the new offsets before remembering to get the old values, so I had to use the gains [which are entered in with less precision], so that's probably why the % drop varies by ~1% from 4%.)
-- Huh! A ~4% drop. Since V=IR, and nothing else has changed, I guess we know that there's therefore a 4% increase in resistance between the production sensor readout chain and the test stand. No show stopper, just good to know, and annoying to have to redo the normalization.
From approximately 9am until 3pm four vertical HEPI actuators were installed in the BSC2 pier housings. Four matching horizontal actuators were also installed on the Piers. This was with the use of a crane. Thanks to Ed and Mick.
Other than getting the wiring out of the way which wasn't too big a deal, and moving the CPS racks-now not so solidly attached, installation was pretty straight forward. The bolts tying the upper section of the handrails didn't lineup easily; these holes should be a little more oversized. A mod to lower the overall height a couple inches would make install safer for the ISI as well as working around the ISI--reduces contact of shoes and ISI. Additionally, a couple inches lower might allow big Jim to stand upright! Thanks Apollo-MarkD, Mark2 & Slim. Couple photos
At 8:03AM today, the IOP watchdog tripped, and I saw connection error messages in the alarm handler. I talked to JeffK and we cleared all alarms, and at 9:03AM, I got another round of alarms, but nothing tripped. At 10:03AM, I got connection alarms for the ITM. Now it's in a funny state for work, however, the alarm was exactly at 10:03AM, so suspicious. Alarms again at 1:03PM, 2:03PM, 3:03PM. Emailed DaveB and RichardM, and Operators (to give them a heads up).
Ran transfer functions and power spectra on H1-SR3. In general, the results look good. There are a couple of peaks in the undamped plots, which are suppressed in the damped plots.
I tested different configurations of blend and isolation filters. To do so, I looked at the GS13 input in cartesian basis in the following configurations:
The blend filters used are the generic ("old" version) blend filters from SVN revision 6036.
Spectra are attached. Damping + Blend 500mHz + ISO level 1 et Damping + Blend 500mHz + ISO level 2 are not displayed to keep the plot readable. They are however saved under DTT.
I used the command window to switch between states. The Watchdogs (ISI,SUS,IOP) did not trip. Damping + Blend 250mHz + ISO level 2 was on for a couple hours without any WD trip. I then tested other configurations.
Comments on performace:
Damping + Blend 250mHz + ISO level 2 is currently running on HAM3-ISI
I copy-pasted the LLO models for h1susauxh2 (h1iopsusauxh2 and h1susauxh2). Started both on the h1susauxh2 frontend. We found copy-paste error in the IOP model with ADC5 duplicated for ADC6 and ADC7. We fixed this but ADC7 still had problems, so we build this one from scratch and the IOP now looks good. A quick review of the model ADC usage shows there are errors with many ADC channels blank on the medm screen but the model should be using them. Someone from team SUS should check this out.
Andres R, Travis S, & Jeff B We moved the Beam Splitter under LVEA Test Stand #2 and mounted it to the BSC2 ISI.
We configured h2boot's Dolphin master to control the three new Dolphin nodes at EY. We used the next three node ids in the sequence
h2pemey = 20
h2susb6 = 24
h2seib6 = 28
We tested by transitioning the IOP watchdog IPC from RFM to Dolphin (h2iopsusb6 sender, h2iopseib6 receiver).
Jeff then transitioned all IPC at EY from RFM to Dolphin for h2sustmsy, h2susetmy, h2isietmy, h2hpietmy, h2iscey and we power cycled the EY computers and restarted all models.
We hand editied the H2.ipc to remove the old RFM channels such that the names could be reused as Dolphin channels.
The IOP watchdog was retested. Jeff tested all SUS,SEI IPC.
As of the above entry, I can confirm that the dolphin network communication between H2 ISI ETMY and its two SUS, H2 SUS ETMY and H2 SUS TMSY is functional, both on the sending (ISI GS13s to SUS, and SUS OFFLOAD to ISI) and receiving (of each) is functional. Further, the SUS PAYLOAD flag functionality from SUS to ISI is also functioning correctly. This completes the installation of all changes from T1200478 (though the afore mentioned to do list remains -- I've been working on H1 today) I've again left ETMY and TMSY peacefully damped.
After much prep work today, the MC1 suspension was swung into the chamber on the HAM install Arm around 3:45pm today and dogged down with a few dogs.
Unlocked testing done for the moment. I put Dial Indicators back on and relocked the system. I reversed the signage but still a good idea to not clamber on the Crossbeams or the Foot in the middle of the housing.
On Oct. 19, 2012 I measured a collection of waveforms and measured several DC voltages at the "Local Diagnostic" connector on a SUS OSEM Satellite Box adjacent to (W)HAM3. This was to provide in-the-field information on operating values and conditions to the CDS engineers designing the "Hardware Watchdog" circuits. The data represents a snapshot of nominal operating conditions. The results were collected into a set of slides and posted to the DCC under G120112-v1, "aLIGO OSEM Satellite Amplifier Representative Signals". No surprises here.
Re-enabled HV outputs -> Spoke with Agilent service tech and problem may be related to the "Protect" mode of operation. In this mode the HV will deselect if the pump current exceeds a programmable threshold (I had recently set all controllers to this mode). The threshold current value programmed is much higher than should be experienced at our nominal pressures and this is the suggested mode of operation however if the current is "glitchy" it can result in the nuisance shut downs experienced of late (none of the other ion pump controllers have tripped off) -> I am now running this unit not in protect mode to see if problem persists.
Gerardo and I worked out a nice little dish setup such that the primary and secondary prisms on one side of the optic barrel could soak in acetone for a while today. We used an SST dish lid and organic cotton rounds to sit the optic in a bath of acetone submerging both prisms. With an all glass pipette, we will add acetone as needed over the next few mornings. The evaporation rate in the setup is on the order of 10s of minutes, so needs far less babysitting than the setup needed when only removing one prism.
As of 3:30 (5+ hours into soaking) Gerardo reports that the prisms were still "solidly" stuck on the barrel. He's left it soaking over night, although we expect evaporation to dry them back out again within ~a few hours.