40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 287 of 335  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  8586   Wed May 15 23:38:04 2013 ranaUpdateelogcategories trimmed

I deleted a bunch of useless categories from the 40m elogd.cfg file. IF you find your category has been deleted, you can now learn how to categorize yourself into the existing categories. ELOG restarted and log file zeroed.

  8588   Thu May 16 02:34:38 2013 ranaUpdateComputer Scripts / ProgramsAutoRUN GUI resurrected

We talked about the thing that watches the scripts for autolocking during the meeting today.

I've resurrected the Perl-Tk GUI that we used through i/eLIGO for watching the IFO and running the appropriate scripts. This is not meant to be a replacement for aLIGO stuff, but just something to get us going for now. I expect that we will make some new fanciness which will eclipse this, but I brought it back so that we don't start off with some 'Advanced' system which is worse than the old one.

You can run it from scripts/c1/ by typing ./AutoRUN.pl. It pops up the GUI and starts in a Disabled mode where it watches and does nothing.

I have done some editing of the GUI's code so that it uses caget / caput instead of ezca binaries. New stuff is in the SVN.

Next up is to start testing it and fixing it up so that it uses the thresholds set in the LSC screens rather than some hardcoded values.

Eventually we should also convert all of its daughter scripts from tcsh to bash to keep Jamie's blood pressure in the low hundreds...

  8596   Fri May 17 16:06:14 2013 ranaUpdate40m upgradingETMY op table disabled

 

 TODO:

  1. We need to replace all of the floppy anodized Al dumps with clean razor blade dumps on stiff mounts. BOTH of the rejected ports of the 1064 FI need some kind of custom dump.
  2. All of the leakthrough beams of the HR mirrors also need razor dumps. A good rule of thumb is that your first notion of how to implement the beam dump is NOT good enough.
  3. The whole lens / modematching situation for the 1064 and 532 paths will have to be redone so as to put the beam waists inside the Faraday crystal (NOT outside). The beam waist in the 4.7 mm diameter Faraday should be ~0.3-0.4 mm.
  4. The efficiency that we got for the doubling shows that we don't need the cylindrical lenses - they are nice, but not needed to get 90% of the max power.
  5. The lenses between the 1064 FI and the doubler should be put onto a base that can be used to adjust the lens position for MM optimization. Nothing fancy, just something slideable.
  6. For this iteration of the table, we can do as Annalisa has written so as to get the green MM lenses ordered ASAP. After next week we can come up with a new plan before dismantling the EX table.
  8667   Mon Jun 3 22:36:07 2013 ranaUpdateLSCALS-TRY_OUT needs anti-whitening

 After working some more on the EY table, we are getting some TEM00 flashes for the Y arm green. We have had to raise the height of one of the MM lenses to prevent clipping.

We used a function generator to apply a ~300 mV 10 Hz triangle wave to scan the laser frequency while aligning.

We tried to use the C1:ALS-TRY_OUT channel to help us in our alignment but there are a couple problems:

1) It seems that there is an uncompensated whitening filter before the ADC - Annalisa is making a compensation filter now.

2) The data delay is too much to use this for fast alignment. We might need to get a coax cable down there or mount a wired ethernet computer on the wall.

3) We need to make DQ channels for the TRY and TRX OUT. We need long term data of these, not just test points.

  8668   Tue Jun 4 10:33:09 2013 ranaUpdateSUSETMY oplev path redone

 We also redid the oplev path.

Someone had used the illegal tactic of using aluminum dogs to hold down mounts which already have screw holes in the bases. This is too flimsy to use.

We then adjusted the position of the second lens to get a ~1 mm spot on the QPD. There is a lot of stray red light from extra reflections, but so be it.

Its possible that we are now clipping the IPANG path, but we will need to lock the Y arm and verify the input pointing to be sure. At this point we are ready to measure the ETMY OL loop gain and tune, etc.

  8673   Tue Jun 4 20:19:07 2013 ranaConfigurationIOOChanged threshold for FSS SLOW loop

