Reports of 34307
DGS (General)
takahiro.yamamoto - 14:11 Friday 29 May 2026 (36968) Print this report
Comment to Lost PCIe connection on K1IOO1 (36952)
[Ikeda, Nakagaki, Oshino, YamaT]

A preparation of new fiber cables was completed.

In addition to the HIB cable, an MTP cable was also installed in a corrugated pipe. This is a backup plan for the case that the HIB cable won't work properly. In this case, IO chassis of K1IOO1 will be also replaced from V1 to V2. When the HIB cable will work properly, it will become a spare cable after the DGS upgrade in future.

The corrugated pipe containing HIB and MTP cables will be laid from the server room to the IOO1 rack on next Tuesday. Until then, the corrugated pipe will be kept at the front room.

Memo for similar cabling works in future
It is more robust to have the extra cable length on the field rack side in case of future changes. And also, HIB and MTP cables have specific orientations as the host (server) side and the target (IO chassis) side. So length of cables of different lengths must be aligned at the host side and placed in a corrugated pipe.

Since the HIB cable reel purchased previously can only be unwrapped from the target side, the easiest way is to pull it all out first and then install it in the corrugated pipe from the host side. When purchasing MTP cables in the future, it is best to choose ones designed as it can be pulled out form the host side (usually the terminal with the pins). Handling ~100m-long cables that have come off the reel is a tough work.
MIF (General)
hirose.chiaki - 12:27 Friday 29 May 2026 (36967) Print this report
Initial alignment in the morning [Xarm, Yarm, OMMT, SRY]

[Yokozawa, Chen, Hirose]

We performed the initial alignment for Xarm, Yarm, OMMT and SRY.
Before Xarm initial alignment, SRM was in LOCK AQ state. So we request SRM GRD to Misalign state.
After that, we completed the Xarm initial alignment.

Subsequently, when we requested ‘IRY LOCK state’ in the initial alignment GRD(Guardian) for the Yarm initial alignment, the IMC’s alignment deteriorated and the lock was lost. To lock Yarm using IR light, we feed feedback to the laser at a high frequency. However, due to the IMC's L2A coupling, it caused the IMC to become misaligned and loss lock.
At that time, the ASC feedback signal was no longer at the normal level, so when we tried to recover the lock again, it became unstable. Therefore, we adjusted the OPLEV on the MCs and the PZT on the IMC’s IP to the values used when the lock was stable. When we tried to lock again, it locked stably. (We reset the PZT offset value to the standard 75V.)

We performed the initial alignment of Yarm. If the transmission power of GRY is low, adjust the PITYAW of SR3; if the transmission power of IRY is low or the flash light is not visible, adjust the PITYAW of BS. This time, we moved BS.

We performed the initial alignment of the OMMT. For the OMMT initial alignment, we referred to klog36759. We also recorded the OMMT1 alignment in the ‘PRFPMI’ of the MEDM screen ‘all oplev’.

For SRY, we request the “Aligning the SRY” state, which is currently in the initial alignment guardian. If the lock is unstable, we adjust the SRM’s PITYAW while monitoring the POPSpol camera and the AS RF34 PD power or AS DC PDA1 OUT power. 
Furthermore, once it was confirmed that the “Aligning the SRY” state had been reached (i.e. SRY lock was complete and the SRM’s ADS was operating stably), the SRY initial alignment was finished. The SRM alignment was recorded and offloaded in the “PRFPMI” on the MEDM “all oplev” screen.

Safety (General)
takashi.uchiyama - 8:18 Friday 29 May 2026 (36965) Print this report
Comment to The top plate is dropped off in the central parking area (34900)
2026/05/28

Kamioka mine company, Hayakawa

We performed a yearly safety inspection of the top ceiling in the central parking lot by Kamioka Mine company on 28 May, 2026.
MIF (ITF Control)
satoru.takano - 1:05 Friday 29 May 2026 (36923) Print this report
SRMI locking test

[Fujimoto, Tanaka, Hirose, Takano]

Summary

We tried locking SRMI. After tuning the filter gain, we easily succeeded in locking it, but further investigation is necessary for good stability.

Detail

For locking DRMI, we tried the SRMI configuration. The idea is to know a hint for a good servo gain of SRCL and MICH in DRMI.

We chose the locking condition as follows:

  1. The Carrier is at the dark fringe in MICH.
    • The f1 sidebands are transmitting MICH by 85 %
  2. The f1 sidebands are on resonance in SRC
    • The carrier would be on anti-resonance, but before entering SRC most carriers are reflected by MICH
  3. Error signals are taken from POP17
    • SRCL: POP17I
    • MICH: POP17Q
    • No guarantee that these two are well degenerated

The conditions for the light fields are different from those in DRMI, but the signal conditions are similar. We expect that, from the servo gain for locking SRMI in these conditions, we would have a good estimate of them for locking DRMI, especially for locking SRCL and MICH in DRMI.

Once we finished the initial alignment of PRMI with ADS, we misaligned PRM and aligned SRM. First we tried the manual locking by tuning the servo gain of MICH and SRCL. After several trials and errors, we found good numbers:

  • SRCL2 gain: 0.5
  • MICH2 gain: -40

We could also enable the integrator on each servo. The measured open-loop transfer functions are shown in Fig.1 and Fig. 2. While locking SRMI, we saw many glitches and they disturbed locking (Fig. 3), resulting in lock loss occasionally. We first suspected the reflection back from PRM, so we misaligned it more by requesting MISALIGNED_BF state, but the situation didn't improve at all.

After succeeding in locking, we implemented the guardian state and tested it. However, every time the guardian failed to lock it when the servos were engaged or the integrators were engaged. After other trial and errors, it turned out that the order of engaging servo gains and the integrators was important: without the integrators, we first need to engage the MICH servo first, then SRCL servo. Also, we found that we couldn't engage the integrator in SRCL servo cannot be enabled without breaking locking, nor increase the SRCL servo gain either. It could be that the demodulation phase is not optimised for SRMI and now POP17I and POP17Q are mixed, which makes the control loops unstable. Further investigation is necessary for stable locking.

 

