40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 268 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  3859   Thu Nov 4 03:13:46 2010 SureshUpdateLockingFibre coupling 1064nm light at the south-end table

[Kiwamu, Suresh]

We decided to use the 1064nm beam reflected from the Y1-1037-45-P mirror after the collimation lens following the doubling crystal for coupling into the optical fiber (ref 3843 and 3847 ).

We replaced a beam dump which was blocking this beam with a Y1-1037-45-P mirror and directed the beam into the fiber coupler with another Y1-1037-45-P.  The power in this beam was about 1W.  This has been stepped down to 10mW by introducing a reflective ND filter of OD=2.  The reflected power has been dumped into a blade-stack beam dump.

Steve has ordered the The Visual Fault Locator from Fluke.  It is expected to arrive within a day or two.



  3858   Wed Nov 3 23:58:45 2010 ranaUpdateElectronicsCougars

I looked at this web page: http://www.teledyne-cougar.com/Index.asp for the RF company that Rich has recently started using.

There are ~15 amplifiers that they sell which have a NF < 2 dB and work in the 10-100 MHz band. We should call them to find out if they will package some amps for us or at least sell us a few with eval. boards so that we can make our own.

  3857   Wed Nov 3 21:19:40 2010 yutaUpdateCDSput LOCKIN to c1ioo model and checked

(Joe, Yuta)

  LOCKIN(consists of oscillator and demodulator) is needed for A2L measurement.
  So, we put LOCKIN to c1ioo model, whose outputs goes to c1mcs ASC.
  After that, I checked the functionality of LOCKIN by directly connecting DAC output for a coil to ADC input for MCL with BNC cable.

What we did:
[Putting LOCKING to c1ioo model]
1. Copied Simulink LOCKIN stuff(cdsOsc, Product, cdsPhase ...) from /cvs/cds/caltech/cds/rward-advLigo/src/epics/simLink/omc.mdl and put it into c1ioo model.

2. Copied MEDM screen file /cvs/cds/caltech/medm/c1/omc/C1OMC_LSC_LOCKIN.adl and modified it for our use.

[Checking LOCKIN]
3. Disconnected MC2_ULCOIL input to SOS Coil driver at 1X4-1-6A and checked the signal from software oscillator at c1ioo is coming.

4. Disconnected the cable labeled "MC OUT1" at 1X2 (which is MCL signal to ADC) and put MC2_ULCOIL output directly using long BNC cable.

