Kiwamu, Lisa, Matt, Stefan - First we verified that the CARM to transmitted light transition still works today (arm power 0.32*single arm). - Next we repeated the transition to AS_45_Q, and turned on the gain scaling (arm power 2.0*single arm). - We also immediately turn on AS_45_Q gain scaling with TR_X (arm power 2.0*single arm). - Then we turned on the DHARD WFS (arm power 2.0*single arm): whitening gain of 9dB: H1:ASC-AS_B_RF45_WHITEN_GAIN 3 H1:ASC-AS_B_RF45_Q_PIT_GAIN and H1:ASC-AS_B_RF45_Q_YAW_GAIN gain to 0.1 input matrix AS_B_RF49Q to DHARD H1:ASC-INMATRIX_P_8_6 1e-4, same for yaw H1:ASC-DHARD_P_GAIN 0.3 , same for yaw control filter modules FM1 (integrator) and FM5 (Low pass LP0.2) output matrix: H1:ASC-OUTMATRIX_P_7_8 = 1 , H1:ASC-OUTMATRIX_P_8_8 = -1 , H1:ASC-OUTMATRIX_Y_7_8 = 1 , H1:ASC-OUTMATRIX_Y_8_8 = 1 - Then we went to a hgher arm power (arm power 32*single arm). - We noticed that TR_X starts saturating right around there, so we intended to switch to the QPDS, but had an unreasonable amount of trouble for this simple operation. - Still trying... Attached is a plot of the CARM transfer function. It also includes a transmitted power ratio of the QPD's and the LSC PD's.
The message is that we increased the build up in the arms up to ~30 times the single arm power (CARM offset ~ 40pm). The first plot shows a trend of the arm power transmission. In the first (incredibly stable!) lock we made several attempts to reduce the CARM offset further, but the IFO started to become unstable, so Stefan was quickly going back to a larger offset to prevent unlocking. It turned out that the problem was a saturation in the X TR diode (clearly visible in the second attachment). The following locking attempts were killed by the (in principle) straightforward task of switching to the in-vac TR QPDs. The problem turned out to be that the signals that we were carefully matching were one before power normalization, and the other one afterwards..
Later, we reduced the CARM offset further down to approximately 20 pm at which point the arm build up was 100 times higher than that of the single arm.
As reported in Stefan's previous log, we were having a difficulty in switching the TR sensor from TR_X(Y)_A to ASC_QPD_Bs. Keeping using TR_A actually introduced a broad noise peak at around 70 Hz which showed up all the LSC loops. Stefan then carefully adjusted their relative gains and therefore the transiotion went very smooth. We did not see an obvious transient in any of the LSC signals during the transition of the TR sensors. Then we further reduced the TR_CARM offset to -15 counts without a problem. We did not see a gain peaking or any sign of significant change in the optical gain of DARM. So we did not have to chage the DARM gain. At this point we saw REFL_DC almost going down as low as 50% and also POP_DC increasing significantly. We kept running the DHARD ASC loops.
We stayed at this point for a while, but then it seemed that the DRMI dropped the lock. Before the lock loss, RMS of the SRCL control signal slowly kept increasing. It could be a coupling from CARM which was contaminating the SRCL control. We may want to decrease the SRCL UGF in order to prevent the SRM suspension from saturating.
Nice going, you are almost there. (The old grouch (for Lisa's benefit)
The ALS_COMM and ALS_DIFF FIND_IR algorithms have not been working over the last few days, but they have been taking a lot of time to fail.
This evening we rewrote them both. ALS_DIFF has a nice algorithm which tries the known good locations quickly, and if that doesn't work it searches around those locations. Unfortunately, the search part has only been tested a few times, because the initial quick check of known locations usually works.
For ALS_COMM, we didn't bother with a search feature. The known good locations are checked, and if that fails (which is rare) it asks for help from the user. It would be good to better test the search functionality of ALS_DIFF, and then make ALS_COMM have something similar just to deal with the rare cases in which the known locations fail.
ALS_COMM is, in fact, not working too well. It may really need some search ability.
For initial alignment, and transmon pointing onto the baffle PDs in particular, we have a new script.
in /opt/rtcds/userapps/release/asc/h1/scripts there is
ditherAlign.py
which has top level functions for TMSX and TMSY (and place holders for the ITMs) - this can be called from the command line e.g., ./ditherAlign.py TMSX
baffleAlign.py
contains functions for aligning optics to baffle PDs - it includes a very coarse spiral search, a dither alignment, and higher level combinations of theseslowDemod.py
contains ultility functions for dithering and demodulation using EPICS (yes, I know its bad, but what else? and it works for freqencies below 4Hz...)testDemod.py
for testing slowDemod.py
When the TMSs are close to the correct position, the dither alignment takes less than 1 minute. When they are way off, it takes a few minutes.
This should be extended to the ITMs and ETMs to help find them when they are really lost. Once it is working well, we should move these into the IAS guardians.
There are some strange things, but in summary,
WFSA is more sensitive to the hard mode (arm axis rotation at around the center of the arm) than the soft (arm axis translation).
WFSB's sensitivity to the hard mode is smaller than WFSA by a factor of 5 or so. Also, WFSB is somewhat more sensitive to the soft than WFSA.
This means that we can use WFSB as the soft mode sensor and feed back to TMSX (because TMS causes the soft and the hard mode with comparable normalized amplitude at the same time), while using WFSA as the hard mode sensor to feed back to e.g. ITMX. Then we can use the ITMX camera image to slowly feed back to the ETMX to fix the beam position on ITMX. Or you can do fancier diagonalization but you get the idea.
In the attached, the right most plot shows the response of WFSA and WFSB against EX and IX PIT motion.
You can see that WFSA's response is much larger than WFSB. You also see that WFSA only goes down when you tilt EX, but that's not the case for IX (why?).
The middle plot shows you both PIT and YAW response. Again WFSA is much more sensitive than WFSB.
The left plot is the response against TMS in YAW (didn't have time to do PIT), and you see that the WFSB response is about twice as large as WFSA.
Both ETM and ITM causes mostly the hard mode motion because the cavity is close to concentric.
OTOH TMS causes both the hard and the soft mode motion at the same time.
So, all in all, these appear to mean that WFSA is more or less the hard mode sensor, and WFSB is the soft one.
SEI working on BSC2
Commissioning work on X-arm
Working happening over the break will require work permits
Apollo working on cabling outside and in the VPW
EE working in H2 building
9:30 Corey Craning in LVEA, done 13:30
10:00 Sudarshan to LVEA
10:45 Richard to LVEA
13:45 Corey back to LVEA
14:00 DaveB to CER, both Mids, back at 14:30
14:00 Richard and Vern to CER
Vern and Richard re-installed the TCS X rotation stage interface board with the protection diodes removed.
Dave Ottaway, Elli
For the X-end green WFS, we adjusted the WFS autocentering gain to match the Y-end WFS. The updated values are:
H1ALS-X_A_AUTOC_PIT_CTRL_GAIN: 200,000
H1ALS-X_A_AUTOC_YAW_CTRL_GAIN: -150,000
H1ALS-X_B_AUTOC_PIT_CTRL_GAIN: 70,000
H1ALS-X_B_AUTOC_YAW_CTRL_GAIN: 70,000
The unity gain frequency at the for the X-end WFS is:
WFS A PITCH: 15 Hz
WFS A YAW: 15 Hz
WFS B PITCH: 6 Hz
WFS B YAW: 7 Hz
And the unity gain frequency at the Y-end:
WFS A PITCH: 10 Hz
WFS A YAW: 10 Hz
WFS B PITCH: 7.5 Hz
WFS B YAW: 7 Hz
Ed, Keita, Jeff
So, a quick and nasty coherence check just to find possible dead monitor channels using a couple of frequencies reveals apparent bad channels:
ETMY M0: SD - voltmon, fastimon
R0: F1 - noisemon
L2: All Channels? - noisemon
ITMY L1: UR fastimon
All suspensions in Y-Arm from TMS back to ITM were tested. Any not specified here measured good.
The fact that ETMY L1 shows apparent DC offsets, in the -4300 ct range in all noisemon channels, UL voltmon and LR fastimon, is not revealed by this measurement.
The contractors will not be working on the new DCS addition during the Thanksgiving holiday, 11/27-11/30. They will return on 12/1.
The frontend laser watchdog was re-activated. For reasons unknown it was switched off around midnight on 11/11.
I'll go through and review to make sure nothing has been reverted or missed but this should be the last HEPI matrices to be corrected, at least those that really affect current operation and positional studies.
The rotation and pringle dofs had magnitude errors of x2 & x4 and the output (CART2ACT) matrix was all 1s. See the first attachment for the before (left) and correct (right) values.
The second attachment shows the times series as the platforms were taken down, the matrices corrected (shifting the Cartesian readings) and bringing things back up. No issues in that process: the ISI ST2 was already just damping, ST1 was brought down to damping and then the HEPI deisolated. Matrices updated, RZ Reference Location corrected, new filters loaded, HEPI and ISI reisolated. I tweaked the yaw position a few 100nrads to recover the exact OpLev output. Brough the system backdown to take a safe.snap and then reisolated. By the way, the Pitch & Yaw are correct.
The final two attachments are the before controllers and the new 4hz UGF generic controllers. The TF data going into these are from H2 ETMY but I still looked at them and with some phase margins in the lower 20degrees and some gain peaking near 3 using a 5hz UGF, I lowered the UGF to 4hz and now the phase margins are lowest in the upper 20s and the worst gain peaking is just over 2.
Updated safe.snap and new foton file committed to svn.
Daniel asked me to remove the search for home command from the ISC_DRMI guardian (this guardian had issued 61 search for home commands in the past 24 hours). I committed isc/h1/guardian/ISC_DRMI.py to SVN before making this change. I commented out the search for home line in the DOWN state's main section, and reloaded this node at 10:47PST.
Daniel was having problems with cam22 when executing a snapshot. The cam22 epics channels froze. Restarting the process via monit and manually did not recover the system, so I rebooted h1digivideo2. Daniel repeated his snapshot and it failed again. After the second reboot I successfully snapshotted cam22 and Daniel can no longer reproduce the error.
model restarts logged for Tue 25/Nov/2014
2014_11_25 04:27 h1fw1
2014_11_25 11:03 h1pslfss
2014_11_25 11:03 h1psliss
2014_11_25 11:03 h1pslpmc
2014_11_25 11:06 h1broadcast0
2014_11_25 11:06 h1dc0
2014_11_25 11:06 h1fw0
2014_11_25 11:06 h1fw1
2014_11_25 11:06 h1nds0
2014_11_25 11:06 h1nds1
2014_11_25 11:07 h1nds1
2014_11_25 12:04 h1broadcast0
2014_11_25 12:04 h1dc0
2014_11_25 12:04 h1fw0
2014_11_25 12:04 h1fw1
2014_11_25 12:04 h1nds0
2014_11_25 12:04 h1nds1
2014_11_25 12:45 h1broadcast0
2014_11_25 12:45 h1dc0
2014_11_25 12:45 h1fw0
2014_11_25 12:45 h1fw1
2014_11_25 12:45 h1nds0
2014_11_25 12:45 h1nds1
2014_11_25 12:46 h1nds1
2014_11_25 19:33 h1fw1
two unexpected restarts. Maintenance day. PSL DAQ changes. DAQ restarts for PSL, DMT and Beckhoff.
conlog daily frequently changing channels report attached.
Evan, Kiwamu, Evans (Matt), Stefan - After finding a new alignment this afternoon, we realigned the DIFF beat note. - We halfway succeeded in scripting the CARM TR transition. The setup is now all done in the state "CARM_ON_TR". - The actual transition requires an ezcaservo (to suppress the voltage difference on the CM board while ramping). We struggled to implement it in Guardian. For now the following lines are required: ezcaservo -r H1:LSC-REFLBIAS_OUTPUT -g 0.000003 -f 1 H1:ALS-C_COMM_VCO_TUNEOFS -t 120 & sleep 5 ezcastep H1:LSC-REFL_SERVO_IN2GAIN -s '0.25' '+-1,28' ezcawrite H1:LSC-REFL_SERVO_IN2EN 0 ezcaswitch H1:LSC-REFLBIAS FM5 FM8 ON The last step engages a boost and a lead filter. Attached below is a loop transfer function of the CARM loop at sqrt(TRX+TRY)=1.5. - After that we moved the arm powers to sqrt(TRX+TRY)=1.5 (about 200nm). There we handed off to H1:LSC-ASAIR_A_RF45_Q. - This took a input matrix gain of 4e-7. We saw an oscillation kick in at 20 Hz, se next we will try at 2e-7.
Maybe the obvious question: Why are we not using the VCO tune servo which is already built into the VCO interface?
In light of yesterday's realization that POPAIR_B was saturating, and that DRMI locks much faster with a lower input power, here is a time series of the demodulated REFLAIR_A error signals during a DRMI lock acquisition attempt at 4 W.
The ADCs have a range of ± 215 counts (≈ 33 000 counts). The largest excursions shown are something like 17 000 counts on RF9I, so that means at 10 W we would instead expect excursions of ≈ 43 000 counts, which means we'd be saturating.
The PRCL trigger is not shown in the attached plot, because PRCL is always on during locking.
J. Kissel, M. Evans, D. Hoak, E. Hall, A. Staley As Dan describes briefly in LHO aLOG 15297, we want to think about how to implement ALS COMM, ALS DIFF, DARM, and CARM, very-low-frequency, tidal offloading global control to the ETM HEPIs in the front end. Currently we're using a guardian-run servo over EPICs, as described in LHO aLOG 15244. In this log, I describe our thoughts on how to do for the long term. After scouring the LSC model, we've found that ETM HEPI models are currently receiving the same LSC signals that the ETM QUADs are receiving. This is left over from when we were trying to attempt the distributed hierarchy. However, now that we've moved to an offloaded hierarchy for length control, we don't want to have to re-create the integrators that exist up the QUAD's signal chain, hope we get it right (and or the computer), and integrate once more to get the offloaded control signal we want. The REFL_SLOW path -- the digitized, slow output of the CARM Common Mode Board which takes the ALS COMM signal as its input -- was initially tossed up as an idea for the digital, very-low-frequency, COMM correction signal because it's currently hooked up through to the LSC CARM bank, but for the reasons described above, it's not exactly what we want for the long term. After discussing the options, we've decided that we need an additional path from the LSC model to each ETM HEPI AND we want to restore the OFFLOAD path from the TOP of the QUAD (straight) to HEPI. Why? - Currently, the digital IMC length control (the natural signal for controlling tidal drift) is only fed directly to MC2, and does not pass through the CARM or DARM banks. - We don't want to offload to, or directly control use the TOP mass of the QUADs because that stage of the QUADs have proven to have particularly bad length-to-angle coupling such that large longitudinal control signals just pitch the test mass over destroying the lock just as much as tidal forces would by themselves by reaching the range of the various VCOs. - For CARM, one might ask - why not offload to MC2's HEPI? - can't because PR2 is also in HAM3, and the low frequency displacements to the PRCL aren't the same as what's needed for the red laser frequency. Further, a nuance of how the green end station lasers are tied to the PSL -- with the *transmission* of the reference cavity, which doesn't change when the IMC to PSL VCO to REFCAV REFL servo is changed -- while the COMM / CARM feedback to the PSL via the IMC changes the *red* frequency to match the common motion of the arms, it *doesn't* change the *green* arm laser frequencies in common with the arms. - For DARM feedback, which will be sent through the suspensions because we need the bandwidth, will be offloaded on a few stages on its way up to HEPI. For CARM, we send most of the control through the MC2 SUS all the way to its TOP (because its a much better behaved SUS) and only the very low frequency would need to be send to the ends. So CARM and DARM need inherently different paths. - For DARM, one might ask - why offload straight to HEPI, why not ST2 of the ISI and up-through as we've snaked through the QUAD? - because, currently, the best configuration is not to use ST2 of the ISIs. The offload path would require the isolation loops to be ON in order to function. Given that the ISI configuration is still, and will probably be, under flux, let's just go straight to HEPI which has happily run with position loops only for quite some time, and we've found that it runs best that way. Given that we're still unsure what will work, we propose to create an additional, mini output matrix in the LSC model that takes in DARM, CARM, and IMCL, and spits out control to ETMX and ETMY HEPI. How much extra infrastructure is needed? - A new mini-matrix as described above, and the wires to make the connections from DARM, CARM, and IMCL to it and out to the top level. - Two new RFM IPCs between the LSC model and the two end station HEPI models. - Restore the M0 offload filter path and EUL2CART matrix that was removed in ECR E1300578, for the Longitudinal DOF only. - Two new end-station dolphin IPC connections between the QUAD models and the HEPI models. - Two new filter banks in the HEPI model (or at least after the output matrix, it could be in the LSC model) to match the frequency response of the direct CARM offloaded signal from LSC to the indirect DARM offloaded signals from SUS. - A summing node at the top level of HEPI. How painful will this change be? How much will it affect library parts? - The LHO LSC model is currently still hooked up to a library, but I'm not sure whether LLO is using it. So, though not under ECR control, a discussion might be nice before a change is made. - Because we can only imagine doing such direct LSC global feedback to the ETM HEPIs, we can add the new filters and summing node to the top level of the ETM HEPI models, and send signals into the common HEPI library part as is without modifying it (or requiring an ECR). - Even though we've removed the OFFLOAD path from all SUS, because we had wanted to re-create the total length control signal on the QUADs eventually (like is done for IMC-X), the longitudinal control signals are still passed to the top of the library part for the QUADs (thank god). Thus, only a top-level change is needed for the QUADs as well -- the EUL2CART matrix and IPC parts can all be added to the top-level of the ETMs only. Because we're only trying to change longitudinal, we shouldn't even need the full EUL2CART matrix (as originally described in T1100617) So in summary, not that bad. BUT -- we'll probably still wait until next week to get started with the changes given the limited staffing over the Turkey-day holiday. Thoughts and comments welcome, ESPECIALLY those that come in BEFORE we make the changes.
Maybe we should put together a design doc first. There are a couple of obvious questions:
A couple notes: 1) How is the IPC getting from LSC front-end to SEI end-station front-end? To do this same scheme at both sites, you will need to send it over the RFM from LSC to end-station ISC or SUS, and from there to the end-station SEI. This is a very slow loop, so I think you can adjust for the extra cycle delay. LLO's end-station SEI do not have GE FANUC RFM cards, so don't use them. 2) The LSC model is currently at the limit in getting RFM to the end-stations (and regularly fails to send properly). There is currently no real-time cycle overhead for an additional RFM broadcast (or two as it has to go to both ends). CDS has not been able to qualify newer, faster hardware that works without timing glitches.
Initial attempts to take undamped TFs on ITMX & ITMY exhibited rung up P & R modes (see LHO aLOG entry 14653). For the next attempt, fine tuning of excitation amplitudes was necessary to avoid ringing up these modes. Phase 3b (in-vacuum) undamped TF measurements have been taken for ITMX & ITMY (QUAD) suspensions as follows:- - ITMX M0-M0 undamped results (2014-10-30_0700_H1SUSITMX_M0_ALL_TFs.pdf) - ITMX R0-R0 undamped results (2014-10-30_0700_H1SUSITMX_R0_ALL_TFs.pdf) - ITMY M0-M0 undamped results (2014-10-28_1200_H1SUSITMY_M0_ALL_TFs.pdf) - ITMY R0-R0 undamped results (2014-10-28_1200_H1SUSITMY_R0_ALL_TFs.pdf) ISI Status: ISI's damped and FULLY_ISOLATED via Guardian. ITMX & ITMY undamped TFs above have been compared with other similar QUADs at the same phase of testing (allquads_2014-10-30_AllQUADS_Doff_Phase3b_ALL_ZOOMED_TFs.pdf). The plot key is as follows:- Blue Trace = Model Prediction (fiber/thincp). Orange Trace = L1 ITMX (fiber 2013−09−04), Phase 3b. Black Trace = L1 ITMY (fiber 2013−09−05), Phase 3b. Magenta Trace = H1 ITMY (fiber 2014−10−28), Phase 3b. Cyan Trace = H1 ITMX (fiber 2014−10−30), Phase 3b. Summary: M0-M0, main chain TFs are a very good fit to the model, for all DOFs, with only some minor cross-couplings from P2V. R0-R0, reaction chain TFs agree with the model predictions and are consistent with similar QUADs. The largest deviation from the model can be seen with the ~1.45 Hz P mode, a consequence of the harness routing stiffening the suspension, seen before. Some minor cross-couplings are also present: from P2L, P2R, and P2V only for ITMY. Damped TFs should be taken to verify that damping loops suppress these cross-couplings. All data, scripts and plots have been committed to the sus svn as of this entry.
Power spectra had been taken and processed a while back, but not posted until now. These power spectra measurements have been compared to previous Phase 3 measurements for H1 ITMs (allquads_2014-11-26_Phase3_H1ITMX_ALL_Spectra_D*.pdf). The plot key is as follows:- Black Dashed Line = Expected Sensor Noise Blue Trace = H1SUSITMY 2013−07−19_1400, Phase 3b (in-vacuum) Green Trace = H1SUSITMX 2014−04−11_1600, Phase 3b (in-vacuum) Red Trace = H1SUSITMX 2014−07−07_1000, Phase 3a (in-air) Summary: Noise floors for recent ITMX measurements are consistent with previous measurements, but are much more noisy below 40 Hz due to air turbulence, clean rooms, purge air etc. Oddly, L1 and L2 OSEM DOFs appear to suffer from a scaling problem. However, scaling is correct for L1 & L2 EULER DOFs. n.b. the same discrepancy was also observed in the data taken before the optic was swapped. Thus, raising no concerns. All data, scripts and plots have been committed to the sus svn as of this entry.
Damped transfer functions can be found in LHO aLOG 15575.