40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 25 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  17169   Mon Oct 3 08:35:59 2022 TegaUpdateIMCAdding IMC channels to frames for NN test

[Rana]

For the upcoming NN test on the IMC, we need to add some more channels to the frames. Can someone please add the MC2 TRANS SUM, PIT, YAW at 256 Hz? and then make sure they're in frames.

and even though its not working correctly, it would be good if someone can turn the MC WFS on for a little while. I'd just like to get some data to test some code. If its easy to roughly close the loops, that would be helpful too.


[Anchal]

Currently, none of these channels are being written on frames. From simulink model, it seems the channels:

  • C1:IOO-MC_TRANS_SUMFILT_OUT_DQ

  • C1:IOO-MC_TRANS_PIT_OUT_DQ

  • C1:IOO-MC_TRANS_YAW_OUT_DQ

are supposed to be DQed but are not present in the /opt/rtcds/caltech/c1/chans/daq/C1MCS.ini file. I tried simply adding these channels to the file and rerunning the daqd_ services but that caused 0x2000 error on c1mcs model. In my attempt, I did not know what chnnum to give for these channels so I omitted that and maybe that is the issue.

The only way I know to fix this is to make and install c1mcs model again which would bring these channels into C1MCS.ini file. But We'll have to run activateDQ.py if we do that which I am not totally sure if it is in running condition right now. @Christopher Wipf do you have any suggestions?


[Rana]

aren't they all filtered? If so, perhaps we can choose whatever is the equivalent naming at the LIGO sites rather than roll our own again.

@Tega Edo can we run activateDQ.py or will that break everything now?


[Tega]

@Rana Adhikari Looking into this now.

@Anchal Gupta The only problem I see with activateDQ.py is the use of the deprecated print function, i.e. print var instead of print(var). After fixing that, it runs OK and does not change the input INI files as they already have the required channel names. I have created a temporary folder, /opt/rtcds/caltech/c1/chans/daq/activateDQtests/, which is populated with copies of the original INI files, a modified version of activateDQ.py that does not overwrite the original input files, and a script file difftest.sh that compares the input and output files so we can test the functionality of activateDQ.py in isolation. Furthermore, looking through the code suggests that all is well. Can you look at what I have done to check that this is indeed the case? If so, your suggestion of rebuilding and installing the updated c1mcs model and running activateDQ.py afterward should do the trick.

I tested the code with:

cd /opt/rtcds/caltech/c1/chans/daq/activateDQtests/

./activateDQ.py

which creates output files with an _ prefix, for example _C1MCS.ini is the output file for C1MCS.ini, then I ran

./difftest

to compare all the input and corresponding output files.

Note that the channel names you are proposing would change after running activateDQ.py, i.e.

C1:IOO-MC_TRANS_SUMFILT_OUT_DQ -> C1:IOO-MC_TRANS_SUM_ERR

C1:IOO-MC_TRANS_PIT_OUT_DQ -> C1:IOO-MC_TRANS_PIT_ERR

C1:IOO-MC_TRANS_YAW_OUT_DQ -> C1:IOO-MC_TRANS_YAW_ERR

My question is this: why aren't we using the correct channel names in the first place so that we have less work to do later on when we finally decide to stop using this postbuild script?


[Anchal]

Yeah I found that these ERR channels are acquired and stored. I don't think we should do this either. Not sure what was the original motivation for this change. I tried commenting out this part of activateDQ.py and remaking and reinstalled c1mcs but it seems that activateDQ.py is called as postbuild script automatically on install and it uses some other copy of this file as my changes did not take affect and the DQ name change still happened.


[Tega]

Ah, we encountered the same puzzle as well. Chris found out that our models have `SCRIPT=activateDQ.py` embedded in the cds parameter block description, see attached image. We believe this is what triggers the postbuild script call to `activateDQ.py`. As for the file location, modern rtcds would have it in /opt/rtcds/caltech/c1/post_build, but I am not sure where ours is located. I did a quick search for this but could not find it in the usual place so I looked around for a bit and found this:

controls@rossa> find /opt/rtcds/userapps/ -name "activateDQ.py"

/opt/rtcds/userapps/trunk.bak/cds/c1/scripts/activateDQ.py

/opt/rtcds/userapps/tags/H2OAT_RCG2.5.1/cds/c1/scripts/activateDQ.py

