Koji: QIL/TCS entrance flooding. Check your lab

Anchal: Can someone take a look at CTN too?

Koij: TCS needs more people @aidan

Koji: CTN ok

Aidan: On my way

Shruti: Cryo seems fine

Aidan: There was a leak in a pipe in the wall of B265A. It was coming from the building air conditioner condensation overflow. Facilities has fixed the pipe and is working on clean-up

I checked the lab this morning. It was dry and there wall was in the same state as yesterday.

The carpentry shop removed wet plaster sections from the wall following the flood (process was gentle scraping of wet plaster flakes, supervised by me). The wet section of wall needs a few days to dry and then they will plaster and paint it.

11:29AM - Lab has flooded again this morning. I'm calling PMA. Looks to be the same issue as before.

Some photos of water and clean-up.

Summary: I came into the lab around 11:30AM and found water on the floor in the changing room outside QIL/TCS. Turns out the condesation overflow pipe from the AC blew out again. This time near the ceiling. Water was on the floor but also had sprayed a little onto the tool chest and East optical table. A few optics got wet on the table. Initial inspection looks like electronics were spared with the exception of the "broken" spectrum analyzer that was on the floor. 

Facilities came in and cleaned up the water. A small amount got into QIL but stayed near the door as the lab floor slopes up from the door area. They fixed the pipe and were looking into whether there was a blockage cuasing this problem. PMA was notified and John Denhart is coordinating follow-up.

Triage effort: given the AC was still active, John and I strung a temporary tarp across the two tables to block any spray.

Yesterday, I installed CentOS 5.3 on the Gateway GT5482 machine that housed the EDT frame-grabber.

1. I installed CentOS 5.3 with all the default options
2. As recommended by the README.lnx_pkg_reqs, I tried and failed to install the "Development Tools", "Development Libraries" and the "X Software Development" using the Add/Remove Software.
3. I copied the entire install CD to ~/fgdriver on the hard disk.
4. Installed the following packages at the command line

> yum install gcc

> yum install make

> yum install tk

> yum install kernel

I tried to run ~/fgdriver/linux.go at this point to install the EDT driver, but the installation failed about halfway through with the message "problem making the driver module". An investigation revealed that this was the due to the failure of ~/fgdriver/linux/module/makefile. I tried running that makefile separately to build the driver module and it crashed with the message: Can't find /lib/modules/2.6.18-128.el5/source/include/linux/mm.h. I concluded that the kernel source code wasn't installed

• Added "Development Libraries" with Add/Remove Software
• Ran the following command lines

> yum install kernel-devel

> yum install kernel-xen-devel

 And then I followed the instructions at the link: http://wiki.centos.org/HowTos/I_need_the_Kernel_Source

from: > yum install rpm-build redhat-rpm-config unifdef

 to:  > rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.el5.src.rpm 2>&1 | grep -v mockb

and at the latter point the rpm build  pissed and moaned that it couldn't find the file kernel-2.6.18-164.15.1.el5.src.rpm

However, some combination of the above must have worked. I rebooted the computer and logged in again as root. At this point the install script ~/fgdriver/linux.go ran from start to finish without complaining. A quick test of the resulting /opt/EDTpdv/camconfig and then /opt/EDTpdv/serial_cmd showed that I could access the Dalsa 1M60 camera through the frame grabber.

Regarding the installation of EDT software, I overlooked a note from the install.pdf  file.

The gist of it is that if the scripts do not run, then remount the CD-ROM by typing the

following:

mount /mnt/cdrom -o remount,exec

which will then allow the scripts to be run. The directory /mnt/cdrom should be changed if

the cdrom is mounted somewhere else. (The note can be found in the page 1 of the file

install.pdf.)

Unfortunately I don't have linux installed at the moment so I cannot test this. My computer was

reinstalled with Windows XP, the previous CentOS system being wiped out. However if this works,

then there is probably no need to copy the files to the hard drive. 

I saw this and tried it when i was installing, but I had more flexibility when I copied the files directly to the hard drive.

