40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 321 of 344  Not logged in ELOG logo
ID Date Author Typedown Category Subject
  495   Sun May 25 16:20:27 2008 ranaConfigurationComputersjoinPDF
I have installed joinPDF 2.1 on rosalba. Since its written in Java, I didn't have to tinker with it at all to work on a 64-bit machine. Now Caryn can put all of her plots into 1 file.
  498   Sun May 25 21:14:14 2008 tobinConfigurationComputersEPICS proxy server
I set up an EPICS gateway server on Nodus so that we can look at 40m MEDM screens from off-site.
The gateway is set up to allow read access to all channels and write access to none of them.

The executable is /cvs/cds/epics/extensions/gateway; it was already installed. A script to start
up the gateway is in target/epics-gateway. For the time being, I haven't set it up to start itself
on boot or anything like that.

To make it work, you have to set the environment variable EPICS_CA_ADDR_LIST to the IP address of
Nodus. For instance, something like this should work:

setenv EPICS_CA_ADDR_LIST 131.215.115.52

On Windows you can set up environment variables in the "System" Control Panel. On one of the tabs
there's a button that lets you set up environment variables that will be visible to all programs.

On Andrey's machine I installed the Windows EPICS extensions, i.e. MEDM and its friends. I also
installed the cool Tortoise SVN client which lets you interact with SVN repositories through
the windows explorer shell. (The right-click menu now contains SVN options.) I checked out
the MEDM directory from the 40m SVN onto the desktop. You should be able to just right-click in
that window and choose "SVN Update" to get all the newest screens that have been contributed to
SVN; however, there are currently some problems with the 40m SVN that make that not go smoothly.

At the moment on Andrey's (Windows) machine you can go into the MEDM folder and double-click on
any screen and it will just work, with the exception that not all the screens are installed
due to SVN difficulties.
  500   Tue May 27 16:24:54 2008 tobinConfigurationComputer Scripts / Programsndsproxy
The NDS Proxy is a program that accepts NDS (LIGO Network Data Server) connections from the internet and relays them to
our internal frame-builder, so that you can get DAQ and test-point channel data from off-site.

I stopped the ndsproxy that was running on rana and started it on nodus, its new home. This will be
documented in the wiki.

So far I haven't found a mechanism by which the ndsproxy was restarted automatically on rana. Has it just been
restarted by hand?

The ndsproxy stuff lives in target/ndsproxy. Restarting it seems to be just a matter of running "start_ndsproxy" in
that directory.
  501   Wed May 28 12:51:32 2008 josephbConfigurationComputersTwo more switches mounted
Two more Prosafe 24 port switches have been mounted in the racks, one in 1Y9 and one in 1Y6. (The first one was placed in 1X4).

The one in 1Y9 has been set to an IP address of 131.215.113.251, while the one in 1Y6 is set to 131.215.113.252, and these have been labeled as such.
  506   Fri May 30 12:03:08 2008 josephb, AndreyConfigurationCamerasHead to head comparison of cameras
Andrey and myself - Joseph B. - have examined the output of the GC650 (CCD) and GC750 (CMOS) prosilica cameras. We did several live motion tests (i.e. rotate the turning mirror, move and rotate the camera, etc) and also used a microscope slide to try to eliminate back reflections and interference.

Both the GC650 and GC750 produce dark lines in the images, some of which look parallel, while others are in much stranger shapes, such as circles and arcs.

Moving the GC750 camera physically, we have the spot moving around, with the dark lines appearing to be fixed to the camera itself, and remain in the same location on the detector. I.e. coming back to the same spot keeps showing a circle. In reasonably well behaved sections, these lines are about 10% dips in power, and could in principle be subtracted out. Its possible that the camera was damaged with too much light incident in the past, although going back to the pmc_trans images that were taken, similar lines are still visible.

Moving the GC650 camera physically seems to change the position of the lines (if one also rotates the turning mirror to get to the same spot on the CCD). It seems as if a slight change in angle has a large effect on these dark bands, which can either be thin, or very large, bordering on the size of the spot size. My guess is (as the vendor suggested) the light is interacting with the electronics behind the surface layer rather than a surface defect producing these lines. Using a microscope slide in between the turning mirror and the GC650, we were able to produce new fringes, but didn't affect the underlying ones.

Placing a microscope slide in between the last turning mirror and the GC750 does not affect the dark lines (although it does seem to add some), nor does turning the final turning mirror, so it seems unlikely to be caused by back reflection in this case.

So it seems the CMOS may be more consistent, although we need to determine if the current line problems are due to exposure to too much light at some point in the past (i.e. I broke it) or they come that way from the factory.

