| ID |
Date |
Author |
Type |
Category |
Subject |
|
614
|
Tue Jul 1 13:34:29 2008 |
rob | Update | Computers | RFM network back |
| Quote: |
For some reason, the computers requiring startup.cmd (like c1lsc) halt after running this command. Actually the computer is running ok, but the command freezes. Basically, what it does is simply to load a kernel module. I don't know what is wrong.
Anyway, I just closed the terminal after running startup.cmd and it seems fine for now. |
This is normal. On the linux RTFEs (Real-Time Front Ends), the real-time code totally hijacks the kernel, disallowing any interrupts. The system thus becomes totally unresponsive while the code is running, and communicates only through the RFM and the VME backplane. |
|
613
|
Tue Jul 1 12:51:34 2008 |
John | Summary | General | IFO alignment |
Rana, Rob, Yoichi, John
The recent computer problems and MZ work had disturbed the alignment of the interferometer.
We adjusted the MC alignment back to nominal positions using old OSEM values. We then walked
the input beam to match the MC. Coupling into the interferometer has increased noticeably.
The rest of the IFO was then aligned to the new input beam.
Proceeding to full IFO locking we were able to engage the AO path and hand off CARM to SPOBDC.
Arm powers got up to 4.
If the new alignment proves successful we will centre all QPDs etc so we can easily return to
this state. |
| Attachment 1: align080701.png
|
|
|
612
|
Tue Jul 1 12:08:38 2008 |
John, Joe | Configuration | PSL | PMC input PD |
Joe and I switched cables so that the PMCR screen actually shows reflection not transmission.
The trans camera had a BNC connected to "video out" labelled PMC input PD. The video signal
going to the monitors does not come from "video out", it comes out the "DC in/sync" cable.
As far as we can see this diode doesn't exist. Where should the PMC input PD BNC cable be
connected? |
|
611
|
Tue Jul 1 11:57:24 2008 |
Yoichi | Configuration | PSL | MZ servo switch problem again |
C1:PSL-MZ_BLANK switch (to turn on/off the servo) is not working again. The switch is always off regardless of the epics state.
I pushed the cables into the xycom card, but it did not fix the problem.
|
|
610
|
Tue Jul 1 11:53:38 2008 |
Yoichi | Update | Computers | RFM network back |
I took a tour of the FE machines and power cycled all of them.
After executing the software restart procedures of those computers, the RFM network got back to the normal state.
For some reason, the computers requiring startup.cmd (like c1lsc) halt after running this command. Actually the computer is running ok, but the command freezes. Basically, what it does is simply to load a kernel module. I don't know what is wrong.
Anyway, I just closed the terminal after running startup.cmd and it seems fine for now. |
|
609
|
Tue Jul 1 10:15:22 2008 |
steve | Update | PSL | eventfull two days |
The laser recovered from a short temp rise. The MZ was aligned and realigned. The suspentions were kicked up accidentally.
Now the computers are down. |
| Attachment 1: 2d.jpg
|
|
|
608
|
Tue Jul 1 09:26:33 2008 |
steve | Update | Computers | RFM network is down |
|
|
607
|
Mon Jun 30 18:36:01 2008 |
Yoichi | Update | PSL | MZ alignment again |
John, Yoichi
We re-adjusted the MZ alignment. The reason behind this is to make sure that the MZ dark port is not falling at a strange fringe, where it is only dark at the dark port PD. It can happen when the two beams poorly overlap.
We tried both the minimization of the MZ dark PD and the maximization of the MZ transmission at the same time.
We also placed another PD in the MZ dark port at a different distance from the original dark PD and tried to minimize this too.
If the MZ dark port is at a strange fringe, one of the dark PD can be dark where the other one is still bright.
If both of the dark PD get dark, the overlap between the beams should be ok.
We tweaked only the two mirrors of the MZ after the EOMs (mainly the one with a PZT).
Right now, the MZ dark power is 0.432.
BTW, we should change the name of the MZ dark port on the medm screen (it is now MZ reflection, where it is not a reflection).
I will try to change it later.
We wanted to put the beam position on the IOO-QPD_POS_* back to the original (before John tweaked the MZ alignment earlier).
However, the trends of IOO-QPD_POS_* show a lot of fluctuation and jumps, of which we don't know the cause. So we could not find reasonable original values.
We suspect a circuit problem in IOO-QPD_POS, especially because the jumps are very strange.
We will do this investigation later too. |
|
606
|
Mon Jun 30 16:00:02 2008 |
josephb, sam | Configuration | Computers | |
Sam and I setup Cat6 cable from Megatron to the 1Y6 Switch (131.215.113.252) and also connected the 1Y6 Hub to the control room switch.
While I was at it, I checked the configurations of the two switchs now connected (one in 1X4 and one in 1Y6) to the martian network. For some reason, the 1X4 had switched to DHCP enabled and was using 131.215.113.105 as an IP address. I had thought I had setup it correctly initially, so am not sure what caused the change.
The easiest way I know of to check the setup is use smartwizard discovery program from the Netgear install CD (in the equipment manual file cabinet of the control room) on a windows machine. The passwords have been set to the controls password.
Megatron should now see and be accessible through the martian network. |
|
605
|
Mon Jun 30 15:56:22 2008 |
Jenne | Update | Electronics | Fixing the LO demod signal |
To make the alarm handler happy, at Rana and John's suggestion I replaced R14 of the MC's Demod board, changing it from 4.99 Ohms to 4.99 kOhms. This increased the gain of the LO portion of the demod board by a factor of 10. Sharon and I have remeasured the table of LO input to the demod board, and the output on the C1:IOO-MC_DEMOD_LO channel:
Input Amplitude to LO input on demod board [dBm]: | Value of channel C1:IOO-MC_DEMOD_LO
------------------------------------------------- | -----------------------------------
-10 | -0.00449867
-8 | 0.000384331
-6 | 0.0101503
-4 | 0.0296823
-2 | 0.0882783
0 | 0.2543
2 | 0.542397
4 | 0.962335
6 | 1.65572
8 | 2.34911
10 | 2.96925 |
|
604
|
Mon Jun 30 15:08:52 2008 |
John | Summary | PSL | MZ alignment |
I adjusted the alignmnet of the Mach-Zehnder's two North mirrors (downstream of the EOMs).
MZ REFL is reduced from 0.54 to 0.43. The largest improvement was due to pitch on the PZT mirror. |
| Attachment 1: mzalign.png
|
|
|
603
|
Mon Jun 30 14:07:26 2008 |
Rob | Configuration | PSL | Don't put the bin in front of the air conditioning unit |
| Quote: | We spotted that the laser power was dropping.
|
the offending configuration: |
| Attachment 1: DSC_0140.png
|
|
|
602
|
Mon Jun 30 13:48:47 2008 |
John, Rob | Configuration | PSL | Don't put the bin in front of the air conditioning unit |
We spotted that the laser power was dropping.
The air conditioning unit was blocked by the blue bin/trash can/cestino causing the laser head temp to increase by 2 degrees.
Let's be careful about this in the future. |
| Attachment 1: binremoval.png
|
|
|
601
|
Mon Jun 30 09:46:15 2008 |
John | Update | IOO | MC WFS |
| MC WFS are on. They seem to do some good during the day. |
|
600
|
Mon Jun 30 08:59:23 2008 |
steve | Update | IOO | IOO-MC_DEMOD_LO is low |
| The alarm handler is beeping relentlessly: asking for help in high partical count and low demod signal |
| Attachment 1: demlo.jpg_____
|
 |
