40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 236 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  2095   Thu Oct 15 02:38:10 2009 rana, robUpdateOMCDark Port Mode Scan using the OMC

Bottom trace is proportional to the OMC PZT voltage - top trace is the transmitted light through the OMC. Interferometer is locked (DARM- RF) with arm powers = 80 / 100. The peaks marked by the cursors are the +(- ?) 166 MHz sidebands.

Attachment 1: OMC-ModeScan_091015.png
OMC-ModeScan_091015.png
  8849   Mon Jul 15 16:44:46 2013 AlexUpdateOMCOMC North Safety

 [Eric Alex]

We are planning on testing our laser module soon, so we have added aluminum foil and a safety announcement to the door of OMC North. The safety announcement is as pictured in the attachment.

Attachment 1: photo_2_(1).JPG
photo_2_(1).JPG
  14022   Tue Jun 26 20:59:36 2018 aaronUpdateOMCprep for vent in a couple weeks

I checked out the elog from the vent in October 2016 when the OMC was removed from the path. In the vent in a couple weeks, we'd like to get the beam going through the OMC again. I wasn't really there for this last vent and don't have a great sense for how things go at the 40m, but this is how I think the procedure for this work should approximately go. The main points are that we'll need to slightly translate and rotate OM5, rotate OM6, replace one mirror that was removed last time, and add some beam dumps. Please let me know what I've got wrong or am missing.

