40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 328 of 341  Not logged in ELOG logo
ID Date Author Typedown Category Subject
  3784   Tue Oct 26 10:50:08 2010 KojiConfigurationelogELOG 2.8.0 -> ELOG 2.7.5 -> ELOG 2.8.0

ELOG restarted with 2.8.0 again.

- moved elog-2.8.0/script dir to elog-2.8.0/script.orig

- copied elog-2.7.5/script to elog-2.8.0/script

- /cvs/cds/caltech/elog/start-elog.csh reconfigured to launch 2.8.0

- /cvs/cds/caltech/elog/elog is linked to ./elog-2.8.0

- logbooks on 25th and 26th were copied from 2.7.5 to 2.8.0.

 

  3790   Tue Oct 26 22:57:37 2010 JenneConfigurationComputersWhy doesn't DTT work?!?

DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu.  Basically, we can't measure any fast channels with DTT.  I keep getting the error: "Unable to select testpoints."  Sadface.

Similar things are true for DataViewer.  The same limited number of fast channels, and no data found:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Is this a framebuilder problem?  Is this something that the CDS team has on the to-do list?

  3793   Wed Oct 27 10:53:03 2010 josephbConfigurationComputersWhy doesn't DTT work?!?

Test points for the SUS channels should be there.  They have been working previously this week.  Possibly break down points include awgtpman, mx_streams, and the fb itself.  I'll look into that.

As far as other fast channels, there are no other fast front ends running than the suspensions ones we have.  Until additional channels get connected to the front ends and the models updated, those are the channels we have available.  However I am working on getting c1ioo up and running, and we can try connecting in some PEM channels today to the c1sus front end's 4th ADC.

 

Edit:

I tried starting a fresh instance of the frame builder, but when I brought the old copy down, it left a pair of zombie or dead mx_stream processes running on c1sus . Basically c1mcs and c1rms were still running, while c1x02 and c1sus came down.  I tried to kill the processes but this caused the c1sus machine to crash.  In the past I've killed left over mx_stream processes running after the frame builder has gone down, but I've never seen them crash the computer.  I'm unsure why this happened since we haven't done any updates of the code, just updated models and daq configuration files.

Quote:

DTT has only SUS and "X02" channels under C1 in the drop down channel selection menu.  Basically, we can't measure any fast channels with DTT.  I keep getting the error: "Unable to select testpoints."  Sadface.

Similar things are true for DataViewer.  The same limited number of fast channels, and no data found:

Server error 13: no data found
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Is this a framebuilder problem?  Is this something that the CDS team has on the to-do list?

 

  3835   Mon Nov 1 12:38:56 2010 Leo SingerConfigurationComputerspython-sqlite installed on Allegra

I installed the Python bindings for sqlite on Allegra using

$ sudo yum install python-sqlite python-sqlite2

  3843   Tue Nov 2 00:17:01 2010 SureshConfigurationLockingTemporary changes to the Video Mux

Fiber coupling 1064 nm light at the end of X arm

This is 'work in progress'.  The attempt is to bring a few milliwatts of the 1064 nm light from the NPRO at the end of the South(X) Arm to the PSL table through an single mode optical fiber.  This would enable us to tune the two NPRO's to be less than 15 MHz apart by looking at their beat frequency before doubling.  Because we have a 1GHz bandwidth PD at 1064 nm, while the photodiode for green has a BW of about 30MHz.

A PBS (P-type) cube has been introduced into the beam of the X arm NPRO  (between the lamda/2 plate and the input lens of the doubling crystal).  By rotating the face of the PBS slightly away from normal incidence, I have diverted away 1.5mW of the 1064 light for coupling into the fiber. The beam has shifted slightly because of this and the green beam from the south arm has to be realigned to reach the PSL table.

A single mode fiber (Thorlabs SM980-5.8-125),  which was already laid half way, has been extended all the way to the PSL table. It runs along the  South arm in the cable tray. 

A pair of mirrors have been arranged in a zig-zag to steer the beam into a fiber coupler.  There was some hope that this coupler had been aligned at some point in the past and that attaching a fiber might result in some transmission.  But this is not the case and fiber coupler needs to be readjusted.

In order to see the light transmitted through the fiber, a camera has been set up on the PSL table.  Its output has been routed into the 'Ref Cavity reflected' video signal.  A video cable running from the ETMX to the Video-MUX used to be connected to the input channel 9 of the Video MUX.  This has now been shifted to output channel 25 of the MUX and disconnected from the camera at the ETMX.   The 'Ref Cav Refl.' video signal has been routed to the output channel 25.  The camera looking at the fiber output can now be seen on a local monitor at the end of the X arm and on the video monitor in the control room.

With the fiber disconnected, the 1064 nm beam was steered into the fiber coupler and its transmission maximised by observing  with an IR viewer.  The fiber was then connected and then the transmission at the PSL table was sought.  There was no transmission seen after a searching around this region for a few mins.

The plan is to purchase a Visual fault locator which would enable us to quickly get a rough alignment of the fiber coupler. A local vendor is listed as a distributor for this product from JDSU.  Contact info:

DuVac Electronics (EDGE)
Tel: 626-796-3291
Email: jack@duvac.com
1759 E Colorado Blvd
Pasadena, CA 91106

 

  3848   Tue Nov 2 16:49:02 2010 JenneConfigurationCamerasCabling on the PSL table

Dear whomever setup the camera on the SW corner of the PSL table,

