40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 320 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  1242   Wed Jan 21 22:53:08 2009 ranaUpdateLSCAS CCD centering and ASDD demod phase
Just my opinion, but I think all we want out of the DD signals is something to control the DRM
and not be sensitive to the carrier and the CARM offset. So if the handoff can be done so that
the lock point is unchanged from single demod then everything is fine.

A second order concern is how the 133 & 199 MHz signals are mixed in order to minimize the
matrix cross-coupling and the SNR of the diagonal elements.
  1241   Wed Jan 21 16:18:17 2009 KakeruUpdateLSCAS CCD centering and ASDD demod phase
I tuned the DD demod-pahse for SRM.
It was tuned as the error singnal is to be 0 when the cavity is locked.

The problem is that the good phase changes if MICH and PRM are handed to DD or not.
This may be a result of the demod-phase of these two signals are tuned to be maximise the error signal, not to be 0-offset.

I will tune these two demod-phases, and write a script to tune.


Quote:
I tuned the demod-phase for PRCL and SRCL hand-off, but it have not been optimized enoughly.
I continue this work tomorrow.


Quote:
After Rob's AS beam work, I centered the beam on the AS CCD.
I also optimized the ASDD demod-phase for the MICH signal.
Rob suggested to me that whenever we restart or change the frequency of the DD Marconis, we have to re-optimize the demod-phase
because the initial phase of the Marconi is random. We had the power failure, so it was time to do so.
I confirmed that MICH hand-off from REFL33Q to AS133DDQ is ok.
I will do the same thing for the PRCL, SRCL hand-offs.
  1240   Tue Jan 20 15:28:42 2009 YoichiUpdateComputersloadLIGOData a GUI for mDV

Quote:
The tool is very nice; I looked at the seismic trend for 16 days (attached).
However, it gives some kind of error when trying to get Hanford or Livingston data.


I fixed it.
You have to click "Load channels" button when you select a new site.
I plotted one minute of MC_F signals from H1, H2, L1 and 40m.
Looks like L1 MC was swinging a lot.
Attachment 1: MC_F.png
MC_F.png
  1239   Mon Jan 19 18:21:41 2009 ranaUpdateComputersloadLIGOData a GUI for mDV
The tool is very nice; I looked at the seismic trend for 16 days (attached).
However, it gives some kind of error when trying to get Hanford or Livingston data.
Attachment 1: a.png
a.png
  1238   Mon Jan 19 15:10:37 2009 YoichiHowToComputersloadLIGOData a GUI for mDV
I installed loadLIGOData, a product of my weekend project, in /cvs/cds/caltech/apps/loadLIGOData.
This is a Matlab GUI for getting data from nds servers. It uses a modified version of mDV to retrieve data.
You can choose and download LIGO data into Matlab quickly.
I also wrote a GUI to plot the downloaded data easily.
With this GUI, you can plot multiple channel data in a single figure, which is useful to identify the cause for a lock loss etc.
You can change the time axis labels to UTC or Local time in stead of GPS second.

You can run it by typing loadLIGOData in a terminal of a linux machine.
A brief explanation of how to use it is written here:
http://lhocds.ligo-wa.caltech.edu:8000/40m/loadLIGOData

At this moment, data from test points cannot be retrieved properly (of course there is no way to go back to the past for test points.
But still we should be able to get data in real time.). I'll try to find a solution.
Attachment 1: loadLIGOData.png
loadLIGOData.png
Attachment 2: plotLigoData.png
plotLigoData.png
  1237   Mon Jan 19 13:58:53 2009 YoichiUpdateASCBetter ditherServo.pl
Nick Smith (@LHO) tested the ditherServo.pl at Hanford.
He added options to specify exit conditions to the script. Now you can make the script exit when
a condition, such as ArmPower > 1.0, is satisfied, or let it wait until a certain condition is satisfied.

I also modified the script to use ezcastep instead of tdswrite for feedback actuation.
The script now runs ezcastep in the background while the next iteration of the tdsdmd is performed.
Instead of kicking mirrors with a big thrust each time by a single tdswrite command, ezcastep gently moves the mirrors with fine steps.
I also implemented this "background ezcastep" technique in Tobin's tdscntr.pl.

The alignment scripts run smoother now.
  1236   Fri Jan 16 18:45:20 2009 YoichiConfigurationIOOMC_L gain increased by a factor of 2
Rana, Yoichi