[side note, I want to make some markup on the optics layouts that I see as pdfs elsewhere in the log and wiki, but haven't done it and didn't much want to dig around random drawing software, if there's a canonical way this is done please let me know.]

Steps to return the OMC to the IFO output:

  1. Complete non-Steve portions of the pre-vent checklist (https://wiki-40m.ligo.caltech.edu/vent/checklist)
  2. Steve needs to complete his portions of the checklist (as in https://nodus.ligo.caltech.edu:8081/40m/12557)
  3. Need to lock some things before making changes I think—but I’m not really sure about these, just going from what I can glean from the elogs around the last vent
    1. Lock the IMC at low power
    2. Align the arms to green
    3. Lock the arms
    4. Center op lev spots on QPDs
    5. Is there a separate checklist for these things? Seems this locking process happens every time there is a realignment or we start any work, which makes sense, so I expect it is standardized.
  4. Turn/add optics in the reverse order that Gautam did
    1. Check table leveling first?
    2. Rotate OM5 to send the beam to the partially transmissive mirror that goes to the OMC; currently OM5 is sent directly to OM6. OM5 also likely needs to be translated forward slightly; Gautam tried to maintain 45 deg AOI on OM5/6.
    3. A razor beam dump was also removed, which should be replaced (see attachment 1 on https://nodus.ligo.caltech.edu:8081/40m/12568)
    4. May need to rotate OM6 to extract AS beam again, since it was rotated last time
    5. Replace the mirror just prior to the window on the AP table, mentioned here in attachment 3: https://nodus.ligo.caltech.edu:8081/40m/12566
      1. There is currently a rectangular weight on the table where the mirror was, for leveling
  5. Since Gautam had initially made this change to avoid some backscattered beams and get a little extra power, we may need to add some beam dumps to kill ghosts
    1. This is also mentioned in 12566 linked above, the dumps are for back-reflection off the windows of the OMC
  6. Center beam in new path
  7. Check OMC table leveling
  8. AS beam should be round on the camera, with no evidence of clipping on any optics in the path (especially check downstream of any changes)
  14051   Wed Jul 11 15:57:00 2018 aaronUpdateOMCReviving OMC electronics
Gautam showed me the electronics racks for the OMC PZTs and DAQ. I'm in the process of chasing down what channels we need, and confirming that we'll be able to plug the old antialiasing/imaging boards into the current DAC/ADC boards. I found what I think was Rob Ward's simlink model for the omc, located at
 
/cvs/cds/caltech/cds/rward-advLigo/src/epics/simLink/omc.mdl
 
Channels in this model:
  • 27 or 29 total ADC channels are used (depending whether we keep 2 spare adc chans)
    • 4 each go to ASC_QPD1/2 (8 chans total)
    • 5 go to TRANS_PD1, TRANS_PD2, REFL_PD, TRANS_PD1_UF, TRANS_PD2_UF. These PD are used for ASC and LSC.
    • 2 go to the LSC, one each for DVMDC, DVMAC, X3DC, and X4DC
    • 12 go to the ASC_PZT
    • 2 go to the SPARE_ADC (not sure what this is)
    • I think these channels are (or were at some point) defined in memory by /cvs/cds/caltech/chans/ipc/G1.ipc
      • I found this from elog 2860; it mentions that these should eventually be migrated over to a file C1.ipc, but I don't see any OMC channels in that file or any of the 'old' C1.ipc files, so I suppose it never happened or they were removed later
    • During this vent, we won't have ASC, so
  • 10 or 14 DAC channels are used (depending whether we keep 4 spare dac chans)
    • 2 from the LSC, one for CLK_OUT and one for "LSC"
    • 8 from ASC, including P1A, P1B, P2A, P2B, P1OSC, Y1OSC, P2OSC, Y2OSC
    • I think these channels are (or were at some point) saved to frames due to /cvs/cds/caltech/chans/daq/C1OMC.ini, which I found from elog 2073
    • At some point, the 33MHz mod depth was controlled by one of the spare OMC chans, C1:OMC-SPARE_DAC_CH_15. See elog 2126. I assume this is no longer the case, since c1omc is defunct.
    • Durnig this vent, we won't have ASC and don't need to CLK_OUT the LSC, so we may just need one DAC channel

As of at least Nov 2009, the .par file for the OMC was located at /cvs/cds/gds/param/tpchn_C2 (see elog 2316)

 
Electronics inventory:
  • Kepco HV supply, "OMC-L-PZT", labels indicate it goes to 250V, needs to be tested  ("TESTED OK 2014OCT12")
  • Tip/Tilt Piezo Driver, LIGO D060287
  • HV Piezo Driver, LIGO D060283
  • QPD Whitening Board, D060214
  • LIGO D050374/D050387
  • LIGO D050368/D050373

Need to check:

  • Can the ADC/DAC adapter boards (eg D0902006) drive whatever ~10V control signal we need across ~10m of SCSI cable?
  •  
  14052   Wed Jul 11 16:23:21 2018 aaronUpdateOMCCoordination of the Output Mode-cleaner Mirror Insertion Expedition (COMMIE)

I started this document on my own with notes as I was tracing the beam path through the output optics, as well as some notes as I started digging through the elogs. Let's just put it here instead....

  1. Beam from AS port into OMMT
  2. Reflect off OM5-PJ
    1. TO DO: check that the PZT works
    2. 40/P/F/L, 1525-45-P
  3. Pick off from OMPO
    1. TO DO: determine how much power is needed for the pick off, choose an appropriate optic (for this vent probably 50-50 is fine)
    2. The PO beam goes to OM6
  4. Reflect off MMT1???
    1. TO DO: determine if this mirror has a PZT, get it working
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
    2. TO DO: determine the real name of this optic, find its recent history in the elog
    3. TO DO: determine the correct telescope parameters to optimally couple into the mode cleaner given the following:
    4. TO DO: look up how the radius of curvature (RC) of the OMC has changed, and therefore what telescope parameters are necessary
  5. Focused by MMT2???
    1. TO DO: determine if this mirror has a PZT
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
    2. TO DO: determine the real name of this optic, find its recent history in the elog
    3. TO DO: what about this optic is tunable? It looks bulky
  6. Columnated by MMT3???
    1. TO DO: determine if this mirror has a PZT
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
  7. Steered by MMT4???
    1. TO DO: determine the real name of this optic
    2. TO DO: why is this optic so small? Looks different from the rest, maybe weird space constraint
  8. Steered by MMT5???
    1. TO DO: why is this optic so large compared to OMMT4?
    2. TO DO: is there a more space efficient way of steering this beam, or even some way that avoids having to steer with three distinct optics
  9. Steered by MMT6???
    1. TO DO: Can this optic be removed with some clever new beam path?
  10. Cleaned by the OMC
    1. TO DO: Where does the promptly reflected beam from OMC1 go after it exits the chamber?
    2. TO DO: check the PZTs
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does the OMC actually have?
    3. TO DO: Determine if a new OMC configuration would be more ideal for the squeezing experiment
      1. This is a large task, not part of this immediate vent
    4. TO DO: What is done with the OMC reflection? What is done with the transmission?
    5. TO DO: Check the logs about how the OMC had been in use; should be mostly from rob ward
  11. Reflected beam goes to the next chamber
  12. Transmitted beam is split by OM7???
    1. TO DO: find the actual name of this optic
    2. TO DO: why does this have the R/T that is does?
  13. Reflected beam goes to my OMPD
    1. TO DO: figure out what this PD is used for, and whether we even need it
      1. I think this might be the camera mentioned in 40m elog 21
      2. Elog 42 says the 4 QPDs for the OMC have meds screens located under C2TPT—is this a clue for channel names?
  14. Transmitted beam is reflected to the next chamber by OM8???
    1. TO DO: determine the name of this optic
    2. TO DO: Where does this beam go? What is it used for?
  15. Beam Dumps to add
    1. Transmission through OM5? Probably don’t need…
    2. OMMT1 transmission
    3. OMMT steering mirror transmissions
    4. OMC transmissions? Probably not?
    5. OMPD transmission?
    6. OM8 transmission
    7. Green scattering off of the window where the beam goes after GR_SM5
    8. Backscatter from the OMC prompt reflection to the window
    9. Backscatter from the OMC reflection to the window
    10. Backscatter from the MC beam off the window (this beam just travels through this chamber, interacts with no optics; there is also what looks like a small blue beam on this diagram, so maybe need to dump that backscatter too)
    11. Backscatter from the PO beam from OM6 going through the chamber window
    12. Backscatter from IM1 out the window
    13. There is a small blue beam from OMMT3 that goes through this window as well, I’m not sure exactly what is is from or for, or if it is physical (there are a few of these strange blue lines, i'm probably just misreading the diagram)
  16. TESTS TO DO
    1. Characterize the PZT control
    2. Lock the OMC with a PZT dither lock
      1. Eg elog 59
    3. “Tap-tap-tappy-tap test” to find resonanes
      1. Look at combination of PDH error signal and DCPD signal???
      2. See elog 86 for results from initial OMC install—Nov 2007
    4. Check wiggling wires, etc
    5. TFs to check? Vertical TF?
    6. OMC Length check— see for eg elog 768
  17. ADDITIONAL TO DO
    1. Mode matching calculation for new radius of curvature optics—see elog 1271
      1. The current MMT is not the optimal configuration even for the old Rc (see 3077 and 3088)

 

Notes during reading elog

  • Entry 590 has a labelled picture of the optics setup with OMC
  • Mention of omcepics at elog 894
  • Some important changes happened in elog 1823
    • 1''->2'' mirror out of the vacuum--I should check whether this is still there, or if it has been moved
    • [many more changes.....]
  • There were at one time 2 cameras monitoring OMCT and R (see 4492, 4493)
  • Some OMC PZT HV supply info is at elog 4738, 4740... 
  • There are some photos of the OMC table at elog 5120, and a note about moving some optics
  • Not strictly about the OMC, but I really like Suresh's diagram 6756, I'll make something similar for the OMC electronics
    • although it is about adding the tip tilt electronics, which I think required a new flange for the OMC chamber
  • OMC stage 1 and 2 are the steering mirrors going into the OMC, and were controlled by EPICS chans (6875, 6884)
    • these PZT HV supplies lived in OMC_SOUTH (or maybe 1Y3? see elog 6893), the driver in OMC_NORTH (LIGO-D060287)
    • Photos of these supplies in 7696
  • There are pictures of the OMC and its PZTs in 7401
  • The OMC HV supply was moved to power a different set of PZTs (see 7603)
  • Talk of replacing the PZTs with picomotors or tip/tilts in 7684
  • More pictures of the OMC table before the OMC was 'removed' are here (8114) and in 12563/12571 Gautam links to a Picassa album with pictures from just before the beam was diverted
  14060   Thu Jul 12 21:16:25 2018 aaronUpdateOMCChecking OMC Electronics

In preparation for tomorrow's vent, I'm checking some of the OMC-related electronics we plan to use.

First up is the HV Piezo Driver (D060283).

(well, technically the first up was the Kepco HV power supply... but I quickly tested that its output works up to 300V on a multimeter. The power supply for OMC-L-PZT is all good!)

According to the DCC, the nominal HV supply for this board is 200V; the board itself is printed with "+400V MAX", and the label on the HV supply says it was run at 250V. For now I'm applying 200V. I'm also supplying +-15V from a Tektronix supply.

I used two DB25 breakout boards to look at the pins for the DC and AC voltage monitors (OMC_Vmon_+/-, pins 1/6, and OMC_Vmon_AC+/-, pins 2 and 7) on a scope. I hooked up a DS345 function generator to the piezo drive inputn (pins 1,6). According to the 2013 diagram from the DCC, there is just one drive input, and an alternative "dither in" BNC that can override the DAC drive signal. I leave the alternative dither floating and am just talking to the DAC pins.

Aspects of the system seem to work. For example, I can apply a sine wave at the input, and watch on the AC monitor FFT as I shift the frequency. However, anything I do at DC seems to be filtered out. The DC output is always 150V (as long as 200V comes from the supply). I also notice that the sign of the DC mon is negative (when the Vmon_+ pin is kept high on the scope), even though when I measure the voltage directly with a multimeter the voltage has the expected (+) polarity.

A few things to try:

  • The DC_Readout electronics scheme on the wiki has separate oscillator and control inputs. This diagram has lied to us in the past and is older, and the traces on top of the breadboard seem to only go to pins 1 and 6, but I'm going to first try to apply a voltage across pins 2 and 7 in case there actually is a separate control I'm ignoring.
    • Driving on these pins seems to do nothing

On further investigation this was the key clue. I had the wrong DCC document, this is an old version of this board, the actual board we are using is version A1 of D060283-x0 (one of the "other files")

Gautam and Koji returned at this point and we started going through the testpoints of the board, before quickly realizing that the DC voltage wasn't making it to the board. Turns out the cable was a "NULL" cable, so indeed the AC wasn't passing. We swapped out the cable, and tested the circuit with 30V from the HV supply to trim the voltage reference at U14. The minimum voltage we could get is 5V, due to the voltage divider to ground made by R39. We confirmed that the board, powered with 200V, can drive a sine wave and the DC and AC mons behave as expected.

  14072   Sat Jul 14 16:04:34 2018 aaronUpdateOMCChecking OMC Electronics

Next check is the DCPD/OMMT Satellite Box

I traced a cable from the OMC electrical feedthrough flanges to find the DCPD/OMMT Satellite Box (D060105). I couldn't find the DCC number or mention of the box anywhere except this old elog.

Gautam and I supplied the box with power and tested what we think is the bias for the PD, but don't read any bias... we tracked down the problem to a suspicious cable, labelled.

We confirmed that the board supplies the +5V bias that Rich told us we should supply to the PDs.

We tested the TFs for the board from the PD input pins to output pins with a 100kHz low pass (attached, sorry no phase plots). The TFs look flat as expected. The unfiltered outputs of the board appear bandpassed; we couldn't identify why this was from the circuit diagram but didn't worry too much about it, as we can plan to use the low passed outputs.

Attachment 1: Screenshot_2018-07-14_17.53.40.png
Screenshot_2018-07-14_17.53.40.png
Attachment 2: Screenshot_2018-07-14_17.57.17.png
Screenshot_2018-07-14_17.57.17.png
  14095   Sat Jul 21 01:14:02 2018 gautamUpdateOMCPZT Jena driver board check

[Aaron, gautam]

We did a quick check of this board today. Main takeaways:

  • There are two voltages (HV pos and HV neg) that are output from this unit.
  • Presumably, these goto different piezoelectric elements, referenced to ground. Are there any spec sheets for these describing the geometry/threshold voltages?
  • The outputs are:
    • \mathrm{HV_{+}} = 10(V_{\mathrm{DAC}}+V_{\mathrm{offset}}), \mathrm{HV_{-}} = 10(-V_{\mathrm{DAC}}+V_{\mathrm{offset}})
    • So with V_{\mathrm{offset}} = 7.5 \mathrm{V}, we expect to be able to use +/- 7.5 V of DAC range.
  • The trim pot had to be adjusted to realize V_{\mathrm{offset}} = 7.5 \mathrm{V}​.
  • I assume 150V is some kind of damage threshold of the PZT, so there is no benefit to using 10V offset voltage (as this would result in 200 V at full range DAC voltages).

With the correct V_{\mathrm{offset}} = 7.5 \mathrm{V}, we expect 0V from the DAC to result in 0 actuation on the mirror, assuming that an equal 75V goes to 2 PZTs mounted diametrically opposite on the optic. Hopefully, this means we have sufficient range to scan the input pointing into the OMC and get some sort of signal in the REFL signal (while length PZT is being scanned) which indicates a resonance. 

We plan to carve out some IFO time for this work next week.

  14120   Tue Jul 31 22:50:18 2018 aaronUpdateOMCOMC Expected Refl Signal

I learned a lot about lasers this week from Siegman. Here are some plots that show the expected reflectivity off of the OMC for various mode matching cases.

The main equation to know is 11.29 in Siegman, the total reflection coefficient going into the cavity:

R=r-\frac{t^2}{r}\frac{g(\omega)}{1-g(\omega)}

Where r is the mirror reflectivity (assumed all mirrors have the same reflectivity), t is the transmissivity, and g is the complex round-trip gain, eq 11.18

g(\omega)=r_1r_2(r_3...)e^{-i\phi}e^{-\alpha_0p}

The second exponential is the loss; in Siegman the \alpha_0 is some absorption coecfficient and p is the total round trip length, so the product is just the total loss in a round trip, which I take to be 4*the loss on a single optic (50ppm each). \phi is the total round trip phase accumulation, which is 2\pi*detuning(Hz)/FSR. The parameters for the cavity can be found on the wiki.

I've added the ipynb to my personal git, but I can put it elsewhere if there is somewhere more appropriate. I think this is all OK, but let me know if something is not quite right.

Attachment 1: omcRefl.pdf
omcRefl.pdf
  14159   Mon Aug 13 20:21:10 2018 aaronUpdateOMCNew DAC for the OMC

[aaron, gautam]

We finished up making the new c1omc model  (screenshot attached).

The new channels are only four DAC for ASC into the OMC, and one DAC for the OMC length:

C1:OMC-ASC_PZT1_PIT
C1:OMC-ASC_PZT1_YAW
C1:OMC-ASC_PZT2_PIT
C1:OMC-ASC_PZT2_YAW
C1:OMC-PZT
 
The model compiles and we can change the channel values, so we are all set to do this OMC scan on the software side.
Attachment 1: c1omcSCREENSHOT.png
c1omcSCREENSHOT.png
  14163   Tue Aug 14 23:14:24 2018 aaronUpdateOMCOMC scanning/aligning script

I made a script to scan the OMC length at each setpoint for the two TTs steering into the OMC. It is currently located on nodus at /users/aaron/OMC/scripts/OMC_lockScan.py.

I haven't tested it and used some ez.write syntax that I hadn't used before, so I'll have to double check it.

My other qualm is that I start with all PZTs set at 0, and step around alternative +/- values on each PZT at the same magnitude (for example, at some value of PZT1_PIT, PZT1_YAW, PZT2_PIT, I'll scan PZT2_YAW=1, then PZT2_YAW=-1, then PZT2_YAW=2). If there's strong hysteresis in the PZTs, this might be a problem.

  14213   Sun Sep 23 20:15:35 2018 KojiSummaryOMCMontecarlo simulation of the phase difference between P and S pols for a modeled HR mirror

Link to OMC_Lab ELOG 308

  14312   Tue Nov 20 20:33:11 2018 aaronUpdateOMCOMC scanning/aligning script

I finished running the cabling for the OMC, which involved running 7x 50ft DB9 cables from the OMC_NORTH rack to the 1X2 rack, laying cables over others on the tray. I tried not to move other cables to the extent I could, and I didn't run the new cables under any old cables. I attach a sketch diagram of where these cables are going, not inclusive of the entire DAC/ADC signal path.

I also had to open up the AA board (D050387, D050374), because it had an IPC connector rather than the DB37 that I needed to connect. The DAC sends signals to a breakout board that is in use (D080302) and had a DB37 output free (though note this carries only 4 DAC channels). I opened up the AA board and it had two IPC 40s connected to an adapter to the final IPC 70 output. I replaced the IPC40 connectors with DB37 breakouts, and made a new slot (I couldn't find a DB37 punch, so this is not great...) on the front panel for one of them, so I can attach it to the breakout board.

I noticed there were many unused wires, so I had to confirm that I had the wiring correct (still haven't confirmed by driving the channels, but will do). There was no DCC for D080302, but I grabbed the diagrams for the whitening boards it was connected to (D020432) and for the AA board I was opening up as well as checked out elog 8814, and I think I got it. I'll confirm this manually and make a diagram if it's not fake news.

Attachment 1: pathwaysketch.pdf
pathwaysketch.pdf
Attachment 2: IMG_0094.JPG
IMG_0094.JPG
Attachment 3: IMG_0097.JPG
IMG_0097.JPG
  14317   Mon Nov 26 15:43:16 2018 aaronUpdateOMCOMC scanning/aligning script

I've started testing the OMC channels I'll use.

I needed to update the model, because I was getting "Unable to setup testpoint" errors for the DAC channels that I had created earlier, and didn't have any ADC channels yet defined. I attach a screenshot of the new model. I ran

rtcds make c1omc
rtcds install c1omc
rtcds start c1omc.
 
without errors.
Attachment 1: c1omc.png
c1omc.png
  14332   Thu Dec 6 11:16:28 2018 aaronUpdateOMCOMC channels

I need to hookup +/- 24 V supplies to the OMC whitening/dewhitening boxes that have been added to 1X2.

There are trailing +24V fuse slots, so I will extend that row to leave the same number of slots open.

While removing one +24V wire to add to the daisy chain, I let the wire brush an exposed conductor on the ground side, causing a spark. FSS_PCDRIVE and FSS_FAST are at different levels than before this spark. The 24V sorensens have the same currents as before according to the labels. Gautam advised me to remove the final fuse in the daisy chain before adding additional links.

gautam: we peeled off some outdated labels from the Sorensens in 1X1 such that each unit now has only 1 label visible reflecting the voltage and current. Aaron will post a photo after his work.

  14337   Mon Dec 10 12:11:28 2018 aaronUpdateOMCAligning the OMC

I did some ray tracing and determined that the aux beam will enter the OMC after losing some power in reflection on OMPO (couldn't find this spec on the wiki, I remember something like 90-10 or 50-50) and the SRM (R~0.9), and then transmission through OMPO. This gives us something like 8%-23% of the aux light going to the OMC, depending on the OMPO transmission. This elog tells me the aux power before the recombination BS is ~37mW, ~3.7mW onto SRM, which is consistent with the OMPO being 90-10, and would mean the aux power onto the OMC is ~3mW, plenty for aligning into the OMC.

Since the dewhitening board I'd intended to use isn't working (see elog) , I'm gong to scan the OMC length with a function generator while adjusting the alignment by hand, as was briefly attempted during the last vent.

I couldn't identify a PD on the AP table that was the one I had used during the last vent, I suspect I coopted the very same PD for the arm loss measurements. It is a PDA520, which has a large (100mm^2) area so I've repurposed it again to catch the OMC prompt reflection during the mode scans. I've mounted it approximately where I expect the refl beam to exit the AS chamber.

I brought over the cart that usually lives at 1X1 to help me organize materials near the OMC chamber for opening.

I replaced the banana connectors we'd been using to send HV to the HV driver with soldered wires going to the final locking connector only, so now the 150V is on a safe cable.

I powered up the DCPD sat box and again confirmed that it's working. I sent a 500Hz sine wave through the sat box and confirmed that I can see the signal in the DCPD channels I've defined in cds. I gave the TT and OMC-L PZT channels bad assignments on the ADC (right now, what reads as 'OMC_PZT_MON' is actually the unfiltered output from the sat box, while the DCPD channels are for the filtered outputs of the box), because the way the signals are grouped on the cables I can't attach all of them at once. For this vent, I'll only really need the DCPD outputs, and since I have confirmed that I can read out both of those I'll fix up the HV driver mon channels later.

Attachment 1: B9DCF55F-1355-410C-8A29-EE45D43A56A4.jpeg
B9DCF55F-1355-410C-8A29-EE45D43A56A4.jpeg
  14338   Mon Dec 10 12:29:05 2018 aaronUpdateOMCOMC channels

I kept having trouble keeping the power LEDs on the dewhitening board 'on'. I did the following:

1. I noticed that the dewhitening board was drawing a lot of current (>500mA), so I initially thought that the indicators were just turning on until I blew the fuse. I couldn't find the electronics diagrams for this board, so I was using analagous boards' diagrams and wasn't sure how much current to expect to draw. I swapped out for 1A fuses (only for the electronics I was adding to the system).

2. Now the +24V indicator on the dewhitening board wasn't turning on, and the -24V supply was alternatively drawing ~500mA and 0mA in a ~1Hz square wave. Thinking I could be dropping voltage along the path to the board, I swapped out the cables leading to the whitening/dewhitening boards with 16AWG (was 18AWG). This didn't seem to help.

3. Since the whitening board seemed to be consistently powered on, I removed the dewhitening board to see if there was a problem with it. Indeed, I'd burned out the +24V supply electronics--two resisters were broken entirely, and the breadboard near the voltage regulator had been visibly heated.

  1. I identified that the resistors were 1Ohm, and replaced them (though I couldn't find 1Ohm surface mount resistors). I also replaced the voltage regulator in case it was broken. I couldn't find the exact model, so I replaced the LM2940CT-12 with an LM7812, which I think is the newer 12V regulator.
  2. Though this replacement seemed to work when the power board was disconnected from the dewhitening board, connecting to the dewhitening board again resulted in a lot of current draw.
  3. I depowered the board and decided to take a different approach (see)

I noticed that the +/-15V currents are slightly higher than the labels, but didn't notice whether they were already different before I began this work.

I also noticed one pair of wires in the area of 1X1 I was working that wasn't attached to power (or anything). I didn't know what it was for, so I've attached a picture.

Attachment 1: 52DE723A-02A4-4C62-879B-7B0070AE8A00.jpeg
52DE723A-02A4-4C62-879B-7B0070AE8A00.jpeg
Attachment 2: 545E5512-D003-408B-9F00-55F985966A16.jpeg
545E5512-D003-408B-9F00-55F985966A16.jpeg
Attachment 3: DFF34976-CC49-4E4F-BFD1-A197E2072A32.jpeg
DFF34976-CC49-4E4F-BFD1-A197E2072A32.jpeg
  14340   Mon Dec 10 19:47:06 2018 aaronUpdateOMCOMC channels

Taking another look at the datasheet, I don't think LM7812 is an appropriate replacement and I think the LM2940CT-12 is supposed to supply 1A, so it's possible the problem actually is on the power board, not on the dewhitening board. The board takes +/- 15V, not +/- 24...

Quote:
 
  1. I identified that the resistors were 1Ohm, and replaced them (though I couldn't find 1Ohm surface mount resistors). I also replaced the voltage regulator in case it was broken. I couldn't find the exact model, so I replaced the LM2940CT-12 with an LM7812, which I think is the newer 12V regulator.

 

  14341   Tue Dec 11 13:42:44 2018 KojiUpdateOMCOMC channels

FYI:

D050368 Anti-Imaging Chassis
https://dcc.ligo.org/LIGO-D050368

https://labcit.ligo.caltech.edu/~tetzel/files/equip

D050368 Adl SUS/SEI Anti-Image filter board 
S/N 100-102 Assembled by screaming circuits. Begin testing 4/3/06 
S/N xxx Mohana returned it to the shop. No S/N or traveler. Put in shop inventory 4/24/06 
S/N 103 Rev 01. Returned from Screaming circuits 7/10/06. complete except for C28, C29 
S/N 104-106 Rev 01. Returned from Screaming circuits 7/10/06. complete except for C28, C29 Needs DRV-135’s installed 
S/N 107-111 Rev 02 (32768 Hz) Back from assembly 7/14/06 
S/N 112-113 Rev 03 (65536 Hz) assembled into chassis and waiting for test 1/29/07 
S/N 114 Rev 03 (65536 Hz) assembled and ready for test 020507 


D050512 RBS Interface Chassis Power Supply Board (Just an entry. There is no file)

https://dcc.ligo.org/LIGO-D050512

RBS Interface Chassis Power Board D050512-00

https://labcit.ligo.caltech.edu/~rolf/jayfiles/drawings/D050512-00.pdf
 

 

  14342   Tue Dec 11 13:48:04 2018 aaronUpdateOMCOMC channels

Koji gave me some tips on testing this board that I wanted to write down, notes probably a bit intermingled with my thoughts. Thanks Koji, also for the DCC and equipment logging!

  • Test the power and AI boards separately with an external supply, ramping the voltage up slowly for each.
  • If it seems the AI board is actually drawing too much current, may need to check its TPs for where a problem might be
    • If it's really extensive may use an IR camera to see what elements are getting too hot
    • Testing in segments will prevent breaking more components
  • Check the regulator that I've replaced
  • The 1 Ohm resistors may have been acting as extra 1A fuses. i need to make sure the resistors I've used to replace them are rated for >1W, if this is the case.
  • Can check the resistance between +-12V and Gnd inputs on the AI board, if there is a short drawing too much current it may show up there.
  • The 7812 may be an appropriate regulator, but the input voltage may need to be somewhat higher than with the low drop regulator that was used before.
  • I want to double check the diagram on the DCC
  14343   Tue Dec 11 14:24:18 2018 aaronUpdateOMCAligning the OMC

I set up a function generator to drive OMC-L, and have the two DCPD mons and the OMC REFL PD sent to an oscilloscope. I need to select a cds channel over which to read the REFL signal.

The two DCPD mon channels have very different behaviors on the PD mons at the sat box (see attachment). PD1 has an obvious periodicity, PD2 has less noise overall and looks more white. I don't yet understand this, and whether it is caused by real light, something at the PDs, or something at the sat box.

I've again gone through the operations that will happen with the OMC chamber vented. Here's how it'll go, with some of the open questions that I'm discussing with Gautam or whoever is around the 40m:

  1. Function generator is driving OMC-L. Right now there is one 150V Kepco supply in use, located on the ground just to the right of the OMC rack. I only have plans to power it on while scanning OMC-L, and until the OMC is fully in use the standard practice will be to use this HV with two people in the lab and shut it off after the immediate activities.
    1. To do: Is a second drive necessary for the TT drivers? I don't think it is during this vent, because we will want to align into the OMC with the TTs in a 'neutral' state. I recall that the way the TT drivers are set up, 0V from the dac to the driver is the 'centered' position for all TTs. Unless we want to compensate for some known shift of the chambers during pumpdown, I think this is the TT position we should use while aligning the OMMT into the OMC.
    2. To do: make sure I'm driving the right pins with the function generator. Update: Seems I was driving the right channels, here's the pinout.
  2. We will use the reflection of aux from the SRM to align into the OMC.
    1. Gautam pointed out that I hadn't accounted for the recombination BS for the aux beam being 90-10. This means there's actually something like 300uW of aux onto the OMC, rather than ~3mW. This should still be enough to see on a card, so it is fine.
    2. However, the aux beam is aligned to be colinear with the AS beam when the SRM is misaligned. So the question is whether the wedge on the SRM makes the SRM-reflected aux beam not colinear with the AS beam

 

---------

Talked with Gautam for a good while about the above plan. In trying to figure out why the DCPD sat box appears to have a different TF for the two PDs (seems to be some loose cabling problem at the mons, because wiggling the cables changed this), we determined that the AA chassis also wasn't behaving as expected--driving the expected channels (28-31) with a sine wave yields some signal at the 100Hz driving frequency, but all save ch31 were noisy. We also still saw the 100Hz when the chassis was unplugged. I will continue pursuing this, but in the meantime I'm making an IDE40 to DB37 connector so I can drive the ADC channels directly with the DAC channels I've defined (need to match pinouts for D080303 to D080302). I also will make a new SCSI to DB37 adapter that is more robust than mentioned here. I also need to replace the cable carrying HV to the OMC-L driver, so that it doesn't have a wire-to-wire solder joint.

We moved a razor blade on the AP table so it is no longer blocking the aux beam. We checked the alignment of aux into the AS port. AUX and AS are not colinear anywhere on the AP table, and despite confirming that the main AS beam is still being reflected off of the OMC input mirror, the returning AUX beam does not reach the AP table (and probably is not reaching the OMC). AUX needs to be realigned such that it is colinear with the AS beam. It would be good if in this configuration, the SRM is held close to its position when the interferometer is locked, but the TTs should provide us some (~2.5mrad) actuation. Gautam will do this alignment and I will calculate whether the TTs will be able to compensate for any misalignment of the SRM.

Here is the new plan and minimal things to do for the door opening tomorrow:

  1. Function generator is driving OMC-L.
    1. The PZT mon channel is sent to the oscilloscope.
    2. To do: confirm again that the triangle wave I send in results in the expected triangle wave going to the OMC, using this mon channel.
  2. The OMC REFL signal is being sent to the AP PD. See photo.
    1. Need to align into this PD, but this alignment can be done in air on the AP table.
  3. Monitor the DCPD signals using the TPs from the sat box going to the oscilloscope.
    1. There may be further problems with the sat box, but for the initial alignment into the OMC only the REFL signal is necessary.
    2. Not minimally necessary, but the sat box needs a new case. It has a front, back, and bottom, but no main case, so the board is exposed.
  4. I will move the OMMT-to-OMC steering mirrors while watching the scope for flashes in the REFL signal.

That is the first, minimal sequence of steps, which I plan to complete tomorrow. After aligned into the OMC, the alignment into the DCPDs shouldn't need modification. Barring work needed to align from OMC to DCPDs, I think most other work with the OMC can be done in-air.

  14346   Tue Dec 11 22:50:07 2018 aaronUpdateOMCAligning the OMC

I did the following:

  • Noticed that the OMC rack's power has +-18V, but I had tested the HV driver with +-15V. Maybe fine, something to watch.
  • Checked that nothing but the OMC driver board was in use on the OMC's Sorensen (the QPD whitening board in the OMC rack is not in use, and anyway is labeled +-15V), then turned down the rack voltage from 18 to 15V. Photos attached of AUX_OMC_S Sorensen bank.
  • I hadn't used the alternative dither before. I started by driving the alternative dither with a 10Vpp sine wave at 1-10 Hz. I have both the DC and AC driver mons on a scope.
    • Initially, I only give it 10V at the HV. I don't see much, nor at 30V, while driving with 0-10V sine waves between 0.1-100Hz.
    • In my last log, I hadn't been using the alternative dither.
  • Instead, I switch over to the main piezo drive, which is sent over DB9. Now I see the following on the AC/DC piezo mon channels:
    • Increasing the HV input (increasing in steps from 10-50V) yields 1V at the DC piezo mon for 50V at the HV input.
    • Driving under a few 100s of Hz results in no change to the AC dither mon. Driving <1Hz results in a small (~10% for a 10Vpp drive) at the HV. I didn't take a full transfer function, but it is the thing to do with cds.
    • Changing the drive amplitude changes the AC mon amplitude proportionally
    • At a few kHz, the 10Vpp drive saturates the AC mon.
    • Photos are in order:
      • 1Hz drive, visible on the DC mon channel in green
      • 1kHz drive 10Vpp, visible on the AC mon channel in violet
      • 1kHz drive 5Vpp
      • 5kHz drive 10Vpp, saturates the AC mon channel
Attachment 1: 8323029A-970E-4BEA-833E-77E709300446.jpeg
8323029A-970E-4BEA-833E-77E709300446.jpeg
Attachment 2: C52735BB-0C56-41A1-B731-678CDDCEC921.jpeg
C52735BB-0C56-41A1-B731-678CDDCEC921.jpeg
Attachment 3: 3F8A0B3B-5C7C-4876-B3A7-332F560D554D.jpeg
3F8A0B3B-5C7C-4876-B3A7-332F560D554D.jpeg
Attachment 4: 3DC88B6A-4213-4ABD-A890-7EC317D9EED0.jpeg
3DC88B6A-4213-4ABD-A890-7EC317D9EED0.jpeg
Attachment 5: C0C4F9C0-9574-4A17-9414-B99D6E27025F.jpeg
C0C4F9C0-9574-4A17-9414-B99D6E27025F.jpeg
Attachment 6: A191E1DE-552F-42A5-BED7-246001248BBD.jpeg
A191E1DE-552F-42A5-BED7-246001248BBD.jpeg
  14354   Thu Dec 13 22:24:21 2018 aaronUpdateOMCOMC channels

I completed testing of the AI board mentioned above. In addition to the blown fuse, there were two problems:

  • A was a large drop of solder splattered on some of the ch 1 ICs, which is why we couldn't maintain any voltage. I removed the solder.
  • The +12V wire from the power board to the AI board was loose, so I removed and replaced that crimp connection

After this, I tested the TF of all channels. For the most part, I found the expected 3rd order ~7500Hz cheby with notches at ~16kHz and 32kHz. However, some of the channels had shallower or deeper notches. By ~32kHz, I was below the resolution on the spectrum analyzer. Perhaps I just have nonideal settings? I'll attach a few representative examples.

I reinstalled the chassis at 1X2, but haven't connected power.

 

  14355   Thu Dec 13 22:36:42 2018 aaronUpdateOMCAligning the OMC

I turned on AUX, and aligned the aux beam to be centered on the first optic the AS beam sees on the AP table. I then turned off the AUX laser.

  14357   Fri Dec 14 13:02:24 2018 aaronUpdateOMCAligning the OMC

I replaced the 2'' AUX-AS combining BS with a 2'' HR mirror for 1064. I aligned the AUX beam from the new HR mirror into the next iris, so AUX passes through irises both before and after the new optic. Now, AS does not go out to the AS PDs.

I mounted the old BS on the SP table in a random orientation.

I also dumped the beam transmitted through one of the AUX steering mirrors before the new HR mirror.

  14358   Fri Dec 14 13:06:12 2018 aaronUpdateOMCAligning the OMC

I replaced the 2'' AUX-AS combining BS with a freshly mounted 2'' HR mirror for 1064. The mirror is labelled 'Y1-2037-45-P', and had a comment on its case: 'V'. I aligned the AUX beam from the new HR mirror into the next iris, so AUX passes through irises both before and after the new optic. Now, AS does not go out to the AS PDs.

I mounted the old BS on the SP table in a random orientation.

I also dumped the beam transmitted through one of the AUX steering mirrors before the new HR mirror.

  14363   Mon Dec 17 20:45:40 2018 aaronUpdateOMCAligning the OMC

[gautam, aaron]

We did work in the OMC chamber today to get the OMC aligned. Aaron was in the clean suit while Gautam steered in-air optics. We modified the aux input steering optics and the final two OMC steering optics (between OMMT and OMC), but did not modify any of the AS path optics.

I had already aligned AUX approximately into the AS port from the AP table. With the OMC N door open, we aligned the aux beam first to OM6, then to OMPO, then OM5. OM5 was the last optic in the OMC chamber that we could align to.

From there, Gautam found the aux beam clipping on a few optics on its way to SR4 using the IR viewer. Once we were approximately hitting SR4, we got a return beam in the OMC chamber, which we were able to coalign with the input aux beam.

We had already done the alignment of SR5 into the OMC during the last vent, so we immediately had a refl off of the OMC, which we aligned onto a PD520 from the PSL table (larger aperture than the previous PD, which anyway needed a macroscopic adjustment to catch the refl beam).

Next, we removed the OMC cover, wrapped it in foil, and placed it in the makeshift clean room near the Y end. The screws remain in a foil bucket in the OMC chamber. With the cover off, Aaron moved the OMC input steering mirrors to align the beam in the OMC. We measured ~2.4mW in the OMC refl beam, which means about 240uW is transmitted into the OMC. Aaron thinks the beam overlaps itself after one round trip in the cavity, but that the entire plane may be too low in pitch, so more alignment may be needed here.

With the beam approximately aligned into the OMC, we energized the OMC-L piezo driver with 200V, and applied a ~0.03Hz triangle wave on the OMC diff input (pins 2-7). We monitor the REFL PD, piezo mon, function generator signal, and one of the trans PDs. We noticed that the PZT mon shows the driver saturating before the function generator reaches its full +-10V, which is something to investigate.

We saw what could have been regular dips in the REFL PD signal, but realized that with an unkown level of mode matching, it will be hard to tell whether the light becomes resonant with the DC signal. Gautam has suggested coaligning the aux and PSL beams, then observing the PDH signal from the PSL beam as the OMC sweeps through resonance, while turning aux back on anytime we try to make adjustments to the alignment of the OMC (so I can see the beam in the cavity).

I'll think through the plan in some more detail and we will try to have the OMC locked tomorrow.


gautam:

  1. All references to SR4 etc actually refer to OM4 etc.
  2. For this experiment, we are using the prompt reflection of the AUX beam from the HR surface of the SRM, so as to get maximum light into the cavity.
  3. For 2.4 mW incident on OMC1 (actually we measured the REFL beam on the AS table), we expect ~24 uW inside the cavity, which isn't a lot but still was visible on the card.
  4. After this work, I checked the IMC alignment - it was still easily able to lock to a TEM00 mode, but the transmission was ~half (i.e. ~600cts) of what I am used to it being in low power mode (~1300 cts). I didn't align the cavity to the input beam, as I think in this case, the right thing to do is to align the input beam to the IMC cavity axis.
Attachment 1: IMG_5922.JPG
IMG_5922.JPG
Attachment 2: IMG_5921.JPG
IMG_5921.JPG
  14365   Tue Dec 18 18:13:32 2018 aaronUpdateOMCOMC L HV Piezo driver tests (again)

I tested the OMC-L HV driver box again, and made the following observations:

  • Drove the HV diff pins (2,7) with a 5V triangle wave
    • Observed that with a ~0.4V offset on the drive, the HV output (measured directly with a 10x probe) has a 0-(almost)200V triangle wave (for 200V HV in), saturating near 200V and near 0V somewhat before reaching the full range of the triangle
    • The HV mon gives the same answer as measuring the HV output directly, and is reduced 100x compared to the HV output.
    • At 1Hz and above, the rolloff of the low pass still attenuates the drive a bit, and we don't reach the full range.
  • Drove the HV dither pins (1,6) with a 100mV to 10V triangle wave, around 15kHz
    • Even at 10V, the dithering is near the noise of the mon channel, so while I could see a slight peak changing on the FFT near the dither frequency, I couldn't directly observe this on a scope using the mon channel
    • However, measuring the HV directly I do see the dither applied on top of the HV signal. The amplitude of the dither is the same on the HV output as on the dither drive.

[gautam, aaron]

We searched for blips while nominally scanning the OMC length.

We sent a 0.1Hz, 10Vpp triangle wave to the OMC piezo drive diff channels, so the piezo length is seeing a slow triangle wave from 0-200V.

Then, we applied a ~15kHz dither to the OMC length. This dither is added directly onto the HV signal, so the amplitude of the dither at the OMC is the same as the amplitude of the dither into the HV driver.

We monitored the OMC REFL signal (where we saw no blips yesterday) and mixed this with the 15kHz dither signal to get an error signal. Gautam found a pomona box with a low pass filter, so we also low passsed to get rid of some unidentified high frequency noise we were seeing (possibly a ground loop at the function generator? it was present with the box off, but gone with the AC line unplugged). [So we made our own lock-in amplifier.] Photo attached.

We tested the transfer function of the LP, and finding it at 100kHz rather than the advertised 10kHz, we opened the box, removed a resistor to change the 3dB back to 10kHz, and confirmed this by measuring the TF.

We didn't see flashes of error signal in the mixed reflection either, so we suspect that either the PZT is not actuating on the OMC or the alignment is bad. Based on what appears to be the shimmering of far-misaligned fringes on the AS camera, Aaron's suspicion from aligning the cavity with the card, and the lack of flashes, we suspect the alignment. To avoid being stymied by a malfunctioning PZT, we can scan the laser frequency next time rather than the PZT length.

Attachment 1: IMG_4576_copy.jpg
IMG_4576_copy.jpg
  14366   Wed Dec 19 00:12:46 2018 gautamUpdateOMC40m OMC DCC node

I made a node to collect drawings/schematics for the 40m OMC, added the length drive for now. We should collect other stuff (TT drivers, AA/AI, mechanical drawings etc) there as well for easy reference.

Some numbers FTR:

  • OMC length PZT capacitance was measured to be 209 nF.
  • Series resistance in HV path of OMC lenght PZT driver is 10 kohms, so this creates a LP with corner 1/2/pi/10kohm/200nF ~80 Hz.
  • Per Rob's thesis, the length PZT has DC actuation coefficient of 8.3 nm/V, ∼ 2 µm range. 
  16845   Wed May 11 15:49:42 2022 JCUpdateOPLEV TablesGreen Beam OPLEV Alignment

[Paco, JC]

Paco and I began aligning the Green Beam in the BS Oplev Table. while aligning the GRN-TRX, the initial beam was entering the table a bit low. To fix this, Paco went into the chamber and correcting the pitch with the steering mirror. The GRN-TRX is now set up, both the PD and Camera. Paco is continuing to work on the GRN-TRY and will update later on today. 

In the morning, I will update this post with photos of the new arrangement of the BS OPLEV Table.


Update Wed May 11 16:54:49 2022

[Paco]

GRY is now better mode matched to the YARM and is on the edge of locking, but it more work is needed to improve the alignment. The key difference this time with respect to previous attempts was to scan the two lenses on translation stages along the green injection path. This improved the GTRY level by a factor of 2.5, and I know it can be further improved. Anyways, the locked HOMs are nicely centered on the GTRY PD, so we are likely done with the in-vac GTRY GTRX alignment.


Update Wed May 12 10:59:22 2022

[JC]

The GTRX PD is now set up and connected. The camera have been set to an angle because the cable to connect it is too thick for the camera to maintain its original position along the side. 

 

Attachment 1: IMG_0770.jpeg
IMG_0770.jpeg
  16906   Fri Jun 10 13:52:22 2022 JCUpdateOPLEV TablesITMX, ITMY, and Vertex Table Beam Paths

I have at taken photos and added arrows which signify the beam paths for ITMX, ITMY, and Vertex Oplev tables.

Attachment 1: DCE4F1D7-5AE0-491C-8AF6-F8B659C0787E_1_105_c.jpeg
DCE4F1D7-5AE0-491C-8AF6-F8B659C0787E_1_105_c.jpeg
Attachment 2: 4B24C891-654D-4C51-A8D9-D316364FCF68_1_105_c.jpeg
4B24C891-654D-4C51-A8D9-D316364FCF68_1_105_c.jpeg
Attachment 3: F5B115E5-885F-463C-9645-BB2EB73B6144_1_201_a.jpeg
F5B115E5-885F-463C-9645-BB2EB73B6144_1_201_a.jpeg
  16912   Tue Jun 14 08:41:36 2022 JCUpdateOPLEV TablesBS Oplev Table Sketch

[JC]

Lately, I have been working on a 3d sketch of the BS OPLEV Table on SolidWorks. This is my progress so far, a few of the components I will have to sketch myself, such as the HeNe laser and photodiodes. This will just be a general layout of the HeNe laser, optics, and photodiodes.

Attachment 1: BS_OPLEV_Table.PNG
BS_OPLEV_Table.PNG
  3180   Thu Jul 8 16:24:30 2010 GopalUpdateOptic StacksCompletion of single stack layer

Single layer of stack successfully modeled in COMSOL. I'm working on trying to add Viton springs now and extend it to a full stack. Having some difficulty with finding consistent parameters to work with.

  3186   Fri Jul 9 11:41:58 2010 GopalSummaryOptic StacksTop Optic Layer Complete; Mechanical Tests Giving Problems

For the last week, I have been attempting to determine the mirror stack transfer function which relates mechanical mirror response to a given ground-motion drive. The idea is to model the stacks in COMSOL and ultimately apply mechanical tests for manual calculation.

 

Procuring the correct drawings to base my 3D models off of was no simple task. There are two binders full of a random assortment of drawings, and some of them are associated with the smaller chambers, while others are appropriate for the main chamber, which is what we're interested in right now. For future workers, I suggest checking that your drawings are appropriate for the task at hand with other people before wasting time beginning the painstaking process of CAD design in COMSOL.

 

The drawings that I ultimately decided to use are attached below. They detail four layers of stacks, each which arrange 15, 12, 8, and 5 (going from bottom to top) Viton damping springs in an orderly fashion. The numbers have been chosen to keep the load per spring as constant as possible, in order for all springs to oscillate with as close a resonant frequency to each other as possible.

 

Stack_1_Drawing.JPG   Stack_2_Drawing.JPG

 

 Stack_3_Drawing.JPG    Stack_4_Drawing.JPG

 

 Isolation_Stack.JPG

 

After making some minor simplifications, I have finished modeling the top stack:

 

Stack_4_1.png

 

After triangular meshing, before my many failed attempts at mechanical testing:

 

Stack_4_2.png

 

Both the Viton and steel portions have been given their material properties, and so I should be (theoretically ) ready to perform some eigenfrequency calculations on this simplified system. If my predictions are correct, these eigenfrequencies shouldn’t be too far of the eigenfrequencies of the 4-layer stacked system, because of the layout of the springs. I’ve tried doing mechanical tests on the top stack alone, but there hasn’t been much progress yet on this end, mostly because of some boundary value exceptions that COMSOL keeps throwing at me.

 

In the next couple weeks or so, I plan to extend this model to combine all four layers into one completed stack, along with a simple steel base and mirror platform. I also plan to figure out how to make eigenfrequency and transfer function measurements.

 

Lastly, to anyone who is experienced with COMSOL, I am facing two major roadblocks and could really use your help:

 

1) How to import one model into another, merge models together, or copy and paste the same model over and over.

2) Understanding and debugging run-time errors during mechanical testing.

 

If you have any idea how to attack either of these issues, please talk to me! Thanks!

 

  3199   Mon Jul 12 18:37:10 2010 GopalUpdateOptic StacksEigenfrequency Analysis of Simple Objects

Eigenfrequency analysis has been successfully completed in COMSOL on both a tutorial camshaft, as well as a homemade metal bar.

Upon increasing in complexity to the busbar, I once again began getting into run time errors and increased lag. It seems that this is due to undefined eigenvalues when solving the linear matrices. I tried many boundary values as well as initial conditions in case this was the issue, but it was not. There seems to be some sort of an internal inconsistency. This is no longer a matter of tweaking parameters.

Next steps:

1) Try using the same techniques on the actual mirror stacks to see if we get lucky.

2) In the likely case that this doesn't happen, continue the debugging process. If necessary, a good deal of time may need to be spent learning the COMSOL lower-level jargon.

  3206   Tue Jul 13 13:56:29 2010 GopalConfigurationOptic StacksVitol Material Properties

Viton flouroelastomers have somewhat variable material properties. The following parameters are being used for eigenfrequency analysis.

Young's Modulus: 72,500-87,000 psi (cite: http://www.row-inc.com/pfa.html) *Accurate for PFAs

Poisson's Ratio: 0.48-0.50 (cite: http://www.engineeringtoolbox.com/poissons-ratio-d_1224.html) *Accurate for rubber

Density: 1800 kg/m^3 (cite: http://physics.nist.gov/cgi-bin/Star/compos.pl?matno=275)

  3207   Tue Jul 13 14:59:04 2010 GopalUpdateOptic StacksEigenfrequency Analysis of Single Stack Complete

Via reconfiguration of Viton parameters (previously posted), I managed to debug the COMSOL run time errors and null pointer exceptions. Listed are the resultant eigenfrequencies obtained through structural analysis testing. For all tests, the bottom of the Viton springs are constrained from motion, and all other parts are free to oscillate. Notice that color variations signify displacement from the equilibrium position. Also note that different initial conditions produce different eigenmodes:

No initial displacement:

Eigenmode_Stack_4.png


0.01 m x-displacement:

Eigenmode_Stack_4_xdisp.png


0.01 m y-displacement:

Eigenmode_Stack_4_ydisp.png


 0.01 m z-displacement:

 Eigenmode_Stack_4_zdisp.png


Clearly, the plate has its first harmonic between 210-215 Hz, which is much greater than seismic noises (which never exceed the 10-Hz range). This suggests a highly attenuating transfer function. Since the remaining three plates have been designed to resonate similarly, it is likely that the entire stack system will also function very well.

Next steps:

1) Extend the eigenfrequency analysis to obtain a transfer function for the single-plate system

2) Expand the CAD model to include all four stack layers, and perhaps a base

 

  3222   Wed Jul 14 19:00:56 2010 GopalConfigurationOptic StacksVitol Material Properties, REVISED

Quote:

Viton flouroelastomers have somewhat variable material properties. The following parameters are being used for eigenfrequency analysis.

Young's Modulus: 72,500-87,000 psi (cite: http://www.row-inc.com/pfa.html) *Accurate for PFAs

Poisson's Ratio: 0.48-0.50 (cite: http://www.engineeringtoolbox.com/poissons-ratio-d_1224.html) *Accurate for rubber

Density: 1800 kg/m^3 (cite: http://physics.nist.gov/cgi-bin/Star/compos.pl?matno=275)

 The Young's Modulus for PFA turned out to be orders of magnitude greater than for Viton. The revised values produced much more accurate results:

Young's Modulus for Viton-75: 1950 psi or 6.6 MPa

(Courtesy Row, Inc. and Steve Vass)

This website contains other details: http://www.row-inc.com/viton.html

  3223   Wed Jul 14 19:15:26 2010 GopalSummaryOptic StacksREVISION: Eigenfrequency Analysis of Single Stack Complete

My previous eigenfrequency analysis was incorrect by two orders of magnitude due to the misuse of Young's Modulus information for Viton. After editing this parameter (as documented on 7/14 19:00), the eigenmodes became much more reasonable. I also discovered the Deformation option under the Surface Plotting Options, which makes the eigenmodes of the single stack much more apparant.

Attached are pictures of the first four eigenmodes:

First Eigenmode: y-translational, 7.49 Hz

Eigenfrequency_1_Stack4.png

Second Eigenmode: x-translational, 7.55 Hz

Eigenfrequency_2_Stack4.png

Third Eigenmode: z-rotational, 8.63 Hz

Eigenfrequency_3_Stack4.png

Fourth Eigenmode: z-translational, 18.26 Hz

Eigenfrequency_4_Stack4.png

 

Attachment 2: Eigenfrequency_2_Stack4.png
Eigenfrequency_2_Stack4.png
  3224   Wed Jul 14 19:36:17 2010 GopalUpdateOptic StacksExperimental Confirmation of COMSOL Analysis

I experimentally determined the spring constant of a single Vitol spring in order to obtain a rough estimate for the natural frequency of single-stack oscillation.

The procedure basically involved stacking metal bars of known mass onto the Vitol and using a caliper to measure deviations from the equilibrium length.

The plot below shows that, for small compressions, the response is linear to an R-squared of 0.98.

Untitled.png

The experimental spring constant came out to be about 270 lb/ft, or 3900 N/m.

Previous documents have listed that the top stack takes on a load of approximately 43 kg. per individual spring. A bit of calculation yields an experimental resonant frequency of 9.5 Hz.

Compared with the theoretical COMSOL first harmonic of about 7.5 Hz, there is a reasonable amount of error. Of course, I used this calculation as a simple ballpark estimate: errors from misplacement onto the Viton were minimized through use of a level, but were still inevitable on the mm scale. Since the two methods yield answers with the same order of magnitude, we are ready to move forward and build the remaining layers of the stack.

  3246   Mon Jul 19 16:11:17 2010 GopalUpdateOptic StacksEigenfrequency Analysis of Full Stack

Expanding on the single-layer model, I added the second, third, and fourth layers to the stack in COMSOL. Eigenfrequency analysis run times increased exponentially as the model multiplied in complexity. The following images document the some of the important eigenfrequencies:


First Eigenmode: y-translational, 3.34 Hz:

Eigenfrequency_1_4Stacks.png


Second Eigenmode: x-translational, 3.39 Hz:

Eigenfrequency_2_4Stacks.png


Third Eigenmode: z-rotational, 3.88 Hz:

 Eigenfrequency_3_4Stacks.png


Sixth Eigenmode: z-translational, 8.55 Hz:

Eigenfrequency_6_4Stacks.png


As expected, the eigenfrequencies are generally lower, but still in the same range, as the single-layer model, because of greater mass but constant weight-per-spring distribution.

Next Steps:

1) Extend a single stack to the full stack system, which consists of three stacks like this. Perform similar eigenmode analysis.

2) Analyze the mirror suspension system and incorporate a similar pendulum on the top plate.

3) Make transfer function measurements between seismic and mirror motions.

  3252   Tue Jul 20 17:38:16 2010 GopalConfigurationOptic StacksStack Type Clarifications

Some clarification is warranted regarding the different shapes of stacks. Corrections are appreciated:

1) The single-leg stack that I just completed should function as a working model for the IO, OO, and MC1/3. Rana commented, however, that the current dimensions are slightly off for MC1/3 (which makes sense since I could only find drawings for the IOC). If anyone knows the whereabouts of similar drawings for MC1/3, I'd much appreciate it.

2) A triple-leg stack can model the BS, ITMX, and ITMY chambers. I don't have exact dimensions for these, but I can make decent approximations from to-scale stack drawings. I'll probably work on a model for this style next, since at least I have some information regarding this version.

3) The MC2 chamber has its own stack model, about which I haven't found any drawings in the binders. I can't start on MC2C at all until I find such drawings.

  3261   Wed Jul 21 17:41:17 2010 GopalConfigurationOptic StacksPictures of Stacks

Now that venting is complete, this is a request for anyone who opens any chamber:

1) Please notify me immediately so I can take pictures of the stacks in that chamber.

