We have observed today some problems when locking the green (I observed already one similar on wednesday). We can see that at some point hte SWEB LC TX gets kicked by approximately 4 urad and the green unlocks (see Figure 1). This triggers an increase of th epower in reflection of the cavity that triggers an unlock. I don't understand the origin of this problem.
I can see that when this jump occurs the flag SWEB_LC_B8_QD_enbl_safe goes to 0 abruptly.
The changes in SWEB TX are driven by the automation, and also partly due to the difference in beam centering between the lock acquisition and the LN3 state. The bench saves what is the correct alignment for itself based on data taken when light is present on the bench, which means in LN3 in practice.
Figure 1. There is a series of changes between two states of benche alignment. At TX=39urad the bench is at the saved value of alignment, while at around 42urad it is following the infrared beam.
Figure 2. The switch to enable the drift control using the quadrant drops to zero, and shortly after the beam alignment changes. The power on the photodiodes remains the same, so it is not the cause of the switch change.
The cause of the switch change is the request by ARMS_LOCK to disable the drift control, and a few seconds late it requests it back.
2025-05-02-11h23m57-UTC>INFO...-AcRelayChTransCmSet> LC_B8_QD_enbl ask to be set to -1 by ARMS_LOCK
2025-05-02-11h23m57-UTC>INFO...-AcRelayChTranSet> LC_B8_QD_enbl, mode set to -1
2025-05-02-11h24m03-UTC>INFO...-AcRelayChTransCmSet> LC_B8_QD_enbl ask to be set to 1 by ARMS_LOCK
2025-05-02-11h24m03-UTC>INFO...-AcRelayChTranSet> LC_B8_QD_enbl, mode set to 1
2025-05-02-11h27m16-UTC>INFO...-AcRelayChTransCmSet> LC_B8_QD_enbl ask to be set to -1 by ARMS_LOCK
2025-05-02-11h27m16-UTC>INFO...-AcRelayChTranSet> LC_B8_QD_enbl, mode set to -1
2025-05-02-11h27m22-UTC>INFO...-AcRelayChTransCmSet> LC_B8_QD_enbl ask to be set to 1 by ARMS_LOCK
2025-05-02-11h27m22-UTC>INFO...-AcRelayChTranSet> LC_B8_QD_enbl, mode set to 1
2025-05-02-11h30m28-UTC>INFO...-AcRelayChTransCmSet> LC_B8_QD_enbl ask to be set to -1 by ARMS_LOCK
This looks like a systematic problem, and seem to have already been happening systematically before, for example in March. The difference now is that the beam is off-center in LN3 so the difference between tracking the beam and remembering the old position become more important.
There is a 100 second time, which I think is the duration to wait to save the new beam position, and the lock acquisiton may be moving on too quickly when the timer (in Acl) reaches only 90s. I have shorted the timer to 80s, we will see at the next lock acquisition if that solves the problem or make it worse.
ACL_RELAY_CH LC_B8_QD_enbl_safe "" LC_LOOP_FREQ 80 0.1 -2 "LC_B8_QD_check" 0.97 0.90 ">="
If that solves the problem we should do the same adjustment for SNEB.
