40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 269 of 337  Not logged in ELOG logo
ID Date Author Type Category Subject
  3435   Wed Aug 18 16:42:14 2010 steveUpdatePEMPSL optical table legs load balanced

 

 Rana, Koji, Alberto and Steve, Tuesday afternoon

 

Atm3, Part of the tunnel under the table was filled with quick drying concrete this morning  to give solid support for tripod legs.

          PVC tube 6 " ID with TEE will able us to connect AP table, PSL table and Control room if needed

Atm4, Table height set to equal AP at  ~32.75 " on copper plates using 5/8-11 x 4.5" set screw-bolt in tripod foot

           Rough leveling was done by 4 individual levels at the four corners with 9" long Stanley cast aluminum levels.

          Load balancing of the total weight  ~ 3000 lbs over  6 legs x3 = ~170 lbs on each jack screw with Snap-On torque wrench at 140 lbs/ft

Atm1, Three crew members at work. Prof. Rana's calibrated right hand was used at jack screws where insufficient space was available for socket head wrench.

Atm2, Table is ready for no shrink grouting now.

         

 

 

 

 

Attachment 1: P1060671.JPG
P1060671.JPG
Attachment 2: P1060674.JPG
P1060674.JPG
Attachment 3: P1060670.JPG
P1060670.JPG
Attachment 4: P1060676.JPG
P1060676.JPG
  3434   Wed Aug 18 12:24:58 2010 josephb,kiwamuUpdateCDSshmem issue

Apparently its possible to have working models get into a bad state in regards to shared memory, which prevents the model from working after killing it and restarting it.  We found that by shutting all the models down, and then killing and restarting the setup_shmem process, it allowed models to function properly again.

The symptom was getting stuck at the burt restore step, according the log files (/opt/rtcds/caltech/c1/target/c1SYS/logs/log.txt).

  3433   Wed Aug 18 12:02:29 2010 AlastairConfigurationComputerselog had crashed again...

...I restarted it.

  3432   Wed Aug 18 11:40:59 2010 josephb,kiwamu,yoichiUpdateCDSEnd station working with latest RCG code

We were able to get the latest SVN checkout (revision 2009), working with the c1x00 (IOP) and c1vgl models at the new X end on the c1iscex machine.

We were unable to get it working yesterday, and as far as we can tell, the only significant change was a reboot of the c1sus machine.  Before the reboot, it did not look like there were any conflicting models running on the c1sus machine, but apparently something was preventing the models on c1iscex from running properly.

Other simulated plant models still need to have their shared memory location blocks updated to the new type.

Now that we have proved we still can get the end model running, we are moving onto the c1sus machine.

  3431   Tue Aug 17 23:59:46 2010 KatharineUpdateelogMaglev update

Katharine, Sharmila

Update: 
We haven't been posting in the elog regularly, for which we are very sorry.  We have been taking notes in our log books, but we ought to have posted here as well.  We apologize and now present an overview of what we've been up to.

Some time ago, we created a Simulink model to predict the response of our system, but for the model to be useful we needed to include approximately correct gains for each block in the diagram, including the magnet force and coil force gradients and OSEM "gain." We also needed to better quantify the 1x1 levitation.


Adjusting the potentiometers:

The circuit which converts current to voltage in the Quadrant maglev control has a variable resistor. This is useful as it gives us a way to zero the current when the levitated object is in the equilibrium position. It was done as follows. The output voltage from the circuit converting current to voltage is fed into the oscilloscope. The voltage values for zero and complete blockage of the LED is noted(say 2V). We adjust the resistor to make the voltage output to be V when the flag completey bolcks the LED. This gives a zero current when the flag is in the equilibrium position.

OSEM Calibration:

The OSEM works by blocking the light that goes into the photodetector from the LED by a flag. To simulate the model we had on simulink, we needed to find what the gain of the OSEM was. The gain of the OSEM is the current it gives per unit displaccement of the flag. To determine this we attached a micrometer to the OSEM flag. The micrometer was long eneough to push the flag to completey block the OSEM. We connected the output of the PD test point (which was the voltage after the photodiode current was converted into voltage) to the oscilloscope. We noted down the voltage difference in the oscilloscope with a fixed reference for different positons of the flag. From the oscilloscope output, we were able to get the PD current. We then selected a linear region of the plot of PD current vs flag position(which is usually in the middle) to fit the graph with a straight line. The slope gives the OSEM gain.

Magnet strength
    We need to know about the relative strengths of our magnets (levitated and fixed in the coil) in order to do magnet matching.  We used a Gaussmeter to measure the field from each coil magnet at  ~2 mm away from the center (the probe was fixed to an aluminum block, so that the tip had the same vertical separation for each of the four fixed plate magnets).  We labeled each of the four magnets and calculated the field at this distance to be 0.206 kG, 0.210 kG, 0.212 kG, and 0.206 kG,  respectively, for coils 1-4.  However, each measurement had a rather large uncertainty of 0.01 kG, because the field strength varied a lot with position on the magnet, and the measurements were limited by how well we could align the probe tip with the center.

Fixed Plate Magnets - magnetic field (kG)           
meas't    1        2        3        4
1       0.205    0.213    0.209    0.204
2       0.211    0.219    0.223    0.207
3       0.199    0.205    0.211    0.201
4       0.207    0.203    0.206    0.213
average 0.206    0.210    0.212    0.206
stdev   0.005    0.007    0.007    0.005

    We also planned to take the same measurements for the coil magnets.  We noted that the magnetic field varied a lot depending on the probe's location, but not in the way we would expect.  At the edges of the magnet, the field was much stronger (~2 kG) than at the center (~0.5 kG).  We initially thought this might have to do with how we were holding the probe -- for instance, if we measured the force towards the edge by moving the tip all the way across the center of the magnet, there might be some kind of integration effect which does not accurately represent the field.   However, we measured the field at the edge with the probe across the magnet and also with the probe, so this is clearly not the case.

    We also noticed that the cylindrical magnet we used for single-magnet levitation was not attracted to the coil magnets in the way we expected.    Though the cylindrical magnet was oriented so that it was strongly attracted to the coil magnet, it was attracted more to the edges than the center, so that it seemed to be repelled by the centers of the coil magnets.  Though this follows somewhat from the Gaussmeter readings, it is not the behavior we would expect when considering the coil magnets as magnetic dipoles.

