Jennie W, Khanh V,

Since Keita and I realised that the WFS A and B quadrants 2 and 3 are swapped between the RF channels and the DC channels, I have been trying to trace down where the error is. Last week we fixed the problem by swapping the cables for WFSA segment  2 and 3 and WFS B segment 2 and 3 cables at the IOT1 feedthrough panel.

I don't think it is in the RF signal chain as when we unplugged WFS HF segment 2 from the outside of the feedthrough, the channel that corresponds to WFS segment 2 went dark in EPICS.

Since we are still laser SAFE in the corner, Khanh and I took a laser pointer onto the JAC table and tried to see if we could only shine it on one quadrant of the QPD. Since the QPD is as large as the beam this was not really practical. We instead moved a beam card in front of the PD and slowly drew it downwards.

Since quadrants 2 and 3 are the two we suspect are swapped, we looked at which of these showed some light first.

We used the response to the table lights being blocked with the card to see if there was a difference in the readout from each QPD segment. Using the laser point for this did not work as the beam reflects off the card and the QPD casing.

Segment 3 showed light before segment 2 when moving the card down from the top of the diode.This implies the readout channels for 2 and 3 are swapped. The step in power was not as obvious as with a laser beam so I would like to recheck this once we go laser hazard.

Khanh and I also took the side panel off the table and traced the individual WFS cables from the QPD boxes to the feedthrough. These cable are all plugged in correctly on the inside of the feedthrough.

Next step is to get Fil's help to either check the DC pin outs on the WFS boxes or check the channels on the RF PD chassis at ISC-R1.

Summary: We think the JAC WFS QPDs have two segments wired incorrectly but only on the DC readouts, not the RF readouts.

h1isibs crashed again following the power cycled of h1seib2 at 09:07 this morning. EJ took a closer look and found that the problem was most probably with Adnaco A4, which has two BIO cards. h1isibs uses both cards and h1hpibs has no binary IO, which explains why only the ISI model is crashing.

While keeping the IO Chassis powered up, we tried a reboot then a power cycle of h1seib2. No A4 was detected and the adapter card link was red. We then powered the computer down and Erik cleaned the A1 fiber pair. This time the adapter went green and the binary cards were seen again.

We started the models at 15:01 and will run like this overnight. At time of writing, 22:00, it has been running for 7 hours.

WP13475 was opened to move the BIO cards from A4 over to the empty A3 if we need to disconnect A4 from the computer (as has been found for h1lsc0).

D. Sigg, R. Short

At the request of the SPI team, I've updated the names of the picomotor driver channels that correlate to new picos added with the SPI install. I also removed the names of old HAM2 and 3 oplev picomotors, as these have not been installed and are not going to be installed. This involved a Beckhoff software restart at approximately 19:00 UTC.

Jim, Jonathan, EJ, Oli, Fil, Dave:

h1seib2 has had several problems over the past 24 hours; missing BIO adnaco, overheating Mellanox IPC, user model ADC timeout, ISI L4C switching not working, DAQ CRCs.

We decided a clean power cycle of the front end and IO Chassis is a good first step.

09:07 h1seib2 stop all models and powerdown. Fil went into CER and powered down IO Chassis and AI Chassis

09:09 IO Chassis power up, CPU power up, AI chassis power up.

Once the models got going again, Jim reported the binary switching problem was resolved.

The PSL is now back on after the CDS and interlock work over the last couple of days.  We turned the PSL back on yesterday and locked the PMC at the end of the day so both could warm up overnight.  This morning I tweaked beam alignment into both the PMC and RefCav.  With the ISS ON, PMC Trans is ~104.8 W and PMC Refl is ~28.6 W, while the FSS RefCav TPD is ~0.527 V.  PMC Trans and Refl have not quite returned to their pre-interlock work levels, but in the past we've seen that it can take up to 24 hours for this to occur.  To that end, I have left the ISS OFF while the PMC continues to warm up, but it can be turned on whenever it is needed.

TITLE: 07/30 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: 4mph Gusts, 3mph 3min avg
    Primary useism: 0.01 μm/s
    Secondary useism: 0.09 μm/s 
QUICK SUMMARY:

Looks like everything is almost back to nominal after the rcg upgrade yesterday!

Madi

