40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 103 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  4477   Thu Mar 31 15:23:14 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Quote:

3. Zoomed-in plot for the SHG crystal show no astigmatism. However, the zoomed out plot shows some astigmatism.

How consistent are they? ==> Interested in seeing the fit including the zoomed out measurements.

Right. Fitting to the data. Zoomed out plots first. I used the general equation f(x) = w_o.*sqrt(1 + (((x-z_o)*1064e-9)./(pi*w_o.^2)).^2)+c for each fit which is basically just the Gaussian beam width parameter calculation but with an extra offset parameter 'c'

Vertical fit for zoomed out data:

Coefficients (with 95% confidence bounds):

       c =   7.542e-06  (5.161e-06, 9.923e-06)

       w_o =   3.831e-05  (3.797e-05, 3.866e-05)

       z_o =       1.045  (1.045, 1.046)

 

Goodness of fit:

  SSE: 1.236e-09

  R-square: 0.9994

 
Horizontal fit for zoomed out data:
 

Coefficients (with 95% confidence bounds):

       c =   1.083e-05  (9.701e-06, 1.195e-05)

       w_o =   4.523e-05  (4.5e-05, 4.546e-05)

       z_o =       1.046  (1.046, 1.046)

 

Goodness of fit:

  SSE: 2.884e-10

  R-square: 0.9998

  Adjusted R-square: 0.9998

  RMSE: 2.956e-06

 

Zoomed_out_fitting01.png

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 

OK. Looking at the plots and residuals for this, the deviation of the fit around the waist position, and in fact all over, looks to be of the order 10um. A bit large but is it real? Both w_o values are a bit lower than the 50um we'd like, but… let's check using only the zoomed in data -  hopefully more consistent since it was all taken with the same power setting.

 

 

Vertical data fit using only the zoomed in data:

 

Coefficients (with 95% confidence bounds):

       c =   1.023e-05  (9.487e-06, 1.098e-05)

       w_o =   4.313e-05  (4.252e-05, 4.374e-05)

       z_o =       1.046  (1.046, 1.046)

 

Goodness of fit:

  SSE: 9.583e-11

  R-square: 0.997

 

Horizontal data fit using only the zoomed in data:

 

Coefficients (with 95% confidence bounds):

       c =   1.031e-05  (9.418e-06, 1.121e-05)

       w_o =    4.41e-05  (4.332e-05, 4.489e-05)

       z_o =       1.046  (1.046, 1.046)

 

Goodness of fit:

  SSE: 1.434e-10

  R-square: 0.9951

 

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Zoomed_in_fitting01.png

 

The waists are both fairly similar this time 43.13um and 44.1um and the offsets are similar too  - residuals are only spread by about 4um this time.

 

I'm inclined to trust the zoomed in measurement more due to the fact that all the data was obtained under the same conditions, but either way, the fitted waist is a bit smaller than the 50um we'd like to see. Think it's worthwhile moving the 62.9mm lens back along the bench by about 3/4 -> 1cm to increase the waist size.

 

 

 

 

 

  4485   Mon Apr 4 14:20:32 2011 BryanConfigurationGreen LockingThe wonderful world of mode-matching

Last bit of oven matching for now.

 

I moved the lens before the oven position back along the beam path by about 1cm - waist should be just above position 9 in this case. Note - due to power-findings from previous time I'm maximising the power into the head to reduce the effect of offsets.

 

From position 9:

Position A1_13.5%_width A2_13.5%_width

(mm) (um mean) (um mean)

-1 121.1 123.6

0 112.5 113.8

1 106.4 106.1

2 102.9 103.4

3 103.6 103.6

4 106.6 107.4

5 111.8 112.5

6 118.2 120.1

7 126.3 128.8

8 134.4 137.1

9 143.8 146.5

10 152.8 156.1

11 163.8 167.1

12 175.1 176.4

13 186.5 187.0

14 197.1 198.4

15 210.3 208.9

16 223.5 218.7

17 237.3 231.0

18 250.2 243.9

19 262.8 255.4

20 274.7 269.0

21 290.4 282.3

22 304.3 295.5

23 316.7 303.1

 

Note - had to reduce power due to peak saturation at 15mm - don't think scale changed, but be aware just in case. And saturated again at 11. And again at 7. A little bit of power adjustment each time to make sure the Beamscan head wasn't saturating. Running the fit gives...

 

Waist_Fits_from_laser.pngWaist_Fits_Bench_Position.png

 

OK. The fit is reasonably good. Residuals around the area of interest (with one exception) are <+/- 2um and the waists are 47.5um (vertical) and 50.0um (horizontal) at a position of 9.09 on the bench. And the details of the fitting output are given below.

 

-=-=-=-=-=-=-=-=-=-=-=-

Vertical Fit

 

cf_ =

 

     General model:

       cf_(x) = w_o.*sqrt(1 + (((x-z_o)*1064e-9)./(pi*w_o.^2)).^2)+c

     Coefficients (with 95% confidence bounds):

       c =   5.137e-06  (4.578e-06, 5.696e-06)

       w_o =   4.752e-05  (4.711e-05, 4.793e-05)

       z_o =        1.04  (1.039, 1.04)

 

 

cfgood_ = 

 

           sse: 1.0699e-11

       rsquare: 0.9996

           dfe: 22

    adjrsquare: 0.9996

          rmse: 6.9738e-07

 

-=-=-=-=-=-=-=-=-=-=-=-

Horizontal Fit

 

cf_ =

 

     General model:

       cf_(x) = w_o.*sqrt(1 + (((x-z_o)*1064e-9)./(pi*w_o.^2)).^2)+c

     Coefficients (with 95% confidence bounds):

       c =    3.81e-06  (2.452e-06, 5.168e-06)

       w_o =   5.006e-05  (4.909e-05, 5.102e-05)

       z_o =        1.04  (1.04, 1.04)

 

 