It would be handy if, even for temporary setups, all cables went underneath the white frame around the PSL table.  As it is now, the cables are in the way of the door.  The door is pretty much closed all the way, but if someone were to open other doors, the far door can easily be pushed all the way to the end of the track, thus squishing the cables.  Squished cables are bad cables.

Thanks!

  3873   Fri Nov 5 23:05:43 2010 ranaConfigurationIOOioo.db file changed in c1iool0 to get back MC TRANS

 

We like to have the MC TRANS channels so that we can run all of our old scripts and trends on it. This is the usual BROWN

channel that's on the LockMC screen. Its also the thing that we use for thresholding to activate the MC Autolocker Daemon.

I modified the ioo.db file in the target/c1iool0/ directory so that the MC_TRANS_SUM, _P, and _Y channels are all now just

CALC records of the MC2 OL channels (where the calculation is MC_TRANS_SUM = MC2 OL_SUM + 0.001, etc.). I then

rebooted c1iool0 a few times to get the syntax right. It SEEMS to be working now. I'm sure that this won't effect anything.
I've committed the new file to the SVN repo. Once Suresh is done hacking the QPD circuit, we can set the threshold in the Autolocker.

  3897   Thu Nov 11 15:27:43 2010 valera, steveConfiguration ISS AOM installed

 We installed the ISS AOM in the PSL. The AOM was placed right after the EOM. The beam diameter is ~600 um at the AOM. The AOM aperture is 3 mm.

We monitored the beam size by scanning the leakage beam through the turning mirror after the AOM. The beam diameter changed from 525 um to 515 um at a fixed point. We decided that the AOM thermal lensing is not large enough to require a  new scan of the mode going into the PMC and we can proceed with PMC mode matching using the scan that was taken without the AOM (to be posted).

  3907   Fri Nov 12 11:36:06 2010 AidanConfigurationComputersFixed the PERL PATH errors from the scripts directory change

 I've been trying to get a PID loop running for the green locking and I've discovered that some of the directories in the path for the Perl Modules are now obselete. Specifically, since the scripts directory has been moved from /cvs/cds/caltech/scripts to /cvs/cds/rtcds/caltech/c1/scripts the following locations in the Perl @INC path list need to be changed:

  • /cvs/cds/caltech/scripts/general
  • /cvs/cds/caltech/scripts/general/perlmodules

I've added the above directories to the PERL5LIB path in /cvs/cds/caltech/cshrc.40m.

 

 

setenv PERL5LIB /cvs/cds/caltech/scripts/general:

/cvs/cds/caltech/scripts/general/perlmodules:

/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:

/cvs/cds/rtcds/caltech/c1/scripts/general:

/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules

 This seems to fix the problem .. at least, you no longer get an error if you try nodus:~>perl -e 'user EpicsTools'

 

  3908   Fri Nov 12 12:06:11 2010 AidanConfigurationGreen LockingPID script working - now it needs to be tuned

 I've set up a PID script that senses the EX-PSL Green Beat note (from the frequency counter) and actuates on the temperature of the end laser to drive the beat note to a given setpoint.

  • I've added the necessary EPICS channels to c1iscaux and rebooted it so that the channels are live. They are listed in a new database file slow_grnx_pid.db
  • This database was added to the list of those loaded by startup.cmd.  
  • The PID script, GRNXSlowServo, is just a modified version of FSSSlowServo.
  • The version I've been running is currently in /cvs/cds/caltech/users/abrooks/.
  • There's also an MEDM screen in this directoy, C1LSC_EX_GRN_SLOW.adl, there that shows the PID settings.

Right now the script only passes the initial sanities checks, that is:

  1. It runs.
  2. You can enable/disable it without any errors and it starts actuating.

The settings all need to be tuned up - e.g. maximum_increment, hard_stops, time_step, PID constants.

Additionally, the units in the whole thing are pretty useless - some of the channels are in VOLTS, others in WATTS. I'd like to change all these to be in Hz. 


EPICS channels added:

  • grecord(ao,"C1:LSC-EX_GRN_SLOWKD")
  • grecord(ao,"C1:LSC-EX_GRN_SLOWKP")
  • grecord(ao,"C1:LSC-EX_GRN_SLOWKI")
  • grecord(ao,"C1:LSC-EX_GRN_PID_SETPT")
  • grecord(ao,"C1:LSC-EX_GRN_TIMEOUT")
  • grecord(stringin,"C1:LSC-EX_GRN_SLOWVERSION")
  • grecord(bi,"C1:LSC-EX_GRN_SLOWLOOP")
  • grecord(bi,"C1:LSC-EX_GRN_DEBUG")
  • grecord(bi,"C1:LSC-EX_GRN_SLOWBEAT")
 

 

  3911   Fri Nov 12 20:40:51 2010 josephb, yuta, valeraConfigurationElectronicsAA voltage range

We changed the range of the two SUS AA boards in the corner from +/-2 V to +/-10 V by changing the supply voltage from +/-5 V to +/-15 V. The change was made by switching the AA power feed wires on  the cross connect. The max supply according to the spec of DRV134/INA134 is +/-18 V.

We checked the new range by applying the voltage to the input of AA and measuring the output going to the ADCs. The local damping MC1,2,3 appears to work.

  3913   Sat Nov 13 16:57:21 2010 valeraConfigurationElectronicsPRM Side OSEM transimpedance change

