I switched in just the base piece of the Hartmann sensor. The cooling fins are removed. I bolted the camera securely to the base plate and I bolted the plate securely to the table.

 5:00PM - (Digitizer = 41.9C, Sensor = 33.8C, Ambient = 19.3C)

 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]

My previous eLog details how the noise in Hartmann Sensor defocus measurements appears to vary with ambient light. New troubleshooting analysis reveals that the rapid shifts in the noise were still related to the ambient light, sort of, but that ambient light is not the real issue. Rather, the noise was the result of some trouble with the centroiding algorithm.

The centroiding functions I have been using can be found on the SVN under /users/aidan/cit_centroid_code. When finding centroids for non-uniform intensity distributions, it is desirable to avoid simply using a single threshold level to isolate individual spots, as dimmer spots may be below this threshold and would therefore not be "seen" by the algorithm. The centroiding functions used here get around this issue by initially setting a relatively high threshold to find the centroids of the brighter spots, and then fitting a hexagonal close-packed array to these spots so as to be able to infer where the rest of the spots are located. Centroiding is then done within small boxes around each estimated centroid location (as determined by the hexagonal array). The functions "find_hex_grid.m" and "flesh_out_hex_grid.m" serve the purpose of finding this hexagonal grid. However, there appear to be bugs in these functions which compromise the ability of the functions to accurately locate spots and their centroids.

The centroiding error can be clearly seen in the following plot of calculated centroids plotted against the raw image from which they were calculated:

At the bottom of the image, it can be seen that the functions fail at estimating the location of the spots. Because of this, centroiding is actually being done on a small box surrounding each point which consists only of the background of the image. This can explain why these centroids were calculated to have much larger displacements and shifted dramatically with small changes in ambient light levels. The centroiding algorithm was being applied to the background surrounding each of these points, so it's very reasonable to believe that a non-uniform background fluctuation could cause a large shift in the calculated centroid of each of these regions.

It was determined that this error arose during the application of the hex grid by going through the centroiding functions step-by-step to narrow down where specifically the results appeared to be incorrect. The function's initial estimate for the centroids right before the application of the hex grid  is shown plotted against the original image:

The centroids in this image appear to correspond well to the location of each spot, so it does not appear that the error arises before this point in the function. However, when flesh_out_hex_grid and its subfunction find_hex_grid were called, they produced the following hexagonal grid:

It can be seen in this image that the estimated "spot locations" (the intersections of the grid) near the bottom of the image differ from the actual spot locations. The centroiding algorithm is applied to small regions around each of these intersections, which explains why the calculated "spot centroids" appear at incorrect locations.

It will be necessary to fix the hexagonal grid fitting so as to allow for accurate centroiding over non-uniform intensity distributions. However, recent experiments in measuring thermally induced defocus produce images with a fairly uniform distribution. It should therefore be possible to find the centroids of the images from these experiments to decent accuracy by simply temporarily bypassing the hexagonal-grid fitting functions. To demonstrate this, I analyzed some data from last week (experiment 72010a). Without bypassing the hex-grid functions, analysis yielded the following results:

However, when hexagonal grid fitting was bypassed, analysis yielded the following:

The level of noise in the centroid displacement vs. centroid location plot, though still not ideal, is seen to decrease by nearly two orders of magnitude. This indicates that bypassing or fixing the problems with the hexagonal grid fitting functions should enable a more accurate measurement of thermally induced defocus in future experiments.

How to move the large engine hoist through the narrow door

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

Attached below is a diagram that describes the organisation of image folders that I am using at the moment with Run_initialize and Run_acquire scripts.

Once the uppermost folder 'image' is set up, other folders in it will be created by the matlab codes if not present. Still it may be of less hassle to create the folders beforehand.

Images that are used during State 1 are saved inside 'probe' and 'secondary' folders (but not inside 'cbt' folders) with prefixes, e.g., 'dark' (for background count estimation) 'expadj' (for exposure adjustments), 'test' etc.

Hope this helps to understand image saving/reading procedures used throuout the two Run scripts. 

Attached are the background and 80% illumination (~uniform spatially uniform) images that Dalsa requested.

Note that the gain of the taps does not appear to be balanced.

 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)

Today I made the first characterization measurements of the mocked-up adaptive wavefront control system planned for the signal recycling mirrors.

The Setup

