40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  TCS elog, Page 2 of 5  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  115   Mon Feb 28 17:56:32 2011 AidanComputingHartmann sensorGot HWS code running and interface to EPICS

Here are the notes from today's efforts:

 

 

- When you 'Run_HWS' in MATLAB and the camera has not been initialized, it says the camera is not accessible. Either that or you need to run 'sudo matlab' (no, sudo doesn't help)

- In Ubuntu have to run '/opt/EDTpdv/initcam -f ~/dalsa_1m60.cfg' to start the camera

- Now have to install MCA

- MCA installed by is crashing MATLAB - not sure why. Maybe its a 'sudo' problem again?
- sudo matlab has the following problem:
mca
??? Invalid MEX-file
'/home/controls/base-3-14-11/extensions/lib/linux-x86_64/mca.mexa64':
libdbStaticHost.so.3.14: cannot open shared object file: No such file or
directory.
 
- adjusting Makefile for MCA to include the correct suffix for a Linux based MEX file ('mexa64', not 'mexglnx') gets the program to compile correctly and then MATLAB runs MCA fine.


- Running 'Run_HWS' with EPICS running but no channels crashes the program

- copy the HWS.db file to the EPICS db location

- cannot create the matlab images folder when the program runs.
- created these manually
- program is trying to adjust the maximum pixel count - it is failing and the camera is complaining (intensity is quite low right now)
- why exposure mode 6? - requires an external SYNC signal
- can't handle low exposure - FIX THIS!!
- why is the expsoure time increased in stepwise fashion? Use algorithm!
      - Commenting this out!!
    - same for the secondary beam
- After running State 1 it asks to continue to State 2 - if you select 'n' the program crashes

- steered beam properly onto HWS
-----------
- continue to State 2 - 'yes' crashes the program
- HS_report is doesn't work
- commented out lines 37 to 47

- get rid of constant requests to continue [run_acquire_auto.m]
- change names of EPICS variables [done]
- add an RMS variable
- the named EPICS variables need to be dynamically named rather than statically named.


--------
run_acquire_auto.m CHANGES
0. Update sensor date: mres = 'y'
1. pres = 'n'; - don't update reference centroids
2. sres = 'n'; - don't update secondary reference centroids
3. select probe beam commented out
4. select secondary beam commented out
5. State 2B - select probe live commented out
6. set user_response = 'y' for continue

A1 - added a loopcounter that starts at zero. the first loop includes user prompts and then they're bypassed in subsequent loops.

-----------

-Seidel aberration fitting seems wrong - not resembling the integrated field
- get rid of the constant pop ups
- have a network license EPICS variable
- how many images are used for reference image?
    - added a variable in run_acquire_auto.m :
        - no_of_cim_ref = 200; (no_of_cim = 5 images was previous)
    - changed the averaging in reference image acquisition from
        - "no_of_cim" to "no_of_cim_ref"
    - didn't change the take command from 5 to 200 images
- commented out lines 239-242 in run_initialize - gives a second way to start run_acquire.m
- probe and secondary beams share the probe background - deliberate?
- average all the images and save as a single matlab 16-bit array
- what is the rms noise as a function of the reference image number of averages?


------
Changing the EPICS variable names.
1. HS_WF - where Seidel coefficients are named.
    - in function seidel_from
2. changed the following lines in 'run_acquire_auto.m'
        %channelname = ['probe-seidel-',fn{counter}];
            channelname = ['C4:TCS-HWSX_PSC_', fn{counter}];

        %channelname = ['secondary-seidel-',fn{counter}];
            channelname = ['C4:TCS-HWSX_SSC_', fn{counter}];
3. ammended the following code in 'run_acquire_auto.m'

    maxEPICSLength = 14;
    for counter = 1:length(fn)
        %channelname = ['probe-seidel-',fn{counter}];
        strname = upper(fn{counter});
        if (numel(strname) > maxEPICSLength)
            strname = strname(1:maxEPICSLength);
        end     
        channelname = ['C4:TCS-HWSX_PSC_', strname];
        probe_seidel_array{counter} = HS_EPICS(channelname);
    end
-----
- bug: on restarting and pressing 'space' and enter at approximately the same times here, the program crashed:

Is it okay to assign one of the already existing handle (y or n)? y
Assigned handle 2 to the instance.
Established the connection to the channel secondary_shutter_open.

hsep_secondary =

  HS_EPICS handle

  Properties:
         channelname: 'secondary_shutter_open'
             handler: 2
    EPICS_is_running: 1

  Methods, Events, Superclasses

Please select the probe beam as the light source. Hit any key to continue.

??? Error using ==> textscan
First input can not be empty.

Error in ==> HS_Camera>HS_Camera.get_exposure_time at 942
        ccet = textscan(ccet,'%f %s');

-----------------

Added the following lines to HWS.db

record(ai, "C4:TCS-HWSX_PSC_PRISM")
record(ai, "C4:TCS-HWSX_PSC_ALPHA")
record(ai, "C4:TCS-HWSX_PSC_PHI")
record(ai, "C4:TCS-HWSX_PSC_CYLINDRICAL_PO")
record(ai, "C4:TCS-HWSX_PSC_SPHERICAL_POWE")
record(ai, "C4:TCS-HWSX_PSC_COMA")
record(ai, "C4:TCS-HWSX_PSC_BETA")
record(ai, "C4:TCS-HWSX_PSC_SPHERICAL_ABER")
record(ai, "C4:TCS-HWSX_SSC_PRISM")
record(ai, "C4:TCS-HWSX_SSC_ALPHA")
record(ai, "C4:TCS-HWSX_SSC_PHI")
record(ai, "C4:TCS-HWSX_SSC_CYLINDRICAL_PO")
record(ai, "C4:TCS-HWSX_SSC_SPHERICAL_POWE")
record(ai, "C4:TCS-HWSX_SSC_COMA")
record(ai, "C4:TCS-HWSX_SSC_BETA")
record(ai, "C4:TCS-HWSX_SSC_SPHERICAL_ABER")

- restarting IOC with C4:TCS-HWSX channels

-------------

-time to add these to the frames



 

  120   Thu Mar 3 07:30:18 2011 WonComputingHartmann sensorEffect of high pixel count on rms

We have been investigating how pixel count is related to the centroid displacements by taking several sets of image frames with different camera
exposure time and input current.

It appears that the reason why rms value did not drop as fast as it should (as the number of averaged image frames increases) is that the pixel counts were too high.

As was previously done, we took 5000 images for rms analysis, and the reference set of centroids were generated from averaging 4000 sets of centroids using first 2000 and last 2000 images. Once a set of centroids for each image frame is obtained and saved (it took about 30 minutes to obtain centroids of 5000 image frames), rms analysis could be done in seconds.

(Alternatively, one could average the images first then find centroids, but this is much slower and the rms values do not change much.)

First figure is the log plot of rms versus N_av (number of image frames that are averaged over), where the maximum pixel count was about 2000.

Blue line is the calculated rms values, red line is the linear fit of the rms values, and black line is the line of the ideal slope -0.5. The rms values are in pixel units. The slope of the linear fit is -0.487. 

Centroids are obtained from the images taken with the exposure time of 23ms, the value of the current driving light source 28 mA, and the distance between the CCD and the light source was about 50 cm. 

rms-low.png
 

Second figure is the plot using images whose max pixel counts were about 2700 (30ms exposure, same current): this gave the fitted slope to be -0.07.

rms-all.png


Next two figures are the plots of rms with the same image set (images with max pixel count of 2700), using 

1. centroids whose peak pixel counts are below 2048 (45 out of 904 centroids), and

2. centroids whose peak pixel counts are above 2047 (859 out of 904 centroids). 
rms-under.pngrms-over.png
Peak pixel counts were obtained from the first image frame. As pixel counts fluctuate between image frames, it would perhaps be better to use averaged images but the outcome will still be qualitatively the same.

These plots clearly show that centroids with high peak pixel counts are responsible for poor reproducibility of the centroids.

The reason why the value of 2048 was chosen to separate centroids is because the camera will have to use the 12th bit for pixel counts 2048 or above.

I need to do more analysis to determine conclusively if the 12th bit is indeed responsible. What is clear at this point is that, once peak pixel counts go over about 2000, the reproducibility of centroids worsens significantly.

:PS:

 
Further investigation revealed that, for the second centroids set (i.e., the centroids obtained from 30ms images) I discussed here, the decrease in centroids reproducibility is due to one spot whose position fluctuated much more wildly than others. That same spot does not cause problems in my first set with lower pixel counts. Here is the 2D plot of rms values of individual centroids fluctuations over image frames. I used griddata command to interpolate values between centroids to get this false color map;

rms_v_c_with.png

The spot shown on the plot corresponds to the centroid located at the pixel (x,y) = (749,353). Its rms value with N_av = 1000 was 0.055 pixel uniits, which is more than ten times as big as average centroid displacements between two images (which is about 0.003).

Once you remove this centroid from the reference set and redo the analysis, the fitted slope goes back to -0.46.

 rms-without.png
Since I was wondering if high pixel counts worsens the reproducibility of the centroids, I also generated scatter plot of (1) rms vs peak pixel counts and (2) fitted slope for each centroid vs peak pixel counts (without removing the problematic centroid):

rms_v_pc-with.png slope_v_pc-with.png

It is evident that one centroid is a huge outlier in rms vs pixel counts plot, but it is not so obvious in the plot of slopes vs pixel counts. Furthermore, there does not appear to be any correlation between pixel counts and the values of the fitted slopes. 

And here are the scatter plots after removing the problematic centroid:

rms_v_pc-without.pngslope_v_pc-without.png

which suggests that there is no real correlation between peak pixel counts of centroids and their values of rms or fitted slope. What is still happening, although, is that as we increase pixel counts by either increasing the camera exposure time or the intensity of the light source, the value of the fitted slope increases as well (hence decreases the reproducibility of centroids).

I will continue this discussion in my next post...

Attachment 2: rms-low.png
rms-low.png
  121   Tue Mar 8 11:30:26 2011 AidanComputingHartmann sensorHartmann sensor code changes and NTP server

I've made the following changes to the Hartmann sensor code and to the machine running the HWS.

  • Machine name is now princess_sparkle (10.0.1.26)
  • I set up ntpd on that machine to sync the clock to GPS - roughly.
  • I added a MATLAB function (store_current_centroids.m) to the Hartmann sensor that saves the centroids and peak intensities to file in GPS labeled files
  • ~/Hartmann_Sensor_Data/centroids/<GPSTIME1>/<GPSTIME2>/<GPSTIME>_<name>.mat

GPSTIME1 = floor(GPSTIME/4E4)*4E4

GPSTIME2 = floor(GPSTIME/2E2)*2E2

I had to add a line in the run_acquire_auto.m script to accommodate this new function and I had to add a function that calculates the peak intensities to the HS_Centroids.m class.

  122   Tue Mar 8 18:28:14 2011 AidanComputingGeneralTO DO notes
  1. Write a Wiki page that describes how to add channels to the Athena Box
  2. Write a Wiki page that describes how to add a new computer to the network and mount all the network drives
  3. Add an EPICS channel that writes the disk usage to file (to keep track of the total accumulated disk space used by the centroid storage)
  123   Tue Mar 8 18:48:00 2011 AidanComputingHartmann sensorHWS code is running and recording centroids

The Hartmann sensor is running continuously and is now recording data to file. The formatting has changed slightly with the data now stored in structures called store_measurement every 200s in files in the following way:

  • store_measurement(ii).centroids - the ii-th centroids
  • store_measurement(ii).intensities - the ii-th intensity list
  • store_measurement(ii).time - the time of the ii-th measurement

The files are stored in ~/Hartmann_Sensor_Data/centroids/<GPSTIME rounded to nearest 4E4 seconds>/<GPSTIME rounded to nearest 2E2 seconds>_<subname>.mat

 

  125   Wed Mar 9 01:00:12 2011 Peter Veitch, Won KimComputingHartmann sensorControl of frame rate usign external trigger

We managed to successfully apply frame rate control via external trigger from a pulse generator.

We supplied 5V pulse train when connected to the optocoupler load, and connected to pins 1 and 2 of external trigger (on the frame grabber board) for using camera 0 (which is the case for us).

Then made the following changes to the config file dalsa_1m60.cfg;

MODE_CNTL_NORM: A0 (previously this value would have been 00)

user_timeout: 0    (this line should be added)

Then I saved the new config file as dalsa_1m60_et.cfg

Next, I loaded the new config using initcam command, then set the exposure mode to be 3. This can be done either using serial_cmd directly or using HS_Camera method set_exposure_mode.

In exposure mode 3, the exposure time is set by the time separation between the falling edges of the pulses, and the camera sets the expousure time to be the maximum value possible (as specified in the camera manual). 

Then I took 10 images using take command, and verified that the frame rate is equal to the frequency of the pulse. We tested 1 Hz and 2 Hz pulse trains, and the frame grabber recoded 1 frames per sec and 2 frames per sec respectively.

We could not yet test the frequency values < 1 Hz as pulse generator we used could not go under 1 Hz.

(EDIT)

We used another pulse generator to test pulse frequencies under 1 Hz, and verified that external trigger mode still works.
 

  131   Fri Apr 1 02:41:55 2011 WonComputingHartmann sensorexposure time and reproducibility of centroids

 Here is a brief and preliminary summary of rms of centroid displacements calculated at a number of different exposure time values. To get the results I did the following for each value of exposure time:

1. Take a set of images. I took 2000 images for shorter exposure times, 1000 images with exposure times greater than 1 second, and 200 images with exposure time 4.4 second. I tried to keep the maximum pixel count to be roughly the same (about 2430 plus/minus 40).

2. Obtain the centroids for each image frames in a set. I saved centroids as an array of n by m by 2, where n is the number of image frames that I took, m is the number of centroids in each frame, and 2 for x and y coordinates.

Then I iterated through the centroid sets to calculate total rms, using various N_av values. If N_av = 100; then reference centroids were obtained by averaging the centroids of first 50 and the last 50 frames, and remaining 100 frames are averaged to get the other (or non-reference) centroids. I think this method gives a better view of the centroid reproducibility than fixing the number of reference centroids to be, say, first 1000 and last 1000 frames and varying the number of frames to be averaged for non-reference centroid.

Datasets of centroids are labelled as spcdet_I_t, where spcdet stands for "same (maximum) pixel count (with) differen exposure times", I the value of the current that drives the light source, and t the exposure time that I used.

Here are the plots:

spcdet_28mA_28ms.pngspcdet_23mA_210ms.png

spcdet_21mA_455ms.pngspcdet_20mA_650ms.png

spcdet_19mA_900ms.pngspcdet_18mA_1290ms.png

spcdet_17mA_1800ms.pngspcdet_16mA_2430ms.png

spcdet_14mA_4400ms.png

It can be seen from these plots that the benefit of averaging multiple frames quickly diminish once we go over 1 second. I am investigating if there is any way to improve the reproducibility while using the same sets of images.

Issues that need further investigation:

  1. Effect of pixels with unusually high pixel count. Dark images that we took show that, with longer exposure times, not only overall dark noise increase (and become less uniform) but also several pixels show unusually high pixel count (even higher than 2000), without a light source on. More investigation is needed to determine how much this affects the centroids calculation and to devise an way to deal with it.

  2. Extra/Duplicate centroids. As exposure time increased, I observed that duplicate centroids start to appear, i.e., HS_Centroids##centroids had duplicate entries. The number of duplicate entries increased as exposure time increased. I believe this is due to the images getting noisier as exposure time increases. So After taking initial reference centroids, I removed duplicate centroid entries before calculating rms. I am thinking about adding a method to do this in HS_Centroids class.

In addition, there were one 'false' centroid when the exposure time was 4.4 seconds. For now I chose to manually remove it myself before calculating rms.

  132   Fri Apr 1 09:51:45 2011 AidanComputingHartmann sensorPrism measurement

 I analyzed the results from the prism experiment. The time series and spectra of the prism are attached.

Conclusions to follow ...

Attachment 1: Hartmann_Sensor_prism_measurement_2011-03-31.pdf
Hartmann_Sensor_prism_measurement_2011-03-31.pdf
Attachment 2: Hartmann_Sensor_Prism_measurement_times_series_2011-03-31.pdf
Hartmann_Sensor_Prism_measurement_times_series_2011-03-31.pdf
  134   Tue Apr 12 22:30:59 2011 AidanComputingEPICSInstalled the thermistor on the Hartmann plate/created MEDM ADC Input screen

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")
}

