jeffrey.kissel@LIGO.ORG - posted 11:55, Friday 01 June 2018 - last comment - 13:44, Friday 01 June 2018(42283)
H1 SUS EX (ETMX and TMSX) are ready for Doors
J. Kissel I've repeated the standard transfer functions on both SUS ETMX and TMSX to confirm that we're ready for doors this afternoon. There was a little bit of confusion on TMSX (see details in comments below), but I can now confirm that all suspensions are healthy, and we're ready for doors. Data templates: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGM0/Data/ 2018-06-01_1602_H1SUSETMX_M0_Mono_WhiteNoise_L_0p02to50Hz.xml 2018-06-01_1602_H1SUSETMX_M0_Mono_WhiteNoise_P_0p02to50Hz.xml 2018-06-01_1602_H1SUSETMX_M0_Mono_WhiteNoise_R_0p02to50Hz.xml 2018-06-01_1602_H1SUSETMX_M0_Mono_WhiteNoise_T_0p02to50Hz.xml 2018-06-01_1602_H1SUSETMX_M0_Mono_WhiteNoise_V_0p02to50Hz.xml 2018-06-01_1602_H1SUSETMX_M0_Mono_WhiteNoise_Y_0p02to50Hz.xml /ligo/svncommon/SusSVN/sus/trunk/QUAD/H1/ETMX/SAGR0/Data/ 2018-06-01_1642_H1SUSETMX_R0_WhiteNoise_L_0p02to50Hz.xml 2018-06-01_1642_H1SUSETMX_R0_WhiteNoise_P_0p02to50Hz.xml 2018-06-01_1642_H1SUSETMX_R0_WhiteNoise_R_0p02to50Hz.xml 2018-06-01_1642_H1SUSETMX_R0_WhiteNoise_T_0p02to50Hz.xml 2018-06-01_1642_H1SUSETMX_R0_WhiteNoise_V_0p02to50Hz.xml 2018-06-01_1642_H1SUSETMX_R0_WhiteNoise_Y_0p02to50Hz.xml /ligo/svncommon/SusSVN/sus/trunk/TMTS/H1/TMSX/SAGM1/Data/ 2018-06-01_1552_H1SUSTMSX_M1_WhiteNoise_L_0p02to50Hz.xml 2018-06-01_1552_H1SUSTMSX_M1_WhiteNoise_P_0p02to50Hz.xml 2018-06-01_1552_H1SUSTMSX_M1_WhiteNoise_R_0p02to50Hz.xml 2018-06-01_1552_H1SUSTMSX_M1_WhiteNoise_T_0p02to50Hz.xml 2018-06-01_1552_H1SUSTMSX_M1_WhiteNoise_V_0p02to50Hz.xml 2018-06-01_1552_H1SUSTMSX_M1_WhiteNoise_Y_0p02to50Hz.xml
Non-image files attached to this report
Comments related to this report
Regarding the TMTS confusion: Most of the measurement time was focused on the confusing transfer function that appeared in essentially only the T to T top mass (M1) transfer function. See attached screenshot showing (a) BLACK A reference from 2018-05-30 (see LHO aLOG 42231). Both stages of BSC-ISI are locked during this measurement. (HEPI is still locked.) (b) BLUEThis morning's 2018-06-01 confusing results, where the 1.4 Hz mode has split into several different modes at 1.23, 1.36, 1.43, 1.54, and 1.7 Hz. Both stages of the BSC-ISI are floating, but *not* damped during this measurement. (HEPI is still locked.) (c) REDThe same measurement, with the BSC-ISI damping loops ON. (HEPI is still locked.) In (a) and (c) the 1.37 Hz, T2, Transverse mode is exactly where expected. However with the ISI undamped in (b), the mode frequencies called above show up instead. The weird thing is that none of these frequencies corresponds to any SUS resonant mode in the chamber. Maybe they're the BSC-ISI modes, but I'm surprised that they're that high Q. The real point of confusion was that the BSC-ISI overview screens' border doesn't go red (normally indicating the inability to drive the DACs) upon an SEI IOP watchdog trip. The SUS IOP watchdogs had been cleared, but the only ISI-overview indication of the trip was a small red box above the DAC outputs, and that the DAC outputs were zero even with ISI damping loops ON. We should make the IOP watchdog actuation blockage a little more clear (and to be fair, it's only infrequently that I pull up the BSC-ISI screen at all when taking SUS transfer functions, but that's user conditioning and not anyone's fault). Along the way, assuming it was some sort of new, subtle rubbing that appeared between 2018-05-30 and today, I tried adding large offsets in all directions. First vertical, because I suspected a temperature drift by trending the vertical OSEMs in the chamber. When that revealed no change, I tried a Roll offset, and tried with & without the (rather large) P & Y alignment offsets. No dice. T'was then that I started thinking about the isolation level of the BSC-ISI and noticed the IOP watchdog, untripped it, and all became well. C'est la vie de mise en service!
Images attached to this comment