Now that we have increased the range of the AA to +/- 10 V I have increased the PRM side OSEM transimpedance from 29 kV/A to 161 kV/A by changing the R64 in the satellite box. The first attached plot shows the ADC input spectrum before and after the change with analog whitening turned off. The PD voltage readback went up from 0.75 to 4.2 V. The second attached plot shows the sensor, ADC, and projected shot noise with analog whitening turned on and compensated digitally. The ADC calibration is 20 V/ 32768 cts. The PRM damping loops are currently disabled.

I checked for oscillation by looking at the monitor point at the whitening board. There was no obvious oscillation on a scope - the signal was 20 mV p-p on 1 us scale which was very similar to the LL channel.

  3914   Sun Nov 14 02:59:31 2010 ranaConfigurationGeneralMEDM snapshots web page

Since Nodus is a Solaris machine it can barely handle doing the ImageMagick commands (such as convert and import). I removed the auto MEDM snapshot routine from it

awhile ago and I think the rate of ELOGD crashes has decreased, although its not definitive.

The snapshots have now been re-actived to run on MAFALDA, after I fixed the absolute pathnames in the scripts and installed (via yum) the packages that mafalda

needed to run this (Xvfb, openmotif, compat, etc.). The snapshots web page is now refreshing by itself and the statScreen/cronjob.sh is running on mafalda 5x per hour.

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

  3949   Thu Nov 18 16:42:29 2010 Joonho LeeConfigurationElectronicsQuad Video for PMCT, RCT, RCR fixed.

The far right monitor in the control room is now displaying IMCR, PMCT, RCR, RCT.

Please note that top left quad is displying PMCT even if the screen is labeled with PMCR.

 

Control room monitor #13 - #16 had been out of order since the last week.

(the monitor number is shown at : http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/VideoMUX )

I found that the connections between camera and the cable to the VIDEO MUX were missing so I connected them.

Initially, PMCT camera was sending its signal to the small monitor on the PSL table.

I splitted the signal so that one signal is going to the small monitor and another is going to the VIDEO MUX.

The "PMCR" is shown on the screen #13 in the control room but it actually showing PMCT camera's signal.

 

This is a temporary VIDEO configuration. It will be upgraded as well when the whole VIDEO will be upgraded.

  3951   Thu Nov 18 23:45:18 2010 ranaConfigurationPSLPMC Refl Cam

