Reports 1-1 of 1 Clear search Modify search
MIF (General)
satoru.takano - 10:53 Sunday 31 May 2026 (36972) Print this report
Initial alignment updates

[Takano]

Summary

Many updates on the initial alignment for DRMI were made. They are implemented in the initial alignment guardian, but no documents for them have been written so far. Also, PRMI ADS problem was solved (I hope).

Detail

When we tried SRMI locking, it seemed that the alignment to AS port looked bad. Until then, we aligned the beam up to OMMT1 using the OMMT2 trans QPD, but left the alignment to OMC as is. We already have the guardian state for the alignment to OMC using OMMT2 and OSTM, but they didn't work because the power after the SRM is now attenuated by 15%. To fit the guardian to the current situation, we added new states for OMC alignment, including OMMT1 alignment using the OMMT2 trans QPD.

The revised procedure is as follows:

  1. Lock one of the arm cavities (Y arm is easier, because normally we align the beam to OMC after Yarm alignment)
    1. Set PRM to MISALIGNED_BF in order to increase the input power later
    2. Because of this, these states are different from the normal IR_LOCKED state, in which PRM is in MISALIGNED_FOR_LOCK_ACQ state.
  2. Increase the input power to 8.5 W while keeping the arm cavity locked
    1. When the input power is 8.5 W, OMC transmission is 30 mW.
    2. The HWPs on both PSL table and REFL table are rotated in iterations. When the input power is increased, the power going to REFL PD gets increased; to compensate for this change, the HWP on REFL table is rotated.
  3. Engage OMMT2 transmission QPD control loop for OMMT1 alignment
  4. Lock OMC and engage OMC QPD control loop for OMMT2 and OSTM loop

These actions were written in INITIAL_ALIGNMENT guardian.

While locking OMC, we faced the guardian error again, which was once reported here. The previous procurement didn't work well unfortunately, but YamaT-san finally found a solution and now it's resolved.

After OMC alignment, I tried to lock PRMI, but it failed even with a decent alignment (POP90I buildup of 0.5). Looking at the error signal, REFL51Q had an offset. I subtracted the dark offset, but still an offset of 2.6 was there. I subtracted it manually by adding an offset in MICH1 filter, then I could lock PRMI, but ADS for it didn't work. Through many many investigations, I found that the angle of REFL HWP was different: when ADS for PRMI worked well, the angle was 125; when it did not, it was 146. The angle depended on which guardian we called to lock PRMI; when we didn't use INITIAL_ALIGNMENT guardian, the angle was 125 and ADS worked successfully, but INITIAL_ALIGNMENT guardian set the HWP angle to 146 when it was called. I changed the guardian so that we set the angle to 125 initially, then we could successfully engage the ADS loop for PRMI. This also removed the REFL51Q offset and PRMI was locked more easily than before.

 

Comments to this report:
takahiro.yamamoto - 16:58 Sunday 31 May 2026 (36975) Print this report
A camera issue in OMC_LSC guardian came from an incomplete bug fix in klog#36772.

We found that this error was caused by multiple accesses to a subprocess pipe in counter==3. It was solved by allowing the pipe access only in subcounter==0. This fix worked well in the FIND_RESONANCE state. A same code fix around TEM00 analysis in the FIND_RESONANCE state was applied to FIND_RESONANCE_FOR_10W and FIND_RESONANCE_FOR_IAL_WITH_RF states.

Old code:
 303         elif self.counter == 3:
 304             if self.p.poll() is not None:
 305                 a = self.p.communicate()
 306                 mode_number = int(a[0][:-1])
New code:
 303         elif self.counter == 3:
 304             if self.p.poll() is not None:
 305                 if self.subcounter == 0:
 306                     a = self.p.communicate()
 307                     self.mode_number = int(a[0][:-1])

By the way, 1-minute-long waiting for the interval limitation of the new pylon-camera-server still remains in the DOWN state. The interval issue had been already solved in klog#36397 by using the client side snapshot implemented in klog#36370. So the waiting time in the DOWN state should be now unnecessary.
satoru.takano - 23:33 Sunday 31 May 2026 (36976) Print this report

Attached figures show the latest open-loop transfer functions of PRCL and MICH in PRMI 3f locked after changing the REFL HWP angle. The overall gain of each loop was tuned to match the old measurement.

Images attached to this comment
Search Help
×

Warning

×