I noticed that when i ran /opt/EDTpdv/camconfig and selected camera 331, which appeared to be closest to the Dalsa Pantera 1M60 camera, the software loaded the configuration file pantera11m4fr.cfg.

I tried to locate which entry in the camconfig list corresponded to the dalsa_1m60.cfg configuration file, but none of them seemed to. I couldn't select any entry and get it to report that it was using the 1m60 config file.

Next I noticed that there were 659 configuration files in the /opt/EDTpdv/camera_config directory but only 460 configuration options in camconfig. This seemed like 1/3 of the config files were somehow not formatted correctly, including,possibly the 1M60 config file.

By editing the pantera11m4fr.cfg I verified that the name of the camera, as it appears in the camconfig program, is the second line in the configuration file. For that file it was:

# CAMERA_MODEL 	"Dalsa Pantera 12 bit single channel camera link"

where the first line is just a single hash. The dalsa_1m60.cfg file did not have a name formatted in the same way as above: it was originally as shown below:

# Dalsa 1m60 config file (freerun)

so i changed the name in that configuration file to the following and it was suddenly available in the list when ./camconfig was run

# CAMERA_MODEL "Dalsa 1m60 config file (freerun)"

I selected that camera (number 53 in the list). Once this was done I ran pdv_flshow/pdvshow again the image that was displayed from the camera appeared to be correctlty demodulated.

Actually, the very first time i ran pdvshow the image was demodulated correctly but it appeared that the origin was offset and then the image wrapped around a little at the edges. However, every successive time I've run pdvshow since then I've had a perfectly demodulated image.

I ran some test patterns by changing the video mode using the serial communications menu in the camera. I also illuminated the Hartmann sensor with a torch/flashlight and got some spot patterns - see attached images.

Also, I've attached the dalsa_1m60.cfg file.

This is an amended version of simple_take.c.

The files below are all in the directory /opt/EDTpdv/hartmann/src

1. simple_hartmann.c   - the C code to access the frame grabber, retrieve an image, load the MATLAB engine and pass the image to MATLAB for centroiding
2. centroid_image.m  - the MATLAB routine that centroids the image
3. get_defocus.m - the MATLAB function that determines the defocus in the centroids
4. build_simple_hartmann.sh - a shell script I wrote that contains the compile and link options to build the thing correctly 

The new machine in the TCS lab is running Ubuntu. I installed the frame-grabber into it and, after loading the configuration file for the camera, was able to access the serial port on the camera and also was able to record a properly formatted image from the Hartmann sensor.

I fixed a bug in how the raw Mako CCD camera images are being read into memory. The bmp files turn out to have a block memory layout that broke my in-place reader.

http://nodus.ligo.caltech.edu:8080/AdhikariLab/859

 http://nodus.ligo.caltech.edu:8080/AdhikariLab/860

 contents of tcs_daq: /target/TCS_westbridge.db

hartmann had started responding to requests to log-in with the a request to change the password. Attempts to change the password proved unsuccessful. I tried to access the machine locally to change the password but I couldn't the display started, so I had to reboot it.

This attachment is a Shockwave Flash animation of the iLIGO ETM getting a 1 W beam with a 3.5 cm radius getting fully absorbed onto the surface at t = 0.

I added a workstation at 10.0.1.26 in the TCS lab.

1. Write a Wiki page that describes how to add channels to the Athena Box
2. Write a Wiki page that describes how to add a new computer to the network and mount all the network drives
3. Add an EPICS channel that writes the disk usage to file (to keep track of the total accumulated disk space used by the centroid storage)

I measured the reflectivity of a possible HWS replacement mirror at 532nm. Thorlabs BB2-EO3

Incident power = 1.28mW

Reflected power = 0.73mW

R = 56% at 45 degrees AOI.

The 400 mW CO2 laser on the Hartmann table is currently configured for a measurement of its relative intensity noise. It is aligned to a TCS CO2P photodetector powered by a dual DC power supply beside the light enclosure. I got some data last night with the laser current dialed back for low output power (0.5-10 mW incident), but still need to analyze it. In the meantime please don't remove parts from the setup, as I may need to repeat the measurement with better power control.

