40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 269 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9789   Tue Apr 8 19:10:39 2014 ranaUpdateLSCarm length measurements

 Since we don't have an arm length precision measurement (i.e. better than centimeters), why not just do as Koji suggests and use the ALS to get the frequency spacing between a few red FSR and then we have the measurement solid ?

  9790   Tue Apr 8 23:04:14 2014 manasaUpdateLSCarm length measurements

Quote:

 Since we don't have an arm length precision measurement (i.e. better than centimeters), why not just do as Koji suggests and use the ALS to get the frequency spacing between a few red FSR and then we have the measurement solid ?

Arm lengths measured using ALS. Both the arms were estimated to have the same length (to the order of a centimeter) 37.51 m

How
I used ALS error signal to lock the arms and scanned the arm to find 4 consecutive IR resonances. From the beat note frequencies measured using the spectrum analyser during IR resonance, the FSR, and hence the length of the arms were calculated.

The estimated lengths are not very precise down to a mm given the resolution of the spectrum analyser. We have brought out the rubidium clock to use as reference for the spectrum analyser to challenge the measurements.

  9804   Fri Apr 11 18:55:28 2014 manasaUpdateLSCarm length measurements

Arm lengths were measured using ALS

X arm length = 37.79 +/- 0.05 m

Y arm length = 37.81 +/- 0.01 m

Whats and whys

We want to measure the arm length with an accuracy of say a mm.

This would mean a measurement precision of 1e-3/40=25ppm. (1mm in 40m)

So the required measurement resolution on the spectrum analyser is 25ppm*4MHz=100Hz (assuming the cavity FSR is roughly 4MHz). 

Although the spectrum analyser does not limit the measurement precision, we are limited by the noise in ALS at 1000Hz rms. So we can use ALS only to measure arm length precise to the order of a few mm.

RXA: Not that we really need to right now, but even with an ALS noise of 1000 Hz, we can can do better just by averaging at each resonance point. And fitting a line as you have already done gets even better:

http://en.wikipedia.org/wiki/Propagation_of_uncertainty

 

The Spectrum analyser was reference locked to the rubidium clock @10MHz for these measurements.

The FSRs of the arms

X arm = 3.9671e+06 +/- 4.8535e+03 Hz

Y arm = 3.9648e+06 +/- 1.1064e+03 Hz

Attachments:

1&2. Plots representing the arm scans showing the beat frequency for which IR resonates in the arm vs the ALS offset (position of the ETM).

3. Data and code (zip file)

P.S. We had trouble scanning the arms using ALS. This was because the slow servo was not enabled. Hence ALS was losing its PDH lock everytime we scanned past a couple of FSRs.

Attachment 1: Xarm.png
Xarm.png
Attachment 2: Yarm.png
Yarm.png
Attachment 3: 40mCavLength.zip
  14268   Fri Nov 2 16:42:31 2018 aaronUpdateComputer Scripts / Programsarm loss measuremenents

I'm continuing the arm loss measurements Yuki was making. I'm first familiarizing myself with the procedures for the measurement Johannes describes.

I'm not very familiar with the medm screens, so I'm just kind of poking around and checking with Gautam. I do the following:

  1. Turned Xarm ASS dither on, then off.
  2. Turned X and Y ALS on, then off shortly after
    1. Realizing I needed some guidance, I found this page on lock acquisition on the wiki
    2. Gautam showed me how to align/lock the IFO so I could take some notes, and we locked the Y arm, misaligned X.
  3. I put the PD back in the AS beam path to get the ASDC signal, and approximately centered the beam. This PD is on channel 1 of the scope, which is at 192.168.113.24.
  4. I centered the beam onto the MC2 PD that Yuki had installed. This PD is on channel 2 of the scope.
    1. Both scope channels are set to 1V scale (I also had tried 500mV, and it didn't seem to make a difference) and 10s time axis spacing (maximum integration time, since we're looking for a DC effect. Is this what we want?)
    2. The impedance for both channels is 1MOhm.
  5. I ran the script to start the loss measurement on the Y arm.
    1. python2 armloss_dcrefl_asdcpd_scope.py 192.168.113.24 1 2 5 YARM
    2. I'm reading ~15 (au?) for the MC channel and ~5% of that out the AS, which seems to make sense to me and looked to be about what Yuki the ratios when I checked the log files. However, I'm a bit confused by the normalization, because the maximum output of the MC PD is 10V, and indeed the scope's display is reading under 10V.

I've left the script running.

  14270   Mon Nov 5 13:52:18 2018 aaronUpdateComputer Scripts / Programsarm loss measuremenents

After running this script Friday night, i noticed Saturday that the data hadn't saved. Scrolling up inthe terminal, I couldn't see where I'd run the script, so I thought I'd forgotten to run it as I was making last minute changes to the scope settings Friday before leaving.

Monday it turns out I hadn't forgotten to run the script, but the script itself was getting hung up as it waited for ASS to settle, due to the offset on the ETM PIT or YAW setpoints. The script was waiting until both pitch and yaw settled to below 0.7, but yaw was reading ~15; I think this is normal, and it looks like Yuki had solved this problem by waiting for the DEMOD-OFFSET to become small, rather than just the DEMOD signal to be small. Since this is a solved problem, I think I might be using an old script, but I'm pretty sure I'm running the one in Johannes' folder that Yuki is referencing for example here. The scripts in /yutaro_scripts/ have this DEMOD-OFFSET functionality commented out, and anyway those scripts seem to do the 2D loss maps rather than 1D loss measurements.

In the meantime I blocked the beams and ran the script in DARK mode. The script is saving data in /armloss/data/run_20181105/, and runs with no exceptions thrown.

