I've installed a Welch WOB-L 2546B-01 at each end station to replace the Gast 523 pumps that we have been using. I've set the pressure to -19inHg and checked the flow at the dust monitor on the floor was 2.8L/min. The new pumps are much quieter, ~84dB vs ~67dB, but at a lower frequency. I'll post more photos of the setup and more details tomorrow after we see how they run over night.

Following the Beckhoff updates today (see alog88317), several settings needed to be restored in CS_ISC, EX_AUX, and EY_AUX after the initial SDF wrangling that was done after all the upgrades were finished.

As a reminder (for myself and others), when a Beckhoff computer is restarted, its settings are brought back up according to an internal settings file on that computer, NOT according to the safe.snap SDF table, unlike a traditional frontend model. This means the SDF tables for the restarted Beckhoff computers (basically anything with SYS in the name) will show several differences, that in most cases should be REVERTED. It's also useful to check the not monitored channels for differences, as we found a few of those today, although they were mostly just picomotor settings. See attached screenshots.

TITLE: 12/02 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

Main activity of the day was the the SUS DAC swap at EX (with the addition of more CDS work at both end stations as well).

In parallel, there was also crane inspection work which initiated gate valve closures due to loads needing to be craned over the beam tubes in the LVEA.  Then in the afternoon, it was decided to open the gate valves for locking (so we could see how the End Stations looked after their big changes today).

      [Through today's recovery to relocking, there were several items which needed to be done.  Had much help from many who made recovery fairly easy **knock on wood**.]

Towards the end of the shift, able to see light flashing in the arms, and started an Initial Alignment (one gotcha was during Scan Alignment of Green Arm alignment which made the ALSx + y guardian nodes red---Ryan and Oli were on top of it and able to get alignment back.  Other than that, alignment completed with no other issues.  Moved on to locking and locked DRMI pretty fast on the first attempt....unfortunately there was a lockloss at DHARD_WFS.

NOTES:

• Not totally sure of where we want to leave H1 for the night.  There may be other people on-site to babysit for a bit (currently, I'm leaving H1 as it is trying to lock (had DRMI lockloss for a 2nd time post today's big day).  Ryan & Oli happen to be here to babysit, but if H1 isn't locked after the last operator leaves, ISC_LOCK should be taken to DOWN!
• DIAG MAIN has the following note:  "HWS:  HWS code stopped for ITMy"
• VIOLIN_DAMPING is also in PAUSE (as was the case yesterday)
• PCal also having issues, but Tony is looking at that with Dave

LOG:

• 1556-1711 EX (kim) & EY (nellie) & then both at FCES technical cleaning
  • 1730-1858 lvea clean (nellie.kim)
• 1610 lvea wifi turned on...since no more observing, keeping ON + turned on mid stations
• 1610 Crane inspection crew begins (will wait on Gate Valves) (randy, tyler)
  • In the afternoon, started moving down the X-arm & Y-arm (randy, tyler)
  • 2359 Back at Corner (done?)
• 1610 LVEA GateValves closed:  GV5, GV7, FC-GV (jordan, travis)
  • 1625 AIP & pressure alarm handler alarms
• 1614-1800 Norco LN2 truck#1 to MX cp6
• 1616 EX SUS DAC swap begins (jeff, dave, fil, jonathan)
  • EX hardware work completed
• 1700-1822 Pest control (chris)
• 1704-1801 Exit sign install near CER (eric)
• 1732-1742 PCal sphere swap (tony)
• 1749-1831 firmware timing at EX (marc, jonathan)
• 1749-1800 refcav alignment touch-up (jason)
• 1750 testing opo (KarMeng)
  • 1755-1804Looking for power supplies in lvea (kar meng.sheila)
•  1751-1759 moving jac stuff in optics lab (jennie.betsy)
• 1757-1835 checking on crane crew & 3ifo checks (tyler)
• 1758-0007 ey purge air test/check (jordan, gerardo)
  • 2317 Ending purge air test (jordan, travis)
• 1822-2001 Norco LN2 truck#1 to EX cp8
• 1829-1951 dustmon pump tests (tj)
  • 2106-2130 Cont after lunch & then a meeting (tj)
  • 2236-2325 Back to EY to finish (tj)
  • 2327-0026 EX to turn on new dustmon pump (tj)
• 1850-1935 firmware timing at EY (marc, jonathan)
• 1935-2017 Firmare timing at MX, MY (marc, jonathan)
• 1945 Verbal reminder for sweeping lvea!
• 1949:  Got word from Tyler gate valves can open (heavy loads over beam tubes complete, but still doing other work and want to see if if it's worth it to keep them closed a bit longer)
• 2006-2037 LVEA walkthru (betsy, travis)
• 2121-2044 crane assistance in lvea (tyler)
• 2132 Beckhoff work (daniel)
• 2155-2335 Magnetometer check in CER (alicia)
• 2158 OPO work cont. (Kar Meng, Eric)
  • 2231 Kar Meng out & laser SAFE for Eric
  • 2334 Eric out
  • 2355 OPO tests continue + laser HAZARD (KarMeng.Eric)
• 2234 Gate Valves opening (travis, jordan, gerardo)
• 2236-2320 cheta enclosure work (matt)
• 2336 Taking photos of SUS racks (dave)
• 2340 Initial Alignment started 
  • Scan Alignment had error & need ALS restarts (oli took care of this)
• 2351-0028 Moving magnetometer & its cable (alicia, rene, sam)

GV5 and GV7 were soft closed at ~8:30am local time today to facilitate equipment craning for crane inspections. We also closed FC-GV 3&5 to isolate the FCT.  They were opened at ~3pm local time at the completion of the vertex crane inspection.

Closing WP 12908

J. Kissel, D. Sigg, D. Barker
ECR E2100485
ECR E2200401
WP 12901

Continuing on the deprecation of 18-bit DAC path (ECR E2100485), we upgraded the h1iscex's DAC0 card today from an 18- to a 20-bit DAC. One of the front-end models that use that DAC is the h1pemex model.

Here's the before vs. after for the models. While there, I found and left the new ADC card from ECR E2200401's PEM sensor array expansion. I'd thought it was installed solely for characterizing the 32CH LIGO DAC, but it had only been temporarily used for that. It should be there! And also, the electric field meter ADC should also remain there.

If the PEM team wants to account for the factor of 4x gain change in the DAC calibration, I installed new DACOUTF filters upstream of the GDS filters that are used to drive the DACs.

The model has been committed to
    /opt/rtcds/userapps/release/pem/h1/models/
        h1pemex.mdl : r28026 --> r34059

Same as 88289, we updated the DACs for ETMX and TMSX, so we needed to update the calibration gain to account for the difference in bits. I added 28BitDAC calibration gains for ETMX M0/R0/L1/L2/L3 and TMSX M1 in COILOUTF FM10 and got rid of any lingering 20BitDAC filters. I did the same for ETMX PI. I loaded these filters in and turned them on, and accepted them as on in sdf safe

Tuesday Maintenance day impact notes.

Due to Beckhoff upgrades and restarts the PCAL lasers were shutoff.
When Beckhoff came back up the PCAL Lasers oddly didn't come back up this time.
The H1:CAL-PCALX_LASERPOWERCONTROL voltage was set to 0. I took that back to 5V for both arms.
Turned H1:CAL-PCALX_LASERENABLE back on. 
H1:CAL-PCALX_SHUTTERPOWERENABLE back on.

Arm specific Settings : 

PCALX: 
H1:CAL-PCALX_OPTICALFOLLOWERSERVOOFFSET was set back to 3.65V. 
H1:CAL-PCALX_OPTICALFOLLOWERSERVOGAIN : 39.60 dB

PCALY: 
H1:CAL-PCALY_OPTICALFOLLOWERSERVOOFFSET : 3.80 V
H1:CAL-PCALY_OPTICALFOLLOWERSERVOGAIN : 38.56 V

Hey future Tony,  Today is the day the X Arm 18bit DAC was changed out for a 20bit as well.
 

We switched to the spare slow controls computer that is running Windows 10 IoT Enterprise LTSC, 21H2 (OS build 19044.4780), and the most recent TwinCAT 3.1 (4026.19.0). This TwinCAT version uses a packet manager and has changed the install directory to C:\Program Files (x86)\Beckhoff\TwinCAT. It supports Visual Studio 2022 and the new Altium workflow. 

One new "feature" is that the PLC boot project needs to be activated in a separate step (previous versions would do this automatically after a build). We updated the install scripts to accommodate this.

We also tried a new TcIoc that was linked against EPICS 7, but it crashed during SDF restore repeatedly.  We reverted back to the previous version linked against 3.15.9.

Per WP12909 we updated firmware on the PCIe Timing Cards at EX, EY, MX, and MY, sticker applied to each updated chassis.

EX:
H1-SUSAUX-EX-V5 (S1103885) with timing card (S2101138) firmware updated
H1-SUS-EX-V5 (S1900326) with timing card (S2101152) firmware updated
H1-SEI-EX-V5 (S1900235) with timing card (S2101093) firmware updated
H1-ISC-EX-V5 (S1900329) with timing card (S2101158) firmware updated

EY:
H1-SUSAUX-EY-V5 (S1103621) with timing card (S2101168) firmware updated
H1-SUS-EY-V5 (S1900238) ** Timing Card Replaced Monday ** applied updated sticker to chassis.
H1-SEI-EY-V5 (S1900231) with timing card (S2101173) firmware updated
H1-ISC-EY-V5 (S1900237) with timing card (S2101109) firmware updated

MX:
H1-MX (S1105017) with timing card (S2101151) firmware updated

MY:
H1-MY (S1103622) with timing card (S2101085) fimrware updated

D. Barker, F. Clara, J. Hanks, R. McCarthy, M. Pirello, D. Sigg

Attached are monthly TCS trends for HWS & CO2 lasers.  (FAMIS link)

For FAMIS #27646: All fan trends look nice and flat!

After the DACs were upgraded at EndY alog88274, I've updated SATMON.adl for ETMY (M0, L1, L2, L3), and TMSY (M0). I had to add a new item to the legend on the bottom right for the 28bit levels. 

Closes FAMIS#27537, last checked 88075
This is being compared to two weeks ago (FAMIS#27534) since it didn't run correctly last week.

Observations
- All HAMs except HAM7, and all CS BSCs ST1 - V1/V2/V3 all look a bit extra noisy between 6.5-9 Hz, but it's not the worst and I assume is probably due to local ground motion. 

- Nothing else looks weird

J. Kissel, E. Capote, J. Betzwieser

Today, I turned OFF the 1153.2 Hz PCALY Calibration Line by changing the frequency and amplitude to 0.0, and turning off the corresponding element in the OSC SUM matrix. 
    $ caput H1:CAL-PCALY_PCALOSC9_OSC_FREQ 0.0
    $ caput H1:CAL-PCALY_PCALOSC9_OSC_SINGAIN 0.0
    $ caput H1:CAL-PCALY_OSC_SUM_MATRIX_1_9 0.0

I've saved those settings in the OBSERVE / safe.snap SDF files to make that stick (they're the same file, soft-linked together).

Context
This line has been on consistently throughout O4, at the same frequency with no change in amplitude -- but never used for any science; t'was just eating up PCAL range. And now the REST of the story... In O3, the PCAL team began prototyping a constant comparison between PCALX and PCALY in order to determine \chi_{XY} . On Sep 11 2019, we turned on a line at 1153.1 Hz
at both end-stations with opposite sign forming a "canceling line" (LHO:51915). Realizing that a truly canceled line has no SNR above the DARM noise to make any statistically significant statement, they moved to 395.1 Hz for a minute (LHO:53259). Then, they finally tried separating them near the end of O3 at 1153.1 and 1153.2 Hz lines on PCALX and PCALY respectively (LHO:54876). Finding they still needed more SNR, they moved the comparison briefly down to 530.2 and 530.1 Hz (LHO:54868); this became the final measurement for P2000113), and then returned them to former frequencies of LHO:54868 on 2023-03-03 (LHO:55386)... and then we just never turned off the PCALY portion #globalpandemicwhoops. The corresponding PCALX portion, at 1153.1 Hz, was unceremoniously turned off without aLOG on a Thursday afternoon between O3 and O4, at 2022-12-08 22:29 UTC (14:29 PDT).

The RefCav reflected spot looked off this morning and the trends Ryan posted yesterday showed a large drop in RefCav TPD, so I tweaked the beam alignment into the RefCav from the Control Room; this was done with the ISS ON and the IMC unlocked.  When I started the TPD was ~0.473 V, and when I finished the TPD is ~0.518 V.  This isn't as high as we have been (~0.55 V), so this is an indication of another misalignment on the PSL table (most likely the double-pass AOM, which is our usual culprit for on-table alignment work).  We're not too far down right now and we are not consistently observing, so we will continue to monitor as usual and will do an on-table alignment should the TPD continue to drop.

Closes FAMIS#37211, last checked 87059
 
HPI-PUMP_L0_CONTROL_VOUT has been trending up for the past ~2 weeks.
All other HEPI pump trends looking as expected.

J. Kissel
ECRs: E2400409 and E2500296
IIET: 35739 and 35706, respectively
WP: 12901
DWG: D1002741

This morning, I updated the front-end user models for the X end station -- h1susetmx, h1susetmxpi, and h1sustmsx -- leveraging all the work and gotchas from yesterday's 32CH DAC upgrade of the Y-end station front end models (Primary models LHO:88280, Inconsequentially Updating Libraries LHO:88283, and Adding DAC compensation filters to the ETM PI library part LHO:88285). The good thing about having the end-stations use identical wiring diagrams means that I can literally copy and paste the digital representations of the DAC connections and cards. I've confirmed that the library part change to the ETM PI library correctly updated in the h1susetmxpi model without effort. The only "difference" was that the top level of the ETMX QUAD model, h1susetmx, had all of the messy prototyping pick-off infrastructure for the early 32CH DAC testing which can now all be ripped out and made to look clean and simple like ETMY's. 

I attach before vs. after screenshots for posterity. 

The revisions of the models that have been successfully compiled:
    /opt/rtcds/userapps/release/sus/h1/models/
        h1susetmx.mdl         r28431 --> r34046        BEFORE vs AFTER
            sus/common/models/ESD_LINEARIZATION_WITH_CHARGE_MASTER.mdl : r16336 --> r30316
        h1susetmxpi.mdl       r27215 --> r34048        BEFORE vs AFTER
            sus/common/models/PI_MASTER_V2.mdl : r26600 --> r34033
        h1sustmsx.mdl         r27182 --> r34050        BEFORE vs AFTER

And as before, I also attach a screenshot of the usage of DAC0 and DAC1 across front-end models. Today I decided to be a little more color-coded with my notes on channel usage; red for consumed/reserved in other models, orange for actually physically unused.

It was time to update the leap seconds file on some infrastructure systems, our famis task came due.

Debian 11 hasn't updated the tzdata package yet, and it expires end of this month.

I updated the leapseconds database on

h1daqdc0
h1daqfw0
h1daqnds0
h1daqtw0
h1daqgds0
h1daqdc1
h1daqfw1
h1daqnds1
h1daqtw1
h1daqgds1
h1fs0
h1fs1
h1hwinj1
h1hwsmsr
h1hwsex
h1hwsey
h1fescript0
h1guardian
h1vmboot5-5 (and its diskless root)
cdsfs0
cdsfs1
cdsfs2
cdsfs3
cdsfs4
cdsfs5
h1digivideo2

Link to the last time we did this: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=85270

[Jenne, Oli]

I'm intermittently, while we're locking, seeing some fuzziness on the ETMY oplev (first 2 attachments, with 'fuzzy'). Oli did a brief check, and while they find a different behavior that is present 4 days ago and today (3rd and 4th attachments, with 'drop'), at least a quick glance isn't finding the fuzziness that I'm seeing. We haven't looked at enough past data to say whether this is new, but it doesn't seem to be hindering our ability to lock, so I think we're fine to go forward with ETMX tomorrow.

J. Freed,

I took Phase noise measurements of the 2 channel Keysight 33600A waveform generator for its use in building SPI Pathfinder in the optics lab before install. Going only off of the phase noise graphs, it is sufficient as it shows comparable results to the SRS which had a phase noise considered to be good enough for SPI pathfinder.

Key.png Shows the phase noise results. C1, C2 are the phase noise results for Channel 1 and Channel 2 on the Keysight, respectively. (Set up shown below). Shown for comparison the SRS SG392, which was suggested as a possible frequency source for SPI. The last measurement shown is the direct measurement of phase noise between the 2 channels of the Keysight. This measurement reflects the intended use case of the Keysight for SPI. As we need 2 frequencies at slightly different frequencies locked to each other and SPI will be measuring the output phase difference. Note the 60Hz peak; most likely caused by unclean AC power. This is why we are not using an AC powered device in the final installation. 

Screenshot2025-12-01at50150 PM.png Shows the setup for C1, and C2. measurements. The SRS value was found with the same set up, just replacing the Keysight 33600A with a SRS. The C1-C2 is a direct measurement by plugging both channels into the BluePhase 1000. There is no 10MHz Ext back attachment in this measurment in order to best represent Keysight's theoretical performance in the optics lab.