Displaying report 1-1 of 1.
Reports until 09:44, Wednesday 03 May 2023
H1 CAL (CAL, DetChar, ISC, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 09:44, Wednesday 03 May 2023 (69284)
PCALY Thermalization Line Amplitudes Reduced by 10% in CAL_AWG_LINES
J. Kissel

Perusing the operations log from last night (LHO:69274), I noticed last night that Camilla has accepted the H1:CAL-PCALY_DARM_GAIN set at 1.0 in the h1caley SDF snap, which restores the PCALY "thermalization" line amplitudes to their original value (from LHO:68947) of 
                                   _FREQ     _SINGAIN
    H1:CAL-PCALY_PCALOSC4_OSC      8.925     3000
    H1:CAL-PCALY_PCALOSC5_OSC     11.575     1000
    H1:CAL-PCALY_PCALOSC6_OSC     15.275     120
    H1:CAL-PCALY_PCALOSC7_OSC     24.500     80

However, a few days ago we noticed that PCALY was regularly saturating its Optical Follower Servo (OFS), so I took a quick and dirty way out of reducing the gain of the filter bank that all these PCAL lines go through, H1:CAL-PCALY_DARM_GAIN, from 1.0 to 0.9 (aLOGged "sneakily" as a comment, in LHO:69160).

While I accepted this lower 0.9 gain in the SDF system at the time, I hadn't edited CAL_AWG_LINES to restore it to 0.9 in between cycles of LINES_ON vs IDLE. Thus, when ISC_LOCK cycled from, say, NOMINAL_LOW_NOISE to NLN_CAL_MEAS back to NOMINAL_LOW_NOISE, and request CAL_AWG_LINES to go from LINES_ON to IDLE back to LINES_ON, the gain would pop back up to 1.0. In the rush to get back into observing, then, folks -- through no fault of their own other than not getting the memo -- would blindly accept 1.0 (as Camilla did last night), and I'd come in the next day and reduce it to 0.9.

I've now just reduced the amplitude of these lines by 10% in the CAL_AWG_LINES code, to 
                                   _FREQ     _SINGAIN
    H1:CAL-PCALY_PCALOSC4_OSC      8.925     2700
    H1:CAL-PCALY_PCALOSC5_OSC     11.575     900
    H1:CAL-PCALY_PCALOSC6_OSC     15.275     108
    H1:CAL-PCALY_PCALOSC7_OSC     24.500     72
such that the H1:CAL-PCALY_DARM_GAIN can always remain at 1.0, as is *still* coded to be set in the transition and now matches the SDF system.

I guess, really, this gain should also be not monitored by the SDF system (as is typical for "guardian controled EPICs records"), but these lines are temporary engineering run lines anyways so eventually we'll want to *re* monitor, and SDF control the gain, so for now I'll leave it as is.

This change took us out of observing at 2023-05-03 16:22 UTC, and we were back in observing by 2023-05-03 16:23 UTC.
Displaying report 1-1 of 1.