Though I couldn't find a problem on the guardian code of IRX_HANDOVER state, this state might not work as expected.
Anyway, it stopped with the software saturation at K1:LSC-DGCARM_OUT.

I found VERTEX guardian stays at IRX_HANDOVER (375) state with the notification as "DGCARM were engaged.". On the other hand, there is no IR flash and output of DGCARM reaches software limit as -2000. So I checked guardian behavior one-by-one.
 

1. FIND_IRX_RESONANCE (370) state seemed to work fine and VERTEX guardian moved to IRX_HANDOVER (375) state as shown in FIg.1. Top panel is state number of VERTEX guardian and the 2nd top panel shows the normalized TRANS power of IRX.


2. In "main" function, IN1 gain and polarity of CARM CMS were set as shown in the 3rd top panel.


3. Then input matrix and ramp time were set in counter==0 as shown in the 4th top panel.


4. Next (counter==1), load button of input matrix was pressed as shown in the 5th top panel. It seemed to be pressed at the same time with setting input matrix and ramp time according to DAQ-ed data. Though there is no proof, this may be due to the fact that DAQ and Guardian are not aligned at the beginning of 1-second each other.


5. After then, ramping matrix value was continued in 2 seconds, LSC-DGCARM_OUT reached -2000, and IR flash was lost soon (see also Fig.2).


6. Though TRANS power check should work after finishing matrix ramping, checks in counter==2 was somehow passed and notification as "DGCARM were engaged" appeared in counter==4 as shown in Fig.3. According to the guardian log (see below), waiting ramp time was surely inserted at least before counter==4.

If counter==2 was executed after waiting matrix ramping, a check of software limit for LSC-DGCARM_OUT in counter==2 should be worked and polarity of DGCARM should be flipped. But guardian didn't work so. I guess conuter==2 was executed before self.timer was set due to some reasons.

I don't think there is a problem on current implementation of IRX_HANDOVER state. But if same issue is repeated, it might be better to insert one more self.counter state between "load matrix" in counter==1 and "software limit check" in counter==2.


-----
Related guardian log
2024-06-29_04:14:10.450203Z VERTEX [IRX_HANDOVER.enter]
2024-06-29_04:14:10.458330Z VERTEX [IRX_HANDOVER.main] timer['waiting'] done
2024-06-29_04:14:10.458562Z VERTEX [IRX_HANDOVER.main] timer['waiting'] = 0
2024-06-29_04:14:10.458739Z VERTEX [IRX_HANDOVER.main] timer['checking'] = 5
2024-06-29_04:14:10.460262Z VERTEX [IRX_HANDOVER.main] ezca: K1:LSC-CARM_SERVO_IN1GAIN => 2
2024-06-29_04:14:10.462438Z VERTEX [IRX_HANDOVER.main] ezca: K1:LSC-CARM_SERVO_IN1POL => 0
2024-06-29_04:14:10.655099Z VERTEX [IRX_HANDOVER.run] ezca: K1:LSC-PD_DOF_MTRX_SETTING_9_27 => 0.3
2024-06-29_04:14:10.656253Z VERTEX [IRX_HANDOVER.run] ezca: K1:LSC-PD_DOF_MTRX_TRAMP => 2
2024-06-29_04:14:10.716544Z VERTEX [IRX_HANDOVER.run] ezca: K1:LSC-PD_DOF_MTRX_LOAD_MATRIX => 1
2024-06-29_04:14:10.716807Z VERTEX [IRX_HANDOVER.run] timer['waiting'] = 2
2024-06-29_04:14:12.716971Z VERTEX [IRX_HANDOVER.run] timer['waiting'] done
2024-06-29_04:14:12.831828Z VERTEX [IRX_HANDOVER.run] USERMSG 0: DGCARM were engaged.
2024-06-29_04:14:15.459277Z VERTEX [IRX_HANDOVER.run] timer['checking'] done

Thank you for your comments, Yamamoto-san. 
The decision should work as it should, but I don't know why - I'll look into it again when I try PRXARM.

Detail about klog30172

• Added 6 dB of gain to GRX_PDH_CMS with reference to klog30125. The offset of GRX_PDH_CMS was adjusted from 2.81 to 6.15 so that the error signal comes around zero.(FIG1)
• We measured the transfer function at CARMCMS with the ALS locked.(FIG2) To increase the UGF, we raised it by 6 dB.(FIG3) It is ideal that the transfer function is more than twice as high as before GR when both GR and IR are turned on. This time it is about four times(FIG4). After turned off IN2 of GR, to increase the UGF, 10 dB was added so that the 0 dB phase is at the top of the phese bubbles.(FIG5)
• We adjusted the offset of COMMON_CMS to the previous job, but reverted the offset of COMMON_CMS to -0.81.

In VERTEX Guardian

• Compared to klog30134, this section summarises the additions in VERTEX Guardian.
  Beyond that, work is still under construction on the state to transition from 3F to 1F. 
  In the DOWN state, the following changes are changed back, but the HWP of IFO_REFL is not turned in the state here.(FIG6)
  • PREP_FM_FOR_PRC: Branches from LOCK_PREP to MICH and PRC. In this state, turn on the calibration filters of the sensors(REFLRF135 and POPRF45) used for PRCL and turn HWP of IFO_REFL to 148 deg for PRX lock.
  • REDUCE_REFL_POWER: Turn HWP to be 178deg for PRXARM after locked PRX. Also, turn on the filter that raises PRCL1 by 10 dB because the gain at PRX is reduced by turning HWP.
  • ENGAGE_PNC_FIB_X: Request PHASE_LOCKED to ALS_FIBX/PNCX. (Request DOWN to ALS_FIBX/PNCX in DOWN state of VERTEX guadian).
  • IRX_HANDOVER: In ENGAGE_ALSX, the ARM error signal by GR is fed back to IMC, EOM of the IR laser, etc. In FIND_IRX_RESONANCE, it finds the peak of the IR by adjusting the offset of the signal fed back to IMC and EOM. When it is finished, go to this state. First, turn on DGCARM. By turning on it, the IR merges with the error signal of the ALSX loop. DGCARM has an integrator filter, which increases the gain of the IR signal relative to the GR signal in the DC band , so that the GR is following the IR. After the loop is closed with DGCARM ON, switch from IN2 (the DGCARM and the GR signal) to IN1 (the analogue signal in IR) in ALS_CARM. Also, reset the signals accumulated in DGCARM due to being switched off at IN2. And request DOWN in ALS_FIBX/PNCX.
  • PRXARM_LOCKED_WITH_3F: State that PRXARM_LOCK is completed.
  • TRANSITION_TO_1FSIG_PRXARM: [Under construction] State to switch from RF135 to POPRF45. The loop cannot be closed at POPRF45 even if the error signal sign is switched. This may be due to a bad alignment.
  • PRXARM_LOCKED: [Under construction] State when TRANSITION_TO_1FSIG_PRXARM is completed.

Note

PRXARM kept for about 8 hours. (Down was requested for other work.) Stability is excellent. (FIG7)