By the way, we should have a jig, which was made at the beginning of 2024, to peacefuly rotate the flag so that the tip direction can align to the vertical direction.

[Ushiba, Washimi, Takahashi]

We found that the H1 (Pic. 1) and H3 (Pic. 3) OSEM flags on the IM are touching the OSEM bodies on the IRM. The H2 (Pic. 2) OSEM flag was also close to the OSEM body.

[Ushiba, Washimi, Takahashi]

We went to investigate the H1 and H3 FLDACCs. We opened the actuator housing and checked the movable range with the LVDT. It was from +80 (actuator side) to +1700 (LVDT side) in H1 and from -2500 to 750 in H3. When we removed the actuator yoke (Pic. 1), the range of the actuator side extended to -600 in H1 (Pic. 2). The actuator coil (Pic. 3) may be touching the yoke. We inserted the 0.5mm shim between the coil bobbin and the folded pendulum body in H1. The range did not change in H3. The folded pendulum has gone to an unstable mode in both H1 and H2. We removed the counterweight of  25g for H1 and 19g for H3. The transfer functions of these two folded pendulums were almost consistent and showed the same resonant frequency of 0.3Hz (Pic. 4). Before closing the top chamber, the Lemo cable for the actuator had broken in H3. Pic. 5 shows the displacement spectra of the H1 and H2 FLDACCs. The sensitivity of the H1 FLDACC was improved.

[Nakagaki, Ikeda, YamaT]

We replaced V3 front-end computer at U13-14 of EY0 rack and V1 IO chassis at U18-21 of EY0 rack to V4 front-end computer and V2 IO chassis, respectively.
Real-time models could be launched but the 2nd DAC cannot be found from OS by some reason.
Today, we had no enough time to investigate what happen, so we will continue this work tomorrow.

-----
Power distribution trouble
Because it's hard to transport many large stuffs to EYC area via EYA booth, two V2 IO chassis (for EYV1 and EY0) and a V4 front-end server (for EY0) were moved to EYC area via mine entrance at Mozumi. V1 IO chassis at U18-21 of EY0 rack was replaced to one of these V2 IO chassis (S2416123). But Adnaco boards in IO chassis weren't driven even when main power switch was enabled. DC24V was surely supplied at the power supply board (ATX-M4), so it seems to be a malfunction of downstream of the power distribution board. According to Ikeda-san, he had never turned on this IO chassis before, so it may be an initial defect. Anyway we gave up to use it and used another IO chassis (S2416124) which would be used for EYV1 in future.

Timing lost issue maybe due to PEM speaker system
By using S2416124 with V4 front-end computer, real-time models could be launched. But we found soon that the timing synchronization didn't work because ADC#0_CH31 for timing duotone signal was contaminated by constant ~-4000ct signal. Though we tried to reboot models and/or the front-end computer in several times, it wasn't recovered.