I've been reviewing data from 2024 to quantify the ALSX mode-mismatch, with the hope of comparing the mode-mismatch from the cavity scan to the mode-mismatch observed from the return ALS beam, measured 90370. The cavity scans were recorded in 80077 , and follow on from the ALSY cavity scans 80065. I pulled the historical data into ndscope, so I was able to get direct numbers for the relevant data. 

There were two scans performed - one with an 'okay' alignment, and one with 'better' alignment. The 'better' alignment scan does not swing through a full FSR, so the mode frequencies could not be measured, however the magnitude distribution ratio could still be calculated to determine the mode-mismatch. 

The 'okay' alignment had a 2.19% mode-mismatch, while the 'better' alignment had a 1.78% mode-mismatch.

We noticed that H1ISIBS had gone down and check the dmesg logs to find this: 
[29807.260951] h1iopseib2: WARN - Missed an expected DAC sample, DAC card: 1, chan 13, time_sec: 1469407411, cycle: 32769
[29808.620352] h1isibs: ERROR - Waiting for ADC cycle 32737, live read is 53217, mm: 0, ioMemCtr: 4065
[29808.620529] h1isibs: ERROR - An ADC timeout error has been detected, waiting for an exit signal.
[31724.338050] perf: interrupt took too long (3129 > 3127), lowering kernel.perf_event_max_sample_rate to 63750 

Jonathan restarted the model ~ around 2:15 UTC -ish. 

EJ, Erik, Jonathan, Tony, Dan M,

This morning EJ and Jonathan started models on the systems and did a daqd restart as rcg5.6 adds a few new channels.  We found that there were install problems with h1suslo12 and h1susauxh6.  EJ looked into those and fixed some permission issues and was able to re-install the models.

We had problems with lsc, seib2, seih23

* LSC - EJ noted that the LSC system had a correctable pci error yesterday around 5:25pm localtime.  We were not controlling anything at this point.  The LSC models would not stay running.  EJ fixed some BIOS setting errors (the c-state settings were not locked to c0/c1 state) and enhanced fault state was not disabled.  EJ traced this down to spikes in the model run time to over 400ms!  We when through and tried a real time processing benchmark with no add in IO cards, the new ethernet NIC, the adnico cards (w/o fibers plugged in), the adnico cards with fibers, and then variations on which fibers.  In the end we have left the 4th adnaco disconnected.  We suspect the fiber got dirty as it was working.  There are no io cards in that chassis on that card.

* seib2 did not see any of its binary io cards.  Rebooting was sufficient to fix that.

* seih23 did not see any IO cards, a reboot fixed that.

After fixing the lsc model Erik and Tony took a spare computer out to end-X to look at seiex.  They were unable to get the computer to see the new ethernet card.  They ended up putting the spare computer in.  Once that was done seiex worked.

After seiex was running, EJ looked at the global IPC state.  We had to restart the ethernet controller and models on cdsh8, as it was erroring out on all its ipcs.  The h1omcpi was having a steady IPC error rate of about 20 errors a second.  The errors are coming from the h1ioplsc0 model.  This is a problem with the fast adc logic just taking a lot of time.  The IPCs where coming in late for the omcpi model.  EJ was able to adjust how it waited for the IPCs to clear the errors.  The base assumption on the IPCS timings is against models that are running with some headroom, the lsc iop mode is running at almost the max time that it can which gives a small window for the IPC.

We restarted h1build and h1ecatmon0 to have them booting from the new bootserver.

Dan Moraru and Jonathan looked at the cdsfs systems.  Dan was able to fix a race condition which prevented the system from doing high availability fail over for the /ligo filesystem.  Now we can move which server is serving /ligo between cfdsf2 and cdsfs3.  Migrating the /ligo filesystem causes access to the filesystem by the control room systems to pause for a few minutes.   We tested this transition a few times, and then tested it by applying system updates and reboots on cdsfs2 and cdsfs3.

Dan also put the same configuration fixes into cdsfs4 and cdsfs5.  These are designed to hold /opt/rtcds (though they are not yet).  We will continue to work on these systems as the cdsfs4 & cdsfs5 have not come back properly from updates.

Gizem K, Wanda V, Jenne, Fil

