40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  TCS elog, Page 4 of 5  Not logged in ELOG logo
ID Date Author Typedown Category Subject
  155   Fri Sep 2 21:41:01 2011 AidanElectronicsHartmann sensorRestarting long term test of QFLD-950-3S

9:40PM PDT - I've just restarted the long term measurement of the Hartmann sensor noise with the QFLD-950-3S.

 

  184   Wed Apr 26 15:29:25 2017 AidanElectronicsHartmann sensorLong term test of fiber launcher

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

  185   Wed May 24 09:58:17 2017 AidanElectronicsElectronicsTemperature sensor batteries swapped in TCS Lab

I noticed that the TCS lab temperature sensor batteries died. Apparently they died two days ago. I swapped in some new batteries this morning.
 

  187   Thu Jul 13 10:11:57 2017 awadeElectronicsBorrowedBorrowed newport TrueRMS Supermeter

I lent your fancy Newport TrueRMS Supermeter with the thermocouple plugs on the top to the SURF student Jordon.  He has it in the cryo lab or the EE workshop with one of the PSL lab temperature probes.

Attachment 1: 2017-07-13_10.06.28.jpg
2017-07-13_10.06.28.jpg
Attachment 2: 2017-07-13_10.06.29.jpg
2017-07-13_10.06.29.jpg
  238   Tue Aug 6 19:22:28 2019 JonElectronicsComputingQIL NFS server set up

I've started building the NFS server for the QIL cymac. It's sitting on the workbench in the TCS lab next to the rack. Please don't move it or any of the parts behind it.

  239   Fri Aug 9 20:33:11 2019 JonElectronicsRing HeaterPower-regulated heater ready to use

Despite some considerable time spent, I was not able to get the Omega SCR controllers working. The first unit definitely arrived damaged. None of its LED indicator lights ever functioned, despite those on the second controller working fine under the same setup. I tried swapping in the second controller, but it has no voltage output and a red LED is illuminated which, according to the manual, means "malfunction on trigger board" or "open SCR."  Either way, the remedy is to "consult factory."

Since we have get moving with data collection, I installed a simple variable transformer (borrowed from the 40m) which steps up/down the AC voltage from 0-120 V with the turn of a knob. I soldered the leads of one of the heaters to a standard power cable which plugs directly into the transformer. I have tested it and confirmed it to work.

Attachment 1: IMG_3576.jpg
IMG_3576.jpg
Attachment 2: IMG_3577.jpg
IMG_3577.jpg
  240   Mon Aug 12 21:15:12 2019 Edita BytyqiElectronics Determining heater/reflector focus

I took images of the heat pattern projected on a piece of paper produced by the semi-circle reflector. I used 108V to drive current throught he heater. I tested the reflector without any coating and then with the dull and shiny sides of Al foil. I wasn't able to test the focal-point cut reflector because I had to glue a screw to it with epoxy which cures overnight. I will do these measurements tomorrow. Figure 2 shows the setup I used to get the data. The shiny side of Al foil is better at IR, so we will use that for the wavefront measurements.

Attachment 1: 20190812_151316.jpg
20190812_151316.jpg
Attachment 2: 20190812_151258.jpg
20190812_151258.jpg
  241   Fri Aug 16 17:05:14 2019 Edita BytyqiElectronics FLIR Images of new reflector focusing heat

We got 11 new semi-circle cut reflectors of radius ~3.6 cm. I glued a screw to the back of one reflector using the same epoxy as for the previous reflectors. Due to the bigger ROC of the reflector, a tight focus is achievable at greater distances (~15 cm).

  3   Mon Dec 28 14:48:29 2009 AidanComputingDAQVME crate has a "new" CPU - needs to be configured

I installed a recycled VME crate in the electronics rack. It currently has a Baja 4700E CPU card in it - and this needs to be configured. We also have the following cards, which are not plugged in right now.

1. ICS-110A-32 Analogue-to-Digital Converter - the jumpers need to be set on this to give it a unique memory address in the VME bus.

2. D000186 LIGO-type Anti Image card.

The CPU card needs to be configured to search it's OS binaries on the network (in this case we're going to store them on the framebuilder in Rana's lab). These settings are accessed by plugging a serial cable into the front of the card and using a terminal window to access the menu system. There are some screen caps of this below. As the card is reset we get the Start-up screen and then we can either do nothing (and a full boot will take place) or we can press a key and access the menu. From there we can restart the boot process by entering "@" or we can change the boot settings by entering "c". These are shown below:

 

 

Attachment 1: VME_boot_02.jpg
VME_boot_02.jpg
Attachment 2: VME_boot_01.JPG
VME_boot_01.JPG
Attachment 3: VME_boot_03.jpg
VME_boot_03.jpg
  4   Tue Dec 29 16:05:09 2009 FrankComputingDAQbooting VME crates from fb1

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

  5   Tue Dec 29 17:50:57 2009 AidanComputingDAQVME crate has proper boot settings

We fixed the start-up settings on the VME crate to look for a TCS startup file on fb0. The settings on the Baja 4700 are now:

Attachment 1: VME_tcs_boot_settings.jpg
VME_tcs_boot_settings.jpg
  6   Fri Jan 29 10:02:15 2010 AidanComputingDAQNew DAQ ordered

 On the advice of Ben Abbott, I've ordered the Diamond Systems Athena II computer w/DAQ, as well as an I/O board, solid state disk and housing for it. The delivery time is 4-6 weeks.

Diamond Systems Athena II

 

  17   Mon Apr 12 08:55:37 2010 AidanComputingHartmann sensorEDT frame grabber is here

 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.

  19   Thu Apr 15 01:47:47 2010 Won KimComputingHartmann sensorNotes on installing EDT PCIe4 DV frame grabber
* 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.
  20   Tue Apr 20 18:05:24 2010 AidanComputingHartmann sensorImages off the Dalsa Camera in CentOS

 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)

 

Attachment 1: Screenshot-PCI_DV_Display.png
Screenshot-PCI_DV_Display.png
Attachment 2: Screenshot-PCI_DV_Display-1.png
Screenshot-PCI_DV_Display-1.png
Attachment 3: -opt-EDTpdv.png
-opt-EDTpdv.png
  21   Wed Apr 21 06:49:51 2010 AidanComputingFrame GrabberInstalling CentOS 5.3 and the EDT frame-grabber - Part 1

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.

 

 

 

 

 

 

  22   Thu Apr 22 01:48:33 2010 Won KimComputingFrame Grabberfrom the manual install.pdf

 

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. 

  23   Thu Apr 22 08:20:51 2010 AidanComputingHartmann sensorInstalled MATLAB and Windows XP Virtualization on Hartmann machine

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"

  24   Thu Apr 22 08:22:18 2010 AidanComputingFrame Grabberfrom the manual install.pdf

