Shoshana, Michael, Jeff, Tony

We spun the NCal as a life check while we were on site. At first the NCal wouldn't turn on and threw a 'NCal power' error. Power-cycling the motor power by replugging the AC cable running to the Beckhoff motor controller (black cable coming from the left in attached picture) fixed the error. We spun the rotor up to 10 Hz for a few minutes before spinning it down.

NCal Settings:

Motor Frequency Request: 1040 ct

Motor Ramp Gain: 0.01

Motor Low Pass Time Constant: 5

TJ, Camilla, Sheila

TJ and Camilla got the HWSs working, and now we turned on the SR3 heater at 15:54 UTC, 2W requested power.  This is to do a check of the SR3 heater calibration and range similar to 27262

(CoreyG, MitchR, RandyT)

This morning, Randy watered down the sand roads.  Later, Mitch & Randy swapped in the new (& better) rigging hardware for the Wind Fence on all the big poles.  

This afternoon, 2 (of5) horizontal cables were installed at Location #4 (of 6).

And of course a new bee hive was observed.  This one is up in the Wind Fence vicinity, and is forming on....a tumbleweed!  Tyler was notified and he checked it out.

Next up is continuing to install horizontal cables at location #4, 5, & 6.  Then panel install and securing panels.

Closes FAMIS26511, last checked in alog82660

The lack of switching recently is due to the vent, but they all show switches during the last quarter.

[Sheila, Elenna]

Alog 84230 contains an extensive report of the beam profile measurements in HAM1 along the REFL path. Keita did a fit of the measurements along the WFS sled to determine that the gouy phase separation of the REFL WFS is good. I have now taken all the data, starting just before RM1 through the WFS sled measurements and run a fit.

Looking back at T1300960, which does a similar fit model from the measurements in the REFL path, there is some confusion about what the input q to HAM1 is, and this resulted in some doubt about the radius of curvature of both RM1 and M5, whose design specs are 1.7 m. That code uses RoCs that are 1.75 m for each mirror, which Sheila and I think is a bit far out of the range of the specification (see E1100056).

There is a total of 8 measurements, four taken around the WFS sled and four taken around the RM1-RM2-M5 area (a ninth measurement of the beam size at the LSC REFL diodes is not included). I added these measurements to the model, as well as RM1, RM2, M5, L101 and L102. I ran a fit based on these components and the beam profile measurements.

The beam path results are shown in this first plot, where RM1 and M5 RoC are set to 1.7 m (as in spec). The astigmatism shows waists upstream of RM1 are separated by over 1 m. I color coded traces for horizontal and vertical, and o's and x's mark the measurement locations that were fit. However, I didn't include any angle of incidence in this calculation, which would probably adjust this result slightly (it appears the AOIs are probably 10 degrees or less). For completeness, I also included the results if we assume the RM1 and M5 RoC are 1.75 m, in this plot. In this result, the upstream waists are 2 m apart.

For both fits, I used the qs that Paul and Lisa calculated as the seed qs in T1300960. Sheila and I are in the process of confirming these qs by doing the beam propagation of the IMC waist to the HAM1 table. To clarify, a la mode forces you to supply some input seed beam for propagation and fitting, so I supplied this seed, since you want to use something you think is pretty close to the true value. However, it only uses that seed as a starting point and then fits the data points supplied. The resulting incoming beam to RM1 is fit as:

horizontal = waist 1.60 mm, 6.4 m upstream of RM1 (RM1 RoC 1.7 m)

vertical = waist 1.52 mm, 7.5 m upstream of RM1 (RM1 RoC 1.7 m)

or

horizontal = waist 1.99 mm, 2.07 m upstream of RM1 (RM1 RoC 1.75 m)

vertical = waist 2.06 mm, 4.2 m upstream of RM1 (RM1 RoC 1.75 m)

The code I wrote is attached to this alog. Below are tables of the beam profile measurements (copied from 84230), and the specs of the mirrors and lenses I used.

