40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 42 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  17280   Thu Nov 17 15:53:47 2022 JCConfigurationCamerasITMX Camera -- attempt at fix

The issue was the power supply.

Quote:

I found that an old BNC cable for ITMXF video existed so I first tried swapping both ends of the cable, one on the ITMX viewport and the other one in the video MUX input in the rear. This didn't fix the issue.

I searched around in the CCD cabinet by XARM and found an identical analog camera so I swapped it and got the same image ...

I then searched for a AC/DC supply cable, but couldn't find one.

 

  17283   Fri Nov 18 09:00:27 2022 JCUpdateVACPressure Gauge Information

I bought the spare Full-Range Pirani Gauge a while ago and realized that I never logged this. The Pirani Gauges we are using is described below.

QTY Product Description Serial No.
1 FRG702CF35 -702 FULL RANGE PIRANI/IMG GA.,2.75CF

LI2218F003

I purchased this gauge from Agilent through TechMart. The spare is located inside the Vac Equipment cabinet (The only brown cabinet.) along the X-Arm.

  17290   Mon Nov 21 09:13:31 2022 JCUpdatePSLPMC input beam aligned again, IMC

[JC, Paco]

I attempted to align PMC Beam from a transmission of 0.72. I failed to do so on my own, but Paco arrived and helped me out. Transmission has gone from from 0.72 to ~0.73.

  17292   Mon Nov 21 14:55:58 2022 JCConfigurationGeneralLED Instead of Incandescent Lights

Electrical came by today to see the lights. The issue may be the switches, but they will come by tomorrow to solve the issue. A couple light bulbs were noticed to be out, but they no longer have incandescent lights. . . only LED. I figured this would be preffered because of the reduction on noise. I would prefer to go ahead and ask to change all the incandescent bulbs to LED bulbs. Are there any objections to this?

  17297   Tue Nov 22 08:56:27 2022 JCUpdatePSLPMC input beam alignment

[Paco, Anchal, JC]

C1:PSL-PMC_PMCTRANSPD ~ 0.715 this morning, this was increased to ~0.730. There also seems to be an earthquake going on and the MC is flashing.

Attachment 1: Screenshot_from_2022-11-22_08-58-45.png
Screenshot_from_2022-11-22_08-58-45.png
  17307   Wed Nov 23 17:21:44 2022 JCUpdateVACInterlocks may have been tripped due to N2 pressure loss

[Paco, JC]

While changing out one of the N2 tanks today, one of the fitting stripped. This caused a major loss of pressure. I replaced one fitting then realized there was a second leak around the area of the gauge. Paco and I changed this and everything should be back up and running. Thhe interlocks may have been tripped  within the last 2 hours.

 

Attachment 1: Screen_Shot_2022-11-23_at_5.22.57_PM.png
Screen_Shot_2022-11-23_at_5.22.57_PM.png
Attachment 2: Screen_Shot_2022-11-23_at_5.23.09_PM.png
Screen_Shot_2022-11-23_at_5.23.09_PM.png
  17316   Mon Nov 28 11:21:25 2022 JCUpdatePSLPMC input beam alignment

C1:PSL-PMC_PMCTRANSPD was increased from 0.72 to 0.731

Attachment 1: Screenshot_from_2022-11-28_11-20-31.png
Screenshot_from_2022-11-28_11-20-31.png
  17321   Tue Nov 29 11:38:37 2022 JCHowToLSCLock Single Arm After MICH lock

I tried locking single arm this morning, but I was unable to because the triggers were set to lock strictly to MICH. Anchal explained this to me and helped me out. I figured this information would be useful and should be logged somewhere. In red, this is accessed through the IFO --> Configure. Choosing X Arm and Y Arm will change the triggers on the C1LSC page for the single arm locking (In the Black Box.) 

Attachment 1: Screen_Shot_2022-11-29_at_11.01.56_AM.png
Screen_Shot_2022-11-29_at_11.01.56_AM.png
  17323   Wed Nov 30 10:48:10 2022 JCConfigurationGeneralLED Instead of Incandescent Lights

All incondescent lightsbulbs have been switched over to LED.

Quote:

Electrical came by today to see the lights. The issue may be the switches, but they will come by tomorrow to solve the issue. A couple light bulbs were noticed to be out, but they no longer have incandescent lights. . . only LED. I figured this would be preffered because of the reduction on noise. I would prefer to go ahead and ask to change all the incandescent bulbs to LED bulbs. Are there any objections to this?

 

  4541   Mon Apr 18 21:09:45 2011 JamieConfigurationComputersnew control room machine: pianosa

I've just installed the new control room machine: "pianosa".   It is a replacement for the old sun machine "op440m" [0].

Hardware:

  • dual dual-core Intel Core i7-2600 CPU @ 3.40GH, hyperthreaded to provide 8 effective cores
  • 16G memory (4x 4G dimms)
  • nVidia GF108 GeForce GT 430

It's now running Ubuntu 10.04 LTS 64bit.  Unfortunately, the default 10.04 kernel is 2.6.32, which does not support pianosa's apparently very new network adapter, which is (from lspci):

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)