/opt/rtcds/userapps/branches/StanfordGuardianDev/cds/c1/scripts/activateDQ.py

/opt/rtcds/userapps/branches/branch-2.3/cds/c1/scripts/activateDQ.py

/opt/rtcds/userapps/branches/branch-2.4/cds/c1/scripts/activateDQ.py

/opt/rtcds/userapps/trunk/cds/c1/scripts/activateDQ.py

My guess is the last one /opt/rtcds/userapps/trunk/cds/c1/scripts/activateDQ.py.

Maybe we can ask @Yuta Michimura since he wrote this script?

Anyway, we could also try removing SCRIPT=activateDQ.py from the cds parameter block description to see if that stops the postbuild script call, but keep in mind that doing so would also stop the update of the OSEM and oplev channel names. This way we know what script is being used since we will have to run it after every install (this is a bad idea).

controls@c1sus:~ 0$ env | grep script

CDS_SCRIPTS_PATH=:/opt/rtcds/userapps/release/cds/c1/scripts:/opt/rtcds/userapps/release/cds/common/scripts:/opt/rtcds/userapps/release/isc/c1/scripts:/opt/rtcds/userapps/release/isc/common/scripts:/opt/rtcds/userapps/release/sus/c1/scripts:/opt/rtcds/userapps/release/sus/common/scripts

It looks like the guess was correct. Note that in the newer version of rtcds, we can use `rtcds env` instead of `env` to see what is going on.

Attachment 1: Screen_Shot_2022-09-30_at_9.52.39_AM.png
Screen_Shot_2022-09-30_at_9.52.39_AM.png
  16802   Fri Apr 22 07:01:58 2022 JcUpdateCoil DriversAdding Resistors and Reinstalling

[Koji, JC]

Coil Drivers LO2, SR2, AS4, and AS1 have been updated a reinstalled into the system. 

LO2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3        Unit: S2100008

LO2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3                    Unit: S2100530

SR2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3        Unit: S2100614

SR2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3                    Unit: S2100615

AS1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3        Unit: S2100610

AS1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3                    Unit: S2100611

AS4 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3        Unit: S2100612

AS4 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3                    Unit: S2100613

Attachment 1: IMG_0536.jpeg
IMG_0536.jpeg
Attachment 2: IMG_0539.jpeg
IMG_0539.jpeg
Attachment 3: IMG_0542.jpeg
IMG_0542.jpeg
Attachment 4: IMG_0545.jpeg
IMG_0545.jpeg
Attachment 5: IMG_0548.jpeg
IMG_0548.jpeg
Attachment 6: IMG_0551.jpeg
IMG_0551.jpeg
Attachment 7: IMG_0554.jpeg
IMG_0554.jpeg
Attachment 8: IMG_0557.jpeg
IMG_0557.jpeg
  10130   Sat Jul 5 04:18:45 2014 AndresUpdate40m Xend Table upgradeAdding Two Lenses After the Second Steering Mirror in Order Two Increase the Gouy Phase Difference Between the Sterring Mirrors

I had been working on the Xend table optical layout update. Since the two steering mirrors in the Xend green are too close to each, there is a very small Gouy Phase different between these two mirrors. It was suggested to place two lenses so that we can increase the Gouy Phase. I have been working with Nick on this problem, and we had found a solution by using a la mode. We had written an a la mode code that optimize the Gouy Phase and the Mode Matching at the same time. After trying different lenses, we found the following results: a mode matching of 0.9939 as it is show in the first attachment below, and we found a Gouy Phase different between the two mirrors of about 60 degrees. I took photos of the Xend Table. The first photo is the Xend table as we had it right now. In the second photo, I moved the 2nd lens, and I placed the two more lenses that we need it, with more or lenses the correct position where they will be placed. The three old lenses will be replaced by three lenses of different focal length as it can be seen in the first attachment below. The first lens and third lens will stay in the same position where the old first lens and old third lens are, and the second lens will be moved by about half of an inch. We might have one or two of the lenses that we need, but we will have to order the rest of the lenses that need. My plan is to verify the lenses that we already have. Then, I need to let Nick know with lenses we need to order. Hopefully, we will be able to update the table by the end of this week if everything turn out fine.