The FSS SLOW actuator often runs off away from zero and into a region where the mode hopping is bad and makes a lot of frequency noise (e.g. that 8 hour period a few weeks ago when Jamie couldn't lock the MC).

It should not have this behavior. The SLOW loop should only be running when the MC is locked.

Today I found that the threshold was set back to 0.2 V (which is approximately the correct value for the RefCav locking). Its being compared to the MC TRANS, so the correct value should be ~1/2 of the maximum MC TRANS.

To find this out, I read this piece of text:

    # Make sure the loop is supposed to be active
    if (get_value("C1:IOO-MC_TRANS_SUM") < get_value("C1:PSL-FSS_LOCKEDLEVEL")) {
    print("Reference Cavity not locked -- control loop disabled.\n");
    next;
    }

from scripts/PSL/FSS/FSSSlowServo. I set the threshold using the commmand:

caput -c -t C1:PSL-FSS_LOCKEDLEVEL 12000

Then I restarted the code on op340m, by typing:

> nohup FSSSlowServo

and then closing the terminal. Seems to be behaving correctly now. Previously, the value was so low that the SLOW loop was never turning itself off.

  8677   Wed Jun 5 14:01:37 2013 ranaUpdateLSCC1:ALS-TRY_OUT filter and green progress

The rejected beam from this Faraday comes out at a tiny, tiny angle and so its tough to pick it off without clipping the main beam.

Some care must be taken in setting this up - Steve may have some good ideas on what kind of mount can be placed so close to the beam.

Why did we ever order this terrible Faraday? Let's never get a Faraday with a tiny angle between the beams again.

  8683   Wed Jun 5 17:37:10 2013 ranaUpdateGeneralfast 2004 qpd

Quote:

Thank you Ben Abbott forwarding this information:

 QPD Amplifier D990272 https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Number&docid=D990272&version= at the X-end.  It plugs into a Generic QPD Interface, D990692, https://dcc.ligo.org/cgi-bin/private/DocDB/ShowDocument?.submit=Number&docid=D990692&version= according to my drawings, that should be in 1x4-2-2A.

 Wrong: this is not an interface.

  8706   Fri Jun 14 02:38:07 2013 ranaUpdateLSCNew modeled sensing matrix

 This is nice - how about figuring out how to plot the measurement and model on the same plot? I guess we need to figure out how to go from counts to Watts.

  8724   Wed Jun 19 15:07:20 2013 ranaUpdateIOOWFS debugging

Trying to figure out what's wrong with the MC WFS:

1) The symptom seems to be that the control signals become very large in the pitch and then the loop breaks when they saturate. Usually this is due to a degenerate matrix or improper inversion. Most likely some of the BURT restore is bad or the analog gain for one of the WFS has been switched when Jamie was doing the "Guardian" debugging.

2) In checking this out, I found that several buttons on the WFS  screens were not working (and apparently have never been working). Please try to test things in the future...The filter bank buttons in C1IOO_MC_TRANS_QPD were using relative path names; fixed these to use abs path names. The buttons in the WFS_MASTER for the IOO_PIT banks were using IOO_PITCH instead...

2.5) Recentered beams on WFS heads with MC alignment good and MC unlocked.

3) Main problem in the WFS still not found - disabling this in the autolocker.

  8733   Thu Jun 20 15:15:39 2013 ranaUpdateIOOWFS debugging

Tried a bunch of stuff, but eventually just turned off the TRANS_QPD loops and loops are stable. Needs more debugging.

  1. Modified the on/off scripts so that the Integrators are no longer toggled. No reason to turn them off since we are clearing the filter bank histories.
  2. With QPD feedback OFF, I have lowered the overall gain by 15x so that its just drift control.
  3. Deleted unused / bad filters from the main filter banks.
  4. Gautam is going to debug the QPD with a red laser pointer and then elog.
  5. Jamie is checking out the MC Coil dewhitening logic to see if that's in a funny state.
  8747   Tue Jun 25 22:50:12 2013 ranaUpdateSUSSUS Screens generation problems?

Untitled.png

From the ALS overview screen, opening up the ETMX and ETMY screens gives these white fields. The PV info indicates that the blank fields were made with some macro variable substitution that didn't work well.

Why are these different from the SUS screens I get from the sitemap?

  8750   Tue Jun 25 23:57:30 2013 ranaUpdateSUSNDS2 Status

I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

  8752   Wed Jun 26 01:30:31 2013 ranaSummaryPEMVariation in 10-30 Hz seismic RMS

For quite a while (no one knows how long), we've seen fluctuations in the 10-30 Hz seismic motion. This shows up as the purple trace on the seismic BLRMS on the wall projector.

