ID |
Date |
Author |
Type |
Category |
Subject |
822
|
Mon Aug 11 11:36:11 2008 |
josephb, Steve | Configuration | Computers | c1susvme1 minor problems |
Around 11 am c1susvme1 start having issues. Namely C1:SUS-PRM_FE_SYNC was railing at some large value like 16384 (2^14). I presume this means the computer was running catastophically late.
I turned off the BS and ITM watch dogs (the PRM was already off), tried hitting reset and sshing in, and running startup, but this didn't help. I then turned off the c1susvme2 associated watch dogs (MC1-3, SRM) and went out to do a hard reboot by switching the crate power off. c1susvme2 came back up fine, was restarted and associated watch dogs turned back on. However, c1susvme1 came back up without mounting /cvs/cds/.
As a test, I replaced the ethernet connection with a CAT6 cable to the Prosafe switch in 1Y6, and then ran reboot on c1susvme1. When it came back up, it had mounted properly, and I was able to run the ./startup.cmd file. At this point it seems to be happy. The new cable is in the trays coming in from the top of the 1Y4 and 1Y6 and approriately labeled.
Edit: Apparently ITMX and ITMY became excited after the reboot (perhaps I turned the watchdogs back on too early? Although that was after the DAQ light was listed as green for c1susvme). Steve noticed this when the alarms went off again (I had turned them off after the reboot seemed successful), and he damped them. Interestingly, the BS remained unexcited. |
823
|
Mon Aug 11 12:42:04 2008 |
josephb | Configuration | Computers | Continuing saga of c1susvme1 |
Coming back after lunch around 12:30pm, c1susvme1's status was again red. After switching off watchdogs, a reboot (ssh, su, reboot) and restarting startup.cmd, c1susvme1 is still reporting a max sync value (16384), occassionally dropping down to about 16377. The error light cycles between green and red as well.
At this point, I'm under the impression further reboots are not going to solve the problem.
Currently leaving the watchdogs associated with c1susvme1 off for the moment, at least until I get an idea of how to proceed. |
824
|
Mon Aug 11 13:59:23 2008 |
josephb | Configuration | Computers | |
While poking around the crate, I noticed an error light on one of the c1susvme2 related boards was lit, while the corresponding light on the c1susvme1 was not. This confuses me as the c1susvme1 is the one having problems.
As a quick sanity check, I unplugged the ethernet connection from the c1susvme1 labeled board, and confirmed I couldn't log into it, and then plugged it back in, restarted it, and re-ran the startup script. This time c1susvme1 seemed to come up fine. Re-enabling the watchdogs doesn't seem to kick anything, and in fact seems to be bringing everything into line properly.
Although the error light on the c1susvme2 clk drvr board is still on. So I'm not sure what thats trying to tell us. Open to suggestions. |
825
|
Mon Aug 11 15:07:49 2008 |
josephb | Configuration | Computers | Procyon aka fb40m switched to new switch |
I've connected Procyon to the Prosafe 24 port switch with a new, labeled Cat6 cable. Quick tests with dataviewer shows that its working. |
828
|
Tue Aug 12 12:21:13 2008 |
josephb | Configuration | Cameras | Variation in fit over 140 images for GC650 and GC750 |
Used matlab to calculate Gaussian fits on 145 GC650 images and 142 GC750 images. These were individual images (no averaging) looking at the PSL output from May 29th 2008. The GC650 and GC750 were looking at a split, but had different exposure values, slightly different distances to the nominal waist of the beam, and were not centered on the beam identically. Mostly this is a test of the fluctuations in the fit from image to image.
Note the mm refer to the size or position on the CCD or CMOS detector itself.
GC650
Mean
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.3743 1.7378 2.6220 0.7901 0.8650 0.0047
Standard Deviation
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.0024 0.0006 0.0005 0.0005 0.0003 0.00001
Std/Mean x100 (percent)
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.6% 0.03% 0.02% 0.06% 0.04% 0.29%
GC750
Mean
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.2024 2.5967 1.4458 0.8245 0.9194 0.0418
Standard Deviation
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.0011 0.0005 0.0005 0.0003 0.0005 0.00003
Std/Mean x100 (percent)
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.6% 0.02% 0.04% 0.04% 0.05% 0.07%
|
831
|
Wed Aug 13 17:00:59 2008 |
steve | Configuration | SUS | BS sat amp removed |
The PRM sat amp is broken. Ben is working on it.
The BS sat amp was removed from the BS sus and it is used with the PRM in
order to damp it for wire stand-off alignment. |
836
|
Thu Aug 14 19:08:14 2008 |
Yoichi | Configuration | SUS | Free swing measurement going on |
I started free swinging spectra measurement of all the suspensions now Aug 14 19:05 (PDT).
The watch dogs are all shutdown. Please do not turn them back on until tomorrow morning. |
839
|
Fri Aug 15 11:52:32 2008 |
josephb | Configuration | Cameras | Multi-computer display and recording of digital camera output |
Through the magic of gstreamer, I've been able to live play on one machine, compress the image, send it to another machine via udp, and also display it there. The "tee" function also allows one to save at the same images at time as well.
The command line used on the "server", say Rosalba or Mafalda is:
CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 100 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! tee name=t1 t1. ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! ximagesink t1. ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host="131.215.113.103" port=5000
This both displays the image and sends it to the host 131.215.113.103 in this case.
I've written a primitive shell script that does most of this.
It requires at the minimum an IP address. You can also give it a number of images (the -m number) and also the exposure value (-E 20000).
Currently in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/ there is a script called CameraServerScript.
Typing in "CameraServerScript 131.215.113.107" would send it to that IP address.
Typing in "CameraServerScript 131.215.113.107 500 40000" would run for 500 images at an exposure value of 40000.
To actually receive, you need gstreamer installed and run the following command:
gst-launch udpsrc port=5000 ! smokedec ! queue ! ffmpegcolorspace ! ximagesink sync=false
Make sure you have the right IP address to send to.
Still working on multicasting (basically a server is constantly sending out images, and the client subscribes to the multicast). |
843
|
Fri Aug 15 19:32:49 2008 |
steve | Configuration | VAC | pumpdown complete |
I have just reached vacuum normal. The maglev peaked at 49.8C body temp with aux fan on at 3.2 Torr
cc1 1e-4Torr
note: pumpdown was put on hold for Koji's goodby lunch |
Attachment 1: pdprm.jpg
|
|
844
|
Mon Aug 18 08:07:10 2008 |
Yoichi | Configuration | SUS | Suspension free swinging |
I've started a free swinging measurement of OSEM spectra now. Please leave the watchdogs untouched. |
847
|
Mon Aug 18 15:32:18 2008 |
josephb | Configuration | Cameras | How to multicast with gstreamer and Gige Cameras |
In order to get multicasting to work, one simply needs to understand the address scheme.
In general, the address range 224.0.0.0 - 239.255.255.255 are reserved for multicasting. Within in this address space, there are some base level operations in the 224.0.0.x range which shouldn't be interfered with.
For a single site, the address range between 239.252.0.0 and 239.255.255.255 is probably best.
Gstreamer and the current 40m network hubs are designed to handle this kind of communication already, so one merely needs to point them at the correct addresses.
While in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode type:
CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host=239.255.1.1 port=5000
This will multicast to the 239.255.1.1 address, using port 5000.
On the machine you wish to subscribe type:
gst-launch udpsrc multicast-group=239.255.1.1 port=5000 ! smokedec ! ffmpegcolorspace ! ximagesink sync=false |
852
|
Tue Aug 19 13:34:58 2008 |
josephb | Configuration | Computers | Switched c1pem1, c0daqawg, c0daqctrl over to new switches |
Moved the Ethernet connections for c1pem1, c0daqawg, and c0daqctrl over to the Netgear Prosafe switch in 1Y6, using new cat6 cables. |
857
|
Tue Aug 19 19:14:17 2008 |
Yoichi | Configuration | DAQ | Fixed C1:IOO-MC_RFAMPDDC |
Yoichi, Rob
C1:IOO-MC_RFAMPDDC, which is a PD at the transmission port of the MC, was not recording sensible values.
So I tracked down the problem starting from the centering of the beam on the PD.
The beam was hitting the PD properly. The DC output BNC on the PD provided +1.25V output when the light was
falling on the PD. The PD is fine.
The flat cable from the PD runs to the IOO rack and fed into the LSC PD interface card.
The output from the interface card is connected to a VMIC3113A DAQ card, through cross connects.
The voltages on the cross connects were ok.
The VMIC3113A was controlled by an EPICS machine (c1iool0). So it provides only a slow channel.
By looking at C1IOOF.ini and tpchn_C1.par, I figured that C1:IOO-MC_RFAMPDDC is using chnnum=13639 in the RFM
network and it is named C1:IOO-ICS_CHAN_15 in the .par file. So it is reading values from the ICS DAQ board.
Actually nothing was connected to the channel 15 of the ICS board and that was why C1:IOO-MC_RFAMPDDC was reading
nothing. So I took the PD signal from the cross connect and hooked it up to the Ch15 of the ICS DAQ through
the large black break out box with 4-pin LEMOs. Now C1:IOO-MC_RFAMPDDC reads the DC output of the PD.
I also put an ND filter in front of the RFAMPD to avoid the saturation of the ADC. The attenuation should have been done
electronically, but I was too lazy. Since the ND filter changes the Stochmon values, someone should remove it and reduce the
gain of the LSC PD interface accordingly.
|
865
|
Thu Aug 21 10:24:20 2008 |
steve | Configuration | SAFETY | laser safe mode condition |
The MOPA and PSL shutters are closed.
Manual beam blocks are in place.
Enclosure interlock is enabled.
No other high power laser is in operation.
We are in laser safe of operation for visiting students from Japan
NO safety glasses required
|
866
|
Thu Aug 21 16:28:59 2008 |
steve | Configuration | SAFETY | safety glasses required |
I just opened the MOPA shutter so PA is warming up.
High power beam path is cleared and laser safety glasses required. |
880
|
Mon Aug 25 14:42:09 2008 |
Eric | Configuration | Cameras | ETMX Digital Camera |
I changed the lens on the camera looking at the ETMX to a 16mm, 1:1.4 zoom lens. This is in preparation to measure a couple parameters that depend on the camera's position and angle, so please avoid repositioning it for a couple of days. |
883
|
Mon Aug 25 21:15:23 2008 |
rana | Configuration | LSC | aux NPRO off |
Looks like no one has used the Lightwave NPRO on the AS table after Koji left, so I turned it off so that it can rest until Alberto does the X-arm measurements. |
884
|
Tue Aug 26 09:04:59 2008 |
rana | Configuration | PSL | PMC Servo Board: Out for Repairs |
I've started modifying our PMC board to bring it up to the 21st century - leave the screen alone or else you might zap something. |
887
|
Tue Aug 26 15:06:16 2008 |
steve | Configuration | VAC | rga scan |
Pumpdown 66 PRM-maglev vac normal -day 11
short form: pd66PRM-m-d11 |
Attachment 1: RGA-0808260125.png
|
|
893
|
Thu Aug 28 18:56:14 2008 |
rana | Configuration | PSL | beam block distorted |
There was a beam block after the Mach Zender. Who or what put this there?
The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??
Use the ELOG people...its good for you. |
896
|
Fri Aug 29 10:20:32 2008 |
Yoichi | Configuration | PSL | beam block distorted |
Quote: | There was a beam block after the Mach Zender. Who or what put this there?
The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??
Use the ELOG people...its good for you. |
I put the block. I was frequently reaching to the FSS box to change the test point probes. I put the block to protect my hands/clothes from being burnt accidentally. |
897
|
Fri Aug 29 11:01:49 2008 |
josephb | Configuration | Computers | Attempt to change a channel gain in ICS-110B |
As noted earlier by Rana, I was playing around with the /cvs/cds/caltech/chans/daq/C1IOOF.ini file with help from Rob. I had made a backup before hand and saved it as C1IOOF.ini.Aug-28-2008. (I have since been informed that C1IOOF.ini.082808 would have been prefered as a name).
We had been trying to up the gain in the C1: PSL-ISS_INMONPD_F in order to do a very low power PMC sweep, in an attempt to get clean modes for fitting. Initially we pressed the reconfig button on the C0DAQ_DETAIL screen, but all that seemed to do was change the Config File CRC. We proceeded to reboot fb40m remotely. However, any change to the ini file (even an extra space at the end of the file) caused a 0x2000 status for C1IOVME16k on the C0DAQ_DETAIL screen. At the time I presumed it was comparing the CRC of the ini-file to something else.
Digging around on in Alex's webspace at http://www.ligo.caltech.edu/~aivanov/ , I found the NDS Access page, which indicated that 0x2000 was a conflict between the front-end and frame builder .ini files.
"There is also status bit 0x2000 which gets added when the DCU configuration is different in front-end and frame builder. That is you can change and .ini file an then reload DAQ configuration with Epics button, which reconfigures the front-end, but leaves frame builders with invalid old configuration. They will detect this change and set the status to 0x2000 to indicate this condition. You will have to restart frame builders to pick up new .ini file and set status back to zero for the affected DCU."
It was when I was going to try reseting the c1iovme via the C0DAQ_RFMNETOWRK medm screen that we realized the EPICS controls were not responding properly. The .ini file was returned to its original form, and mass reboots commenced. |
899
|
Fri Aug 29 12:41:26 2008 |
josephb, Eric | Configuration | Computers | More front ends moved to new network |
Used Cat6 cables to finish moving all the front ends in 1Y4 and 1Y5 over to the new GigE network switches, specifically to the switch in 1Y6. This included the ones labeled c1susvme2, c1sosvme, and c1dscl1epics0. |
902
|
Fri Aug 29 16:35:18 2008 |
Yoichi | Configuration | PSL | beam block distorted |
Quote: | There was a beam block after the Mach Zender. Who or what put this there?
The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??
Use the ELOG people...its good for you. |
The apparent distortion of the MC refl. was caused by mis-alignment of the MC mirrors.
Because the MC1 was mis-aligned, the reflected light was clipped by a steering mirror.
I restored the MC angle bias values from the conlog history and now the MC locks.
According to conlog, the MC alignment was changed at around 18:30 on Thursday PDT.
It could have been caused by the computer reboots. |
903
|
Fri Aug 29 17:39:25 2008 |
rana | Configuration | PSL | PMC: ADC Channels |
The attached PNG shows the PMC error and controls signals with no calibration.
There are 3 states:
DARK - RF input disabled & output blanked. This should be a measure of the ADC noise
(-10 dB) - This is with the gain slider down at 5 dB instead of the nominal 15 dB.
Looks like the Generic DAQ board whitening is good enough for these signal levels above ~1 Hz.
From the low and high gain spectra it also looks like the UGF is ~500 Hz with the gain at 15 dB. |
Attachment 1: mcf.png
|
|
906
|
Sat Aug 30 13:28:01 2008 |
rana | Configuration | PSL | PMC: List of changes |
This is a list of changes made to the PMC board while we had it out for modifying the notch:
- LC-LC 4th order low pass filter
- Replace the AD797 (U2) with an OP27. AD797's are bad - do not use them anywhere for any reason. The OP27 is slower and has a 3x worse input noise but doesn't compromise the bandwidth or noise performance of the PMC by any significant amount. The rule is: use OP27 everywhere unless you have a very good reason why not.
- There is no 'H1' jumper on board. R9 is 90.9 Ohms and R2=900 Ohms so that the U2 stage has a gain of 10.
- Cut a trace and inserted a 500 Ohm resistor between U2-pin6 and U5A-pin2 (the AD602). The AD602 has a 100 Ohm input impedance which cannot be driven without limiting by the AD797 or the OP27. The 500 Ohm resistor makes it a driveable load for low level signals which is all that should be there since its the error point of the servo. it also becomes a 6:1 voltage divider. Since the AD602 has a fixed output voltage noise of 100 nV/rHz, this will limit the noise performance if the VGA gain is less than 20 dB, but whatever.
- R11 7.87k -> 1.74k, R12 = 78.7k -> 700k. This increases the high frequency gain of that stage by 7.87/1.74 = 4.5 and lowers the low frequency pole from 2 to 0.2 Hz to give the PMC some more staying power at DC. The loop shape is now 1/f^2 in the 9-480 Hz band and so the phase dips enough to make it almost conditionally stable, but not quite.
- C26 changed from ??? + a 30 pF trim cap into a fixed NNN pF cap to set the notch frequency for the 14.5 kHz body mode that we measured. Once our brick configuration is more settled we can increase the Q of this notch from small to big.
- Grounded pin 5 of U14 & U15 (AD620). These have sometimes been used as "differential" drivers in LIGO by connecting this reference voltage pin to the remote ground of the next board. This has always lead to insidious oscillation and noise. This beauty also has an output noise of 100 nV/rHz. Just never use this chip if you can help it; we can make true differential drivers - we have the technology.
Of course, we didn't have a current version of a schematic sitting around so I printed out a Rev E schematic and marked it up with red pen. I'll post pictures later and put the schematic into the PSL schematics notebook. Would be useful to take the old schematic and update it in Acrobat so that we have something electronic. |
908
|
Mon Sep 1 19:23:17 2008 |
Yoichi | Configuration | PSL | FSS on an auxiliary loop |
Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.
Today, I did the 4th item of my TO DO list.
Using a mini-circuit mixer and two SR560s, I constructed an auxiliary servo loop for the reference cavity.
With this loop, I was able to lock the reference cavity without using the FSS box.
By locking the reference cavity with this auxiliary servo, I was able to measure the PC path transfer function.
I will post the analyzed results later.
I borrowed the PD RF and the LO signals from the main FSS loop by power splitters. Therefore, the gain of the main FSS loop
is now about 3dB low. I tried to compensate it by increasing the EOM modulation depth, but the PC path is still a bit noisy.
Probably the already too low LO power is now seriously low (the LO power cannot be changed from EPICS).
Because I did not want to leave the PC path with large output overnight (it will heat up the PA85, and might cause damage, though unlikely),
I disabled the FSS for now.
|
910
|
Tue Sep 2 09:58:42 2008 |
Yoichi | Configuration | PSL | FSS on an auxiliary loop |
Quote: | Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.
|
Now I removed the power splitters for the aux. reference cavity servo. The FSS is back and the MC locks.
I'm now returning one of the active high-impedance probes to the Wilson house. They need it today.
We are left with only one active probe. If anyone finds another active probe in the 40m lab.,
please let me know (according to Rana we should have one more). |
913
|
Tue Sep 2 22:43:16 2008 |
Yoichi | Configuration | PSL | Updated FSS open loop TF |
Since the LO level of the FSS servo was too low, I replaced the RF oscillator board with a combination of
a Stanford signal generator and an RF amplifier.
Right now, the POY RF amplifier is used for this purpose temporarily.
Now the LO level is about 16dBm. The RF power going into the EOM is attenuated by 20dB from the LO level.
I played with the cable length to get the phase right.
Then I was able to lock the FSS with the new RF signal source.
Attached is the open loop transfer function of the current FSS. Now the UGF is a bit above 200kHz, a factor of 2 improvement.
This gain was achieved with the common gain slider at 13.5dB and the fast gain = 30dB.
With the old RF oscillator board, UGF=100kHz was achieved with the common gain =30dB. Therefore, the increase of the LO gave
us a large signal gain.
Increasing the gain further, again ,makes the PC path crazy.
Rich suggested that this craziness was caused either by the slew rate limit of the PA85 or the output voltage limit of the bypass Op-amp(A829)
is hit.
TO DO:
* Look at the error signal spectrum to see if there is any signal causing the slew rate saturation at high frequencies.
* Find out what the RF signal level for the EOM should be. 20dB attenuation is an arbitrary choice.
* Find out the cross over frequency. Determine where the fast gain slider should be.
etc ... |
Attachment 1: OPLTF.png
|
|
915
|
Wed Sep 3 18:43:19 2008 |
Yoichi | Configuration | Electronics | Two more active probes |
I found two active probes, an HP41800A and a Tektronix P6201.
Thanks John for telling me you saw them before.
Now we have three active probes, wow !
We have to find or make a power supply for P6201.
The manual of the probe is attached. |
Attachment 1: Tektronix-P6201-active-probe.pdf
|
|
916
|
Wed Sep 3 18:45:01 2008 |
Alberto | Configuration | | PD3 gain |
Alberto, Yoichi,
We found that the PD3 servo was unstable with a gain of 1, so we switched it to 0.5 |
922
|
Thu Sep 4 11:33:25 2008 |
josephb, Eric, Jenne | Configuration | Computers | Attempt to increase gain for C1:PSL-ISS_INMONPD_F via 110B |
We were attempting to increase the gain on the channel C1:PSL-ISS_INMONPD_F in preparation to do a scan of the PMC at very low input power.
We started by adding a line to the C1:IOOF.ini file in /cvs/cds/caltech/chans/daq/ under that channel that said "gain=10.0". Before touching anything, the channel was outputting around 4000 counts.
We hit the reconfig button for c1iovme16k, then rebooted c1iovme (which turned out to do nothing) and then the framebuilder, in a method consistent with the wiki. This turned out to put the channel in an odd state, where it was showing very rapid, random spikes, virtually but still around 4000ish counts. We returned the file back to its original format, hit reconfig, and then rebooted the framebuilder. The channel however, was still behaving in the same broken way.
After poking around the PSL table, looking at some direct outputs, we came back and rebooted c1iovme and the framebuilder again, which fixed the channel, such that it was reading out correctly. Taking this as a sign that maybe we should reboot the framebuilder, then c1iovme to get the channel to load changes, we changed the file again to have "gain=10.0". Upon reboot of the framebuilder, the channel was still reading out fine, but at the same level. So we continued with the reboot of c1iovme. This still had no effect on the channel output.
The ini file has been set back at this point, however since Yoichi is working, I'm holding off doing a reconfig and reboot on the framebuilder until later. |
925
|
Thu Sep 4 16:24:56 2008 |
rana | Configuration | Computers | Attempt to increase gain for C1:PSL-ISS_INMONPD_F via 110B |
Quote: | We were attempting to increase the gain on the channel C1:PSL-ISS_INMONPD_F in preparation to do a scan of the PMC at very low input power.
|
According to the Wikipedia, certain esoteric mathematical
operations lead to the result that 4000 x 10 > 32768. |
930
|
Thu Sep 4 18:02:34 2008 |
rana, josephb | Configuration | PEM | Accelerometer gains increased by 10 |
We increased the Accelerometer gains by 10 by modifying the C1ADCU_PEM.ini file.
[C1:PEM-ACC_MC1_X]
chnnum=15014
gain = 10
etc.
The plot shows the before and after for one channel. The ADC noise floor is ~10^-2 counts/rHz in this plot so now
we can do much better noise subtraction. |
Attachment 1: acc.png
|
|
932
|
Fri Sep 5 09:56:14 2008 |
josephb, Eric | Configuration | Computers | Funny channels, reboots, and ethernet connections |
1) Apparently the I00-ICS type channels had gotten into a funny state last night, where they were showing just noise, exactly when Rana changed the accelerometer gains and did major reboots. A power cycle of the c1ioo crate and appropriate restarts fixed this.
2) c1asc looks like it was down all night. When I walked out to look at the terminal, it claimed to be unable to read the input file from the command line I had entered the previous night ( < /cvs/cds/caltech/target/c1asc/startup.cmd). In addition we were unable to telnet in, suggesting an ethernet breakdown and inability to mount the appropriate files. So we have temporarily run a new cat6 cable from the c1asc board to the ITMX prosafe switch (since there's a nice knee high cable tray right there). One last power cycle and we were able to telnet in and get it running. |
937
|
Mon Sep 8 15:38:57 2008 |
Yoichi | Configuration | PSL | POY RF amp is back to its original task |
I temporarily fixed the busted ZHL-32A RF amplifier's power connector by simply soldering a cable to the internal circuit and pulling the cable out of the box through a hole for the power connector.
So I released the POY RF amplifier from the temporary duty of serving the FSS RF distribution and put it back to the original task,
so that Rob can finally re-start working on the lock acquisition.
Now the temporarily fixed ZHL-32A is sitting next to the IOO rack along with the power supply and a Stanford signal generator.
Please be careful not to topple over the setup when you work around there. They will be there until Peter's Wentzel RF box arrives. |
941
|
Thu Sep 11 11:29:14 2008 |
josephb | Configuration | Computers | Final netgear switch in place in 1Y2 |
I've placed the final (of 4) Netgear prosafe 24 port switch at the very top of 1Y2. At that location, there are no holes left to screw into, so it has 4 rubber feet and is sitting on the top most signal generator. It has been plugged in and connected to the control room hub with a labeled cat6 ethernet cable.
Its IP address has been set to 131.215.113.253, and has the usual controls password if using the "Smart Wizard Discovery Tool" which comes on the Netgear CD. The CD can be found in the Equipment manuals filing cabinet under Netgear. This program unfortunately only runs on a window PC.
To Do: Fix the C1:ASC ethernet connection which is currently coming straight out the front door and connected to the 1X4 switch (again through the front door). |
948
|
Mon Sep 15 14:00:52 2008 |
josephb | Configuration | Computers | 1Y9 Hub and C1asc |
The 1Y9 switch is now using a labeled Cat6 cable in cable trays to connect to the main switch in the offices. In addition, the c1asc cable which had been coming out the door was fixed last Friday, and is now labeled, going out the top and connects to the hub in 1Y2.
Note: Do not connect new ethernet cable from switch to switch without disconnecting the old cable to the rest of the network - this tends to make the Ethernet network unhappy with white flashing alarms. |
949
|
Tue Sep 16 10:57:45 2008 |
Yoichi | Configuration | PEM | Particle counter gain |
Summary:
Since we reduced the integration time of the particle counter by a factor of 10, we had to add a gain of 10
to the EPICS channels C1:PEM-count_full and C1:PEM-count_half.
I asked Alex to change it and he did it. I forgot to ask him to change the gain of C1:PEM-count_half. So now only
C1:PEM-count_full has x10 gain.
Detail:
C1:PEM-count_full and C1:PEM-count_half are 'Soft Channel' records in the database (Pcount.db). The values are actually
written into the VAL fields directly by an SNL code Particle.o.
Particle.o reads data from the RS-232C port, to which the particle counter is connected. Then it parses the data and put values
into relevant EPICS channels using channel access. This means we cannot change the gain of the channels by modifying the
database file. For example, ASLO field does not have any effect when the value is directly written into the VAL field.
We had to modify the SNL code. Alex modified Particle.st and the new SNL object file is Particle_x10.o sitting in
/cvs/cds/caltech/target/c1psl/. I modified seq.load so that c1psl loads Particle_x10.o when rebooted.
The source code for the old Particle.st can be found on lesath.ligo.caltech.edu in
/export/CDS/d/epics/apple/Caltech/40mVac/40mVacScipe/dev/src
I asked Alex to disclose the location of the source of the new code.
In order to compile the SNL code into an object file for Motorola CPU by ourselves, we have to call Dave Barker at LHO. |
950
|
Tue Sep 16 13:04:22 2008 |
Yoichi | Configuration | PEM | C1:PSL-FSS_RMTEMP alarm level changed |
At the request of Steve, I modified the HIGH value of C1:PSL-FSS_RMTEMP from 21.27 to 23.0.
The HIHI is set to 23.50. |
951
|
Tue Sep 16 16:47:01 2008 |
pete | Configuration | PSL | Prototype FSS reference installed |
After verifying output, I installed the new prototype 21.5 MHz FSS reference (Wenzel crystal oscillator and ZHL-2 amp). Yoichi and I successfully locked the MC, and have left the new reference in place. It's temporarily sitting on the corner of the big black optics table (AP table?). |
952
|
Wed Sep 17 12:55:28 2008 |
rob | Configuration | IOO | MC length |
I measured the mode cleaner length last night:
SR620 Marconi
199178070
165981524 165981725
132785380
33196345
I did the division in Marconi-land, rather than SR620-land.
If someone wants to do this in SR620-land, feel free to do it and post the numbers. |
954
|
Wed Sep 17 13:43:54 2008 |
Yoichi | Configuration | PSL | RC sweep going on |
I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over. |
957
|
Wed Sep 17 15:22:31 2008 |
Yoichi | Configuration | PSL | RC sweep going on |
Quote: | I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over. |
The measurement is still going on.
I will post an entry when it is done.
Thank you for the patience. |
959
|
Wed Sep 17 17:58:35 2008 |
Yoichi | Configuration | PSL | RC sweep going on |
The cavity sweep is done. The IFO is free now. |
965
|
Thu Sep 18 14:36:54 2008 |
josephb | Configuration | Computers | Name server and Epics |
The problems Rob was experiencing last night was due to part of the setup (or rather testing of the setup) of the new nameserver running on linux1.
The name server was setup on linux1 by doing the following:
1) Installed xorg-x11-xauth via yum which was necessary to get remote x windows to work in linux1
2) Installed xorg-x11-fonts-Type1 in order to get the gui system-config-* programs to work
3) Ran system-config-bind, which created a default set of nameserver files. I unfortunately didn't understand the gui all that well, so I manually edited and added files to these base ones. The base files were generated in /var/named/chroot/etc/ and /var/named/chroot/var/named.
4) I added martian.zone and 113.215.131.in-addr.arpa.zone, named.conf.local, and edited named.conf so it loaded named.conf.local. The martian.zone file acts a forward look up (i.e. give it a name and it returns an IP number like 131.215.113.20). The 113.215.131.in-addr.arpa.zone acts as a reverse look up (i.e. give it an IP number like 131.215.113.20 and it tells you the name). The file named.conf.local merely points to these two files.
Note: One can add or change IP lookup by simply updating these two files. The format should be obvious from the files.
5) I specifically ssh'd in as root to linux1 (using su wasn't sufficient) and then typed "service named start" (without quotes). You can also use "restart" or "stop" instead of "start". This started the name server, giving an [Ok] message.
6) I edited the /etc/resolve.conf file on linux1 so that it pointed to itself first ("nameserver 127.0.0.1" at the top of the file). I also added the line "search martian", which allows one to simply use linux1 as opposed to linux1.martian.
I also edited the /etc/resolve/conf file on linux2, and it seems to resolve names fine.
7) And here is where I broke things. As a test, I moved /etc/hosts to /etc/hosts.bak, and then tested to see if names were being resolved correctly. By using the command host, I determined they were in fact working. I also tested with ssh.
However, something basic didn't like me moving the hosts file. Apparently when a front-end machine needed to reboot, it wouldn't come back up, without any ability to SSH or telnet into them.
With Yoichi and I did quite a bit of debugging this morning and determined the nameserver itself isn't conflicting, merely the lack of the host file was the source of the problem. One theory is that services don't know to go to DNS to resolve host names. I think by modifying the /etc/nsswitch.conf file to include dns as an option for services and other programs, it might work without the host file, however, I'm going to leave that to tomorrow morning which is less likely to interfere with current operations.
As it stands, things are working with the nameserver running and the host file in place. |
973
|
Fri Sep 19 11:21:45 2008 |
josephb | Configuration | Computers | Nameserver and Rosalba |
I tried modifying the nsswitch.conf file to include going to dns in addition to local files for everything (services, network, etc) and then moving the /etc/hosts file to /etc/hosts.bak. Unfortunately, this still didn't allow front-ends to reboot properly. So I'm not sure what is using the hosts file, but whatever it is, is apparently important. After the test I placed the hosts file back and reverted the nsswitch.conf file.
I also noticed that Rosalba was having problems connecting to the network. This apparently was because I had shut down the dhcp server on the NAT router, as had been discussed at the meeting on Wednesday.
To fix this, I modified the /etc/sysconfig/network-scripts/ifcfg-eth1 file to fix rosalba's ip as 131.215.113.24 (which doesn't seem to be in use). I also updated rosalba's /etc/resolv.conf file to point at linux1's name server, and two additional name servers as well, and added the "search martian" line. I modified the /etc/sysconfig/network-scripts/ifcfg-eth0 file so the built in network card doesn't come up automatically, since its currently not plugged into anything. Lastly, I added rosalba and its IP to linux1's name server files. |
980
|
Mon Sep 22 21:30:06 2008 |
rana | Configuration | PSL | bad FSS |
The MC refl power was going up and the FSS PC drive was so large that I had to turn up the FSS
common gain from 1.5 dB to 10.5 dB to get it to be better. Attached are the before (REF) and
after plots of frequency noise. Is the FSS gain really supposed to be 1.5 dB?? How did we gain
so many dB's of optical gain? Is there a loop measurement from after Peter's oscillator change? |
Attachment 1: DAQ.png
|
|
982
|
Mon Sep 22 22:24:19 2008 |
rana | Configuration | PSL | bad FSS |
Quote: | The MC refl power was going up and the FSS PC drive was so large that I had to turn up the FSS... |
Looks like I bumped the PS for the 21.5 MHz test setup and changed the supply voltage of the amplifier
from +24 to +38 V. This made the amplifier go hot after a few hours and the output eventually dropped.
Yoichi and I walked out there now and it was too hot to touch. We turned it off and put it on a heat
sink to make it chill out and it came back after a few minutes. We have set the input to the amp to
be -7 dBm instead of -8 dBm after deciding that we should take into account the 1 dB loss in the cable
run and deliver a real +17 dBm to the mixer.
The right way is to calibrated the LO mon of the FSS. |
986
|
Tue Sep 23 15:28:06 2008 |
pete | Configuration | PSL | new 21.5 MHz FSS reference installed |
The new 21.5 MHz FSS reference is now installed in the rack with the 7 Sorensen PS. Both outputs give 18.7 dBm. The MC seems happy.
Bob did the +24 V and +15 V hookups for the amp and the Wenzel oscillator respectively, off of the din strips on the right of the rack.
I have attached two photographs. One shows the front of the box as mounted in the rack, and the other shows the inside of the box. From the second photo the circuit is apparent. Black wire coming in has ground, green has +15, and white has +24. After the switches, ground and +15 go to the Wenzel crystal oscillator, and ground and +24 go to the mini-circuits amp. There is 5 dB attenuation between the Wenzel 21.5 MHz output and the amp input. There is 3 dB attenuation between the amp output and the splitter.
The Wenzel crystal oscillator is their "streamline" model, and puts out 13.2 dBm. The amp is mini-circuits ZHL-2. |
Attachment 1: fss_ref_001.jpg
|
|
Attachment 2: fss_ref_013.jpg
|
|