Attempting single-magnet levitation for each coil:
    We attempted to levitate single magnets using all four OSEM/coil combinations.   We assembled the magnets and OSEMs using Haixing's mount, and, adjusting the height of the OSEM plate, attempted to levitate the single magnet with a flag with which we were previously successful.   This was completely unsuccessful using all of the coil magnets (and when we tried to levitate using the south magnets, we flipped the cylindrical magnet's orientation).
    Since we had already achieved this levitation, this seemed particularly wrong.  We disassembled the fixed OSEM plate in Haixing's mount and built a cursory OSEM mount, similar to the one we had used for levitation before, and did not fix it in place.  After a little experimenting with the height and position of the OSEM, we were able to achieve levitation with coils 1 and 4.
    We noted the levitation magnet separation (~4.5 mm) and the height of the OSEMs at which levitation was achieved (147 +/- 1 mm for coil 1, 146 +/- 1 mm for coil 4).  Then, we reassembled Haixing's OSEM plate and tried to levitate the cylindrical magnet at coil 1 and coil 4, respectively, adjusting the OSEM plate so that the height of the OSEM of interest was the same as when we achieved single-magnet levitation.  This was unsuccessful, which leads us to believe that there is some alignment issue between the fixed coil magnets and the OSEMs in the mount,  possibly due to the unusual field from the fixed coil magnets.
    We also were completely unable to levitate using coils 2 and 3.  Coils 1 and 4 have identical circuit paths, whereas 2 and 3 differ slightly.  With more time, we need to investigate this further.

Force-distance measurements
    We also measured the repulsive force between the cylindrical magnet and the coil magnets as a function of separation.  We fixed each of the coil magnets, individually, on a stack of sticky notes on a precision balance (the stack of sticky notes was to prevent the coil magnet from interacting with the digital balance) and zeroed the balance.  We then fixed the cylindrical magnet (oriented so that it would be repelled by the coil magnet) to a teflon rod, and mounted the rod so that we could slide it up and down a long cylindrical post.  Noting the position of the rod and cylindrical magnet, we were able to measure the repulsive force as a function of separation (see Excel graph).
    However, because the magnetic field varied so much with position on the coil magnet, there is a lot of uncertainty associated with these measurements.    We tried to keep the cylindrical magnet in the same horizontal position, but it was impossible to keep the exact position while sliding the mounted teflon rod up and down the posts.    In spite of this, we fit the linear region of this graph, near the equilibrium separation of the magnets, for a very approximate measurement of the magnetic field force gradient. The slope gives the force per unit distance of the magnet.

Coil-force measurement
    We measured the force by changing the current through the coil of wire, using a very similar setup as described above.  Since we are concerned with the magnetic force as a function of current, not separation, we fixed the teflon rod so that the cylindrical magnet and coil magnet were separated by ~4.5 mm, the approximate levitation separation of the two magnets.   We then completely blocked the OSEM with the flag, creating a maximum PD current, and measured the coil current using an oscilloscope when the LED was fully blocked and the current when we removed the flag.  At the same time, we measured the repulsive force by looking at the precision balance.
    Unfortunately, we had difficulty taking further readings, because our circuit starting behaving oddly (described below).  Otherwise, we would repeat this process by blocking the OSEM LED by various amount and measuring the change in coil current, and the corresponding reading on the precision balance.   However, the force should be linearly dependent on coil current, and we ought to know one other point: when there is no current in the coil, there should be no magnetic force from the coil to the magnet.  Using this information, we can determine the slope of magnetic force by coil current, but it's not very reliable as we have only one real data point.
    One additional aspect makes this reading questionable.  When we switched on the power supply, the reading on the precision balance changed, before we had blocked the OSEM LED at all. Since no light was blocked, theoretically no photocurrent should be coming from the PD and there should not be a coil current from the feedback, so the force should not be changing. We are not sure why this is.

Recent Circuit Behavior
    Some noise in the circuit appears to be hugely amplified when the gains of each coil are high, resulting in a high frequency signal of a few hundred kHz.  When the gains are all sufficiently high, this noise can saturate the coil current so that when PD current changes, there is no visible change in coil current.
    On Saturday, we noticed some odd behavior from the circuit.  We hooked up the oscilloscope so we could see both PD current and coil current, and were very surprised that the PD current signal was oscillating and continually changing even when no flag was inside the OSEM.   This was also affecting the coil current as well.  We thought this might be due to some component burning out in our circuit, or RC coupling somewhere, but we did not get a chance to pinpoint the origin of this problem.

Modeling
Initially we had attempted to model the force-distance treating the two cylindrical magnets as dipoles, and finding the attraction/repulsions between the four distinct poles.  However, the resulting equation did not have a maximum, which is what we got in our measured values, so it seems this is not the best approach.  We would like to try the current loop approximation.

Attachment 1: repulsiveforce.png
repulsiveforce.png
Attachment 2: OSEMcalibration.png
OSEMcalibration.png
Attachment 3: OSEMslopes.png
OSEMslopes.png
  3430   Tue Aug 17 14:09:15 2010 steveUpdatePEMPSL optical table schedule

Tuesday, 17 August : fill tunnel, set table height, level table and balance load

Wednesday : grout tripod legs and leave it alone

Thursday : built  guide-form for concrete

Friday :  pour concrete

Monday, 23 August : remove guide forms and clean up

  3429   Tue Aug 17 09:06:08 2010 AlbertoUpdateelogelog was down

I just restarted the elog after I found it down a few minutes ago.

  3428   Tue Aug 17 02:07:11 2010 YoichiUpdateCDSDACs have correct number of channels