cfgood_ = 

 

           sse: 4.6073e-11

       rsquare: 0.9983

           dfe: 22

    adjrsquare: 0.9981

          rmse: 1.4471e-06

 

 

 

  3230   Thu Jul 15 16:57:31 2010 josephb, kiwamuUpdateCDSThe temporarily named c1scx machine getting ready to connect to IO chassis

This is the machine which will be the new x end front end machine.  Its IP is 192.168.113.86. 

We changed the root and controls passwords to the usual.  We have modified the controls user group to be 1001, by using "usermod -u 1001 controls" (we had to use the non-rtl kernel to get that command to work).

We changed /etc/fstab to point to /cvs/cds on Linux rather than some downs machine.  We added a link to /cvs/cds/rtcds in the local /opt directory.

We modified the /etc/rc.d/rc.local file to no longer run /opt/open-mx/sbin/omx_init start, /cvs/cds/geo/target/fb/mx_stream -d scipe12:0 om1, and /cvs/cds/geo/target/fb/mx_stream -d scipe12:0 -e2 -r2 om2.  We modified the /usr/bin/setup_shmem.rtl to run only c1x00 c1scx and c1spx.

I also commented out a line0 "/bin/rm -f /rtl*"

 

  16265   Wed Jul 28 20:20:09 2021 YehonathanUpdateGeneralThe temperature sensors and function generator have arrived in the lab

I put the temperature sensors box on Anchal's table (attachment 1) and the function generator on the table in front of the c1auxey Acromag chassis (attachment 2).

 

Attachment 1: 20210728_201313.jpg
20210728_201313.jpg
Attachment 2: 20210728_201607.jpg
20210728_201607.jpg
  2215   Mon Nov 9 14:59:34 2009 josephb, alexUpdateComputersThe saga of Megatron continues

Apparently the random file system failure on megatron was unrelated to the RFM card (or at least unrelated to the physical card itself, its possible I did something while installing it, however unlikely).

We installed a new hard drive, with a duplicate copy of RTL and assorted code stolen from another computer.  We still need to get the host name and a variety of little details straightened out, but it boots and can talk to the internet.  For the moment though, megatron thinks its name is scipe11.

You still use ssh megatron.martian to log in though.

We installed the RFM card again, and saw the exact same error as before.  "NMI EVENT!" and "System halted due to fatal NMI".

Alex has hypothesized that the interface card the actual RFM card plugs into, and which provides the PCI-X connection might be the wrong type, so he has gone back to Wilson house to look for a new interface card.  If that doesn't work out, we'll need to acquire a new RFM card at some point

After removing the RFM card, megatron booted up fine, and had no file system errors.  So the previous failure was in fact coincidence.

 

  1186   Mon Dec 8 11:41:27 2008 YoichiSummaryVACThe rough pump for the TP2 replaced
Bob, Yoichi

The foreline pressure of the TP2 (the foreline pump for the main mag-lev turbo (TP1)) was at 2.8torr this morning
when Bob came in.
Looked like the foreline pump (Varian SH-110) was leaking.
Bob started the backup rough pump in parallel with the "leaking" one to keep the foreline pressure low.
We then closed the valve 4 (between TP2 and TP1) and stopped the TP2 and the SH-110.
We replaced SH-110 with another one, but still the foreline pressure was high.
So we replaced it with yet another one. We also changed the quick coupling fasteners on the SH-110 and wiped the O-rings.
This time, it worked fine and the foreline pressure dropped to around 38 mTorr.

Since there is no valve between the TP2 and the SH-110, we could not keep the TP2 running while we were replacing the
problematic SH-110. This means the TP1 was running without a foreline pump during the work. We tried to minimize the
down time of the TP2. The temperature of the TP1 was 33.6C before we stopped the TP2 and it went up to 37.3C during the
work. It is now coming down to the original temperature.

Since we don't know if the problem was caused by bad SH-110s or leaking quick couplings, Bob is checking these apparently
"leaking" SH-110s.
  4920   Thu Jun 30 08:18:08 2011 SureshUpdateIOOThe resonances and notches on WFS1 have been tuned.

As noted before the  resonances had to be tuned to the 29.5 MHz ( or rather 29.485 MHz to match with the Wenzel) and notches to twice that frequency (58.97 MHz). 

I tuned these frequencies and remeasured the transimpedance curves .  These are in the attached pdf file. 

Some notes.

1) The variable inductances on the PCB have a ferrite core which is actually ferrite powder compacted around an iron screw.  The screw serves to provide the adjustability.  However, being iron, it seems to have rusted and so the cores are stuck.  So several of the cores splintered when I tried to adjust the frequencies.

2) The WFS1 had a finger print/smudge on the face of the PD.  I drag wiped it with methanol to get rid of it.

 

WFS1 is ready to go on the table.  I am going to work on WFS2 today.

 

Attachment 1: WFS1_tuned.pdf
WFS1_tuned.pdf WFS1_tuned.pdf WFS1_tuned.pdf WFS1_tuned.pdf
  7845   Mon Dec 17 22:42:27 2012 KojiSummaryGeneralThe projector lamp ended its life?

i just heard a rather large exploding sound in the control room.
I tried to locate the source and found the projector is not illuminating the wall anymore.
There is a slight smell of burning, but nothing is smoking.

Probably the lamp ended its life.

Rana and I just talked about the projector life time an hour ago! It must have been hearing!

  7846   Mon Dec 17 22:49:33 2012 ManasaSummaryGeneralThe projector lamp ended its life?

Quote:

i just heard a rather large exploding sound in the control room.
I tried to locate the source and found the projector is not illuminating the wall anymore.
There is a slight smell of burning, but nothing is smoking.

Probably the lamp ended its life.

Rana and I just talked about the projector life time an hour ago! It must have been hearing!

 LOL

We should try purchase a projector with LED this time...longer lifetime! I guess the price of replacing the lamp in the one we have will be more or less same as a new one!

  7847   Tue Dec 18 00:45:19 2012 KojiSummaryGeneralThe projector lamp ended its life?

...Nah. The projector is pretty new (t<1yr) and this is the first time to have the lamp busted after the installation last year in Jan.

