40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 318 of 349  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  1009   Tue Sep 30 13:43:43 2008 robUpdateLockinglast night
Steady progress again in locking again last night. Initial acquisition of DRMI+2ARMs was working well.
Short DOF handoff, CARM->MCL, AO on PO_DC, and power ramping all worked repeatedly, in the cm_step script.
This takes us to the point where the common mode servo is handed off to an RF signal and the CARM offset
is reduced to zero. This last step didn't work, but it should just require some tweaking of the gains
during the handoff.
  1014   Wed Oct 1 02:54:03 2008 robUpdateLockingbad

Tried the spring-y side tonight with a discouraging lack of progress. There were several locks of DRMI+2ARMs with
the +f2 (springy) sideband resonating in the DRM, but they weren't very stable. Moving to just the DRMI and resonating
the +f2, in order to tune up the acquisition and the handoff to the double demod signals, revealed the problem that the
DRM just won't stay locked on the +f2 sideband. It locks quickly, but only for a few seconds. This is different from the
behaviour with the -f2 sideband, which locks quickly and stably. In theory, the two sidebands should behave similarly.
It could be problems with HOMs in the recycling cavities, and so we may try changing the modulation frequency slightly.
  1019   Thu Oct 2 02:45:50 2008 robUpdateLockingmarginally better
Locking the DRMI with the +f2 sideband was marginally better tonight. I was able to get it lock stably enough to take transfer
functions and handoff MICH & PRC to double demod signals. After re-alignment, however, behaviour was similar to last night
(locks quickly but only for a few seconds), so that lends some credence to HOM-as-bad-guy theories.
  1023   Fri Oct 3 15:09:58 2008 robUpdatePSLFAST/SLOW

Last night during locking, for no apparent reason (no common mode), the PSL FAST/SLOW loop starting going just a little
nutz. Attached is a two day plot. The noisy period started around 11-ish last night.
Attachment 1: FASTSLOW.png
FASTSLOW.png
  1024   Fri Oct 3 15:57:05 2008 robUpdateLockinglast night, again
Last night was basically a repeat of the night before--marginally better locking with the DRMI resonating the +f2
sideband. Several stable locks were achieved, and several control handoffs to DDM signals worked, but never from
lock to lock--that is, a given DD handoff strategy would only work once. This really needs to work smoothly before
more progress can be made.

Also, a 24Hz mode got rung up in one/several of the suspensions--this can also impede the stability of locks.
  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
  1038   Fri Oct 10 00:34:52 2008 robOmnistructureComputersFEs are down

The front-end machines are all down. Another cosmic-ray in the RFM, I suppose. Whoever comes in first in the morning should do the all-boot described in the wiki.
  1125   Mon Nov 10 11:06:09 2008 robHowToIOOmode cleaner locked

I found the mode cleaner unlocked, with (at least) MC1 badly mis-aligned. After checking the coil alignment biases and finding everything there looking copasetic, I checked the trends of SUS{PIT,YAW,POS} and found that both MC1 and MC3 took a step this morning. The problem turned out to be loosed/jiggled cables at the satellite amplifiers for these suspensions. Giving them a good hard push to seat them restored the alignment and the mode cleaner locked right up.
  1126   Mon Nov 10 11:32:49 2008 robUpdateComputersc1iscex rebooted

it was running a few cycles late
  1165   Mon Dec 1 15:09:27 2008 robUpdatePEMhalf-micron particle count is alarming
  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!
  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.
  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?
  1224   Tue Jan 13 11:10:42 2009 robConfigurationComputersconlogger restarted
unknown how long it's been down.
  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.
  1303   Sat Feb 14 16:15:19 2009 robConfigurationComputersc1susvme1

c1susvme1 is behaving weirdly.  I've restarted it several times but its computation time is hanging out around 260 usec, making it useless for suspension control and locking.  I also found a PS/2 keyboard plugged in, which doesn't work, so I unplugged it.  It needs to be plugged into a PS/2 keyboard/mouse Y-splitter cable. 

  1304   Sat Feb 14 16:53:26 2009 robUpdateLSCLocking status

Quote:
Yoichi, Jenne, Alberto, Rob

Last night, the locking proceeded until the CARM -> MC_L hand-off.
However, the MC_F gets saturated (as expected) and the IFO loses lock soon after the hand-off.
So we need to offload MC_F.
We ran the offloadMCF script, but it did not work, i.e. just waiting for CARM mode.
Looks like an EPICS flag is not set right.


