40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 33 of 344  Not logged in ELOG logo
IDup Date Author Type Category Subject
  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.

  1616   Thu May 21 18:05:03 2009 peteUpdateSUSETMX coils look OK

Quote:

I checked the four rear coils on ETMX by exciting XXCOIL_EXC channel in DTT with amplitude 1000@ 500 Hz and observing the oplev PERROR and YERROR channels.  Each coil showed a clear signal in PERROR, about 2e-6 cts.  Anyway, the coils passed this test.

 

 I also made xfer fctns of the 4 piston coils on ETMY and ETMX with OL_PIT.  (I looked at all 4 even though the attached plot only shows three.)  So it looks ike the coils are OK.

Attachment 1: etmx_etmy_coils.pdf
etmx_etmy_coils.pdf
  1617   Thu May 21 18:07:32 2009 ranaUpdatePSLScrew on Needle valve loosened
Alberto and I went in to loosen up the needle valve yesterday around 4:30 PM. The idea was to cut down on
the flow to the NPRO so that the cooling power of the chiller would be used almost entirely on the
amplifier instead of the NPRO block.

The need valve was basically all the way open. The lock nut was screwed in all the way and stuck. By using
pliers and a wrench for the nut, we freed the lock nut. Even so, the screw for the needle valve seemed to
be bad: I think the thread is stripped; it doesn't go down even after several turns. I even tried to squirt
alchohol on it and really press down in the hopes of catching a thread. It may have closed slightly but its
impossible to be sure.

I also increased the NPRO diode current to the max (+0.1 A). This got us a little bit of NPRO power and
I hope some more AMPMON stability. The attached plot shows 4 days of minute trend. If you squint you
might believe that we got some suppression in the HTEMP fluctuations over the last two days.
Attachment 1: Untitled.png
Untitled.png
  1618   Thu May 21 18:21:57 2009 ranaSummaryTreasureYoichi's words

Yoichi's final words on what do next with the interferometer (as of 5 PM on May 21, 2009):

  1. Measure laser noise couplings in spring and anti-spring configurations.
  2. Dewhitening filter turn on for the ETMs.
  3. Noisebudget - import from the sites.
  4. Stabilize CM handoff.

My personal sub-comments to these bullets:

  1. For the laser noise I'm not sure that we will be able to understand these if the couplings are mainly from junk light due to accidental HOM resonances.
  2. WE should look into putting a static passive stage of filtering into the ETMs if warranted by the NB.
  3. Because of the sad track record with this, I will start us off this time by importing and modifying the H1/L1 versions.
  4. I guess we can do this by just acquiring on MC2 with the huge CARM offset. It works for the single arm so it should work for offset CARM.
  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.

  1620   Fri May 22 01:27:14 2009 peteUpdateSUS200 days of MC3 side

Looks like something went nuts in late April.  We have yet to try a hard reboot.

Attachment 1: mc3_side_200days.png
mc3_side_200days.png
  1621   Fri May 22 17:03:14 2009 rob, steveUpdatePSLMOPA takes a holiday

The MOPA is taking the long weekend off.

Steve went out to wipe off the condensation inside the MOPA and found beads of water inside the NPRO box, perilously close to the PCB board.  He then measured the water temperature at the chiller head, which is 6C.  We decided to "reboot" the MOPA/chiller combo, on the off chance that would get things synced up.  Upon turning off the MOPA, the neslab chiller display immediately started displaying the correct temperature--about 6C.  The 22C number must come from the MOPA controller.  We thus tentatively narrowed down the possible space of problems to: broken MOPA controller and/or clog in the cooling line going to the power amplifier.  We decided to leave the MOPA off for the weekend, and start plumbing on Tuesday.  It is of course possible that the controller is the problem, but we think leaving the laser off over the weekend is the best course of action.

 

 

  1622   Fri May 22 17:05:24 2009 rob, peteUpdateComputershard reboot of vertex suspension controllers

we did a hard reboot of c1susvme1, c1susvme2, c1sosvme, and c1susaux.  We are hoping this will fix some of the weird suspension issues we've been having (MC3 side coil, ITMX alignment).

  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.

  1624   Mon May 25 21:31:47 2009 carynUpdatePEMplugged in Guralp channels