Attached for reference is the RIN measurement from the initial data.

Went down to the lab and showed Rana the setup. He's fine with me being down there as long as I let someone know. He also recommended using an adjustable mount  (three screws) for the test mirror instead of the mount with top bolt and two nubs on the bottom - he thinks the one with three screws as constraints for the silica will be easier to model (and be more symmetric constraints)

Mounted the f=8" lens (used a 2" pedestal) and placed it on the table so the image fit well on the CCD and so a sharp object in front of the lens resulted in a sharp image. The beam was clipping the f=4" lens (between gold mirror and test mirror) so I spent time moving that gold mirror and the f=4" lens around. I'll still need to finish up that setup.

The beam reflecting off the test mirror was clipping the lens between gold mirror and test mirror, so I reconfigured some of the optics, unfortunately resulting in a larger angle of incidence.

From the test mirror, the beam size increases much too rapidly to fit onto the 2-inch diameter lens with f=8 that was meant to resize the beam for the CCD of the HWS. It seems that the f=8 lens can go about 6 inches from the test mirror, and an f ~ 2.3 (60 mm) lens can go about 2 inches in front of the CCD to give the appropriate beam size. However, the image doesn't seem very sharp.

The beam is also not hitting the CCD currently because of the increase in angle of incidence on the test mirror and limitations of the box. I'd like to move the HWS closer to the SLED (and will then have to move the SLED as well).

The table is set up. The HWS and SLED were moved slightly, and a minimal angle between the test mirror and HWS was achieved.

There are two possible locations for the f=60mm lens that will achieve appropriate magnification onto the HWS: 64cm or 50 cm from the f=200mm lens. 

At 64cm away, approximately 79000 saturated pixels and 1054 average value.

At 50cm away, approximately 22010 saturated pixels and 1076 average value.

Currently the setup is at 64cm. Could afford to be more magnified, so might want to move the f=60mm lens around. Also, if we're going to need to be able to access the HWS (i.e. to screw on the array) we might want to move to the 50cm location.

With Jon's help, I changed the setup to include a mode-matching telescope built from the f=60mm (1 inch diameter) lens and the f=100mm lens. These lenses are located after the last gold mirror and before the test optic. The height of the beam was also adjusted so that it is more centered on these lenses. Note: these two lenses cannot be much further apart from each other than they currently are, or the beam will be too large for the f=100mm lens.

We considered different possible mounts to use for the test optic, and decided to move it to a mount where there is less contact. The test optic was also moved closer to the HWS to achieve appropriate beamsize on the optic coming from the mode-matching telescope.

The f=200 lens is now approximately 2/3 of the distane from the test optic to the HWS, resulting in an appropriately sized beam at the HWS.

Current was also turned down to achieve 0 saturated pixels.

Attached the grid array of the HWS.

Applied voltage (5V, 7V, 9.9V, 14V) to the heater pad and took measurements of T and spherical power (aka defocus).

The adhesive of the temperature sensor isn't very sticky. The first time I did it it peeled off. (Second time partially peeled off). We want to put it on the side of Al if possible.

Bonded a mirror (thickness ~6 mm) to aluminum disk (thickness ~5 mm) and it's still curing.

To the best of my ability, calculated the magnification of the plane of the test optic relative to the HWS (2.3) and input this value.

Increased the temperature slightly and saved data points of defocus to txt files when temperature leveled out. This was a slow process, as it takes a while for things to level out. I only got up to about 28.5C, and will need to continue this process.

I also plotted the best-fit defocus for each temperature from COMSOL (Temperature vs. Defocus), and looking at values from HWS it seems that we're off by a normalization factor of approx. 4.

Caltech Facilities has determined that the walls in the SE corner of the TCS Lab in West Bridge were water damaged during last weekend’s rain. They are going to remove the plaster from the walls and dehumidify the area for a week or so. All tables in the room are going to be covered with plastic for this process. In the short term I’ve shutdown all the equipment in the lab (including FB4). The 2-micron cavity-testing fabrication has been moved next door to the QIL.