Since we fixed the FSS AOM double-pass, which used to be a single-pass, the MC_L gain was too low for
making the cross-over at 100Hz.
Rana increased it by a factor of two. Now it seems that the cross over is ok (attachment 1).

We also noticed that the MC_F spectrum is noisier than before (attachment 2).
The reference is from 6/24/2008.
Attachment 1: MC_F-MC_L-xover.pdf
MC_F-MC_L-xover.pdf
Attachment 2: MC_F.pdf
MC_F.pdf
  1235   Fri Jan 16 18:33:54 2009 YoichiSummaryComputersc1lsc rebooted to fix 16Hz glitches
Kakeru, Yoichi

There were 16Hz harmonics in the PD3 and PD4 channels even when there is no light falling on it.
Actually, even when the connection to the ADC was removed, the 16Hz noise was still there.

Rob suggested that this might be digital problem, because data is sent to the daq computer very 1/16 of a second.

We restarted c1lsc and the problem went away.
  1234   Fri Jan 16 18:29:08 2009 YoichiUpdateSUSOplevs QPDs centered
Kakeru centered ITMX and BS optical levers with the help of Jenne on the walkie-talkie.
  1233   Fri Jan 16 18:25:32 2009 Yoichi, Kakeru, RanaUpdateLSCArms were unstable
The single arm lock had been unstable for both arms in the past few days.

Symptoms:
When an arm was locked by itself, the transmitted power showed a lot of fluctuations (sharp drops).
The first attachment shows the arm power fluctuations in power spectrum and time series.
References are when the boost filters are off for the arm feedback.
You can see that when the boosts are off, the power fluctuates a lot.
Also it is obvious that X-arm is a lot worse than Y.


Diagnosis:
The second attachment is the comparison of the error signal spectra between boosts on and off.
(PD3_I is the error signal of X-arm, PD4_I is Y arm). References are boost on.
Since the arm power fluctuation was suppressed by the gain increase, it was suspected that the main
reason for the power fluctuation is not alignment fluctuation. Rather, it is length or frequency fluctuation.

Then I took spectra and coherences of PD3_I, PD4_I and MC_F with both arms locked independently.
You can see broadband coherence between PD3_I (Xarm) and MC_F (frequency noise). In contrast the coherence
between PD4_I and MC_F is smaller. This means X-arm is more susceptible to the frequency noise than Y.
What can make a simple Fabry-Perot cavity more susceptible to frequency noise ? An offset ?
So I canceled the X-arm offset at the X-arm filter bank. Bingo ! The arm power fluctuation of X-arm became as small as Y-arm
in the dataviewer.
But what is making this offset ?
After watching the dataviewer screen for a while, the arm power fluctuation became larger again. I had to re-adjust the artificial offset
to minimize the fluctuation. This made me think that the source of the offset must be something to do with alignment.
In this case, clipping of the beam at the PD was very suspicious.
So I checked the centering of the POX and POY PDs. As expected, POX was terribly off-centered.
POY was also not exactly at the center of the plateau of DC output.
After centering those PDs, the large offset in the arm loops went away.
Now the arm powers are stable without artificial offset in the loop filters.
The last attachment shows the comparison of arm power fluctuation before and after the PD centering.
(references are the measurements before the centering).
Attachment 1: TRXY.pdf
TRXY.pdf
Attachment 2: ErrorSignals.pdf
ErrorSignals.pdf
Attachment 3: coherenceBetweenArms.pdf
coherenceBetweenArms.pdf
Attachment 4: ArmPowersAfterPDwasCentered.pdf
ArmPowersAfterPDwasCentered.pdf
  1232   Fri Jan 16 11:33:59 2009 robConfigurationDMFDMF start script

Quote:
I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work Frown


It should work soon. The PATH on mafalda does not include ".", so I added a line to the start_DMF subscript, which sets up the DMF ENV, to prepend this to the path before starting the tools. I didn't put it in the primary login path (such as in the .cshrc file) because Steve objects on philosophical grounds.

Also, the epics tools in general (such as tdsread) on mafalda were not working, due to PATH shenanigans and missing caRepeaters. Yoichi is harmonizing it.
  1231   Fri Jan 16 11:28:54 2009 YoichiUpdateComputersLab. laptop needs wireless lan driver update
One of the lab. laptops (belladonna) cannot connect to the network now.
I guess this was caused by someone clicked the update icon and unknowingly updated the kernel, which resulted in the wireless lan driver malfunctioning.
It was using a Windows driver through ndiswrapper.
Someone has to fix it.
  1230   Thu Jan 15 22:30:32 2009 ranaConfigurationDMFDMF start script