FAMIS 26408 - PSL Weekly Check
Laser Status:
    NPRO output power is 1.849W
    AMP1 output power is 70.39W
    AMP2 output power is 140.6W
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN
    PDWD watchdog is GREEN

PMC:
    It has been locked 0 days, 2 hr 14 minutes
    Reflected power = 23.66W
    Transmitted power = 105.4W
    PowerSum = 129.0W

FSS:
    It has been locked for 0 days 0 hr and 3 min
    TPD[V] = 0.7928V

ISS:
    The diffracted power is around 3.4%
    Last saturation event was 0 days 2 hours and 13 minutes ago

Possible Issues:
    PMC reflected power is high

Fil, Rahul

This morning we finished ground loop checks on HAM1 chamber, since Jim was done with final cabling work. The only grounding issues we found were in RM1 and PM1, hence we removed pin1 from the in-air cable (connecting Satamps).

Thu May 15 10:11:20 2025 INFO: Fill completed in 11min 16secs

Dry air skid checks, water pump, kobelco, drying towers all nominal.

Dew point measurement at HAM1 -43.9 °C.

FAMIS - 26378 Checking HVAC Fans Vibrometers.

Fans dont look too bad aside from H0:VAC-MY_FAN_270_1_ACC_INCHSEC which seems to be a  Noisier fan.

TITLE: 05/15 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 12mph Gusts, 8mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.08 μm/s
QUICK SUMMARY:

LVEA is LASER Safe. Hartman Lasers are on but are Eye safe and are ~780nm green/blue in color.

HAM1 ISI is currently unlocked.

Today's  Agenda:
CS:
HAM1 optical Alignment checks
HAM1's Glamour shots.
HAM1 Ground Checks.
Cable Tray work.
GOUI phase measurements in the output arm
TCS work?
 

EX
More wind fence work.

EY
SEI BRS work.

Now that ISC is done with their alignment, I have been working on testing the ISI. Last night TJ and I unlocked and balanced the ISI, I did some quick tests to make sure the actuators were pushing where I expected them and found the horizontal and vertical actuator for each corner was swapped, so I switched the cables at the chamber. This morning I did some tests like range of motion and CPS linearity and some quick spectra to check that all of the sensors looked more or less the same and a quick set of tfs to look for rubbing. Now starting my long overnight tfs, so hopefully there are no big eqs overnight. If those go well, I hope to have everything for the testing report by the afternoon tomorrow.

Attached images are some of the tests I did today. First image is CPS linearity, which looks kind of ratty because I think the purge was too high, but otherwise looks okay. Second image shows unlocked asds for the CPS, GS13s and L4Cs. No glaring issues, but the kind of noisy V2 GS13 and CPS made me think some rubbing or high purge was happening. Last image is a set of tfs I used for chamber closeout comparing the measurements on HAM8 from last year to HAM1 today. Looks okay for a quick measurement.

Fil, TJ, Camilla. WP 12533

We turned back on the RH and SR3 heater chassis which were turned off for venting. After these were turned on, ITMX came back to it's nominal value of 0.44W/segment.

TJ and I played with the inverse RH filters for a while on ITMX (instructions 50777),  turning ITMX up to 0.5W for a couple of hours, it doesn't really make sense to us what it was doing as it drops the power lower than the requested power which seems un-intuitive 68549. Now back at nominal 0.44W/segment with the RH inverse filter guardian back to NOMINAL (off). 

ETMY had come back to the incorrect value after the April power outage (last saved Beckhoff value maybe), so TJ turned that back to the nominal 1.3W/segment on ETMY too. 

TITLE: 05/14 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
HAM1 Purge air has been turned Down.
HAM1 ISI is Currently Unlocked.
It got too windy to work on the Wind Fence  while elevated at EX, so wind fence work was postponed.
SEI BRS team found a broken cable on the BRS System.

TCS team Turned on the Hartman Wave front lasers. These are Eye safe lasers that have a power output of less than a mW. So if you see a blue-green ~780nm beam it MAY be from that.

Bees are still at EX.

LOG:                                                                                                                                                                 

Sheila D, TJ S.

