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 }
K. Arai
Based on a discussion with Jeff K, change of the channel names from H2:SUS-*-*-OSEMOUTF-*
to H2:SUS-*-*-COILOUTF-*
was carried out.
The point is that this naming should be better as they are actually connected to the coils, not to the OSEM sensors.
- ITMX/ITMY/FMX/FMY/BS models were influenced and action has been made.
- Scripts using OSEMOUTF are to be influenced. (need attention)
- Related simulink models were updated and running with green status
- Related MEDM screen were updated
- Related filter definitions (.txt files), daq configuration for slow and fast channels (.ini files) were updated. (i.e. the same filters as before have been loaded).
Detailed procedure
1. Update the simulink models for QUAD and BSFM
Any "OSEMOUTF" related names and descriptions were changed to "COILOUTF" and so on.
The modification has been done on the following files in /opt/rtcds/lho/h2/userapps/release/sus/common/models/
BSFM_MASTR.mdl
QUAD_MASTR.mdl
2. Replace the filter names in the "chans" file
Before building and installing the new models, the filter names in the "chans" file should be replaced
as the installation script tries to inheret the previous configuration. If this replacement is not done before the installation,
the previous filter coefficients are lost in the new files, and the entry for the new blank filters are created.
Once this happens, we will have to move the filter definitions from the old files with foton (one by one).
This is painful. So we need this operation!
Any instances of "OSEMOUTF" in the following files are replaced to "COILOUTF"
(in /opt/rtcds/lho/h2/chans/
)
H2SUS_ITMX.txt
H2SUS_ITMY.txt
H
2SUS_FMX.tx
t
H
2SUS_FMY.tx
t
H2SUS_BS.txt
3. Replace the channel names in the daq configuration files
Also the DAQ configuration should be taken over at the build for the same reason.
This should be done for both of the fast and slow channels.
Any instances of "OSEMOUTF" in the following files are replaced to "COILOUTF"
(in /opt/rtcds/lho/h2/chans/daq/
)
Slow channels:
H2EDCU_SUSITMX.ini H2EDCU_SUSITMY.ini H2EDCU_SUSFMX.ini H2EDCU_SUSFMY.ini H2EDCU_SUSBS.ini
Fast channels:
H2SUSITMX.ini
H2SUSITM
Y.ini
H2SUSFMX
.ini
H2SUSFM
Y.ini
H2SUSBS
.ini
4. Bulld the models
h2susitmx, h2susitmy, h2susfmx, h2susfmy were built and installed. I have noticed that there has been no BS model yet.
5. Restart the realtime codes
At h2susb478
, h2iopsusb478, h2susitmx, h2susitmy have been restarted.
At h2susb78
, h2iopsusb78, h2susfmx, h2susfmy have been restarted,
6. Restart the data concentrator
The daq status signals returned to green.
7. Update MEDM screens
The medm screens in the following directories were to be updated
/opt/rtcds/lho/h2/userapps/release/sus/common/medm/QUAD/
/opt/rtcds/lho/h2/userapps/release/sus/common/medm/BSFM/
a. The files which contains OSEMOUT in their names were renamed
(in BSFM)
SUS_CUST_BSFM_M1_COILOUTF.adl
SUS_CUST_BSFM_M2_COILOUTF.adl
(in QUAD)
SUS_CUST_QUAD_L1_COILOUTF.adl
SUS_CUST_QUAD_L2_COILOUTF.adl
SUS_CUST_QUAD_M0_COILOUTF.adl
SUS_CUST_QUAD_R0_COILOUTF.adl
b. change any instances of "OSEMOUT" to "COILOUT".
This includes the replacement of the channel names as well as the filenames.
(in BSFM)
SUS_CUST_BSFM_OVERVIEW.adl
SUS_CUST_BSFM_M1_COILOUTF.adl
SUS_CUST_BSFM_M2_COILOUTF.adl
(in QUAD)
SUS_CUST_QUAD_OVERVIEW.adl
SUS_CUST_QUAD_R0.adl
SUS_CUST_QUAD_L1_COILOUTF.adl
SUS_CUST_QUAD_L2_COILOUTF.adl
SUS_CUST_QUAD_M0_COILOUTF.adl
SUS_CUST_QUAD_R0_COILOUTF.adl
8. Confirm dataviewer and each medm screen shows right things
9. Commit the Simulink models and MEDM screens to the svn
Summary. Field trials are about to begin for elimination of Time Error Correction (TEC), the practice of running the power grids at 59.98 or 60.02 Hz for short periods to keep 60 Hz clocks accurate. This change in 60 Hz regulation should be neutral or help with detection of the Crab pulsar at 59.4 Hz because it is expected to reduce low frequency excursions and the new average grid frequencies are expected to be higher, about 60.002 (LLO) and 60.0009 (LHO). The North American Electric Reliability Corporation (NERC), is planning on changing the regulation of the 60 Hz frequency for the eastern (LLO) and western (LHO) power grids, raising questions about how this may effect detection of the Crab by changing the tails of the 60 Hz peak. I talked with Andy Rodriquez (andy.rodriquez@nerc.net), Director of Standards Development at NERC, and reviewed NERC documents to asses the proposed elimination of Time Error Correction, which would mean that, over the long term, the average line frequency would not be precisely 60 Hz. The power grid frequency varies from 60 Hz when supply and demand become unbalanced. When power use increases with morning activities, or a generator shuts down, the frequency decreases. Figure 1 shows a low frequency excursion from loss of generation. As demand drops off at night or as more generators come on line, the frequency increases. Figure 2 shows that morning and night are particularly susceptible to frequency excursions. Figure 3 shows the rms deviation from 60 Hz for the different grids in 1996. Several control mechanisms affect the line frequency and are used either to minimize frequency departures from 60 Hz or to adjust financial balances between the generating authorities. Organized by time scales, the control mechanisms are: 1) primary control, on a second to minute scale, consisting of independent generator governors that increase or decrease, e.g., the flow of dam water to turbines when a deadband of, typically, 36 mHz is exceeded. Primary control also includes Automatic Generation Control (AGC), automatic control of clusters of generators, 2) secondary control, on a scale of 1 – 10 minutes, includes AGC and manual phone calls to power plants and other load management actions, 3) tertiary control, on a scale of 10 minutes to hours, includes adjustments of purchases from generating facilities and bringing generators on or off-line to meet demand, and 4) time and inadvertent interchange control, on a scale of hours. Inadvertent interchange control involves frequency changes when financial balances between generating authorities are manipulated. For example, if a regional authority inadvertently provided less energy than it sold, in order to compensate it may run its generators slow while other authorities on the grid run fast. Finally, on a multi-hour scale, the difference between the average frequency and 60 Hz is corrected by purposefully running the grid for a short time at 60.02 or 59.98 Hz. These Time Error Corrections are instigated manually (e.g. by phone to power plants) in the eastern grid and automatically (WATEC) or manually in the western grid. They are initiated when a clock using the 60 Hz line frequency would be inaccurate by +/- 10 s (Eastern Interchange) or +/- 2 s (Western Interchange). NERC proposes to eliminate Time Error Correction, claiming that the only benefit lies in improving the accuracy of 60 Hz clocks, which are becoming outdated by commonly available and more accurate time pieces. In fact, Time Error Correction tends to decrease frequency stability: a study showed that 40% of the excursions below 59.95 Hz (an alarm threshold) in the Eastern Interconnection occurred during periods when the grid was running at 59.98 Hz to correct clocks. So, from a LIGO perspective, elimination of Time Error Correction will be beneficial because it will reduce the extent of low frequency excursions that further reduce frequency when the grid is running at 59.98 Hz. During frequency emergencies, e.g. for a large unscheduled shutdown of generation facilities, the frequency is raised by the primary through tertiary controls mentioned above. Time Error Correction plays no role in these emergencies and is only used after the fact to make up for frequency excursions. Furthermore, there is a tendency for power authorities to err on the side of over-generation rather than under-generation because negative consequences begin at smaller deviations on the low frequency side than on the high frequency side. So without time error correction, the average frequency is expected to be slightly higher than 60 Hz. Based on past time error corrections, the new average grid frequency for the Eastern Interconnection (LLO) is expected to be about 60.002 Hz and, for the Western Interconnection (LHO) about 60.0009 Hz. The Crab gravitational wave frequency is expected to be about 59.4 at the beginning of aLIGO, so elimination of Time Error Correction should be neutral or slightly helpful.
Wall panels were put into place in the acoustic enclosure. Work is coming along pretty smoothly, no big issues so far.
In other news, the laser should be arriving on site early Monday.
- Gerbig working on clean room by H2 PSL - PSL delivery expected this afternoon is delayed until Monday as freight waits in Seattle - ICC in BSC8 continues - Farewell to RobertL, RolfM, RyanL - Stoneway delivery for EE people - Much mechanical and electrical activity in H2-ITMY test stand area - MichaelR transitioning LVEA to laser hazard at 1650
Betsy B., Andres R, Jeff B. We attached the lower wires to the FM in the Staging Building. All masses are now suspended with no apparent gross problems. There is a small amount of pitch in the Top Mass, which we will work on next week.
The remaining chamber floor and ring sections were brushed although tools remained problematic. As of 2:30 pm, 32 sections had been through first vacuum. The crew will stay in chamber today until the entire upper chamber has been vacuumed so that we can pull the bellows protection and get fibers off the support tubes on Monday.Zack and Randy were able to work on drills a little bit today which is good because the small replacement bearings arrived.
Moved SUS ITMY Sattelite Rack to southwest corner of ISI cleanroom. H2 ISI ITMY field cables were re-routed to move excessive wire bundles out of clean room area. Swapped out cabling for appropriate lengths (GS-13, T240, L4C, and CPS). Ran cabling inside clean room while staying clear of floor. H2 SUS ITMY sattelite amplifiers were swapped out. Modifications to units are: 1.Replace IC551 & IC552 AD797's with OP27's 2.Replace L101, L201, L301, & L401 with 100 ohm resistors 3.Remove C107, C207, C307, & C407 capacitors. 4.Replace R102, R202, R302, & R402 160k resistors with 121k resistors R. McCarthy, F. Clara, J. Garner, D. Stone