ID |
Date |
Author |
Type |
Category |
Subject |
3847
|
Tue Nov 2 16:24:07 2010 |
Koji | Update | Auxiliary locking | Alignment for the green in the X trans table | [Kiwamu Koji]
Today we found the green beam from the end was totally missing at the vertex.
- What we found was very weak green beam at the end. Unhappy.
- We removed the PBS. We should obtain the beam for the fiber from the rejection of the (sort of) dichroic separator although the given space is not large.
- The temperature controller was off. We turned it on again.
- We found everything was still misaligned. Aligned the crystal, aligned the Faraday for the green.
- Aligned the last two steering mirrors such that we hit the approximate center of the ETMX and the center of the ITMX.
- Made the fine alignment to have the green beam at the PSL table.
The green beam emerged from the chamber looks not so round as there is a clipping at an in-vac steering.
We will make the thorough realignment before closing the tank. |
7673
|
Tue Nov 6 16:38:37 2012 |
jenne, jamie, ayaka, manasa | Update | Alignment | Alignment back under control again | We had a big alignment party early this morning, and things are back to looking good. We have been very careful not to bump or touch tables any more than necessary. Also, we have removed the apertures from the BS and PRM, so there are no more apertures currently left in the chambers (this is good, since we won't forget).
We started over again from the PZTs, using the PRM aperture and the freestanding aperture in front of PR2, to get the height of the beam correct. We then moved PZTs to get the beam centered on BS, ITMY, ETMY. We had to do a little poking of PR2 (and PR3?) to get pitch correct everywhere.
We then went to ETMX to check beam pointing, and used BS to steer the beam to the center of ETMX. We checked that the beam was centered on ITMX.
We went through and ensured that ITMX, ITMY, PRM, SRM are all retroreflecting. We see nice MICH fringes, and we see some fringes (although still not so nice...) when we bring PRM and SRM into alignment.
We checked the AS path (with only MICH aligned), and made sure we are centered on all of the mirrors. This included steering a little bit on the mirrors on the OMC table, in yaw. Initially, AS was coming out of the vacuum, but hitting the side of the black beam tube. Now it gets nicely to the table.
For both AS and REFL, we made sure there is no clipping in the OMC chamber.
I recentered the beams for AS and REFL on their respective cameras.
IPPOS was centered on the QPD. This involved moving the first out-of-vac steering mirror sideways a small amount, since the beam was hitting the edge of the mirror. IPANG was aligned in-vac, and has been centered on the QPD.
Right now, Manasa, Jamie and Ayaka are doing some finishing touches work, checking that POY isn't clipping on OM2, the second steering mirror after the SRM, and they'll confirm that POX comes out of the chamber nicely, and that POP is also still coming out (by putting the green laser pointer back on that table, and making sure the green beam is co-aligned with the beam from PR2-PR3. Also on the list is checking the vertex oplevs. Steve and Manasa did some stuff with the ETM oplevs yesterday, but haven't had a chance to write about it yet. |
7291
|
Tue Aug 28 00:16:19 2012 |
jamie | Update | General | Alignment and vent prep | I think we (Jenne, Jamie) are going to leave things for the night to give ourselves more time to prep for the vent tomorrow.
We still need to put in the PSL output beam attenuator, and then redo the MC alignment.
The AS spot is also indicating that we're clipping somewhere (see below). We need to align things in the vertex and then check the centerings on the AP table.
So I think we're back on track and should be ready to vent by the end of the day tomorrow. |
Attachment 1: as1.png
|
|
17669
|
Fri Jul 7 13:33:48 2023 |
JC | Configuration | Daily Progress | Alignment and restoring the IFO | [Yuta, JC]
We are restoring the IFO alignment back to Nominal operating state
What we did:
- Fixed the IMC and got WFS back to running state.
- Returned all TMs to there original postion using the OPLEVs
- Used BurtRestore to bring back the C1:HPC.adl and C1:BAC.adc
- Align the OPLEVs.
Summary:
To start off the morning, I began to work on IMC which became misaligned ~6:00am. IMC WFS seemed to be the issue, so I turned these off and pushed worked to align IMC manually (This took a ton of time). After aligning, Yuta came in and showed me how to fix IMC WFS and we got it to work again. the main issue being that "Clear History" was stuck for a bit and the offsets were stuck to insane values.
Next we moved forward with viewing the BHD PDs. Yuta knew there was an issue with the BurtRestore Yehonathan and I did yesterday because there were no values on the C1:HPC.adl page. To fix this, in the terminal we typed -->
~> cd /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2023/Jun/9
Now, you land in whichever date you chose, for us it was the 9th of June:
9> burtgooeyC1:HPC.adl
This will pull up BURT. from here go Restore-> Snapshot Files-> (Select your time) -> (Select which files you want to restore) -> Ok -> Cancel -> Restore. (Keywords: How to burtrestore )
This will restore the files of which you have chosen back to the date you selected.
Yuta and I restored C1:HPC.adl and C1:BAC.adl.
Following, now that all the BurtRestoring is done, we moved forward with aligning single arms. We had a very trashy mode on BHD and decided to align TT1 and TT2.
I tried to align the Y arm to start off, but ETMy was acting very hectic. I was trying to align the OPLEVs to start off, but ETMY Oplev was VERY FAR OFF. It was very weird that I was moving YAW for a very good amount and yet the Red Beam would not move one bit in the YAW direction! I couldnt get it even close to hit the steering mirror to hit the ETMY_OPLEV_QPD. I asked Yuta for help and it turns out that the gain for the alignment offesets were 0! After Yuta found this, he restored the original offset values by using:
restoreAlignment -o ETMY -t 'now 14days'
(Keywords: How to restoreAlignment)
After this issue was fixed, I was able to align the OPLEV beam with ease and we started to get some flashing on the Y Arm. Yuta now has the Y Arm locked with flashing on the X Arm. We plan to align nicely and realign the OPLEVs before the end of the day. |
17670
|
Fri Jul 7 15:24:38 2023 |
Koji | Configuration | Daily Progress | Alignment and restoring the IFO | The incompleteness of burtrestore is a critical issue. We need to track down what is the issue.
|
10534
|
Wed Sep 24 18:17:46 2014 |
ericq | Update | General | Alignment Restored | Interferometer alignment is restored
ASS has been run on each arm, recycling mirrors were aligned by overlapping on AS camera.
Notes:
- Mode cleaner alignment took some manual tweaking, locked fine around 1k counts. Still no autolocker.
- At this point, some light was visible on AS and REFL, which was a good sign regarding TTs.
- Used green light to align ETMs to support a green 00 mode.
- Ensured no recylcying flashes were taking place on AS camera and PRM face camera.
- Arms were locked using AS55, with the other ITM misalgined, for better SNR than PO[XY]. ASS brought arm powers to ~0.06, which is about what we would expect from 1k MC2 trans instead of 16k.
- ASS Yarm required debugging, see below.
- ETMX was getting kicks again. Top Dsub connector on the flange near the ground closer to the end table was a little loose. We should fasten it more securely.
- At this point, michelson alignment was good. Brought in PRM to see PRC flashes, REFL spot was happy. Brought in SRM to AS sppot.
- Saved all optic positions.
- Oplevs:
- PRMs new aligned state is falling off the QPD.
- ETMs and BS oplev centering are fine, rest are less good, but still on the detector.
ASS-RFM issue:
ETMY was not getting its ASC pitch and yaw signals. C1SCY had a red RFM bit (although, it still does now...)
I took a look at the c1rfm simulink diagram and found that C1RFM had an RFM block called C1:RFM-TST_ETMY_[PIT/YAW] and C1SCY had one called C1:TST-SCY_ETMY_[PIT/YAW].
It seems that C1TST was illegally being used in a real signal chain, and Jenne's recent work with c1tst broke it. I renamed the channels in C1RFM and C1SCY to C1:RFM-SCY_ETMY_[PIT/YAW], saved, compiled, installed, restarted. All was well.
There are still some in SCY that have this TST stuff going on, however. They have to do with ALS, it seems, but are SHMEM blocks, not RFM. Namely:
- C1:TST-SCY_TRY
- C1:TST-SCY_GLOBALPOS
- C1:TST-SCY_AMP_CTRL
|
1793
|
Sun Jul 26 13:19:54 2009 |
rana | Update | PSL | Aligning the mode cleaner | I set the MC back to its good alignment (June 21st) using this procedure. The trend of the OSEM values over the last 40 days and 40 nights is attached.
Then I aligned the periscope to that beam. This took some serious periscope knob action. Without WFS, the transmission went to 2.7 V and the reflection down to 0.6V.
Then I re-aligned the MC_REFL path as usual. The beam was far enough off that I had to also re-align onto the MC LSC PD as well as the MC REFL camera (~2 beam radii).
Beams are now close to their historical positions on Faraday and MC2. I then restored the PZT sliders to their April snapshot and the X-arm locked.
Steve - please recenter the iris which is on the periscope. It has been way off for a long time.
So it looks OK now. The main point here is that we can trust the MC OSEMs.
Afterwards I rebooted c1susvme1 and c1susvme2 because they were skewed.
|
Attachment 1: Untitled.png
|
|
1794
|
Sun Jul 26 16:05:17 2009 |
Alberto | Update | PSL | Aligning the mode cleaner |
Quote: |
I set the MC back to its good alignment (June 21st) using this procedure. The trend of the OSEM values over the last 40 days and 40 nights is attached.
Then I aligned the periscope to that beam. This took some serious periscope knob action. Without WFS, the transmission went to 2.7 V and the reflection down to 0.6V.
Then I re-aligned the MC_REFL path as usual. The beam was far enough off that I had to also re-align onto the MC LSC PD as well as the MC REFL camera (~2 beam radii).
Beams are now close to their historical positions on Faraday and MC2. I then restored the PZT sliders to their April snapshot and the X-arm locked.
Steve - please recenter the iris which is on the periscope. It has been way off for a long time.
So it looks OK now. The main point here is that we can trust the MC OSEMs.
Afterwards I rebooted c1susvme1 and c1susvme2 because they were skewed.
|
It is really surprising that we now have again the data from the MC OSEMs since up to two days ago the record looked corrupted (see the attachments in my entry 1774).
The reason I ended up severely misaligning the the MC is exactly that there wasn't anymore a reference position that I could go back to and I had to use the camera looking a the Faraday. |
1795
|
Mon Jul 27 09:34:07 2009 |
steve | Summary | IOO | Aligning the mode cleaner |
Quote: |
I set the MC back to its good alignment (June 21st) using this procedure. The trend of the OSEM values over the last 40 days and 40 nights is attached.
Then I aligned the periscope to that beam. This took some serious periscope knob action. Without WFS, the transmission went to 2.7 V and the reflection down to 0.6V.
Then I re-aligned the MC_REFL path as usual. The beam was far enough off that I had to also re-align onto the MC LSC PD as well as the MC REFL camera (~2 beam radii).
Beams are now close to their historical positions on Faraday and MC2. I then restored the PZT sliders to their April snapshot and the X-arm locked.
Steve - please recenter the iris which is on the periscope. It has been way off for a long time.
So it looks OK now. The main point here is that we can trust the MC OSEMs.
Afterwards I rebooted c1susvme1 and c1susvme2 because they were skewed.
|
I'm impressed by Rana's simple way to align the MC. IFO arms are locked or flashing. 20 days trend attached.
|
Attachment 1: 20dtrend.jpg
|
|
1788
|
Fri Jul 24 21:02:46 2009 |
Alberto | Update | PSL | Aligning the beam to the Faraday | This afternoon I kept working on the alignment of the beam so that it matches at the same the PSL periscope, the Mode Cleaner and the Faraday isolator at the input of the IFO.
The camera looking at the Farady showed a beam quite low from the center of the Faraday's entrance. I wanted to move it up.
After working on the periscope alignment and on the MC mirrors, I think I managed to moved it up a bit. To know whether that was enough or not I wanted to evaluate the alignment to the X arm by checking the value of TRX.
In order for the MC to be finely matched to the input beam from the periscope, the WFS controls have to be on. Before turning them on, I centered the beam on their QPDs and run the WFS_zero_offset script.
When I turned them on, the control signal in Pitch from WFS2 started going up with no stop. It was like the integrator in the loop was fed with a DC bias. The effect of that was to misalign the MC cavity from the good state in which it was with the only length control on (that is, transmission ~2.7, reflection ~ 0.4).
I don't know why that is happening. To exclude that it was due to a computer problem I first burtrestored C1IOO to July the 18th, but since that did not help, I even restarted it. Also that didn't solve the problem.
Flashes at ETMX show at least that the beam is going through the Farady. How well, I can't tell untill the MC is under full control.
I have to leave the lab now, but I can be back tomorrow to keep working on that. |
1791
|
Sat Jul 25 16:04:32 2009 |
rob | Update | PSL | Aligning the beam to the Faraday |
Quote: |
When I turned them on, the control signal in Pitch from WFS2 started going up with no stop. It was like the integrator in the loop was fed with a DC bias. The effect of that was to misalign the MC cavity from the good state in which it was with the only length control on (that is, transmission ~2.7, reflection ~ 0.4).
I don't know why that is happening. To exclude that it was due to a computer problem I first burtrestored C1IOO to July the 18th, but since that did not help, I even restarted it. Also that didn't solve the problem.
|
At least one problem is the mis-centering of the resonant spot on MC2, which can be viewed with the video monitors. It's very far from the center of the optic, which causes length-to-angle coupling that makes the mulitple servos which actuate on MC2 (MCL, WFS, local damping) fight each other and go unstable. |
1792
|
Sat Jul 25 19:04:01 2009 |
Koji | Update | PSL | Aligning the beam to the Faraday |
Quote: |
Quote: |
When I turned them on, the control signal in Pitch from WFS2 started going up with no stop. It was like the integrator in the loop was fed with a DC bias. The effect of that was to misalign the MC cavity from the good state in which it was with the only length control on (that is, transmission ~2.7, reflection ~ 0.4).
I don't know why that is happening. To exclude that it was due to a computer problem I first burtrestored C1IOO to July the 18th, but since that did not help, I even restarted it. Also that didn't solve the problem.
|
At least one problem is the mis-centering of the resonant spot on MC2, which can be viewed with the video monitors. It's very far from the center of the optic, which causes length-to-angle coupling that makes the mulitple servos which actuate on MC2 (MCL, WFS, local damping) fight each other and go unstable.
|
I played with the MC alignment for the beam centering. After that, I restored the alignment values.
In principle, one can select the MC2 spot as one likes, while the transmitted beam axis to the IFO is not changed
as far as you are at the best alignment. This principle is almost trivial because the beam axis matches
to the input beam axis at the best alignment.
The alignment solution is not unique for a triangle cavity if we don't fix the end spot position.
In practice, this cruising of the MC2 spot is accomplished by the following procedure:
0) Assume that you are initially at the best alignment (=max transmission).
1) Slightly tilt the MC2.
2) Adjust MC1/MC3 so that the best transmission is restored.
I started from the following initial state of the alignment sliders:
BEFORE TRIAL
MC1 Pitch |
+3.6242 |
MC1 Yaw |
-0.8640 |
MC2 Pitch |
3.6565 |
MC2 Yaw |
-1.1216 |
MC3 Pitch |
-0.6188 |
MC3 Yaw |
-3.1910 |
MC Trans |
2.70 |
After many iterations, the spot was centered in some extent. (See the picture)
RESULT
|
|
adj. |
MC1 Pitch |
+3.363 |
(-0.26) |
MC1 Yaw |
-1.164 |
(-0.3) |
MC2 Pitch |
3.7565 |
(+0.1) |
MC2 Yaw |
-1.2800 |
(~ -0.16) |
MC3 Pitch |
-0.841 |
(~ -0.22) |
MC3 Yaw |
-3.482 |
(~ -0.29) |
MC Trans |
2.75 |
|
The instability looked cured somewhat.
Further adjustment caused a high freq (10Hz at the camera) instability and the IMCR shift issue.
So I returned to the last stable setting.
Side effect:
Of course, if you move MC1, the reflected spot got shifted.
The spot has been apparently off-centered from the IMCR camera. (up and right)
At this stage, I could not determine what is the good state.
So, I restored the alignment of the MC as it was.
But now Alberto can see which mirror do we have to move in which direction and how much. |
Attachment 1: MC2_Cam.jpg
|
|
14337
|
Mon Dec 10 12:11:28 2018 |
aaron | Update | OMC | Aligning 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
|
|
14343
|
Tue Dec 11 14:24:18 2018 |
aaron | Update | OMC | Aligning 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:
- 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.
- 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.
- 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.
- We will use the reflection of aux from the SRM to align into the OMC.
- 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.
- 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:
- Function generator is driving OMC-L.
- The PZT mon channel is sent to the oscilloscope.
- 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.
- The OMC REFL signal is being sent to the AP PD. See photo.
- Need to align into this PD, but this alignment can be done in air on the AP table.
- Monitor the DCPD signals using the TPs from the sat box going to the oscilloscope.
- There may be further problems with the sat box, but for the initial alignment into the OMC only the REFL signal is necessary.
- 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.
- 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 |
aaron | Update | OMC | Aligning 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
|
|
Attachment 2: C52735BB-0C56-41A1-B731-678CDDCEC921.jpeg
|
|
Attachment 3: 3F8A0B3B-5C7C-4876-B3A7-332F560D554D.jpeg
|
|
Attachment 4: 3DC88B6A-4213-4ABD-A890-7EC317D9EED0.jpeg
|
|
Attachment 5: C0C4F9C0-9574-4A17-9414-B99D6E27025F.jpeg
|
|
Attachment 6: A191E1DE-552F-42A5-BED7-246001248BBD.jpeg
|
|
14355
|
Thu Dec 13 22:36:42 2018 |
aaron | Update | OMC | Aligning 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 |
aaron | Update | OMC | Aligning 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 |
aaron | Update | OMC | Aligning 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 |
aaron | Update | OMC | Aligning 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:
- All references to SR4 etc actually refer to OM4 etc.
- 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.
- 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.
- 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
|
|
Attachment 2: IMG_5921.JPG
|
|
5182
|
Thu Aug 11 04:45:07 2011 |
Suresh | Update | IOO | Aligning the 1064nm beam with the in-vacuum pzt's | [Kiwamu, Suresh]
We worked on the beam path from MC to BS this evening.
After the beam spots on MC1 and MC3 were close to the actuation nodes (<1mm away) we checked the beam position on the Faraday Isolator (FI) to make sure that it is passing through both the input and output apertures without clipping. The beam is slightly displaced (by about half a beam diameter) downwards at the input of the FI. The picture below is a screen shot from the MC1 monitor while Kiwamu held an IR card in front of the FI.

