40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 216 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  9485   Wed Dec 18 03:29:48 2013 DenUpdateLSCyarm locked on mc

As a CM slow path test I locked free swinging yarm by actuating on MC length with bandwidth of 200 Hz. Crossover with AO is not stable so far.

I used xarm as an ool frequency noise sensor. MC2 violin mode is at 645 Hz, I have added a notch filter to LSC-MC2 bank.

Attachment 1: MC_ARM.pdf
MC_ARM.pdf
  9486   Wed Dec 18 11:32:34 2013 ranaUpdateLSCXend QPD schematic investigation

 

 Since we use the TransMon QPD for triggering the high/low gain switching we need to run with the whitening OFF during lock acquisition and the turn it on after we have the arms locked with ALS. This should be put into the up/down scripts.

  9487   Wed Dec 18 11:37:12 2013 JenneUpdateLSCPOP22 and POP110 demod phases

Somehow the POP22 and POP110 demod phases weren't correct anymore.  I guess Den saw this after he changed the setup for the REFL165 PD at the LSC rack, but didn't elog it. 

I went out to the LSC rack, and found that the power supply that is supplying the amplifiers for both POP22/110 and REFL165 was set to ~16V each channel.  I put it back to 15V for each channel.  I don't know what Den intended for the 165 amplifier (more volts is more gain), but the POP22/110 amplifier usually runs with 15V. 

I also reset the POP22 and POP110 demod phases.  Since I'm not able to lock PRMI on sideband this morning (why?!?!), I locked on the carrier, and moved the phases around until POP22 and POP110 were both maximally negative.  The phases are/were:

  OLD [deg] NEW [deg]
POP22 107.2 -165.0
POP110 95.0 150.0

This is a ~60 degree change for both PDs. 