Guralp Vert1b and Guralp EW1b are plugged back in to PEM ADCU #10 and #12 respectively. Guralp NS1b remains plugged in. So,  PEM-SEIS_MC1_X,Y,Z should now corrsp to seismometer as before.

  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.

  1630   Thu May 28 18:41:26 2009 steveUpdatePSLthe saga of the chiller is ending

I drained the water and removed side covers from the Neslab RTE 140 refrigerated water cooler unit this morning. The hoses to the laser were disconnected.

This abled you to see the little window of refregerant  R404A was free of bubles, meaning: no recharge was needed.

The circulator bath was refilled with 7 liters of Arrowhead distilled water and the unit was turned on.

The water temp was kept 20.00+- .05C without any load. Finally the AC-repair man Paul showed up.

He measured the R404A level to be as specified: 23-24 PSI on the suction side and 310 PSI on the discharge side.

The unit was working fine. Paul found an intermittently functioning starting capacitor on the compressor  that was removed.

The 240 micro Farad 120VAC cap will arrive tomorrow

  1631   Fri May 29 18:57:09 2009 steveUpdatePSLthe laser is back

Steve, Rob and Alberto

 

Starting capacitor 216 miroFarad was installed on the compressor. Water lines were connected to the MOPA as corrected, so the flow meter readings are logical.

Now IN means flowing water in the direction of black arrow on the hose.

We struggled with the Neslab presetting:  temp, bauds rate  and other  unknowns  till Rob found the M6000 manual on Peter king's website.

Alberto realized that the chiller temp had to be reset to 20C on water chiller.

I put 1mg of Chloramin T into the water to restrict the growth of algae in the bath.

The NPRO heat sink  was around ~20C without flow meter wheel rotation  and the PA body ~25C by touch of a finger

I just opened up the needle valve a litle bit so the flow meter wheel would started rotating slowly.

That small glitch at the end of this 3 hrs plot shows this adjustment.

Attachment 1: laserisback.jpg
laserisback.jpg
  1632   Sat May 30 11:24:56 2009 robConfigurationPSLNPRO slow scan

I'm setting SLOWDC to about -5.

I had to edit FSSSlowServo because it had hard limits on SLOWDC at (-5 and 5).  It now goes from -10 to 10.

 

 

Attachment 1: slowSCAN.png
slowSCAN.png
  1633   Sat May 30 12:03:34 2009 robUpdatePSLMC locked

I locked to PSL loops, then tweaked the alignment of the MC to get it to lock. 

I first steering MC1 until all the McWFS quads were saturated.  This got the MC locking in a 01 mode.  So I steered MC1 a little more till it was 00.  Then I steered MC2 to increase the power a little bit.  After that, I just enabled the MC autolocker.

  1634   Sat May 30 12:36:52 2009 robUpdateComputersc1susvme2, c1iscex running late

c1susvme2 has been running just a bit late for about a week.  I rebooted it. 

The plot shows SRM_FE_SYNC, which is the number of times in the last second that c1susvme2 was late for the 16k cycle.   Similarly for ETMX.

 

Attachment 1: srmsync.jpg
srmsync.jpg
Attachment 2: etmxsync.jpg
etmxsync.jpg
  1635   Mon Jun 1 13:25:00 2009 robUpdateComputersc1susvme2, c1iscex running late

Quote:

c1susvme2 has been running just a bit late for about a week.  I rebooted it. 

The plot shows SRM_FE_SYNC, which is the number of times in the last second that c1susvme2 was late for the 16k cycle.   Similarly for ETMX.

 

 

The reboot appears to have worked.

Attachment 1: doublesync.jpg
doublesync.jpg
  1636   Mon Jun 1 13:56:52 2009 AlbertoUpdatePSLLaser Power after fixing the laser chiller

The laser power seems to have become more stable after fixing the laser chiller. The power is lower than it used to be (MOPA amplitude 2.5 versus 2.7) but, as shown in the attchement, it became more steady.