Since yesterday (alog 91299) and Monday (alog 91271) we saw lots of back-reflection from the end of the fibers, today we went to the ends to terminate the fibers with what is essentially a fiber beam dump.

First, Fil went to each end, and connected a jumper fiber cable to the junction box panel at the end of each of our fibers (recall we're using #24 on each arm).  Then we went, and Gizem spliced in to that jumper fiber a cladding-only "fiber", that will absorb the light since there isn't a core to this fiber.  This termination fiber is laid inside of a pvc pipe, which is then laying on the floor, taped closed to be light-tight as well as secured to the floor using UltraTape.  

Unfortunately, the data looks more noisy now than it did earlier in the week.  Gizem and Wanda ran an OTDR test on the newly terminated fibers, and indeed the ends of the fibers seem to be absorbing the light as desired.  However the connection point between the LIGO fiber and the jumper fiber seems to have lots of reflection.  

Folks will look at the data further to help decide whether we should keep the termination fibers, or just remove them and live with the slightly-noisy data that we had earlier in the week rather than the very noisy data we have today.

Attached are some action shots of Gizem splicing, Wanda watching, and the pvc pipes we have the termination fibers in.

Travis, Gerardo, Jordan

During the closing of GV6 back in May, we noticed that there was some blow-by in the pneumatic system when trying to hard close the valve, see alog 90093. 

We were able to hard close the valve eventually but as preventative maintenance we wanted to replace the air cylinder seals, similar to GV7.

Prior to disassembly we measured the locations of the reed switches from the top surface of the bottom plate to the bottom surface of the reed switches:

Bottom Switch: 1 1/8"

Top Switch: 49 1/4"

We then disassembled the air cylinder and replaced the seals following procedure/notes collected during the GV7 repair. During cleaning of the old grease on the piston head, we noticed there were two burrs on the top of the piston, we did not notice any damage to the inside of the cylinder, but as a precaution we used a small flat file to remove the burrs. We also chased the threads on the four threaded rods with a die to aid with reinstallation. After cleaning and inspection of the cylinder tube, we found no issues or damage so we decided to continue to use that cylinder and keep the new one as a spare.

No other issues encountered, we removed the old seals, cleaned the grooves, added copious amounts of the supplied grease to the o-rings, seals and the inside of the air cylinder, and then re-assembled the cylinder tube. Pictures posted below and a final procedure is in progress and will be posted to the DCC.

We did not get a chance to cycle the valve after the seal replacement, so we will continue tomorrow with cycling the valve.

TITLE: 07/29 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: Oli
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 10mph Gusts, 5mph 3min avg
    Primary useism: 0.71 μm/s
    Secondary useism: 0.12 μm/s 
QUICK SUMMARY:

Dan, Jonathan, & Erik are still working on the file server.  OPS-Overview is still all red.
But Jonathan just walked in and said I can start recovering the IFO. 
So i will start taking the SEI and the SUS back to Damped and aligned.

Ryan S and I added a check in DIAG_MAIN called PSAMS() which checks that the PSAMS Strain Gauge for ZM2, ZM4 and ZM5 is within 0.1V of the target. If not, gives the message "PSAMS not at Target Voltage". This should let us know if anything goes wrong with the chassis or servo as in FRS 31062. We reloaded DIAG_MAIN and it worked as expected. 

P. Thomas, F. Clara, R. Short, T. Sanchez, R. McCarthy

WP 13441.

The laser safety interlock code is now running (temporarily) on the CX2040-0155 machine labeled 'testing' in the MSR at IP address 10.105.0.113. It is using commit 86f4fb088fbed6ce3c0e47afcdfc756547e70416 on the branch labeled 'scripting' in the lho-laser-safety gitlab repository: https://git.ligo.org/cds/ifo/beckhoff/lho-laser-safety/-/commit/86f4fb088fbed6ce3c0e47afcdfc756547e70416

The original intention was to use the machine that was already running the previous version of the code, a C5210-0020 in the MSR labeled h1safety0 at IP address 10.105.0.10. However, after reimaging this machine with the Beckhoff service tool using the IN-0406-0112-03-0-2021-21-0002H_1.TIB, IN-0406-0112-03-0-2021-21-0002H_2.TIB, and IN-0406-0112-03-0-2021-21-0002H_3.TIB images, the computer went into a cycle where it showed the Windows square with a spinning busy indicator, then went blank and restarted again and again. I then tried using the IN-0303-0010-03-0-2020-11-0001V_1.TIB, IN-0303-0010-03-0-2020-11-0001V_2.TIB, IN-0303-0010-03-0-2020-11-0001V_3.TIB, and IN-0303-0010-03-0-2020-11-0001V_4.TIB images. This started off more promising, but then went to a completely black and unresponsive screen. I contacted Beckhoff technical support and they said these were the wrong images for this machine. They sent me IN-0406-0112-03-0-2024-00-00043_1.TIB, IN-0406-0112-03-0-2024-00-00043_2.TIB, and IN-0406-0112-03-0-2024-00-00043_3.TIB. I tried these but they sent the computer into a boot cycle like the first images. They then suggested updating the code on the service tool. At this point it was getting late in the day, so the decision was made to use the test machine to get things back up and running.
I reimaged the test machine with the CX1800-0511-1009v2.4a_1.TIB, CX1800-0511-1009v2.4a_2.TIB, and CX1800-0511-1009v2.4a_3.TIB images and proceeded with the rest of the work permit.

Filiberto, Ryan, Tony and I verified the following:
IOT1 doors, LVEA Exit ESTOP, LVEA Entrance ESTOP, ISCT1 doors, IOT2 doors, PSL ESTOP, TCSY doors, TCSY ESTOP, CHETAY ESTOP, SQZ ESTOP, SQZT7 doors, SQZT0 doors, SQZ Table ESTOP, HWS doors, HWS ESTOP, TCSX doors, TCSX ESTOP, HIGH BAY Exit ESTOP, HIGH BAY Entrance ESTOP, CHETAX ESTOP, EY VEA Entrance ESTOP, EY VEA Exit ESTOP, EY ALS ESTOP, EY ALS doors, EY PCAL Enclosure, EX VEA Entrance ESTOP, EY VEA Exit ESTOP, EX ALS ESTOP, EX ALS doors, EX PCAL Enclosure, FCES ESTOP, FCES doors.
The EX PCAL enclosure only trips off the EX and EY PCAL lasers. The EY PCAL enclosure only trips off the EX and EY PCAL lasers. The CHETA doors tripped off all of the lasers, which turned out to be the wrong thing to do. Filiberto made a hardware change so that this wouldn't happen, but the code needs to be eventually changed to fix this.

Ryan C, Rahul

The broken PSAMS unit has been replaced (again for the 2nd time in the last two weeks) with a repaired one (ZM5-SN4, repaired by CIT and characterized by Camille). Once the PSAMS optic was installed in ZM5 suspension, we suspended all stages and balanced it and laced the mighty mouse cable. ZM5 was then re-installed in HAM7 chamber and dogged down by two dog clamps for now.

Inside the chamber, the PSAMS and BOSEM cables are now connected to the electronics chain and all stages of the suspension are set free. 

I will take health check measurements once the front end comes back online.

In the meanwhile we tested the PSAMS near the SQZ racks and the results are given below,

SG (Strain Gauge) resistance was measured to be 355.7 ohms (pin 11&24) and 707 ohms (pin 12&24).

We were able to drive the PZT voltage from 0 to 200V and obtain the strain gauge voltage ranging from 0.365V to 5.41V.

Attaching latest pictures of ZM5 below after it has been re-installed in the chamber.

After a lock loss this morning Sheila and I spent some time looking further into the mode spacing for ALS (alog80065). We each took an arm and looked at the mode spacing and peak heights at good alignments and some not as good alignments. This exercise didn't yield any major revelations, but did confirm that our Y arm definitely doesn't have perfect mode matching, X arm seems to be better than Y. 

Attachment 1 - ALS Y 00 mode to 2nd order mode spacing. This showed that yesterday Sheila and Ibrahim missed the small 1st order mode between these and Sheila has sinced updated their FSR and FHOM values (alog80076).

Attachment 2 - An example of ALS Y locking below the max flashes, showing that some of our power is in the higher order modes.

Attachment 3 - ALS X comparison of attachment 1

Attachment 4 & attachment 5  - ALS X 1st order peak spacing and height for an okay alignment (4) vs a better alignment (5).

Attachment 6 & attachment 7 - Same as above but for the 2nd order modes.