I am not sure if Den ever checked the demod phase of REFL165 after he put in the new SMA cable (there's no mention of it in the elog!), so I'm going to check that to see if it helps get PRMI locking back.  I know that Den had also been using REFL11 for PRMI locking, but the parameters he used for that aren't in the log either.

  9488   Wed Dec 18 13:34:03 2013 SteveUpdateGeneralLIGOX people

40m crew and visitor Holger Muller from Berkeley.

Attachment 1: 40m2013Dec.jpg
40m2013Dec.jpg
Attachment 2: 40mCup.jpg
40mCup.jpg
  9489   Wed Dec 18 15:35:48 2013 SteveUpdatePEMexcess seismic noise

This is not a test. Life can be dangerous in the 40m Control  Room.

Attachment 1: seismicCar.jpg
seismicCar.jpg
  9491   Wed Dec 18 18:45:39 2013 JenneUpdateLSCREFL 165 demod phases

I checked out the REFL165 demod phase, and it looks like it was okay.  it was -20.9 degrees.  I turned on my sensing matrix oscillators, and maximized the PRCL signal in the REFL165_I_ERR channel, and got a pretty good maximization at +155 degrees.  I used this to lock the PRMI on sidebands, with MICH gain of +0.3, and PRCL gain of +0.1 . 

Since this is working, I'm leaving the REFL 165 phase here, at +155 degrees, although this is almost exactly 180 degrees from what Den left it at, so I'm not sure why I was not able to lock with a demod phase of -20.9.  (I tried all 4 permutations of signs, with gain values of the same magnitude (0.3 for MICH, 0.1 for PRCL), and wasn't able to lock.  I'll try to figure this out tomorrow, but it was time for the meeting, then the IFO has been busy doing more important things the rest of the afternoon.

Plan for checking:  Lock with demod phase of 155, measure TF to one of the other REFL diodes (11, 33 or 55), lock on that other REFL diode.  Then, change the REFL 165 demod phase back to -20.9, and measure the transfer function again.  Hopefully the answer is just that I was doing something dumb, and it works easily.  This test/measurement should only take a few minutes, but it'll make me happier knowing that things still work as they should.

  9492   Thu Dec 19 03:29:34 2013 DenUpdateLSCCM servo test using yarm is complete

Koji, Den

Procedure:

  • lock yarm on IR, wire POY to CM input
  • transition arm to CM length path by actuating on IMC
  • increase AO gain for a stable crossover
  • engage CM boosts

Result:

  • arm can be kept on resonance and even acquired on MC2
  • stable length / AO crossover is achieved
  • high bandwidth loop can not be engaged because POY signal is too noisy and EOM is running out of range

We spent some time tuning CM slow servo such that fast path would be stable in the AO gain range -32db -> 29dB (UGF=20kHz) when all boosts are turned off and common gain is 25dB. Current filters that we use for locking are not good enough - AO can not be engaged due to oscillations around 1kHz. This is clearly seen from slow path closed loop transfer function. I will attach servo shapes tomorrow.

Attached plot "EOM" shows EOM rms voltage while changing AO gain from -10dB to 4dB. For UGF of 20kHz we need AO gain of 29dB.

It seems we can start using CM servo for CARM offset but the sensor should be at least factor of 30 better than POY. Add another factor of 10 if we would like to use BOOST 2 and BOOST 3.

Attachment 1: EOM.png
EOM.png
  9494   Thu Dec 19 14:40:42 2013 KojiUpdateCDSRFM Time over mitigation for c1mcs

I worked on the mitigation of c1mcs time-over issue this afternoon.

The timing for the c1mcs is successfully reduced from >60us to 45us.


The previous models are svned in redoubt as follows:

MCS rev. 6696
RFM rev. 6697
IOO rev. 6698

What I changed was:

- Remove connection from ALS (on c1ioo) to MCS (on c1sus). This should be all done in LSC. (# of RFM IPC in MCS -1)

- MC2 trans QPD filters are moved from IOO to MCS to reduce the RFM channels in MCS.
  Previously the signals for the 4 segments are sent. Now the processed siganls (pit/yaw/sum) are sent. (# of RFM IPC in IOO -1, MCS -1)

- WFS MC3 feedback channels are moved from MCS to RFM to distribute the RFM channels (# of RFM IPC in MCS -2, in RFM +2)

model    prev. timing[us] current timing[us]  diff in time[us]  diff in ch#
c1mcs         >60                45                -15              -4
c1rfm         47                 53                + 6              +2       
c1ioo         47                 36                -11              -1

Revisions of the new models:
MCS rev. 6702
RFM rev. 6701
IOO rev. 6700

  9496   Thu Dec 19 19:45:12 2013 ericqUpdateGreen LockingX-Arm Green PDH Loop Stuff
With the fixed servo box, I remeasured the OLTF, the servo, and the low pass filter between the mixer output and servo input. Dividing the OLTF by the servo and LPF transfer functions should just leave the the [laser PZT->cavity->PD] transfer function, which should have the shape of the cavity pole plus any delay in the loop, up until the PZT is no longer linear / the measurement has bad SNR.

I'm missing a few pieces of the loop. While I know the PD gain in V/W, I don't know how much power is in the sideband, which affects the slope of the PDH error function. Also, I've found old ELOG posts mentioning either 1 or 5MHz/V being the NPRO PZT response, but am not sure how to determine what it actually is. These are essentially just scalars though, so finding the reason for low phase margin doesn't depend on them.

Here are the TFs I've measured ("residual" refers to OLTF/(servo*LPF)):



The teal "residual" TF presumably owes its shape to the cavity pole + the time delay around the loop. Messing around with the data, the shape fits very well to a real pole at 27kHz and a ~3usec delay. I have no real way to back that up as the unique truth behind it, however. Is there a good way to measure the delay? Without assuming any delay, the shape is best fit by a real pole at 26kHz and some funky complex zeros.

Another thing to look at is the CLG implied by the measurement of the OLTF, given by 1/(1-G). I plotted this quantity for the measured loop, and also for G/2 and 3G/2 to get an idea for how it changes as you turn the servo gain knob. I measured with the knob at 4.0. There seems to be quite a bit of gain peaking!



Also, I drew up a simple block diagram sort of thing to show how everything is connecting down at the green electronics rack at the end of the X arm (while totally glossing over the optical elements involved). This hopefully helps anyone who wants to inspect/take apart/massacre the setup.

  9499   Fri Dec 20 01:24:11 2013 DenUpdateLSChigh bandwidth loop achieved for yarm

Koji, Den

CM Servo with POY11 successfully engaged. UGF: ~15kHz.


Tonight we decided to repeat one arm locking using high-bandwidth CM servo. We low-passed AO signal to avoid saturations of the EOM. We tried different configurations that compromise between noise and loop phase margin and ended up with a pole at 30kHz. SR560 is used as a low-pass filter.

Another problem that we faced was big (~2.6V) electronic offset at the input of 40:4000 BOOST. Once engaged, cavity would be kicked out of lock. We calibrated this offset to be almost half linewidth of the cavity (~300pm). To avoid lock loss during engaging the boost we increased common mode gain to maximum (31 dB).

Measured OL is attached. UGF is 15kHz, phase margin is 60 degrees. We have also simulated evolution of loop shape during bringing AO path. Plot is attached.

The final procedure is

  • set common gain up to 31dB, AO gain to 8dB, MC IN2 gain 10dB, CM offset 0.7V
  • lock arm with CM slow path with bandwidth of 200 Hz
  • enable AO path, gradually increase slow and fast gains by 12 dB
  • enable boost
Attachment 1: CM_OL_meas.pdf
CM_OL_meas.pdf
Attachment 2: cm_ol_sim.pdf
cm_ol_sim.pdf
Attachment 3: CM_slow_fast_cross.pdf
CM_slow_fast_cross.pdf
  9500   Fri Dec 20 03:31:07 2013 KojiUpdateLSClock acquisition path for the CM servo

up/down scripts are to be made

(Offset Edit on Dec 20 10:38PM)


Configuration:
POY11QMon -> CM Servo In1 -> CM Servo -->Out1 -> ADC -> CM Slow FM -> LSC MC Servo FM -> ETMY(x1.0) -> DAC -> ETMY
                                       |
                                       -->Servo Out -> SR560 (DC, 1st order 30kHz LPF) -> MC In2


Lock acquisition path 1

Initial condition:

CM Slow FM:

  • Gain 2.6

CM Servo setting:

  • In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +8dB

MC Servo setting:

  • In2 10dB, SW:OFF

Acquisition:

  • Engage LSC
  • LSC MC servo gain +0.1, FM7/FM10 (Trigger FM2 with 3sec delay)
  • Turn on MC

Transition:

  • Enable AO path (CM servo In1 SW:ON, MC servo In2 SW:ON)
  • LSC MC gain +0.1 -> +0.2
  • AO path gain 8dB->14dB
  • LSC MC gain +0.2 -> +0.35
  • AO path gain 14dB->18dB
  • CM servo offset -1.88 -2.7 -> 0.8 0.0 (gradually)
  • Enable CM servo Boost

Lock acquisition path 2

Initial condition:

CM Slow FM:

  • Gain 2.6

CM Servo setting:

  • In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +20dB

MC Servo setting:

  • In2 10dB, SW:OFF

Acquisition:

  • Engage LSC
  • LSC Yarm G=+0.25 FM4/5 (Trigger FM3/6/7/8)

Transition:

  • Enable MC servo In2 (SW:ON)
  • Set LSC MC gain +0.2 FM7/10
  • Enable LSC MC (On)
  • Enable CM servo In1 (SW:ON)
  • Disable LSC Yarm (OFF)
  • Change CM servo offset -1.88 -> +0.700 -2.70 -> 0.0
  • Enable CM servo Boost
  • Turn on LSC CM FM2 (optional)

Transition to ETMY LSC to MCL

  • After all of the transition: LSC output matrix ETMY (+1.00)
  • LSC output matrix MC2 (-1.00)
  • LSC output matrix ETMY (0.00)
  9501   Fri Dec 20 03:34:40 2013 KojiUpdateLSChigh bandwidth loop achieved for yarm

This too huge offset difference with/without "BOOST" switch should be checked.

  9504   Fri Dec 20 17:41:25 2013 SteveUpdateGeneralProjector - lightbulb replaced

 The lamp lasted for 4,622 hours.

This time I purchased just the bare lamp itself . The housing doubles the price. The disadvantage of this technic that the lamp housing window can not be cleaned  perfectly. Atm2 picture is exaggerating this spot.

However, It does not degrade the image quality.

Roll over image to zoom in

      

 
 

Glamps RLC-061 Projector Original Bulb Lamp for VIEWSONIC Pro8200 Pro8300

 

 

Attachment 1: explodedlamp.jpg
explodedlamp.jpg
Attachment 2: clweanedWindowShield.jpg
clweanedWindowShield.jpg
  9506   Fri Dec 20 20:04:01 2013 SteveUpdateVACpower supply replaced with a short vent

Quote:

Quote:

Instrument rack power supplies checked and labeled at present loads.

The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.

It is alarming to me because all vacuum valve positions are controlled by this 24V

 The temperature went down to room temp with temporary fan in the back. Voltage and current are stable.

Regardless, it will be replaced early next week.

Koji, Steve

 It was a bad experience again with our vacuum system.  The valves went crazy as we rebooted the computer. This was required for the swap in of a good 24V power supply.

The IFO was vented to 27 Torr through the annuloses, VA6, V7, Maglev,VM2 and VM1 (VC2 was open too)

I just opened the PSL shutter after a 4 hours pumpdown.

Condition: annuloses are not pumped, the IFO and the RGA are pumped as Atm2 shows

I will be here tomorrow morning to switch over to vacuum normal. 

More details later

 

 

Attachment 1: 4hrPumpdown.png
4hrPumpdown.png
Attachment 2: pumpdownAfterHickup.png
pumpdownAfterHickup.png
Attachment 3: PSpumpdown.png
PSpumpdown.png
  9507   Fri Dec 20 22:45:02 2013 KojiUpdateLSChigh bandwidth loop achieved for yarm

I checked the offset situation in the CM servo boost circuit. 

- The offset voltage on the CM servo screen is a raw DAC output. This number is diluted by the voltage divider before the amplifier.
  So, the actual offset of the boost circuit was much smaller. (~20mV)

- There is a offset trimmer on the board. This was adjusted so that the boost does not generate an output offset.

- So the default offset is 0V.

- When the arm was locked with (digital) POY11, the CM servo offset is necessary to be -2.7 (now).
  This means that analog POY11Q and digital POY11 has different offset for the best resonance transmission.
  That is believable if POY11I is contributing to the digital POY11 signal.

  9508   Fri Dec 20 23:00:41 2013 KojiUpdateVACpower supply replaced with a short vent

I'm leaving the 40m now. IFO is aligned. Everything look good.

- The main volume P1=5e-4, CC1=1.4e-5 is still pumped by TP1 and TP2

- RGA P4<0e-4, CC4 2.1e-7, is pumped by TP3

- The annuluses are isolated.

- RP1/2/3 are off.

  9510   Sat Dec 21 10:53:35 2013 SteveUpdateVACpower supply replaced with a short vent-pumpdown completed

The recovery- pumpdown reached valve configuration  vacuum normal at 20 hours, cc1 7.7e-6 Torr

Lesson learned: turn all pumps off, close all valves before you reboot ! like you would prepare for AC power shut down.

 

Attachment 1: 20hrsVacNormal.png
20hrsVacNormal.png
  9514   Thu Jan 2 10:50:24 2014 SteveUpdateVAC vacuum monitor is still blank

 The date is correct on this monitor.

Last stored RGA scan data Dec 20, 2013

IFO pressure at CC1 5.8e-6 Torr

Valve configuration: Vacuum Normal, confirmable only by manual checking of position indicators and pressure gauge controllers  readouts

 

Attachment 1: Help.png
Help.png
Attachment 2: vacation.png
vacation.png
Attachment 3: 20131220lastRGAscan.png
20131220lastRGAscan.png
  9515   Thu Jan 2 13:35:06 2014 KojiUpdateVAC vacuum monitor is still blank

We probably need to restart the machine, but I didn't want to touch c1vac1 and c1vac2. 

  9521   Mon Jan 6 18:32:17 2014 RANAUpdateIOOMC1/3 kicked this morning at 8:30

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

Attachment 1: kicked.png
kicked.png
  9522   Mon Jan 6 20:52:09 2014 JenneUpdateIOOMC1/3 kicked this morning at 8:30

When I got in this morning at 9-something (9:45 maybe?), Steve was taking dust photos on the AS table, of the MC Refl path.  Other than that, I don't have any information. 

Also, Tuesday is our traditional janitor day, so I'm hesitant to put our blame there.  (I think we've kept Tuesdays, even though we're on a less-often schedule....Steve will have to correct me if I'm wrong on this).

  9523   Mon Jan 6 22:11:46 2014 JenneUpdateLSCPRCL sideband locking still not so happy

 

 The PRCL once again doesn't want to lock on sidebands for me.  I can lock on the carrier just fine (using the IFO Config settings, along with some hand-alignment of the PRM). 

However, I can't convince it to lock on sidebands.  Using the configs that I used on Dec 18th (elog 9491), I'm not getting it.  I've done the arm ASS alignment, and I've run LSCoffsets, both of which seemed to do their things appropriately. 

I'm going to attribute this today to not being in the groove yet, and I'll look at it again in the morning.

  9524   Tue Jan 7 10:44:13 2014 SteveUpdateIOOMC drift

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

 I was taking pictures at the AP table at the morning and ETMX optical table after noon. There was no activity on the IOO chamber.

 Look at the last 2 hours of  Rana's trend plot. MC1 and MC2 sensor voltage started increasing.

I think it was a drift action.

Attachment 1: 2dTrend.png
2dTrend.png
Attachment 2: driftNotKick.png
driftNotKick.png
  9525   Tue Jan 7 11:11:36 2014 ranaUpdateIOOMC drift

 

 NOT drift. The sudden steps are certainly the result of being kicked. The slow drift at the end of the day might be a slow strain relaxation.

It pays to be careful and not put too much weight or impulsive forces on the chambers or tables.

  9526   Tue Jan 7 16:41:08 2014 manasaUpdateIOOWFS moving MC suspensions

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

The MC trend for the last 2 days shows that the MC suspensions were kicked again earlier today.  Looking back at the suspension channel INMONs along with the MC trans sum shows that the suspensions get kicked everytime MC locks and unlocks. (Attch:1)

So I checked the effect of WFS on the suspensions by disabling and enabling the WFS feedback servo (Attch:2).

Since the IMC is not at it best pointing, whenever the  MC autolocker runs and enables the WFS, the suspensions look like they are getting kicked.  But really, it's just the WFS doing their job. 

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

Attachment 1: 2dayMCtrend.png
2dayMCtrend.png
Attachment 2: WFSvsMCsuspensions.png
WFSvsMCsuspensions.png
  9527   Tue Jan 7 17:16:04 2014 manasaUpdateIOOMC aligned

Quote:

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

 Aligned MC to offload the WFS

1. Turned OFF the WFS feedback servo.

2. Aligned the MC suspensions by moving the pit and yaw sliders. MC trans sum brought from ~11000 counts to ~15000 counts. MC RFPD DCMON reads 0.45 counts.

3. Turned ON the WFS servo. The WFS output now reads in the order of 0 to +/-15.

4. Measured the MC spot positions. The spot positions look like they moved for the better compared to what they were yesterday.

 

Attachment 1: MCspots.png
MCspots.png
  9528   Tue Jan 7 20:57:41 2014 JenneUpdateIOOMC aligned

[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good.

While we were out on the table, we also changed the anodized aluminum dump for a razor dump, to catch the reflection from the 2inch lens that is the first thing the MC refl path sees out of vac.

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

  9529   Tue Jan 7 21:00:02 2014 JenneUpdateIOOIP POS, IP ANG aligned

After locking the arms (after the MC alignment work), Manasa and I aligned IP POS, IP ANG, and both end transmission QPDs. 

We noticed that IP ANG is clipping in yaw as it comes onto the end table.  It looks to me like it's clipping on the edge of the plastic box's aperture, but I can't guarantee that it's not also clipping elsewhere. 

  9530   Tue Jan 7 22:44:45 2014 JenneUpdateCDSdaqd on fb is segfaulting every ~30 seconds

The daqd process is segfaulting and restarting itself every 30 seconds or so.  It's pretty frustrating. 

Just for kicks, I tried an mxstream restart, clearing the testpoints, and restarting the daqd process, but none of things changed anything.  

Manasa found an elog from a year ago (elog 7105 and preceding), but I'm not sure that it's a similar / related problem.  Jamie, please help us!

Here is a screen dump from the "dtail":

Every 1.0s: dmesg | tail -50                                                                                                                         Tue Jan  7 22:43:23 2014

[   33.498691]  [<ffffffff8104a063>] kthread+0x7a/0x82
[   33.498695]  [<ffffffff81003654>] kernel_thread_helper+0x4/0x10
[   33.498698]  [<ffffffff81049fe9>] ? kthread+0x0/0x82
[   33.498701]  [<ffffffff81003650>] ? kernel_thread_helper+0x0/0x10
[   33.498703] ---[ end trace 6236defa99b3e091 ]---
[   33.498705] mx INFO: Board 0: allocated MSI IRQ 67
[   33.498713] mx INFO: CPU0: PAT = 0x7010600070106
[   33.498715] mx INFO: CPU0: new PAT = 0x1010600070106
[   33.498718] mx INFO: Board 0: Using PAT index 6
[   33.499101] eth0: no IPv6 routers present
[   33.531013] mx INFO: Board 0: device 8, rev 0, 1 ports and 2096896 bytes of SRAM available
[   33.531017] mx INFO: Board 0: Bridge is 10de:005d
[   33.531228] mx INFO: Board 0: MAC address = 00:60:dd:46:ea:ec
[   33.535971] mx INFO: Loaded mcp of len 235448
[   34.489244] mx INFO: Starting usermode mapper at /opt/mx/sbin/mx_start_mapper
[   39.148855] mx INFO: mx0: Link0 is UP
[   39.588511] mx INFO: myri0: Will use skbuf frags (4096 bytes, order=0)
[   39.589299] mx INFO: 1 Myrinet board found and initialized
[  287.706367] daqd used greatest stack depth: 3368 bytes left
[86605.907520] daqd[18407]: segfault at 38b08e4c0 ip 00007f11b3942a6c sp 00007f10b1917d50 error 4
[86605.907530] daqd[18424]: segfault at 38b544f90 ip 00007f11b3942a6c sp 00007f10b12c6d30 error 4 in libc-2.10.1.so[7f11b390e000+14c000] in libc-2.10.1.so[7f11b390e000+14c00
0]
[86605.907544]
[86605.919454] daqd[21319] general protection ip:7f11b3942a6c sp:7f10b1814d30 error:0
[86605.919462] daqd[18442] general protection ip:7f11b3942a6c sp:7f10b0bf4d30 error:0
[86605.919615] daqd[18443]: segfault at 38aee3db0 ip 00007f11b3942a6c sp 00007f10b0b73d50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919694] daqd[18412]: segfault at 38aff35d0 ip 00007f11b3942a6c sp 00007f10b1752d30 error 4
[86605.919701] daqd[18417]: segfault at 38b544f70 ip 00007f11b3942a6c sp 00007f10b154dd50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919708] daqd[18445]: segfault at 38aff35b0 ip 00007f11b3942a6c sp 00007f10b0ab1d50 error 4
[86605.919733] daqd[18429]: segfault at 38b42ae90 ip 00007f11b3942a6c sp 00007f10b10c1d50 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.919741] daqd[18440]: segfault at 38b08e480 ip 00007f11b3942a6c sp 00007f10b0cb6d30 error 4 in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958551]  in libc-2.10.1.so[7f11b390e000+14c000] in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958557]
[86605.958577]  in libc-2.10.1.so[7f11b390e000+14c000]
[86605.958586]  in libc-2.10.1.so[7f11b390e000+14c000]
[86605.959639] daqd used greatest stack depth: 3160 bytes left
[98139.100888] show_signal_msg: 13 callbacks suppressed
[98139.100895] daqd[23753]: segfault at 39c7363b0 ip 00007f5bf253ba6c sp 00007f5b69b48d30 error 4 in libc-2.10.1.so[7f5bf2507000+14c000]
[98687.815120] daqd used greatest stack depth: 2984 bytes left
[208995.594227] daqd[10386] general protection ip:7f3b7c930a6c sp:7f3a79f09d50 error:0 in libc-2.10.1.so[7f3b7c8fc000+14c000]
[353015.067479] daqd used greatest stack depth: 2880 bytes left
[367406.863618] daqd[13078]: segfault at 41 ip 0000000000000041 sp 00007fb1f0ba2cf8 error 14 in daqd[400000+7c000]
[367406.863833] daqd[13104] general protection ip:7fb2f3018a6c sp:7fb1f01c8d30 error:0
[367406.863877] daqd[13086] general protection ip:7fb2f3018a6c sp:7fb1f089ad30 error:0
[367406.877408] daqd[13080]: segfault at 41 ip 0000000000000041 sp 00007fb1f0ae0ca8 error 14 in daqd[400000+7c000]
[367406.877435]  in libc-2.10.1.so[7fb2f2fe4000+14c000]
[367406.877442] daqd[13100]: segfault at 39ba287b0 ip 00007fb2f3018a6c sp 00007fb1f034cd30 error 4 in libc-2.10.1.so[7fb2f2fe4000+14c000]
[367406.878372]  in libc-2.10.1.so[7fb2f2fe4000+14c000]
[399802.887523] daqd[18295] general protection ip:7fb056a71a6c sp:7faf96125f10 error:0 in libc-2.10.1.so[7fb056a3d000+14c000]
[410595.969327] daqd[22057]: segfault at 3a91f27b0 ip 00007f48e96eea6c sp 00007f47e6c26d50 error 4 in libc-2.10.1.so[7f48e96ba000+14c000]
[410595.988926] daqd[22068]: segfault at 3a91f2790 ip 00007f48e96eea6c sp 00007f47e681bd30 error 4 in libc-2.10.1.so[7f48e96ba000+14c000]

  9531   Tue Jan 7 23:08:01 2014 jamieUpdateCDS/frames is full, causing daqd to die