I tried to restart the DMF using the start_all script: http://dziban.ligo.caltech.edu:40/40m/280

it didn't work Frown
  1229   Thu Jan 15 09:19:32 2009 steveUpdateIOOMC locking
MC2 sus damping was found tripped at the morning the second time this week.

Damping was restored, ISS gain lowered to avoid saturation, MZ manually locked
and MC locking was back.
  1228   Wed Jan 14 15:53:32 2009 steveDAQPSLMC temperature sensor

Quote:
I added a channel for the temperature sensor on the MC1/MC3 chamber: C1:PSL-MC_TEMP_SEN.
To do that I had to reboot the frame builder. The slow servo of the FSS had to get restarted, the reference cavity locked and so the PMC and MZ.


Where is this channel?
  1227   Wed Jan 14 10:59:06 2009 steveBureaucracyVACrga waiting to be "connected"
We have no RGA data since old Dycor passed away in the middle of Oct, 2008
New SRS-RGA200 was installed on the vac envelope on Nov 14, 2008
It is waiting to be software connected to the 40m logging
  1226   Wed Jan 14 09:22:43 2009 steveHowToVACN2 supply pressure lowered for vac valves

Quote:
I've been replacing the N2 bottles recently.
I noticed that the consumption is too high. I had to replace them every two days.
Normally the interval is three or more days.
I suspect there is some leak in the line.

Strangely, it is always the left hand bottle which goes empty. The right hand bottle has been
there for more than a week at about 1000 psi.

We should check it when Steve is back.



All vac valves operated by N2
The two cylinders are located in entry room 103
There is an auto switch over valve between them to insure continuous supply.
The pressure regulator should be set 70 PSI on the gauge
This pressure we keep constant.
All vac valves will close in case of running out of N2 or losing ac power so
it is essential that one replaces empty N2 cylinder.

Simply disconnect large CGA580 fitting with a crescent wrench.
Swap in full cylinder from outside, reconnect fitting tightly and open cylinder valve.
Now you should be reading the full cylinder pressure.
Write each cylinder pressure and date-time on the board so one can see if there is a leak
Attachment 1: n280d.jpg
n280d.jpg
  1225   Tue Jan 13 18:59:09 2009 KakeruUpdateLSCAS CCD centering and ASDD demod phase
I tuned the demod-phase for PRCL and SRCL hand-off, but it have not been optimized enoughly.
I continue this work tomorrow.


Quote:
After Rob's AS beam work, I centered the beam on the AS CCD.
I also optimized the ASDD demod-phase for the MICH signal.
Rob suggested to me that whenever we restart or change the frequency of the DD Marconis, we have to re-optimize the demod-phase
because the initial phase of the Marconi is random. We had the power failure, so it was time to do so.
I confirmed that MICH hand-off from REFL33Q to AS133DDQ is ok.
I will do the same thing for the PRCL, SRCL hand-offs.
  1224   Tue Jan 13 11:10:42 2009 robConfigurationComputersconlogger restarted
unknown how long it's been down.
  1223   Mon Jan 12 18:53:03 2009 YoichiUpdateLSCAS CCD centering and ASDD demod phase
After Rob's AS beam work, I centered the beam on the AS CCD.
I also optimized the ASDD demod-phase for the MICH signal.
Rob suggested to me that whenever we restart or change the frequency of the DD Marconis, we have to re-optimize the demod-phase
because the initial phase of the Marconi is random. We had the power failure, so it was time to do so.
I confirmed that MICH hand-off from REFL33Q to AS133DDQ is ok.
I will do the same thing for the PRCL, SRCL hand-offs.
  1222   Mon Jan 12 10:57:38 2009 robUpdateGeneralsome stuff

The AS beam was not hitting the AS166 diode, so I aligned the last little steering mirror and adjusted the phase for MICH locking.

I turned on the HV supplies for the OMC.

Then I realigned the beam onto the AS166 diode, since the steering mirrors came on when I turned on the HV supplies.

It took awhile to find the alignment of the beam into the OMC. Once that was done, the output beam alignment was set, so I aligned onto the AS166 diode a third time.

The bottom two Sorensens in the OMC voltage supply don't look right. They have stickers that say +-24V, but each is sitting at 17.5V and showing no current draw. What's going on here?
  1221   Fri Jan 9 17:30:10 2009 KakeruUpdateComputersSnapshots of MEDM screens