However, when I try to dither align the YARM, I get an error that "this is not a degree of freedom that has an ASS". I'm alsogetting some exceptions from MEDM about unavailable channels. It must have been something about donatella not initializing, because it's working on pianosa. I turned on YARM ADS from pianosa. Monitoring from dataviewer, I see that LSC-TRY_OUT has some spikes to 0.5, but it's mostly staying near 0. I tried returning to the previous frozen outputs, and also stepping around ETMY-[PIT/YAW] from the IFO_ALIGN screen, but didn't see much change in the behavior of LSC-TRY. I missed the other controls Gautam was using to lock before, and I've also made myself unclear on whether ASS is acting only on angular dof, or also on length.

I unblocked the beams after the DARK run was done.

  14274   Tue Nov 6 10:19:26 2018 aaronUpdateComputer Scripts / Programsarm loss measuremenents

I'm checking out the data this morning, running armloss_AS_calc.py using the parameters Yuki used here.

I made the following changes to scripts (measurement script and calculator script)

  • Included the 'hour' of the run in the armloss_dcrefl_* script. This way, we can run more than once a day without overwriting data.
  • Changed the calculator script to loop over all iterations of locked/misaligned states, and calculate the loss for adjacent measurements.
    • That is, the measurement script will make a measurement with the arm locked, then with it misaligned, and repeat that N times
    • The calculator now finds the loss for the nth iteration using *_n_locked and *_n_misaligned, and finds N separate loss measurements
    • The dark signal is also computed N times, though all of the dark measurements are made before running the arm scripts, so they could be all integrated together.
    • All of these are saved in the same directory that the data was grabbed from.

I repeated the 'dark' measurements, because I need 20 files to run the script and the measurements before had the window on the scope set larger than the integration time in the script, so it was padded with bad values that were influencing the calculation.

On running the script again, I'm getting negative values for the loss. I removed the beamstops from the PDs, and re-centered the beams on the PDs to repeat the YARM measurements.

  14280   Wed Nov 7 05:16:16 2018 yukiUpdateComputer Scripts / Programsarm loss measuremenents

Please check your data file and compare with those Johannes made last year. I think the power in your data file may have only three-disits and flactuate about 2%, which brings huge error. (see elog: 40m/14254)

Quote:

On running the script again, I'm getting negative values for the loss. 

  5077   Sun Jul 31 22:35:35 2011 kiwamuUpdateLSCarm loss measurement : done

I did the measurement of the arm loss on both X and Y arm by running the armLoss script.

The results will be posted later.

Quote from #5074

I will measure the loss on the X and Y arm cavity tomorrow.

 

  5359   Wed Sep 7 16:21:35 2011 kiwamuUpdateLSCarm loss measurement : resluts

Here are the results of the arm loss measurements, which I have done before the vent.

I ran the existing matlab script, called 'armLoss.m', to estimate the loss. The script resides in /scripts/LSC.


(Y arm)

 Round trip loss =  154.668624 +/- 11.343204 ppm

Yarmloss.png

The figure above is a time series of the measurement.

In the lower plot the power in the ASDC_PD are plotted. The green dotted-curve is the power when the Y arm is unlocked.

The blue dotted-curve is the one when the Y arm is locked.

In the upper plot the estimated loss from each combination of locked/unlocked power are plotted.

 


(X arm)

Round trip loss = ????? 50 ppm ?????

The obtained time series looked wired because difference in the ASDC power when the arm was locked/unlocked were small.

This small difference results in such a small loss.

To see what was going on I will look at the trend data.

Xarmloss.png

Quote from #5077

I did the measurement of the arm loss on both X and Y arm by running the armLoss script.

The results will be posted later.

 

  1557   Thu May 7 18:12:12 2009 peteUpdateLockingarm power curve

I've plotted TRX, TRY, PD12I and PD11Q.  Arm powers after locking increase for a few tens of minutes, peak out, and then decrease before lock is lost.

 

 

Attachment 1: 2009_may_7_powers.jpg
2009_may_7_powers.jpg
  1558   Thu May 7 23:21:04 2009 peteUpdateLockingarm power curve

Quote:

I've plotted TRX, TRY, PD12I and PD11Q.  Arm powers after locking increase for a few tens of minutes, peak out, and then decrease before lock is lost.

 

 

 I should have mentioned that the AS port camera image seems to get progressively uglier over the course of these locks.  Maybe we can use the JoeCam to make a movie of it. 

  2414   Mon Dec 14 15:18:18 2009 JenneUpdatelorearmLoss script ran....results confidential

I ran the armLoss script for both Xarm and Yarm.  The results are confidential, pending the completion of Alberto's cavity pole/finesse measurement due to the 'bet' as to what the new losses are after the drag wiping.

If you're the kind of person who likes to look at their Chrismas presents, the log files with the results are in the usual place for this script: /scripts/LSC/loss-ARM-GPStime.log  (loss-Y-944865071.log and loss-X-944865946.log)

  5542   Mon Sep 26 11:35:44 2011 steveUpdateCamerasarms cameras upgraded

The arm's CCD cameras were reset as picture shows last week.

The height adjustment only works at ITMX. Short post holders are ordered to make this feature  available on the rest.

The 75 ohms video and power supply cables are stress relieved. Solid cover can be attached now without  miss aligning cameras.

Attachment 1: P1080251.JPG
P1080251.JPG
  1117   Thu Nov 6 10:06:41 2008 steveUpdateLockingarms lock degradation
I have been locking the arms in the mornings lately.
The daily drift of LSC-TRX is ~ 15% and LSC-TRY ~5%
Attachment 1: arms.jpg
arms.jpg
  1591   Fri May 15 17:30:00 2009 robUpdateLSCarms, coils, locks