Inside the light-tight enclosure on the center table, I've assembled and aligned a 10.2 micron CO₂ projector which provides a heating beam of up to 150 mW incident on an SRM-like test optic. A co-aligned 633 nm probe beam and Hartmann wavefront sensor are used to measure the resulting thermal lens. I've written and installed new software on the machine hws (10.0.1.167) for viewing the wavefront distortion in real time, as shown in the below screenshot. This viewer is launched from the terminal via the command $stream_gradient_CIT

There is also a second utility program for displaying the raw Hartmann sensor CCD image in real time, which is useful for aligning the probe beam. It is launched by the terminal command $stream_intensity_CIT

Initial Thermal Lens Measurements

Lens Formation Time Scale

First, I made a time-resolved measurement of the thermal lens formation on the test optic at maximum heating beam power (150 mW). The lens appears to reach steady-state after 30 s of heating. When the heating beam is turned off, the lens decays on a very similar time scale.

Lens Strength v. Incident Heating Power

Second, I measured the thermal lens strength as a function of incident heating beam power, which I measured via a power meter placed directly in front of the test optic. Below is the approximate maximum optical path difference induced at several heating beam powers.

The above optical path differences are approximate and were read-off from the live display. I recorded Hartmann sensor frame data during all of these measurements and will be analyzing it further.

The VGA signal outputted by the multiplexer is too weak to drive two monitors. This has required video cables to be manually switched back and forth between the monitor mounted above the laser table and the desktop console.

Today I solved this problem by installing an amplifying (active) VGA splitter on the video output of the multiplexer. One output of the amplifier goes to the desktop monitor and the other to the laser table. We can now monitor the HWS realtime GUIs directly above the optical setup, with no cable swapping.

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 installed the Maku Gigabit CCD camera driver software on the hws-ws machine. The camera viewer can be opened from the terminal (from any directory) with the command

$ZimbaViewer

and there is also a shortcut icon on the desktop. The camera is ocurrently on the subnet at 10.0.1.157 and is configured to get its IP via DHCP. We can assign it a static IP if we'd like to keep it on the network permanently.

I left the camera mounted on the CO2 laser table. It's connected and ready to use.

There is an SDK for the camera with compiled examples. For a really quick image grab from the command line, use the following:

/opt/Vimba_2_1/VimbaC/Examples/Bin/x86_64bit/SynchronousGrab

This will produce a BMP image. We should probably recompile the C code to produce a 16-bit TIFF image.

Aidan found a C demo code for acquiring a single image from the Mako CCD camera and saving it to disk (SynchronousGrab -- aliased on tcs-ws as makoGrab). I wrapped that inside my realtime HWS beam profiler code to create a realtime beam profiler for the Mako camera. The interface is identical to that for the HWS.

The Mako camera is running on the tcs-ws machine (10.0.1.168) and is launched from the console via the command

$stream_intensity_CIT

It is currently configured to write a raw image to the local frame archive every 5 seconds (it prints the write location in the console), which can be disabled by setting the "-d" flag.

I restarted the Athena box and created an MEDM screen that shows the 8 differential input voltages next to their corresponding inputs on the breakout terminal strip. See the attached image. The MEDM screen is located at /home/controls/TCS_athena01_input_screen.adl on tcs_daq.

Channel 1 in the Athena is taking the output from the first channel in the temperature sensing box. That is connect to an RTD in the Hartmann sensor. The three other resistors in the Wheatstone bridge that the RTD is connected to have resistances of 1130 Ohms. There is 7V across the bridge and it has 100x gain afterwards (50x gain stage + 2x gain in single to differential output). The thermistor has temperature dependence K = 0.00385 Ohms/Ohm/degree K for 1000Ohms at 0 degrees.

R = 1000*EXP(K *delta T)

delta T = LOG(R/1000)/K

 I have configured some EPICS channels on the softIoc on the Athena box to display the voltage across the thermistor, calculate its resistance and then calculate the temperature in a linear and exponential fashion. These are stored in /target/TCS_westbridge.db on tcs_daq.

 The calibration of DEGREES_LOG is incorrect (or at least, the sign is). Fix this please.

