40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 325 of 349  Not logged in ELOG logo
 List |  Find |  Login |  Help 
 Full | Summary | Threaded | Show attachments  Show only new entries    17449 Entries 
Goto page Previous  1, 2, 3 ... 324, 325, 326 ... 347, 348, 349   Next  
ID Datedown Author Type Category Subject
  1263   Mon Feb 2 12:35:22 2009 AlbertoConfigurationGeneralNew Elog 2.7.5 in Service on Nodus
I moved the 40m, the Adhikari Lab and the SUS elogs from Dziban (located in Millikan's 6th floor) to our gateway server Nodus. In this way we should the complete control of it. I also updated the elog manager from the 2.6.5 version to the 2.7.5. Some smoothing of its interface might still be needed these days. We'll be testing it for a while before killing the old one. from now on everybody is invited to use only the new elog address since there will be no record of entries posted in the old one. Let me know of any possible difficulty in having access to it.
  1262   Fri Jan 30 19:38:57 2009 KakeruUpdatePSLISS Bad
Kakeru, Peter

We try to improve ISS bord, but there isn't circuit diagram with correct parameters.
We are to measure transfar function and guess each parameter before we desogn new circuit parameters.
  1261   Fri Jan 30 17:30:31 2009 Alberto, JosephbConfigurationComputersNew computer Ottavia set up
Alberto, Joseph,

Today we installed the computer that some time ago Joe bought for his GigE cameras. It was baptized "OTTAVIA".

Ottavia is black, weighs about 20 lbs and it's all her sister, Allegra (who also pays for bad taste in picking names). She runs an Intel Core 2 Quad and has 4GB of RAM. We expect much from her.

Some typical post-natal operations were necessary.

1) Editing of the user ID
  • By means of the command "./usermod -u 1001 controls" we set the user ID of the user controls to 1001, as it is supposed to be.

2) Connection to the Martian network
  • Ottavia was given IP address 131.215.113.097 by editing the file /etc/sysconfig/networ-scripts/ifcfg-eth0 (we also edited the netmask and the gateway address as in the Wiki)
  • In linux1, which serves as name server, in the directory /var/named/chroot/var/named, we modified both the IP-to-name and name-to-IP register files 131.215.113.in-addr.arpa.zone and 131.215.11in-addr.martian.zone.
  • We set the file /etc/resolv.conf so that the OS knows who is the name server.

3) Mounting of the /cvs/cds path
  • We created locally the empty directories /cvs/cds
  • We edited the files /etc/fstab adding the line "linux1:/home/cds /cvs/cds nfs rw,bg,soft 0 0"
  • We implemented the common variables of the controls environment by sourcing the cshrc.40m: in the file /home/controls/.cshrc we added the two lines "source /cvs/cds/caltech/cshrc.40m" and "setenv PATH ${PATH}:/cvs/cds/caltech/apps/linux64/matlab/bin/"
  1260   Thu Jan 29 18:10:13 2009 YoichiUpdatePSLISS Bad
Kakeru, Yoichi

As we noted before, the ISS is unstable. You can see the laser power oscillation around 3Hz.
We took the open-loop transfer function of the ISS around the lower UGF.
The phase margin is almost non-existent.
It was measured with the ISS gain slider at 2dB (usually it was set to 7dB).
So if we increase it by 3dB, it is guaranteed to be unstable.

The higher UGF has also a small phase margin (about 12deg.).
With the ISS gain slider at 2dB, the upper UGF is too low, i.e. the UGF is located at the beginning of the 1/f region.
So we if we make the lower UGF stable by lowering the gain, the upper UGF becomes unstable.

We took out the ISS box from the PSL table.
Kakeru and Peter are now trying to modify the filter circuit to give more phase margin at the lower UGF.
  1259   Thu Jan 29 17:24:41 2009 KakeruUpdateoplevsarm cavity oplev calibration
I calibrated optlevs again. My previous work has a lot of mistakes, so ignore it.

