Attached are plots of dust counts > .5 microns. Very high levels of dust in the LVEA (H0:PEM-LVEA_DST11_5). High levels of dust in the optics lab (H0:PEM-LAB_DST1_5). Some dust in the clean room over BSC8 (H0:PEM-LVEA_DST15_5).
EricA CoreyG HughR On Wednesday we started this process of connecting the Actuators to the Crossbeam (Foot). We completed this yesterday long with 130lbs on extra weight on the West Crossbeam to mimic the ACB. We then released the HEPI suspension and then made adjustments to the big HEPI Springs to bring the dial indicators back to pre-disturbed position. We got pretty close to this but there remains some differences. I'm confident we remain in tolerance for the translational position but the Yaw may need tweaking. Today we made gap checks of the HEPI Actuator actuator-plate/bellows shield. This is our motion limit and we need to insure it remains centered. We've made some adjustments of the Actuator positions to improve this centering. We still need to do a couple more. We also ended the day yesterday with a stuck L4-C (Horizontal NW(Pier2)) but Eric pulled that out and gingerly freed it. It has been reinstalled.
Table legs were set into place and leveled. On Monday the table legs will be grouted into place.
H2 SUS FMY's damping loops are no longer stable with the settings I'd confirmed working yesterday. HOWEVER, they are stable if the signs of all the loops are changed (i.e. change H2:SUS-FMY_M!_DAMP gains from negative to positive). I had logged in this morning (~10a ET, 7a PT) to take some transfer functions on ITMY, noticed in passing that H2 SUS FMY's watchdog had tripped and thought "no big deal," something must have glitch and tripped it over night, and left it be. When I had finished ITMY's measurements, I went back to clean up my work and re-damp everything so that seismic could get to work, and noticed (1) FMY's Master switch was off (was on when I glanced at it) (2) FMY's COILOUTF filter's outputs were off I, by-hand, turned the switches back on, and blindly turned on the the damping loops. The slowly but surely became unstable within a few seconds. Totally confused, I flailed about for a bit looking for sign errors etc. Regrettably I didn't BURT capture FMY after yesterday's confirmation that the damping loops were running yesterday. So, I've BURT restored to the snapshot where the loops were confirmed stable last, in ${RTCDSROOT}/userapps/release/sus/h2/burtfiles/fmy/fmy_dampfilter_111004.snap as per Jeff G.'s aLOG 1506. All loop signs are the same as what I expected (and as I had them set to yesterday) -- the only tweak I needed to do was to select the correct filters in the COILOUTF banks, because Jeff G's snapshot was taken before the filter bank upgrade, mentioned here. After this they're still unstable! In trying to figure out what the heck is wrong, I flipped the sign on the DAMP Filter gains from - to +, and they're stable (?!?!). Still investigating ... Richard has to make some changes to the DC powr supplies at 11a PT, so for now I've turned off all digital control to both ITMY and FMY. I'm looking for something electronic (chassis, ADCs, computers, networks, etc.) or digital (MEDM setting, model changes, CDS software changes) that might cause the sign of the actuation to flip -- and only on FMY. It's VERY strange. Perhaps the timing glitch, and Dave's subsequent reboot of everything and BURT restore, mentioned in passing here, changed something digital upstream of the FMY signal chain (like the IOP)? Sounds unlikely, but possible ...
Upgrade of control room and MSR update. Floor tiles were removed, under floor cables are being removed. Timing system in the MSR was glitched, requiring all front ends plus their IO Chassis to be power cycled. All systems were burt restored to 15:00 local time.
Attached are plots of dust counts > .5 microns. The dust monitor in the clean room over BSC8 had a low battery alarm when I came in today, and I restarted it. The system was down intermittently while the servers were moved from the MSR to the electronics building.
Final work on linoleum was completed today. All seams were welded, and grout dams were caulked into place. Table legs were also moved over to the South bay.
(Corey, Hugo, Jim, Mitch)
Assy #3
For all intents and purposes, this Assembly is ready to be pulled off the Test Stand.
Assy #1
T. Sadecki, J. Kissel Travis / Hugh can give more details of the problems had during cabling up the H2SUSFMY, but once we got all BOSEMs turned on, and the OSEMINF filters were fixed, it was trivial to close the damping loops on FMY (as it should be!). All damping loops (ITMY M0, ITMY R0, and FMY M1) are closed and running. Watchdog levels: OSEM DC -- +/- 30000 OSEM AC RMS -- 8000 ACT AC RMS -- 25000 Typical watched levels with damping loops closed (and no one mucking around the chamber) OSEM DC -- ~15000 OSEM AC RMS -- < 150 ACT AC RMS -- < 1000
Crystal chiller flow increased from 14.5 lpm to 15.2 lpm
Diode chiller flow increased from 24 lpm to 28 lpm
Diode chiller pressure at valve underneath table increased from 4.3 bar to 5 bar
J. Batch, J. Kissel After failed attempts to run diagonalization measurements of the newest QUAD built using DTT (DTT opens, sends excitation out to the suspension as seen on MEDM, runs for the allotted time and stops, but no data is plotted and DTT reports an error message say "Test time out."), Jim found that the framebuilder / daqd process had "somehow lost 30 seconds ... possibly because we unplugged a cable temporarily." I think he's referring to timing cables that may have been plugged/unplugged during the Mass Storage Room gutting. He has rebooted the frontend, and I have burt restored using the ${RTCDSROOT}/userapps/release/sus/x1/burtfiles/x1susquad_safe.snap restore file. I'm retaking the diag. measurements now, and all is functioning properly.
While on the phone, but still watching the MEDM screens of SUS's in BSC8, I saw the values coming in off the front end freeze. After some investigation, I found that the IOPs for both front ends that control H2SUSITMY and H2SUSFMY had lost their IRIG-B timing -- H2:FEC-28_IRIGB_TIME, H2:FEC-28_IRIGB_TIME were some large red number (normally green and around ~15 us). This also seems to have caused all the running models on those front ends to have a red 0x4000 status with regards to the framebuilder / daqd. I'm not sure why all this happened, but I've restarted the processes on both front ends and all seems fine...
Work continues on the aLIGO upgrade of the LHO control room and MSR. The iLIGO computing systems have largely been removed, we are now de-cabling both rooms.
EricA CoreyG HughR Re--WorkPermit 3029 We got 3 vertical and 1 horizontal Actuators connected so 1/2 way there. We didn't get started on the actual attachment til 1pm so I think we should be able to wrap it up in the morning. We'll still need to adjust the Springs after all connected but again, maybe we'll be wrapped up early afternoon. As usual, please be mindful of the dial indicators if you are in their neighborhoods.
D. Cook, J. Oberling
We placed 3 new monuments west of BSC06 at End Y today for use in the in-chamber alignment of the H2 ETMy. These are labeled IAM-25, IAM-26, and IAM-27 and their coordinates are as follows (units of mm):
After powering up the FMy satellite boxes and checking that the EE on the outside of the chamber were functioning properly (thanks, Richard), I went in the chamber to look at the in-vacu stuff. Indeed, the cable that needed an end-to-end swap before the holiday break, had not finished making it to it's connecting octopus cable. When I tried to seat it, I found that the 225 cable needed helicoils, preventing good connection. We're hunting tools now to finish helicoiling these (all 3 225 cables need the helicoils) connectors.
Today I finished helicoiling and connecting the FMy cabling at the optical table. While this eliminated a possible source of problems, it turned out the real problem was a bent pin on the air side of the feedthrough. After straightening the bent pin, the cable was reconnected and successfully tested for functionality.
Though there was a bent pin on the Vac. flange I believe this was a result of troubleshooting and not the initial cause. Per my directions this cable was removed and changed and replugged in a number of times in trying to narrow down the problem.