This is the two arms locked, for an hour.  No integrator in either loop, but from this it looks like ETMY may have a bigger length2angle problem than ETMX.  I'll put some true integrators in the loops and do this again.

 

 

Attachment 1: armslock_no_int.png
armslock_no_int.png
  1592   Sat May 16 16:20:33 2009 robUpdateLSCarms, coils, locks, #2

Quote:

This is the two arms locked, for an hour.  No integrator in either loop, but from this it looks like ETMY may have a bigger length2angle problem than ETMX.  I'll put some true integrators in the loops and do this again.

 

 

 There appear to be at least two independent problems: the coil balancing for ETMY is bad, and something about ITMX is broken (maybe a coil driver). 

The Y-arm becomes significantly misaligned during long locks, causing the arm power to drop.  This misalignment tracks directly with the DC drive on ETMY.  Power returns to the maximum after breaking and re-establishing lock.

ITMX alignment wanders around sporadically, as indicated by the oplevs and the X-arm transmitted power.  Power returns to previous value (not max) after breaking and re-establishing lock.

Both loops have integrators.

Attachment 1: twoproblems.png
twoproblems.png
Attachment 2: coil_imbalanceETMY.png
coil_imbalanceETMY.png
Attachment 3: ITMXalignment.png
ITMXalignment.png
  13099   Fri Jul 7 09:03:40 2017 SteveSummaryHistoryas it was in 1994


 

Attachment 1: 1994.PDF
1994.PDF 1994.PDF
  12977   Mon May 8 21:53:56 2017 ranaSummarySEIattempt to get seismic BLRMS minute trend

I tried to get some minute trend data today, but was unable to get it from inside or outside the control room using our matlab or python tools.

It seems the NDS2 interface will not work anywhere since it needs our minute trends to be written as frames; in the last version that Jamie left us, our minute trend frame files are not being written since they lead to periodic daqd crashes.

From inside the control room, we can get the minute trend (only with DataViewer). I've attached 30 days of BS_X just to show its real.

We can get the numerical data from the Grace plot window using the menu option Data->Export->ASCII.

You must select all of the 'Write Sets' to get all of the traces in the plot window. The resulting ascii file is not in a great format, but its not terrible.

Attachment 1: BLRMS_trend.png
BLRMS_trend.png
  1043   Mon Oct 13 13:51:49 2008 peteConfigurationPSLattempt to measure FSS ref phase
On Friday I began a measurement of the FSS reference phase. The setup involves the following:
+ turn off the 166 MHz LO (top signal generator on 1Y2 rack)
+ bring FSS LO 21.5 MHz to the 166 MHz delay line phase shifter, and back out the phase shifter with a second length of cable
+ add a length of cable to the RF 21.5 MHz in preparation for measuring FSS IN2 as a function of delay

Trouble locking the FSS, and ran out of time before the measurement could be performed.
  9475   Sun Dec 15 03:13:15 2013 DenUpdateLSCattempt to reduce carm offset

X,Y arms were stabilized using ALS and moved 5 nm from the resonance, PRMI was locked on sideband using REFL165 I&Q. POP angular servo was running; PRMI RIN was good (~2-3%)

During slow offset reduction I was sweeping MICH, PRCL and POP servos for instabilities due to possible optical gain variations, loops were fine.

I could reduce offset down to ~200 pm and then lost lock due to 60 Hz oscillations as shown on the attached plot "arm_offset"

Arms were stabilized with RMS comparable to the offset and power in arms was fluctuating from 3 to 45.

60 Hz line most probably comes from MICH. RMS is dominated by the power lines and is ~ 1 nm as seen on the plot "PRMI_CAL". I think this is too much but we need to do simulations.

Attachment 1: ARM_OFFSET.pdf
ARM_OFFSET.pdf
Attachment 2: PRMI_CAL.pdf
PRMI_CAL.pdf
  12876   Thu Mar 9 17:26:43 2017 SteveUpdateGeneralattempted ETMY picture taking

I removed the video monitoring can and replaced it with Olympus SP-570UZ camera. It has no IR blocker. The OSEM light are dominant because I can not zoom in more.

I left the camera in place so you can try it. Leave the LEXAN plate on the glass window so no accident can happen. The illuminator is on and you can turn it off-on with the manual switch, close to the camera. Camera manual is on my desk.

 

  12877   Thu Mar 9 20:11:04 2017 KojiUpdateGeneralattempted ETMY picture taking