I wrote a web page which shows snapshots of MEDM screens generated by Yoich's script (e-log #1206).
https://nodus.ligo.caltech.edu:30889/medm/screenshot.html
This page refreshes itself every 5 minutes automatically.

The .html file is generated by /cvs/cds/caltech/statScreen/bin/genHtml.pl
This script generates the .html file contains snapshots listed on /cvs/cds/caltech/statScreen/etc/medmScreens.txt every 5 minutes with cron.
When you wont to display other screens, please edit this .txt file and wait 5 minutes!


To make thumbnails, I wrote /cvs/cds/caltech/statScreen/bin/genThumbnail.pl
This script reads /cvs/cds/caltech/statScreen/etc/medmScreens.txt, too.
(Sometimes, it makes thumbnails with larger storage...)


Quote:
I wrote scripts to take snapshots of MEDM screens in the background.
These scripts work even on a computer without a physical display attached.
You don't need to have X running.
So now the scripts run on nodus every 5 minutes from cron.
The screen shots are saved in /cvs/cds/caltech/statScreen/images/

There is a wiki page for the scripts.
http://lhocds.ligo-wa.caltech.edu:8000/40m/captureScreen.sh

Someone has to make a nice web page summarizing the captured images.
  1220   Fri Jan 9 16:52:18 2009 steveUpdateVACtp3 forline pump replaced
Alberto took 40m vacuum 101 class as we replaced the drypump at the annulus pump line.

He is still not authorized to use the monster 2 3/8" open end wrench that is 36" long.

The fore line pressure dropped to 20 mTorr from 1 Torr as the pumps were swapped.
Bob needs to be given credit for replacing the tip seal on this Varian SH-100 drypump
The ss-hose felt dry at the tp3 exhaust end but it was some what "teflon coated-placticky-
-almost oily" at intake end of the dry pump.
We'll have to replace this metal hose next time.

This is a reminder that the 40m vacuum operation is fully manual.
It requires two people to switch a vacuum valve and one of them has to be experienced.
  1219   Fri Jan 9 09:14:17 2009 steveUpdatePEMifo is recovered after eq
There is no obvious damage from last night earth quake.
All sus dampings were turned on, MC locked and the arms locked right on
Attachment 1: eq4.5sb.jpg
eq4.5sb.jpg
  1218   Thu Jan 8 20:26:17 2009 robOmnistructureGeneralEarthquake in San Bernardino
Magnitude 4.5
Date-Time

* Friday, January 09, 2009 at 03:49:46 UTC
* Thursday, January 08, 2009 at 07:49:46 PM at epicenter

Location 34.113N, 117.294W
Depth 13.8 km (8.6 miles)
Region GREATER LOS ANGELES AREA, CALIFORNIA
Distances

* 2 km (1 miles) S (183) from San Bernardino, CA
* 6 km (4 miles) NNE (25) from Colton, CA
* 8 km (5 miles) E (89) from Rialto, CA
* 88 km (55 miles) E (86) from Los Angeles Civic Center, CA

Location Uncertainty horizontal +/- 0.3 km (0.2 miles); depth +/- 0.8 km (0.5 miles)
Parameters Nph=142, Dmin=1 km, Rmss=0.38 sec, Gp= 14,
M-type=moment magnitude (Mw), Version=Q

I felt it from home.

All the watchdogs are tripped, vacuum normal. It looks like all the OSEM sensor values are swinging, so presumably no broken magnets. I'm leaving the suspensions off so we can take fine-res spectra overnight.

Watchout for crappy cables coming loose.
  1217   Thu Jan 8 16:49:37 2009 ranaConfigurationloreHP 5550dtn (Grazia) set up on allegra

Quote:
I set up printing to grazia from allegra. The CUPS interface was not as straightforward as Tobin had made it seem in the Wiki. I had to type in the IP address and port number by hand.

The steps (AFAIR):
1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://131.215.115.220:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.


It ought to be root to do that.
  1216   Mon Jan 5 11:21:05 2009 AlanOmnistructureComputer Scripts / ProgramsNew 40mWebStatus

Quote:

I guess we need some kind of "official" crontab file for controls@nodus so that we know how/where to add things. So, I put one in /cvs/cds/caltech/crontab/controls@nodus.crontab