The second plot shows that this is not only a periodic increase in the usual 29.5 Hz HVAC peak, but also an anomolous 32.2 Hz peak. Probably some malfunctioning machinery - maybe in the 40m or maybe on the roof.

  8761   Thu Jun 27 02:44:33 2013 ranaUpdateGreen Lockingc1als model edited

 Could be that this is OK, but it doesn't yet make sense to me. Can you please explain in words how this manages to apply the calibration rather than just add an extra gain to the phase tracking loop?

  8762   Thu Jun 27 05:44:51 2013 ranaUpdate 40MARS wireless network problems

Quote:

I'm not sure what's going on today but we're seeing ~80% packet loss on the 40MARS wireless network.  This is obviously causing big problems for all of our wirelessly connected machines.  The wired network seems to be fine.

I've tried power cycling the wireless router but it didn't seem to help.  Not sure what's going on, or how it got this way.  Investigating...

 I'm still seeing some problems with this - some laptops are losing and not recovering any connection. What's to be done next? New router?

  8773   Thu Jun 27 21:45:48 2013 ranaUpdatePEMBLRMS are going crazy

Its an increase in the microseismic peak. Don't know what its due to though.

  8774   Thu Jun 27 21:59:42 2013 ranaUpdateComputer Scripts / ProgramsMatlab upgraded

I moved the old matlab directory from /cvs/cds/caltech/apps/linux64/matlab_o to /cvs/cds/caltech/apps/linux64/matlab_oo

and moved the previously current matlab dir from /cvs/cds/caltech/apps/linux64/matlab to /cvs/cds/caltech/apps/linux64/matlab_o.

And have installed the new Matlab 2013a into /cvs/cds/caltech/apps/linux64/matlab.

Since I'm not sure how well the new Matlab/Simulink plays with the CDS RCG, I've left the old one and we can easily revert by renaming directories.

  8775   Thu Jun 27 22:05:25 2013 ranaUpdateGeneralPianosa fixed

The keyboard on Pianosa workstation has been flaky for the last several days at least. Today, it was having troubles mounting the linux1 file system and was hanging on boot.

People in the control room emailed Jamie and then grew afraid of the computer. Annalisa suggested that we put garlic on it since was clearly possessed.

Typing 'dmesg' at the command prompt, I found that there were thousands of messages like these:

[ 3148.181956] usb 2-1.2: new high speed USB device number 68 using ehci_hcd
[ 3149.773883] usb 2-1.2: USB disconnect, device number 68
[ 3150.228900] usb 2-1.2: new high speed USB device number 69 using ehci_hcd
[ 3152.076544] usb 2-1.2: USB disconnect, device number 69
[ 3152.787391] usb 2-1.2: new high speed USB device number 70 using ehci_hcd
[ 3154.123331] usb 2-1.2: USB disconnect, device number 70
[ 3154.578459] usb 2-1.2: new high speed USB device number 71 using ehci_hcd

So I replaced the existing Dell keyboard with an older Dell keyboard and the bad messages have stopped. No garlic was used.

  8802   Thu Jul 4 17:14:53 2013 ranaUpdateSUSNew SUS screen

 Now that the 3f locking looks so cool for the PRMI, I suppose that the PRMI + arm stuff will be very successful.

At LLO, I've just noticed the screens that they have for the single pendulums / TTs. I'm attaching a screenshot of the one Zach is using for the steering into the OMC. We should grab these and replace our existing SUS screens with them.

  8861   Tue Jul 16 19:16:12 2013 ranaUpdateDAQNDS2 Status

I have modified the settings on the router that connects our Martian network to the outside world so that one can access the NDS2 server running on megatron:31200.

To get at the data you point your data getting client (Matlab, ligoDV, DTT, etc.) at our router and the megatron port will be forwarded to you:

131.215.115.189:31200

is what you should point to. Now, it should be possible to run DetChar jobs (e.g. our 40m Summary pages) from the outside on some remote server. You can also grab 40m data on your laptop directly by using matlab or python NDS software.

  8887   Mon Jul 22 03:10:41 2013 ranaSummaryloreAngel of the Y End Table?

 Trying to take an image or movie of the ETMY Transmon cam, we got instead this attached image.

I think it is just some scattered green light, but others in the control room think that it is a message from somewhere or someone...

  8917   Wed Jul 24 14:26:24 2013 ranaUpdateIOOFound the cause of mysterious MC motion

Yes, this was not ELOG'd by me, unfortunately. This was the MC tickler which I described to some people in the control room when I turned it on.