Valera and Haixing and I installed a PMC REFL camera today. We stole the camera control box from the MC2 trans area (because I don't know why we need a camera there).

We installed it such that it is looking at the leak through of the last turning mirror before the PMC REFL RFPD. This beam was previously going into a Thorlabs razor blade dump.

There is no steering mirror to align into this camera; we just positioned the camera such that the REFL beam fills up the monitor. WE cable tied the cable to the table and the

output of the camera control box is piped into the control room correctly as PMCR. The "IMCR" quadrant is actually the PMCT beam. JoonHo is going to fix this promptly.

Also, I noticed how beautiful  the MC2 Simulink diagram is so I post it here for your viewing pleasure. We should take this as a reference and not produce any new diagrams which are less useful or beautiful or easy to understand.

  3969   Mon Nov 22 20:01:56 2010 kiwamuConfigurationComputersGPIB box : took it out from HP3563A and connect it to AG4395A

 I disconnected the yellow GPIB box from the backside of HP3563A (classic analyzer),

and connected it to AG4395A (network analyzer), which is the official place for it.

  3990   Mon Nov 29 18:05:17 2010 Leo SingerConfigurationComputersinstalled graphviz on Rosalba

I installed the following packages on Graphviz in order to support visualization of GStreamer pipeline graphs:

graphviz

  4017   Mon Dec 6 22:43:19 2010 FrankConfigurationelogelog restarted

I restarted the elog because i changed the configuration for the cryo-elog.

Used the "start-elog.csh" script in /cvs/cds/caltech/elog/

  4059   Wed Dec 15 16:04:49 2010 steveConfigurationVACvacuum valves found in default condition

This condition is created when we run out of nitrogen that holds the valves in set positions. The Maglev and other turbos are still running in this configuration so one has to pay attention that the foreline valves are open.

Reset  error message on vacuum screen and opened V4 & V5 at 3pm today.

  4083   Tue Dec 21 16:20:09 2010 steveConfigurationVACpumpdown has started

Slow pumpdown of rebuilt IFO-mark4 started at 3pm today.

We are at 680Torr at this minute with 1.5 Torr/min speed.

  4089   Wed Dec 22 17:24:50 2010 steveConfigurationVACslow pumpdown at 12 hours

We have reached 200 Torr at 12 hours of slow pumping speed. Kiwamu stopped the pumping for 11 hrs last night .and I restarted it this morning.

Now RV1 is fully open with butterfly valve in place  and the second roughing  pump RP3 was just turned on.

 

How to stop pumping:

1,  close RV1 manual valve with torque wheel

2, close V3

3, turn off roughing pumps RP1 & RP3

4, disconnect metal hose connection to butterfly valve

  4090   Wed Dec 22 21:38:47 2010 kiwamuConfigurationVACRe:slow pumpdown at 12 hours

I stopped the pumping at 9:30 pm. Now we are at 29 torr.

Quote: from  #4089

How to stop pumping:

1,  close RV1 manual valve with torque wheel

2, close V3

3, turn off roughing pumps RP1 & RP3

4, disconnect metal hose connection to butterfly valve

 

  4094   Thu Dec 23 13:30:09 2010 steveConfigurationVACslow pumpdown complete

The pump down continued this morning by the removal of the butterfly valve. Two roughing pumps were used to reach 500 mTorr

The Maglev monitoring MEDM screen "Rotating" indicator is not working. It is on all times. Please look at Maglev controller monitor for real information.

Pump down is completed.           

Configuration: vacuum normal after 86 days at atm               CC1 = 1e-5 Torr                  

                      IFO is hungry for light (and maybe some goulash with a little paprikash too)

  4100   Sat Jan 1 16:36:16 2011 ranaConfigurationSUSrampdown.pl was not running

The crontab for op340m which runs various IFO maintenance activities has been set to the wrong path for the watchdog rampdown script since the CDS changeover.

This is a dangerous situation. With the watchdog thresholds set as high as 1000, the magnets can be broken if the new CDS has some mental problems. This kind of thing happened before at LHO (which is why Stan invented the watchdogs). Please try to make sure that the watchdog thresholds are not set that way - its our only defense against bad CDS.

I've now corrected the crontab. The watchdog thresholds are being stepped down every 30 minutes as before.

However, out test points are gone again, so who knows how things are behaving.

  4137   Tue Jan 11 17:08:43 2011 SureshConfigurationPSLreplaced the pzt-steering mirror on PSL

[Rana, Jenne, Suresh]

Yesterday, We replaced the existing beam steering mirror and the PZT it was mounted on with a Gooch and Housego mirror (20ppm transmission at < 30deg incidence @1064nm) and a Polaris-K1 Newport steel mount. (JD)

We realigned the G&H mirror to get the MC flashing. 

We then had to reduce the gain in the servo circuit to accommodate the increased optical power going into MC. 

MC locked to PSL once again.

Note: 

      the old mirror stuck on the PZT has been removed.  The mirror had no markings and has been stored in the 'Unknown Optics' Box along the East Arm.

      The PZT has been stored in the PZT cabinet along with its 2in mirror mount.

  4143   Wed Jan 12 17:22:47 2011 SureshConfigurationLockingMC demod phase adjusted to minimise the I output

[Koji, Suresh]

We wanted to check and make sure that the relative phase of the two inputs ( local oscillator and photodiode signal ) to the demod board is such that the Q output is maximised.   We displayed the I and  Q signals on the oscilloscope in XYmode with I along the X direction.  If Q is maximised (and therefore I is minimised) the oscillocope trace would be perfectly vertical since all the signal would be in Q and none in I. Initially we noted that the trace was slightly rotated to the CCW of the vertical and that a short cable was present in the PD input line.  Removing this rotated the trace CW and made it pretty much vertical.  The screen shot of the oscilloscope is below.

.TEK00000.PNG

  4158   Fri Jan 14 17:58:50 2011 OsamuConfigurationGeneralStandalone RT setup

 I'll be gone to Hanford site next week and come back to Caltech on 24th's week.

I setup a standalone RT system at the desk around circuit stock in the 40m.

Please leave this setup until I come back. I'll keep working when I come back.

 

  4162   Mon Jan 17 04:10:10 2011 ranaConfigurationComputersNTPD restarted on c1dcuepics (to fix the MEDM screen times)

I installed NTPD on Megatron (its Ubuntu, so different from the CentOS workstations). Here's the terminal cap to show that its actually working:

megatron:/etc>sudo /etc/init.d/ntp restart
 * Stopping NTP server ntpd                                              [ OK ]
 * Starting NTP server ntpd                                              [ OK ]
megatron:/etc>/etc/init.d/ntp status
 * NTP server is running
megatron:/etc>ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 nodus.martian   204.123.2.72     2 u    7   64    1    0.217    3.833   0.001
 europium.canoni 193.79.237.14    2 u    6   64    1  155.354    3.241   0.001
megatron:/etc>date
Mon Jan 17 04:07:08 PST 2011

Along the way, I also updated the /etc/inet/ntp.conf file for nodus. It was using the USNO as a NTP server and I've pointed it to the Caltech NTP server as per the IMSS NTP page.

  4178   Thu Jan 20 17:00:39 2011 AidanConfigurationLockingBallpark figures for Green Locking PLLs (Digital vs Analogue)

If we use a digital PLL for locking the frequency of the PSL and END green lasers then we can expect a UGF of around 1kHz (assuming a sampling rate of 16kHz). Let's assume a simple 1/f loop giving a loop gain of ~1000x at 1Hz. If the free-swinging ETM pendulum motion at 1Hz is of the order of 1 micron, then the residual motion at 1Hz, once we lock the digital PLL by actuating on the ETM position, will be of the order of 1nm. This is bordering on too high.

Alternatively, is we use an analogue PLL then we can expect a much higher UGF and many orders of magnitude more gain at 1Hz (see here). So we would expect the residual motion of the pendulum to be much smaller - probably limited by some other noise source somewhere in the system (I doubt it's going to be reduced by 12 orders of magnitude).

RA: I think ballpark's not good enough for this. To see what's good enough, we need to to an analysis similar to what Bram has for the ALS. Get the 40m seismic spectrum from the arm locking spectrum or the green laser feedback signal and then correct it for a realistic loop shape.

KA: For this purpose I have made the simulink model for the green locking more than a year ago, but the entire green team has consistently neglected its presence...
https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/Green_Locking/Servo_modeling/091121/

  4182   Fri Jan 21 11:45:01 2011 AidanConfigurationLockingBallpark figures for Green Locking PLLs (Digital vs Analogue)

Quote:

If we use a digital PLL for locking the frequency of the PSL and END green lasers then we can expect a UGF of around 1kHz (assuming a sampling rate of 16kHz). Let's assume a simple 1/f loop giving a loop gain of ~1000x at 1Hz. If the free-swinging ETM pendulum motion at 1Hz is of the order of 1 micron, then the residual motion at 1Hz, once we lock the digital PLL by actuating on the ETM position, will be of the order of 1nm. This is bordering on too high.

Alternatively, is we use an analogue PLL then we can expect a much higher UGF and many orders of magnitude more gain at 1Hz (see here). So we would expect the residual motion of the pendulum to be much smaller - probably limited by some other noise source somewhere in the system (I doubt it's going to be reduced by 12 orders of magnitude).

RA: I think ballpark's not good enough for this. To see what's good enough, we need to to an analysis similar to what Bram has for the ALS. Get the 40m seismic spectrum from the arm locking spectrum or the green laser feedback signal and then correct it for a realistic loop shape.

KA: For this purpose I have made the simulink model for the green locking more than a year ago, but the entire green team has consistently neglected its presence...
https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/Green_Locking/Servo_modeling/091121/

 Agreed. It doesn't completely rule out the digital PLL. I'll check out Kiwamu's model.

  4186   Fri Jan 21 23:55:25 2011 ranaConfigurationLSCPhase Noise Measurement filter

We've set up a beat note measurement between the VCO driver and the Marconi (see Suresh's elog).

Here's the 'unWhiten' filter for compensating the SR560 TF.

It has poles = 1 mHz, 5 kHz, 5 kHz

and  zeros = 30 mHz, 1 kHz

The gain is set to be ~0.001 in the 1-100 Hz band to compensate the G=1000 of the SR560.

  4221   Fri Jan 28 13:05:56 2011 KojiConfigurationComputersscript path fixed

We had some issues in terms of the script paths. I have fixed it by replacing /cvs/cds/caltech/scripts to /cvs/cds/rtcds/caltech/c1/scripts

Here is the output of diff

----------------------------------------------


rossa:caltech>diff cshrc.40m cshrc.40m.20110128
44,47c44,45
< # OBSOLETE set path = ($path /cvs/cds/caltech/scripts/general)
< # OBSOLETE set path = ($path /cvs/cds/caltech/scripts/general/netgpibdata)
< set path = ($path /cvs/cds/rtcds/caltech/c1/scripts/general)
< set path = ($path /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata)
---
> set path = ($path /cvs/cds/caltech/scripts/general)
> set path = ($path /cvs/cds/caltech/scripts/general/netgpibdata)
50,51c48
< # OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules:/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
< setenv PERL5LIB /cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
---
> setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules:/cvs/cds/caltech/libs/solaris9/usr_local_lib/perl5/5.8.0/:/cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
61,64c58,59
< #OBSOLETE setenv PATH ${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/caltech/scripts/general/netgpibdata:$PATH
< setenv PATH ${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata:$PATH
< #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts
< setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts
---
> setenv PATH ${SOLARISPATH}/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:/cvs/cds/caltech/scripts/general/netgpibdata:$PATH
> setenv SCRIPTS /cvs/cds/caltech/scripts
87,88c82
< #OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
< setenv PERL5LIB /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
---
> setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
99,100c93
< #OBSOLETE setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata
< setenv SCRIPTPATH /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/scripts/general/netgpibdata
---
> setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata
103,104c96
< #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts
< setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts
---
> setenv SCRIPTS /cvs/cds/caltech/scripts
135,137c127
< #OBSOLETE alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM'
< alias listenDARM '/cvs/cds/rtcds/caltech/c1/scripts/c1/listenDARM'
<
---
> alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM'
156,157c146
< #OBSOLETE setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules
< setenv PERL5LIB /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/c1/scripts/general/perlmodules
---
> setenv PERL5LIB /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/perlmodules
167,168c156
< #OBSOLETE setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata
< setenv SCRIPTPATH /cvs/cds/rtcds/caltech/c1/scripts/general:/cvs/cds/rtcds/caltech/scripts/general/netgpibdata
---
> setenv SCRIPTPATH /cvs/cds/caltech/scripts/general:/cvs/cds/caltech/scripts/general/netgpibdata
172,173c160
< #OBSOLETE setenv SCRIPTS /cvs/cds/caltech/scripts
< setenv SCRIPTS /cvs/cds/rtcds/caltech/c1/scripts
---
> setenv SCRIPTS /cvs/cds/caltech/scripts
198,199c185
< #OBSOLETE alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM'
< alias listenDARM '/cvs/cds/rtcds/caltech/c1/scripts/c1/listenDARM'
---
> alias listenDARM '/cvs/cds/caltech/scripts/c1/listenDARM'
288,295c274,277
< #OBSOLETE alias makefiltscreen '/cvs/cds/caltech/scripts/Admin/makeFilterScreen.pl'
< #OBSOLETE alias makelockinscreen '/cvs/cds/caltech/scripts/Admin/makeLockInScreen.pl'
< #OBSOLETE alias f_and_r '/cvs/cds/caltech/scripts/Admin/find_and_replace.pl'
< #OBSOLETE alias plotrgascan '/cvs/cds/caltech/scripts/RGA/plotrgascan'
< alias makefiltscreen '/cvs/cds/rtcds/caltech/c1/scripts/Admin/makeFilterScreen.pl'
< alias makelockinscreen '/cvs/cds/rtcds/caltech/c1/scripts/Admin/makeLockInScreen.pl'
< alias f_and_r '/cvs/cds/rtcds/caltech/c1/scripts/Admin/find_and_replace.pl'
< alias plotrgascan '/cvs/cds/rtcds/caltech/c1/scripts/RGA/plotrgascan'
---
> alias makefiltscreen '/cvs/cds/caltech/scripts/Admin/makeFilterScreen.pl'
> alias makelockinscreen '/cvs/cds/caltech/scripts/Admin/makeLockInScreen.pl'
> alias f_and_r '/cvs/cds/caltech/scripts/Admin/find_and_replace.pl'
> alias plotrgascan '/cvs/cds/caltech/scripts/RGA/plotrgascan'

  4223   Fri Jan 28 15:50:44 2011 JenneConfigurationPSLThe PSL has a name!

Back in the days when we were talking about getting a new 2W PSL, I was given naming rights by Rana for this new laser. 

Today, the 40m PSL was given its new name: Edwin.

Here he is, with his shiny new label:

EdwinTheLaser.jpg

  4258   Mon Feb 7 21:23:11 2011 ranaConfigurationPSLPSL FSS Temperature Sensor Interface box removed

I noticed that the RMTEMP channel was spiking myteriously when Kiwamu opened the PSL door. We found out that the LEMO connectors would intermittently short to the case and cause ~1 deg steps in the temeprature.

We have removed the case and examined it. Not only were the connections to the box intermittent, there was a cold solder joint inside on an unsecured flying add-on opamp. The whole thing is a giant hack.

PK was the last person to work on this box, but I'm sure that he wouldn't have left it in this state. Must be gremlins.

P2070555-1.JPG

The LEMO connectors on the front are the ones touching. The LT1021 is the badly soldered part.

  4266   Wed Feb 9 23:48:12 2011 SureshConfigurationCamerasVideo Cable work: New Labels

[Larisa, Aidan,Steve,Suresh]

   Today was the first session for implementing the new video cabling plan laid out in the document " CCD_Cable_Upgrade_Plan_Jan11_2011.pdf"  by Joon Ho attached to his elog entry 4139.  We started to check and label all the existing cables according to the new naming scheme. 

So far we have labeled the following cables. Each has been checked by connecting it to a monitor near the Video Mux and a camera at the other end.

C1:IO VIDEO 8ETMYF

C1:IO-VIDEO 6 ITMYF

C1:IO-VIDEO 21 SRMF

C1:IO-VIDEO 25 OMCT

C1:IO-VIDEO 19 REFL

C1:IO-VIDEO 22 AS

C1:IO-VIDEO 18 IMCR

C1:IO-VIDEO 14 PMCT

C1:IO-VIDEO 12 RCT

C1:IO-VIDEO 9 ETMXF

C1:IO-VIDEO 1 MC2T

 

Next we need to continue and finish the labeling of existing cables.  We then choose a specific set of cables which need to be laid together and proceed to lay them after attaching suitable lables to them.

 

 

  4273   Fri Feb 11 09:27:03 2011 steveConfigurationVACRGA scan

The RGA scan is normal at day 52 of this pump down.

Light power BS 1064nm ~25mW, ETMX 532nm ~5mW

  4301   Tue Feb 15 11:57:06 2011 steve, valeraConfigurationPSLPMC swap

 We swapped the PMC s/n 2677 for s/n lho006.

The table below summarizes the power levels before and after the PMC swap.

  old new
Ptrans 1.32 W 1.42 W
Transmission 85 % 91.5 %
Refl PDDC locked/unlocked 5.0 %  4.3 %
Loss 7-8 % 2-3 %
Leakage out of the back 10 mW 0.3 mW

 

- The power into the PMC (1.67 W) was measured with Scietech bolometer before the first steering PMC mirror. The leakage through the steering mirrors was measured with Ophir power meter to be 12+8 mW. There is also a lens between the mirrors which was not measured. 

- The power through the PMC was measured after the doubler pick off (105 mW), steering mirror (4 mW), and lens (not measured).

- The estimated reflection from four lens surfaces is 1-2% hence 1% uncertainty in the losses in the table.

- The beams into the PMC and on REFL PD were realigned. The beams downstream of the PMC are blocked as we did not realigned the PMC and doubler paths.

- The trans PD ND filters were removed. The VDC=1.28 V now.

- The NPRO current is 2.102 A

 

Atm 1 old

Atm2  new

  4331   Sun Feb 20 21:22:33 2011 rana, kiwamu, valeraConfigurationIOOMC Servo Change

For some reason, Kiwamu forced us to change the MC servo electronics today. We are now combining it with the FSS box.

The MC Servo by itself was locking by just driving the NPRO PZT. Becuase of the ~30 kHz mechanical resonances of that system, our badnwidth is limited. To get higher bandwidth, we can either use a wideband frequency shifter like the AOM or just use the ole FSS combo of PZT/EOM. The old MC servo was able to get 100 kHz because it used the AOM.

So we decided to try going through the FSS box. The MC servo board's FAST output now goes into the IN1 port (500 Ohm input impedance) of the TTFSS box. This allows us to use the FSS as a kind of crossover network driving the PZT/EOM combo.

At first it didn't work because of the 5V offset that Jenne, Larisa, Koji, and Suresh put into there, so I cut the wire on the board that connected the power to the summing resistor and re-installed the MC Servo board.

We also removed the old Jenne-SURF 3.7 MHz LP between the MC mixer and servo. Also removed the Kevin-box (1.6:40) stuck onto the NPRO PZT.

We have yet to measure the UGF, but it seems OK. The PCDRIVE is too high (~5-6V) so there is still some high frequency oscillation. Needs some investigation.

* To get the FSS SLOW servo to work (change NPRO temperature to minimize PZT drive onto NPRO) I set the setpoint to 5V in the script so that we operate the FSS box output at 5V mean. I set the threshold channel to point to MC_TRANS_SUM instead of RC_TRANSPD. I also had to fix the crontab on op340m so that it would point to the right scripto_cron script which runs the FSSSlowServo, RCThermalPID.pl, etc. I also had to fix scripto_cron itself since it had the old path definitions and was not loading up the EpicsTools.pm library.

** Also, I was flabbergasted by the dog clamping on the last turning mirror into the MC. Barely touching the mount changes the alignment.

  4335   Tue Feb 22 00:18:47 2011 valeraConfiguration c1ioo and c1ass work and related fb crashes/restarts

I have been editing and reloading the c1ioo model last two days. I have restarted the frame builder several times. After one of the restarts on Sunday evening the fb started having problems which initially showed up as dtt reporting synchronization error. This morning Kiwamu and I tried to restart the fb again and it stopped working all together. We called Joe and he fixed the fb problem by fixing the time stamps (Joe will add details to describe the fix when he sees this elog).

The following changes were made to c1ioo model:

- The angular dither lockins were added for each optics to do the beam spot centering on MC mirrors. The MCL signal is demodulated digitally at 3 pitch and 3 yaw frequencies. (The MCL signal was reconnected to the first input of the ADC interface board).

- The outputs of the lockins go through the sensing matrix, DOF filters, and control matrix to the MC1,2,3 SUS-MC1(2,3)_ASCPIT(YAW) filter inputs where they sum with dither signals (CLOCK output of the oscillators).

- The MCL_TEST_FILT was removed

The arm cavity dither alignment (c1ass) status:

- The demodulated signals were minimized by moving the ETMX/ITMX optic biases and simultaneously keeping the arm buildup (TRX) high by using the BS and PZT2. The minimization of the TRX demodulated signals has not been successful for some reason.

- The next step is to close the servo loops REFL11I demodulated signals -> TMs and TRX demodulated signals -> combination of BS and PZTs.

The MC dither alignment (c1ioo) status:

- The demodulated signals were obtained and sensing matrix (MCs -> lockin outputs) was measured for pitch dof.

- The inversion of the matrix is in progress.

- The additional c1ass and c1ioo medm screens and up and down scripts are being made.

  4345   Wed Feb 23 16:34:42 2011 valeraConfiguration pmc lens staged

I put the PMC last mode matching lens (one between the steering mirrors) on a translation stage to facilitate the PMC mode matching.

Currently 4% of incident power is reflected by the PMC. But the reflected beam does not look "very professional" on the camera to Rana - meaning there is too much TEM20 (bulls eye) mode in the reflected beam.

I locked the  PMC  on bulls eye mode and measured  the ratio of the TEM20/TEM00 in transmission to be 1.3%. Thus the PMC mode matching is ~99% and the incident beam HOM content is ~3%.

While working on the PMC I found that the source of PMC "blinking" is not the frequency control signal from MC to the laser (the MC servo was turned off) but possibly some oscillation which could be affected even by a small change of the pump current 2.10 A to 2.08 A. I showed this behaviour to Kiwamu and we decided to leave the the current at 2.08 A for now where things look stable and investigate later.

  4350   Thu Feb 24 16:47:26 2011 steveConfigurationPSL shutter is back on the PSL output

Uniblitz mechanical shutter was placed into the beam path of the PSL output with razor beam trap. The output power was 1.39W at 2.08A

It is working from the MEDM screen "old map" C1IOO_Mech_Shutter.adl

  4367   Wed Mar 2 16:51:53 2011 steveConfigurationGreen Lockingmech shutter in place at the south end

I moved old POX shutter from ITMY optical table to the south end. MEDM POX mechanical shutter screen is now closing the green beam  injection into the Y arm.

I kluged in a 40m long bnc cable that Alberto left on the floor for control. It is labelled POX-sht  This is a temporary set up.

  4368   Wed Mar 2 17:19:58 2011 AidanConfigurationGreen LockingMoved PDH PD on end table

As previously noted, there are multiple beams coming back from the ETM surface onto the PDH PD on the end table. They are spread out in a vertical pattern. All the spots swing together (as the ETM moves?).

I moved the PDH Green PD on the end table so that it was further away from the Faraday and I added an iris in between the Faraday and the PD. Now only the principle reflection from the ETM is incident on the PD. See attached photos. In order to sneak past the neighbouring optics, I had to steer the beam down a bit, so the PD is now lower than it previously was.

Just FYI: the angle between the returning beams is about 5 or 6 mrad at the PD. Before the beams get to the PD they go through a telescope that de-magnifies the beam by about 5 or 6 times. This implies that the angle between adjacent returning beams from the ETM is around 1 mrad at the ETM.

This does make the position of the spot on the PD more susceptible to the alignment of the ETM - we should use a short focal length lens and image the ETM plane onto the PD.

 

First image - overview of table

Second image - the three returning beams immediately before the IRIS

Third image - a close up of the IRIS and PDH PD. 

 

 

 

  4402   Thu Mar 10 17:03:48 2011 Larisa ThorneConfigurationElectronicscalculations for passive low pass filter on X arm

[Kiwamu, Larisa] 

 

We want to increase gain in the lower frequencies, so a circuit must be designed (a passive low pass filter). 

 

First, measurements were taken at the X arm for impedance and capacitance, which were 104.5kOhms and 84.7pF respectively. Kiwamu decided to make the circuit resemble a voltage divider for ease of calculation, such that Vout/Vin would be a ratio of some values of the equivalent circuit reactance values. After a few algebra mistakes, this Vout/Vin value was simplified in terms of the R, C measured and the R', C' that would be needed to complete the circuit. 

Since the measured C was very small and the measure R was fairly high, the simplified form allowed us to pick values of R' and C' that would make the critical frequency occur at 0.1Hz: set the R' resistance to 1MOhm and C' capacitance to 10uF, which would yield a gain ~1.

With these values a circuit we can start actually making the circuit.

  4407   Sun Mar 13 00:00:58 2011 jzweizig, ranaConfigurationDAQNDS2 code change and restart

 John has changed the NDS2 code and restarted it on Mafalda. The issue is that it goes off the rails everytime the DAQD is restarted on FB because of filename convention war between GDS and CDS.

Until this is resolved, please make sure to restart the NDS2 process on Mafalda everytime you restart DAQD by doing this:

pkill -KILL nds2

/users/jzweizig/nds2-mafalda/start_nds2

  4416   Fri Mar 18 17:55:58 2011 SureshConfigurationGreen LockingWork Plan for Y-end Aux laser installation

A rough time-table and the various tasks are given below:

Note:  700mW NPRO sitting on AP table (Model No: 126-1064-700, Sl No. 415)  = Alberto's laser

 

 

Y-arm Aux laser installation
 1

Temperature dependence of frequency of Alberto's laser:

 a) Shifting Alberto's Laser (AL) to the PSL table and setting up a beat frequency measurement between AL and PSL

 b) Determining the frequency vs Temperature curve for the AL

Mar 21st to 25th Bryan and Suresh
2 Re-positioning the Input beam onto the IP-ANG-PD and realigning the X-arm Mar 21st to 25th Kiwamu and his 'team'  :-)
3