5. Checked the functionality of LOCKIN by StripTool.
   The cable wiring did not conflict with my expectation.
   Software mixer is working.(frequency is doubled. X_SIN has offset and X_COS doesn't)

6. Put the cables back.


  Thanks to c1rfm, c1ioo and c1sus are talking without ADC timeout.
  Also, LOCKIN is working fine.

Attachment 1: Screenshot_C1IOO_LOCKIN.png
  3856   Wed Nov 3 19:14:00 2010 ranaUpdatePSLPMC mode matching update

I moved the lens just before the PMC to check the mode matching landscape. The PMC trans went up from ~6.5 to ~6.8. That's 5% with ~1 hour of work.

As per the micrometer, this took ~7-8 mm of travel. Since there's so much power left in the HOMs, we we we will have to do a proper mode scan and re-calculate the solution.

The measured transmission is now ~610 mW. The power reflected from the PMC with it unlocked is ~1400 mW.

  3855   Wed Nov 3 17:01:01 2010 josephbSummaryCDSComparison of RFM read times


RFM reads are slow.  Rolf has said it should take 2-3 microseconds per read. 

c1sus is taking about 7 microseconds per read, twice as slow as Rolf's claim.


The RFM card is in the IO chassis, and is sharing the PCIe bus with 4 ADC cards, 3 DAC cards, 4 BO cards, and a BIO card.  Its possible this crowded bus is causing the reads to take even longer.

Test Results:

Compare read times between the c1sus computer, which has its RFM card in the IO chassis, to c1ioo, which has its RFM card in the computer.


No RFM reads: 8 microseconds

3 RFM reads: 20 microseconds (~4 per read)

6 RFM reads: 32 microseconds (~4 per read)


No RFM read: 25 microseconds (bigger model)

1 RFM read: 33 microseconds (~8 per read)

3 RFM read: 45 microseconds (~7 per read)

6 RFM read: Over 62 microseconds, doesn't run.


It looks like moving the RFM card may help by about a factor of 2 in read speed, although its still not quite what Alex and Rolf claim it should be.

The c1mcs and c1ioo models have been reverted to their normal operations.


  3854   Wed Nov 3 16:49:31 2010 steveUpdateGeneralstorage cabinet is in place

The south end of IFO room 104 was reshuffled. The flow bench was moved all the way to the south end to create more room for the crane reach. The old  large drawing cabinet  was moved under the vacuum tube.

The new clear view through  Acrylic-plexyglass cabinet is anchored. It has powder finished coating so it will not out-gas too much.The back side shelf mounting holes are sealed off with kapton tape. The doors still needs some gaskit seals.

Attachment 1: P1070018.JPG
  3853   Wed Nov 3 15:13:55 2010 josephbUpdateCDSTemporary RFM slow read work around


Each RFM read in the c1mcs model is adding ~7 microseconds to the cycle time.  Adding too many pushes it over the 62 microsecond limit.

RFM writes do not have this problem.

Temporary Solution:

The fastest fix was to create a new front end model, called c1rfm, which does nothing but read in the MC1, MC2, MC3 PIT and YAW signals from the c1ioo machine, and then passes them along to the c1mcs model via shared memory, which is fast.

This means the data being sent is 2 cycles slow, one to go over the RFM, and one to go over shared memory.  It is running at 16384 cycles/second, so it shouldn't have much impact at the frequencies we use those channels for.

MC_L is still being sent directly to the c1mcs front end code via RFM.

Current Status:

The c1mcs model is running at  30-33 microseconds for CPU time.

The c1rfm model is running at 45-47 microseconds for CPU time.

All 7 channels, MC_L, MC1_PIT, MC1_YAW, MC2_PIT, MC2_YAW, MC3_PIT, MC3_YAW are responding.

The c1rfm model was added to the /diskless/root/etc/rtsystab file on the fb machine so that it automatically starts on the reboot of c1sus.

The USR and CPU time channels for c1rfm were added to the MCS_SLOW.ini file in /opt/rtcds/caltech/c1/chans/daq/ so that the framebuilder records them, namely:


The framebuilder was restarted to take these new channels into account.


Finish implementing and debugging the "round robin" RFM reader so as to not require a seperate model to be doing RFM reads in parallel.

Look into improving read speed by either merging timestamps and data into a single  or reading time stamp once every tenth or hundreth cycle, although this at best provides a factor of 2 improvement.

Check to see if RFM card being on the IO chassis or directly in the computer chassis makes a difference.

Get Alex and Rolf to improve RFM read speed.

  3852   Wed Nov 3 09:32:00 2010 ranaSummaryCDSEurocard board swapping

When swapping Eurocard boards, it is safest to first turn down the power supplies and then do the swapping.

Otherwise, it is sometimes the case that people plug in the board slowly and/or asymmetrically. This can cause the opamp to see one of the power supply rails without the other (e.g. +15 but not -15).

This can destroy some opamps. The true danger is that there may be damage to the board which you do not notice for several months, thereby leaving a timebomb for the next person.

Don't be an electronics terrorist!

  3851   Wed Nov 3 03:00:47 2010 KojiSummaryGreen Lockingcoarse locked green beat frequency

Wow! Great guys!!

Can I expect to see the spectra of the frequency counter output with and without the servo?

RA: I think the SBP-70 is a bad idea. It limits the capture range. So does the SHP-25. You should instead just use a DC-block; the SR620 should work from 1-200 MHz with no problems.

Also, we have to figure out a better solution for the DAC at the ends: we cannot steal the QPD gain slider in the long run and the 4116 DAC at the ends has all 8 channels used up. Should we get the purple box for testing or should we try to use the fast DAC in the EX IO chassis as the actuator?

  3850   Wed Nov 3 02:37:39 2010 yutaSummaryGreen Lockingcoarse locked green beat frequency

(Kiwamu, Yuta)

We succeeded in coarse locking the green beat frequency, using a frequency counter and feeding back the signal to the X-end laser temperature.

  beat note -> RF PD -> SHP-25 -> SLP-100 -> ZFL-1000LN -> ZFL-1000LN -> ZFL-500LN -> ZFRSC-42 -> SBP-70 -> ZFRSC-42 -> SR620 -> c1psl(C1:PSL-126MOPA_126MON)
  c1auxey(C1:LSC-EX_GREENLASER_TEMP) -> X-end laser temp

  The frequency counter SR620 converts the beat frequency to voltage.
  We added some filters (SHP-25, SLP-100, SBP-70). Otherwise, SR620 doesn't count the frequency correctly.

What we did:

  1. Getting green beat note again
     Set PSL laser temp to 31.81 °C and X-end laser temp to 37.89 °C.
     Set PPKTP crystal temp to 37.6 °C, which maximizes output green beam power.

  2. ADC channel and DAC channel
     Disconnected one channel going into VME-3123 (at 1X1) and used c1psl's C1:PSL-126MOPA_126MON as ADC channel for the output from SR-620
     Made a new DAC channel on c1auxey named C1:LSC-EX_GREENLASER_TEMP, and disconnected one channel from VME-4116 (at 1X9) to use it as DAC channel for X-end laser temperature control.

  3. Coarse lock by ezcaservo
        ezcaservo C1:PSL-126MOPA_126MON -s 150 -g -0.0001 C1:LSC-EX_GREENLASER_TEMP
     "-s" option is a set value. The command locks C1:PSL-126MOPA_126MON to 150 (in counts), using 0Hz pole integrator.

  The beat frequency locked on to ~77MHz. The frequency fluctuation of the beat note during the servo is ~3MHz with ~10sec timescale.
  VCO has  ~+/-5MHz range, so this coarse locking meets the requirement.

  Here's a plot of the error signal and feed back signal;

  3849   Wed Nov 3 02:23:11 2010 yutaSummaryCDSchecking whitening filter board

  Last night, I found that some of the input channels have wrong hardware filter switching(see elog #3842).
  So, to check the whitening board(D000210), I swapped the one with ok switching and bad switching.
  During the checking, I somehow broke the board.
  I fixed it, and now the status is the same as last night (or, at least look like the same).

What I did:
  1. Switching for SRM_LRSEN looked bad and every input channel for MC3 looked OK.
     So, I unplugged the whitening board for SRM (1X5-1-5B) and plugged it into MC3's place(1X5-1-8B).

  2. Ran WDWchecker.py for MC3. The switching seemed OK for every input channel, which means the whitening board was not the wrong one.

  3. Swapped back the whitening board as it was.

  4. Found MC3_ULSEN_OUT and MC3_LLSEN_OUT was keep showing negative value(they should be positive).

  5. Check the board and found that one of LT1125 for UL/LL was wrong (broken virtual ground).

  6. Replaced LT1125 and put the board back to 1X5-1-8B.

  7. Checked the board with WDWchecker.py and dataviewer 5-hour minute trend.
      The input signal came back to normal value(Attachment #1), MC3 damping working, input filter switching seems working

before LT1125 replacement after LT1125 replacement
C1:SUS-MC3_ULSEN_IN1: -2.4 dB [!]
C1:SUS-MC3_URSEN_IN1: 16.9 dB
C1:SUS-MC3_LRSEN_IN1: 15.4 dB
C1:SUS-MC3_LLSEN_IN1: -1.1 dB [!]
C1:SUS-MC3_SDSEN_IN1: 18.4 dB
C1:SUS-MC3_ULSEN_IN1: 18.2 dB
C1:SUS-MC3_URSEN_IN1: 17.6 dB
C1:SUS-MC3_LRSEN_IN1: 16.6 dB
C1:SUS-MC3_LLSEN_IN1: 17.1 dB
C1:SUS-MC3_SDSEN_IN1: 16.2 dB

  The whitening board seems OK.
  The wrong one is either wiring or RT model. Or, the checking script.

Attachment 1: MC3SEN.png
  3848   Tue Nov 2 16:49:02 2010 JenneConfigurationCamerasCabling on the PSL table

Dear whomever setup the camera on the SW corner of the PSL table,

It would be handy if, even for temporary setups, all cables went underneath the white frame around the PSL table.  As it is now, the cables are in the way of the door.  The door is pretty much closed all the way, but if someone were to open other doors, the far door can easily be pushed all the way to the end of the track, thus squishing the cables.  Squished cables are bad cables.


  3847   Tue Nov 2 16:24:07 2010 KojiUpdateAuxiliary lockingAlignment for the green in the X trans table

[Kiwamu Koji]

Today we found the green beam from the end was totally missing at the vertex.

- What we found was very weak green beam at the end. Unhappy.

- We removed the PBS. We should obtain the beam for the fiber from the rejection of the (sort of) dichroic separator although the given space is not large.

- The temperature controller was off. We turned it on again.

- We found everything was still misaligned. Aligned the crystal, aligned the Faraday for the green.

- Aligned the last two steering mirrors such that we hit the approximate center of the ETMX and the center of the ITMX.

- Made the fine alignment to have the green beam at the PSL table.

The green beam emerged from the chamber looks not so round as there is a clipping at an in-vac steering.
We will make the thorough realignment before closing the tank.

  3846   Tue Nov 2 15:24:18 2010 josephbUpdateCDSc1ioo and c1mcs only sending MC_L, MC1_PIT, MC1_YAW

In order to have the c1mcs model run, we're running with only 3 RFM channels between c1ioo and c1mcs at the moment.  This leaves the model at around 45 microseconds, and at least lets us damp.

Alex and I still need to track down why the RFM read calls are taking so much time to execute.

  3845   Tue Nov 2 13:51:40 2010 josephb, yutaUpdateCDSRFM slowdown problem


Each RFM memory location which needs to be read by a front end model slows the model significantly.

With no RFM memory locations to be read (replaced with grounds), the c1mcs model runs around 25 microseconds per cycle.

With 1 RFM memory location (MC_L), it runs around 29-33 microseconds.

With 3 RFM memory locations (MC_L, MC1_PIT, MC1_YAW), it runs around 45 microseconds.

With 7 RFM memory locations, the code generally doesn't run at all, going past the 62 microsecond maximum required to be able to keep up with the 16 kHz sample rate.

Last night Yuta somehow got it running with 7 RFM memory locations, but in that case, all the odd numbered RFM channels (1,3,5 as counted by the ipc file) did not work.  It was running at around 55 microseconds in that case.

The c1ioo code which is writing the data to the RFM card is experiencing no such slow down.

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  ...
  3844   Tue Nov 2 11:34:53 2010 josephb, alexUpdateCDSdiagconfd running, excitations back in dtt


Diagnostic test tools was starting with errors.


After the reboot of the frame builder machine yesterday by Alex, the diagconfd daemon was not getting started by xinetd.  There was a sequence error in the startup where xinetd was being called before mounting drives from linux1.

Important Note:

If you do not see the "nds" line you would not have diagnostic tests enabled in the DTT:

[controls@rosalba apps]$ diag -i | grep nds
nds * * 8088 *


Alex changed /etc/xinetd.d/diagconfd file to point to /opt/apps/gds/bin/diagconfd instead of /opt/apps/bin/diagconf.  He also ensured xinetd started after mounting from linux1.

Alex's Suggestion:
My feeling is we should get rid of this feature and have an NDS address
entry box in the "Online" tab in the DTT with the default "nds". I
mentioned this to Jim Batch and he greed with me, so maybe he is going to
implement this. So maybe you guys want to request the same thing too, send
the request to Rolf and Jim, so we can have the last demon exercised.

  3843   Tue Nov 2 00:17:01 2010 SureshConfigurationLockingTemporary changes to the Video Mux

Fiber coupling 1064 nm light at the end of X arm

This is 'work in progress'.  The attempt is to bring a few milliwatts of the 1064 nm light from the NPRO at the end of the South(X) Arm to the PSL table through an single mode optical fiber.  This would enable us to tune the two NPRO's to be less than 15 MHz apart by looking at their beat frequency before doubling.  Because we have a 1GHz bandwidth PD at 1064 nm, while the photodiode for green has a BW of about 30MHz.

A PBS (P-type) cube has been introduced into the beam of the X arm NPRO  (between the lamda/2 plate and the input lens of the doubling crystal).  By rotating the face of the PBS slightly away from normal incidence, I have diverted away 1.5mW of the 1064 light for coupling into the fiber. The beam has shifted slightly because of this and the green beam from the south arm has to be realigned to reach the PSL table.

A single mode fiber (Thorlabs SM980-5.8-125),  which was already laid half way, has been extended all the way to the PSL table. It runs along the  South arm in the cable tray. 

A pair of mirrors have been arranged in a zig-zag to steer the beam into a fiber coupler.  There was some hope that this coupler had been aligned at some point in the past and that attaching a fiber might result in some transmission.  But this is not the case and fiber coupler needs to be readjusted.

In order to see the light transmitted through the fiber, a camera has been set up on the PSL table.  Its output has been routed into the 'Ref Cavity reflected' video signal.  A video cable running from the ETMX to the Video-MUX used to be connected to the input channel 9 of the Video MUX.  This has now been shifted to output channel 25 of the MUX and disconnected from the camera at the ETMX.   The 'Ref Cav Refl.' video signal has been routed to the output channel 25.  The camera looking at the fiber output can now be seen on a local monitor at the end of the X arm and on the video monitor in the control room.

With the fiber disconnected, the 1064 nm beam was steered into the fiber coupler and its transmission maximised by observing  with an IR viewer.  The fiber was then connected and then the transmission at the PSL table was sought.  There was no transmission seen after a searching around this region for a few mins.

The plan is to purchase a Visual fault locator which would enable us to quickly get a rough alignment of the fiber coupler. A local vendor is listed as a distributor for this product from JDSU.  Contact info:

DuVac Electronics (EDGE)
Tel: 626-796-3291
Email: jack@duvac.com
1759 E Colorado Blvd
Pasadena, CA 91106


  3842   Mon Nov 1 23:31:05 2010 yutaUpdateCDSchecked input hardware filter in single frequency

  For input filter, we have analog whitening filter and also digital whitening filter. They have the same TF and when analog one is off, digital one should be on and vice versa.
  I made a python script that checks the switching automatically.

  Excite the suspension in a single frequency and see sensor inputs(XXSEN_IN1).
  Calculate the magnitude in the excitation frequency and compare it when digital whitening is off and on.
  When digital whitening is off, analog should be on, so sensor inputs should gone though the analog filter. That means the signal is multiplied by the TF of that filter, which makes the difference.

  We currently don't have excitation and I thought I have to wait, but instead of putting some extra excitation, I found that 60Hz line noise is useful.

  The script is /cvs/cds/caltech/users/yuta/scripts/WDWchecker.py
  For every sensor input, it;
    0. Stores current filter switching(XXSEN_SW1R)
    1. turns OFF the digital filter(FM1, using ezcaswitch)
    2. tdsdmd XXSEN_IN1 in 60Hz
    3. turns ON the digital filter
    4. tdsdmd XXSEN_IN1 in 60Hz
    5. divides mag(2.) by mag(4.) and calculate the analog filter gain in 60Hz
    6. Restores the filter switching in the state before the checking

  The results are;

C1:SUS-BS_ULSEN_IN1: 22.2 dB
C1:SUS-BS_URSEN_IN1: 18.7 dB
C1:SUS-BS_LRSEN_IN1: 22.7 dB
C1:SUS-BS_LLSEN_IN1: 16.0 dB
C1:SUS-BS_SDSEN_IN1: 21.5 dB
C1:SUS-PRM_LLSEN_IN1: -32.3 dB

C1:SUS-MC1_ULSEN_IN1: 17.0 dB
C1:SUS-MC1_URSEN_IN1: 18.6 dB
C1:SUS-MC1_LRSEN_IN1: 14.9 dB
C1:SUS-MC1_LLSEN_IN1: 27.0 dB
C1:SUS-MC1_SDSEN_IN1: 16.6 dB
C1:SUS-MC2_ULSEN_IN1: 19.8 dB
C1:SUS-MC2_URSEN_IN1: 14.0 dB
C1:SUS-MC2_LRSEN_IN1: 20.8 dB
C1:SUS-MC2_LLSEN_IN1: 16.1 dB
C1:SUS-MC2_SDSEN_IN1: 17.3 dB
C1:SUS-MC3_ULSEN_IN1: 15.5 dB
C1:SUS-MC3_URSEN_IN1: 17.3 dB
C1:SUS-MC3_LRSEN_IN1: 18.2 dB
C1:SUS-MC3_LLSEN_IN1: 18.7 dB
C1:SUS-MC3_SDSEN_IN1: 16.8 dB

  Whitening filter has 18dB gain at 60Hz. (It's 3Hz pole, 30Hz zero, 100Hz zero and 0dB at DC)
  So, from the result, at least MC suspensions look like they have correct switching.
  But some channels doesn't look ok.
  We have to check those.

   - check ITMX_SDSEN, PRM_ULSEN, PRM_LLSEN, SRM_LRSEN input filters
   - check the script and see if the script can really check. maybe the script needs some adjustments (# of averaging, multiple frequency, ......)
   - make AWG(, tdssine) work
   - check output hardware filter

By the way:
  fb is back. I don't know why. With help from Joe, I just compiled c1mcs again and again changing number of RFM channels.

  3841   Mon Nov 1 19:32:08 2010 yutaSummaryCDSfb crashed? during c1ioo and c1mcs connection at ASC

Frame builder died again!!

  We want to do angle to length measurement to optimize the beam position and increase visibility of MC locking.
  In order to do A2L measurement, we need excitation point, but AWG is currently not working.
  The better way is to use LOCKIN stuff like we had for OMC and put it to C1IOO WFS.
  A software oscillator in LOCKIN shakes the suspension, and demodulate the length signal.
  We can choose whatever DOF to shake, whatever signal to demodulate. It would be useful not just for A2L.

What I did:

  I started to put C1IOO WFS signal into C1SUS MC suspension RT model, but after compiling new c1mcs, fb crashed.
  Looks like daqd and mx_streams are running, but DAQ is not working(red).
  I don't know how to restart in a new way!

  3840   Mon Nov 1 17:27:47 2010 JenneUpdateSUSPRM ready for installation into chamber

[Jenne, Suresh]

Over the weekend, Bob and Daphen gave the PRM a 48hr. vacuum bake.  This afternoon Suresh and I placed it back in the wire in the tower.  We used the microscope-on-translation-stage technique to make sure the scribe lines on each side of the optic are at the same height, and then secured the PRM using all of the EQ stops.  It is wrapped in foil, and ready for its journey into the IFO room.  When we next have the BS chamber open, we should put the PRM in, and move the current PRM to its final place on the ITMY table as the SRM.

  3839   Mon Nov 1 16:43:24 2010 KojiSummaryCDSCDS time delay measurement

Um, Beautiful.

Actually, 123.5usec is almost exactly twice of 1/16384Hz.
Because of the loop, we have 1/16384Hz delay. I wonder where we do have the delay.

In order to understand the behaviour of the system can I ask you to test the following things?

1) What are the delay without IOPs with fsampl of 16k, 32k, 64k?

2) What are the delay with IOP with fsampl of 32k, 64k?


  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.


  3838   Mon Nov 1 15:47:15 2010 yutaSummaryCDSCDS time delay measurement

  I measured CDS time delay last week, but because of my lack of understanding the system, it was incorrect.
  IOP has an anti-aliasing filter before downsampling from 64kHz(65536Hz) to 16kHz(16384Hz) and also has an anti-imaging filter before upsampling from 16kHz to 64kHz.
  So, I should have take feCoeff4x into account twice.

  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.

 - make AWG(, diaggui TF measurement, tdssine) work
 - check input/output filter switching (using tdssine & tdsdmd)
 - measure openloop TF of MC suspension damping
 - divide it with my expectation and see if there are any filters I don't know



Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice.

I attached the slides I made during my visit for March LVC '09. P.5 would be useful.


  3837   Mon Nov 1 15:35:41 2010 josephbUpdateCDSFront end USR and CPU times now recorded by DAQ


We have no record of how long the CPUs are taking to perform a cycle's worth of computation


I added the following channels to the various slow DAQ configuration files in /opt/rtcds/caltech/c1/chans/daq/




To restart the daqd code, simply kill the running process.  It should restart automatically.  If it appears not to have started, check the /opt/rtcds/caltech/c1/target/fb/restart.log file and the /opt/rtcds/caltech/c1/target/fb/logs/daqd.log.xxxx files.  If you made a mistake in the DAQ channels and its complaining, fix the error and then restart init on the fb machine by running "sudo /sbin/init q"

  3836   Mon Nov 1 14:53:30 2010 josephb, alex, rolfUpdateCDSAlex updated FB and mx_streams code


The framebuilder was being flaky.  MX_streams would go down, prevent testpoints from working and so forth.


Send Alex up North for a week to fix the code. 

Alex came back and installed updates to the frame builder and the mx_streams code (Myrinet Express over Generic Ethernet Hardware) used by the front ends to talk to the frame builder.  Instead of 1 stream per model, there's now just 1 per front end handling all communications.

Alex did an SVN update and we now have the latest CDS code.

Self restarting codes:

The frame builder code (daqd) and nds pipe have been added to the fb machine's inittab.  Specifically it calls a script called /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab.

The addition to the /etc/inittab file on fb is:



When these codes die they should automatically restart.

Self starting codes at boot up:

The front ends now start the mx_stream script (which lives in /opt/rtcds/caltech/c1/target/fb/ directory) at boot up.  They call it with the approriate command line options for that front end. It can be found in the /etc/rc.local file.

They look like: mx_stream -s "c1x02 c1sus c1mcs c1rms" -d fb:0

As always, the front end codes to be started are defined in the /etc/rtsystab file (or on fb, in the /diskless/root/etc/rtsystab file).

However, if it does go down you would need to restart it manually, although it seems more robust now and doesn't seem to go down every time we restart the frame builder.

All the usual front end IOCs and modules should be started and loaded on boot up as well.


Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant Frame builder  ...
  3835   Mon Nov 1 12:38:56 2010 Leo SingerConfigurationComputerspython-sqlite installed on Allegra

I installed the Python bindings for sqlite on Allegra using

$ sudo yum install python-sqlite python-sqlite2

  3834   Mon Nov 1 11:34:08 2010 josephbUpdateCDSCA.Client.Exception spam fixed


    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:SUS-ITMX_TO_COIL_0_3_INMON", Connecting to:, Ignored: c1susdaq:42367"
    Source File: ../cac.cpp line 1208
    Current Time: Fri Oct 29 2010 18:07:39.132686519

The above exception gets thrown for each channel sent to the framebuilder when you start the frame builder.  Its the 192.168.113.xxx (main martian) and 192.168.114.xxx (DAQ) networks sending the same information.  This makes it hard to see real errors when starting the frame builder.


Configure EPICS channel access to only use one network.  This is done by modifying the /etc/bash/bashrc and the /diskless/root/etc/bash/bashrc files with the following two lines:


The first line tells the computers not to automatically search all attached network devices.  The second tells it to use the 192.168.113.xxx network for EPICS channel broadcasts.

  3833   Mon Nov 1 10:28:41 2010 steveBureaucracySAFETYSuresh received 40m safety training

Our new postdoc Suresh Doravari received 40m specific safety training last week.

  3832   Mon Nov 1 10:17:55 2010 steveUpdateGeneralbreakers relabelled

Pedro of the electrical shop helped to retrace wires from the racks to the breakers. Many wrong labels were replaced. These labels are  still representing                          the south arm as Y and  the east arm as X.

Racks: 1X1,2,3,4 and 1Y3,4,5,6,7 and 9 are connected through manual disconnect swithes to  AC power breaker PC-1 on the west wall of IFO room 104.

             This panel PC-1 is connected to T1 isolation transformer in room 101 Panel L - # 38, 40, 42

Racks: 1Y1 & 2  psl and mc are connected through manual disconnect switches to AC power breaker PC-2 just west of the psl enclosure.

             This panel is connected to T2 isolation transformer in room 101 Panel L - # 32, 34, 36

Attachment 1: P1060970.JPG
Attachment 2: P1060972.JPG
Attachment 3: P1060975.JPG
  3831   Sun Oct 31 00:19:35 2010 ranaSummaryComputer Scripts / ProgramsHP3563A netGPIB function

I've wheeled the old HP audio frequency signal analyzer into the control room to debug the GPIB/python interface. The wireless setup was getting more than 80% packet loss in the office area.

I also noticed that we have multiple and competing copies of the netgpib package installed. Kiwamu is going to merge them soon. Pleae only use the official location:


which is also the SVN working copy. Committ all changes periodicallty so that we can share the updated versions between sites.

  3830   Sat Oct 30 14:35:43 2010 KojiSummaryCDSCDS time delay measurement


Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice.

I attached the slides I made during my visit for March LVC '09. P.5 would be useful.


  [time delay of the CDS]  (left, middle)
    The time delay gets larger with frequency. The time delay seems to be -175 usec at DC.
    However, the gain seems a little different from my expectation(feCoeff4x). So, there are maybe other filters I don't know.
    I neglected TF of upsampling this time.


Attachment 1: CDS_system_investigation_090323.pdf
CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf CDS_system_investigation_090323.pdf
  3829   Sat Oct 30 05:27:53 2010 yutaSummaryCDSCDS time delay measurement

  We want to know the time delay of CDS in the IOP scheme.


What I did:
1. Plugged out SCSI cable from ADC card 2 and DAC card 0 on C1SUS machine.
   ADC card 2 is ADC 0
   DAC card 0 is DAC 0

2. Measured tranfer function between ADC and DAC by SR785 and compared with the downsampling filter in IOP with 65534Hz(=4x16384Hz) sampling frequency.

  As ADC_0_0 corresponds to PRM ULSEN input and DAC_0_0 corrsponds to ULCOIL output, we turned all the filters off and set gains to 0 or 1 so that TF between ULSEN to ULCOIL will be ideally 1. (see this wiki page for channel assigns)

  The filter coefficients for the down sampling filter was found in;
  It was named feCoeff4x.

static double feCoeff4x[9] =
        -1.71662585474518,    0.78495484219691,   -1.41346289716898,   0.99893884152400,
        -1.68385964238855,    0.93734519457266,    0.00000127375260,   0.99819981588176};

3. Calculated the time delay dt using the following formula;
  dt = [pm - pc]/f/360deg    (pm: measured phase, pc: calculated phase from feCoeff4x, f: frequency)

4. Measured TF between the SCSI cables to estimate the effect of the cables and others.
  Disconnected SCSI cables from ADC and DAC, and connected A aad B(see setup).
  I measured both when input coupling of SR785 is DC and AC and see what happens.

  [time delay of the CDS]  (left, middle)
    The time delay gets larger with frequency. The time delay seems to be -175 usec at DC.
    However, the gain seems a little different from my expectation(feCoeff4x). So, there are maybe other filters I don't know.
    I neglected TF of upsampling this time.

  [cable and other effect]  (right)
    The effect to the time delay measurement was tiny by a factor of 10^4 to 10^3 (few nsec).
    But the total cable length was about 5 m and assuming signal speed is 0.6c, delay will be about 30 nsec.
    I don't know what's happening.


  - make a model that does not go through IOP and see the delay caused by IOP

By the way:
  fb daqd is still running for hours!
  Every FEs are running(c1sus,rms,mcs).

  3828   Fri Oct 29 18:37:33 2010 yutaSummaryCDSdaqd and current CDS status

  Before Joe left(~ 1 hour ago), fb was working for a while. But after he left, daqd core dumped.
  This is maybe because we started c1sus and c1rms again for a delay measurement, just before he left.

What I did:
  I restarted IOP(c1x02) and FE models.
  Now it seems OK (we can use dataviewer and diaggui), but daqd reports bunch of errors like;

    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:SUS-ITMX_TO_COIL_0_3_INMON", Connecting to:, Ignored: c1susdaq:42367"
    Source File: ../cac.cpp line 1208
    Current Time: Fri Oct 29 2010 18:07:39.132686519

tp node xx invalid  (xx is 38 to 36)

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant  ...

   Please add other stuff you need.

Below is an example of how the color code works:


  3827   Fri Oct 29 16:43:25 2010 josephbUpdateCDSc1ioo now talking to c1sus


c1ioo was not able to talk to c1sus because of timing issues.  This prevented the mode cleaner length signal (MC_L) from getting to c1sus.


The replacement c1ioo chassis from Downs with a more recent revision of the IO backplane works. 

The c1ioo is now talking to c1sus and transmitting a signal.

We connected the cable hanging off the DAQ interface board labeled MC OUT1 to the MC Servo board's output labeled OUT1.

During debugging I modified the c1x02, c1x03, c1mcs and c1ioo codes to print debugging messages.  This was done by modifying the /opt/rtcds/caltech/c1/advLigoRTS/src/fe/commData2.c file.  I have since reverted those changes.


We still need to check that everything is connected properly and that the correct signal is being sent to the MC2 suspension.


  3826   Fri Oct 29 16:39:01 2010 JenneUpdateTreasureOld Green suspension towers disassembled

[Jenne, Joonho]

At Koji's request, we disassembled 2 of the old Green suspension towers that have been sitting along the X-arm forever (read that last word in a 'Sandlot' voice.  Then you'll know how long the suspensions have been sitting there).

They are now hanging out in plastic trays, covered with foil.  They will now be much easier to store.

We should remember that we have these, particularly because the tables at the top are really nice, and have lots of degrees of freedom of fine adjustment.



Atm1, there is one more of these old suspension towers

Atm2, disassembled

Attachment 1: P1070014.JPG
Attachment 2: P1070015.JPG
  3825   Fri Oct 29 16:03:35 2010 kiwamuUpdatePSLwideband EOM : installed the triple resonant box



The box is electrically isolated from the optical bench.

Underneath the box there are four rubber legs and two Delrin plates (black and white) on the top of the box. 

As everyone knows this box is a prototype, so I will make another nicer box with a PCB in this November.

  3824   Fri Oct 29 14:16:26 2010 JenneUpdateSUSPRM baking

[Suresh, Jenne]

We took a look-see at the PRM after the gluing from last night.  The balance is still okay.  The reflected beam is a teeny bit below the laser aperture (center of the beam maybe ~2mm below, so ~1mRad low).  This is within our okay range, since the DC offset that the OSEMs will give will be even more, and the coils can definitely handle this kind of offset.

We took the optic out of the tower, and gave it to Bob and Daphen to bake over the weekend.

  3823   Fri Oct 29 14:06:12 2010 kiwamuUpdateGreen LockingRe: 80MHz VCO for green PLL : VCO calibration

P.S. There is a document about the 80MHz VCO box. This may be helpful. 

link to LIGO DCC

  3822   Fri Oct 29 11:29:29 2010 josephbUpdateCDSHow I broke the frame builder yesterday


Long before Yuta came along and deleted daqd, I had done something to prevent the framebuilder code from running at all.


Alex pointed out via e-mail that the corresponded to the inability to access certain frame files due to their permissions being only for root. 

Turns out when I had run the code under the inittab, I forgot to make it use controls, instead of root (which is the default).  This later on caused problems for the code when it tried to access those files, resulting in the wierd errors we saw.


Use chown to change the offending frame files back to controls.


Write a proper inittab script which uses "su controls" before running the daqd code.

  3821   Fri Oct 29 11:25:15 2010 josephb, yutaSummaryCDS[EMERGENCY] accidentally deleted daqd


Missing daqd file, i.e. the framebuilder executable.


1) Go to /opt/rtcds/caltech/c1/core/advLigoRTS/

