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

}

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

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

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

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.

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

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.

Borrowed thorlabs power meter on 21 Sep 2017.  It is on the south table of the ATF lab.

I have borrowed TCS's label maker in CTN for few days. If you need it, you can take it from the top of blue cabinets.

In anticipation of the point absorber SURF project, I cleaned up the server rack and installed a new workstation today.

The workstation replaces the old one, whose hard drive had failed, with a more powerful machine. The hostname (tcs-ws), IP address (10.0.1.168), user name (controls), and standard password (written in the secret place) are all the same as before.

I moved the control consol from its old spot in the back corner of the lab to the bench beside the rack. This is a more convenient location because the Hartmann sensor realtime GUIs can now be easily seen from the optical tables. I mounted the HWS machine in the rack as well and reconnected the video multiplexer to all the machines.

I tested the Hartmann sensor Python software and confirmed it to be working. It required a minor bug fix to the realtime gradient field GUI code. It seems that since this script was last run, the input data file type has switched from pickled numpy to HDF5.

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

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

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

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:

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

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:

 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

 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

 ATF:1812

These are also being written to frames on FB4.

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

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.

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.

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.

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?

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.

• 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

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. 

 The 200W Thermopile power head from Thorlabs arrive today. The scanned delivery note and calibration info are attached.

The first pieces of the Bosch framing have arrived from Valin Corporation. These are just small pieces such as the fasteners and the gussets. There are no custom lengths of framing yet.

The details are in the attached Packing List. [1:25PM] I haven't verified that everything is there yet.

 Another box of Bosch stuff arrived in my office. The packing list is attached

 The custom pieces of the Bosch framing have arrived. Transportation is currently moving them downstairs to the lab. The packing list is attached.

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

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

 See attached delivery note ...

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

 See attached delivery note ...

Ian and I moved some new hardware into the lab, shown in the below photos. It is from the shipment of loaned equipment recently returned by Whitman College. 

Attachment 1:

• ZnSe 1" dia. lenses (x2)
• ZnSe 38.1 mm dia. windows (x2)

Attachment 2:

• Synrad 20 W CO2 laser
• Synrad laser controller

Attachment 3:

• Intraaction Model GE modulator driver
• Intraaction AOM

Attachment 4:

• Second Intraaction Model GE modulator driver
• Unknown optical cavity (was packaged together with the driver)

The ZnSe lenses and windows were put in the CO2 drawer of the optics cabinet. The CO2 laser, AOM, and modulator drivers were left packaged in boxes underneath the large laser table.

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.

 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:

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

Done!

 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. 

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

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:

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

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

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

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]

 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.

 I labelled and strung 8 of the 16 custom 40' BNC cables from L-Com between the HWS table and the BNC feed-through on the rack. Each cable is labelled HWS TABLE CHxx where 01<= xx <= 08. I'm going to leave the other 8 until we have room in the BNC feedthrough on the rack.

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

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.

I installed the Maku Gigabit CCD camera driver software on the hws-ws machine. The camera viewer can be opened from the terminal (from any directory) with the command

$ZimbaViewer

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

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

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

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

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

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

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

$stream_intensity_CIT

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