|
599
|
Mon Jun 30 05:33:38 2008 |
Koji | Update | General | Abs. Len. Meas. ~ Optical setup (II) |
o The position of the iris was adjusted so as not to disturub the beam for OMCR CCD.
o The RF spectrum analyzer was returned to the place of the network analyzer.
| Quote: |
In the process of making this report, I noticed that one of the iris apertures is about disturbing the beam for OMCR CCD. I will check this before I go to Hanford. Also an RF spectrum analyzer is at the AP table. I try to return this near the PSL on Monday morning.
|
|
|
598
|
Mon Jun 30 01:49:06 2008 |
John | Update | IOO | MC work |
I'm in the process of aligning the mode cleaner/ input beam.
I turned off the WFS and cleared their histories, adjusted the input periscope and re-aligned the mode-cleaner accordingly.
I then unlocked the cavity and centred the beams on the WFS.
MC transmission is ~3.3 and the REFL beam looks a little better.
However, turning the WFS on now lowers the transmission. More thought tomorrow.
I'm leaving the MC locked with WFS off. |
|
597
|
Sun Jun 29 20:29:48 2008 |
rana | Update | PSL | Correlation of PSL SLOW control v. Room temperature |
|
| Attachment 1: slowtemp.png
|
|
|
596
|
Sun Jun 29 20:09:40 2008 |
John | Summary | IOO | mcup and mcdown indicators |
I edited the mcup and mcdown scripts so that C1IFO_STATE shows when these scripts are running.
I also added indicators to the LockMC screen. |
| Attachment 1: mcscreen.png
|
|
| Attachment 2: ifostate.png
|
|
|
595
|
Sun Jun 29 19:53:26 2008 |
John | Summary | PSL | ISS |
| Quote: | | I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates. |
Seemed to go back to normal after the frame builder came back. |
|
594
|
Sun Jun 29 19:19:47 2008 |
rana | Summary | IOO | Trends of the PSL/IOO Quads over 1000 days |
| Only IOO POS has been working for the past 2 years. I guess we should recommission the IOO ANG and REFL QPDs |
| Attachment 1: a.png
|
|
|
593
|
Sun Jun 29 18:58:43 2008 |
rana | Summary | Computers | 1e20 is too big for AWG and/or IOVME |
While testing out my matlab/awgstream based McWFS diagnostic script I accidentally put a
huge excitation into C1:IOO-WFS1_PIT_EXC . This went to 1e20 and then caused
some SUS to trip and c1susvme2 to go red. I tried booting it via the normal procedures
but it wouldn't come back, even after 2 crate power cycles. I also tried booting AWG
via the vmeBusReset, but that didn't do it. Then I booted c1iovme from the telnet prompt
and then I could restart c1susvme2 successfully.
The reason the excitation was so large is that the following filter command is unstable:
[b,a] = butter(4,[0.02 30]/1024);
The low pass part is OK, but it looks like making such a low frequency digital filter
is not. Que lastima. On the bright side, the code now has some excitation amplitude
checking. |
|
592
|
Sun Jun 29 14:53:02 2008 |
rob | Update | Computers | Rebooting |
| Quote: | All of the computers are now showing green lights.
Remaining problems:
Alignment scripts are failing with "ERROR: LDS - NDS server error #13"
I think this is a server transmission error.
Dataviwer shows all channels as zero. |
Fixed. Just started the testpoint manager on fb40m.
su
/usr/controls/tpman &
|
|
591
|
Sun Jun 29 11:31:52 2008 |
John | Summary | PSL | ISS |
| I reduced the gain of the ISS (C1: PSL-ISS_VGAGAIN) from 5dB to 2dB. Any higher and it constantly saturates. |
|
590
|
Sun Jun 29 02:33:28 2008 |
Koji | Update | General | Abs. Len. Meas. ~ Optical setup (I) |
I have constructed the beam injection optics for the abs length measurement.
The injection beam was coarsely aligned to the interferometer. The reflected beam from SRM was already seen at AS CCD.
I have attached the optical configration for this measurement and the optics layout at the AP table.
I am going to go to LHO for three weeks. During the absence Alberto tunes the mode matching and the alignment of the interferometer.
In the process of making this report, I noticed that one of the iris apertures is about disturbing the beam for OMCR CCD. I will check this before I go to Hanford. Also an RF spectrum analyzer is at the AP table. I try to return this near the PSL on Monday morning.
Attachment 1: Optical configuration for the abs length measurement.
1) One of the arms is locked to the PSL beam by the main control system (red).
2) A laser beam is injected from the AS port (blue). This laser essentially has different frequency from that of PSL.
3) The injected beam and the outgoing PSL beam appear at the output of the faraday in the injection system.
4) They beat each other at the frequency difference of those two lasers.
5) A PLL is used to lock the frequency difference to a local oscillator (LO).
6) The LO frequency is swept at around 3.87MHz, that is the approximate FSR frequency of the arm cavity.
7) If the LO frequency hits the FSR within the resonant width, the beating also appears at the transmitted light as the injected beam also becomes resonant to the arm cavity.
8) Amplitude of the beating at the transmitted light is measured by a RF spectrum analyzer as a function of the LO frequency. We get the FSR frequency (= the arm cavity length) from the top of the resonance.
Attachment 2: Optics at the AP table for the laser injection
700mW NPRO, laser source. vertically polarized.
Periscope, to raise the beam 1 inch to make the beam at the 4 inch elevation.
INJ_SM1/INJ_SM2, steering mirrors to align the injection beam to the IFO beam.
HWP1, half wave plate to make the beam to the farady horiz-polarized. nominal 42deg on the readout.
FI, Faraday isolator for protection of the NPRO from the returning light, for obtaining the returning light.
HWP2, to make the beam from the Faraday horiz-polarized. nominal 357deg on the readout.
MM_Lens, f=125mm to match the laser mode to the IFO beam.
SM1/SM2, steering mirrors to align the IFO beam to the Farady Isolator.
IRIS1/IRIS2, for the coarse alignment of the injection beam.
FLIP, flipper mount to turn on/off the injection optics.
Alignment procedure of the injection system
0) Ignite NPRO several hours before the experiment so that the laser frequency can be stable.
1) Turn up FLIP. Close the shutter of NPRO.
2) Adjust SM1/SM2 so that the ifo beam can appear at the output of FI.
3) Adjust height and position of IRIS1/IRIS2 with regard to the ifo beam so that the ifo beam goes through IRIS1/IRIS2 even when they are closed.
4) Turn down FLIP. Open the shutter of NPRO.
5) Adjust INJ_SM1/INJ_SM2 so that the injection beam can go through IRIS1/IRIS2 even when they are closed.
6) At this time, it is expected that the reflection of the injection beam from SRM appears at AS CCD, if SRM is aligned.
7) Adjust INJ_SM1/INJ_SM2 so that the injection beam at AS CCD can overlap to the IFO beam.
8) Confirm the beam at the output of the FI also overlaps.
---- We are here ----
9) Change the ifo configuration to the X or Y arm only.
10) Scan the crystal temperature of the 700mW NPRO in order to try to have the beating of the two beams at the PD. AS OSA may be useful to obtain the beating.
11) Once the beating is obtained, adjust INJ_SM1/INJ_SM2 such that the beating amplitude is maximized. |
| Attachment 1: optical_configuration.png
|
|
| Attachment 2: optical_layout_ap_table2.png
|
|
| Attachment 3: optical_layout_ap_table2.pdf
|
|
|
589
|
Sat Jun 28 23:23:50 2008 |
John | Update | Computers | Rebooting |
All of the computers are now showing green lights.
Remaining problems:
Alignment scripts are failing with "ERROR: LDS - NDS server error #13"
I think this is a server transmission error.
Dataviwer shows all channels as zero. |
|
588
|
Sat Jun 28 14:56:44 2008 |
John | Update | Computers | ini files |
In short, I was editing the ini files yesterday evening, I didn't e-log it and after some investigation this afternoon it apears
that I am to blame for all the computer problems which followed.
I wanted to edit C0EDCU.ini and C1IOOF.ini to change C1: PSL-FSS_FAST to a fast channel as C1: PSL-FSS_FAST_F
was dead.
I opened these files and made backups. It appears this is where it all went awry. My backup for C1IOOF
is called C1IOO.ini.090627 i.e. missing the F.
Later c1susvme2 and c1iovme crashed. After failing to bring c1iovme back I wondered if my edits had
caused the problems so I restored the back up files. It appears that here I wrote over C1IOO with my backup of
C1IOOF (presumably because I had made a typo in the name).
To remedy the situation we could restore C1IOO from e.g. chans/archive/C1IOO_080618_160028.ini
No excuses for not e-logging this activity. |
|
587
|
Sat Jun 28 03:10:25 2008 |
rob | Update | Computers | c1iovme |
| Quote: | C1susvme2 and C1iovme crashed which sent the optics swinging and tripped the watchdogs.
Koji and I were able to restore c1susvme2 without any trouble.
We have been unable to revive c1iovme. We have tried telneting in and running startup.cmd,
the process runs for a while then hangs with "DAQ init failed -- exiting".
Resetting the board doesn't help. I didn't try keying the whole crate.
All optics are back to normal with damping restored. |
I tried keying the crate, then keying the DAQ controller & AWG, then powering down & restarting the framebuilder.
On coming up, the framebuild doesn't start a daqd process, and I can't get one to start by hand (it just prints "652", and then stops).
No error messages and daqd doesn't appear in the prstat.
I then tried keying the DAQ controller again (after the fb0 reboot), which blew the watchdogs on all the suspensions. So then I went around and keyed all the crates.
Now, the suspension controllers are back online. Still no c1iovme, and now the framebuilder/DAQ/AWG are also hosed. We can try keying all the crates again, in the order that Yoichi did last week.
After some more poking around, I found the daqd log file. It's now complaining about
Jun 28 03:00:39 fb daqd[546]: [ID 355684 user.info] Fatal error: channel `C1: PSL-FSS_MIXERM_F' is duplicated 126
This is the second error message like this. It first complained about C1: PSL-FSS_FAST_F, so I commented that out of C1IOOF.ini and rebooted the framebuilder (note this is an actual reboot of the full solaris machine). Eventually I discovered that C1IOOF.ini and C1IOO.ini are essentially identical. They presumably will keep getting these duplicate channel errors until one of them is completely removed.
C1IOO.ini has a modification time of seven PM on Friday night. Who did this and didn't elog it? I've now modified C1IOOF.ini, and I don't remember when it was last modified. |
|
586
|
Fri Jun 27 19:59:44 2008 |
John | Update | Computers | c1iovme |
C1susvme2 and C1iovme crashed which sent the optics swinging and tripped the watchdogs.
Koji and I were able to restore c1susvme2 without any trouble.
We have been unable to revive c1iovme. We have tried telneting in and running startup.cmd,
the process runs for a while then hangs with "DAQ init failed -- exiting".
Resetting the board doesn't help. I didn't try keying the whole crate.
All optics are back to normal with damping restored. |
|
585
|
Fri Jun 27 18:21:01 2008 |
Jenne | Update | Electronics | Response of the LO input on the MC demod board |
The alarm handler has been flipping out saying that the LO input of the MC's demod board is too low, so at Rana's suggestion, Eric and I measured the response of the LO input. We used an SR345 function generator at 29.485MHz and several different amplitudes to make a table. The demod board should see an input from the LO between 0-2dBm. When I measured what was going into the LO input from the 29.5MHz delay line phase shifter, the LO input was seeing 4dBm. I'm going to put a 3dB attenuator between the phase shifter and the demod board.
Also, now that we have this table of response values, I'm going to change the settings of the alarm handler to something more reasonable.
Amplitude of 29.485MHz input sine wave [dBm] | Value of channel C1:IOO-MC_DEMOD_LO
-------------------------------------------- | -----------------------------------
-10 | -0.000449867
-8 | -0.000449867
-6 | -0.000449867
-4 | 0.000384331
-2 | 0.00526733
0 | 0.0199163
2 | 0.0492143
4 | 0.0931613
6 | 0.161523
8 | 0.229885
10 | 0.293364 |
|
584
|
Fri Jun 27 18:03:46 2008 |
Jenne | Update | Electronics | Another bad cable in the MC servo |
| Eric was helping me to measure the response of the LO input on the MC's Demod board, and when we disconnected the end of the cable between the demod board and the delay line phase shifter for the 29.5MHz oscillator, we noticed that the phase shifter's end of the cable was loose, like the connector wasn't fully connected. When we checked it by wiggling the connector, the SMA end fell off. I made a new SMA end for the cable, and reinstalled the cable. The MC locked as soon as I plugged the cable in, so everything seems good again. I tried to not change the cable length when I remade the connector, but the cable is shorter than it was by a small amount, due to the way the end fell off. |
|
583
|
Fri Jun 27 15:20:52 2008 |
rob | DAQ | LSC | .ini file change |
I removed C1:LSC-XARM_CTRL from the frames and added C1:LSC-CARM_ERR |
|
582
|
Fri Jun 27 14:36:39 2008 |
John | Summary | Locking | |
Rob, Yoichi, John
Some progress last night:
Switched back to SPOB_DC for CARM.
Shaped the MC LSC loop to reduce excess noise in the 20-30Hz band. Likely the most significant change.
Could this be due to fan noise from the laptop on the SPOB table?
Brought in the AO path earlier (at low gain).
Reduced offset to 6 and increased MC gain before handing off to SPOB. Ramped up AO and MC gain then switched off the
moving zero.
Looks like PD11 is the most promising candidate for RF CARM although the demod phase needs attention. |
| Attachment 1: gettingcloser.png
|
|
|
581
|
Fri Jun 27 09:20:15 2008 |
steve | Frogs | PEM | dust particle count is up & alarm handler is on |
This 3 years plot show the trend of seasons.
When outside air quality goes bad ( 0.5 micron > 1 million ) the lab follows.
I will demonstrate this effect with a 4th of July fire works calibration.
Let's do not forget the construction activity next door either.
The alarm handler is busy:
It's sound level were reset to a modest level yesterday.
It would be nice to change the alarm sound so it can play Wagner:Der Ring des Nibelungen:
Das Rheingold, Die Walkure & Siegfried and Gotterdammerung
or something more appropriate than the present frog call
1, half micron count is climbing ( it's close to 16k now )
2, MZ refl signal is too high
3, MC lenght servo LO is too |
| Attachment 1: dust3y.jpg
|
|
|
580
|
Thu Jun 26 22:08:33 2008 |
Jenne | Update | Electronics | 3.7MHz bandstop filter in MC Servo |
The 3.7MHz elliptical bandstop filter that I made during my SURF summer is now installed in the MC servo loop to reduce the noise at 3.7MHz.
I have taken transfer functions with and without the filter between TP1A and TP2A, with EXCA at -20dBm, using the HP4195A Network Analyzer. I have also taken power spectra of TP1A with and without the filter, and time domain data with the filter of OUT2 on the MC Servo Board and Qmon on the Demod board just before the MC servo board. The filter is between Qmon and OUT2 in the loop.
The UGF and phase margin don't change noticeably with and without the filter, and the MC still locks nicely (after the minor fiasco this afternoon), so I think it's okay. The UGF is around 57kHz, with about 38 degrees phase margin.
1 July 2008: I redid the plots. Same info, but the traces with and without the filters are now on the same graph for easier readability. |
| Attachment 1: MCLoopGainBoth.png
|
|
| Attachment 2: TP1ASpectrumBoth.png
|
|
| Attachment 3: QmonWithFilt.png
|
|
| Attachment 4: MCOut2WithFilt.png
|
|
|
579
|
Thu Jun 26 21:07:11 2008 |
rana | Configuration | ASS | dust & MC1 |
I realized today, that yesterday while we were trying to debug the adaptive noise canceler, I turned
off the analog dewhitening on MC1. I did this by changing settings on the Xycom screen but I
forgot to elog this -- this may have caused problems with locking via increased frequency noise.
I have now returned it to its nominal, dewhitening on, configuration.
I also used mDV to look at the last year of dust trend. I have plotted here the cumulative
histogram in percentile units of the 0.5 micron dust level. The x-axis is in units of particles per cu. ft.
and the y-axis is percentage. For example, the plot tells us that over the last year, the counts were
below 6000, 90% of the time. I have set the yellow and red alarm levels to alarm at the 95-th and 99-th
percentile levels, respectively. |
| Attachment 1: Screenshot-2.png
|
|
|
578
|
Thu Jun 26 20:59:22 2008 |
rana | Update | Computer Scripts / Programs | Alarm Handler |
| Please do not turn off the Alarm Handler on op540m. |
|
577
|
Thu Jun 26 18:29:44 2008 |
Jenne | Update | | MC Back online |
Jenne, Rob, Yoichi
I was playing with the Mode Cleaner earlier today, working on measuring the effect of the new filter (see next post for loop gain measurements etc.), and bumped something which made it so the Mode Cleaner would not lock.
After much poking around by Rob and Yoichi, we found that the TNC-to-2 pin LEMO from Out1 of the MC Servo Board to Ch1 of the Pentek Generic board to the right of the MC Servo Board was bad. If we touched the cable, the MC would lock, but as soon as we let go, the MC would fall out of lock. The LEMO end of the cable was not heat shrink wrapped, so the 2 wires could have been touching. I replaced the cable, and the MC locked immediately after plugging it in, so I think that has fixed the problem. |
|
576
|
Thu Jun 26 18:27:04 2008 |
rana | Update | Computer Scripts / Programs | No Dataviewer No Cry |
Dataviewer was hanging. It would open the Grace window but then not plot anything. Since DTT was working
fine we diagnosed this as a DV only problem. It turned out that there was a boatload of messages in the
dataviewer queue. You can check for extra messaages using the command 'ipcs -q' and then use 'rmq' to remove them.
Dataviewer is working now.
Here's the screen dump from op440m:
op440m:~>ipcs -q
IPC status from <running system> as of Thu Jun 26 18:19:32 PDT 2008
T ID KEY MODE OWNER GROUP
Message Queues:
q 400 0x1a51 -Rrw-rw-rw- controls staff
q 1 0x501 -Rrw-rw-rw- controls staff
q 2 0x512 -Rrw-rw-rw- controls staff
q 103 0x553 -Rrw-rw-rw- controls staff
q 4 0x574 -Rrw-rw-rw- controls staff
q 5 0x18be --rw-rw-rw- controls staff
q 56 0x1d9f -Rrw-rw-rw- controls staff
q 7 0x1e56 -Rrw-rw-rw- controls staff
q 8 0x1efd -Rrw-rw-rw- controls staff
q 109 0x2044 -Rrw-rw-rw- controls staff
q 10 0x207a -Rrw-rw-rw- controls staff
q 11 0x24c4 -Rrw-rw-rw- controls staff
q 12 0x24d7 -Rrw-rw-rw- controls staff
q 13 0x251b -Rrw-rw-rw- controls staff
q 14 0x2fe8 -Rrw-rw-rw- controls staff
q 115 0x3a65 -Rrw-rw-rw- controls staff
q 116 0x967 -Rrw-rw-rw- controls staff
q 17 0x98e -Rrw-rw-rw- controls staff
q 118 0x456c -Rrw-rw-rw- controls staff
q 669 0x194 -Rrw-rw-rw- controls staff
q 620 0xe70 -Rrw-rw-rw- controls staff
q 71 0x15d0 -Rrw-rw-rw- controls staff
q 222 0x3586 -Rrw-rw-rw- controls staff
q 173 0x5e37 -Rrw-rw-rw- controls staff
q 624 0x5e4d -Rrw-rw-rw- controls staff
q 475 0x10d7 -Rrw-rw-rw- controls staff
q 176 0x5ee3 -Rrw-rw-rw- controls staff
q 277 0x4e22 -Rrw-rw-rw- controls staff
q 428 0x25f3 -Rrw-rw-rw- controls staff
q 29 0x3354 -Rrw-rw-rw- controls staff
q 180 0x368f -Rrw-rw-rw- controls staff
q 131 0xb0f -Rrw-rw-rw- controls staff
q 82 0x47a5 --rw-rw-rw- controls staff
q 83 0x4b83 -Rrw-rw-rw- controls staff
q 34 0x4f6d -Rrw-rw-rw- controls staff
q 85 0x4539 -Rrw-rw-rw- controls staff
q 86 0x67a1 --rw-rw-rw- controls staff
q 37 0x4b7 -Rrw-rw-rw- controls staff
q 38 0xd37 -Rrw-rw-rw- controls staff
q 39 0x156c -Rrw-rw-rw- controls staff
q 40 0x2b62 -Rrw-rw-rw- controls staff
op440m:~>rmq
---------------------------------------------------------------
Deleting message queues which are owned by user: controls ....
---------------------------------------------------------------
Deleted message queue: 400
Deleted message queue: 1
Deleted message queue: 2
Deleted message queue: 103
Deleted message queue: 4
Deleted message queue: 5
Deleted message queue: 56
Deleted message queue: 7
Deleted message queue: 8
Deleted message queue: 109
Deleted message queue: 10
Deleted message queue: 11
Deleted message queue: 12
Deleted message queue: 13
Deleted message queue: 14
Deleted message queue: 115
Deleted message queue: 116
Deleted message queue: 17
Deleted message queue: 118
Deleted message queue: 669
Deleted message queue: 620
Deleted message queue: 71
Deleted message queue: 222
Deleted message queue: 173
Deleted message queue: 624
Deleted message queue: 475
Deleted message queue: 176
Deleted message queue: 277
Deleted message queue: 428
Deleted message queue: 29
Deleted message queue: 180
Deleted message queue: 131
Deleted message queue: 82
Deleted message queue: 83
Deleted message queue: 34
Deleted message queue: 85
Deleted message queue: 86
Deleted message queue: 37
Deleted message queue: 38
Deleted message queue: 39
Deleted message queue: 40
---------------------------------------------------------------
op440m:~>
|
|
575
|
Thu Jun 26 18:24:28 2008 |
Yoichi | Update | PSL | FSS input ofset slider problem - fixed |
I checked the FSS servo interface board and found that a LT1125CSW used to differentialize offset channel was broken (no virtual short).
So I replaced it. Now the slider is working.
The op-amp was hitting the rail. So it seems like we had been applying the maximum offset to the FSS input all the time.
The reason why the FSS loop still worked with the large offset is that the applied offset (~14V) is attenuated by a factor of 500 at the summing point. |
|
574
|
Thu Jun 26 14:06:00 2008 |
Masha | Update | General | 500mW INNOLIGHT NPRO info |
Below is the placement of 500mW INNOLIGHT NPRO mephisto laser. It is set up on the Symmetric Port table.  |
|
573
|
Thu Jun 26 12:30:40 2008 |
John | Summary | Locking | CARM on REFL_DC |
Idea:
Try REFL_DC as the error signal for CARM rather than PO_DC.
Reasoning:
The PO signal is dominated by sideband light when the arms are detuned so that any misalignment in the recycling cavity introduces spurious signals. Also, the transfer function from coupled cavity excitation to REFL signal is not so steep and hence REFL should give a little more phase. Finally, the slope of the REFL signal should make it easier to hand over to RF CARM.
Conclusion:
The REFL signal showed no clear improvement over PO signals. We've gone back to PO.
During the night we also discovered that the LO for the MC loop is low. |
|
572
|
Thu Jun 26 10:56:15 2008 |
Max Jones | Update | PEM | Removed Magnetometer |
| I removed the Bartington Magnetometer on the x arm to one of the outside benches. I'll be trying to determine if and how it works today. It makes a horrible high pitched sound which is due to the fact that the battery is probably 16 yrs old. It still works with ac power though and I want to see if it is still operating correctly before I ask to buy a new battery. Sorry for the bother. |
|
571
|
Thu Jun 26 01:10:18 2008 |
rana | Update | PEM | Alarm Handler indicates that dust level is high |
In its first useful act, the Alarm Handler started beeping indicating that the dust particle
counts for particles of diameter less than 0.5 micron had exceeded 5000 /cu. ft. Here's the
80 day trend of particles, temperature and humidity: |
| Attachment 1: Untitled.png
|
|
|
570
|
Thu Jun 26 01:08:22 2008 |
rana | Configuration | General | Alarm Handler Revived |
I have revived the Alarm Handler by turning it on on op540m and adjusting the levels of
several of the alarming channels to not alarm (like laser power). The alarm levels are now
set to something reasonable and people should start actually paying attention to them.
I also removed the EO Shutter and Stacis alarm stuff since we don't use them.
To really get in and edit it, you have to close the Alarm Handler and edit the file
in /cvs/cds/caltech/alh/. It allows you to add/subtract useful channels and put in
guidance information.
If the alarm handler beeps about something, don't just close it or silence it, Steve. Just
fix it somehow (either set the threshold better or find the real cause). |
| Attachment 1: b.gif
|
|
|
569
|
Wed Jun 25 18:03:21 2008 |
Yoichi | Configuration | PSL | FSS Input Offset slider problem |
While working on the PMC scanning, I noticed that the FSS input offset slider is doing nothing.
I traced the signal flow and checked the cables/boards.
The slider changes the output voltage from a VMIVME4116 DAC in the PSL rack. This output voltage is confirmed to be correct at the FLKM64 connector. The signal is connected to the FSS servo interface box (D040423) trough a ribbon cable. However, the output from the interface box is always -27V regardless of the slider position.
Therefore, either the interface box (D040423) or the ribbon cable has a problem.
I will debug the interface box using an extension card when no one is working on the interferometer. |
|
568
|
Wed Jun 25 13:56:56 2008 |
John | Summary | Locking | Tuesday night locking |
Rob, John
Worked to try and reduce the CARM offset using the dc arm transmissions before changing to SPOB DC. This proved somewhat unsuccessful, the offset couldn't be reduced to more than five (arms storing 5x more power than single arm cavity lock). |
|
567
|
Wed Jun 25 13:38:22 2008 |
Koji | Update | General | Abs. Len. Meas. ~ Placement of the 700mW NPRO on the AP table |
This morning I have put the 700mW NPRO on the AP table for the abs length measurement.
The RF amplifier was moved (the cables were not changed). I cleaned up some cable arrangements. I was keen not to disturb any of the other optical path. Even so, please let me know if any suspicious behaviour is found on the AP table. |
| Attachment 1: NPRO700mW_placement.jpg
|
|
|
566
|
Wed Jun 25 12:25:28 2008 |
Eric | Summary | Cameras | 2D Gaussian Fitting Code |
I initially wrote a script in MATLAB that takes pictures of the laser beam's profile and fits them to a two dimensional gaussian in order to determine the position and width of the beam. This code is now (mostly) ported to C so that it can be imbedded in the camera software package that Joe is writing. The fitting works fairly well for pictures with the beam directly incident on the camera, and less well for pictures of scatter off the end mirrors of the arms, since scatter from defects in the mirror have intensities much greater than the intensity of the beam's gaussian profile.
The next steps are to finish up porting the fitting code to C, and then modify it so it can better handle the images off the end mirror. Some thoughts on how to do this are to use a fourier transform and a low pass filter, or to simply use a center-of-mass calculation (with the defect peaks reduced in intensity), since position is more important than beam width in this calculation. The eventual goal is to include the edge of the optic in the picture and use the fit of the beam position in comparison to the optic's position to find the beam's location on the mirror. |
|
565
|
Wed Jun 25 11:36:14 2008 |
Max Jones | Update | Computer Scripts / Programs | First Week Update |
For the first week I have been modifying the noise budget script in caltech/NB to run with 40 m parameters and data. As per Rana's instructions, I have tried to run the script with only seismic and Darm sources. This involves identifying and changing channel names and altering paramter files (such as NB/ReferenceData/C1IFOparams.m). To supply the parameter files, I have copied the H1 files with (as yet only) slight modification. The channel name changes have been made to mirror the sites for the most part. Two figures are attached which show the current noise budget. The Day plot was taken 6/23/08 at ~10:30 am. The night plot was taken 6/22/08 at ~11:00 pm . Note that the SRD curve is for the sites and not for the 40 m (I hope to change that soon). Also in one of the plots the DARM noise signal is visible. Obviously this needs work. A list of current concerns is
1) I am using a seismic transfer function made by previous SURF student Ryan Kinney to operate with channels of the form C1:PEM_ACC-ETMY_Y (should I be using C1:DMF-IX_ACCY?) and the channels I am currently using are the acceleraometers for the mode cleaner with names of the form C1:PEM_ACC-MC1_X. Rana said that he thinks these may be the same but I need to be sure.
2) We don't have a DARM_CTRL channel but the code requires it, currently I am using DARM_ERR as a substitute which is probably partly responsible for the obvious error in DARM noise.
Any suggestions are appreciated. Max. |
| Attachment 1: C1_NoiseBudgetPlot_Day.eps
|
|
| Attachment 2: C1_NoiseBudgetPlot_Night.eps
|
|