Attachment 1: OverlapAndComponentsOfTheSolution.png
OverlapAndComponentsOfTheSolution.png
Attachment 2: CloseLookToTheGouyPhaseBetweenMirr1AndMirr2.jpg
CloseLookToTheGouyPhaseBetweenMirr1AndMirr2.jpg
Attachment 3: EntireRangeOfBeamPath.jpg
EntireRangeOfBeamPath.jpg
Attachment 4: XendTableWithTwoNeedLensesAdding.JPG
XendTableWithTwoNeedLensesAdding.JPG
Attachment 5: SchematicOfSolutionForTheLensesGouyPhase.jpeg
SchematicOfSolutionForTheLensesGouyPhase.jpeg
Attachment 6: XendGreenModeMatchingAndGouyPhaseOptimization.m
clear all
% In this code we are using a la mode to optimatize the mode matching and
% to optimatize the Gouy phase between mirror 1 and mirror 2. All the units
% are in meter

w0=2.943*1e-5; % The Waist of the laser measured before the faraday
z0_laser=-0.039; % position measured where the waist is located 
lamb= 532*10^-9; % wavelength of green light in mm
lFaraday=.0638; % Length of the faraday

... 148 more lines ...
Attachment 7: BeforeIncludingLensesORMovingLenses.JPG
BeforeIncludingLensesORMovingLenses.JPG
  14074   Mon Jul 16 18:12:00 2018 KojiUpdateVACAdding a manual gate valve between TP1 and V1/VM2

[Steve Koji]

We are in the process of adding a manual gate valve between TP1 (Osaka Maglev) and the other gate valves (I suppose V1 and VM2).
The work is still on going and we will continue to work on this tomorrow. Because this section is isolated from the main volume, this work does not hold off the possible rough pumping tomorrow morning.

The motivation of this work is as follows:
- Since TP2 failed, the main vacuum volume has been pumped down by TP1 and TP3. However TP3 is not capable to handle the large pressure difference at the early stage of the turbo pumping. This cause TP3 to have excessive heating or even thermal shutdown.
- The remedy is to put a gate valve between TPs and the main vacuum to limit the amount of gas flowing into the TPs. This indeed slows down the pumping speed of turbo, but this is not the dominant part of the pumping time.

Actual work:
- Comfirmed TP1 is isolated.
- Unscrewed the flange of TP1.
- Remove TP1. This required to lift up TP1 with some shim as the nuts interferes with the TP1 body. (Attachment1, 2, 3)
- Now remove 10inch flange adapter. (Attachment4)
-
Attach 10"-8" adapter and 8" rotational sleeve. (Attachment5)

Attachment 1: P_20180716_155413.jpg
P_20180716_155413.jpg
Attachment 2: P_20180716_155645.jpg
P_20180716_155645.jpg
Attachment 3: P_20180716_155738.jpg
P_20180716_155738.jpg
Attachment 4: P_20180716_162307.jpg
P_20180716_162307.jpg
Attachment 5: P_20180716_172000.jpg
P_20180716_172000.jpg
  4271   Thu Feb 10 14:52:36 2011 AidanHowToComputersAdding filenames in MATLAB plots

The following code is incredibly useful when creating  MATLAB plots as it adds the filename of the script to the plot itself. I think it should be used for all MATLAB plots that go on the elog.

For example, I have no idea where the data/script is that was used to generate these plots.

 

orient landscape

xposn = 0.0;

yposn = -0.13; % you sometimes have to tweak this value depending on the page size and the number of subplots

text(xposn,yposn,[filename('fullpath'), '.m'], ...

     'Units', 'normalized', ...

     'Interpreter', 'none', ...

     'FontSize', 6)

print('-dpdf', [filename('fullpath'), '.pdf'])

  9430   Wed Nov 27 18:31:26 2013 KojiSummaryLSCAdittion of the ALS error signals to the LSC input matrix

The Phase tracker outputs (= ALS X/Y error signals) are now conveyed to the LSC model.

Their entry points at the LSC model are C1:LSC-ALSX_IN1 and C1:LSC-ALSY_IN1.
They are connected to the signal matrix (28th and 29th signals) via signal conditioning filters (C1:LSC-ALSX and C1:LSC-ALSY).

The main LSC screen has not been updated. The conventional ALS servos are still remains as they were.

This renovation required the recompilation of c1als, c1rfm, and c1lsc. Two PCIe-RFM bridge paths were added resulting in
increase of the c1rfm timing budget from 38 to 44.

  6409   Wed Mar 14 03:34:44 2012 kiwamuUpdateSUSAdjustment of BS suspension output matrix : coupling from SIDE to POS

