I have updated the h2iscey model with the latest changes from T1100472v2. It looks like the channel mapping hasn't changed since the last time I updated it, but I tweaked the subsystem input channel naming to make it clearer where the ADC channels are going from the top level.
NOTE: model not compiled or installed.
Randy, Slim, Scott & Ed pulled the HAM5 North door and connected up the iLIGO HAM Support Table to the Support Tubes. This is to hold their relative positions while the exterior HEPI Support Structure is built up. This table (like all the others in the HAMs) will be removed when Chamber cleaning commences. This one along with another one or two of the units still residing in the H1 HAMs will have to be kept clean for this same purpose.
Since it's clearly frustrating that we can't move forward with the H2 SUS TMSY installation, I wanted to show what's going on with the TOP to TOP transfer functions of H2 SUS ETMY, (Main Chain [M0] data I took this morning) so people understand why I'm holding up the show. I don't have an answer yet, but these are the plots at which I'm staring to try and glean what's going on -- suggestions are welcome!~ I'm still taking data on the reaction chain -- will post when I have that data. The first attachment (allquads_120213*.pdf) is MAGENTA, is current (2012-02-13), "first light" monolithic ETMY data, compared against - BLUE A model of the monolithic main chain (fiber). - ORANGE H2 SUS ITMY's "first light" data (2011-11-19) -- Mated w/ BSC-ISI, First Monolithic Results (Fully Laced), M0 F1 poorly aligned/ratty. M0 R and M0 V not measured because of bad M0 RT. - BLACK H2 SUS ITMY's latest and greatest (2012-01-10), phase 3a approved, in-air, post-cartridge install data. The second attachment shows only the current data, but in more detail (and with regrettably more busy plots), specifically cross coupling and OSEM basis response to the EULER drive.
Here's the R0 transfer function results (same color coding as above). With this data, Brett and I have managed to convince ourselves the the two chains are coupled in some way. After phone conversation with M. Barton, B. Bland, T. Sadecki, B. Shapiro, and myself, our best guess is that because the reaction chain UIM stage is "pretty severely rolled, and too high by millimeters," that the UIM flags are the coupling point. Another possibility is that the Top Blades' clamp bolts (those that secure the blade to the launching clamp) are interfering -- the top plates of the top mass overlap, or perhaps more accurately: where there's a cut-out in the Main Chain plate that exposes the Main chain's blade spring bolts, the Reaction chain's top plate overlaps that cutout. This hypothesis is supported by comparing the main chain and reaction chain TFs -- you'll see that modes have bifurcated in similar ways, and even some of the high frequency modes (e.g. in V and R) have bifurcated at the same frequency, but in exactly opposite amplitudes in each chain's set of TFs -- implying that were seeing the same physical mode in both chains, which are slightly different in frequency because of the two different chain types, show up in each other's dynamics. Betsy and Travis are down at the end station now investigating, where one of the first things they will do is try to lock up the reaction mass such that it is entirely free of the main chain, and we will then remeasure the main hoping to confirm our hypothesis. Then (of course) the next step is to figure out the why the reaction chain is so screwy....
Found it. The R0 UIM Left Blade Clamp screws were grounding on the bottom of the M0 UIM left top Plate. The roll of this chain just bit us again... We're going to drop the left side of R0, giving up some barrel-barrel centering (adding sideshift to the ERM) of the test mass to ERM. As well, the height of the ERM may go a bit low. Recall, we had worked towards "fixing" sideshift, height, and roll. Looks like "fixing" was the wrong thing to do.
For the record, we removed 2mm of shims at the left Top Stage Blade tip, lowering the left side of the R0 chain. There is 1mm left.
Preliminary Results look encouraging!
Attached is a quick before vs. after comparison between the two degrees of freedom that should be most decoupled -- Vertical and Yaw -- for both chains. Both show signs of significant improvement. take the measurements with a grain of salt -- flags are not yet centered, and there's ~half the averages than is normal ('cause we wanted the info faster).
Betsy and Travis are cleaning up now (re-aligning lower stage flags, etc.), and then I'll begin a full suite of measurements when they're finished (either tonight, or early tomorrow morning).
The source of the interference between the chains is the screw head touching the underside of the plate near background.
After dropping the left side of the reaction chain by 2mm, you can now see a gap above the reaction chain screw heads and below the horizontal plate of the main chain UIM.
Eric James and I installed and performed preliminary tests on the ITMY optical lever on Tuesday, Feb. 7. Alignment was straightforward, and the return beam was bright enough to see without difficulty. We did have some clearance issues with the receiver breadboard, which did not clear the beam tube. We added some 2-inch spacers to offset the breadboard from the pylon (to clear the bellows) and removed about an inch from the corner to ensure the board would clear the main tube. Electronics went well, thanks to help from Thomas Vo, Dave Barker, who established a preliminary medm screen to read out the oplev signal.
Rolf, Alex, Dave.
We upgraded LHO from RCG-2.3.1 to RCG-2.4.1 today. All systems were burtrestored using the supplied safe.snap files, or from the autoburt of 9am this morning. H2 systems were not activated beyond doing the burt restores (watchdogs left tripped, etc.).
The problem of some cores running long was investigated. All front ends were configured to new advanced bios settings. This appears to have fixed the run-long problem, we will continue to check this over the weekend.
Discovered H2 SUS ETMY had not been BURT restored after this upgrade. The BURT file, using /opt/rtcds/userapps/release/sus/burtfiles/etmy/h2susetmy_safe.snap (NOTE THE CHANGE OF LOCATION OF CDS USERAPPS REPO!!) gave a red, "NOT OK!" message upon restore, but from the looks of the error log and looking over the system, I think it's an issue with BURT file formatting upgrade, not that anything got improperly restored. After the restore, I can comfirm that the DAQ is functional -- I'm taking first set of Transfer Functions after upgrade now, I can (1) open DTT, (2) use it to send out excitations, (3) read back (in the present) _DQ channels. From prior discussions with D. Barker, R. Bork, and M. Landry, I'm 80% confident that h2susetmy's *was not* changed in this upgrade, where h2susitmy and h2susfmy's models were. I mention this because I was worried that the BIO (Binary Input/Output; completely different from the bios the Dave mentions above) would have lost its functionality -- therefore inhibiting drive (that pesky "test/coil" switch). Will provide more details in later aLOGs when I know more.
In BSC8, I'd found the H2 SUS FMY also needed a BURT restore. I've restored this suspension using
${userapps}/release/sus/h2/burtfiles/fmy/h2susfmy_safe.snap
However, because we've upgraded our Binary I/O interface in the RCG 2.4 version of the Simulink masters models,
${userapps}/branches/branch-2.4/sus/common/models/QUAD_MASTER.mdl
${userapps}/branches/branch-2.4/sus/common/models/BSFM_MASTER.mdl
which is what was used to compile both H2 SUS ITMY (a QUAD) and H2 SUS FMY (a BSFM) (but NOT YET H2 SUS ETMY), and that upgrade includes the need for new MEDM screens, found in
${userapps}/branches/branch-2.4/sus/common/medm/${optic}/SUS_CUST_${OPTIC}_BIO.adl
we need to make changes to
/opt/rtcds/lho/h2/medm/SITEMAP.adl,
which is where the generic screens' hard coded variables live.
I have updated the paths for ITMY and FMY (both in the call to the OVERVIEW screen, as well as in the SUSDIR variable), but it still doesn't call the right screen. Unfortunately, without the right variables sent to the screen, opening the screen by itself just shows white channels -- a feature of the generic screens.
Debugging is in progress...
H2 SUS ITMY is now functional: the trick was that the
${userapps}/branch-2.4/sus/common/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl
MEDM screen's link to the
${userapps}/branch-2.4/sus/common/medm/quad/SUS_CUST_QUAD_BIO.adl
was hard-coded to
/opt/rtcds/$(site)/$(ifo)/userapps/release/sus/common/medm/quad/SUS_CUST_QUAD_BIO.adl.
Once I corrected the button link, I was able to pull up the correct version of that screen, and change the coil driver State (H2:SUS-ITMY_BIO_M0_STATEREQ set to 1.0), and enable the coils (H2:SUS-ITMY_BIO_M0_CTENABLE set to 1.0). The attached TF shows that actuation works, and the dynamics haven't changed.
One would expect that H2 SUS FMY has the same problem, but when I fixed his overview,
${userapps}/branch-2.4/sus/common/medm/bsfm/SUS_CUST_BSFM_OVERVIEW.adl
the *new* channels came up white, implying that they don't exist, or are broken in some way. I'm still waiting here from Dave whether he compiled FMY with the RCG2.4 version of the BSFM_MASTER.
Attached are plots of dust counts > .5 microns.
Work continues on the MSR and control room upgrades. Underfloor power and network are almost complete. The new aligo racks went into the MSR today for the H1 systems. Frontends for H1 are being built ready for MSR install.
Jason and I pulled the chain on two monuments in the Y-END station and read it at 8536.5 mm. We then setup the total station over one monument and the corner cube over the other. We looked at four different corner cubes with and without the cross hairs and they all read consistently at 8536.0 mm (0.5 mm difference as measured by the chain) We will next compare the other SET 1X total station using the same setup, but I don't expect to see much of a difference. The distance from the TM HR face to the corner cube reference plate for the ITMy is 44.6 mm; and 43.9 mm for the ETMy so that shows consistency as well. The corner cube reference plate is 17.74 mm to the mounting surface that registers against the Quad face frame. So far nothing glaring.
The Ham Large Triple Suspension, H2-PR3 metal build is fully suspended. We dialed it in this afternoon by eye and ruler. The M2 mass required no adjustment to bring it into bubble level (see photo). It is showing a slight roll which is in sync with the roll on the M1 mass. M1 required a slight adjustment of the wire attachment point to bring it into level. Again it is showing a slight roll, but we do not have the flags installed and the high side of the mass has the two flags. If M1 responds to the mass of the flags the way the Quad UI mass does, I expect we will need little adjustment to bring it into spec. By eye, the blade tips look close to even. Monday we will start optical leveling and alignment.
ISI Testing results highlighted a discrepancy for this level. Scott and I did a peg test and saw the horizontal crosshair was not normal to the vertical rotational axis by 40µrad. This isn't much for a survey instrument but amounts to .003" over the 6' length of a HAM ISI Optical Table. Hugo & I adjusted this to something less than 4µrad so we were pleased. Even going from 40 to 4 was one of those measurement: put some pressure on the screw and when you think it might have moved, check because you might have moved too much. We had this instrument for something approaching a year now and it has been around. We have two others and they should certainly too be checked. This one may have crept out of adjustment or it may be that the factory specs is only 100microrads.
Could .fig, .mat and .m be added to the supported (matlab scripts, data and figures) be added to the list of files which can be up loaded?
I have added .m, .mat, and .fig to the list of allowed attachment types. Please note that the graphics library that the aLOG uses to create thumbnails does not support .fig files, so it cannot yet display the .fig files. I have requested that LLO update their logbooks as well.
In alog #2034, we mentioned an issue probably created by a malfunctioning actuator in corner 2 (Horizontal - NW). Two modifications were made since the issue was mentioned:
- Disconnecting and reconnecting the actuators (Horizontals and Verticals separately)
- Swapping the actuator valve of horizontal actuator in the NW corner
After rerunning the test (attached figure), you can notice that corner 2 (NW) behaves more linearly (not the case of corner 3 after the actuators reinstallation).
The attached are WhiteNoise TFs taken last night and early this morning for the H2 SUS ETMY M0 and R0 masses. For both chains, the Long, Trans, Pitch, & Yaw resonances are vivid above the white noise excitations. The Vertical and Roll DoFs for both masses had very low coherence for various amplitudes. A tuned matlab transfer function measurement is running since early morning for both masses. DTT templates in SVN: ~/SusSVN/sus/trunk/QUAD/H2/ETMY/SAGM0/Data/2012-02-09_M0_*_WhiteNoise*.xml ~/SusSVN/sus/trunk/QUAD/H2/ETMY/SAGR0/Data/2012-02-09_R0_*_WhiteNoise*.xml Plots: ~/SusSVN/sus/trunk/QUAD/H2/ETMY/SAG*/Results/2012-02-09_*_WhiteNoise*.pdf
Diagonalization measurement results for H2SUSETMY M0 & R0 are attached. For M0, the Vertical DoF is at least 22dB isolated from the other OSEMs at 2.25Hz, which is excellent. The M0 Yaw DoF,however, appears to be highly coupled to the F1 and SD OSEMs at 1.3Hz (the Yaw DoF consists of the F2 & F3 OSEMs) - the M0 TOP mass might need some adjustments to decouple Yaw. For R0, the Vertical DoF is roughly 10-12 dB isolated from the other OSEMs - on the cusp of tolerance. The Yaw DoF is about ~15dB isolated, which is good. Plots in SVN: '~SusSVN/sus/trunk/QUAD/H2/ETMY/SAGM0/Results/' '~SusSVN/sus/trunk/QUAD/H2/ETMY/SAGR0/Results/' DTT templates: '~SusSVN/sus/trunk/QUAD/H2/ETMY/SAGM0/Data/ETMY_M0_Diagonalize_1p3_Yaw.xml' '~SusSVN/sus/trunk/QUAD/H2/ETMY/SAGM0/Data/ETMY_M0_Diagonalize_2p2_Vert.xml' '~SusSVN/sus/trunk/QUAD/H2/ETMY/SAGR0/Data/ETMY_R0_Diagonalize_1p3_Yaw.xml' '~SusSVN/sus/trunk/QUAD/H2/ETMY/SAGR0/Data/ETMY_R0_Diagonalize_2p2_Vert.xml'
Attached are plots of dust counts > .5 microns for yesterday and today.
The attached files are plots of the ITMY L1 WhiteNoise TFs measured last night. The parameters were significantly different from previous measurements of the TFs from the L1 stage. The drive amplitudes were tweaked for better coherence to distinguish the resonances. Coherence is decent for the L DoF and good enough to see the resonance peaks. The Pitch and Yaw DoFs have much better coherence, as expected. The locations of the peaks coincide well with the models for the most part. ----------------------------------------------------------- DTT template files: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H2/ITMY/SAGL1/Data '2012-02-01_H2SUSITMY_L1_*DOF*_TF.xml' PDFs of Plots: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H2/ITMY/SAGL1/Results/ '2012-02-08_L1_Long_TF_200k_amp_0to1000Hz_WhiteNoise.pdf' '2012-02-08_L1_Pitch_TF_15k_amp_0to1000Hz_WhiteNoise.pdf' '2012-02-08_L1_Yaw_TF_5k_amp_0to1000Hz_WhiteNoise.pdf'
Yesterday, we observed the UIM LR BOSEM to be railed. Today, Filiberto swapped satellite boxes - no change in the railed signal. Then he swapped cables - again no change to the railed signal. So, we swapped the BOSEM which apparently fixed the signal. The original BOSEM s/n 480 was bad. We switched in s/n 022 and Kissel reset the OLV offsets. We then finished aligning it and the rest of the UIM BOSEMs. All 4 UIM OSEMs are aligned, but with only 1 CAM attaching the BOSEM, due to range issues.
Pictures of the UIM BOSEM centering and PUM Flag mounts are on resource space: https://ligoimages.mit.edu/?c=963 Interestingly, my phone camera picked up the BOSEM LED light - shown as a purple dot on the flags. A good metric to really "see" centering. (Now, about that phone bill...) Look at the "original file name" for a clue as to which one you are looking at.
After Jeff reported that L1 (UIM) LR OSEM was saturating the ADC while "open lighted" (see his comment here), Betsy and Travis went in this morning to swap it out with another. His now open light current (in counts) is controls@cdsws1:Data 0$ tdsavg 30 H2:SUS-ETMY_L1_OSEMINF_LR_IN1 OL = 24151.6 [cts] (Kinda low, but ... it's fine -- It's the UIM stage, not worth effort of finding another, and that's why we compensate for the gain difference in the OSEMINF banks.) Speaking of, I've entered the corresponding offset and gain: H2:SUS-ETMY_L1_OSEMINF_LR_OFFSET -12075 (OL / -2) H2:SUS-ETMY_L1_OSEMINF_LR_GAIN +1.242 (30000 / OL)
Stuart A To help guide the selection of BOSEMs, prior to making open-light measurements or installing them into the suspensions, please refer to the list attached below. This has been generated by cross-referencing open-light measurements made in Birmingham on the ATE, with the BOSEMs held in stock at LHO (extracted from ICS). For further details please refer to the LLO aLOG entry 2460 In summary, if the BOSEM serial number appears in the text file below, then you can be more confident that the open-light measurement will exceed Jeff K's 25k count goal.
