| ID |
Date |
Author |
Type |
Category |
Subject |
|
372
|
Wed Mar 12 23:05:44 2008 |
rana | Update | IOO | MC WFS |
they are bad, somewhat
please fix |
|
375
|
Thu Mar 13 12:11:58 2008 |
aivanov | Update | Computer Scripts / Programs | routing PEM -> ASS -> SUS_MCL |
on ASS RFM 1 has PEM signals at
float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.
ASS sends to RFM 0
float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL |
|
376
|
Thu Mar 13 13:15:09 2008 |
aivanov | Update | Computer Scripts / Programs | new sfotware intall, backup files |
New:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o
-rw-r--r-- 1 controls staff 57920 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme2/losLinux2.o
-rw-r--r-- 1 controls staff 57976 2008-03-13 13:11 /cvs/cds/caltech/target/c1susvme1/losLinux1.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscey/losEtmy.o
-rw-r--r-- 1 controls staff 246861 2008-03-13 13:12 /cvs/cds/caltech/target/c1iscex/losEtmx.o
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o
-rw-r--r-- 1 controls staff 63547 2008-03-12 14:57 /cvs/cds/caltech/target/c0dcu1/dcuDma.o
Backups:
op440m:40m>ls -alt /cvs/cds/caltech/target/c1susvme[12]/*.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme2/losLinux2.o.13mar08
-rw-r--r-- 1 controls staff 55960 2005-06-21 13:30 /cvs/cds/caltech/target/c1susvme1/losLinux1.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c1isce[xy]/*.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscex/losEtmx.o.13mar08
-rw-r--r-- 1 controls staff 229793 2007-03-08 11:09 /cvs/cds/caltech/target/c1iscey/losEtmy.o.13mar08
op440m:40m>ls -alt /cvs/cds/caltech/target/c0dcu1/*.o.12mar08
-rw-r--r-- 1 controls staff 60810 2004-09-08 08:47 /cvs/cds/caltech/target/c0dcu1/dcuDma.o.12mar08 |
|
377
|
Thu Mar 13 18:20:29 2008 |
John | Update | General | New Focus 4003 EOM 29.489MHz |
I measured the modulation index as a function of drive power using an OSA. Agrees well with spec of 0.2 rad/V.
 |
|
380
|
Fri Mar 14 15:06:24 2008 |
rob | Update | Computer Scripts / Programs | routing PEM -> ASS -> SUS_MCL |
| Quote: |
on ASS RFM 1 has PEM signals at
float at 0x100000 has c0dcu1 first ICS110B chan 1
float at 0x100004 has chan 2
etc.
ASS sends to RFM 0
float at 0x100000 goes to PRM MCL
0x100004 to BS MCL
0x100008 to IMTX MCL
0x10000c to ITMY MCL
0x100010 to SRM MCL
0x100018 to MC1 MCL
0x10001c to MC3 MCL
0x100020 to ETMX MCL
0x100024 to ETMY MCL |
You can differentiate between RFM 0 and RFM 1 in the simulink model by adding 0x4000000 to the offsets for RFM 1. |
|
385
|
Thu Mar 20 15:28:20 2008 |
steve | Update | VAC | tp2 's drypump replaced |
| The fore pump of tp2 was replaced at fore line pressure 998m Torr |
|
388
|
Fri Mar 21 09:02:03 2008 |
steve | Update | VAC | tp 2 failed |
Small turbo #2 is the forepump of the maglev.
It failed last night, shut down the maglev and interlock closed V1
Ifo pressure is 20 mTorr now. The Yarm was still locked at 8am this morning.
The PSL beam to MC was blocked just before the output periscope.
The psl mechanial shutter did not work from epic screen. |
|
389
|
Fri Mar 21 11:54:38 2008 |
rob | Update | VAC | tp 2 failed |
| Quote: | Small turbo #2 is the forepump of the maglev.
It failed last night, shut down the maglev and interlock closed V1
Ifo pressure is 20 mTorr now. The Yarm was still locked at 8am this morning.
The PSL beam to MC was blocked just before the output periscope.
The psl mechanial shutter did not work from epic screen. |
The PSL mechanical shutter actually did trip last night, greatly confusing me and Rana. Not realizing that the software vacuum interlock had tripped, we manually re-opened the shutter. I'll modify the relevant MEDM screens to indicate when the EPICS interlock trips. |
|
396
|
Sun Mar 23 00:56:42 2008 |
John | Update | LSC | More on 3f |
We ended our last attempt at 3f locking concerned about the beam size on PD6. I investigated tonight. The beam was not obviously overfilling the diode and a quick tweak of the steering mirror revealed a decent plateaux. Nevertheless we decided to try a different approach to see if we found the same problems as before on a different diode.
This time our 3f diode was Refl 33. I put a splitter on the output of the diode at the LSC rack sending one half into the usual refl 33 board, the other into refl DD 199 (which is demodulating at 99Mhz).
I got as far as handing off PRC to the 3f signal in lock. More work needed. |
|
398
|
Mon Mar 24 13:03:54 2008 |
rob | Update | Electronics | HP4195A is back |
| Quote: | | The swept sine output looks totally normal from 500Mhz to 150MHz (measuring ~220mVrms below 300MHz -- 0dBm), where it abruptly transitions to a distorted waveform which the scope measures as having a frequency of ~25MHz and with 450mVrms (+6dBm). It then transitions again at some other part of the sweep to a cleaner-looking 25MHz waveform with ~1.2Vrms (+15dBm). |
The HP4195A is back from repair. At first, it exhibited exactly the same behaviour for which it was sent in for repair, and which is described above (pillage from entry 337). After speaking with the repair tech on the phone, who tried to imply that the digital scope was tricking us, I plugged the output into our HP8591E spectrum analyzer, just to have firm ammunition to combat the repair guy's looniness. This led to even weirder behaviour, like no output and overload signals on the inputs (with nothing connected). After turning the unit on and off several times, and firmly seating (and screwing in) the DB9 connectors in the back of the unit, it appears to be working properly. Except for a brief glitch as it passes through 150MHz, the swept sine signal now appears normal, both on the scope and in the spectrum analyzer.
Apparently the whole thing is due to a loose connection somewhere in the box, which wasn't actually fixed by the repair, but has at least been temporarily fixed by me stumbling around with a screwdriver and then pushing the power button a couple of times. |
|
400
|
Tue Mar 25 10:44:24 2008 |
rob | Update | Computers | c1susvme2 |
| Quote: | c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.
After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.
We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look. |
I rebooted it again this morning. The ASS machine is currently not running its process, for whatever reason (someone turn it off?). Let's leave it like this for a day and see how the c1susvme2 does. The other recent change is Steve's install of a cooling fan--maybe that's causing the problem. |
|
401
|
Tue Mar 25 13:21:25 2008 |
Andrey | Update | Computers | c1susvme2 is not behaving itself again |
|
|
402
|
Tue Mar 25 15:56:09 2008 |
John | Update | Treasure | Assorted pictures |
| Some pictures scavenged from the D40. |
| Attachment 1: D40.pdf
|
|
|
403
|
Tue Mar 25 16:34:47 2008 |
rob | Update | Computers | c1susvme2 |
| Quote: |
| Quote: | c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.
After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.
We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look. |
I rebooted it again this morning. The ASS machine is currently not running its process, for whatever reason (someone turn it off?). Let's leave it like this for a day and see how the c1susvme2 does. The other recent change is Steve's install of a cooling fan--maybe that's causing the problem. |
Now c1susvme1 is joining the action. Since leaving the ASS off doesn't change anything, we can probably absolve it of blame. I now suspect the 4-pin LEMO cables going from the CLK DRIVER modules to the clock fanout modules. These cables are being squeezed/shaken by Steve's new fan setup, and may have been the culprit all along. John will do some testing to see if they are indeed the problem. |
|
405
|
Wed Mar 26 22:26:15 2008 |
John | Update | Computers | c1susvme |
| I removed the fan and tweaked the timing cables to see if they were the source of our problems. I saw no effect. I'm leaving the fan off for the moment to see if that helps. It is on top of the filing cabinet next to my desk. |
|
406
|
Fri Mar 28 16:18:18 2008 |
rob | Update | Computers | c1susvme2 status |
| c1susvme2 is getting worse and worse. it won't run for more than ~45 minutes without fatally de-syncing. for now I've turned off c1iovme (which sends the MCL signal) to see if that's causing the problem. next I'll swap the boards for c1susvme1 and c1susvme2 to see if it's the cpu (or maybe the RFM card) itself, rather than the timing/pentek systems. |
|
408
|
Mon Mar 31 14:14:16 2008 |
rob | Update | Computers | c1susvme2 status |
| Quote: | | c1susvme2 is getting worse and worse. it won't run for more than ~45 minutes without fatally de-syncing. for now I've turned off c1iovme (which sends the MCL signal) to see if that's causing the problem. next I'll swap the boards for c1susvme1 and c1susvme2 to see if it's the cpu (or maybe the RFM card) itself, rather than the timing/pentek systems. |
I swapped the processors for c1susvme1 and c1susvme2. So for now, to startup, you should ssh into c1susvme1 and run the startup.cmd for c1susvme2, and vice versa. |
|
409
|
Wed Apr 2 15:03:51 2008 |
steve | Update | General | reflectivity of black glass |
The reflectivity of black glass, shade 12 was supplied by Donald O'Shea
of Emerald Glass Inc., Westlake, OH 44145
The reflectivity of this glass was measured as shown
Old 1064 nm Crysta Laser with poor beam quality was the source. |
| Attachment 1: bg12refl.pdf
|
|
| Attachment 2: bg12refsetup.pdf
|
|
|
416
|
Mon Apr 7 16:42:56 2008 |
rana | Update | Computers | eLog intermittent |
Phil Ehrens restarted Dziban again this morning. Looks like its still crashing each Monday around 8 AM.
Here is the latest suspect:
http://open.itworld.com/5040/reboot-unix-nlsunix-071225/page_1.html |
|
417
|
Mon Apr 7 18:58:49 2008 |
steve | Update | General | reflectivity of SS304 |
The reflectivity of stainless steel 304 super polished # 8 was measured the same way as elog entry 409
The reflectivity: 74 +- 1 % from incident angle 10 to 80 degrees |
| Attachment 1: ss304s8refl.pdf
|
|
|
421
|
Wed Apr 16 10:20:01 2008 |
Andrey | Update | Computers | Rosalba and linux3 |
| Quote: | There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.
Its a 64-bit Linux and so that may cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.
I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.
We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow. |
The ethernet cable for linux3 was installed on Wednesday morning. Now linux3 has Internet connection again. |
|
423
|
Thu Apr 17 15:00:59 2008 |
steve | Update | VAC | vac controller computer to be replaced |
Now that Rosalba is up and running someone should step forward to volunteer for this job.
Old desk top at the Vacuum Rack should be replaced by a functional less old computer so
the vacuum controller can count on an emergency situation. It's only has to be able to run medm
The existing one is dying. |
|
424
|
Thu Apr 17 20:17:37 2008 |
Andrey | Update | PEM | Two issues with our weather station |
I encountered two difficulties working with the "Weather Station".
(1) It turns out that there is no indication for "outside humidity" on the "weather monitor" (a small black box located on the north wall of the interferometer). I realized that "outside humidity" is absent in our system when I tried to see the Dataviewer trend and real-time value from the channel "C1: PEM-weather-outsideHumid". It shows impossible number 128%.
It follows from the "Davis" technical documentation that the outside sensor can be of two types: either "External Temperature Sensor" or "External Temperature/Humidity Sensor". I suspect (I do not know for sure) that we have the first type of sensor "external temperature only" and therefore we in principle cannot have information about outside humidity. I propose to Steve to climb to the roof on Friday to resolve this uncertainty looking at the sensor.
(2) I wanted to change the units of pressure from "Pascal" (force/area) to other units, "mbar" for example. For this purpose I need to edit the file "Weather.st" in the directory /cvs/cds/caltech/target/c1pem1 (this file is run on the VME processor "c1pem1"). Unfortunately, when I try to open the file with emacs, I get the message that the file exists but protected from modifications. I do not know how to unblock the file "Weather.st". I need some help with that.
I thought that switching-off the processor "c1pem1" could resolve the issue, so I switched-off the whole crate where the processor "c1pem1" is installed for about 5 minutes, turning the metallic key. As it did not make any difference for the accessibility of the file "Weather.st", I switched-on the crate after 5 minutes. There are other processors besides "c1pem1", so they were turned-off for several minutes earlier today.
Also, I created a new MEDM screen which has information about weather only, a smaller version of the "C0Checklist.adl" MEDM screen. Both screens are now located under the most top-left button "Checklist" of the main MEDM screen. |
|
425
|
Fri Apr 18 16:02:58 2008 |
alex | Update | SUS | end station sus front-end bug fix |
| installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables. |
|
426
|
Fri Apr 18 16:27:04 2008 |
rob | Update | SUS | end station sus front-end bug fix |
| Quote: | | installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables. |
But where is the code? |
|
427
|
Fri Apr 18 16:48:13 2008 |
Andrey | Update | PEM | Rain collector of weather station |
Today the rain collector of our weather station was cleaned. As a result, we checked that the rain indication on the weather monitor and on the MEDM screens is alive and working properly. I am adding some details about the roof sensors to the wiki-40 page about the weather station. See especially the link "More description of the roof sensors and their interaction with UNIX computers" from the main Weather Station page in wiki-40.
Pictures of the rain collector before (dirty, the opening is fully clogged with dust and dirt) and after (clean opening in the bottom of the bowl) the cleaning are attached. |
| Attachment 1: DSC_0520--before.JPG
|
|
| Attachment 2: DSC_0537--after.JPG
|
|
|
428
|
Fri Apr 18 19:46:08 2008 |
rana | Update | ASS | check adaptive |
I restarted the adaptive code today using 'startass' and 'upass'.
I moved them into the scripts/ASS/ subdirectory.
Things seem OK. With a MU=0.03 and a TAU=0.00001, there is a still
a good factor of 10 reduction of the 3 Hz stack peak from the MC2
drive by doing FF into MC1.
I edited the ASS-TOP screen so that we could see such small numbers. I
also re-aligned the MC SUS to match the input beam (mainly MC3). The
cavity was locking on a TEM10 mode mostly -- we should look in the SUS
OSEM trends to see if MC3 has moved a lot in the last month or so.
Caryn Palatchi (a Caltech undergrad who just started working with us)
illustrated to me today that using even 1000 FIR taps is not very effective
for low frequency noise cancellation if you have a 2048 Hz sample rate. More
precisely, the asymptotic Wiener filter which our 'LMS' algorithm converges
to, can often amplify the noise at frequencies below f_sample/N_taps.
A less obvious thing that she also noticed is that there is almost no cancellation
of the 16.25 Hz bounce mode when using such a short filter. That's because that
mode is fairly high Q: the transfer function from the Z-ACC to the cavity signal
goes through the high-Q vertical suspension resonance; the FF signal we send back
goes through the low-Q horizontal pendulum response only. Therefore the filter
needs to be able to simulate ~100 cycles at 16.25 Hz in order to cancel that peak.
Duh.
The message here is: we need to find a computationally efficient way to do FIR filtering
or its not going to ever be cool enough to help us find the Crab. |
| Attachment 1: 0052_xray_thm45.jpg
|
|
|
430
|
Sun Apr 20 20:29:46 2008 |
rana | Update | Computer Scripts / Programs | tdsread bugs |
There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob.
I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.
I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.
My guess is that the problem with the IOO channel is not related, but I'm not sure:
op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS> |
|
432
|
Mon Apr 21 12:58:42 2008 |
rob | Update | ASS | check adaptive |
| Quote: |
Caryn Palatchi (a Caltech undergrad who just started working with us)
illustrated to me today that using even 1000 FIR taps is not very effective
for low frequency noise cancellation if you have a 2048 Hz sample rate. More
precisely, the asymptotic Wiener filter which our 'LMS' algorithm converges
to, can often amplify the noise at frequencies below f_sample/N_taps.
A less obvious thing that she also noticed is that there is almost no cancellation
of the 16.25 Hz bounce mode when using such a short filter. That's because that
mode is fairly high Q: the transfer function from the Z-ACC to the cavity signal
goes through the high-Q vertical suspension resonance; the FF signal we send back
goes through the low-Q horizontal pendulum response only. Therefore the filter
needs to be able to simulate ~100 cycles at 16.25 Hz in order to cancel that peak.
Duh.
The message here is: we need to find a computationally efficient way to do FIR filtering
or its not going to ever be cool enough to help us find the Crab. |
This is the reason for "RDNSAMP" parameter in the ASS code. The FIR filtration is applied at the downsampled rate, not the machine rate. So, if RDNSAMP=32, the effective sampling rate of the FIR filter is 64Hz, and thus noise cancellation should be good down to 64Hz/1000, or 64mHz, and the filter has an impulse response time that extends to 15 secs. I'm not convinced the filter length is what's limiting the performance at the bounce mode, but I agree that a faster FIR implementation would be good. |
|
433
|
Mon Apr 21 13:12:21 2008 |
rob | Update | Computer Scripts / Programs | tdsread bugs |
| Quote: | There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob.
I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.
I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.
My guess is that the problem with the IOO channel is not related, but I'm not sure:
op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS> |
This is the same bug described in entry 180. I believe it has nothing to do with tdsread, which did not change in the time period before the bug appeared, but perhaps has something to do with other EPICS libraries somewhere (tdsread relies on these epics libraries to do its dirty work). Here is entry 180 for reference:
| Quote: | tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.
This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls. |
The solution that's been in effect for the past few months has just been to modify the scripts to not make these kinds of calls. |
|
435
|
Tue Apr 22 10:59:24 2008 |
rob | Update | SUS | MC1 electronics busted |
| Quote: | I spent some time trying to fix the utter programming fiasco which was our MCWFS diagonalization script.
However, it still didn't work. Loops unstable. Using the matrix in the screen snapshot is OK, however.
Finally, I realized from looking at the imaginary part of the output matrix that there was something
wrong with the MC1 drive. The attached JPG shows TFs from pit-drives of the MC mirrors to WFS1.
MC1 & MC3 are supposed to have 28 elliptic low pass filters in hardware for dewhitening. The MC2
hardware is different and so we have given it a software 28 Hz ELP to compensate. But it looks like
MC1 doesn't have the low pass (no phase lag). I tried switching its COIL FM10 filters to make it
switch but no luck.
We'll have to engage the filters to make the McWFS work right and to get the MC noise down. This
needs someone to go check out the hardware I think.
I have turned the gain way down and this has stabilized the MC REFL signal as you can see from the StripTool screen. |
This was just because the XYCOM was set to switch the "dewhites" based on FM9 rather than FM10. To check whether the hardware ellipDW filters were engaged, I drove MC1 & MC3 in position (using the MCL bank), and looked at the transfer functions MC2_MCL/MC1_MCL and MC2_MCL/MC3_MCL. This method uses the mode cleaner length servo to enable a relatively clear transfer function measurement of the ellipDW, modulo the loop gain of MCL and the fact that it's really hard to measure an ELP cascaded with a suspension. The hardware and the switching appear to be working fine.
It's now set up such that the hardware is ENGAGED when the coil FM10 filters are OFF, and I deleted all the FM10 filters from the coils of MC1 and MC3. Since we don't switch these filters on and off regularly, I see no need to waste precious SUS processor power on filters that just calculate "1". |
|
436
|
Tue Apr 22 16:17:48 2008 |
rob | Update | SUS | end station sus front-end bug fix |
| Quote: | | installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables. |
What Alex means is that the EPICS values for the ETMY optical levers were being clobbered in the RFM. The calculations were being done correctly in the FE, so the DAQ/testpoints were working--it was just the EPICS/RFM communication via c1losepics that was bugged. This was a result of the recent SUS code changes to accept inputs from the ASS for adaptive feedforward. |
|
437
|
Tue Apr 22 17:08:04 2008 |
Caryn | Update | IOO | no signal for C1:IOO-MC_L |
| C1:IOO-MC_L signal was at zero for the past few days |
|
442
|
Thu Apr 24 14:10:26 2008 |
rob | Update | Locking | locking work |
Rob, Johnnie
We made some progress on locking last night (Wed night), namely that we were able to handoff (briefly) the CARM-MCL path the REFL-DC error signal. We tried this because we suspect that the reason the PO-DC is not a good CARM error signal is because at low powers, the dc light level in the recycling cavity is dominated by the +f2 RF sideband. Thus, REFL-DC should work a bit better at low powers, which it did. It wasn't super stable, though, so this will require a bit of work to make the transition reliable & stable. The next things to work on include setting the AO path gain properly and possibly going to higher arm powers before handing off (thus increasing the discriminant).
Another thing we found is that the alignment scripts are not working in an ideal fashion. Running the alignment scripts for the two arms (XARM & YARM) leaves the Michelson badly misaligned, making it impossible to get good DRM alignment. This will have to be fixed. |
|
445
|
Thu Apr 24 23:27:48 2008 |
rana | Update | PEM | acoustic noise in MC_F |
I looked at the coherence between the Microphone in the PSL (PEM-AS_MIC) and the MC_F channel.
We want to use a microphone to do Wiener/Adaptive noise cancellation on the MC and so we need to
have a coherence of more than ~0.1 in order for that to have any useful effect.
The attached plot shows the spectrum and coherence with and without the HEPA turned up. As you can
see, the HEPA noise is just barely noticeable in this microphone. 
We will need to get something with at least 20 dB more sensitivity.:P |
|
446
|
Thu Apr 24 23:50:10 2008 |
rana | Update | General | Syringes in George the Freezer |
There are some packets of syringes in the freezer which are labeled as belonging to an S. Waldman.
Thu Apr 24 23:48:55 2008
Be careful of them, don't give them out to the undergrads, and just generally leave them alone. I
will consult with the proper authorities about it. |
|
448
|
Fri Apr 25 13:20:04 2008 |
Andrey | Update | PEM | Microphone test |
In response to Rana's request, I tested the microphone (if it is alive or not) by clapping my hands and speaking aloud nearby.
The microphone is alive, see the attached "Full Data" for 5 minutes from Dataviewer. |
| Attachment 1: Microphone.png
|
|
|
450
|
Fri Apr 25 15:44:21 2008 |
steve | Update | PSL | scattering measurments |
In pursuit of a low back scattering, high power beam dump we looked at materials such:
polished copper, polished aluminum, diamond cut aluminum, variety of polished & heat treated stainless steel and shades of black glasses.
Black glass is ideal at low power. Superpolished SS 304 #8 is the only material that measures close to bg
We are still looking for a conductive low back scattering material that would be ideal for a good high power beam trap.
Black glass-shade 12, ss304 superpolished #8 and white paper-B98-24lbs back scattering were compared at 1064 nm
Atm 1: data plot numbers from front panel of SR830 display,
sensitivity: 1x1 mV for bg and ss
1x1 V for wp
Atm 2: drawing of measurement set up
Atm 3: SR830 lock.amp settings
Atm 4: view from steering mirror
Atm 5: view from black glass trap
Atm 6: white paper |
| Attachment 1: scatmeas20080425.xls
|
| Attachment 2: scattring_set_up_20080425.ppt
|
| Attachment 3: sr830settings.pdf
|
|
| Attachment 4: viewfmirror.pdf
|
|
| Attachment 5: viewfbgtrap.pdf
|
|
| Attachment 6: wpnmount.pdf
|
|
|
458
|
Mon Apr 28 23:44:33 2008 |
Andrey | Update | Computer Scripts / Programs | Weather.db |
I was trying to figure out how to modify the file "Weather.db" so that the atm.pressure would be recalculated from Pa to bar before appearing in the EPICS screen, but so far I did not succeed. I restarted processor "c1pem1" several times. I will continue this tomorrow, and also I will modify the nmaes of the weather channels. |
|
460
|
Tue Apr 29 21:30:49 2008 |
Andrey | Update | PEM | In the process of renaming channels for Weather Station |
I startted renaming channels for the weather station, and I will continue this tomorrow, on Wednesday.
I have restarted 'c1pem1' several times and reconfigured "C0DCU1" on the framebuilder MEDM screen.
Framebuilder now does not work. |
|
462
|
Thu May 1 08:31:51 2008 |
steve | Update | SUS | earthquake trips etmy & mc1 |
Earthquake at Lake Isabel magnitude 4.4 at 1am today shakes the 40m
ETMY and MC1 watchdogs tripped.
Sus damping restored. |
|
465
|
Mon May 5 15:53:14 2008 |
steve | Update | VAC | drypump replaced & readbacks are out |
The small turbo pump of the annulus system is tp3
It's drypump was replaced at 1.4 Torr after 8 months of operation.
The rebuilding cost of this SH100 drypump is getting ridiculously high $1349.
I'll look for a replacement.
Joseph rebooted c1vac2 card on Apr 24 entry#441
This restarted the readbacks of the turbos and ion pumps for a while.
That was nice. The readbacks are not working again
|
|
472
|
Fri May 9 08:40:24 2008 |
steve | Update | SUS | ETMY sus damping restored |
ETMY lost damping at 19:10 last night.
There was no seismic event than.
Sus damping was restored this morning. |
|
473
|
Fri May 9 10:15:36 2008 |
josephb | Update | Computers | Nodus has moved |
| Steve and myself moved Nodus from under the table in the control room, to just above the Rana computer in the control room rack. |
|
474
|
Tue May 13 10:15:52 2008 |
steve | Update | SUS | restored damping of BS & PRM |
I think our janitor was cleaning too heavy handedly.
The BS and PRM sus damping were lost.
They were restored. |
|
475
|
Tue May 13 10:38:28 2008 |
steve | Update | Computers | rfm network is down |
The RFM network went down yesterday around 5pm
Only c1susvme1 is alive but it's timing is off.
Andrey is bringing the network up.
Andrey wants to make an addition first that our situation is very much similar to that described by Rana in his elog entry # 353 (March 03). All of the rectangular boxes are red, except for SUS1-c1susvme1 and AWG (only these two rectangles are green). |
|
477
|
Wed May 14 14:05:40 2008 |
Andrey | Update | Computers | Computer Linux-2, MEDM screen "Watchdogs" |
Computer "Linux-2", MEDM screen "C1SUS_Watchdogs.adl": there is no indication for ETMY watchdogs, everything is white. There is information on that screen "C1SUS_Watchdogs.adl" about all other systems (MC, ETMX,...), but something is wrong with indicators for ETMY on that particular control computer. |
|
487
|
Mon May 19 11:49:57 2008 |
steve | Update | SUS | etmy oplev laser replaced |
The 9 years old Uniphase HeNe was replaced by a new JDSU 1103P
Power output ~3.5 mW, reflected light back on qpd ~140 microW, 12,800 counts
Andrey will get the ~2.5 mm od spot on the qpd smaller by replacing
the f1000 lens |
|
490
|
Wed May 21 15:21:33 2008 |
rob | Update | Computer Scripts / Programs | autolockers 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. |
|
496
|
Sun May 25 19:33:16 2008 |
rana | Update | IOO | MC Bad after Re-alignment |
The MC pointing was off and the transmitted power was down after John and Andrey brought it back after the bootfest.
I tried getting it back on Friday but was unsuccessful. Today, after the Phoenix Landing, I got it back to someplace
reasonable, but it still seems to be far off. I will check with Rob before we recenter and of the QPDs.
I had to move all of the MC SUS and also align the beam using the IOO periscope. The attached PDF shows some trends
over the last 80 days. You can see that the drop in MC TRANS is about the same as the drop in PMC TRANS. |
| Attachment 1: e.pdf
|
|
| Attachment 2: pmc.png
|
|