Attached are the results of image-processing of the images from the two our cameras using Andrey's new Matlab script.
Attachment 1: Waveform_Reconstruction_May30-2008.pdf
Waveform_Reconstruction_May30-2008.pdf Waveform_Reconstruction_May30-2008.pdf Waveform_Reconstruction_May30-2008.pdf Waveform_Reconstruction_May30-2008.pdf Waveform_Reconstruction_May30-2008.pdf Waveform_Reconstruction_May30-2008.pdf
  508   Fri May 30 21:30:15 2008 tobinConfigurationComputerssvn on solaris
I installed svn on op440m.  This involved installing the following packages from sunfreeware:

apache-2.2.6-sol9-sparc-local  libiconv-1.11-sol9-sparc-local   subversion-1.4.5-sol9-sparc-local
db-4.2.52.NC-sol9-sparc-local  libxml2-2.6.31-sol9-sparc-local  swig-1.3.29-sol9-sparc-local
expat-2.0.1-sol9-sparc-local   neon-0.25.5-sol9-sparc-local     zlib-1.2.3-sol9-sparc-local
gdbm-1.8.3-sol9-sparc-local    openssl-0.9.8g-sol9-sparc-local

The packages are located in /cvs/cds/caltech/apps/solaris/packages.  The command line to install
a package is "pkgadd -d " followed by the package name.  This can be repeated on nodus to get
svn over there.  (Kind of egregious to require an apache installation for the svn _client_, I 
know.)
  509   Sun Jun 1 19:25:10 2008 ranaConfigurationComputersnew monitor on op440m
I installed the new 24" flat screen on op440m. I increased the screen resolution from 1280x1024 to 1900x1200 using
the obscure 'fbconfig' command. You can type Google it if you want.

The old monitor is on the surplus cart. If you are reading this and think you might walk from the 40 over to
Bridge, please wheel the cart full of old computer equipment (on the north side of the control room) over to Larry.

I also copied over all the images on the D40 to a folder on Kirk's computer and deleted the originals.

Dan Busby also visited us last week to help us move the drill press from the Y arm down into the sub basement
of W Bridge.
Attachment 1: Andrey-440.jpg
Andrey-440.jpg
Attachment 2: Busby08.jpg
Busby08.jpg
  510   Sun Jun 1 19:39:35 2008 tobinConfigurationComputerselog, etc
Phil Ehrens gave me a DVD of the 40m elog, apache, and (Jamie's) SVN archive.
I copied it to nodus:/home/controls/dvd-from-ehrens.  Once we get the elog
running on nodus, we can copy the datafile over again from dziban (so that
we don't lose any elog entries) and switch over.
  513   Tue Jun 3 10:19:45 2008 tobinConfigurationComputersbig machine
Several of us transported the big new awesome Sun box from Bridge over to
the 40m last week. If I recall correctly, it's a SunFire X4600 with
something like sixteen 64-bit AMD processor cores at 2.8 GHz. It sounds
like a jet engine when it starts up (before the cooling fans are throttled
back) and has four power supplies (each with its own connection
to the wall). It has slick removable hard disks and fan units too. Our
working name for it is "megatron".

Anyway. It came with two hard disks, one with Solaris 10 installed. I took
the other hard disk over to Alex, who copied a Realtime Linux installation
onto it. Alex says it boots and runs fine.

It remains for you guys to install the machine onto rails and install the
whole thing into a rack. Before it goes into service as a realtime control
machine, you might as well install Matlab on it and do some heavy-duty
computation.

  514   Tue Jun 3 10:40:27 2008 tobinConfigurationComputersnew dataviewer
Alex let me know the secret location of the latest dataviewer executable for Linux. It is:

http://www.ligo.caltech.edu/~aivanov/upload/dv/Control/dc3

If your linux dataviewer on linux2 has the "year field not filled in" bug, you should download this into /usr/local/bin/dc3 (after making a backup of that file).

It looks like there's no dataviewer installed on rosalba yet. We should figure out a better directory layout for the linux machines; currently dataviewer is installed locally on linux2. It should be in /cvs/cds/caltech/apps/linux/something so that all the linux machines see the same installation.
  517   Wed Jun 4 13:46:42 2008 josephbConfigurationCamerasChanging incident angle images
Attached are images from the GC650 and GC750 when the incident angle was varied from 0 tilt (normal incidence) to 5,10, and 20 degrees. Each time the beam was realigned via the last turning mirror to be on roughly the same spot. This light was a pickoff of the PSL table light just before it leaves the table.

Images include the raw data, fit to the data, residual normalized by peak power "w(1)", and normalized by the individual bin power.

The first pdf includes 0 degrees (normal) and ~5 degrees of tilt for the GC650 (CCD) camera.

The second pdf includes ~10 and ~20 degrees of tilt images for the GC650 (CCD) camera.

The third pdf includes 0 and ~5 degrees of tilt for the GC750 (CMOS) camera.

The fourth pdf includes ~10 and ~20 degrees of tilt for the GC750 (CMOS) camera.

Things to note:
1) GC750 camera seems to have a structure on the camera itself, somewhat circular in nature. One possible explanation is the camera was damage at a previous juncture due to too much light. Need to check earlier images for this problem.
2) GC650 has "bands" which change direction and thickness with angle. Also at higher incidence angle, the sensitivity seems to drop (unlike the GC750 where overall power level seems to stay constant with increasing angle of incidence).
3) GC650 seems to have a higher noise floor,seen from the last plot of each pdf (where each pixel of the residual is normalized by the power in the corresponding pixel of the fit).
Attachment 1: GC650_0dg_5dg.pdf
GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf
Attachment 2: GC650_10dg_20dg.pdf
GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf
Attachment 3: GC750_0dg_5dg.pdf
GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf
Attachment 4: GC750_10dg_20dg.pdf
GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf
  519   Wed Jun 4 16:57:12 2008 josephbConfigurationCamerasDark images from cameras (electronics noise measurement)