Quote:

The daqd process is segfaulting and restarting itself every 30 seconds or so.  It's pretty frustrating. 

Just for kicks, I tried an mxstream restart, clearing the testpoints, and restarting the daqd process, but none of things changed anything.  

Manasa found an elog from a year ago (elog 7105 and preceding), but I'm not sure that it's a similar / related problem.  Jamie, please help us

The problem is not exactly the same as what's described in 7105, but the symptoms are so similar I assumed they must have a similar source.

And sure enough, /frames is completely full:

controls@fb /opt/rtcds/caltech/c1/target/fb 0$ df -h /frames/
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   13T     0 100% /frames
controls@fb /opt/rtcds/caltech/c1/target/fb 0$

So the problem in both cases was that it couldn't write out the frames.  Unfortunately daqd is apparently too stupid to give us a reasonable error message about what's going on.

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

  9532   Tue Jan 7 23:09:10 2014 manasaUpdateIOOMC aligned

Quote:

[Rana, Jenne]

We turned off the WFS servos, and looked at the MC REFL DC, and saw that it was still good, so we said that since the MC spots are pretty good, that we'll keep this alignment for now. 

Rana put the beam back on the center of the IOO QPDs on the PSL table.

We switched a steering mirror in the WFS path that was the wrong handed-ness to be the correct handed-ness, then put the beam on the centers of the WFS.  We turned on the WFS, and everything seems good. 