Alan and I agreed that we should edit the crontab by "crontab -e" command rather than editing the "official" crontab in /cvs/cds/caltech/crontab/.
After confirming that the new crontab works as expected, you are encouraged to make a copy of the new crontab into /cvs/cds/caltech/crontab/ as a backup.
Then do "svn ci" in the directory.
  1215   Sun Jan 4 13:17:23 2009 AlanOmnistructureComputer Scripts / ProgramsNew 40mWebStatus
I have set up some code in /cvs/cds/caltech/scripts/webStatus along with a cronjob on controls@nodus to generate a webStatus every half hour, at 40mWebStatus

you are welcome to add/delete lines corresponding to interesting EPICS channels, in the template /cvs/cds/caltech/scripts/webStatus/webStatus_template.html . The 2nd number is the "golden" value of the EPICS channel; it can be edited by hand, or one could copy a "golden" webStatus.html to webStatus_template.html . I think it's probably premature to automate this...

I noticed that Yoichi also has a cron job posting 40m medm screen snapshots. Very nice.

controls@nodus also runs a third cronjob, which checks if the nightly backup fails, and if so, sends an email to me.

I guess we need some kind of "official" crontab file for controls@nodus so that we know how/where to add things. So, I put one in /cvs/cds/caltech/crontab/controls@nodus.crontab
  1214   Fri Jan 2 18:49:54 2009 YoichiUpdateLSCLSC modulation frequencies adjusted
I noticed that the IFO did not lock in the MICH configuration.
This was because AS166Q signal was too small.
The demodulation phase seemed not right, i.e. the I-phase signal was larger than Q.
I suspected that the 166MHz modulation frequency was not exactly on the MC FSR, since I just
recovered the number written on the Marconi after the power failure.
I measured the optimal frequency by the method explained in elog:752.
It was 165981500Hz, which is pretty close to the number Rob measured in elog:952, but significantly different from
the label on the Marconi.
I set the frequencies of all the MARCONIs accordingly and updated the labels.

After this, the AS166 demodulation phase was still not good enough (the Q and I signals were about the same).
So I rotated the phase by 45deg. In principle, this should set the demod-phase right for DARM too. Is it correct, Rob ?
I also adjusted the PD offsets. After those adjustments, MICH locks stably with a slightly increased gain (20 as compared to 10 before).
  1213   Fri Jan 2 17:20:44 2009 ranaSummaryComputer Scripts / Programs40m GWINC
I have made a '40m' directory in the iscmodeling CVS tree which allows one to run a 40m version of GWINC.

As does the previous one, it takes the default advLIGO config file and modifies some of the struct parameters
to make it appropriate for the 40m.

To make it run, I have added susp1.m to the GWINC directory. This calculates suspension thermal noise using
the Gonzalez-Saulson method that was later extended to
mirrors by Y. Levin. This is also the code used in the LIGO Noise Budget at the sites.

The previous code was giving a much larger value for thermal noise (probably because I didn't understand how
to use it right). It was based on a SURF report from '99.

Since we will have a mixture of MOSs and SOSs in the arms, I have just used SOSs in the model. So the suspension
thermal noise is overestimated by ~sqrt(2) (and realistically its uncertain by a much larger factor).

Since the new code now uses GWINC, the mirror and coating thermal noise are now more correct and use the
coherent therm-optic noise picture.

The 2 page PDF file shows the noise for 0 deg and 90 deg tuning of the SRC.

Although it looks like, from this plot, that we could measure coating thermal noise at the 40m, in reality we would have
to fix all of the technical noise sources first. Just the coil driver noise is probably at the level of 3 x 10^-17 m/rHz
at 100 Hz.
Attachment 1: bench40.pdf
bench40.pdf bench40.pdf
  1212   Thu Jan 1 01:15:45 2009 YoichiSummaryVACN2 line leak ?
I've been replacing the N2 bottles recently.
I noticed that the consumption is too high. I had to replace them every two days.
Normally the interval is three or more days.
I suspect there is some leak in the line.

Strangely, it is always the left hand bottle which goes empty. The right hand bottle has been
there for more than a week at about 1000 psi.

We should check it when Steve is back.
  1211   Thu Jan 1 01:07:03 2009 YoichiSummaryEnvironmentParticle counts going crazy
I increased the fan speed of the PSL HEPA filter to the maximum.


Quote:
Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1210   Thu Jan 1 00:55:39 2009 YoichiUpdateASCAlignment scripts for Linux
A Happy New Year.

