40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 149 of 336  Not logged in ELOG logo
ID Date Author Type Category Subject
  9452   Tue Dec 10 10:07:01 2013 SteveUpdateIOOmore beam traps

 New razor beam dump installed to trap reflected beam of the input vacuum window.

 

Attachment 1: InputWindowRefDump.jpg
InputWindowRefDump.jpg
Attachment 2: InpWindowRefDupm.jpg
InpWindowRefDupm.jpg
  9451   Mon Dec 9 11:44:08 2013 SteveUpdateendtable upgradeETMY optable got new beam dump

Aluminum shield replaced by razor beam dump.

Attachment 1: ETMYoptBefore.jpg
ETMYoptBefore.jpg
Attachment 2: ETMYoptAfter.jpg
ETMYoptAfter.jpg
  9450   Sat Dec 7 19:29:14 2013 KojiUpdateCDSMEDM/ADL: replace rectangle with specified objects

In order to unify the theme for MEDM screens, I'll have to make many combinations of rectangles, polygons, and invisible related-screen buttons.
Everytime I change the size of the block, I have to modify the size of this combination. It is impossile for me.

So, I made a script to replace a certain type of rectangles with a combination of the objects with the same (or related) size.

The script is here (so far)

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

So far, there is only "TYPE1" for the predefinition. It actually takes another argument to specify the
path of the related screen to open when the block is clicked. The path should be filled in "Channel B"
slot of the original rectangle. (See Attachment 1)

The "TYPE1" style has the function calls as indicated below. place_rect is to place a rectangle object. You can
specify the filling method and color. place_rel_disp is to place an invisible button with the link to the specified
path by strOpt. place_polygon places a polygon. The cordinate array for the polygon is described with
the relative positions from the specified position.

        place_rect(rect_x-4,         rect_y-4,        rect_w+7, rect_h+7, "outline",  0) # outline white box
        place_rel_disp(rect_x, rect_y, rect_w, rect_h, strOpt, 0, 14)                    # invisible button
        place_rect(rect_x,           rect_y,          rect_w,   rect_h,   "fill",     3) # main gray box
        place_rect(rect_x+3,         rect_y,          rect_w-6, 3,        "fill",     0) # top white rim
        place_rect(rect_x,           rect_y,          3,        rect_h-3, "fill",     0) # left white rim
        place_rect(rect_x+rect_w-3 , rect_y,          3,        rect_h,   "fill",    10) # right gray rim
        place_rect(rect_x,           rect_y+rect_h-3, rect_w-3, 3,        "fill",    10) # bottom gray rim
        place_polygon(rect_x+rect_w-3,rect_y,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # top-right white triangle
        place_polygon(rect_x,rect_y+rect_h-3,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # bottom-left white triangle

Attachment 1: rectangle_config.png
rectangle_config.png
Attachment 2: rect_replace_result.png
rect_replace_result.png
  9449   Fri Dec 6 21:38:27 2013 KojiUpdateLSCCDS related activities for LSC

I worked on the CDS related stuffs for LSC yesterday and today.


1. Slow machines:

I checked the database files for c1iscaux and c1iscaux2 (slow machines). They are mainly
used for the control of LSC whitening filters. The channel names were totally random as we
reconfigured the RF PDs while the channel names had been unchanged.

- Now the database was modified so that the PD name and the channels are related.
- saverestore.req and autoBurt.req were also changed accordingly.

- PD interface channels are completely random. Don't use them.
- I found the whitening of DCPDs are not effective.

- We need to clean up /cvs/cds/caltech/target directory. The autoBurt requests in the old targets
are making unnecessary burt files.

2. LSC screens

- The channel names on the LSC OVERVIEW screen was modified. (Attachment 1)
- A new LSC Whitening screen was made. (Attachment 2)

3. LSC screen generator

To touch the main LSC screen is very tough. The screen was split in to several sub screens
and combined with a command.

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/generateLSCscreen.py

This command combines the multiple adl files into a single file with x&y offsets.
This way, you can work with the each section of the screen.
Also, moving the blocks are just easy.

4. LSC Code Bug?

During the screen making, I found that a couple of the whitening switches are not
working properly.
e.g. When AS165 (either I or Q) FM1 is activated throught the whitening trigger,
the MSB bit (bit15) of the binary I/O (C1:LSC-BIO_0_0) does not .

SImilarly ASDC FM1 does not toggle bit15 of C1:LSC-BIO_0_1.

The other channels seems OK.

At first, I thought this is a bug of "Bit2Word" block. But an individual test of the block showed that
the block is not guilty. So why is only Bit15 malfunctioning???

 

Attachment 1: LSC1.png
LSC1.png
Attachment 2: LSC2.png
LSC2.png
  9448   Fri Dec 6 15:57:41 2013 SteveUpdateIOObeam dumps for PSL pointing monitoring

Quote:

Since the pointing has gone bad again, I went to the PSL to investigate. Found some bad things and removed them:

1) There was a stopped down iris AGAIN in the main beam path, after the newly installed mirror mount. I opened it. Stop closing irises in the beam path.

2) The beam dump for the IOO QPD reflection was just some black aluminum. That is not a real dump. I removed it. We need two razor blade dumps for this.

