Displaying report 1-1 of 1.
Reports until 09:34, Friday 08 November 2024
H1 ISC
oli.patane@LIGO.ORG - posted 09:34, Friday 08 November 2024 - last comment - 11:20, Monday 18 November 2024(81142)
Edit to ISC_LOCK to make sure the IMC is locked before leaving READY

Camilla, Oli

Recently, because of the PSL/IMC issues, we've been having a lot of times where the IFO (according to verbals) seemingly goes into READY and then immediately goes to DOWN because the IMC is not locked. Camilla and I checked this out today and it turns out that these locklosses are actually from LOCKING_ARMS_GREEN - the checker in READY that is supposed to make sure the IMC is locked was actually written as nodes['IMC_LOCK'] == 'LOCKED' (line 947), which just checks that the requested state for IMC_LOCK is LOCKED, and it doesn't actually make sure the IMC is locked. So READY will return True, it will continue to LOCKING_ARMS_GREEN, and immediately lose lock because LOCKING_ARMS_GREEN actually makes sure the IMC is locked. This all happens so fast that verbals doesn't have time to announce LOCKING_ARMS_GREEN before we are taken to DOWN.

To (hopefully) solve this problem, we changed nodes['IMC_LOCK'] == 'LOCKED' to be nodes['IMC_LOCK'].arrived and nodes['IMC_LOCK'].done, and this should make sure that we stay in READY until the IMC is fully locked. ISC_LOCK has been reloaded with these changes.

Comments related to this report
thomas.shaffer@LIGO.ORG - 11:20, Monday 18 November 2024 (81336)OpsInfo

The reason it has been doing this is because there is a return True in the in main method of ISC_LOCK's READY state. Then a state returns True in its main method, it will skip the run method.

I've loaded the removal of this in ISC_LOCK.

Displaying report 1-1 of 1.