[Rana / Kiwamu]

 We put some elements in the BS output matrix to mitigate the actuator coupling from SIDE to POS.

As a result the degree of the coupling reduced by a factor of 2 or so.

Rana did the "Q of 5" test on the SIDE damping servo after putting the elements and set the gain to be 40.

 

The attached screen shot is the new elements that we put in the suspension output matrix.

Untitled.png

 

(How to)

  • Excite the SIDE motion by AWG at 3 Hz.
  • Monitor the POS signal in DTT
  • Try some numbers in the matrix elements until the peak at 3 Hz in the POS signal is minimized

Quote from #6369

The BS SIDE damping gain seemed too low. The gain had been 5 while the rest of the suspensions had gains of 90-500.

I increased the gain and set it to be 80.

 

I did the "Q of 5" test by kicking the BS SIDE motion to find the right gain value.

However there was a big cross coupling, which was most likely a coupling from the SIDE actuator to the POS motion.

Due to the cross coupling, the Q of 5 test didn't really show a nice ring down time series. I just put a gain of 80 to let the Q value sort of 5.

I think we should diagonalize the out matrices for all the suspensions at some point.

 

  5288   Tue Aug 23 14:49:14 2011 jamie, jenne, kiwamu, suresh, keikoUpdateSUSAdjustment of ETMY, issue with ITMY whitening

Before lunch we took a closer look at two of the suspensions that were most problematic: ITMY and ETMY.  Over lunch we took new free swinging data.  Results below:

  • For ITMY we discovered that the whitening on the UL sensor was not switching.  This was causing the UL sensor to have a different response, with a steeper roll of, which was causing all of the transfer function estimates to the other sensors to have large imaginary components.   We took new free swing data with all of the whitening turned OFF.  The result is a much improved matrix and diagnalization.  The input matrix elements are mostly the same, but the coupling is basically gone.  We'll fix the whitening after the pump down.
ITMY ITMY.png       pit     yaw     pos     side    butt
UL    0.157   1.311   1.213  -0.090   0.956 
UR    1.749  -0.490   0.886  -0.038  -1.042 
LR   -0.251  -2.000   0.787  -0.007   1.066 
LL   -1.843  -0.199   1.114  -0.059  -0.936 
SD   -0.973  -0.205   1.428   1.000   0.239 
4.34779
  • ETMY has a very problematic SIDE OSEM.  The magnet does not line up with the OSEM axis, and since there is no lateral adjustment in the side OSEMs, there's not much we can do about this.  We're using aluminum foil to wedge the OSEM over as far as possible, but it's not quite enough.  With the OSEM plates horizontal there is a lot of POS->SIDE coupling.  With the OSEM plates vertical, the magnetic sits a little too close to the rear face, which can cause the magnet to get stuck to the LED plate.  We're trying to decide where to leave it now, but the new diagnalization with the OSEM plates vertical is definitely better: 
ETMX ETMY.png        pit     yaw     pos     side    butt
UL   -0.138   1.224   1.463  -0.086   0.944  
UR    0.867  -0.776   1.501  -0.072  -1.051  
LR   -0.995  -0.896   0.537  -0.045   0.754  
LL   -2.000   1.104   0.499  -0.059  -1.251  
SD    0.011   0.220   1.917   1.000   0.224 
 4.42482
  7901   Tue Jan 15 19:26:35 2013 jamieUpdateAlignmentAdjustment of active TTs and input alignment

[Jamie, Manasa, Jenne]

We started by verifying that the tip-tilts were getting the correct signals at the correct coils, and were hanging properly without touching.

We started with TT2.  It was not hanging freely.  One of the coils was in much further than the others, and the mirror frame was basically sitting on the back side yaw dampers.  I backed out the coil to match the others, and backed off all of the dampers, both in back and the corner dampers on the front.

Once the mirror was freely suspended, we borrowed the BS oplev to verify that the mirror was hanging vertically.  I adjusted the adjustment screw on the bottom of the frame to make it level.  Once that was done, we verified our EPICS control.  We finally figured out that some of the coils have polarity flipped relative to the others, which is why we were seeing pitch as yaw and vice-versa.  At that point we were satisfied with how TT2 was hanging, and went back to TT1.

