thomas.vo@LIGO.ORG - posted 16:02, Tuesday 27 May 2014 (12094)
BS ISI tripped at ~22:30 UTC
Actuation limit reached.
Actuation limit reached.
Actuation limit reached.
Both were T240 trips. There isn't a clear reason, the tour hasn't started yet, the door work is finished.
Something was tilting the platform
This could have been due to signals from the LSC which were msitakenly sent to the BS suspension, I'm not sure.
This morning, I:
- added the SR3 and SRM baffles to the HAM5 table and all of their dog clamps - I don't know why I didn't anticipate that the AOS cookie cutters for these were incorrect since I just went through this at HAM4, but they are. This time, I set all of the baffles in place according to the hole pattern on the table and the maps. I will get the cookie cutters modified to be correct, but at least the weight is on the table and roughly in the correct place.
- switched out the TFE stops on the SR3 - this was more involved than I anticipated since the 2" all metal/TFE stops were trapped by their own EQ stop bracket (chalk that one up to another #facepalm #poordesign). I ended up having to dissassemble the brackets somewhat in order to rotate them to get the old and new EQ stops to clear. We shoulda done this before putting it i the chamber - put the TFE was so nice during the move...
- added a vertical 3" wafer holder and a 1" horizontal witness plate holder to the table
- added the temperature cable and it's 8 brackets to the table - I did not lace the cable since there is still an open question on how I can do this better this time. It's bundled out of the way and is of negligable weight for SEI rebalancing.
- finished securing the cable routing.
- removed all tools/pans.
So, all payload is on the table and I've turned it over to SEI for balanceing/testing.
10:08 PDT, rebooted h1guardian0 due to memory swapping. All guardian processes started automatically.
HughR, HugoP,
We installed the rencently-designed HAM-HEPI generic position loops on HAM4 last Friday. We had tried in the past but there was an issue with the way they were saved as a .mat file, before being loaded by the commissioning scripts. This has been fixed, and the updated controllers, and scripts are available under the SVN:
Generic Position Loops:
/ligo/svncommon/SeiSVN/seismic/HEPI/Common/Generic_Pos_Loops/Position_Loops/HAM_HEPI_Generic_Position_Loops_23_May_2014.mat
Plots:
/ligo/svncommon/SeiSVN/seismic/HEPI/Common/Generic_Pos_Loops/Plots/
Design Scripts:
/ligo/svncommon/SeiSVN/seismic/HEPI/Common/Generic_Pos_Loops/Scripts/
This Sled is trivial in that it only has one lens & the WFS are not on the Sled (already on table). So basically, one just lays the optics out according to the drawing; this was done months ago. Unfortunately, I didn't take photos of the layout or measure distances between optics; I opened up the Sled and did this the other day.
Photos for the Sled are here.
For the positions of the optics, I used a ruler and measured from the edge of the Breadboard to each individual optic. So, we have:
All of these measurements are +/- 1mm. (see attached photo for rough drawing of layout).
Found the DTS frame writer had a kernel panic, and the ldas gw was frozen. It's still down, and likely will be until this afternoon.
The upgrade of framecpp to ldas-tools-1.19.32 done on May 2 prevents daqd from starting, as the version of libframecpp that daqd requires is not present any longer. I'll have to recompile the daqd processes for the data concentrator, nds, and frame writer computers.
The daqd programs have been recompiled from the trunk, and daqd has been restarted on x1fw1, x1nds1, and x1dc0.
- Arnaud Pele took transfer functions on HAM5 and they look good. - Apollo looking to tack both doors on HAM4 - CPB build preparation in the west bay cleanroom (the room w/o the solid stack) - TCS continuing to work on HWS camera build, nominal laser hazard time in the afternoon for CO2Y alignment - Peter King is still working on the ISS Maintenance day today - Water is back on! - LN delivery to CP2 - Greg Grabeel is flushing LN2 for long term storage.
Lisa, Daniel, Sheila
The messages:
1. We could successfully engage WFS after we aligned the cavity and centered them, using Keit'a matrix
2. We don't see any improvement in the ALS COMM noise as measured by transmitted IR with WFS on and off. However, the noise is small to start with (around 10Hz rms). So we reached level 2 on Valera's levels of awesomeness (It worked, but it didn't improve the noise).
(Lisa, Sheila, Daniel)
We finally added the CM summing node to the common mode path. The signals are hooked-up as follows:
Fast readbacks still need to be tested. The medm screen can be accessed from the ALS overview screen.
I just noticed that the h1guardian0 machine is in need of some attention. It currently is using all its RAM and is swapping from disk, so presumably it is now performance limited.
The memory usage started increasing around 17:30 PDT Thursday 22nd, and got steadily worse. Swapping started at 03:30 PDT Friday 23rd and has been doing so ever since then.
We will most probably reboot during tomorrow's maintenance.
controls@h1guardian0:~ 1$ free -g
total used free shared buffers cached
Mem: 11 11 0 0 0 0
-/+ buffers/cache: 11 0
Swap: 11 5 6
model restarts logged for Sat 24/May/2014
2014_05_24 06:44 h1fw0
model restarts logged for Sun 25/May/2014
Unexpected restart of h1fw0, no restarts reported for Sunday.
J. Kissel, A. Staley As suspected, the problem appears to be the 71 MHz local oscillator that the Y end. At the remote advice of Alexa, I increased the ALSY's "LO mon" value, H1:ALS-Y_REFL_A_DEMOD_LONOM, from 20 to 21. As soon as I did so, the arm locked up instantly, the demod error disappeared, and the guardian error message cleared. Even more strange, the monitor value, H1:ALS-Y_REFL_A_DEMOD_LOMON is still *above* 21, so the nominal must be a mean with a range not a threshold. Even more strange than that, if I decrease the nominal value back down to 20, the arm remains locked. DAH! I guess I have plenty more to learn on this system. Anyways, the 71 MHz power supply still claims that its power supply voltages are too low, and its output monitor, H1:ISC-RF_Y_AMP71M_OUTPUTMON, says the power is 51 [dBm]. We should fix this (if its actually broken) on Tuesday. We should also put in some effort to making the guardian subsystem messages more clear. For now I'll continue with the LO nominal set to 21 [??]. (Though I'm surprised that Stefan's state machine doesn't prevent me from doing this...) Also, I attach the MEDM screen chain one has to follow to get to this information. SITEMAP > ALS tab > ALS Overview > Y Arm PDH [little black words in a silver background box] > 71MHz RF Amp I'm leaving both the X and Y arm locked and well aligned. And will shoot for the moon again tomorrow.
Doesn't make a lot of sense to me. The PDH LO is driven the 24.4MHz source. The 71MHz is used by the VCO. It looks like the monitor cable is unplugged, or maybe the 71MHz source is down? Check the RF monitors of the VCO. Documentation actually exists. RF monitors are part of the Beckhoff system. The tolerance is ±1dBm. A 1dBm variation of the PDH LO shouldn't prevent the Y-arm from locking.
(Corey, Gerardo, Patrick)
Two days ago (about 4am Thurs morning) the ISS diffracted power started to drift down from about 6.7% down to 2.0%. Once at 2%, it started to go into oscillations (roughly around 3am this morning); see attached 2-day trend.
Without instructions on how to address this (and no recent alogs noting this behavior), we scratched our heads a bit, moved some gains and hit buttons to no effect. We returned back to the original state. Then Patrick suggested we try switching from PD A to PD B, and this appeared to stop the oscillations. It took us to a value of about 5%. Unfortunately, it looks like the power is still sloping down however. (Curious to see if the ISS goes back into oscillations at 9pm tonight).
Actually switching PDs was not the way to go here; we generally want to stay with PD-A.
So here, you want to adjust the REFSIGNAL (H1:PSL-ISS_REFSIGNAL) channel in 0.01 amounts. With Rick on the phone, I went from -1.63 to -1.55. This stablized the Diffracted Power and took it from ~2% up to ~10%.
J. Kissel The Messages: (1) The effective bias voltage charge on the test mass is -28 [V_pk], which quite small compared to the BIAS range of 400 [V_pk] (and in conflict with Keita's assessment from the optical levers [see LHO aLOG 11905]). (3) The force actuation strength is asymmetric with respect to bias voltage, confirming Keita's result (see LHO aLOG 11872) (2) The force coefficient at 11 [Hz], measured as a function of bias voltage, is roughly 0.5e-10 [N/V^2], a factor of 8 below the expected 4.2e-10 [N/V^2] (expected from pg 7 of G0900956) DETAILS ------------- Brett: please proof read: ------------- Note, no linearization algorithm was used during this experiment. (1) Using the time-honored MIT method of measuring test-mass charge (e.g. from Brett, John, and Lisa), I drove a single frequency line into the control voltage H1 SUS ETMX ESD drive, looking at the X arm cavity length (as measured by green), while stepping the bias voltage through its entire range. As one steps down the bias voltage, we expect the linear response to drop to zero. Further, one can take the slope of the response as the bias decreases from both the positive and negative side and predict an effective bias voltage created by residual charge on the test mass. I attach the results. Using a linear regression, weighted by the coherence as follows, unc = sqrt( (1 - coh) / 2*nAvgs*coh ) weight = 1 / unc^2; I calculated the intersection of the two slopes to be -27.99 [V_pk]. I took an excessive amount of data points, because I didn't know what I was doing when I started and wasn't sure how the results would turn out. The template is here for excitation: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGL3/Data/2014-05-15_H1SUSETMX_L3_ChargeTest.xml For the record, I tried using the script recommended by Brett (LHO aLOG 11914), but after updating all the necessary channel names and input variables. it failed deep with in its subfunctions because of some xmlconv library that's now gone missing since 2009. I didn't have the time nor expertise to debug, so I just changed the bias by hand and measured the ten averages with the GUI DTT session, capturing references as I went, and exported at the end for processing. (2) No further details here, it's obvious that the drive strength is weaker with positive bias voltage than with negative. I have no good explanation for this. (3) From these displacement response results, one can also obtain the force coefficient for each bias step. The calculation is as follows: disp_mpk = 1e-12 * sqrt(2) * sqrt(binWidth) * disp_pmrtHz; force_Npk = disp_mpk * 1./compliance_11Hz.mpN; V_CTRL.Vpk = nActs * sqrt(2) * sqrt(binWidth) * esdGain * excChannel.amplitude.V_DAC.VrtHz; V_BIAS.Vpk = bias.V_ESD; forceCoefficient = abs(force_Npk ./ (2*V_CTRL.Vpk * V_BIAS.Vpk)); where disp_pmrtHz = displacement response of the arm cavity length at 11 [Hz] during each bias voltage setting, in [um] (which I subsequently turned into [pm] for plotting clarity) as measured from the calibrated ALS control signal, H1:ALS-X_REFL_CTRL_OUT_DQ sqrt(2)*sqrt(binWidth) = sqrt(2)*sqrt(0.09375 [Hz]), calculation needed to change from noise units ?_{rms}/rtHz to amplitude units of ?_pk 1e-12 = 1e-12 [m/pm] compliance_11Hz.mpN = 5.3e-06 [m/N], TST to TST, L to L transfer function at 11 [Hz], obtained from the QUAD model. excChannel.amplitude.V_DAC.VrtHz = 12.45 [V/rtHz], measured output request voltage from the DAC (calibrated from counts out of the digital last output to ESD, i.e. H1:SUS-ETMX_L3_MASTER_OUT_LL_DQ using the 180bit DAC gain, 20/2^18 [V/ct]) esdGain = 40 [V/V], gain of the ESD driver sqrt(2)*sqrt(binWidth) = sqrt(2)*sqrt(0.09375 [Hz]), calculation needed to change from noise units ?_{rms}/rtHz to amplitude units of ?_pk nActs = 4, since the calibrated output requested voltage is only from one channel. and I've computed the force coefficient, a, using only the linear term, since I used the amplitude of the linear term alone F = a (V_CTRL sin(wt) - V_BIAS)^2 = a V_CTRL^2 sin^2(wt) - 2 a V_CTRL V_BIAS sin(wt) + a V_BIAS^2 [ sin^2(wt) = 1/2 - 1/2 cos(2wt) + O(4w) ] = a(V_BIAS^2 + 1/2 V_CTRL^2) - 2 a V_CTRL V_BIAS sin(wt) + - 1/2 a V_CTRL^2 cos(2wt) DC Term Linear Term Bi-linear Term =>> Linear Term, a = F (2 V_CTRL V_BIAS) Confusingly, this resulting coefficient, a = 0.5e-10 [N/V^2] is a factor of 8 weaker than expected, which is *different* than the factor of 4 weaker that was needed to explain the linear transfer functions taken last week (see the second attachment of LHO aLOG 11676). The script that processes the measurements is here: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGL3/Scripts/analyzeesdcharge_20140515.m
Jeff, This is getting pretty mysterious. Suggest that you try to establish whether you actually can see the capacitance change with relative motion of the test mass with respect to the recoil mass in each ESD quadrant. The bridge circuit would be a good way of doing this. I will be at LHO starting Monday and could help out with the measurement. One explanation is that you do not really have a solid connection to either the bias or the control electrodes - an open connection with either only capacitive coupling or a high resistance. RW
Jeff, 1 piece of good news - this amount of voltage implies that the isolation performance is probably not compromised by the charge. Long ago I did a rough estimate for how much charge could be on the optic in a blob near the tip of the earthquake stop. https://dcc.ligo.org/T080214 Although the field gradient is the important thing, and this is a function of both of the amount of charge and the spatial distribution there-of, one can say the if the blob is about the size of the stop, then the voltage of it is about 140 V before it compromises the isolation performance. -Brian
J. Kissel, B. Shapiro, Brett has caught a mistake in my calculations above, in that I *should not* multiply the control voltage, V_CTRL.Vpk, by a factor of four (i.e. nActs). My thoughts on including the factor of four were that I was measuring the requested DAC output of *one* quadrant, and since there're 4 quadrants, I add the force created by each of them. However, given how the force coefficient was defined for all four quadrants, it's better to think of each of the four quadrants creating a ring of control voltage, all held at the same requested value. It's then the potentional difference between this control ring and the bias ring that generates the forces on the test mass. Hence the caluclation for the force coefficient should be disp_mpk = 1e-12 * sqrt(2) * sqrt(binWidth) * disp_pmrtHz; force_Npk = disp_mpk * 1./compliance_11Hz.mpN; V_CTRL.Vpk = sqrt(2) * sqrt(binWidth) * esdGain * excChannel.amplitude.V_DAC.VrtHz; V_BIAS.Vpk = bias.V_ESD; forceCoefficient = abs(force_Npk ./ (2*V_CTRL.Vpk * V_BIAS.Vpk)); (Thanks for the clarification Brett!) In addition, while debugging, I caught another error: The uncertainty from each data point as calculated above computes the *relative* uncertainty. As displayed on the graph, since the plot shows absolute amplitude of the displacement, the uncertainty should be displayed in absolute units, as in unc = disp_pmrtHz.full .* sqrt( (1 - coh) / 2*nAvgs*coh ) weight = 1 / unc^2; Finally, even more dumb of a mistake, a copy and paste error meant I was using the asd vector as my coherence vector. All of the above errors, bugs, and mistakes have been corrected, and I attach a revised plot. The new force coefficient is roughly 2.2e-10 [N/V^2].