grecord(calc,"C4:TCS-HWS_THERM_VOLTS")
{
        field(SCAN,".1 second")
        field(INPA,"C4:TCS-ATHENA_ADC0")
        field(INPB,"C4:TCS-ATHENA_ADC8")
        field(CALC,"(A-B)/3276.8")
}
grecord(calc,"C4:TCS-HWS_THERM_OHMS")
{
        field(SCAN,".1 second")
        field(INPA,"C4:TCS-HWS_THERM_VOLTS")
        field(CALC,"(-1130)*((A/700)-0.5)/((A/700)+0.5)")
}
grecord(calc,"C4:TCS-HWS_THERM_DEGREES_LIN")
{
        field(SCAN,".1 second")
        field(INPA,"C4:TCS-HWS_THERM_OHMS")
        field(CALC,"(A-1000)*3.85")
}
grecord(calc,"C4:TCS-HWS_THERM_DEGREES_LOG")
{
        field(SCAN,".1 second")
        field(INPA,"C4:TCS-HWS_THERM_OHMS")
        field(CALC,"(LOGE(A/1000))/0.00385")
}

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.

I illuminated the Hartmann sensor with the output of a fiber placed ~1m away.

I noticed that the illumination was not uniform, rather there was some sort of 'burst' or 'star' right near the center of the image. This turned out to be due to the Hartmann plate clamps - it disappeared when I removed those. It appears that there is scatter off the inner surface of the holes through the clamp plates. I'm not sure if it's from the front or back plates.

Needs further investigation ...

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.

 I measured the AC and DC channel transfer functions of the eLIGO L1 TCSY ISS board for PD1 and PD2. The gain is quite high on the AC channels so I added +40dB of attenuation to the source from the SR785. As Frank pointed out, even though this isn't exactly +40dB at low frequencies, it still attenuates and that attenuation is common to both the input to the Channel 1 of the SR785 and the input to the ISS board.

The results are shown in the attached plot. I didn't bother including the phase, I'm just interested in the magnitude for calibration purposes.

 The original data files from the SR785 are attached below: 

Cheryl Vorvick, Chris Guido, Phil Willems

Attached is a PDF with some initial noise testing. There are 5 spectrum plots (not including the PreAmp spectrum) of the laser. The first two are with V_DC around 100 mV, and the other three are with V_DC around 200 mV. (As measured with the 100X gain preamplifier, so ideally 1 and 2 mV actual) We did one spectrum (at each power level)  with no attempt of noise reduction and one spectrum with the lights off and a make shift tent to reduce air flow. The 5th plot is at 200mv with the tent and the PZT on. (The other 4 have the PZT off).

The second plot is just the spectrums divided by their respectives V_DC to get an idea of the RIN.

I got the LTG CO2 laser to deliver 50.02W as measured by the Thorlabs 200W power head today. This required running the Glassman HV supply at full power (30.0kV, 31.1mA), tweaking the end grating and output coupler alignments, and cleaning the ZnSe Brewster windows on the laser tubes, and it only lasted a few seconds before dropping back to ~48W, but the laser delivered the specified power. In the factory it delivered 55W at the 10.6 micron line I am using now- I checked it with the CO2 laser spectrum analyzer- so there is more work to do.

 Hour-long trend puts the lab temperature at 19.51C

Dalsa temperature:

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.

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

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.

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.

Today, I set up a system consisting of the 520 nm laser, a 2'' mirror and two lenses of focal lengths f1 = 40 cm and f2 = 20 cm. The goal was to collimate the beam coming from the laser, so it goes parallel through the test optic at a radius of ~2.5 cm and then focus it to a radius of ~ 1.2 cm to fit the CCD dimensions of the HWS. The mirror was placed about 1 cm close to the laser and the first lens is setup at a distance~f1=40cm from the mirror. The test optic is placed between the two lenses and the second lens is placed about 10 cm from the CCD. The distance between the two lenses isn't important and could change in the future. The lenses and mirrors are all labeled.

I measured the approximate angle of divergence (0.06 rad) of the laser by taking the beam diameter at different positions along the propagation axis. This allowed for the ABCD matrix calculations to be finalized and the focal lengths of the lenses be chosen accordingly. 

In order to have more space in the box, I removed everything that was not necessary to the side.

[Aidan, Jordan, Radhika]

Radhika and Jordan identified some particulates (hair and flecks of foil) on the O-ring on the IR labs dewer. Additionally, we saw a scratch in the O-ring groove and a nick on the metal of the base of the dewer where it meets the O-ring. All were in the leaky vicinity previously identified by the He testing.

We set up a cradle to hold the dewer while we are working on it. Still needs vertical supports.

R & J replaced the O-ring with a new one with Crytox applied. 

 The measurement from the on-board PD of the Superlum SLED seems to be falling. This effect started around 5PM last night which is right about the time we moved the position of the PD that the SLED is illuminating on the optical table (via optical fiber).

Curiously, the current set point and delivered current to the SLED are dropping as well. 