Given how hard it is to look at TT1, I just made sure all the dampers were backed out and touched the mirror frame to verify that it was freely swinging.  I leveled TT1 with the lower frame adjustment screw by looking at the spot position on MMT1.  Once it was level, we adjusted the EPICS biases in yaw to get it centered in yaw on MMT1.

I then adjusted the screws on MMT1 to get the beam centered at MMT2, and did the same at MMT2 to get the beam centered vertically at TT2.

I put the target at PRM and the double target at BS.  I loosened TT2 from it's base so that I could push it around a bit.  Once I had it in a reasonable position, with a beam coming out at PR3, I adjusted MMT1 to get the beam centered through the PRM target.  I went back and checked that we were still centered at MMT1.  We then adjusted the pitch and yaw of TT2 to get the transmitted beam through the BS targets as clear as possible.

At this point we stopped and closed up.  Tomorrow first thing AM we'll get our beams at the ETMs, try to finalize the input alignment, and see if we can do some in-air locking.

The plan is still to close up at the end of the week.

  7902   Tue Jan 15 20:00:42 2013 ManasaUpdateAlignmentAdjustment of active TTs and input alignment

 

Just for reference! The changes made to the TT matrix in order to fix the polarity problem:

The old matrix values are mentioned in elog!

 

PIT    YAW                   New                   

Pit slider           |  -100   -100  |  UL  

     0               | -100    100   |  LL

Yaw slider           |  100   -100   |  UR

    0                |  100    100   |  LR

 

 

 

 

 

 

 

  4580   Thu Apr 28 10:53:50 2011 josephbUpdateCDSAdventures in Hyper-threading

What was done:

1) Turn off MC1, MC2, MC3, BS, ITMX, ITMY, PRM, SRM watchdogs.

2) Turn c1sus computer off (sudo shutdown now)

3) Go connect monitor and keyboard to c1sus.  Turn c1sus on.

4) Hit "del" key at the right time to go to setup (BIOS).

5) Go to BIOS advanced tab, CPU options, enable Multi-threading.

6) Hit F10 to save and let the computer continue booting.

What went wrong:

Once c1sus was up, I noticed several red lights and dead keep alives for the c1sus models.

Typing dmesg on c1sus revealed many messages like:

[  107.583420] c1x02: cycle 33737 time 20; adcWait 10; write1 0; write2 0; longest write2 0
[  107.583771] c1x02: cycle 33760 time 19; adcWait 11; write1 0; write2 0; longest write2 0

This indicates the Input/Output Processor (IOP) is not completing its duties within the 15 microseconds (1/64 kHz) that it has.  These lines indicate its take 20 or 19 microseconds.  (I saw messages ranging from 16 to 22 microseconds).

So this seems to agree with Rolf's observations that hyperthreading can cause a 5-10 microsecond increase in computation time.

So the next thing to do is modify which core the codes are running on, and try to get them paired up on the same physical core.

  811   Thu Aug 7 17:32:23 2008 JenneUpdateSUSAfternoon PRM activities
Rana, Jenne, Yoichi, Dmass

After Yoichi confirmed this morning that the wire was in both grooves, Rana attempted to lift the PRM a tiny bit, and twist it around (very gently of course) to see if we could make the wire slip back to its nominal position underneath the optic. On the first attempt, the wire ended up slipping the wrong way, causing slightly more tilt. On another attempt, the wire came out of the groove nearest the chamber door by about 0.5mm. We got the wire back in the groove by slightly lifting the optic, and pushing the wire back in. Then, on further attempts at making the wire slip back to its nominal position, the wire came out of the groove farthest from the chamber door. It is very difficult to get at that side of the PRM, because the table is crowded, and it is on the far side of the optical table from the chamber door. We decided to pull the PRM out of the chamber. Rana clamped the mirror into its cage using the earthquake stops and removed the OSEMS, and then we pulled the mirror out. We put it on a cart that was covered with foil and had a little foil house for the optic cage. We rolled the mirror+cage over to the flow bench at the end of the y-arm.

We saw that the wire is no longer even on the standoff (~3mm away from the groove) on the side that was farthest from the chamber door.

Since we have not confirmed that we have spare wire and spare magnets (and due to the time of day), we have decided to cover the cage with some foil, while it is sitting on the flow bench, and we'll fix the wire in the morning.
  5977   Tue Nov 22 14:39:50 2011 JenneUpdateelogAfternoon elog restart

