jim.warner@LIGO.ORG - posted 01:54, Thursday 13 June 2019 - last comment - 13:36, Thursday 13 June 2019(49877)
TCS_ITMY_CO2 guardian just knocked us out of OBSERVE, again
Just like last night, ITMY TCS CO2 guardian just kicked us out of observe again. I don't see this node on the SDF overview, so I couldn't see what it was complaining about, but, once again, it resolved itself on its own.
Comments related to this report
jim.warner@LIGO.ORG - 05:22, Thursday 13 June 2019 (49878)
And it just happened again. Finally found the node on the GRD overview (it's not on the SDF overview) and looking at the log, it looks like the laser is coming unlocked and the guardian has to change some PZT set point. If this is going to keep knocking us out of observe every twenty minutes, can we unmonitor the stuff the guardian is touching?
Don't unmonitor as TCS glitch has a direct impact on DARM (though I don't know if that could be above or close to the noise floor). Right thing to do is to fix it. I sent an email to Aidan.
david.barker@LIGO.ORG - 13:36, Thursday 13 June 2019 (49892)
Just to reiterate Corey's point, this is not a SDF issue. The SDF diffs for the h1tcscs model has been zero the whole time, and the channels which are being changed by guardian are not being monitored by SDF. Remember that the SDF screen shows models, the GRD screen shows nodes.
Stepped out to get a cup of coffee and when I came back, we were out of observe again. Not sure what happened, but I suspect that this happened again.
And it just happened again. Finally found the node on the GRD overview (it's not on the SDF overview) and looking at the log, it looks like the laser is coming unlocked and the guardian has to change some PZT set point. If this is going to keep knocking us out of observe every twenty minutes, can we unmonitor the stuff the guardian is touching?
2019-06-13_12:38:33.009662Z TCS_ITMY_CO2 [LASER_UP.run] laser unlocked. jumping to find new locking point
2019-06-13_12:38:33.077630Z TCS_ITMY_CO2 JUMP target: FIND_LOCK_POINT
2019-06-13_12:38:33.078431Z TCS_ITMY_CO2 [LASER_UP.exit]
2019-06-13_12:38:33.129241Z TCS_ITMY_CO2 JUMP: LASER_UP->FIND_LOCK_POINT
2019-06-13_12:38:33.129853Z TCS_ITMY_CO2 calculating path: FIND_LOCK_POINT->LASER_UP
2019-06-13_12:38:33.129853Z TCS_ITMY_CO2 new target: LOCK_LASER
2019-06-13_12:38:33.130841Z TCS_ITMY_CO2 executing state: FIND_LOCK_POINT (-12)
2019-06-13_12:38:33.135027Z TCS_ITMY_CO2 [FIND_LOCK_POINT.enter]
2019-06-13_12:38:33.262513Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SERVO_GAIN_SW2 => 1024
2019-06-13_12:38:33.388425Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SERVO_GAIN => OFF: OUTPUT
2019-06-13_12:38:33.389545Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SERVO_GAIN_SW1 => 16
2019-06-13_12:38:33.641183Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SERVO_GAIN => OFF: FM1
2019-06-13_12:38:33.642014Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_CHILLER_SERVO_GAIN_SW1 => 20
2019-06-13_12:38:33.894316Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_CHILLER_SERVO_GAIN => OFF: INPUT, FM1
2019-06-13_12:38:34.146424Z TCS_ITMY_CO2 [FIND_LOCK_POINT.main] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT => ON: OFFSET, OUTPUT
2019-06-13_12:38:34.194611Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 3.5
2019-06-13_12:38:34.197203Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] = 3
2019-06-13_12:38:37.201594Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] done
2019-06-13_12:38:37.333333Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 7.0
2019-06-13_12:38:37.336119Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] = 3
2019-06-13_12:38:40.336862Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] done
2019-06-13_12:38:40.455196Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 10.5
2019-06-13_12:38:40.466286Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] = 3
2019-06-13_12:38:43.466342Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] done
2019-06-13_12:38:43.580825Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] ezca: H1:TCS-ITMY_CO2_PZT_SET_POINT_OFFSET => 14.0
2019-06-13_12:38:43.581786Z TCS_ITMY_CO2 [FIND_LOCK_POINT.run] timer['wait'] = 3
https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=49865
Don't unmonitor as TCS glitch has a direct impact on DARM (though I don't know if that could be above or close to the noise floor). Right thing to do is to fix it. I sent an email to Aidan.
Just to reiterate Corey's point, this is not a SDF issue. The SDF diffs for the h1tcscs model has been zero the whole time, and the channels which are being changed by guardian are not being monitored by SDF. Remember that the SDF screen shows models, the GRD screen shows nodes.