We then proceeded to check the beam position on various optical elements downstream. But first we levelled the BS table and checked to see if the reflection from PJ1 (1st Piezo) is landing on the MMT1 properly. It was and we did not make any adjustment to PJ1. However the reflection from MMT1 was not centered on MMT2. We adjusted the MMT1 to center the beam on it. We then adjusted MMT2 to center the beam on PJ2. At this point we noticed that the spot on IPPO (pick off window) was off towards the right edge. When we centered the beam on this it missed the center of the PRM. In order to decide what needs to be moved, we adjusted PJ2 such that the beam hits the PR2, bounces back to PR3, and becomes co-incident with the green beam from X-arm on the BS. Under this condition the beam is not in the center of PRM and nor is it centered on IPPO. In fact it is being clipped at the edge of the IPPO.
It is clear that both IPPO and the PRM need to be moved. To be sure that the beam is centered on PR2 we plan to open the ITMX chamber tomorrow. |
7579
|
Fri Oct 19 01:21:42 2012 |
Evan | Update | Locking | Aligning PZTs, PRM | [Evan, Jenne]
Tonight we made an attempt at getting the PRM + ITMY aligned with correct input pointing. We steered the good PZT so that the input beam makes it through the aperture in front of ETMY. We then aligned the PRM so that the retroreflection of the input beam makes it back into the Faraday. After that we tried dithering the alignment of ITMY and the beamsplitter to see if we could see a spot flash across the AS port, but we saw nothing.
For the PRM alignment we set up a camera looking into the window at the Faraday in the IOO chamber; it's called FI_BACK. We stole a 50mm lens from the ETMY face camera.
We also tried looking for beam on IP_POS and IP_ANG. When the input beam is aligned to pass through the ETMY aperture, we can see beam on the steering mirrors preceding IP_POS, but it hits a mirror mount. When the input beam is aligned as it was on Monday, it clips on the ETMY aperture but makes it further along the IP_POS optical path. In both cases, we weren't able to see any beam coming out for IP ANG. |
4116
|
Wed Jan 5 23:22:00 2011 |
Jenne | Update | Cameras | Aligned the Xarm, no big deal | [Kiwamu, Jenne]
We successfully aligned the X arm. No big deal. Nothing to write in giant colorful letters about. If we thought it was tricky, we'd be excited. But since we're rockstar grad students, we can do this anytime, with one hand behind our back.
The details:
Earlier this evening, Kiwamu put a PD at the dark port. After starting with the usual steering beams around and approximately centering them by finding the beam on the SUS tower, we saw that we could see the fringes on a 'scope hooked up to the dark port's new PD. We could make the dip in the scope trace go away by misaligning the ETM, so we were confident that it was due to some kind of resonance in the arm. We then fine-tuned our beam centering by moving the optics in either pitch or yaw until the fringe went away, wrote down the number, then moved the other direction until the fringe went away, and then put the optic back in the middle of those two numbers. We did the ETM first, then the ITM (because the beam on the PD is sensitive to the ITM pointing, so we didn't want to have to move the ITM very far). We saw that the cavity had a visibility of ~56% when we had finished with this method.
We then went to look for the flashes transmitted through the ETM. We were not able to see them on a card, but when we looked with an IR viewer at the back face of the ETM, we could see the flashes. We stole a spare CCD camera found on the PSL table, and the camera power supply from the RefCav Refl camera, and set up a CCD camera with telephoto lens on the ETMX Trans table, looking directly at the back of the ETM. We hooked the camera up to the regular ETMX camera cable, so we can see the flashes in the control room. You can see them here:

While the cavity was aligned, here were the slider positions:

|
4117
|
Wed Jan 5 23:37:12 2011 |
rana | Update | Cameras | Aligned the Xarm, no big deal | Pretty fancy work actually...I wouldn't have guessed that you need to look at the back of the ETM. Does this mean that we can't see the flashes from inside the arm cavity? If so, its a pretty remarkeable statement about the wide angle scatter of the new mirrors. Do we really have 1W going into the MC? |
4118
|
Wed Jan 5 23:45:33 2011 |
Jenne | Update | Cameras | Aligned the Xarm, no big deal | Correct. We can see the flashes clearly on our new ETM camera, but we see absolutely nothing on the ITM.
Unfortunately, the camera is in the path of the green beam, so we'll have to figure out a more permanent plan. Right now the laser at the end is shuttered.
Measuring the power now....
Quote: |
Pretty fancy work actually...I wouldn't have guessed that you need to look at the back of the ETM. Does this mean that we can't see the flashes from inside the arm cavity? If so, its a pretty remarkeable statement about the wide angle scatter of the new mirrors. Do we really have 1W going into the MC?
|
|
4119
|
Thu Jan 6 00:03:05 2011 |
Koji | Update | Cameras | Aligned the Xarm, no big deal | Nice, nice! 
The power budget for the FPMI is here. The expected Intracavity power and the transmission are at most ~8W and 100uW, respectively.
|
3804
|
Thu Oct 28 03:21:35 2010 |
Suresh | Update | Locking | Aligned the MC2 transmission photodiode | Yuta and Suresh
The MC2 transmission is seen on the QPD
Once the laser was locked to the cavity, and the PMC was able to follow the laser (ref: elogs by Yuta and Rana today) we had a steady TEMoo mode in the MC. This gave us sufficient transmission through MC2 to be easily visible with an IR viewer and we were able to guide the beam on to the QPD. The beam however seemed to over fill the QPD, a lens (f=180mm) was placed before the beam folding mirror and the spot sized reduced. The the QPD was found to be not fixed to the table and this was also recitified. The signal level is still low: total signal is just about 7 DAQ steps amounting to about 5mV. Tomorrow we plan to work on the alignment of the PSL and MC and thus increase this signal.
A new channel to observe the length variations in the MC.
A long BNC cable was laid from the MC locking electronics next (southwards) to the PSL table to the DAQ cards picking up the signals from the PRM OSEMS. This is to pick up one of the MC locking signals and collect it on a DAQ channel. However as there are no spare DAQ channels currently available one of the PRM OSEM (UL and LL) photodiode channels was unplugged and replaced with the signal from the long BNC cable. For identifying the correct DAQ channel we put in a 2 Vpp 10Hz signal with a function generator into this BNC. Tow signals can be picked up in this fashion and they are available on PRM_LLSEN_IN1 and PRM_ULSEN_IN1. We plan to use this for improving the alignment of the MC tomorrow.
The algorithm for this alignment is that if the beam from the PSL is not centered on the MC1 then tilting MC1 would result in a change in the length of the cavity as seen by the light. Using this as feedback the spot could be precisely centered on the MC1 and then the MC alignment could be completed by moving MC2 and MC3 to reobtain TEM_oo within the cavity. |
2318
|
Mon Nov 23 21:36:38 2009 |
Koji | Update | IOO | Aligned PMC/RC | I aligned the beam goes to PMC. It increased the MC Trans from 8.25 to 8.30.
I also aligned the beam goes to RC.
When I touched the FSS box (wrong: this was the VCO driver) that was close to one of the steering mirror, suddenly the RC trans increased.
It is now 9.8. I am afraid that it gets saturated. I could not reproduce the phenomenon. This could be caused by a bad contact?
Note that I didn't see there is any loose optic. |
Attachment 1: 091123_PSL.png
|
|
10724
|
Mon Nov 17 23:04:51 2014 |
Jenne | Update | PSL | Aligned PMC | I aligned the beam into the PMC, mostly in yaw. Don't know why it drifted, but it was annoying me, so I fixed it. |
8101
|
Mon Feb 18 23:41:15 2013 |
Sendhil | Update | Alignment | Aligned IPPOS, IPANG and OPLEVS | [Yuta, Sendhil]
We aligned IPPOS, IPANG and all OPLEVs (except for ETMX and SRM).
1. First aligned the IPPOS by tweeking the steering mirrors inside the BS chamber.
2. Aligned the IPANG by tweeking the steering mirrors inside the BS chamber and ETMY chamber.
3. Aligned the OPLEVS for the BS and PRM was done by tweeking the steering mirrors inside the BS chamber and checked that OPLEV beams were not clipped.
4. Centred the OPLEV beams for the ITMY and ETMY.
5. For the OPLEV of ITMX the alignment was done by tweeking the steering mirrors inside the ITMX chamber.
|
Attachment 1: IPANGIPPOSoplevs.png
|
|
14151
|
Thu Aug 9 22:50:13 2018 |
gautam | Update | CDS | AlignSoft script modified | After this work of increasing the series resistance on ETMX, there have been numerous occassions where the insufficient misalignment of ETMX has caused problems in locking vertex cavities. Today, I modified the script (located at /opt/rtcds/caltech/c1/medm/MISC/ifoalign/AlignSoft.py) to avoid such problems. The way the misalign script works is to write an offset value to the "TO_COIL" filter bank (accessed via "Output Filters" button on the Suspension master MEDM screen - not the most intuitive place to put an offset but okay). So I just increased the value of this offset from 250 counts to 2500 counts (for ETMX only). I checked that the script works, now when both ETMs are misaligned, the AS55Q signal shows a clean Michelson-like sine wave as it fringes instead of having the arm cavity PDH fringes as well .
Note that the svn doesn't seem to work on the newly upgraded SL7 machines: svn status gives me the following output.
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/cvs/cds/rtcds/userapps/trunk/cds/c1/medm/MISC/ifoalign' is too old (format 10, created by Subversion 1.6)
Is it safe to run 'svn upgrade'? Or is it time to migrate to git.ligo.org/40m/scripts? |
Attachment 1: MichelsonFringing.png
|
|
683
|
Wed Jul 16 16:59:07 2008 |
Alberto | Update | General | Aligment | I think the two beams are aligned again - they both pass the Faraday, they match at the irises and all along the optical path on the AP table. Although the NPRO beam does not show up at the AS port. |
7101
|
Tue Aug 7 11:46:24 2012 |
Jamie | Update | CDS | Alex working on daqd | Alex is apparently working on daqd (remotely). I'll report back when I find out more. |
3836
|
Mon Nov 1 14:53:30 2010 |
josephb, alex, rolf | Update | CDS | Alex updated FB and mx_streams code | Problem:
The framebuilder was being flaky. MX_streams would go down, prevent testpoints from working and so forth.
Solution:
Send Alex up North for a week to fix the code.
Alex came back and installed updates to the frame builder and the mx_streams code (Myrinet Express over Generic Ethernet Hardware) used by the front ends to talk to the frame builder. Instead of 1 stream per model, there's now just 1 per front end handling all communications.
Alex did an SVN update and we now have the latest CDS code.
Self restarting codes:
The frame builder code (daqd) and nds pipe have been added to the fb machine's inittab. Specifically it calls a script called /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab.
The addition to the /etc/inittab file on fb is:
daq:345:respawn:/opt/rtcds/caltech/c1/target/fb/start_daqd.inittab
nds:345:respawn:/opt/rtcds/caltech/c1/target/fb/start_nds.inittab
When these codes die they should automatically restart.
Self starting codes at boot up:
The front ends now start the mx_stream script (which lives in /opt/rtcds/caltech/c1/target/fb/ directory) at boot up. They call it with the approriate command line options for that front end. It can be found in the /etc/rc.local file.
They look like: mx_stream -s "c1x02 c1sus c1mcs c1rms" -d fb:0
As always, the front end codes to be started are defined in the /etc/rtsystab file (or on fb, in the /diskless/root/etc/rtsystab file).
However, if it does go down you would need to restart it manually, although it seems more robust now and doesn't seem to go down every time we restart the frame builder.
All the usual front end IOCs and modules should be started and loaded on boot up as well.
Current CDS status:
MC damp |
dataviewer |
diaggui |
AWG |
c1ioo |
c1sus |
c1iscex |
RFM |
Sim.Plant |
Frame builder |
... |
|
|
|
|
|
|
|
|
|
|
... |
|
1159
|
Mon Nov 24 16:43:34 2008 |
rana | Configuration | Computers | Alex and Jay took away some computers from the racks | I was over at Wilson house and saw Jay and Alex bring in 3 rackmount computers. One was a Sun 4600 and
then there were 2 3U black boxes. I got the impression that these were the data concentrators or
data collectors or framebuilder test boxes. They said that they got these from the 40m and no one was
in the lab to oppose them except for Bob and he didn't put up much of a fight.
Everything looks green on the DAQ Detail and RFM network screens so perhaps everything is OK. Beware. |
4758
|
Sat May 21 17:02:38 2011 |
Koji | Update | Electronics | Alberto's 11MHz was modified to POP55MHz | - Resonant at 55MHz. The transimpedance is 258Ohm. That is about half of REFL55 (don't know why).
- 11MHz&110MHz notch
- The 200MHz oscillation of MAX4106 was damped by the same recipe as REFL11.