To get around this I temporarily added a PCI nic so that I could get on the network.  I then added the Ubuntu kernel team PPA archive and installed linux-image-2.6.38-2, which is new enough to have the needed network driver, but not completely bleeding edge:

sudo add-apt-repository ppa:kernel-ppa/ppa
sudo apt-get update
sudo apt-get install linux-image-2.6.38-2-generic linux-headers-2.6.38-2-generic

Once the built in nic was working I removed the temporary one.  Everything seems to be working fine now.

I have not yet done any configuration to integrate pianosa into the CDS network.  I'll do that tomorrow.

[0] op44m has been moved into the control room rack next to linux1, in headless mode.  If there is still a need to run scripts that only run on solaris, op440m can still be accessed via ssh as normal.  Hopefully we can fully decommission this machine soon.

[1] https://launchpad.net/~kernel-ppa/+archive/ppa

  4542   Mon Apr 18 21:14:53 2011 JamieConfigurationComputersnew control room machine: pianosa
Also, op440m's Sun monitor did not work well with pianosa, so I'm lending pianosa my HP monitor until we can get a suitable replacement.
  4564   Mon Apr 25 11:58:37 2011 JamieBureaucracyComputerswiki?

Quote:

40m wiki seems to have been down for quite a while now but I can't see any info in the elog about it.  Is there some ongoing problem?

 There was an email from Dave Barker about this.  They had to reorganize the DNS at LHO.  The URL that should be used is: http://blue.ligo-wa.caltech.edu:8000/40m

  4645   Thu May 5 16:11:22 2011 JamieUpdateLSCchans file for LSC

Quote:

Foton doesn't correctly display the LSC filter bank file : C1LSC.txt.

 This was because of a bug in the RCG for foton filter module naming when top names is being used.  Rebuilding the LSC front-end model with top_names (which was needed to get around another bug in the RCG) broke the filter file.  I manually fixed the file, so it should work now.

  4667   Mon May 9 16:12:49 2011 JamieConfigurationCDScanonicalize paths to core and userapps

I have updated the /opt/rtcds paths to reflect the new specification of the CDS aLIGO code release procedures document.


Path to RTS/opt/rtcds/caltech/c1/core/release

This is where the advLigoRTS front-end code generator is checked out.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This used to be at /opt/rtcds/caltech/c1/core/advLigoRTS


Path to userapps: /opt/rtcds/caltech/c1/userapps/release

This is where the cds_user_apps code is checked out.  cds_user_apps is where all of the front-end models, medm screen, scripts, etc. will live.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This was most recently at /opt/rtcds/cds_user_apps

 

  4668   Mon May 9 16:58:23 2011 JamieBureaucracyCDS!!!!REMEMBER TO COMMIT YOUR MODIFICATIONS!!!!

Whenever you modify any of the front-end code in /opt/rtds/caltech/c1/userapps, such as models, scripts or medm screens, REMEMBER TO COMMIT YOUR CHANGES, WITH A LOG MESSAGE!!!

cd /opt/rtcds/caltech/c1/userapps/trunk
svn commit path/to/modified/file

If you forget to commit things, they may be purged and you will loose your work.  ALWAYS COMMIT!

Things to note and watch out for:

  • When you commit, make sure you specify explicitly the path to the file that you are committing.  This repository is shared by all LIGO sites, including the sites (LHO and LLO) so you really want to make sure you're not committing anything that affects anything other than "c1" (ie. the 40m)
  • Only commit one file at a time, unless the changes to multiple files are tightly coupled.
  • Never commit without specifying the path to the file that you are committing.  Other people may be working on other files in the repository, and you don't want to commit their work with yours.
  • YOU MUST LEAVE A LOG MESSAGE.  Your log message should be specific to the file you have modified, and should be clear and verbose to explain exactly what you have done.
  • Use the "svn status" command to give you an overview of what is going on in the working directory.  This will tell you which files have been modified.  See "svn help status" for more information.

If you have questions ASK.  Don't force things.

  4669   Mon May 9 17:21:13 2011 JamieBureaucracyCDS!!!!REMEMBER TO COMMIT YOUR MODIFICATIONS!!!!

Also, remember to update the svn working copy before you begin doing any work, to make sure you're working on the most recent version:

cd /opt/rtcds/caltech/c1/userapps/trunk
svn update
  4730   Tue May 17 11:45:20 2011 JamieConfigurationCDSpurged non-c1 site files from rtcds checkout of cds_user_apps
I purged all of the working copy checkouts of site files for all sites that are not c1 from the rtcds cds_user_apps working directory (/opt/rtcds/caltech/c1/userapps/trunk). I first checked that there were no outstanding changes, and then did the following (in bash):
cd /opt/rtcds/caltech/c1/userapps
rm -rf trunk
svn update --depth=files trunk
svn update --depth=empty trunk/{CDS,ISI,ISC,PSL,SUS}
svn update trunk/{CDS,ISI,ISC,PSL,SUS}/{c1,common}
  4735   Tue May 17 22:50:00 2011 JamieConfigurationLSCNew digital lockin added to LSC model/screen