Images attached to this report
MIF (General)
hirose.chiaki - 22:32 Thursday 28 May 2026 (36964) Print this report
Initial alignment[Xarm, Yarm, OMMT, SRY, PRMI]

[Fujimoto, kTanaka, Hirose]

We performed the initial alignment in order to perform PLL work. However, as the initial alignment took longer than expected, I ended up working on the SRMI instead of the PLL. The initial alignment work done was on the Xarm, Yarm, OMMT, SRY and PRMI. I will post the details later.

IOO (IMC)
hirose.chiaki - 21:29 Thursday 28 May 2026 (36963) Print this report
The restoration of IMC after restarting IOO0

[Yamamoto, kTanaka, Hirose]
I explain the restoration of IMC during the klog36960.

  • The PIT and YAW SUMOUT values for MCI, MCO, and MCE, which had been stable whilst the IMC was locked and ASC was active, had dropped to 0.
    To re-lock the IMC, I set the OPTICALIGN OFFSET to the PIT and YAW SUMOUT values for MCI, MCO and MCE recorded just before the system failed.
  • If it still does not flash, the PZT must be adjusted. In this instance, as it is known that the PZT / DOF5 is effective, I first adjusted the PZT’s OFFSET to a value equal to the DOF5 OUTPUT value minus the nominal 75 V.
  • With this setting, apply LSC and ASC.
  • Check that the DOF5 Input value is 0.
  • Then, slowly return the OFFSET to 75 V.

I will comment further if there are any errors.

MIF (General)
hirose.chiaki - 20:56 Thursday 28 May 2026 (36959) Print this report
Supplied voltage manually to the PZT of the GreenX and GreenY fibre inputs in order to perform the initial alignment

[Tanaka, Yokozawa, Hirose]

To perform the initial alignment, it is necessary to use GreenX and GreenY. 
Currently, as the IOO1 control is under maintenance (klog36952), the PZT voltage cannot be remotely input at k1:ALSFIB under the k1:IOO0 control.
Therefore, we have manually set it to 75V. (Fig.1) If IOO1 recovers, it will be necessary to manually reset it to 0 again.

PZTs adjusted on PSL table at this time: Gr M24, Gr M25(woofer for FIBX_locking), Gr M8(tweeter for FIBX_locking), Gr M20, Gr M21(woofer for FIBY_locking), Gr M19(tweeter for FIBY_lock); To adjust the phase of the input light to the fiber for sending GreenX and GreenY to POP and POS, or to adjust the alignment (optical axis shift).

Images attached to this report
MIF (General)
shun.saito - 19:03 Thursday 28 May 2026 (36962) Print this report
Comment to PLL Test Using a PFD (36955)

The open-loop transfer function measured in klog:36958 is attached.

  • Photo 1 shows the open-loop transfer function obtained using the filter shown in Photo 1 of klog:36958 with the PFD.
  • Photo 2 shows the filter used when the UGF was adjusted to 10 kHz using the mixer.
  • Photo 3 shows the open-loop transfer function obtained using the filter shown in Photo 2 when using the mixer.
Images attached to this comment
DGS (General)
takahiro.yamamoto - 13:10 Thursday 28 May 2026 (36960) Print this report
Comment to Lost PCIe connection on K1IOO1 (36952)
[Kenta, Hirose, Yokozawa, YamaT]

An operation mode of shutter circuit was changed as the local control mode once.
We confirmed the local control mode worked fine.
But, after then, we noticed the shutter model is running on K1IOO0 not K1IOO1.
So we reverted the operation mode as the remote control mode again.

Finally, the models on K1IOO0 were restarted and we confirmed IR shutter can be operated via EPICS.
Lock recovery of PMC and IMC will be reported later by Hirose-san or Kenta.

Turning the power supply breaker for K1IOO1 somehow makes a timing glitch on K1IOO0.
So, when we recovered K1IOO1, K1IOO0 must be in SAFE mode though PMC/IMC lock can be kept during the cabling work for K1IOO1.
Please remind this fact when K1IOO1 will be turned ON/OFF after the cabling work.

For using the IO guardian, ezca for ISS channel was commented out in DOWN state of IO (see attachment).
It might be a temporal modifcation, but same operation is written also in DOWN state of ISS.
So it may be able to be removed permanently.
Images attached to this comment
MIF (General)
shun.saito - 5:24 Thursday 28 May 2026 (36958) Print this report
Comment to PLL Test Using a PFD (36955)

[Ushiba, Takano, Saito]

The VCO efficiency was set to match the efficiency of the sub-laser PZT, which is 1.871 MHz/V. Under this condition, a filter was designed so that the UGF of the open-loop transfer function became 10 kHz. Since the PFD requires an input signal larger than 300 mVpp, while the actual beat signal is only about 0.2 mVpp, it may be difficult to use the PFD in practice. PLL operation was also successfully achieved using a mixer instead of the PFD. Furthermore, it was confirmed that if the beat signal fluctuation is smaller than approximately 936 kHz, lock acquisition is possible by turning on the integrator at the appropriate timing.
 

  • To match the efficiency of the VCO in Moku:Lab to that of the sub-laser PZT, the VCO efficiency was set to 1.871 MHz/V. Then, as in the previous experiment, the open-loop transfer function was measured, and the filter was adjusted so that the UGF became 10 kHz. The filter used is shown in Photo 1. According to klog:35917, resonance of the main laser PZT is observed above 80 kHz, and the resonance frequency of the sub-laser PZT is expected to be similar. Therefore, setting the UGF to 10 kHz is considered sufficiently safe. In addition, the PFD requires an input signal larger than 300 mVpp, whereas the current PLL beat signal (klog:36919) is only about 0.2 mVpp. Since amplification by more than a factor of 1000 would be required, the PFD is not suitable for use in the PLL system.

  • When a mixer was used instead of the PFD, the filter was designed in the same manner as for the PFD case, and PLL operation with a UGF of 10 kHz was successfully achieved. Furthermore, because the frequency of the actual beat signal fluctuates, an additional signal with an amplitude of 500 mVpp and a frequency of 100 mHz was applied to verify whether PLL operation could still be maintained under frequency fluctuations. This corresponds to a fluctuation of approximately 936 kHz. If the same filter used for the non-fluctuating case was applied directly, oscillation occurred. Therefore, one of the two integrators was turned off, and lock acquisition was achieved by turning the integrator on when the error signal frequency became sufficiently low.