Quote:

- DACs 

  None of them are working although the computer can recognize that all three DAC cards are mounted.

  I think something in the IOP file and the model file may be wrong because this symptom looks similar to that of C1ISCEX we tested two weeks before ( see this entry ) 

  I have to fix it anyhow because the DACs are very necessary part for this damping test.

 Since we had a similar trouble with the DAC at CLIO, I checked if this problem comes from the same origin.

The origin of the problem we had was that although the board was sold as 16 channel DAC, the firmware was set to use only 8ch.

To see if this problem exist in the DAC boards of c1sus, I added the following code to the /cvs/cds/caltech/cds/advLigoRTS/src/fe/map.c

printk("DAC ASSC = 0x%x\n",dacPtr[devNum]->ASSC);

in the definition of mapDac() function.

This code prints the information of the ASSC (Assembly Configuration) register of the PMC66-16AO16 board as a kernel message at the start up time of the realtime code. You can check the message with dmesg command.

After the modification, I recompiled the c1sus and installed it.

make c1sus; make install-c1sus

After starting c1sus, I checked the dmesg. Then found that the ASSC register was set to 0x130006. To decipher this magic number, you have to consult with the manual of the DAC, which is available online.

http://www.generalstandards.com/view-products.php?product=pmc66-16ao16

The manual says the 17th and 18th bits of this number set the number of channels. Those bits are 11 for 0x130006. According to the manual, 11 means 16 channels are present. So it seems that the ASSC register is correctly set. In the case of CLIO, the ASSC register was 0x110003, meaning only 8 channels are present.

Unfortunately, the ASSC register was not the cause of the problem, but at least this possibility was checked.

  3427   Mon Aug 16 23:39:29 2010 YoichiUpdateSUSMore TT characterization

Quote:

Things we noticed:  Koji and I had been concerned the last time we were looking at TT#2 because the frequency got lower and the Q seemed to get higher when we added the damping to the vertical blades.  Yoichi and I did not find that to be true today.  We did notice, however, that the EQ stop screws with the viton had been placed in the holes closer to the clamping point, whereas with TT #4 the screws had been placed in the holes farther from the clamping point.  We moved the screws on TT #2 to the outer holes, and noticed that the frequency increased slightly, and the Q significantly decreased.  We then followed this outer-hole philosophy when installing screws in TT #3.

The inner and outer screw holes of the EQ stop Jenne is talking about are shown in the photo below.

EQStopScrewHoles.jpg

  3426   Mon Aug 16 23:13:25 2010 ZachUpdateeloge to the log

 Zach

  • I get so many freebies it's ridiculous
  3425   Mon Aug 16 19:12:18 2010 JenneUpdateSUSMore TT characterization

[Jenne, Yoichi]

We characterized Tip Tilts numbers 2 & 3 today.  Recall #4 is the one which Koji and I measured some time ago, and #s 1 & 5 have yet to be suspended (that's on the to-do list for tomorrow).

When we began looking at #3 (the one which had been in the BS chamber for a few days, but was removed for characterization) we found that the pitch pointing was way off.  The beam was way too low after reflection.  So we adjusted that (and got it right on the first try....a miracle!).  This does however make me pretty concerned about our in-chamber pointing.  Are we destroying our pointing during travel between the cleanroom and the chambers?  Is there anything we can do about it? Pointing doesn't seem to be lost when we move them around on the tables in the cleanroom, ie we can pick up a TT, move it, leave it for a while, move it back to the oplev, and the pointing still seems okay.  But the TT which was sent to the chambers came back with bad pointing. I'm sure this is related to the hysteresis we see in the pointing if we poke the top of the mirror holder versus the bottom when exciting pitch motion.

For both #2 and #3, we measured the frequency and Q of Pitch, Yaw, Pos, Side, Vert motion.  For the Vert motion, we measured both without and with EQ stops as dampers.  For the other modes, all were measured with the ECD backplane in place.  Pitch and Yaw were measured with reflection off of the mirror surface onto the PD, while Pos, Side and Vert were measured using the wire clamp on the mirror holder to obscure the beam as a shadow sensor.

TT #2

Pitch: Overdamped, no freq measured, Q < 1/2

Yaw: freq ~1.8Hz, Q between 2-7

Pos: freq ~1.75Hz, Q too low to measure, but above critically damped

Side: freq ~ 1.8Hz, Q~5

Vert no dampers: freq ~20Hz, Q~36

Vert with dampers on outer screws: freq~24Hz, Q~8,

TT #3

Pitch: no freq measured.  Q~1/2?  Upon being excited in Pitch, the beam started down way below the photodiode, came up a little past its DC place, and went back down a tiny bit.  So not quite overdamped.

Yaw: freq ~1.96Hz, Q very low

Pos: freq ~1.72Hz, Q~3

Side: freq ~1.85Hz, Q~6

Vert no dampers: freq ~20Hz, Q~75

Vert with dampers on outer screws: freq ~20Hz, Q~34  (Frequency stayed constant....we did several measurements both with and without the dampers...but the half life time changed significantly)

 

Things we noticed:  Koji and I had been concerned the last time we were looking at TT#2 because the frequency got lower and the Q seemed to get higher when we added the damping to the vertical blades.  Yoichi and I did not find that to be true today.  We did notice, however, that the EQ stop screws with the viton had been placed in the holes closer to the clamping point, whereas with TT #4 the screws had been placed in the holes farther from the clamping point.  We moved the screws on TT #2 to the outer holes, and noticed that the frequency increased slightly, and the Q significantly decreased.  We then followed this outer-hole philosophy when installing screws in TT #3.