I found a '$<' in the offloadMCF script. I don't know precisely what that construct means, but I think it caused the script to wait for input when it shouldn't. It probably got in there accidentally. We need to be careful when we're opening scripts just to look at how they work that we don't accidentally change them. I like to use the command 'less' for this purpose.

With this gone, the script worked properly, although the lock didn't last long. I don't know if the next stage in the process is failing or if it's just a bit too noisy in the afternoon. I didn't get a chance to do much testing since the sus controller (susvme1) went nuts. In retrospect, this could be due to something in the script, so maybe we should try a burt restore to Friday afternoon next time someone wants to look at it.
  1311   Mon Feb 16 16:26:29 2009 robUpdateComputersmedm directory wiped on nodus

Quote:

Quote:
I accidentally did an 'rm -rf' on the medm directory in nodus, instead of on my laptop as was intended.

I then did an svn checkout. So everything should be current as of the last update, but I am sure that
we have not done a checkin on all of the latest screen enhancements. So...we may have to revert to the
Sunday morning tar to get the latest changes back.


Indeed, some changes to the medm directory I made were lost.
It was my fault not to check-in those changes.
I asked Alan to restore the directory from the daily rsync backup.
However, the backup job executed this morning have already overwritten the previous (good) backup with the current (bad) medm directory, which Rana restored from the svn. Alan will ask Stuart and Phil if there is still older backup remaining somewhere.

Anyway, I realized that we should stop the backup cron job whenever you think you made a mistake on /cvs/cds/ directory to prevent unwanted overwriting.
The procedure is:
(1) Login to fb40m
(2) Type 'crontab -e'. Emacs will open up in the terminal.
(3) Comment out the backup job (insert # at the beginning of the line containing /cvs/cds/caltech/scripts/backup/rsync.backup ).
(4) Save the file (Ctrl-x Ctrl-s) and exit (Ctrl-x Ctrl-c).

I will post this information on the wiki.


We should change the rsync script so that it does not delete stuff. Maybe it can keep deleted stuff for 6 months or something.
  1343   Fri Feb 27 13:49:19 2009 robUpdateLockingthurs night

Could not get past arm power of ~11 or so.  I was suspicious of the transmon high-gain/low-gain PD handover, so I ran the matchTransMon scripts, but that did not help.  I also removed the line in the cm_step script that increased the CM gain by 18dB at an arm power of 4.  The gain of the CM servo will increase naturally as the power in the IFO builds up, so it may not be good to crank it right away.  I tried several other CM gains, and watched the DARM loop, but still could not get past an arm power of ~10-11.  I'm not sure what's wrong, but it may be that mysterious CM-servo/McWFS conspiracy, so we can try turning down the McWFS gain next time.

  1465   Thu Apr 9 23:11:27 2009 robSummaryLockingLaser PM to PO-DC transfer functions at multiple CARM offsets

I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise.  There are transfer functions for multiple CARM offsets.  Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere.  POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer.  We should look into switching back to REFL-DC.

 

Attachment 1: CARMoffs1.png
CARMoffs1.png
Attachment 2: CARMoffs2.png
CARMoffs2.png
Attachment 3: CARMcarpet.png
CARMcarpet.png
  1466   Thu Apr 9 23:20:35 2009 robSummaryLockingLaser PM to REFL-DC transfer functions at multiple CARM offsets

Quote:

I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise.  There are transfer functions for multiple CARM offsets.  Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere.  POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer.  We should look into switching back to REFL-DC.

 

 Here are the corresponding transfer functions for REFL-DC.

Attachment 1: CARMoffs1_r.png
CARMoffs1_r.png
Attachment 2: CARMoffs2_r.png
CARMoffs2_r.png
Attachment 3: CARMcarpet_r.png
CARMcarpet_r.png
  1499   Mon Apr 20 11:57:27 2009 robUpdateCamerasMafalda may need an update

Quote:

I tried installing libusb-dev on mafalda in order to try getting the usb frame grabber to work on it, but could not as it could not download the package.

I then tried to do a sudo apt-get update, which failed completely, as the repository seems to have ceased existing.  Basically I had all 404 Not Found errors.

Turns out Mafalda is still running Ubuntu 7.04, whose support ended late 2008.  So there's a couple things that can be done:

1) Ignore it, and simply not update Mafalda anymore.  This also means some newer software and hardware simply won't work with it (like the usb frame grabber)

