Add 150ml water to Crystal chiller. Added 200ml to Diode chiller. As noted before, the crystal chiller filter is brown, due to 70W install, and will be replaced when the install is finished. The Diode chiller filter is OK. Closing FAMIS task #6565
(late entry from today's work)
Today we valved in heated gas N2 to allow it to flow through the CP4 reservoir. We learned a few things:
I insulated the exposed regen and exhaust pipes and wrapped the exposed purge valve underneath CP4 with Al foil. Also replaced broken TC#2 that measures air a few feet away from supply near top of enclosure (mounted to regen pipe).
Heat Profile Summary RAMP -> Increase measured temperature towards the SETPOINT value at a rate of 1C / hour SOAK -> After measured temperature attains the SETPOINT value, maintain measured temperature at SETPOINT value for time (hours) value entered as "HOLD" RAMP -> Decrease measured temperature towards value at a rate of 1C / hour to that seen at the start of the initial RAMP segment. We increased the SETPOINT value to 115C before leaving the site tonight. Once home, I logged on and noticed that all four of the displayed (camera looking at controller display) temperatures had risen significantly from the values I had noted when leaving the site, i.e. had ramped up at a rate much faster than the program limit of 1C / hour should have allowed it to. In spite of this, the heater output was showing 100%, i.e. was fully on (20 kW)! The output should have responded and been 0% to prevent such a rapid temperature increase. I also noticed that the "HOLD" lamp was on. Thus, the heating profile had somehow advanced to the SOAK segment of the profile and was trying to get the measured temperature to match the SETPOINT value of 115C. I phoned Sheila D. in the control room and she agreed to go out the Y-mid station and help us remotely. Unfortunately, she couldn't get into the building as the mid-stations require a unique key. When I arrived, I lowered the SETPOINT value to slightly less than that of TC1 (T/C used by control loop) which should have caused the heater output to respond by decreasing down from 100%. I waited several minutes, but the heater output never changed and the HOLD lamp stayed on. I ended up power cycling the control unit and restarting the program. I also lowered the SETPOINT value. It seems to be working now. NOTE TC3's bimetal junction must be sampling the air even though it is intended to be clamped to the SST of CP4. I believe this because it changes much too rapidly as should be physically possible while in contact with a large mass and it behaves much like TC1 and TC2 which are intended to be sampling air. TC4 is confirmed anchored to the lift eye on the side of GV11 and is the only T/C which behaves as if in good thermal contact with a large mass of SST. I will re-examine TC3 tomorrow.
I also had to reboot the unit by power cycling it on Saturday when raising the set point. After raising the set point, the heater power increased, causing the control and readback T/Cs to ramp up much faster than 1C/hr. I will talk to the vendor about this bug.
At the moment we have a mix of commercial fibre and the custom (Fabrice) fibre. The mix is due to some fiber being short and the necessity to get light into HAM6 and align the OPO asap.
For Green
We still have a Thorlabs patch fiber from the PAF-X-5-A coupler delivering 2.6mW to the patch panel with about 70% coupling efficienecy. A Thorlabs fiber (extension) delivers 1.4mW to Fiber SN11 (E1700235-V6). SN11 delivers 0.7mW to the vacuum feedthrough. A seperate measurement (alog40762) shows the vacuum feedthrough (SN8) and in-vacuum fibre (SN6) together are 88% efficient.
For IR
SN10 temporarily goes from the PAF-X-5-C coupler to the patch panel delivering 9.37 mW with 72% coupling efficiency. We use a communications fibre as an extension that delivers 8.9mW to SN12. We forgot to measure the output of SN12 and we only get 3.5 mW into the chamber at the output of SN7.
Summary to date of Fabrice's fibres
SN8+SN6=88% (alog40762)
SN11=50%
SN10>72% (includes free-space to fibre coupling efficiency)
SN12+SN9+SN7=40% (unfortunately forgot to measure SN12 individually until after it was connected, and it's awkward, maybe revisit after close HAM6)
Still to install switch and fibres SN9, SN8 and SN7, revisit SN11 and SN12 when time allows.
After tweaking beam alignment and the collimation lens that sends light into the fibre input couplers on ISCT6 we have the following updated results
SN10 > 90% (Seed, includes free-space to fibre coupling efficiency)
SN7 > 85.5% (Green, includes free-space to fibre coupling efficiency)
SN8 > 86% (CLF+Seed, includes mating sleave from fibre switch)
SN9 > 86% (CLF, includes free-space to fibre coupling efficiency)
I've notice some of the mating sleave's are worse than others (one as low as 70% transmission).
I will revisit SN11 (the long green fibre) when the balancing is finished and access is easier.
Terry, Sheila, TJ, Nico, Corey
After TJ's suspension work this morning Nico and Corey helped us install the viewport simulator and move SQZT6 a few inches to the west. Terry and I aligned the 1064 and 532 refl paths through the viewport simulator and adjusted the periscopes on SQZT6 so that both beams are on the table. Terry alinged the green REFL path all the way towards the 1801 which is our temporary REFL PD.
We tried to drive the OPO PZT, now that we think the cabling in chamber is correct, but we were not able to drive the PZT. We also need a power cable for the 532 REFL diode.
Our next steps are to look for a PDH signal out of the 532 refl diode and to attempt to align the SQZ beam to the 2 apperatures while scanning the OPO.
Hugh, Dave:
On 27th February I modified h1oaf to add two RFM senders, one for each arm. This tested that sending the additional channel around the RFM loop did not adversely impact the existing data transfer.
Today Hugh added a receiver for the X-arm channel on h1pemex. The receiver reported continuous errors once all systems were started.
After thinking about this the answer became obvious, the h1oaf model is running way too long to be able to send an RFM signal to the end station. The Timing System reports the latency of sending a signal over the single-mode fiber-optics link to the end station is 29uS. Therefore sending models should ideally be running under 30uS total processing time, which is the case with h1omc (14uS).
To quickly test this, I moved the RFM channel H1:SEI-OAF_2_EX_MUX_RFM from h1oaf to h1pemcs (I hand edited H1.ipc to change the source model name), recompiled and restarted h1oaf and h1pemcs, at which point the receive errors at h1pemex were cleared.
The temporary solution (until we install the long-range Dolphin network) is to use h1pemcs to receive, process and distribute the ground motion data. Any signals which may also be needed by h1oaf can either be read from the dolphin network separately, or sent from h1pemcs via shared memory IPC channels.
WP7397 DNS server upgrade
Carlos, Ryan:
The internal CDS DNS servers were upgraded, please see alog 40855 for details.
WP7380 Squeeze model changes
Sheila, Dave:
The models h1omc, h1asc, h1sqzwfs and h1susopo were modified and restarted this morning.
Seismic STS-GND site wide data distribution
Hugh, Dave:
We modified the models h1isietmx, h1pemex, h1oaf and h1isiitmy to send RFM data between the corner station and EX. Please see secondary alog for details of the problem found and its resolution.
HWWD reset at EY.
The HWWD unit was reset at EY to permit ISI operation. I verified that the LEDs did their startup sequence at the time of the reset.
Fixed broken related display links on SDF_OVERVIEW MEDM
There were three broken buttons on the new SDF MEDM, these are fixed.
New Beckhoff C1PLC4 and safety configurations
Daniel, Patrick, Dave:
New H1ECATC1PLC4.ini and H0EDCU_SAFETY.ini files were generated. I still need to update the autoBurt.req and SDFs for these systems.
DAQ Restart.
DAQ was restarted for various changes:
new H1EDCU_ECATC1PLC4.ini
new H0EDCU_SAFETY.ini
new ini files for h1isietmx, h1oaf, h1pemex, h1sqzwfs, h1susopo
I attempted to add a new INI file for the Rate-Of-Change (ROC) system, which is supporting CP4 bake-out. But I found that some of the channel names exceed the 54 max length limit. Because of this the DAQ restart took longer than usual (about 10 minutes compared with a couple of minutes)
WP7377 h1tw0 hardware replacement
Carlos, Jonathan
The old h1tw0 (cpu and external raid) were removed from the DAQ rack, and were replaced with a single new 4U unit.
Vacuum cell phone alarms, both Thermocouples high alarm set at 130C.
Chandra, Dave:
To support CP4 bake-out, the two thermocouples which are in the cell phone alarm system had their high alarm limit set to 130C.
This afternoon, I went into BSC10 with the intent to:
1) Find something mechanical on TMSY that was causing a small peak at around 2.5 Hz to poke up out of the transfer functions.
- Thought I found something, TFs back in the CR show I didn't fix it.
2) Find something mechanical on ETMY that was causing a small peak poking out of the P TF.
- Found something on the reaction chain, but nothing on the main.
3) Center the L2 stage AOSEMs on ETMY since they moved after Travis' tweek to the pitch of the reaction chain late last week.
- Did this! Woohoo.
4) Try to hunt down the mechanical shorts on the cables Fil reported in his alog from last week.
- Didn't have the feed thru map on me while standing in the chamber alone so couldn't figure out which cable of the 30 connections to start working on. Fil's language of what cables doesn't help much with out further maps... Now back in the CR, Kissel and I see that the shorts are apparently on these cables:
ETMY Face Cable
ETMY L1 (UIM stage)
ETMY L2 (PUM stage)
The TMS looks fine for shorts.
ETMY shared cable and R0 face cable look fine for shorts.
See attached fro spectra.
There are 3 in-vac thermistors mounted to the OPO. The first one is read through the TEC controller and works fine. The other 2 are reading zero Ohms. The wiring is correct up to the Squeezer EtherCAT chassis 3, indicating it has an internal wiring problem.
The Peltier heater works too. The controller parameters and loop shape were imported from LLO, and the servo works in-air.
Carlos and I racked the new hardware for h1tw0. The old hardware has been pulled from the racks.
Ran SEI seismometer mass position checks. The following are out of range: There are 13 T240 proof masses out of range ( > 0.3 [V] )! ETMX T240 1 DOF X/U = -0.345 [V] ETMX T240 1 DOF Z/W = -0.578 [V] ETMX T240 2 DOF X/U = -0.491 [V] ETMX T240 2 DOF Z/W = -1.077 [V] ETMY T240 1 DOF Z/W = -1.013 [V] ETMY T240 2 DOF Y/V = -0.852 [V] ETMY T240 3 DOF X/U = -0.912 [V] ETMY T240 3 DOF Y/V = -0.392 [V] ITMX T240 1 DOF X/U = -0.594 [V] ITMX T240 2 DOF Z/W = 0.343 [V] ITMX T240 3 DOF X/U = -0.671 [V] ITMY T240 3 DOF X/U = -0.677 [V] ITMY T240 3 DOF Z/W = -1.293 [V] and There are 2 STS proof masses out of range ( > 2.0 [V] )! STS A DOF Y/V = -4.67 [V] STS A DOF Z/W = 5.894 [V] All other T240s and STSs are reporting in range.
Trends reflect ongoing work during 70W installation.
J. Kissel
I've filled in the infrastructure for ZM1, which was mostly copying over filters from ZM2, and filling in the standard OSEM2EUL and EUL2OSEM matrices for an HTTS. I found, however, that the damping loops don't work. So, I took some driven transfer functions and spectra to see if I could identify the problem. Sadly, the dynamics -- especially the common mode actuator longitudinal TF -- looks pretty dicey. See attached screen shots.
Data templates live here:
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/ZM1/SAGM1/Data
2018-03-02_2225_H1SUSZM1_M1_WhiteNoise_L_0p01to50Hz.xml
2018-03-02_2225_H1SUSZM1_M1_WhiteNoise_P_0p01to50Hz.xml
2018-03-02_2225_H1SUSZM1_M1_WhiteNoise_Y_0p01to50Hz.xml
Problem with ZM1 Identified / Diagnosed; Solution Proposed J. Kissel The above transfer functions -- especially the P to P and Y to Y transfer functions -- reminded me of what we typically see in the off-diagonal transfer functions (e.g. P to Y or Y to L). This lead me to suspect the basis transformation and/or the sign of actuation chain. I first confirmed that the OSEM2EUL or EUL2OSEM matrices were installed correctly, and they were (I just did it, so...). So, then I started applying offsets in the COILOUTF bank. Using the conventions defined in T1200015, I expect that a positive offset in the COILOUTF bank (if I've got the COILOUTF GAIN correct, and the magnets are arranged as in the HTTS controls design description, E1400316) would cause that corresponding OSEM sensor to go more positive. This worked for UL and LL, but I got a more negative response from UR and LR. I then flipped the COILOUTF GAIN sign on those two, and et voila! The transfer functions cleaned up nicely, and look exactly as expected (within the tolerance / varience of HTTS resonances that we've seen prior). I conclude that the UR and LR Flag/Magnets have N and S facing magnets, respectively (when looking at them from the back of the optic) when they hould have S and N, respectively. Nice -- "simple" solution! For now, I've left the non-conforming COILOUTF gains that make the SUS bhave as normal in place. I've spoken with TJ, and he'll (a) check the polarity of the flags to confirm, and (b) flip them, such that ZM1 conforms to E1400316 on Monday. If only the OPOS was this easy to diagnose... New data files live in /ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/ZM1/SAGM1/Data/ 2018-03-02_2312_H1SUSZM1_M1_WhiteNoise_L_0p01to50Hz.xml 2018-03-02_2312_H1SUSZM1_M1_WhiteNoise_P_0p01to50Hz.xml 2018-03-02_2312_H1SUSZM1_M1_WhiteNoise_Y_0p01to50Hz.xml
... But #RespectThePhase
J. Kissel
A keen observer will notice that although the labels in the legend say ZM1 for the reference, I copied over the template from
/ligo/svncommon/SusSVN/sus/trunk/HTTS/H1/ZM2/SAGM1/Data/
2018-01-24_1909_H1SUSZM2_M1_WhiteNoise_L_0p01to50Hz.xml
2018-01-24_1909_H1SUSZM2_M1_WhiteNoise_P_0p01to50Hz.xml
2018-01-24_1909_H1SUSZM2_M1_WhiteNoise_Y_0p01to50Hz.xml
then text search-and-replaced ZM1 with ZM2. Long-story-short: the reference trace is ZM2.
Now, respect the phase: see that ZM2's phase is 180 deg at DC, where ZM1's is 0 deg at DC for all DOFs? Grumble Grumble Grumble... That means where ZM2 requires a different damping loop sign than ZM1.
An inventory of our HTTS reveals that OM1, OM2, OM3, ZM2, and RM1 all require positive damping loop gains (all other digital signs being equal), and RM2 -- and now ZM1 -- requires negative.
Sadly -- this also means that ALL BUT RM2 and ZM1 ARE WRONG by an overall sign.
*now* I think that it's the *LEFT* sign of the magnets that are flipped the wrong way -- namely that UL and LL are S and N, respectively when they should be N and S, respectively.
But -- since we have access to ZM1 right now, and I'd rather we have to change one (two, if you count RM2) suspension than five.
So -- this is what I predict TJ will find (looking at the back / AR side of the optic):
UL UR
S S
N N
LL LR
and he should re-arrange the magnets to be
UL UR
S N
N S
LL LR
which is the exact opposite of what's shown in E1400316, so that we confirm to the apparent LHO convention.
THIS aLOG AND COMMENTS ARE FULL OF LIES: Go to LHO aLOG 40847 for final answer as to what was going wrong with the sign convention.
Starting again this morning. Flowing small amount of GN2 to start (1/4 turn on valve ~ 20-40 scfhx100). So far no change on heat output from enclosure. Proportional gain set to 3, cycle time 0.1s and zeros for the I. and D. portions of Beckhoff PID parameters. Regen setpoint at 80C. Bake enclosure currently at 82C at TC#1 and heater at 41%.
The PSI procedure calls for 50 gram/s of GN2 flow rate. 1 kg of GN2 = 30.42 cf, so 50 grams/s = 5476 scfh (our flow meter reads in multiple of x100, so the marker should fall roughly around 55 scfhx100.
Increased flow by opening valve another 1/4 turn (open 1/2 turn total) to achieve 55 scfhx100. Regen temp peaks at around 75C and then falls to 55C and goes back up, with current P(ID) settings. No change on enclosure heater - still at 41%.
NOTE: flow bounces around between 30-45 schfx100 because of the vaporizer. When it settles for moments, it reads around 20 scfhx100. I will continue to slowly open ball valve, referred to as the "vaporizer feed valve (V-11) in PSI documentation. Also note that the valve they refer to as "regeneration vent valve" (HV107) does not exist at LHO.
Taking detailed notes for future reference and for LLO's upcoming CP regen.
Trend of regen temp (measured just downstream of heater outside in a TC well) and exhaust temp, measured by TC that is routed up the exhaust exit pipe a few feet (modified from original TC well from days of manual/sem-auto overfilling).
Opened up vaporizer feed valve by another 1/4 turn (3/4 turn total). More fluctuations in flow rate. Will continue to monitor as it settles. No change in enclosure heater (41%).
Increased GN2 flow again (now valve is opened one full turn) with fluctuations around 40 scfhx100 or less. Also increased proportional gain setting to 5 to get regen temp closer to setpoint (80C). It was cycling around 60C with a setting of 3.
Opened up vaporizer feed valve another 1/4 turn (1-1/4 turns so far), inching towards 55 scfhx100 flow (around 40 now). Also raised the prop. gain setting to 7 to get regen temp closer to set point of 80C.
Enclosure heater now at 42% output and supply temp reads 85C. We will need to raise the setpoint today. I contacted the vendor about the bug in code (?) when we raise set point. We're finding we need a hard reboot of the system so the heater doesn't overshoot and push to 100% output.
Opend vaporizer feed valve another 1/2 turn for a total of two full turns open. Flow is hovering around 40 scfhx100. Increased regen GN2 setpoint to 95C with prop. gain setting at 7. Enclosure heater output is 43%.