As Koji points out, with the MCL path turned off this injects frequency noise and pointing fluctuations into the MC. With the MCL path back on it would have very small effect. After the pumpdown we can turn it back on and have it disabled after lock is acquired. Unfortunately, our LOCKIN modules don't have a ramp available for the excitation and so this will produce some transients (or perhaps we can ezcastep it for now). Eventually, we will modify this CDS part so that we can ramp the sine wave.

  8925   Thu Jul 25 14:45:06 2013 ranaUpdatePEMGuralp specgram with ligoDV and NDS2

 Once you install a matlab newer than 2012a, you can install ligoDV as a matlab app and get the NDS2 client software for free. So you can easily get the 40m data from the outside world now and do the analysis on your own computer rather than login through nodus.

  8994   Mon Aug 12 10:44:22 2013 ranaUpdateLSCPRMI(sb) lock recovered

  In the past, we used to use Stefan's 'ezcademod' or Matt's 'ezlockin' to do auto phase adjustment.

JoeB / Jamie are working on python replacements for these tools, but in the near term possibly I can make a bash script to use ezcaservo and the existing LOCKINs to do this.

  9020   Fri Aug 16 21:15:04 2013 ranaUpdateCDSNew/old CDS laptop for X-End

I took the "aso-laptop" and made it into Ubuntu a couple months ago. Today I added it to the Martian network and then moved it to the X End.