The dither alignment scripts did not run on linux machines because tdscntr and ezcademod do not run
on linux. Tobin wrote a perl version of tdscntr and I modified it for 40m some time ago.
Today, I wrote a perl version of ezcademod. The script is called ditherServo.pl and resides in /cvs/cds/caltech/scripts/general/.
It is not meant to be a drop-in replacement, so the command line syntax is different. Usage is explained in the comment of the script.

Using those two scripts, I wrote linux versions of the alignment scripts.
Now when you call, for example, alignX script, it calls alignX.linux or alignX.solaris depending on the OS of
your machine. alignX.solaris is the original script using the compiled ezcademod.
In principle, ezcademod is faster than my ditherServo.pl because my script suffers from the overhead of
calling tdsdmd on each iteration of the servo. But in practice ditherServo.pl is not that bad. At least, as far as
the alignment is concerned, the performances of the both commands are comparable in terms of the final arm power and the convergence.

Now the alignXXX commands from the IFO Configure MEDM screen work for X-arm, Y-arm, PRM and DRM. I did not write a script for Michelson, since
it is optional.
I confirmed that "Align Full IFO" works correctly.
  1209   Wed Dec 31 22:59:40 2008 YoichiSummaryEnvironmentParticle counts going crazy
Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1208   Tue Dec 30 18:51:18 2008 rana,yoichiConfigurationElectronicsIlluminator Power Supply reset
We noticed that none of the illuminators were working.

The switches were off on all the ports. After turning them on it still didn't work.

The +24 V Sorensen power supply which powers all of the illuminators had its OVP light on.
We turned it off, ramped the voltage to zero, turned it back on, and then went back to +24 V.

We then checked the operation of the illuminators; ETMY is still MIA.

Each of the illuminators sucks ~0.6-0.7 A when the (unlabeled) rheostat knob panel is set
to the "25" setting.

It seems pretty unwise, in the EMI sense, to be sending Amps of unshielded, high current,
switching supply outputs for 40m down the arms. This creates a huge antenna for radiating
the switching noise. I hereby assign minus 5 points to whoever designed this system.

Illuminator Upgrade:
- Use LEDs of a wavelength that the OSEMs don't see. LEDs are also cool so that the
  Suspension won't drift in alignment.

- Use 2 power supplies so that the power is balanced.

- Make is +/-12 V twisted AWG 14 wire so that the EMI is contained. Should also
  be shielded cable.
  1207   Mon Dec 29 21:51:02 2008 YoichiConfigurationComputersWeb server on nodus
The apache on nodus has been solely serving for the svn web access.
I changed the configuration and all files under /cvs/cds/caltech/users/public_html/ can be seen under
https://nodus.ligo.caltech.edu:30889/

The page is not password protected, but you can add a protection by putting an appropriate .htaccess
in your directory.
For the standard LVC password, put the following in your .htaccess
AuthType Basic  
AuthName "LVC password"
AuthUserFile /cvs/cds/caltech/apache/etc/LVC.auth
Require valid-user
  1206   Mon Dec 29 21:38:57 2008 YoichiUpdateComputersSnapshots of MEDM screens
I wrote scripts to take snapshots of MEDM screens in the background.
These scripts work even on a computer without a physical display attached.
You don't need to have X running.
So now the scripts run on nodus every 5 minutes from cron.
The screen shots are saved in /cvs/cds/caltech/statScreen/images/

There is a wiki page for the scripts.
http://lhocds.ligo-wa.caltech.edu:8000/40m/captureScreen.sh

Someone has to make a nice web page summarizing the captured images.
  1205   Mon Dec 29 18:01:07 2008 AidanUpdateAuxiliary lockingUpdated 40m Upgrade Document T080074-00-R

Added a paragraph to the 40m Upgrade document describing the fiber stabilization and frequency doubling proposed for auxiliary locking.

Also added a complete diagram of the fiber stabilization and a draft sketch of the frequency doubling.

Uploaded to https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/ via svn.
  1204   Wed Dec 24 12:46:54 2008 YoichiUpdateComputersTest points are back
Rob told me how to restart the test point manager.
It runs on fb40m and actually there is an instruction on how to do that in the Wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Computer_Restart_Procedures#fb40m

I couldn't find the page because when I put a keyword in the search box on the upper right
corner of the Wiki page and hit "enter", it only searches for titles. To do a full text
search, you have to click on the "Text" button.

Anyway, now the test points are back.
  1203   Wed Dec 24 10:33:24 2008 YoichiUpdateComputersSeveral fixes. Test point problem remains.
Yesterday, I fixed several remaining problems from the power failure.

