TITLE: 11/13 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: 10mph Gusts, 8mph 5min avg
Primary useism: 0.04 μm/s
Secondary useism: 0.55 μm/s
QUICK SUMMARY: Vent work continues
Looking into PSL temperatures, I started looking at the AC temperatures, and what I see is that the signals for TBLS and ACS appear to be switched. Attachment shows from left to right:
Late alog for last Fri:
After moving the AUX IFO simulator beam to the ITMx-PR3 targets installed late Thur, we connected the ITMX Elliptical baffle box to it's down tube suspension structure. Immediately we discovered that the box looked visibly crooked and out of alignment. Recall that Robert has data supporting that this (and maybe the ITMY baffle) are misaligned and causing coupling into DARM, see his alog 39290.
We spent a few hours looking into the surveying history of this baffle and came up with somewhat unfinished IAS and alog records of final alignment of this baffle back in 2013. As well, these records indicate that alignment of the baffles was only performed using the center target, which seems insufficient to align the baffle. SO, maybe it's no wonder there has been coupling here.
Monday, we'll continue work to align baffles and more, likely with some consult with SYS...
(Betsy, Gerardo)
This morning Betsy and I removed the OFI Table from HAM5, cage, suspension assembly and damping assembly remain inside HAM5.
The table was transported to the optics lab for testing.
In order to keep the suspensions damped as much as possible, I've loaded a changed suspension guardian similar to what is described in 39327
This will not impact the way users interact with the suspension guardians. Previously, the suspensions guardians would turn off all damping whenever any stage tripped, the new code does not do this and relies on the watchdogs to turn off any stages which have unreasonable drives. When the user untrips the watchdog everything will be turned off so that it can be turned back on using the usual guardian procedure.
The code that we are running here at LHO is actually userapps/sus/h1/guardian/SUS2.py It is in the svn as revision 16426. Tripped is still a protected state, which was necessary to keep the suspension from going to the RESET goto state. Attached is a diff between what I've just loaded and the previous version.
[Arnab, Chandra, Kyle, Rakesh]
We spent a good part of today setting up for and diagnosing an unidentified known leak (e-7 Torr-L/s range) between GV 5 & 6, where cryopump #1 (CP1) and spool are (corner station, y-arm side). First we checked for inner o-ring leaks by connecting aux turbo cart to GV annuli and pumping and pressurizing (to about 1 Torr) with bottled dry N2 using a control needle valve. Then we soft closed GV6 (with GV5 hard closed) and shortly after valved in the newly installed 55 l/s ion pump (IP) connected to bottom of CP1. Then we walked over to the 10" CETEC GV on CP1 spool to start removing the ISO flange to connect 500 l/s turbo for He leak checking. Kyle checked the CETEC valve to verify it was closed and was able to tighten by a good half turn. We see two pressure bumps that correlate with these activities. We think we fixed the leak by tightening that CETEC valve (and suspect the ISO side is up to air), but won't know for sure until we open GV6 and trend the adjacent gauge (PT-124b), which rises when exposed to CP1 volume (because of leak) and falls when GV6 is closed.
After the pressure at CP1 (PT-114b) started to plateau just above 1e-8 Torr, we valved out the 55 l/s IP for about 10 minutes (without compressing Cu gasket on right angle valve) and valved back in to check response. We are leaving it in this configuration over the weekend - with GV6 soft closed and 55 l/s IP valved in. Dave Barker set a text alert for PT-114b to alarm for pressures above 2e-7 Torr in case the IP turns off.
Note that this volume has been He leak checked in the past by John & Kyle and remained inconclusive after spraying He and seeing no signal on leak checker.
The TCS CO2 Y table is approximately in its new location. Unfortunately, this new location is partially off the technical slab, one leg is mostly off as seen in the first photo. While lowering the table off of the wheels one bolt sheared off, so I removed the wheel for now and moving will have to be done with a pallet jack. The new baffle hardware has also been installed with a temporary plate. The panel has a hole too large for the new hardware and this plate will be used until a new panel comes in. The next step is to install the new BSC viewport pieces and lightpipe.
I extracted the failed fiber-channel fiber FMM-10M-0018 and routed the replacement FMM-10M-0014 through the fiber tubes and cable trays. While the fiber was being replaced, the redundant routing of E18-1 to LDAS via the two Q-Logic switches resulted in no loss of connection. I also rerouted two management ethernet cables from the surplussed SATABOY to the primary controller card on both E18 RAIDS, we will activate these next week.
WP7215 Chandra, Kyle, Dave:
As per request from the vacuum group, I have added the PT114B Cold Cathode vacuum gauge (and its associated ERROR channel) to the alarm system. It is configured to alarm if its value goes above 2.0e-07 Torr (it is currently at 1.3e-08 Torr and trending downwards). Alarms will be sent to the vacuum group and myself.
Issues with Commissioning mode and issues with Science mode led me to try a new mode, which is Commissioning mode with Makup Air turned down from 100%.
Leaving it set at 40% - JeffK is watching.
History of TBLN since alignment on Oct. 31st is shown in the attached plot.
J. Kissel Now that MC2 has been fixed (LHO aLOG 39382), other than PR3 (LHO aLOG 39383), all intentionally freely suspended HAM2 / HAM3 suspensions are free of rubbing at the moment: MC1, MC2, MC3, IM1, IM2, IM3, IM4, PRM, PR3. Note, PR2 still has its protective lens cap on, and likely EQ stopped so I didn't both measuring it. Data can be found commited with the 2017-11-10 date stamp in the appropriate folder of the SusSVN. /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC?/SAGM1/Data/*.xml /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM1/Data/*.xml /ligo/svncommon/SusSVN/sus/trunk/HLTS/H1/PR3/SAGM1/Data/*.xml /ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM?/SAGM1/Data/*.xml
J. Kissel The only other suspension in HAM2 / HAM3 that is rubbing is PR3. As with MC2, it doesn't look too serious, because the Qs are all nice and high. Probably another grazing EQ stop or two. Black 2017-07-25_1507 pre-vent clean reference Red 2017-11-10_2044 current rubbing state Betsy has been made aware, and will address when convenient.
Problem fixed -- it was the Front HR Upper Right stop grounded on the face of the optic. See LHO aLOG 39416.
J. Kissel, B. Weaver While we waited for the PSL to figure out at what temperature it would like to be (see LHO aLOG 39371), I took top-to-top mass transfer functions of all the HAM2 / HAM3 suspensions. In doing so, I discovered that MC2 was rubbing. As such, Betsy -- while out on the floor for other reasons -- dipped in to HAM3 and found that a few of the barrel stops were grazing the optic. She backed them off, and I re-ran TFs that indeed confirmed this was the source of the rubbing. I attach screenshots of the 6 DOFs of TFs. Black 2017-08-01_1733 -- pre-vent clean reference data Blue 2017-11-10_1722 while MC2 was rubbing Red 2017-11-10_1829 after Betsy releaved the EQ stop rubbing Repeat: MC2 is now free of rubbing.
For future reference -- on the barrel stops that were rubbing the optic: two of the eight were rubbing, on opposite corners (low on one side, high on the other), but it was too dark in chamber to tell to precisely identify which ones.
Posted below are the particle count mean trends for the past 30 days. For the most part the counts are good. There are a few high counts (over 1000) spikes in HAM4 and HAM5. The HAM4 spikes are connected with the door removal. Cannot correlate the HAM5 spikes to a single event, however there was much activity around around HAM5 around this time.
I could find no aLOG entries between 10-11 and 10-15 to explain the spike at BSC3 (DM #30). Cleaning around the chambers sometimes stirs up dust, which may explain these counts. That they quickly declined to normal levels indicates these events were a one time occurrence.
Gerardo stated that the Optical Table was not very level using a small T-Level and that the OFI needed adjustment to hang properly after doing all the adjustments on an optical table bench.
So I used the Optical Auto Level to look at the table. With seven shots, above the walls at every corner and in the center of the table, the range of level was +-0.1mm--very level in our books. I did manage to tie it into our LVEA monuments to put an actual elevation on the table: -325.8mm Lz. Adding the -0.3mm conversion from local the global gives -325.8mm Gz (See T1100187.) Looking at D0901129, it shows the Optical table to be 325mm below the BEAM TUBE CL. I can't tell or remember if this is below the HAM5 BT CL or below the BSC2 BT CL where global 0 0 0 is positioned. Either way, we are within 0.5 to 0.8mm of ideal elevation for this Optical Table and again very level. Frankly, I'm relieved! Attached are my field notes.
I've got a couple typo above:
Gerardo stated that the Optical Table was not very level using a small T-Level and that the OFI needed adjustment to hang properly after doing all the adjustments on an optical table bench.
So I used the Optical Auto Level to look at the table. With seven shots, above the walls at every corner and in the center of the table, the range of level was +-0.1mm--very level in our books. I did manage to tie it into our LVEA monuments to put an actual elevation on the table: -325.8 325.5mm[see notes] Lz. Adding the -0.3mm conversion from local the to global gives -325.8mm Gz (See T1100187.) Looking at D0901129, it shows the Optical table to be 325mm below the BEAM TUBE CL. I can't tell or remember if this is below the HAM5 BT CL or below the BSC2 BT CL where global 0 0 0 is positioned. Either way, we are within 0.5 to 0.8mm of ideal elevation for this Optical Table and again very level. Frankly, I'm relieved! Attached are my field notes.
I started to look at times when the fast shutter fired to check if there are times when more energy passed the shutter than desired (in part because of the broken beam dump in HAM6). I wrote a script that looked at about 40 days of minute trend of the AS WFS (which are behind the shutter) and picked out times when they were high. Attached are plots of the three events where the most energy seems to be getting past the shutter in those 40 days. In all of these three cases, the power on the AS_C PD doesn't seem to have exceeded the threshold for the shutter to fire until there had already been several seconds of large power fluctuations at the AS port. The shutter triggers as expected when the power goes over the threshold.
This afternoon Gerard and Koji helped me confirm that the fast shutter is cabled correctly by shining a flashlight on AS_A, AS_B, and AS_C. Indeed AS_C is connected to the fast shutter trigger.
Fil also helped me interpret the PCB layout for the transimpedance amp, I peaked inside the one for AS_C and confirmed that when looking from the front of the chassis (side where the LED is on the board) the red jumpers are on the left side, between pins 1 and 2, which means that the whitening is used. This means that the whitening is correctly compensated in the front end calibration of AS_C.
After talking with Daniel, my confusion was caused by the AS_C readback saturating in the whitening stage of the transimpendance amp. Since the sum output bypasses this whitening stage, it does not saturate and the signal readback by the beckhoff (Trigger Volts) reflects the realistic power on the PD.
So it looks like it is not really feasible to check how much energy is getting past the fast shutter using one of our HAM6 PDs. The AS WFS saturate the ADC during the lockloss transient, so they aren't very useful, and AS_C saturates the whitening stage.
Sheila, Jonathan, Dave:
Sheila had a question about the relative timing of an analog event which was recorded by both a front end computer and a Beckhoff slow controls computer. When looking at the two channels from the DAQ, there was a time difference of about a tenth of a second.
As a test, I have some slow signals coming from front end models and being a acquired by the DAQ through two paths: one direct alongside the fast data, and an equivalent channel coming in via the EDCU. To show the delay, I looked at the h1ioplsc0 model's state word, and manually changed it by running an excitation to set the EXC bit. In the attached plot, the signal being sent directly to the DAQ data-concentration is the upper red plot, the signal being acquired over the network via the EDCU is the lower purple plot. As can be seen, the front end data is packetized into a 1/16th block before sending to DC, which in turn packetizes the data into a 1/16 block and adds the Beckhoff data point. This results in an apparent 2 sample delay (0.125S) in the red plot. In actuality, the red plot is timed correctly, and the Beckhoff event is incorrectly time stamped as preceding the event by 0.1 S.
We think moving the EDCU to a front end would resolve this.
The use of a front-end based EDCU (instead of the DAQ Data Concentrator) is already implemented in the CDS code base. It has already been tested extensively on test stand and, and briefly on L1. There are installation instructions in the DCC. This change is required to ensure EPICS data agreement when multiple Data Concentrators are used to increase redundancy.
Subsequent inquiries concerning my alog has made me realize my entry could be made more clear. The issue is that slow data coming directly from the front end computer to the DAQ data concentrator has a pipe-line delay, whereas data being acquired by the EDCU does not. When looking at the two signals in real time mode, the EDCU signal changes first, followed 3 cycles later (0.18S) by the FEC channel. The data-concentrator takes the pipe-line delay into account by timing the signal from the FEC's time stamp (not the EPICS IOC), meaning that when this event is later replayed by opening frame files, the FEC signal has the correct time, and the EDCU signal erroneously appears to have happened before the event time.
J. Kissel Since HAM4's construction / installation stuff for this vent is complete as of yesterday's HWS Scraper Baffle install (LHO aLOG 39266), and the debugging of SR2's M2 OSEM today (LHO aLOG 39277), I took the afternoon to start B&K hammering all of the new / old baffle equipment and HWS mirror / lens mounts. Note, I deliberately skipped the SR2 cage, since nothing has changed on it since it was originally measured in LHO aLOG 12089, and I trust that Betsy and Travis successfully re-dogged and torqued bolts when they finished the relocation a few days ago LHO aLOG 39240. Will post pictures and results next week.
I'm attaching some plots of Jeff's data. Would be nice if the B&K data were easier to get into a publishable form, I can't guarantee I haven't screwed something up in here, a lot of places where it would be easy to make a mistake. Some of the TFs have almost no coherence, Jeff said it was hard to get the accelerometer close in couple cases.
One extended point about getting data from the B&K machine. It's possible to export one data set at a time (i.e. get the tf & coherence for one channel). Then to get them in a manageable format for matlab, I used sed to remove the last seven lines and the first 84 lines from the exported data txt file. This was some thing of the form:
sed -i '6486,6492d' *100-1100*.txt
to remove the last seven lines of all of Jeff's data files that had 100-1100 in the name (for the frequency band) and:
sed -i '1,84d' *.txt
to remove the first 84 lines from all of the files in the directory. Best to backup your data before doing this, cause sed won't ask if you're sure. I had to try several times to get it right. The '1,84d' tells sed to delete lines 1-84. There's probably some clever way to tell sed to remove the last seven lines, I couldn't find it, so I just looked in the file to see how many lines there were.
Attached are pictures of each setup for the above B&K hammering, in case they need to be reproduced. Jim has volunteered to process the data.