The attached is the ETMY image with the single arm locked. This was the best I could do. Here is the recipe

  • Turn on SP570UZ
  • Switch to "M" mode (Manual aperture and exposure)
  • Set the aperture to be the widest (smallest F number) and the exposure to be maximum (15 second).
  • Switch to AF mode by the lens side switch
  • Use the lens dial to adjust the zoom until the OSEMs fill the central 1/3 box (i.e. 1/9 area of the field of view). If you zoom more, you can't focus the spot later.
  • Use menu button to switch to ISO1600 (You are now capable to see the beam spot)
  • Switch to MF mode by the lens side switch
  • Use the lens dial to adjust the focus to have the sharpest image of the spot. This can be achieved at the focal distance of ~1m
  • Use menu button to switch back to ISO64
  • Push the shutter (I didn't use it, but you should be able to use 2sec timer)
Attachment 1: P3090032.JPG
P3090032.JPG
  12881   Fri Mar 10 18:00:22 2017 SteveUpdateGeneralattempted ETMY picture taking

Your technique works Koji

Attachment 1: P3100044.JPG
P3100044.JPG
Attachment 2: P3090024.JPG
P3090024.JPG
  11636   Tue Sep 22 17:30:55 2015 jamieUpdateDAQattempts at getting new fb working

Today I've been trying to get the new frame builder, tentatively 'fb1', to work.  It's not fully working yet, so I'm about to revert the system back to using 'fb'.  The switch-over process is annoying, since our one myrinet card has to be moved between the hosts.

A brief update on the process so far:

I'm being a little bold with this system by trying to build daqd against more system libraries, instead of the manually installed stuff usually nominally required.  Here's some of the relevant info about th fb1 system:

  • Debian 7 (wheezy)
  • lscsoft ldas-tools-framecpp-dev 2.4.1-1+deb7u0
  • lscsoft gds-dev 2.17.2-2+deb7u0
  • lscsoft libmetaio-dev 8.4.0-1+deb7u0
  • lscsoft libframe-dev 8.20-1+deb7u0
  • /opt/rtapps/epics-1.4.12.2_long
  • /opt/mx-1.2.16
  • advLigoRTS trunk

I finally managed to get daqd to build against the advLigoRTS trunk (post 2.9 branch).  I'll post detailed build log once I work out all the kinks.  It runs ok, including writing out full frames, as well as second and minute trends and raw minute trends, but there are a couple of show-stopper problems:

  • daqd segfaults if the C1EDCU.ini is specified.  If I comment out that one file from the 'master' channel ini file list then it runs without segfaulting.
  • Something is going on with the mx_streams from the front ends:
    • They appear to look ok from the daqd side, but the FEC-<ID>_FB_NET_STATUS indicators remain red.  The "DAQ" bit in the STATE_WORD is also red.  Again, this is even though data seems to be flowing.
    • The mx_stream processes on the front ends are dying (and restarting via monit) about every 2 minutes.  It's unclear what exactly is happening, but they all dia around the same time, so it possibly initiated from a daqd problem.  Around the time of the mx_stream failures, we see this in the daqd log:
[Tue Sep 22 17:24:07 2015] GPS MISS dcu 91 (TST); dcu_gps=1127003062 gps=1127003063

Aborted 1 send requests due to remote peer Aborted 1 send requests due to remote peer 00:25:90:0d:75:bb (c1sus:0) disconnected
mx_wait failed in rcvr eid=004, reqn=11; wait did not complete; status code is Remote endpoint is closed
00:30:48:d6:11:17 (c1iscey:0) disconnected
mx_wait failed in rcvr eid=002, reqn=235; wait did not complete; status code is Remote endpoint is closed
disconnected from the sender on endpoint 002
mx_wait failed in rcvr eid=005, reqn=253; wait did not complete; status code is Bad session (missing mx_connect?)
disconnected from the sender on endpoint 005
disconnected from the sender on endpoint 004
[Tue Sep 22 17:24:13 2015] GPS MISS dcu 39 (PEM); dcu_gps=1127003062 gps=1127003069
  • Occaissionally the daqd process dies when the front end mx_streams processes die.

I'll keep investigating, hopefully with some feedback from Keith and Rolf tomorrow.

  11653   Wed Sep 30 13:59:49 2015 jamieUpdateDAQattempts at getting new fb working

I got Steve to get us a new Myrinet fiber network adapter card for fb1:

  • Myrinet 10G-PCIE-8B-S

I just finished installing the card in fb1, and it came up fine.  We happened to have a spare fiber, and a spare fiber jack in the DAQ switch, so I went ahead and plugged it in in parallel to the old fb:

controls@fb1:~/rtbuild/trunk 130$ /opt/mx/bin/mx_info
MX Version: 1.2.16
MX Build: controls@fb1:/opt/src/mx-1.2.16 Fri Sep 18 18:32:59 PDT 2015
1 Myrinet board installed.
The MX driver is configured to support a maximum of:
    8 endpoints per NIC, 1024 NICs on the network, 32 NICs per host
===================================================================
Instance #0:  364.4 MHz LANai, PCI-E x8, 2 MB SRAM, on NUMA node 0
    Status:         Running, P0: Link Up
    Network:        Ethernet 10G

    MAC Address:    00:60:dd:43:74:62
    Product code:   10G-PCIE-8B-S
    Part number:    09-04228
    Serial number:  485052
    Mapper:         00:60:dd:46:ea:ec, version = 0x00000000, configured
    Mapped hosts:   7

                                                        ROUTE COUNT
INDEX    MAC ADDRESS     HOST NAME                        P0
-----    -----------     ---------                        ---
   0) 00:60:dd:43:74:62 fb1:0                             1,0
   1) 00:25:90:0d:75:bb c1sus:0                           1,0
   2) 00:30:48:be:11:5d c1iscex:0                         1,0
   3) 00:30:48:d6:11:17 c1iscey:0                         1,0
   4) 00:30:48:bf:69:4f c1lsc:0                           1,0
   5) 00:14:4f:40:64:25 c1ioo:0                           1,0
   6) 00:60:dd:46:ea:ec fb:0                              1,0

We can now work on fb1 while fb continues to run and collect data from the front ends.

I'm still not getting the mx_stream connections to the new fb1 daq to work.  I'm leaving everything running as is on fb for the moment.

  484   Sun May 18 18:14:30 2008 ranaSummaryComputer Scripts / Programsautlockers and cron
Today I noticed that the MC was unlocked, the MC autolocker was off, the PSL autolocker was off,
and the PSL Slow loop was off.

Reading through .log files and our elog it seems like things have been this way since Tuesday
when Andrey went around rebooting computers to bring things back.

And it looks like the ETMY optical lever is dead.

I restarted the PSL & MC scripts on op340m. I also locked and aligned the X arm to verify that
not everything is broken. The Y Arm is unalignable until we replace the HeNe.
  311   Tue Feb 12 16:18:29 2008 robConfigurationComputer Scripts / Programsautoburt cron moved to op340m