ITMX pit: 195 microrad/ct
ITMX yaw: 185 microrad/ct
ETMX pit: 303 microrad/ct
ETMX yaw: 296 microrad/ct

ITMY pit: 192 microrad/ct
ITMY yaw: 141 microrad/ct
ETMY pit: 294 microrad/ct
ETMY yaw: 301 microrad/ct

(For ITMY, the data is low quality)

My calcuration and Peter's(based on Royal's report) is different in two point.
i) Royal uses some geometrical factor to calibrate ITM.
ii) Royal fits data to exp(-a^2/(2*w0^2)), and I fit data to exp(-a^2/w0^2).

When I calculate with modification of these differences, my result became almost same value of Peter's one.
Now we are discussing which equation is correct.


But we must do some laser works before it...
  1258   Thu Jan 29 16:50:53 2009 josephb, albertoConfigurationComputersMegatron fixed
The warning light on megatron and the fans at full speed were fixed by not just power cycling, but completely unplugging megatron from power, waiting for a minute, and then reconnecting the power cables.

Apparently, the Sunfire X4600s at Hanford have also had intermittent problems, which required unplugging the machines completely. In their case, they were unable to access the machine normally, nor could they access the the Intergrated Lights Out Manager (ILOM).

Here, we could interact normally with megatron, but were unable to connect to the ILOM. We were able to get BIOS, but unable to change any of the setting for the ILOM connection. Since the ILOM is a seperate processor and effectively always on, even when the power light is off, a normal shutdown won't reset it. Hence the need to completely disconnect the power supply.
  1257   Thu Jan 29 13:52:34 2009 YoichiUpdatePSLLaser is back (sort of)
Here is what I think has happened to the laser.

After the chiller line to the NPRO base clogged, the FSS slow slider went down to keep the laser frequency constant.
It is evident in the attachment 1 that the behavior of the slow slider and the DTEC (diode temp. stabilization feedback signal) are almost the same except for the direction. This means the slow servo was fighting against the increased heat caused by the lack of the cooling from the bottom.
DTEC was doing the same thing to keep the diode temperature constant.

Even though the slow actuator (a Peltier on the crystal) worked hard to keep the laser frequency constant, one can imagine that there was a large temperature gradient in the crystal and the mode shape may have changed.

Probably this made the coupling of the NPRO beam to the PA worse. It may also have put the NPRO in a mode hopping region, which could be the cause of the noisiness.

Right now, the MOPA power is 2.7W.
The FSS, PMC, MZ are locked. At first, the PMC locked on a sideband. I had to twiddle the phase flip button of the PMC servo to lock the PMC. Probably this is another sticky channel, which needs to be tweaked after a reboot of c1psl. I added a code to do this in /cvs/cds/caltech/scripts/Admin/slider_twiddle.

Currently the ISS is unstable. Kakeru and I are now taking OPLTF of the servo.
Looks like the phase margin at the lower UGF is too small.
  1256   Wed Jan 28 19:08:50 2009 YoichiUpdatePSLLaser is back (sort of)
Yoichi, Peter, Jenne

Summary:
We found that the chiller water is not going to the NPRO base. It was hot whereas it was cold when I touched it a few months ago.
I twisted the needle valve on the water line to the NPRO base. Then we heard gargling noise in the pipe and the water started to flow.
The laser power is now climbing up slowly. The noisiness of the MOPA output is reduced.

I will post more detailed entry explaining my theory of what actually happened later.
  1255   Wed Jan 28 12:51:32 2009 YoichiUpdateComputersMegatron is dying
For the past three days, Megatron has been making a huge noise. Sounds like a fan is failing.
There is an LED with "!" sign on the front panel. It is now orange. Looks like some kind of warning.
We can login to the machine. "top" shows the CPU load is almost zero.
Shall we try rebooting it ?
  1254   Wed Jan 28 12:42:51 2009 YoichiUpdatePSLMOPA dying
Yoichi, Jenne, Peter