I drew up one way we could set up the three available bake ovens in the TCS lab on the single oil pump. 

If this looks feasible to others, we can move the ovens into the TCS lab. Duo and I will be occupied at KNI during Tuesday and Monday morning, so the usual lab cleanup time may not be the best. Perhaps Monday afternooon we can at least get the ovens out of the hallway and get one of them set up for baking.

My preference is to have tubes back towards the wall where possible. We might be able to drill a large diameter hole in the table top to accommodate them.

We have to get confirmation that the exhaust can be extracted - otherwise this whole thing is moot.

Aidan and I continued the lab clean-up today. There's still more to do, but we did fully clear the large optical table which formerly housed the 50 W CO2 laser. I moved the optical enclosure over from the small table to serve as the area for the point absorber experiment. Inside it I mounted the Hartmann sensor and a 532 nm Thorlabs LED source. The LED still needs collimating/focusing optics to be installed.

Small/Medium size gloves need to be ordered in order to handle the optics carefully.

New gloves are ordered for the TCS and QIL labs. They arrive tomorrow (Friday).

Facilities came in on Friday and teed off a new duct to provide exhaust for the proposed new vacuum bake area in the TCS Lab. Photos are attached. 

We installed a plastic sheet between the work area and the rest of the lab (the rest of the lab was overpressurized relative to the work area). Also, they use a vacuum when doing any drilling.

I cleaned up the HWS table in preparation for replacement with the 4x10 table. We still need to move the cabinet and get the enclosure out of the way.

We (Aidan, Koji, Radhika, Aaron) partially tidied up the TCS Lab. The front table is clean and ready to recieve PD tesitng optics, electronics and vacuum hardware. We moved all electronics units (oscilloscopes, power supplies, etc) to the rack in the NE corner of the lab. The back table was partially tidied up. We need to schedule cleaning of the remaining tables in the lab and also an inventory and disposal of obsolete equipment in all the cupboards.

[JC, Chub, Radhika]

Chub and I ordered a few parts from McMaster in order build a handrail-like stopper to keep the dewar from falling over. We also cut off the excess 8020 which was leaning over the table to fit. To hold down the support for the Dewar, Radhika and I decided to use C-clamps from the EE shop.

[JC]

The desktop computer is now running Debian Linux

How to move the large engine hoist through the narrow door

See http://nodus.ligo.caltech.edu:8080/Mariner/122

I added LED stip lighting above the desk on the West wall. I also tidied that desk up (mostly in the drawers).

 The EDT PCIe4 DV C-Link frame grabber arrived this morning. There is a CD of drivers and software with it that I'll back up to the wiki or 40m svn sometime soon.

 I installed the EDT PCIe4 DV C-Link frame grabber in a spare Windows XP PC and connected the Dalsa 1M60 camera directly to it via the CameraLink cable. In this configuration I was able to access the menu system in the camera using the supplied serial_cmd.exe routine.

PC --> Frame-Grabber --> Camera-Link Cable --> Dalsa 1M60: works OK

Next, I attached the RCX C-Link: Fiber to Camera Link converters to either end of a 300' fiber, plugged them into the PC and the Dalsa 1M60 and then supplied them with 5V of power. Once again, I was able to access the on-board menu system in the camera (as the attached screen-capture shows). I also did a quick-test using the in-built video display program and verified that I could get an image from the camera - by waving around my hand in front of the CCD I was able to modulate the light in the image on the computer. This, therefore, demonstrates that the camera can be easily accessed and run at a distance of at least 300' via optical fiber.

PC --> Frame-Grabber --> RCX C-Link --> 300' optical fiber --> RCX C-Link --> Dalsa 1M60: works OK

The attached images:

 hartman_sensor.JPG: a screencap of the Dalsa 1M60 on-board menu system captured with the C-Link to fiber connector running