There were no major drifts in the WFS error signals while we were gone for dinner, so the MC seems okay for now.

 The last 4 hour trend for WFS error signals show some amount of drift. We should still look at the long term trend to solve the issue.

Attachment 1: WFSdrift.png
WFSdrift.png
  9533   Tue Jan 7 23:13:47 2014 jamieUpdateCDS/frames is full, causing daqd to die

Quote:

So why is /frames full?  Apparently the wiper script is either not running, or is failing to do it's job.  My guess is that this is a side effect of the linux1 raid failure we had over xmas.

It actually looks like the wiper script has been running fine.  There is a log from Tuesday morning:

controls@fb ~ 0$ cat /opt/rtcds/caltech/c1/target/fb/wiper.log

Tue Jan  7 06:00:02 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385289132k
/frames/trend/second 100891124k
/frames/full 12269554048k
/frames/trend/minute 1906772k
Combined 12757641076k or 12458633m or 12166Gb

/frames size 13460088620k at 94.78%
/frames is below keep value of 95.00%
Will not delete any files
df reported usage 97.72%
controls@fb ~ 0$

So now I'm wondering if something else has been filling up the frames today.  Has anything changed today that might cause more data than usual to be written to frames?

I'm manually running the wiper script now to clear up some /frames.  Hopefully that will solve the problem temporarily.

  9534   Tue Jan 7 23:24:41 2014 JenneUpdateGeneralIFO plan, list o' things to do