To Do List: We need to suspend the ECDs and the Optics for the remaining two Tip Tilts, and to characterize them.  We also (probably farther-future) need to take transfer functions using a shaker / shake table with our spare Tip Tilt.  After all the TTs are suspended and have their modes measured, we will be ready for installation into the chamber during the next vent.

 

  3424   Mon Aug 16 13:33:06 2010 ZachFrogsPhotosHere's the 40m team

 One day I'll get to be part of the krew

  3423   Fri Aug 13 20:58:20 2010 JennaSummaryElectronicsRubidium clock phase noise measurement

 Here's an overview of the rubidium measurement:

rubidium_diagram.png

HPIM3871.JPG

 

HPIM3880.JPG

 We have two SRS FS275 Rubidium clocks which are locked together using the built-in PLL through the 1pps input/output. The default time constant for this locking is 18.2 hours because it's designed to be locked to a GPS. We changed this time constant to .57 hours (as decribed in this elog entry) to get the clocks to more reliably lock to each other. We then mix the 10MHz outputs together using a 7dbm mixer (see elog here and picture below)

HPIM3872.JPG

 

The signal then goes through an AC-coupled SR560 with a gain of 100 and LPF at 10kHz, and is then fed into the DAQ. In the first picture below you can make out what all the lights are labeled, and in the second you can see what lights are on. I couldn't get a picture that did both in one, sadly.

HPIM3878.JPG

HPIM3876.JPG

  3422   Fri Aug 13 18:32:48 2010 steveUpdatePEM new legs attached to optical table

Koji, Rana and Steve

 

The floor preparation continued today. The really messy part of drilling and jack-hammering the concrete were done in controlled manner.

Particle counts peaked at 106K of 0.3 micron and 13 K of 1.0 micron particles/ cfmin at the top of SP table.

Legs were installed with the help of Koji and strongman Rana. Professor Rana was very useful lifting the 85 lbs legs. 

 

Atm1, Drilling holes for ribbed bar reinforcement of concrete

Atm2, Koji and Rana are playing hide and seek while installing legs

Atm3-4, 6 Rigid tripod legs attached by 6x3 of 1/4-20x 7/8 screws. The top plates of the legs were torqued to 108 ft/lbs by Rana

Attachment 1: P1060612.JPG
P1060612.JPG
Attachment 2: P1060626.JPG
P1060626.JPG
Attachment 3: P1060631.JPG
P1060631.JPG
Attachment 4: P1060636.JPG
P1060636.JPG
  3421   Fri Aug 13 15:29:35 2010 AidanFrogsPhotosHere's the 40m team
Attachment 1: 40m_team.JPG
40m_team.JPG
  3420   Fri Aug 13 13:11:30 2010 DmassUpdateelogrestarted

Quote:

Quote:

 script

 More of the same. 

Who is putting weird figures into the elog?!?!  I haven't checked lately, but this is what usually crashes the elog.  It's been happening a lot lately, and it might be the .pdf's. 

Let's play a new game.  We'll call this game "Everyone only use .png files for the next week" Ready? GO!

Do we know what causes the crashes for definite? Let's give the whole knowledge gathering a shot. Surfs welcome to post. Please follow the format and keep it brief. P.S. if the elog stops responding or hangs while you're trying to edit a post or write a post, you may have crashed it.

Person

  • Crashes

Dmass

  • I have crashed the elog with downsized jpegs (~300-900kB).
  • I see jpegs on the front page of the 40m (which seem to have not crashed it?)
  • I have posted pdf's with and without png thumbnails (associated automatically via the Mac program preview) without problem.

 

Edit this post to add your own experience using the above format

  3419   Fri Aug 13 09:41:00 2010 nancyOmnistructureComputersCharger for dell laptop

 I have taken the charger for the dark gray dell laptop from its station, and have labelled the information there too.

Will keep it back tonight.

  3418   Fri Aug 13 01:53:12 2010 GopalUpdateOptic StacksGravity Implementation Confirmed

Time Domain Analysis on a Driven, Damped Simple Pendulum has produced a method for implementing gravity.

COMSOL made this simple task a cryptic one: the following methods had previously failed:

  • Previous Frequency Domain testing lead to unwanted oscillations of all loads.
  • Prescribed accelerations at first seemed to create a constant gravity, but instead incorrectly constrained net acceleration to the inputted amount

Methodology:

1) An (approximately) impulse displacement was applied in the horizontal direction. The pendulum bob's displacement was observed for varying pendulum lengths.

2) The drive and response displacements vs. time were FFT'd to produce transfer functions.

3) The fundamental frequencies were inverted, squared, and plotted against frequency.

4) Since the graph is linear with an R^2 of over 0.99, it is reasonable to assume that gravity is properly acting as a restoration force.

Pendulum_Length.png

Attachment 1: Pendulum_Length.png
Pendulum_Length.png
Attachment 2: Pendulum_Length.png
Pendulum_Length.png
  3417   Thu Aug 12 23:49:04 2010 nancyUpdateEnvironmentLaser chiller temp raised

Since the laser is off, Jenne and I rasied the chiller-chiller (small AC in the Control Room) set point temperature to 73 degree F (from 68F) to save people from shivering.

  3416   Thu Aug 12 23:41:48 2010 JenneUpdateelogrestarted

Quote:

 script

 More of the same. 

Who is putting weird figures into the elog?!?!  I haven't checked lately, but this is what usually crashes the elog.  It's been happening a lot lately, and it might be the .pdf's. 

Let's play a new game.  We'll call this game "Everyone only use .png files for the next week" Ready? GO!

  3415   Thu Aug 12 23:17:54 2010 ZachUpdateelogrestarted

 script

  3414   Thu Aug 12 18:30:08 2010 kiwamuUpdateCDSRe: current status

Yes.  

The medm screen C1SUS_GDS_TP.adl showed some numbers which correspond to that I wrote  on the outputs.

But I still could not get any physical voltage coming from the DACs.

Quote:

 When you write outputs on DAC_0 or DAC_1 is the C1SUS GDS TP screen showing anything? 

  3413   Thu Aug 12 17:28:28 2010 RazibUpdatePhase CameraSideband power measurement (updated)

Quote:

This sounds very relieving although this could be a lower bound of the number.
Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.