Repositioning the optics on the Y-end  table and relocating Alberto's laser ( at this point it will be rechiristened as Y-End-NPRO )

Mar 27th - 28th
Bryan and Suresh
4 Maximising the doubling effiiciency and obtaining the PD and QPD signals into the CDS Mar 29th - Apr 1st "
5 Aligning the Y-end green to pass through the Y-arm and locking the green to the Y arm Apr 3 - 8th "
6 Aligning the IR beam to the Y- arm and locking the Y arm to the IR Apr 10 - 15 "

 

  4422   Tue Mar 22 00:03:29 2011 BryanConfigurationGreen LockingPSL vs Y arm laser temperature pairing

 OK. Today we did the same type of measurement for the Y arm laser as was done for the X arm laser here: http://nodus.ligo.caltech.edu:8080/40m/3759 

And attached here is a preliminary plot of the outcome - oddities with adding on the fitted equations, but they go as follows

(Red)    T_yarm = 1.4435*T_PSL - 14.6222

(Blue)    T_yarm = 1.4223*T_PSL - 10.9818

(Green) T_yarm = 1.3719*T_PSL - 6.3917


 

 PSL_vs_Y_arm_Temperatures.png

It's a bit of a messy plot - should tidy it up later...

  4423   Tue Mar 22 00:23:20 2011 JenneConfigurationGreen LockingPSL vs Y arm laser temperature pairing