Gave the elog its afternoon / tea-time reboot, since it was hanging yet again.

  5343   Tue Sep 6 11:27:19 2011 JenneUpdateGeneralAfternoon pre-pumpdown todo list

These are the things that I can think of that we need to do before we can close up:

* Take a close look at both ITMs' OSEMs, and ensure that the magnets aren't too close to either plate in the OSEMs.  Both have had funny business over the past week.

* Do a free swinging test on both ITMs.  (ITMY may not need it, if we haven't touched it since the last free swinging test, but it can't hurt to take the data)

* Confirm that POX is exiting the chamber.

* Is there anything else???

 

Our goal is to finish this work by tonight, so that we can close doors and start pumping tomorrow.

  138   Thu Nov 29 10:36:47 2007 albertoConfigurationComputer Scripts / ProgramsAgilent 82357B GPIB to USB Interface Installation Procedeure
To run the Agilent Automation-Ready CD provided with the interface is only the first step of the installation. Apparently there should be also a second CD with the drivers for Windows XP but I couldn't find it. So, after Installaing the IO Libraries Suite from the CD, I had to install the drivers with an executable downloaded from the Agilent's website at:

http://www.home.agilent.com/agilent/editorial.jspx?cc=US&lc=eng&ckey=1188958&nid=-35199.0.00&id=1188958

and only then I could plug in the interface.
Anyway, I burned a cd with the file and put it together with the other one.
  14322   Tue Nov 27 17:06:51 2018 SteveConfigurationVACAgilent 84FS turbo installed as TP2

Chub & Steve,

We swapped in our  replacement of Varian V70D "bear-can" turbo as factory clean.

The new Agilent TwisTorr 84 FS  turbo pump [ model x3502-64002,  sn IT17346059 ]  with intake screen, fan, vent valve. The controller  [ model 3508-64001, sn IT1737C383 ] and a larger drypump IDP-7,  [ model x3807-64010, sn MY17170019 ] was installed.

Next things to do:

  1. implement hardware interlock to close V4 at 80% pumping speed slowdown of "standby" rotation speed, estimated to be ~ 40,000 RPM ( when Standby 50K RPM  )
  2. set up isolation valve in the foreline of TP2, with delayed start of the IDP-7 and/or use relay to power drypump.  This turbo controller can not switch off or start of the dry pump. [ Agilent isolation valve #X3202-60055, with position indicator, pneumatic actuation, 115V solenoid ]..........as a second thought, we do not need isolation valve if we go with the relay option. The IDP-7 has built in delay of 10-15 sec
  3. test performance of new turbo
  15681   Wed Nov 18 17:51:50 2020 gautamUpdateVACAgilent pressure gauge controller delivered

It is stored along with the cables that arrived a few weeks ago, awaiting the gauges which are now expected next week sometime.

  16898   Tue Jun 7 19:13:12 2022 yutaUpdateSUSAgreement on suspension damping loop polarity conventions

Anchal, Paco and I agreed to follow the polarity conventions below for suspension damping loops.
Some of the polarity/gains were changed to homogenize all the suspensions to the convention.
All the suspensions are homogenized except for MC1 (which have all - in sensor inputs and all - in coil outputs) and AS1 (SDCOIL_GAIN have the same sign as LL).


*SEN_GAIN to be +1
INMATRIX to be the following, and calibrated so that SUSPOS/SIDE_IN will be um and SUSPIT/YAW_IN1 will be urad (calibration to be done later)
+ + + + *
+ + - - *
+ - - + *
* * * * +
SUS*_GAINS to be +

TO_COIL gains to be the following
+1 +1 +1  *
+1 +1 -1  *
+1 -1 +1  *
+1 -1 -1  *
 *  *  * +4
*COIL_GAIN to be the following or flipped one so that SUS*_GAINS will be +
+
-
+
-
+

To do this, the following changes were made

For BS, ITMX, ITMY, PRM, SRM, ETMX, ETMY, MC1, MC2 and MC3 ("old" suspensions), TO_COIL_5_4_GAIN (for side) is changed from +1 to +4 and SUSSIDE_GAINs are divided by 4 accordingly.
For ETMX, the sign of SUSSIDE_GAIN is flipped to +, and SDCOIL_GAIN to be -1 (it was +1).
For MC1, *SEN_GAINs are - (not following the convension; see 40m/16894). The sign of INMATRIX_4_5 (for side) is flipped to +, SUSPOS/PIT/YAW_GAIN are flipped to +, and *COIL_GAIN are flipped to - (not following the convension). IMC WFS output matrix components for MC1 were also flipped. 

Attachment 1: NoteBeforeChanges.JPG
NoteBeforeChanges.JPG
  14572   Thu Apr 25 10:13:15 2019 ChubUpdateGeneralAir 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!

  11928   Tue Jan 12 08:40:06 2016 SteveUpdatePEMAir cond maintenance

Air condition maintenance is happening. It should be done by 10am

  12415   Tue Aug 16 21:54:27 2016 gautamUpdateSUSAir-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
IMG_3005.JPG
  12416   Wed Aug 17 08:47:43 2016 ericqUpdateSUSAir-bake finished

I turned off the air bake oven at 8:45AM. I'll leave the optics alone for a bit while it cools.

  12420   Wed Aug 17 23:00:57 2016 gautamUpdateSUSAir-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
IMG_3006.JPG
  12422   Thu Aug 18 14:14:20 2016 gautamUpdateSUSAir-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...

  12411   Mon Aug 15 18:28:15 2016 gautamUpdateSUSAir-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:

  1. Are we okay using an Al suspension block?
  2. 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?
  3. 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
IMG_6816.JPG
  578   Thu Jun 26 20:59:22 2008 ranaUpdateComputer Scripts / ProgramsAlarm Handler
Please do not turn off the Alarm Handler on op540m.
  570   Thu Jun 26 01:08:22 2008 ranaConfigurationGeneralAlarm 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
b.gif
  571   Thu Jun 26 01:10:18 2008 ranaUpdatePEMAlarm 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
Untitled.png
  644   Tue Jul 8 00:14:28 2008 JohnSummaryComputersAlarm 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.
  14863   Fri Sep 6 16:38:24 2019 aaronUpdateALARMAlarm 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 ranaUpdateComputersAlarm 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.

  1766   Tue Jul 21 01:11:30 2009 DmassAoGComputersAlarms 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.

  15634   Mon Oct 19 15:40:02 2020 KojiUpdatePEMAlaska 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)

  4758   Sat May 21 17:02:38 2011 KojiUpdateElectronicsAlberto'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.