The attached pdfs are 1 second and 1 millisecond long integrations from the GC650 and GC750 cameras with a cap in place - i.e. no light.

They include the mean and standard deviation values.

The single bright pixel in the 1 second long exposure image for the GC650 seems to be a real effect. Multiple images taken show the same bright pixel (although with slightly varying amplitudes).

The last pdf is a zoom in on the z-axis of the first pdf (i.e. GC650 /w 1 sec exposure time).

I'm not really sure what to make of the mean remaining virtually fixed for the different integration times for both cameras. I guess 0 is simply offset, but doesn't result in any runaway integrations in general. Although there are certainly some stronger pixels in the long exposures when compared to the short exposures.

Its interesting to note the standard deviation actually drops from the long exposure to the short exposure, possibly influenced by certain pixels which seem to grow with time.

The one with the least variation from its "zero" was the 1 millisecond GC750 dark image.
Attachment 1: GC650_1sec_dark.pdf
GC650_1sec_dark.pdf
Attachment 2: GC650_1msec_dark.pdf
GC650_1msec_dark.pdf
Attachment 3: GC750_1sec_dark.pdf
GC750_1sec_dark.pdf
Attachment 4: GC750_1msec_dark.pdf
GC750_1msec_dark.pdf
Attachment 5: GC650_1sec_dark_zoom.pdf
GC650_1sec_dark_zoom.pdf
  520   Thu Jun 5 10:46:26 2008 josephbConfigurationCamerasApproximately uniform reflected white light
In an attempt to investigate the structures seen in previous images for the GC750, I aimed it at a relatively clean section of gray table top roughly a cm or two from the surface and took images (without a lens). As I was holding this with my hand, the angle wasn't completely even with the table, and thus there's a gradient of light in the pictures. However, one should in principle be able to pick out features (such as a circular spot with less sensitivity), but these do not show up.

In my mind, these images seem to indicate the electronics are fine, and suggest that the CMOS or CCD detectors themselves are undamaged (at least in regards to white light, as opposed to 1064nm). An issue with the plastic cap (protective piece) may be the culprit, or perhaps a tiny bit of dust, which the incoherent light from all angles goes around efficiently?

Will try blowing the cameras with clean nitrogen today and see if that removes or changes the circular structure we have seen.
Attachment 1: GC650_white_light.pdf
GC650_white_light.pdf
Attachment 2: GC750_white_light.pdf
GC750_white_light.pdf
  521   Thu Jun 5 13:35:23 2008 josephbConfigurationCamerasGC750 looking at 1064nm scattered light
I've taken 200 images of the GC750 (CMOS) camera while holding it by hand up to a beam card (also held by hand) in the path of ~5mW of beam power. I then averaged the images to produce the fourth attached plot.

Rob has pointed out the image looks a lot like PCB traces. So perhaps we're seeing the electronics behind the CMOS sensor?

I repeated the same experiment with HeNe laser light (again scattered off a card). These show none of the detailed structure (just what looks to be a large reflection from the card moving around depending on how steady my hand was). These are the first 3 attached plots. So only 1064nm light so far sees these features.

As a possible solution, I did a quick and dirty calibration by dividing a previous PSL output beam by the 1064 average scatter light values. These produce the last attached pdf (with multiple images). The original uncalibrated image is on top, while the very simply calibrated image is on the bottom of each plot.

It seems as the effect may be power dependent (which could still be calibrated properly, but would take a bit more effort than simply dividing), as determined by looking at the edges of the calibrated plot.
Attachment 1: GC750_HeNe_scatter_avg.pdf
GC750_HeNe_scatter_avg.pdf
Attachment 2: GC750_HeNe_scatter_avg2.pdf
GC750_HeNe_scatter_avg2.pdf
Attachment 3: GC750_HeNe_scatter_avg3.pdf
GC750_HeNe_scatter_avg3.pdf
Attachment 4: GC750_scatter_avg.pdf
GC750_scatter_avg.pdf
Attachment 5: GC750_nitrogen_white.pdf
GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf GC750_nitrogen_white.pdf
  525   Fri Jun 6 16:47:04 2008 josephbConfigurationCameras GC650 scatter images of 1064nm light