Quote:

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. 

 

 The SCR was at first measured using the output of the PD. That was exactly from where we got our 0.09 (previous elog entry). The second measurement was from the CCD.

  3412   Thu Aug 12 17:10:07 2010 KojiUpdatePhase CameraSideband power measurement (updated)

This sounds very relieving although this could be a lower bound of the number.
Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.

Ed: I meant time series of the PD output

Quote:

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. 

 

  3411   Thu Aug 12 16:52:02 2010 RazibUpdatePhase CameraSideband power measurement (updated)

I made some measurement of the SCR (signal to contrast ratio) from the signal from the EOM and the AOM.

The recipe for that was:

1. Trigger the camera at 20 Hz (from function generator).

2. Take a series of 20 images.

3. Do FFT to take out the DC component.

4. Extract the beat signal out of the FFT'd data.

5. Block the EOM.

6. Take another set of images of the AOM beam.

7. Take more(!) images, but this time of the background (blocking both EOM and AOM).

 

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry.

The plot for that is:

SCR.jpg

 After measuring the SCR, I also measured the amplitude of the sideband and made an amplitude profile of the 40 MHz sideband.

The amplitude measurement is done as follows:

We know that the our 5 Hz signal consists of,

Sig = A_r * A_sb    where A_r = amplitude of the reference beam, A_sb= amplitude of the sideband

So, A_sb = Sig / A_r .

But,  A_r = sqrt ( P_AOM - Background),

Thus  A_sb = Sig / sqrt( P_AOM - Background) .

So the amplitude profile is done by taking the 5 Hz beat signal and dividing by the square root of the AOM beam minus the background light.

The plots looks like this:

DC_sig_sideband_profile.jpg

The solo sideband profile looks like this:

sideband_profile.jpg

Next we plan to trigger the camera with a 1 KHz signal and take snaps at n* T/4 (where n=0,1,2,3) of the period of the beat signal. So the plan is to trigger the camera at the point where the red dots appear in following cartoon.

sine_trig.jpg

Some more details of this setup will be posted later.

  

Quote:
 

 

Attachment 4: sine_trig.jpg
sine_trig.jpg
  3410   Thu Aug 12 16:18:46 2010 steveUpdateEnvironmenttiles and adhesive removed

Quote:

I powered down 1Y1 and 1Y2 instrument racks of MC and RF-systems this morning.

Both racks, SP table, clean tools-parts boxes and MC2 area are also covered with plastics.

Bertin Bros. Construction, Inc is working on the floor preparation. Their head man is Robby Bertin, cell 626. 831.2264

Today's job:

remove tiles, clean off tile glue, drill for ribbed  steel bars, rough clean- surface for good bounding. paint floor with bounding agent

Tiles and adhesive removed. There were no dust storms created. Solvent paint- removal made the hole IFO -lab smell like the paint shop.

The south door is open with a fan blowing air inside. The north-west door is open through control room to outside to let air rinse the drying

paint-removal. Koji is  taking lunch break while test riding our new PSL table legs.

Attachment 1: P1060604.JPG
P1060604.JPG
Attachment 2: P1060606.JPG
P1060606.JPG
Attachment 3: P1060603.JPG
P1060603.JPG
Attachment 4: P1060610.JPG
P1060610.JPG
Attachment 5: DSC_2388.JPG
DSC_2388.JPG
  3409   Thu Aug 12 16:18:00 2010 JennaUpdateElectronicsRb clocks overnight

I took a look at the data from the middle of the night to see if it was significantly quieter than the data from the day, but it doesn't seem to be. The plot shows data from yesterday around 12:30pm and from this morning around 2am. It's a bit quieter at low frequencies, but not by much.

Attachment 1: rbcomp.pdf
rbcomp.pdf
  3408   Thu Aug 12 14:01:53 2010 josephbUpdateCDScurrent status

First, awesome progress.

Second, the Binary Output parts do in fact need to be added to the c1sus model.  They don't need to appear in the IOP though.  (They are somehow automatically taken care of by the IOP code). 

It looks like in the 2004 revision in SVN, the cdsCDO32 part (located in the CDS_PARTS.mdl/IO_PARTS) was broken.  I fixed it and updated the svn with it, so a svn update should pull the corrected version.

I'm not sure whats wrong with the DAQs.  I'll try to take a closer look at the model file tonight and see if I can make suggestions.  When you write outputs on DAC_0 or DAC_1 is the C1SUS GDS TP screen showing anything?

  3407   Thu Aug 12 11:59:31 2010 kiwamuHowToCDSset up ntp daemom

(sad story)

When I was working on a new front end machine c1sus, I found that make command didn't run and gave the following message.

      "make:warning:clock skew detected.Your build may be incomplete"

This was caused by a clock difference between the nfs (nodus) and the terminal machine (c1sus).

I had to set up ntp daemon to synchronize them. Here is a procedure to set up it

 


(how to)

- log in to a front end machine

              ssh c1sus

- enable the ntp daemon

              sudo ntsysv

- configure the ntpd

              vi (emacs)  /etc/ntp.conf

- below is the contents I wrote on ntp.conf

             server 192.168.113.200  minpoll 4 maxpoll 4 iburst

      driftfile /var/lib/ntp/drift

 - let the daemon run
            sudo service ntpd start
- check it if it's running
             ntpq -p
  3406   Thu Aug 12 11:39:27 2010 ZachUpdateelogelog restarted

with script

  3405   Thu Aug 12 11:19:04 2010 kiwamuUpdateCDScurrent status

Current status of the new CDS test (summaries can be found on the wiki)

- Cables 

  All the necessary cables are in our hands, such as SCSIs, 37 pin D-sub and 3 pin power cables.

  With a big help from Jenne and Koji, we made 37 pin F/M cables and 3 pin power cables on the last Tuesday.

  Now all the cables are connected to the machines except for the 3 pin power cables.

  To install the power cables I will switch off Sorensens at new 1X5  for a minute.

 