2) Look in the Makefile for a likely build suspect.  In this case it was build dc, which stands for data concentrator.

3) So we ran "make dc"

4) Go to the sub-directory build/dc/ and then copy the daqd file there to the /opt/rtcds/caltech/c1/target/fb directory

5) Test it to ensure we're getting channels (Yay!)

Future Safeguards:

Place the new target directory under SVN control.


  3820   Fri Oct 29 06:20:20 2010 kiwamuUpdateGreen Locking80MHz VCO for green PLL : VCO calibration

 I calibrated the VCO frequency as a function of the applied input voltage.

The range is approximately +/- 5 MHz, which is large enough to cover the arm's FSR of 3.75MHz.


======== measured parameters ======

center frequency: 79.5 MHz

VCO range: 74MHz - 84MHz

coefficient : 1.22MHz/ V (+/- 2V range)

nominal RF power: -0.66 dBm

(Note: The measurement was done by using Giga-tronics hand-hold power meter.)

Quote from #3803

Tomorrow I will check the VCO part, especially I am curious about the VCO range.

  3819   Fri Oct 29 05:40:51 2010 kiwamuUpdatePSLwideband EOM aligned : AM decreased by 24dB

At the PSL table I aligned the wideband EOM more carefully.

Amplitude modulation (AM) components in the main beam at 29.5MHz were successfully diminished by 24 dB. 