Took images similar to the scattered light images from earlier, except with the CCD GC650 camera. The first three attached plots are an average of all 200 images, an average of the first 100 and then an average of the last 100 images.

They show no definite structure. The big red blob which changes with time may be a brighter reflection, although it virtually the same type of setup as the GC750 images.

To do this properly, I should grab a short focal length lens and simply blow up the beam to a size greater than the detector area and simply fix both cameras looking into.

The last set of plots are mean and standard deviation plots from a previous set of runs on 5/29/08 with the GC750 and GC650 running at the same time. The GC650 was receiving approximately 33% of the total power and GC750 was receiving 66% (in otherwords a factor of 2 more).
Attachment 1: GC650_scatter_200.pdf
GC650_scatter_200.pdf
Attachment 2: GC650_scatter_100a.pdf
GC650_scatter_100a.pdf
Attachment 3: GC650_scatter_100b.pdf
GC650_scatter_100b.pdf
  526   Mon Jun 9 17:32:14 2008 YoichiConfigurationPSLPMC transmittance
I checked the current PMC transmissivity at a low power.
The input laser power to the PMC was reduced to 75mW by rotating the HWP in front of the PBS.
In this configuration, the output power from the PMC was 50mW. So the transmittance is about 66%.
The reading of C1:PSL-PMC_PMCTRANSPD is now 0.1 whereas it was 2.7 before turning the power down.

I will check the transmittance at a higher power when I get the cable for the 35W calorie meter, which is missing now.
  527   Mon Jun 9 17:57:59 2008 YoichiConfigurationPSLPMC input power backed to the original
I rotated back the HWP before the PBS to restore the input laser power to the PMC.
Now the reading of PSL-PMC_PMCTRANSPD is 2.7.
  530   Wed Jun 11 15:30:55 2008 josephbConfigurationCamerasGC1280
The trial use GC1280 has arrived. This is a higher resolution CMOS camera (similar to the GC750). Other than higher resolution, it has a piece of glass covering and protecting the sensor as opposed to a plastic piece as used in the GC750. This may explain the reduced sensitivity to 1064nm light that the camera seems to exhibit. For example, the image averages presented here required a 60,000 microsecond exposure time, compared to 1000-3000 microseconds for similar images from the GC750. This is an inexact comparison, and the actual sensitivity difference will be determined once we have identical beams on both cameras.

The attached pdfs (same image, different angles of view) are from 200 averaged images looking at 1064nm laser light scattering from a piece of paper. The important thing to note is there doesn't seem to be any definite structure, as was seen in the GC750 scatter images.

One possibility is that too much power is reaching the CMOS detector, penetrating, and then reflecting back to the back side of the detector. Lower power and higher exposure times may avoid this problem, and the glass of the GC1280 is simply cutting down on the amount passing through.

This theory will be tested either this evening or tomorrow morning, by reducing the power on the GC750 to the point at which it needs to be exposed for 60,000 microseconds to get a decent image.

The other possibility is that the GC750 was damaged at some point by too much incident power, although its unclear what kind of failure mode would generate the images we have seen recently from the GC750.
Attachment 1: GC1280_60000E_scatter_2d.pdf
GC1280_60000E_scatter_2d.pdf
Attachment 2: GC1280_60000E_scatter_3d.pdf
GC1280_60000E_scatter_3d.pdf
  545   Thu Jun 19 15:52:06 2008 AlbertoConfigurationComputersMeasure of the current absorbed by the new Megatron Computer
Together with Rich Abbot, sam Abbot and I measured the current absorbed by the new Megatron computer that we installed yesterday in the 1Y3 rack. The computer alone absorbs 8.1A at the startup and then goes down to 5.9A at regime. The rest of the rack took 5.2A without the computer so the all rack needs 13.3 at the startup and the 11.1A.

We also measured the current for the 1Y6 rack where an other similar Sun machine has been installed as temporary frame builder and we get 6.5A.


Alberto, Rich and Sam Abbot
  558   Tue Jun 24 17:12:10 2008 josephb, EricConfigurationCamerasGC750 setup, 1X4 Hub connected, ETMX images
The GC750 camera has been setup to look at ETMX. In addition, the new 1X4 rack mounted switch (131.215.113.200) has been connected via new cat6 cable to the control room hub (131.215.113.1?), thanks to Eric. The camera is now plugged into 1X4 rack switch and now has a gigabit connection to the control room computers as well as Mafalda (131.215.113.23).

By using ssh -X mafalda or ssh -X 131.215.113.23, then typing:

target
cd Prosilica/bin-pc/x86/
./Sampleviewer