- Suspension model file 

  The model file named C1SUS was made and I succeeded in compiling and building it. So it is ready for the test.

  But some medm screens look like not correctly complied.

  For example the channel names which are listed on C1SUS_MONITOR_ADC0.adl aren't correctly assigned.

 

- ADCs 

 All the ADC channels are working. Also the channel assignments are correct.

 I checked all the ADC channels if it was working while I ran the front end realtime code C1SUS.

 By injecting a signal from a function generator directly to the SCSIs, I could clearly see the numbers hopping on medm screens.

 

- DACs 

  None of them are working although the computer can recognize that all three DAC cards are mounted.

  I think something in the IOP file and the model file may be wrong because this symptom looks similar to that of C1ISCEX we tested two weeks before ( see this entry ) 

  I have to fix it anyhow because the DACs are very necessary part for this damping test.

 

- Binary Outputs

  They didn't work at all. Even the computer didn't recognize the binary output cards.

  I think I should put some magical components on the model files.

 

- Conversion of the filter coefficients 

  The conversion of the filter coefficients has been doen yesterday.

  It looks running well because I can load and unload these filters on medm screens.

  I manually copied the filter coefficients from the current suspension filter file to that of new filter file.

 The current file can be found under /cvs/cds/caltech/chans/,  and the new one is under /cvs/cds/rtcds/caltech/c1/chans


Suspended works

   - Binary Outputs

   - simlink realtime model with the new CDS PARTS ( see the notice from Joe )

 

To be done

   - let DACs work

   - damping tests

 

  3404   Thu Aug 12 10:56:31 2010 steveUpdateEnvironment dusty floor work in progres

I powered down 1Y1 and 1Y2 instrument racks of MC and RF-systems this morning.

Both racks, SP table, clean tools-parts boxes and MC2 area are also covered with plastics.

Bertin Bros. Construction, Inc is working on the floor preparation. Their head man is Robby Bertin, cell 626. 831.2264

Today's job:

remove tiles, clean off tile glue, drill for ribbed  steel bars, rough clean- surface for good bounding. paint floor with bounding agent

  3403   Wed Aug 11 16:56:00 2010 KojiSummaryEnvironmentCovering of the IFO

Katharine, Sharmila, Gopal, Kiwamu, Jenne, Aidan, Steve, and Koji

A guy from the carpenter shop has done the drilling work in the morning.

In the afternoon we wrapped the central part of the interferometer with plastic sheets in order to avoid the dusts from the tile ripping that will happen tomorrow.

Attachment 1: IMG_2732.jpg
IMG_2732.jpg
  3402   Wed Aug 11 16:38:02 2010 JennaUpdateElectronicsRubidium clock phase noise

Quote:

The units of this plot are rad/rt(Hz). I've no idea why it just says magnitude.

 This is a known thing (at least to me and Rana), so it's not just you.  When you put in some points like your PD Spec, the units disappear, and I've never figured out how to get them back while keeping the points.  Thanks for putting the units in your entry though.  If anyone else does know how to get the units to 'stick' where they're supposed to be, that would be helpful. 

  3401   Wed Aug 11 16:13:59 2010 JennaUpdateelogelog restarted

The elog crashed, so we restarted it again.

  3400   Wed Aug 11 15:27:16 2010 JennaUpdateElectronicsRubidium clock phase noise

We unsynched the clocks by unhooking the 1pps locking. I've added it to the plot of the other measurements here, and we've divided by a factor of sqrt(2) in the calibration to get the phase noise from just one clock, so the calibration is now

pi (rad) /6415 (counts) /100/sqrt(2).

I've also added the noise of the clock according to SRS to the plot.

The units of this plot are rad/rt(Hz). I've no idea why it just says magnitude.

Attachment 1: 08_11_Rb_withspec.pdf
08_11_Rb_withspec.pdf
  3399   Wed Aug 11 13:28:44 2010 josephbUpdateCDSNew cdsIPCx parts, old part breaks models

While working on a test stand at LLO, I've discovered that there's a new update to the Real Time Code Generator that breaks virtually all of our current models.

Previously, we've been using the cdsIPCx part as a flexible link between models, and could be set to RFM (reflected memory), SHMEM (shared memory on the local computer), or PCIE (pci express or dolphin I think) depending on what was written in the IPC file (found in /cvs/cds/caltech/chans/ipc/C1.ipc).

Recently, three new parts were added called cdsIPCx_SHMEM, cdsIPCx_RFM, cdsIPCx_PCIE, and the previous cdsIPCx broken.  The cdsIPCx_***** has to match the type written in the IPC file or else it errors out with a rather unhelpful error message which doesn't tell you which part/line is in conflict...

i.e.

***ERROR: IPCx type mis-match: I vs. ISHM
make: *** [g1lsc] Error 255

In anycase, when using a current checkout (updated or checked out after ~July 30th), all cdsIPCx blocks in the simulink models needs to be changed to the approriate type.  I'm trying to get a new CDS_PARTS.mdl file I updated into the svn, but for now you can just open up the model file directly in the /advLigoRTS/src/epics/simLink/lib directory and copy it in from there (i.e. cdsIPCx_SHMEM.mdl) to your model file.  I'm also trying to get the feCodeGen.pl file changed so the error message actually tells you what channel/part is mismatching so you don't have to guess.

An easy way to modify a file for all shared memory connections without doing a ton of cutting, pasting and renaming is:

sed -i 's/"cdsIPCx"/"cdsIPCx_SHMEM"/g' file_name_here.mdl

  3398   Wed Aug 11 12:58:56 2010 JennaUpdateElectronicsRubidium clock phase noise

I took some measurements of the clock this morning, first without the box, then with the box, then without the box again. All the noise levels look pretty much the same. When I first put the box on, it was only propped up on one side, so I think the clocks got a bit overheated and the data looks ridiculous, which is the first plot. I took it off and let them cool down a bit, and then put the box on, this time with a generous 3 inch gap at the bottom all the way around, and it seemed to be fine after that.