Quote:

 

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.

 

  25   Mon May 3 17:42:20 2010 AidanComputingEPICSEPICS install by Alex

Alex Ivanov came in on Friday and demonstrated his EPICS kung-fu. His EPICS knig-fu is strong.

We fixed the IP address of the Hartmann machine, renamed it hartmann, and mounted the cvs drives from the frame builder. - including the EPICS base from that machine. In principle, with a new softIoc, this should have been enough to run EPICS on the hartmann machine. However, whilst the softIoc would start, it wouldn't broadcast any channels. Eventually we figured out that this was because of the Windows Virtualization adding another IP address to the hartmann machine (revealed with /sbin/ifconfig). So we removed the virtualization system and then EPICS seemed to broadcast much better.

The minutia of install isshown in the history files for the controls and root users - attached.

 

Attachment 1: history.txt
    1  cd
    2  mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
    3  echo '%_topdir %(echo $HOME)/rpmbuild' > .rpmacros
    4  ls
    5  cd rpmbuild/
    6  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18.15.1.el5.src.rpm 2
    7  cd ..
    8  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18.15.1.el5.src.rpm 2>&1 | grep -v mockb
    9  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.e15.src.rpm 2>&1 | grep -v mockb
   10  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.e15.src.rpm 2>&1 | grep -v mockb
... 183 more lines ...
Attachment 2: history_root.txt
    1  yum
    2  yum install gcc
    3  yum install make
    4  yum install tk
    5  yum install tcl
    6  yum install mm
    7  yum install kernel
    8  yum install source
    9  yum install include
   10  yum install kernel-source
... 797 more lines ...
  26   Mon May 3 17:43:48 2010 AidanComputingFrame GrabberSuccessful image capture with EDT frame grabber

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.

 

 

Attachment 1: 20100503_dalsa1m60_configuration_notes.txt
Configuring HWS to get image in CentOS
----------

9:34AM - Dalsa 1m60 turned on

----
$ /opt/EDTpdv
$ ./serial_cmd
%%this starts the serial communications device in the EDT FG but it isn't configured.

... 123 more lines ...
Attachment 2: 2010-05-03_dalsa1m60_image_test_pattern_and_spots.tif
2010-05-03_dalsa1m60_image_test_pattern_and_spots.tif
Attachment 3: 2010-05-03_dalsa1m60_image_test_pattern_right_side.tif
2010-05-03_dalsa1m60_image_test_pattern_right_side.tif
Attachment 4: dalsa_1m60.cfg
#
# CAMERA_MODEL "Dalsa 1m60 config file (freerun)"
#

# camera name/description
#
camera_class:                  "Dalsa"
camera_model:                  "1M60"
camera_info:                   "12 bit dual channel camera link"

... 39 more lines ...
  27   Tue May 4 09:18:15 2010 AidanComputingHartmann sensorAdded aliases and icons for EPICS commands and dataviewer etc. to hartmann

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"

  28   Tue May 4 10:30:07 2010 AidanComputingHartmann sensorEPICS and MEDM screen for Hartmann sensor

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

  Digitizer Board Temperature Sensor Board Temperature
Dalsa 1M60 menu command vt vt

Response from 1M60

Camera Temperature on Digitizer Board: 47.2 Celsius Camera Temperature on Sensor Board: 39.4 Celsius
Menu accessed via MATLAB: unix('/opt/EDTpdv/serial_cmd vt') MATLAB: unix('/opt/EDTpdv/serial_cmd vt')
Temperature stored in MATLAB: local variable called DBtemp (from the numerical sub-string) MATLAB: local variable called SBtemp (from the numerical sub-string)
EPICS channel written via MATLAB: unix(['ezcawrite {channel-name} ' num2str(DBtemp)]) MATLAB: unix(['ezcawrite {channel-name} ' num2str(SBtemp)])
EPICS channel defined in HWS.db HWS.db
Channel name C4:TCS-HWS_TEMP_DIGITIZER C4:TCS-HWS_TEMP_SENSOR

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

although this doesn't execute it in the background. The MATLAB routine /home/controls/matlab_scripts/read_dalsa_temperature_write_to_epics.m is run continuously to access the serial port, get the temperature data and to write it to the EPICS channels. These were then available to read in the Hartmann sensor MEDM screen which is shown below. Also shown is a StripTool monitoring the temperatures. I had just turned off a fan that was cooling the 1M60 which is why the temperature is rising.
 
 
 

 

 

Attachment 1: Screenshot-C4HWS_medm_21.adl_(edited).png
Screenshot-C4HWS_medm_21.adl_(edited).png
Attachment 2: Screenshot-StripTool_Graph_Window.png
Screenshot-StripTool_Graph_Window.png
Attachment 3: HWS.db
record(ai,"C4:TCS-HWS_TEMP_DIGITIZER")


record(ai,"C4:TCS-HWS_TEMP_SENSOR")
Attachment 4: HWS.cmd
dbLoadRecords "HWS.db"
iocInit
Attachment 5: read_dalsa_temperature_write_to_epics.m
% get the temperature off the 1M60
% written by Aidan Brooks. 22nd Apr 2010

% define aliases
ezcawrite = '/cvs/opt/apps/Linux/gds/bin/ezcawrite';


ii = 1;
while ii == 1
    [s, r] = unix('/opt/EDTpdv/serial_cmd vt');
... 54 more lines ...
  29   Tue May 4 13:35:13 2010 AidanComputingHartmann sensorHartmann temperature channels in frame builder

 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]


 

 

 

  30   Wed May 5 09:04:01 2010 AidanComputingHartmann sensorAdded /home/controls/scripts/modules directory to PYTHONPATH on hartmann

 I added the following line to ~/.bashrc

 

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

This adds the above directory to PYTHONPATH and allows those modules in that directory to be access from anywhere.

 

  31   Wed May 5 18:45:51 2010 AidanComputingHartmann sensorPython code to interface the Dalsa1M60 and export the temperature to EPICS

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

