EDIT on X arm: I found different settings in C1SUS_ITMX, with respect to ETMX, ITMY and ETMY (namely LSC/DAMP is OFF and LSC/BIAS is ON); I don't know if this is intended or for some reason ITMX was not recovered properly after the lock loss, so I didn't change anything, but it may be worth looking into that.
Still no luck in recovering the X arm, I am giving up for tonight; honestly I didn't try many things, as I don't know well the system and didn't want to mess things up.
Preliminary results so far:
I confirm that the best settings for the ramp of the ALS scan are 20s and 500 points; this causes however the script to be fairly slow (80s for the scan/data collection, 7s for the coarse peak finding, 17s for the fine peak finding, total ~2 min); in the best cases the TR*_OUT obtained is around 0.90, as shown in the first plot (early in the evening, all the following plots are in chronological order, if that can help finding the reason for the X arm misbehaviour...):
However, after a few minutes somehow the TR*_OUT went down a bit, without any kind of intervention; also, it is visible the instability of the X arm:
Even when X arm was somewhat stable, its performance and robustness were (far) worse than the Y arm ones:
The following plot shows (about the Y arm only) that there is still some margin, as the maximum value of TRY_OUT is not completely kept at the end of the procedure:
Finally the last plot I managed to obtain, before the X arm went completely crazy...
The next step, after obviously figuring out the X arm situation, is to try some averaging during the fine scan, I don' t know if this will improve the situation, however it shouldn't impact on the execution time. Tomorrow I'll post something more detailed on the script itself and the wavelet implementation.