Reports until 12:22, Thursday 04 February 2016
H1 AOS
hugh.radkins@LIGO.ORG - posted 12:22, Thursday 04 February 2016 - last comment - 09:35, Friday 05 February 2016(25385)
Update Guardian Re SEI Log 910-- Correcting DAMP path Turn Off on WD Trip--WP 5723

Updated userapps: isi/common/guardian/isiguardianlib/watchdog:

hugh.radkins@opsws1:watchdog 0$ svn up
U    states.py
Updated to revision 12546.
 

guardctrl restart ISI_ETMX_ST2:  this caused the guardian to deisolate stage2.  Not what I experienced Tuesday when I did similar..  When I restarted stage1 guardian, it did not touch the platform, as I expected.

Tripped the platform and now as expected, the damping loops were turned off when a state4 trip occurs.  Okay, so update fixed issue.

At ETMY, restart Stage1 first, then Stage2 and Guardian did nothing to the platforms...

Restarted HAM3, no problem.  Tested (tripping PR2 in the process) and the DAMPing path was turned off.  So good.

When restarting ISI_HAM6, this ISI guardian switched its request state to NONE but did not do anything, chamber manager was throwing messages.  Toggled ISI to HIGH_ISOLATED and everyone became happy.

TCS crew is working on SRC so I'll not touch them.

 

Guardian restart & test ETMX, HAM3.

Guardian restart ETMY, HAM2, HAM6.

I'll complete the remainder of the restarts and maybe test a couple more when TCS is clear.

Comments related to this report
hugh.radkins@LIGO.ORG - 16:22, Thursday 04 February 2016 (25391)
Link

restarted the guardian for the BS ISI stages.

hugh.radkins@LIGO.ORG - 09:35, Friday 05 February 2016 (25406)
Link

Completed the Guardian restarts but I did not do any further trips to test the function.

Restarted, HAMs 4 & 5 and the ITMs.  Interesting about half of these, toggled the ISI to NONE and some became unmanaged, but, switching them back to HIGH_ISOLATED and INITing the CHamber manager set things back right without troubling the platforms.

WP closed.