We just should purchase two bulbs.

  7885   Wed Jan 9 13:34:34 2013 KojiSummaryGeneralThe projector lamp ended its life?

[Koji, Manasa]

- A new projector lamp installed.

- The old lamp lasted 8751 "equivalent lamp hours".

- The old lamp was found being shattered inside. It contains mercury.
So next time you hear the explosion sound of the lamp, establish the ventilation of the room and escape for an hour.

  1861   Fri Aug 7 17:46:21 2009 ZachUpdateCamerasThe phase camera is sort of working

Shown below are the plots of the amplitude and phase of the Mephisto laser light modulated with a chopper as a square wave at about 1 kHz.  The color bar for the phase should run from -pi to pi, and it does when I don't accidently comment out the color bar function.  Anyway, the phase is consistently pi/4 or pi/4 plus or minus pi.  Usually all three of these phases occur within the same image, as shown below.  Also, the amplitude is a factor of two or so higher than it should be where this phase jump occurs.  I think these problems are associated with the nature of the square wave.  However, there is a software bug that appears to be independent of the input data: there is a rounding error that causes the amplitude to jump to infinity at certain points.  This happened for only a dozen or so pixels so I deleted them from the amplitude plot shown below.  I am currently working on a more robust code that will use the Newton-Raphson method for nonlinear systems of equations. 

Attachment 1: ampAv.png
ampAv.png
Attachment 2: phaseAv.png
phaseAv.png
  190   Thu Dec 13 12:05:36 2007 albertoOmnistructureElectronicsThe new Butterworth seems to work quite well
It works better probably because of the small inductors I'm using this time.
The peak is at 30 MHz because I didn't have the precise elements to get 33.

The bandwidth and the Q could be improved by adding one or two more order to the filter and trying to better match the low-pass' resonant frequency with the high-pass'.

Also I have to see if it could work at 166 and 199 MHz as well.
Attachment 1: TF_New_Butterworth_12-Nov-2007_TF.png
TF_New_Butterworth_12-Nov-2007_TF.png
Attachment 2: Bultervverth2.png
Bultervverth2.png
  7768   Fri Nov 30 14:21:18 2012 ranaHowToComputer Scripts / ProgramsThe mystery of PDFs and you. As deep as the mystery of Rasputin.

This is how to post PDF:

From DTT, print the plot as a postscript file.

Then use ps2pdf to make a archival PDF version (the flag is the key!). Example:

ps2pdf -dPDFX /home/controls/Desktop/darm.ps

Attachment 1: darm.pdf
darm.pdf
  7789   Wed Dec 5 01:06:22 2012 AyakaUpdateWienerFilteringThe microphones and the speaker on the AP table

 In order to see the acoustic coupling on arm signals, I set 6 microphones and the speaker on the AP table. The microphones are not seismically isolated for now.
I have a signal generator under the AP table.

DSC_4956.JPGDSC_4961.JPG

When I played the 43 Hz triangular wave sound, I could see some coherence between POY error signal and microphones even though there is no peak in POY.

APsig.pdf

To Do:

  • Try to subtract the acoustic signal and see with which microphone the acoustic signal can be subtracted best. But how can I find whether the signal is subtracted or not? Is coherence information enough?
  • Make circuits for microphones to come to 40m.
  • Make suspension systems for microphones. One idea is that the microphones should be suspended from bridges which is to be put around at the top of the tables since there is no space for stacks for each microphones.
  • Prepare a new ADC.
  • Perform the same measurements at the other tables, such as POX and POY.
  7792   Wed Dec 5 09:53:01 2012 ranaUpdateWienerFilteringThe microphones and the speaker on the AP table

  Don't try to re-invent the mic mount: just copy the LIGO mic mount for the first version.

  4714   Fri May 13 22:45:37 2011 SureshUpdateRF SystemThe full set of 8 Demod boards is ready for testing

We have Completed the hardware changes to the full set of 8 demod boards.  The last one completed today is AS11.  I have collected the info on all the demod boards available so far in the table below.  As we measure the actual phase and amplitude unbalance we will expand this table to include new info.

The set of 8 demod boards
Demod Board S. No. Power Splitter Frequency range of splitter (MHz) Phase unbalance from datasheet (deg) Amplitude Unbalance from datasheet (dB)
AS11 121 PSCQ-2-51W 5 to 50 87.49 0.1
REFL11 021 PSCQ-2-51W 5 to 50 87.49 0.1
POY11 119 PSCQ-2-32 3.2 to 32 87.58 0.05
AS55 029 PSCQ-2-51W 5 to 50 no info no info
REFL55 118 PQW-2-90 30 to 90 90.14 0.92
POY11 119 PSCQ-2-32 3.2 to 32 87.58 0.05
POY22 020 PSCQ-2-32 3.2 to 32 90.26 0.02
POY110 120 PSCQ--120 80 to 120 90.88 0.58

 

  4067   Fri Dec 17 00:55:30 2010 KojiUpdateIOOThe dark port beams reached the AP table

[Koji and Kiwamu]

We obtained two dark port beams on the AP table: OMC REFL and AS

- First, IPANG and BS were aligned so as to have the beams on the center of the ETMs.

- Then ITMX/ITMY/PRM/SRM were aligned to have fringes in a single spot anywhere.

- As we already had the dark port beam on the steering mirrors on the BS table, today the PZT mirrors were adjusted.
This work was the beam steering between the BS table to the OMC table. After some tweaking of the mirror mounts, 
the spot on the last PZT mirror was found.

As we have not touched any of the OMC optics since they were aligned well, the alignment has been adjusted by the nobs of the PZT steering mirrors.
Once the beam is on the output mode matching telescope (OMMT), the work was quite easy thanks to the beam shrinking by the OMMT.

Note that the dark port beam is slightly clipped by the green steering mirror. The steering mirror will be moved next time.

After the alignment, we indeed obtained OMC REFL and AS beams on the AP table.
The fringes were visible on the OMC REFL CCD.