The calibration for the data is pi (rad) /6415 (counts) /100.

Aidan: I edited this post to change the plots from Postscripts to PDFs.

Attachment 1: 08_11_Rb_crazybox.pdf
08_11_Rb_crazybox.pdf
Attachment 2: 08_11_Rb_comparison.pdf
08_11_Rb_comparison.pdf
  3397   Wed Aug 11 11:51:45 2010 Gopal UpdateWIKI-40M Update8.5.10 - 8.11.10 Weekly Update

Summary of this Week's Activities:

Thursday, August 5:

X-Displacement Transfer Function Measurement

JPL Tour

Friday, August 6:

Y-Displacement Transfer Function Measurement

Z-Displacement Transfer Function Measurement

Monday, August 9:

Worked on COMSOL/MatLab Interface --> problems may be due to older version

Discussed with Koji options for calling our COMSOL sales representative

Jan and I decided that there is in fact something wrong with the installations on both my Mac and Kallo

Reinstalled on both machines, but the problem was not solved

Jan said we'd go see Larry tomorrow

Tuesday, August 10:

Attempted to figure out Time-Dependent Modal Analysis --> don't think it's what we need

Began reading the LiveLink for MatLab documentation --> even the directions in this produced issues

Discovered "Prescribed acceleration" option for gravity:

A test with it on the simplest stack eliminated the unwanted oscillation, which I guess is a partial success...

Trying the same thing with Koji on a simple pendulum, however, didn't produce the expected increase in resonant frequency

