Yes.  I think that's a good idea, since we're not using them at this time, and we want c1mcs to behave.  Maybe make an elog note of which version is the first without them, so that we can conveniently find the model(s) in the svn?

 PRM-BS & Faraday video ccd  cameras  covered as shown. These thin wall metalized ducts are perfect for blocking light in both direction.

They are very light and give you easy access to adjustment.

 My job right now is to characterize the green PDH loops on each arm. Today, Jenne took me around and pointed at the optics and electronics involved. She then showed me how to lock the green beams to the arms (i.e. opening the shutters until you hit a TM00 shape on the transmitted beam camera). Before lunch, the y arm was easiest to lock, and the transmitted power registered at around 0.75. 

After lunch, I took a laptop and SR785 down to the y end station. I unhooked the PDH electronics and took a TF of the servo (without its boost engaged, which is how it is currently running) and noise spectrum with the servo input terminated.

I then set up things a la ELOG 8817 to try and measure the OLTF. However, at this point, getting the beam to lock on a TM00 (or something that looked like it) was kind of tough. Also, the transmitted power was quite a bit less than earlier (~0.35ish), and some higher order modes were higher than that (~0.5). Then, when I would turn on the SR785 excitation, lock would be lost shortly into the measurement, and the data that was collected looked like nonsense. Later, Koji noted that intermittent model timeouts were moving the suspensions, thus breaking the lock. 

We then tried to lock the x arm green, to little success. Koji came to the conclusion that the green input pointing was not very good, as the TM00 would flash much less brightly than some of the much higher order modes. 

Tomorrow, I will measure the x arm OLTF, as it doesn't face the same timeout issue that is affecting the y arm.

c1scy had frequent time-over. This caused the glitches of the OSEM damping servos.

Today Eric Q was annoyed by the glitches while he worked on the green PDH inspection at the Y-end.

In order to mitigate this issue, low priority RFM channels are moved from c1scy to c1tst.
The moved channels (see Attachment 1) are supposed to be less susceptible to the additional delay.

This modification required the following models to be modified, recompiled, reinstalled, and restarted
in the listed order: c1als, c1sus, c1rfn, c1tst, c1scy

Now the models are are running. CDS status is all green.
The time consumption of c1scy is now ~30us (porevious ~60us) (see Attachment 2)

I am looking at the cavity lock of TEM00 and I have witnessed no glitch any more.
In fact, the OSEM signals have no glitch. (see Attachment 3)

We still have c1mcs having regularly time-over. Can I remove the WFS->OAF connections temporarily?

Last week, Koji cleaned up the LSC model to make it much more readable, while he was working on piping the ALS signals to the LSC model.  However, somehow the DAQ Channels block got deleted before the model was committed to the svn.  Since there were 2 months between svn checkins for c1lsc.mdl, it's possible that someone had the model open just to look at, and the block got deleted, and that's the version that Koji started with. 

Anyhow, thankfully we have the svn, so Koji and I found that the DAQ Channels block was (as expected) in the previously checked-in version of the LSC model.  I put a copy of the old model onto my desktop, opened it up, copied the DAQ Channels block, and then pasted it into the new cleaned-up version of the model.  (Jamie - is there a way to conveniently download a previous version through the web interface?)

I have checked it in, compiled and restarted the lsc model.  The _DQ channels are back now.

2 weeks ago I took some data, and remembered today at the 40m meeting that I hadn't posted it.  Bad grad student.

All I'm trying to show here is that we see flashes in the arms that are larger than the ~50 units that we see saturate the Thorlabs transmission PDs. For arm power values below ~50, the QPD sum and Thorlabs PDs give approximately the same values.  So, 1 unit on the Thorlabs PDs is equivalent to 1 unit on the QPD sum, and 50 units on the Thorlabs diode is equivalent to 50 units on the QPD sum.

The situation was arms held on resonance with ALS, and the PRMI was flashing.

Arm powers of ~140 imply a power recycling gain of ~7.

 When I came in this morning, in addition to the fb being unhappy [elog 9436] (which Koji later fixed [elog 9437] ), c1auxex was down / not talking to the world nicely. 

I tried telnet-ing, but was rejected, so EricQ and I went down to the Xend and pushed the reset button on the computer.  The computer came back up just fine, and I did a burt restore to 03:07 on Nov 30th.

Now FB is fixed: daqd and nds are running

When I rebooted FB, I noticed that any of the nfs file systems were not mounted.
I started tracking down the issues from here.

I googled the common issues of the nfs mounting during the boot sequence.
- It is good to give "_netdev" option to fstab to mount the system after the network connection is established.

