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 Dec 4 21:48:01 2009, Jenne, Update, oplevs, Oplevs centered, IP_POS and IP_ANG centered Oplev_IPang_screenshot_4Dec2009.png
    Reply  Fri Dec 4 23:17:55 2009, rob, Update, oplevs, Oplevs centered, IP_POS and IP_ANG centered 
       Reply  Sat Dec 5 01:40:11 2009, Koji, Update, oplevs, Oplevs centered, IP_POS and IP_ANG centered 
          Reply  Sat Dec 5 18:23:48 2009, Koji, Update, oplevs, Oplevs centered, IP_POS and IP_ANG centered Screenshot_091205_1830.png
Message ID: 2353     Entry time: Fri Dec 4 23:17:55 2009     In reply to: 2352     Reply to this: 2354
Author: rob 
Type: Update 
Category: oplevs 
Subject: Oplevs centered, IP_POS and IP_ANG centered 


[Jenne Koji]

 We aligned the full IFO, and centered all of the oplevs and the IP_POS and IP_ANG QPDs.  During alignment of the oplevs, the oplev servos were disabled.

Koji updated all of the screenshots of 10 suspension screens.  I took a screenshot (attached) of the oplev screen and the QPD screen, since they don't have snapshot buttons.

We ran into some trouble while aligning the IFO.  We tried running the regular alignment scripts from the IFO_CONFIGURE screen, but the scripts kept failing, and reporting "Data Receiving Error".  We ended up aligning everything by hand, and then did some investigating of the c1lsc problem.  With our hand alignment we got TRX to a little above 1, and TRY to almost .9 . SPOB got to ~1200 in PRM mode, and REFL166Q got high while in DRM (I don't remember the number). We also saw a momentary lock of the full initerferometer:   On the camera view we saw that Yarm locked by itself momentarily, and at that same time TRX was above 0.5 - so both arms were locked simultaneously.   We accepted this alignment as "good", and aligned all of the oplevs and  QPDs.

It seems that C1LSC's front end code runs fine, and that it sees the RFM network, and the RFM sees it, but when we start running the front end code, the ethernet connection goes away.  That is, we can ping or ssh c1lsc, but once the front end code starts, those functions no longer work.  During these investigations, We once pushed the physical reset button on c1lsc, and once keyed the whole crate.  We also did a couple rounds of hitting the reset button on the DAQ_RFMnetwork screen.

 A "Data Receiving Error" usually indicates a problem with the framebuilder/testpoint manager, rather than the front-end in question.  I'd bet there's a DTT somewhere that's gone rogue.

ELOG V3.1.3-