Attachment 1: dalsa_to_epics.py
#!/usr/bin/python

# Import the Dalsa1M60 packzge
import Dalsa1M60, subprocess

# define the serial command location
serial_cmd_location = '/opt/EDTpdv/serial_cmd'

# start a loop that continually gets the temperatures
getTemperatures = 1
... 18 more lines ...
Attachment 2: VerifyTemperature.py
#!/usr/bin/python

# part of the Dalsa1M60 package
# a module for verifying the temperature of the Dalsa 1M60
#
# The serial command 'vt' is sent to the camera. The camera responds as follow
s
#    > vt
#    Camera Temperature on Digitzer Board: 47.2 Celsius
#    Camera Temperature on Sensor Board: 39.4 Celsius
... 65 more lines ...
Attachment 3: dalsa_1m60.cfg
#
# CAMERA_MODEL "Dalsa 1m60 config file (freerun)"
#

# camera name/description
#
camera_class:                  "Dalsa"
camera_model:                  "1M60"
camera_info:                   "12 bit dual channel camera link"

... 51 more lines ...
  32   Thu May 6 10:34:38 2010 AidanComputingHartmann sensorEPICS and MEDM screen for Hartmann sensor - part 2

I added the camera parameters to EPICS and the MEDM screen. These are available as channels now in EPICS and eventually there will be a python script that writes the EPICS value to those channels, but right now it is just a python script that reads the values off the Dalsa camera.

I updated the channels in /cvs/cds/caltech/chans/daq/C4TCS.ini so that these are saved to the daq and I also restarted the daq daemon.

The python script that gets the camera parameters is here: scripts/Dalsa1M60/GetCameraParameters.py and the script that writes the parameters to the EPICS channels is here scripts/dalsa_to_epics.py.

These are attached as is C4TCS.ini and HWS.db which defines the new channels.

Attachment 1: dalsa_to_epics.py
#!/usr/bin/python

# Import the Dalsa1M60 packzge
import Dalsa1M60, subprocess

# define the serial command location
serial_cmd_location = '/opt/EDTpdv/serial_cmd'

# start a loop that continually gets the temperatures
getTemperatures = 1
... 75 more lines ...
Attachment 2: GetCameraParameters.py
#!/usr/bin/python

# NAME
#       GetCameraParameters - a module for getting the Dalsa 1M60 parameters
#
# PACKAGE
#       Part of the Dalsa1M60 python package
#
# SYNOPSIS
#       GetCameraParameters( serial_cmd_location  )
... 412 more lines ...
Attachment 3: HWS.db
record(ai,"C4:TCS-HWS_TEMP_DIGITIZER")
record(ai,"C4:TCS-HWS_TEMP_SENSOR")
record(ai, "C4:TCS-HWS_TAP1GAIN")
record(ai, "C4:TCS-HWS_TAP2GAIN")
record(ai, "C4:TCS-HWS_PRETRIGGER")
record(ai, "C4:TCS-HWS_DATA_MODE")
record(ai, "C4:TCS-HWS_BINNING_MODE")
record(ai, "C4:TCS-HWS_GAIN_MODE")
record(ai, "C4:TCS-HWS_OUTPUT_CONFIG")
record(ai, "C4:TCS-HWS_EXPOSURE_MODE")
... 27 more lines ...
Attachment 4: C4TCS.ini
[default]
dcuid=4
datarate=16
gain=1.0
acquire=1
ifoid=0
datatype=4
slope=1.0
offset=0
units=NONE
... 14 more lines ...
  33   Thu May 6 12:32:11 2010 AidanComputingHartmann sensordalsa_to_epics Python script crashed ...

Here's the error:

 

 Traceback (most recent call last):

  File "./dalsa_to_epics.py", line 81, in ?
    stdout = subprocess.PIPE)    
  File "/usr/lib64/python2.4/subprocess.py", line 550, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.4/subprocess.py", line 916, in _execute_child
    errpipe_read, errpipe_write = os.pipe()
OSError: [Errno 24] Too many open files

[2]+  Exit 1                  ./dalsa_to_epics.py  (wd: ~/scripts)
(wd now: /cvs/users/abrooks/advLigo/HWS)
 
  34   Thu May 6 21:32:26 2010 Won KimComputingHartmann sensorPeak detection and centroiding code

 

 

Attached is .m file of the custom function that I wrote and used to automatically detect peaks in a Hartmann image,
and calculate the centroid corrdinates of each of those peaks.

A simple example of its usage,  provided that myimage is a two-dimensional image array obtained from the camera, is

 

radius = 10;

peak_positions = detect_peaks_uml(myimage,radius);

no_of_peaks = length(peak_positions);

centroids_array = zeros(no_of_peaks);

for k = 1:no_of_peaks

  centroids_array(k,1) = peak_positions(k).WeightedCentroid(1);

  centroids_array(k,2) = peak_positions(k).WeightedCentroid(2);

end

 

I chose my value of radius by looking at spots in a sample image and counting the number of pixels across a peak. It may be 
more useful to automatically obtain a value for the
radius. I may run some tests to see how different choices of radius
affect the centroid calculations. 

I may also need to add some error checking and/or image validating codes, but so far I have not encountered any problems. 

Please let me know if anyone needs more explanation!

Won

Attachment 1: detect_peaks_uml.m
function ctr = detect_peaks_uml(image,radius)
% Usage example:
% positions = detect_peaks_uml(myimage,10);
% 
% total number of peaks detected: length(positions.WeightedCentroid)
% access the coordinates of the nth peak:
% positions(n).Weightedcentroid(1), positions(n).WeightedCentroid(2)

weighted_image = image .^ 2;
background = imopen(weighted_image,strel('disk',radius));
... 11 more lines ...
  35   Tue May 11 10:32:00 2010 AidanComputingHartmann sensorPeak detection and centroiding code - review

This looks really efficient! However, I think there's a systematic error in the calculation. I tested it on some simulated data and it had trouble getting the centroids exactly right. I need to better understand the functions that are called to get an idea of what might be the problem.

 

Quote:

 

 

Attached is .m file of the custom function that I wrote and used to automatically detect peaks in a Hartmann image,
and calculate the centroid corrdinates of each of those peaks.

A simple example of its usage,  provided that myimage is a two-dimensional image array obtained from the camera, is

 