We keep the dark port setup on the OMC (in-vac) and AP tables so that they can be the reference of the dark port alignment.
In principle we can align the beams onto the OMC by the two PZT mirrors.


What is left?

Our minimum success of this vent is to setup the X arm cavity which is needed for the green locking.
This setup was already realized. So we fulfilled the condition to close the tank even if the damping of
the ETMY is not achieved. (But we should try)

Tomorrow, we make a light touches to POY, Green, IPPOS, and check the table leveling, clamping, etc, in general.

JD:  We should check OSEMs for all optics *after* table leveling.  Some of them (esp. BS and ITMX) are currently close to their limits right now.

KA: Check green alignment. / Take photos of the tables. / Fix the leveling weights


Location    Optics            Action
--------------------------------------------------------------
@ITMY -     POY               mirror replacement (45deg->0deg) / alignment

@BSC -      Green steering    alignment
            IPPOS steering    alignment
            Beam dumps
            Table Leveling

@ETMX -     Al foil removal
            Table Leveling

@ETMY -     ETMY damping
            OSEM
            OPLEV
            Table Leveling

@ITM/ETM -  Mirror Wiping

  2969   Fri May 21 16:27:45 2010 AlbertoOmnistructureEnvironmentThe control room is molding...

... not just because we haven't locked the interferometer for quite some time. I mean, it literally stinks. The chiller's chiller is molding. Its' dripping water and there's mold all under it (Jo just confirmed: "yeah, it's mold").

Someone from Caltech maintenance just crossed the door. Hopefully he'll help us fix it.

I'll keep you updated. Stay tuned.

  13995   Thu Jun 21 13:24:00 2018 keerthanaUpdateelogThe cavity scan data of June 20

(Jon, Keerthana, Sandrine)

We tried to align the AUX and PSL laser yesterday. We collected the data from the spectrum analyser for the Y-ARM reflection and also for the Y-ARM transmission from the ETM mirror. I am attaching the plots here.

Attachment 1: AS110_Beat.pdf
AS110_Beat.pdf
Attachment 2: YEND_Beat.pdf
YEND_Beat.pdf
  3871   Fri Nov 5 19:33:18 2010 JenneUpdateElectronicsThe beginnings of the new phase of the RF work

Joon Ho and I took a look at the RF stuff that Alberto left, and we determined that we've got most everything that we need.  On Monday, Joon Ho will list off the stuff that we're missing, and we'll have Steve order it.

Joon Ho also replaced the temporary front panel to the RF generation box with Alberto's fancy new panel.  Pics are here (although you have to sign in as foteee to see them). 

Work on the frequency distribution box will continue on Monday.

  3482   Fri Aug 27 22:09:37 2010 JenneUpdatePSLThe beginnings of the new PSL

[Rana, Jenne]

Like a new phoenix, the 40m PSL is in the process of being reborn...

phoenix.jpg

