Reports 1-1 of 1 Clear search Modify search
AdV-COM (automation)
bersanetti, mantovani - 17:18 Thursday 16 June 2022 (56169) Print this report
Autorelock implementation

Today we worked on the remaining part of the implementation of the Autorelock feature; what was missing was dealing correctly with the self-parking of the PR mirror due to the tripping of the protection for SDB1; we made some changes to the code of the nodes ITF_LOCK and DRMI_LOCK and the results are the following, although obtained with low statistics:

  • the automation is not stuck anymore in case of PRM tripping and the full interferometer going to DOWN (i.e. in any state higher then LOCKED_CARM_OFFSET_MID);
  • if only the DRMI unlocks but the arms stay locked on the green with 3kHz of CARM offset the automation should not get stuck anymore, but as a drawback PRM and SRM won't be kept aligned before trying again and they will get misaligned and realigned again, which is safe but time-consuming and ultimately annoying; another test is being studied in order to overcome this.

In any case, even if some more statistics would be beneficial, I guess we can try to make a first autorelock attempt during the night.

Comments to this report:
bersanetti - 2:38 Friday 17 June 2022 (56174) Print this report

Tonight at 23:53 UTC I found the ITF in an unexpected state; already, a possible fix for the issue reported in the second bullet point of the original entry was in place:

  • ITF_LOCK was managed by ITF_STATUS (the timeout was reached), but it wasn't in the fallback state (LOCKED_ARMS_IR); this is a second occurrence of the bug already witnessed last Sunday;
  • instead, ITF_LOCK was trying to lock the DRMI, but the PR was still misaligned (after tripping); so, a first hypothesis is that the countermeasure that was put in place is too fast and cannot catch the PR being tripped in order to bring it back to the aligned position; in any case, the automation was not stuck, the ITF was not locking the PR being misaligned, but for the same reason the ITF was safe as no big flashes were going around;
  • then, I manually asked to realign the PR and the lock could proceed; I could witness the same effect again live at around 23:59 UTC; this was cured in the same way;
  • at the following attempt, the lock of the DRMI was successfull and the lock acquisition could proceed; unfortunately, the ITF unlock while trying the handoff of CARM to the IR on the MC (00:03:45 UTC, unrelated to automation); this time, the autorelock correctly put the ITF in the fallback state, LOCKED_ARMS_IR.

The ITF was left in the LOCKED_ARMS_IR state, autorelock disengaged at 00:37 UTC and ITF_LOCK left unmanaged (standard state).

Search Help
×

Warning

×