A viewer will be brought up. By clicking on the 3rd icon from the left (looks like an eye) will bring up a live view.

Closing the view, and then cd ../../40mCode, and then running ./Snap --help will tell you how to use a simple code for taking .tiff images as well as setting things such as exposure length and size of image (in pixels) to send.

When the interferometer was set to an X-arm only configuration, we took two series of 200 images each, with two different exposure lengths.

Attached are three pdf images. The first is just a black and white single image, the second is an average of 100 images, and the third is the standard deviation of the 100 images.
Attachment 1: GC750_ETMX_E30000_single.pdf
GC750_ETMX_E30000_single.pdf
Attachment 2: GC750_ETMX_E30000_avg.pdf
GC750_ETMX_E30000_avg.pdf
Attachment 3: GC750_ETMX_E30000_std.pdf
GC750_ETMX_E30000_std.pdf
  569   Wed Jun 25 18:03:21 2008 YoichiConfigurationPSLFSS 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.
  570   Thu Jun 26 01:08:22 2008 ranaConfigurationGeneralAlarm 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
b.gif
  579   Thu Jun 26 21:07:11 2008 ranaConfigurationASSdust & 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
Screenshot-2.png
  602   Mon Jun 30 13:48:47 2008 John, RobConfigurationPSLDon'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
binremoval.png
  603   Mon Jun 30 14:07:26 2008 RobConfigurationPSLDon'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
DSC_0140.png
  606   Mon Jun 30 16:00:02 2008 josephb, samConfigurationComputers 
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.
  611   Tue Jul 1 11:57:24 2008 YoichiConfigurationPSLMZ 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.
  612   Tue Jul 1 12:08:38 2008 John, JoeConfigurationPSLPMC 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?
  616   Tue Jul 1 16:48:42 2008 rob, johnConfigurationPSLMZ servo switch problem resolved forever

Quote:
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.


We have fixed this problem forever, by totally disabling this switch. Looking at the schematic for the MZ servo and the datasheet of the AD602, we found that a HI TTL on pin 4 disables the output of the AD602. Since the MZ servo was stuck in the off position, this seemed to indicate that it may be the XYCOM220 itself which is broken, constantly putting out a +5V signal regardless of the EPICS controls. We thought we might be able to get around this by disconnecting this signal at the cross-connect, but ultimately we couldn't find it because there is no wiring diagram for the Mach-Zehnder (!). So, we pulled the board and wired pin 9A of P1 to ground, permanently NORMALizing the MZ_BLANK switch. John has marked up the schematic, and someone should modify the MEDM screen and check the new screen into svn.

We can still the turn the MZ servo on and off by using the test input 1 switch.

Someone also will need to modify the MZ autolocker to use the test input 1 (MZ_SW1) instead of the old MZ_BLANK.
  621   Wed Jul 2 06:46:05 2008 AlbertoConfigurationGeneralNPRO on to warm up
This morning I turned on the NPRO on the AP table so that it can warm up for a few hours before I start using it today.
The flipping mirror is down so no beam is injected in to the IFO.


Alberto
  631   Thu Jul 3 13:54:26 2008 robConfigurationComputersmDV on rosalba

Does mDV work on rosalba? It can't find NDS_GetChannels. Looking on mafalda, I see that NDS_GetChannels is a mexglx. I think this means someone may need to compile it for 64-bit matlab before we can have mDV on rosalba. When that's done, we should get mDV running on megatron.
  649   Tue Jul 8 21:46:38 2008 YoichiConfigurationPSLGC650M moved to the PMC transmission
I moved a GC650M, which was monitoring the light coming out of the PSL, to the transmission port of the PMC to see the transmitted mode shape.
It will stay there unless someone find other use of it.

Just FYI, you can see the picture from the control computers by the following procedure:

ssh -X mafalda
cd /cvs/cds/caltech/target/Prosilica/40mCode
./SampleViewer

Chose 02-2210A-06223 and click on the Live View icon.
  681   Wed Jul 16 15:59:04 2008 josephb, EricConfigurationCamerasPMC trans camera path
In order to reduce saturation, we placed a Y1 plate (spare from the SP table) in transmission just before the GC650 camera looking at the PMC transmision. The reflection (most of the light) was dumped to a convient razor blade dump. We also removed the 0.3 and 0.5 ND filters and placed them in the 24 hour loan ND filter box.

Good exposure values to view are now around 3000 for that camera.
  682   Wed Jul 16 16:28:14 2008 josephbConfigurationComputersFixed IP address on Switch
Realized today that the change I made back on June 30th to the switch was to the wrong switch. I had disabled the DHCP setting and mislabeled the switch in the control room (which seems to not have affected anything).

I've turned DHCP back on and labeled it correctly using the Netgear "Smartwizard discovery" program.
  693   Fri Jul 18 12:24:15 2008 josephb, EricConfigurationCamerasChanged Lenses on GC750 at ETMX