Images attached to this comment
CRY (General)
nobuhiro.kimura - 20:02 Wednesday 27 May 2026 (36957) Print this report
Comment to Cryo-cooler Unit Maintenance Work (36134)

[Kimura, Yasui and M. Takahashi]
 On May 27 as part of maintenance work on the cryogenic cooling units, we set up two valve units for the radiation shield cryo-coolers (EYC P-53 and EYC P-55).
We also replace adosorver and filter units in the EYC P-53 and EXC P-55 helium compressoers.
 The remaining tasks are filling the system with G-1 class helium gas up to 15 bar and performing leak tests on all connections.

DGS (General)
takahiro.yamamoto - 16:50 Wednesday 27 May 2026 (36956) Print this report
Comment to Lost PCIe connection on K1IOO1 (36952)

[Ikeda, Nakagaki, Oshino, YamaT]

K1IOO1 was able to be launched properly with a spare 100m fiber laid on the floor.
So, we finally concluded that malfunction and/or aging of a HIB cable is a cause.
Because the contact cleaner of cable terminals didn’t fix this problem, we plan to lay a new HIB cable between the server room and the IOO1 rack.

----
Preparation status of a recovery work:

  • It appears we have an enough amount of corrugated tube in stock.
  • There is a space to lay a new corrugated tube in the hole on the wall at the server room.
  • It looks like we won’t need to drill any holes in the wall this time.
    (We need to consider a hole issue at the future DGS upgrade.)
  • We need to discuss a route of the new cable, human assignment of technical staffs, and a use of an aerial work platform.
    (Hopefully, we can discuss them with Hayakawa-san tomorrow.)


Prospect of recovery
I expect 0.5~1 day for cabling work except at heights. It’s now still unclear when the technical staffs will be available and the aerial work platform can be used, but even if we can do so Thursday afternoon or Friday morning, it will likely take at least until the end of Friday or around noon on Monday.

Consideration about temporary measures until full restoration:
k1shutter (shutter control for main IR), k1alsfib (fiber noise cancelation) and k1psliss don't work at all now. So the shutter cannot be opened now. And also, according to Ushiba-kun, green lasers cannot be aligned because the offsets of the woofer PZTs from DAC are dead.

IR laser shutter can be opened by the local operation mode of the laser shutter circuit. Though a shutter operation remotely via EPICS cannot be done in this mode, IMC lock can be recovered. (Thanks to the hardware interlock, there should be no concern about laser safety). We can also change the output power from PSL room via HWP, so we can use main IR beam for some purposes by this operation. But I'm not sure the stability and noise level because ISS is still unavailable.

Regarding the PZT offset, we can use the 75V output from the Thorlabs(?) PZT driver instead of the 5V output from the DAC. (In my understanding, we normally use 5V offset output from DAC without any offset output from PZT driver.) Fine and remote alignment cannot be available, but rough alignment of green lasers should come back.
 

MIF (General)
shun.saito - 3:28 Wednesday 27 May 2026 (36955) Print this report
PLL Test Using a PFD

[Abe, Tanaka, Hasegawa, Fujimoto, Saito]

To use in the PLL system, we verified the output signal of a Phase Frequency Discriminator (PFD) built by Nishino-san and brought from Mitaka. A PLL test was performed using Moku:Go and Moku:Lab. In addition, the open-loop transfer function was measured.
 

  • First, the output signal of the PFD was examined. Please refer to JGW-D1809187 for the circuit diagram. A signal generated by the Moku:Go function generator with an amplitude of 300 mVpp and a frequency of 10.1 MHz was input to the PFD as the RF signal, while another signal with an amplitude of 300 mVpp and a frequency of 10 MHz was input as the LO signal. The output signal was then observed using the oscilloscope function of Moku:Lab. The observed waveform resembled a partially saturated version of Figures 8 and 9 in the datasheet of the PFD component AD9901KP. In addition, when the RF signal was changed to 10 MHz and the LO signal to 10.1 MHz, the output signal was found to invert. Furthermore, when the frequency difference between the RF and LO signals was reduced to 1 Hz and the output signal was observed as a function of phase difference, a linear response was confirmed, although part of the signal appeared to be saturated.
     
  • However, since this behavior was considered acceptable for practical use, we proceeded to test whether PLL operation could be achieved using Moku:Go and Moku:Lab. First, a signal with an amplitude of 300 mVpp and a frequency of 10.1 MHz generated by the Moku:Go function generator was input to the PFD as the RF signal, while a signal with an amplitude of 300 mVpp and a frequency of 10 MHz was input as the LO signal. Next, the PFD output signal was connected to Moku:Lab and passed through a flat filter with 0 dB gain implemented using a PID controller. The output signal from Moku:Lab was then fed back to Moku:Go, where the frequency modulation function of the function generator was used to apply feedback. While observing the RF and LO signals on the oscilloscope, it was found that, after the control loop was engaged, the RF signal stopped drifting relative to the LO signal (Photo 1). The yellow trace corresponds to the RF signal, and the blue trace corresponds to the LO signal. Therefore, the PLL appeared to operate successfully.
     
  • Next, the open-loop transfer function was measured. Another Moku:Lab unit was prepared, and the measurement was performed using the input and output signals of the Moku:Lab used for filter generation. The excitation signal was applied through the other input port and summed using the PID controller. The signal path connected to PID Controller Output 1 was used for the PLL loop, while the path connected to Output 2 was used for open-loop transfer function measurements. As a result, the UGF was found to be around 387.90 kHz, as shown in Photo 2. Since the phase had already crossed 180 degrees, the loop should theoretically have been unstable. However, the oscilloscope still indicated successful PLL operation, suggesting that the open-loop transfer function might not have been measured correctly.
     
  • Upon closer consideration, because a filter existed between the signals used for the measurement, the measured transfer function actually represented only the Moku:Go and PFD section. In other words, if the open-loop transfer function is represented as G and the filter transfer function as F, the measured quantity was -G/F. To determine the phase delay of the filter section, the transfer function of Moku:Lab was measured separately (Photo 3). From this measurement, the phase delay of Moku:Lab was estimated to be approximately 0.865 μs. Based on this result, the gain of the PLL loop filter alone was changed to -23 dB so that the UGF would shift to a frequency region where the Moku:Lab phase delay is nearly zero. The resulting transfer function is shown in Photo 2. Since the oscilloscope signal also behaved similarly to that shown in Photo 1, the PLL operation is considered to have been successful.