I've started a long-term measurement of the HWS fiber-launcher. I'm interested in seeing how stable the output is. The HWS is currently running in the following configuration:

• SLED: QFLD-635-1S (635nm, 1mW) - current driver set to 38.02mA, thermistor set point = 10.778kOhm
• SLED coupled to patch cable
• Patch cable coupled to Newport fiber launcher FPR1-C1A which contains a FPH-CA4 fiber optic chuck (FC/APC connector). All grub screws are tighten on this (two for holding chuck, one for roll motion, one for X translation lock and one for Y translation lock)
• Output of fiber hits a 100m focal length lens (SPX043AR.16 BBAR 0.65 - 1.0um) placed approximately 100mm from the fiber output
• Output of lens is projected approximately 125mm onto the HWS where it is centered on the HWS plate

The HWS is currently running at 57Hz. The HWS code is running on HWS (10.0.1.167). It is the same as the site code with some modifications to determine information about the Gaussian beam envelope. The following data is written to file on the HWS machine in files containing 10,000 cycles. Each cycle (or row) the following data is recorded:

• GPS TIME
• PRISM_X
• PRISM_Y
• SPHERICAL_POWER
• CYLINDRICAL_POWER 
• Envelope peak intensity
• Envelope X centroid
• Envelope Y centroid
• Envelope X width
• Envelope Y width

These are saved to files on the HWS machine: ~/framearchive/C4/HWSlongterm/<GPSTIME>_CIT_HWS.txt

 I set up the SLED to test its long term performance. The test began, after a couple of false starts, around 9:15AM this morning.

The output of the fiber-optic patch cord attached to the SLED is illuminating a photo-detector. The zero-level on the PD was 72.7mV (with the lights on). Once the PD was turned on the output was ~5.50 +/- 0.01V. This is with roughly 900uW exiting the SLED.

The instructions from Superlum suggest limiting the amount of power coupled back into the fiber to less than 3%. With the current setup, the fiber is approximately 2" from the photodetector. What is the power coupled back into the fiber?

Assume a worst case of 100% of the light reflected from the PD, the wavelength is 830nm and a waist size of about 6um radius at the output of the fiber. The beam size at 4" (from the fiber output to the PD and back again) or ~100mm from the fiber is about 4.4mm radius. Therefore about (6um/4.4mm)^2 or ~2ppm will be coupled back into the fiber. This is sufficiently small.

The attached plots from dataviewer show measurements from the SLED (on-board photodetector, on-board temperature sensor, current setpoint, current limit, current to diode) over the last 15 hours.

I did a beam size/beam propagation measurement of the low power CO2 laser (Access Laser L3, SN:154507-154935)

 The Thorlabs MFF001 flipper mirror recommended by Bram has arrived. The delivery note is attached.

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.

I have spent some time with Matlab Compiler and Matlab Compiler Runtime (MCR). I could only get my hands on 2008b version so far, but I believe 2009b version will work in the same way.

Below is a set of notes based on my experience so far.

Matlab compiler installation

1. Copy the toolbox archive files to the folder where matlab is installed. To me this is /usr/matlab_2008b/ (may need to do as root or use sudo). Two files to be copied are tbx.compiler.common and tbx.compiler.glnxa64.

sudo cp tbx.compiler.* /usr/matlab_2008b/

2. Execute the install script.

cd /usr/matlab_2008b
sudo ./install

3. Enter the file installation key that came with the matlab compiler files.

4. Leave the root directory as it was.

5. Finish the installation by activating the toolbox with the license file.

Build a standalone application using matlab compiler

I created a folder called matlab_project as a place to put compiled applications, and matlab_predep as a place to put files to be deployed.

Once Matlab Compiler is installed, it can be launched from the matlab console by typing deploytool. Then I proceeded as below:

1. Create a new project by clicking the New icon (the first one from the left).

2. Choose a standalone application.

3. Click main file and Go to menu Project -> Add Files (or right_click on "main file" icon).

4. Choose the matlab file hello.m (in my case, from matlab_predep folder). hello.m could be, for example, a simple script like

function hello
     disp('Hello!');
end

5. Click the Build icon (third from the right).

When the process finishes, inside matlab_project folder I found a file called "hello.prj" and a folder called "hello". Insider the hello folder was two folders "distrib" and "src".

Install Matlab Compiler Runtime

1. Run MCRinstaller.bin as root. I found this file in the folder /usr/matlab_2008b/toolbox/compiler/deploy/glnxa64