2) Try to find another, unofficial repository which still has all of the Ubuntu 7.04 packages.

3) Upgrade to a newer, still supported Ubuntu, such as 7.10, 8.04, or 8.10.

I'd personally lean towards the 3rd option, and go to the 8.04 long term support version.  If people agree with it, I could do the upgrade sometime Monday or Tuesday.

 

 

 

I don't see a reason to proliferate operating systems.  Is there any reason we actually need Ubuntu? Can we put CentOS on it?

  1500   Mon Apr 20 18:17:44 2009 robSummaryLockingCARM offset/Power rubric

Plotted assuming the average arm power goes up to ~80.  No DARM offset.

Attachment 1: ARMpowersCARM.png
ARMpowersCARM.png
  1516   Fri Apr 24 11:34:32 2009 robUpdateLockingDARM demod phase

Quote:

Quote:
Tonight, I was able to go up to arm power = 40 by tweaking the DARM demodulation phase.
I think the DARM loop became unstable because the demodulation phase was not right and the error signal contained some junk from I-phase.
I did not do any sophisticated demodulation phase optimization. Rather I just tweaked the phase so that the dark port image becomes stable.
I will do more careful demodulation phase tuning next time.


In the next try, I was actually able to go up to arm power = 70 stably.
At this power level we are ready for the RF CARM hand off.


There's actually code in place in the LSC to dynamically adjust the demod phase for AS1. I've never made much use of it, because it's possible to get around the problem with some gain tweaking if you start at the right phase, or because I did the DC readout handoff earlier.

Attached is a cartoon showing how the demod phase at the dark port changes as the CARM offset is decreased.
Attachment 1: darm_phase_rotate.png
darm_phase_rotate.png
  1518   Fri Apr 24 16:24:25 2009 robOmnistructureVACPaschen

In response to Steve's elog entry, and for 40m posterity, I provide the Paschen Curve.

Attachment 1: paschens.png
paschens.png
Attachment 2: paschenplot.m
% Paschen Curve plotting

% From http://home.earthlink.net/~jimlux/hv/paschen.htm

% Breakdown voltage:
% Vbreakdown = B * p * d / (C + ln( p * d))
% 
% Breakdown field strength:
% Ebreakdown = p * ( B / ( C + ln ( p * d)))
% 
... 38 more lines ...
  1529   Tue Apr 28 16:36:24 2009 robHowToLockingsetting the RF CARM demod phase

To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.

Attachment 1: CARM_phases_REFL.pdf
CARM_phases_REFL.pdf CARM_phases_REFL.pdf CARM_phases_REFL.pdf CARM_phases_REFL.pdf
Attachment 2: SRCL_phases_REFL.pdf
SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf
  1530   Tue Apr 28 17:51:13 2009 robHowToLockingsetting the RF CARM demod phase

Quote:

To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.

 

For POX33, the ideal phase for single arm locking does not yield a zero-offset CARM signal.  So the offset needs to be manipulated digitally. 

Attachment 1: XARM_phases_POX.pdf
XARM_phases_POX.pdf XARM_phases_POX.pdf XARM_phases_POX.pdf XARM_phases_POX.pdf
Attachment 2: CARM_phases_POX.pdf
CARM_phases_POX.pdf CARM_phases_POX.pdf CARM_phases_POX.pdf CARM_phases_POX.pdf
  1533   Wed Apr 29 15:56:43 2009 robUpdateLockingeffect of SRCL detune on ARM powers in a CARM sweep

With no DARM offset, sweeping CARM shows an asymmetry between the state where we lock to a DARM spring and the state with a DARM anti-spring.  This is why we have a link between the DARM and CARM optical springs. 

For each DARM detune direction (positive or negative, spring or anti-spring), there is only one CARM direction which can yield a DC-based error signal lock with a CARM offset but no DARM offset, which is what we want.

Attachment 1: CARMsweep_DARMspringnospring.png
CARMsweep_DARMspringnospring.png
  1535   Thu Apr 30 15:10:54 2009 robUpdateLockingCARM RF changed to REFL_2I

Quote:
Yoichi, Peter

As Rob suggested, the optimal demodulation phase is easier to find for REFL_2I than POX_1I.
Moreover, for 166MHz LO, we have a phase shifter (delay line) already installed. So we can easily change the demodulation phase of REFL_2I.
Tonight, we switched the RF CARM signal to REFL_2I.
To do so, I changed the signal going to the REFL1 input of the common mode board from POX_1I to REFL_2I.
I moved a BNC-T installed at the output of POX_1I to the REFL_2I output to split the REFL_2I signal and send it to the CM board.
Since the gain of the REFL_2I was about 20dB lower than that of POX_1I, I increased the gain of the SR560, which is installed between the REFL_2 demodulation board and the CM board, from 1 to 10.