I added a lockin to the LSC model, and added it's corresponding control to the LSC screen.  Here's is what I added to the LSC model:

lsc-mdl-lockin.png

On the left are the froms from the normalized RF PD outputs. Those go into a matrix, whose single row goes into the lockin signal input. The clock output from the lockin goes into the LSC output matrix (last row).

Here is what I added to the LSC master screen:

lsc-screen-lockin.png

I also modified the lockin overview screen:

lsc-lockin-screen.png

I think this new screen looks a lot cleaner.  Maybe we could start using this one as a template for lockin screens.

  4764   Wed May 25 19:03:59 2011 JamieConfigurationCDSUpdate rtcds checkout of cds_user_apps with new top-level directory names.

The top-level subsystem subdirectories in the cds_user_apps source repository were renamed today to be all lower case.  This required checking out the new directory and updating all of the model links in /opt/rtcds/caltech/c1.  Here is how I updated the cds_user_apps working tree:

cd /opt/rtcds/caltech/c1/userapps
mv trunk{,.bak}
svn update --depth=files trunk
svn update --depth=empty trunk/{cds,isi,isc,psl,sus}

I then fixed the links in the /opt/rtcds/caltech/c1/core/release/src/epics/simLink directory:

for link in $(find . -maxdepth 1 -type l); do ln -sf $(readlink $link | tr [:upper:] [:lower:]) ; done

A couple of things had to be cleaned up:

  • /opt/rtcds/caltech/c1/userapps/trunk/cds/c1/models/c1uct.mdl was linked in, but that model doesn't seem to exist anymore, so I removed the link.
  • a couple of things were linked from /opt/rtcds/caltech/c1/userapps/trunk instead of /opt/rtcds/caltech/c1/userapps/release, so I fixed those links.
  • /opt/rtcds/caltech/c1/userapps/release/cds/test/models/llo/l1isctest.mdl was not checked out, so I checked it out and fixed the link (this model should really be named something different if it is of common use, or we plan on using it at the 40m).

 

  4765   Wed May 25 19:19:11 2011 JamieConfigurationCDS!!!CHECK IN YOUR MODELS!!!

!!!CHECK IN MODEL CHANGES!!!

Today I found three models that were modified, but not checked in to the SVN repository:

M       sus/c1/models/lib/sus_single.mdl
M       isc/c1/models/c1lsc.mdl
M       isc/c1/models/c1mcp.mdl

I checked in the c1lsc model, since I think it was just the change that Kiwamu made in http://nodus.ligo.caltech.edu:8080/40m/4749.  I left the others, since I have no idea what they are or who made them.

Please please please remember to commit your model changes to the SVN after you're done.  This is particularly important for important models, such as c1lsc.  If you don't check in your changes I can pretty much guarantee that at some point you will loose them.

 

  4766   Wed May 25 20:12:55 2011 JamieConfigurationLSCNew digital lockin added to LSC model/screen

Quote:

This is OK....but, the input matrix should come from the same place as the regular input matrix: i.e. it should be just another row like CARM, DARM, etc. rather than have its own screen.

 You're absolutely right.  That was a brain-fart oversight.  I fixed the model so that the input from the lockin comes from another output row in the RFPD input matrix.  I then fixed the C1LSC medm screen accordingly:

lsc-lockin-adl.png

This is obviously much simpler and more straight-forward.

A future improvement would be to modify the DCPD input matrix to be able to route those signals to the lockin as well.  This is actually currently possible since the DCPD input matrix is just a subset of the full input matrix, but it's not available via medm yet.

  4767   Thu May 26 17:10:21 2011 JamieConfigurationLSCNew digital lockin added to LSC model/screen

Quote:

A future improvement would be to modify the DCPD input matrix to be able to route those signals to the lockin as well.  This is actually currently possible since the DCPD input matrix is just a subset of the full input matrix, but it's not available via medm yet.

 I went ahead and added the lockin output to the DCPD input matrix.

 

  4773   Tue May 31 15:45:37 2011 JamieUpdateCDSc1iscey IOchassis powered off for some reason. repowered.

We found that both of the c1iscey models (c1x05 and c1scy) were unresponsive, and weren't coming back up even after reboot.  We then found that the c1iscey IOchassis was actually powered off.  Steve's accepts some sort of responsibility, since he was monkeying around down there for some reason.  After powerup and reboot, everything is running again.

  4780   Thu Jun 2 16:23:42 2011 JamieUpdateSUSSUS control models updated to use new sus_single_control library part

A new library part was made for the single suspension controller (it was originally made from the c1scx controller), using the following procedure:

  1. Opened c1scx model (userapps/trunk/sus/c1/models/c1scx)
  2. Cut ETMX subsystem block out of SUS subsystem
  3. Pasted ETMX block into new empty library, and renamed it C1_SUS_SINGLE_CONTROL
  4. Tweaked names of inputs, and generally cleaned up internals (cosmetically)
  5. Saved library to: userapps/trunk/sus/c1/models/lib/sus_single_control.mdl

Once the new sus_single_control library part was made and the library was committed to the cds_user_apps repo, I replaced all sus controller subsystems with this new part, in:

  • c1scx
  • c1scy
  • c1sus (x5 for each vertex mass)