radius = 10;

peak_positions = detect_peaks_uml(myimage,radius);

no_of_peaks = length(peak_positions);

centroids_array = zeros(no_of_peaks);

for k = 1:no_of_peaks

  centroids_array(k,1) = peak_positions(k).WeightedCentroid(1);

  centroids_array(k,2) = peak_positions(k).WeightedCentroid(2);

end

 

I chose my value of radius by looking at spots in a sample image and counting the number of pixels across a peak. It may be 
more useful to automatically obtain a value for the
radius. I may run some tests to see how different choices of radius
affect the centroid calculations. 

I may also need to add some error checking and/or image validating codes, but so far I have not encountered any problems. 

Please let me know if anyone needs more explanation!

Won

 

 

 

Attachment 1: test_centroid_code.m
% generate an blank image
imarr = zeros(1024, 1024);

% get the background and intensity levels
bckgrd = 700.0;
I1 = 56000.0;

% get the 2D coordinate arrays
x = 1:1024;
... 61 more lines ...
  36   Thu May 13 16:54:46 2010 AidanComputingHartmann sensorRunning MATLAB programs in C on CentOS - only use R2008b for less hassle

 After much effort trying to get a MATLAB routine to compile in C I discovered the following pieces of information.

1. CentOS will not install a gcc compiler more recent than 4.1.2 with yum install. This is circa 2007. If you want a more recent compiler it must be installed manually.

2. To compile and link C programs that call the MATLAB engine, they must be compiled in MATLAB using the mex command. Every version of MATLAB after R2008b requires the gcc compiler 4.2.3.