- "auto" option specifies that the file system is mounted when mount -a is run

Resulting /etc/fstab is this:

But this didn't help mounting the nfs file systems at boot yet. I dug into google again and found a command "/sbin/rc-update".
"/sbin/rc-update show" shows what services are activated at boot. It did not include "nfsmount". So the following command
was executed

> sudo /sbin/rc-update add nfsmount boot

> /sbin/rc-update show

After rebooting, I confirmed that the nfs file systems are correctly mounted
and daqd and nds are automatically started.

This means that FB had never been configured to run correctly at boot. Shame on you!

It seems that the front fan unit was running at the full speed. The fan itself seems still OK.

I talked with Jamie and make a power cycling (i.e. shutdown gracefully, unplug the power supply cables (x4), plug them in again, and pushed the power button)

The warning signal went off and the fan is quiet. FOR NOW.

Now, daqd and ndsd is down.

FB cannot mount /opt/rtcds and /cvs/cds during its boot.

After mounting these manually, I tried to run /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab
but they don't keep running.

I'll be back to this issue tomorrow with Jamie's help.

 I was trying to repeat  elog 9007  I did only get to line 2 of the Solution by Koji when Ottavia shut down, where I was working. This was all what I did.

Steve was trying to do something to it this morning, but I'm not exactly clear on what it was.  Maybe that helped?  Steve, can you tell us what you were trying to do this morning?

I just got over here from Downs, where I managed to convince Todd to let me borrow one of their three remaining timing slave boards for c1iscex.  I walked down to the X end to replace the board only to discover that the link light on the existing timing board was back!  c1iscex was not responding, so I hard rebooted the machine, and everything came up rosy (all green!):

To repeat, I DID NOTHING.  The thing was working when I got here.  I have no idea when it came back, or how, but it's at least working for the moment.  I re-enabled the watchdog for ETMX SUS and it's now damped normally.

I'm going to hold on to the timing card for a couple of days, in case the failure comes back, but we'll need to return it to Downs soon, and probably think about getting some spare backups from Columbia.

Rack 1x6 is very noisy.

 SunFire X4600 computer: FB (directly below Megatron) has it's yellow warning light on. It must be loosing one of it's  fan bearings.

Jetstore's error message: IDE channel #2 reading error

 I felt in my bones that the MC was in trouble so I came by and noticed that it hadn't locked for a couple hours. The FSS SLOW was at -1.6V, but putting it back to zero didn't fix things. I adjusted the FSS error point offset to +1 and that took the FSS_FAST off of the +10 V rail. Relocked and seems OK.

We need to plan to make the M Evans mod to the FSS box to make the PC drive less angry.

Last 40 days of MC Alignment trends  show that the recent MC WFS tuning / offseting worked out OK. MC REFL seems low and flat.

The Phase tracker outputs (= ALS X/Y error signals) are now conveyed to the LSC model.

Their entry points at the LSC model are C1:LSC-ALSX_IN1 and C1:LSC-ALSY_IN1.
They are connected to the signal matrix (28th and 29th signals) via signal conditioning filters (C1:LSC-ALSX and C1:LSC-ALSY).

The main LSC screen has not been updated. The conventional ALS servos are still remains as they were.

This renovation required the recompilation of c1als, c1rfm, and c1lsc. Two PCIe-RFM bridge paths were added resulting in
increase of the c1rfm timing budget from 38 to 44.

[Jenne, Koji]

I was trying to lock the Yarm, and saw that I was not getting signals to go between the LSC and SCY models.  I had digital zeros for TRY, and when I overrode the trigger and tried to force signal to ETMY, I had digital zeros at the SUS-ETMY_LSC input. The corresponding filter bank in the rfm model was receiving signals, so the Dolphin connection between LSC and SUS was okay, it was just the RFM connection going to the end station that wasn't succeeding. 

Koji restarted the c1scy model, and then went inside the IFO room, and found that the SUS IO chassis power was off.  We must have accidentally turned it off while we were in there earlier.  Koji turned on the power, and also restarted the rfm model, and we now have real signals going back and forth. 

Yarm is locked, ASS worked nicely, etc, etc, so things seem normal again (with the Yarm....ETMX stuff is still out of order).

 [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.

 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.

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.

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()

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.

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

The short time plots are correct.

 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.

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

 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

[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.

[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.

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.

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.

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?

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. 

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.

 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.

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

 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

 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! 

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.

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.

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 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?

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.

 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.

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:

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.

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.

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.

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.

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.

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

 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.