As most of you know, the MOPA output power has been declining rapidly since Jan 21. (See the attachment 1)
There was also an increase in the NPRO power observed in LMON, which is an internal power monitor of the NPRO.
Similar trend can be seen in 126MON, which picks up some scattered light from the NPRO but there may be some contributions from the PA output.

The drop in the AMPMON, LMON and CURMON (NPRO current) from the middle of Jan 26 to the end of Jan27 was caused by me.
I tried to decrease the NPRO current to put the NPRO power back to the level when the MOPA output was higher. But it did not bring back the MOPA power.
So I put back the current after an hour. This caused the sharp power drop on Jan26.
By mistake, I did not fully recover the current at that time and left it like that for a day. This accounts for the long power drop period continued until Jan27.

Shortly after I tweaked the current, the MOPA output power started to fluctuate a lot. This drives the ISS crazy.
To see if this was caused by the NPRO or power amplifier,
we decided to fix the 126MON to monitor the real NPRO power.
We opened the MOPA box and installed a mirror to direct a picked off NPRO beam to the outside of the box through an unused hole.
We set up a lens and a PD outside of the MOPA box to receive this beam. The output from the PD is connected to the 126MON cable.
So 126MON is now serving as the real monitor of the NPRO power. It has not yet been calibrated.

The second attachment shows a short time series of the MOPA power and NPRO power. When the beam is blocked, the 126MON goes to -22.
So the RIN of the NPRO is less than 1%, whereas the MOPA power fluctuates about 5%. There is also no clear correlation between the power fluctuation of the MOPA and the NPRO. So probably the MOPA power fluctuation is not caused by NPRO.

At this moment, all the feedback signals (current shunt, slow and fast actuators) are physically disconnected from MOPA box so that we can see the behavior of MOPA itself.
  1253   Mon Jan 26 14:51:54 2009 josephbConfigurationVAC 
We need a new RS-232 to Ethernet bridge in order to interface properly with the new RGA. The RGA has a fixed baud rate of 28.8k, and the current bridge (which used to work with the old RGA) doesn't have that baud rate as an option. Currently looking into purchasing a new bridge, and trying to make sure it can meet the communications requirements of the RGA.
  1252   Sat Jan 24 11:50:24 2009 AlbertoConfigurationElectronicsPhotodiode Filters' Transfer Functions
I found an elog entry by Jenne with the measurement of the transfer functions of the filters of some of our photodetectors. Since it might turn useful to us these days, while I'm thinking about posting them on the wiki sometime, I also copy the link here:
Jenne's on the PD's TF

If we still had the data for those plots, it would be great. Do we have it?
  1251   Fri Jan 23 16:33:27 2009 peteUpdateoplevsx-arm oplev calibrations
ITMXpit 71 microrad/ct
ITMXyaw 77 microrad/ct
ETMXpit 430 microrad/ct
ETMXyaw 430 microrad/ct

As with y-arm, my ITM measurements agree with Kakeru and Royal, but my ETM measurements are not quite a factor of 2 higher. Kakeru and I are investigatin.
  1250   Fri Jan 23 14:00:02 2009 YoichiUpdatePSLPMC transmission is down

Quote:
The PMC transmission is going down.
I have not relocked the PMC yet.


I tweaked the alignment to the PMC.
The transmission got back to 2.65. But it is still not as good as it was 3 days ago (more than 3).

It is interesting that the PMC transmission is inversely proportional to the NPRO output.
My theory is that the increased NPRO power changed the heat distribution inside the power amplifier.
Thus the output mode shape changed and the coupling into the PMC got worse.
MOPA output shows a peak around Jan-21, whereas the NPRO power was still climbing up.
This could also be caused by the thermal lensing decreasing the amplification efficiency.
  1249   Fri Jan 23 12:48:12 2009 KakeruUpdateoplevsarm cavity oplev calibration
I calibrated optlevs of x and y arm cavity, indipendently from Peter's work.

ITMX pit: 77 microrad/ct
ITMX yaw: 73 microrad/ct
ETMX pit: 280 microrad/ct
ETMX yaw: 263 microrad/ct