Last night when we were locking the MC, we noticed that the reflected light had AM which somewhat disturbes the Pound-Drever-Hall locking of the MC.

So I aligned the wideband EOM to reduce the AM components.



  In order to observe AMs I put a photodiode PDA255 whose bandwidth is 50MHz after the wideband EOM.

Before the PD I also put a convex lens together with a stack of ND filters and put a steering mirror to control the beam spot on the PD.


First I aligned the EOM such that the DC voltage from the PD was maximized. This process corresponds to a coarse alignment.

And then I tried reducing a peak at 29.5MHz seen in the spectrum analyzer. 



At the beginning the AM peak in the spectrum analyzer was at about -48 dBm.

After the alignment of the EOM it went down below the PD's dark noise floor of -72 dBm.

I checked the alignment also with an IR viewer, it looks quite good.

  3818   Fri Oct 29 04:58:04 2010 KevinUpdatePSLPBS Optimization

[Koji and Kevin]

Since there was still a lot of power being reflected from the PBS before the Faraday rotator, I placed another PBS at the reflection from the first PBS to investigate the problem. If everything was ideal, we would expect the PBS to transmit P polarization and reflect S polarization. Thus, if the laser was entirely in the TEM00 mode, with the quarter and half wave plates we should be able to rotate the polarizations so that all of the power is transmitted through the PBS. In reality, some amount of P is reflected in addition to S reducing the power transmitted. (We are not sure what the PBS is since there are no markings on it but CVI says that their cubes should have less than 5% P reflection).

