[Yokozawa, Yuzu]
We performed the lockloss investigation of 2024/09/09 10:36:18 JST. The main cause of this lockloss was due to the saturation of K1:PSL-PMC_HEATER_IMMON, which is used for the control of PMC. (right top of Fig)
Working memo
- Initially, we checked the LSC_LOCK and ASC_LOCK guardian. The both messages were 'PRMI seems to be unlocked'. The condition to fail this decorator is ezca['LSC-POP_PDA2_RF90_I_NORM_MON'] > 0.1. But, this happened after the LSC(ASC)_LOCK guardian entered in the LOCKLOSS state (see 1st, 2nd, 4nd columns of Fig).
- This is strange causally, because the timing (LSC_LOCK guardian judged the LOCKLOSS) is ~200ms faster than the timing (actually the decorator satisfied).
- Although we chatted with YamaT-san, it's still unknown. We will check the future lockloss carefully about this earlt timing of 200ms.
- The IO and IMC guardian was in DOWN state after the LOCKLOSS of LSC_LOCK guardian.
- After the several investigations, we found the PMC was in the DOWN state before the LOCKLOSS of LSC_LOCK guardian (see 1st and 5nd columns of Fig). The error message was 'PMC lost lock. Jump into the DOWN state'. The condition to fail this decorator is K1:PSL-PMC_PZT_HV_MON_OUTPUT < 300 (Fig). This seems to be the cause of the lockloss.
- Based on Ushiba-san's comment, there is another control for PMC by using K1:PSL-PMC_HEATER_INMON. But it was saturated as -15000 since 9/5(Fri) 8:50 JST (Fig). To saturate the signal, it took 10 minutes.
- Because K1:PSL-PMC_HEATER_INMON was saturated, the K1:PSL-PMC_PZT_HV_MON_OUTPUT was mainly used to control the PMC and was saturated.
- Note that I saw the log that YamaT-san entered the PSL room on Friday twice (10:48 and 11:14). But, the timing to recover from the saturation is different (10:30 and 11:36) (Fig) (Fig). It looks not coincident.
- We are not sure why K1:PSL-PMC_HEATER_INMON was saturated.