I moved the autoburt cron job from op440m to op340m. For some reason, burtrb requires gcc to run (I gather it uses the C-preprocessor to parse input files), so I had to install that on op340m to get it to work properly.

There are no more cron jobs running on op440m now.
  13525   Wed Jan 10 15:25:43 2018 johannesConfigurationComputer Scripts / Programsautoburt making backups again
Quote:

I manually created the /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2018/ directory. Maybe this fixes the hickup? Gotta wait about 30 minutes.

It worked. The first backup of the year is now from Wednesday, 01/10/18 at 15:19. Ten days of automatic backups are missing. Up until 2204 the year folders had been pre-emptively created so why was 2018 missing?

gautam: this is a bit suspect still - the snapshot file for c1auxex at least seemed to be too light on channels recorded. this was before any c1auxex switching. to be investigated.

  13524   Wed Jan 10 14:17:57 2018 johannesConfigurationComputer Scripts / Programsautoburt no longer making backups

I was looking into setting up autoburt for the new c1auxex2 and found that it stopped making automatic backups for all machines after the beginning of the new year. There is no 2018 folder (it was the only one missing) in /opt/rtcds/caltech/c1/burt/autoburt/snapshots and the /latest/ link in /opt/rtcds/caltech/c1/burt/autoburt/ leads to the last backup of 2017 on 12/31/17 at 23:19.

The autoburt log file shows that the back script last ran today 01/10/18 at 14:19, as it should have, but doesn't show any errors and ends with "You are at the 40m".

I'm not familiar with the autoburt scheduling using cronjobs. If I'm not mistaken the relevant cronjob file is /cvs/cds/rtcds/caltech/c1/scripts/autoburt/autoburt.cron which executes /cvs/cds/rtcds/caltech/c1/scripts/autoburt/autoburt.pl

I've never used perl but there's the following statement when establishing the directory for the new backup:

  $yearpath = $autoburtpath."/snapshots/".$thisyear;
  # print "scanning for path $yearpath\n";
  if (!-e $yearpath) {
    die "ERROR: Year directory $yearpath does not exist\n";
  }

I manually created the /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2018/ directory. Maybe this fixes the hickup? Gotta wait about 30 minutes.

  2471   Sun Jan 3 08:23:39 2010 ranaConfigurationCDSautoburt.pl 'fixed' for post 2009 years

Tobin & Keith pointed out in the LLO ilog that there was a code bug in the autoburt.pl script for autoburts.

I edited the autoburt.pl script so that it will work from now until 2099 (by which time we may no longer be using this version of perl):

nodus:autoburt>diff autoburt.pl~ autoburt.pl
234c234
<     $thisyear = "200".$timestamp[5];
---
>     $thisyear = "20".$timestamp[5];

The autoburt has not been working ever since 11PM on New Year's eve.

I ran it by hand and it seems to run fine. I noticed along the way that it was running on op340m (our old Sun Blade 150 machine). The autoburt.pl was pointing at /cvs/cds/bin/perl

which is Perl v5.0. I changed it to use '/usr/bin/env' and now points at '/usr/bin/perl' which is perl 5.8. It runs fine with the new perl:

op340m:scripts>time perl /cvs/cds/scripts/autoburt.pl >> /cvs/cds/caltech/logs/autoburtlog.log
5.37u 6.29s 2:13.41 8.7%

Also ran correctly, via cron, at 9AM.

  10049   Tue Jun 17 16:52:40 2014 ericqUpdateComputer Scripts / Programsautolocker confusion

Quote:

the MC autolocker is NOT running alright.

I'm kind of confused by the current auto locker situation. Somebody renamed the script from autolockMCmain40m to AutoLockMC.csh and did not update the crontab with the new filename. 

Furthermore it doesn't seem like  scripto_cron,a script which keeps the auto locker alive, runs ok on ottavia. When I run this on the command line, it claims that the process is already running, and returns some bunk PID that doesn't correspond to any running process. The script has a line stating setenv OSTYPE solaris , so maybe there's something funky going on with it's pgrep-ing or other command parsing.   

Lastly, if I try running AutoLockMC.csh directly on ottavia, I get a bunch of complaints about pmath and pezcabit not being found. 

  10052   Tue Jun 17 19:39:29 2014 ranaUpdateComputer Scripts / Programsautolocker confusion

I renamed the Autolocker and described it in the elog from this weekend. To run it, you have to run it from the scripts/MC/ directory (as always). I restarted the autolocker on Ottavia with nohup.

> nohup ./AutoLockMC.csh &

To figure out how to get cron to run it, we will have to debug the difference between linux and solaris pgrep, so that's in progress.

  10054   Wed Jun 18 11:28:19 2014 ManasaUpdateComputer Scripts / Programsautolocker confusion

Quote:

I renamed the Autolocker and described it in the elog from this weekend. To run it, you have to run it from the scripts/MC/ directory (as always). I restarted the autolocker on Ottavia with nohup.

> nohup ./AutoLockMC.csh &

To figure out how to get cron to run it, we will have to debug the difference between linux and solaris pgrep, so that's in progress.

I am NOT convinced that the autolocker script is running or doing anything. The MC was unlocked as of this morning and the autolocker wasn't doing anything to any of the MC servo buttons and sliders. The autolocker control shows that it is 'alive' but it still blinks 'MC down' even after I locked the MC manually. I am suspecting that this might have to do something with the caget and caput in autolock script itself rather than the CRON. I will look into this problem later today.

Moral of the story: The autolocker is not doing its job.

  10056   Wed Jun 18 13:29:48 2014 ranaUpdateComputer Scripts / Programsautolocker confusion

 

 Moral is wrong.

AutoLocker was working fine last night and we observed it to run and do the appropriate mcdown and mcup stuff. Probably something is breaking with it after several hours.