We cleared many old optics and components (including Alberto's favorite periscope) off of the north end of the PSL table.  Some optics are stored on the SP table, others on the shelf inside the PSL enclosure.

The new Innolight 2W NPRO is on the table, the PMC has been moved, and the main path of the laser has been sketched out using steering mirrors. Since we still don't have a beam, we're roughly placing all of our optics, and we'll finalize the alignment after turning on the laser.

Using a leveled HeNe, I checked the height of optics we should use to match the height of optics in the chambers by shining the light at the first steering mirror in the chamber, and ensuring that the beam hit the center of that optic .  Since the new PSL table height is identical to the AP table, it's not a surprise that from now on we will be using a 4" beam height on the PSL table, rather than the old PSL 3" beam height.

On the to-do list is to make a plate with 4 through holes to raise the PMC up by 1 inch, and to make an adapter plate (or come up with another plan) for mounting the AOM that goes directly after the NPRO/Faraday, among many other things.  We also still need to make some space for the RefCav to be put in its new place on the table, and then install it with Steve's help.   

  3483   Sat Aug 28 01:02:31 2010 ranaUpdatePSLThe beginnings of the new PSL

In fact, many of the mounts need to be adapted to 4": the beefy steering mirrors going into the PMC, the PMC RFPD, the ISS AOM, the Faraday between the NPRO and the AOM, the NPRO itself, the ISS PDs.

Also for the FSS: the 21.5 MHz EOM, the PBS, the AOM, the refcav periscope, and the RFPD.

Its obvious, in retrospect, that we would have to do this, but it somehow didn't occur to me until actually trying to put things on the table...

The NPRO itself is already tapped with 3 (metric) M3 holes. It also has 4 (un-tapped) holes at its 4 corners which look like they are for feet. Anyone have a mount design for the Innolight NPRO already?

We also started labeling the table with the new coordinate system. In this system, the NE corner is the origin. The screw hole which is most NE is 1,1. The numbering increases in the south (+X) direction and goes negative in the west (-Y) direction.

  703   Sat Jul 19 19:41:56 2008 YoichiAoGPSLThe author of the entry 702 is Yoichi not Rob
I made a mistake.
  7212   Fri Aug 17 04:13:45 2012 SashaUpdateSimulationsThe SimPlant Saga CONTINUES

THE GOOD: SimPlants ITMX and ETMX are officially ONLINE. Damping has been instituted in both, with varying degrees of success (see Attachment 1). An overview screen for the SimPlants is up (under XARM_Overview in the sitemap - you can ignore the seperate screens for ETMX and ITMX for now, I'll remove them later), C1LSP will be online/functional by Monday.

The super high low-frequency noise in my simPlant is from seismic noise and having a DC response of 1, so that the seismic noise at low frequencies is just passed as is and then amplified along with everything else in the m --> counts conversion. Not quite sure how to deal with this except by NOT having a DC response of 1 (which it technically doesn't have when you do the algebra - Rana said that "it made sense" for the optic to have unity gain at low frequencies, but the behavior is not matching up with reality).

THE BAD: It looks like the ITMX Switch from Reality to simPlant doesn't work (or some of the signals aren't getting switched). When switching from reality to simulation, it looks like the control system is receiving signals from the SimPlant, but is transmitting them to the real thing. As a result, when you flip the switch from reality to sim, ITMX goes seriously crazy and starts slamming back and forth against the stop. REALLY NOT GOOD. As soon as I saw what was going on, I turned back to reality and flipped the watch dogs on (YES THEY WERE OFF). I'll investigate the connections between the plant and control system some more in the morning (i.e. later today) (this is also probably what is causing the "lost connections" in c1sup/sus we can see in the machine status screen).

Attachment 1: plantvreality.jpg
plantvreality.jpg
  7218   Fri Aug 17 12:47:30 2012 SashaUpdateSimulationsThe SimPlant Saga CONTINUES

Quote:

THE GOOD: SimPlants ITMX and ETMX are officially ONLINE. Damping has been instituted in both, with varying degrees of success (see Attachment 1). An overview screen for the SimPlants is up (under XARM_Overview in the sitemap - you can ignore the seperate screens for ETMX and ITMX for now, I'll remove them later), C1LSP will be online/functional by Monday.

The super high low-frequency noise in my simPlant is from seismic noise and having a DC response of 1, so that the seismic noise at low frequencies is just passed as is and then amplified along with everything else in the m --> counts conversion. Not quite sure how to deal with this except by NOT having a DC response of 1 (which it technically doesn't have when you do the algebra - Rana said that "it made sense" for the optic to have unity gain at low frequencies, but the behavior is not matching up with reality).

THE BAD: It looks like the ITMX Switch from Reality to simPlant doesn't work (or some of the signals aren't getting switched). When switching from reality to simulation, it looks like the control system is receiving signals from the SimPlant, but is transmitting them to the real thing. As a result, when you flip the switch from reality to sim, ITMX goes seriously crazy and starts slamming back and forth against the stop. REALLY NOT GOOD. As soon as I saw what was going on, I turned back to reality and flipped the watch dogs on (YES THEY WERE OFF). I'll investigate the connections between the plant and control system some more in the morning (i.e. later today) (this is also probably what is causing the "lost connections" in c1sup/sus we can see in the machine status screen).

 Problem with ITMX solved! The ITMX block in c1sup hadn't been tagged as "top_names". I rebuilt and installed the model, and there are no longer lost connections, :D

  3161   Tue Jul 6 17:29:04 2010 ChipUpdatePEMThe Ranger is mine!
  7340   Tue Sep 4 20:13:46 2012 JenneUpdateGeneralThe Plan - Tues evening version

 Tues

* Hit center of ETMY, using input optics, PR3.

* Get IPANG out of vac, center QPD.

Wed

* AM: Riju do MC mode scans

* Starting right after 40m meeting, if not before: Lock MICH to get BS, ITMs aligned well

* Check if beam is hitting center of ITMX.

* Check for clipping around BS

     - Use Watek to look at beam at all 4 BS ports - make sure no clipping going into BS, after BS in the michelson, or the AS port

       - Use some old in-vac mirrors to direct beam out the BS door.  Cameras are waiting near BS chamber.

* Prepare glass beam dumps??

* IPPOS - make sure beam gets out of chamber

* Jan take photos of ETMX scattering setup

* Manasa take in-vac photos of all tables, for table layouts

* Jan / Manasa viewport transmission

* Install glass beam dumps?

* Install glass baffle at ETMY. Jan maybe install baffle at one of ITMs.

* ????

Thurs

* ????

* Check table levelling one last time on all tables. 

Fri

* Close all heavy doors.  (Access connector, ITMX, ITMY, BS, ETMX, ETMY? )

* Drag wipe test masses

* Start at ~10am?

Mon (if not Fri)

* Start pumping

  7335   Tue Sep 4 13:31:55 2012 JenneUpdateGeneralThe Plan

We need a plan for the rest of the week.  I want to be closing the heavy doors on Friday at the latest.  Please add to / comment on this list!

 

Tues

* Lock MICH to get BS, ITMs aligned well

* Check if beam is hitting center of ITMs. 

* Check for clipping around BS

     - Use Watek in-vac to look at beam at all 4 BS ports - make sure no clipping going into BS, after BS in the michelson, or the AS port

* Try to get arms to flash??

* Prepare glass beam dumps??

Wed

* IPPOS / IPANG - make sure beam gets out of chambers (this may require opening ETMY)

* Jan take photos of ETMX scattering setup

* Manasa take in-vac photos of all tables, for table layouts

* Jan / Manasa viewport transmission

* Install glass beam dumps?

* If ETMY open, install glass baffle

* ????

Thurs

* ????

* Check table levelling one last time on all tables. 

Fri

* Close all heavy doors.  (Access connector, ITMX, ITMY, BS, ETMX, ETMY? )

* Drag wipe test masses

* Start at ~10am?

Mon (if not Fri)

* Start pumping

  7336   Tue Sep 4 13:44:17 2012 ManasaUpdateGeneralThe Plan

Quote:

We need a plan for the rest of the week.  I want to be closing the heavy doors on Friday at the latest.  Please add to / comment on this list!

 

Tues

* Lock MICH to get BS, ITMs aligned well

* Check if beam is hitting center of ITMs. 

* Check for clipping around BS

     - Use Watek in-vac to look at beam at all 4 BS ports - make sure no clipping going into BS, after BS in the michelson, or the AS port

* Try to get arms to flash??

* Prepare glass beam dumps??

Wed

* IPPOS / IPANG - make sure beam gets out of chambers (this may require opening ETMY)

* Jan take photos of ETMX scattering setup

* Manasa take in-vac photos of all tables, for table layouts

* Install glass beam dumps?

* If ETMY open, install glass baffle

* ????

Thurs

* ????

* Check table levelling one last time on all tables. 

Fri

* Close all heavy doors.  (Access connector, ITMX, ITMY, BS, ETMX, ETMY? )

* Start at ~10am?

Mon (if not Fri)

* Start pumping

Wed

* Jan/Manasa - Measure transmission of viewport at ETMX

 

 

 

 

 

  10614   Wed Oct 15 22:39:17 2014 JenneUpdateLSCThe Plan

 [Rana, Jenne]

We're summarizing the discussions of the last few days as to the game plan for locking.  

  1. PRMI on REFL165.  The factor of 5 in frequency will give us more MICH signal.    We want this.
    1. Drive CARM, measure coupling to PRCL, MICH while locked on REFL33.
    2. Switch to REFL165, re-measure CARM coupling.
    3. Hopefully this will reduce the AS port fluctuations, and reduce the POP22 power decrease as CARM offset decreases. 
  2. DARM transition from ALSdiff to an intermediate signal.  Simulate, and try empirically.
    1. Maybe try ASDC normalized by sum of transmissions?
    2. Maybe try difference of transmissions divided by sum of transmissions?  
  3. Look at data on disk.
    1. Do we have anything specific causing our locklosses (lately there haven't been obvious loop instabilities causing the locklosses)?
    2. How much do we think our lengths are actually changing right now (particularly DARM on ALSdiff)?
    3. Are there better ways of combining error signals that could be useful?
    4. Do we need to work on angular loops?
      1. Oplevs
      2. POP ASC for sidebands
      3. POP QPD or Trans QPDs for arms
  4.  Think about what could be causing ETMX to be annoying.  The connection that is most suspect has been ziptied, but we're still seeing ETMX move either at locklosses or sometimes just spontaneously.
  5.  RAM.  What kind of RAM levels do we have right now, and how do they affect our locking offsets?  Do we have big offsets, or negligible offsets?
  5450   Sun Sep 18 15:57:00 2011 KojiUpdateIOOThe PZT driver engaged to PZT1

[Koji Kiwamu]

The pzt driver for PZT1 has been installed.
As there was unknown resistive connection in the vacuum chamber as described below,
the PZT out cable at the PJ driver module should always be disconnected.
The sensor cables have no problem to be connected to the controller.
In fact, they are a good monitor for the state of the PZTs.

In this configuration, Pitch and Yaw direction of PZT1 is under the control of the EPICS value as we expected.


Details:

- At the beginning, we tested the PZT driver output with low voltage level (~10V). We did not see any oscillation of the opamps.
  The pitch output was observed to be OK, while the YAW output exhibited a half of the expected output voltage.
  The opamp was holding correct voltage, however the voltage after the 1K output resister was about a half.
  This indicated there was a voltage division happening.

- The cause of the voltage division was tracked. We found that the yaw red (=hot) line is connected to pitch black
  in the vacuum chamber with a resistance of 1.4kOhm. The black cables are shorted to the ground level in the PJ driver.

- We decided to unplug the PJ's cable so that we can isolate the black cables while hoping the PZTs were drived only
  by the red and white cables. And they did.

- This means that we should not connect the PZT driving cable to the PJ's driver. The sensors have no problem to be connected.

- Pinouts:

DSUB25
|. .|
|. .|
|. o|  5
|o  | 17
|  o|  4 
|o  | 16   Yaw Black
|  o|  3   Pitch Black
|o  | 15   Yaw White
|  o|  2   Yaw Red
|o  | 14   Pitch White
 \ o|  1   Pitch Red
  \-+

* Pitch White and Yaw White are connected to the ground at the amplifier side.
* Yaw Red and Pitch Black is connected with 1.4kOhm and isolated from the others.


  4223   Fri Jan 28 15:50:44 2011 JenneConfigurationPSLThe PSL has a name!

Back in the days when we were talking about getting a new 2W PSL, I was given naming rights by Rana for this new laser. 

Today, the 40m PSL was given its new name: Edwin.

Here he is, with his shiny new label:

EdwinTheLaser.jpg

  11175   Thu Mar 26 10:41:06 2015 SteveUpdateIOOThe PMC is not clamped

The PMC is seated on 3 SS balls and it is free to move. I'm sure it will move in an earthquake. Not much, because the input and output K1 mirror frame will act as an earthquake stop.Atm2

Are there a touch of super glue on the balls? No, but there are V grooves at the bottom and on the top of each ball.Atm3

 

Attachment 1: IMG_0001.JPG
IMG_0001.JPG
Attachment 2: PMCstops.jpg
PMCstops.jpg
Attachment 3: PMCballv.jpg
PMCballv.jpg
  2616   Fri Feb 19 10:18:19 2010 JenneUpdateVACThe P1 vac pressure is almost to 3mTorr

The Vac pressure measured at P1 is at 2.5mTorr.  I expect we'll hit 3mTorr sometime this afternoon, at which point (according to Steve) the interlock will shut the shutter, and we won't have light in the IFO.  Anything which needs to happen with light in the IFO before Monday needs to happen fairly soon.

Attachment 1: VacPressureAlmostShutoffLaser_19Feb2010.png
VacPressureAlmostShutoffLaser_19Feb2010.png
  4304   Tue Feb 15 21:45:08 2011 ranaUpdateIOOThe MC TRANS Story

I forgot to elog that last night I touched up the MC2_TRANS QPD setup. I was perplexed by it always going out of alignment so I investigated.

I found that the fork clamp for the steering mirror for the QPD was not tightened. Shame. The beam diameter was equal to the aperture of the QPD and was clipping. Double shame.

I added a lens and tightened the mounts and centered the beam at ~9 PM yesterday. You can see in the attached trend that the measured power went up by ~10%.

Later, there's a big gap where Valera and Steve change out the PMC. You can see that the MC REFL voltage goes from 4.5 V to 5 V (10% increase in the power delivered to the MC).

There's essentially no change in the total transmission - this indicates that although the PMC transmission is now higher by ~10%, the matching to the IMC has been degraded by an equivalent fraction.

Needs some mode matching work.

Attachment 1: a.png
a.png
  5522   Thu Sep 22 18:33:01 2011 KojiSummaryLSCThe LSC screen modification

As per the request of Anamaria, I have added the slider of the demodulation phase for each RF PD screens.

Attachment 1: PD_screen.png
PD_screen.png
  5528   Thu Sep 22 23:18:51 2011 KojiSummaryLSCThe LSC screen modification

 

C1LSC_RFPD.adl screen was modified to have more information.

Attachment 1: C1LSC_RFPD.png
C1LSC_RFPD.png
  5498   Wed Sep 21 14:28:25 2011 KojiSummaryLSCThe LSC code/screen modification for LSC LOCKINs

The LSC code has been modified

- The code was modified, compiled, and installed.

- The code is now running. FB was restarted to deal with the change of the channel names.

- Now we have LOCKIN1, 2, and 3. This required the change of the names from C1:LSC-LOCKIN_.... to C1:LSC-LOCKIN1_...

 

- The LSC screen has also modified. It has three lockins on the screen.

- The corresponding matrix screens have been modified/created and linked from the main screen.

- I need to make the screens more cool but the locking team can start to use those lockins.

  1025   Fri Oct 3 19:38:02 2008 robMetaphysicsEnvironmentThe Gatekeeper

Found this lady outside the door of the 40m lab a few nights ago.
Attachment 1: DSC_0409.JPG
DSC_0409.JPG
  1026   Sat Oct 4 07:23:42 2008 KojiMetaphysicsEnvironmentThe Gatekeeper
Hi, this is Koji from Japan.

I am afraid that this is a poisonous spider, Latrodectus hasseltii.
In Japanese word "Seaka-goke-gumo" (red-backed widow spider)

I am not an expert of insects, but this type of spider is getting famous in Japan as they were accidentally imported from South-West asia and Austraria to Japan in recent years, and they settled in certain city areas.

It is said that its neurotoxic venom causes unpleasant results such as shock, pain, and inflammation, even it is not too strong to kill human.

Be careful.


Quote:

Found this lady outside the door of the 40m lab a few nights ago.
  4037   Thu Dec 9 12:28:52 2010 josephb, alexUpdateCDSThe Dolphin is in (Reflected memory that is)

Setting the Configurations files:

On the fb machine in /etc/dis/ there are several configurations files that need to be set for our dolphin network.

First, we modify networkmanager.conf.

We set  "-dimensionX 2;" and leave the dimensionY and dimensionZ as 0.  If we had 3 machines on a single router, we'd set X to 3, and so forth.

We then modify dishosts.conf.

We add an entry for each machine that looks like:

#Keyword name nodeid adapter link_width
HOSTNAME: c1sus
ADAPTER:  c1sus_a0 4 0 4

The nodeids (the first number after the name)  increment by 4 each time, so c1lsc is:

HOSTNAME: c1lsc
ADAPTER:  c1lsc_a0 8 0 4

The file cluster.conf is automatically updated by the code by parsing the dishosts.conf and networkmanager.conf files.

Getting the code to automatically start:

We uncommented the following lines in the rc.local file in /diskless/root/etc on the fb machine:

# Initialize Dolphin
sleep 2
# Have to set it first to node 4 with dxconfig or dis_nodemgr fails. Unexplai   ned.
/opt/DIS/sbin/dxconfig -c 1 -a 0 -slw 4 -n 4
/opt/DIS/sbin/dis_nodemgr -basedir /opt/DIS

For the moment we left the following lines commented out:

# Wait for Dolphin to initialize on all nodes
#/etc/dolphin_wait
We were unsure of the effect of the dolphin_wait script on the front ends without Dolphin cards.  It looks like the script it calls waits until there are no dead nodes.

In /etc/conf.d/ on the fb machine we modified the local.start file by uncommenting:

/opt/DIS/sbin/dis_networkmgr&

This starts the Dolphin network manager on the fb machine.  The fb machine is not using a Dolphin connection, but controls the front end Dolphin connections via ethernet.

The Dolphin network manager can be interacted with by using the dxadmin program (located in /opt/DIS/sbin/ on the fb machine).  This is a GUI program so use ssh -X when logging into the fb before use.

Setting up the front ends models:

Each IOP model (c1x02, c1x04) that runs on a machine using the Dolphin RFM cards needs to have the flag pciRfm=1 set in the configuration box (usually located in the upper left of the model in Simulink).  Similarly, the models actually making use of the Dolphin connections should have it set as well.  Use the PCIE_SignalName parts from IO_PARTS in the CDS_PARTS.mdl file to send and receive communications via the Dolphin RFM.

  4257   Mon Feb 7 19:21:32 2011 Beard PapaMetaphysicsPhotosThe Adventures of Dr Stochino and Beard Papa

  783   Sat Aug 2 13:07:23 2008 KojiConfigurationGeneralThe AP table cleaned
During the construction of the independent PLL I cleaned up some of the unused optics from the AP table. Essentially this should be harmless as they had already been isolated from any beam. They were related to Go's squeezing project and Osamu's MC Transmitted beam measurement.

Nevertherless, if you find any problem on the signals at the AP table (when the ifo returns), I am the person to be blamed.

I am going to update the table layout later next week.
  2490   Fri Jan 8 20:13:49 2010 Alberto, JoBConfigurationComputersThe 40m Kaiser Permanent Reboot Marathon
This morning after Alex and Jo's tinkering with Megatron the RFM network crashed and it brought down also some computers. The effect was that it was not possible to lock the mode cleaner anymore.
A few computers crashed and things didn't come back to their origianl state.
After an endless day of rebooting and fixing problems with the single front ends (in particular with c1susvme1), eventually the mode cleaner got locked again.
Among my weapons I also used the Nuclear Option (TM).
Maybe I'll include more details in a future elog entry.
Anyway, in the end I burtrestored everything to Jan 8 2009 at 9:00.

pasadena_marathon.JPG

  1454   Fri Apr 3 17:20:05 2009 YoichiUpdateLockingThe 3.8kHz peak seems like the DARM RSE (not 100% sure though)
Yoichi, Kentaro,

Last night, we took several measurements of the AO path loop TFs with various offsets/demod. phases tweaked.
The first attachment shows the AO path loop TF as a function of the offset (in counts) added to the DARM error signal.
Though it is a bit crowded plot, you can see a general tendency that the peak becomes lower in height and higher in frequency as
the DARM offset goes from negative to positive. Since the peak height also depends on the arm power and it fluctuates during the measurements,
the change is not monotonic function of the offset though.

Being suspicious of the demodulation phase of the DARM error signal (AS166), we scanned it (see the second attachement).
But there is no significant change.
Note that the phase of the TF is 180 degrees different from the first attachment. This is because I changed the measurement point of the returning signal
on the CM board from TP2A to OUT2 to see POX_1I signal as well. These points should give the same signal for PO_DC except for the sign.

We also took the AO path TFs by changing the MICH offset (the third attachment). Again, there is no big change.

With the CARM locked with the PO_DC signal, we took the transfer function from the AO path actuation signal to the response of the POX_1I (4th attachment).
There is a huge 3.8kHz peak.

Finally, we measured the DARM response by exciting the ETMs differentially (the PDF attachment).
The shape of the 3.8kHz resonance looks like the DARM RSE peak.

It is speculated that somehow the DARM RSE resonance is coupled into the CARM loop. Don't know how though.
I'm now working on an Optickle simulation to get an insight into this issue.
Attachment 1: AO-TF-DARM-OFFSET.png
AO-TF-DARM-OFFSET.png
Attachment 2: AO-TF-DARM-DEMOD-PHASE.png
AO-TF-DARM-DEMOD-PHASE.png
Attachment 3: AO-TF-MICH-OFFSET.png
AO-TF-MICH-OFFSET.png
Attachment 4: POX_1I.png
POX_1I.png
Attachment 5: DARM-Loop.pdf
DARM-Loop.pdf
  3878   Mon Nov 8 10:37:14 2010 KojiUpdateIOOThe 10% pick-off for MCREFL was replaced to a HR mirror

As MC2 Trans mon QPD is temporary removed for fixing, we needed a reference for the MC alignment.

I replaced the 10% pick-off in the MCREFL path to the HR mirror.
Now the MCREFL DC with MC unlock is ~2.2, while it is ~0.29 in lock.
i.e. The visibility is 87%.

This means that the MCWFS were disabled for the moment.

  3954   Fri Nov 19 12:53:50 2010 josephbUpdateCDSTestpoints on c1iscex now working

Problem:

c1iscex did not have test points working last night.

Solution:

The diag -i command indicated that :

awg 19 0 192.168.113.80 822095891 1 192.168.113.80

awg 45 0 192.168.113.80 822095917 1 192.168.113.80

The first number after the awg should be the DCUID number.  The IP address 192.168.113.80 corresponds to c1iscex.  So we had awg and testpoints setup for DCUI 19 and 45 on c1iscex.  DCUID 19 is c1x01 (the IOP), but 45 was used for a test awhile back. 

Turns out that in the testpoint.par file located in /cvs/cds/rtcds/caltech/c1/target/gds/param, there were two entries for c1scx, one with DCUID 24 and also DCUID 45.  The model at the time was running with DCUID 24.

So I changed the model DCUID to 45, deleted the [C-node24] entry in the testpoint.par file, and restarted the machine, and also did a "telnet fb 8088" and "shutdown" to restart the frame builder.

  13287   Fri Sep 1 16:55:27 2017 gautamUpdateComputersTestpoints now accessible again

Thanks to Jonathan Hanks, it appears we can now access test-points again using dataviewer.

I haven't done an exhaustive check just yet, but I have loaded a few testpoints in dataviewer, and ran a script that use testpoint channels (specifically the ALS phase tracker UGF setting script), all seems good.

So if I remember correctly, the major CDS fix now required is to solve the model unloading issue.

Thanks to Jamie/Jonathan Hanks/KT for getting us back to this point! Here are the details:

After reading logs and code, it was a simple daqdrc config change.

The daqdrc should read something like this:

...
set master_config=".../master";
configure channels begin end;
tpconfig ".../testpoint.par";
...


What had happened was tpconfig was put before the configure channels
begin end.  So when daqd_rcv went to configure its test points it did
not have the channel list configured and could not match test points to
the right model & machine.  Dave and I suspect that this is so that it
can do an request directly to the correct front end instead of a general
broadcast to all awgtpman instances.

Simply reordering the config fixes it.

I tested by opening a test point in dataviewer and verifiying that
testpoints had opened/closed by using diag -l.  Xmgr/grace didn't seem
to be able to keep up with the test point data over a remote connection.

You can find this in the logs by looking for entries like the following
while the daqd is starting up.  When we looked we saw that there was an
entry for every model.

Unable to find GDS node 35 system c1daf in INI fiels
  2599   Fri Feb 12 15:59:16 2010 josephbUpdateComputersTestpoints not working

Non-testpoint channels seem to be working in data viewer, however testpoints are not.  The tpman process is not running on fb40m.  My rudimentary attempts to start it have failed. 

# /usr/controls/tpman &
13929
# VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
no test point service registered
Test point manager startup failed; -1

It looks like it may be an issue with the reflected memory (although the cables are plugged in and I see the correct lights lit on the RFM card in back of fb40m.)

The fact that this is a RFM error is confirmed by /usr/install/rfm2g_solaris/vmipci/sw-rfm2g-abc-005/util/diag/rfm2g_util and entering 3 (which should be the device number).

Interestingly, the device number 4 works, and appears to be the correct RFM network (i.e. changing ETMY lscPos offset changes to the corresponding value in memory).

So, my theory is that when Alex put the cards back in, the device number (PCI slot location?) was changed, and now the tpman code doesn't know where to look for it.

Edit: Doesn't look like PCI slot location is it, given there's 4 slots and its in #3 currently (or 2 I suppose, depending on which way you count).  Neither seems much the number 4.  So I don't know how that device number gets set.

 

 

ELOG V3.1.3-