For the following measurements, the laser crystal temperature was 31.8° C, the current was 2.1 A, the half wave plate was at 267° and the quarter wave plate was at 330°. I first measured the power reflected from the first PBS then added the second PBS to this reflected light and measured the transmitted and reflected powers from this PBS with the following results:

reflection from first PBS 127 mW
reflection from second PBS 48 mW
transmission from second PBS 81 mW

This shows that approximately 81 mW of P polarization was being reflected from the first PBS and that there is approximately 48 mW of S polarization that could not be rotated into P with the two wave plates. Attachment 1 shows the shape of the reflected (S polarization) beam from the second PBS. This shows that the S polarization is not in TEM00 and can not be rotated by the wave plates. The transmitted P polarization is in TEM00.

We then rotated the first PBS (in yaw) to minimize the amount of P being reflected. Repeating the above measurement with the current alignment gives

reflection from first PBS 59 mW
reflection from second PBS 52 mW
transmission from second PBS 8.5 mW

Thus by rotating the cube to minimize the amount of P reflected, ~70 mW more power is transmitted through the cube. This adjustment moved the beam path slightly so Koji realigned the Faraday rotator and EOM. The PMC was then locked and the beam was realigned on the PMC. At 2.1 A, the transmission through the PMC is 6.55 V and the reflection is 178 mV. With the PMC unlocked, the reflection is 312 mV. This gives a visibility of 0.43.