If you have suspicions about the script, best to look through the logs during the first few hours when we had it running yesterday.

  10060   Wed Jun 18 17:38:14 2014 JenneUpdateComputer Scripts / Programsautolocker running again

The MC autolocker is once again running on Ottavia, with the nohup command.  

It was hanging for a long time (at least minutes) on the cavput and the caputs in the MC2 tickle on and off scripts.  I claim that there isn't a good reason to not just use ezcawrite, or whatever the latest and greatest fully functioning function is, so I've changed the cavput to a series of ezcawrites, and all of the caputs are also ezcawrites.  Now I don't see any hanging, and the MC locks itself.

This does not solve the scripto_cron issue, so if Ottavia is rebooted, or the autolocker is otherwise killed, it will not start itself up. 

  10074   Thu Jun 19 16:49:15 2014 ranaUpdateComputer Scripts / Programsautolocker running again

  We've noticed that the caget/caput and cdsutils take a long time to return the command prompt. The following two ping commands indicate that it may be related to routing or our new BIND9 DNS setup on chiara.

 

 

controls@ottavia|~ > ping -c 5 -D c1sus

 

PING c1sus.martian (192.168.113.85) 56(84) bytes of data.

 

[1403221338.383403] 64 bytes from 192.168.113.85: icmp_req=1 ttl=64 time=0.114 ms

 

[1403221343.386211] 64 bytes from 192.168.113.85: icmp_req=2 ttl=64 time=0.059 ms

 

[1403221348.387666] 64 bytes from 192.168.113.85: icmp_req=3 ttl=64 time=0.060 ms

 

[1403221353.389736] 64 bytes from 192.168.113.85: icmp_req=4 ttl=64 time=0.059 ms

 

[1403221354.390713] 64 bytes from 192.168.113.85: icmp_req=5 ttl=64 time=0.060 ms

 

--- c1sus.martian ping statistics ---

 

 

 

5 packets transmitted, 5 received, 0% packet loss, time 20007ms

 

rtt min/avg/max/mdev = 0.059/0.070/0.114/0.023 ms

 

 

 

controls@ottavia|~ > ping -c 5 -D 192.168.113.85

 

PING 192.168.113.85 (192.168.113.85) 56(84) bytes of data.

 

[1403221463.737857] 64 bytes from 192.168.113.85: icmp_req=1 ttl=64 time=0.078 ms

 

[1403221464.737353] 64 bytes from 192.168.113.85: icmp_req=2 ttl=64 time=0.059 ms

 

[1403221465.737318] 64 bytes from 192.168.113.85: icmp_req=3 ttl=64 time=0.050 ms

 

[1403221466.737316] 64 bytes from 192.168.113.85: icmp_req=4 ttl=64 time=0.052 ms

 

[1403221467.737321] 64 bytes from 192.168.113.85: icmp_req=5 ttl=64 time=0.050 ms

 

 

 

--- 192.168.113.85 ping statistics ---

 

5 packets transmitted, 5 received, 0% packet loss, time 3999ms

 

rtt min/avg/max/mdev = 0.050/0.057/0.078/0.014 ms

 
  490   Wed May 21 15:21:33 2008 robUpdateComputer Scripts / Programsautolockers and cron

I added hourly cron jobs to op340m to ensure that

MC autolocker
FSS Slow Servo
PSL watch

are running. I've also edited the wiki procedure to reflect the fact that these no longer need to be restarted by hand.
  187   Mon Dec 10 20:35:59 2007 tobinConfigurationComputer Scripts / Programsautolocking scripts
I added this tidbit of csh code to the MZ autolocker to prevent multiple copies from running (on one computer):
if (`pgrep lockMZ | wc -l` > 1) then
   echo lockMZ is already running! 
   exit
endif
Similarly, here's some bash code that does something similar; I'll add it to the other autolocker scripts:
if                                                                                                                       
  pgrep `basename $0` | grep -v $$ > /dev/null                                                                           
then                                                                                                                     
  echo Another copy of this program is already running.  Exiting!                                                        
  exit 1                                                                                                                 
fi
This code searches for all processes with the same name as this script ($0) and then use grep to exclude (-v) the current process ID ($$).
  3723   Thu Oct 14 20:49:50 2010 yutaUpdateComputersautomated Q-value adjuster

