[Georgia, TVo, Sheila, Jenne]
Summary: We were able to lock and align the Xarm and input beam for both green and IR.
This morning, we locked Xarm with the green laser, and aligned TMSX, ETMX and ITMX to the green beam. As usual, PR3 was adjusted to get the transmitted green beam out onto ISCT1. (The ALS light pipe was also opened.) The ALS WFS didn't end up working for us today - the yaw signals seemed to make sense, but the pitch signals didn't really. We decided to move on rather than investigate this in detail. The TMS and ITM pointing were both set using the bafflePD alignment script, then ETMX was adjusted to maximize the transmission through the cavity.
After lunch, we succeeded in moving IM4 and PR2 to get the IR beam aligned to the Xarm.
We ended up using LSC-POP_A_RF45_I to lock the Xarm, rather than the planned ASC-AS_A_RF45_I_SUM. POP has worse SNR, but seemed to work a little bit better. We did not go back and re-try to use AS_A after the cavity was well-aligned, but we need to check and confirm that the signal path is doing what we think it is, sometime using MICH (it all looked fine, and was going to Xarm_IN1, but we just weren't catching any good locks). We used an input matrix element of -10 for POP, so that the XARM_IN1 was the same roughly +-200 counts that it was during O2 initial alignments of Xarm-only flashing with the old ASAIR_RF45. Otherwise all the Xarm locking settings were as in guardian.
We had some struggles throughout the day, see in particular Sheila and Georgia's alogs. TVo is summarizing our Xarm visibility measurement in yet another alog.
Attached is our alignment after the arm peek. IMC WFS were on, but no other ASC is engaged. I also attach the IMC overview, for the IM4 trans and POP_B values, so we don't have to trend them later.
Attached are screenshots showing the ITMX suspension overview, the IM overview, and spot positions on IM4 and the OSS QPD (which the beam is not on right now) and the oplev overview after yesterday's alignment, in case this information is useful in addition to the slider values.
Also, after locking the X arm in green we also adjusted PR3 to maximize the comm beatnote on ISCT1 which has not moved since O2. The final alignment of IR into the X arm was done with this PR3 alignment.
Since the HPO has been off, the FSS has been oscillating at 238Hz according to the PZT fastmon. THe attached screenshot shows some examples.
This caused us some problems during the arm peak, and it would be difficult/futile to do DRMI with this happening. It would be great if someone could look at this loop in the morning.
This morning I looked at the noise spectra for the Pockels cell path and the PZT path. There is a broad hump around the region Sheila mentioned, along with a large number of what I presume are mains related peaks. Adjusting either the common gain or the fast gain did not appear to have any affect on the hump. In the Pockels cell path, there was a large peak at ~55 kHz, which might be a harmonic of the PZT/Pockels cell cross over. Attached is the transfer function of the TTFSS measured this morning. It is noticeably different from ones I remember. Not least of which the unity gain frequency is down a fair amount. Increasing the common gain increased the unity gain and phase margin but the PZT monitor became noisier. Not 100% sure of the reason. My suspicion is that it may be related to the alignment of the Pockels cell after the NPRO. That would be one thing to look at when the laser gets overhauled. Also attached are the measured transfer functions of the pre-modecleaner servo for slider gains of 16 dB and 19 dB.
I unplugged a read back signal cable (that we never have utilized) which indicates the OPEN/CLOSED status of CP4's 10" gate valve and, shortly thereafter, noticed that PT246B had tripped off -> I re-enabled it in CDS but it isn't likely to "fire" at these Y2 BT pressures -> I assume that this is another example of the inter-dependencies with the Beckhoff "daisy chain" setup? I haven't yet adjusted to the new "normal".
This also happened today when closing GVs 5,7. PTs 114,124,134 tripped.
This doesn't sound to me like a Beckhoff issue, or at least not the one I think you are referencing.
Revisited leak checking the new hardware bolted to CP4's 10" gate valve -> No leaks detected with 6 x 10-10 torr*L/sec background -> Moved clean room etc. and began wrapping components for baking -> Expect to be baking by e.o.b. tomorrow.
TITLE: 02/06 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
Today light was flashed down the X-arm. Locked with green and currently working on locking in red. Not sure if they'll stay here the full time to 8pm, but Jenne said, "will be definitely be here past 4pm." :)
LOG:
Some recent modest ASC full data trend plots have shown gaps in the data with an accompanying popup error:
[Error] Purging failed. Increase 'Max drawing path length' in prefs.
It is not immediately clear what "purging" and "max drawing path length" mean, but if you increase it from the default of 20k to 100k the gaps disappear.
Attached is the 'gappy' plot with the popup, and the preferences with the increased max drawing path length
Recently, Rolf and Jonathan alerted CDS to the existence on 'qtgrace', a currently-supported grace implementation that appears to solve several issues. In the attached plot, you can see an extra sizing slider (currently at 1.3) and a "Fit" button that resizes a plot to fit the window. Currently packaged by Michael Thomas for SL7, we are working on a test rollout at LLO
Opened GV 5,7 for commissioners x arm work. Opened up GV 5 to utilize cryopump #1. Pressure at beam splitter is currently 1.14e-7 Torr. Pressures just past CP 1,2 are 6.64e-8 Torr and 7.75e-8 Torr, respectively.
Recorded another RGA scan just before opening valves, after the filament was turned on overnight (thanks Jeff K.!). Will scan again later today.
(This RGA computer in control room is not functioning properly. An upgrade is in its future.)
Note the high N2 peak.
Here's an RGA scan at 3:30pm with corner exposed to arms (X1,X2,Y1). Carlos had to wipe the RGA computer today and unfortunately we lost all the stored ASCII data from previous RGA scans. Many should be in aLog but since the default ASCII file that exports from Quadera doesn't upload into aLOG, it sometimes didn't get uploaded (such as this morning's scan). Scan plots are always uploaded as PDF, jpeg, or similar.
TITLE: 02/06 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
Wind: 5mph Gusts, 4mph 5min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.57 μm/s
QUICK SUMMARY:
Gate Valve #7 in the LVEA is currently being opened, and we are staging for taking a peak down the X-arm.
J. Kissel, D. Barker A while back, I'd put together Simulink infrastructure for the OPOS (optical parametric oscillator suspension; then called VOPO) while we were beginning to rearrange the SUS HAM56 ADC / DAC allocation to accommodate the new squeezer suspensions (see LHO aLOG 38827). Since then, we've decided several things we'd like to change: - We don't like a suspension type and an instance of that suspension type to be the same. So, VOPO and VOPO gotta go. - We don't call the output mode cleaner the "vacuum output mode cleaner," so, we've dropped the V in VOPO for the instantiation, and now the suspension type is OPOS. - We don't like the channel ordering H1 V1, H2 V1, H3 V3, in the digital system, because that's not how team seismic orders there sensors named the same way, so we convert to H1 H2 H3, V2 V3 V3 (see E1700390 for sensor arrangement) - The important axis of the OPOS is *not* aligned with the HAM6 ISI's Cartesian coordinate system, so we convert to every other suspension's coordinate system, i.e. Euler, i.e. L T V R P Y (see G1701821). Also, I never actually got the MEDM screen infrastucture up to speed to match *any* model, let alone the above new requests. Today, I updated the front-end code to meet all of the above requests, compiled it, Dave installed it and restarted the h1susopo process. After that, I've moved things around in the sus/common/medm/ userapps repo folder to changing things from VOPO to OPOS, updated a bunch of screens and the associated marco file, and committed it all to the svn. I've also *begun* to fill in this infrastructure where I can, but it's not fully complete. OSEM2EUL and EUL2OSEM basis transformation matrices we copied by hand from TST aLOG 11396, 'cause the scripts that calculate the values need to be updated for the now-preferred channel order. I've still gotta - copy over damping filters, - re-check-in with TJ regarding magnet polarity for the COILOUTF gains, - fill in the watchdog signal processing filters, and of course, - we need OSEMs to include any open light current stuff in the OSEMINFs). Certainly good enough until we actually hook up our OPOS to the readout and control system. We also need to change the naming convention in the h1susauxh56 model (VOPO to OPO) so we can pick up the coil driver monitor channels that are always useful when debugging whether suspension is being driven. Finally, I've made sure the SDF system's safe.snap is up to date with all new settings, and committed that to the repo as well. Attached are a few screenshots and a text file with more detailed notes about what needed changing -- especially the details of the top-level front-end model changes.
J. Kissel I've made the necessary name changes to the h1susauxh56 front-end model and the associated channels on the OPOS overview screen. The auxiliary model has *not* been restarted, since I don't want to demand a DAC restart on the arm peak team. We should install the code and restart the h1susauxh56 front-end process as soon as is convenient. Further MEDM and settings updates: - I've updated the overview screen to include a diagram of the relationship between the OSEM coordinate system and the Euler coordinate system, a. la. E1700390. - I've converted the coil driver monitor screen (which was a totally incorrect copy of a HAM triple's monitor screen) into a standard, six-channel, filter bank screen. This allows for calibration of the voltage monitor signals, if we so desire. Remember, the OPOS AOSEMs are driven with an HAM-A driver which *only* has voltage monitors, unlike core-optic suspensions which have the full NOISEMON, VOLTMON, FASTIMON and SLOWRMSIMON collection of monitors, and it only has one isolation stage, so a fancy screen in not needed here. (Since the h1susauxh56 model with corrected channel names has not been installed, the screen remains full of white EPICs records.) - I've installed COILOUTF coefficients: they're all negative. See explanation below. - I've installed filtering on the OSEMs for the OPOS watchdog. Remember, this is one of the first suspensions to receiuve the updated watchdog infrastructure (see E1700387) so it now, not only has a 0.1 to 10 Hz bandpass prior to the cdsRMS part that all , but a 10 sec "averaging" filter (i.e. a 4th order butterworth low pass filter with a corner at 0.1 Hz) after the cds RMS part. Y'know, like you're supposed to with an RMS calculation. We'll see how it goes once we hook up OSEMs. We'll also then decide how to calibrate the signal and set the threshold. - I've copied over the damping filters from LLO, using that which was committed to cds_user_apps/trunk/sus/l1/filterfiles/L1SUSOPO.txt rev. 16732 (last changed rev. 16627) Spying on LLO, I've found that although there are lots of filters in each bank, only one is used (FM6), and the gain field is otherwise populated with gains something like what's mentioned in LHO aLOG 11390. I'll have to have a conversation with Stuart / Arnaud before I claim I understand what's happening. After these changes, I can definitely say we're ready for OSEMs. OPOS COILOUTF Sign Convention Explanation: To establish the sign I use +YAW for the horizontals, +VERT for the verticals, the existing EUL2OSEM matrix, the established AOSEM sign conventions requested regarding coil current vs. magnet polarity T1200015, and the physical orientation of the OSEMs found in the assembly drawing D1500295. For +YAW, we wish for the OSEMs to expand (as per D1500295), i.e. to push the magnet away from the coil. Given that all OPOS magnets have N polarity facing in the OSEM (as per E1700390), we need a negative current across the coil to create a push with a N magnet (as per T1200015). The EUL2OSEM matrix retains the sign of the requested +Y drive (i.e. the Y to H1H2H3 EUL2OSEM elements are all positive), so we must invert the sign of the requested, +YAW * EUL2OSEM, drive signal to get a negative requested current on each OSEM. Thus the H1H2H3 COILOUTF gains shall be negative. For +VERT, we wish for the OSEMs to contract, i.e. to pull the magnet into the coil. With the N polarity facing into the magnet, that means we need a positive current across the coil. The EUL2OSEM matrix flips the sign of the requested +VERT drive (i.e. the V to V1V2V3 EUL2OSEM elements are all negative), so we again must invert the sign of the requested, +VERT * EUL2OSEM, drive signal to get a positive requested current on each OSEM. Thus, the V1V2V3 COILOUTF gains shall all be negative.
J. Kissel, S. Aston Stuart rightfully noticed that although the OPOS_MASTER model had the usual OPTICALIGN, LOCK, and DRIVALIGN array of filters, it was not reflected on the MEDM overview screen. Whoops! I've now added all that and committed the screens to the userapps repo.
Initially found a high 10-9 torr*L/sec leak on the turbo pump side of the 2 1/2" RGA isolation valve -> vented, R&Rd this gasket -> follow up leak test done with an LD background of 4 x 10-9 torr*l/sec Leaving LD running overnight but with turbo spun down
TITLE: 02/05 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
LOG:
Valved in vertex RGA and all six main ion pumps and valved out all three main turbo pumps (all pumps reading ~1 mA). Tomorrow will open GV 5,7 for x-arm commissioning (8am-8pm local).
RGA scan with IPs valved in and MTPs valved out. Also attached scan pre-vent for comparison.
How long had the filament been energized before taking today's scan?
< 90 min. Jeff K. turned filament on for me via phone instructions. Will scan again tomorrow morning before opening up to beam tube.
Here is a scan after the IPs were pumping over night and turbos valved out, and RGA filament turned on for > 12 hrs.
Sheila, Nutsinee, Terry,
This is an update on the progress so far on the VIP. We have aligned and mode matched both the CLF/seed 1064 path and the 532 pump path to the OPO, and are ready to think about swapping M1 for the higher green reflectivity version.
Here's the green data (+PZT calibration). Note that the data hasn't been corrected for dark current.
I corrected the green data for dark current as Sheila suggested. The mode matching calculated from transmitted power is now 73.5%. The dips in reflected power are 78.8% of the power off resonance. Higher order modes has not been taken into account.