40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 152 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  9428   Wed Nov 27 14:45:49 2013 JenneUpdateCDStiming problem at c1iscex IO chassis

 [Koji, Jenne]

The new fiber arrived today, and we tried it out.  No luck.  We think it is the timing card, so we'll need to get one, since we can't find a spare.

Order of operations:

* Lay new fiber on floor, plugged it in at both ends, saw no fiber link lights.

* From control room, killed all models running on c1iscex, shutdown computer.  Still no link lights.

* Power cycled computer and IO chassis.

* Tried plugging new fiber into different port on Master Timing Sequencer, with other end still plugged in to c1iscex.  Still no link lights.

* Looked around with flashlight at Xend IO chassis.  The board that the fiber is connected to does not have a power light, although the board next to it has 2.  We compared with the SUS IO chassis, and the board there with the fiber has one power light, plus the fiber link lights, as well as 2 on the board next to the fiber.  So, perhaps there's a problem with power distribution on the timing board at the Xend? 

* Unplugged and replugged the power connector to the timing board, inside the IO chassis, board next to the fiber's board got lights back, but the fiber's board did not.  However, power must be going through the board with the fiber attached, to the next board, so there's power at least on some part of the timing board, just not the whole thing.

From this, we conclude that the blue fiber that was in place is probably fine (or is not found guilty), and that we need a replacement timing board.  Koji didn't find one in the "CDS stuff" boxes underneath the Jenne Laser, and I feel like I recall Jamie saying that we would have to get a spare from somewhere else.  We rolled up the new spare fiber, and put it in the box with other "CDS Stuff" under the Jenne Laser table.

  9427   Mon Nov 25 17:28:33 2013 JenneUpdateCDStiming problem at c1iscex IO chassis

Quote:

There is definitely a timing distribution malfunction at the c1iscex IO chassis.  There is no timing link between the "Master Timer Sequencer D050239" at the 1X6 and the c1iscex IO chassis.  Link lights at both ends are dead.  No timing, no running models.

It does not appear to be a problem with the Master Timer Sequencer.  I moved the c1iscey link to the J15 port on the sequencer and it worked fine.  This means its either a problem with the fiber or the timing card in the IO chassis.  The IO timing card is powered and does have what appear to be normal status lights on (except for the fiber link lights).  It's getting what I think is the nominal 4V power.  The connection to the IO chassis backplane board look ok.  So maybe it's just a dead fiber issue?

I do not know what could have been the problem with c1auxex, or if it's related to the fast timing issue.

 Steve and Koji looked around, and called around, and there seem to be no spare fibers that are long enough to reach the end, so Steve has ordered

"Tripp Lite N520-30M 100' Multimode Duplex 50/125 Fiber Optic Patch Cable LC/LC"

 and it should be here tomorrow.

  9426   Mon Nov 25 12:57:54 2013 JamieUpdateCDStiming problem at c1iscex IO chassis

There is definitely a timing distribution malfunction at the c1iscex IO chassis.  There is no timing link between the "Master Timer Sequencer D050239" at the 1X6 and the c1iscex IO chassis.  Link lights at both ends are dead.  No timing, no running models.

It does not appear to be a problem with the Master Timer Sequencer.  I moved the c1iscey link to the J15 port on the sequencer and it worked fine.  This means its either a problem with the fiber or the timing card in the IO chassis.  The IO timing card is powered and does have what appear to be normal status lights on (except for the fiber link lights).  It's getting what I think is the nominal 4V power.  The connection to the IO chassis backplane board look ok.  So maybe it's just a dead fiber issue?

I do not know what could have been the problem with c1auxex, or if it's related to the fast timing issue.

  9425   Mon Nov 25 10:57:14 2013 KojiUpdateCDSwoes on the X-end hosts

This morning I came in the 40m then found
1) c1auxex was throwing out the same errors as recently seen.
2) c1iscex processes had errors which persisted even after the mx stream reset.

1) c1auxex - fixed

Tried telnet c1auxex => rejected by the host

Went down to the south end. Power cycled the target. Came back to the control room.
=> Confirmed the epics read/write is back.
Burtrestored the epics vars for the target to the snapshot on 31th Oct at 5:07.

2) c1iscex - still not fixed

ssh c1iscex
rtcds restart all
=> c1x01 is still in red. 
Followed the procedure on the elog entry 9007. => Still the same error.

At least c1x01 is stalled. Here is the status.

Sync Source is TDS.
C1:DAQ-DC0_C1X01_STATUS is 0x2bad.
C1:DAQ-DC0_C1X01_CRC_SUM stays 0.
The screen shot is attached.

dmesg related to c1x01

