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.