We removed the giant TV zoom lens and replaced it with a much smaller fixed zoom lens. Currently it views the entire optic. We have another (also small) zoom lens which focuses much better on the spot itself. With how far back the camera is currently placed, neither of these fixed zoom lenses can touch or hit the view port or the chamber while still attached to camera and mount, even using all of the mount's motion range. So this should be less of a safety issue.

Ideally, we'd like to get some images of the full optic (including osems and so forth) with the X-arm locked, and then use the higher zoom lens while still locked, to get images we can use to calibrate the x and y length scales.
  710   Mon Jul 21 19:55:16 2008 rana,jenneConfigurationIOONoise in MC_F
Jenne put the MC board on extender today - its still that way but everything is probably connected (check AO).

We measured the TFs of the DAQ section for MC_F because of how everything looked wrong in the plots Jenne
put in the log earlier. Everything we measured today seemed to jive with the schematic. We also looked up
the original traveler for this board which Betsy filled in years ago: it also is in spec for the DAQ filtering.

So then I looked at the power spectrum of the output signal to the VCO. It had lots of HFC (high frequency crap).
I adjusted the parameters of the FSS (common gain, fast gain, RF phase Astonished) and lowered the MC common gain. This
produced a global minimum in that 4D parameter space.

I think that basically, the FSS gain is too low even with the common gain slider maxed. Having the fast gain up
at 19 dB like I had left it was bad - even though it minimizes the PC control signal, it produces a lot of HFC
up around 100 kHz in MC_F. After John (finally) gets around to measuring the FSS loop we can figure out how to
better tune this. The MC gain then has to be tuned so as to best minimize the HFC given the new FSS gain; there's
basically no coupling from the MC gain to the FSS loop shape so its always best to tune the FSS first. Pleased

The RF phase of the FSS was a mystery - I have no idea why it should do anything and I have never heard of this
and I don't know why I tried it today. But...changing it by ~0.6-0.7 slider units reduced the HFC by another factor
of ~3. Somebody should put this slider into units of degrees.8-)

Here's a table of the changes. Please make these the new nominals:
you asked for:   diff 2008/07/21,13:00 2008/07/22,2:44:16 utc '.*FSS.*|.*MC.*'
LIGO controls: differences, 2008 07/21 13:00:00 utc vs. 2008 07/22 02:44:16 utc
__Epics_Channel_Name______   __Description__________   __value1____     __value2____
C1:IOO-MC_REFL_GAIN                                    22.000000        19.000000
C1:IOO-MC_REFL_OFFSET                                  0.818380         0.818100
C1:PSL-FSS_MGAIN                                       10.000000        30.000000
C1:PSL-FSS_PHCON                                       2.073170         1.413170

The attached plot shows the "SERVO" TNC output of the board; this is supposed to be the same as the voltage going to the
VCO box. So its V/Hz transfer function is flat above 40 Hz. Tomorrow Jenne will post more data and remove the extender
board.

Since I only used an SR785, I only saw noise up to 100 kHz. Its key to use an RF spectrum analyzer when checking out
the FSS and the MC systems.
Attachment 1: SCRN0024.GIF
SCRN0024.GIF
  719   Wed Jul 23 01:42:26 2008 ranaConfigurationPSLFSS RFPD: Examined, "repaired", and re-installed
Rob said that there might be something wrong with the FSS RFPD since the loop gain is so low.
Next time we should just use the Jenne laser on it in-situ and compare with our reference.

We had a 24.5 MHz LSC PD which Rob got from Sam. Sam got it from Rai. I gave it to Rai in Livingston
because it seemed suspicious. Seems fine now. This black box PD had a lower overall response than
the goldbox one we already had. The 2001-2005 era diodes which we got from the Canadian Perkin-Elmer
all had high capacitance and so that's not a surprise.

So the goldbox one was not broken totally.

I found that the offset came from a cracked capacitor. C25 was a yellow thru-hole ceramic 0.1 uF.
Its a surface mount board...don't know why this was like this but there's also no reason it should
have cracked unless it was soldered on with too much heat. I replaced it with a 0.47 uF ceramic
surface mount. Also R24 was a 20 Ohm resistor and L3 was not stuffed?? Removed R24 and put a 1 uH
inductor into L3. This is there so that the input to the MAX4107 is AC coupled.

However, the DC signal that Rob saw was actually because of the cracked C25. It had shorted and was
making a 25 mV signal at the input to the MAX4107 which has a gain of 10. This was producing ~165 mVdc
into a 50 Ohm load and so it could have saturated most mixers. The FSS board, however, has an overly
monstrous level 21 (I think) mixer and so this should not have been an issue. Maybe.