3. Building gcc 4.2.3 takes a lot more than 1 hour of compile time. I accidentally killed the build process and gave it up as a lost cause. 

 

  37   Mon May 17 19:41:13 2010 AidanComputingFrame GrabberC code that calls MATLAB engine and centroiding algorithms

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 
Attachment 1: simple_hartmann.c
/**
 * @file
 * An example program to show usage of EDT PCI DV library to acquire and
 * optionally save single or multiple images from devices connected to EDT
 * high speed digital video interface such as the PCI DV C-Link or PCI DV
 * FOX / RCX.
 * 
 * Provided as a starting point example for adding digital video acquisition
 * to a user application.  Includes optimization strategies that take
 * advantage of the EDT ring buffer library subroutines for pipelining image
... 521 more lines ...
Attachment 2: centroid_image.m
function centroids = centroid_image(image, centroids)
%
% This function centroids a supplied image. It returns a centroids structure
%
% 'centroids' structure
% --------------------
% centroids.image_background_level  - the background intensity of an image
%                                     with no illumination on it
%          .spot_radius             - the radius of a hartmann spot
%          .spot_threshold_level    - the minimum intensity of pixels used to
... 98 more lines ...
Attachment 3: get_defocus.m
function defocus = get_defocus(centroids)
% 
% a function to extract the defocus of the gradient field
%
% 'centroids' structure
% --------------------
% centroids.image_background_level  - the background intensity of an image
%                                     with no illumination on it
%          .spot_radius             - the radius of a hartmann spot
%          .spot_threshold_level    - the minimum intensity of pixels used to
... 56 more lines ...
Attachment 4: build_simple_hartmann.sh
#!/bin/bash


gcc -O2 -I/opt/EDTpdv -I/apps/matlab_R2008b/extern/include -I/apps/matlab_R2008b/simulink/include -DMATLAB_MEX_FILE -c -D_GNU_SOURCE -fexceptions -I/apps/matlab_R2008b/extern/include -DMX_COMPAT_32 -O -DNDEBUG simple_hartmann.c


gcc -O2 -I/opt/EDTpdv -I/apps/matlab_R2008b/extern/include -I/apps/matlab_R2008b/simulink/include -DMATLAB_MEX_FILE -c -D_GNU_SOURCE -fexceptions -I/apps/matlab_R2008b/extern/include -DMX_COMPAT_32 -O -DNDEBUG /apps/matlab_R2008b/extern/src/mexversion.c

gcc -O2 -O -I/opt/EDTpdv -o /opt/EDTpdv/hartmann/bin/simple_hartmann simple_hartmann.o mexversion.o -L/opt/EDTpdv -lpdv -lpthread -lm -ldl -Wl,-rpath-link,/apps/matlab_R2008b/bin/glnxa64 -L/apps/matlab_R2008b/bin/glnxa64 -leng -lmx -lstdc++
  38   Tue May 18 09:33:44 2010 AidanComputingEPICSAdded defocus and other Hartmann sensor channels to EPICS and DAQ

 I've added the following channels to the HWS softIoc in /cvs/cds/caltech/target/softIoc/HWS.db

 

 

EPICS and DAQ restart procedure

  1. Kill the existing softIoc. Use a "ps -e | grep softIoc" command to determine the process id.
  2. After editing the HWS.db file restart the softIoc with the following command:
[controls@hartmann softIoc]$  /cvs/opt/epics-3.14.10-RC2-i386/base/bin/linux-x86/softIoc -S  HWS.cmd &
[3] 11280
[controls@hartmann softIoc]$ dbLoadRecords "HWS.db"
iocInit
Starting iocInit
############################################################################
## EPICS R3.14.10- $R3-14-10-RC2$ $2008/10/10 15:01:51$
## EPICS Base built Oct 28 2009
############################################################################
iocRun: All initialization complete

        3. Edit the /cvs/cds/caltech/chans/daq/C4TCS.ini file and kill the daqd process on fb1. It should restart automatically.

Done!

 

  39   Thu May 20 08:20:54 2010 AidanComputingHartmann sensorCentroiding algorithm and code to generate simulated data

 Here's a copy of an email I distributed today that describes the centroid and simulation code I wrote.

Hi Won,

I've written some code that generates an image of Gaussian spots and provides you with the coordinates of the centers used to generate those spots. There is the facility to turn on i) photo-electron shot noise, ii) random displacement of the nominal positions of the centers from a regular array and iii) 12-bit digitization to more accurately model the output from a CCD.

I've included an example routine that calls this function and then centroids those spots using a variant of your centroiding algorithm.

You should be able to use this to generate reliable simulated data to test versions of your centroiding algorithm.

Cheers,
Aidan.

Attached files: 
1. test_spot_generation_and_centroiding.m     - the example routine. Run this first
2. generate_simulated_spots.m         - the function to generate the simulated spots in an image and as a set of positions
3. centroid_image.m - the function to centroid an image

Attachment 1: test_spot_generation_and_centroiding.m
% example usage of generate_simulated_spots and centroid_image

clear all
close all



%% example 1 - 
%----------------------------------------------------------
npixels = 1024;          % the number of pixels in the image
... 143 more lines ...
Attachment 2: generate_simulated_spots.m
function output = generate_simulated_spots(npixels, digitizeFLAG, ...
                          IntensityNoiseFLAG, positionNoiseFLAG)
%
% a function to generate an image of spots to centroid and to provide the original 
% locations of the spots. 
% 
% input
% -----
% npixels - pixels in output image
% digitizeFLAG:          0 - floating point array is output
... 160 more lines ...
Attachment 3: centroid_image.m
function centroids = centroid_image(image, centroids)
%
% This function centroids a supplied image. It returns a centroids structure
%
% 'centroids' structure
% --------------------
% centroids.image_background_level  - the background intensity of an image
%                                     with no illumination on it
%          .spot_radius             - the radius of a hartmann spot
%          .spot_threshold_level    - the minimum intensity of pixels used to
... 95 more lines ...
  61   Wed Jun 30 00:00:13 2010 Kathryn and WonComputingHartmann sensorrms of centroid position changes

Given below is a brief overview of calculating rms of spot position changes to test the accuracy/precision of the centroiding code. Centroids are obtained by summing over the array of size 30 by 30 around peak pixels, as opposed to the old method of using matlab built-in functions only. Still peak pixel positions were obtained by using builtin matlab function. Plese see the code detect_peaks_bygrid.m for bit more details.

 

My apologies for codes being well modularised and bit messy...

 

Please unzip the attached file to find the matlab codes.

The rest of this log is mainly put together by Kathryn.

 

Won

 

(EDIT/PS) The attached codes were run with raw image data saved on the hard disk, but it should be relatively easy to edit the script to use images acquired real time. We are yet to play with real-time images, and still operating under Windows XP...

---
When calculating the rms, the code outputs the results of two
different methods. The "old" method is using the built-in matlab
method while the "new" method is one Won constructed and seems to
give a result that is closer to the expected value. In calculating
and plotting the rms, the following codes were used:

- centroid_statics_raw_bygrid.m (main script run to do the analysis)
- process_raw.m (takes raw image data and converts them into 2D array)
- detect_peaks_bygrid.m (returns centroids obtained by old and new methods)
- shuffle.m (used to shuffle the images before averaging)

The reference image frame was obtained by averaging 4000 image frames,
the test image frames were obtained by averaging 1, 2, 5, 10 ... 500,
1000 frames respectively, from the remaining 1000 images.

In order to convert rms values in units of pixels to wavefront
aberration, do the following:

aberration = rms * pixel_width * hole_spacing / lever_arm

pixel_width: 12 micrometer
hole_spacing: about 37*12 micrometer
lever_arm: 0.01 meter

rms of 0.00018 roughly corresponds to lambda over 10000.

Note: In order to get smaller rms values the images had to be shuffled
before taking averages. By setting shuffle_array (in
centroid_statics_raw_bygrid.m) to be false one can
turn off the image array shuffling.

N_av        rms

1     0.004018866673087
2     0.002724680286563
5     0.002319477846009
10    0.001230553835673
20    0.000767638027270
50    0.000432681002432
100   0.000427139665006
200   0.000270955332752
500   0.000226521040455
1000  0.000153760240692

fitted_slope = -0.481436501422376

Here are some plots:

rms_plot_shuffle.jpgrms_plot_noshuffle.jpg

---

Next logs will be about centroid testing with simulated images, and wavefront changes due to the change in the camera temperature!

(PS) I uploaded the same figure twice by accident, and the site does not let me remove a copy!...

Attachment 2: rms_plot_shuffle.jpg
rms_plot_shuffle.jpg
Attachment 4: eLOG.zip
  63   Sun Jul 4 06:45:50 2010 Kathryn and WonComputingHartmann sensoranalyzing the wavefront aberration

Happy Fourth of July!

The following is a brief overview of how we are analyzing the wavefront aberration and includes the aberration parameters calculated for 9 different temperature differences. So far we are still seeing the cylindrical power even after removing the tape/glue on the Hartmann plate. Attached are the relevant matlab codes and a couple of plots of the wavefront aberration.

We took pictures when the camera was in equilibrium at room temperature and then at each degree increase in camera temperature as we heated the room using the air conditioner. For each degree increase in camera temperature, we compared the spot positions at the increased temperature to the spot positions at room temperature. We used the following codes to generate the aberration parameters and make plots of the wavefront aberration:

-build_M.m (builds 8 by 8 matrix M from centroid displacements)
-wf_aberration_temperature_bygrid.m (main script)
-wf_from_parms.m (generates 2D aberration array from aberation parameters)
-intgrad2.m (generates 2D aberration array from an interpolated array of centroid displacements)

In order to perform the "inverse gradient" method to obtain contours, we first interpolated the centroid displacement vectors to generate a square array. As this array has some NaN (not a number) values, we cropped out some outer region of the array and used array values from (200,200) to (800,800). Sorry we forgot to put that part of the code in wf_aberration_temperature_bygrid.m.

The main script wf_aberration_temperature_bygrid.m needs to be revised so that the sign conventions are less confusing... We will update the code later.

The initial and final temperature values are as follows:

 

  Hand-held Digitizer Board Sensor Board
Initial 30.8 44.4 36.0
Final 40.8 51.2 43.2

 

Aberration parameters:


1) Comparing high temp (+10)  with room temp


        p: 1.888906773203923e-004
       al: -0.295042766811686
      phi: 0.195737681653530
        c: -0.001591869846958
        s: -0.003826146141562
        b: 0.098283157674967
       be: -0.376038636781319
        a: 5.967617809296910


2) Comparing +9 with room temp


        p: 1.629083055002727e-004
       al: -0.222506109890745
      phi: 0.193334452094940
        c: -0.001548838746542
        s: -0.003404217451916
        b: 0.091368295953142
       be: -0.351830698303612
        a: 5.764068008962653


3) Comparing +8 with room temp


        p: 1.485283322069376e-004
       al: -0.212605187544093
      phi: 0.206716196097728
        c: -0.001425962488852
        s: -0.003148796701331
        b: 0.089936286297599
       be: -0.363538909377296
        a: 5.546514425485094


4) Comparing +7 with room temp


        p: 1.284124028380585e-004
       al: -0.163672705473379
      phi: 0.229219952949728
        c: -0.001452457146947
        s: -0.002807207555944
        b: 0.084090100490331
       be: -0.379195428095102
        a: 5.289173743478881


5) Comparing +6 with room temp


        p: 1.141756950753851e-004
       al: -0.149439038317734
      phi: 0.240503450300707
        c: -0.001350015836130
        s: -0.002529240946848
        b: 0.078118977034120
       be: -0.326704416216547
        a: 4.847406652448727


6) Comparing +5 with room temp


        p: 8.833496828581757e-005
       al: -0.071871278822766
      phi: 0.263210114512376
        c: -0.001257787180513
        s: -0.002095618522105
        b: 0.069587080420443
       be: -0.335912998511077
        a: 4.542557551218057


7) Comparing +4 with room temp


        p: 6.217428324604411e-005
       al: 0.019965235199575
      phi: 0.250991433584904
        c: -0.001266061216964
        s: -0.001568527823273
        b: 0.058323732750548
       be: -0.289315790283207
        a: 3.957825468583509


8) Comparing +3 with room temp


        p: 4.781068895714900e-005
       al: 0.140720713391208
      phi: 0.270865276786418
        c: -0.001228146894728
        s: -0.001371110045136
        b: 0.052794990899554
       be: -0.273968130963666
        a: 3.591187350052610


9) Comparing +2 with room temp


        p: 2.491163442408281e-005
       al: 0.495136135872766
      phi: 0.220727346409557
        c: -9.897729773516012e-004
        s: -0.001076008621974
        b: 0.048467660428427
       be: -0.280879088681660
        a: 3.315430577872808


10) Comparing +1 with room temp


       p: 8.160828332639811e-006
      al: 1.368853902659128
     phi: 0.116300954280238
       c: -6.149390553733007e-004
       s: -3.621216621887707e-004
       b: 0.025454969698557
      be: -0.242584267252882
       a: 1.809039775332749

The first plot is of the wavefront aberration obtained by integrating the gradient of the aberration and the second plot fits the aberration according to the aberration parameters so is smoother since it is an approximation.


Attachment 1: eLOG.zip
Attachment 2: wf_aberration_plot_hightemp_byintegration.jpg
wf_aberration_plot_hightemp_byintegration.jpg
Attachment 3: wf_aberration_plot_hightemp_fitted.jpg
wf_aberration_plot_hightemp_fitted.jpg
  66   Tue Jul 20 15:45:51 2010 AidanComputingGeneralAdd fixed IP addresses to local machines in TCS lab

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

  67   Tue Jul 20 18:13:06 2010 AidanComputingGeneralAdded TCS channels to frame builder

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

 contents of tcs_daq: /target/TCS_westbridge.db

grecord(ai,"C4:TCS-ATHENA_ADC0")
{
field(DTYP,"ATHENA")
field(INP,"#C0 S0")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC1")
{
       field(DTYP,"ATHENA")
field(INP,"#C0 S1")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC2")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S2")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC3")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S3")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC4")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S4")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC5")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S5")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC6")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S6")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC7")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S7")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC8")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S8")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC9")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S9")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC10")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S10")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC11")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S11")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC12")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S12")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC13")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S13")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC14")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S14")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC15")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S15")
        field(SCAN,".1 second")
}
grecord(ao,"C4:TCS-ATHENA_DAC0")
{
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S0")
        field(HOPR,"32768")
        field(LOPR,"-32768")
}
 
grecord(ao,"C4:TCS-ATHENA_DAC1")
{
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S1")
}
grecord(bi,"bi0")
{
        field(SCAN,".1 second")
field(DTYP,"ATHENA")
field(INP,"#C0 S8")
        field(ZNAM,"zero")
        field(ONAM,"one")
}
grecord(bo,"C4:TCS-ATHENA_BO0")
{
        field(DOL,"HeartBeat")
        field(OMSL,"closed_loop")
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S1")
        field(ZNAM,"zero")
        field(ONAM,"one")
}
grecord(bo,"C4:TCS-ATHENA_BO1")
{
        field(DOL,"LevelAlarm")
        field(OMSL,"closed_loop")
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S2")
        field(ZNAM,"zero")
        field(ONAM,"one")
}
grecord(bo,"C4:TCS-ATHENA_BO2")
{
        field(DOL,"Pressure_OK")
        field(OMSL,"closed_loop")
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S3")
        field(ZNAM,"zero")
        field(ONAM,"one")
}
 
 

 

  68   Thu Jul 22 11:02:59 2010 AidanComputingGeneralRestarted hartmann machine

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.

 

 

  70   Fri Jul 23 10:33:08 2010 AidanComputingHartmann sensorDalsa camera ADC 8th digitizer error

I plotted a histogram of the total intensity of the Hartmann sensor when illuminated and found that the 128 count problem extends all the way up through the distribution. This isn't unreasonable since that digitizer is going to be called on mutliple times.

First things first, the value of 128 equals a 1 in the 8th digitizer, so for a 16-bit number in binary, it looks like this: 0000 0000 1000 0000 and in hex-code 080

The values of the peaks in the attached distribution are as follows:

 

Number of counts Hex Code

128

 080
384  180
640  280
896  380
1152  480
1408  580
1664  680
1920  780
2176  880
2432  980
2688  A80
2944  B80
3200  C80

 

Attachment 1: histogram_of_dalsa_intensity.pdf
histogram_of_dalsa_intensity.pdf
  71   Fri Jul 23 12:33:51 2010 AidanComputingHartmann sensorInvar clamp scatter

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

  72   Fri Jul 23 12:38:58 2010 AidanComputingHartmann sensorImages for Dalsa

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.

 

Attachment 1: dark_0000.jpg
dark_0000.jpg
Attachment 2: bright_0000.jpg
bright_0000.jpg
  73   Fri Jul 23 19:52:49 2010 AidanComputingHartmann sensorDalsa camera ADC 8th digitizer error

I've attached an image that shows the locations of those pixels that record a number of counts = (2*n-1)*128. 

The image is the sum of 200 binary images where pixels are given values of 1 if their number of counts = (2*n-1)*128 and 0 otherwise.

The excess of counts is clearly coming from the left hand tap. This is good news because the two taps have independent ADCs and it suggests that it is only a malfunctioning ADC on the LHS that is giving us this problem.

Quote:

I plotted a histogram of the total intensity of the Hartmann sensor when illuminated and found that the 128 count problem extends all the way up through the distribution. This isn't unreasonable since that digitizer is going to be called on mutliple times.

First things first, the value of 128 equals a 1 in the 8th digitizer, so for a 16-bit number in binary, it looks like this: 0000 0000 1000 0000 and in hex-code 080

The values of the peaks in the attached distribution are as follows:

 

Number of counts Hex Code

128

 080
384  180
640  280
896  380
1152  480
1408  580
1664  680
1920  780
2176  880
2432  980
2688  A80
2944  B80
3200  C80

 

 

Attachment 1: image-location-of-excess_pixel_count_pixels.jpg
image-location-of-excess_pixel_count_pixels.jpg
  75   Sun Jul 25 16:24:56 2010 AidanComputingSLEDSuperlum SLED test integrated with DAQ - new channel names

 I added some new channels to the Athena DAQ that record the diagnostic channels from the Superlum SLED.

  • C4:TCS-ATHENA_I_SET_VOLTS:  - the set current signal in Volts (1V = 1A)
  • C4:TCS-ATHENA_I_ACTUAL_VOLTS:   - a signal proportional to the actual current flowing to the SLED (1V = 1A)
  • C4:TCS-ATHENA_I_LIM_VOLTS: - the current limit signal in volts (1V = 1A)
  • C4:TCS-ATHENA_TEMP_SENS_V:   - the signal from the on-board temperature sensor [thermistor] (1V = 10kOhm ?)
  • C4:TCS-ATHENA_PD_VOLTAGE: - the signal from the on-board photodetector (1V = 1A?)

The ioc that handles the EPICS channels is on tcs_daq(10.0.1.34) in /target/TCS_westbridge.db

The channels are added to the frame builder in /cvs/cds/caltech/chans/daq/C4TCS.ini

Currently, the driver for the SLED is ON but the current to the SLED is off. This is to check that the zero value of the PD_VOLTAGE signal doesn't wander.

Also, the input noise of the Athena is around +/- 10 counts (where 2^15 counts = 10V) which is a pretty poor 3mV.

  76   Mon Jul 26 09:42:30 2010 AidanComputingSLEDLong term test on SLED started - Day 0

 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.

Attachment 1: SLED_superlum_long_term_test_0001A.pdf
SLED_superlum_long_term_test_0001A.pdf
Attachment 2: SLED_superlum_long_term_test_0001B.pdf
SLED_superlum_long_term_test_0001B.pdf
  82   Fri Jul 30 10:04:54 2010 AidanComputingHartmann sensorRestarted the HWS EPICS channels

 Restarted the HWS EPICS channels on hartmann with the following command:

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

  83   Fri Jul 30 11:01:31 2010 AidanComputingHartmann sensorEPICS softIoc alias

 I added an alias HWSIoc to controls which can be used to start the HWS EPICS softIoc.

 

alias HWSIoc='/cvs/cds/caltech/target/softIoc/startHWSIOC.sh'
 
and the bash script is:
 

#!/bin/bash
 
cd /cvs/cds/caltech/target/softIoc
 
/cvs/opt/epics-3.14.10-RC2-i386/base/bin/linux-x86/softIoc -S  /cvs/cds/caltech/
target/softIoc/HWS.cmd &
 
cd -
 

 

  84   Fri Jul 30 13:38:39 2010 James KunertComputingHartmann sensorSummary of Thermal Defocus Data Analysis

Below is a table summarizing the results of recent thermal defocus experiments. The values are the calculated change in measured defocus per unit temperature change of the sensor:

Experiment 72710a 72710b 72810a 72910a
DeltaS/DeltaT (x) [m^-1/K] -1.31E-4 -1.46E-4 -1.40E-4 -1.52E-4
DeltaS/DeltaT (y) [m^-1/K] -1.63E-4 -1.53E-4 -1.56E-4 -1.70E-4

More detail on these experiments will be available in my second progress report, which will be uploaded to the LIGO DCC by next Monday.

The main purpose of this particular eLog is to summarize what functions I wrote and used to do this data analysis, and how I used them. All relevant code which is referenced here can be found on the SVN; I uploaded my most recent versions earlier today.

Here is a flowchart summarizing the three master functions which were specifically addressed for each experiment:

ThermDefocMasterFunctions.png

py4plot.m is probably the most complicated of these three functions, in terms of the amount of data analysis done, so here's a flowchart which shows how the function works and the main subfunctions that it addresses:

ThermDefoc--py4plot.png

 

Also, here is a step-by-step example of how these functions might be used during a particular experiment:

 

(1)Suppose that I have an experiment which I have named "73010a", in which I wish to take 40 images of 200 sums. I would open the code for framesumexport2.py and change lines 7, 8 and 17 to read:


7  LoopN=40
8 SumN=200
17 mainoutbase="73010a"

And I would then save the changes. I would double-check that the output basename had indeed been changed to 73010a (it will overwrite existing data files, if you forget to change the basename before running it). I would then let the script run (changing the set temperature of the lab after the first summed image was taken). Note that the total duration of the measurement is a function of how many images are summed and how many summed images are taken (in this example, if I was taking each single image at a rate of 11Hz, data collection would take ~20 seconds and data processing (summing the images) would take ~4 minutes (on the order of ~1 second per image in the sum) (the script isn't very quick at summing images, obviously).

EDIT(7/30 3:40pm):  I just updated framesumexport2.py so that the program prompts you for this information. I also changed enabled execute permissions on the copy of the code on the Hartmann machine located in /users/jkunert/, so going to that directory and typing ./framesumexport2.py then inputting the information when prompted is all you need to do now. No need to go change around the actual code every time, any more.

 

(2)Once data collection had ceased entirely, I would open MATLAB and enter the following:

[x,y,dx,dy,time,M,centroids]=pyanalyze_uni('73010a',40);

The function would then look for 73010a.raw and 73010a.txt in ./opt/EDTpdv/ and import the 40 images individually and centroid them. The x and y outputs are the centroid locations. If, for example, 952 centroids were located, x and y would be 952x1x40 arrays. M would be a 40x4 array of the form:

[time_before_img_taken      time_after_img_taken      digitizer_temp      sensor_temp]

 

(3)Once MATLAB had finished the previous function, I would input:

tG=struct;
py4plot('73010a',0,39,x,y,'73010a','200',[1 952],2,tG)

The inputs are, respectively:

(1)python output basename,
(2)first image to analyze (where the first image is image 0),
(3)last image to analyze,
(4)x data (or, rather, data to analyze. to analyze y instead, just flip around "x" and "y" in the input),
(5)y data (or, if you want to analyze the y-direction, "x" would be the entry here),
(6)experiment name,
(7)number of sums in each image (as a string),
(8)range of centroids to include in analysis (if you have 952 centroids, for example, and no ridiculous noise at the edges of the CCD, then [1 952] would be the best entry here),
(9)outlier tolerance (number of standard deviations from initial fit line that a datapoint must be within to be included in the second line fitting, in the dx vs x plot),
(10)exponential fitting structure (input an empty structure unless the temperature/time exponential fit turns out poorly, in which case a better fit parameter guess can be inputted as field tG.guess)

  85   Fri Jul 30 19:22:24 2010 AidanComputingEPICSWaveform Channel Access for storing centroids

 A waveform channel was added to the HWS softIoc on hartmann. This allows arrays of data to be stored in a single channel. It's not clear whether it is storing this data as a set of number or strings. However, the values can be changed by the following command:

caput -a -n C4:TCS-HWS_CENTROIDSX 5 1,2,3,4,5

Although the <no of values> entry doesn't seem to actual enforce anything - you can have more or less values than this in the array and they are still added to the channel. What does seem to be necessary is no spaces between the commas and the values of the array.

This also works:

[controls@fb1 cds]$ caput -a -n C4:TCS-HWS_CENTROIDSX 2 1,2,3n
Old : C4:TCS-HWS_CENTROIDSX          1,2,35.4342 
New : C4:TCS-HWS_CENTROIDSX          1,2,3n 
which suggests that this is really a string variable - even with the -n enforce. The cainfo command suggests this as well. 

[controls@fb1 cds]$ cainfo C4:TCS-HWS_CENTROIDSX
C4:TCS-HWS_CENTROIDSX
    State:         connected
    Host:          
    Access:        read, write
    Data type:     DBR_STRING (native: DBF_STRING)
    Element count: 1
 
 

Usage: caput [options] <PV name> <PV value>

       caput -a [options] <PV name> <no of values> <PV value> ...

  -h: Help: Print this message

Channel Access options:

  -w <sec>:  Wait time, specifies longer CA timeout, default is 1.000000 second

Format options:

  -t: Terse mode - print only sucessfully written value, without name

Enum format:

  Default: Auto - try value as ENUM string, then as index number

  -n: Force interpretation of values as numbers

  -s: Force interpretation of values as strings

Arrays:

  -a: Put array

      Value format: number of requested values, then list of values


 

  86   Fri Jul 30 21:19:05 2010 AidanComputingEPICSWaveform Channel Access for storing centroids

After some discussion with Frank we figured out how to edit the record type in HWS.db so that the waveform/array channel actually behaved like a numerical array and not like a single string. This just involved defining the data type and the element count in the record definition, like so:

record(waveform, "C4:TCS-HWS_CENTROIDSX")
{
field(EGU,"PIXELS")
field(HOPR,"1024")
field(LOPR,"0")
field(FTVL,"DOUBLE")
field(NELM,"1000")
}
 

and then when the ioc was rebooted, examination of the channel showed the following:

 

[controls@hartmann softIoc]$ cainfo C4:TCS-HWS_CENTROIDSX
C4:TCS-HWS_CENTROIDSX
    State:         connected
    Host:          hartmann:5064
    Access:        read, write
    Data type:     DBR_DOUBLE (native: DBF_DOUBLE)
    Element count: 1000
 
 
[controls@hartmann softIoc]$ caput -a -n C4:TCS-HWS_CENTROIDSX 10 1 2 3 4 5 6 7 8 9 10 11 12 13.1
Old : C4:TCS-HWS_CENTROIDSX 13 1 2 3 4 5 6 7 8 9 10 11 12 13.1 
New : C4:TCS-HWS_CENTROIDSX 13 1 2 3 4 5 6 7 8 9 10 11 12 13.1 
 
 
[controls@hartmann softIoc]$ caget C4:TCS-HWS_CENTROIDSX
C4:TCS-HWS_CENTROIDSX 1000 1 2 3 4 5 6 7 8 9 10 11 12 13.1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 

 

Quote:

 A waveform channel was added to the HWS softIoc on hartmann. This allows arrays of data to be stored in a single channel. It's not clear whether it is storing this data as a set of number or strings. However, the values can be changed by the following command:

caput -a -n C4:TCS-HWS_CENTROIDSX 5 1,2,3,4,5

Although the <no of values> entry doesn't seem to actual enforce anything - you can have more or less values than this in the array and they are still added to the channel. What does seem to be necessary is no spaces between the commas and the values of the array.

This also works:

 

[controls@fb1 cds]$ caput -a -n C4:TCS-HWS_CENTROIDSX 2 1,2,3n
Old : C4:TCS-HWS_CENTROIDSX          1,2,35.4342 
New : C4:TCS-HWS_CENTROIDSX          1,2,3n 
which suggests that this is really a string variable - even with the -n enforce. The cainfo command suggests this as well. 

 

 

[controls@fb1 cds]$ cainfo C4:TCS-HWS_CENTROIDSX
C4:TCS-HWS_CENTROIDSX
    State:         connected
    Host:          
    Access:        read, write
    Data type:     DBR_STRING (native: DBF_STRING)
    Element count: 1
 
 

 

 

Usage: caput [options] <PV name> <PV value>

       caput -a [options] <PV name> <no of values> <PV value> ...

  -h: Help: Print this message

Channel Access options:

  -w <sec>:  Wait time, specifies longer CA timeout, default is 1.000000 second

Format options:

  -t: Terse mode - print only sucessfully written value, without name

Enum format:

  Default: Auto - try value as ENUM string, then as index number

  -n: Force interpretation of values as numbers

  -s: Force interpretation of values as strings

Arrays:

  -a: Put array

      Value format: number of requested values, then list of values


 

 

 

ELOG V3.1.3-