ID |
Date |
Author |
Type |
Category |
Subject |
2303
|
Thu Nov 19 18:49:55 2009 |
Alberto | Configuration | elog | Elog debugging output - Down time programmed today to make changes |
Quote: |
We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.
Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:
./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1
which replaces the old one without the part with the -v argument.
The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.
I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.
So be aware that:
We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.
|
I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.
I have to go through the problem...
The elog is up again. |
2308
|
Fri Nov 20 13:54:45 2009 |
Alberto | Omnistructure | Environment | New Paper and Cardboard Recycling Bins Introduced to the 40m |
The 40m produces a large amount of paper and cardboard waste. It would be worth it if we disposed those kind of garbages for recycling.
I set up two new garbage bins in the lab: one in the control rooms that adds up to the can/bottle recycling bin, and one other one in the office area, next to the printer for general paper disposal.
People in the lab are strongly invited to make use of the two new garbage bins and recycle their paper and cardboard waste.
Boxes can be larger than the garbage bin, so I'd recommend people to crash them before throwing them into the bin.


|
2321
|
Tue Nov 24 14:33:22 2009 |
Alberto | Update | ABSL | working on the AP table |
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table. |
2324
|
Tue Nov 24 19:16:02 2009 |
Alberto | Update | ABSL | working on the AP table |
Quote: |
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.
|
Closing the AP table and the NPRO shutter now. |
2326
|
Wed Nov 25 08:43:08 2009 |
Alberto | Update | ABSL | Working on the AP table |
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table. |
2328
|
Wed Nov 25 10:20:47 2009 |
Alberto | Update | ABSL | AbsL PLL not able to lock |
Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.
The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.
Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.
Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.
It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.
Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.
I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder. |
2329
|
Wed Nov 25 11:02:54 2009 |
Alberto | Update | ABSL | AbsL PLL not able to lock |
Quote: |
Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.
The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.
Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.
Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.
It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.
Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.
I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder.
|
I confirm what I said earlier. The amplitude of the beat is -10 dBm at 300MHz. It goes down at lower frequencies. In particular it gets to-60 dBm below 20 MHz. For some strange reason that I couldn't explain the beating efficiency has become poorer at low frequencies. |
2334
|
Wed Nov 25 15:42:27 2009 |
Alberto | Update | ABSL | Working on the AP table |
Quote: |
I'm working on the AP table. I also opened the auxiliary NPRO shutter. The auxiliary beam is on its path on the AP table and PSL table.
|
NPRO shutter closed |
2337
|
Wed Nov 25 20:14:58 2009 |
Alberto | Update | ABSL | AbsL PLL not able to lock: problem fixed |
Quote: |
Last night something happened on the beat between the PSL beam and the auxiliary NPRO beam, that spoiled the quality of the beating I had before. As a result the PLL has become unable to lock the two lasers.
The amplitude of the beat at the spectrum analyzer has gone down to -40 dBm from -10 that it was earlier. The frequency has also become more unstable so that now it can be seen writhing within tens of KHz.
Meanwhile the power of the single beams at the PLL photodiode hasn't changed, suggesting that the alignment of the two beam didn't change much.
Changes in the efficiency of the beating between the two beams are not unusual. Although that typically affects only the amplitude of the beat and wouldn't explain why also its frequency has become unstable. Tuning the alignment of the PLL optics usually brings the amplitude back, but it was uneffective today.
It looks like something changed in either one of the two beams. In particular the frequency of one of the two lasers has become less stable.
Another strange thing that I've been observing is that the amplitude of the beat goes down (several dBm) as the beat frequency is pushed below 50 MHz. Under 10 MHz it even gets to about -60 dBm.
I noticed the change yesterday evening at about 6pm, while I was taking measurements of the PLL open loop tranfer function and everything was fine. I don't know whether it is just a coincidence or it is somehow related to this, but Jenne and Sanjit had then just rebooted the frame builder.
|
Problem found. Inspecting with Koji we found that there was a broken SMA-to-BNC connector in the BNC cable from the photodiode. |
2338
|
Wed Nov 25 20:24:49 2009 |
Alberto | Update | ABSL | PLL Open Loop Gain Measured |
I measured the open loop gain of the PLL in the AbsL experiment.
I repeated the measurement twice: one with gain knob on the universal PDH box g=3.0; the second measurement with g=6.0
The UGF were 60 KHz and 100 KHz, respectively.
That means that one turn of the knob equals to about +10 dB. |
Attachment 1: 2009-09-25_OLgain_g3png.png
|
|
Attachment 2: 2009-09-25_OLgain_g6png.png
|
|
2339
|
Wed Nov 25 20:28:17 2009 |
Alberto | Update | ABSL | Stopped working on the AbsL |
I closed the shutter of the NPRO for the night. |
2345
|
Mon Nov 30 10:28:47 2009 |
Alberto | AoG | all down cond. | sea of red |
Quote: |
Came in, found all front-ends down.
Keyed a bunch of crates, no luck:
Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS
Powered off/restarted c1dcuepics. Still no luck.
Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time.
BURT restored to Nov 26, 8:00am
But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow.
|
I found the red sea when I came in this morning.
I tried several things.
- ssh into fb40m: connection refused
- telnet fb40m 8087: didn't respond
- shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen;
- powercycled fb40m AND C0DAQCTRL: no improvement
- shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen
I'm now going to restart the single front -ends and burtgooey them if necessary. |
2346
|
Mon Nov 30 11:29:40 2009 |
Alberto | AoG | all down cond. | sea of red |
Quote: |
Quote: |
Came in, found all front-ends down.
Keyed a bunch of crates, no luck:
Requesting coeff update at 0x40f220 w/size of 0x1e44
No response from EPICS
Powered off/restarted c1dcuepics. Still no luck.
Powered off megatron. Success! Ok, maybe it wasn't megatron. I also did c1susvme1 and c1susvme2 at this time.
BURT restored to Nov 26, 8:00am
But everything is still red on the C0_DAQ_RFMNETWORK.adl screen, even though the front-ends are running and synced with the LSC. I think this means the framebuilder or the DAQ controller is the one in trouble--I keyed the crates with DAQCTRL and DAQAWG a couple of times, with no luck, so it's probably fb40m. I'm leaving it this way--we can deal with it tomorrow.
|
I found the red sea when I came in this morning.
I tried several things.
- ssh into fb40m: connection refused
- telnet fb40m 8087: didn't respond
- shutdown fb40m by physically pushing the power button: it worked and the FB came back to life but still with a red light on the MEDM DAQ_DETAIL screen;
- powercycled fb40m AND C0DAQCTRL: no improvement
- shutdown fb40m, C0DAQCTRL, C1DCUEPICS and pushed the reset button on the RF network crate; then I restarted the computers in this order: fb40m, C1DCUEPICS, C0DAQCTRL: it worked: they came back to life and the lights eventually turned green on the MEDM montior screen
I'm now going to restart the single front -ends and burtgooey them if necessary.
|
Everything is back on.
Restarted all the front ends. As usual c1susvme2 was stubborn but eventually it came up.
I burt-restored all the front-ends to Nov 26 at 8am.
The mode cleaner is locked. |
2350
|
Thu Dec 3 15:55:24 2009 |
Alberto | AoG | LSC | RF AM Stabilizer Output Power |
Today I measured the max output power at the EOM output of one of the RF AM Stabilizers that we use to control the modulation depth. I needed to know that number for the designing of the new RF system.
When the EPICS slider of the 166 MHz modulation depth is at 0 the modulation depth is max (the slider's values are reversed : 0 is max, 5 is min; it is also 0 for any value above 5, sepite it range from 0 to 10).
I measured 9.5V from the EOM output, that is 32 dBm on a 50 Ohm impedance. |
2365
|
Tue Dec 8 10:20:33 2009 |
Alberto | DAQ | Computers | Bootfest succesfully completed |
Alberto, Kiwamu, Koji,
this morning we found the RFM network and all the front-ends down.
To fix the problem, we first tried a soft strategy, that is, we tried to restart CODAQCTRL and C1DCUEPICS alone, but it didn't work.
We then went for a big bootfest. We first powered off fb40m, C1DCUEPICS, CODAQCTRL, reset the RFM Network switch. Then we rebooted them in the same order in which we turned them off.
Then we power cycled and restarted all the front-ends.
Finally we restored all the burt snapshots to Monday Dec 7th at 20:00. |
2376
|
Thu Dec 10 08:40:12 2009 |
Alberto | Update | Computers | Fronte-ends down |
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest. |
2378
|
Thu Dec 10 08:50:33 2009 |
Alberto | Update | Computers | Fronte-ends down |
Quote: |
I found all the front-ends, except for C1SUSVME1 and C0DCU1 down this morning. DAQAWG shows up green on the C0DAQ_DETAIL screen but it is on a "bad" satus.
I'll go for a big boot fest.
|
Since I wanted to single out the faulting system when these situations occur, I tried to reboot the computers one by one.
1) I reset the RFM Network by pushing the reset button on the bypass switch on the 1Y7 rack. Then I tried to bring C1SOSVME up by power-cycling and restarting it as in the procedure in the wiki. I repeated a second time but it didn't work. At some point of the restarting process I get the error message "No response from EPICS".
2) I also tried rebooting only C1DCUEPICS but it didn't work: I kept having the same response when restarting C1SOSVME
3) I tried to reboot C0DAQCTRL and C1DCU1 by power cycling their crate; power-cycled and restarted C1SOSVME. Nada. Same response from C1SOSVME.
4) I restarted the framebuilder; power-cycled and restarted C1SOSVME. Nothing. Same response from C1SOSVME.
5) I restarted the framebuilder, then rebooted C0DAQCTRL and C1DCU, then power-cycled and restarted C1SOSVME. Niente. Same response from C1SOSVME.
Then I did the so called "Nuclear Option", the only solution that so far has proven to work in these circumstances. I executed the steps in the order they are listed, waiting for each step to be completed before passing to the next one.
0) Switch off: the frame builder, the C0DAQCTRL and C1DCU crate, C1DCUEPICS
1) turn on the frame builder
2) reset of the RFM Network switch on 1Y7 (although, it's not sure whether this step is really necessary; but it's costless)
3) turn on C1DCUEPICS
4) turn on the C0DAQCTRL and C1DCU crate
5) power-cycle and restart the single front-ends
6) burt-restore all the snapshots
When I tried to restart C1SOSVME by power-cycling it I still got the same response: "No response from EPICS". But I then reset C1SUSVME1 and C1SUSVME2 I was able to restart C1SOSVME.
It turned out that while I was checking the efficacy of the steps of the Grand Reboot to single out the crucial one, I was getting fooled by C1SOSVME's status. C1SOSVME was stuck, hanging on C1SUSVME1 and C1SUSVME2.
So the Nuclear option is still unproven as the only working procedure. It might be not necessary.
Maybe restating BOTH RFM switches, the one in 1Y7 and the one in 1Y6, would be sufficient. Or maybe just power-cycling the C0DAQCTRL and C1DCU1 is sufficient. This has to be confirmed next time we incur on the same problem. |
2384
|
Thu Dec 10 13:10:25 2009 |
Alberto | Configuration | LSC | 166 LO Disconnected |
I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.
I'm doing a couple of measurement and I'll put it back in as soon as I'm done. |
2389
|
Thu Dec 10 17:05:21 2009 |
Alberto | Configuration | LSC | 166 MHz LO SMA-to-Heliax connection repaired |
I replaced the SMA end connector for the 166 MHZ Local Oscillator signal that goes to the back of the flange in the 1Y2 rack. The connector had got damaged after it twisted when I was tigheting the N connector of the Heliax cable on the front panel. |
2393
|
Thu Dec 10 18:31:44 2009 |
Alberto | Configuration | LSC | 166 LO Disconnected |
Quote: |
I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.
I'm doing a couple of measurement and I'll put it back in as soon as I'm done.
|
These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:
@11MHz Loss=0.22dBm/meter
@55MHz Loss=0.41dBm/meter
(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V ) |
2396
|
Fri Dec 11 11:42:26 2009 |
Alberto | Configuration | LSC | 166 LO Disconnected |
Quote: |
They must not be dBm, must be dB
Quote: |
Quote: |
I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.
I'm doing a couple of measurement and I'll put it back in as soon as I'm done.
|
These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:
@11MHz Loss=0.22dBm/meter
@55MHz Loss=0.41dBm/meter
(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V )
|
|
I apologize for the lack of correctness on the units in yesterday's elog entry, but I wasn't very sharp last night.
I repeated the measurement today, this time also making sure that I had a 50ohm input impedance set in the scope. These the results for the losses.
RG-174 Cable |
0.053 dB/m @ 11MHz |
0.155 dB/m @ 55 MHz |
I also measured the losses in the Heliax cable going from the 166 MHz LO to the LSC rack:
166MHz LO Heliax |
0.378 dB @ 11MHz |
1.084 dB @ 55 MHz |
|
2397
|
Fri Dec 11 13:18:17 2009 |
Alberto | Configuration | VAC | pumpdown has started |
Quote: |
Oplev positions before and after drag wiped arm TMs as of yesterday. Slow-mode pumpdown has started with 3/4 turn opened RV1 valve at 8am today.
|
I'm leaving the lab now for less than 2 hours. I should be back in time for when the pumping is finished so that I can measure the finesse again. |
2402
|
Fri Dec 11 19:51:13 2009 |
Alberto | Configuration | LSC | 166 LO Disconnected |
Quote: |
Seems like very strange cable loss numbers. The Heliax is lossier than the RG-174? I wonder how these compare with the specs in the cable catalog?
|
In my last entry there was a typo for the measurement of the Heliax at 55 MHz. I corrected it. It was 1.084 dB instead of 1.084 dB/m.
For the Heliax I don't have the measurement of the loss per meter since I don't know the cable actual length.
Except for that, I checked the values I found on the Internet.
My measurements for the RG-174 seem comparable to the loss specified in the catalog ( here): 6.6dB in 100ft @ 55 MHz, that is 0.22 dB/m, that compare with 0.155 dB/m that I measured.
I did the measurement on a 4.33 meter long cable with SMA connectors at the ends. |
2413
|
Mon Dec 14 14:16:14 2009 |
Alberto | Update | Treasure | LOCKSTARS |
Quote: |
Good job guys. What I did was saying "I don't know", "Maybe", and "Ants...".
Now you can proceed to measurements for the visibility and the cavity pole!
Quote:
|
[Jenne, Kiwamu, Koji]
We got the IFO back up and running! After all of our aligning, we even managed to get both arms locked simultaneously.
|
|
I'm going to do it right now. |
2415
|
Mon Dec 14 19:33:04 2009 |
Alberto | Update | General | Arm Cavity Poles measured again after cleaning the optics last week |
Last week we vented and we cleaned the main optics of the arm cavities.
I measured the frequency of the cavity poles for both the arm cavities to see how they changed (see previous elog entry 2226). These the results:
fp_X = 1616 +/- 14 Hz
fp_Y = 1590 +/- 4 Hz
The error is the statistical error that I got with the Matlab NonLinearLeastSquare fitting function.
I calculated the cavity pole frequencies by measuring the transfer function between a photodiode located at the end of the arms (either X or Y) and another photodiode placed after the mode cleaner. Both diodes where Thorlabs PDA255.
(Last time, I had measured that the pair of diode had a flat calibration).
With the SR785 I measured the transfer function by exciting the OMC_ISS_EXC input cable.
For both arms I set to 1V the excitation amplitude. I repeated the measurements for different excitation amplitudes without observing any changes.
I then fitted the data with the NonLinearLeastSquare function of matlab. The script I wrote to do that is attached to this entry in a compressed file.
The files also contains the PDF with the output plots and the data from both set of measurements performed before and after the cleaning.
The data is commented in a file called measurements.log.
In the end I disabled again the test switch on the ISS MEDM screen.
I disconnected the excitation cable from the OMC_ISS_EXC input cable.
I removed the photodiode that measured the Mode Cleaner transmission from the PSL clearing the way for the beam to get back to its path to the RFAM photodiode. |
Attachment 1: XarmTF01_fit.pdf
|
|
Attachment 2: YarmTF01_fit.pdf
|
|
Attachment 3: ArmCavityFinesseMeasurment.tar.gz
|
2418
|
Tue Dec 15 05:29:31 2009 |
Alberto | Update | General | Arm Cavity Poles measured again after cleaning the optics last week |
The Y arm cavity pole moved down by 130 Hz, whereas the X arm moved by only 34 Hz. I wonder if that is because Kiwamu spent much more time on cleaning ITMY than on any other optic. |
2420
|
Tue Dec 15 21:39:34 2009 |
Alberto | Update | ABSL | brief summary of this afternoon's measurements |
I took measurements of the open loop gain of the AbsL PLL with the old Universal PDH Box.
I Also measured the filter shape of both the new and the old PDH box.
I'm going to plot the results in a nice form tomorrow morning.
For who's interested, the PLL UGF was at 10KHz.
I can't lock the PLL with the new PDH box. Measuring its filter's shape, as suggested by Koji, I found out that it differs from the old one. That despite the fact that the two boxes should share the same circuit schematic. O,r at least, that is what it looks like from the schematics in the DCC.
I need to understand whether that is intentional and, if that was the case, what kind of use Rich Abbott designed it for.
Tomorrow I'm going to post in the elog the filter's transfer functions too.
Before leaving the lab I closed the auxiliary laser's mechanical shutter. |
2421
|
Wed Dec 16 11:21:20 2009 |
Alberto | Update | ABSL | Universal PDH Box Servo Filters |
Yesterday I measured the shape of the servo filter of both the old and the new Universal PDH boxes.
Here they are compared.

