[Joe, Kiwamu]

We modified the activateDAQ.py script which lives in /opt/rtcds/caltech/c1/chans/daq/ and updates the C1SUS.ini, C1MCS.ini, C1RMS.ini, C1SCX.ini and C1SCY.ini files.  These files contain the DAQ channels for all the optics.

It has been modified so that channels like C1:SUS-ITMX_ULSEN_OUT_DAQ become C1:SUS-ITMX_SENSOR_UL.  Similarly the oplev signals go from C1:SUS-ITMX_OLPIT_OUT to C1:SUS-ITMX_OPLEV_PERROR.

After some debugging, we ran the script successfully and checked the output was correct.  We then restarted the frame builder (telnet fb 8088 and then shutdown) and also hit the DAQ reload button for all the front ends.

I tested in dataviewer that I could go back several years as well as going back just 1 hour in the history and see data for C1:SUS-ITMX_SENSOR_LL as well as C1:SUS-ITMX_OPLEV_YERROR.  I also tested realtime is also working for these channels.

The contents of the script are below.

inputfiles=["C1SUS.ini","C1RMS.ini","C1MCS.ini","C1SCX.ini","C1SCY.ini"]
prefix="[C1:SUS-"
optics=["BS_","ITMX_","ITMY_","PRM_","SRM_","MC1_","MC1_","MC2_","MC3_","ETMX_"]
#channels=["SUSPOS_IN1","SUSPIT_IN1","SUSYAW_IN1","SUSSIDE_IN1","ULSEN_OUT","URSEN_OUT","LRSEN_OUT","LLSEN_OUT","SDSEN_OUT","OL_SUM_IN1","OLPIT_IN1","OLYAW_IN1"]
channels_dict = {'SUSPOS_IN1':'SUSPOS_IN1_DAQ',
'SUSPIT_IN1':'SUSPIT_IN1_DAQ',
'SUSYAW_IN1':'SUSYAW_IN1_DAQ',
'SUSSIDE_IN1':'SUSSIDE_IN1_DAQ',
'ULSEN_OUT':'SENSOR_UL',
'URSEN_OUT':'SENSOR_UR',
'LRSEN_OUT':'SENSOR_LR',
'LLSEN_OUT':'SENSOR_LL',
'SDSEN_OUT':'SENSOR_SIDE',
'OLPIT_OUT':'OPLEV_PERROR',
'OLYAW_OUT':'OPLEV_YERROR',
'OL_SUM_OUT':'OPLEV_SUM'}

suffix="_DAQ]\n"

## set datarate
datarate=2048

## read the ini files
for inputfile in inputfiles:
    print inputfile
    outputfile=inputfile
    ifile = open(inputfile,'r')
    lines = ifile.readlines()
    ifile.close()

    for k in range(len(lines)):
        for op in optics:
            for ch in channels_dict:
                if (prefix+op+ch+suffix) in lines[k]:
                    lines[k]=prefix + op + channels_dict[ch] + "]\n"
                    lines[k+1]=lines[k+1].lstrip("#").rstrip(lines[k+1].split("=")[1])+"1\n"
                    lines[k+2]=lines[k+2].lstrip("#")
                    lines[k+3]=lines[k+3].lstrip("#").rstrip(lines[k+3].split("=")[1])+str(datarate)+"\n"
                    lines[k+4]=lines[k+4].lstrip("#")
    ofile = open(outputfile,'w')
    for k in range(len(lines)):
        ofile.write(lines[k])
        #print lines[k]
    ofile.close()