Background:
 Now we can use pyNDS(see elog #3722), so I wrote a python script that adjusts Q-value automatically.

What I did:
1. Wrote a python script. /cvs/cds/caltech/users/yuta/scripts/QAdjuster.py

2. Ran this script for every DOF, every MC suspension.

Result:
 Following lines and attached are example output when I ran QAdjuster.py for MC3 POS.

Currently, C1:SUS-MC3_SUSPOS_GAIN is 5

Connecting.... authenticate failed: Unspecified error
Connecting.... done
Current GPS time is 971149410

I kicked C1:SUS-MC3_SUSPOS_OFFSET

Waiting for the ringdown...... 0\

Current GPS time is 971149431

omega_0= 6.326764,
Q= 11.254252,
A= -53.491850,
delta= 5.007821,
ofset= 4349.808434

Q-value was 11.3
Set C1:SUS-MC3_SUSPOS_GAIN = 10.2311380794


 Current Q-values automatically set are as follows.

  MC1 MC2 MC3
POS 4.9 4.8 5.9
PIT 6.8 5.5 4.5
YAW 6.4 5.6 5.3
SIDE 5.8 5.2 5.0


Next work:
 - Modify the script so that it adjusts all the channels automatically. Now, it is one by one, trial by trial.
 - Modify the script so that it automatically turns the offset switch on. Now, it must be turned on beforehand.
 - Write a how-to

Attachment 1: MC3_SUSPOS.png
MC3_SUSPOS.png
  11245   Fri Apr 24 21:31:20 2015 KojiSummaryCDSautomatic mxstream resetting

We were too much annoyed by frequent stall of mxstream. We'll update the RCG when time comes (not too much future).

But for now, we need an automatic mxstream resetting.

I found there is such a script already.

/opt/rtcds/caltech/c1/scripts/cds/autoMX

So this script was registered to crontab on megatron.
It is invoked every 5 minutes.

# Auto MXstream reset when it fails
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /opt/rtcds/caltech/c1/scripts/cds/autoMX >> /opt/rtcds/caltech/c1/scripts/cds/autoMX.log

  883   Mon Aug 25 21:15:23 2008 ranaConfigurationLSCaux NPRO off
Looks like no one has used the Lightwave NPRO on the AS table after Koji left, so I turned it off so that it can rest until Alberto does the X-arm measurements.
  13478   Thu Dec 14 23:27:46 2017 johannesUpdateDAQaux chassis design

Made a front and back panel and slot panels for DSub and IDC breakouts. I want to send this out soon, are there any comments? Preferences for color schemes?

Attachment 1: auxdaq_40m_4U_front.pdf
auxdaq_40m_4U_front.pdf
Attachment 2: auxdaq_40m_4U_rear.pdf
auxdaq_40m_4U_rear.pdf
Attachment 3: auxdaq_40m_4U_DSub37x2.pdf
auxdaq_40m_4U_DSub37x2.pdf
Attachment 4: auxdaq_40m_4U_IDC50.pdf
auxdaq_40m_4U_IDC50.pdf
  13916   Tue Jun 5 02:06:59 2018 gautamUpdatePSLaux laser first (NULL) results

[johannes, gautam]

  1. Johannes aligned the single bounce off the ITM into the AUX fiber on the AS table, and also the AUX beam into the fiber on the PSL table.
    • Mode matching isn't spectaular anywhere in this chain.
    • But we have 2.6mW of light going into the SRM with the AOM deflection into the 1st order beam (which is what we send into the IFO) maximum.
  2. We set up some remote capabilities for the PLL and Marconi frequency (=PLL setpoint) control.
  3. Motivation was to try and lock DRMI, and look for some resonance of the AUX beam in the SRC.
    • We soon realized this was a way too lofty goal.
    • So we decided to try the simpler system of PRMI locked on carrier.
    • We were successfully able to sweep the Marconi setpoint in up to 20kHz steps (although we can only move the setpoint in one direction, not sure I know why now).
    • Then we decided to look for resonances of the AUX beam in the arm cavity.
    • Still no cigar broken heart
  4. Plus points:
    • PLL can be reliably locked remotely.
    • Marconi freq. can be swept deterministically remotely.
  5. Tomorrow:
    • Fix polarization issues. There is some low freq drift (~5min period) of the power incident on the fiber on the PSL table which we don't understand.
    • Verify MM into IFO and also into fiber at PSL table.
    • Do mode spectroscopy.

I was wondering why the PMC modulation sidebands are showing up on the control room analyzer with ~6dB difference in amplitude. Then I realized that it is reasonable for the cabling to have 6dB higher loss at 80 MHz compared to 20 MHz.

  13911   Sun Jun 3 22:48:59 2018 johannesUpdatePSLaux laser replacement

I brought the NPRO from the Crackle experiment over to the 40m Lab and set it up on the PSL table to replace the slowly dying AUX laser. I also brought along a Faraday isolator, broadband EOM, and an ISOMET AOM with driver electronics from the optics storage in the Crackle Lab.

This laser is a much newer model, made in 2008, and still has all its mojo, but we should probably keep up the practice of turning it off when it's not going to be used for a while. I measured 320 mW leaving the laser, and 299mW of that going through the Faraday isolator, whose Brewster-angle polarizer I had to clean because they were a little dusty. While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted. This is a completely different failure mode from what we've seen with the other NPROs that we can hopefully get repaired at some point, particularly because the laser is newer, but for now it's installed on the PSL table. This likely means that the noise eater isn't working on this unit either, for different reasons, but at least we have plenty of optical power.

The setup is very similar to before, with the addition of a Faraday isolator and a broadband EOM, in case we decide to get more bandwidth in the PLL. I changed the Crystal Technologies 3200-113 200 MHz AOM for an ISOMET 80 MHz AOM with RF driver from the Crackle lab's optics storage and sized the AUX beam to a diameter of 200 micron. I couldn't locate an appropriate heat sink for the driver, which is still in factory condiction, but since the PSL AOM also runs on 80MHz I used that one instead. The two AOMs saturate at different RF powers, so care must be taken to not drive the AUX AOM too high. At 600 mV input to the driver the deflection into the first order was maximal at 73 % of the input power, with the second order beam and the first order on the other side cleary visible.

In order to speed things up I didn't spend too much time on mode-matching, but the advantage of the fiber setup is that we can always improve later if need be without affecting things downstream. I coupled the first order beam into the fiber to the AS table with 58% efficiency, and restored the beat with the PSL laser on the NewFocus 1611. The contrast there is only about 20%, netting a -20 dBm beat note. This is only a marginal improvement from before, so the PLL will work as usual, but if we get the visibility up a little in the future we won't need to amplify the PD signal for the PLL anymore.

Some more things I wanted to do but didn't get to today are

  • Measure intensity noise of aux laser
  • Measure rise and fall times of new AOM
  • Get PLL back up and running
  • Place 90/10 beamsplitter in AS path and couple IFO output into fiber (= couple fiber output into IFO)

I'll resume this work tomorrow. I turned the aux laser and the AOM driver input off. For the PSL beat the AOM drive is not needed, and the power in the optical fiber should not exceed 100 mW, so the offset voltage to the AOM RF driver has to remain below 300 mV.

  13912   Mon Jun 4 02:52:52 2018 johannesUpdatePSLaux laser replacement

> While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted.

NPRO internal power monitor often shows smaller value than the actual due to a broken PD or misalignment. I don't think we need to fix it.

STEVE: Aux Lightwave M126-1064-200, sn259 [July 2009] 1.76A, ADJ 9,  9mW on it's display should not mislead you. It's output  320mW

Quote:

I brought the NPRO from the Crackle experiment over to the 40m Lab and set it up on the PSL table to replace the slowly dying AUX laser. I also brought along a Faraday isolator, broadband EOM, and an ISOMET AOM with driver electronics from the optics storage in the Crackle Lab.

This laser is a much newer model, made in 2008, and still has all its mojo, but we should probably keep up the practice of turning it off when it's not going to be used for a while. I measured 320 mW leaving the laser, and 299mW of that going through the Faraday isolator, whose Brewster-angle polarizer I had to clean because they were a little dusty. While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted. This is a completely different failure mode from what we've seen with the other NPROs that we can hopefully get repaired at some point, particularly because the laser is newer, but for now it's installed on the PSL table. This likely means that the noise eater isn't working on this unit either, for different reasons, but at least we have plenty of optical power.

The setup is very similar to before, with the addition of a Faraday isolator and a broadband EOM, in case we decide to get more bandwidth in the PLL. I changed the Crystal Technologies 3200-113 200 MHz AOM for an ISOMET 80 MHz AOM with RF driver from the Crackle lab's optics storage and sized the AUX beam to a diameter of 200 micron. I couldn't locate an appropriate heat sink for the driver, which is still in factory condiction, but since the PSL AOM also runs on 80MHz I used that one instead. The two AOMs saturate at different RF powers, so care must be taken to not drive the AUX AOM too high. At 600 mV input to the driver the deflection into the first order was maximal at 73 % of the input power, with the second order beam and the first order on the other side cleary visible.

In order to speed things up I didn't spend too much time on mode-matching, but the advantage of the fiber setup is that we can always improve later if need be without affecting things downstream. I coupled the first order beam into the fiber to the AS table with 58% efficiency, and restored the beat with the PSL laser on the NewFocus 1611. The contrast there is only about 20%, netting a -20 dBm beat note. This is only a marginal improvement from before, so the PLL will work as usual, but if we get the visibility up a little in the future we won't need to amplify the PD signal for the PLL anymore.

Some more things I wanted to do but didn't get to today are

  • Measure intensity noise of aux laser
  • Measure rise and fall times of new AOM
  • Get PLL back up and running
  • Place 90/10 beamsplitter in AS path and couple IFO output into fiber (= couple fiber output into IFO)

I'll resume this work tomorrow. I turned the aux laser and the AOM driver input off. For the PSL beat the AOM drive is not needed, and the power in the optical fiber should not exceed 100 mW, so the offset voltage to the AOM RF driver has to remain below 300 mV.

 

  13913   Mon Jun 4 11:00:37 2018 gautamUpdatePSLaux laser replacement
Quote:

I couldn't locate an appropriate heat sink for the driver, which is still in factory condiction, but since the PSL AOM also runs on 80MHz I used that one instead.

We have the appropriate heatsink - I'd like to minimize interference with the main beam wherever possible.

Quote:

For the PSL beat the AOM drive is not needed, and the power in the optical fiber should not exceed 100 mW, so the offset voltage to the AOM RF driver has to remain below 300 mV.

If damage to the fiber is a concern, I think it's better to use a PBS + waveplate to attenuate the power going into the fiber. When the AOM switching is hooked up to CDS, it's easy to imagine a wrong button being pressed or a wrong value being typed in.

It would probably also be good to have a pickoff monitor for the NPRO DC power so that we can confirm its health (in the short run, we can hijack a PSL Acromag channel for this purpose, as we now do for FSS_RMTEMP). I don't know that we need an EOM for the PLL, as in order to get that going, we probably need some fast electronics for the EOM path, like an FSS box. 

STEVE: I ordered the right heatsink for the acousto after Koji pointed out that the vertical fins are 20% more efficient. Why? Because hot air rises. It will be here in 3-4 days.

  16085   Mon Apr 26 18:52:52 2021 Anchal, PacoHowToComputer Scripts / Programsawg free slot

Today we had some trouble launching an excitation on C1:IOO-MC_LSC_EXC from awggui. The error read:

awgSetChannel: failed getIndexAWG C1:SUS-MC2_LSC_EXC ret=-3

What solved this was the following :

  1. launch the dtt command line interface
  2. Anchal remembers a slot number 37008
  3. We issue >> awg free 37008
  4. Slot freed, launch a new instance of awggui
  1366   Fri Mar 6 18:14:58 2009 YoichiUpdateComputersawg not working
Starting from this afternoon, the awg is not working.
I rebooted FE computers, c0daqawg as well as tpman and daqd processes on fb40m several times.
But the problem is still there.
I sent an email to Alex.
  6204   Tue Jan 17 02:44:59 2012 kiwamuUpdateCDSawg not working

AWG is not working. This needs to be fixed.

I could set the channel and the parameters in the AWGGUI screen, but it never inject signals to the realtime system.

  6207   Tue Jan 17 16:09:20 2012 kiwamuUpdateCDSawg not working on the c1sus machine

Actually awg works fine without any problems when the excitation channels belong to the c1lsc machine.

It seems that the awg doesn't inject signals on the channels of the c1sus machine, for example C1:SUS-BS_LSC_EXC and so on.

Quote from #6204

AWG is not working. This needs to be fixed.

ELOG V3.1.3-