3) There was an ND filter wheel (???) after one of the PMC steering mirrors. This is not good noise / optics practice. I removed it and dumped the beam in a real dump. No elog about this ?!#?

 

The attached trend shows the last 20 days. The big step ~2 weeks ago is when Steve replaced the steering mirror mount with the steel one. I don't understand the drift that comes after that.

 

Today I also spent ~1 hour repairing the Aldabella laptop. Whoever moved it from the PSL area to the SP table seems to have corrupted the disk by improper shutdown. Please stop shutting the lid and disconnecting it from the AC power unless you want to be fixing it. Its now running in some recovery mode. Lets leave it where it is next to the PSL and MC1.

I steered the MC suspensions back to where they were on the trends before the PSL mirror mount swap and then aligned the PSL beam into it by touching the last 2 steel mounts. Once the alignment was good without WFS, I centered the beams on the IOO QPDs. If it behaves good overnight, I will center the unlocked beams on the MC WFS.

 

Please stay off the PSL for a couple days if you can so that we can watch the drift. This means no opening the doors, turning on the lights, or heavy work around there.

 IOO pointing monitoring qpds received razor beam dumps on their refs.

The Pos QPD was rotated and recentered.

The Ang QPD was left untouched.

TREND plot of 23 days is attached.

Attachment 1: IOO_QPD_MONS.jpg
IOO_QPD_MONS.jpg
Attachment 2: PointingTrend23d.png
PointingTrend23d.png
  9447   Fri Dec 6 12:45:51 2013 ericqUpdateGreen LockingGreen PDH Characterization

Yesterday, made a slew of measurements on the X-arm when locked on green. By tweaking the temperature loop offset and the green input PZT pointing, I was able to get the transmitted green to around 1.0. The PDH board gain was set to 4.0. I had trouble making swept sine measurements of the OLTF; changing the excitation amplitude for different frequency ranges would result in discontinuities in the measured TF, and there was only a pretty narrow band around the UGF that seemed to have reasonable coherence.

So, I used the SR785 as a broadband noise generator and measured the TF via dividing the spectra in regions of coherence. Specifically, I used the "pink noise" option of the SR785. I also used a SR560 as a low pass to get enough noise injected into the lower frequency range to be coherent, while not injecting so much into the higher frequencies that the mode hopped while measuring. 

The servo board TF was easily fitted to a 4th order zpk model via VFIT, but I'm having trouble fitting the OLTF. (There is a feature in the servo TF that I didn't fit. This is a feature that Zach saw [ELOG 9537], and attributed to op amp instability) Plots follow. Also, while these need to be calibrated to show the real noise spectrum of the cavity motion, I'm attaching the voltage noise spectra of the error and control signals as a check that electronics/PD noise isn't dominating either signal. 

LoopTF.pdfServoTF.pdf

MixerOutput.pdfServoOutput.pdf

  9446   Fri Dec 6 10:03:07 2013 SteveUpdateSUSIR effect on MC sensors only

Quote:

 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.

 

 The PRM sensors are no longer effected by IR. What changed? The MC still does.

Attachment 1: 10minPMCnotLocked.png
10minPMCnotLocked.png
Attachment 2: 6Dec2013.png
6Dec2013.png
  9445   Thu Dec 5 16:20:26 2013 SteveUpdateCDSglitches are gone

Quote:

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?

 Koji cleaned up very nicely.

Attachment 1: glitchesGONE.png
glitchesGONE.png
Attachment 2: NOglitches.png
NOglitches.png
  9444   Thu Dec 5 12:20:09 2013 JenneUpdateCDSfixing c1mcs timing - go for it