Attachment 1: Screenshot-TCS_athena01_input_screen.adl.png
Screenshot-TCS_athena01_input_screen.adl.png
  135   Tue Apr 12 22:46:27 2011 AidanComputingEPICSAdded temperature sensor channels to the frame builder and restarted fb1

Added the following to the frame builder in /cvs/cds/caltech/chans/daq/C4HWS.ini and restarted daqd as per instructions in http://nodus.ligo.caltech.edu:8080/TCS_Lab/29

 

[C4:TCS-HWS_THERM_VOLTS]
[C4:TCS-HWS_THERM_OHMS]
[C4:TCS-HWS_THERM_DEGREES_LIN]
[C4:TCS-HWS_THERM_DEGREES_LOG]

  138   Mon Apr 18 15:03:49 2011 AidanComputingDAQAthena DAC channels hooked up to BNC patch panel

 I added the four Athena DAC channels to the second BNC patch panel in the rack. At the moment there are only two EPICS channels in the database:

  • C4:TCS-ATHENA_DAC0
  • C4:TCS-ATHENA_DAC1

 

  140   Fri Apr 22 19:51:37 2011 AidanComputingEPICSpyepics installed on princess_sparkle

 I installed the pyepics package on princess_sparkle since this is much easier under Ubuntu than under CentOS.

  1. sudo apt-get install python-dateutil python-setuptools
  2. make sure that LD_LIBRARY_PATH points to EPICS libraries by echo $LD_LIBRARY_PATH
  3. sudo ldconfig
  4. sudo easy_install -U pyepics