Note by KA:
We realigned the beam toward the PMC at 1.0A at first so that we don't cook any parts. Once we get the TEM00 resonance, the steering mirrors were aligned to maximize the PMC transmission. Then the pumping current was increased to 2.1A.

  3817   Fri Oct 29 04:24:34 2010 KojiUpdateIOOPMC output increased: need attention

[Kevin Koji]

- The PBS alignment increased the transmitted power

- The first faraday and the PMC EOM were realigned.

- The transmission of the PMC increased from ~5.4V to ~6.5V.

Thus we need to pay attention to the incident beam power on to the MC
so that it does not exceed the power of 20-40mW.

Kevin will give us the detail of the work.

  3816   Fri Oct 29 01:18:03 2010 KojiSummarySUSPRM standoff glued

[Suresh Koji]

The standoff glued. The incandescent lamp set for curing the epoxy.

Jenne and Suresh did the balancing job. The next job was to glue it.

They ran out of the clear epoxy, and tried to use the grey epoxy which we used on the other suspensions for the upgrade.
They found that the solution A with grey color one was dried out and grainy.

We made a test piece of the grey epoxy (mixed with the solution B) in order to see the glue is still usable or not.
After the PMA party, we found that the glue was not stiffening but brittle. We judged that the grey epoxy is no longer useful.

