(In this post I mean "railing" as "parked at the maximum actuation range", where "oscillation" means "PZT is fighting the EOM") The FSS Fast Path has been railing recently, preventing the FSS from locking. (Pic 1) It seems as though FSS_OSCILLATION does not in fact monitor the FSS RMS, but triggers on a threshold. When the FSS voltage would pass a certain value, the PSL_FSS guardian would send it to state FSS_OSCILLATING. This state brings the common gain down to -10 dB, then slowly back up to wherever it started. This works great for stopping oscillations, but not for permanent rails. I modified the PSL_FSS code to increase the oscillation threshold from 0.6 to 3 V for five seconds whenever the fast voltage is railed at greater than 10 volts with extremely low RMS. This should allow the FSS loop to close and bring the temperature within range. Railing hasn't happened again, so I haven't had a chance to test the state, but it does still suppress actual oscillations.
[Hang Gabriele]
There might be some problem with the logic of the FSS_OSCILLATION state. This morning the guardian was continuously reducing the gain to -10 db, and then ramping it up to more than +100 db. Our guess is that the self.high_gain variable which is set in the main() function got a wrong, large value. Maybe we should hard code a gain of 20 db there?
We fix the problem by stopping the guardian, setting the FSS common gain to 20 db and restarting the guardian.
For now we hacked the PSL_FSS guardian the FSS_OSCILLATING state so that the FSS_COMMON_GAIN could not exceed 20 dB. We could thus lock the IMC without needing to manually pause the PSL every time.
Specifically, we modified the original
if not ezca['FSS_OSCILLATION'] or not ezca['FSS_RESONANT']
into:
if (not ezca['FSS_OSCILLATION'] or not ezca['FSS_RESONANT']) and (ezca['FSS_COMMON_GAIN']<20.)
H1:PSL-FSS_OSCILLATION is set whenever H1:PSL-FSS_PC_PP exceeds the threshold.
More info in alog 43970.
Above comment of mine, "H1:PSL-FSS_OSCILLATION is set whenever H1:PSL-FSS_PC_PP exceeds the threshold.", is totally false, see Jason's alog.