I followed the instructions in (https://wiki-40m.ligo.caltech.edu/Network) and added it to the files in /var/named/chroot/var/named on linux1 and did the "service named restart".

The router already had his MAC address in its list (because Yoichi was illegally using his personal laptop on the Martian). The new laptop's name is 'asia'. This is a legal name according to our computer naming conventions and this Wikipedia page (http://en.wiktionary.org/wiki/Category:Italian_female_given_names). It has been added to the Name Pool on the wiki.

The terminal on the laptop still calls itself 'aso-laptop' so I need some help in fixing that. It successfully connects to 40MARS and displays a MEDM sitemap after sshing in to pianosa.

I use 'ssh -X -C' since I find that compression actually helps when the laptops are so far from the router.

  9021   Sun Aug 18 16:04:07 2013 ranaSummaryCDSFB lights all RED: mxstream restart

Sun Aug 18 15:52:50 2013

Found the FB lights (C1:FEC-NN_FB_NET_STATUS and C1:DAQ-DC0_C1XXX_STATUS) RED for everything on the CDS_FE_STATUS screen.

I used the (! mxstream restart) button ro restart the mxstreams. Everything is green now.

PMC was out of lock- relocked it and the IMC locked itself as did the X & Y arms on IR. X was already green locked.

  9022   Sun Aug 18 17:56:16 2013 ranaSummaryCDSMEDM Screen CPU Usages

I noticed at LLO (?) that the LSC screen there uses up ~25-30% of the CPU time on a single core for the control room iMac workstations - this seems excessive.

Here is an accounting of CPU usage percentages for some of our screens:

 

Screen Name CPU (%)
LSC_OVERVIEW 7
ALS_OVERVIEW 0
ALS 1
SUS_SUMMARY 0
IOO_WFS_MASTER 0.3
OPLEV_MASTER 0.5

These were measured using the program 'glances' on rosalba. MEDM running with only the sitemap used up 0.9% of a CPU. With the screens running, the fluctuation from sample to sample could be ~ +/- 0.5%. While the LSC screen seems to be the biggest pig, it is only big in comparison to small pigs. Certainly this pig has gotten bigger after getting sent to Louisiana.

  9023   Sun Aug 18 20:07:41 2013 ranaUpdateComputer Scripts / Programsuserapps SVN up

JoeB and JamieR are working somewhat coherently on a set of python libraries to fulfill all of our command line CDS wants. This is being done mostly to satisfy The Guardian and the SkunkTools project.

I did an 'svn up' in /opt/rtcds/userapps (it might finish in ~1000 years) to get the things that they have so far (in particular, Joe's 'pyavg'). There's going to be some issues since the pylib stuff written by Yuta/Kiwamu has never been integrated with anything and is imported as 'epics' in many python scripts. As we move over to the new stuff there will be a lot of broken script functions since the new libraries are also used in that way.

  9031   Mon Aug 19 14:22:36 2013 ranaUpdateGreen LockingXend green aligned

  9037   Tue Aug 20 00:19:23 2013 ranaUpdateLSCPRMI / DRMI investigations

While Jenne was plotting, I locked and aligned the MICH with AS55_Q. Then I aligned the PRM and locked PRMI using REFL55_I/Q with triggering on POP22, but no power normalization.

I used this to set the phase for REFL11 and REFL55 (driving PRM at 111.3 Hz and minimizing the Q response using the DTT Sine Response tool). I flipped the sign on REFL11 by 

The REFL11 gain is ~50x larger than REFL55; this is with the 15 dB whitening gain on REFL55 and none for REFL11. What's going on here? The attached PDF shows the two time series with the free swinging PRMI and both phases set to ~ +/- 2 deg. The REFL55 signals have been scaled up by 50x.

So then we went in and looked at the RF signals at the demod boards. To do this we disconnected the RFPD test cables and hooked the RF Mon outputs into the 50 Ohm inputs on a scope. The following PNG images show the scope traces. The REFL11 (yellow) traces are too big!! See how small the REFL55 (green) are. REFL11 is saturating - need to fix.

TEK00000.PNGTEK00001.PNG

TEK00002.PNGTEK00003.PNG

  9042   Tue Aug 20 16:23:41 2013 ranaSummaryGeneral/home/cds nearly full

/home/cds is >98% full - below are some of the usage numbers:

controls@rosalba:/users/OLD 0$ du -h --max-depth=1
42M    ./katrin
1.5M    ./ben
2.4M    ./sanjit
569M    ./waldman
328M    ./sonia
3.6G    ./lsinger
44M    ./dbusby
105M    ./dbarron
21M    ./manuel
709M    ./yaakov
46M    ./rodionov
240M    ./ishwita
2.7G    ./clara
56M    ./gopal
290M    ./mashaB
87M    ./varvella
5.6M    ./Sascha
2.9G    ./ryan
190M    ./nancy
3.5G    ./john
269M    ./elizabeth.davison
165M    ./jweiner
460K    ./mjones
49M    ./stephanie
52M    ./mohana
56M    ./noriyasu
38M    ./mjenson
76M    ./sballmer
224M    ./kirk
812K    ./bonnie
33M    ./janosch
16M    ./kevin
122M    ./dblair
2.6G    ./mirko
389M    ./keenan
195M    ./tf
150M    ./littlezach
193M    ./jmiller
1.8G    ./ting
131M    ./dmalling
842M    ./sharmila
1.4G    ./caryn
12G    ./rward
4.1M    ./jay
443M    ./emintun
184M    ./katharine
76K    ./nick
804K    ./nicole.ing
14M    ./jenny
542M    ./vsanni
45M    ./peter
7.8G    ./miyakawa
4.8M    ./channa
4.0K    ./frank
9.9G    ./razib
35M    ./amin
361M    ./sharon
62M    ./bram
3.9M    ./volodya
7.9M    ./larisa
301M    ./sasha
33M    ./eric.hendries
18M    ./vuk
101M    ./huan
1.8M    ./sonali
453M    ./megan
43M    ./Royal
5.4G    ./ayaka
19M    ./mott
518M    ./justing
501M    ./avi
173M    ./kakeru
3.9G    ./alberto
41M    ./paul.fulda
59M    ./elena
67G    .

controls@rosalba:/opt/rtcds/userapps 0$ du -h --max-depth=1
1.4G    ./tags
13M    ./trunk.bak
40K    ./.svn
3.0G    ./trunk
174M    ./trunk.bak2
4.2G    ./branches
8.7G    .

linux1:cds>nice du -h --max-depth=1
du: `./llo/chans/daq/archive': Permission denied
du: `./llo/chans/daq/old': Permission denied
707M    ./llo
9.7M    ./mit~
752K    ./raidwebFirmware
462M    ./epics
2.1G    ./tmp
1.5G    ./gds
76M    ./project
9.1G    ./ligo
449G    ./rtcds
3.3G    ./apps
20K    ./.kde
512K    ./cdscfg
1.4M    ./.Trash-controls
5.8M    ./scripts
20K    ./.TemporaryItems
964G    ./caltech
71M    ./bin
16K    ./.Trash-1001
4.5G    ./rtapps
564M    ./src
11M    ./vw
3.8M    ./dvSave
460M    ./lho
1.2G    ./data
1.5T    .

  9045   Wed Aug 21 17:42:03 2013 ranaSummaryGeneral/home/cds nearly full

One of the reasons that our disk is getting full is due to the scripts_archive directory. A backup script runs on op340m and makes a tar.bz2 file of the scripts directory and puts it in scripts_archive every morning at 6 AM.

On Oct 7, 2011, Koji fixed this script to point at our new scripts directory instead of the old /cvs/cds/caltech/scripts directory. Since then, however, no one has fixed the exclude file to NOT back up the junk that's in that directory. Its a 1.6 GB directory so its full of it.

I've deleted a bunch of junk from the scripts directory: this directory is for scripts, not for your personal home movies or junk data files. Put those in your USER directory. Put temporary data files in /tmp/. I've also added a few more patterns to the exclude file so that less .mpg, .png, .pdf, .dat, etc get stored every day. The new daily .tar.bz2 file wil be ~25 MB instead of 770 MB.

(also fixed the backup script to use 'env' to setup the perl environment and removed the hard-coded path to tar)

  9046   Wed Aug 21 19:26:19 2013 ranaUpdateIOOFound the cause of mysterious MC motion

Quote:

Yes, this was not ELOG'd by me, unfortunately. This was the MC tickler which I described to some people in the control room when I turned it on.

As Koji points out, with the MCL path turned off this injects frequency noise and pointing fluctuations into the MC. With the MCL path back on it would have very small effect. After the pumpdown we can turn it back on and have it disabled after lock is acquired. Unfortunately, our LOCKIN modules don't have a ramp available for the excitation and so this will produce some transients (or perhaps we can ezcastep it for now). Eventually, we will modify this CDS part so that we can ramp the sine wave.

 I've written a new TICKLE script using the newly found 'cavget' and 'cavput' programs. They are in the standard epics distribution as extension binaries. They allow multichannel read/write as well as ramping, delays, incremental steps, etc. http://www.aps.anl.gov/epics/tech-talk/2012/msg01465.php.

Running from the command line, they seem to work fine, but I've left it OFF for now. I'll switch it into the MC autolocker at some point soon.

  9056   Thu Aug 22 22:05:36 2013 ranaUpdateGreen LockingGTRY normalized

Meh. 600 counts is too weak.  You should fix the electronics so that the maximized green laser transmission gives more like ~10000 counts.

  9058   Fri Aug 23 14:19:28 2013 ranaUpdateSUSViolin filters moved to LSC, from SUS

  Just to rephrase somewhat:

  • We balance the BS & PRM actuators in the LSC Output matrix so that there is no MICH signal going into REFL_I @ 100 Hz.
  • REFL Phase is adjusted by driving PRM and minimizing Q/I to within ~1 deg (Q/I ratio of ~2%)
  • The REFL_I sensing matrix element is ~50x bigger than REFL_Q (in W/m)
  • When we turn ON the violin mode notch in the BS SUS, it changes the MICH drive into a purely PRCL drive at that frequency !!!
  • So, putting notches into the SUS screens is bad since it imbalances the drives.
  9061   Sun Aug 25 06:07:11 2013 ranaUpdateLSCDRMI Locked with improved lock streatches

 We're ready for using the auto configure.

We can put our scripts for the MICH, PRMI, and DRMI into the IFO CONFIGURE screens for now and then it should be easy to get them into the Guardian once Jamie has the bugs worked out.

This screen can also be used to setup and start the dither alignment for each configuration (once we have one working for DRMI / SRM).

Also, now that the notches/bandstop filters for the violin modes have been move from the SUS into the LSC, we should fix the triggering to engage them a few seconds after the boosts.

  9067   Mon Aug 26 20:13:17 2013 ranaConfigurationElectronicsputting together a 110 MHz LSC demod board for AS

Quote:

I have modified one of the spare demod boards that was sitting above the electronics bench (the one which was unlabeled - the others say 33MHz, 55MHz and 165MHz) to be the new AS110 demod board.  In place of the T1 coil, and the C3 and C6 resistors, I have put the commercial splitter PSCQ-2-120+.  In place of U5 (the low pass for the PD input) I have put an SCLF-135+.

OK, but what kind of filter should we be actually using? i.e. what purpose the 135 MHz low pass serve in contrast to a PHP-100+ ?

  9093   Mon Sep 2 03:51:14 2013 ranaHowToGeneralHow To Coil Cables

 http://youtu.be/pEd7ru24Vx0

  9104   Wed Sep 4 20:39:23 2013 ranaUpdateSUSMC2 tickler turned OFF

Quote:

 [Jenne, Manasa]

While we were trying to relock the MC after Jenne put back the RF box, we found there was some mysterious motion in MC2. After spending time trying to figure out where this was coming from, the source was found to be at LOCKIN2 of MC2 suspension "The MC TICKLERthat was left enabled. This was turned OFF and MC locked just fine after that.

 

EDIT JCD:  The Tickler should be disabled, if the autolocker is disabled.

 Sounds like this was just incidental, since the MC locked fine also with the tickler enabled for weeks.

The tickle is disabled by the down script, but there's no way to correctly handle all possible button pushes. If you want to disable the autolocker for some reason you should run mcdown before trying to lock. This will set up things with the correct settings.

  9108   Thu Sep 5 00:40:33 2013 ranaUpdateSUSMC2 tickler turned OFF

 

 You're right - down turns it on. Still, the fact that the same tickle recently causes a problem and didn't make 20% power fluctuations until now tells me that its not that the tickle amplitude is too large. Whatever changed recently is the problem.

  9131   Mon Sep 16 14:11:47 2013 ranaUpdateLSCMICH calbration

  There doesn't seem to be any coherence among the different directions of ground motion (as expected from seismic theory), so I am suspicious of such a low MICH noise.

  9133   Mon Sep 16 19:41:01 2013 ranaConfigurationComputer Scripts / Programscdsutils checked out into /opt/rtcds
 controls@rosalba:~ 0$ cdsutils
Traceback (most recent call last):
  File "/ligo/apps/cdsutils/lib/cdsutils/__main__.py", line 7, in <module>
    from cdsutils import CMDS
  File "/ligo/apps/cdsutils/lib/cdsutils/__init__.py", line 4, in <module>
    from servo import servo
  File "/ligo/apps/cdsutils/lib/cdsutils/servo.py", line 1, in <module>
    from epics import PV
ImportError: No module named epics
controls@rosalba:~ 1$
Mon Sep 16 19:40:32 2013 
  9141   Thu Sep 19 18:48:24 2013 ranaUpdateComputer Scripts / ProgramsPMC locker

 In May of 2013 Den wrote a PMC Autolocker because he ignored / didn't want to read anyone else's code. Later that year Yuta also wrote another one from scratch for the same reasons.

I tried to use both today, but neither one runs. Yuta's one doesn't run because he was using a bunch of private yuta library stuff in the yuta directory. That kind of programming style is pretty useless for us since it never works after some time.

So I re-activated and tested the PMCAutolock bash script (it is actually a symbolic link called "PMCAutolock" which points to AutoLock.sh). These scripts are all basically the same:

They turn off the loop (or turn down the gain) and then scan the PZT, look for a resonance, and then activate the loop.

One problem with the logic has been that turning off the loop makes the gain so low that the peak flashes by too fast. But leaving the loop ON and just sweeping with the gain turned down to -10 dB is also not good. That only reduces the UGF from 1 kHz to ~100 Hz. What we want is more like a 10 Hz UGF while scanning the length. SO, I edited the script to turn down the modulation depth on the EOM by that factor. After acquiring lock, it returns all settings to the nominal levels as defined on the PSL_SETTINGS screen.

I've tested it a few times and it seems to work OK. You can run it from the yellow shabang button on the PMC screen.

I also changed the .bashrc aliases for the MEDM command so that if you type medm_good at the command line you get MEDM screens with scalable fonts. So you can stretch the screens.

  9142   Thu Sep 19 21:15:44 2013 ranaUpdateComputer Scripts / ProgramsPMC locker

I used a script (~PSL/PMC/testAutoLocker.sh) to unlock the PMC and run autlocker ~100 times to see how robust the new autlocker is.

It failed to grab it 2 out of 137 times. During those times it just went on trying to ramp the PZT even after it had gone to a rail. Once someone resurrects Rob's 'trianglewave'  script we should be OK. Even so, I think this is good enough. Please try this out via the yellow button next time the PMC needs to be locked.

It usually takes 10-30 seconds to lock, depending upon where the fringe is compared to the upper voltage rail. Good enough.

  9143   Thu Sep 19 21:42:18 2013 ranaUpdateSUSOptical Lever Trend for 90 days: ETMX and PRM are the bad ones
  9147   Fri Sep 20 20:14:52 2013 ranaSummaryGeneral/home/cds nearly full

Quote:

One of the reasons that our disk is getting full is due to the scripts_archive directory. A backup script runs on op340m and makes a tar.bz2 file of the scripts directory and puts it in scripts_archive every morning at 6 AM.

On Oct 7, 2011, Koji fixed this script to point at our new scripts directory instead of the old /cvs/cds/caltech/scripts directory. Since then, however, no one has fixed the exclude file to NOT back up the junk that's in that directory. Its a 1.6 GB directory so its full of it.

I've deleted a bunch of junk from the scripts directory: this directory is for scripts, not for your personal home movies or junk data files. Put those in your USER directory. Put temporary data files in /tmp/. I've also added a few more patterns to the exclude file so that less .mpg, .png, .pdf, .dat, etc get stored every day. The new daily .tar.bz2 file wil be ~25 MB instead of 770 MB.

(also fixed the backup script to use 'env' to setup the perl environment and removed the hard-coded path to tar)

 OUr disk was getting full again. Turned out my "fix" to 25 MB was only a fix to 250 MB. Since we were getting disk full warnings on our Ubuntu workstations, I deleted some COMSOL.dmg files from users/zach/ and then started deleting every other tarball from the scripts_archive directory. ~221 GB are now free. Still need to fix the exclude file for scripts better.

  9148   Fri Sep 20 20:27:18 2013 ranaUpdateIOOmode cleaner not locking

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

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

  9150   Sun Sep 22 21:03:15 2013 ranaConfigurationSUSTuned bounce and roll mode of ETMY suspension

 Today I noticed that there was a lot of noise at the Bounce and Roll eigenfrequencies for ETMY. I found that the bandstop filter were set at completely the wrong frequencies, so I've remade them.

The filters were last tuned by Leo in May of 2011. Even so, he left the frequencies at the frequencies of the old MOS suspensions which had f_bounce ~ 12 Hz.

 The FOTON plot shows the OLD ones versus the NEW ones. The DTT spectra shows the oplev error signals in the usual state. I have also copied these over to the SUSPOS,PIT,YAW, and SIDE filter banks and turned them all ON.

I also turned OFF and deleted the 3 Hz RG filter that was there. There's no such peak in the error signal and even if one wanted to compensate for the stack mode, it should be a low Q filter, not this monster.

  9151   Sun Sep 22 21:28:53 2013 ranaUpdateSUSset OL T RAMP values (they are not visible on the OL screens)

controls@rosalba:/opt/rtcds/caltech/c1/scripts/SUS 0$ ./setOLtramps
Old : C1:SUS-ETMX_OLPIT_TRAMP        0
New : C1:SUS-ETMX_OLPIT_TRAMP        2
Old : C1:SUS-ETMX_OLYAW_TRAMP        0
New : C1:SUS-ETMX_OLYAW_TRAMP        2
Old : C1:SUS-ETMY_OLPIT_TRAMP        2
New : C1:SUS-ETMY_OLPIT_TRAMP        2
Old : C1:SUS-ETMY_OLYAW_TRAMP        2
New : C1:SUS-ETMY_OLYAW_TRAMP        2
Old : C1:SUS-ITMX_OLPIT_TRAMP        0
New : C1:SUS-ITMX_OLPIT_TRAMP        2
Old : C1:SUS-ITMX_OLYAW_TRAMP        0
New : C1:SUS-ITMX_OLYAW_TRAMP        2
Old : C1:SUS-ITMY_OLPIT_TRAMP        0
New : C1:SUS-ITMY_OLPIT_TRAMP        2
Old : C1:SUS-ITMY_OLYAW_TRAMP        0
New : C1:SUS-ITMY_OLYAW_TRAMP        2
Old : C1:SUS-BS_OLPIT_TRAMP          0
New : C1:SUS-BS_OLPIT_TRAMP          2
Old : C1:SUS-BS_OLYAW_TRAMP          0
New : C1:SUS-BS_OLYAW_TRAMP          2
Old : C1:SUS-PRM_OLPIT_TRAMP         0
New : C1:SUS-PRM_OLPIT_TRAMP         2
Old : C1:SUS-PRM_OLYAW_TRAMP         0
New : C1:SUS-PRM_OLYAW_TRAMP         2
Old : C1:SUS-SRM_OLPIT_TRAMP         0
New : C1:SUS-SRM_OLPIT_TRAMP         2
Old : C1:SUS-SRM_OLYAW_TRAMP         0
New : C1:SUS-SRM_OLYAW_TRAMP         2
 
Done setting TRAMPs

ELOG V3.1.3-