Attachment 1: MOPAtrend.jpg
MOPAtrend.jpg
  1637   Mon Jun 1 14:33:42 2009 robConfigurationComputer Scripts / Programsop540m Monitor added to web status

I added op540m's display 0 (the northern-most monitor in the control room) to the MEDM screens webpage: https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

 

Now we can see the StripTool displays that are usually parked on that screen.

 

 

  1638   Mon Jun 1 14:49:07 2009 robSummaryPSLpsl thoughts

Some thoughts on what happened with the MOPA cooling. 

Some unknown thing happened to precipitate the initial needle valve jiggle, which unleashed a torrent of flow through the NPRO.  This flow was made possible by the fact that the cooling lines are labeled confusingly, and so flow was going backwards through the needle valve, which was thus powerless to restrict it.  The NPRO got extremely cold, and most of the chiller's cooling power was being used to unnecessarily cool the NPRO.  So, the PA was not getting cooled enough.  At this, point, reversing the flow probably would have solved everything.  Instead, we turned off the chiller and thus discovered the flaky start-motor capacitor. 

Now we have much more information, flow meters in the NPRO and main cooling lines, a brand-new, functioning needle valve, a better understanding of the chiller/MOPA settings necessary for operation, and the knowledge of what happens when you install a needle valve backwards.

 

  1639   Mon Jun 1 15:01:31 2009 ranaUpdatePSLLaser Power after fixing the laser chiller: more traces
If you look at the correlation between RMTEMP and HTEMP, you see what we knew: namely that there
was a 1:1 correlation before. After the chiller fix, I can see no correlation between the room and
amplifier temperature at the resolution of 10:1. So the chiller loop has a gain > 10 at 24 hour time
scales.

I don't understand why the PMC looks more stable.
Attachment 1: Picture_7.png
Picture_7.png
  1640   Mon Jun 1 19:19:26 2009 ranaUpdatePSL1000 days of hour-trend
Attachment 1: u.png
u.png
  1641   Tue Jun 2 02:28:58 2009 peteUpdateLockingDD handoff work

alberto, pete

 

We worked on tuning the DD handoff tonight.  We checked the DD PD alignments and they looked fine.  First I tuned the 3 demod phases to minimize offsets.  Then I noticed that the post-handoff MICH xfer function needed an increase in gain to look like the pre-handoff xfer function (which has a UGF of about 25 Hz).  I increased the MICH PD9_Q gain from 2 to 7 in the input matrix.   But, the handoff to PRC still failed, so tomorrow we will try to find out why.

In the plot, ref0 is before MICH handoff, and ref1 is after MICH handoff.  There is also a PRC trace (before PRC handooff).

 

 

Attachment 1: mich_dd.pdf
mich_dd.pdf mich_dd.pdf
  1642   Tue Jun 2 23:12:08 2009 robConfigurationComputersntp on op440m

I restarted ntpd on op440m to solve a "synchronization error" that we were having in DTT.  I also edited the config file (/etc/inet/ntp.conf) to remove the lines referring to rana as an ntp server; now only nodus is listed.

To do this:

log in as root

/usr/local/bin/ntpd -c /etc/inet/ntp.conf

  1643   Tue Jun 2 23:53:12 2009 peteDAQComputersreset c1susvme1

rob, alberto, rana, pete

we reset this computer, which was out of sync (16384 in the FE_SYNC field instead of 0)

  1644   Tue Jun 2 23:55:45 2009 AlbertoUpdateoplevsoplevs centerd

Tonight I centered the oplevs for ITMX/Y, SRM, PRM, BS.

After doing that I noticed that the BS drifted a little from where I had set it.

  1645   Wed Jun 3 03:22:16 2009 peteUpdateLockingDD handoff

Rana, Alberto, Pete

We have the DD handoff nominally working.  Sometimes, increasing the SRC gain at the end makes MICH get unstable.  This could be due to a non-diagonal term in the matrix, or possibly because the DRM locks in a funky mode sometimes. 

To get the DD handoff working, first we tuned demod phases in order to zero the offsets in the PD signals handed-off-to.  Based on transer function measurements, I set the PRC PD6_I element to 0.1, and set the PD8_I signal to 0, since it didn't seem to be contributing much.  We also commented out the MICH gain increase at the end of the DD_handoff script.

