corey.gray@LIGO.ORG - posted 05:18, Tuesday 10 September 2019 - last comment - 16:37, Tuesday 10 September 2019(51840)
Back To OBSERVING After Almost 7-hrs
Now that we are back to Observing, figured I'd post locking notes from the night.
Summary:
- DOWN time: 4:39-11:28utc (almost 7hrs)
- Took 8 Lock attempts & 3 Alignments (my long alignment was not needed though!)
- Due to the down time, we should probably still back out the IM alignment change from Sunday night during the next lockloss.
Locking Notes:
- 7:07 Niko's LOCK#3: Lockloss at INCREASE POWER after the first step in powering up.
- 7:08 - 7:26 My LOCK #1: Lockloss at ENGAGE SOFT LOOPS
- 7:30-10:08 LOCK#2:
- After several attempts at locking with the new IM pointing from Sunday night, decided to back IM pointing out.
- 7:33 Restored IM1, IM2, IM3 to where they were before the last lock. (settings restored from SDF list here).
- 7:35-9:37 Starting a 3rd Initial Alignment (because there is a new input pointing)
- Notes/Issues from Initial Alignment are in this alog.
- NOTE: getting "IMC WFS not centered" messages for IMC LOCK. Observe this in all the space it takes up in the ISC LOCK log.
- DRMI did not lock. PRMI locked & then DRMI locked quickly afterward.
- 10:08 Lockloss at ENGAGE SOFT LOOPS: this happened fairly quickly and before the "usual" ITMy point absorber manuever which has the "usual" OMC & all-test mass Saturations noted by Verbal.
- 10:09-10:34 LOCK #3:
- DRMI locks after 7.5minutes w/ no operator assistance
- Our new "Usual Point Absorber Manuever": Verbal talks to me about a saturating OMC & all test masses, and then goes quiet as it moves our beam spot from an Initial Alignment spot to locking spot (Verbal gets vocal as we traverse the point absorber on the ITMy). This is our new normal. Oh--you will also see DHARD Pit get rung up during this traverse, but it will come down, too. And I believe we also get the guardian note of "OMC not ready" during this maneuver as well.
- Lockloss at INCREASE POWER (this is after the first "step" for increase power, sort of what Niko and I saw for his last
- 10:35-10:47 LOCK#4:
- DRMI locks in under 5min
- Lockloss at CARM TO TR
- 10:49 LOCK #5:
- DRMI locks in about 9min
- Went directly to NOMINAL LOW NOISE
- Had a long list of Diffs for CALCS (accepted all of them & snapshot is attached)
- 11:28 Back to OBSERVING!
Images attached to this report
Comments related to this report
J. Kissel
Regarding Corey's comment:
NOTE: getting "IMC WFS not centered" messages for IMC LOCK. Observe this in all the space it takes up in the ISC LOCK log.
This is a known issue/problem that is not resolvable without a hardware change: check out my aLOG from tail end of July: LHO aLOG 50920, and Daniel's subsequent reference to 5109.
To quote my aLOG: "This message appears, typically, after PSL incursions (rare), site power outages (rare), or computer failures (rare) when the IMC suspensions's or PSL Periscope PT alignments get lost. Because these events are rare, instituional memory loss causes confusion for folks when they see that error message and wonder if action is needed. However, once these alignments are roughly recovered (via reseting sliders on suspensions), the WFS, again typically, eventually recover their centering all on their own as the RF loops converge [there are no "DC centering" loops on IMC WFS, as there are for many of the the WFS systems]."
However, last night, none of these things happen, and the IM alignment is all down stream of the IMC WFS. So I'm equally confused as to why the WFS got outside of their range. Worth trending.
But in short -- while these warnings are annoying -- they are reflecting of a real issue, so don't ignore them.
CAL CS differences are due to poor rounding of the installation of Calibration Model Reference Values art Calibration Line frequencies. Will work on resolving this later today.
Today we did have the problems with TR_CARM that Corey and Niko descirbed last night, and we think we have addressed the problem: 51861
We didn't have any of the locklosses from ENGAGE_SOFT_LOOPS today. I did look at one of them from last night, and it does seem that we still have low gain in SRC2 (P+Y) and INP1 P so that the loops aren't holding their error signals around 0 in these steps. Speeding these up a bit might help us out here. Keita and I started to work on speeding up some of the ASC for similar reasons last Tuesday 51715, but we didn't get a chance to try increasing the gain in these very slow loops.
Images attached to this comment