Steve found a pack of Vac Seal in the chemical fridge. We decided to use this one for the gluing of the standoff.

After the gluing, we set an incandescent lamp to make the glue warm. 

Finally, we wrapped the suspension tower with Al foils and turned the HEPA fans again.

Attachment 1: IMG_3674.jpg
  3815   Thu Oct 28 23:17:15 2010 yutaSummaryCDS[EMERGENCY] accidentally deleted daqd

Rana showed me that if c1sus machine runs c1mcs stuff(and c1x02 stuff) only, we can use dataviewer without crashing fb.
Also, if we set correct NDS server and port(fb/8088), we can use diaggui on every machine.

During my investigation on what he did, I accidentally deleted daqd......
I am very very sorry.

I don't know if it helps or not, but all I have is the following information:


[What I deleted]
   -rwxr-xr-x 1 controls controls 6583071 Oct  1 11:57 daqd

[help message for daqd existed]
CDS Data Acquisition Server, Frame Builder, version 2.0
California Institute of Technology, LIGO Project
Client communication protocol version 11.4

        daqd [-f <input frame file name>]
        [-c <configuration file (default -- $HOME/.daqdrc)>]

        [-s <frame writer pause usec (default -- 1 sec)>]

This executable compiled on:
        Fri Oct  1 10:33:18 PDT 2010
        Linux fb #7 SMP Fri Sep 24 14:09:53 PDT 2010 x86_64 Dual-Core AMD Opteron(tm) Processor 8220 AuthenticAMD GNU/Linux