With some gain tweaks, we were able to hand off the CARM from REFL_DC to REFL_2I. We also succeeded in switching the REFL_2I ADC channel from PD11 to PD2_DC (the output of the length path from the CM board). This switching is necessary in order to engage the boost on the CM board.

There remains some offset in the CARM when the arm power is maximized. This is expected because the REFL_2I demodulation phase is probably not exactly right.
I will optimize the demodulation phase tomorrow.



From Optickle simulations, it looks like the SRCL/CARM gain ratio at REFL I2 is about 8e-4. So a 1 nanometer offset in SRCL yields 0.8 picometers of offset in CARM.
  1537   Fri May 1 10:04:10 2009 robUpdateLocking166MHz LO phase adjustment

Quote:
I continued to adjust the REFL_2I demodulation phase.
I first optimized the demod phase for SRCL in the DRMI configuration (the error signals were DDs).
Then I restored the full IFO and offset locked it.
Before handing the DARM to RF, I adjusted the 166MHz delay line to maximize the SRCL signal at REFL_2I.
I did this before the DARM RF hand off because changing the delay line setting also changes the AS166 demodulation phase.
After this, I adjusted the digital phase shifter for AS166 to maximize the DARM signal for this port.

I also adjusted the digital demodulation phase of PD11 (REFL_2I) because the optimal demodulation phase for the initial lock acquisition is somewhat (15deg)
different from the optimal demodulation phase for the SRCL when the central part is locked with the DD signals.
This happens because the resonant condition of the central part (lock points of the recycling cavities) changes when the error signals are switched to the DD signals,
due to the offset in the DD signals. This is not good and should be fixed by the optimization of the DD demodulation phases.

Finally, I reduced the CARM offset to zero and tweaked the delay line a bit to maximize the arm power.

Right now, the locking script runs fine until the end.
At the end of the script, I was able to engage the boost on the CM board.



Awesome. Up next: dewhitening.
  1545   Tue May 5 08:26:56 2009 robUpdateLockingDC Readout and DARM response

Quote:
Tonight, I was able to switch the DARM to DC readout a couple of times.
But the lock was not as stable as the RF DARM. It lost lock when I tried to measure the DARM loop gain.

I also measured DARM response when DARM is on RF.
The attached plot shows the DARM optical gain (from the mirror displacement to the PD output).
The magnitude is in an arbitrary unit.

I measured a transfer function from DARM excitation to the DARM error signal. Then I corrected it for the DARM open loop gain and the pendulum response to get the plot below.

There is an RSE peak at 4kHz as expected. The origin of the small bump and dip around 2.5kHz and 1.5kHz are unknown.
I will consult with the Optickle model.
I don't know why the optical gain decreases below 50Hz (I don't think it actually decreases).
Seems like the DARM loop gain measured at those frequencies are too low.
I will retry the measurement.


The optical gain does decrease below ~50Hz--that's the optical spring in action. The squiggles are funny. Last time we did this we measured the single arm TFs to compensate for any tough-to-model squiggles in the transfer functions which might arise from electronics or the suspensions.
  1548   Tue May 5 11:44:33 2009 robUpdateLocking DARM response

Here's the RF DARM optical response, on the anti-spring side, from optickle. Note that for the f1 sideband, changing the demod phase mostly adjusts the overall gain, while for the f2 sideband a change in demod phase alters the shape of the response. This is the quadrature-selecting power of using a single RF sideband as a local oscillator.
Attachment 1: DARMtf_nospring.png
DARMtf_nospring.png
Attachment 2: DARMtf_demodphases.png
DARMtf_demodphases.png
  1549   Tue May 5 14:02:16 2009 robUpdateLSCDARM DC response varies with DARM offset

Note the effect of quadrature rotation for small offsets.

Attachment 1: DARM_DARM_AS_DC_2.png
DARM_DARM_AS_DC_2.png
Attachment 2: DARM_DARM_AS_DC_3.png
DARM_DARM_AS_DC_3.png
Attachment 3: DARM_DARM_AS_DC_2.pdf
DARM_DARM_AS_DC_2.pdf
Attachment 4: DARM_DARM_AS_DC_3.pdf
DARM_DARM_AS_DC_3.pdf
  1559   Thu May 7 23:34:59 2009 robUpdateSEIseisBLRMS already lost