I found a LEMO cable connecting the timing board to the Penteks was lose on the c1susvme1 crate.
After I pushed it in, the DMA error has not occured on c1susvme1.

I logged into op340m using a Null Modem Cable.
The computer was failing to boot because there were un-recoverable disk errors by the automatic fsck.
I run fsck manually and corrected some errors. After that, op340m booted normally and now it is working fine.
Here is the serial communication parameters I used to communicate with op340m:
>kermit      (I used kermit command for serial communication.)
>set modem type none
>set line /dev/ttyS0     (ttyS0 should be the device name of your serial port)
>set speed 9600
>set parity none
>set stop-bits 1
>set flow-control none
>connect

After fixing op340m, the MC locked.
Then I reset the HV amps. for the steering PZTs.
Somehow, the PZT1 PIT did not work. But after moving the slider back and forth several times, it started to work.

I reset the mechanical shutters around the lab.

I went ahead to align the mirrors. The X-arm locked but the alignment script did not improve
the arm power.
I found that test points are not available. (diag said test point management not available).
Looks like test point manager is not running. Called Rolf, but could not reach him.
I'm not even sure on which machine, the tp manager is supposed to be run.
Is it c0daqawg ?
  1202   Tue Dec 23 10:35:40 2008 YoichiUpdateComputersRFM network breakdown mostly fixed
Rana, Rolf, Alberto, Yoichi

The source of the problem was the RFM bypass box, as expected.
Rana pointed out that the long cable I used to bring the 5V from the Sorensen to the box
may cause a large voltage drop considering that the box is sucking ~3A.
So we connected the cable to another power supply (5V/5A linear power supply).
Then the LEDs on the bypass box turned green from red, and everything started to work.

A weired thing is that when I connected the cable to the wrong terminals of the power supply which
have lower current supply capabilities, the supply voltage dropped to 3V, but still the LEDs on the bypass box
turned green. This means the bypass box can live with 3V.
I noticed that there is a long cable from the Sorensen to the cross connect on the side of the rack, where I
connected my cable to the bypass box. This long cable had somewhat large resistance (1 or 2 Ohms) and dropped
the supply voltage to less than 3V ?
Anyway, the bypass box is now on a temporary power supply. Alberto was assigned a task to find a replacement power
supply.

There are two remaining problems.
c1susvme1 fails to start often claiming a DMA error on a Pentek. After several attempts, you can start the machine,
but after a while (1 hour ?) it fails again.
op340m is not responding to ssh login. It responds to ping.
We hooked up a monitor and keyboard (USB because the machine does not have a PS/2 port) to it and rebooted.
At the boot, it briefly displays a message "No keyboard, try TTYa", but after that no display signal.
Steve found me a serial cable. I will try to login to the machine using the serial port.

  1201   Mon Dec 22 13:48:22 2008 YoichiUpdateComputersRFM network bypass box's power supply is dead
As a temporary fix, I cut the cable of the power supply and connected it to the Sorensen power supply +5V on the rack.
Now, the RFM bypass box is powered up, but some LEDs are red, which looks like a bad sign.
I restarted all the FE computers, but this time I got errors during the execution of the startup commands in the VxWorks machines.
The errors are "General Protection Fault" or "Invalid Opcode".
The linux machines do not show errors but still the status lights in EPICS are red.
We need Alex's help. He did not answer the phone, so Alberto left a voice mail.
  1200   Sun Dec 21 14:18:04 2008 YoichiUpdateComputersRFM network bypass box's power supply is dead
I restarted the front-end computers by power cycling them one-by-one.
After issuing startup commands, most of them started normally at least by looking
at the output from telnet/ssh.
However, the status monitors of the FE computers on the EPICS screen are still red.
I noticed that all the LEDs on the VMIC 5594 RFM network bypass box are off.
According to the labels, fb40m, c0daqctrl, c0dcu are connected to the box.
This means (I believe) c1dcuepics cannot access the RFM network. So we have no control over
the FE computers through EPICS.

I pushed the reset button on the box, power cycled it, but nothing changed.
I checked the fuse and it was OK. Then I found that the power supply was dead.
It is a small AC adapter supplying +5VDC with a 5-pin DIN like connector.
We have to find a replacement.
  1199   Sun Dec 21 13:00:06 2008 steveUpdateall down cond.vac and laser back on
There was a power outage sometimes early Saturday.

All things are down.