POP55_transimpedance.pdf

 

Attachment 1: POP55_schematic_110520_KA.pdf
POP55_schematic_110520_KA.pdf POP55_schematic_110520_KA.pdf
Attachment 2: POP55_transimpedance.pdf
POP55_transimpedance.pdf
  1159   Mon Nov 24 16:43:34 2008 ranaConfigurationComputersAlex 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.
  3836   Mon Nov 1 14:53:30 2010 josephb, alex, rolfUpdateCDSAlex 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  ...
                     ... 
  7101   Tue Aug 7 11:46:24 2012 JamieUpdateCDSAlex working on daqd

Alex is apparently working on daqd (remotely).  I'll report back when I find out more.

  683   Wed Jul 16 16:59:07 2008 AlbertoUpdateGeneralAligment
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.
  14151   Thu Aug 9 22:50:13 2018 gautamUpdateCDSAlignSoft 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 yes.

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
MichelsonFringing.png
  8101   Mon Feb 18 23:41:15 2013 SendhilUpdateAlignmentAligned 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
IPANGIPPOSoplevs.png
  10724   Mon Nov 17 23:04:51 2014 JenneUpdatePSLAligned 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.

  2318   Mon Nov 23 21:36:38 2009 KojiUpdateIOOAligned 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
091123_PSL.png
  3804   Thu Oct 28 03:21:35 2010 SureshUpdateLockingAligned 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.

  4116   Wed Jan 5 23:22:00 2011 JenneUpdateCamerasAligned 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:

DSC_2822.JPG

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

KiwamuJenne_5Jan2011_Xarm_Aligned.png

  4117   Wed Jan 5 23:37:12 2011 ranaUpdateCamerasAligned 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 JenneUpdateCamerasAligned 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 KojiUpdateCamerasAligned 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.

 

  7579   Fri Oct 19 01:21:42 2012 EvanUpdateLockingAligning 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. 

  5182   Thu Aug 11 04:45:07 2011 SureshUpdateIOOAligning 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.

FI_input_spot.jpg

 

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.

  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
ELOG V3.1.3-