Then I started the following python script ~/start_test_channels.py in the background on princess_sparkle. The EPICS channels are actually in an IOC on tcs_daq. They are all acquired by the frame builder at 16Hz.

 

 

 

 

Attachment 1: start_test_channels.py
#!/usr/bin/python
# a short script to output low frequency sine wave to EPICS channels

import epics
import math
import time
import os
import random

a = 0
... 70 more lines ...
  141   Sun Apr 24 18:31:18 2011 AidanComputingNetwork architectureAdded hosts and network drives on TCS machines

Under edit ...

I added the names of the network machines to the /etc/hosts file on princess_sparkle, tcs_daq and tcs_ws.

I also added the /cvs drive on fb1 to the /etc/fstab file on princess_sparkle so that can be accessed from those machines.

  142   Mon Apr 25 16:28:27 2011 Aidan, JoeComputingNetwork architectureFixed problem network drive fb1:/cvs on Ubuntu & CentOS machines

With Joe's help we fixed the failure of princess_sparkle to mount the fb1:/cvs directory when relying on /etc/fstab.

First we changed the mounting options in fstab to the following:

fb1:/cvs        /cvs            nfs     rw,bg,soft        1 1

When we got the following error trying it directly from the command line,

controls@princess_sparkle:~$ sudo mount /cvs
[sudo] password for controls:
mount: wrong fs type, bad option, bad superblock on fb1:/cvs,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