Can't find hostname 'fb40m'

 

it only lasted a few hours

  1579   Wed May 13 02:53:12 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

  1582   Wed May 13 14:43:29 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

Quote:

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

 Lies!  The problem was not resolved. The plot shows a 2-day trend, with the onset of the problem yesterday clearly visible as well as the ineffectiveness of the soft-reboot done yesterday.   So we'll try a hard-reboot.

Attachment 1: MC3sidemon.png
MC3sidemon.png
  1584   Thu May 14 00:15:39 2009 robSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.
Attachment 1: sidemon.png
sidemon.png
  1591   Fri May 15 17:30:00 2009 robUpdateLSCarms, coils, locks

This is the two arms locked, for an hour.  No integrator in either loop, but from this it looks like ETMY may have a bigger length2angle problem than ETMX.  I'll put some true integrators in the loops and do this again.

 

 

Attachment 1: armslock_no_int.png
armslock_no_int.png
  1592   Sat May 16 16:20:33 2009 robUpdateLSCarms, coils, locks, #2

Quote:

This is the two arms locked, for an hour.  No integrator in either loop, but from this it looks like ETMY may have a bigger length2angle problem than ETMX.  I'll put some true integrators in the loops and do this again.

 

 

 There appear to be at least two independent problems: the coil balancing for ETMY is bad, and something about ITMX is broken (maybe a coil driver). 

The Y-arm becomes significantly misaligned during long locks, causing the arm power to drop.  This misalignment tracks directly with the DC drive on ETMY.  Power returns to the maximum after breaking and re-establishing lock.

ITMX alignment wanders around sporadically, as indicated by the oplevs and the X-arm transmitted power.  Power returns to previous value (not max) after breaking and re-establishing lock.

Both loops have integrators.

Attachment 1: twoproblems.png
twoproblems.png
Attachment 2: coil_imbalanceETMY.png
coil_imbalanceETMY.png
Attachment 3: ITMXalignment.png
ITMXalignment.png
  1594   Sun May 17 20:50:38 2009 robOmnistructureEnvironmentmag 5.0 earthquake in inglewood

2009 May 18 03:39:36 UTC

Earthquake Details

Magnitude 5.0
Date-Time
  • Monday, May 18, 2009 at 03:39:36 UTC
  • Sunday, May 17, 2009 at 08:39:36 PM at epicenter
Location 33.940°N, 118.338°W
Depth 13.5 km (8.4 miles)
Region GREATER LOS ANGELES AREA, CALIFORNIA
Distances
  • 2 km (1 miles) E (91°) from Lennox, CA
  • 2 km (1 miles) SSE (159°) from Inglewood, CA
  • 3 km (2 miles) NNE (22°) from Hawthorne, CA
  • 7 km (4 miles) ENE (72°) from El Segundo, CA
  • 15 km (10 miles) SSW (213°) from Los Angeles Civic Center, CA
Location Uncertainty horizontal +/- 0.4 km (0.2 miles); depth +/- 0.9 km (0.6 miles)
Parameters Nph=139, Dmin=7 km, Rmss=0.42 sec, Gp= 40°,
M-type=local magnitude (ML), Version=C
Source
Event ID ci10410337
  1595   Sun May 17 21:45:40 2009 robUpdateASCITMX oplev centered
  1605   Tue May 19 12:30:41 2009 robConfigurationSUSETMY f2pRatio script run

Quote:
Now that the ETMY optical lever is not so bad, I ran the f2pRatio script and it seems to have worked.

I cleaned up the script a little also. Updated in the SVN.

ETMY's A2L scripts have to be run to reduce the A2L noise once the arm is locked again. Might also need
to set the OL UGF too.


Just to show, in part, what the script does.

The F2A filters are turned on at 12:21, and the oplev no longer responds to large LSC drives in ETMY.
Attachment 1: f2ademo.png
f2ademo.png
  1615   Thu May 21 12:58:32 2009 robConfigurationALARMPEM count-half disabled

I've disabled the alarm for PEM_count_half, using the mask in the 40m.alhConfig file.  We can't do anything about it, and it's just annoying.

  1619   Fri May 22 00:43:24 2009 robConfigurationComputer Scripts / ProgramsIFO configure scripts for XARM and YARM