ITMY pit: 120 microrad/ct
ITMY yaw: 93 microrad/ct
ETMY pit: 280 microrad/ct
ETMY yaw: 270 microrad/ct

This result is similar to Royal's one (within 30% difference except for ETMX pit), but different from Peter's in ETMY.

The attached figure is the data and fitted curve of ITMX pit.
I took this data for 8s, with 4 Hz excitation.
  1248   Fri Jan 23 10:00:21 2009 steveUpdatePSLPMC transmission is down
The PMC transmission is going down.
I have not relocked the PMC yet.
  1247   Thu Jan 22 23:36:50 2009 peteHowTooplevsarm cavity oplev calibration
calibrated the y-arm oplevs. the procedure is contained in a matlab script. the whereabouts of this script will be revealed in a future log entry.

ITMYpit 140 microrad/ct
ITMYyaw 98 microrad/ct
ETMYpit 400 microrad/ct
ETMYyaw 440 microrad/ct (previous measurement gave 420 microrad/ct)

procedure:

1) Start with a single arm aligned and locked. Dither the mirror tilt in a DOF. Measure arm cavity power and oplev error signal. See the first attached plot.

2) Fit the plot to a gaussian and determine mu and sigma.

3) For a spherical ETM optic, the power in the cavity P(a), as a function of translational beam axis displacement a=R*sin(theta), is proportional to exp[-a^2/(2*x^2)] where x is the waist size (D. Anderson APPLIED OPTICS, Vol. 23, No. 17, 1984). The power as a function of mirror tilt in cts, P(tilt) is proportional to exp[-(tilt-mu)^2 /(2*sigma^2)]. So if R is the mirror radius then theta = arcsin(a/R) = arcsin[(1/R)*(tilt-mu)*x/sigma)].

4) Fit theta versus mirror tilt to get the calibration. See the second attached plot.

5) For a flat ITM optic, mirror tilt causes an angular displacement of the beam. The math for this case is given in Anderson.
  1246   Thu Jan 22 14:38:41 2009 carynDAQPSLMC temperature sensor

Quote:

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?


That's not the name of the channel anymore. The channel name is PEM-MC1_TEMPS. It's written in a later entry.
  1245   Thu Jan 22 12:08:59 2009 peteUpdateoplevsoplev calibration
Following the procedure described in Royal Reinecke's 2006 SURF report, I've calibrated the ETMY yaw oplev DOF. The idea is to sweep the mirror tilt, measuring the transmitted cavity power and the oplev error signal. The cavity power can be related to the mirror tilt in radians following D. Anderson APPLIED OPTICS, Vol. 23, No. 17, 1984.

I've made a simple matlab script which spits out the final number; it calls Royal's perl script to do the sweep. I get 420 microrad/ct for ETMY yaw. In 2006 Royal got 250 microrad/ct. Could something have changed this much, or is one of us wrong? I'll double check my procedure and do the other arm cavity oplevs, and describe it in detail when I have more confidence in it.

Kakeru and I plan to extend this to handle the PRM, SRM, and BS. One script to rule them all.
  1244   Thu Jan 22 11:54:09 2009 AlbertoConfigurationPSLMach Zehnder Output Beam QPD
I rotated by 180 degrees the 10% beam splitter that it is used to fold the beam coming from the Mach Zehnder (directed to the MC) on to the QPD.

The alignment of the beam with that QPD has so been lost. I'll adjust it later on.

The rotation of the BS had the (surprising) effect of amplifying the Absolute Length experiment's beat by 9 times. Maybe because of a polarizing effect of the Beam Splitter which could have increased the beating efficiency between the PSL and the NPRO beams?
  1243   Thu Jan 22 08:34:10 2009 steveBureaucracySAFETYsafety training
Kakeru received 40m safety training yesterday.

He has no authorization to work alone in the high power beam path yet.
  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.
  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.
  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.
  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.
  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).
  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
  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
  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.113°N, 117.294°W
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).
Goto page Previous  1, 2, 3 ... 324, 325, 326 ... 347, 348, 349   Next  
ELOG V3.1.3-