During these trials, we noticed that the PEM large speaker output laud sounds when some stuffs turned ON and OFF. And also, when AI chassis connected with PEM speaker was turned OFF, PEM speaker output continuous sounds. Finally timing synchronization came back by unplugging DB9 cable of speaker output from AI chassis. Even when that AI chassis turned OFF, timing signal still lost if DB9 cable was kept a connection, so GND connection (shell or #5 pin of DB9) between the digital system and the speaker system seemed to be a cause of this issue.

By the way, a same speaker system also made a hang-up trouble on MCF rack in several times (klog#25343, klog#29433, klog#33565, etc.). It might be better to reconsider the design of how the speaker system is connected to the digital system. If this affects the timing, while a rough coincidence analysis might be possible, a coherence analysis is no longer reliable.

Missing PCIe card issue
After recovering timing synchronization, we noticed that the 2nd DAC (DAC#1) wasn't found by the IOP model. According to lspci command, OS also couldn't found the DAC#1. So it seemed an issue on hardware of common Linux not an issue on LIGO real-time software. Though EY0 had 3 ADC, 2 DAC, 1 BIO, and 1 BO, this configuration hadn't been tested in the test bench. So we doubted the card combination issue that was often seen with V1 IO chassis and removed 1 BO card in order to make a same configuration as EX0 that was successful in klog#36654. But DAC#1 was still missed.

As the next, to know which DAC card was assigned as DAC#1, we swapped two DAC cards (but we noticed soon we cant know by this method) and restarted the front-end computer. At that time, ADC#0_CH#30 shows a some response that is assigned for duotone loop back when DAC duotone was enabled. After then, to check the duotone loop back in the original configuration, we restored two swapped DACs and restarted. Then DAC#1 was found by OS and the IOP model though I have no idea why it came back.

Because DAC#1 came back, we also restored the removed BO card to back to the original configuration, then DAC#1 was missed again... We had no enough time to continue this investigation today. So this work will be continued tomorrow.

Thoughts
Swapping DAC and restoring BO were done without any SCSI and DB37 pin connection. So this issue is now related to only IO chassis or PCIe cards not related to the connection of circuits.

All used PCIe cards were just moved from V1 IO chassis to V2 one today. So if we didn't break them in today's work, PCIe cards themselves should be no problem. Only concern is that DAC#1 was damaged by speaker issue. We plan to take a spare DAC card tomorrow just in case.

If the configuration of EY0 (3 ADC, 2 DAC, 1 BIO, and 1 BO) has a problem, removing BO permanently may become a solution. It's a same config. of EX0, so it's a reasonable solution though the k1caley model must be updated. IX1 and IY1 have 3ADC, 3DAC, 5 BIO, and 1 BO, so using BO itself should be no problem. On the other hand, it's not so surprising there is a card combination issue (a number of each card type, used slot etc.) with V2 IO chassis because we faced such kind of issue with V1 IO chassis in the past. Of course, it may be a malfunction of used BO card, so a check with spare BO card is also necessary tomorrow.

If S2416124 has also a problem (accroding to Ikeda-san, it also hadn't been used in the test bench, so ), we must consider to restore to V1 IO chassis and V3 front-end computer. In this situation, schedule to use Mozumi entrance again (bring back to problematic stuffs and take new stuffs to EY again) is also serious concern.

Since today's results revealed insufficient tests in the test bench, we will likely need to reconsider and accelerate the operation of the test bench.

[Kimura and Yasui]
 It was confirmed that the water level in the tank of the cooling water system attached to the X-10 vacuum pump unit on the X-arm had decreased to approximately one-third of its normal level.
Consequently, on April 1, we performed a complete tank replacement, which also served to refill the water.
 After the replacement work, we left the cooling water system cover off to monitor the rate of water loss.

During the routine inspection on April 3, we will reinstall the cooling water system cover after confirming that there are no further water leaks.

I measured L & R for each IM H coils at the feedthroughs (with cross cables), pin 2-7, with the LCR meter at 100Hz

1. /opt/rtcds/userapps/release/pem/common/scripts/weewx_sync.sh for Atotsu
2. /opt/rtcds/userapps/release/pem/k1/scripts/snow/K1PEM_SNOW_DAQ.py

Summary:

Not only H1 but also H3 FLDACC does't seem healthy.
It is very suspicious that they are rubbing somewhere.

What I did:

To investigate if the pendulum itself is healthy or not, I performed the DC response ceck for FLDACCs.
Procedure is as folows:

1. Engage FLDACC feedback controls so that pendulum is aligned with respect to the LVDT.
2. Turn off INPUT of FLDACCSERVO filter banks to hold the outputs.
3. Change offsets as +100, 0, -100, and 0 with the ramp time of 60 seconds.

Figure 1, 2 and 3 show the result of H1, H2, and H3 FLDACC signals, respectively.
H1 FLDACC signals moves smoothly in the positive direction while not in negative direction.
H2 FLDACC signals moves smoothly in both directions.
H3 FLDACC signals moves smoothly in the positive direction while not in negative direction as well as H1.
So, only FLDACC H1 seems healthy.

Since there is large hysteresis in H1 and H3 FLDACCs, it is suspicious that these proof masses are rubbing somewhere.

Thanks to the guardian modification, FLDACCs' local controls can be implemented into the guardian.
They are now automatically engaged when SRM is going to the READY state.

More pictures: link

The actuators in the IM H1/2/3 OSEMs are not working.

[Washimi, Takahashi]

We went to the recovery work.

• VAC staff opened the top chamber.
• We checked the suspension. We found the IRM is touching the EQ stop at X-Y+ (Pic. 1).
• We screwed out the stopper nuts for the BF keystone to the top of the stud bolts and glued them with TRA-BOND (Pics. 2, 3, 4).
• We tried to align the TM using the Oplev. We found the F0 yaw FR was not working during the alignment. The pushing bolt head has been detached from the rotor bar (Pic. 5). The rotor was rotated by hand. Finally the TM was aligned.
• We added the stopper nuts to make the double nuts for the F0 keystone (Pics. 6, 7, 8).
• VAC staff closed the top chamber temporarily.

[Kimura and Yasui]

 Pressure transducers were installed on the supply side of the He  compressors for the four duct shield cryocooler units (Xfs, Xfa, Yfs and Yfa) in the center machine room.
The pressure transducers have a range of 0 to 40 bar (absolute pressure).
In the future, we plan to connect the output of the pressure transducers to the existing data logger (GM-10) and monitor the supply pressure of the helium compressors via the network.
Additionally, pressure transducers of the same model will be installed on the four duct shield cryocoolers at the X-end and Y-end.

[Washimi, Takahashi, Ushiba (remote)]

We investigated the strange BF behavior reported in klog36669. The situation had changed.

• The movable range of the BF keystone was from +1335 to +2166 (um) in LVDT output; only 0.8mm. The setpoint is 0.
• The measured transfer function (Pic. 1) and spectrum (Pic. 2) showed the damped resonance when the BF GAS was around 1500.
• The RM position was higher than the reference level by 1.5mm (Pic. 3).

We found the lower stoppers (Pic. 4) for the BF keystone have gone down to near the lowest. It might be due to vibration from the stepper motor driving the FR.

• We screwed up the stoppers (nuts). The movable range was extended from -1300 to +2284.
• We could move the keystone to 0 with the FR.
• The measured transfer functions (Pic. 5,6,7) and spectrum (Pic. 8) became natural.
• The RM position was consistent with the reference level (Pic. 9).

[Kimura and Yasui]
 It was confirmed that the water level in the tank of the cooling water system attached to the Y-10 vacuum pump unit on the Y-arm had decreased to approximately one-third of its normal level.
Consequently, on March 25, we performed a complete tank replacement, which also served to refill the water.
 After the replacement work, we left the cooling water system cover off to monitor the rate of water loss.
During a routine inspection on March 27, it was confirmed that there was no further water loss, so we reinstalled the cooling water system cover.
 A decrease in the water level of the cooling water system tank has also been confirmed for the X-10 vacuum pump unit on the X-arm.
We plan to replenish the water during the next maintenance operation.

Since actuator signs of FLDACCSERVO_COILOUTF was defined as LVDT signals decrease when applying positive DC offset from COILOUTF, I swapped the sign of all FLDACCSERVO_COILOUTF gains.
In addition, FLDACC servo was closed with the gain of 1 at FLDACCSERVO_{H1,H2,H3}_GAIN but they should be -1 in case of Type-A suspensions.
To unify the suspension control method, I didn't swap the filter gains, so the loop can be closed with gains of -1 now.

I will implement it to the guardian after changing the guardian for the Type-B suspension so that FLDACC loops can be engaged before READY state.

[Takahashi, Ushiba]

We investigated the geophone noise reported in klog36664.

Figure 1 shows the amplitude spectrum density of ACCINF_H1_IN1 with calibration in diaggui (red) and ACCINF_H1_OUT (blue).
Obviously these two signals are different though these two signals should be same, so the noise measured in ACCINF_H1_OUT seems to come from calculation errors.
Note that the other ACCINF signals have similar behaviour though the situation seems slightly better (fig2 shows an example of H2 ACC signals).
This phenomena can be explained due to the large DC values of ACCINF output signals due to the very low-frequency poles for cnverting velocity to displacement.
Since real-time model is calculating the signals in double precision while diaggui calculates in float, this problem doesn't affect the performance of the suspension controls.

According to the klog23368, ADC noise level measured before shows the large excess at low frequency (3e-1 cnt/rtHz @ 0.1 Hz).
Figure 3 shows the comparison of the spectra of H1 and H2.
The low frequency noise of H1 is higher than that of H2, and the noise level is consistent with the ADC noise level (3e-1 cnt/rtHz @ 0.1Hz), so the H1 geophone noise at low frequency is limited by ADC noise, which causes the larger DC offsets when applying low frequency poles resulting the larger calculation errors.

Since it is hard to reduce the ADC noise level because we have already known that this phenomena is highly depending on GND connection of the DGS rack, one possible solution is to use the ADC channels of CH23 instead of CH20.
To do that, we need following changes:
1. Swap the cables at geophone distributer.
2. Change SRM tower model

Anyway, since the problem is not inside the vacuum chamber, it would not be necessary to replace the geophone this time.

I revised the diaggui templates for the health check of the IP. The resonant frequencies of the IP were changed from 63 to 51mHz for L and from 70 to 59mHz for T.

I performed a health check of the suspension.

• The health check scripts for the IP and BF GAS did not work.
• The IM H1, H2, H3, L, T, and Y TFs had a gain lower than the references. The H1/2/3 OSEM positions are out of linear range.
• The F0 and F1 GAS TFs were very different from the references when the BF GAS was around the setpoints in the READY state (Plot 20, 21). The BF GAS behavior was like rubbing. When the BF GAS was about +1500 (um) far from the setpoint with the FR (Plot 22), the rubbing was settled. Then the F0 and F1 GAS TFs were still different in the READY mode. The F0 and F1 GAS TFs were recovered when the GASs were controlled in DC (ALIGN -> FLOAT); the BF GAS was at the setpoint (Plot 23, 24). The point is not the keyston position but the FR position.

I measured the resistances of PI#1~#3 GEO, after the flip cable.

The values for 4-5, 9-5, and 4-9 were increased during the measurements, so I wrote the values that had finally stabilized.

The all 3 Geophones' behaviors were almost the same.