2) If I'm not around, please take a few pictures for me. I'm most interested in the shape, number of layers, size, and damper arrangements of each stack.

This is most important for the MC1/MC3 chamber, MC2 chamber, and BS/ITMX/ITMY chambers.

Thanks!

  3276   Fri Jul 23 14:26:01 2010 GopalUpdateOptic StacksSimple Frequency Response Measurements in COMSOL

Over the past couple days, I discovered a simple, direct method for calculating frequency responses with a combination of COMSOL and any plotter such as Excel or MatLab. The simple case of rectangular prism of steel was analyzed using this method; details will be posted shortly on the COMSOL Wiki page. The frequency response matched theoretical reasoning: the bar acts as a simple mechanical low-pass filter, rapidly attenuating driving frequencies at the base beyond the first eigenmode.

It therefore shouldn't be too difficult to extend this analysis to the MC1/MC3 stack. The many eigenfrequencies will produce a more complicated transfer function, and so more data points will be taken.

The major shortcoming of this method involves dealing with the imaginary components of the eigenfrequencies. As of now, I haven't found a way of measuring the phase lag between the drive and the response. I also haven't found a way of changing the damping constants and therefore playing with phase components.

 

  3298   Tue Jul 27 12:02:31 2010 GopalUpdateOptic StacksPreliminary Transfer Function Measurements on MC1/MC3