Quote:

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

 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?

  9443   Thu Dec 5 11:06:43 2013 SteveUpdateCameras viewport video ccd cameras are all covered

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

 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.

Attachment 1: PRMcamera.jpg
PRMcamera.jpg
Attachment 2: PRMcameraCover.jpg
PRMcameraCover.jpg
Attachment 3: FaradayCameraCover.jpg
FaradayCameraCover.jpg
  9442   Wed Dec 4 21:41:09 2013 ericqUpdateGreen LockingGreen PDH Characterization

 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.

  9441   Wed Dec 4 21:33:24 2013 KojiUpdateCDSc1scy time-over issue mitigated

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?

Attachment 1: TST.png
TST.png
Attachment 2: CDS.png
CDS.png
Attachment 3: no_glitch.png
no_glitch.png
  9440   Wed Dec 4 15:43:13 2013 JenneSummaryLSCPut LSC DAQ channels back

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.

  9439   Wed Dec 4 14:16:42 2013 JenneUpdateLSCPRFPMI flashes on transmission QPDs

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.

ArmsResonatingUsingALS_PRMIflashing_TRX_TRY.pdf

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

  9438   Wed Dec 4 13:37:34 2013 JenneUpdateCDSc1auxex down again

Quote:

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.

 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.

  9437   Wed Dec 4 12:02:39 2013 KojiUpdateCDSFB restored

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:

/dev/sdb1                            /            ext3    noatime                    0 1
/swapfile                            none         swap    sw                         0 0
shm                                  /dev/shm     tmpfs   nodev,nosuid,noexec        0 0
/dev/sda1                            /frames      ext3    noatime                    0 0
linux1:/home/cds/                    /cvs/cds     nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/rtcds               /opt/rtcds   nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/rtapps              /opt/rtapps  nfs     _netdev,auto,rw,bg,soft    0 0
linux1:/home/cds/caltech/apps/linux  /opt/apps    nfs     _netdev,auto,rw,bg,soft    0 0

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

* Broken runlevel entry: /etc/runlevels/boot/portmap
            bootmisc | boot                         
             checkfs | boot                         
           checkroot | boot                         
               clock | boot                         
         consolefont | boot                         
               dcron |      default                 
               dhcpd |      default                 
            hostname | boot                         
            in.tftpd | boot                         
             keymaps | boot                         
               local |      default nonetwork       
          localmount | boot                         
             modules | boot                         
               monit |      default                 
                  mx |      default                 
            net.eth0 |      default                 
              net.lo | boot                         
            netmount |      default                 
                 nfs | boot                         
            nfsmount | boot                         
          ntp-client | boot default                 
           rmnologin | boot                         
           rpc.statd | boot                         
                sshd | boot                         
           syslog-ng | boot                         
      udev-postmount |      default                 
             urandom | boot                         
              xinetd |      default

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!

  9436   Tue Dec 3 17:08:06 2013 KojiUpdateCDScomputer problems

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.

  9435   Tue Dec 3 07:42:23 2013 SteveUpdateCDSc1iscex timing problem mysteriously disappears??? (thanksgiving miracle???)

Quote:

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

  9434   Mon Dec 2 17:05:13 2013 JenneUpdateCDSc1iscex timing problem mysteriously disappears??? (thanksgiving miracle???)

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?

  9433   Mon Dec 2 16:04:47 2013 JamieUpdateCDSc1iscex timing problem mysteriously disappears??? (thanksgiving miracle???)

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.

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!):

festatus.png

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.

  9432   Mon Dec 2 14:24:10 2013 SteveUpdateCDScomputer problems

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

Attachment 1: c1iscex.png
c1iscex.png
Attachment 2: 1X6.JPG
1X6.JPG
  9431   Sat Nov 30 23:50:28 2013 ranaUpdateIOOmode cleaner not locking

Quote:

 I used our procedure from this entry to set the IMC board offset as well as the FSS board offset.

I found this afternoon that the MC was having trouble locking: the PC path was railing as soon as the boost was engaged. Could be that there's some misalignment on the PSL which has led to some RAM having to be canceled by this new offset. Let's see if its stable for awhile.

 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.

Attachment 1: mcdrift.png
mcdrift.png
  9430   Wed Nov 27 18:31:26 2013 KojiSummaryLSCAdittion of the ALS error signals to the LSC input matrix

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.

  9429   Wed Nov 27 16:29:21 2013 JenneUpdateCDSAccidentally turned off SUS IO chassis

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

  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.

ELOG V3.1.3-