J. Bartlett, V. Brocato, J. Kissel After restoring the functionality of the SUS BSC Test Stand, Jeff and Virginia installed new Flat Flags D1100573 on BSFM01 in the staging building, and then installed and aligned the already-cabled up OSEMs. We then centered the M1 flags both in the sensitive axis ("In and Out", to a 15k count offset) and together we ran through an OSEM diagonalization to align the flags perpendicular to the sensitive axis (using those pesky CAM Nuts). Though the M2 stage OSEMs were centered along the sensitive axis (again assuming 15k offset), we did not attempt to do any better perpendicular alignment than by eye. OSEM diagonalization templates for a Test Stand BSFM live in /ligo/svncommon/SusSVN/sus/trunk/BSFM/X1/Common/dtt_templates/BSFM_OSEMDiagonalization_*.xml Just because -- I took a high resolution version of the same thing, when the suspension has settled nicely for an evening, and is wrapped up in a C3 shroud, to see how good we can do. See attached .pdfs. As we have seen in the past F1 is the worst offender at about 10 - 15dB isolation from the drive degree of freedom when driving in both Vertical and Yaw (and it should not be sensitive to either). Other OSEMs (coherently) show 30 dB of isolation or greater, which is expected.
V. Brocato, J. Garcia, J. Kissel, A. Ramirez, R. Mittleman We've finally received a load of Class A in-vacuum peek cables from Caltech (ICS Shipment-1998), in which were several lengths of Seismically-Responsible Suspension Cables (SRSCs), D1000225's. Suspensions had been waiting on these since the mate, such that we might have sufficient cable length to connect up the H2SUSITMY QUAD appropriately through the isolation stages of the BSC-ISI, as per the System's drawing D1101477. Upon receiving them, Virginia inventoried what was shipped (Drawing and Serial Numbers, see attached's first and second column) because we were informed that what was in ICS was not complete -- which has been confirmed. After identifying that we had a significant number of the needed D1000225s, we went though them to identify their lengths (see third column). D1101477 suggests that we need the 180" length for ITMY and 199" lengths for the FMY, but (as confirmed by Kate Gushwa at Caltech) there were none of the 180" lengths in this load. We did find six of 199" length. Hoping to press forward, Jeff, Rich, and I began by re-arranging / de-tangling the cables that were coming off of the QUAD, and then assessed what we were missing in order to continue. We didn't get very far. After using the site-aside-because-they're-not-needed UIM Stop Plates as temporary optical table cable clamps, and merely draping the D1000225s over the ISI, we came up with the following list: - Allen key for removing gender benders - Cable Brackets (D1001346) and associated hardware - Cable Clamps (peek / viton / metal / otherwise) and associated hardware - Aluminum cable labels (made by G2 earlier in the week) - Cross brace cable clamp hardware and instructions on how to use them - Class B fake feedthrough - 3/8-16 and 1/4-20 bolts of varying lengths Also, upon reviewing / actually trying to implement the cable path up the BSC-ISI defined in D1101477, we noticed that the launch and land of the cables from Optical Table/Stage 2 to Stage 1 happens rather quickly. I think perhaps there is some confusion as to what is Stage 2 and what is Stage 1 (which is admittedly confusing with the nested structure of the BSC=ISI). First impressions from Rich and I would have guessed that the cable should make the transition from the optical table to running up the side of Stage 2, before making the important jump between isolation stages. As it is shown now, there is lots of slack on the cable, and the probability for rubbing / mechanical shorts are high. Further, though the D1101477 doesn't show it, that area is already crowded with BSC-ISI cables, making routing more difficult than what is shown in the SolidWorks rendering. Pictures attached!
K. Arai
H2 CDS freezed at around 9pm and any of the epics channels are currently white.
It seems to be a spontaneous crash as no one was working on the realtime codes itself.
We await for the restoration action by the experts for an hour and leave the site if not avilable.
Dome is back on--Jimw GregG Scott Slim MarkD Hugh We dropped the iLIGO Support Table into the chamber and it landed (in a very controlled way) onto the Support Tubes. We bolted the Table to the Tubes to fix the Support Tubes' relative position. We balanced the position of the Support Tubes wrt the Chamber and then secured them to the Crossbeam via the V-Blocks. We then disconnected the Table from the Tubes and pulled it from the Chamber. It was a little trapped between the Support Tubes suggesting we hadn't been as iterative in the torquing of the V-Blocks to the Crossbeam as we should have been. We tweaked the a V-Block outward and the Table slipped out. We wrapped up the day by replacing the Dome and the East Door Cover after we emptied the chamber of our detritus. Some photo of the day: 1) The Jib Cranes holding the Support Tubes-there is one of these at each of the four corners. 2) The Support Table flying toward the Chamber. 3) The Support Table bolted to the Support Tubes. 4) GG hoping to not be forgotten! Thanks Crew, good job!
The Support Tubes were set horizontally wrt the Chamber D nozzles to < +- 1/16", maybe closer to +-1/32.
Usual deliveries in the morning: Praxair Unifirst Paradise water Swageloc delivery and rental pick-up Activities: Patrick to take dust monitors to End-Y In-chamber cleaning in BSC8 – finished just before 4pm. Seismic work at End-Y station
Had issues with the signal input selection monitor bits for the PUM. A test bit controls where the drive signal for each channel comes from. The PUM has two DB9 connectors, "DRIVE IN" or "TEST IN". See Jeff Kissel Alog - QUAD BIO I/O Simulink/MEDM Upgrade for further details. This test bit controls a relay that selects from "DRIVE IN" or "TEST IN". Attached to this circuit are two transistors that output the state of the relay. When the relay was activated, it would respond by switching. The problem came from the rest of the circuit, where the input voltage on this bit was around 0.8V. This was enough voltage to keep the base of the transistor "on" regardless of the state. Jay Heefner recommended we switched out R111 on all four channels from 10K to 100K. Did modifications on PUM Chassis SN S102650. Unit is back in SUS rack and monitor channels are all working. F. Clara, J. Heefner, R. McCarthy
Correct SN of Chassis is S1102650.
Used aux. pump cart to "hog" out HAM1, HAM2 and HAM3 annulus volumes -> no change in vertex pressure -> will continue hunt tomorrow
The Viton vibrational absorbers (VA's) were added to the sleeve of the mated Quad in the LVEA last Friday. The VA's were clamped to each of the four posts of the sleeve of the Quad in a "spiral" configuration which means they were stepped up incrementally around the Quad. An accelerometer was inserted into each VA and tap tested using a B&K hammer. The hammer's software plotted each impulse response and confirmed the hammer had not "double-hit" the surface. First, each VA was tapped individually parallel and perpendicular to the orientation of the accelerometer in the VA. Each attached "vibration_absorber_##" pdf file has the parallel response on the first page and the perpendicular on the second. The "##" corresponds to the S/N of the VA. Here we simply have images of the plots for analysis. Next, 3 locations on the Upper Structure, 4 locations on the Lower Structure, and 4 locations on the Sleeve Structure were chosen for tap testing. The impulse responses are plotted along with a picture showing their locations on the assembly. The last image is a close-up of one of the VA's. Each plot has each of the X,Y, and Z DoF responses of the accelerometer. Exporting the data into text files was discovered after these tests were ran so we would not have to rely on images of the responses. The ability to process the data via MATLAB is currently in development.
Mark, Scott, Chris, and Carolyn worked out at the chamber today. Wipe down with isopropanol was completed and all of Rai's requested samples were taken. The floor was re-installed so that 2nd vacuum could begin early tomorrow. Zack worked on air drill dis-assembly. Some of the tools for the dedicated clean assembly space arrived today. Mark H. and I talked about safety concerns related to my "walk" down the beamtube to survey fiber content in the low spots. We agreed that I would only go a short distance down the tube (max. 5 ft) and that Safety will work on a Hazard Analysis for longer beamtube "walk-abouts".
I have put the MetOne 227B dust monitor with serial number 980500282 in the VEA (not in any clean room) at end Y. Both the sample and the holding time are set to 1 minute.
This entry covers work from last Fri-today.
(Corey, Eric, Greg, Jim)
BSCISI#1
Capacitive Position Sensors (CPS) were replaced on this assembly. There was bad solder/flux on these CPS. The new CPS were installed and need to be aligned and have their gaps set; will do this and re-balance the system when the SUS team is done with their work.
BSCISI#3
Stage1 Close Out Plate & Cover were installed & torqued down. Inner Hex and Outer Walls have been installed for upcoming Keel Installation. The Top-Facing Keel is getting helicoiled.
GregG JimW Slim Kevin Ed & Hugh Re-Work Permit #2875/E1100715 On Monday afternoon we pulled the East cover from BSC6 (Inner O-ring is missing) so Jim could go in and disconnect the Wire Straps holding the Support Tubes in place. Then using the Jib Cranes mounted on the Crossbeams, we lifted the Support Tubes so the Chocks could be removed from the D-Nozzles. The dome was pulled and crammed into place on the North side of the BeamTube. Today we planned to install the iLIGO Support Table to the Support Tubes and then connect the Support Tubes to the Crossbeams via the V-Blocks.
J . Kissel, K. Arai Given that we have a more complete understanding of the QUAD's Binary Input/Output (BIO) switching (arising from conversations with Jay, Filiberto, and Richard, putting it together in T1100378, changing cryptic channel names, and using the monitor chassis), I've reflected the current state of knowledge by giving the BIO simulink block and BIO MEDM screen some TLC. Attached are screenshots of the results. A few interesting points - For every stage, there is a "TEST/COIL" control and corresponding "SIGNAL INPUT SELECTION", TEST or AI monitor bit. Having the control bits set to "TEST" (0) switches the input to the TEST inputs, a separate DB9 connection on the front of the Coil Driver Chassis. Nominally, the output of the Anti-Imaging (AI) Chassis is hooked up to the COIL DB9 inputs. Hence, if you want any drive signal to get from the digital system out to the OSEM COILs, one needs to control the TEST/COIL bits to 1, which corresponds to "AI ENABLED," or a 1 on the monitor bits. - Since have thing control bits set to "TEST" is rarely (if ever) a useful setup, I've colored the monitor bits of the SIGNAL INPUT SELECTION to show YELLOW / RED when the TEST bits are enabled, because it means that no digital drive signal is being received by Coil Drivers. (In the screen capture, the L2/PUM monitors demonstrate this color scheme). - Speaking of the L2/PUM bits, the signal input selection monitor bits are currently busted. The monitor AND ONLY THE MONITOR is stuck in the "TEST" state. Filiberto has discovered that this is because the TEST state corresponds to the "low" (0 V) relay state, and the circuit is still receiving some amount of voltage when switched low, just above the threshold (0.8 V, where the threshold is 0.7 V or something like that). We have confirmed through directly measuring output voltage, and indirectly measuring the outputs via the monitor I/O chassis, that the CTRL bits are working just fine. - Of particular interest to the end users, the suggested states of operation (hexidecimal values entered into:SUS- _ _CTRL) are "hard-coded" written into the MEDM screen - In the simulink model, the EPICs input channels that control the BIO CTRL bits are burried inside the QUAD_MASTER.mdl model, and given cleaner, self-explanatory names repesented on the MEDM screen. And the up-most level of the main diagram (h2susitmy.mdl) design philosophy of having only unique input and output parts on that level has been restored. A few details of the upgrade: The compilation process involved a great deal of excruciating guess and check work. Regrettably, the final design involves lots of notoriously flaky CDS_PARTS, including bus creators/selectors, tags, DIO blocks, bit2word and word2bit parts. In the end, the most painful discoveries were the following: (1) The interaction between what Simulink was designed for and the RCG requires the need for a unit delay *somewhere* in the DIO input / output chain. In reality, the DIO block represents 64 input bits and 64 output bits that are causally disconnected. However, its representation in Simulink appears as though it part of a linear system (like it's a filter bank or something). Hence when the signal chain is connected at the top most level in *what appears to be* a loop, the simulink/RCG compiler freak out when there is no clock-cycle delay between hooking up the output of this "system" to the input. Note that I specify it must be the top level -- I tested moving the unit delay into the subsystem, and it would not compile. This "freak out" is manifested in the compiler as immediately complaining that *all* the buses and tags could not be connected -- which of course lead to a red herring + wild goose chase of slowly implementing baby steps of including buses, then tags, then connecting and reconnecting signals, etc. etc. Moral off the story -- one needs a unit delay somewhere in the DIO signal in the top most level of the chain. (2) Something is terribly buggy with the cdsBit2Word and cdsWord2Bit parts. In the initial design Rolf put together, he had found the need to cdsBit2Word then immediately cdsWord2Bit each of the 4 monitor 16-bit words, before sending them to an epics variable. However, after finally succeeding in surmounting problem (1) I found that *3 of the 4 IDENTICAL connections were functional, but one was not.* Exact same parts, exact same type of input signal, exactly the same style of connection. After peppering the signal chain with test points, I had finally discovered that the cdsBit2Word -> cdsWord2Bit transfer was entirely unnecessary to begin with, so it is now completely removed.
J. Kissel, J. Garcia, V. Sandberg, F. Clara Now that the BSFM has been suspended, we set out to turn on the OSEMs and read out the open light from them. We initially noticed there was simply bit noise on the medm screens. After power-cycling the SUS test stand rack IOP and FrontEnd processes, the input values read out bit noise after checking all physical cable connections. Several reboots were in order but to no avail. It occurred to us to check the rack for any missing hardware, and lo and behold, our Anti-Aliasing chassis had disappeared from its seat in the rack. We went in search of what we knew was initially installed in the rack: the Version 1 style AA chassis (the ones with the old metal tags, as opposed to the fancy new bar code stickers) in the EE shop. It was rumored this box had been transported to the LVEA for testing purposes, but was not found there either. We eventually tracked it down under a pile of electronics boxes on a shelf in the EE lab. The serial number for this particular box is now S1104801 (old number was S080010, new number to be later added) with a drawing number of D070081-V1. Functionality was confirmed and later installed in the SUS test stand rack. After re-cabling the chassis, the IOP and FrontEnd processes were ran again. Input signals read out to our satisfaction and we rolled on to the next step of preparing the assembly. The "Prepare_BSFM_06272011.m" script was then run from the '~[SusSVN]/BSFM/X1/Common/Scripts/' directory on the SUS workstation. With the appropriate medm screens open, we confirmed the script entered the offset, matrix, and switch values. The medm values confirmed we were looking at open light readout from the OSEMS.
Gerbig put up the framing for the diode room today, and added more wall panels to the anteroom and laser room.
The 200W laser arrived today and is now sitting in the large item access area, where it will sit until October. Please do not stack anything heavy on the box labeled 3. It is the only one that does not have a box stacked on top it.
Split crew: Carolyn, Chris, and Scott H. played support roles today. Mark Layne and I removed bellows protection and the started the fiber hunt on the support tubes. I took a few pix: please see below. We collected several of the more flamboyant fibers just in case anyone wants to look at them later. Then, it was time for vacuuming: bellows, ring, lower chamber, and chamber floor. Wipe down was started after lunch. Mark and I agreed on locations for Rai's wipe samples, so we will collect those as we go. Wipe down of the collar was completed. Some tooling and staging work was also completed today. Zack finished taking apart all the drills that seized when we tried to use them in this chamber. The parts have been sorted and will be cleaned. Then, we will try the LLO random re-assembly method on those. The drills that worked in chamber have been set aside for now. Randy and Mick moved the pedestals for supporting the dome and staging tables down to Y-end.
We took a decent set of system id over the weekend and it looks like all of those people who were snickering at Brian are going to have to aplogize. The signal from rX andrY stage one actuators to rX and rY stage 2 CPS is about 50-100 times larger then the signal for the other four degrees of freedom, and since we have not normalized the actuators yet we expect a few percent of cross coupling at low frequency. The results for Stage 2 Act to stage 1 CPS are more or less the same
J. Kissel, K. Arai, R. Lane, J. Garcia, R. Mittleman, B. Shapiro In eLIGO, the SUS watchdog had been cobbled together as its own CDS block quickly using iLIGO watchdogs as a model, and was never properly understood (at least by me), nor well documented. In the switch over to aLIGO RCG, I had made an attempt to simplify the SUS watchdog by taking advantage of the more simple CDS RMS filter block (see entry 1265 for details). However, I had naively used the block to take the RMS of the OSEM raw input signals and called it good, because I had assumed that the time constant of the averaging filter also defined the frequency response of what signal was being watched (as though the RMS filter was a linear block). However, after some experience using this simple watchdog, and discussions with Brett, Rich, and Koji, they've [reminded / convinced / taught] me that this isn't what we want to watch at all. Hence, we've installed band-limiting filters between the raw OSEM signals and the RMS filter. The frequency response of this filter is attached, but can be described by the following bit of design code: bandLimPoles = [0.1 10 10]; bandLimZeros = [0]; bandLimFilter.c = zpk(bandLimZeros,-2*pi*bandLimPoles,1); gain = abs(squeeze(freqresp(bandLimFilter.c,2*pi*1))); bandLimFilter.c = bandLimFilter.c / gain; The motivation behind this shaping of the signal is as follows: - The frequency band in which the suspensions are moving the most is between 0.1 Hz and 10 Hz, given that all resonances for all degrees of freedom are confined to this band. - Above 10 Hz, the OSEM signal is dominated by sensor noise, and hence is not useful as a watchdog signal. - Even if there were useful signals above 10 Hz, (a) the coils and coil drivers do not have the strength to push the suspension around, (b) the suspension's response to actuation is rolling off drastically anyways, and (c) given that this frequency band is above the fundamental resonances of the suspension, if the suspension point is driven at 10Hz and above, the significant passive isolation should provide sufficient protection. - The OSEM signal must be AC coupled, or else the RMS is dominated by the DC offset of the OSEM which is not useful as a watchdog signal. We are interested in the position amplitude RMS around the resonances, such that we can catch large, on-resonance, amplitude motion that would drive the suspension into its stops, In other words the response of the signal fed into the RMS filter should be flat, since OSEMs are inherently a position sensor. That means there must be *some* pole frequency where we switch from an AC coupled velocity RMS to flat position RMS. If this pole frequency is too low, the position RMS of the resonaces will be washed out by the inherently large low-frequency motion. Hence, as a first, reasonable guess, we've chosen 0.1 Hz -- just below the lowest longitudinal resonance. - As mentioned in aLOG 1265, the step response of the RMS filter is roughly 7 seconds. This is another goldy-locks problem, in that if the step response is too long or too short then one loses functionality. We know 100 seconds is too long, 1 second is too short. Given that we're "stuck" with 7 seconds we figured it would suffice for now. In summary, the exact shape (where to put the poles and zeros) of the signal to be RMS'd is quantitatively arbitrary, but the response now has the right qualitative shape. Poles at 0.1 and 10 Hz can be tweeked later if necessary, and given increased functionality in the RMS block we could adjust the time constant. The watchdog now has the right functionality for the system at hand . I also attach pictures of the infrastructure - osemwatchdogsimulink.png: screenshot of the signal flow of an OSEM sensor flag generator in the QUAD_MASTER.mdl simulink diagram (found in the QUAD//WD/OSEM/ subsystem, isoStage=[M0, R0, L1, L2]) - osemwatchdogmedm.png: screen shot of a given stage's watchdog MEDM screen. The OSEM BAND LIMITERS bank is button that takes you to - osembandlimmedm.png: the filter banks where the band limiters are defined in FM1. The last attachment is a spectra of an L1 OSEM comparing the signal before and after the bandlimiting filter, just to prove it's functionality. The suspension is locked and not plugged in, so the actual signal is rather meaningless. Once we get a functional suspension, I'll put the effort into making a calibrated plot, containing more useful information,
J. Kissel, R. Lane, K. Arai, J. Garcia, R. Mittleman An integral part of the suspension watchdog system is the aLIGO RCG's cdsRms block (design details to follow), so I wanted to give it a little extra attention. As of RCG 2.3 and later, this block is implemented with the following C Code: 1 float rms; 2 static float rms_avg; // which means rms_avg is a persisent variable between loop iterations 3 if(feInit) // If it's the first loop cycle 4 { 5 rms_avg = 0.0; 6 } 7 else 8 { 9 // RMS: RMS 10 rms =; 11 if(rms > 200000) rms = 200000; 12 if(rms < -200000) rms = -200000; 13 rms = rms * rms; // HERE'S THE SQUARE 14 rms_avg = rms * .00005 + rms_avg * 0.99995; // HERE'S THE LOW PASS, "MEAN" 15 rms = lsqrt(rms_avg); // HERE'S THE SQUARE ROOT 16 Of particular interest here is the low pass filter that defines the averaging time constant (defined on line 14). Given the above c-code, the filter is defined in a standard format, with the following loop structure (taking x = rms * rms, A = 0.00005, and y = rms_avg): +---+ x ----| A |-----( + )----------------------------- > y +---+ | | | | | +-------+ +--------+ | +--| (1-A) |--| z^(-1) |--+ +-------+ +--------+ which should nominally have a transfer function H(f) of y = A * x + y * (1-A) * exp(- 2 * pi * i * f * T) // identical to line 14!! y * (1 - (1-A) * exp(- 2 * pi * i * f * T) ) = A * x H(f) = y / x = A / (1 - (1-A) * exp(- 2 * pi * i * f * T) ) where f is the frequency vector and T = 1/fs is the sampling time. This transfer function corresponds to a single pole at f = 1/(2*pi*T)*log(1/(1-A)) This means for a fixed A, the averaging pole is dependent on the sampling rate fs of the model using the RMS block. For future upgrades of the RCG, we should consider having an additional input to this block that defines A, such that the user can customize the filter time constant where needed, and have it adaptable to other model sampling rates. For the suspension models, running at fs = 16384 Hz, this corresponds to a pole frequency of 0.13 Hz, indicating that the RMS block has a impulse response of about 7 sec. This is coincidentally just about the right response for a suspension watchdog, at least as a first iteration. (Further design details to come).= rms; 17 }