40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log  Not logged in ELOG logo
Entry  Fri Feb 13 13:35:38 2009, Yoichi, Update, LSC, Locking status 
    Reply  Sat Feb 14 16:53:26 2009, rob, Update, LSC, Locking status 
       Reply  Sun Feb 15 09:35:00 2009, Yoichi, Update, LSC, Locking status 
       Reply  Sun Feb 15 15:53:21 2009, Rob, Update, LSC, Locking status 
          Reply  Mon Feb 16 10:18:13 2009, Alberto, Update, LSC, FE system rebooted 
             Reply  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.
ELOG V3.1.3-