It could still be more stable, but it seems to work most of the time.

 

 

  1646   Wed Jun 3 03:30:52 2009 ranaUpdateMOPANPRO current adjust
I increased the NPRO's current to the max allowed via EPICS before the chiller shutdown. Yesterday, I did this
again just to see the effect. It is minimal.

If we trust the LMON as a proportional readout of the NPRO power, the current increase from 2.3 to 2.47 A gave us
a power boost from 525 to 585 mW (a factor of 1.11). The corresponding change in MOPA output is 2.4 to 2.5 W
( a factor of 1.04).

Therefore, I conclude that the amplifier's pump has degraded so much that it is partially saturating on the NPRO
side. So the intensity noise from NPRO should also be suppressed by a similar factor.

We should plan to replace this old MOPA with a 2 W Innolight NPRO and give the NPRO from this MOPA back to the
bridge labs. We can probably get Eric G to buy half of our new NPRO as a trade in credit.
Attachment 1: Untitled.png
Untitled.png
  1647   Wed Jun 3 11:28:01 2009 carynUpdatePEMUnplugged Guralp channels
  1648   Wed Jun 3 12:31:13 2009 carynUpdatePEMplugged in guralp channels
  1649   Wed Jun 3 18:55:27 2009 ranaUpdateCOCsnapshot of upgrade layout
Attachment 1: layout.png
layout.png
  1650   Thu Jun 4 01:32:20 2009 robConfigurationLSCAS port mode scan

Here is a set of mode scans of the AS port, using the OMC as a mode scanner.  The plot overlays various configurations of the IFO.  

To remove PZT nonlinearity, each scan was individually flattened in fsr-space by polynomial (3rd order) fitting to some known peak locations (the carrier and RF sidebands).
 

Attachment 1: modes.png
modes.png
  1651   Thu Jun 4 15:53:15 2009 steveUpdatePSLNPRO cooling flowrate adjusted

The Neslab chiller is working well. It's temp display shows 20.0 C rock solid. Flow meter rotating at 13.5Hz at the out put of the chiller.

The MOPA temp was measured with a hand held thermocouple . The  PA was  34 C and 29 C at NPRO heat sink.

The NPRO flow meter was not rotating at this time. There was just trickeling water flow though the meter.

I closed the needle valve this point. It needed 8 turns clockwise. This drives head temp to 19.9 C

Than I opened the needle valve 9 turns and the flow meter wheel was  rotaing at ~ 1 Hz

We gained a little power. Can you explain this?

 

Attachment 1: needlevalve.jpg
needlevalve.jpg
  1652   Thu Jun 4 16:54:19 2009 peteUpdateLockingdaytime DD handoff

I played with the DD handoff during the day.  The DRM dark port was flickering like a candle flame in Dracula's castle.  The demod offsets for the handoff signals looked fine.  After MICH handoff, the MICH_CTRL started to get unstable at some low frequency, maybe 3 Hz (I didn't measure).  So I increased the MICH gain from 0.1 to 0.17 and it settled down.  PRC and SRC went fine.  Then the DD_handoff script raised the MICH gain to 0.7, and an instability started to grow in MICH_CTRL (at some higher frequency).  I decreased the MICH gain from 0.7 to 0.5, and it settled down and stayed stable.

  1653   Thu Jun 4 23:39:23 2009 peteUpdatePEM5 days, 20 days of accelerometers

Looks like yesterday was particularly noisy.  It's unclear to me why diurnal variation much more visible in MC1_Y, and why the floor wanders.

 

The first plot shows 5 days.  The second plot shows 20 days.

Attachment 1: acc_5day.png
acc_5day.png
Attachment 2: acc_20days.png
acc_20days.png
  1654   Fri Jun 5 01:10:13 2009 rob, peteUpdateLockingundermined

We were stymied early in the evening by a surreptitiously placed, verbo-visually obfuscated command in the drstep script. 

  1655   Fri Jun 5 02:59:03 2009 pete, albertoUpdateLockingtdsavg failure in cm_step script

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

  1656   Fri Jun 5 13:51:49 2009 robUpdateLockingtdsavg failure in cm_step script