It seems that the most important short-term task we have right now is to figure out what our PRC length is, and what our tolerance from nominal is.  Gabriele and EricQ are going to work on that tomorrow.  If our PRC is of a length that we can't do anything useful for full IFO locking, we need to open up and fix it sooner rather than later.

While we're in there, we need to also put a baffle on the back side of the PRM cage, to protect the OSEMs from stray light.  Den and I discovered before Christmas that turning off the OSEM and OpLev damping to the PRM (while using the POP QPD for ASC) significantly reduced the power fluctuations in the PRC.  We still had arm power fluctuations, but I believe those are likely because our ALS system can't hold an arm precisely at full resonance.  So, putting a black glass baffle with ~2 inch aperture right up against the OSEMs should help a lot.  This week, I'll ask Steve to make me a quickie to-scale cardboard version of the baffles that he has had cut, so I can try securing it to the dirty suspension cage that we have out.  I will also check to make sure I have seen with my own eyes the baffles that I need, and copper wire to tie it to the cage.

Other, lower-priority things that we should do eventually:

* Steve, please find another razor beam dump for the WFS reflections - Rana and I used one of the ones that was there for reflection off the 2 inch lens in the MC refl path (replacing the aluminum dump that has been there for ages).  We also need to label all of our razor dumps with their purpose, with a label on top, so we remember not to remove dumps that are actually in use.