controls@c1iscex ~ 0$ dmesg |grep c1x01
[   32.152010] c1x01: startup time is 1069440223
[   32.152012] c1x01: cpu clock 3000325
[   32.152014] c1x01: Epics shmem set at 0xffffc9001489c000
[   32.152208] c1x01: IPC at 0xffffc90018947000
[   32.152209] c1x01: Allocated daq shmem; set at 0xffffc9000480c000
[   32.152210] c1x01: configured to use 4 cards
[   32.152211] c1x01: Initializing PCI Modules
[   32.152226] c1x01: ADC card on bus b; device 4 prim b
[   32.152227] c1x01: adc card on bus b; device 4 prim b
[   32.154801] c1x01: pci0 = 0xdc300400
[   32.154837] c1x01: pci2 = 0xdc300000
[   32.154842] c1x01: ADC I/O address=0xdc300000  0xffffc90003f62000
[   32.154845] c1x01: BCR = 0x84060
[   32.154858] c1x01: RAG = 0x117d8
[   32.154861] c1x01: BCR = 0x84260
[   32.583220] c1x01: SSC = 0x16
[   32.583223] c1x01: IDBC = 0x1f
[   32.583236] c1x01: DAC card on bus 14; device 4 prim 14
[   32.583237] c1x01: dac card on bus 14; device 4
[   32.584527] c1x01: pci0 = 0xdc400400
[   32.584546] c1x01: dac pci2 = 0xdc400000
[   32.584551] c1x01: DAC I/O address=0xdc400000  0xffffc90003f6a000
[   32.584555] c1x01: DAC BCR = 0x810
[   32.584678] c1x01: DAC BCR after init = 0x30080
[   32.584681] c1x01: DAC CSR = 0xffff
[   32.584687] c1x01: DAC BOR = 0x3415
[   32.584693] c1x01: set_8111_prefetch: subsys=0x8114; vendor=0x10e3
[   32.584722] c1x01: Contec 1616 DIO card on bus 23; device 0
[   32.593429] c1x01: contec 1616 dio pci2 = 0x4001
[   32.593430] c1x01: contec 1616 diospace = 0x4000
[   32.593434] c1x01: contec dio pci2 card number= 0x0
[   32.593439] c1x01: Contec BO card on bus 18; device 0
[   32.593447] c1x01: contec dio pci2 = 0x3001
[   32.593448] c1x01: contec32L diospace = 0x3000
[   32.593451] c1x01: contec dio pci2 card number= 0x0
[   32.593456] c1x01: 5565 RFM card on bus 7; device 4
[   32.597218] Modules linked in: c1x01(+) open_mx mbuf
[   32.599939]  [<ffffffffa002e430>] mapRfm+0x71/0x392 [c1x01]
[   32.600199]  [<ffffffffa002ec91>] mapPciModules+0x540/0x8cf [c1x01]
[   32.600458]  [<ffffffffa002f2c1>] init_module+0x2a1/0x9d6 [c1x01]
[   32.600717]  [<ffffffffa002f020>] ? init_module+0x0/0x9d6 [c1x01]
[   32.616194] c1x01: RFM address is 0xd8000000
[   32.616196] c1x01: CSR address is 0xdc000000
[   32.616206] c1x01: Board id = 0x65
[   32.616209] c1x01: DMA address is 0xdc000400
[   32.616213] c1x01: 5565DMA at 0xffffc90003f72400
[   32.616215] c1x01: 5565 INTCR = 0xf010100
[   32.616217] c1x01: 5565 INTCR = 0xf000000
[   32.616218] c1x01: 5565 MODE = 0x43
[   32.616220] c1x01: 5565 DESC = 0x0
[   32.616232] c1x01: 5 PCI cards found
[   32.616233] c1x01: ***************************************************************************
[   32.616234] c1x01: 1 ADC cards found
[   32.616235] c1x01:     ADC 0 is a GSC_16AI64SSA module
[   32.616236] c1x01:         Channels = 64
[   32.616236] c1x01:         Firmware Rev = 34
[   32.616238] c1x01: ***************************************************************************
[   32.616239] c1x01: 1 DAC cards found
[   32.616239] c1x01:     DAC 0 is a GSC_16AO16 module
[   32.616240] c1x01:         Channels = 16
[   32.616241] c1x01:         Filters = None
[   32.616242] c1x01:         Output Type = Differential
[   32.616242] c1x01:         Firmware Rev = 6
[   32.616244] c1x01: MASTER DAC SLOT 0 1
[   32.616244] c1x01: ***************************************************************************
[   32.616246] c1x01: 0 DIO cards found
[   32.616246] c1x01: ***************************************************************************
[   32.616248] c1x01: 0 IIRO-8 Isolated DIO cards found
[   32.616248] c1x01: ***************************************************************************
[   32.616250] c1x01: 0 IIRO-16 Isolated DIO cards found
[   32.616250] c1x01: ***************************************************************************
[   32.616252] c1x01: 1 Contec 32ch PCIe DO cards found
[   32.616252] c1x01: 1 Contec PCIe DIO1616 cards found
[   32.616253] c1x01: 0 Contec PCIe DIO6464 cards found
[   32.616254] c1x01: 2 DO cards found
[   32.616255] c1x01: TDS controller 0 is at 0
[   32.616256] c1x01: Total of 4 I/O modules found and mapped
[   32.616257] c1x01: ***************************************************************************
[   32.616259] c1x01: 1 RFM cards found
[   32.616260] c1x01:     RFM 0 is a VMIC_5565 module with Node ID 41
[   32.616261] c1x01: address is 0x18d80000
[   32.616261] c1x01: ***************************************************************************
[   32.616262] c1x01: Initializing space for daqLib buffers
[   32.616263] c1x01: Initializing Network
[   32.616264] c1x01: Found 1 frameBuilders on network
[   32.616265] c1x01: Epics burt restore is 0
[   33.616012] c1x01: Epics burt restore is 0
[   34.617018] c1x01: Epics burt restore is 0
[   35.618017] c1x01: Epics burt restore is 0
[   36.619011] c1x01: Epics burt restore is 0
[   37.621007] c1x01: Epics burt restore is 0
[   38.622008] c1x01: Epics burt restore is 0
[   39.733257] c1x01: Sync source = 4
[   39.733257] c1x01: Waiting for EPICS BURT Restore = 1
[   39.793001] c1x01: Waiting for EPICS BURT 0
[   39.793001] c1x01: BURT Restore Complete
[   39.793001] c1x01: Found a BQF filter 0
[   39.793001] c1x01: Found a BQF filter 1
[   39.793001] c1x01: Initialized servo control parameters.
[   39.794002] c1x01: DAQ Ex Min/Max = 1 3
[   39.794002] c1x01: DAQ XEx Min/Max = 3 53
[   39.794002] c1x01: DAQ Tp Min/Max = 10001 10007
[   39.794002] c1x01: DAQ XTp Min/Max = 10007 10507
[   39.794002] c1x01: DIRECT MEMORY MODE of size 64
[   39.794002] c1x01: daqLib DCU_ID = 19
[   39.794002] c1x01: Calling feCode() to initialize
[   39.794002] c1x01: entering the loop
[   39.794002] c1x01: ADC setup complete
[   39.794002] c1x01: DAC setup complete
[   39.794002] c1x01: writing BIO 0
[   39.814002] c1x01: writing DAC 0
[   39.814002] c1x01: Triggered the ADC
[   40.874003] c1x01: timeout 0 1000000
[   40.874003] c1x01: exiting from fe_code()

 

Attachment 1: Screenshot.png
Screenshot.png
  9424   Fri Nov 22 16:32:08 2013 SteveUpdateVACRGA scan at day 108

Quote:

 

 Valve configuration: Vacuum Normal

 

Attachment 1: RGAscanVacNormal108d.png
RGAscanVacNormal108d.png
Attachment 2: day108.png
day108.png
Attachment 3: pd76m110d.png
pd76m110d.png
  9423   Fri Nov 22 14:21:43 2013 JamieUpdateComputer Scripts / ProgramsDAQ?

Quote:

Jamie, I think the computers know that you are away. c1lsc keeps going down.

The short time plots are correct.

Is there some indication from the attached image that there is a problem with c1lsc?  I see some drop outs in the channels you're plotting, but those are not c1lsc channels.

The channels with the drop outs are I think derived channels, as opposed to ones that are generated on the front end.  Therefore they could have been affected by the c1auxey outages from earlier in the week.

  9422   Fri Nov 22 09:54:22 2013 SteveUpdateCDSDAQ?

Jamie, I think the computers know that you are away. c1lsc keeps going down.

The short time plots are correct.

Attachment 1: comp8d.png
comp8d.png
  9421   Thu Nov 21 16:32:20 2013 SteveUpdateIOOPMC needs a touch of love

 

 The PMC power degrading on this 3 days plot. MC2 -T = 14,200 counts. C1:IOO-MC_TRANS_SUM can not be ploted in dataviewer. The MEDM screen has a valid number.

Initial pointing is not so bad (what does "not so bad" mean ???)

C1iscey comes and goes again.

 

Attachment 1: PMCplus.png
PMCplus.png
  9420   Thu Nov 21 10:24:50 2013 KojiUpdateSUSbeam dumps

You don't need the fourth glass piece on the diamond beam dump.

  9419   Thu Nov 21 09:56:15 2013 SteveUpdateSUSgreen glass beam dumps

 Green welding glass  is used in these Koji designed dumps (D1102375)

We have 10 pieces of hexagonal  dumps for 5.5" high beam They require 1 5/8" space.  Atm1 

Atm2, Large V traps are 3" tall only, 5 pieces