Quote:

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

 Did you try restarting the framebuilder?

 

What you type is in bold:

op440m> telnet fb40m 8087

daqd> shutdown

 

  1657   Fri Jun 5 16:45:28 2009 rob, peteHowToComputerstdsavg failure in cm_step script

Quote:

Quote:

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

 Did you try restarting the framebuilder?

 

What you type is in bold:

op440m> telnet fb40m 8087

daqd> shutdown

 

Restarting the framebuilder didn't work, but the problem now appears to be fixed.

Upon reflection, we also decided to try killing all open DTT and Dataviewer windows.  This also involved liberal use of ps -ef to seek out and destroy all diag's, dc3's, framer4's, etc.

 

That may have worked, but it happened simultaneously to killing the tpman process on fb40m, so we can't be sure which is the actual solution.

 

To restart the testpoint manager:

what you type is in bold:

rosalba> ssh fb40m

fb40m~> pkill tpman

The tpman is actually immortal, like Voldemort or the Kurgan or the Cylons in the new BG.  Truly slaying it requires special magic, so the pkill tpman command has the effect of restarting it.

 

In the future, we should make it a matter of policy to close DTTs and Dataviewers when we're done using them, and killing any unattended ones that we encounter.

 

  1658   Fri Jun 5 17:22:55 2009 peteUpdateLockingdaytime locking

After fixing the tp problem, I tried locking again.  Grabbing and DD handoff, no problem.  Died earlier than last night, handing off CARM to REFL_DC, around arm power of 4 or so.  Seems to happen after turning off the moving zero, Rob says it might be touchy in daytime.

  1659   Sat Jun 6 01:44:53 2009 rob UpdateLocking?

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

  1660   Sun Jun 7 04:57:39 2009 YoichiUpdateLocking?

Quote:

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

 I've seen this before. At that time, the problem was gone spontaneously the next day.

You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.

 

  1661   Mon Jun 8 18:22:27 2009 AlbertoDAQLSCAdded PD11 I amd Q slow channels

I just added two slow channels to C0EDCUEPICS to monitor the input of PD11. The names are:

[C1:LSC-PD11_I_INMON]
[C1:LSC-PD11_Q_INMON]

  1662   Tue Jun 9 11:29:07 2009 JenneUpdateoplevsMeasured ETMY oplev beam size...put everything back

I measured the ETMY oplev beam size at a couple different distances away from the HeNe by taking out the steering mirror and letting the light propagate a ways.  I put the steering mirror back, aligned the oplev, and was able to relock the Yarm, so I think it's all back as it has been the last couple of weeks.

 

Now I need t o do some geometry and ray-tracing matrices to decide what focal length lens to buy, then we'll have  a shiny new ETMY oplev. 

  1663   Tue Jun 9 23:25:24 2009 robUpdateLocking?

Quote:

Quote:

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

 I've seen this before. At that time, the problem was gone spontaneously the next day.

You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.

 

 

Well, it hasn't gone away yet.  It happened Sat, Mon, and Tues afternoon, as well as Friday.  The threshold varies slightly, but is always around ~200-300 cnts.   I've tried reducing the offset with the signal coming from the CM board and the signal not going through the CM board, I've also tried jumping the signal to zero (rather than a gradual reduction). 

Tonight we'll measure the MC length and set the modulation frequencies, and maybe try some MZ tweaking to do RFAMMon minimization.    

  1664   Wed Jun 10 01:52:34 2009 AlbertoUpdateElectronicsMC length and Marconis' frequencies

Pete, Rob, Alberto,

yesterday we thought that some of the problems we were having in locking the IFO might be related to a change of the length of the mode cleaner. So today we decided to measure it again.

We followed the Sigg-Frolov technique (see 40m Wiki, Waldman, Fricke). For the record, the MC_AO input corresponds to IN2 on the MC Servo board.

We obtained: L = 27.092 +/- 0.001 m

From the new measurement we reset the frequencies of the Marconis to the following values:

33196450 Hz

132785800 Hz

165982250 Hz

199178700 Hz

 

ELOG V3.1.3-