40m
QIL
Cryo_Lab
CTN
SUS_Lab
CAML
OMC_Lab
CRIME_Lab
FEA
ENG_Labs
OptContFac
Mariner
WBEEShop
|
40m Log |
Not logged in |
 |
|
Fri Feb 13 13:35:38 2009, Yoichi, Update, LSC, Locking status
|
Sat Feb 14 16:53:26 2009, rob, Update, LSC, Locking status
|
Sun Feb 15 09:35:00 2009, Yoichi, Update, LSC, Locking status
|
Sun Feb 15 15:53:21 2009, Rob, Update, LSC, Locking status
|
Mon Feb 16 10:18:13 2009, Alberto, Update, LSC, FE system rebooted
|
Mon Feb 16 14:12:21 2009, Yoichi, Update, LSC, FE system rebooted
|
|
Message ID: 1304
Entry time: Sat Feb 14 16:53:26 2009
In reply to: 1301
Reply to this: 1305
1306
|
Author: |
rob |
Type: |
Update |
Category: |
LSC |
Subject: |
Locking status |
|
|
Quote: | Yoichi, Jenne, Alberto, Rob
Last night, the locking proceeded until the CARM -> MC_L hand-off.
However, the MC_F gets saturated (as expected) and the IFO loses lock soon after the hand-off.
So we need to offload MC_F.
We ran the offloadMCF script, but it did not work, i.e. just waiting for CARM mode.
Looks like an EPICS flag is not set right. |
I found a '$<' in the offloadMCF script. I don't know precisely what that construct means, but I think it caused the script to wait for input when it shouldn't. It probably got in there accidentally. We need to be careful when we're opening scripts just to look at how they work that we don't accidentally change them. I like to use the command 'less' for this purpose.
With this gone, the script worked properly, although the lock didn't last long. I don't know if the next stage in the process is failing or if it's just a bit too noisy in the afternoon. I didn't get a chance to do much testing since the sus controller (susvme1) went nuts. In retrospect, this could be due to something in the script, so maybe we should try a burt restore to Friday afternoon next time someone wants to look at it. |