* At some point, we should change the one remaining steering mirror in the main PSL path that is aluminum, to a steel Polaris ("Polanski" or "Polish") mount.  For now, we should just make sure we have one handy.  Hopefully this will help reduce the PMC transmission drift that we see.

* Steve, in the morning sometime this week, can you please do a test of the drift of the IOO QPDs?  We'd like to see a trend that is maybe 30 or 60 minutes long of the QPD signals.  First 10 minutes, all lights in IFO room off.  Then, 10 minutes with the lights in the PSL on.  Then, the rest of the time the PSL lights off.  We want to see if these are hot enough to be causing a big temperature change in the PSL box, which may then be causing some optics to drift.

* QPD code in the simulink models (trans QPDs, but also OpLevs, and anywhere else we do normalization) needs to have anti-divide-by-zero protection.  I'll take care of this, it should be a quick copy of what we have elsewhere in the simulink code.

* Note to self for the future, instead of doing a dither alignment for the ASS for the arms, we can use the IP POS and IP ANG, as well as end transmission QPD signals.  However, for now, the ASS is working just fine.

* We want to go back to the idea of putting a lens into the in-vac IP ANG path, to avoid the clipping that Manasa and I were seeing tonight.  We want something of order 2inch diameter, 1meter focal length.  The material doesn't matter, but we do want it AR coated for 1064nm on both sides.  We also need to make sure that we could use a fixed 2 inch in-vac mirror mount, or something, to hold this lens.  If that won't work, we need to come up with another plan.  Manasa is working on thinking about precisely what lens we want to buy for a nice guoy phase telescope for IPANG, so we'll buy a lens after she puts her conclusions in the elog.

* An idea for the MC spots plot that Rana had was to plot the beam tilt and translation, rather than the raw spot positions on the mirrors.  The point of this would be to make it easier to see what the output beam from the MC looks like.  For MC pointing, we should also think about what our actual tolerances are.  The biggest thing is that we need to get through the Faraday without being too close to any edge, and also the REFL beam needs to come back through without clipping.  For now, we're just visually checking that the POP beam and the REFL beam both look unclipped since we don't have access to good camera views of either side of the Faraday.

  9535   Tue Jan 7 23:50:27 2014 jamieUpdateCDS/frames space cleared up, daqd stabilized

The wiper script is done and deleted a whole bunch of stuff to clean up some space:

controls@fb ~ 0$ /opt/rtcds/caltech/c1/target/fb/wiper.pl --delete

Tue Jan  7 23:09:21 PST 2014

Directory disk usage:
/frames/trend/minute_raw 385927520k
/frames/trend/second 125729084k
/frames/full 12552144324k
/frames/trend/minute 2311404k
Combined 13066112332k or 12759875m or 12460Gb

/frames size 13460088620k at 97.07%
/frames above keep value of 95.00%
Frame area size is 12401156668k
/frames/full size 12552144324k keep 11781098835k
/frames/trend/second size 125729084k keep 24802313k
/frames/trend/minute size 2311404k keep 620057k
Deleting some full frames to free 771045488k
- /frames/full/10685/C-R-1068567600-16.gwf
- /frames/full/10685/C-R-1068567616-16.gwf
...
controls@fb ~ 0$ df -h /frames
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              13T   12T  826G  94% /frames
controls@fb ~ 0$
So it cleaned up 826G of space.  It looks like the fb is stabilized for the moment.  On site folks should confirm...

 

asdfasdfsadf sadf asdf

  9536   Tue Jan 7 23:53:35 2014 JamieUpdateCDSdaqd can't connect to c1vac1, c1vac2