All models were rebuild, installed, and tested, and everything seems to be working fine.

  4781   Thu Jun 2 16:31:41 2011 JamieUpdateCDSaquired SUS channel name suffixes changed from _DAQ to _DQ

CDS changed the suffix for all aquired channel names from _DAQ to _DQ.  When we rebuilt the sus models, described in the previous log, the channel names were changed and consequently the channel files were completely rewritten.

To fix the issue, the latest archived channel file was copied back into the chans directory, and the suffixes were changed, as so:

cd /opt/rtcds/caltech/c1/chans
cp archive/C1SUS_110602_155403.ini  C1SUS.ini
sed -i 's/DAQ/DQ/g' C1SUS.ini

We then restarted the models and the framebuilder.

  4793   Tue Jun 7 11:39:27 2011 JamieUpdateSUSNo binary output module in ETMY
Quote:

1) The FM1 files in the XXSEN modules should switch the analog shadow sensor whitening. I found today that, at least on ETMY and ETMX, they do nothing. This needs to be fixed before we can use the suspensions.

Joe discovered today that ETMY in fact has no binary output module at all, so there is actually no digital control of the whitening filters at ETMY.

We suspect that the ETMY binary output module was maybe harvested to put in the LSC rack, but we're not sure.

We found a spare binary output adapter pcb, which I will try to assemble into a module to install in ETMY.

This does not explain what's going on with ETMX, though.  ETMX has a binary output module, that appears to be properly hooked up.  I'll try to debug what's going on there as well.

In the mean time, I've removed the ETMX binary output module to use as a reference for putting together another identical module for ETMY.

  4815   Tue Jun 14 09:25:17 2011 JamieUpdateCDSDolphin fiber tested with c1sus, still bad

The bad Dolphin was still bad when tested with a connection between c1sus and the Dolphin swtich.

I'm headed over to Downs to see if we can resolve the issue with the PCIe extension fiber.

  4817   Tue Jun 14 16:38:31 2011 JamieUpdatePSLTweaked input pointing to PMC

The PMC trans power was a little low (0.77V or so).  I tweaked up the input pointing and now we're getting about 0.875V transmitted.

  4821   Wed Jun 15 01:30:38 2011 JamieSummaryLSCSchnupp asymmetry measurement

Measurement of Schnupp asymmetry

This was done by measuring the relative phase between the sidebands reflected from the two arms while the arm cavities are locked.

The Schnupp asymmetry is measured to be:   Lsa = 3.64 ± 0.32 cm

schnupp.png

Description:

As a phase reference we use the zero crossing of the response function for the out-of-phase control signal for the single arm cavity lock [0]. The difference in the RD rotation phase of the response zero crossings indicates the phase difference in the sideband signals reflected from the arms. Assuming the asymmetry is less than half the RF modulation wavelength [1], the asymmetry is given by the following formula:

       \Delta \phi   c   1 
L_sa = ----------- ----- -
           360     f_RSB 2

We use a LSC digital lock-in to measure the response of the arm cavity at a single-frequency drive of it's end mirror.

[0] The locations of the zero crossings in the out-of-phase components of the response can be determined to higher precision than the maxima of the in-phase components.

[1] fRSB = 55 MHz,     c/fRSB/2 = 2.725 m

Procedure:

  1. Lock/tune the Y arm only.
    • We use AS55_I to lock the arms.
  2. Engage the LSC lock-in.
  3. Tune the lock-in parameters:
  4. lock-in freq: 103.1313 Hz
    I/Q filters:  0.1 Hz low-pass
    phase:        0 degrees
    
  5. Set as input to the lock-in the out-of-phase quadrature from the control RFPD.  In this case AS55_Q->LOCKIN.
  6. Drive the arm cavity end mirror by setting the LOCKIN->Y_arm element in the control matrix.
  7. Note the "RD Rotation" phase between the demodulated signals from the control PD (AS55)
  8. For some reasonable distribution of phases around the nominal "RD Rotation" value, measure the amplitude of the lock-in I output.
    • Assuming the Q output is nearly zero, it can be neglected.  In this case the Q amplitude was more than a factor of 10 less than the I amplitude.
    • Here we take 5 measurements, each separated by one over the measurement bandwidth (as determined by the lock-in low pass filter), in this case 10 seconds.  The figure above plots the mean of these measurements, and the error bars indicate the standard deviation.

The data and python data-taking and plotting scripts are attached.

Error Analysis:

To to determine the parameters of the response (which we know to be linear) we use a weighted linear least-squares fit to the data:

y = b X

where:

X0j = 1
X1j = xj              # the measurement points
y = yi                 # the response
b = (b0, b1)     # line parameters

The weighting is given by the inverse of the measurement covariance matrix. Since we assume the measurements are independent, the matrix is diagonal and Wii = 1/\sigmai2 The
estimated parameter values are given by:

\beta  =  ( XT W X )-1 XT W y  =  ( X'T X' )-1 X'T y'

where X' = w X, y' = w y and wii = \sqrt{Wii}.

The X' and y' are calculated from the data and passed into the lstsq routine. The output is \beta.