The way the filter's transfer function has been measured is by a swept sine between the "SERVO INPUT" and the "PIEZO DRIVE OUTPUT" connection on the box front panel. The spectrum analyzer used for the measurement is the SR785 and the source amplitude is set at 0.1V.
The two transfer functions are clearly different. In particular the old one looks like a simple integrator, whereas the new one already includes some sort of boost.
That probably explains why the new one is unable to lock the PLL. Indeed what the PLL needs, at least to acquire lock, is an 1/f filter.
I thought the two boxes were almost identical, at least in the filter shapes. Also the two schematics available in the DCC coincide. |
Attachment 1: NewandOlfFilterTF.png
|
|
2422
|
Wed Dec 16 11:46:25 2009 |
Alberto | Update | ABSL | Absl PLL Open Loop Gain |
Yesterday I measured the Open Loop Gain of the PLL in the absolute length experiment. The servo I used was that of the old Universal PDH box.
The OLG looks like this:

The UGF is at 10 KHz. |
2427
|
Thu Dec 17 09:30:08 2009 |
Alberto | HowTo | Computers | Nodus sluggish |
The elog has been quite slow for the last two days. The cause is nodus, that has been slowing down the access to it.
I looked at the list of the running processes on nodus by typing the command prstat, which is the equivalent for Solaris of the Linux "top". I didn't see any particular process that might be absorbing too many resources.
I remember Rana fixing the same problem in the past but couldn't find his elog entry about that. Maybe we should just restart nodus, unless someone has some other suggestion. |
2428
|
Thu Dec 17 17:13:50 2009 |
Alberto | Omnistructure | Environment | STACIS stuff |
One of the electronics benches is currently occupied by the STACIS equipment.
We need that table If no one is working on the STACIS anymore, it should be removed from there. |
2429
|
Thu Dec 17 19:03:14 2009 |
Alberto | HowTo | Computers | Nodus sluggish |
Quote: |
The elog has been quite slow for the last two days. The cause is nodus, that has been slowing down the access to it.
I looked at the list of the running processes on nodus by typing the command prstat, which is the equivalent for Solaris of the Linux "top". I didn't see any particular process that might be absorbing too many resources.
I remember Rana fixing the same problem in the past but couldn't find his elog entry about that. Maybe we should just restart nodus, unless someone has some other suggestion.
|
Problem solved. Nodus and the elog are running fine. It's just that the elog takes some time to make a preview of complex pdf attachments, like those in Kiwamu's entry 2405. |
2459
|
Mon Dec 28 15:19:19 2009 |
Alberto | Update | Computers | Burtrestored to Dec 26 at 20:00 |
Since it wasn't sure whether all the front-ends had been restored after the bootfest, I burtrestored everything to Dec 26 at 20:00.
Always keep in mind that to burtrestore c1dcuepics, the snapshot file has to be modified by hand by moving the last quote up to the line before the last. |
2460
|
Mon Dec 28 15:34:14 2009 |
Alberto | Update | ABSL | Working on the AP table |
I opened the auxiliary laser's shutter.
I'm currently working on the AP table. |
2461
|
Mon Dec 28 18:35:27 2009 |
Alberto | Update | ABSL | Working on the AP table |
Quote: |
I opened the auxiliary laser's shutter.
I'm currently working on the AP table.
|
I finished working on the table.
I closed the AUX NPRO's shutter. |
2467
|
Wed Dec 30 10:58:48 2009 |
Alberto | Update | General | All watchdogs tripped this morning |
This morning I found all the watchdogs had tripped during the night.
I restored them all.
I can't damp ITMX. I noticed that its driving matrix is all 1s and -1s as the the right values had been lost in some previous burtrestoring. |
2476
|
Tue Jan 5 09:18:38 2010 |
Alberto | Omnistructure | Electronics | Universal PDH Box Stored in the RF Cabinet |
FYI: I stored the Universal PDH boxes in the RF cabiner in the Y arm. |
2479
|
Tue Jan 5 13:23:45 2010 |
Alberto | Omnistructure | Environment | turning page |
In the lab there are lots of old posters with outdated autocad drawings, or printouts with schematics of old electronics hanging on the walls.
Can we get rid of those and start giving the lab a fresh and modern look? |
2485
|
Fri Jan 8 10:03:04 2010 |
Alberto | Omnistructure | LSC | SPOB shutter was closed |
This morning I found that there was no light on the SPOB PD. I went looking at the photodetector and I found that the shutter in front of it was closed.
I switched the shutter driver from n.c. to n.o. which had the effect of opening it.
I guess we inadvertently closed the shutter with Rana when last week we were tinkering with the ITMY camera. |
2491
|
Sat Jan 9 09:47:03 2010 |
Alberto | Update | LSC | Problems trying to lock the arms |
This morning I've been having problems in trying to lock the X arm.
The X arm's filter FM6 in the LSC screen starts blinking as it was halfloaded. Then the transmitted power drops from 1 to ~0.5 and eventually the arm loses lock.
To me it looked like a computer related issue. So I decide to reboot C1ISCEX by powercycling it.
That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1. |
2492
|
Sat Jan 9 11:07:30 2010 |
Alberto | Update | LSC | Problems trying to lock the arms |
Quote: |
This morning I've been having problems in trying to lock the X arm.
The X arm's filter FM6 in the LSC screen starts blinking as it was halfloaded. Then the transmitted power drops from 1 to ~0.5 and eventually the arm loses lock.
To me it looked like a computer related issue. So I decide to reboot C1ISCEX by powercycling it.
That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1.
|
The X arm is now locked with TRX stable at ~1.
I think earlier on today I was having problems with running the alignment scripts from op540. Now I'm controlling the IFO from Rosalba and I can easily and stably lock all degrees of freedom.
I needed the X arm to be locked to align the auxiliary beam of the AbsL experiment to the IFO. To further stabilize TRX I increased the loop gain from 1 to 1.5.
Now the auxiliary beam is well aligned to the IFO and the beat is going through the PRC. I'm finally ready to scan the recycling cavity.
I also changed the gain of the PRC loop from -0.1 to -0.5. |
2493
|
Sat Jan 9 15:02:01 2010 |
Alberto | Update | ABSL | PRC scanning |
I scanned the PRC in the frequency range of 30-60 MHz, untill the PLL lost lock. But everything is working fine.
The PRC remained lock for all time, with SPOB at ~1000.
I'm leaving the lab now, planning to come back tomorrow.
I turned the flipping mirrors down and closed the mechanical shutter of the auxiliary NPRO. |
2496
|
Sun Jan 10 16:05:51 2010 |
Alberto | Omnistructure | Environment | Lab Thermostats Temperature Lowered by 1 deg F |
Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.
Today I lowered the temperature of the three thermostats that we have inside the lab by one degree:
Y arm thermostat: from 71 to 70 F
X arm thermostat: from 70 to 69 F
Aisle thermostat: from 72 to 71 F.
For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold. |
2500
|
Mon Jan 11 09:18:44 2010 |
Alberto | Update | General | Measurement running |
I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.
Please make sure of not interfering with the interferometer until it is done. Thank you. |
2501
|
Mon Jan 11 10:01:06 2010 |
Alberto | Omnistructure | Environment | Lab Thermostats Temperature Lowered by 1 deg F |
Quote: |
Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.
Today I lowered the temperature of the three thermostats that we have inside the lab by one degree:
Y arm thermostat: from 71 to 70 F
X arm thermostat: from 70 to 69 F
Aisle thermostat: from 72 to 71 F.
For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold.
|
Today the lab is perceptibly cooler.
The temperature around the corner is 73 F. |
2502
|
Mon Jan 11 11:06:53 2010 |
Alberto | Update | ABSL | Measurement running |
Quote: |
I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.
Please make sure of not interfering with the interferometer until it is done. Thank you.
|
I'm done for the moement.
I realized that I need to take into account somehow the DC power from the photodiode. By now the measurement of the transmitted beat's power is affected by the total power circulating inside of the PRC and thus it depends on the cavity alignment.
I closed the laser shutter and turned down the flipping mirrors.
I'm planning to restart measuring by 2.30pm today. Till then the interferometer is available. |
2504
|
Mon Jan 11 16:59:14 2010 |
Alberto | Update | ABSL | Interferometer Busy |
I'm currently running a measurement on the PRC.
Please don't interfere with the IFO until it is done. Talk with Alberto if you've been intending to work inside the lab.
Thank you. |
2505
|
Mon Jan 11 19:36:13 2010 |
Alberto | Update | ABSL | Measurement running |
Leaving for dinner. Back in ~1hr.
I left a measurement running. Please don't interfere with it till I'm back. Thanks. |
2508
|
Tue Jan 12 09:37:05 2010 |
Alberto | Update | ABSL | IFO available |
I finished measuring the AbsL for this morning. The IFO is again available.
Please don't mess up with the interferometer though. I'll be back in a couple of ours |
2512
|
Wed Jan 13 12:01:06 2010 |
Alberto | Update | Computers | c1dcuepics, c1lsc rebooted this morning |
Since last night the alignemtn scripts couldn't work.
c1lsc wasn't working properly because attempts to lock the X arm would try to control ETMY and attempts of locking the Y arm, wouldn't actuate any optics.
Also, another sign of a malfunctioning c1lsc was that one of the LSC filter modules, FM6, couldn't get loaded properly. It looked like only half loaded on the LSC MEDM screen.
On the other hand, plotting the trend of the last month, c1lsc's CPU didn't look more loaded that usual.
Rebooting and restarting C1lsc wasn't enough and I also had to reboot c1dcuepics a couple of times beforse getting things back to work. |