I was able to lock with the 24.5 MHz black box PD but it was not too hard to repair the gold box one
so I did. I tuned it so that the notch is truly at 43 MHz (2x the FSS 21.5 MHz modulation) but because
someone has done this using a hacky cap in parallel with the main PD, I am unable to get the resonant
peak to line up at 21.5 MHz. Its at 23 MHz instead. This loses us ~2 dB in signal. Since the frequency
is so low, we can increase the gain in the MAX4107 by another factor of 3 or so in the future.


So the PD is not our problem. Still worth verifying that the cable is good -- its around 10 miles long!!
And loops around in there with a bunch of other cables. We have an electronic phase shifter so this seems
totally misguided.

The other bad problem is that the mode matching is pretty horrible. Something like 1/3 of the carrier
power doesn't go into the cavity.
FSS TODO:
1) Check cable between RFPD and FSS box for quality. Replace with a good short cable.

2) Using a directional coupler, look at the RFPD output in lock on a scope with 50 Ohm term.
   I suspect its a lot of harmonics because we're overmodulating to compensate for the bad
   mode matching.

3) Purchase translation stages for the FSS mode matching lenses. Same model as the PMC lenses.
   Fix the mode matching.

4) Get the shop to build us up some more bases for the RFPDs on the PSL such as we have for the LSC.
   Right now they're on some cheesy Delrin pedestals. Too soft...

5) Dump the beam reflected off the FSS RFPD with a little piece of black glass or a razor dump.
   Anodized aluminum is no good and wiggles too much.

The attached PDF shows photos of the old and new style PDs. One page 3 there's a wire that I soldered on
as a handle so that we can remove the RF can (occasionally people claim that soldering to the lid screws
up the magnetic shielding magic of the lid. use this as a litmus test of their electronics know-how; its
a tin can - not an orgone box). Pages 4 & 5 are the circuit before I soldered, page 6 the cap after I
tried to remove it, page 7 is the circuit after I put in the new cap, and page 8 is the schematic with
the mark up of the changes.
Attachment 1: Untitled.pdf
Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf Untitled.pdf
  724   Wed Jul 23 16:31:02 2008 AlbertoConfigurationComputersMegatron connected
Joe, Rana, Alberto,

we found out the password for Megatron so we could log in and set a new one so that now it's the same as that for controls.
The IP address is 131.215.113.59.

We had to switch to another LAN ports to actually connect it.
  725   Wed Jul 23 17:19:48 2008 AlbertoConfigurationComputersMegatron connected
We changed the IP address. Ther new one is 131.215.113.95.

Joe, Alberto


Quote:
Joe, Rana, Alberto,

we found out the password for Megatron so we could log in and set a new one so that now it's the same as that for controls.
The IP address is 131.215.113.59.

We had to switch to another LAN ports to actually connect it.
  727   Wed Jul 23 21:48:30 2008 robConfigurationGeneralrestore IFO when you're done with it

when you are done with the IFO, please click "Restore last auto-alignment" on the yellow IFO portion of the C1IFO_CONFIGURE.adl screen. Failure to comply will be interpreted as antagonism toward the lock acquisition effort and will be met with excoriation.
  729   Thu Jul 24 01:04:01 2008 robConfigurationLSCIFR2023A (aka MARCONI) settings

Quote:


P.S.: We made a test by changing the frequency of the local oscillator by a little bit and then coming back to the original value. We observed that the phase of the signal can change, so every time this frequency is moved the 3f demod phase need to be retuned.