2. Go along with the default options unless desired otherwise.

3. Add following to .bashrc, below the entries regarding EPICS. $LD_LIBRARY_PATH should now be aware of EPICS as well as MCR related paths. 

export MCR_ROOT=/opt/MATLAB/MATLAB_Compiler_Runtime
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MCR_ROOT/v79/runtime/glnxa64:$MCR_ROOT/sys/os/glnxa64:$MCR_ROOT/v79/sys/java/jre/glnxa64/jre1.6.0/lib/amd64/native_threads:$MCR_ROOT/v79/sys/java/jre/glnxa64/jre1.6.0/lib/amd64/server:$MCR_ROOT/v79/sys/java/jre/glnxa64/jre1.6.0/lib/amd64
export XAPPLRESDIR=$MCR_ROOT/v79/X11/app-defaults

4. Run the revised .bashrc by typing 'source ~/.bashrc'. Next time the user logs in, doing this won't be necessary.

Run the built application

1. Go to distrib folder to find the executable application file (e.g., hello). You will also find the executable shell script (e.g., run_hello.sh), the role of which is basically to set up environment variables and run the application, in case the environment variables are not globally set up.

2. Once in that folder, run the application by simply typing ./ and its name (e.g., ./hello). If the library environment variable is set up as in the step 3 of "Install Matlab Compiler Runtime", the application will be run and you should see the hello message as the output.


Build an application that uses HS classes

I wrote a simple script test_HS.m that takes and saves 10 images using the camera, averages the images and finds centroids. Thus the script requires the class files HS_Base, HS_Camera, HS_Image, and HS_Centroids.

I added those four class files by right-clicking Other Files (found below Main function) then choosing Add File, then clicked the build icon.
 

Installing MCR

I located the MCRInstaller on our distribution of MATLAB on the Ubuntu machine (/MATLAB_R2009b/toolbox/compiler/deploy/glnxa64/MCRInstaller.bin). I ran the installer, as root,and followed the default options to install it. Next I updated the .bashrc file to include the necessary pointers to various libraries:

I've downloaded the test_HS binary from the SVN and added the ~/test_images/ directory as recommended by Won. I then ran the code by entering ./test_HS ~/test_images/

The code ran successfully through the serial_cmd access and the image acquisition process and only crashed when it tried to access the variable mes_message. This indicates a run-time error, not a compilation error. If you examine lines 751 and 752 of HS_Camera.m you can see the typo (mes_meesage vs mes_message) in the code that is the source of the error:

Here's the output:

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.

There were known to be huge (65%) heating beam power losses on the SRM AWC table, somewhere between the CO2 laser and the test optic. Today I profiled the setup with a power meter, looking for the dominant source of losses. It turned out to be a 10" focusing lens which had the incorrect coating for 10.2 microns. I swapped this lens with a known ZnSe 10" FL lens (Laser Research Optics LX-15A0-Z-ET6.0) and confirmed the power transmittance to be >99%, as spec'd. There is now ~310 mW maximum reaching the test optic, meaning that the table losses are now only 10%.

Using a single-axis micrometer stage I also made an occlusion measurement of the heating beam radius just in front of the test optic. I moved the 10" focusing lens back three inches away from the test optic to slightly enlarge the beam size. In this position, I measure a beam radius of 3.5+/-0.25 mm at 1.5" in front of the test optic (the closest I can place the power meter). The test optic is approximately 20" from the 10" FL lens, so the beam has gone through its waist and is again expanding approaching the test optic. I believe that at the test optic, the beam is very close to 4 mm.

 See attached delivery note ...

30mm T-junctions, grounding straps and T-slot covers have arrived

 Another box of Bosch framing parts arrived today. The delivery note is attached.

Since we set up the 2-lens system focusing the laser beam to the CCD, the next step was to mount the spherical reflector (31 mm wide) and the heater (~3 mm diameter). I used a small 3-axis stage to mount the heater, providing 3 degrees of freedom that would allow to manipulate the height of the heater, its position with respect to the reflector (left-right and in-out). The reflector was mounted in such a way that we can control its rotation angle, height and horizontal displacement. The current design is not quite sophisticated as it is just a first test, however I will look into different tools in the lab to see if I can use less mounts to get the same degrees of freedom.

The new heaters are supposed to be heated using AC. We used a DC power supply and ran ~30V through the wire, however only about ~50 mA of current was running through it. Jon will look into the specs of the new heaters to see if the power supply was the problem.

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).