Spool piece pulled. Gate valve and flange protection installed.

J. Garcia, J. Kissel

After the addition of the USER DACKILL to the model last Thursday, we Jeff's added some new information to the overview screen, as well as modifying other parts for ease of use. Details below. This change effects the following screens:

${userapps}/release/sus/common/medm/quad/
SUS_CUST_QUAD_OVERVIEW.adl
SUS_CUST_QUAD_R0.adl
SUS_CUST_QUAD_DACKILL.adl   # new!

and the changes have been committed to the SVN. Note, that these screens have been tested with no other QUAD besides H2 SUS ETMY, so please be patient while we propagate to others. 

Details:
Take a look at the .pdf attachment, which shows the overview screen, with a bunch of areas highlighted. This is what I'll use to walk you through the changes.

* ORANGE This (finally) shows (beginnings of) elucidating the many, many layers of "protection" that prevent the user from getting a digital drive signal out to the suspension coils. From left to right (in the orange box),

WATCHDOG -- hooked up to watch the "first thing off the ADC" OSEM signals, both AC BLRMS and raw DC, as well as the "last thing out to the DAC" AC BLRMS of the digital drive. As we've (re-)learned from the 2012-03-01 ISI/CDS Badness, this isn't *actually* the last thing in/out of the model; there's an extra layer of digital IOP between the signals that are watched by this 'dog. So, these signals are the first/last thing in/out of the QUAD user model.
USER DACKILL -- eventually meant to be similar to the new ISI "rogue excitation monitor," where if the USER model detects badness from itself (using the monitor chassis' coil driver readbacks), it will send a request to the IOP to shut down its DACs. Currently -- because we wanted to get something in quick, and we don't yet understand the monitor chassis signals enough to use them as a watchdog, the DACKILL's input is the same "M0/R0 Tripped" flag that's sent to the ISI. 
IOP DACKILL -- This is the "temporary software version of the hardware watchdog." It actually watches the first thing off the ADC: the raw OSEM counts at full data rate, as they come into the IOP model, without any signal conditioning. These watchdog thresholds are (supposedly) set to be much looser that the WATCHDOG thresholds, and therefore should only trip when something really bad's happening. NOTE, this does not watch the drive signals, only sensor signals.
TEST/COIL ENABLE -- This is not originally intended as a watchdog; it's the hardware switch between the "test" and "coil" input on the front of the coil driver chassis, controlled by the digital Binary Input/Output (BIO) system. When the BIO bit is flipped to "test," (i.e. 0, the default, non-powered chassis condition) the coil driver switches to taking input from the "test" DB9 spigot of the front of the chassis, which normally has nothing connected to it. When flipped to "coil," (i.e. 1) the coil driver switches to taking input from the DAC, because this port has cables connected to the AI chassis, and is the normal signal path out. So, unless the BIO is ON, functional, and flipped to 1, there's no way you're getting any digital signal out to drive the suspension. 

NOTES:
- The USER DACKILL and TEST/COIL layers are why I put quotes around "protection," 'cause at the moment, I'm not sure they're doing anything but interfering with completely normal drives. The USER DACKILL will be made into a more useful watchdog shortly. The TEST/COIL, I guess, is "protecting" against a non-function BIO system, but the BIO system isn't essential / dangerous.
- The dotted lines extend out to exactly where the various layers "protect;" The USER and IOP DACKILLs shut down all of the DACs from that QUAD's user model, whereas the WATCHDOG only stops output at a given stage. 

The hope is that, once we have a hardware watchdog, we can consolidate this "protection" system a little better. But I wouldn't hold my breath. Since we're looking for 0% failure, it's always going to be this hard to get a drive signal out. The key is having all the layers clearly visible and understood, such that one doesn't forget layer number 4 of 6, after not having looked at a given SUS for a while.

* RED A button that opens up the new DACKILL screen; see dackill.png attachment. Should be pretty self-explanatory: as currently hooked up, the M0 and R0 watchdog flags are summed, then (a) sent off to the ISI, when 0 is OK, non-zero is BAD, and (b) inverted, such that 0 is BAD, non-zero is OK, and piped into the DACKILL part. Again, this is not the final implementation, but it should be good enough for now.

* YELLOW At the advise of the SEI team, I re-purposed the epics variables 

$(IFO):SUS-$(OPTIC)_COMMISH_STATUS
$(IFO):SUS-$(OPTIC)_COMMISH_MESSAGE

to be used by automated scripts as well as users. Now, when the $(IFO):SUS-$(OPTIC)_COMMISH_STATUS channel is switched to 1 (controlled either by the ON/OFF button, or a caget/ezcaswitch call to that channel by a script), that little box starts to blink yellow, and says "IN PROGRESS." Note that I've removed $(IFO):SUS-$(OPTIC)_COMMISH_MESSAGE from the screen, but not from the model. Formerly, it was used as place to inform people who to talk to during a measurement, but it proved cumbersome and ineffective. We'll remove it from the model the next time it's convenient -- it's not hooked up to anything, so it makes no difference whether it's in the model but not-visible on the screens.

* WHITE At the request of those using the screens all the time, I've separated the R0 watchdog out from the R0 screen button. This allows for easy, less-clicking, access to the R0 watchdog screen.

Staging around the east side of BSC3 started. The chamber cleanroom is in place. 

Installed all HAM2 feedthroughs per Hugh's map. Started work on HAM1 feedthroughs: several 25-pin still needed. Can someone answer the question about what gets returned to the top of these chambers?

Attached are plots of dust counts > .5 microns.

(Corey, Hugh, Hugo)

iLIGO Baffle Removal

The Baffle in BSC10 needed to be removed (because it blocked the One-Arm-Test Quad in BSC6).  This Baffle is suspended in place by springs which were attached to the Chamber.  Hugo and I were able to disconnect the springs at the chamber bracket connection.  The baffle was then laid down on the floor (see fuzzy photo) of BSC10.  The springs for the baffle appeared to be a bit oily (evident by black marks on my gloves).  We opted to not bring the baffle out because we would have had to maneuver this around the alignment tripod and the BSC6 Quad/Transmon.  We also left the four brackets in place on the chamber.

ISI Cabling

Hugo and I secured the ISI connectors in their feed-thrus via their connector screws.  We were NOT able to do this for all (3) Trillium connectors, because they were missing connector screws(!).  While doing this work, some SUS connectors were also secured to their feed-thrus.

We also went about cleaning up some of the ISI cabling.  Basically, we didn't want any of our cables to hang to low and be a possible head obstruction; also didn't want to have a seismic short from Stage0 to the Chamber (since Stage0 is floating due to HEPI).  This clean-up was accomplished by using cable clamps on Stage0.

Attached are plots of dust counts > .5 microns for April 13, 2012.

D. Barker, J. Kissel

In order to better understand the auxiliary chassis' signals which monitor the coil driver's output "noise," voltage, current, and rms current, I've added the following H2 SUS ETMY channels to the frames:

Channel                         Sample Rate
H2:SUS-ETMY_M0_FASTIMON_SD_DQ   2048
H2:SUS-ETMY_M0_NOISEMON_SD_DQ   2048
H2:SUS-ETMY_M0_RMSIMON_SD_DQ    2048 
H2:SUS-ETMY_M0_VOLTMON_SD_DQ    2048 

H2:SUS-ETMY_R0_FASTIMON_SD_DQ   2048 
H2:SUS-ETMY_R0_NOISEMON_SD_DQ   2048 
H2:SUS-ETMY_R0_RMSIMON_SD_DQ    2048 
H2:SUS-ETMY_R0_VOLTMON_SD_DQ    2048 


Details:
----------------
Because I didn't want to break anything in the morning on a Saturday before leaving the state, I added these channels to the frames by directly modifying the
/opt/rtcds/lho/h2/chans/daq/H2SUSAUXB6.ini
file, uncommenting the above listed channels, and switching the acquire flag to 1. I followed this edit by hitting DAQ_RELOAD on the H2SUSAUXB6_GDS_TP.adl screen, with the intent to then restart the framebuilder (i.e. h2susdc0); a practice that's normal, and confirmed to work a few days ago.

HOWEVER, upon hitting DAQ_RELOAD, all H2 frontends immediate indicated a red, 0x2bad status, and the H2SUSAUXB6 front end crashed (as indicated by all white channels on Dave's H2CDSOVERVIEW.adl screen).

I called Dave immediately. Thankfully, our savior was home, up, and happy to help. Here's what we did:

I restarted the framebuilder:
     contorls$ telnet h2dc0 8087
     Trying 10.201.0.160...
     Connected to h2dc0.cds.ligo-wa.caltech.edu.
     Escape character is '^]'.
     daqd> shutdown

No dice. All frontend still show 0x2bad.

Attempted to power cycle h2iopb6 (IOP dcuid = 115, H2SUSAUXB6 = 116) remotely.
     - Open a web browser, go to URL http://10.99.201.${dcuid}
     - Select "Remote Control" tab
     - Hit "Power Control" button
     - Select "Power Cycle" radio button
     - Hit "Perform Action" button
Got no response after two attempts, realized I had accidentally went to http://10.99.201.11/ (h2iopseib6). *sigh*. Curiously enough, the h2seib6 computer didn't seem to reboot...
Went to http://10.99.201.115/, and performed the above steps.

The framebuilder status for h2iopsusauxb6 immediately flipped to 0x0 and, after quite a bit of time, the IOP model came back up as indicated by his channels going from white to live.

While I was futzing around with that (maybe during the first few attempts at rebooting "h2susb6," when I was actually rebooting h2seib6), Dave had removed the h2susauxb6 user model from [[some list, whose name/location I didn't catch; but NOT the /opt/rtcds/lho/h2/target/h2dc0/master file]], believing it was preventing the power cycle and/or causing the computer to hang on reboot.

Once we saw the h2iopsusauxb6 alive, he reinstalled the h2susauxb6 user model, and viola! the h2susauxb6 framebuilder status switched to 0x0, and after a similarly long time [[and not just because of the EPICS gateway]], his channels turned live.

Dave had hoped that once we got h2susb6 up, the remaining front ends would restore good 0x0 frame builder status, but no such luck.

Dave, having encountered this problem just this past week when Vincent added some channels to the framebuilder, he knew that he had to restart all the frontend's mx_stream process. This is done by logging into each frontend independently and running
/etc/start_streamers.sh.

One by one, after each kickstart of a given frontend's mx_stream, each model's framebuilder status returned to a pleasant 0x0.

Hazaah!!


Finally, after ~30 minutes, I let Dave get back to his weekend. Did I mention "Hazaah!!"?

The new channels are now in the frames, and I've confirmed I can receive data in the past via DTT. *Sheesh*

Note that this was supposed to be a quick, clean, unobtrusive way to temporarily get channels in the frames -- because I "didn't want to break everything by risking a model recompile." You can see how that went (*).(*). On Monday, or sometime soon, we will do the recommended new-standard method of adding channels to frames by including them in a permanent text list inside the user model, and re-compiling.

Since I was working up to the last minute, I haven't had the chance to aLOG everything yet, but I wanted to let everyone know what's coming, and what I've done. Forgive the brevity, more details to come. I've left H2 SUS ETMY with his damping loops running. Thanks er'body!

- Modified QUAD MEDM screens
     - to include blinky measurement status light on overview
     - to include more detail show all layers of "protection" on overview and R0
     - created a new user dackill screen

- Took transfer function measurements of ETMY
    - At first glance: we're rubbing on R0, M0 looks OK

- Added auxiliary chassis M0 and R0 SD monitor channels (a total of 8) to the frame builder 
    - This crashed everything, but after a call with Dave every things back up and running

- Measured spectra of SD monitor channels during 
    - everything off
    - damping loops on
    - during TRANS TF

All changes to MEDM screens, models, and .ini files have been committed to the userapps repository, and all new data have been committed to the SusSVN repository.

This afternoon I aligned the periscopes for the ALS beam and the Hartmann sensor beam.  I also retro-reflected the ALS beam and aligned the TCS pickoff (also destined for the Hartmann sensor) up to the Uniblitz shutter that was installed yesterday.

The alignment of the Hartmann beam (from the AR reflection off the ETM) is in the ballpark, but we'll have to wait for an actual beam to do it properly.  Note that to avoid interference with the ALS beam, the Hartmann beam is 'caught' by one mirror just below the upper ALS periscope assembly, and shot over to another periscope frame, and then down to the table.  (This is the periscope frame for a future IR beam that will come out of the vacuum.)  The mirror for the Hartmann beam is 3" below and 1" to the left of the ALS mirror; this placement is based on Bram's suggestion & calculation of where to put the beams on the viewports to avoid clipping.

There is some wiggle room in the periscope mounts, both vertically and horizontally, in case we need to re-align at the endstation.

In trying to fit a mirror mount for the Hartmann beam I wound up flipping the upper periscope assembly and tying down a corner with a dog clamp.  In the final design this is probably unnecessary.

On Wednesday we unlocked H2 SUS ETMY for the first time after cartridge install, and last night we took a set of transfer functions to diagnose its health. Attached are the results; they look excellent! 

Among the other usual attachments,
2012-04-12_H2SUSETMY_M0_ALL_TFs.pdf -- Main Chain, individual comparison with Model, shows cross-coupling and OSEM basis response
2012-04-13_H2SUSETMY_R0_ALL_TFs.pdf -- Reaction Chain, individual comparison with Model, shows cross-coupling and OSEM basis response
allquads_120413_H2SUSETMY_ALLM0_TFs.pdf -- Main chain, zoomed out version of the below described plots
allquads_120413_H2SUSETMY_ALLR0_TFs.pdf -- Reaction chain, zoomed out version of the below described plots

In the main chain (M0) chain's allquads_120413_ALLM0_*.pdf, I compare 4 measurements, all monolithic lower halves,
2012-01-10 H2 SUS ITMY, Phase 2b approved measurement (On test stand, mounted to BSC8-ISI, Chamber-side Test in LVEA)
2012-02-16 H2 SUS ITMY, Phase 3a approved measurement (In-chamber, partially at vacuum)
2012-03-14 H2 SUS ETMY, Phase 2b approved measurement (On test stand, mounted to BSC6-ISI, Chamber-side Test at End Station)
2012-04-12 H2 SUS ETMY Current measurement (In-chamber, mounted to BSC6-ISI, glass ERM, vibration absorbers OFF)

and in the reaction (R0) chain's allquads_120413_ALLR0_*.pdf, I compare
2011-11-22 X1 SUS QUAD04 Phase 1b approved measurement (On test stand, mounted to Solid Stack, fully laced, metal dummy mass)
2012-01-24 X1 SUS QUAD03 Phase 1b approved measurement (On test stand, mounted to Solid Stack, fully laced, metal dummy mass)
2012-03-15 H2 SUS ETMY, Phase 2b approved measurement (On test stand, mounted to BSC6-ISI, Chamber-side Test at End Station, glass ERM)
2012-04-13 H2 SUS ETMY Current measurement (In-chamber, mounted to BSC6-ISI, glass ERM, vibration absorbers OFF)

At first glance, the TFs look great. 
- No major rubbing, the dynamics, overall, appear, as-usual, strikingly similar to suspensions of similar type. 
- On the reaction chain, Pitch looks fine, implying the lacing cables haven't moved or at least changed the dynamics for the worse. 
- The main chain looks just down right great and consistent. A couple of the degrees of freedom even cleaned up since Phase 2b (see L, T, and R). Nice!

Upon further inspection, I see a couple of things that raise some yellowy green flags on the reaction chain:
    - The second R0 longitudinal mode @ 0.85 is bifurcated. What you can't see is that the magenta curve (the previous ETMY measurement), is also bifurcated, but the lower frequency of the two split modes is lower in magnitude in the magneta curve, and is therefore hidden behind the cyan. Because this mode is *not* bifurcated in the two metal mass measurements, I'm curious if this is something peculiar (I dare say "wrong"), with ETMY. The problem is that we have statistics of one on a glass ERM. All metal mass measurements don't show this feature. This good very well be just how the plant changes between a metal and glass mass.
    - Similarly with the second R0 transverse mode. Though the metal mass measurements show two modes around that frequency (one much more pronounced than the other) the two measurements of the one glass ERM show that this mode shape has changed toward shall we say "more complicated." Of course, transverse is always a noisy measurement since only the SD OSEM is driving it (as opposed to the other DOFs which have at least 2).

Finally, zooming out and looking at, for example allquads_120413_H2SUSETMY_ALLM0_TFs.pdf, I notice that our favorite, high-frequency "what looks like a giant mechanical zero, but we've proven to be just electronics cross coupling some where in the chain, which we've convinced ourselves was the temporary ribbon cables we use in our mock-feedthroughs" feature is STILL PRESENT after the install into chamber, where we're using nothing but production cables and real-deal feed-throughs. We convinced ourselves with FMY that this was true, but perhaps, we were too hasty with our conclusions. Some nice additional proof will be a comparison between vibration absorbers OFF vs. vibration absorbers ON, which I will get tonight.

GregG, JimW

Following SUS's adding vibration absorbers, SEI went in and rebalanced. This included re-adjusting the gaps on 3 of the CPS's as fallout from yesterdays replacement of allegedly defective sensors. We also did some refining of the cable routing on corner 3, as it is a very busy area (as shown in the attached photo) and was showing evidence of rubbing from TF's run earlier in the week. BSC6 should now be in pretty good shape for testing over the weekend.

BSC8--Saw activity around this chamber, so I'm assuming they were able to remove the Arm off the door flange.

BSC6--Vibration Absorbers have been installed

There were tons of Diode Room Access Alarms throughout the day.

* Vibration Absorbers were installed on ETMy structure
* I started pinning up the cables to Stage0 with the PEEK finger brackets DXX00600
* We set the EQ stops to ~1mm from the masses

The SUS is fully suspended and shields are removed.

On Wednesday the code at end X was moved to new code running on h0epics2, a Ubuntu workstation. Yesterday the weather stations at end Y, mid X and mid Y were ported as well. The weather station at the corner station is currently removed.

Find photos of yesterday's installation at BSC8 in ResourceSpace. 

We restarted the internal EPICS Gateway several times yesterday in order to extend the max data size per PV to allow Rolf's new waveform record data access to the control room. The new SUS ini file problem was resolved to double-quotes in comment lines and usage of a non-supported 128Hz acquisition rate. 
The system reservation utility is being upgraded and made ready for export to LLO.

J. Garcia, J. Kissel

Turns out the BSC6 ISI is locked, so we have a perfect opportunity to sneak in a measurement while Vincent isn't looking. Wahoo!
 
We started this measurement at 
1018325503 (Apr 13 2012 04:11:28 UTC; 21:11:28 PDT)
on cdsws1 ( but logged into from the operator station [operator0?] )

We expect it should end in ~7 hours, i.e. roughly around 04:00 PDT. 

Regardless of it's finishing status (or the results from it) -- we are still a go for installing vibration absorbers tomorrow first thing. 

While Betsy and crew were re-installing the lower half of ITMY into BSC8, she was kind enough to shine a flashlight down the beam tube so I could look for signals from the four scattered light PDs associated with the arm cavity baffle, H2 hole.  I clearly saw her flashlight signature as the flashlight was shone on the inner walls of the beam tube.

A first order 70 Hz low pass filter was installed on each of the inputs to the 4 Melles Griot transimpedance amplifiers to cut down on the large high frequency noise.  The filter puts 1k in series with each transimpedance amplifier input (virtual ground node).  This should be fine at the very low light levels associated with the scattered light PDs, but would introduce nonlinearity at photocurrents much higher than 100uA or so.

Each Melles Griot amplifier was left in the 2uA peak transimpedance setting, which corresponds to a transimpedance of 10^6 V/A.  There is also a gain of 10 in the PEM BNC input channels.  The dark noise of each of the four channels as viewed on the data viewer is about 100 counts peak to peak, with small (100s of counts) DC offsets.  The flashlight test caused excursions in the viewed signals of order 1-2 thousand counts.

The PEM channels for each of H2 ITMY scattered light PDs were moved to:
PD1 - software channel 27 (written as "28" on the front of the PEM DAQ chassis)
PD2 - software channel 28 (written as "29" on the front of the PEM DAQ chassis)
PD3 - software channel 29 (written as "30" on the front of the PEM DAQ chassis)
PD4 - software channel 30 (written as "31" on the front of the PEM DAQ chassis)

The last channel of the PEM chassis is dedicated to the duotone input, so it's not