Just in case the laser trips, would the person bringing the laser back up please make a note of the status of the laser and whether or not the chillers are running. On the PSL Beckhoff computer, hit the "Stat>" button located towards the bottom right of the main screen (the one with the schematic of the laser drawn). The next screen is the System status screen. Make a note of whether just the "Interlock OK" field, located near the top left hand corner, is red. Or if all the fields on the left hand side is red. Also please make a note of whether or not the chillers are running.
Without going into the full soap opera, the PSL chiller was replaced with the "original" chiller. This chiller was upgraded with the new vortex flow sensors. A new calibration factor for the flow sensor was entered into the chiller's memory bank and the bypass valve was manipulated to give the right flow rate through the HPO laser heads and front end laser. A log about the interlock will be submitted later once I've sorted out the messy details. JeffB, Peter, Jason
Peter, Kiwamu, Evan
In the process of trying to realign the IMC, we found that the LF OSEM on the top stage of MC3 is seemingly nonresponsive. Additionally, the left-hand OSEMs on the M2 and M3 stages have very few counts coming from their shadow sensors.
For M1 LF, the input readback is railed low, and does not respond even when the MC3 alignment slider is "moved" many hundreds of microradians in yaw. RT, in contrast, shows a clear response. The voltage and current readbacks for LF are similarly nonresponsive. It seems that they acquired their present values around yesterday at 11:20 AM local time.
Peter and I looked at the HAM2 driver chassis, but did not see anything immediately wrong. Then we went to the satellite boxes. Peter found that one of the cables for the MC3 top stage was not screwed in and was hanging slightly. Fixing this did not change the behavior of LF, however.
It seems that this problem can be traced back to the ADC/DAC chassis which drives the LF OSEM. It is putting out -25 V all the time.
By physically disconnecting the DAC drive to the T3, LF, RT, and SD on MC3 (thereby removing the -25 V being sent to LF), Kiwamu and I were able to see that the OSEM shadow sensors all gave reasonable numbers of counts (several thousands at least), including LF and the middle/bottom stage OSEMs.
We restarted the MC3 model, but this did not fix the issue.
As a background task over the past few weeks I've been working on a Matlab script that will provide the capability to test all suspension actuator channels. The aim would be to have it available to run on a weekly/bi-weekly basis, during a maintenance window by Detector Engineers or Operators, so that we can be more pro-active in our search for OSEM channels that may have become unresponsive. The test itself is very straightforward (just applying a ramping positive/negative bias to the OSEM and monitoring the sensors response), but the logistics of running it on so many channels and maintaining a measurement list, are somewhat more of a challenge. This script is currently being tested at LLO, and after completing my survey of actuators at LLO I aim to release it for LHO ASAP.
The Y end station had a Guralp seismometer set up with some clearly temporary electronics: cables strung on the floor and in front of racks; power supply and breakout boxes on the floor. With the work going on in the Y-end VEA to install the new ES-Driver, this set up was getting in the way, and posing a tripping hazard. As the work permit run-through in the morning meeting revealed no permit for this setup, I took the liberty of disconnecting the cables and cleaning things up. The Guralp itself was not moved, but signals are no longer being acquired (if indeed they were before).
(R. Weiss, B. Abbott, C. Torrie, J. Worden, B. Gateley, G. Moreno)
We assembled one TMDS*, and is currently being tested in the corner station mechanical room.
We are using dry air from the corner station purge air system to test the unit.
The corner station purge air will remain on until testing is complete.
*TMDS = Test Mass Discharging System.
you're gonna need a bigger c-clamp
Not possible to use a bigger clamp - there is no crane in that room.
700 Cris - LVEA
800 Cris - Out
807 Ken - LVEA working on tables
900 Jeff K. - To EY
901 Jim B. - To CER
902 Bubba - LVEA to move a 3IFO pallet
915 Richard - To CER
916 Hugh - To LVEA to clean up presentation from yesterday
919 Bob, Steve - H2 room
919 Filliberto, Andres - To EY cable pulling for low noise ESD
951 Karen, Cris - To MY and MX
1005 Sudarshan, Darkhan, Rick - To EX for PCal work
1035 Richard - out of CER
1043 Richard - LVEA to talk to Ken near HAM 6
1051 Karen - Leaving MY
1105 Nutsinee - To EY, tagging cable
1112 Dave B. - To EX
1119 Richard - Out of LVEA
1129 Jim B. - Out of CER
1148 Dave B. - Back from EX
1209 Jeff K. - Done with activities at EY
1255 Filliberto - To LVEA to help Ken
1256 Sudarshan, Darkhan, Rick - Leave EX for lunch
1307 Richard - To LVEA
1320 Marco - To EY
1352 Richard - To LVEA
1448 Jodi - To LVEA placing barcodes
1503 Jodi - out
1504 Kiwamu - To EX and EY transitioning to laser hazard
1517 Elli, Nutsinee - To LVEA to restart CO2 laser
1528 Elli, Nutsinee - out
1546 Richard - out
1548 Rick, Sudarshan, Darkhan - To EX
Because Kissel turned on the timing check IOP switches (H1:FEC-7_DACDT_ENABLE), I wrote them into the burt file with SDF.
Nutsinee, Elli
CO2 lasers are back on after transitioning to laser hazard. As before, CO2X is sending 0.23W of central heating to ITMX. CO2Y is on, but is not sending any power to ITMY. We restarted the CO2 laser chillers, which had stopped at yesterday at 15-05-19 17:00UTC and were displaying a "low temperature" fault. At Peter and Richard's request, we have left the CO2 laser keys in their respective chassis in the LVEA.
I have remotely commited a new revision of the h1psliss model that recovers the recent ODC upgrades that were mistakenly wiped out in the most recent revision of that model. The changes are, as in the SVN log, as follows:
After an 'svn up h1psliss.mdl', the model should be rebuilt, reinstalled, and restarted, followed by a daqd restart, which should restore the PSL ODC channels written to frames to a working state.
The RMA replacement of the broken power supply for h1hwinj0 was delivered today. I have installed the PS as the UPS-powered unit in h1hwinj0.
At roughly 10:40 PDT h1iscex
stopped running its models with an ADC timout. Rick and the PCAL team were in the VEA at the time, but we could not link any activity with a potential glitch of the IO Chassis. I restarted the system using a full power cycle of both CPU and IO Chassis. We burt restored h1calex
from earlier this morning.
Per Jeff Kissel's request Betsy and I (Xavi) looked at several SYS subsystem channels to perform timing checks on the IO chassis. These checks were in slides by Shivaraj and the slides should be added to this alog and references to the slides added. The channels we looked at (shown in the attached green medm screen shot) are: H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_1 (Master1) H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_2 (Master2) H1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (Y-arm) H1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (X-arm) Two of them are in the Master, one in the y-arm, and the third in the x-arm. It does not appear that any other channels are active at this time. We took a week of data (in the past of today) for each of these channels and attach figures that show the time series (to check for trends) as well as histograms. All in all these plots look reassuring. Notable features: 1) The timing differences between adjacent points are integer multiples of 7.45ns. Mostly the integer is 1 (see Master1TimeseriesDiff.jpg, only posted it for Master 1, others look the same). 2) There do not appear to be significant drifts (e.g. < 50ns for 1 week in Master 1) 3) The spread is about 50ns (shown in figures labeled Histograms) 4) there is ~1 day periodicity in the time series for Master 2 5) There seem to be common glitches (small ones at the level of ~0.25 us, e.g. see all time series toward the end) Betsy and Xavi
For Livingston I was able to look at the following channels: L1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_1 (Master1) L1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_2 (Master2) L1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (Y-arm) L1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (X-arm) The channels exists but the time series are populated with zeros. X
Elli, Nutsinee
Following LHO alog17941 (PSL accelerometer detected 1Hz glitches) and LLO alog17844 (1Hz peak seen in a magnetometer). Elli left the HWSX camera on from the night of May 16th until the morning of May 18th. I have compared and attached the spectrum from two lock stretches where the HWSX camera was turned on (May 17th 12:00:00 UTC) and off (May 15th 12:00:00 UTC). There's no evidence of HWS camera at the corner station coupled into DARM at ~45 Mpc.
The concern I believe is that this 1Hz comb may be the cause of the 1Hz signal that was seen on the AOM's of the CO2 laser systems see LLO alog 16873. This is not the most pressing issue at this point in time I am of the understanding because the AOMS are not currently used for intensity stabilization of the CO2 lasers, but it is something that is wanted in the near future.
The HWS in the corner station do not cause a 1 Hz feature in the spectrum, they cause glitches once per second. It's not easy to recognize in a spectrum, but very clear in a spectrogram with 1/4 sec FFTs and overlap of 0.9; see Josh's alog. Attached are two spectrograms of the ITMX GS13, the first from the time with the HWS off and the second with it on. The glitches are clear. The third attachment is DARM, where there's no evidence of the glitches.
At LLO, elevated 29-30Hz signal on ground sensors at EndY found the HVAC Fan Frame sitting on a rock. I checked all I could at LHO and only found a couple things that if they were to move into the wrong spot, they could short out the springs. I removed what I could and told bubba about what I could not. Almost because I was unable to open the far west door in the south hallway at the corner station.
Power was interrupted to Comtrol serial adapter, so the EPICS IOC for the weather at end Y needed to be restarted.
EndX has been transitioned to laser Hazard for Pcal work.
Day's Activities
H1 Operator Locking Notes For Today
Came in to find the Arms not locking on GREEN in the morning. Alignment was OK, but when I tweaked up alignment and engaged WFS & this would drop the arm powers. With Daniel & Ellie's help (& Evan's alog), saw that there were issues with the Pit/Yaw M0 Lock Filters for the ITMs. So Inputs were disabled, Cleared Histories & turned off FM2 (+20dB) & FM3 ("empty") filters for ITMx & ITMy. After this we were able to take the arms to "Locked_No_Slow", and then walked through the rest of Initial Alignment.
When we went to locking the full ifo, the first steps is "Check IR" via ISC Lock Guardian Node. We had nice ALS arm powers, but when we got to the "Find IR" state, the arms would break lock and the MC would break lock (not sure of the order though). I believe Sheila caught the issue here (she noticed Tidal issues and then some filters being turned OFF on the ETMs).
Additional Locking Notes I took last Thursday (perhaps moot by now?).
For Locking:
Summary
Our current quad distribution scheme for DARM should be compatible with the new low-noise ESD driver. Most of our rms drive to the ESD happens below 3 Hz, so the extra compensation required for the new 2 Hz / 50 Hz pole/zero pair shouldn't cost us anything.
Details
In the ETMY ESD drive we currently have passive filters installed (D1500113), with a pole at 1.6 Hz and a zero at 53 Hz. We digitally compensate for these in the L2L drivealign filter for L3.
If we remove these passive filters and install the new low-voltage driver (D1500016), we will instead have two poles at 2.2 Hz and two zeros at 50 Hz, and we'll compensate these digitally in the same way. So we will effectively have an extra pole around 2 Hz and an extra zero around 50 Hz, compared to what we have now.
I've attached a set of spectra of the ETMY ESD drive in full lock. The blue is our current drive. The red is my projection of the drive we would have if we install the new driver and compensate accordingly. It seems that most of the rms in the drive comes from 3 Hz and below, so the total rms (about 3×103 ct) won't change much when we change the digital compensation.
This is wrong. I forgot that the new driver has less dc gain for the quadrants than the Strathclyde driver, so of course we will have to push more DAC counts out at all frequencies.