Images attached to this report
Comments to this report:
shun.saito - 5:24 Thursday 28 May 2026 (36958) Print this report

[Ushiba, Takano, Saito]

The VCO efficiency was set to match the efficiency of the sub-laser PZT, which is 1.871 MHz/V. Under this condition, a filter was designed so that the UGF of the open-loop transfer function became 10 kHz. Since the PFD requires an input signal larger than 300 mVpp, while the actual beat signal is only about 0.2 mVpp, it may be difficult to use the PFD in practice. PLL operation was also successfully achieved using a mixer instead of the PFD. Furthermore, it was confirmed that if the beat signal fluctuation is smaller than approximately 936 kHz, lock acquisition is possible by turning on the integrator at the appropriate timing.
 

  • To match the efficiency of the VCO in Moku:Lab to that of the sub-laser PZT, the VCO efficiency was set to 1.871 MHz/V. Then, as in the previous experiment, the open-loop transfer function was measured, and the filter was adjusted so that the UGF became 10 kHz. The filter used is shown in Photo 1. According to klog:35917, resonance of the main laser PZT is observed above 80 kHz, and the resonance frequency of the sub-laser PZT is expected to be similar. Therefore, setting the UGF to 10 kHz is considered sufficiently safe. In addition, the PFD requires an input signal larger than 300 mVpp, whereas the current PLL beat signal (klog:36919) is only about 0.2 mVpp. Since amplification by more than a factor of 1000 would be required, the PFD is not suitable for use in the PLL system.

  • When a mixer was used instead of the PFD, the filter was designed in the same manner as for the PFD case, and PLL operation with a UGF of 10 kHz was successfully achieved. Furthermore, because the frequency of the actual beat signal fluctuates, an additional signal with an amplitude of 500 mVpp and a frequency of 100 mHz was applied to verify whether PLL operation could still be maintained under frequency fluctuations. This corresponds to a fluctuation of approximately 936 kHz. If the same filter used for the non-fluctuating case was applied directly, oscillation occurred. Therefore, one of the two integrators was turned off, and lock acquisition was achieved by turning the integrator on when the error signal frequency became sufficiently low.

Images attached to this comment
shun.saito - 19:03 Thursday 28 May 2026 (36962) Print this report

The open-loop transfer function measured in klog:36958 is attached.

  • Photo 1 shows the open-loop transfer function obtained using the filter shown in Photo 1 of klog:36958 with the PFD.
  • Photo 2 shows the filter used when the UGF was adjusted to 10 kHz using the mixer.
  • Photo 3 shows the open-loop transfer function obtained using the filter shown in Photo 2 when using the mixer.
Images attached to this comment
DGS (General)
takahiro.yamamoto - 21:39 Tuesday 26 May 2026 (36954) Print this report
Comment to Lost PCIe connection on K1IOO1 (36952)
[Ikeda, Nakagaki, YamaT]

Abstract

Similar trouble occurred again on K1IOO1 around 1:15 JST on May 26th and we weren't able to resolve that issue today.
Based on the results of several investigations, a 100-meter HIB cable emerged as the prime suspect.
Two additional tests are needed to confirm the suspicion, and we plan to conduct them tomorrow.
If the HIB cable is indeed the cause of this issue, we will need to run a new cable from the server room to the REFL area.

Details

Because K1IOO1 was dead again, restarting real-time models on K1IOO0 was postponed and recovering K1IOO1 was resumed.
According to the server logs, it seemed to a same issue as one in yesterday. At first, K1IOO1 front-end was just rebooted and it's confirmed that IO chassis was missed from the real-time OS. After then all cables were removed from IO chassis (actually, one DB37 cable for BIO was forgotten to remove). It's a different procedure and investigation under different situation from yesterday, so, strictly speaking, reproducibility and identity of the problem weren't able to be checked by today's investigation. (Since we had already confirmed early this morning on the test stand that a problematic HIB card in yesterday's work wasn't broken, there was no reason to hurry up to disconnect the cable out of fear of a malfunction.) Anyway, IO chassis couldn't be found by real-time OS after removing all signal cables.

Even if all signal cables were removed, electrical connection between IO chassis and another equipment in the field racks because GND of power line of IO chassis (DC24V) is connected to one of DC18V and also AC. So we prepared dedicated power supply unit to float IO chassis completely from the field racks. In this situation, IO chassis should work as the standalone. But the problem was not solved. From this result, we assumed this issue was different from the trouble on MCF0 that another equipment around field racks affects stability of IO chassis.