some quick Google searches suggested installing nfs-common, so we tried sudo apt-get install nfs-common and that seemed to do the trick.

CentOS

For the CentOS machines, the following was done:

sudo mkdir /cvs

and then the same mounting configuration was added to /etc/fstab
 

Additionally, all three machines now have a /users symbolic link to /cvs/users

  144   Tue May 10 00:55:08 2011 WonComputingHartmann sensorMatlab Compiler and Matlab Compiler Runtime

 

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.
 

  145   Wed May 11 09:07:03 2011 AidanComputingHartmann sensorChanged ownership of /opt/EDTpdv

 I changed the ownership of /opt/EDTpdv to controls with the command:

controls@princess_sparkle:/opt/EDTpdv$ sudo chown controls EDTpdv/

 

  146   Wed May 11 18:38:47 2011 AidanComputingHartmann sensortest_HS binary

 From Won: (the zip file is also on the SVN /users/won/compiled_code/test_HS.zip)

 

Attached is test_HS.zip file, that contains

- test_HS.prj: project file created by Matlab Compiler. This file is not
 required to run the application but I included it just in case someone's
 insterested.

- test_HS folder contains two subfolders src and distrib, each of which
 contains the standalone application test_HS.

Usage: test_HS <path to the image folder>, for example

 test_HS ~/test_images/

Make sure you create the folder prior to running the application, and the
folder name ends with "/". Running test_HS will take and save 10 images
using the camera (provided the frame grabber applications are installed in
/opt/EDTpdv), averages those 10 images and find centroids, then plots the
result.

As I put in the eLOG, one needs MCRInstaller.bin and run it to install MCR
(probably 2008b 64bit version to test my files). If there are difficulties
getting MCRInstaller, let me know.

Won
<test_HS.zip>

 

Attachment 1: test_HS.zip
  147   Wed May 11 18:44:54 2011 AidanComputingHartmann sensorMatlab Compiler and Matlab Compiler Runtime

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:

 

export LD_LIBRARY_PATH=/home/controls/base-3-14-11/lib/linux-x86_64:/MATLAB_R2009b/runtime/glnxa64:/MATLAB_R2009b/bin/glnxa64
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
 
 
Running test_HS binary from Adelaide on Ubuntu distribution

 

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:

751                 mes_meesage = ['Intensity too high: ',fobj.name];
752                 cam.inform_messenger('ImageNotValid',mes_message);

Here's the output:


 

controls@princess_sparkle:~/Hartmann_Sensor_SVN/users/won/compiled_code/test_HS/test_HS/distrib$ ./test_HS ~/test_images/
The camera is accessible.


G E N E R A L   C A M E R A   S E T T I N G S:

Camera Model No.:               DS-22-01M60-11E
Camera Serial No.:              04437062
Sensor Serial No.:              0411218

Tap 1 Gain:                     0
Tap 2 Gain:                     0

Firmware Design Rev.:           03-81-00070-03  Sep 30 2004
DSP Design Rev.:                17.3

Pretrigger:                     0      
Video Mode:                     Normal Operating Mode
Data Mode:                      12 bit 
Binning Mode:                   1x1

Gain Mode:                      1x Output Gain Mode
Output Configuration:           2 Tap
Exposure Control:               enabled
Exposure Mode:                  2      

SYNC Frequency:                 8 Hz
Exposure Time:                  123646.66 uSec

OK>

executing /opt/EDTpdv/take -s 1 -l 10 -f /home/controls/test_images/test ...
??? Undefined function or variable "mes_message".

Error in ==> HS_Camera>HS_Camera.read_raw at 752



Error in ==> HS_Camera>HS_Camera.read_from_folder at 668



Error in ==> HS_Camera>HS_Camera.read_from_fg at 721



Error in ==> HS_Camera>HS_Camera.read_images at 590



Error in ==> test_HS at 9


 
MATLAB:UndefinedFunction
 

 

Quote:

 
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.
 

 

  148   Tue May 17 16:08:02 2011 AidanComputingHartmann sensorWrite speed of the frame grabber to file

 The attached file shows the output of the command. The maximum average frame rate is 57.2Hz when the nominal frame rate was 58Hz:

/opt/EDTpdv/take -f max_frame_rate_image -l 120 -N 4 -d > max_frame_rate_data.txt

 

 

 

 

 

 

 

Attachment 1: max_frame_rate_data.txt
reading image from Dalsa 1M60 12 bit dual channel camera link
width 1024 height 1024 depth 12  total bytes 2097152 
writing 1024x1024x12 raw file to max_frame_rate_image0000.raw (actual size 2097152)
writing 1024x1024x12 raw file to max_frame_rate_image0001.raw (actual size 2097152)
writing 1024x1024x12 raw file to max_frame_rate_image0002.raw (actual size 2097152)
writing 1024x1024x12 raw file to max_frame_rate_image0003.raw (actual size 2097152)
writing 1024x1024x12 raw file to max_frame_rate_image0004.raw (actual size 2097152)
writing 1024x1024x12 raw file to max_frame_rate_image0005.raw (actual size 2097152)
writing 1024x1024x12 raw file to max_frame_rate_image0006.raw (actual size 2097152)
writing 1024x1024x12 raw file to max_frame_rate_image0007.raw (actual size 2097152)
... 117 more lines ...
  149   Wed May 18 18:52:12 2011 AidanComputingHartmann sensorTest of position modulation algorithm

 I measured the prism and displacement of the Gaussian beam on the Hartmann sensor. The beam pointing was modulated at 10mHz using a galvo mirror as illustrated in Attachment 1. The galvo was around 680mm from the Hartmann sensor. The amplitude of the prism modulation was approximately 1E-5 radians. The displacement of the beam was measured using a new algorithm that tries to fit a parabola to the logarithm of the intensity of each Hartmann spot. The amplitude of the displacement modulation was measured at around 42 microns: corresponding to around 6E-5 radians (=42um/680mm).