Please help me, Joe.

  3814   Thu Oct 28 21:20:11 2010 yutaUpdateCDSFlaky fb, tried DAQ re-install, but no help

  Unfortunately, fb is flakier than normal. We can't use dataviewer and diaggui now.
  I thought it might be because editting .ini files(list of DAQ channels) in /cvs/cds/rtcds/caltech/c1/chans/daq/ without using GUI was doing something wrong.
  So, I re-installed DAQ, but it didn't help.

What I did:
1. ssh c1sus, went to /opt/rtcds/caltech/c1/core/advLigoRTS/ and ran
  make uninstall-daq-c1SYS
  make install-daq-c1SYS

It didn't help.
More than that, MC suspension damping went wrong. So;

2. Rebooted c1sus machine.
 I restored MC suspension damping by doing this.
 (Similar thing happened Tuesday when we were trying to lock MC)

  Editting .ini DAQ channel list file wasn't wrong. (or, I failed in finding anything wrong right now)


Attempted Fixes:

Yuta may try restoring the old DAQ channel choices and see if that makes a difference.


  3813   Thu Oct 28 20:08:26 2010 yutaUpdateGreen Lockingrevised RF amp cascading

  Yesterday, I said I will use ZHL-32A for amplifying beat note signal, but as Koji pointed out, ZHL-32A is for medium high power.
  So I changed my mind to use ZFL-1000LN instead. ZFL-1000LN is a low noise RF amp whose maximum power is 3dBm.
  Also, we included a splitter in our consideration.

What I did:

1. Set up a new setup. ZFL-1000LN has a gain of +24dB at 80MHz and splitter ZFRSC-42 has a loss of -6dB. So;

beat note signal -> ZFL-1000LN -> ZFL-1000LN -> ZFRSC-42 => SR620 and VCO

2. Measured frequency-output relation. When the input signal was 80MHz -48dBm, the output was -8.7dBm. For other frequencies;
       60MHz  -3.3dBm
       70MHz  -5.7dBm
       80MHz  -8.7dBm
       90MHz  -5.5dBm
      100MHz  -3.5dBm
  So, we can see frequency up to >100MHz by SR620 using this setup.

3. Checked harmonics peak levels of the output using an RF spectrum analyzer. When the input signal was 80MHz -48dBm, the height of the peaks were;
     80MHz -8.8dBm
    160MHz -30dBm
    240MHz -42dBm
  Other peaks were smaller than the 3rd harmonics. Also, RF PD that detects beat note signal has a cut-off frequency at around 100MHz. So, we don't need to worry about wave transformation for this setup.


ZHL-32A is a high power (well..., actually middle power) amplifier with the max output power of +29dBm (~1W!).
It seems to be overkill.
Your signal is so small so you don't need ZHL-32A, but can use small amp which we may have somewhere in the lab.

And the description:
"RF amplifier ZHL-32A has around +28dBm gain at 80MHz"
The unit is wrong.

Yes. I corrected my previous elog.

  3812   Thu Oct 28 19:10:26 2010 taraUpdateElectronicsTTFSS for 40m

I keep a set of new TTFSS for 40m in electronic cabinet along the North arm.

The set number is #6. It is working and has not been modified by me.

Other two sets,# 5 and #7, are kept at PSL lab.

  3811   Thu Oct 28 16:38:54 2010 josephbUpdateCDSFlaky fb, reverted inittab changes on fb


Yuta reported many of the signals being displayed by dataviewer "fuzzier" than normal.  And diaggui was not working.

Running "diag -i" reported:

Diagnostics configuration:
awg 21 0 822095893 1
awg 36 0 822095908 1
awg 37 0 822095909 1
tp 21 0 822091797 1
tp 36 0 822091812 1
tp 37 0 822091813 1

This seems to be missing an nds type line between the 3 awgs and the 3 tp lines.

The daqd code (the framebuilder) is being especially flaky today, and I'm starting to see new errors.

[Thu Oct 28 16:13:46 2010] Couldn't open full trend frame file

T-972342780-60.gwf' for writing; errno 13
epicsThreadOnceOsd epicsMutexLock failed.
epicsThreadOnceOsd epicsMutexLock failed.
epicsThreadOnceOsd epicsMutexLock failed.
epicsThreadOnceOsd epicsMutexLock failed.
epicsThreadOnceOsd epicsMutexLock failed.
Segmentation fault (core dumped)


[Thu Oct 28 16:17:06 2010] Couldn't open full frame file
`/frames/full/9723/.C-R-972343024-16.gwf' for writing; errno 13
CA client library tcp receive thread terminating due to a C++ exception
FATAL: exception not rethrown
CA client library tcp receive thread terminating due to a C++ exception
CA client library tcp receive thread terminating due to a C++ exception
FATAL: exception not rethrown
cac: tcp send thread received an unexpected exception - disconnecting
Aborted (core dumped)

What was done today that might have affected it:

A new c1ioo chassis from Downs was connected to c1ioo.  I also connected c1ioo to the DAQ network (192.168.114.xxx) which talks to the frame builder.

I started downloading the necessary files to be able to follow Keith's instructions for a standard control / teststand setup in /opt/apps , /opt/rtapps, etc.  However, it has not actually been installed yet.

Yuta added additional OL channels to the DAQ config for being recorded.

Attempted Fixes:

I reverted the inittab changes I made in this elog.  Didn't help.

I disconnected c1ioo from the DAQ network.  Didn't help.

Rebooted the frame builder machine.  Didn't help.

I've sent an e-mail to Alex describing the problem to see if he has any idea where we went wrong.

Yuta may try restoring the old DAQ channel choices and see if that makes a difference.

Current Status:

daqd framebuilder code still won't stay up.  So no channels at the moment.

  3810   Thu Oct 28 13:01:34 2010 steveUpdatePEMcrane repair guys left for the day


Fire-smoke sensors in the vertex area #2-31, 2-30 east, 2-32 south/MC2 and 2-37 old control room area are turned off to accommodate the welding

activity of folding crane. These sensors will be reactivated at 3:30pm today.

Stay out of the 40m lab: IFO room till 6 pm today.

 The new cord wheel was to big. They be back tomorrow?

The lab is open.

ELOG V3.1.3-