dadq is logging the following error messages to it's log related to the fact that it can't connect to c1vac1 and c1vac2:

CAC: Unable to connect because "Connection timed out"
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1vac2.martian:5064"
    Source File: ../cac.cpp line 1127
    Current Time: Tue Jan 07 2014 23:50:53.355609430
..................................................................
CAC: Unable to connect because "Connection timed out"
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1vac1.martian:5064"
    Source File: ../cac.cpp line 1127
    Current Time: Tue Jan 07 2014 23:50:53.356568469
..................................................................

 Not sure if this is related to the full /frames issue that we've been seeing.

  9538   Wed Jan 8 13:46:39 2014 JenneUpdateGeneralIFO plan, PRM baffle

Quote:

While we're in there, we need to also put a baffle on the back side of the PRM cage, to protect the OSEMs from stray light.  Den and I discovered before Christmas that turning off the OSEM and OpLev damping to the PRM (while using the POP QPD for ASC) significantly reduced the power fluctuations in the PRC.  We still had arm power fluctuations, but I believe those are likely because our ALS system can't hold an arm precisely at full resonance.  So, putting a black glass baffle with ~2 inch aperture right up against the OSEMs should help a lot.  This week, I'll ask Steve to make me a quickie to-scale cardboard version of the baffles that he has had cut, so I can try securing it to the dirty suspension cage that we have out.  I will also check to make sure I have seen with my own eyes the baffles that I need, and copper wire to tie it to the cage.

Steve may actually be onto something with the clamps that he had made a year and a half ago.  These clamps hold the glass, and then clamp to the base of the suspension cage.  Not the table, but the base of the suspension cage. The drawings are in elog 6344.  I'm not sure that the 1/4-20 holes in the clamp things are exactly where we'll want them, but we should be able to just dog it down to the base of the suspension.  I need to check this, but it may be even easier than tieing the glass to the cage.

Also, something to think about is that the earthquake stop screws extend backwards farther than the OSEMs.  I'm not sure anymore if we have shorter 1/4-20 earthquake stops around (if we do, they should be in the cleanroom shelves), but if we can't swap those out, they'll limit how close we can get to the OSEMs. 

Here's an overhead photo from 6 Sept 2012:

PRMcage_6Sept2012.JPG

  9540   Wed Jan 8 17:53:26 2014 manasaUpdateGeneralIFO plan, IPANG telescope

For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I have put down a solution where we use a pair of lenses; one of which will be mounted in-vacuum in the ETMY chamber and the other on the endtable.
This way we will also allow have some freedom to configure the layout out-of vacuum in case the need arises. The layout will look something like in the cartoon:
IPANG_layout.png