I have successfully completed a preliminary transfer function measurement test on the MC1/MC3 stack in COMSOL. Using the measurement scheme described on the Wiki, I initialized a 1 N/m^2 sinusoidal perturbation on the bottom of the stack and measured the maximum displacement of the top layer. This preliminary test just calculated the responses to 1-,2-,3-,4-, and 5-Hz drives along the x-axis (pictures attached).

Currently, I am rerunning the same test but from 1-10 Hz with 0.1-Hz steps. When both x- and y-axis responses have been plotted, I can move on to repeating this entire process on the MC2 stack.

Attachment 1: MC1_MC3_FDA_1.png
MC1_MC3_FDA_1.png
Attachment 2: MC1_MC3_FDA_2.png
MC1_MC3_FDA_2.png
Attachment 3: MC1_MC3_FDA_3.png
MC1_MC3_FDA_3.png
Attachment 4: MC1_MC3_FDA_4.png
MC1_MC3_FDA_4.png
Attachment 5: MC1_MC3_FDA_5.png
MC1_MC3_FDA_5.png
  3301   Tue Jul 27 18:42:57 2010 GopalUpdateOptic StacksBode Magnitude Plot and Concerns

I completed the frequency domain analysis mentioned previously in the x-direction. Although I ran it from 1-10 Hz, with 0.1-Hz increments, COMSOL was unable to complete the task past 7 Hz because the relative error was beyond the relative tolerance. To solve this issue, I'd have to rerun the simulation with a finer mesh, an unfavorable option because of the already-extensive run times. The Bode magnitude plot from this simulation is attached:

Bode_Mag_MC1_MC3.png

 

This simulation raises some questions about the feasibility of this method:

 

1) Do we have the computing power necessary?

 

I already moved my work from my personal Mac Pro to Kallo (4 GB --> 12 GB RAM difference). Now, instead of crashing the program constantly, I typically wait a half hour for a standard run of the model. Preferably, I could move my work to Megatron or some other workhorse-computer... but I also know that many of the big boys are already being strained as is.

 

2) Is it possible to take measurements through Matlab?

 

This way, I could write a script to instruct COMSOL and just run a few tests at a time overnight. Also, I wouldn't have to sit and record measurements manually as I've done here. The benefits of such an improvement warrant further attention. I'll work on this option next.

 

3) Up until what frequency do we need to model?

 

As I've shown, normal meshing yields data up to 7 Hz. Is this enough? Do we need more data? Certainly not less, I'm quite sure. We need to keep in mind that as frequency range increases, run times increase exponentially.

 

4) How do we incorporate gravity into the equation?

 

Gravity will produce a bit of extra force in the non-restoring direction for off-axis deviations, slightly decreasing the expected frequency. Whether or not this is an important effect is questionable, since the deviations are typically on the order of a micron, which is orders of magnitude smaller than the initial displacement I'm using on the base. I've decided to ignore this complication for now.

 

 

  3324   Thu Jul 29 20:43:32 2010 GopalSummaryOptic StacksModeling Tips and Tilts