Fiber_Camera_Link_1.jpg: A RCX C-Link and one end of the 300' fiber connected to the Dalsa 1M60

Fiber_Camera_Link_3.jpg: A RCX C-Link and the other end of the 300' fiber connected to the PC

* EDT PCIe4 DV frame grabber: installation notes for linux system 

(Note)

Main issue I encountered was the fact that most of the shell scripts
did not run by simply entering them. It's bit strange because if you
do ls -al to view the file lists they are made executable. So it's
possible that others don't encounter the same kind of problems as I
did.

However, if one executes the command "./linux.go", for example, and
receives the message saying

 bash: ./linux.go: /bin/sh: bad interpreter: Permission denied

then one may follow the steps I took as below.


1. Make a folder to put the content of CD, for example:

     mkdir ~/fgdriver

2. Copy the content of the CD-ROM to the folder.

3. Go to the folder.

     cd ~/fgdriver

4. Change or check the mode of the following script files (using the 
   command chmod) to be executable (using "chmod a+x filename"):

     linux.go

     ~/fgdriver/linux/EDTpdv/installpdv (this one should already be 
     executable)

     ~/fgdriver/linux/EDTpdv/pdv/setup.sh      

5. run ./linux.go and choose DV by clicking it.

(Note)

I am assuming that the programming language Tcl is already installed
in the machine. CentOS 5.4 that I have installed came with Tcl. If Tcl
is not installed, I think that linux.go will run cli_startmenu.sh
instead (located in the same directory as linux.go). So make sure
cli_startmenu.sh is executable (see step 4).

6. Choose default installation directory and start installation

(Note) 

In my first attempt to install the files, the installation message
window hung after displaying many lines of "........". That was
because the file setup.sh was not made executable (see step 4). So I
made setup.sh executable, ran linux.go again, then I could see further
messages flowing through (basically compiling c source files). I'm not
sure whether others will enounter the exactly same problem though.

7. After the installation completes, go to the /opt/EDTpdv folder.

     cd /opt/EDTpdv

8. Final Step: Make edt_load and edt_unload executable. (See step 4)

(Note)

Most of the other executables we need for running the frame
grabber/camera should already be executable at this point; but somehow
in my installation the above two files were not made executable. I
again do not know whether others will experience the same
problem. Since there are lots of executables generated when
installation completes, I advise that, whenever a certain command does
not run, one should check if that command file is executable or not.

----

Please let me know if you find any parts of the above confusing. I will
do my best to clarify.

 I installed CentOS on the machine with the EDT frame-grabber. I then installed the frame-grabber software from the CD.

In the /opt/EDTpdv/ directory the camconfig program was run and I entered "331" to start the frame-grabber and run with the Dalsa 1M60 settings ... this was necessary to get the frame grabber running, but didn't seem to force pdvshow, installed at a later point, to use this configuration file. At this point I could access the camera menu with the serial_cmd program.

After some effort, which will be detailed shortly, I managed to finally get the pdv_show GUI program compiled and installed. I found that trying to run that program with the dalsa_1m60.cfg configuration file resulted in a segmentation fault.

However, when I ran it with the default Dalsa configuration file, pantera11m4fr.cfg, and selected "Continuous Exposure" I got a stream of illuminated pixels on the screen. It was clear that the display was displaying the pixels coming back from the camera in the wrong way (for instance, trying to load a 1024x1024 image into a 1440x900 array), however, by changing the frame rate on the camera to 20Hz and waving my hand around in front of the camera I was able to modulate the intensity of the hash of pixels being displayed. This means that the frame-grabber is successfully getting data - it just isn't interpreting it correctly yet.

Here are a couple of images from pdv_show (hit Alt+PrtScrn to get a screenshot of the active window):

 1. Screenshot-PCI_DV_Display.png - the image on the computer with the camera running unobscured

2. Screenshot-PCI_DV_Display-1.png - the image on the computer with me covering the camera with my hand.

3. -opt-EDTpdv.png - the camera parameters at the time of this test (running serial_cmd)