I like this activateDAQ script, but someone (Jenne with Joe's help) still needs to add the PEM channels - we still cannot see any seismic trends.

Although Joe and Kiwamu claim that they have inserted the correct DAQ names for the OPLEVs (e.g. PERROR and YERROR) back in Jan. 11, when I look today, I see that these channels are missing!

I want my PERROR/YERRORs back!

Since there will be some work that supposedly will involve moving stuff on the table and racks; here is the updated to-do list for FOL.

While working on the vac controls today, I also took care of some of the remaining to-do items. Below is a summary of what was done, and what still remains.

Completed today

• TP2/3 overcurrent interlock raised from 1 to 1.2 A. This was tripping during normal operation as the pump accelerates from low-speed (standby) to normal-speed mode.
• Interlock conditions on VABSSCO/VABSSCI removed. Per discussion with Steve, these are not vent valves, but rather isolation valves between the BS/IOO/OMC annuli. The interlocks were preventing the valves from opening, and hence the IOO and OMC annuli from being pumped.
• Channel exposed for interlocking in-vacuum high-voltage drivers. The channel name is C1:Vac-interlock_high_voltage. The vac interlock service sets this channel's value to 0 when the main volume pressure is in the range 3 mtorr-500 torr, and to 1 otherwise.
• Annuli pumping integrated into the set of recognized states. "Vacuum normal" now refers to TP1 and TP2 pumping on the main volume AND TP3 pumping on all the annuli. The system is currently running in this state.
• TP1 lowered to the nominal speed setting recommended by Steve: 33.6 krpm (560 Hz).

Still remaining

• Implement a "blinker" input-output signal loop between two Acromags to detect hardware failures like the one today.
• Add an AC power monitor to sense extended power losses and automatically put the system into safe shutdown.
• Migrate the RGA to c1vac. Still some issues getting the serial comm working.
• Troubleshoot the SuperBee (backup) main volume Parani gauge. It has not communicated with c1vac since a serial adapter was replaced two weeks ago. Chub thinks the gauge was possibly damaged by arcing during the replacement.
• Scripting for more automated pumpdowns.
• Generate a bootable backup hard drive for c1vac, which could be swapped in on a short time scale after a failure.

I've placed some notes pertaining to what Koji and I have learned today about getting the RCG code working on the 40m wiki at:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Notes_on_getting_the_CDS_Realtime_Code_Generator_working

We're still trying to fix the tst system, as the moment its reporting an invalid number of daq channels and during daq initialization it fails.  (This from the /cvs/cds/caltech/target/c1tst/log.txt file). Note: This problem is only on megatron and separated from the conventional DAQ system of the 40m.

cpu clock 2800014
Warning, could open `/rtl_mem_tst' read/write (errno=0)
configured to use 2 cards
Initializing PCI Modules
2 PCI cards found
***************************************************************************
1 ADC cards found
        ADC 0 is a GSC_16AI64SSA module
                Channels = 64
                Firmware Rev = 512

***************************************************************************
1 DAC cards found
        DAC 0 is a GSC_16AO16 module
                Channels = 16
                Filters = None
                Output Type = Differential
                Firmware Rev = 3

***************************************************************************
0 DIO cards found
***************************************************************************
0 IIRO-8 Isolated DIO cards found
***************************************************************************
0 IIRO-16 Isolated DIO cards found
***************************************************************************
0 Contec 32ch PCIe DO cards found
0 DO cards found
***************************************************************************
0 RFM cards found
***************************************************************************
Initializing space for daqLib buffers
Initializing Network
Found 1 frameBuilders on network
Waiting for EPICS BURT at 0.000000 and 0 ns 0x3c40c004
BURT Restore = 1
Waiting for Network connect to FB - 10
Reconn status = 0 1
Reconn Check = 0 1
Initialized servo control parameters.
DAQ Ex Min/Max = 1 32
DAQ Tp Min/Max = 10001 10094
DAQ XTp Min/Max = 10094 10144
DAQ buffer 0 is at 0x8819a020
DAQ buffer 1 is at 0x8839a020
daqLib DCU_ID = 10
DAQ DATA INFO is at 0x3e40f0a0
Invalid num daq chans = 0
DAQ init failed -- exiting

 Dmass tells me that you have to record at least one channel.  ie at least one channel in your .ini file must be set to acquire, otherwise the DAQ will flip out.  It seems to be unhappy when you're not asking it to do things.

I continued on the STAND ALONE debugging of the megatron codes.

- I succeeded to run c1aaa with ADC/DAC. (c1aaa is a play ground for debugging.)

  The trick was "copy DAC block from sam.mdl to aaa.mdl".
  I don't understand why this works. But it worked.
  I still have the problem of the matrices. Their medm screens are always blank. Needs more works.

- Also I don't understand why I can not run the build of c1tst when I copy the working aaa.mdl to tst.mdl.

- The problem Joe reported: "# of channels to be daqed" was solved by

make uninstall-daq-aaa
make install-daq-aaa



  This command is also useful.

daqconfig

- Now I am in the stable development loop with those commands

killaaa
make uninstall-daq-aaa
make aaa
make install-aaa
make install-daq-aaa
make install-screens-aaa
startaaa


  I have made "go_build" script under /home/controls/cds/advLigo

usage:
./go_build aaa

- Note for myself: frequently visited directories

/home/controls/cds/advLigo/src/epics/simLink (for model)
/home/controls/cds/advLigo (to build)
/cvs/cds/caltech/target/c1aaa (realtime code log)
/cvs/cds/caltech/target/c1aaaepics (ioc log)
/cvs/cds/caltech/medm/c1/aaa (medm screens)
/cvs/cds/caltech/chans (filter coeffs)
/cvs/cds/caltech/chans/daq (daq settings)

I am still working on the c1aaa code. Now it seems that C1AAA is working reasonably (...so far).

1) At a certain point I wanted clean up the system status. I have visited /etc/rc.local to add c1aaa for realtime to non-realtime task

before:
/usr/bin/setup_shmem.rtl mdp mdc tst&
after:
/usr/bin/setup_shmem.rtl mdp mdc tst aaa&


   I rebooted the system several times.

sudo /sbin/reboot

2) I found that gabage medm screens accumulated in ~/cds/advLigo/build/aaaepics/medm after many trials with several simulink models.
This directory is always copied to /cvs/cds/caltech/medm/c1/aaa at every make install-screens-aaa
This caused very confusing MEDM screens in the medm dir like C1AAA_ETMX_IN_MATRX.adl (NOT ETMY!)

I did

cd ~/cds/advLigo
make clean-aaa


to refresh aaaepics dir. The current development procedure is

killaaa
make clean-aaa
make uninstall-daq-aaa
make aaa
make install-aaa
make install-daq-aaa
make install-screens-aaa
startaaa

3) Sometimes startaaa does not start the task properly. If the task does not work, don't abandon.
Try restart the task. This may help. 

killaaa
(deep breathing several times)
startaaa

What to do next:

- MEDM works

* make more convenient custom MEDM screens so that we can easily access to the filters and switches
* retrofit the conventional SUS MEDM to the new system

- once again put/confirm the filter coeffs and the matrix elements

- configure DAQ setting so that we can observe suspension motion by dataviewer / dtt

- connect the suspension to megatron again

- test the control loop

Dmass, Joe, Koji

A puzzle has been solved: Dmass gave us a great tip

"The RGC code does not work unless the name of the mdl file (simulink model) matches to the model name "

The model name is written in the second line. This is automatically modified if the mdl file is saved from simulink.
But we copied the model by using "cp" command. This prevent from the TST model working!

megatron:simLink>head tst.mdl
Model {
  Name                    "tst"
  Version                 7.3
  MdlSubVersion           0
...
...
...

This explained why the AAA model worked when the DAC block has been copied from the other model.
This was not because of the ADC block but the saving model fixed the model name mismatch!

Now our current working model is "C1TST". Most of the functionalities have been implemented now:

• The simulink model has been modified so that some of the functionalities can be accomodated, such as LSC/ASC PIT/ASC YAW.
• Some filter names are fixed so as to inherit the previous naming conventions.
• The SUS-ETMY epics screen was modified to fit to the new channel names, the filter topologies, and the matrices.
• The chans file was constructed so that the conventional filter coefficients are inherited.
• All of the gains, filter SWs, matrix elements have been set accordingly to the current ETMY settings.
• burt snapshot has been taken: /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap
burtrb -f /cvs/cds/caltech/target/c1tstepics/autoBurt.req -o controls_1091117_024223_0.snap -l /tmp/controls_1091117_024215_0.read.log -v

What to do next:

• Revisit Oplev model so that it accomodates a power normalization functionality.
• ETMY QPD model is also missing!
• Clean up mdl file using subsystem grouping

• Check consistency of the whitening/dewhitening switches.
• Connect ADC/DAC to megatron
• Test of the controllability
• BTW, what is happened to BIO?
• Implementation of the RFM card

Directories and the files:

• The .mdl file is backed up as
/home/controls/cds/advLigo/src/epics/simLink/tst.mdl.20091116_2100


• The default screens built by "make" is installed in
  /cvs/cds/caltech/medm/c1/tst/
They are continuously overridden by the further building of the models.


• The custom-built medm screens are stored in
/cvs/cds/caltech/medm/c1/tst/CustomAdls/

The backup is
/cvs/cds/caltech/medm/c1/tst/CustomAdls/CustomAdls.111609_2300/


• The custom-built chans file is
/cvs/cds/caltech/chans/C1TST.txt

The backup is
/cvs/cds/caltech/chans/C1TST.111609


• burt snap shot file
  /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap


As mentioned in last post, we earlier made an error in making sure that all time series arrays go in with same sampling rate in CSD calculation. When we fixed that, our recursive method just blew out in all the efforts since then.

We suspect a major issue is how our measured sensing matrix (the cross-coupling matrix between different degrees of freedom on excitation) has significant imaginary parts in it. We discard the imaginary vaues and only use real parts for iterative method, but we think this is not the solution.

Here we present cross-spectral density of different channels representing the three sensed DOFs (normalized by ASD of no excitation data for each involved component) and the sensing matrix (TF estimate) calculated by normalizing the first cross spectral density plots column wise by the diagonal values. These are measured with existing ideal output matrix but with the new input matrix. This is to get an idea of how these elements look when we use them.

Note, that we used only 10 seconds of data in this run and used binwidth of 0.25Hz. When we used binwidth of 0.1 Hz, we found that the peaks were broad and highest at 13.1 Hz instead of 13 Hz which is the excitation frequency used in these measurements.

How should we proceed?

• We feel that we should figure out a way to use the imaginary value of the sensing matrix, either directly or as weights representing noise in that particular data point.
• Should we increase the excitation amplitude? We are currently using 500 counts of excitation on coil output.
• Are there any other iterative methods for finding the inverse of the matrix that we should be aware of? Our current method is rudimentary and converges linearly.
• Should we use the absolute value of the sensing matrix instead? In our experience, that is equivalent to simply taking ratios of the PSD of each channel and does not work as well as the TF estimate method.

Over the next few days, I will be working on upgrading the aLIGO Conlog install to include new bugfixes distributed by Patrick T.  The currently running conlog *should* not be affected, but please let me know if it is (ryan.fisher@ligo.org).

 The upgrade to the aLIGO Conlog is completed.  The conlog is once again running on megatron in a screen session. (see http://nodus.ligo.caltech.edu:8080/40m/6396)

I've updated the scan_adls script (currently located in /cvs/cds/caltech/conlog/bin) to look at new location of our medm screens.  I made a backup of the old conlog channel list as /cvs/cds/caltech/conlog/data/conlog_channels.old-2011-01-28.

I then ran the update_chanlist script in the same directory, which calls the scan_adl script.  After about 5 minutes it finished updating the channel list.  I restarted the conlogger just to be sure, and checked that our new model channels showed up in the conlog (which they do).

I have added a cron job to the op340m cron tab to once a day run the update_conlog script at 7am.

Next, I'm working on a HealthCheck script which looks at the conlog channel list and checks to see if channels are actually changing over short time scales, and then spit back a report on possibly non-functioning channels to the user.

[Joe,Alex]

Alex came over and we installed the new Dolphin drivers so that the front ends using the Dolphin PCIe RFM network don't pause for a long time when one of the other nodes in the network go down.  Generally this pause would cause the code to time out and quit.  Now you can take c1lsc or c1sus down without having the other have problems.

We did note on reboot however, that the Dolphin_wait script sometimes (not always) seems to hang.  Since this is run at boot up, to ensure the dolphin card has had enough to allocate memory space for data to be written/read from by the IOP process, it means nothing else in the startup script gets run if it does happen.  In this case, running "pkill dolphin_wait" may be necessary.

Note that you may still have problems if you hit the power button to force a shutdown (i.e. holding it for 4 seconds for immediate power off), but as long as you do a "reboot" or "shutdown -r now" type command, it should come down gracefully. 

What was done:

Alex grabbed the code from his server, and put it /home/controls/DIS/ on fb.

He ran the following commands in that directory to build the code.

./configure  '--with-adapter=DX' '--prefix=/opt/DIS'

make

sudo make install

He proceeded to modify the /diskless/root/etc/rc.local to have the line:

insmod /lib/modules/2.6.34.1/kernel/drivers/dis/dis_kosf.ko

In that same file he commented out

cd /root

and

exec /bin/bash/

He then modified the run levels in /diskless/root/etc/inittab. Level 0, level 3, and level 6 were changed:

l0:0:wait/etc/rc.halt

l3:3:wait:etc/rc.level3

l6:6:wait:/etc/rc.reboot

Then he created the scripts he was refering to:

rc.level3 is just:

exec /bin/bash

rc.halt is:

/opt/DIS/sbin/dxtool prepare-shutdown 0
sleep 3
halt -p

rc.reboot is:

reboot

Basically rc.halt calls a special code which prepares the Dolphin RFM card to shutdown nicely.  This is why just hitting the power button for 4 seconds will cause problems for the rest of the dolphin network.

We then checked out of svn the latest dolphin.c in  /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe

The Dolphin RFM cards have a new numbering scheme.  4 is reserved for special  broadcasts to everyone, so the Dolphin node IDs now start at 8.  So we needed to change the c1lsc and c1sus Dolphin node IDs.

To change them we went to /etc/dis/dishosts.conf on the fb machine, and changed the following lines:

HOSTNAME: c1sus
ADAPTER:  c1sus_a0 4 0 4
HOSTNAME: c1lsc
ADAPTER:  c1lsc_a0 8 0 4

to

HOSTNAME: c1sus
ADAPTER:  c1sus_a0 8 0 4
HOSTNAME: c1lsc
ADAPTER:  c1lsc_a0 12 0 4

The FE models for the c1lsc and c1sus machines were recompiled and then the computers were rebooted.  After having them come back up, we tested that there was no time out by shutting down c1lsc and watching c1sus. We then reveresed and shutdown c1sus while watching c1lsc.  No problems occured.  Currently they are up and communicating fine.

Getting started:  Worked on understanding the functionality of summary_page.py.  The problem with the code is that it was written in one 8000 line python script, with sparse documentation.  This makes it difficult to understand and tedious to edit, because it's hard to tell what the precise order of execution is without tracing through the code line by line.  In other words, it's difficult to get an overview of what the code generally does, without literally reading all of it.  I commented several functions / added docstrings to improve clarity and start fixing this problem.

Crontab:  I believe I may have discovered the cause of the 6PM stop on data processing.  I am told that the script that runs the summary_pages.py is called every 6 hours.  I believe that at midnight, the script is processing the next day's data (which is essentially empty) and thus not updating the data from 6PM to midnight for any of the days.

Git:  Finally, created git repository called public_html/__max_40m-summary_testing to use for testing the functionality of my changes to the code (without risking crashing the summary_pages).

I've been working on updating the suspensions model, incorporating Koji's refinements as well as trying to simplify the model and making it less cluttered. 

This had the side benefit of making an incorrect connection obvious.  I had incorrectly wired the ASCPIT input to be summed into the yaw path, and the ASCYAW input into the pitch path.  This has been corrected.

I've finished a single optic, and now I am in the process of propagating the changes to all the optics, as well as cleaning up the overall diagram using Rolf's new tags, which make things much less cluttered.  I've attached a screenshot of the PRM optic control model, and will be updating the Matlab web export once I've updated the full model.

 Upgrade of IMC Reflection Optical Setup

Nick and I upgrade the IMC. We move both WFSs and placed them facing west. When aligning the beam into the WFS, we make sure that the beam were hitting the center of the mirrors and then we placed the lenses in their corresponding position. We used the beam scanner to measure the waist and the waist in the second WFS was bigger than 1mm, and the second WFS was a little bit below than 1mm. We center the beam in the WFSs and in the PD. We did haven't measure whether we have a good Gouy Phase. Below I attached the picture of how the new setup look like.   

I upgraded Pylon, the C/C++ API for the GigE cameras, to the latest release, 5.2.0. It is installed in the same location as before, /opt/rtcds/caltech/c1/scripts/GigE/pylon5, so environment variables do not change. The old version, 5.0.12, still exists at opt/rtcds/caltech/c1/scripts/GigE/backup_pylon5.

The package contains a GUI application (/bin/PylonViewerApp) for streaming video. The old version supports saving still images, but Milind discovered that the new version supports saving video as well. This required installing a supplementary package supporting MPEG-4 output.

Basler's GUI application is launched from the terminal using the alias pylon. I've tested it and confirm it can save both videos and still-image formats. I recommend to also try grabbing images using this program and check the bit resolution. It would be a useful diagnostic to know whether it's a bug in Joe B.'s code or something deeper in the camera settings.

Since there are multiple SURF projects that rely on the cameras:

1. I moved the new installs Jon made to "new_pylon5" and "new_pypylon". The old installs were moved back to be the default directories.
2. The bashrc alias for pylon was updated to allow the recording of videos (i.e. it calls the PylonViewerApp from new_pypylon).
3. There is a script that can grab images at multiple exposures and save 12-bit data as uint16 numpy arrays to an HDF5 file. Right now, it is located at /users/kruthi/scripts/grabHDR.py. We can move this to a better place later, and also improve the script for auto adjusting the exposure time to avoid saturations.

My changes were necessary because the grabHDR.py script was throwing python exceptions, whereas it was running just fine before Jon's changes. We can move the "new_*" dirs to the default once the SURFs are gone.

Let's freeze the camera software config in this state until next week.

I'll keep developing the camera server on a parallel track using the "new_..." directory naming convention. One thing I forgot to note is that the new pylon/pypylon packages require Python 3, so will not work with any of the 2.7 scripts. All of the environment I need to set up is exclusively Python 3. I won't change anything in the Python 2.7 environment in current use.

Also, I found the source of the bit resolution issue: Joe B's code loads a set of initialization parameters from a config file. One of them is "Frame Type = Mono8" which sets the dynamic range of the stream. I'll look into how this should be changed. 

Upon leaving the lab:

- HEPA is ON at the original speed (i.e. same speed at 5PM today)

- WFS servo is ON, partly because we want to see how stable it is. It is not handled with the autolocker right now.
So there is a possibility that the WFS servo goes wild and make the IMC totally misaligned (and does not come back)
In such a case, go to the WFS servo screen and push "CH" (clear history) of each servo filters.

I measured the scatter from the eLIGO beam dumps as best I could. The experiment setup is shown in the attached diagram. 

After familiarizing myself with the equipment in the morning I noticed three issues with the setup

1 - around the minimum scatter the back scatter from the beam dump is very susceptible to the incident angle (makes sense since the Si plate inside the beam dump at Brewster's angle when there is minimum scatter).

2 - The mirrored plug (Part 20 in D0900095) which is suppose to be used for alignment is not very effective. It moves around too much in its hole in the front face of the beam dump. Just by touching it I could make the reflected beam jump around by about 0.1 radians.

- I think to align these properly we'll have to partly assemble the dumps. If we leave off the front plate of the horn then we can measure the reflection off the Si. If we measure this with a power meter then alignment becomes a simple matter of rotating until this reflection is minimized.

3. - For this measurement the incident beam was a small (~ 1mm diameter) central beam with a small amount of spray of laser light beyond that central region. This spray was hitting the aluminium front face of the beam dump and was scattering back to the photodiode. This was clearly the limiting factor in the measurement. Most of this light was spread horizontally so I placed a couple of pieces of black glass on either side of the aperture, just blocking the edges a little. This reduce the background reading at the minimum scatter from 17.0uV to around 4.5uV with still a little bit of light hitting the top and bottom of beam dump face.

The incident power on the beam dump fluctuated a little but was in the range 20.5 to 22mW. The response of the PD is approximately 0.2 A/W and the transimpedance is 7.5E4 V/A.

The SR830 Sensitivity was set to 1x1 mV.

It was difficult to measure the actual angle of incidence. The dump pivoted about a point directly under the input aperture at the front. By measuring the displacement of a point on the back of the dump as I rotated it and knowing the distance between this point and the pivot point I was able to make a reasonably accurate measurement of a range of angles about the minimum.

The measured scatter (in V measured directly by the PD and as a fraction of the incident power) is shown in the attached plots.

I think I can do a better job cleaning up the incident beam - so these numbers only represent an upper limit on the scatter.

attachment 1: beam dump assembly

attachment 2: experimental layout

attachment 3: scatter measurement

attachment 4: BRDF - (scatter divided by the solid angle = 1.1 m steradians)

attachment 5: (slightly blurred )photo of dump - overhead view 

[Aidan, Kiwamu]

Kiwamu and I plugged the output from a DS3456 function generator into the ADC and started recording the data. The func. generator output a 237.8Hz, 1Vpp sine wave. We chose this value because it corresponds to the FSR of a 38.5m cavity (=3.896MHz) divided by 2^14, the frequency divider amount we intend to use.

Since 1 FSR divided down is 237.8Hz and corresponds to a length change of the cavity of 532nm/2 = 266nm, then we can, roughly, say that a frequency change of 1Hz corresponds to a length change in the cavity of approximately 1nm. The width of the 237.8Hz peak in the spectra corresponds to an upper limit on the noise floor due to digitizing the signal (this could be limited by the ADC, or the function generator, or the windowing on the FFT).

The FWHM of the peak in the spectrum was approximately 5mHz, corresponding to an uncertainty in the length of the cavity of about 6pm (we used a Hanning Window, 50% overlap and a BW of 2.92mHz, 7 averages). Regardless of what is the dominant contribution to the width of the peak, this implies that the frequency noise associated with digitizing a signal in the ADC is much smaller than we require and will not limit our performance if we choose to use a frequency divider and digital PLL with the Green Locking.

RA: Here's the previous measurement

BALUNs

example of plots illustrating DAC range / saturation

I updated the database files for the 7 BHD optics to separate the OSEM variance trigger and the LATCH_OFF trigger operations so that an OSEM variance value exceeding the max of say 200 cnts turns off the damping loop whereas pressing the LATCH_OFF button cuts power to the coil. I restarted the modbusIOC service on c1susaux2 and checked that the new functionality is behaving as expected. So far so good.

TODO

Figure out the next layer of watchdogging needed for the BHD optics.  

[Anchal, Tega]

Implemented ramp down of coil bias voltage when the BHD optics watchdog is tripped. Also added a watchdog reset button to the SUS medm screen that turns on damping and ramps up the coil PIT/YAW bias voltages to their nominal values. I believe this concludes the watchdog work.

Test details:

• We locked both arms and opened the shutter for Yend green laser.
• After toggling the shutter on.off, we got a TEM00 mode of green laser locked to YARM.
• We then cleared the phase Y history by clicking "CLEAR PHASE Y HISTROY" on C1LSC_ALS.adl (opened from sitemap > ALS > ALS).
• We sent excitation signal at ITMY_LSC_EXC using awggui at 43Hz, 77Hz and 57Hz.
• We measured the power spectrum and coherence of C1:ALS-BEATY_FINE_PHASE_OUT_HZ_DQ and C1:SUS-ITMY_LSC_OUT_DQ.
• The BEATY_FINE_PHASE_OUT_HZ is already calibrated in Hz. This we assume is done by multip[lying the VCO slope in Hz/cts to the error signal of the digital PLL loop that tracks the phase of beatnote.
• We calibrated C1:SUS-ITMY_LSC_OUT_DQ by multiplying with
  where f is in Hz.
  The 2.44/f² nm/cts is taken from 13984.
• We added the calibration as Poles/zeros option in diaggui using gain=54.577e3 and poles as "0, 0".
• We found that ITMY_LSC_OUT_DQ calibration matches well at 57Hz but overshoots (80 vs 40) at 43 Hz and undershoots (50 vs 80) at 77Hz.

Conclusions:

• If we had DRFPMI locked, we could have used the beatnote spectrum as independent measurement of arm lengths to calibrate the interferometer output.
• We can also use the beatnote to confirm or correct the ITM actuator calibrations. Maybe shape is not exactly 1/f² unless we did something wrong here or the PLL bandwidth is too short.

Contacted Charles regarding use of Altium. Got to know that Altium is installed on cit40m iMac in Win7 on VirtualBox. Had to update Virtualbox to get it working. Altium now works for sometime, but then fails, saying that it is unlicensed.

There were several cases where the long EQ stops didn't perform as expected.

In one type of case, we used a counterweight at the front of the adapter but not in the back leaving a recess where the lower back EQ stop should touch.

In the other type, a recess in the thick optics adapter prevented the upper EQ stop from touching the adapter. In the first thick optic, the screw was screw barely scratched the recess' corner. In the second case, it didn't touch it at all.

In the last group meeting, we discussed using Peek screws (made out of plastic) to prevent metal on metal bumping when the EQ can touch the adapter and Peek nuts when it doesn't to increase its impact area.

Mcmaster has 1.5" long 1/4-20 screws (part number 98885A131) that will fit well in the OSEM plates. We can order 20 of those.

The biggest Peek nuts on Mcmaster however are not big enough (7/16" wide) to cover the entire bottom recess area which is 0.5" wide (they are good enough for the top recess area in the thick adapter optic design). Koji suggested that we can use a big Peek washer for that purpose that can be held between nuts. We should then order 10 Peek nuts (98886A813) and 1 package of 10 Peek washers (0.63" OD) (93785A600).

I have been working on using PyKat to run Finesse. There appear to be several ways to run an equivalent simulation using Finesse:

1: .kat only

Run a .kat file directly from the terminal. For example, if in the directory containing the Finesse kat.ini file, run the command ‘./kat file.kat’. This method does not use PyKat.

To edit the simulation using this method, one must directly edit the .kat file. This is not ideal, as all parameters must be hard-coded, and there is no looping method for duplicate commands.

Both of the following methods use PyKat in some manner. To run Finesse using PyKat from a .py file, the command ‘from pykat import finesse’ should be included. In addition, two environment variables must be defined:

• ‘FINESSE_DIR': directory containing ‘kat’ executable
• ‘KATINI’: location and name of kat.ini file

Within a .py file running PyKat, the kat object contains all of the optical components and their states. To create a kat object, we use the command:

kat = finesse.kat()

2: .kat + .py

To load Finesse commands from a .kat file, we can use the command loadKatFile(). For example, using the kat object as defined above:

kat.loadKatFile(‘file.kat’)

The kat object now contains any components defined in the .kat file. The states of these components can be altered using PyKat. For example, if in the .kat file, we defined a mirror named ‘ITM’, with R = 0.9, T = 0.1, phi = 0, and with nodes 1 and 2 to its left and right, respectively, using the Finesse command

m ITM 0.9 0.1 0 n1 n2

we can now alter the state of the mirror using a PyKat command such as

kat.ITM.phi = 30

which changes the ‘phi’ property of the mirror to 30 degrees. Once all alterations to objects are made, we can run Finesse using the command

out = kat.run()

which stores the output of the Finesse simulation in the variable out.

3: .py only

We can also run a Finesse simulation without any .kat file. There are two ways to define Finesse objects within a .py file.

- Parse a string containing Finesse commands, as would be found in a .kat file, using the command parseCommands(). For example,

            kat.parseCommands(‘m ITM 0.9 0.1 0 n1 n2’)

defines the same mirror as above. This object can now be altered using pyKat in the same manner as above.

- Define an object using the classes defined in PyKat. For example, to define the same ITM mirror, we can use:

ITM = mirror(‘ITM’, ‘n1’, ‘n2’, 0.9, 0.1, 0)

kat.add(ITM)

The syntax for these classes can be found in the files included in the PyKat package named ‘commands.py’, ‘detectors.py’, and ‘components.py’.

We can also run Finesse commands (rather than just defining components) using their respective classes. These must also be added to the kat object. For example:

x = xaxis(‘lin’, [‘-4M’, ‘4M’], ‘f’, 1000, ‘laser’)

kat.add(x)

This runs the command ‘xaxis’, which sets the x-axis of the output data to run from freq = -4 MHz to 4 MHz, in 1000 steps. This is equivalent to the following Finesse command:

xaxis laser f lin -4M 4M 1000

In theory, we should be able to use PyKat to run any Finesse command. However, not all Finesse commands appear to be defined in PyKat; one example is the Finesse command ‘yaxis’, which I cannot locate in PyKat. In addition, I have had difficulty running some commands such as ‘cav’ and ‘pd’, despite following their class definitions in the PyKat files. However, these commands can still be easily run in PyKat using parseCommands().

 WE currently use long cables to give us the dispersion that we want for the MFD. A cable gives a long delay - both the phase delay and the group delay.

But we only need the dispersion (group delay). We can get this by just using a very sharp low pass filter and having the corner be above the frequency that we have the beat signal.

For example, the MiniCircuits SLP-200+ has got a corner frequency of 200 MHz and a group delay of ~10 ns (like a 3 m vacuum delay). So we would have to use 10 of these to get the delay we now get. The passband attenuation is only 0.5 dB, so we would lose 5 dB. The cost is $35 ea. We have a few on the shelf.

OTOH, if we tune the beat frequency down to 30 MHz, we can use the SLP-30 which has a group delay of 30 ns around 30 MHz. That's like 9m at light speed. We could easily get a nice result by just using 4 or 5 SLP in series.

So why is Kiwamu using cables?? And how should we really choose the beat note frequency??

BLACK   - raw ground motion measured by the Guralp
MAGENTA - motion after passive STACIS (20 Hz harmonic oscillator with a Q~2)
GREEN   - difference between ground and top of STACIS
YELLOW  - EUCLID noise in air
BLUE    - STACIS top motion with loop on (60 Hz UGF, 1/f^2 below 30 Hz)
CYAN    - same as BLUE, w/ 10x lower noise sensor

The DFD was setup to measure the change in beatnote when excited. A long long (128in) cable goes from the SR785 near the DFD all the way to the Xend AUX which it accordingly excites and the DFD is monitored by the oscilloscope at the other end. This was completed on Friday. The wires and stand have been moved to the side but the setup is still a bit chaotic. As of writing this post, there is still atleast some minor issue with the setup as we aren't getting the expected output. 

[I will shortly update this elog with more pictures]

Edit: the SR785 was replaced by the AG 4395, and pictures added

[Deeksha, Cici]

We used a python script to collect data from the SR785 remotely. The SR785 is now connected to the wifi network via Ethernet port 7.

Joe and I have taken control of the EPICS channels C1:PEM-Stacis_EEEX_geo and C1:PEM-Stacis_EEEY_geo since we heard that they are no longer in use.  We are currently 
using them to test the ability for the Snap camera code to read and write from EPICS channels.  Thus, the information being written to these channels is completely unrelated
to their names or previous use.  This is only temporary; we'll create our own channels for the camera code shortly (probably within the next couple of days).

- Eric

I used MC_L signal from the Mode Cleaner as the desired signal with GUR2_X as witness signals. I observed good subtraction where coherence is high. But there was noise added in other frequency bands. I am not sure how to avoid that.

Please find attached documents that contains relevant plots.

One of these V beam dumps was installed for BH44 RF PD.
The rest is now stored in the box in the shelf along Yarm, together with RF PD mounts.

Joe, Alberto and Steve

We tested gate valve V1 interlock by :

1, decelerated rotation by brake from maglev controller unit.

2, turned maglev  controller off from controller unit.

3, unpluged 220VAC plug from wall socket

None of the above action triggered V1 to close. This needs to be corrected in the future.

The MEDM monitor screen of maglev indicated the correct condition changes.

 V1 valve is open to IFO now. V1 interlock will be tested tomorrow.

Valve configuration: VAC NORMAL with CRYO and Maglev are both pumping on the IFO

The PR2 candidate V6-704/705 mirrors (Qty2) are now @Downs. Camille picked them up for the measurements.

To identify the mirrors, I labeled them (on the box) as M1 and M2. Also the HR side was checked to be the side pointed by an arrow mark on the barrel. e.g. Attachment 1 shows the HR side up

Camille@Downs measured the surface of these M1 and M2 using Zygo.

 Designated vacuum control lap top is trouble some to use. Joe finally fixed it and I switched valve configuration back to vacuum normal. Shutter is open

They are VAT valves F28-62887-03, 11, 14 and so on ~15-16 years old.

VAT's answer:

Yes, our engineers are aware of this issue.  They say:

The pneumatic actuator needs lubricant as the O-ring (Viton) slides in the cylinder. Without grease the O-ring would be abraded and leaking after only a relatively few cycles.  The lubricant used in our pneumatic actuators is an emulsion of oil and Teflon flakes.   Vibration, many cycles and sometimes high temperature lead to the separation of the oil and Teflon.   That is apparently the issue you are seeing.

VAT is and has been testing and qualifying new lubricants, and this is one of the factors we are always looking to improve.  The formula we used 15 years ago in these valves seems to have performed reasonable  well.  Our formula today should perform even better.

We realize this explanation does not help you with these existing valves, but 15 years of service is not too bad is it? 

Steve -NOTE:bonnet seal is metal so there is no way this oil can get into our vacuum ( only if the bellow leaks )

CC1 5e-7 Torr,  VC1 closed at 18:25,  IFO is not pumped, RGA is in bg-mode

At about 1am or so Yoichi and I opened VC1.  CC1 had fallen to about 5e-5 torr.