I edited the configure scripts (those called from the C1IFO_CONFIGURE screen) for restore XARM and YARM.  These used to misalign the ITM of the unused arm, which is totally unnecessary here, as we have both POX and POY.  They also used to turn off the drive to the unused ETM.  I've commented out these lines, so now running the two restores in series will leave a state where both arms can be locked.  This also means that the ITMs will never be deliberately mis-aligned by the restore scripts.

  1623   Sun May 24 11:24:08 2009 robUpdateComputerselog restarted

I just restarted the elog.  It was crashed for unknown reasons.  The restarting instructions are in the wiki.

  1625   Tue May 26 17:05:44 2009 robUpdatePSLMOPA re-activated

steve, rob, alberto

 

Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line.  After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end.  This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa.  This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference. 

Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter. 

We also re-discovered that the 40m procedures manual contains an error.  To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER.  The proc man says ON, RS-232, RUN/STOP.

The laser power is at 1.5W and climbing.

Attachment 1: DSC_0513.JPG
DSC_0513.JPG
Attachment 2: DSC_0517.JPG
DSC_0517.JPG
  1626   Tue May 26 17:34:14 2009 robUpdatePSLMOPA re-deactivated

Quote:

steve, rob, alberto

 

Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line.  After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end.  This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa.  This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference. 

Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter. 

We also re-discovered that the 40m procedures manual contains an error.  To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER.  The proc man says ON, RS-232, RUN/STOP.

The laser power is at 1.5W and climbing.

 Rob, Alberto

The chiller HT alarm started blinking, as the water temperature had reached 40 degrees C, and was still rising.  We turned off the MOPA and the chiller.  Maybe we need to open the needle valve a bit more?  Or maybe the flow needs to be reversed?  The labels on the MOPA are backwards?

Attachment 1: laser_temp.jpg
laser_temp.jpg
  1627   Wed May 27 10:54:09 2009 robUpdatePSLwe don't understand the chiller (broken)

Quote:

Quote:

steve, rob, alberto

 

Steve installed two rotary flow meters into the MOPA chiller system--one at the chiller flow output and one in the NPRO cooling line.  After some hijinks, we discovered that the long, insulated chiller lines have the same labels at each end.  This means that if you match up the labels at the chiller end, at the MOPA end you need switch labels: out goes to in and vice-versa.  This means that, indubitably, we have at some point had the flow going backwards through the MOPA, though I'm not sure if that would make much of a difference. 

Steve also installed a new needle valve in the NPRO cooling line, which works as expected as confirmed by the flow meter. 

We also re-discovered that the 40m procedures manual contains an error.  To turn on the chiller in the MOPA start-up process, you have to press ON, then RS-232, then ENTER.  The proc man says ON, RS-232, RUN/STOP.

The laser power is at 1.5W and climbing.

 Rob, Alberto

The chiller HT alarm started blinking, as the water temperature had reached 40 degrees C, and was still rising.  We turned off the MOPA and the chiller.  Maybe we need to open the needle valve a bit more?  Or maybe the flow needs to be reversed?  The labels on the MOPA are backwards?

 The chiller appears to be broken.  We currently have it on, with both the SENSOR and RS-232 unplugged.  It's running, circulating water, and the COOL led is illuminated.  But the temperature is not going down.  The exhaust out the back is not particularly warm.  We think this means the refrigeration unit has broken, or the chiller computer is not communicating with the refrigerator/heat exchanger.  Regardless, we may need a new chiller and a new laser.

  1628   Wed May 27 15:59:44 2009 robUpdatePSLwe don't understand the chiller (broken)

steve, alberto, rob

After some futzing around with the chiller, we have come to the tentative conclusion that the refrigeration unit is not working.  Steve called facilities to try to get them to recharge the refrigerant (R-404a) tomorrow, and we're also calling around for a spare chiller somewhere in the project (without luck so far).

  1629   Thu May 28 14:34:25 2009 robUpdatePSLchiller diagnosis

Quote:

steve, alberto, rob

After some futzing around with the chiller, we have come to the tentative conclusion that the refrigeration unit is not working.  Steve called facilities to try to get them to recharge the refrigerant (R-404a) tomorrow, and we're also calling around for a spare chiller somewhere in the project (without luck so far).

 The repair man thinks it's a bad start capacitor, which is 240uF at 120V.  Steve has ordered a new one which should be here tomorrow, and with luck we'll have lasing by tomorrow afternoon.

ELOG V3.1.3-