Quote:

 OK. Today we did the same type of measurement for the Y arm laser as was done for the X arm laser here: http://nodus.ligo.caltech.edu:8080/40m/3759 

And attached here is a preliminary plot of the outcome - oddities with adding on the fitted equations, but they go as follows

(Red)    T_yarm = 1.4435*T_PSL - 14.6222

(Blue)    T_yarm = 1.4223*T_PSL - 10.9818

(Green) T_yarm = 1.3719*T_PSL - 6.3917

 

 It's a bit of a messy plot - should tidy it up later...

 I'm going to take the easy question - What are the pink data points??

  4425   Tue Mar 22 19:03:45 2011 BryanConfigurationGreen LockingPSL vs Y arm laser temperature pairing

Quote:

 I'm going to take the easy question - What are the pink data points??

And I'm going to answer the easy question - they're additional beat frequency temperature pair positions which seem to correspond to additional lines of beat frequencies other than the three highlighted, but that we didn't feel we had enough data points to make it worthwhile fitting a curve.

It's still not entirely clear where the multiple lines come from though - we think they're due to the lasers starting to run multi-mode, but still need a bit of thought on that one to be sure...

  4437   Thu Mar 24 13:50:30 2011 BryanConfigurationGreen LockingY arm laser

 Just a quick update... the Lightwave laser has now been moved up to the end of the Y arm. It's also been mounted on the new mounting block and heatsinks attached with indium as the heat transfer medium.

A couple of nice piccies...IMG_0188.JPG

ELOG V3.1.3-