Atm3, Diamond shapes come with 2" and 1" square green glass ( after Koji's correction I removed the not needed glass ) D1102445 and D1102442

 

Baked green glass pieces in stock: 30 pieces of 2" x 2" ,---  30 pieces of 1" x 1",David 4-17-2014

Baked diamond holders in stock: 10 pieces of 2" and 10 pieces of 1"David 4-17-2014

PEEK shims 2" and  1"

Baked green glass pieces blank:  4 pieces of 7" x 9"

Baked green glass pieces with 40 mm hole on 7" x 9" for SUS tower:  7 pieces.

NOTE: in December 2012 we talked about 50 mm aperture need. What diameter is the right one  today? 51 mm aperture plates are cut 4-10-2014

Attachment 1: HEXdump.jpg
HEXdump.jpg
Attachment 2: Vdump.jpg
Vdump.jpg
Attachment 3: Diamond1_2inchTraps.jpg
Diamond1_2inchTraps.jpg
  9418   Wed Nov 20 17:05:15 2013 JenneUpdateLSCXend QPD and Whitening board replaced

[EricQ, Jenne]

We have put the Xend QPD back in place, and centered it.  The whitening board was replaced by me a few days ago.

We also went down to the Yend and centered the Yend QPD.

I used the offset.py script that Masayuki wrote to zero the offsets of the individual quadrants when the PSL shutter was closed, and then I averaged the output of the SUM filter banks, and made the gains 1/AvgSum, so that both the Thorlabs PD and the QPD are normalized to 1 at single-arm resonance, for each arm.

I don't know what the gain is of the QPD head off the top of my head, relative to the Thorlabs PD, but eventually we want them to be the same, so that 1=1 and 700=700 on each PD.

  9417   Wed Nov 20 16:05:52 2013 JenneUpdateLSCPRMI carrier locking, OpLev Check

[Jenne, EricQ]

We locked the PRMI on carrier again today, after lunch.  Following a suggestion from the 40m meeting, we wanted to compare the PRMI carrier fluctuations with the new vs. old OpLev servo for the PRM. 

To do change between the servo shapes, I put in an elliptic lowpass at 35Hz, since I overwrote that with the 55Hz lowpass the other day.  The only other change between shapes is turning on and off my boost / emphasis filter. 

So, the scenarios were:

(1) New OpLev servo

(2) Old OpLev servo (no boost, but 3.2Hz res gain and bounce roll notches on), with 55Hz lowpass

(3) Old OpLev servo with 35Hz lowpass

For scenario (1), like last night, there were small power fluctuations.  For scenario (2), most of the time there were small power fluctuations, but occasionally there would be a kick somewhere, and the power would dip down by ~50%, and the fluctuations would continue like a ringdown for a few seconds, and then we'd be back to small fluctuations until the next kick.  For scenario (3), even with trying different LSC servo gains, we could not get the PRMI to lock on carrier for more than a few tenths of a second.  During that time, the power fluctuations were very large. 

So, the old oplev servo was kind of okay, but the lowpass at 35 Hz was bad, bad, bad.  It seems that the new OpLev servo is doing good things for us.

  9416   Wed Nov 20 01:10:38 2013 JenneUpdateLSCPRMI carrier locking

I have increased the gain of the MICH loop to -100, and set FMs 2,3,7 to be triggered.  I have also increased the PRCL gain to 2.  The PRCL ASC pitch and yaw gains used to be -0.004, but I have increased them both to -0.01.

Now, I'm seeing power fluctuations in POPDC of ~200 pk-pk, at an average value of 2650.  That's a RIN of 7.5% .  If I turn off all OSEM damping for the PRM (after the cavities are already locked), I get POP DC fluctuations of 100 pk-pk at the same average value, so a RIN of 4%. 

Back on October 30th (elog 9338), we had an average POPDC of 400, with fluctuations of 200 pk-pk, so a RIN of 50%. 

So, I am pleased that, with the carrier locking, I have lower power fluctuations.  And, since there is more overall power in the PRC right now than we had 3 weeks ago, I'm hopeful that a PRMI+arms test will have lower power fluctuation.

Also, a note, when my MICH gain was still low, I had lots of power fluctuation at the AS port, which was coherent with my POPDC power fluctuations (which makes sense).  At that time, my overall RIN was higher than it is now (although I neglected to write down the numbers), but more significantly, I saw occasional 'kicks', where the ASDC and POPDC powers would ring for 1 or 2 seconds, with power fluctuations of order 40%.  I have not seen any of those kicks since increasing the MICH gain.

  9415   Tue Nov 19 21:59:35 2013 manasaUpdateLSCPRMI carrier locking

Quote:

Since we have never tried to lock PRMI on carrier after the folding mirrors were flipped, I tried to lock PRCL on carrier.

I thought this might give us some idea about the PRC stability for resonance or some clue as to what happens to the PRM suspensions and PRMI stability when we have carrier resonating in the cavity.

I changed the sign of the PRCL gain and also tried increasing the gain. But this did not work and I was not able to carrier lock PRMI. May be I am missing to change some parameter that is very trivial?

PRMI could not be locked on carrier using 3f. The configuration from the last time when PRMI was carrier locked (elog) were used and PRMI locked on carrier with these settings.

== PRMI carrier ==
  MICH: AS55_Q_ERR, AS55_PHASE_R = -12 deg,  MICH_GAIN = -0.2, feedback to ITMX(-1),ITMY(+1)
  PRCL: REFL55_I_ERR, REFL55_PHASE_R = 70 deg, PRCL_GAIN = 1.0, feedback to PRM

Below is the video capture showing the PRM front and back face when carrier flashes with few second locks.

EDIT by JCD:

The demod phase numbers that Manasa is quoting above were correct back in March, when the elog she's quoting from was written.  They are not true now, since we've adjusted things in the last 8 months.  Also, I'm using a gain of -1.5 for MICH, and +1.5 for PRCL.  MICH has no FMs triggered, PRCL has FM 2,3,6 triggered.  Since we won't be using this configuration for full locking, but just for some tests, I'm currently using AS55 Q for MICH, and REFL 55I for PRCL, and using the ITMs to actuate on MICH for today.

  9414   Tue Nov 19 21:28:05 2013 manasaUpdateLSCPRMI carrier locking

Since we have never tried to lock PRMI on carrier after the folding mirrors were flipped, I tried to lock PRCL on carrier.

I thought this might give us some idea about the PRC stability for resonance or some clue as to what happens to the PRM suspensions and PRMI stability when we have carrier resonating in the cavity.

I changed the sign of the PRCL gain and also tried increasing the gain. But this did not work and I was not able to carrier lock PRMI. May be I am missing to change some parameter that is very trivial?

  9413   Tue Nov 19 17:47:17 2013 JenneUpdateLSCPRMI+2arms attempt

So far this afternoon, I have redone the IFO alignment, locked both arms with ALS, moved both arms off resonance, locked PRMI, and started bringing one arm back to resonance. 

The alignment was really not good, which I knew yesterday, but the ASS wasn't working yesterday.  I hand-did the alignment, and tried locking, which was easier with the slightly better alignment.

I locked both arms with ALS, found the resonances, and then moved them off resonance using Masayuki's scripts.

I then restored the PRM alignment, and locked the PRMI. 

I started bringing the Yarm back, but I kept losing lock when I got to about 0.1 transmission.


After losing lock several times, I switched over to looking at the ASS. I have figured out the problem, and fixed it.  The ASS for the arms now works again.

Looking at the StripTool plots of the lockin outputs for each arm, it was clear that the "L" traces were their usual size, but the "T" traces, which are demodulated versions of the transmission DC PDs, were tiny.  I investigated in the model, and the answer is obvious:  both the LSC and the ASS get the transmission information directly from the end sus computers.  Since we recently moved the normalization gain for the transmission diodes into the SUS models from the LSC model, this means that the ASS was seeing a differently sized signal than it had in the past. 

To fix this, I put a gain into the T_DEMOD_SIG filter banks for all 8 lockins that use info from the transmission DC PDs.  I used 1/g , where g is the gain that is in the C1:SUS-ETM#_TR#_GAIN channels.  For TRX, that number is -0.003, and for TRY that number is 0.002 .  So, in the .snap file that is used when turning on the ASS, I have given the Xarm lockins a gain of -333, and the Yarm lockins a gain of 500.  I chose this place, because the only thing that has happened to the signal until this point is a bandpass, so the rest of the servo gains can remain the same. 

I tested the ASS, and it works just like it used to.  I let it run, and align all of the optics, then I misaligned by a small amount each of the ETMs, saw that the lockin output values changed, and then were servoed back to zero.  So, it seems all good. 

  9412   Tue Nov 19 15:04:14 2013 JenneUpdateCDSCan talk to AUXEY again

The ETMY sliders on IFO_ALIGN were white again this morning, so I went down to the Yend and pushed the RESET button on auxey.  I then did a burt restore to 00:07am this morning for both auxey and auxex (since the stickers on the machines are still the old naming convention, I wonder if the autoburt is also backwards, so I did both).  Now the 'save' and 'restore' scripts for ETMY are working again.

Hopefully it's all better now, but I'll keep an eye on it.

  9411   Tue Nov 19 14:47:59 2013 manasaUpdateLSCGreen status

Quote:

After I aligned the IR interferometer (no ASS - we still need to figure out what's going on with that), I am trying to find the green beatnotes for each arm.

First, I locked the green lasers to each arm.

I then went out to the PSL table and aligned the Green Yarm path by overlapping the near-field and far-field of the yarm transmission and the PSL green pickoff.  I then turned on the power for the Beat PDs, since it was off (I confirmed that the outputs were plugged into the beatbox, so they are seeing 50 ohms).  I assume that the beat PDs were off since Manasa pulled the Beatbox last week, but there is no elog reference!!  Anyhow, after seeing a real signal, I maximized the DC power on the beat PD for the Yarm.  I then maximized the light on the DC transmission PD for the Yarm.

I looked at the Xarm, and the near-field alignment looks okay, but I haven't checked the far-field.

I started looking for the beatnotes from the control room:

I am changing the SLOW_SERVO2_OFFSETs by 30 counts, and then unlocking and relocking the arms, and checking to see if I see a peak on the RF spectrum analyser. 

The Y offset started at -10320, and I found a beatnote at -11230 (beatnote is about 26MHz).  The X offset started at 4500.  Going larger seemed to get me to a less bright TEM00 mode, so I switched and have been searching by going down in offset, but haven't yet found the beatnote.  I suspect that I actually need to align the X path on the PSL table.  The Y beatnote is very small, about -30dBm, so I also need to tweak the alignment by maximizing the peak value.

 I found the beatnotes for both the X and Y arm ALS this morning. The beat amplitudes measured -5dBm and -18dBm respectively and occurred at SLOW SERVO2 OFFSET 4550 and -10340. I had to only tweak the Y green PSL alignment to increase the beat amplitude.

I locked both the arms using ALS and they were stably locked until MC unlocked for a moment (nearly 16 minutes).

The only thing missing in the list of things you looked into is the status of the PSL slow actuator adjust. Check if this is near zero.

  9410   Tue Nov 19 14:47:44 2013 JenneUpdateLSCPRM oplev measured and modeled TF

Quote:

I forgot how we could turn on the PRM oplev servo and the PRM ASC servo at the same time without conflict.
It seems that this new oplev servo covers 0.04 to 8Hz. It's pretty broadband. Do we inject the ASC signal to the oplev error?

 Right now all 3 servos that control PRM angle (OSEM damping, Oplev, and ASC) run in parallel, and they're all AC coupled. 

  9409   Tue Nov 19 11:56:10 2013 manasa, jenne, ericQUpdateLSCPRM- OSEM side ccd camera is in place

Quote:

Quote:

Can't we somehow hook up this camera to the MUX with the movie mode?
I think both the MUX and the sensoray are compatible with the color video signal.
Only the old CRT is B/W.

 Watek ccd with Tamron lens is hooked up to MUX

This set up close to the viewport glass! Please be careful!

 Video captures when power recycling cavity is locked (videos 1 & 2) and flashing (video 3). Arms stayed misaligned.

1. CH1 and CH2 are loooking at PRM front and back faces. CH3 and CH4 are looking at POP and REFL

 2. CH1 and CH2 are loooking at PRM front and back faces. CH3 and CH4 are looking at the ITMs

3. CH1 and CH2 are loooking at PRM front and back faces. CH3 and CH4 are looking at POP and REFL

  9408   Tue Nov 19 11:33:39 2013 SteveUpdateSUSPRM- OSEM side ccd camera is in place

Quote:

Can't we somehow hook up this camera to the MUX with the movie mode?
I think both the MUX and the sensoray are compatible with the color video signal.
Only the old CRT is B/W.

 Watek 902H ccd with Tamron M118FM50 lens is hooked up to MUX  Please be careful! In this set up the lens is close to the view port glass window! 

Attachment 1: closetoWindowGlass.jpg
closetoWindowGlass.jpg
Attachment 2: DangerUnprotectedViewport.jpg
DangerUnprotectedViewport.jpg
  9407   Tue Nov 19 01:11:19 2013 JenneUpdateLSCGreen status

I am able to lock the Yarm ALS, but not at the full gain that I should be.  I attribute this to my mediocre alignment of the path on the PSL table.  EDIT: Manasa pointed out that I forgot to set the PSL FSS slow adjust to ~zero, so the PSL temperature was off, so there wasn't really any hope for me last night.

However, I decided that I should write down the ALS locking procedure, as shown to me by Masayuki on 29Oct2013, that is written in one of the Control Room notebooks.  So, here it is.  I will write channel names and DTT template names for the Y arm, but the procedure is the same for both arms.

  1. Lock and align arms using IR.
  2. Lock green beams to arms.
  3. Align green beams to arms.
  4. Check beatnote alignment on PSL table.
  5. Find beatnote by changing end laser temperature (C1:ALS-Y_SLOW_SERVO2_OFFSET) in steps of ~30, watch spectrum analyser for peak.  Easier if arms are locked in IR, but disable LSC system before moving to step 6.  Beatnote should be less than ~50 MHz, and should have a peak height of about -20dBm or more.  When doing 2 arms, be careful that beatnotes of the different arms do not overlap in frequency.  Manasa reminds me that you must also remember to set the PSL FSS SLOW actuator adjust to near zero, to get the PSL back near its nominal temperature.
  6. Check UGF of phase tracker loop.  (DTT template in /users/Templates/ALS/YALS_PT_OLTF.xml) Want UGF to be ~2kHz.  Change C1:ALS0BEATY_FINE_PHASE_GAIN as necessary.
  7. Start the watch script from the ALS screen to watch for lockloss.
  8. Look at the PHASE_OUT spectrum (DTT template in /users/Templates/ALS/ALS.xml).
  9. Clear history of Phase Tracker Loop (clear hist button on C1:ALS-BEATY-FINE_PHASE screen).  Very important to do this before step 10, every time you get to step 10  (i.e. if you lose lock and are starting over)!
  10. Check sign of loop gain by using + or - 0.1 for the gain (C1:ALS-YARM_GAIN).  Beatnote should immediately stop moving if you have the sign right.  Otherwise, it'll zip around (if it does, repeat step 9, step 10).
  11. Turn gain of ALS up to ~15.  Watch the PHASE_OUT spectrum, look for the servo bump.  When you see it, back off the gain a little.  Gain of ~15 is usually about the right ballpark.
  12. Turn on FM 2, 3, 6, 7, 8 of C1:ALS-YARM.  (FM5 should already have been on).
  13. Wait for PHASE_OUT spectrum to come down.  Turn on FM10 of C1:ALS-YARM.
  14. Check UGF of ALS loop (DTT template in /users/Templates/ALS/YALS_OLTF.xml).  Want UGF to be about 150 or 170 Hz (at the peak of the phase bubble).  Adjust C1:ALS-YARM_GAIN as necessary.
  15. ALS is locked!  Use something like the "Scan Arm" script from the ALS screen to find IR resonance, or do whatever measurement you want.  Dataviewer template /users/Templates/Dataviewer_Templates/ALSdtv.xml may be useful.
  9406   Tue Nov 19 00:18:30 2013 JenneUpdateLSCGreen ALS wishlist

EricQ said that he's going to start hanging out at the 40m a bit, and I was thinking about what I can have him help me with.  This lead to me writing up a wishlist for things that have to do with the ALS system and green lasers.  Some of these are very small tasks, while others are pretty big.  They are certainly not all high priority.  But, they're on my wishlist.

Calibrations

  • How many counts of SLOW_SERVO2_OFFSET is one green FSR (for each arm)?
  • Calibrate ALS OFFSETTER#_OFFSET counts to nm or Hz offset between the end lasers and the PSL.

Automation / script writing

  • Automate finding the beatnotes (requires freq counters)
  • Automate locking the ALS

Digital Acquisition

  • All 3 laser temperatures
  • Frequency counting of beatnotes

Hardware

  • Install flipper mirrors on the PSL table to switch between trans DCPDs and far-field views of beam overlap for each arm.
  • IR beatnote project - send pickoff of end lasers to PSL via fiber, set up beat detection for each arm, create PLLs.
  • Yarm PZT installation and autoalignment.
  9405   Tue Nov 19 00:07:16 2013 JenneUpdateLSCGreen status

After I aligned the IR interferometer (no ASS - we still need to figure out what's going on with that), I am trying to find the green beatnotes for each arm.

First, I locked the green lasers to each arm.

I then went out to the PSL table and aligned the Green Yarm path by overlapping the near-field and far-field of the yarm transmission and the PSL green pickoff.  I then turned on the power for the Beat PDs, since it was off (I confirmed that the outputs were plugged into the beatbox, so they are seeing 50 ohms).  I assume that the beat PDs were off since Manasa pulled the Beatbox last week, but there is no elog reference!!  Anyhow, after seeing a real signal, I maximized the DC power on the beat PD for the Yarm.  I then maximized the light on the DC transmission PD for the Yarm.

I looked at the Xarm, and the near-field alignment looks okay, but I haven't checked the far-field.

I started looking for the beatnotes from the control room:

I am changing the SLOW_SERVO2_OFFSETs by 30 counts, and then unlocking and relocking the arms, and checking to see if I see a peak on the RF spectrum analyser. 

The Y offset started at -10320, and I found a beatnote at -11230 (beatnote is about 26MHz).  The X offset started at 4500.  Going larger seemed to get me to a less bright TEM00 mode, so I switched and have been searching by going down in offset, but haven't yet found the beatnote.  I suspect that I actually need to align the X path on the PSL table.  The Y beatnote is very small, about -30dBm, so I also need to tweak the alignment by maximizing the peak value.

  9404   Mon Nov 18 21:40:24 2013 KojiUpdateLSCPRM oplev measured and modeled TF

I forgot how we could turn on the PRM oplev servo and the PRM ASC servo at the same time without conflict.
It seems that this new oplev servo covers 0.04 to 8Hz. It's pretty broadband. Do we inject the ASC signal to the oplev error?

  9403   Mon Nov 18 21:26:13 2013 KojiUpdateSUSPRM pictures

Can't we somehow hook up this camera to the MUX with the movie mode?
I think both the MUX and the sensoray are compatible with the color video signal.
Only the old CRT is B/W.

  9402   Mon Nov 18 21:20:54 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

 The auxey machine is back, in that I can interact with the IFO_ALIGN sliders, and they actually make the optic move, but I still can't read and write to and from the EPICs channels:

controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 0$ cdsutils read C1:SUS-ETMY_PIT_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:13:52.044973819
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_PIT_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$ cdsutils read C1:SUS-ETMY_YAW_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:14:07.040168660
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_YAW_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$

This is also causing trouble for the BURT save and BURT restore scripts, that are called from the IFO_ALIGN screen.  If I look at the log that is written from an attempted 'save' of the slider values, I see:

**** READ BURT LOGFILE

--- Start processing files
file >/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt/ETMY.req<
preprocessing ... done
pv >C1:SUS-ETMY_PIT_COMM< nreq=-1
pv >C1:SUS-ETMY_YAW_COMM< nreq=-1
--- End processing files

--- Start searches
C1:SUS-ETMY_PIT_COMM ... ca_search_and_connect() ... OK
C1:SUS-ETMY_YAW_COMM ... ca_search_and_connect() ... OK
--- End searches
Waiting for 2 outstanding search(es) ...
Waiting for 2 outstanding search(es) ...
did not find 2

--- Start reads
C1:SUS-ETMY_PIT_COMM ... not connected so no ca_array_get_callback()
C1:SUS-ETMY_YAW_COMM ... not connected so no ca_array_get_callback()
--- End reads

--- Start wait for pending reads

-- End wait for pending reads 0 outstanding read(s)

**** END BURT LOGFILE

The burt save file has no values in it.  Even if I copy over the ETMX save file and put in the correct channel names and values, a burt restore is unsuccessful. 

So, I can do locking tonight by restoring and misaligning by hand, but this sucks, and needs to be fixed. Other optics (at least PRM, SRM, ETMX) seem to be working just fine.  It's just ETMY that has a problem.

 

  9401   Mon Nov 18 21:02:54 2013 JenneUpdateLSCPRM oplev measured and modeled TF

I have created a new filter for the PRM oplev damping loops.  The biggest change is an increase in the gain between 0.4 - 7 Hz.

Here is a plot of the old, and my new modelled open loop gain:

PRM_OLG_NewOld.png

When I look at my step and impulse response time series, the notches for the bounce and roll were causing some ringing, so for now they are turned off, both in the model and in the real time system.  Also, the "OLG orig" trace has a 4th order elliptic lowpass at 75 Hz, but the real system had a 4th order elliptic low pass at 35 Hz.  When we use 35 Hz in the model, we get lots of ringing.  So, we have moved both model and real system to 55 Hz 4th order elliptic low passes.  Also, also, we haven't been using the 3.3 Hz resonant gain, so I removed that from the modelled loop.

I have put the "boost" for the .4-7 Hz emphasis into FM 7 of the PRM oplev filters.  I also removed several old filters that are never used.  So, for now, the PRM oplevs should have engaged:  FM 1, 7, 9. Pitch gain is +5, yaw gain is -9.  We can consider re-implementing the bounce-roll notches, and the stack resgain if it looks like those are getting rung up, and causing trouble.

Here is a set of spectra, showing the improvement.  It's unclear why yaw is worse than pitch below 4Hz, and why pitch is so much worse than yaw between 4-15 Hz, however for each of pitch and yaw, the before (reference pink and cyan traces) is higher than the improved (dark red, dark blue traces) between a few tenths of a Hz up to 3ish Hz.  And, we're not causing more noise elsewhere.  We do want to monitor to make sure we're not ringing up the bounce and roll modes, but for now they seem fine.

PRM_oplev_improvement.pdf

  9400   Mon Nov 18 19:45:42 2013 RANAUpdateSUSPRM pictures

Nice camera work Steve! I will use these for publicity photos.

Now we need to get one of the video cameras hooked into the MUX so that we can see the flashing and do some image subtraction.

  9399   Mon Nov 18 17:00:20 2013 JenneUpdateSUSPRM pictures

It crossed my mind that, from these pictures, it could be glow from the oplev scattered light that is causing the problem.  However, that seems not possible, since the power fluctuations that we see depend on the presence of the IR light - if it were the oplev light, then when I close the PSL shutter, I should see the same amount of kick, which I don't.  Also, the amount of fluctuation increases with increased stored power in the cavities.  Also, also, Steve reminds me that some of the MC mirrors see similar kicks in their OSEM signals, but they don't have oplevs.

So, I don't believe that the oplev light is causing the problem, but I wanted to write down why I don't think that's it. 

Investigations into OSEM and oplev loops to get rid of the kicks are continuing.

  9398   Mon Nov 18 16:39:38 2013 SteveUpdateSUSPRM pictures

PRM is aligned. IFO is not locked. It is just flashing, including arms. Olympus SP570UZ camera used without IR blocker. Note: PRM side OSEM does not show IR effect.

I will take more pictures with IOO IR blocked and HeNe oplev blocked  tomorrow morning.

Attachment 1: PRM1.JPG
PRM1.JPG
Attachment 2: PRMsurface.JPG
PRMsurface.JPG
Attachment 3: PRM2.JPG
PRM2.JPG
  9397   Fri Nov 15 14:08:13 2013 manasaUpdatePSLPSL Innolight shuts down again

Quote:

I have just turned on the PSL Innolight laser. The laser shut down  with unknown reason a day ago.

PSL NPRO shut down again today for reasons unknown. I was working near the IOO rack and noticed there was no light at both the refl and trans PMC cameras. Jenne and I checked the PSL and found the 'OFF' red switch on the laser driver lit up. Switching ON the green button brought the laser back. PMC and MC autolocked after this.

  9396   Fri Nov 15 13:26:00 2013 JenneUpdateCDSAUXEY is back

Quote:

Quote:

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 This is what I remember doing all the time when Rob was around, but with all the new computers, I forgot whether or not this was allowed for the slow computers.

Anyhow, I went down there and keyed the crate, but auxey isn't coming back.  I'll give it a few more minutes and check again, but then I might go and power cycle it again.  If that doesn't work, we may have a much bigger problem.

 I went and keyed the crate again, and this time the computer came back.  I burt restored to Nov 10th.  ETMY is damping again.

  9395   Fri Nov 15 12:38:50 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 This is what I remember doing all the time when Rob was around, but with all the new computers, I forgot whether or not this was allowed for the slow computers.

Anyhow, I went down there and keyed the crate, but auxey isn't coming back.  I'll give it a few more minutes and check again, but then I might go and power cycle it again.  If that doesn't work, we may have a much bigger problem.

  9394   Fri Nov 15 12:00:28 2013 KojiUpdateCDSCan't talk to AUXEY?

Quote:

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 Don't forget to run burtrestore for the target.

  9393   Fri Nov 15 10:49:55 2013 jamieUpdateCDSCan't talk to AUXEY?

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

  9392   Fri Nov 15 10:31:45 2013 SteveUpdateISSSR560 ISS loop connection

Quote:

Quote:

We have implemented an SR560-based ISS loop using the AOM on the PSL table. This is a continuation of the work in 40m:9328.

We dumped the diffracted beam from the AOM onto a stack of razor blades. This beam is not terribly well separated from the main beam, so the razor blades are at a very severe angle. Any alternatives would have involved either moving the AOM or attempting to dump the diffracted beam somewhere on the PMC refl path. We trimmed the RF power potentiometer on the driver so that with 0.5 V dc applied to the AM input, about 10% of the power is diverted from the main beam.

We ran the PMC trans PD into an AC-coupled SR560. To shape the loop, we set SR560 to have a single-pole low- pass at 300 Hz and an overall gain of 5×104. We take the 600 Ω output and send it into a 50 Ω feed-through terminator; this attenuates the voltage by a factor of 10 or so and thereby ensures that the AOM driver is not overdriven.

The AOM driver's AM input accepts 0 to 1 V, so we add an offset to bias the control signal. The output of the 50 Ω feedthrough is sent into the 'A' input of a second SR560 (DC coupled, A − B setting, gain 1, no filtering). Using a DS345 function generator, a 500 mV offset is put into the 'B' input (the function generator reads −0.250 V because it expects 50 Ω input). The 50 Ω output of this SR560 is sent into the AOM driver's AM input.

A measurement of suppressed and unsuppressed RIN is attached. We have achieved a loop with a bandwidth of a few kilohertz and with an in-loop noise suppression factor of 50 from 100 Hz to 1 kHz. This measurement was done using the PMC trans PD, so this spectrum may underestimate the true RIN.

 A small followup measurement. Here are spectra of the MC trans diode with and without the ISS on. The DC value of the diode (in counts) changed from 17264.2 (no ISS) to 17504.3 (with ISS), but I didn't account for this change in the plot.

There is a small inkling of benefit between 100Hz and 1kHz. Above about 100Hz, the RIN is suppressed to about the noise level of this measurement. Below 100Hz there is no change, which probably means that power fluctuations are introduced downstream of the AOM, which argues for an outer-loop ISS down the road.

Atm #2 is in units of RIN.

 I have disconnected the cable from the SR560 to LSC -ch8 for 15minutes this morning. It is moved from the floor to the top of the chambers as preparation for 40m tour. The SR560 seems to be overloading.

The  ISS servo is off according to the MEDM screen. Why MC-T plot showing zero?  The MC was happy yesterday.

 

Attachment 1: ISS.png
ISS.png
  9391   Fri Nov 15 10:19:26 2013 manasaUpdateCDSCan't talk to AUXEY?

Quote:

 

 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.
 

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.

 

This is what was done (as I recollect) when we said "inspected":Tenet into the computer, ping them and look at the status. Since c1auxey is not responding, here is how c1auxex responds.

controls@rossa:/cvs/cds/caltech/target 0$ telnet c1auxex
Trying 192.168.113.59...
Connected to c1auxex.martian.
Escape character is '^]'.

c1auxex > h
  1  i
  2  -help
  3  --help
  4  h
  5  2
  6  h
  7  -help
  8  i
  9  h
value = 0 = 0x0
c1auxex > i

  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
tExcTask   _excTask       fde244   0 PEND          87094   fde1ac   3006b     0
tLogTask   _logTask       fdb944   0 PEND          87094   fdb8a8       0     0
tShell     _shell         ddad00   1 READY         6d974   dda9c8  3d0001     0
tRlogind   _rlogind       fbc11c   2 PEND          2b604   fbbdf4       0     0
tTelnetd   _telnetd       fba278   2 PEND          2b604   fba1a8       0     0
tTelnetOutT_telnetOutTa   db7578   2 READY         2b604   db72e0       0     0
tTelnetInTa_telnetInTas   db6060   2 READY         2b5dc   db5d68       0     0
callback   _callbackTas   f7941c  40 PEND          2b604   f793d4       0     0
scanEvent  ee7ca8         ecacb4  41 PEND          2b604   ecac6c       0     0
tNetTask   _netTask       fd75b8  50 READY         6be6c   fd7550       0     0
scanPeriod ee78f8         ecd554  53 READY         6d192   ecd508       0     0
scanPeriod ee78f8         f23e48  54 DELAY         6d192   f23dfc       0     6
tFtpdTask  _ftpdTask      fb7848  55 PEND          2b604   fb778c       0     0
scanPeriod ee78f8         f266e8  55 READY         6d192   f2669c       0     0
scanPeriod ee78f8         f38678  56 READY         6d192   f3862c       0     0
callback   _callbackTas   f7bcbc  57 PEND          2b604   f7bc74       0     0
scanPeriod ee78f8         f906d8  57 DELAY         6d192   f9068c       0    59
scanPeriod ee78f8         f995ac  58 DELAY         6d192   f99560       0   238
scanPeriod ee78f8         f9c908  59 DELAY         6d192   f9c8bc       0   538
callback   _callbackTas   fa4c1c  65 PEND          2b604   fa4bd4       0     0
scanOnce   ee7764         f9f96c  65 PEND          2b604   f9f92c       0     0
epicsPrint f0501c         e88fa0  70 PEND          2b604   e88f64   c0002     0
ts_Casync  ee5bae         f76b7c  70 DELAY         6d192   f76880  3d0004   178
tPortmapd  _portmapd      fb8d60 100 PEND          2b604   fb8c2c      16     0
EgRam      ea00e4         fa14ac 100 PEND          2b604   fa1458       0     0
CA client  _camsgtask     d85878 180 PEND          2b604   d85774  3d0004     0
CA client  _camsgtask     df91e8 180 PEND          2b604   df90e4       0     0
CA client  _camsgtask     d98bf4 180 PEND          2b604   d98af0       0     0
CA client  _camsgtask     e03cd0 180 PEND          2b604   e03bcc       0     0
CA client  _camsgtask     ddf2b8 180 PEND          2b604   ddf1b4       0     0
CA client  _camsgtask     faaec8 180 PEND          2b604   faadc4       0     0
CA client  _camsgtask     d79f3c 180 PEND          2b604   d79e38       0     0
CA TCP     _req_server    f305dc 181 PEND          2b604   f30540       0     0
CA repeaterf109e2         f215a8 181 PEND          2b604   f21474       0     0
CA event   _event_task    d7fe58 181 PEND          2b604   d7fe10       0     0
CA event   _event_task    d6ce5c 181 PEND          2b604   d6ce14       0     0
CA event   _event_task    dab7e0 181 PEND          2b604   dab798       0     0
CA event   _event_task    d76efc 181 PEND          2b604   d76eb4       0     0
CA event   _event_task    d9bddc 181 PEND          2b604   d9bd94       0     0
CA event   _event_task    d9a864 181 PEND          2b604   d9a81c       0     0
CA event   _event_task    da8d8c 181 PEND          2b604   da8d44       0     0
CA UDP     _cast_server   f2f064 182 READY        efcabe   f2efe4       0     0
CA online  _rsrv_online   f2d84c 183 DELAY         6d192   f2d7bc       0   265
EV save_res_event_task    de88dc 189 PEND          2b604   de8894   3006b     0
save_restor_save_restor   df61cc 190 PEND          2b604   df5c44  3d0002     0
RD save_res_cac_recv_ta   fb47d8 191 READY         2b604   fb46a4  3d0004     0
logRestart f05d42         e861c0 200 PEND+T        2b604   e86174      33  1714
taskwd     ef4d46         e85030 200 DELAY         6d192   e84f7c       0   224
value = 0 = 0x0
c1auxex >
telnet> quit
Connection closed.
controls@rossa:/cvs/cds/caltech/target 0$

  9390   Fri Nov 15 09:27:58 2013 KojiUpdateIOOWFS with beam dumps

Unfortunately this does not work. These WFSs are not the detectors which we can move freely.
In order to move the WFS detectors, we need the precise design of the Gouy phase for each WFS heads.
Without the design, we can't move the detectors.

  9389   Fri Nov 15 09:24:41 2013 SteveUpdateIOOWFS with beam dumps

This is a proposal to move WFSs such way that their reflected beam can be trapped.

Later ps: Nic will take care of the Gouy phase telescopes.

Attachment 1: MCwfsRefTraped.jpg
MCwfsRefTraped.jpg
  9388   Fri Nov 15 08:01:20 2013 SteveUpdateSUSETMY damping restored

ETMY sus damping restored

Attachment 1: ETMYsus.png
ETMYsus.png
  9387   Thu Nov 14 22:23:22 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.
 

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.


controls@rossa:~ 0$ telnet c1auxey
Trying 192.168.113.60...
Connected to c1auxey.martian.
Escape character is '^]'.
Connection closed by foreign host.
controls@rossa:~ 1$ telnet c1auxex
Trying 192.168.113.59...
Connected to c1auxex.martian.
Escape character is '^]'.

c1auxex >
telnet> ^]
?Invalid command
telnet> exit
?Invalid command
telnet> quit
Connection closed.
controls@rossa:~ 0$ telnet c1auxey
Trying 192.168.113.60...
Connected to c1auxey.martian.
Escape character is '^]'.
Connection closed by foreign host.
  9386   Thu Nov 14 14:35:12 2013 SteveUpdateSUSIR effect on MC and PRM sensors

 Sorry to say but MC1, MC2, MC3 and PRM face OSEMS are having the same problem of leaking IR into the sensors

The PMC was not locked for 11 minutes on this plot.

 

Attachment 1: MC_PRM_IReffect.png
MC_PRM_IReffect.png
  9385   Thu Nov 14 14:27:51 2013 nicolasOmnistructureGeneralSR785 Analyzer CRT replaced

 The 785 analyzer in the 40 had a wonky hard to read screen. I was hoping that a new white CRT would fix all the problems. 

I installed a white CRT, which didn't fix the wonkyness, but I adjusted the CRT position, brightness, focus settings to make the screen somewhat more readable.

BEFORE:

IMG_20131114_125728.jpg

AFTER:

IMG_20131114_141425.jpg

If we want to send the thing in for service to fix the wonkyness, we should probably hold on to the old CRT because they will probably replace the whole screen assembly and we'll lose our white screen.

  9384   Thu Nov 14 11:41:19 2013 SteveUpdateSUSPRM sensors effected by IR

 IR off for 11 minutes. The PRM  face sensors are effected. The PRM side and the rest of the SUS OSEMS are not effected.

 

Attachment 1: IRon_off.png
IRon_off.png
  9383   Thu Nov 14 02:55:26 2013 ranaUpdateSUSPRM motion correlated to intracavity power

 

Some more words about the ISS -> OSEM measurement:

The calibration of the OSEMs have been done so that these channels are each in units of microns. The SIDE channel has the lower noise floor because Valera increased the analog gain by 5x some time ago and compensated with lower digital gain.

The peak heights in the plot are:

UL   0.85

LL   0.78

UR   0.61

LR   0.45

S    0.27

So that tells us that the coupling is not uniform, but mostly coming in from the left side (which side is the the SIDE OSEM on?).

Jenne and I discussed what to do to mitigate this in the loops. Before we vent to fix the scattering (by putting some covers around the OSEMs perhaps), we want to try to tailor the OSEM damping loops to reduce their strength and increase the strength of the OL loops at the frequencies where we saw the bulk of the instability last time.

Jenne is optimizing OL loops now, and I'm working on OSEM tweaking. My aim is to lower the overall loop gains by ~3-5x and compensate that by putting in some low Q, resonant gain at the pendulum modes as we did for eLIGO. We did it here at the 40m several years ago, but had some troubles due to some resulting instability in the MC WFS loops.

 

In parallel, Steve is brainstorming some OSEM shields and I am asking around LIGO for some AC OSEM Satellite modules.

  9382   Thu Nov 14 02:50:43 2013 JenneUpdateLSCPRM oplev measured and modeled TF

In the process of figuring out what we can do to fix our PRM motion problem, I am looking at the PRM oplev. 

Eventually (as in, tomorrow), I'd like to be able to simulate some optic motion as a result of an impulse, and see what the oplev loops do to that motion.  (For starters, I'll take the impulse response of the OSEM loop as my time series that the oplev loop sees).

One thing that I have done is look at the oplev model that Rana put together, which is now in the noisebudget svn: /ligo/svncommon/NbSVN/aligonoisebudget/trunk/OpLev/C1

This script plots the open loop gain of the modeled oplev:

PRM_OL_TF_model.png

This should be compared to the pitch and yaw measured transfer functions:

 PRM_OLPIT_TF.pdf

PRM_OLYAW_TF.pdf

In the YAW plot, there are 2 transfer functions.  The first time around, the UGF was ~2.5Hz, which is too low, so I increased the gain in the C1:SUS-PRM_OLYAW filter bank from -3 to -9. 

The shapes of the measured and modeled transfer functions look reasonably similar, but I haven't done a plot overlay.  I suspect that the reason I don't see the same height peak as in the model is just that I'm not taking a huge number of points.  However, if the other parts of the TF line up, I'll assume that that's okay.

I want to make sure that the modeled transfer function matches the measured ones, so that I know I can trust the model.  Then, I'll figure out how to use the time series data with the simulated loop.  Ideally, I'd like to see that the oplev loop can fully squish the motion from the OSEM kicks.  Once I get something that looks good (by hand-tweaking the filter shape), I'll give it a try in the actual system.  We should, as soon as I get the optimal stuff working, redo this in a more optimal way.  Both now, and after I get an optimal design, I'll look at the actual step and impulse responses of the loop, to make sure there aren't any hidden instabilities.

Other thoughts for the night:

Rana suggests increasing the gain in some of the oplev QPD heads (including PRM), so that we're getting more than a few hundred counts of power on each quadrant.  Since our ADCs go to 32,000 counts, a few hundred is very small, and keeping us close to our noise limits.

Also, just an observation, but when I watch the REFL camera along with POP and AS, it's clear that the PRM is getting kicked, and I don't have the ETMs aligned right now, so this is just PRMI flashes.  There is also a lot of glow in the BS chamber during flashes (as seen on the PRM face video camera).

  9381   Thu Nov 14 00:33:37 2013 ranaConfigurationPSLPMC LO is dying...

Back in 2009, Jenne replaced the PMC board mixer with a Level 13 one. Today I noticed that the LO level on the PMC screen was showing a LO level of ~5-10 dBm and fluctuating a lot. I think that it is related to the well known failure of the Mini-Circuits ERA-5SM amplifier which is on the D000419-A schematic (PMC Frequency Reference Card). The Hanford one was dying for 12 years and we found it in late 2008. If we don't have any in the blue bin, we should ask Steve to order 10 of them.

The attached trend shows 2000 days of hour trend of the PMC LODET channel. The big break in 2009 is when Jenne changed the mixer and then attenuated the input by 3 dB. The slow decay since then is the dying amplifier I guess.

Since the LOCALC channel was not in the trend, I added it to the C0EDCU file tonight and restarted the FB DAQD process. Its now in the dataviewer list.

I went out and took out the 3 dB attenuator between the LO card and the PMC Mixer. The LO monitor now reads 14.9 dBm (??!!). The SRA-3MH mixer data sheet claims that the mixer works fine with an LO between 10 and 16 dBm, so I'll leave it as is. After we get the ERA-5, lets fix the LODET monitor by upping its gain and recalibrating the channel.

Attachment 1: Untitled.png
Untitled.png
  9380   Wed Nov 13 20:02:12 2013 Nic, EvanUpdateISSSR560 ISS loop

Quote:

We have implemented an SR560-based ISS loop using the AOM on the PSL table. This is a continuation of the work in 40m:9328.

We dumped the diffracted beam from the AOM onto a stack of razor blades. This beam is not terribly well separated from the main beam, so the razor blades are at a very severe angle. Any alternatives would have involved either moving the AOM or attempting to dump the diffracted beam somewhere on the PMC refl path. We trimmed the RF power potentiometer on the driver so that with 0.5 V dc applied to the AM input, about 10% of the power is diverted from the main beam.

We ran the PMC trans PD into an AC-coupled SR560. To shape the loop, we set SR560 to have a single-pole low- pass at 300 Hz and an overall gain of 5×104. We take the 600 Ω output and send it into a 50 Ω feed-through terminator; this attenuates the voltage by a factor of 10 or so and thereby ensures that the AOM driver is not overdriven.

The AOM driver's AM input accepts 0 to 1 V, so we add an offset to bias the control signal. The output of the 50 Ω feedthrough is sent into the 'A' input of a second SR560 (DC coupled, A − B setting, gain 1, no filtering). Using a DS345 function generator, a 500 mV offset is put into the 'B' input (the function generator reads −0.250 V because it expects 50 Ω input). The 50 Ω output of this SR560 is sent into the AOM driver's AM input.

A measurement of suppressed and unsuppressed RIN is attached. We have achieved a loop with a bandwidth of a few kilohertz and with an in-loop noise suppression factor of 50 from 100 Hz to 1 kHz. This measurement was done using the PMC trans PD, so this spectrum may underestimate the true RIN.

 A small followup measurement. Here are spectra of the MC trans diode with and without the ISS on. The DC value of the diode (in counts) changed from 17264.2 (no ISS) to 17504.3 (with ISS), but I didn't account for this change in the plot.

There is a small inkling of benefit between 100Hz and 1kHz. Above about 100Hz, the RIN is suppressed to about the noise level of this measurement. Below 100Hz there is no change, which probably means that power fluctuations are introduced downstream of the AOM, which argues for an outer-loop ISS down the road.

Atm #2 is in units of RIN.

Attachment 1: ISS_560_rot.pdf
ISS_560_rot.pdf
Attachment 2: ISS_560cal.pdf
ISS_560cal.pdf
  9379   Wed Nov 13 19:41:55 2013 JenneUpdateISSISS AOM

AOM driving from DAC:

I found that the DAC channels for TT3 and TT4 are connected up in the simulink model, but we aren't using them, since we don't actually have those tip tilts installed.  So, we hooked up the TT4 LR DAC output, which is channel 8 on the 2nd set of SMA outputs.  We put our AOM excitations into TT4_LR_EXC.

 

ELOG V3.1.3-