I installed a Windows XP virtualization on the Hartmann machine. It can be accessed from the desktop, or by running virt-manager at the command line. Once the virtualization manager starts the virtualization of Windows needs to be started. It runs quite slowly.

I also installed MATLAB on this machine in /apps/. TThis was intended to be /apps/MATLAB/ but apparently the install program doesn't add a top directory called MATLAB as you might expect. I had to run a yum install libXp because it was complaining that "/apps/bin/glnxa64/MATLAB: error while loading shared libraries: libXp.so.6: cannot open shared object file: No such file or directory"

I updated the .bashrc file in controls@hartmann to include aliases for the ezca EPICS commands and a few others. Details shown below:

Also added launchers to the top panel for MATLAB, sitemap, dataviewer and StripTool. The icons for the launchers are located in:

/cvs/users/ops/ligo-launchers/icons

Changes to .bashrc

alias dv="/cvs/opt/apps/Linux/dataviewer/dataviewer"
alias StripTool = "/cvs/opt/apps/Linux/medm/bin/StripTool"
alias medm="/cvs/opt/apps/Linux/medm/bin/medm"
alias sitemap='medm -x /cvs/cds/caltech/medm/c2/atf/C2ATF_MASTER.adl'

# EPICS aliases
alias ezcademod="/cvs/opt/apps/Linux/gds/bin/ezcademod"
alias ezcaread="/cvs/opt/apps/Linux/gds/bin/ezcaread"
alias ezcaservo="/cvs/opt/apps/Linux/gds/bin/ezcaservo"
alias ezcastep="/cvs/opt/apps/Linux/gds/bin/ezcastep"
alias ezcaswitch="/cvs/opt/apps/Linux/gds/bin/ezcaswitch"
alias ezcawrite="/cvs/opt/apps/Linux/gds/bin/ezcawrite"

I added the Dalsa 1M60 temperature measurements to EPICS. The break down is as follows:

I added a softIoc called HWS to /cvs/cds/caltech/target/softIoc. It added the channels following channels: C4:TCS-HWS_TEMP_DIGITIZER and C4:TCS-HWS_TEMP_SENSOR. The ioc (input/output controller) is run with the following command:

/cvs/opt/epics-3.14.10-RC2-i386/base/bin/linux-x86/softIoc HWS.cmd

 I've added the digitizer and sensor board temperature readings from the HWS to the frames. This was done in the following way

1. Create a new file /cvs/cds/caltech/chans/daq/C4TCS.ini - with the channels in it - see below

2.  open /cvs/cds/caltech/target/fb1/master

3. add a line that includes the C4TCS.ini file when the frame builder starts

4. restart frame-builder by killing the daq daemon - kill <process id for daqd> (this is the only thing that needs to be entered as it will automatically restart)

C4TCS.ini

[default]

dcuid=4

datarate=16

gain=1.0

acquire=1

ifoid=0

datatype=4

slope=1.0

offset=0

units=NONE

[C4:TCS-HWS_TEMP_SENSOR]

[C4:TCS-HWS_TEMP_DIGITIZER]

 I added the following line to ~/.bashrc

export PYTHONPATH=/home/controls/scripts/modules:/usr/local/lib/python

Python script

I wrote a Python script, ~/scripts/dalsa_to_epics.py that reads the temperature off the camera using serial_cmd vt and then it writes this to the EPICS channels using ezcawrite. See attached. It is now running continuously in the background as dalsa_to_epics.

Dalsa1M60 baud rate

Also I accessed the menu of the 1M60 and changed the baud rate to 115200 using sbr 115200. Then I edited the dalsa_1m60.cfg file to set the baud rate to 115200 in that file. Finally, I changed the settings on the camera so that it will boot with the new baud rate when it is turned off and on again - this was with wus in the camera menu.

All the files are attached.

~/scripts/dalsa_to_epics.py

~/scripts/Dalsa1M60/VerifyTemperature.py

/opt/EDTpdv/camera_config/dalsa_1m60.cfg