J. Kissel, G. Mansell Georgia and I gathered one last data set with the prototype electric field sensor at BSC10 / EY, with the goal of measuring a few driven fields: the ISI coil drivers and the SUS ETMY's ESD Shield. With a reasonable drive (sine waves @300 Hz, with ~40% of the DAC range for the ISIs, as-low-as 5 Vpp on the ESD shields) we can resolve both clearly above the noise floor. Attached are the results, in 2018-03-06_H1SUSETMY_BSC10_EFM_Results.pdf We conclude (at the respective frequencies), the field generated per unit drive is Field Coupling Units Notes ISI ST1 Coils 0.8723 (V.m^{-1}).A^-1 (Driven in V, 3 Vertical Actuators, answer = mean(field ./ (3*current drive on V1))) 3.7284e-10 (V.m^{-1}).(DAC ct)_Z^{-1} (answer = mean(field ./ (3*dac count drive on V1))) ESD Shield 0.0024451 (V.m^{-1}).V (answer = mean(field ./ voltage drive on shield)) %%%%%%%%%%% Details %%%%%%%%%%% Measurement Setup Notes The ESD Cabling vs. The SHV Passthrough Box in which one can configure how the shields are connected, a.k.a "Shield Box" Associated Pictures: 2018-03-06_H1SUSETMY_ESD_CablesAtFeedThru_AsFound_Pics.pdf - We went up to the mezzanine work platform above BSC10 in order to connect / replace the current limiting resistor (CLR) box with the Shield Box, and we were surprised to find the chamber-feedthru-to-CLR-box-side of the ESD cables disconnected from the CLR box. This was both convenient and inconvenient for us: the cables we needed to connect to the Shield Box were already disconnected, but that meant we had to assume the cable ordering from the rack-side of the CLR box was correct and the box was a passthrough (I was 90% confident of this, but I note that this box is not in the wiring diagram -- D1400177). The order we found connected: Rack-side CLR Rack-side Box Label Cable Label 1 LR 2 UR 3 UL 4 LL 5 Bias - Before connecting the chamber-feedthru-to-CLR-box-side of the ESD cables to the Shield Box, we tested whether the CLR-box side of the shields were grounded w.r.t. the chamber (a.k.a. "floating"). The were not grounded; they were floating. We did not check whether the chamber-feedthru side of the cables were grounded. We should have, but we're reasonably confident that the CDS team confirms this regularly. Driving the Shield: Associated Pictures: 2018-03-06_H1SUSETMY_BSC10_ShieldDrive_Setup_Pics.pdf - After connecting the chamber-feedthru-to-CLR-box-side of the ESD cables to the Shield Box (in the above described order), we had a frustrating amount of trouble trying to keep the Shield box (electrically) floating, i.e. preventing it from grounding, and making sure what voltage we applied to the Shield Box's shield "excitation" wire + gator clip actually went to the shields of the chamber-feedthru-to-CLR-box-side of the ESD cables. The "ShieldDrive_Setup_Pics" picks show that we needed the already-there clean wipe bag, and several used clean wipes in order to get the Shield Box chassis and all shields floating the desired affect, that driven voltage showed up on the shield and only the shield of the chamber-feedthru-to-CLR-box-side of the ESD cables. - We used an analog SR DS340 wave function generator to drive the shield, with the "func out" output set to High-Z. The output was connected to the gator-clip of the Shield Box's excitation cable with a BNC to clip-lead adapter that had its clip leads cut off. We were sure to wrap the gator-clip + (red) signal bare wire in a used cleanroom wipe to ensure shielding from ground. The (black) shield wire was floating in air. - In order to test that the drive was making it to the chamber-feedthru-to-CLR-box-side of the ESD cable shield and the system was otherwise floating, we requested a 1 V_{pk} offset from the SR DS340, and measured the potential difference between ground and the CLR-box side (now the Shield Box side) of the chamber-feedthru-to-CLR-box-side of the ESD cables. - We then BNC T'd in an oscilliscope to confirm the output levels of our various sine-wave drives (removing the 1V offset). The Field Meter: Associated Pictures: 2018-03-06_H1SUSETMY_BSC10_InChamber_Electrometer_Pics.pdf - We re-installed the prototype field meter in the middle of the chamber on the bench that was in chamber. It was set up to measure the field in the longitudinal direction. - We guess that the field meter is about 0.75 meters away from the EY test mass, in the +X, +Y global coordinate direction. - Of acoustical note from the last time, this bench was sitting on used clean wipes, where as the previous measurements' bench had not. - At the request of others, we took a full-span measurement of the ambient chamber field (with the door covered in foil to rudimentarily complete the chamber faraday cage) with the return of the battery box floating (i.e. with the white banana clip hooked into the battery box, no grounding clip) and grounded (i.e. with the banana clip hooked into the battery box, and also electrically connected to ground). We saw no difference in these results (see pg 4 of the EFM_Results.pdf attachment) so we measured the remaining driven results with the return floating. - We used this reference ASD to find a nice quiet / sensitive region to drive. We chose the ~300 Hz region because it was above all of (what we think to be) acoustic noise, but still low enough frequency to be relevant to the most sensitive region of the IFO's DARM sensitivity. ST1 ISI Z Drive: - Both stages of the BSC ISI are mechanically locked to Stage 0, and HEPI is locked, so no physical motion of the platform is caused by driving the ST1 actuators at ~300 Hz. - We had to reset many layers of watchdogs, including the hardware watchdog in the EE HighBay in order to allow for ISI drive to occur. - Once able, drove the ISI in Z with a 367.3 Hz size wave (via awggui, with a 360-370 Hz 4th other cheby1 bandpass to be sure we were only driving at 367.3 Hz) in the H1:ISI-ETMY_ST1_ISO_Z_EXC field. - We drove at 200 ct_pk and 400 ct_pk at the ISO_Z_EXC point, which I later confirmed with dataviewer and DTT that that corresponds to identical drive to the V1, V2, and V3 actuators, at the level of 12700 and 25300 ct_pk, which is 8111 and 16223 ct_{rms} (as measured via ASD by a fres = 0.125 Hz BW spectrum, with the default Hann window; NENBW = 1.5, ENBW = NENBW*fres = 0.1875). - The two amplitudes were to check for / confirm linearity. ESD Shield Drive: - With feedthru-to-CL-box ESD cables, the Shield Box, and waveform generator described as above, we drove three sign waves at 383.5, 321.9, and 269.1, to look for frequency dependence, and the first of which at three amplitudes to look for linearity. Analysis Details - I calibrated the DAC output of the ISI into current across the coils by dividing by the following calibration (in matlab in post-processing) derived from D1001575, coildriver.c = zpk(-2*pi*136,-2*pi*[32 300],1); isiinterface.c = zpk(-2*pi*15.9, -2*pi*0.4, 0.4/15.9); actuator.g = 20/2^16 * 1.0 * 0.156; % A / DAC ct calibration.isi.c = actuator.g * coildriver.c * isiinterface.c; - That results in a calculated current of 3.4 and 6.9 uA_{rms} at 367.3 Hz on each coil. - To convert this to the total current through the three vertical coils, I just multiply by 3 to get 10.4 and 20.8 uA_{rms}. - Because the ASD I used is not bin-centered, I scaled this up a bit by the ratio of the data-viewer measured peak amplitude (converted to rms amplitude) and the peak amplitude measured in the MASTER_OUT ASD (again converted to rms amplitude). These factors were a small 10% correction to arrive at the numbers you seen in the legend of plot 2 in EFM_Results.pdf. - To arrive at the concluding answer above, I took the mean of the to rms amplitude ratios (noting that the SR785 uses a Blackman-Harris window as default, NENBW = 2.0044, fres = 0.25, ENBW = NENBW*fres = 0.5111) Results Discussion - It appears the field scales linearly with both ISI and ESD shield excitation. Good! That's why I report the average in the concluding results. - With three data points, it's tough to say, but the lowest of the three frequencies we drove of the ESD shield showing a larger amplitude makes be suspicious that the shield coupling is frequency dependent. What's Next - We intend to bring the field meter down to EX next and do a plethora of further exploratory measurements. - Take a more detailed frequency response of the field resulting from the ESD shield driving. - Try driving the signal and bias of the ESD - Try different DOF excitations on the ISI ST1 - Try driving ISI ST2 actuators. (probably won't see anything, cause they're smaller than the ST1 actuators.) - Try driving OSEM coils. (probably won't see anything). - We also intend to project these results to DARM, essentially calibrating LLO's measurements of the shield driving to DARM (LLO aLOG 28675) into electric field units.
Posted are the results of the IS CPS noise spectra. All look OK except HAM6. HAM6 is a bit elevated. Since there are many activities at or near HAM6 this is not necessary unexpected. Closing FAMIS #6940.
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).
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%.
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.
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.