Note that, at this point, we have not been able to determine whether the problem lies with the HIB cable itself or with the combination of the long cable and the power supply conditions around the REFL. So we plan to connect IO chassis located in K1IOO1 and the server room with the spare cable by the temporal cabling. A result of this test will tell us HIB cable is really bad or not. Also, if the HIB cable is a cause of this issue, it might be worth checking to see if cleaning the terminals improves the situation or not. (The IOO area gets incredibly dusty.) The standard approach is to run a new cable from the server room to the IOO1 rack. In that case, the action items are as follows:
  • Checking a stock of corrugated pipe (and purchasing if necessary)
  • Checking a route of the new cable
  • Drilling work on the wall of the server room
  • Drilling work on the wall between the front room and the corner station
  • Assigning human resources for work at heights
CRY (General)
nobuhiro.kimura - 16:45 Tuesday 26 May 2026 (36953) Print this report
Comment to Cryo-cooler Unit Maintenance Work (36134)

[Kimura, Yasui, M. Takahashi and H. Sawada]
 On May 25 and  26, as part of maintenance work on the cryogenic cooling units, we set up two valve units for the radiation shield cryo-coolers (EXC P-53 and EXC P-55).
Then we charged G-1 class helium gas into the helium commpressors ( EXC P-53,EXC P-55)    up to 15 bar. 

DGS (General)
takahiro.yamamoto - 22:58 Monday 25 May 2026 (36952) Print this report
Lost PCIe connection on K1IOO1
[Ikeda, YamaT]

Abstract

We found K1IOO1 (k1iopioo1, k1alsfib, and k1psliss) was dead around 13:00 JST on May 23rd.
Finally, K1IOO1 was recovered by replacing HIB host and adapter cards to connect the front-end computer and IO chassis.
Due to an undesirable connection on the power line between IO chassis of K1IOO0 and K1IOO1, we had to reboot also K1IOO0 after recovering K1IOO1.
Then, IRIG-B synchronization issue occurred on K1IOO0 and it will probably takes several hours.
Please restart all models on K1IOO0 once after IRIG-B timing will become stable at least in tomorrow morning.

Details

