New Lockloss Tag Request: When ASC Error Signals Hit "Soft Limiters"

In order to limit the speed and increase the robustness of the collection of ASC loops, we installed "soft limiters" which create a user-defined limit to the ASC error signals, and thus throttling the speed at which a limited loop pushes the optic around in its respective degree of freedom -- allowing all the other, slower, unlimited loops to catch up "their" DOFs.

Recently, we've seen a series of lock losses around when we engage the full IFO ASC system, with INP1, CHARD, and SRC2 loops (we guess) are limited in such a way that we don't think the collection of loops have time to steer things to the right place, resulting in some loops flying off in to the weeds, pulling down intra cavity powers, and eventually causing a "quick" lock loss from lack of light levels. See some of the lock losses we've been following up in LHO aLOG 51942: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=51942

We should create a tag for these kinds of lock losses. The symptom being that any or several ASC error signals "hits the rail" of its soft limiter. Example set of channels to check / compare via time series: H1:ASC-CHARD_P_SMOOTH_INMON (the "real" error signal prior to throttling) vs. H1:ASC-CHARD_P_INMON (the "limited" error signal that will appear "railed") against H1:ASC-CHARD_P_SMOOTH_LIMIT (the value at which the "real" error signal is limited). This tag would look for such railing in all the ASC degrees of freedom that have a smooth limit installed and ON (via the H1:ASC-DHARD_P_SMOOTH_ENABLE). As of Sep 2019, these DOFs are PRC2, INP1, CHARD, SRC1, and SRC2 [which would replace "CHARD" in the above example] in both pitch and yaw [P is pitch in the above example, Y would be for yaw].