(Jan was unable to see Larry today, but we're meeting on Wednesday instead).

Wednesday, August 11 (morning):

Some background research on multiple-layer stack theory

Began working on presentations

 

 

 

  3396   Wed Aug 11 02:44:37 2010 ZachUpdateelogelog restarted

You'll never guess what happened: the elog crashed!

I restarted it with the script. Yay.

  3395   Tue Aug 10 22:40:55 2010 KojiSummaryPEMAccelerometer located on and below the PSL table

Result of the accelerometer measurement

Introduction

We wanted to characterize the PSL table before the work before its lifting up.
We put a set of three-axis Wilcoxon accelerometers on the ground and another set on the PSL table through the weekend.

Result

- The data at 9th Aug 00:00(UTC) is used. This was Sunday 5PM in the local time.
- The freq resolution was 0.01Hz. The # of avg was 50.

- The accelerometer signals were calibrated by the value 1.2e-7 V/(m/s^2). We use this absolute value of the spectrum for the comparison purpose.

- The accelerometers were aligned to North(X), East(Y), and Up(Z). There was the coherence observed from 2~20Hz.
  The transfer functions are valid only this frequency region although we still can set the lower bound of them.

- The transfer functions in the horizontal directions show huge peaks at around 20Hz. The Q of the peaks are ~30 to ~100.
  The vertical transfer function shows somewhat lower peak at around 50Hz with Q of ~10.

Some thoughts

- The low resonant freq and the high Q of the horizontal mode comes from the heaviness of the table.

- We are going to raise the table. This will usually mean that we get the lower resonant freq. This is not nice.

- So, the decision to use 6 tripods rather than 4 was right.
- The steel tripods are expected to give both more rigidity and more damping than the chep-looking hollow Newport legs.
- Concrete grouting of the tripods will also lower the effective height and will benefit for us.

 

Attachment 1: PEM_100809.pdf
PEM_100809.pdf
  3394   Tue Aug 10 17:21:48 2010 steveUpdateGeneralPSL optical table is at 30" height

Mike Gerfen, Koji and Steve,

 

Our old ( 6 x 10 x 1 ) ft Newport optical table will have the same height as the neighboring AP table when this job is finished.

Today's work was to elevate the optical table ~ 2400 lbs to 30" clearance to create a workable space below.

 

Atm1,  enclosure frame was raised by 6"

Atm2,  2 pellet jacks and 4x4 technology in the work.

Atm3,  ready for drill and tap with jig plate in place, note 4 Al legs 8" OD. 1/4" wall safely supporting the load

Atm4,  showing clamps that holding 1/2" plywood with jigs

Atm5, We removed the 4 old legs: 6" OD steel, 1/4" wall and 10" high after they were unloaded.

Attachment 1: P1060586.JPG
P1060586.JPG
Attachment 2: P1060583.JPG
P1060583.JPG
Attachment 3: P1060591.JPG
P1060591.JPG
Attachment 4: P1060593.JPG
P1060593.JPG
Attachment 5: P1060597.JPG
P1060597.JPG
  3393   Tue Aug 10 16:55:38 2010 JennaUpdateElectronicsc1iovme restarted

 Alastair and I restarted the c1iovme around the time of my last elog entry (~3:20).

  3392   Tue Aug 10 15:23:35 2010 JennaUpdateElectronicsRubidium clock time constant

[Jenna & Alastair]

We changed the locking time constant on one of the Rubidium clocks using the RbMon software that came with it. We had to use the ancient Dell laptop latitudeD810 because it has a serial port built in, and we couldn't get the usb->serial adapter to work right with the clock. We tried the usb connector on more than one computer, and we had installed the right adapter and the computer seemed to recognize it fine, it just wouldn't communicate with the clock. We even tried it with the Dell latitute laptop and it still failed to work, so the only way seems to be to use the serial port directly.

The clock has a default time constant of 18.2 hours because it's designed to be locked to a GPS clock which is less stable than the Rb clock itself, so we changed it to a time constant of .57 hours. We also changed the length of the BNC cables to get the DC offset to 10mV, but then as I was typing this, we opened up data viewer to look at the real time data and saw the output suddenly leap up, and found that the offset is now -5mV mysteriously, so we went to investigate and found that the gain of the SR560 was still set to 1 from a calibration. We beat one of the clocks with a marconi for a few minutes with the gain still at this level to do another calibration, and then hooked the clocks back up together and upped the gain to 100. The DC offset is currently about 2.5mV. We're going to leave them alone for a few hours, and then check to see what the signal looks like over that period.

  3391   Tue Aug 10 05:56:07 2010 KojiUpdatePSLPSL Table Lifting Preparation

Work on Aug 9th

Steve, Jenne, Koji, Alberto, Aidan, Jan, Sharmila, Katherine

From 9am to 6pm

  • Shutting down the PSL after the 90885 hours of service
  • Removals
    • The accelerometers
    • The reference cavity chamber
    • The periscopes were left so far
  • The cables between the PSL table and the outside have been disconnected
    • Listed items on Friday
    • Some unlisted items recorded and disconnected
    • Drained the cooling water from the chiller lines
    • Pulled out the chiller connections at the control room as well as the chiller control cables (temp sens & RS232C)
  • Sealed the PSL table with plastic sheets
    • Put antistatic films to the table (they are supported by the long optical poles)
    • Used capton tapes to fix the films on to the table
    • Put the white huge plastic sheet to cover the table at once
    • Some spaces at the edge of the tables are left flat such that the C-clamps can be attached
  • Sealed the AP and the ITMY tables by capton tapes

Some photos are attached in this entry. All of the photos found in the picasa album (click the slideshow)

Attachment 1: IMG_2686.jpg
IMG_2686.jpg
Attachment 2: IMG_2691.jpg
IMG_2691.jpg
Attachment 3: IMG_2692.jpg
IMG_2692.jpg
Attachment 4: IMG_2711.jpg
IMG_2711.jpg
  3390   Tue Aug 10 01:05:17 2010 ZachUpdateelogelog restarted

 Elog was down. Restarted with the script.

  3389   Mon Aug 9 21:50:50 2010 nancyUpdateIOOMode Cleaner ASC

Quote:

The WFS and QPD servos were working. That was great.
Everything was fine except for the time series plots.

I could not get what story you are telling with the time series.
(e.g. your's are good or bad or anything)

 Well, the data is kind of not enough to be analysed in time domain,

But by far from what I analyse, I think that the new control is not worse than the old one.

I donot also find any better results, except for this one being theoritically stronger.

  3388   Mon Aug 9 15:54:43 2010 KojiUpdateIOOMode Cleaner ASC

The WFS and QPD servos were working. That was great.
Everything was fine except for the time series plots.

I could not get what story you are telling with the time series.
(e.g. your's are good or bad or anything)

  3387   Mon Aug 9 13:32:02 2010 nancyUpdateIOOMode Cleaner ASC

 E-log entry for Friday - will attach more plots to this entry on wednesday after i am back   to the 40.

 
Started working at some 1030 hrs and recording the Open Loop Tfs for all 6 loops.
The control was not so good, and I lost the lock quite a number of times while measureing
WFS  did not converge when the spot was aligned to the center. But there was convergence to a non-center point. So if  the control system was switched on near those points, it was converging to that point.
 
Autolocker : switches WFS control on directly, whereas the best way is to gradually increase the gain to 1. Also, the autolocker code now needs to be changed to incoporate the switing off the MC2 oplev in down and switch it on in the up script.
 
After Koji locked the Reference Cavity in the evening, I resumed measurements for the Open Loop TFs.
 
Measurement of the Open Loop Transfer Functions :
 
 
noise waveform was generated using arbitrary wf generator and injected into each loop.
An LPF was applied to have max co-relation at minimum disturabnce. (thanks to Rana)
The Transfer functions, Co-relations and Power Spectra were then measured using the DTT.
 
 
Power Spectrum of the IN1, IN2 and EXC shows clearly the suppression of the noise, and OLTF shows the phase margins.
 
- Courtesy Rana again for suggesting the idea of plotting power spectra of all signals in the same graph.
 
Later in the night , Koji worked with me and we reflected upon all TFs and changed gains whereevr required according to the phase margin considerations from the Open Loop TFs.
We used the same output matrix given in the previous e-log.   
 
 
Final gains -
 
Alignment Gain in the WFS Master - 1.000
 
Loop Gain
WFS1 P 0.27
WFS1 Y 0.7
WFS2 P 0.15
WFS2 Y 0.110
MC 2OPLEV P -0.1
MC2 OPLEV Y -0.1
 
 
this measurement invloved locking the MC to the correct position, with the spot centered at both the WFS and the QPD. invloved some cheating (offsets) after we tried centering w/o offsets.
demod signal was also centered while alignment.
credits to Koji for getting the correct lock position and also staying with me till late night in the lab
 
Important Points to be noted
 
1. All loops' histories have to be cleared while swtiching them on.
2. turn the loop output before the loop input so that there is no remnant history in the loop.
2. Alignment gain was gradually increased to 1. and tehn the oplevs turned on.
 
 
Later measured teh PSD of  6 error signals under 3 conditions -
 
New Control ON
 
New Control OFF
 
Old Control ON
 
 
Also measured the time series for the MC_trans and MC_refl for the 3 conditions.
 
 
 Status MC_Trans  MC_REF 

  

New Control ON  trans_on.pdf refl_on.pdf   
New Control OFF trans_off.pdf  refl_off.pdf  
Old Control ON trans_old.pdf refl_old.pdf  
 
 
 
 
 
 
 
  

 

Attachment 5: refl_off.pdf
refl_off.pdf
  3386   Mon Aug 9 12:46:24 2010 NancyUpdateIOOMode Cleaner WFS


 Yesterday , I put in the Output Matrix, and changed the gain sliders for the 4 WFS loops.

From how much to how much have you chnged the gain?

I changed the gains from all 4 0.01 to o.27, 0.23, 0.32 and 0.11 and the main alignment gain to be 0.8

 

 

Next we stepped to putting in the gains for the MC2 oplev servo.

I like to put the credit to Aidan for teaching Nancy how to use FOTON.

 Yes, I am sorry for not mentioning this.

Thanks Aidan

 

 

ELOG V3.1.3-