After the morning briefing, we found K1IOO1 had been dead since around 13:00 JST on May 23rd. It wasn't a kernel trouble that sometimes occur and we was able to access K1IOO1 remotely. But all PCIe cards in IO chassis couldn't be found by the lspci command (e.g. 10b5:9056 is the General Standard product).
$ lspci -nvvv | grep 10b5:9056 -A1
14:04.0 1180: 10b5:9056 (rev ff) (prog-if ff)
!!! Unknown header type 7f
--
16:04.0 1180: 10b5:9056 (rev ff) (prog-if ff)
!!! Unknown header type 7f
--
For this reason, it did not appear that a model restart would resolve the issue, and it seemed that either a system reboot (a better case) or a power cycle of the I/O chassis (a worse case) would be necessary. So we asked commissioners to clear all SDF differences in the morning (klog#36948) and we started to recover it in this afternoon.

At first, we did a visual inspection around IO chassis and it seemed to run properly (LED on the baseboard and PCIe cards blinked and timing slave was synchronized). If this issue was caused by a momentary power outage, both IOO0 and IOO1 should be dead at the same time. But only K1IOO1 was dead in this time. So it didn't seem to be the momentary power outage at the upstream of the power distribution board in the IO chassis. But as a very rare case, we doubted a some kind of problem on the power supply path in the IO chassis just in case and tried to shutdown the front-end computer after disabling Dolphin connection, to unplug Dolphin cable and then to boot up the front-end computer. However, PCIe cards couldn't be found by the real-time OS.

Because this issue didn't seem to be a instantaneous power supply trouble, we doubted a malfunction of IO chassis itself (In the past, some capacitors on the baseboard of IO chassis were broken by aging such as klog#16759). In this case, we can identify it by the power cycle. However, IO chassis was able to boot up problems except the issue that real-time OS cannot find any PCIe cards in IO chassis.

After confirming that it's not a problem of the baseboard of IO chassis, we tried to swap HIB host and adapter cards to connect the front-end computer and the IO chassis. HIB card trouble is only remaining cause we had faced in the past (e.g. klog#6174). First, we replaced only HIB adapter card which was used for EX0 before replacing to V2 IO chassis in klog#36654. Because there was no change in situation, HIB host card was also replaced as one which was used for IX1 before replacing to V2 IO chassis in klog#36572 (One used in EX0 was already brought back to Mozumi, so we wasn't able to use it today). After that, we remembered the compatibility issue (klog#33429), so we replaced HIB adapter card to one which was used in IX1 before and was still installed in the old V1 IO chassis. Then, K1IOO1 was able to be recovered with a pair of HIB host and adapter cards which were used in IX1 before.

During the work above, we turned off the power breaker of K1IOO1. Somehow breaker switch affected the IO chassis of K1IOO0 and the front-end computer of K1IOO0 lost IO chassis. So we also needed to reboot K1IOO0. It came back just a reboot of front-end computer after disabling Dolphin connection. But unfortunately, IRIG-B synchronization issue occurred and it seems to take several hours. Maybe IRIG-B synchronization will become stable around 0-1am. After then, all the real-time models on K1IOO0 must be restarted to recover them. So please restart all models in tomorrow morning. Until that, we cannot lock PMC/IMC and so on.
Comments to this report:
takahiro.yamamoto - 21:39 Tuesday 26 May 2026 (36954) Print this report
[Ikeda, Nakagaki, YamaT]

Abstract

Similar trouble occurred again on K1IOO1 around 1:15 JST on May 26th and we weren't able to resolve that issue today.
Based on the results of several investigations, a 100-meter HIB cable emerged as the prime suspect.
Two additional tests are needed to confirm the suspicion, and we plan to conduct them tomorrow.
If the HIB cable is indeed the cause of this issue, we will need to run a new cable from the server room to the REFL area.

Details

Because K1IOO1 was dead again, restarting real-time models on K1IOO0 was postponed and recovering K1IOO1 was resumed.
According to the server logs, it seemed to a same issue as one in yesterday. At first, K1IOO1 front-end was just rebooted and it's confirmed that IO chassis was missed from the real-time OS. After then all cables were removed from IO chassis (actually, one DB37 cable for BIO was forgotten to remove). It's a different procedure and investigation under different situation from yesterday, so, strictly speaking, reproducibility and identity of the problem weren't able to be checked by today's investigation. (Since we had already confirmed early this morning on the test stand that a problematic HIB card in yesterday's work wasn't broken, there was no reason to hurry up to disconnect the cable out of fear of a malfunction.) Anyway, IO chassis couldn't be found by real-time OS after removing all signal cables.

Even if all signal cables were removed, electrical connection between IO chassis and another equipment in the field racks because GND of power line of IO chassis (DC24V) is connected to one of DC18V and also AC. So we prepared dedicated power supply unit to float IO chassis completely from the field racks. In this situation, IO chassis should work as the standalone. But the problem was not solved. From this result, we assumed this issue was different from the trouble on MCF0 that another equipment around field racks affects stability of IO chassis.

Note that, at this point, we have not been able to determine whether the problem lies with the HIB cable itself or with the combination of the long cable and the power supply conditions around the REFL. So we plan to connect IO chassis located in K1IOO1 and the server room with the spare cable by the temporal cabling. A result of this test will tell us HIB cable is really bad or not. Also, if the HIB cable is a cause of this issue, it might be worth checking to see if cleaning the terminals improves the situation or not. (The IOO area gets incredibly dusty.) The standard approach is to run a new cable from the server room to the IOO1 rack. In that case, the action items are as follows:
  • Checking a stock of corrugated pipe (and purchasing if necessary)
  • Checking a route of the new cable
  • Drilling work on the wall of the server room
  • Drilling work on the wall between the front room and the corner station
  • Assigning human resources for work at heights
takahiro.yamamoto - 16:50 Wednesday 27 May 2026 (36956) Print this report

[Ikeda, Nakagaki, Oshino, YamaT]

K1IOO1 was able to be launched properly with a spare 100m fiber laid on the floor.
So, we finally concluded that malfunction and/or aging of a HIB cable is a cause.
Because the contact cleaner of cable terminals didn’t fix this problem, we plan to lay a new HIB cable between the server room and the IOO1 rack.

----
Preparation status of a recovery work:

  • It appears we have an enough amount of corrugated tube in stock.
  • There is a space to lay a new corrugated tube in the hole on the wall at the server room.
  • It looks like we won’t need to drill any holes in the wall this time.
    (We need to consider a hole issue at the future DGS upgrade.)
  • We need to discuss a route of the new cable, human assignment of technical staffs, and a use of an aerial work platform.
    (Hopefully, we can discuss them with Hayakawa-san tomorrow.)


Prospect of recovery
I expect 0.5~1 day for cabling work except at heights. It’s now still unclear when the technical staffs will be available and the aerial work platform can be used, but even if we can do so Thursday afternoon or Friday morning, it will likely take at least until the end of Friday or around noon on Monday.

Consideration about temporary measures until full restoration:
k1shutter (shutter control for main IR), k1alsfib (fiber noise cancelation) and k1psliss don't work at all now. So the shutter cannot be opened now. And also, according to Ushiba-kun, green lasers cannot be aligned because the offsets of the woofer PZTs from DAC are dead.

IR laser shutter can be opened by the local operation mode of the laser shutter circuit. Though a shutter operation remotely via EPICS cannot be done in this mode, IMC lock can be recovered. (Thanks to the hardware interlock, there should be no concern about laser safety). We can also change the output power from PSL room via HWP, so we can use main IR beam for some purposes by this operation. But I'm not sure the stability and noise level because ISS is still unavailable.

Regarding the PZT offset, we can use the 75V output from the Thorlabs(?) PZT driver instead of the 5V output from the DAC. (In my understanding, we normally use 5V offset output from DAC without any offset output from PZT driver.) Fine and remote alignment cannot be available, but rough alignment of green lasers should come back.
 

takahiro.yamamoto - 13:10 Thursday 28 May 2026 (36960) Print this report
[Kenta, Hirose, Yokozawa, YamaT]

An operation mode of shutter circuit was changed as the local control mode once.
We confirmed the local control mode worked fine.
But, after then, we noticed the shutter model is running on K1IOO0 not K1IOO1.
So we reverted the operation mode as the remote control mode again.

Finally, the models on K1IOO0 were restarted and we confirmed IR shutter can be operated via EPICS.
Lock recovery of PMC and IMC will be reported later by Hirose-san or Kenta.

Turning the power supply breaker for K1IOO1 somehow makes a timing glitch on K1IOO0.
So, when we recovered K1IOO1, K1IOO0 must be in SAFE mode though PMC/IMC lock can be kept during the cabling work for K1IOO1.
Please remind this fact when K1IOO1 will be turned ON/OFF after the cabling work.

For using the IO guardian, ezca for ISS channel was commented out in DOWN state of IO (see attachment).
It might be a temporal modifcation, but same operation is written also in DOWN state of ISS.
So it may be able to be removed permanently.
Images attached to this comment
takahiro.yamamoto - 14:11 Friday 29 May 2026 (36968) Print this report
[Ikeda, Nakagaki, Oshino, YamaT]

A preparation of new fiber cables was completed.

In addition to the HIB cable, an MTP cable was also installed in a corrugated pipe. This is a backup plan for the case that the HIB cable won't work properly. In this case, IO chassis of K1IOO1 will be also replaced from V1 to V2. When the HIB cable will work properly, it will become a spare cable after the DGS upgrade in future.

The corrugated pipe containing HIB and MTP cables will be laid from the server room to the IOO1 rack on next Tuesday. Until then, the corrugated pipe will be kept at the front room.

Memo for similar cabling works in future
It is more robust to have the extra cable length on the field rack side in case of future changes. And also, HIB and MTP cables have specific orientations as the host (server) side and the target (IO chassis) side. So length of cables of different lengths must be aligned at the host side and placed in a corrugated pipe.

Since the HIB cable reel purchased previously can only be unwrapped from the target side, the easiest way is to pull it all out first and then install it in the corrugated pipe from the host side. When purchasing MTP cables in the future, it is best to choose ones designed as it can be pulled out form the host side (usually the terminal with the pins). Handling ~100m-long cables that have come off the reel is a tough work.
DGS (General)
takahiro.yamamoto - 20:13 Monday 25 May 2026 (36951) Print this report
Comment to Deployment of V2 IO-chassis and the front-end computer for EX1 (36909)
[Ikeda, YamaT]

We measured ADC and DAC noise of K1EX1 with the V2 IO chassis.
There is no large difference in glitchy channels in the previous measurements measurement with the V1 IO chassis klog#20902.

We cannot assess an impact of these minor differences on lock acquisition now (the required values for PRFPMI and RSE may differ).
It appears that there are no issues at least in terms of maintaining the LOCK_ACQUISITION state for VIS.

Noise on each channels are shown in attached figures.
Original measurement data can be found in /users/DGS/measurements/{ADC,DAC}/K1EX1/2026/0524/*.xml
Images attached to this comment
DGS (General)
shoichi.oshino - 17:16 Monday 25 May 2026 (36950) Print this report
Manual Activation of MATLAB R2016b Due to Discontinued Online Authentication Support
During the license renewal of MATLAB R2016b on k1ctr27, the activation wizard failed to launch a web browser, preventing online authentication. An investigation revealed that the issue was caused by MathWorks discontinuing support for the online activation servers for older versions, including R2016b (R2008a–R2017a). As a workaround, the activation was successfully completed by accessing the MathWorks License Center and manually obtaining and installing the license file using the host ID of the target machine.
DGS (General)
shoichi.oshino - 13:23 Monday 25 May 2026 (36949) Print this report
Comment to Installed new network switch at Control Room (36868)
The network switch that was newly installed two weeks ago has been operating stably, so the previously used network switches and LAN cables were removed. Although the original plan was to shut down k1ctr2 and k1ctr3, the removal was completed without shutting them down.

MIF (General)
dan.chen - 13:22 Monday 25 May 2026 (36948) Print this report
SDF clear

With Kenta Tanaka

We cleared the SFDs.

Memo
SR TM ICSINF had hodling values -10.657 for P and 29.068 for Y. We put these values at OFFSET of these filters and cleared the hold. (The offset switchs are kept at OFF.)
Later, we probably need to put these vaues to set flters.

Images attached to this report
MIF (General)
dan.chen - 9:14 Monday 25 May 2026 (36946) Print this report
Initial alignment trial

Summary

I tried to perform the initial alignment, but I could not reach IRX_LOCKED. The initial TR_GRX was low, around 0.3. After manually adjusting the alignment, TR_GRX increased to about 0.6, and I requested IRX_LOCKED. However, the X arm still did not lock.

When the arm briefly approached the lock, the IR beam spots on ITMX and ETMX were clearly off from the center. I adjusted the ITMX and ETMX OPTICALIGN values to bring the IR beam closer to the centers, but the lock could not be established. Since the situation did not improve, I stopped the trial and restored the OPTICALIGN values of BSPR3, ITMX, and ETMX to the original values.

One possible issue is that the IR and GR axes were not well matched?

Preparation

  • Opened the GR shutter.
  • Moved PRM from LOCK_ACQUISITION to MISALIGNED.
  • Moved ITMX from LOCK_ACQUISITION to MISALIGNED.
  • Kept SRM in LOCK_ACQUISITION at first.
  • Confirmed SRC flashes using K1:LSC-POP_PDA1_RF17_I_NORM_MON.
  • Moved SRM from LOCK_ACQUISITION to MISALIGNED.
  • Confirmed that ETMX and ETMY could reach LOCK_ACQUISITION.

X-arm alignment trial

I confirmed that FIB and PNC were locked as expected. I then requested IRX_LOCKED, but the lock was not acquired. The IR beam on ETMX was largely miscentered, and TR_GRX was only about 0.3.

I once set the initial alignment guardian to DOWN and manually adjusted PR3 to improve the GRX transmission:

  • PR3 (P, Y): (62.8, -28.1)(56.8, -28.5)
  • TR_GRX: about 0.3 → about 0.6

After requesting IRX_LOCKED again, the lock was still not stable. When the beam was briefly visible during the lock trial, the IR beam was located around the upper-right side on ETMX and the lower-left side on ITMX. The displacement seemed to be mainly in yaw.

I then adjusted the ITMX and ETMX OPTICALIGN values:

  • (IXP, IXY, EXP, EXY): (5.0, -13.0, -9.5, -11.0)(5.8, -16.5, -8.2, -11.8)
  • At some moments the IR beam looked reasonably good on the TCam, but the lock was immediately lost.
  • TR_IRX was around 0.2 during such attempts.
  • The transmitted beam often looked like a vertically split higher-order mode rather than TEM00.
  • Tried (5.8, -16.5, -10.0, -11.8).
  • Tried (5.8, -16.5, -7.0, -11.8); the TEM00 rate seemed slightly better.
  • Finally tried (7.1, -16.5, -8.3, -11.8) because the beam still looked slightly high on ETMX.

Even after these adjustments, IRX_LOCKED could not be achieved. The lock attempts frequently ended up in non-TEM00 modes. This may indicate that the IR input axis, or the mismatch between the IR and GR axes, was the limiting issue?

Restoration

I stopped the trial and restored the alignment values:

  • Set the initial alignment guardian to DOWN.
  • Restored ITMX and ETMX OPTICALIGN: (IXP, IXY, EXP, EXY) = (5.0, -13.0, -9.5, -11.0).
  • Restored PR3: (P, Y) = (62.8, -28.1).
VIS (General)
dan.chen - 7:33 Monday 25 May 2026 (36947) Print this report
Type A GAS filters are closing to satuation

I found some GAS filters are closing to the satuation values.
Do we need offload works?

Images attached to this report
IOO (IMC)
kenta.tanaka - 11:09 Friday 22 May 2026 (36945) Print this report
Strange offset in IMC IP PZTs were applied. Please do not touch PZT offsets if you cannot take care of the PZT driver or PZT themselves.

Tanaka, Fujimoto

We found that IMC IP PZTs were applied strange offset during today's initial alignment. During initial alignment by ST students, IMC could not be locked because IMC alignment become worse. Whole we investigated the cause of the misalinment, we found the issue. 

PZT offset value is set to the middle (75 V) of the range (0-150V). On the other hand, offset value seems to be changed two times recently, May 11th and April 22th respectively (fig.1). In the PZT2, the offset value was changed to the negative value (-22V). The PZT driver could not be receieved the negative value because the negative voltage will break the driver or PZT itself. Since PZT offsets are not changed automatically, they are changed by human.

Fortunately, we restored PZT offsets to nominal value, then IMC alignment was restored.

Please do not touch PZT offsets if you cannot take care of the PZT driver or PZT themselves.

Images attached to this report
MIF (ITF Control)
satoru.takano - 8:48 Friday 22 May 2026 (36943) Print this report
Trial on DRMI

[Fujimoto, Tanaka, Takano]

Summary

We tried to lock DRMI for the first time since the last RSE trial. Several problems were found to be solved.

Detail

For the first time since the last RSE trial 6 years ago, we started the work on DRMI locking.

Preparation works:

  1. The interferometer was first aligned by students from ST [Kawakami, Hasegawa, Abe] with the great help of Kenta.
  2. We moved on to aligning SRM using SRY. We encountered a strange behaviour with the locking point, but Hiroki miraculously solved it.
  3. After aligning SRM with SRY ADS, we offloaded the value using the offload function, but it didn't work well. Further investigation is necessary.
  4. We misaligned SRM again and aligned PRMI. We manually aligned PRM to improve the POP90 buildup, but the maximum was ~ 0.4, which should be close to 1.
  5. Once PRMI was locked with 3f signals, ADS was engaged, but it took a very long time, and the buildup never exceeded 0.5.
  6. We stopped ADS and manually moved BS in pitch, then the buildup increased. This indicates that PRMI ADS doesn't work now.
  7. Manual alignment tweaking for BS and PRM was done, and the buildup reached ~ 0.8.
  8. While working, many glitches were observed and they disturbed (probably) MICH control. At the same time, bright beam spots appeared on the bottom of ITMX and ITMY. It seems that the reflection from SRM was close to the main beam and f1 sidebands barely resonated. We need to misalign SRM more, but unlike ITMs, MISLIGNED_BF state is not prepared for Type-B. Probably we have to move IPs.

DRMI trial

We realigned SRM and tried to lock DRMI in these ways:

  1. Hiroki's idea: use 1f signals
    1. Plan to use REFL45I for PRCL, POP17Q for MICH, and POP17I for SPRCL.
    2. We estimated the expected gain for them using Finesse simulations and put these gains in the sensing matrix.
    3. Wait for a while. Noticed that the gain for SRCL was bigger by one order than the other and seemed to kick SRM a lot.
  2. Satoru's idea: use 3f signals
    1. Plan to use REFL135I for PRCL, REFL51Q for MICH, and REFL51I for SPRCL.
    2. We intentionally misaligned SRM by changing the oplev setpoint and locked PRMI.
    3. We gradually aligned the SRM and hoped that PRMI would stay locked, but it turned out that MICH control was vulnerable to f1 resonance in SRC.
    4. Then we fully aligned SRM, and left all three servos on. We set triggers and waited for being locked. Sometimes AS34 buildup was held in < 1 sec, but it didn't last for long.

After several hours of trial and error, we concluded that we need to develop effective locking strategies.

Notes

While thinking of strategies, we found these issues:

  1. The Schnupp asymmetry in KAGRA is too big for stable control of MICH
    1. In LIGO and Virgo, they are O(cm), and the Michelson reflectivity is almost 0 for f1, which makes the SRC undercoupled. Thanks to it, MICH signal with 1f and 3f is relatively insensitive to SRCL and easier to keep locking than KAGRA.
    2. For KAGRA, it's overcoupled (Michelson: R=15%, SRM: R=85%) and f1 buildup in SRC is quite big. This makes MICH sensitive to SRC resonance for f1.
  2. We investigated the possibility of using f3. It is said that f3 doesn't resonate in any cavities, but Finesse simulations show that it actually resonates in both PRC and SRC. Are we wrong, or are the simulations?
MIF (ITF Control)
satoru.takano - 8:16 Friday 22 May 2026 (36944) Print this report
Comment to Strange offset in POP17 for locking SRY (36935)

We confirmed that this offset disappeared when ITMX was in MISALIGNED_BF state. For SRM alignment using SRX or SRY, we should misalign ITMY or ITMX by MISALIGNED_BF, not MISALIGNED.

Search Help
×

Warning

×