I also made a choice of using longer focal length lenses (CVI 2" lenses f =1 m). Below is the beam path summary for IPANG telescope. I have used the waist diameter at the ITM for propagation. The endtable is roughly at 41.2m. The QPD will be placed in front of the waist (w0=47um).
IPANG.png 

  9542   Thu Jan 9 10:34:58 2014 SteveUpdatePSLPSL pointing changes in pitch

  IOO QPDs tested in dark, lighted and open PSL enclosure. The created temperature change 0.03 C has  effect on monitoring  in pitch.

 

 Atm1,  all lights off 10 min, PSL enclosure lights on  10 min, all lights off 15 min, open  door # 11 at north east corner of enclosure ( HEPA filters are running at 30V ) for 10 min, closed-dark enclosure 15 min

              dark 10, lighted 10, dark 15, open-dark 10 and closed-dark 15 minutes

 

Atm2, Pitch drift of 24 hours does not recover

Attachment 1: Lfnfdnc.png
Lfnfdnc.png
Attachment 2: 24hPSLpointing.png
24hPSLpointing.png
  9543   Thu Jan 9 17:21:45 2014 ranaUpdateGeneralIFO plan, IPANG telescope

Quote:

For the IPANG telescope design, we are in the 'beyond the Rayleigh range' regime. So using a single lens to make the beam small is not a great idea. I

Can you please explain this? I don't understand what exactly is the issue or 'great idea'.

I think we should be OK with just a single lens in the vacuum. But what we need is the ray tracing analysis to show what the effect will be on the IPANG readout.

  9545   Fri Jan 10 10:28:03 2014 SteveUpdatePSLPSL pointing changes

 

I looked at IOO QPDs again. QPD_POS was clamped by one screw. Dog clamp was added on the unclamped side.

QPD_ANG chassis has no isolation to optical table..._POS has.  QPD_ANG  base was tightened also.

Both QPDs moved a little bit but I did not centered them.  The spot sizes are 2-3 mm  They should be smaller.

How ever, we still can not explane the pitch movement of the IOO beam

 

Razor beam dumps were labeled at the AP table.

 

The 40m roof was cleaned from leafs this morning.

 

 

Attachment 1: clamped.png
clamped.png
  9547   Fri Jan 10 15:33:02 2014 SteveUpdatePSLlaser drift monitor set up idea

this locationQuote:

Quote:

Quote:

I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

 The PMC transmission continuously degrades. In order to see what is really drifting the laser output after PBS was sampled as shown.

 IOO pointing is drifting in pitch. I'd like to use a QPD instead of the paper target to see if the Innolite output is stable. The idea is to move temporarily IOO-QPD_POS to  this location

Attachment 1: 2daysDrift.png
2daysDrift.png
  9549   Mon Jan 13 11:08:48 2014 SteveUpdatePSL3 good days of IOO pointing

 Three good days of IOO pointing: Friday, Sat and Sun    What was changed?  May be the clamping on Friday?

IOO vertical changes recovering as tempeture. IP is clipping at plastic enclosure of ETMY

 

NOTE: ANTS at the PSL optical table.  I will mop with chemicals tomorrow if we see more.

 

Attachment 1: 3gdPSLpointing.png
3gdPSLpointing.png
  9550   Mon Jan 13 16:50:55 2014 SteveUpdateVACMaglev controller needs service

Quote:

 The date is correct on this monitor.

Last stored RGA scan data Dec 20, 2013

IFO pressure at CC1 5.8e-6 Torr

Valve configuration: Vacuum Normal, confirmable only by manual checking of position indicators and pressure gauge controllers  readouts

 

 The Osaka TG390MCAB maglev turbo pump's controller TC010M has passed the 40,000 hrs of operation. This triggered the " alarm" LED  warning light to come on. 

It is normal maintenance.  Maglev TP-1 is running perfectly.  Osaka will send us a loaner-controller that we can use while they do the std maintenance.

I'm thinking of ~ February to do this.

  9552   Tue Jan 14 10:12:12 2014 SteveUpdatePSLlaser drift monitor set up idea

Quote:

this locationQuote:

Quote:

Quote:

I wonder what's drifting between the laser and the PMC? And why is it getting worse lately?

 The PMC refl is bad in pitch today, and the transmission is only 0.76, rather than our usual 0.83ish.

I did a quick, rough tweak-up of the alignment, and now we're at 0.825 in transmission.

 The PMC transmission continuously degrades. In order to see what is really drifting the laser output after PBS was sampled as shown.

 IOO pointing is drifting in pitch. I'd like to use a QPD instead of the paper target to see if the Innolite output is stable. The idea is to move temporarily IOO-QPD_POS to  this location

 I do like to move IOO-QPD_POS temporarily to see that the feedback has anything to do with with the pointing.

Attachment 1: bad4thday.png
bad4thday.png
  9553   Tue Jan 14 10:34:57 2014 SteveUpdatePSLgreen transmission measurment

GariLyn is using our green light on the west side of the PSL table. The green PDA36As were moved and the HEPA turned up to 60V

Attachment 1: greenPickUp.jpg
greenPickUp.jpg
  9556   Wed Jan 15 13:05:30 2014 JenneUpdatePEM4.4 EQ in Fontana, CA

It looks like there was a 4.4 magnitude earthquake near Fontana, CA around 1:30am today.  This tripped all of the suspension watchdogs, which Q has just now re-enabled. 

  9558   Wed Jan 15 18:42:57 2014 JenneUpdateASCPOP ASC QPD offline for a few hours this afternoon

I was in the lab, near the south end of the ITMX oplev table, looking for something, and I bumped the POP ASC QPD's power supply.  I thought that it was fine, but did not adequately check it.  When EricQ asked me just now about why the PRC is so wobbly today, I checked, and the power for the QPD wasn't properly connected (it's kind of a crappy connector, that if you nudge, contacts or loses contact).  Anyhow, I restored power to the QPD, and the PRC looks a little more stable now.  My fault for not checking more carefully, and my apologies to Q and Gabriele for their frustrations this afternoon.

  9559   Thu Jan 16 08:19:29 2014 SteveUpdatePEM4.4 and 3.8M local earth quakes


It looks like there was a 4.4 magnitude earthquake near Fontana, CA around 1:30am today.  This tripped all of the suspension watchdogs, which Q has just now re-enabled. 

   Earth quake shake down yesterday Atm1

Atm2, today's shake

Attachment 1: local4.4eq.png
local4.4eq.png
Attachment 2: local3.8eq.png
local3.8eq.png
  9560   Thu Jan 16 21:38:13 2014 ericqUpdateLSCRepeat of PRC length measurement

[ericq,Jenne]

Since we don't have agreement between the measurements we made the other day and the earlier estimations, I wanted to repeat the demodulation angle measurement. We had to do a few things to keep the PRMI locked, since in the last few days, it hasn't been stable enough.

The mode cleaner had been very fussy lately; the WFS were pushing in a way that caused fast oscillations of the transmission and reflection powers. I turned off the servos, manually aligned the mode cleaner to transmission of about 15k and refl of about .4, centered the beams on the WFS QPDs, and turned the loops back on. Things were much stable after that. Also, Jenne noticed that the PMC loop had walked the laser PZT temperature to a bad place, and fixed it.

After aligning the carrier locked PRMI, the last piece needed to get things stable enough for sideband locking was turning off the angular damping on the PRM suspension screen (this was turned back on when we were done). Waiting until evening noise levels probably helped too. We used a 1000 count MICH excitation in the PRMI case, and recorded data for about a minute in one degree steps around the demodulation phase that looked to put the excitation entirely within the Q of the PD. Also, we notched out the excitation frequency in the MICH servo bank for today's measurement; I think it's outside of the loop bandwidth anyways, but it's good to be sure. 

Jenne and I pondered a bit whether changing the AS55 demodulation phase while it (AS55 Q) is being used as the MICH control signal introduces subtleties that we haven't anticipated, but couldn't come up with anything concrete. Changing the angle from the what maximizes the Q just looks like a slight change in MICH gain, and shouldn't affect the phase of the excitation signal on the PD...

In any case, the data have been recorded, and the results will follow soon. 

  9563   Tue Jan 21 19:41:59 2014 JenneUpdateElectronicsRF distribution box power button fail

Rana, Gabriele and I are trying to measure the FSR of the PRC (elog about that later), and we turned off the power to the RF generation box so that we could switch cables at the EOM combiner.  However, as in elog 9101, the power button won't latch when we try to turn the power back on.  All 3 of us tried, to no avail.  For our measurement, poor Gabriele is standing holding the button pushed in, so that we can have some RF sidebands. 

Tomorrow, we'll have to pull the RF generation box, and put in a better switch.

ELOG V3.1.3-