The Maglev was started and reached normal operating condition.
V1 was opened at P1 3.8 mTorr and cc1 is back to 3e-6 Torr now

The MOPA was turned on.
Ion pump HV on to FSS cavity.
  1198   Sat Dec 20 23:37:43 2008 robOmnistructureGeneralSaturday Night Fever after presumed power failure

Just came by to pick something up...

... alarm handlers screeching...

... TP1 failure--closing V1... call Steve... Steve says ok till tomorrow...

... all front ends down (red)...

... all suspensions watchdogged...

... all (I think) servos off...

... PSL shutter closed ...

... chiller at 15C ... I turned it off to prevent condensation in PA...

... MOPA shutter closed... turned off key on Lightwave power supply

... good luck all, and happy holidays!
  1197   Fri Dec 19 16:38:09 2008 steveUpdateLSCall optlevs centered
All optlevs were centered after full alignment.

Qpd sums are:
ETMX 12,229 counts
ITMX 9,932
ETMY 12,043
ITMY 4,362
BS 1,880
PRM 1,423
SRM 11,641
  1196   Fri Dec 19 14:35:58 2008 Yoichi AlbertoUpdateIOOMC WFS and IOO-POS QPD re-centering
For the past two days, the MC alignment has kept drifting.
This morning, the MC alignment was so bad that it wouldn't lock to the TEM00 mode.
We aligned the MC mirrors manually until the reflection looks like a nice bull's-eye (the WFSs were off at this moment).
Then we un-locked the MC and centered the beams on the WFS QPDs.
Since the QPDs were saturated with the full laser power falling on them, I reduced the PSL power by turning the HWP after the MOPA.
After this, we turned on the WFSs and everything looks normal now.
We will see the trend of the MC related channels to monitor the drift.

Although unlikely, it might be caused by the drift of the input beam to the MC.
We found that the IOO-POS QPD was mis-centered and saturating.
We replaced the BS picking up the beam for the QPD from 33% reflection to 10% one. The QPD was still saturated.
So we put the 33% BS in the beam path to the QPD to further reduce the power. The beam kicked by the 33% BS
is dumped to a black aluminum plate. We should use a better beam dump later.
Now the IOO-POS QPD should tell us some information about the beam pointing of the PSL, though it has no sensitivity
to the relative motion of the PSL table to the vacuum chambers.
  1195   Fri Dec 19 11:29:16 2008 Alberto, YoichiConfigurationMZMZ Trans PD
Lately, it seems that the matching of the input beam to the Mode Cleaner has changed. Also, it is drifting such that it has become necessary to continuously adjust the MC cavity alignment for it to lock properly.

Looking for causes we stopped on the Mach Zehnder. We found that the monitor channel:
C1:PSL-MZ_MZTRANSPD

which supposedly reads the voltage from some photodiode measuring the transmitted power from the Mach Zehnder, is totally unreliable and actually not related to any beam at all.

Blocking either the MZ input or output beam does not change the channel's readout. The reflection channel readout responds well, so it seems ok.
  1194   Fri Dec 19 11:18:52 2008 AlbertoConfigurationGeneralMode Cleaner Temperature Monitor
I reduced from 10 to 5 the gain of the SR560 that Caryn has set up after the lock-in amplifier nest to the PSL rack because the overload LED was flashing.
  1193   Thu Dec 18 19:15:54 2008 Alberto, YoichiConfigurationSUSMode Cleaner Cavity Alignment

Quote:
This morning I found the MC locked to the 10 mode. When I locked it on the 00 mode, it was unstable and eventually it always got locked to the wrong mode.

I looked at the Drift Mon MEDM screen, which shows a reference record for position, pitch and yaw of each mirror, and I found that the MC optics were in a different status. Moving the sliders of the mirrors' actuators, I brought them back to the reference position. Then the lock got engaged and it was stable, although the MC reflection from the photodiode, with the wave front sensors (WFS) off, was about 2V. That's higher than the 0.5V the it could get when we aligned the cavity and the input periscope last time.

With the WFS on, the reflection dropped to 0.3V and, so far, the the cavity has been stably locked.


This evening the mode cleaner was again locking on a higher mode so we tweaked the mirrors' actuators by their sliders on the MEDM screen until we improved the reflection to 0.3V.

Then we went inside and, on the AS table, we centered the beam on the wave front sensors.

Now the mode cleaner is locked, the reflection is less than 0.3V and the transmission about 3V, tha is it is in ideal conditions. We'll see if it holds.
ELOG V3.1.3-