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

TITLE: 12/02 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 2mph Gusts, 1mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.30 μm/s 
QUICK SUMMARY:

H1's been locked 13.5+hrs with a range hovering around132Mpc and no squeezing.  There was a minor optics dust alarm at around 534amPDT (cleared in 10min).

[RyanS, Oli, Jenne, Jeff]

Locking went well, and we're currently at NomLowNoise (no squeezing though).  We're good to go for swapping the Xend DACs tomorrow.  

SRC1 during DRMI ASC seems to pull things away at the last little bit rather than converging, so we've been turning it off by hand.  If it's still being problematic when we next try to lock (tomorrow? or Wed?), then we should set it to False in the DRMI guardian. 

We also turned SRC1 off in full ASC during our first lock attempt, since it seemed to be wandering off.  But, we lost lock in MOVE_SPOTS, probably because we weren't by-hand making the SRM follow along (since the beam diverters were closed so we didn't really have anything to track with).  Second lock I left SRC1 on in full ASC, and things went fine and we got all the way to NLN.

The squeezer guardian is stuck in LOCK_OPO.  I tried once setting the SQZ_MANAGER to DOWN and again to FREQ_DEP_SQZ, but it's still not happy.  Since this is not what we were trying to test today (we were just seeing if the Yend DAC swaps worked), I'm just leaving the SQZ_MANAGER in DOWN.

We did, at Jeff's suggestion, have the VIOLIN_DAMPING guardian paused, since we didn't want to do bad things to violin modes if there was a big phase change with the new DAC.  However Daniel estimates that we should see about a 10 degree phase shift at 1kHz, and a much smaller shift at 500 Hz, so I've just unpaused that guardian and the modes seem to be damping fine. 

I am leaving the IFO locked, but requested ISC_LOCK to DOWN, so that if it does lose lock, it won't try to re-lock.  This, and the lack of squeezing, means that I am not setting the Observing bit.

[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.

Richard, Jonathan, Fil, Marc, Daniel, EJ, Jeff, Oli, Ryan S, Dave:

h1susey was upgraded from Gen Std DACs (3x18bit, 2x20bit) to 2 LIGO-DACs.

Fil upgraded the three AI chassis to use the new SCSI interface board.

We removed the old Gen Std DACs and installed the two new LIGO-DACs.

The first LIGO-DAC drives the first standard AI, which in turn daisy-chain drives the second standard AI.

The second LIGO-DAC drives the special PI AI chassis.

After the hardware was changed the new h1iopsusey, h1susetmy, h1sustmsy and h1susetmypi models were rev-lock built and installed. A common model change for h1susetmy was accepted for its build.

EJ did a custom build for h1iopsusey due to rev-update issues found for watchdog source files. The user models were built with the production RCG-5.5.2

Following the model starts, the DAQ was restarted for new INI files due to removed DACs in h1iopsusey and h1susetmy.