I have discovered a method of completely characterizing the 6x6 response of all six types (x-,y-, and z- translational/rotational) of oscillatory disturbances at the base of the stack.

  • "Tipping" drives are trivial, and simply require a face load in the appropriate direction.
  • "Tilting" drives could use a torque, but I am instead implementing multiple edge loads in opposing directions to create the appropriate net curl. This curl will be kept constant across the three axes for sake of comparing the resulting transfer functions.
  • "Tipping" responses are once again trivial, and merely require the displacement vector of the top center coordinate to be recorded.
  • "Tilting" responses require the normal vector to be recorded and manipulated to produce the angular coordinates (assuming right-handed coordinate system):
    • θx = tan-1(x/z)
    • θy = tan-1(y/z)
    • θz = tan-1(y/x)

The first three concepts have been confirmed through simulations to produce correct transfer functions. The last test seems to be producing some problems, in that the vector normal to the equilibrium position (an obvious and useless piece of information) is sometimes given instead of the vector normal to the position of maximum displacement. This means that, as of now, I have the capability of measure the half of the complete 6x6 matrix of transfer functions in the coming weeks. The first three of eighteen transfer functions are attached below and will be included in my progress report.

XTrans_XDisp.pngYTrans_XDisp.pngZTrans_XDisp.png

  3339   Sat Jul 31 04:03:11 2010 GopalSummaryOptic StacksComplete Displacement Translational Transfer Function Matrix