We discovered this little tidbit in March, and remembered it tonight. Basically we found that whenever you change the frequency on one of these signal generators (and maybe any other setting as well), the phase of the signal can change (it's probably just the sign, but still...), meaning that you when you return settings to their intial value, not everything is exactly as it once was. For most applications, this doesn't matter. For us, where we use one Marconi to demodulate the product of two other Marconis, it means we can easily cause a great deal of grief for ourselves, as the demod phase for the double demod signals can appear to change.

Programmatically, what this means is that every time you touch a Marconi you must elog it. Especially if you change a setting and then put it back.
  735   Thu Jul 24 19:29:26 2008 YoichiConfigurationPSLC1:PSL-STAT_FSS_NOM_C_GAIN is changed from 30 to -0.7
Koji, Yoichi

Since the light power going to the ref. cavity is now significantly increased (see Janne's elog later),
C1:PSL-STAT_FSS_NOM_C_GAIN
is changed from 30 to -0.7.
Otherwise, the MC did not lock.
  743   Sun Jul 27 20:25:49 2008 ranaConfigurationEnvironmentOffice Temperature increased to 75 F
Since we have the chiller for the PSL chiller now, I've just increased the office area
temperature set point by 2 F
to 75 F to see if the laser will still behave.
  744   Sun Jul 27 20:49:21 2008 ranaConfigurationComputersNTP
After Aidan did whatever he did on op440m, I had to restart ntpd. I noticed it didn't actually do
anything so I restarted it by hand with the '-l' option to make a logfile. Essentially, the
problem is that NTPD is not allowed access to the outside world's NTP servers by our NAT router;
this should be fixed.

So for now I set all of the .conf files to point to rana and nodus' IP addresses. According to the
log files, that is successful. Rosalba and Mafalda, however, seem to have correct time but are
looking at rhel.ntp.pool.org and time.nist.gov, respectively. Maybe these have special rules?

For reference, the linux machines' conf files are /etc/ntp.conf
and the solaris machines' conf files are /etc/inet/ntp.conf

I also logged into dcuepics (aka scipe25) and did as instructed.
  751   Mon Jul 28 23:41:07 2008 robConfigurationPSLFSS/MC gains twiddled

I found the FSS and MC gain settings in a weird state. The FSS was showing excess PC drive and the MC wouldn't lock--even when it did, the boost stage would pull it off resonance. I adjusted the nominal FSS gains and edited the mcup and mcdown scripts. The FSS common gain goes to 30dB, Fast gain to 22dB, and MCL gain goes to 1 (which puts the crossover back around ~85 degrees where phase rises above 40 degrees).
  752   Tue Jul 29 01:03:17 2008 robConfigurationIOOMC length measurement
rob, yoichi

We measured the length of the mode cleaner tonight, using a variant of the Sigg-Frolov method. We used c1omc DAC outputs to inject a signal (at 2023Hz) into the AO path of the mode cleaner and another at DC into the EXT MOD input of the 166MHz IFR2023A. We then moved an offset slider to change the 166MHz modulation frequency until we could not see the 2023Hz excitation in a single-bounce REFL166. This technique could actually be taken a step further if we were really cool--we could actually demodulate the signal at 2023Hz and look for a zero crossing rather than just a powerspec minimum. In any case, we set the frequency on the Marconi by looking at the frequency counter when the Marconi setting+EXT MOD input were correct, then changed the Marconi frequency to be within a couple of Hz of that reading after removing the EXT MOD input. We then did some arithmetic to set the other Marconis.

The new f2 frequency is:

New              OLD
--------------------------
165983145        165977195

  753   Tue Jul 29 09:12:43 2008 KojiConfigurationIOOMC length measurement
I found that the prev modulation freq had been determined with a same kind of measurement by Osamu, which also looked accurate.
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=09/12/2002&anchor_to_scroll_to=2002:09:12:17:10:30-ajw

(There is also a document by Dennis to note about this measurement
http://www.ligo.caltech.edu/docs/T/T020147-00.pdf )

So, it means that the round trip length of the MC shortened by 1mm in the 6 years.
New              OLD
--------------------------
27.0924          27.0934    [m]

Quote:
rob, yoichi

We measured the length of the mode cleaner tonight, using a variant of the Sigg-Frolov method.
....
The new f2 frequency is:
New              OLD
--------------------------
165983145        165977195
  767   Wed Jul 30 13:09:40 2008 josephb, EricConfigurationPSLPMC scan experiment
We turned the PSL power down by a factor of 4, blocked one half of the Mach Zehnder and scanned the PMC by applying a ramp signal to PMC PZT. Eric will adding plots later today of those results.

We returned the power to close to original level and removed the block on the Mach Zehnder, and then relocked the PMC.
  773   Wed Jul 30 18:45:01 2008 ranaConfigurationSUSNew SUS Drift Technology
I updated the SUS DRIFT screen again, this time with a new feature.

I used Rolf's idea for the AdvLIGO status system and just made the nominals be an
unused sub-field (.SVAL) of the main INMON record. Then I wrote a .csh script to
use tdsavg to average the current INMON vals and insert that as the .SVAL. The next
script should read the .SVAL and set the HIHI and LOLO based on this.

Of course, the values I have just entered are no good because our suspensions are in
a bad state but we can run this script (SUS/setDriftNoms) next time things are good.

And...even better would be if someone were to do the same but used mDV to grab the
minute trend in the past good times instead of the tdsavg (which can't go in the past).
  777   Thu Jul 31 16:11:22 2008 josephbConfigurationComputersMatlab on Megatron
Matlab now works on megatron.

I did a few things:

1) Added to the PATH environment variable. Did this in .bash_profile in the /home/controls directory by adding the line

PATH=$PATH:/cvs/cds/caltech/apps/linux64/matlab/bin/
export PATH

This probably should be somewhere else up further up the line, but I was too lazy to figure it out.

2)Fixed a gateway mistake I had added earlier so the megatron could use the NAT router and see the outside world so yum worked.

3) Removed the i386 based libXp and openmotif packages.

4) Installed the x86_64 based libXp and openmotif packages.

Edit: Forgot that I also added the following line to the /etc/fstab file in order to mount the shared code. This was stolen directly from Rosalba's /etc/fstab file. This was so that it could see the matlab code.
linux1:/home/cds/ /cvs/cds nfs rw,bg,soft 0 0
ELOG V3.1.3-