|
Attachment 1: POP55_schematic_110520_KA.pdf
|
|
Attachment 2: POP55_transimpedance.pdf
|
|
15634
|
Mon Oct 19 15:40:02 2020 |
Koji | Update | PEM | Alaska EQ M7.5 | Alaska M7.5 20:54UTC https://earthquake.usgs.gov/earthquakes/eventpage/us6000c9hg/executive
I looked at the suspensions. The watchdogs have not been tripped.
IMC was locked but continually shaken. (and occasional unlock) |
1766
|
Tue Jul 21 01:11:30 2009 |
Dmass | AoG | Computers | Alarms going off | I came into the 40m to sign things out briefly then swiftly return them, and the alarms were going off on op540m at 1am.
The cat and donkey? were making much noise. |
14863
|
Fri Sep 6 16:38:24 2019 |
aaron | Update | ALARM | Alarm noise from smart-ups machine under workstation? | There was an alarm sound from the Smart-UPS 2200 sitting under the workstation. I see that the 'replace battery' light is red, and this elog tells me that these batteries are replaced every ~1-4 years; the last replacement was march 2016. Holding down the 'test' button for 2-3 seconds results in the alarm sound and does not clear the replace battery indicator. |
14864
|
Fri Sep 6 18:08:29 2019 |
rana | Update | Computers | Alarm noise from smart-ups machine under workstation? | please no one touch the UPS: last time it destroyed ROSSA. Please ask Chub to order the replacement batteries so we can do this in a controlled way (fully shutting down ALL workstations first). Last time we wasted 8 hours on ROSSA rebuilding.
Quote: |
There was an alarm sound from the Smart-UPS 2200 sitting under the workstation. I see that the 'replace battery' light is red, and this elog tells me that these batteries are replaced every ~1-4 years; the last replacement was march 2016. Holding down the 'test' button for 2-3 seconds results in the alarm sound and does not clear the replace battery indicator.
|
|
644
|
Tue Jul 8 00:14:28 2008 |
John | Summary | Computers | Alarm handler | Rob thought it would be nice to have some alarms on the cpu loads and FE syncs.
I added all these channels to the alarm handler config file and wrote a script
which would set their values (HIHI,HIGH etc).
Ezcawrite allowed me to set the alarm levels (and ezcaread would give the correct
value) but no matter what I set the value to the alarm wouldn't sound.
After experimenting with a few other channels it appears that the alarm handler will
not show alarms if the alarm levels are absent from the db file (even though ezca
gives a value).
I edited the following files so we can have alarms on the cpus.
In c1iscepics:
lsc40m.db
asc40m1.db
In c1losepics:
bs.db
etmx.db
etmy.db
itmx.db
itmy.db
mc1.db
mc2.db
mc3.db
prm.db
srm.db
I saved backups in the appropriate folders.
Next time we have a bootfest please also do c1iscepics and c1losepics so these changes
will be implemented. |
571
|
Thu Jun 26 01:10:18 2008 |
rana | Update | PEM | Alarm Handler indicates that dust level is high | In its first useful act, the Alarm Handler started beeping indicating that the dust particle
counts for particles of diameter less than 0.5 micron had exceeded 5000 /cu. ft. Here's the
80 day trend of particles, temperature and humidity: |
Attachment 1: Untitled.png
|
|
570
|
Thu Jun 26 01:08:22 2008 |
rana | Configuration | General | Alarm Handler Revived | I have revived the Alarm Handler by turning it on on op540m and adjusting the levels of
several of the alarming channels to not alarm (like laser power). The alarm levels are now
set to something reasonable and people should start actually paying attention to them.
I also removed the EO Shutter and Stacis alarm stuff since we don't use them.
To really get in and edit it, you have to close the Alarm Handler and edit the file
in /cvs/cds/caltech/alh/. It allows you to add/subtract useful channels and put in
guidance information.
If the alarm handler beeps about something, don't just close it or silence it, Steve. Just
fix it somehow (either set the threshold better or find the real cause). |
Attachment 1: b.gif
|
|
578
|
Thu Jun 26 20:59:22 2008 |
rana | Update | Computer Scripts / Programs | Alarm Handler | Please do not turn off the Alarm Handler on op540m. |
12411
|
Mon Aug 15 18:28:15 2016 |
gautam | Update | SUS | Air-bake preparation | I assume that we are prepared to live with the pitch bias situation of ETMY (i.e. we can achieve a configuration in which there is some pitch bias to the coils, and the OSEMs are inserted such that the PD outputs are half their maximum value). Or at least that we don't want to go through the whole standoff-regluing procedure for ETMY as well.
So today I took the optic out, and began to make some preparations for the air bake.
- Both optics are now sitting in their respective metal donuts.
- How do we want to bake the optics? Bob has said he has prepared the oven for this bake, and that he has configured the temperature controller to a setpoint of 34C, and a ramp time of 2 hours to reach that temperature from lab temperature (we should check this before putting the optics in there with our independent temperature sensor - also, he is away for the week now so we can't get his input on any of these). But what about the actual logistics of how the optics are going to be housed? Specifically:
- Do we want the donut to sit on some sort of tray? Presumably it is not ideal to have the HR surface in close proximity to the oven floor?
- Does the oven need any special cleaning?
- Do we cover the donut+optic setup with a glass jar? If we do, any particles we eject off the optic can't escape the confines of the bowl, and if we don't, detritus from elsewhere may settle on the optic?
- How long do we want this bake to last? 24hours? 48 hours? Bob didn't have an answer when I asked him earlier in the afternoon...
- I also removed the suspension block from the top of the towers of both ETMX and ETMY, so that Steve could work on sanding them before we acetone-wipe and bake the towers themselves.
- It was very apparent that the weights of the two pieces were largely different (ETMY suspension block ~350g, ETMX suspension block ~960g), even though they have the same physical dimensions.
- Investigation into why this was yielded nothing conclusive. But Steve and I think that the ETMY suspension block is made out of Aluminum rather than SS, which would explain why the wire grooves seem deeper in the ETMY piece than the ETMX piece. It is worth noting that the specification calls for SS and not aluminum. But the top piece of the ETMY suspension (and indeed the old ETMX suspension) looks different from the specification, in that they don't have tapped holes for the secondary wire clamps (see Attachment #1).
- I'm not sure if this is important, but it is worth noting. Steve and I also checked the remaining suspension towers. We think that ITMY, BS, SRM and PRM have the correct (to specification) suspension block. We couldn't get a look at ITMX and didn't want to take the door off. So ETMY (and possibly ITMX) will be the only suspension(s?) with a different suspension block.
- Steve's sanding efforts did not go ideally.
- He was successful in removing the wire grooves.
- But the sharp edge which is supposed to clamp the wire seems to have been rounded a little bit (see Attachment #1).
- Overall, the section that we was sanded looks lower (i.e. its like we've dug a small channel into the plane of the suspension block)
- Given that we suspect the ETMY suspension block is Aluminum, it is likely that attempting to sand it will yield an even deeper channel.
- Do we want to bake the suspension towers in the large baking oven? Presumably we don't want to bake the optics with anything else. But does the large oven need any special cleaning before we stick the towers in there?
- ETMY has some acetone marks on it. I will try and have this removed by drag wiping with more acetone and isopropanol prior to the bake tomorrow. Anyways we will first-contact clean the HR (and AR) sides after the bake before installing the optic.
In summary, the questions that remain (to me) are:
- Are we okay using an Al suspension block?
- How perfectly do we want wire grooves from prior suspensions removed? It looks like sanding doesn't work well, do we want to consider sending this into the shop?
- Baking logistics, as described above.
I think we can start the baking of the optics tomorrow. The timeline for the suspension towers is unclear, depends on how we want to deal with the sanding dilemma. |
Attachment 1: IMG_6816.JPG
|
|
12422
|
Thu Aug 18 14:14:20 2016 |
gautam | Update | SUS | Air-bake of towers - finished | I took the two cages, wires and wire clamps out this morning, back into the cleanroom after their 12 hour 70C bake.
I've also applied first contact to the AR face of the optics. Steve is preparing a jig which will allow us to apply first contact on the HR side with the optic horizontal. The idea is to apply a large coating first, to clean the bulk of the HR surface, and peel it off before re-suspending the optic. Then we can paint on a smaller area, suspend the optic (and hope the pitch balancing is alright) before taking the whole assembly into the chamber where it will be peeled off.
Calum recommended that we buy a new ionizing gun + electrometer assembly (apparently our current set up is woefully obsolete) but I don't know if we can have these in time for the first contact peeling... |
12420
|
Wed Aug 17 23:00:57 2016 |
gautam | Update | SUS | Air-bake of towers | I just put in the following into the air bake oven for a 12 hour, 70C bake:
- ETMX and ETMY cages (with sanded suspension blocks loosely tightened for now, we will tighten them after the bake)
- 13 new wire clamps that were recently made by the shop
- 7 lengths of suspension wire (since the new wire is unlikely to arrive for another 2 weeks). This should be sufficient in case we overtighten the wire clamps a couple of times and the wire snaps.
I put these in at 10.30pm. So the oven will be turned off at 10.30am tomorrow morning. The oven temperature seems stable in the region 70-80 C (there is no temperature control except for the in built oven control, I just adjusted the dial till I found the oven remains at ~70C.
Tomorrow, we will look to put on first contact onto the ETMs, and then get about to re-suspending them. |
Attachment 1: IMG_3006.JPG
|
|
12416
|
Wed Aug 17 08:47:43 2016 |
ericq | Update | SUS | Air-bake finished | I turned off the air bake oven at 8:45AM. I'll leave the optics alone for a bit while it cools. |
12415
|
Tue Aug 16 21:54:27 2016 |
gautam | Update | SUS | Air-bake - IN PROGRESS | I put in both ETMX and ETMY into the air-bake oven at approximately 8.45pm tonight. They can be removed at 8.45am tomorrow morning.
- Given that we had previously melted a thermocouple in this oven, and there have been no high temperature bakes in it since, we ran the oven at 100C for about 3 hours in the afternoon
- After that, I left the oven door open for an hour for the interior to return to room temperature
- I then re-connected the controller (which doesn't seem very precise, it pulses the AC power to the oven in order to control the temperature), and dialled the oven back down to heating level 4, which is what Bob had it set at. I then waited for a couple of hours for the oven to reach ~34C
- Before putting the optics in, I gave the inside of the oven a quick wipe with a clean wipe, and palced a layer of Al foil on the bottom of the oven
- The optics are sitting on their donuts (see Attachment #1) - the copper wire elevates the optic+donut slightly and provides a path for air flow
- ETMY was drag wiped with acetone+isopropanol prior to baking (to remove acetone stains from soaking to remove epoxy residue
- We will of course be cleaning the optics with first contact prior to re-installation in the vacuum chambers
- I am not sure what the extra cylindrical piece in there is, but Bob advised me to leave it in there so that's what I did
- I've observed the temperature over ~2hours since I first put it in, and the oven/controller isn't going bonkers, so I'm trusting the controller and leaving for the night
|
Attachment 1: IMG_3005.JPG
|
|
11928
|
Tue Jan 12 08:40:06 2016 |
Steve | Update | PEM | Air cond maintenance | Air condition maintenance is happening. It should be done by 10am |
14572
|
Thu Apr 25 10:13:15 2019 |
Chub | Update | General | Air Handler Out of Commission | The air handler on the roof of the 40M that supplies the electronics shop and computer room is out of operation until next week. Adding insult to injury, there is a strong odor of Liquid Wrench oil (a creeping oil for loosening stuck bolts that has a solvent additive) in the building. If you don't truly need to be in the 40M, you may want to wait until the environment is back to being cool and "unscented". On a positive note, we should have a quieter environment soon! |
|