The RFC not locking was due to the fact that sometimes (more frequently in the last days) the script which resets the modulation amplitude of the 6 MHz sideband does not succeed, so the RFC doesn't get its locking signal back; launching the script manually solved the issue, but it reoccured at least another time during the weekend (and it was cured in the same way). Remember that cycling ITF_LOCK through DOWN->INIT->DOWN has the same effect, if done without rush (explanation below).

Looking into ITF_LOCK' s logfile (attached), it seems that this happens if the ITF unlocks exactly when, during lock acquisition, such a command is already in place for lowering that amplitude (i.e. at MICH_SET = 0.2 and PRITF_DF, before moving on to LOW_NOISE_1). In such cases there are two competing commands sent to the LNFS, which both act on steps of 1 dBm. One would guess that whichever commands finishes last "wins".

However, looking at the data (see Figure) we cannot see any competition: given the monotonic trend, it seems that only 1 "object" can talk to the LNFS at a given time, so the second command (the one in the DOWN state) is actually ignored, despite the logs; this is because the log messages are written by the Python script, not by the LNFS itself.

A countermeasure would be to improve the already present check in the DOWN state by adding a timer that, after a given time, re-sends the command; alternative solutions are implementing the reset in the INJ_MAIN node with a natural delay and only before relocking the RFC; or still inside ITF_LOCK, but even later when we lock the arms (but this would imply locking the RFC with the 8 MHz signal and the risk of confusion when locking non-standard configurations). The first "alternative" solution seems the best one in my opinion, to be discussed with INJ people.