Two lock loss occurred;
1st : May 28 2023 02:40:43.000
2nd : May 28 2023 05:03:38.000
1st No hint
2nd lock loss, manually moved to Down state to align the PR3(IPC glitch started)
We need to investigate why AS17Q became zero, but after this event, several controls accelerate to lock loss
Hi Yokozawa-san,
Thank you for your effort on lock loss study.
For lock loss study, it might be better to use ndscope of PRFPMI_ERR_FBK.yml, which can be opened from Commissioning Dock medm (and also shown in the monitor in the control room).
Especially, raw inputs of OMC PD is much more important than OMC_DC_SUM because we have 2nd-order dewhitening filters for the individual PDs, which could make the high frequency oscillation hard to see.
Also, yamamoto-kun reported MN outputs sometimes close to saturation and makes the IFO unstable.
So, it is also better to check the feedback signals to each stage of ETMX to confirm no saturation was occured at that time.
For the DAC saturation on MN, there is no DQ channel on coil basis.
So we may need to check both an EPICS record (K1:VIS-ETMX_MN_COILOUTF_H1_OUTPUT) and an overflow counter (K1:FEC-103_DAC_OVERFLOW_1_1).
(Though it's better to check all coils, checking MN_H1 should be enough for almost all cases because it is saturate at first.)
Just for the purpose of detecting the saturation, checking only overflow counter is enough.
Please see also /users/DET/tools/Segments/Script/RevealSegments/templates/lockloss_general.yml.
It contains required channels to check only known lockloss reasons.
Roughly 80% of lockloss can be explained by this template except PR3_Y problem it was already fixed in klog#25379.
So it helps us to remove lockloss by known reasons in order to investigate unknown reasons.