Last week Alex merged in the changes I had made to the local 40m copy of the Real Time Code Generator. These were to add a new part, called FiltMuxMatrix, which is a matrix of filter banks, as well as fixing the filter medm generation code so the filter banks actually have working time stamps.
I checked out a new version of the CDS SVN with these changes merged in. Changes that will be added in the near future by Rolf and Alex include the addition of "tags". These are pieces in simulink which act as a bridge between two points, so you can reduce the amount of wire clutter on diagrams. Otherwise they have no real affect on the generated C code. Also the ADC/DAC channel selector and in fact the ADC/DAC parts will be changing. The MIT group has requested the channel selector be freed up for its original purpose in matlab, so Rolf is working on that.
For the time being, Alex has created a directory /rtcds on Linux1 under /home/cds. He then created softlinks to that directory on megatron, c1iscex, and allegra in the /opt directory. This was an easy way to have a shared path.
After checking out the CDS SVN, we discovered there some files missing that Alex had added to his version, but not the main branch. Alex came over to the 40m and proceeded to get all those files checked in. We then checked it out again. Changes were made to the awg, framebuilder, and nds codes and needed to be rebuilt.
Certain other file name conventions were also changed. Instead of tpchn_c1.par, tpchn_c2.par, etc, its now tpchn_c1lsc.par, tpchn_c2lsp.par, etc. The system name is included at the end of the filename, to help make it clearer what file goes with what.
This required an edit of the chnconf file, which has explicit calls to those file names. Once we edited that file, we had to reload the xinetd service which its apparently a subpart of (this can be accomplished by /etc/init.d/xinetd stop, then /etc/init.d/xinetd start).
/etc/rc.d/rc.local also had to be edited for the new model names (c1lsc, c1lsp, etc).
The daqdrc file (for the framebuilder) now parses which dcu_rate to use from the tpchn_c1lsc.par type files, so the dcu_rate 20 = 16384 lines have been removed. set gds_server has also been removed, and replaced with tpconfig "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par"; from which it can get the hostname. This information is now derived from the c1SYS.mdl file.
After that Alex informed me the IOP processor needs to be running for the other models to work properly, as well as for the Framebuilder to work.
Initially there was a problem running on Megatron, because the IOP gets its timing signal from the IO chassis, and there was none connected to megatron. However, he has since modified the code so that if there's no IO chassis, the IOP processor just uses the system clock. It has been tested and runs on megatron now.
Those drawings are an OK start, but its obvious that things have changed at the 40m since 2002. We cannot rely on these drawings to determine all of the channel counts, etc.
I thought we had already been through all this...If not, we'll have to spend one afternoon going around and marking it all up.
I found the laser dead this morning.
The crane people are here to unjam it.
Laser hazard mode is lifted and LASER SAFE MODE is in place. No safety glasses but CRANE HAZARD is still active.
Stay out of the 40m lab !
We're going to have to reinstate the policy of No food / organic trash *anywhere* in the 40m. Everyone has been pretty good, keeping the food trash to the one can right next to the sink, but that is no longer sufficient, since we've been invaded by an army of ants:
We are going back to the old policy of Take your trash out to the dumpsters outside. I'm sure there are some old wives tales about how exercise after eating helps your digestion, or something like that, so no more laziness allowed!
Not dead. It just had a HT fault. You can tell by reading the front panel. Cycling the power usually fixes this.
[Steve, Kiwamu, Jenne]
The 40m is now back in Laser Hazard mode. Safety glasses are required for entry into the LVEA / IFO room.
I talked with Rolf, and asked if we were using Megatron for IO. The gist boiled down to we (the 40m) needed to use it for something, so yes, use it for the IO computer. In regards to the other end station computer, he said he just needed a couple of days to make sure it doesn't have anything on it they need and to free it up.
I had a chat with Jay where he explained exactly what boards and cables we need. Adapter boards are 95% of the way there. I'll be stopping by this afternoon to collect the last few I need (my error this morning, not Jays). However it looks like we're woefully short on cables and we'll have to make them. I also acquired 2 D080281 (Dsub 44 x2 to SCSI).
For each 2 Pentek DACs plus a 110B, you need 1 DAC adapter board (D080303 with 2 connectors for IDC40 and a SCSI). You also need a D080281 to plug onto the back of the Sander box (going to the 110Bs) to convert the D-sub 44 pins to SCSI.
LSC will need none, SUS will need 3, IO will need 1, and the ends will need 1 each. We have a total of 6, we're set on D080303s. We have 3 110Bs, so we need one more D080281 (Dsub44 to SCSI). I'll get that this afternoon.
For each XVME220, we'll need one D080478 binary adapter. We have 8 XVME220s, and we have 8 boards, so we're set on D08478s.
For the ends, there's a special ADC to DB44/37 adapter, which we only have 1 one of. I need to get them to make 1 more of these boxes.
We have 1 ADC to DB37 adapter, of which we'll need 1 more of as well, one for IO and one for SUS.
However, for each Pentek ADC, we need a IDC40 to DB37 cable. For each Pentek DAC we need an IDC40 to IDC40 cable. We need a SCSI cable for each 110B. I believe the current XVME220 cables plug directly in the BIO adapter boxes, so those are set.
So we need to make or acquire 11 IDC40 to DB37 cables, 7 IDC40 to IDC40 cables, and 3 SCSI cables.
The insects and the laser trouble... Strange coincidences with LHO surprised me, but now I have been relieved.
I picked up the ribbon cable connectors from Jay. It looks like we'll have to make the new cables for connecting the ADCs/DACs myself (or maybe with some help). We should be able to make enough ribbon cables for use now. However, I'm adding "Make nice shielded cables" to my long term to do list.
I pointed out the 2 missing adapter boxes we need to Jay. He has the parts (I saw them) and will try to get someone to put it together in the next day or so. I also picked up 2 more D080281 (DB44 to SCSI), giving us enough of those.
I once again asked Jay for an update on IO chassis, and expressed concern that without them the CDS effort can't really go forward, and that we really need this to come together ASAP. He said they still need to make 3 new ones for us.
So we're still waiting on a computer, 3 IO chassis, router + ethernet.
MOPA is back onliine. Rana found that the fuse in the AC power connector's fuse had blown. This was evident by smelling all of the inputs and outputs of the MOPA controller. The power cord we were using for this was only rated for 10A and therefore was a safety hazard. The fuse should be rated to blow before the power cord catches on fire. The power cord end was slightly melted. I don't know why it hadn't failed in the last 12 years, but I guess the MOPA was drawing a lot of extra current for the DTEC or something due to the high temperature of the head.
We got some new fuses from Todd @ Downs.
The ones we got however were fast-blow, and that's what we want The fuses are 10A, 250V. The fuses are ~.08 inches long, 0.2 inches in diameter.
The folding crane was fixed and tested this morning by the NNN rigging company. Pictures will be posted by Steve in the morning.
Afterwards, the ITM-east door was installed, jam-nuts checked. No high voltage was on for the in-vac PZTs.
The annulus spaces were roughed down to 350mTorr by Roughing Pump RP1. For this operation, we removed the low flow valve from the RP1 line.
After the spaces came down to ~400 mTorr, we closed their individual valves.
Warning: The VABSSC1 and VABSSC0 valves are incorrect and misleadingly drawn on the Vacuum overview screen.
Our idea is to have a much slower pumpdown this time than the last time when we had a hurricane kick up the dust. Looks like it worked, but next time we should do only 1/2 turn.
A little D-sub terminator was put on the Gur1 input to the Guralp box, to check again the noise level of the box.
The pumpdown started at 4 PM (2300 UTC). At 10 PM, we (Jenne, Jan, and I) opened up the RV1 valve to full open. That's the second inflection point in the plot.
As per Steve's instructions, at 12:43 AM, I used the following steps to stop the pumpdown until the morning:
Summary of this Week's Activities:
6/23: LIGO Safety Tour; Simulink Controls Tutorial
6/24: Simulink Diagram for Feedback Loop; Constructed Pendulum Transfer Function; Discussion with Dr. Weinstein
6/25: Prepare for pump-down of vacuum chamber; crane broken due to locking failure; worked through COMSOL tutorials
6/28: Ran through Python Tutorials; Began learning about Terminal
6/29: Wrote Progress Report 1 First Draft
6/30: Began editing Progress Report 1
Wednesday Morning E-log :
Most of the time through this week, i was working towards making the simulink model work.
It involved learning simulink functions better, and also improving on the knowledge of control theory in general, and control theory of our system.
1. Thusrday : found tfs for the feedback loop. and tried many different filters and gains to stabilize the system (using the transient response of the system). - not through
2. Friday : decided to use error response and nullify the steady state error instead of looking at convergence of output. tried many other filter functions for that.
Rana then showed me his files for WFS.
3. Sunday - played with rana's files, learnt how to club simluink with matlab, and also about how to plot tfs using bode plots in matlab.
4. Monday : Read about state-space models, and also how to linearize in matlab. done with the latter, but the former still needs deeper understanding.
read ray-optics theory to calculate the geometric sensing matrix.
It first requires to calculate the eigen mode of the cavity with tilted mirrors. this eigen mode is needed to be found out using ray-optics transfer matrices for the optics involved . figured out matrices for the tilted plane mirrors, and am working on computing the same for MC2.
5. Tuesday : went to Universal Studios , Hollywood :P
6. Wednesday (today) : Writing the report to be submitted to SFP.
I spent this morning populating the SUS IO Chassis and getting it ready for installation into the 1Y4 rack. I discovered I'm lacking the internal cables to connect the ADC/DAC boards to the AdL adapter boards that also go in the chassis (D0902006 and D0902496). I'm not sure where Alex got the cables he used for the end IO chassis he had put in. I'll be going to Downs after the meeting today either to get cables or parts for cables, and get the SUS chassis wired up fully.
I'd also like to confirm with Alex that the OSS-MAX-EXP-ELB-C board that goes in the IO chassis matches the host interface board that goes in the computer (OSS-HIB2-PE1x4-1x4 Re-driver HIB, since we spent half a day the last time we installed an IO chassis determining that one of the pair was bad or didn't match.
The SUS chassis has been populated in the following way:
Slot 1 ADC PMC66-16AI6455A-64-50M
Slot 2 DAC PMC66-16AO16-16-F0-OF
Slot 3-6 BO Contec DIO-1616L-PE Isolated Digital IO board
Slot 7 ADC PMC66-16AI6455A-64-50M
Slot 8-9 DAC PMC66-16AO16-16-F0-OF
Slot 1 ADC adapter D0902006
Slot 2 DAC adapter D0902496-v1
Slot 7 ADC adapter D0902006
Slot 8-9 DAC adapter D0902496-v1
Weekly Project Update:
We are studying Haixing's circuit diagram for the quadrant maglev control circuit. We have analyzed several of the sub-circuits and plotted transfer functions for these in MatLab. To check the circuit, we will compare the calculated transfer functions with those obtained from the HP control systems analyzer.
To learn how to use the control systems analyzer, we are reading App Note 243 as well as an online manual (477 pages in the first volume). We are beginning with a simple test circuit, and are comparing its measured frequencyresponse with calculated transfer functions. We currently have obtained a response graph beginning at 100 Hz (which we have not yet figured out how to print), and we are planning to investigate behavior at lower frequencies.
We also have been continuing our reading on control systems after a failed attempt at magnetic levitation.
This week I have completed following tasks:
1. Worked out the analytical expressions for the amount of power of the DC and oscillatory part going into the camera.
2. Realigned the He-Ne PhaseCam setup as we had to replace the first steering mirror after the laser with a silvered mirror ( one without a dielectric coating for 1064 nm).
3. Gone through the code written by a previous surfer (Zach Cummings).
4. Read the paper 'Real-time phase-front detector for heterodyne interferometers'- F. Cervantes et. el. where they talk about constructing a phase detector for LISA pathfinder mission. One interesting fact I found was that, they used InGaAs chip for their CCD Cam which has a amazing QE of 80% @ 1064 nm. Unfortunately, the one we are using (Micro MT9V022 CMOS) has only ~5% QE for 1064 nm and 50% for 633 nm. One top of it MT9V022 has a built-in infra-red filter infront of it to make it more insenstive to 1064. In such limitations, we may have to find a work-around for this issue. Any idea?
5. Read about the EOM and AOM and their vibrating (!) way to add on and alter the incident light on them. (Source: Intro to Optical Electronics-Yariv)
One task that we couldn't accomplish even though I planned on doing is:
1. Move,if possible, to the Nd:YAG setup.
Task for this week:
1. Produce breathtaking calibration of the camera at He-Ne setup.
2. Read 'Fringe Analysis'-Y.Surrel and 'Phase Lock Technique'-Gardner.
3. Modify the phasecam code.
4. Produce an alternate triggerbox using diodes instead of Op-Amp as op-amp is suspected to fail at some point driving the camera due to impedance mismatch.
5. Answer Koji's question at Aidan's ELOG .
I moved the Guralp box's input terminator from Gur1 to Gur2 a minute or so ago to check the other channels.
Atm 2 is showing the butterfly valve that closes down down the orifice at higher pressure to slow down the pumping speed.
See elog entry #2573
Now that the MC is back up and running, I put the Guralp seismometers at the ends of the mode cleaner. Gur1 is near MC2, and Gur2 is near MC1 (yes, it seems backwards....that's how the cable lengths work). Also, the set of 3 MC2 accelerometers are in place under MC2. I can't find the black cube for the other set of accelerometers, so there aren't any around MC1/3.
40m SURFs Razib Obaid, Nancy Aggarwal, Unknown Bearded SMURF, Megan Daily, Gopal Nataraj, Katharine Larson and Sharmila Dhevi received 40m specific safety training on June 23, 2010.
Kiwamu, Nancy, and I restored the power into the MC today:
We found many dis-assembled Allen Key sets. Do not do this! Return tools to their proper places or else you are just wasting everyone's time!
Slow pump down _pd68 has reached the vacuum normal state. CC4_Rga region is pumped now. The RGA is still off.
Precondition to this pump down: 129 days at atm, ITMs replaced. MMT, oplev and other components were removed from BSC, ITMCs. New MMT mirrors are in. IOO_access_connector was out. The end chambers were not opened.
In order to identify the output adapter of the BNC patch panel used for about 20 PEM channels, I had to disconnect its power and remove the back panel. Channels coming into that panel (seismometers and so forth) was out from 1:36 to 1:56 pm.
I did a quick check of some of the channels and it looks like its working again after putting it all back together.
Kevin sent me an email with top secret info on where one of the other accelerometer cubes was hiding (it was with his shaker setup on the south side of the SP table), so I took it and put the 3 MC1 accelerometers in their 3-axis configuration.
Also, I changed the orientation of both sets of 3 axis accelerometers to reflect a Right Handed configuration, to go along with the new and improved IFO configuration. Previously (including last night), the MC2 accelerometers were together in a Left Handed configuration.
Thanks to Steve's work on some L brackets, and Kiwamu's lifting help, we now have a new SUS IO chassis in the new 1X4 rack (formerly the 1Y4 rack), just below the new SUS and LSC computers. I have decided to call the sus machine, c1sus, and give it IP address 192.168.113.85. We also put in a host interface adapter, OSS-HIB2-PE1x4-1x4 Re-driver HIB, which connects the computer to the IO chassis.
The IP was added to the linux1 name server. However, the computer itself has not been configured yet. I'm hoping to come in for an hour or two tomorrow and get the computer hooked up to a monitor and keyboard and get its network connection working, mount /cvs/cds and get some basic RCG code running.
We also ran ethernet cables for the SUS machine to the router in 1X6 (formerly 1Y6) as well as a cable for megatron from 1X3 (formerly 1Y3) to the router, in anticipation of that move next week.
During the day, I realized we needed 2 more ADCs, one of which I got from Jay immediately. This is for two 110Bs and 4 Pentek ADCs. However, there's a 3rd 110B connected to c0dcu1 which goes to a BNC patch panel. Original Jay thought we would merge that into 4 pin lemo style into the 2nd 110B associated with the sus front ends. We've decided to get a another ADC and adapter. That will have to be ordered, and generally take 6-8 weeks. However, it may be possible to "borrow" one from another project until that comes in to "replace" it. This will leave us with our BNC patch panel and not force me to convert over 20 cables.
I also discovered we need one Contec DIO-1616L-PE Isolated Digital IO board for each Chassis, which I wasn't completely aware of. This is used to control the ADCs/DACs adapter boards in the chassis. It means we need still need to put a Binary Output board in the c1iscex chassis. Hopefully the chassis as they come in come from Downs continue to come with the Contec DIO-1616L-PE boards (they have so far).
The current loadout of the SUS chassis is as follows:
Far left slot, when looking from the front has the OSS-MAX-EXP-ELB-C board, used to communicate with the c1sus computer.
Slot 1 ADC PMC66-16AI6455A-64-50M
Slot 3-6 BO Contec DIO-32L-PE Isolated Digital Output board
Slot 7 ADC PMC66-16AI6455A-64-50M
Slot 10-11 ADC PMC66-16AI6455A-64-50M
Slot 12 Contect DIO-1616L-PE Isolated Digital IO board
Slot 10-11 ADC adapter D0902006
Kiwamu and I went through and looked at the spare channels available near the PSL table and at the ends.
First, I noticed I need another 4 DB37 ADC adapter box, since there's 3 Pentek ADCs there, which I don't think Jay realized.
Anyways, in the IOO chassis that will put in, for the ADC we have a spare 8 channels which comes in the DB37 format. So one option, is build a 8 BNC converter, that plugs into that box.
The other option, is build 4-pin Lemo connectors and go in through the Sander box which currently goes to the 110B ADC, which has some spare channels.
For DAC at the PSL, the IOO chassis will have 8 spare channel DAC channels since there's only 1 Pentek DAC. This would be in a IDC40 cable format, since thats what the blue DAC adapter box takes. A 8 channel DAC box to 40 pin IDC would need to be built.
The ends have 8 spare DAC channels, again 40 pin IDC cable. A box similar to the 8 channel DAC box for the PSL would need to be built.
The ends also have spare 4-pin Lemo capacity. It looked like there were 10 channels or so still unused. So lemo connections would need to be made. There doesn't appear to be any spare 37 DB connectors on the adapter box available, so lemo via the Sander box is the only way.
Joe needs to provide Kiwamu with cabling pin outs.
If Kiwamu makes a couple spares of the 8 BNC to 37DB connector boards, there's a spare 37DB ADC input in the SUS machine we could use up, providing 8 more channels for test use.
I connected a monitor and keyboard to the new c1sus machine and discovered its not running RTL linux. I changed the root password to the usual, however, without help from Alex I don't know where to get the right version or how to install it, since it doesn't seem to have an obvious CD rom drive or the like. Hopefully Tuesday I can get Alex to come over and help with the setup of it, and the other 1-2 IO chassis.
I went to talk to Rolf and Jay this morning. I asked Rolf if a chassis was available, so he went over and disconnected one of his test stand chassis and gave it to me. It comes with a Contect DIO-1616L-PE Isolated Digital IO board and an OSS-MAX-EXP-ELB-C, which is a host interface board. The OSS board means it has to go into the south end station. There's a very short maximum cable length associated with that style, and the LSC and IOO chassis will be further than that from their computers (we have dolphin connectors on optical fiber for those connections).
I also asked Jay for another 4 port 37 d-sub ADC blue and gold adapter box, and he gave me the pieces. While over there, I took 2 flat back panels and punched them with approriate holes for the scsi connectors that I need to put in them. I still need to drill 4 holes in two chassis to mount the boards, and then a bit of screwing. Shouldn't take more than an hour to put them both together. At that point, we should have all the adapter boxes necessary for the base design. We still need some stuff for the green locking, as noted on Friday.
We rebooted c1iovme because the lines stopped responding to inputs on C1:I00-MC_DRUM1. This fixed the problem.
I talked to Alex, and he explained the steps necessary to get the real time linux kernel installed. It basically went like copy the files from c1iscex (the one he installed last month) in the directory /opt/rtlidk-2.2 to the c1sus locally. Then go into rtlinux_kernel_2_6, and run make and make install (or something like that - need to look at the make file). Then edit the grub loader file to look like the one on c1iscex (located at /boot/grub/menu.lst).
This will then hopefully let us try out the RCG code on c1sus and see if it works.
[Jenne, Kyung Ha]
We successfully suspended the 4 eddy current dampers for the first Tip Tilt. We had some lessons learned, including how to carefully get an allen wrench in between the dampers to do up some of the screws, and how to be careful not to bend the wire while tightening the screws. More tomorrow...
I measured the RC transmitted light signals here at the 40m. I made all connections through the PSL patch panel.
Other than two steering mirrors in front of the periscope, and the steering mirror for the RFPD which were used to steer
the beam into the cavity and the RFPD respectively, no optics are adjusted.
We re-aligned the beam into the cavity (the DC level increased from 2 V to 3.83V) (Fig2) (We could not recover the power back to what it was 90 days ago)
and the reflected beam to the center of the RFPD.
I measured the spectral density of the signal of the transmitted beam behind RefCav in both time and frequency domain.
This will be compared with the result from PSL lab later, so I can see how stable the signal should be.
I did not convert Vrms/rtHz to Hz/rtHz because I only look at the relative intensity of the transmitted beam which will be compared to the setup at PSL lab.
We care about this power fluctuation because we plan to measure
photo refractive noise on the cavity's mirros
(this is the noise caused by dn/dT in the coatings and the substrate,
the absorption from fluctuating power on the coating/mirror changes
the temperature which eventually changes the effective length of the cavity as seen by the laser.)
The plan is to modulate the power of the beam going into the cavity,
the absorption from ac part will induce frequency noise which we want to see.
Since the transmitted power of the cavity is proportional to the power inside the cavity.
Fluctuations from other factors, for example, gain setting, will limit our measurement.
That's why we are concerned about the stability of the transmitted beam and made this measurement.
How do you calibrate this to Hz/rtHz?
I measured the RC transmitted light signals here at the 40m. I made all connections through the PSL patch panel. No optics/PD were touched.
We re-aligned the beam into the cavity (the DC level increased from 2 V to 3.83V)
and the reflected beam to the center of the RFPD.
Last Weds-Thurs, we wrote and edited our progress reports.
Tuesday (and Weds morning): Continued circuit analysis of Haixing's circuit and plotting transfer functions (almost have one for entire circuit). Hooked up OSEM and circuit to power supply, but the LED didn't appear to light up in IR. Now we are going to hook the OSEM directly to the power supply, sans circuit, to see if the problem is with the circuit or OSEM.
6/30: 2nd and 3rd drafts of Progress Report
7/1: 4th draft and final drafts of Progress Report; submitted to SFP
7/5: Began working through busbar COMSOL example
7/6: LIGO meeting and lecture; meeting with Koji and Steve to find drawing of stacks; read through Giaime's thesis, Chapter 2 as well as two other relevant papers.
7/7: Continued working on busbar in COMSOL; should finish this as well as get good headway on stack design by the end of the day.
I have completed the following tasks:
1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.
Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.
2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .
Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).
3. Finished writing my Progress Report 1 .
Wednesday after the meeting - Started report, learnt mode cleaner locking from Kiwamu and Rana, saw how to move optics on the tables with Rana and kiwamu.
Thursday - Made the report
Tuesday - report.
Today - am trying locking the MC with kiwamu's help to see the WFS signals and also to start characterizing the QPD.
The 1 Ton yellow crane support beam jammed up at Friday morning, June 25.
The 40m vertex crane has a folding I-beam support to reach targeted areas. The rotating I-beam is 8 ft long. The folding extension arm gives you another 4 ft.
The 12 ft full reach can be achieved by a straightening of the 4 ft piece. There is a spring loaded latch on the top of the I-beam that locks down when the two I-beams align.
This lock joins the two beams into one rigid support beam for the jib trolley to travel. The position of this latch is visible when standing below, albeit not very well.
To be safe it is essential that this latch is locked down fully before a load is put on the crane.
We were preparing to pump down the 40m vacuum system on Friday morning. The straight alignment of the 8 and 4 ft piece made us believe that
the support beams were locked. In reality, the latch was not locked down. The jib trolley was driven to the end of the 12 ft I-beam. The 200 lbs ITM-east door was lifted
when the 4 ft section folded 50 degrees around the pivot point. This load of door + jib-trolley + 4 ft I-beam made the support beam sag about 6 inches
The door was removed from the jib hoist with the blue Genie-lift. The sagging was reduced to ~3".
The Genie-lift platform was raised to support the sagging crane jib-trolley. The lab was closed off to ensure safety and experts were called in for consultation. It was decided to bring in professional riggers.
Halbert Brothers, Inc. rigging contractor came to the lab Tuesday morning to fix the crane. The job was to unload the I-beam with safety support below. They did a very good job.
The static deformation of I-beams sprung back to normal position. There are some deformation of the I-beam ~2 mm where the beams were jammed under load.
It is not clear if this is a new deformation or if the crane sections have always been mis-aligned by a couple of mm.
The crane was tested with 450 lbs load at 12 ft horizontal travel position. The folding of I-beams were repeatedly tested for safe operation. Its a 1 ton crane, but we tested it with 450 lbs because that's what we had on hand.
We're working on the safety upgrade of this lift to prevent similar accident from happening.
Atm 1) load testing 2007
Atm 2) jammed-sagging under ~400 lbs, horizontal
Atm.3) jammed-folded 50 degrees, vertical
Atm.4) static deformation of I-beams
Atm.5) unloading in progress with the help of two A-frames
Atm.6) it is unloaded
Atm.7-8) load testing
Atm.9) latch locked down for safe operation
Atm.9) zoom in of the crane sections misalignment
I also removed two of the AM stabilizers from the 1Y2 rack. The other one, which is currently running th MC modulations, is still in the rack, and there it is going to remain together with its distribution box.
I stored both AM stabilizers and the Stochmon box inside the RF cabinet down the East arm.
We made some good progress on suspending the Tip Tilt ECDs today. We finished one whole set, plus another half. The half is because one of the screw holes on the lower right ECD somehow got cross threaded. The ECD and screws in question were separately wrapped in foil to mark them as iffy. We'll redo that second half tomorrow. This makes a total of 2.5 (including yesterday's work) ECD backplanes suspended. The only thing left for these ones is to trim up the excess wire.
We also (with Koji) took a look at the jig used for suspending the mirror holder. It looks like it was designed for so many Tip Tilt generations ago as to be basically useless for the 40m TTs. The only really useful thing we'll get out of it is the distance between the suspension block and the mirror holder clamps. Other than that we'll have to make do by holding the mirror and block at the correct distance apart, utilizing a ruler, calipers, or similar. Rana pointed out that we should slightly bend the blade springs up a bit, so that when they are holding the load of the mirror holder, they sit flat.
Attached below are 2 different pictures of one of the ECD backplane sets that has been suspended. One with black background to illustrate the general structure, and one with foil background to emphasize the wires.
We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th. This corresponds to the same day that some other upgrade computers were installed. Coincidence?
We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number). No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000. Except sometimes it is 0x2000. Anyhow, it's bad, and we can't make it good again.
I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)
Rana found out that a connection was bad in the shown place, due to which the MEDM screen was showing bad offset for length control.
Basically, the offset slider value would not go into the system because of that bad connection, and was locking the mode cleaner at the wrong location.
Nancy and Koji:
This is what I and Koji measured after aligning the MC in the afternoon.
MC_Trans 4.595 (avg)
MC_Refl 0.203 (avg)
power = 1.34mW
13.5% width : x=6747.8 +- 20.7 um , y = 6699.4+- 20.7 um
Hmm. I expect that you will put more details of the work tomorrow.
i.e. motivation, method, result (the previous entry is only this),
and some discussiona with how to do next.
The fundamental problem is way back when I built the new LSC model using "lsc" as the name instead of something like "tst", I forgot to go to the current frame builder master file (/cvs/cds/caltech/chans/daq/master) and comment out the C1LSC.ini line. Initially there was no conflict with c1susvme, because the initially was dcu_id 13. The dcu_id was eventually changed to 10 from 13 , and thats when it conflicted with the c1susvme2 dcu_id which was also 10. I checked it against wiki edits to my dcu_id list page and I apparently updated the list on May 20th when it changed from 13 to 10, so the time frame fits. Apparently it was previously conflicting with C0GDS.ini or C1EXC.ini, which both seem to have dcu_id = 13 set, although the C1EXC file is all commented out. The C0GDS.ini file seems to be LSC and ASC test points only.
The solution was to comment out the C1LSC.ini file line in the /cvs/cds/caltech/chans/daq/master file and restart the framebuilder with the fixed file.
After talking with Rolf, and clarifying exactly which machine I wanted, he gave me an 4600 Sun machine (similar to our current megatron). I'm currently trying to find a good final place for it, but its at least here at the 40m.
I also acquired 3 boards to plug our current VMIPMC 5565 RFM cards into, so they can be installed in the IO chassis. These require +/- 5V power be connected to the top of the RFM board, which would be not possible in the 1U computers, so they have to go in the chassis. These style boards prevent the top of the chassis from being put on (not that Rolf or Jay have given me tops for the chassis). I'm planning on using the RFM cards from the East End FE, the LSC FE, and the ASC FE.
I talked to Jay, and offered to upgrade the old megatron IO chassis myself if that would speed things up. They have most of the parts, the only question being if Rolf has an extra timing board to put in it. Todd is putting together a set of instructions on how to put the IO chassis together and he said he'd give me a copy tomorrow or Monday. I'm currently planning on assembling it on Monday. At that point I only need 1 more IO chassis from Rolf.
When I asked about the dolphin IO chassis, he said we're not planning on using dolphin connections between the chassis and computer anymore. Apparently there was some long distance telecon with the dolphin people and they said the Dolphin IO chassis connection and RFM doesn't well together (or something like that - it wasn't very clear from Rolf's description). Anyways, the other style apparently is now made in a fiber connected version (they weren't a year ago apparently), so he's ordered one. When I asked why only 1 and what about the IOO computer and chassis, he said that would either require moving the computer/chassis closer or getting another fiber connection (not cheap).
So the current thought I hashed out with Rolf briefly was:
We use one of the thin 1U computers and place that in the 1Y2 rack, to become the IOO machine. This lets us avoid needing a fiber. Megatron becomes the LSC/OAF machine, either staying in 1Y3 or possibly moving to 1Y4 depending on the maximum length of dolphin connection because LSC and the SUS machine are still supposed to be connected via the Dolphin switch, to test that topology.
I'm currently working on an update to my CDS diagram with these changes and will attach it to this post later today.