The error on the parameters is described by the covariance matrix M\beta:

M\beta = ( XT W X)-1 = ( X'T X')-1

with correlation coefficients \rhoij = M\betaij / \sigmai / \sigmaj.

The x-axis crossing is then given by:

X(Y=0) = - \beta1 / \beta0

References:

Valera's LLO measurement
http://en.wikipedia.org/wiki/Weighted_least_squares
http://en.wikipedia.org/wiki/Linear_least_squares_(mathematics)#Weighted_linear_least_squares
http://en.wikipedia.org/wiki/Error_propagation

Attachment 2: arm_phase.py
#!/usr/bin/env python

import sys
import os
import subprocess
import time
import pickle
from numpy import *
import nds
import matplotlib
... 229 more lines ...
Attachment 3: plot.py
#!/usr/bin/env python

import pickle
from numpy import *
import matplotlib
#matplotlib.use('AGG')
from matplotlib.pyplot import *

##################################################

... 137 more lines ...
Attachment 4: schnupp_ETMX.pik
(dp0
S'I'
p1
(dp2
cnumpy.core.multiarray
scalar
p3
(cnumpy
dtype
p4
... 341 more lines ...
Attachment 5: schnupp_ETMY.pik
(dp0
S'I'
p1
(dp2
cnumpy.core.multiarray
scalar
p3
(cnumpy
dtype
p4
... 341 more lines ...
  4823   Wed Jun 15 12:16:37 2011 JamieUpdateLockingMICH noise budget?

Quote
If you tilt your head sideways, you will notice that in this plot (totally uncalibrated, as yet), the BLACK trace, which is my white-light measurement of the AS55 shot noise is above the AS55Q noise when the Michelson is locked (true only at low frequency).  You will also notice that the same appears to be true for the Whitening Filter + Antialiasing Filter + ADC noise (GRAY trace).  Since Black, Gray, Pink and Green should all have the same calibration factor (a constant), calibrating the plot will not change this.  Brown and Blue are the MICH_OUT (aka MICH_CTRL) for dark and bright fringes, respectively.

Hey, Jenne.  I think there are a couple of things.  First, you're missing a PD dark noise measurement, which would be useful to see.

But I think the main issue is that it sounds like all of your closed loop measurements are done with the in-loop PD.  This means that everything will be suppressed by the loop gain, which will make things look like they have a noise lower than the actual noise floor.

  4833   Fri Jun 17 17:02:15 2011 JamieUpdateSUSETMX/ETMY binary output modules (re)installed, not yet tested

I have installed a new binary output module in ETMY, where there was none previously.  It is installed, powered (with working LEDs), hooked up (to the binary output card and the cross connect), but it hasn't been fully tested yet.

I also re-installed the binary output module in ETMX, with newly modified power-indicator LEDs.

Both modules are fully installed, but they have not yet been fully tested to confirm that they are indeed switching the whitening and de-whitening filters.

  4837   Mon Jun 20 09:28:19 2011 JamieUpdateCDSShutting down low-voltage DC power in 1X1/1X2 racks

In order to install the BO module in 1X2, I need to shut down all DC power to the 1X1 and 1X2 racks.

  4838   Mon Jun 20 10:45:43 2011 JamieUpdateCDSPower restored to 1X1/1X2 racks. IOO binary output module installed.

All power has been restored to the 1X1 and 1X2 racks.  The modecleaner is locked again.

I have also hooked up the binary output module in 1X2, which was never actually powered.  This controls the whitening filters for MC WFS.  Still needs to be tested.

  4859   Wed Jun 22 18:50:45 2011 JamieSummaryGeneralJuly 2011 vent plan

Kiwamu and I have started to put together a vent plan on the 40m wiki:

http://blue.ligo-wa.caltech.edu:8000/40m/vent/201107

We will keep working on this (there's still a *lot* to fill in), but please help fill in the plan by adding questions, answers, procedures, preparations, etc.

 

  4869   Thu Jun 23 22:00:22 2011 JamieUpdateSUSburt snapshot

I recorded a burt snapshot of these settings: /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2011/Jun/23/21:40

  4902   Tue Jun 28 21:05:05 2011 JamieUpdateSUSSUS control model updated

I have updated the sus_single_control model, adjusting/cleaning up/simplifying the LSC/POS input signals, and routing new signals to the lockins. Notably one of POS inputs to the part ("lockin_in") was eliminated (see below).

The 6 inputs to the TO_COIL output matrix are now:

LSCPOS + OFFSET + ALT_POS_IN
ASCPIT + OFFSET + SUSPIT + OLPIT
ASCYAW +OFFSET + SUSYAW + OLYAW
SIDE
LOCKIN1
LOCKIN2

The ALT_POS input is used only by the ETMs for the green locking. Just outside of the sus_single_control library part in the ETM models are the green locking controls, consisting of the ETM?_ALS filter bank and the ETM?_GLOCKIN lockin, the outputs from which are summed and fed into the aforementioned ALT_POS input.

As for the SUS lockins (LOCKIN1 and LOCKIN2 in the library model), their input matrix now gets the direct inputs from the OSEMS (before filtering) and the outputs to the coils, after all filtering. These will aid in doing binary output switching tests.

All suspension models (c1sus, c1scx, c1scy) have been rebuild and restarted so that they reflect these changes.

  4903   Tue Jun 28 22:07:46 2011 JamieHowToSAFETYEurocrate extender card fried (ie. Jamie did a very bad thing)

IMPORTANT ELECTRONICS SAFETY LESSON TO FOLLOW

Yesterday, I fried the +15 V power supply rail on one of the Eurocrate extender cards while I was checking out the binary switching in the 1X5 rack.  I will describe what I did it in the hopes that everyone else will be less stupid than me.

I wanted to monitor the voltage across a resistor on the suspension OSEM whitening board.  Since I knew that both sides of the resistor would be at non-zero voltage (including possibly at the power-supply rail), I used a battery-operated scope with floating inputs, so that the scope would not try to pull the probe shield to ground.  That should be OK, although not recommended, as you'll see, because you must be very careful to make sure that the scopes inputs are indeed floating.

Let's call the original signal 'A'.  The trouble came when I then connected another signal (B), whose shield was connected to the ground on the whitening board, to the scope.  Apparently the grounds on the scope inputs are connected, or were in the configuration I was using.  When I connected the signal B, B's ground shorted A's shield to ground, which had been sitting at the +15V rail.  That short circuit then fried the +15V supply line on the extender card I was using (escaping magic smoke was detected).  Thankfully this only blew the extender card, and not the Eurocrate or the Eurocrate power supply or the whitening board or the scope etc, all of which would have been much worse.

The moral of the story is to be very careful when connecting power supply voltages to the shield or ground of a scope.  In short, don't do it.  I didn't ultimately need to, since I could have found other ways to measure the same signal.

 

  4904   Tue Jun 28 22:36:04 2011 JamieUpdateSUSChecking binary switching of SUS whitening filter

I have been checking the binary output switching for the SUS whitening filters. It appears that the whitening switching is working for (almost) all the vertex suspensions (BS, ITMX, ITMY, PRM, SRM), but not for the ETMs.

The table below lists the output from my switch-checking script (attached). The script uses the SUS digital lockin to drive one coil and measure the same coil's OSEM response, repeating for each coil/OSEM pair. I used a lockin drive frequency of about 10 Hz, at which the whitening filter should have 10 db of gain.

All but one of the vertex OSEMS show the proper response (~10db gain at 10Hz) when the whitening is switched on from the digital controls. ITMY UL appears to not be switching, which I fear is due to my electronics fail noted in my previous log post.  The ETMs are clearly not switching at all.

I will try to get the ETM switching working tomorrow, as well as try to asses what can be done about the ITMY UL switch.  After that I will work on confirming the coil drive dewhite switching.

lockin settings

freq: 10.123 Hz
amp: 10000
I/Q filters: 0.1 Hz LP, 4-pole butterworth

response

BS
ul : 3.31084503062 = 10.3987770676 db
ll : 3.34162124753 = 10.4791444741 db
sd : 3.43226254574 = 10.7116100229 db
lr : 3.28602651913 = 10.3334212798 db
ur : 3.29361593249 = 10.3534590969 db

ITMX
ul : 3.37499773336 = 10.5654697099 db
ll : 3.2760924572  = 10.3071229966 db
sd : 3.13374799272 =  9.9212813757 db
lr : 3.28133776018 = 10.3210187243 db
ur : 3.37250879937 = 10.5590618297 db

ITMY
ul : 0.99486434364 = -0.0447226830807 db
ll : 3.39420873724 = 10.6147709414 db
sd : 3.88698713176 = 11.7922620572 db
lr : 3.357123865   = 10.5193473069 db
ur : 3.37876008179 = 10.5751470918 db

PRM
ul : 3.26758918055 = 10.2845489876 db
ll : 3.32023820566 = 10.4233848529 db
sd : 3.25205538857 = 10.2431586766 db
lr : 3.24610681962 = 10.227256141  db
ur : 3.31311970305 = 10.4047425446 db

SRM
ul : 3.30506423619 = 10.3835980943 db
ll : 3.28152094133 = 10.3215036019 db
sd : 3.08566647696 =  9.7869796462 db
lr : 3.30298270419 = 10.378125991  db
ur : 3.3012249406  = 10.3735023505 db

ETMX
ul : 0.99903400106 = -0.00839461539757 db
ll : 0.99849991349 = -0.0130393683795 db
sd : 1.00314092883 =  0.0272390056874 db
lr : 1.00046493718 =  0.00403745453682 db
ur : 1.00265600785 =  0.0230392084558 db

ETMY
ul : 1.00223179107 =  0.0193634913327 db
ll : 0.96755532811 = -0.286483823189 db
sd : 1.00861855271 =  0.0745390477589 db
lr : 1.05718545676 =  0.483023602007 db
ur : 0.99777406174 = -0.0193558045143 db
Attachment 1: botest.py
#!/usr/bin/env python

import sys
import os
import subprocess
import time
import pickle
from numpy import *
import nds
import matplotlib
... 207 more lines ...
  4921   Thu Jun 30 11:36:54 2011 JamieUpdateSUSRe: ITMX whitening, ETMX left free swinging

Quote:

While closing up the whitening shop for the night, I noticed that the ITMX whitening state (Whitening "On") is opposite that of all other suspensions (they all have Whitening "Off").  I don't know which way is correct, but I assume they should all be the same.  Once all the whitening and BO testing is done, we should make sure that they're all the way we want them to be.

This was certainly my fault, probably left over from early debugging of my BO switch check script.  I've turned the ITMX whitening all off, to match the other suspensions.

Quote

Also, Koji and I are leaving ETMX free swinging.  That's the way we found it, presumably from Jamie's BO testing at the end station today.  We don't know what the optic's story is, so we're leaving it the way we found it.  Jamie (or whomever left it free swinging), can you please restore it when it is okay to do so?  Thanks!

Again, this was my fault.  Sorry.  I just accidentally left this off when I finished yesterday.  Much apologies.  I've turned the ETMX watchdog back on.

  4922   Thu Jun 30 11:40:21 2011 JamieUpdateIOORe: misc. MC work

Quote:

Jamie has started to revert the "ALTPOS" effect on the MC mirrors. So far, the screens and SLOW channels have been fixed, but the fast channels still say "ALTPOS" in the dataviewer instead of "MCL".

 The framebuilder just needed to be restarted to pull in the fixed channel names.  I restarted the framebuilder and now the channels (C1:SUS-MC2_MCL_*) are showing up properly.

  4929   Fri Jul 1 16:01:48 2011 JamieUpdateSUSETM binary whitening switching fixed

I have fixed the binary whitening switching for the ETMs (ETMX and ETMY).  See below for a description of what some of the issues were.

The ETMX whitening/no-whitening response (same measurements performed in my previous post on checking vertex sus whitening switching) looks as it should.  The ETMY response seems to indicate that the switching is happening, but the measurements are very noise.  I had to up the averaging significantly to get anything sensible.  There's something else going on with ETMY.  I'll follow up on that in another post.

response

ETMX
ul : 3.28258088774 = 10.3243087313 db
ll : 3.31203559803 = 10.4018999194 db
sd : 3.27932572306 = 10.3156911129 db
lr : 3.28189942386 = 10.3225053532 db
ur : 3.31351020008 = 10.4057662366 db

ETMY
ul : 2.9802607099  =  9.4850851468 db
ll : 1.46693103911 =  3.3281939600 db
sd : 2.19178266285 =  6.8159497462 db
lr : 2.2716636118  =  7.1268804285 db
ur : 3.42348315519 = 10.6893639064 db

End rack cable diagrams inconsistent with binary channel mapping

One of the big problems was that the most up-to-date end rack cable diagrams (that I can find) are inconsistent with the actual binary mapping. The diagram says that:

  • BO adapter chassis output A (ch 1-16)   --> CAB_1X4_26 --> cross-connect 1X4-B7 (carrying QPD whitening switching signals)
  • BO adapter chassis output B (ch 17-32) --> CAB_1X4_27 --> cross-connect 1X4-A6 (carrying OSEM whitening switching signals)

In fact, the binary outputs are switched, such that output A carries the OSEM signals, and output B carries the QPD whitening signals.

I SWITCHED THE CABLES AT THE BINARY OUTPUT ADAPTER CHASSIS so that:

  • BO adapter chassis output A (ch 1-16)   --> CAB_1X4_27 --> cross-connect 1X4-A6 (carrying OSEM whitening switching signals)
  • BO adapter chassis output B (ch 17-32) --> CAB_1X4_26 --> cross-connect 1X4-B7 (carrying QPD whitening switching signals)

The rest of the wiring remains the same.

I made the same transformation for ETMY as well.

  4930   Fri Jul 1 18:41:53 2011 JamieUpdateSUSCore optic sus damping controllers normalized

I found many of the core optic (ETMs, ITMs, BS, PRM, SRM) suspension DOF damping controllers (SUSPOS, SUSPIT, SUSYAW, SUSSIDE) to be in various states of disarray:

  • Many of the controllers did not have their "Cheby" and "BounceRoll" filters switched on.
  • Some of the controllers didn't even have the Cheby or BounceRoll filters at all, or had other different filters in their place.
  • ETMY was particularly screwy (I'll make a separate follow-up post about this)
  • A bunch of random other unused filters lying around.
  • oplev servos not on
  • etc.

I went around and tried to clean things up, by "normalizing" all of the DOF damping filter banks, ie. giving them all the same filters and clearing out unused filters, and then turning on all the appropriate filters in all core optic damping filter banks ("3:0.0", "Cheby", "BounceRoll").  I also went sure that all the outputs were properly on, and the oplev servos were on.

A couple of the optics had to have their gains adjusted to compensate for filter changes, but nothing too drastic.

Everything now looks good, and all optics are nicely damped.

I didn't touch the MC sus damping controllers, but they're in a similar state of disarray and could use a once-over as well.

 

  4931   Fri Jul 1 18:48:13 2011 JamieUpdateSUSETMY sus controller found to be in a bad state

I'm not sure what happened to ETMY SUS, but it was in a pretty bad state.  Bad burt restore, I would guess.

Most egregiously, the inputs to all of the coil output filters were switched off.  This is a bit insidious, since these inputs being off doesn't show up on the overview screen at all.  This explains why ETMY had not been damping for the last couple of day, and why my binary whitening switching measurements were nonsense.

I also found that ETMYs damping filter was a 30 Hz high pass, instead of the 3 Hz high pass in all the other suspension controllers.  Unfortunately a messed up burt restore can't explain that.

I normalized the ETMY controller to match all of the other controllers (ie. gave it a nice new 3 Hz high pass), adjusted gains accordingly, and now ETMY is behaving nicely.

  4932   Fri Jul 1 18:54:34 2011 JamieUpdateSUSETMY binary whitening switching confirmed to be fixed

After finally figuring out what was messed up with ETMY I was able to get good measurements of the binary whitening switching on ETMY to determine that it is in fact working now:

ETMY
ul : 3.2937569959  = 10.3538310999 db
ll : 3.28988426634 = 10.3436124066 db
sd : 3.34670033732 = 10.4923365497 db
lr : 3.08727050163 =  9.7914936665 db
ur : 3.27587751842 = 10.3065531117 db

  4941   Tue Jul 5 18:57:10 2011 JamieUpdateSUSMore normalization of all sus controllers

Based on Rana's comment I have gone through and moved all of the corner frequencies for the high pass filters in the SUS damping controllers to 30 Hz.  I did this for all optics (MC1, MC1, MC3, BS, ITMX, ITMY, PRM, SRM, ETMX, ETMY) all degrees of freedom (POS, PIT, YAW, SIDE).

Rana also suggested I turn off all of the BounceRoll filters until we get a chance to tune those individually for all the suspensions.

Finally, I normalized the MC SUSXXX filter banks to look just like all the other suspensions.

All damping filter banks for all degrees of freedom for all single suspensions should all be the same now (modulo the differences in the BounceRoll filters, which are now turned off).

  4944   Wed Jul 6 10:35:35 2011 JamieUpdateSUSRe : More normalization of all sus controllers

Quote:

We found the 30 Hz high pass filters had lower gain than what they used to be at low frequcnies.

So we increased the gain of the high pass filters called '30:0.0'  by a factor of 10 to have the same gain as before.

 

I'm not convinced that this is what you want to do, or at least I wouldn't do it this way.  The "k" in the zpk filter was set such that the filter had unity gain above the high-pass cut-off frequency.  For a 30 Hz high-pass the k needs to be a factor of 10 smaller than it would be for a 3 Hz high-pass to achieve this high frequency unity gain.

As it is now these HP filters have 20 dB of gain above 30 Hz.  If the open loop transfer function needs to more gain I would have done that by adjusting the overall DC gain of the filter bank, not by increasing the gain in this one filter.  Maybe you guys have been doing it differently, though.  Or maybe I'm just completely off base.

  4945   Wed Jul 6 11:45:20 2011 JamieUpdateSUSMore normalization of all sus controllers

Quote

I'm attaching a screenshot of some of the problems I see so far with MC3.

I tried to fix all of the problems that I could identify in this screen shot:

  • Fixed the TO_COIL output filter matrix screen to correctly point to the matrix element filter screens (all SUS)
  • Removed MCL sections from SUS_XXX_POSITION screens, except for MC2.  I also modified the _POSITION screens for the ETMs to refer to ALS instead of MCL.
  • Zeroed out all of the lockin gains in the TO_COIL matrices (MC SUS)
  • Made sure all whitening filter were ON (all SUS)
  • Made sure all cts2um calibration filters were on (all SUS)
  • Made sure all oplev servos were on (all SUS)
  4946   Wed Jul 6 15:32:32 2011 JamieUpdateSUSRe : More normalization of all sus controllers

So after talking to Kiwamu about it, I understand now that since the damping loops need all of this extra gain when the high-pass corner is moved up, it's more convenient to put that gain in the control filter itself, rather than having to crank the overall DC gain up to some inconveniently high value.

  4961   Tue Jul 12 10:18:05 2011 JamieUpdateCDSC1:DAQ-FB0_C1???_STATUS indicators red, restored after controller restarts

Yesterday I found the C1:DAQ-FB0_C1???_STATUS lights to be red for the SUS, MCS, SCX, and SCY controllers.  I know this has something to do with model communication with the framebuilder, but I unfortunately don't remember exactly what it is.  I decided to try restarting the affected models to see if that cleared up the problem.  It did.  After restarting c1scx, c1scy, c1sus, and c1mcs everything came back up green.

We need some better documentation about what all of these status indicators mean.

  4971   Fri Jul 15 08:48:36 2011 JamieSummarySUSPhotosensor Head Lessons

Nicole: I thought we had decided to use teflon as the insulator between the PCB (yellow) and the LED/PDs?  I don't think you should use another circuit board with copper on it.  The copper will short the LED/PD heads to the metal box, which might be problematic.

Otherwise the design looks pretty good.  I think the PDs have three leads each, yes?

ELOG V3.1.3-