To resolve the discrepancy between the prism and displacement measurements, I removed the Hartmann plate to simply get a Gaussian beam on the CCD (bottom right image in Figures 2 & 3 - the beam is slightly clipped and there is a ghost beam in the center - I'm not yet certain where this is coming from). I measured the Gaussian beam displacement directly by fitting a Gaussian to the mean horizontal cross-section of the intensity distribution (top right plot in Figures 2 & 3). Using this technique the measured displacement on the CCD had an amplitude of around 0.7 +/- 0.05 pixels = 8.4 +/- 0.6 microns, corresponding to a prism of 12.5E-6 radians (seen in top left plot in Figures 2 and 3). This indicates that there is an error in the Gaussian fitting algorithm using the Hartmann sensor data.

 The second plot simply shows the position modulation of the beam as I increased the amplitude of the signal going to the galvo. 

 

Voltage (Vpp) Displacement on CCD (pixels)
0.01 0.325
0.012 0.400
0.014 0.487
0.015 0.541
0.016 0.576
0.019 0.708
0.02 0.763
0.023 0.887
0.028 1.194
0.034 1.803
0.041 3.053
0.049 7.107

 

Attachment 1: galvo_mirror_experiment.jpg
galvo_mirror_experiment.jpg
Attachment 2: 2011-05-18_gaussian_beam_with_galvo_constant.pdf
2011-05-18_gaussian_beam_with_galvo_constant.pdf
Attachment 3: 2011-05-18_gaussian_beam_with_galvo.pdf
2011-05-18_gaussian_beam_with_galvo.pdf
  154   Fri Sep 2 14:41:48 2011 AidanComputingHartmann sensorQFLD-950-3S long term test finished

I ran a test of the HWS with the QFLD-950-3S for 5 days. The test was terminated as we need to disconnect all the cabling and tidy up all the computers in the lab.

  181   Mon May 13 14:09:02 2013 ZachComputingDAQC2ATF model rebuilt

 ATF:1812

  182   Thu Dec 15 14:02:01 2016 AidanComputingNetwork architectureCorrect network settings for Ubuntu 14 in /etc/network/interfaces

These settings work to get a computer onto the TCS/ATF network.

Attachment 1: IMG_8148.JPG
IMG_8148.JPG
  183   Fri Dec 16 10:41:33 2016 AidanComputingNetwork architectureCorrect network settings for Ubuntu 14 in /etc/network/interfaces

Spelt out in a searchable fashion:

auto <portname>

iface <portname> inet static

   address 10.0.1.x

   netmask 255.255.255.0

   network 10.0.1.0

   broadcast 10.0.1.255

   gateway 10.0.1.1

   dns-nameservers 10.0.1.1 131.215.139.100 8.8.8.8

 

 

Quote:

These settings work to get a computer onto the TCS/ATF network.

 

  189   Wed Oct 11 19:14:16 2017 Jon RichardsonComputingElectronicsReplaced TCS Monitor

I replaced the dead 24" monitor on the work bench, which is connected to the video multiplexer. Mike Pedraza was kind enough to bring us us a new one and take away the old one.

  192   Fri Oct 13 18:35:29 2017 Jon RichardsonComputingElectronicsInstalled Maku Ethernet CCD Camera

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.

Attachment 1: IMG_2287.JPG
IMG_2287.JPG
  194   Tue Oct 24 10:19:53 2017 Jon RichardsonComputingElectronicsInstalled Maku Ethernet CCD Camera

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.

Quote:

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.

 

  195   Tue Oct 24 15:05:57 2017 Jon RichardsonComputingElectronicsInstalled a Realtime Beam Profiler for the Mako CCD Camera

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.

  196   Wed Oct 25 15:34:14 2017 Jon RichardsonComputingFrame GrabberMako CCD Camera Code is Fixed

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.

  197   Thu Oct 26 10:21:28 2017 AidanComputing Beam size EPICS channels added to TCS-WS softIoc

I've added a softIoc to TCS-WS to capture the beam size from the MAKO camera. The IOC is run using ...

controls@tcs-ws:~$ softIoc -S EPICS_IOC/iocBoot/iocfirst/st.cmd &

The st.cmd contains the following text:

controls@tcs-ws:~$ more EPICS_IOC/iocBoot/iocfirst/st.cmd

dbLoadDatabase "/home/controls/EPICS_IOC/db/beamSize.db"

iocInit

 

The db file is:

 

controls@tcs-ws:~$ more EPICS_IOC/db/beamSize.db

 

record(ai, "C4:AWC-MAKO_BEAMSIZE_WX")

{

    field(PREC,"3")

}

 

record(ai, "C4:AWC-MAKO_BEAMSIZE_WY")

{

    field(PREC,"3")

}

 

record(ai, "C4:AWC-MAKO_BEAM_POSN_X")

{

    field(PREC,"3")

}

 

 

record(ai, "C4:AWC-MAKO_BEAM_POSN_Y")

{

    field(PREC,"3")

}

 

  198   Thu Oct 26 10:31:31 2017 AidanComputingDAQBeam size EPICS channels added to TCS-WS softIoc

These are also being written to frames on FB4.

Quote:

I've added a softIoc to TCS-WS to capture the beam size from the MAKO camera. The IOC is run using ...

controls@tcs-ws:~$ softIoc -S EPICS_IOC/iocBoot/iocfirst/st.cmd &

The st.cmd contains the following text:

controls@tcs-ws:~$ more EPICS_IOC/iocBoot/iocfirst/st.cmd

dbLoadDatabase "/home/controls/EPICS_IOC/db/beamSize.db"

iocInit

 

The db file is:

 

controls@tcs-ws:~$ more EPICS_IOC/db/beamSize.db

 

record(ai, "C4:AWC-MAKO_BEAMSIZE_WX")

{

    field(PREC,"3")

}

 

record(ai, "C4:AWC-MAKO_BEAMSIZE_WY")

{

    field(PREC,"3")

}

 

record(ai, "C4:AWC-MAKO_BEAM_POSN_X")

{

    field(PREC,"3")

}

 

 

record(ai, "C4:AWC-MAKO_BEAM_POSN_Y")

{

    field(PREC,"3")

}

 

 

  199   Thu Oct 26 10:45:44 2017 AidanComputingDAQBeam size EPICS channels added to TCS-WS softIoc

See attached photo for how data is written to frames ...

Quote:

These are also being written to frames on FB4.

Quote:

I've added a softIoc to TCS-WS to capture the beam size from the MAKO camera. The IOC is run using ...

controls@tcs-ws:~$ softIoc -S EPICS_IOC/iocBoot/iocfirst/st.cmd &

The st.cmd contains the following text:

controls@tcs-ws:~$ more EPICS_IOC/iocBoot/iocfirst/st.cmd

dbLoadDatabase "/home/controls/EPICS_IOC/db/beamSize.db"

iocInit

 

The db file is:

 

controls@tcs-ws:~$ more EPICS_IOC/db/beamSize.db

 

record(ai, "C4:AWC-MAKO_BEAMSIZE_WX")

{

    field(PREC,"3")

}

 

record(ai, "C4:AWC-MAKO_BEAMSIZE_WY")

{

    field(PREC,"3")

}

 

record(ai, "C4:AWC-MAKO_BEAM_POSN_X")

{

    field(PREC,"3")

}

 

 

record(ai, "C4:AWC-MAKO_BEAM_POSN_Y")

{

    field(PREC,"3")

}

 

 

 

Attachment 1: FullSizeRender_10.jpg
FullSizeRender_10.jpg
  201   Tue Oct 31 14:37:49 2017 AidanComputingDAQNew Acromag units for AWC experiments - XT1221 ans XT1541

I set up an Acromag DAC today with the fixed IP address 10.0.1.56. Last Friday Andrew and Antonio set up an ADC unit with fixed IP address 10.0.1.55. The former is for outputting a control voltager that goes to the driver for the heater on composite mirror we are testing. The latter is used to read the temperature of the thermocouple on the composite mirror. The thermocouple to voltage conversion is achieved with a Type K Thermocouple Amplifier unit from The Sensor Connection.

The temperature sensor channel is C4:AWC-TEMPMON_C. We took a couple of different measurements of temperature and calibrated the conversion from volts to Celsius as: C = 122.06*V -0.67

The new temperature sensor channel is now being recorded in the frames.

  202   Thu Nov 9 14:18:56 2017 AidanComputingDAQFB4 ip address has changed

We've had trouble logging into FB4. I access the computer directly in the AWC lab and found that the IP address had changed from 10.0.1.156 to 10.0.1.161.

I'm not sure how this happened. It's possible that the IP address is not set to a static value and FB4 was rebooted. I'm not familar with Debian so I don't know where to look to find whether the IP address is static or not.

The DAQD is still running.

  203   Tue Nov 14 19:08:00 2017 Jon RichardsonComputingNetwork architectureRsync Server for Automatic LDAS Backups

I implemented an access point for LDAS to pull data from the TCS lab EPICS frame archive (fb4:/frames) via rsync. The setup is analogous to what is already running at the 40m for automated backups. Here are the implementation details in case we want to replicate this in other W. Bridge labs.

Two lab machines are needed, the frame builder machine (fb4; 10.0.1.156) and a second machine to handle the network interfacing with the outside world (tcs-ws; 10.0.1.168).

1. Set up an NFS mount on tcs-ws to remotely access the frame archive on fb4.

i. NFS server-side setup:

a. Install the required packages

controls@fb4:~$ sudo apt-get install rpcbind nfs-common nfs-kernel-server

b. Add the following line to the file /etc/exports

/frames 10.0.1.168(rw,sync,no_root_squash)

c. Restart the NFS-related services

controls@fb4:~$ sudo /etc/init.d/rpcbind restart

controls@fb4:~$ sudo /etc/init.d/nfs-common restart

controls@fb4:~$ sudo /etc/init.d/nfs-kernel-server restart

ii. NFS client-side setup:

a. Install the required packages

controls@tcs-ws:~$ sudo apt-get install rpcbind nfs-common

b. Add the following line to the file /etc/fstab

10.0.1.156:/frames /fb4/frames nfs rw,nofail,sync,hard,intr 0 0

c. Create the directory for the mount point, then set ownership and permissions

controls@tcs-ws:~$ sudo mkdir /fb4/frames

controls@tcs-ws:~$ sudo chmod -R 775 /fb4

controls@tcs-ws:~$ sudo chown -R controls.root /fb4

c. Mount the new network drive

controls@tcs-ws:~$ sudo mount -a

2. Configure the rsync daemon on tcs-ws.

i. Create a new file named /etc/rsyncd.conf with the following content. These settings match those of the 40m setup.

max connections = 10

read only = yes

log file = /var/tmp/rsyncd.log

list = yes

uid = controls

gid = controls

use chroot = yes

strict modes = yes

pid file = /var/run/rsyncd.pid

 

[ldasaccess]

        comment = For LDAS access to TCS lab frame files

        read only = yes

        path = /fb4/frames

        hosts allow = ldas-grid.ligo.caltech.edu,localhost

ii. Kill, then restart the rsync daemon. The daemon may not be already running.

controls@tcs-ws:~$ sudo kill `cat /var/run/rsyncd.pid`

controls@tcs-ws:~$ sudo rsync --daemon

3. Open a port through the gateway firewall for LDAS to access.

To do this, configure a new port forwarding on the linksys gateway router in the usual way (access the router settings via http://10.0.1.1 from the web browser of any subnet machine). For the TCS lab, the external-facing gateway port 2046 is forwarded to port 873 of tcs-ws (the standard rsync port).

Security is handled by the tcs-ws rsync daemon. Its config file allows outside access to only the hostname ldas-grid.ligo.caltech.edu, and that access is read-only and restricted to the /fb4/frames directory.

4. Testing.

For testing purposes, another outside machine name can be temporarily appended to the "hosts allow" parameter of /etc/rsyncd.conf. For example, I appended my office desktop machine. From the outside machine, the connectability of the rsync server can be tested with:

user@outside-hostname:~$rsync -dt rsync://131.215.115.216:2046/ldasaccess

If successful, the command will return an output similar to

drwxr-xr-x        4096 2017/08/28 16:13:31 .
drwxr-xr-x        4096 2017/11/14 02:30:38 full
drwxr-xr-x        4096 2017/08/28 16:13:38 trend

showing the contents of the frame archive.

  206   Mon Feb 5 15:08:06 2018 AidanComputingDAQFrame builder clock is totally wrong

The framebuilder on FB4 thinks the current time is 26-Jan-2018 6:18AM UTC. The date command on FB4 yields the correct date and time (5-Feb-2018 15:17 PST).

There is a major error with the framebuilder clock.

  212   Wed May 30 18:50:05 2018 awadeComputingDAQRebooted fb4

Time was still off by nine days as of yesterday.  I tried rebooting remotely to see if time would correct to system clock.  It didn't and fb4 hung.

Just manually restarted the box.  Now dataviewer is showing a 'Time Now'  of 5 Jan 1980.   

Not sure how to set the frame builder clock time. Ultimately the best solution is to have ADC cards but can we find a hack for now? Is it possible to run a cron script it to reset time to the computer time?

 

 

 

Quote:

The framebuilder on FB4 thinks the current time is 26-Jan-2018 6:18AM UTC. The date command on FB4 yields the correct date and time (5-Feb-2018 15:17 PST).

There is a major error with the framebuilder clock.

 

  213   Wed May 30 18:59:49 2018 awadeComputingDAQFB4 ip address has changed

Maybe you've resolved this now. I moved the DHCP allocation to 10.0.1.160 and above around that time because a bunch of misc devices were starting to populate the dynamically allocated IP space around there.  I'd say FB4 was not setup with a manual IP at the time.

 

Quote:

We've had trouble logging into FB4. I access the computer directly in the AWC lab and found that the IP address had changed from 10.0.1.156 to 10.0.1.161.

I'm not sure how this happened. It's possible that the IP address is not set to a static value and FB4 was rebooted. I'm not familar with Debian so I don't know where to look to find whether the IP address is static or not.

The DAQD is still running.

 

  221   Thu Aug 16 11:52:27 2018 AidanComputingDAQAdded AWC thermocouple reader back to acromag1
  • Thermcouple reader is plugged into an Acromag ADC (10.0.1.55)
  • acromag1 is now reading this in:
    • ~/modbus/iocBoot/iocTest/test_acromag.cmd (contains ip address of ADC)
    • ~/modbus/db/TEMPMONCHANS.db (contains the EPICS channel definitions and calibration of thermocouple reader)
  • C4:AWC-TEMPMON_C (output channel)

Restored work done in http://nodus.ligo.caltech.edu:8080/TCS_Lab/201

 

 

 

  222   Wed Oct 17 16:17:45 2018 awade, AidanComputingDAQAdded AWC thermocouple reader back to acromag1

Acromag IOC process was removed from PSL lab acromag1 computer a few months ago.  Aidan needs them again but it would be better if it were run from TCS lab computers.

An instance of the modbus IOC is now running on tcs-ws within a docker container.  Docker is named tcslabioc.  Configuration files are located in ~/modbus.  Instructions on how to use the docker are located in ATF:2249.  To install docker see google.

To set up the specific instance in the TCS lab run

>sudo docker run -dt --name tcslabioc -v /home/controls/modbus/test_acromag.cmd:/home/modbus/IOCStart.cmd -v /home/controls/modbus:/home/modbus -p 5064:5064 -p 5065:5065 -p 5064:5064/udp -p 5065:5065/udp andrewwade/modbusepicsdocker 

Then whenever you want to stop, run:

> sudo docker stop tcslabioc

or to restart run

>sudo docker restart tcslabioc. 

So if you update the .cmd or .db files just run the restart command above and the channels should automatically update when it reboots. For other cleanup and control commands see docker documentation.  It can also be configured to keep alive on system reboot.

The cmd and db files are included below in the attachments for reference. 

 

Quote:
  • Thermcouple reader is plugged into an Acromag ADC (10.0.1.55)
  • acromag1 is now reading this in:
    • ~/modbus/iocBoot/iocTest/test_acromag.cmd (contains ip address of ADC)
    • ~/modbus/db/TEMPMONCHANS.db (contains the EPICS channel definitions and calibration of thermocouple reader)
  • C4:AWC-TEMPMON_C (output channel)

Restored work done in http://nodus.ligo.caltech.edu:8080/TCS_Lab/201

 

 

 

 

Attachment 1: TCSIOCFILS.tar.gz
  224   Tue Dec 4 16:57:08 2018 AidanComputingHartmann sensorUpdated GIT version of HWS code

I changed the HWS code to the new git.ligo HWS version.

  • Object files are in ~/hws
  • scripts are in ~/hws-server
  • utilities are still in old git repo moved to ~/.HWS_code_temporary_home

I've set up some symbolic links to these directories to mimic the old directory structure, so ..

  • ~/pyHWS links to new object file directory
  • ~/pyHWS/scripts lnks to new scripts directory
  • ~/pyHWS/utilities links to old utilities directory
  7   Thu Feb 4 14:05:59 2010 AidanElectronicsRing HeaterRing heater transfer function measurement 240mHz-5Hz

I've been trying to measure the ring heater transfer function (current to emitted power) by sweeping the supply voltage and measuring the emitted power with a photodector positioned right next to the ring heater.

Last night the voltage was sweeping with a 1000mV setting on the SR785 which was fed into the Voltage Control of the Kepco Bipolar Operational Power Supply/Amplifier which was biased around 10V.

The results are very, very strange. The magnitude of the transfer function decreases at lower frequency. I'll post the data just as soon as I can (ASCII dumps 13 and 14 on the disk from the SR785).

The circuit looks like this:

 

SR785 drive ----> Amplifier ----> Ring Heater : Photodetector ---> SR560 (5000x gain) ----> SR785 input

 

 

  8   Thu Feb 4 15:26:37 2010 AidanElectronicsRing HeaterRing heater transfer function measurement 240mHz-5Hz

Quote:

I've been trying to measure the ring heater transfer function (current to emitted power) by sweeping the supply voltage and measuring the emitted power with a photodector positioned right next to the ring heater.

Last night the voltage was sweeping with a 1000mV setting on the SR785 which was fed into the Voltage Control of the Kepco Bipolar Operational Power Supply/Amplifier which was biased around 10V.

The results are very, very strange. The magnitude of the transfer function decreases at lower frequency. I'll post the data just as soon as I can (ASCII dumps 13 and 14 on the disk from the SR785).

The circuit looks like this:

 

SR785 drive ----> Amplifier ----> Ring Heater : Photodetector ---> SR560 (5000x gain) ----> SR785 input

 

 

 This is wrong. It turns out the SR785 was wired up incorrectly.

  10   Fri Feb 5 12:42:19 2010 SteveElectronicsPre-amplifierChanges to board

Test entry

  11   Mon Feb 8 10:45:50 2010 Steve O'ConnorElectronicsPre-amplifierreplace Pot with fixed Resistor

 

            Preamp for Bulls eye detector                
                             
  It was felt that the Pot used at the input stage to remove offset added Noise            
  To test this the Pot was replaced with a fixed resistor and the offset removed at the second stage        
  Noise was measured after the first stage and at the monitor point first with the pot and then with the pot replaced with a Resistor  
                             
              First stage gain =1+500/10 test point 1 gain = 51      
              second stage gain=10K/1K test point 2 gain = 510    
  1K Pot (R19) is present                      
                             
  Chan #1                          
    dbVrms/Hz       nV/Hz       Referred Input Noise  nV/Hz      
                    gain = 51        
    200Hz 100Hz 50Hz   200Hz 100Hz 50Hz   200Hz 100Hz 50Hz    
  Test Point #1 -141.1 -140.0 -136.8   88.1 100.0 144.5   1.7 2.0 2.8    
                    gain = 510        
  Test Point #2 -119.4 -120.4 -118.4   1071.5 955.0 1202.3   2.1 1.9 2.4    
                             
                             
                             
  Pot replaced with Resistor (R4)                    
                             
  Chan #1                          
    dbVrms/Hz       nV/Hz       RIN        
                    gain = 50        
    200Hz 100Hz 50Hz   200Hz 100Hz 50Hz   200Hz 100Hz 50Hz    
  Test Point #1 -142.7 -142.7 -141.9   73.7 73.3 80.8   1.4 1.4 1.6    
                    gain = 500        
  Test Point #2 -122.0 -121.1 -120.7   794.3 881.0 922.6   1.6 1.7 1.8    
                             
                             
  When the Pot was replaced with R4, the offset was removed with the Pot at the second gain stage          
  R4 was not a thin film metal resistor                    
  12   Mon Feb 8 17:44:38 2010 AidanElectronicsPre-amplifierreplace Pot with fixed Resistor

Quote:

 

            Preamp for Bulls eye detector                
                             
  It was felt that the Pot used at the input stage to remove offset added Noise            
  To test this the Pot was replaced with a fixed resistor and the offset removed at the second stage        
  Noise was measured after the first stage and at the monitor point first with the pot and then with the pot replaced with a Resistor  
                             
              First stage gain =1+500/10 test point 1 gain = 51      
              second stage gain=10K/1K test point 2 gain = 510    
  1K Pot (R19) is present                      
                             
  Chan #1                          
    dbVrms/Hz       nV/Hz       Referred Input Noise  nV/Hz      
                    gain = 51        
    200Hz 100Hz 50Hz   200Hz 100Hz 50Hz   200Hz 100Hz 50Hz    
  Test Point #1 -141.1 -140.0 -136.8   88.1 100.0 144.5   1.7 2.0 2.8    
                    gain = 510        
  Test Point #2 -119.4 -120.4 -118.4   1071.5 955.0 1202.3   2.1 1.9 2.4    
                             
                             
                             
  Pot replaced with Resistor (R4)                    
                             
  Chan #1                          
    dbVrms/Hz       nV/Hz       RIN        
                    gain = 50        
    200Hz 100Hz 50Hz   200Hz 100Hz 50Hz   200Hz 100Hz 50Hz    
  Test Point #1 -142.7 -142.7 -141.9   73.7 73.3 80.8   1.4 1.4 1.6    
                    gain = 500        
  Test Point #2 -122.0 -121.1 -120.7   794.3 881.0 922.6   1.6 1.7 1.8    
                             
                             
  When the Pot was replaced with R4, the offset was removed with the Pot at the second gain stage          
  R4 was not a thin film metal resistor                    

 

Just a note: this board was for the QPD not the Bull's eye detector.

 

  14   Thu Feb 11 21:46:23 2010 AidanElectronicsRing HeaterRing heater time constant measurement - start time

After leaving the ring heater off for several hours I turned on a 40V, 0.2A supply at a gps time of 949 988 700

The channel recording the PD response is C2:ATF-TCS_PD_HGCDTE_OUT.

However, there is a delay between the time at which something is supposed to be recorded and the time at which it is recorded. I looked at the GPS clock and it read that time when I started the heater voltage. If you play the channel back in dataviewer you see the temperature start to increase around 80s BEFORE the heater current was switched on. This needs to be calibrated away!!!

  15   Fri Feb 12 11:39:28 2010 AidanElectronicsRing HeaterRing heater transfer function

I applied a step function to the silver WATLOW heater and measured the response with the photodiode. The power spectrum of the derivative of the PD response is attached. The voltage isn't calibrated, but that's okay because right now we're just interested in the shape of the transfer function. It looks like a single pole around 850uHz. The noise floor is too great above 4 or 5 mHz to say anything about the transfer function.

 

 

Attachment 1: watlow_heater_transfer_fn.jpg
watlow_heater_transfer_fn.jpg
  16   Fri Feb 12 21:00:06 2010 AidanElectronicsRing HeaterRing heater step function response - time series

Hideously slow internet at airport is making me write a brief entry. This is the times series of the hesilver watlow heater radiative response to a step function.

Laso United airlines are a bit cheap ....

Attachment 1: silver_watlow_heater_step_function_response_2010-02-12.pdf
silver_watlow_heater_step_function_response_2010-02-12.pdf
  18   Mon Apr 12 17:25:01 2010 AidanElectronicsHartmann sensorFiber-Camera Link demonstration

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

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

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

 

PC --> Frame-Grabber --> RCX C-Link --> 300' optical fiber --> RCX C-Link --> Dalsa 1M60works OK

The attached images:

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

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

 

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

 

 

 

 
 
 
 
 
 
 
 
 

 

Attachment 1: hartmann_sensor.JPG
hartmann_sensor.JPG
Attachment 2: Fiber_Camera_Link_1.jpg
Fiber_Camera_Link_1.jpg
Attachment 3: Fiber_Camera_Link_3.jpg
Fiber_Camera_Link_3.jpg
ELOG V3.1.3-