Over the past 36 hours, I've run full-fledged FDAs on KALLO.

The transfer functions for translational drives and responses are neatly described by the attached transfer function "matrix."

Progress_Report_2.png

Next steps:

1) Extend the 3x3 analysis to include tilts and rotations in a 6x6 analysis.

2) Figure out how to do the same types of tests for phase instead of displacement.

  3376   Fri Aug 6 15:50:29 2010 GopalUpdateOptic Stacks(Much Better Looking) Displacement-Displacment Transfer Functions

I reran the FDA in COMSOL on the MC1/MC3 Stack and produced the following Displacement-Displacement Transfer Functions:

X-Translational Drive has a blue background

Y-Translational Drive has a red background

Z-Translational Drive has a green background

Obtaining the Displacement-to-Phase part of the Transfer Function still produces difficulties -- I'm still working on the COMSOL-Matlab interface to perhaps better facilitate this.

RA: I have deleted those plots because they weren't transfer functions. Transfer functions must always be the ratio of something to something. For example: if I had a nickel for every bad plot I see, I would be a millionaire. In that example, the transfer function would have the units of nickels/plots. For the stacks, it should be meters/meter.

 

Attachment 1: MC1_MC3_XTrans.png
MC1_MC3_XTrans.png
Attachment 2: MC1_MC3_YTrans.png
MC1_MC3_YTrans.png
Attachment 3: MC1_MC3_ZTrans.png
MC1_MC3_ZTrans.png
  3380   Fri Aug 6 19:46:59 2010 GopalUpdateOptic Stacks(Much Better Looking) Displacement-Displacment Transfer Functions

Quote:

I reran the FDA in COMSOL on the MC1/MC3 Stack and produced the following Displacement-Displacement Transfer Functions:

X-Translational Drive has a blue background

Y-Translational Drive has a red background

Z-Translational Drive has a green background

Obtaining the Displacement-to-Phase part of the Transfer Function still produces difficulties -- I'm still working on the COMSOL-Matlab interface to perhaps better facilitate this.

RA: I have deleted those plots because they weren't transfer functions. Transfer functions must always be the ratio of something to something. For example: if I had a nickel for every bad plot I see, I would be a millionaire. In that example, the transfer function would have the units of nickels/plots. For the stacks, it should be meters/meter.

 

My apologies for the mislabeled axes on my previous plots. They have been corrected to a ratio (in./in.), as Rana so kindly suggested in his helpful, not-at-all-condescending response.

I have chosen to stay in the English system because all of the original stack drawings are in inches as well.

ELOG V3.1.3-