Closes FAMIS 26012. Last checked in alog 80608.
No significant changes from last week.
Overnight the ITMX coil driver states were wrong, causing the ASC controls to satuate the PUM durring acquisition. (This become aparent when the DHARD gains are increased at the end of DHARD WFS, which happens right before PARK_ALS_VCO 80699)
This used to be reset in ISC_LOCK PREP_FOR_LOCKING state, this has been commented out (line 618), with a note that SDF will take care of this, this has been commented out in the guardian for over a year. Indeed. we found that the coil driver state was incorrectly set to 3
The attached screenshot shows the error was introduced to the safe.snap sometime between 2:30 and 5 pm yesterday, as it was correctly reset in the first two locking attempts of the day, but wasn't correctly reset after the lockloss at 5 local time last night.
Erik, EJ, Dave:
We found that h1susitmx's safe.snap file was truncated from 2265 lines to 1336 lines (last 929 lines removed) at 14:47 Tue 15oct2024. This truncated file was loaded into the model at 17:09 Tue. The BIO STATEREQ channels were in the missing block, and so were not restored to val=2 until the safe.snap file was fixed Wed 09:20.
TITLE: 10/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Corrective Maintenance
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 2mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.27 μm/s
QUICK SUMMARY:
TJ was up all night damping Violin modes!
When I walked in IFO was Unlocked and struggling to lock green arms.
Relocking:
I've Requested Inintial Alignment.
Locking Notes:
Initial_Alignment went smooth, DRMI_1F locked quickly:
ISC_LOCK got past DHARD_WFS and immediately I_X Saturations started to happen.
We noticed that the Saturations were coming from the ITMX L2 stage.
Sheila spotted the fact that the Coil Drivers were in the wrong state.
H1:SUS-ITMX_BIO_L2_UL_STATEREQ = 3
H1:SUS-ITMX_BIO_L2_UR_STATEREQ = 3
H1:SUS-ITMX_BIO_L2_LL_STATEREQ = 3
H1:SUS-ITMX_BIO_L2_LR_STATEREQ = 3
But they needed to be in state 2 instead!
Sheila stopped me from just quickly changing that 3 to a 2, which would have broken the lock.
Apparently Shelia relieved one of the Coil Drivers from driving, and then changed the state of that Coild Driver while it was not driving. Then turned that coil driver back on and rotated it back into driving with the restof the Coil Drivers. The she would rotate another Coil Driver out of driving to update the state. Maintaining at least 3 coil Drivers at a time.
Apparently there is a matrix change from driving with all 4 Coils to driving with 3 coils.
Then change the ramp time and value from 3 to 2, then change the matrix to rotate through all 4 coild drivers to "free" a different coild driver from driving. is the procedure that kept our lock. Please see Sheila's alog.
We believe that there was a change to Prep_for_locking that is supposed to update the state of the coild drivers before locking.
P.S.
We turned the Softloops off to deal with the above, and we sat in POWER_25W but we only had 10Watts, because softloops were turned off and we forgot to turn them back on. But it gave Rahul time to Damp Violin modes, which is good because the violin modes do seem big red and mad.
Violin modes are now damping down nicely using the nominal settings for 2W. I have ramped-up the gains for few of the modes in all four optics which will enable to calm them down faster. Later will move to damp violins at full power.
Been trying to get the violins down for the past 2 hours and made barely any progress. Many of the problem modes on ITMX just didn't seem to respond positively to any gains that have worked in the past. We just lost lock, so I'll try some damping on RF and see if that can somehow help.
After losing lock a few times while damping, I think I've finally found a combo that kinda works. While waiting in RF I would request the violin gaurdian to go to DAMPING_ON_SIMPLE, then change the ITMX mode 3 gain down from -40 and increase as needed, and change the ETMY mode 1 to +90 and with a gain of -0.2 as teh google doc says. This worked well and damped most of the problematic modes. I still had issues with ITMX mode 3 & 13 though. This is the limiting factor right now. These two modes just won't go down at any reasonable pace.
Just lost lock again. The lock losses have been from small earthquakes, and other reasons that I haven't figured out.
Damped in RF for a while and was able to get ITMX modes to what I thought were reasonable levels, when we transitioned to DC there were still saturations going on, so I tried damping further there but we lost lock. Each time they ring back up and I have to start almost from scratch. I thought that there must be an incorrect setting or filter on ITMX, but I haven't found anything. At this point I'm beginning to think there might be something else wrong, but I have no idea where to keep looking right now since things seem to somewhat work while damping the violins.
TITLE: 10/16 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Aligning
INCOMING OPERATOR: TJ
SHIFT SUMMARY:
IFO is LOCKING at CHECK_VIOLINS_BEFORE_POWERUP.
Violins:
We lost lock at 00:09 UTC (lockloss alog 80697) and have not been able to get to NLN since. A local earthquake rung violins up violently such that some are in the 8/9 zone. While the alignment is great, (DRMI locked without PRMI 5 times), we have IX saturations starting at PARK_ALS_VCO. I initially thought this was an ALS or maintenance Tuesday issue, but that doesn't seem to be the case. After chatting to Jenne, we realized that it was indeed the violins. So I started damping.
Setting all violins to their nominal damping states successfully prevented IX from saturating at ENGAGE_ASC_FOR_FULL_IFO, where it was saturating consistently. Moving to CHECK_VIOLINS_BEFORE_POWERUP results in 1 saturation/second, losing lock eventually (after 30 mins or so). Any form of powerup also loses lock immediately. I talked to Rahul, and he recommended staying at a steady state to damp for a few hours since sometimes it just takes that long. Spoke to the incoming operator, TJ and he's been informed of the unsteady state of the IFO.
I'm already past this state but my recommendation (from speaking to Rahul) would be to stay at PREP_ASC_FOR_FULL_IFO at nominal damping for a few hours.
FAMIS 27800 TCS Chiller Water Level Top-Off_Weekly
TCS CO2X Level before : 29
added 250 ml
TCS CO2X Level after : 30
TCS CO2Y Level before : 9
added 200 ml
TCS CO2Y Level after : 10
Nothing seemed out of place, I saw no leaks.
Noted in the following TCS Chiller spreadsheet:
https://docs.google.com/spreadsheets/d/1Mu7-pmjWiRQxU3rX3lI0LB4UXI9asC-efkCnS9sT58k/edit?gid=0#gid=0
Lockloss due to an EQ from Mexico. EQ mode activated but ground motion was too high and we lost lock 3 mins after EQ mode.
TITLE: 10/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 156Mpc
INCOMING OPERATOR: Ibrahim
SHIFT SUMMARY:
Scheduled work to be done today for maintenance:
CDS - Frontend software work on h1sush7, h1cdsh8 and h1oaf0. (The firmware on these three frontends will be downgraded to production standard and these computers will be power cycled.) Also adding strain relief - will isolate all corner computer systems to safe guard other work, 15 mins.
CDS - Implement the model changes needed for the strain gauge servos for ZM2, ZM4 and ZM5. This requires a model reboot of h1tcscs, as well as adding 3 channels to the copy guardian (Daniel)
09:00a -- SEI/SUS [CR] -- Measure HAM2ISI - PR3 cross-coupling. (Kissel) WP 12140
8am PSL - 1hr - Swap original NPRO controller back in since it didn't help glitches and has baggage (Ryan S)
9am - TCS - [CO2-Y Table] Take LVEA to laser hazard and prep for CO2Y swap. (Camilla) WP12121
9:30 - SQZ- beam profile of beam at pump ISS AOM, requires LVEA laser hazard (Sheila, Camilla) -- Postpwned
VAC - Filter Cavity Pump work end closest to FCES - FCT GVs closed near FCES
VAC - MY GV10 AIP work
SEI - HAM5 OLG script test (Ryan C, Jim) -- Postpwned
8h00 FAC - [ OSB R169] Disassembly/removal of old fume hood in the OSB Bake lab followed by any prep required for this space to be used differently. (T. Guidry, E. Otterman, C. Soike) WP12119 ????
FAC - DGR bringing EQ onsite, behind Staging Building ????
After others, check CR - Biergarten SEI Guralp sensor huddle tests - temp BNC installed there and R3 ????
---------------------------------------------------------------------------
General Notes:
Many ISI Trips on HAM2 and ITMY during maintenance.
Norco N2 Refill at Y arm side of CS at 17:35UTC
Relocking Notes:
I.A: Moved PR2 after marking old Osem values to get Xarm to find IR.
Moving IMs after marking Osem values to get xarm to find IR. Once I got IM4 close ALIGN_IFO Took over.
20:29UTC Initial_Alignment finished and Locking started.
Hard Drive Failure in H1Guardian Server Raid Array, CDS Team Hot Swapped a Guardian hard drive see alog.
Lockloss from OMC_WHITENING [591]
LOG:
| Start Time | System | Name | Location | Lazer_Haz | Task | Time End |
|---|---|---|---|---|---|---|
| 15:04 | FAC | Karen, Kim, Nelly | Ham Shaq | N | Technical cleaning | 17:04 |
| 15:05 | FAC | Christina | VPW | N | Forklifting | 17:26 |
| 15:08 | Vac | Janos | Mx | N | Pumping at MX and EX | 19:32 |
| 15:11 | PSL | Ryan | LVEA PSL Racks | N | Swapping PSL NPRO controller | 16:03 |
| 15:14 | VAC | Gerardo | LVEA | N | Getting cable from LVEA | 16:03 |
| 15:19 | TCS | Camilla, McCarthy | LVEA | N | Looking for parts | 16:03 |
| 15:31 | EE | Fil | PSL Rack & OutArm | N | Helping Ryan with PSL NPRO controller swap and Cable Trays near output arm | 16:44 |
| 16:09 | FAC | Karen, Kim, Nelly | EX, EY, HamShaq | N | Technical cleaning, Nelly out @ 16:47 | 17:44 |
| 16:17 | CDS | Dave & crew | Remote | N | DAQ Restarts & SUS model upgrades. | 17:07 |
| 16:18 | VAC | Travis, Jordan | HAM Shaq | N | Turbo Pump work | 18:11 |
| 16:25 | TCS | Camilla | LVEA | Yes | LASER HAZARD Transition! WP12121 | 16:32 |
| 16:26 | PR3 | Kissel | CtrlRm | N | Measure HAM2ISI - PR3 cross-coupling | 19:03 |
| 16:36 | SAFE | HAZARD | LVEA | YES | !!!!!LVEA IS LASER HAZARD!!!! | 03:16 |
| 17:07 | PSL | Jason & Ryan Short | LVEA | YES | adjusting injection currents | 17:54 |
| 17:45 | FAC | Karen & Kim | LVEA | Yes | Technical Cleaning, Karen Out 18:28 UTC | 18:39 |
| 17:55 | SAFE | Fire Alarm | Staging | N | Testing Fire Alarm functionality | 19:55 |
| 18:08 | PEM | Lance & RyanS | LVEA | Yes | Looking at PEM Coils | 18:20 |
| 18:33 | SEI | RyanC | ControlRoom | N | SEI HAM5 OLG script test | 19:08 |
| 19:01 | PSL | Ryan S | CtrlRm | N | Adjusting the PSL Rotation Stage | 19:16 |
| 19:16 | OPS | Camilla | LVEA | Yes | LVEA Sweep | 19:56 |
| 19:57 | EE | Fil | Mid Y | N | Picking up parts | 20:17 |
| 21:48 | PSL | Jason, RyanS | Optics Lab | YES | Working on new NPRO head | 00:48 |
| 22:04 | VAC | Janos | MidY | N | Checking Vac work at Mid station. | 22:17 |
| 22:16 | VAC | Gerardo | Mid Y | N | GB10 power supply swap | 22:53 |
TITLE: 10/15 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 14mph Gusts, 9mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.35 μm/s
QUICK SUMMARY:
IFO is in NLN and OBSERVING as of 23:14 UTC
Got into observing just now following a rough lock acquisition involving an EQ lockloss and an IM/PR misalignment (in turn related to SDF reversions and dolphin) that took some time to re-align.
Ibrahim, Oli
Below are updates and promising findings concerning the most recent BBSS LHO Top Mass -4mm BP Adjustments to tackle the F1 Drift issue summarized in alog 80577.
On Friday 10/11, Oli P and I moved the blade positions (mm BP Units) to:
Front Left: Side: 0.02, Top: -4.03 Back Left: Side: -0.03, Top -3.90 Front Right: Side: 0.02, -3.91 Back Right: Side: -0.05, -3.95 Avg: Side: -0.01 Height: -3.95
Find:
The good news is that with these 4.5 days of Data, we see no sign of F1 Drift.
We will post another alog with TF to model comparisons as we find which model d1 parameter fits these -4mm BP positions best.
That's good news! What is the configuration for the addable masses on the top mass for both the bottom and top plate?
The Addable Masses on the top plate were redistributed to the Front (top). 150g and 150g as shown in the attached image. No change to the bottom plate. We did not change the total mass.
Adding this Pitch Plot (which still shows no drift!) to give a measure of how much the diurnal moves day-to-day. Plot attached shows a max of 31.8 cts trough to peak max.
This is such that future drift measurements (e.g. at LLO) can try new configurations quickly and measure the prevailing drift without getting caught in the daily pitch breathing error.
In prep for heightened demand during the storage building construction, I ran the well pump today for 4 hours beginning at roughly 8:15am PST.
R. Short, J. Oberling
After the NPRO control box was swapped last week and glitches persisted (see alog80566), we decided it would be best to switch back to the original so that signal readbacks for the NPRO would be accurate. I started by bringing down the PSL in a controlled manner (ISS, FSS, PMC, AMPs, NPRO), then went out to the LVEA PSL racks and swapped control box S/N S2200008 for S2200009. Since this is the control box that had previously been in service with this NPRO laser head, no adjustments were needed to set the temperature and current to be correct. I returned to the control room and brought the whole system back up without issue.
Once it was time to lock the FSS, similar to what was needed with the last control box swap, I manually moved the NPRO temperature down about 0.4K (from 0.19 to -0.23) and locked the RefCav so that the SQZ laser would be happy. I then updated the FSS search parameters and accepted them in SDF (see screenshot).
As I noted in the 10-day trends yesterday (see alog80665), PMC REFL has risen over the past week, so I attempted a remote alignment tweak using the picomotors before the PMC. In the end, I wasn't able to make much of any improvement to the PMC alignment. I also attempted a remote alignment tweak for the RefCav, and here I was able to get a slight improvement from 0.80V to 0.81V on the TPD.
Looking for more things to try to impact the laser glitching and hopefully bring down the amount of PMC reflected power, Jason and I returned to the PSL racks to try adjusting the NPRO pump current. We ultimately raised the current from 2.12A to 2.19A, increasing the NPRO output power from 1.82W to 1.91W according to the PD in front of the laser, but not having much of an impact on the PMC. We also tried slightly altering pump diode currents in the amplifiers, but we didn't see any improvement, so these remain as they were.
I concluded our PSL activities today with a rotation stage calibration following the steps in alog79596. The measurement file, new calibration fit, and screenshot of accepting SDFs are attached.
| W (Max power in) | D | B (Min power angle) | C (Min power in) | |
| Old Values | 94.642 | 1.990 | -24.794 | 0.000 |
| New Values | 91.236 | 1.990 | -24.797 | 0.000 |
Original NPRO injection current was 2.133 A, and the new injection current is 2.193 A.
WP12131 h1tcscs model, add FMs and Voltage slow channels
Daniel, Vicky, Dave:
A new h1tcscs model was installed when h1oaf0 was rebooted this morning. DAQ restart was required, the addition of 51 slow channels.
WP12132 New Dolphin adapter card Firmware.
Keith, Jonathan, Erik, EJ, Tony, Dave:
Downgraded firmware was loaded onto the Dolphin IX-611 adapter cards in h1sush7, h1cdsh8 and h1oaf0. This is to prevent sponteneous PCI level switching which is possibly the cause of some O4 cornerstation Dolphin glitches.
Procedure was:
WP12134 DAQ Restart Script, Restart rts-nds.service
Jonathan, Erik, Dave:
To prevent /run/nds/jobs filling, the scripts to restart the DAQ was modified to restart the rts-nds.service on the nds machines as well as restarting their rts-daqd.services.
This allows systemd to empty the /run/nds/jobs directory, which was over 50% full on h1daqnds1. We tested this as part of this morning's DAQ restart, it worked well.
WP12087 Add VACSTAT gauge PVs to DAQ
Dave:
My first attempt to add the VACSTAT PVs relating to vacuum gauge monitoring failed because the channel names exceeded the DAQ length limit of 54 characters.
I modified the VACSTAT code to drop the _PRESS_TORR from the PT channels names, which allowed these channels to be added to the DAQ.
A new H1EPICS_VACSTAT.ini file was created which added 368 channels to the EDC. DAQ and EDC restart was needed.
The new VACSTAT IOC was restarted, and the new MEDMs installed into production.
WP12143 Replace failed SDD in h1guardian1
Dave, Jonathan, Erik:
cds_report reported a failed disk in h1guardian1's md3 raid at noon today. Jonathan and Erik found a failed 230GB SDD which is part of the root file system on h1guardian1. It was replaced with a 1TB SSD (the smallest we have), resyning the new disk only took about an hour.
DAQ Restart
Jonathan, Erik, Dave:
We restarted the DAQ for the addition of h1tcscs slow channels and the new VACSTAT EDC channels. EDC was restarted, its channel count increased from 57061 to 57429.
This was the first test of the new restart script, which after doing the round of rts-daqd restarts then restarts rts-nds on the nds machines.
The only problem was a spontaneous retstart of framewriter 1 after it had written about 3 full frames. It came back by itself and has been stable since.
Tue15Oct2024
LOC TIME HOSTNAME MODEL/REBOOT
08:20:39 h1sush7 ***REBOOT*** <<< Dolphin firmware install
08:22:27 h1sush7 h1iopsush7
08:22:40 h1sush7 h1susfc1
08:22:53 h1sush7 h1sussqzin
08:23:06 h1sush7 h1susauxh7
08:32:25 h1cdsh8 ***REBOOT*** <<< Dolphin firmware install
08:34:17 h1cdsh8 h1iopcdsh8
08:34:30 h1cdsh8 h1isiham8
08:34:43 h1cdsh8 h1susfc2
08:34:56 h1cdsh8 h1sqzfces
08:35:09 h1cdsh8 h1susauxh8
08:35:22 h1cdsh8 h1pemh8
08:38:04 h1oaf0 ***REBOOT*** <<< Dolphin firmware install
08:39:45 h1oaf0 h1iopoaf0
08:39:58 h1oaf0 h1pemcs
08:40:11 h1oaf0 h1tcscs <<< New h1tcscs model install
08:40:24 h1oaf0 h1susprocpi
08:40:37 h1oaf0 h1seiproc
08:40:50 h1oaf0 h1oaf
08:41:03 h1oaf0 h1calcs
08:41:16 h1oaf0 h1susproc
08:41:29 h1oaf0 h1calinj
08:41:42 h1oaf0 h1bos
09:04:44 h1daqdc0 [DAQ] <<< DAQ 0-leg restart
09:04:57 h1daqfw0 [DAQ]
09:04:57 h1daqtw0 [DAQ]
09:04:58 h1daqnds0 [DAQ]
09:05:06 h1daqgds0 [DAQ]
09:05:26 h1susauxb123 h1edc[DAQ] <<< EDC restart for VACSTAT chanels
09:11:01 h1daqdc1 [DAQ] <<< DAQ 1-leg restart
09:11:13 h1daqfw1 [DAQ]
09:11:14 h1daqnds1 [DAQ]
09:11:14 h1daqtw1 [DAQ]
09:11:22 h1daqgds1 [DAQ]
09:15:52 h1daqfw1 [DAQ] <<< Spontaneous restart of FW1 DAQD
(Dave, Vicky, Daniel)
The necessary filter modules for the ZM2/4/5 strain gauge servos were booted into the h1tcscs model, and the medm updated. We added some channels to the copy guardian, since the strain gauge channels are acquired in the TwinCAT system. The new filter modules were loaded with a -1/f filter and then engaged with a gain of 1. The output limiter were set to 50V.
We played around with the new servos by stepping the target strain gauge settings. The response time seems to be about 7-8 sec. All working fine.
So when running the PSAMS servo, to change PSAMS ROC, set H1:AWC-ZM{2,4,5}_M2_STRAIN_VOLTAGE_TARGET instead of adjusting the applied voltage offset slider H1:AWC-ZM{2,4,5}_M2_SAMS_OFFSET.
Attaching some trends of the PSAMS servo working overnight -
Screenshot 1 - For ZM4, servo filter bank settings and ndscope trends of a step in the servo setpoint. The PSAMS servo output adjusts the applied voltage (see PZT DC voltage readback, eg H1:AWC-ZM4_PSAMS_VOLTAGE_DC) to bring the strain gauge voltage readback (H1:AWC-ZM4_PSAMS_STRAIN_VOLTAGE) to the target setpoint voltage (H1:AWC-ZM4_M2_STRAIN_VOLTAGE_TARGET).
Screenshot 2 - ZM2,4,5 PSAMS strain gauge voltage trends before/after servo. Before PSAMS servo (last few days) - the applied PSAMS PZT voltage is static, and the PSAMS strain gauge voltage readbacks drifts (small amount). After turning on PSAMS servos, the applied PSAMS PZT voltages are servo'd to stabilize the strain gauge readbacks to the "TARGET" values.
Screenshot 3 - ZM5 suspension MEDM screen, showing where the PSAMS servo filter bank and target setpoints are. This ZM5 suspension medm screen is in $(userapps)/sus/common/medm/hxds/SUS_CUST_HPDS_OVERVIEW.adl (Sheila helped us svn-commit this screen from LLO, then Daniel pulled it for use at LHO).
Daniel updated the PSAMS servo parts in the AWC block of h1tcscs.mdl, found in userapps/trunk/tcs/h1/models. The SDF's appeared in the h1tcscs table (in the "OAF" box on the sdf screen). Daniel has sdf-monitored the PSAMS filter banks, and left the ZM PSAMS PZT offsets sdf-monitored. Note these pzt offset values are basically meaningless when the servo is running. The ZM2/4/5 offsets are now all SDF'd around 100V, so they would come back to ~nominal values after any resets.
This follows up on Adam's llo73464 "Adding SAMS servo to HPDS common part" (from LLO: WP 11839, IIET ticket 32287, and ECR E2400361) to pull the psams servo for LHO.
TITLE: 10/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Aligning
OUTGOING OPERATOR: TJ
CURRENT ENVIRONMENT:
SEI_ENV state: CALM
Wind: 4mph Gusts, 3mph 3min avg
Primary useism: 0.03 μm/s
Secondary useism: 0.38 μm/s
QUICK SUMMARY:
When I Arrived ISC_LOCK was in Inintial_alignment, Init_Align was in Locking Green Arms, and ALSY arm has no light on it.
Last lockloss was 2024-10-15_13:01:37Z ISC_LOCK NOMINAL_LOW_NOISE -> LOCKLOSS
TJ Said he got called by H1 Manny just before 7:30.
I will be running Oli's script as described in Alog 76606 to save all slider values before the CDS team does their DAQ Restart thing.
Output of Oli's script:
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py
No optics or groups entered. -h or --help to display opt-ions.
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -h
usage: update_sus_safesnap [-h] [-p] [-o [OPTICS ...]]
Reads the current OPTICALIGN_{P,Y}_OFFSET values and uses those to overwrite
the OPTICALIGN_{P,Y}_OFFSET values in the burt files linked from their
respective safe.snap files.
options:
-h, --help show this help message and exit
-p, --print-only Use -p or --print-only to only print the beforeand
after values without updating the values saved in
safe.snap. (default: False)
-o [OPTICS ...], --optics [OPTICS ...]
Type the names of optic groups (ex. itm) or individual
optic names (ex. pr2), with spaces in between. Case
does not matter.
OptGroup | Optics OptGroup | Optics
itm ITMX etm ETMX
ITMY ETMY
bs BS tms TMSX
TMSY
rm RM1
RM2 pr PRM
PR2
im IM1 PR3
IM2
IM3 mc MC1
IM4 MC2
MC3
sr SRM
SR2 ifo_out OFI
SR3 (om if w/o OFI) OMC
OM1
fc FC1 OM2
FC2 OM3
zm_in OPO zm_out ZM4
ZM1 ZM5
ZM1 ZM6
ZM3
(default: none)
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o itm bs rm im sr fc zm_in etm tms pr mc ifo_out zm_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
ITMX ITMY BS RM1 RM2 IM1 IM2 IM3 IM4 SRM SR2 SR3 FC1 FC2 OPO ZM1 ZM2 ZM3 ETMX ETMY TMSX TMSY PRM PR2 PR3 MC1 MC2 MC3 OFI OMC OM1 OM2 OM3 ZM4 ZM5 ZM6
Traceback (most recent call last):
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 318, in <module>
old_new = replace_offsets(opt_dicts(optics), print_only=print_only)
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 201, in replace_offsets
cur_vals.append(ezca[pchanname])
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 304, in __getitem__
return self.read(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 294, in read
pv = self.connect(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 272, in connect
raise EzcaConnectError("Could not connect to channel (timeout=%ds): %s" % (self._timeout, name))
ezca.errors.EzcaConnectError: Could not connect to channel (timeout=2s): H1:SUS-OFI_M1_OPTICALIGN_P_OFFSET
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o zm_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
ZM4 ZM5 ZM6
SUS-ZM4_M1_OPTICALIGN_P_OFFSET
Old Saved: -7.92342523045482380439e+02
New Saved: -772.2246009467159
SUS-ZM4_M1_OPTICALIGN_Y_OFFSET
Old Saved: -9.85740674423158566242e+02
New Saved: -981.3613025567112
SUS-ZM5_M1_OPTICALIGN_P_OFFSET
Old Saved: -1.15000000000000000000e+02
New Saved: -115.0
SUS-ZM5_M1_OPTICALIGN_Y_OFFSET
Old Saved: -4.60000000000000000000e+02
New Saved: -460.0
SUS-ZM6_M1_OPTICALIGN_P_OFFSET
Old Saved: 1.39848934620929139783e+03
New Saved: 1408.6829424213722
SUS-ZM6_M1_OPTICALIGN_Y_OFFSET
Old Saved: -2.83802124439147348767e+02
New Saved: -260.05899996129443
anthony.sanchez@cdsws29: python3 update_sus_safesnap.py -o ifo_out
Running $(USERAPPS)/isc/h1/guardian/update_sus_safesnap.py
Updating and printing out saved OPTICALIGN_{P,Y}_OFFSET values from safe.snap vs current values for these optics:
OFI OMC OM1 OM2 OM3
Traceback (most recent call last):
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 318, in <module>
old_new = replace_offsets(opt_dicts(optics), print_only=print_only)
File "/opt/rtcds/userapps/trunk/isc/h1/scripts/update_sus_safesnap.py", line 201, in replace_offsets
cur_vals.append(ezca[pchanname])
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 304, in __getitem__
return self.read(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 294, in read
pv = self.connect(channel)
File "/var/opt/conda/base/envs/cds/lib/python3.10/site-packages/ezca/ezca.py", line 272, in connect
raise EzcaConnectError("Could not connect to channel (timeout=%ds): %s" % (self._timeout, name))
ezca.errors.EzcaConnectError: Could not connect to channel (timeout=2s): H1:SUS-OFI_M1_OPTICALIGN_P_OFFSET
anthony.sanchez@cdsws29:
That error to my update_safe_snap script shouldn't happen again - I had put the OFI as an option in there for overwriting the OPTICALIGN offset settings, but it turns out that the OFI doesn't have opticalign offsets! Neither does the OPO, so I've removed both of those from the code.
It seems to now be working correctly (but it's tricky to test) so hopefully there are no more issues with running it.