Summary: the ALS arm guardians will now log the Beckhoff fiber locking error messages (untested though, testing later), and I've relaxed some of the thresholds set in Beckhoff. This is all nice, but I don't anticipate major gains from this.

Why: Our ALS locking has not been as reliable as it once was and has been one of the primary reasons for our locking not being fully autonomous. We have been discussing ways to help our ALS locking without large scale ALS table mode matching efforts, that would be very time and resource heavy, and has the chance to impact the ALS system negatively while we are still in a run. One issue that Sheila pointed out was that there were some times before this recent break that the Beckhoff automation code would flag some type of error and then stop the locking automation, the guardian node would see this and drop to the unlocked state and then start over. Sheila thinks that the Beckhoff errors are often based on far too strict of thresholds, and we should rely more on the guardian node for the error checking.

Guardian Changes: While the Beckhoff error codes for fiber locking are in the DAQ (H1:ALS-X_FIBR_LOCK_ERROR_CODE), this binary value needs a map to convert it back to something human readable. The guardian node doesn't look at these directly either, so we don't currently have an easy way to see what the Beckhoff automation is failing on...until now! The binary first has to be converted to hex, then the hex values and their associated error codes were found in a table from E1300482. I wrote a quick dictionary with a string message for the different binary values that are in epics. I've added this into the ALS nodes as a decorator to many different locking states. It will frequently check if there are any errors and log them so we can track what is happening a bit better. It won't be perfect though since it's just a decorator and it's possible that we will miss some of these error messages.

What codes have we been seeing? So in terms of error codes, what has been happening? In 2025, there was a trend in the X arm error codes that was seen during some times where ALS was fussy. Attachment 1 is an example where there is a "beat note out of range of frequency comparator" followed by a "laser error" code. This generally only lasts a few minutes though, and it looks like there were issues before these codes popped up. For the Y arm, the error codes are up for <1second and will often happen a minute or more after the arm loses lock, so I don't think this is too useful. The most common error codes that pop up are: Reference cavity transmission PD error, Reference cavity transmission below the limit, Beat note power too low.

Threshold Changes: One thing that has already been done was lower the PLL reference cavity transmission low limit (ref cav trans low limit) - alog83547. Today, I changed the PLL beat note frequency range from 3MHz-150Mhz to 2MHz-350MHz. The max frequency I saw was near 300MHz, so 350  seemed like enough to get it out of the way. Beat note minimum was already at -40dB, well out of the way already (see attachment 2 for examples). There might be some more places to relax the Beckhoff thresholds, but these related to the most common errors that we saw. Except for the very vague "Laser error" code. This will need more time to look into.

Ibrahim, Betsy, Oli

Yesterday Betsy and Ibrahim swapped the wire loops for gold-plated wire loops (84378), so today Ibrahim took some top to top transfer function measurements and I've analyzed them (2025-05-14_1400_X1SUSBS_M1_ALL_TFs).

I have also made plots comparing them to our last measurements from February (83075). The new wire makes basically no difference (NoPlatingvsAuPlating).

I've also compared this latest measurement to LLO's latest measurement, and they are matching pretty well (AcceptanceReview).

These have all been committed to svn as r12307 and r12308 for the loop plating comparison.

I branched and added some functionality to my misaligned GUI located on ASC IFO_ALIGN_COMPACTEST. I wrote another script to take a lock start and end and run the GUI every 5 minutes, take a screenshot then stitch them all together to make a gif of the lock so that we can see the changing alignments throughout lock stretches. It's a little slow, it was taking 20 minutes per hour till I realized I was redoing a large calculation each iteration unnecessarily, changing that brought it down to ~10 mins/hour of lock.

Here's an example gif of a short 2 hour lock starting at 03/30/25 18:13

Betsy, Ibrahim

Today, Betsy and I replaced the non-plated BBSS bottom wire loop with the gold plated wire loop, which was done successfully and took roughly two hours. We've confirmed the BBSS is centered and aligned. We will monitor and inspect the BBSS in the next few days and coming week. Stay tuned for new transfer functions etc.

Gallery of the wire loop below!