16:20UTC I added 350ml of water to the Xtal chiller. THe level alarm on the unit was sounding off.
Attached are the VPW desiccant plots with this month's added data. Nothing out of the ordinary shown since last months replacement of batteries in the sensors.
TITLE: 01/24 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
Wind: 4mph Gusts, 3mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.40 μm/s
QUICK SUMMARY:
16:00 6.2 EQ in Japan showing on BLRMS‌ (approx)4.5 hours ago
17:55 King Soft on site (someone else opened the gate. I was behind them)
J. Kissel, M. Pirello FRS Ticket 9771 (EDITED -- we confused ourselves: it's the US SatAmp that isn't reading out ZM2 correctly, not SUS-SQ-21 cable as originally suspected) After identifying and fixed that ZM2's HAM-A driver has not been properly jumpered (see LHO aLOG 40218), we still are chasing down why we see so little ADC voltage from the OSEM sensors, and why the OSEM spectrum looks so poor in performance. After playing the "swap the cable connections with a known working chain at every connection of the whole chain" game, we traced the problem down tothe cable between the SatAmp and Chamber feedthrough; SUS-SQ-21the US SatAmp reading out the ZM2 OSEM chain (see wiring diagram here D1700384).The nail on the coffin is attached: we read out ZM2 from the chamber feedthrough with the OFI's ex-vacuo cabling (its equivalent "last cable on the way to the chamber" is SUS-SQ-30) and electronics -- and vice versa -- we see full, normal levels of ~15000 [ADC ct] of DC OSEM sensor voltage on the three OSEMs that the OFI digital system can read out, and we see low, junky DC OSEM sensor voltages on the three OFI OSEMs.Throw thatcableSatAmp in the trash, I say!
The ASCII art version of the two SUS's wiring diagram:
--------+ +----+ +----+ +----+ +-----+
ZM2 | SUS-SQ-21 | | SUS-SQ-23 | | SUS-SQ-28 | | SUS-SQ-10 | |
in |-----------| |-----------| CD |-----------| AI |-------------| DAC |
Chamber | | | |____| |____| |_____|
| (A) (B) | | (C) (E) (F) (G) (I) (K)
________| | SA |
| |
| | SUS-SQ-25 +----+ SUS-HAM5-89 +-----+
| |----------------------------| AA |-------------| ADC |
|____| |____| |_____|
(D) (H) (J) (L)
--------+ +----+ +----+ +----+ +-----+
OFI | SUS-SQ-30 | | SUS-SQ-31 | | SUS-SQ-33 | | SUS-SQ-35 | |
in |-----------| |-----------| CD |-----------| AI |-------------| DAC |
Chamber | | | |____| |____| |_____|
| (A) (B) | | (C) (E) (F) (G) (I) (K)
________| | SA |
| | SUS-SQ-32 +----+ SUS-SQ-11 +-----+
| |----------------------------| AA |-------------| ADC |
|____| |____| |_____|
(D) (H) (J) (L)
Description of tests:
(0) Starting conditions: wiring as drawn above.
OFI read is read out well (~15k cts at ADC), ZM2 is read out poorly (~1k cts at ADC).
(1) Swap ZM2 21 (A) with OFI 30 (A) (at the chamber).
Result: OFI signal chain (starting with OFI 30 (A)) is reading out ZM2, and does so well. ZM2 signal chain is reading out OFI (starting with ZM2 21 (A)), and does so poorly.
Conclusion: Something is bad with something in ZM2 signal chain. ZM2 in chamber is OK.
(2) Go to starting conditions, but swap ZM2 21 (B) with OFI 30 (B) (at the back of the SatAmp).
Result: OFI is readout poorly by ZM2 signal chain, ZM2 is readout well by OFI signal chain.
Conclusion: Begin to rule out something is bad with SUS-SQ-21, and suspect SatAmp or upstream.
(3) Go to starting conditions, but replace ZM2 SUS-SQ-21 entirely with a temporary cable.
Result: ZM2 signal chain still reads out ZM2 poorly.
Conclusion: Something is bad upstream of SUS-SQ-21, or temporary cable is bad.
(4) Go to starting conditions, but replace OFI SUS-SQ-30 entirely with same temporary cable
Result: OFI signal chain reads out OFI well.
Conclusion: Temporary cable is good. Must be Something is bad upstream of SUS-SQ-21.
(5) Go to starting conditions, but swap ZM2 25 (D) with OFI 32 (D) (at the front of the SatAmp).
Result: ZM2 25 (D) and upstream reads out OFI SatAmp and downstream well.
Conclusion: ZM2 Signal chain from SUS-SQ-25 connection at SatAmp works well, must be that SatAmp is busted.
Grand Conclusion -- SatAmp is busted.
*phew*
#SlowAndSteadyWinsTheRace
After an additional test of swapping the ZM2 and OFI signals through another nearby, vacant chassis -- that for the VOPO H1H2H3V3 OSEMs (i.e. 21 (B) and 30 (B) into the back of the VOPO chassis, and 25 (D) and 32 (D) to the front of the new VOPO chassis), which resulted in *both* signal chains reading out poorly, Marc pulled the chassis to look inside -- suspicious of a similar jumper problem discovered recently with the ZM2 HAM-A coil driver chassis (see LHO aLOG 40218) He discovered that none of these new SatAmps had jumpers in place over the JP1 "AOSEM vs. BOSEM" connector (see first page of "AdL 4 Channel Satellite Amplifier" D080276). Sheesh! Of course, only as I write this aLOG to I realize that I told Marc that he should jumper the JP1 connector in the AOSEM configuration, but HTTSs use BOSEMs. Doh!@ I've taken transfer functions and an amplitude spectral density of the OSEMs. All look strikingly normal now. Wahoo! I wonder... the OM1 reference looks pretty much dead on with the new "fixed" ZM2 TFs. Are all the US sat-amps reading out BOSEMs jumpered to AOSEM? I confess I don't know the difference between the response of the two, and clearly a BOSEM works well jumpered to the AOSEM position (i.e. ZM2). I'll talk with Marc tomorrow and test ZM2 with the SatAmp jumpered to the BOSEM configuration to see what happens.
Jenne, Thomas, Sheila
The message is that we don't think that we need to move the OMC to have OK clearances in HAM6.
This is in preparation for tomorow's GV11 annulus vent activity
A. Bell, J. Oberling, T. Sadecki, D. Sellers
Today we successfully welded the first two fibers into the new ETMy monolithic. Some tooling readjustment was necessary as we switched sides of the suspension (not unusual, just a bit larger in magnitude than we usually see) which caused us to waste a fiber. Another fiber broke poorly as we were scribing off the fuse ends and was thus scrapped. These 2 fibers constituted one 'set' for a particular corner of the suspension, and due to the new violin mode grouping scheme, caused us to have to scramble back to the pulling lab to collect of new corner 'set'.
For future reference, the time consumption of the new VM grouping scheme is rather high. Since the fibers are matched, we can no longer simply pick another fiber that meets the looser requirements for fiber profile, but must recalculate the pitch contribution of another 'set' of fibers with respect to the already installed fibers and hope that we have fibers in the cabinet that meet our needs. From the fiber pulling side, Karl Toland from Glasgow has been here for 3 weeks pulling and profiling fibers for the remaining 3 ETM replacement (1 more at LHO and both at LLO) and is still working toward that end (i.e. he is not done yet).
As I understand it, the temperature sensors for the LVEA were moved away from the walls so the HVAC system would be less influenced by the OAT (outside air temperature) wagging the buildings interior temperatures around. Such as the detector chambers getting warmer as the HVAC stepped it up to deal with declining OATs. This is most clearly evidenced at the quad suspension with sagging due to warming blade springs. These temperature swings impact not only SUS V but the SEI BRS and potentially ASC.
This temperature sensor move from the walls to interior locations has not been done at the end stations.
The first attached plot shows twenty days of the ETMX M0 Vertical and the EndX OAT. The M0_V has been shifted -20000 seconds where it shows a nice correlation with the daily temperature cycles as well as the longer term trend.
The corner station OAT sensor is not reading reasonable numbers at the moment and it looks like it has been that way for a few months (FRS 9765.) Maybe it is reasonable to use the End Station OAT for comparison but instead, on the second attachment is the EndX and the ITMs M0_Vs. I've shifted them onto the Y area to allow more zoom. Clearly EndX has much larger daily and longer term response to the OAT, maybe about a factor of two.
The temperature sensors were NOT moved away from the walls. What we did do is install an additional 6 temperature sensors at the chambers and these are used in a combination with the existing wall sensors to control the temperatures in the LVEA.
All the models on h1iscey were in error and not writing any good DAQ data. To restore the PEM data, I restarted all of h1iscey's models (h1pemey, h1alsey, h1iscey and h1caley).
at 11:14 PST I restarted the DAQ for three changes:
new h0vaclx INI file following Patrick's changes (addition of Y5_PT191, Y6_PT192 and Y7_PT193)
new h1ecatc1plc[2,4] INI files following Daniel's Squeezer changes
new H1EDCU_HWS.ini file with the two non-running channels from h1hwsex removed (H1:TCS-ETMX_HWS_HEARTBEAT and H1:TCS-ETMX_HWS_SOFTWARE_ERROR_CODE)
EDCU is now GREEN.
I ran my new EDCU channel verification script (h1dc0_edcu_channel_verification) to confirm all the new EPICS channels existed before I restarted the DAQ.
Updated per WP 7307. No issues. Dave is working on adding the channels to the DAQ.
Set new gauges to read in Torr. Burtrestored to 6:00 am local time.
Powercycled in an attempt to remedy bogus outside temperature reading. No effect. IOC restarted.
Checked on the RF connections to/from the EOM. I could not get an SMA torque wrench around the middle (ie the 24.1 MHz)
connector because there was insufficient space. The two outer connectors (9.1 and 45.5 MHz) and the two cable connectors
(24.1 and 45.5 MHz) checked out okay. The other end of the cables is an N connector.
One difference between the cables is that the 9.1 MHz cable has no 90 degree SMA elbow connecting it to the EOM body.
While heading into the PSL to measure the power going into the IMC, I did my usual check of beams on the IO path, and discovered a string of IR light on the first lens after the EOM. I routinely look at the IO path with a viewer, and have not see this string of IR light before. I noticed that Peter had torqued the connectors on the EOM, so am attaching this to his alog. I see evidence that the beam path to the EOM input steering mirror has shifted, but my history with the EOM mount is that it is not well secured, and the amount of clipping would be consistent with a shift in the EOM position.
IR camera images of EOM - horizontal string of IR light is seen on the first lens after the EOM, should not be there.
Beam on EOM input steering mirror has moved enough that a beam that should go through is clipped on the left side of the steering mirror.
Beams in ALS path are clipped on the input to the ALS faraday, and a mirror mount downstream of the faraday has a large area IR beam that's visible on the mount, and may be the source of the beam on ISS box that is new.
What I see:
What I recommend:
Added 200 ml to the crystal chiller. Added 150 ml to the diode chiller. Power watchdogs for the oscillator and front end laser were reset.
J. Kissel, M. Pirello After SUS'ing out the OMs and the OFI, and while still trouble shooting ZM2, I wanted to post redlines to D1002876-v4 which hasn't been updated to include new squeezer suspensions. Granted, we still haven't confirmed ZM2's functionality (see LHO aLOG 40207).
Betsy reminds me that systems is more likely to update the in-vacuum cable harness routing documents than the flange layout documents. For HAM5, that's D1101917, v4 of which is indeed up-to-date and includes ZM2 (marked as SQZ-TIP/TILT) and the OFI. Thanks for the reminder, Dubs!