40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 73 of 341  Not logged in ELOG logo
IDup Date Author Type Category Subject
  3631   Thu Sep 30 21:55:31 2010 ranaUpdateCDSDAQ sys update

Its pretty exciting to see that Joe got Alex to actually use the ELOG. Its a proof that even rare events occur if you are patient enough.

1) I fixed the MEDM links to point to the new sitemap.adl in /opt/rtcds. There is a link on the new sitemap which points to the old sitemap so that there is nothing destroyed yet.

2) Some of the fields in the screen are white. These are from the new c1sus processor, not issues with the slow controls. I think its just stuff that has not yet been created in the C1SUS simulink module.

Untitled.png

3) The PZT steering controls are gone. Without this we cannot get the beam down the arm. Must fix before aliging things after the MC. Since PZT used to be controlled by ASC, we'll have to wire the Piezo Jena PZT controls in from a different VME 4116. Possibly c1iool0's crate?

4) Also, the IPANG and IPPOS are somehow not working right. I guess this is because they are part of the ASC / the old ETMX system. We'll have to wire the IPANG QPD into the new ETMY ADC system if we want to get the initial alignment into the Y-arm correct.

5) I've started migrating things over from the old SITEMAP. Please just use the new SITEMAP. it has a red link to the old one, but eventually everything on the new one will work after Joe, Alex, me, and Kiwamu are done tweaking.


 

  3632   Fri Oct 1 10:56:30 2010 josephb,alexUpdateCDSfb work continued

Alex fixed the time issue with the IRIG-B signal being far off, apparently their IRIG-B signal in downs seems to be different.  He simply corrected for the difference in the two signals in the code.

For debugging purposes we uncommented the following line in the feCodeGen.pl script (in /opt/rtcds/caltech/c1/advLigoRTS/src/epics/util/):

print EPICS "test_points ONE_PPS $dac_testpoint_names $::extraTestPoints\n" 

This is to make every ADC testpoint available from the IOP (such as c1x02).

  3633   Fri Oct 1 11:33:15 2010 josephb, alexConfigurationCDSChanging gds code to the new working version

Alex is installing the newly compiled gds code (compiled on Centos 5.5 on Rosalba) which does in fact include the ezca type tools. 

At the moment we don't have a solaris compile, although that should be done at somepoint in the future.  It means the gds tools (diaggui, foton, etc) won't work on op440m.  On the bright side, this newer gds code has a foton that doesn't seem to crash all the time on Linux.

 

  3634   Fri Oct 1 11:53:42 2010 josephbConfigurationCDSAdded RCG simlink files to the 40m svn

I've added a new directory in /opt/rtcds/caltech/c1/core called rts_simlink.  This directory is now in the 40m svn.  Unfortunately, the simlink files used to generate the front end c codes live in a directory controlled by the CDS svn.  So I've copied the .mdl files from /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink/ into this new directory and added them into the 40m svn.  When making changes to the simlink files, please copy them to this new directory and check them in so we can a useful history of the models.

 

  3635   Fri Oct 1 14:13:29 2010 josephb, alexUpdateCDSfb work that still needs to be done

1) Need to check 1 PPS signal alignment

2) Figure out why 1PPS and ADC/DAC testpoints went away from feCodeGen.pl?

3) Fix 1PPS testpoint giving NaN data

4) Figure out why is daqd printing "making gps time correction" twice?

5) Need to investigate why mx_streams are still getting stuck

6) Epics channels should not go out on 114 network (seen messages when doing
burt restore/save).

7) Dataviewer leaves test points hanging, daqd does not deallocate them
(net_Writer.c shutdown_netwriter call)

8) Need to install wiper scripts on fb

9) Need to install newer kernel on fb to avoid loading myrinet firmware
(avoid boot delay)

  3636   Fri Oct 1 16:34:06 2010 josephbUpdateCDSc1sus not booting due to fb dhcp server not running

For some reason, the dhcp server running on the fb machine which assigns the IP address to c1sus (since its running a diskless boot) was down.  This was preventing c1sus from coming up properly.  The symptom was an error indicated no DHCP offers were made(when I plugged a keyboard and monitor in).

To check if the dhcp server is running, run ps -ef | grep dhcpd.  If its not, it can be started with "sudo /etc/init.d/dhcpd start"

  3637   Fri Oct 1 16:46:20 2010 steveBureaucracySAFETYYuta received 40m-101-safety training

Our visiting graduate student Yuta Michimura received 40m specific basic safety training today.

  3638   Fri Oct 1 18:19:24 2010 josephb, kiwamuUpdateCDSc1sus work

The c1sus model was split into 2, so that c1sus controls BS, PRM, SRM, ITMX, ITMY, while c1mcs controls MC1, MC2, MC3.  The c1mcs uses shared memory to tell c1sus what signals to the binary outputs (which control analog whitening/dewhitening filters), since two models can't control a binary output.

This split was done because the CPU time was running above 60 microseconds (the limit allowable since we're trying to run at 16kHz). Apparently the work Alex had done getting testpoints working had put a greater load on the cpu and pushed it over an acceptable maximum.    After removing the MC optics controls, the CPU time dropped to about 47 microseconds from about 67 microseconds.  The c1mcs is taking about 20 microseconds per cycle.

The new model is using the top_names functionality to still call the channels C1SUS-XXX_YYY.  However, the directory to find the actual medm filter modules is /opt/rtcds/caltech/c1/medm/c1mcs, and the gds testpoint screen for that model is called C1MCS-GDS_TP.adl.  I'm currently in the process of updating the medm screens to point to the correct location.

Also, while plugging in the cables from the coil dewhitening boards, we realized I (Joe) had made a mistake in the assignment of channels to the binary output boards.  I need to re-examine Jay's old drawings and fix the simulink model binary outputs.

  3639   Fri Oct 1 18:53:33 2010 josephb, kiwamuUpdateCDSThings needing to be done next week

We realized we cannot build code with the current RCG compiler on c1ioo or c1iscex, since these are not Gentoo machines.  We need either to get a backwards compatible code generator, or change the boot priority (removing the harddrives also probably works) for c1ioo and c1iscex so they do the diskless Gentoo thing.  This would involve adding some MAC address to the framebuilder dhcpd.conf file in /etc/dhcp along with the computer IPs, and then modifying the /diskless/root/etc/rtsystab with the right machine names and models to start.

I also need to bring some of the older, neglected models up to current build standards. I.e. use cdsIPCx_RFM instead of cdsIPCx and so forth. 

Need to fix the binary outputs for c1sus/c1mcs.  Need to actually get the RFM running, since Kiwamu was having some issues with his green RFM test model.  We have the latest checkout from Rolf, but we have no proof that it actually works.

  3640   Fri Oct 1 21:34:14 2010 rana, taraUpdatePSLHigh Voltage Driver added to TTFSS -> NPRO

Quote:

We added the Thorlabs HV Driver in between the FSS and the NPRO today. The FSS is locking with it, but we haven't taken any loop gain measurements.

This box takes 0-10 V and puts out 0-150 V. I set up the FSS SLOW loop so that it now servos the output of FAST ot be at +5V instead of 0V. This is an OK

temporary solution. In the future, we should add an offset into the output of the FSS board so that the natural output is 0-10 V.

I am suspicious that the Thorlabs box has not got enough zip to give us a nice crossover and so we should make sure to measure its frequency response with a capacitive load.

 

 We measured the Thorlabs HV Driver's TF today. It is quite flat from 1k to 10k before going up to 25 dB at 100k,

and the response does not change with the DC offset input.

 

The driver is used for driving the NPRO's PZT which requires higher voltage than that of the previous setup.

We need to understand how the driver might effect the FSS loop TF, and we want to make sure that the driver

will have the same response with DC input offset.

 

Setup

 

We used SR785 to measure the TF. Source ch was split by a T, one connected to Driver's input, another one connected to the reference (ch A). See fig2.

The driver output was split by another T. One output was connected to NPRO,

another was connected to a 1nF capacitor in a Pomona box, as a high pass filer (for high voltage), then to the response (ch B)

 The source input is  DC offset by 2V which corresponds to 38 V DC offset on the driver's output.

The capacitance of the PZT on the NPRO is 2.36 nF, as measured by LC meter.

 

 The result shows that the driver's TF is flat from 1k to 10k, and goes up at higher frequency, see fig1.

 

The next step is trying to roll of the gain at high frequency for PZT. A capacitor connected to ground might be used to roll off the frequency of the driver's output.

We will inspect the TF at higher frequency (above 100 kHz) as well.

            

Attachment 1: NPROTF.png
NPROTF.png
Attachment 2: 2010_10_01.png
2010_10_01.png
  3641   Mon Oct 4 06:47:46 2010 rana, taraUpdatePSLHigh Voltage Driver added to TTFSS -> NPRO

Inside the FSS box, the FAST path has a ~10 Hz pole made up from the 15k resistor and the 1 uF cap before the output connector.

This should be moved over to the output of the driver to make the driver happy - without yet measuring the high frequency response,

it looks like to me that its becoming unhappy with the purely capacitive load of the NPRO's PZT. This will require a little surgery inside

the FSS box, but its probably justified now that we know the Thorlabs box isn't completely horrible.

 

  3642   Mon Oct 4 11:20:45 2010 josephbUpdateCDSFixed Suspension binary output list and sus model

I've updated the CDS wiki page listing the wiring of the 40m suspensions with the correct binary output channels.  I previously had confused the wiring of the Auxillary crate XY220 (watchdogs) with the SOS coil dewhitening bypasses.  So I had wound up with the wrong channels (the physical cables we plugged in were correct, just what I thought was going on channel X of that cable was wrong).  This has been corrected in the plan now.  The updated channel/cable list is at http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/CDS/Suspension_wiring_to_channels

  3643   Mon Oct 4 13:48:41 2010 Leo SingerConfigurationComputersUninstalled gstreamer-devel and gstreamer-plugins-base-devel on rosalba

 I uninstalled gstreamer-devel and gst-plugins-base-devel on Rosalba.  Here is the command I ran:

$ sudo yum remove gstreamer-devel gstreamer-plugins-base-devel

 

Actually, I had installed these myself a few days earlier, before I knew that I should be recording such changes in the elog.  I'm sorry!

  3644   Mon Oct 4 15:28:10 2010 josephbUpdateCDSTrying to get c1ioo booting as Gentoo.

I modified the dhcpd.conf file in /etc/dhcp on the fb machine.  I added a entry for c1ioo, listing its MAC address and ip number near the bottom of the file.  I then restarted the dhcp server using "sudo /etc/init.d/dhcpd restart" while on the fb machine.

I also modified the rtsystab, which is used to determine which front end codes start on boot up of a machine.  I added a line: c1ioo   c1x03  c1ioo

I am now in the process of getting c1ioo to come up as a Gentoo machine so I can build a model with an RFM connection in it and test the communication between c1sus and c1ioo.  This involves removing the hard drives and checking to make sure the boot priority is correct (i.e. it checks for a network boot).

  3645   Mon Oct 4 19:48:00 2010 yutaUpdateVACseveral mirrors installed to ITMX/BS chamber

(Koji, Kiwamu, Yuta)

Lots of progress for the optics placement in the vacuum chamber.
We are ready to go to the next step: open the access connector between IMC and OMC.
 


Background:

The actual work in the vacuum chamber started.
The first goal of the vent is to get the green beam coming out from the chambers to the PSL table.


What we did:

1. Inspection of the tip-tilt suspension

The alignments of the TTs were inspected. We had five TTs having been sitting on the table in Bob's clean room.
Prior to their installation we checked the alignments of those because they sometimes showed large hysteresis mainly in the pitch directions.

If a TT has the hysteresis, the pitch position doesn't come back to the previous position. This may cause an issue of the interferometer operation.

- SN001, SN003, SN005 looked well aligned and show no hysteresis.

- The alignment of SN002 was not so good (theta ~ 0.004 rad ) compared to those three, but no hysteresis, we think this guy is still acceptable for the installation.

- SN004 had an apparent hysteresis. This guy doesn't come back to the previous place, being applied a touch. We have to fix this at some point.

2. Work in the ITMX chamber

Now all of the optic in this chamber was installed in the approximate place.

- Installed POX/POP steering mirrors.

- TT(SN003) was placed.

- The two steering optics for ITMX OPLEV were placed at the designed positions.

3. Work in the BS chamber

Installed 2 TTs to the BS chamber.
- SR3: TT(SN001)
- PR3: TT(SN005)

After the alignment of the green steering mirrors, we confirmed
the green beam is successfully hitting the west wall of the OMC chamber.

Those TTs are approximately aligned using the weakly reflected green beams.

Next work:

- Open the access connector

- Place another periscope and two steering mirrors for green

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

 

Attachment 1: P1060901.JPG
P1060901.JPG
Attachment 2: P1060904.JPG
P1060904.JPG
  3646   Tue Oct 5 09:26:04 2010 steveConfigurationPEMmoved accelerometers

Accelerometers xyz were moved from IOO-south/west  corner to under PSL table. They were turned off for ~20 minutes.

Guralp was also moved eastward about 2 ft. It is not leveled.

This is part of the preparation to remove access connector.

  3647   Tue Oct 5 11:42:20 2010 kiwamuSummaryGreen Lockingdeveloping green locking plant

 With a help from Joe, I made a diagram of the simulated plant for green locking in order to get better understanding and consensus.

Eventually these simulated plants will help us developing (sometimes debugging) the digital control systems.

Here is the diagram which tells us how we will setup and link the control/plant models and on which machine they will be running.

green_sm3.png

 

Basically upper side represents the realtime control, and the lower side is the simulated plant.

The models are talking to each other via either a local shared memory (orange line) or the reflective memory network (purple line).

 Each model is stil not systematically named, at some point we have to have an absolute standard for naming the models.

 

- current model names -

  GCV = Green Control model at Vertex

  GCX(Y) = Green Control model at X (Y) end

  GPV = Green Plant model at Vertex

 

 - things to be done -

1. let the RFM work

2. revise the old plant models : SUP, SPX(Y) and LSP

 

  3648   Tue Oct 5 13:46:26 2010 josephb, alexUpdateCDSRestarted fb trending

Fb is now once again actually recording trends.

A section of the daqdrc file (located in /opt/rtcds/caltech/c1/target/fb/ directory) had been commented out by Alex and never uncommented.  This section included the commands which actually make the fb record trends.

The section now reads as:

# comment out this block to stop saving data

#
start frame-saver;
sync frame-saver;
start trender;
start trend-frame-saver;
sync trend-frame-saver;
start minute-trend-frame-saver;
sync minute-trend-frame-saver;
start raw_minute_trend_saver;
#start frame-writer "225.225.225.1" broadcast="131.215.113.0" all;
#sleep 5;

  3649   Tue Oct 5 13:52:15 2010 ranaUpdateCDSproof of trend

Untitled.png

  3650   Tue Oct 5 13:59:17 2010 Leo SingerConfigurationComputersInstalled x264-devel on Allegra

 I installed the package x264-devel on allegra.martian.  This package provides headers and libraries for the popular h264 video codec.  I am going to use this in the GStreamer streaming media server on Allegra.

  3651   Tue Oct 5 14:11:09 2010 josephb, alexUpdateCDSGoing to from rtlinux to Gentoo requires front end code clean out

Apparently when updating front end codes from rtlinux to the patched Gentoo, certain files don't get deleted when running make clean, such as the sysfe.rtl files in the advLigoRTS/src/fe/sys directories.  This fouls the start up scripts by making it think it should be configured for rtlinux rather than the Gentoo kernel module.

  3652   Tue Oct 5 16:30:00 2010 josephb, yutaHowToCDSScreen settings and medm screens for new system

You can find the sitemap medm screen in

/opt/rtcds/caltech/c1/medm/master

The settings for the screens were last saved by burt in the original system on Sept 29, 2010 at 11:07.  So go to the

/cvs/cds/caltech/burt/autoburt/snapshots/2010/Sep/29/11:07

directory.  You can grep for the channels in the files in this directory.

You can also then use the autoBurt.req file in the /opt/rtcds/caltech/c1/target/sysname/sysnameepics (c1sus/c1susepics) to backup the settings entered.  Save to the /opt/rtcds/caltech/c1/target/snapshots directory for now.

 

 

  3653   Tue Oct 5 16:58:41 2010 josephb, yutaUpdateCDSc1sus front end status

We moved the filters for the mode cleaner optics over from the C1SUS.txt file in /opt/rtcds/caltech/c1/chans/ to the C1MCS.txt file, and placed SUS_ on the front of all the filter names.  This has let us load he filters for the mode cleaner optics.

At the moment, we cannot seem to get testpoints for the optics (i.e. dtt is not working, even the specially installed ones on rosalba). I've asked Yuta to enter in the correct matrix elements and turn the correct filters on, then save with a burt backup.

  3654   Tue Oct 5 17:39:21 2010 steveConfigurationVACwest access connector removed

Kiwamu, Koji, Yutah, Rana, Jan and Steve

We removed the west access connector this afternoon.

  3655   Tue Oct 5 18:27:18 2010 Joonho LeeSummaryElectronicsCCD cable's impedence

Today I checked the CCD cables which is connected to the VIDEOMUX.

17 cables are type of RG59, 8 cables are type of RG58. I have not figured out the type of other cables(23 cables) yet.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

To check the impedance of each CCD cable, I went to the VIDEOMUX and looked for the label on the cable's surface.

Type of RG59 is designated to the cable of impedance 75ohm. I wrote down each cable's input or output channel number with observation(whether it is of type RG59 or not).

The result of observation is as follows.

Type channel number where it is connected to
Type 59 in#2, in#11, in#12, in#15, in#18, in#19, in#22, in#26, out#3, out#4, out#11, out#12, out#14, out#17, out#18, out#20, out#21
Type 58 in#17, in#23, in#24, in#25, out#2, out#5, out#7, out#19
unknown type others

 

For 23 cables that I have not figured out their type, cables are too entangled so it is limited to look for the label along each cable.

I will try to figure out more tomorrow. Any suggestion would be really appreciated.

  3656   Tue Oct 5 21:22:46 2010 yutaUpdateVACgreen beam reached PSL table

YES ! We got the green light coming out from the OMC chamber to the PSL table !

 (Koji, Kiwamu, Yuta)

Background

As a result of the work in the chambers, the green beam reached the OMC chamber yesterday.
Today's mission was to let the green beam coming out from the chambers to the PSL table.

What we did:
1. Installed the last three steering mirrors.
  The mirrors were 532 HR mirror with AR and 1deg wedge (CVI Y2-LW-1-2050-UV-45-P/AR).
  Two of them are placed to the MC chamber. Another one was to the OMC chamber

During putting the mirrors to the MC chamber, we found that a cable tower was sitting on a position exactly where we wanted to put one of the mirrors.

So we moved the tower to the very south west corner. 

 

2. Installed a periscope to the MC chamber

The function of this periscope is to lower the beam height of the green light which is risen up by another periscope in the BS chamber.

We aligned it to the green beam, so that the beam hits the center of the mirrors on the periscope.  

 

3. Aligned the optics

We aligned the green mirrors so that we can let the green beam go out from the chamber.

Actually the inside of the OMC chamber didn't look like the same as that of our optical layout.

For example there is unknown base plate, which apparently disturbs the location of our last steering mirror.

Therefore we had to change the designed position of the steering mirror.

Now the mirror is sitting near the designed position (~ 1/2 inch off), but it's fine because it doesn't clip any 1064 beam.

 
Result:

The green beam is now hitting the north wall of the PSL table.

 

Notes:

The green beam looks having some fringes, it may be caused by a multiple reflection from a TT when the green beam goes through it. We are going to check it. 

 

Next work:

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

 IMG_3627.jpg

 

  3657   Wed Oct 6 00:32:01 2010 ranaSummaryDAQNDS2

This is the link to the NDS2 webpage:

https://www.lsc-group.phys.uwm.edu/daswg/wiki/NetworkDataServer2

We should install this so that we can use this modern interface to get 40m data from outside and inside of the 40m.

  3658   Wed Oct 6 11:03:51 2010 josephb, yutaHowToCDSHow to start diaggui for right now

I'm hoping to get a proper install this week done, but for now, this a stop gap.

To start diagnostic test tools, go to rosalba.  (Either sit at it, or ssh -X rosalba).

cd /opt/apps

type "bash", this starts a bash shell

source gds-env.bash

diaggui

 --------- Debugging section ------

If that throws up errors, try looking with "diag -i" and see if there's a line that starts with nds.  In the case last night, Alex had not setup a diagconf configuration file in the /etc/xinetd.d directory, which setups up the diagconf service under the xinit service.  To restart that service (if for example the nds line doesn't show up), go to /etc/init.d/ and type "sudo xinit start" (or restart).

Other problems can include awg and/or tpman not running for a particular model on the front end machine.  I.e. diag -i should show 3 results from 192.168.113.85 (c1x02, c1sus, c1mcs) at the moment , for both awg and tp.  If not, that means awg and tpman need to be restarted for those.

These can be started manually by going to the front end, to the /opt/rtcds/caltech/c1/target/gds/bin/ directory, and running awgtpman -s sysname (or in the case of IOP files [c1x02, c1x03, etc], awgtpman -s sysname -4.  Better is probably to run the start scripts which live /opt/rtcds/caltech/c1/scripts/ which kills and restarts all the process for you.

 

 

  3659   Wed Oct 6 12:00:23 2010 josephb, yuta, kiwamuUpdateCDSFound and fixed filter sampling rate problem with suspensions

While we looking using dtt and going over the basics of its operation, we discovered that the filter sample rates for the suspensions were still set to 2048 Hz, rather than 16384 Hz which is the new front end.  This caused the filters loaded into the front ends to not behave as expected.

After correcting the sample rate, the transfer functions obtained from dtt are now looking like the bode plots from foton.

We fixed the C1SUS.txt and C1MCS.txt files in the /opt/rtcds/caltech/c1/chans/ directory, by changing the SAMPLING lines to have 16384 rather than 2048.

  3660   Wed Oct 6 14:49:54 2010 ranaSummaryloreSteve on the sea

jacques.jpg

  3661   Wed Oct 6 15:56:14 2010 josephbHowToCDSHow to load matrices quickly and easily

Awhile ago I wrote several scripts for reading in medm screen matrix settings and then writing them out.  It was meant as kind of a mini-burt just for matrices for switching between a couple of different setups quickly.

Yuta has expressed interest in having this instruction available.

In /cvs/cds/caltech/scripts/matrix/ there are 4 python scripts:

saveMatrix.py, oldSaveMatrix.py, loadMatrix.py, oldLoadMatrix.py

The saveMatrix.py and loadMatrix.py are for use with the current front end codes (which start counting from 1), where as the old*.py files are for the old system.

To use saveMatrix.py you need to specify the number of inputs, outputs, and the base name of the matrix (i.e. C1:LSP-DOF2PD_MTRX is the base of C1:LSP-DOF2PD_MTRX_0_0_GAIN for example), as well as an ouptut file where the values are stored.

So to save the BS in_matrix setting you could do (from /cvs/cds/caltech/scripts/matrix/)

./saveMatrix.py -i 4 -o 5 -n "C1:SUS-BS_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

The -i 4 indicates 4 inputs, the -o 5 indicates 5 outputs, -n "blah blah" indicates the base channel name, -f indicates a matrix bank of filters (if its just a normal matrix with no filters, drop the -f flag), and -d ./to_coil_mtrx.txt indicates the destination file.

To write the matrix, you do virtually the same thing:

./loadMatrix.py -n "C1:SUS-PRM_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

In this case, you're writing the saved values of the BS, to the PRM.  This method might be faster if you're trying to fill in a bunch of new matrices that are identical rather than typing 1's and -1's 20 times for each matrix.

I'll have Yuta add his how-to of this to the wiki.

  3662   Wed Oct 6 16:16:48 2010 josephb, yutaUpdateCDSc1sus status

At the moment, c1sus and c1mcs on the c1sus machine seem to be dead in the water.  At this point, it is unclear to me why.

Apparently during the 40m meeting, Alex was able to get test points working for the c1mcs model.  He said he "had to slow down mx_stream startup on c1sus".   When we returned at 2pm, things were running fine. 

We began updating all the matrix values on the medm screens.  Somewhere towards the end of this the c1sus model seemed to have crashed, leaving only c1x02 and c1mcs running.  There were no obvious error messages I saw in dmesg and the target/c1sus/logs/log.txt file (although that seems to empty these days).  We quickly saved to burt snap shots, one of c1sus and one of c1mcs and saved them to /opt/rtcds/catlech/c1/target/snapshots directory temporarily.  We then ran the killc1sus script on c1sus, and then after confirming the code was removed, ran the startup script, startc1sus.  The code seemed to come back partly.  It was syncing up and finding the ADC/DAC boards, but not doing any real computations.  The cycle time was reporting reasonably, but the usr time (representing computation done for the model) was 0.  There were no updating monitor channels on the medm screens and filters would not turn on.

At this point I tried bringing down all 3 models, and restarting c1x02, then c1sus and c1mcs.  At this point, both c1sus and c1mcs came back partly, doing no real calculations.  c1x02 appears to be working normally (or at least the two filter banks in that model are showing changing channels from ADCs properly).  I then tried rebooting the c1sus machine.  It came back in the same state, working c1x02, non-calculating c1sus and c1mcs.

  3663   Wed Oct 6 22:46:36 2010 kiwamuUpdateGreen LockingSHG at PSL table

 I put some optics to get the green SHG on the PSL table.

Now a green light successfully comes out from the doubling crystal.

Since the optical layout of the PSL table was dramatically changed, I had to re-setup the green SHG stuff. 

 

 - what I did

I put a steering mirror after the 90/10% pick off mirror, and then a half wave plate and a convex lens.

The lens is approximately on the right place.

 To get the green beam easily, temporarily I raised the current of the NPRO up to 2 A.

I connected the oven to the heat controller, set the temperature to 36.8 deg which is the set point previously used.

After putting and aligning the oven, I finally obtained the green beam.

At the end of the work I set the NPRO current back to 0.9 A and relocked the PMC.

 

- things to be done

 1. more precise mode matching

 2. optimization of the temperature 

  3664   Thu Oct 7 08:39:39 2010 steveBureaucracySAFETYJoonho receives safety training

Our new undergrad Joonho Lee received 40m specific basic safety training yesterday.

Yuta and Joonho are scheduled to participate in the LIGO-laser safety tutelage with Peter K on Oct 12

  3665   Thu Oct 7 10:37:42 2010 josephbUpdateCDSc1sus with flaky ssh

Currently trying to understand why the ssh connections to c1sus  are flaky.  This morning, every time I tried to make the c1sus model on the c1sus machine, the ssh session would be terminated at a random spot midway through the build process.  Eventually restarting c1sus fixed the problem for the moment.

However, previously in the last 48 hours, the c1sus machine had stopped responding to ssh logins while still appearing to be running the front end code.  The next time this occurs, we should attach a monitor and keyboard and see what kind of state the computer is in.  Its interesting to note we didn't have these problems before we switched over to the Gentoo kernel from the real-time linux Centos 5.5 kernel.

  3666   Thu Oct 7 10:48:41 2010 josephb, yutaUpdateCDSc1sus status

This problem has been resolved.

Apparently during one of Alex's debugging sessions, he had commented out the feCode function call on line 1532 of the controller.c file (located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/ directory).

This function is the one that actually calls all the front end specific code and without it, the code just doesn't do any computations.  We had to then rebuild the front end codes with this corrected file.

Quote:

At the moment, c1sus and c1mcs on the c1sus machine seem to be dead in the water.  At this point, it is unclear to me why.

Apparently during the 40m meeting, Alex was able to get test points working for the c1mcs model.  He said he "had to slow down mx_stream startup on c1sus".   When we returned at 2pm, things were running fine. 

We began updating all the matrix values on the medm screens.  Somewhere towards the end of this the c1sus model seemed to have crashed, leaving only c1x02 and c1mcs running.  There were no obvious error messages I saw in dmesg and the target/c1sus/logs/log.txt file (although that seems to empty these days).  We quickly saved to burt snap shots, one of c1sus and one of c1mcs and saved them to /opt/rtcds/catlech/c1/target/snapshots directory temporarily.  We then ran the killc1sus script on c1sus, and then after confirming the code was removed, ran the startup script, startc1sus.  The code seemed to come back partly.  It was syncing up and finding the ADC/DAC boards, but not doing any real computations.  The cycle time was reporting reasonably, but the usr time (representing computation done for the model) was 0.  There were no updating monitor channels on the medm screens and filters would not turn on.

At this point I tried bringing down all 3 models, and restarting c1x02, then c1sus and c1mcs.  At this point, both c1sus and c1mcs came back partly, doing no real calculations.  c1x02 appears to be working normally (or at least the two filter banks in that model are showing changing channels from ADCs properly).  I then tried rebooting the c1sus machine.  It came back in the same state, working c1x02, non-calculating c1sus and c1mcs.

 

  3667   Thu Oct 7 14:39:50 2010 yutaUpdatePSLmeasured PMC's laser power-output relation

(Rana, Yuta)

Motivation:

 We wanted to see thermal effects on the PMC.

What I did yesterday:
 Changed the current of the NPRO from 2A to 0.8A and measured the power of the reflected/transmitted light from the PMC when locked.
 I also measured the power of the reflected light when PMC is not locked (It supposed to be proportional to the output power of the laser).

Result:
 Attached. Hmmmm......
 At several points of the laser current, I could'nt lock the PMC very well. The power of the reflected/transmitted light depend on the offset voltage of the PZT.
 When the laser power was weak(~<0.9A), the power of reflected/transmitted light changed periodically(~ several minutes).

Attachment 1: PMCreflect.png
PMCreflect.png
  3668   Thu Oct 7 14:57:52 2010 josephb, yutaUpdateCDSc1sus status

Around noon, Yuta and I were trying to figure out why we were getting no signal out to the mode cleaner coils.  It turns out the mode cleaner optic control model was not talking to the IOP model. 

Alex and I were working under the incorrect assumption that you could use the same DAC piece in multiple models, and simply use a subset of the channels.  He finally went and asked Rolf, who said that the same DAC simulink piece in different models doesn't work.  You need to use shared memory locations to move the data to the model with the DAC card.  Rolf says there was a discussion (probably a long while back) where it was asked if we needed to support DAC cards in multiple models and the decision was that it was not needed.

Rolf and Alex have said they'd come over and discuss the issue.

In the meantime, I'm moving forward by adding shared memory locations for all the mode cleaner optics to talk to the DAC in the c1sus model.

 

Note by KA: Important fact that is worth remembering

  3669   Thu Oct 7 15:05:46 2010 KojiUpdatePSLmeasured PMC's laser power-output relation

It was a bit difficult to comprehend the result.
Is it good? or bad? Have you seen the thermal effect? or not?

- Put linear lines to show the visibility of the cavity.

- Calibrate the incident power and make another plot to show the visibility (%) vs the incident power (W).

Quote:

(Rana, Yuta)

Motivation:

 We wanted to see thermal effects on the PMC.

What I did yesterday:
 Changed the current of the NPRO from 2A to 0.8A and measured the power of the reflected/transmitted light from the PMC when locked.
 I also measured the power of the reflected light when PMC is not locked (It supposed to be proportional to the output power of the laser).

Result:
 Attached. Hmmmm......
 At several points of the laser current, I could'nt lock the PMC very well. The power of the reflected/transmitted light depend on the offset voltage of the PZT.
 When the laser power was weak(~<0.9A), the power of reflected/transmitted light changed periodically(~ several minutes).

 

  3670   Thu Oct 7 15:21:51 2010 steveUpdatePSLRF filter for PMC

We got two small RF filter for the PMC from Valera  They are made by http://www.larkengineering.com/   "MC35.5-3-AB" sma, 29300-01

Attachment 1: 35.5MHZ.pdf
35.5MHZ.pdf
  3671   Thu Oct 7 16:21:02 2010 KojiOmnistructureCDSBig 3

Both Rolf and Alex (at least his elbow) together visited the 40m to talk with Joe for the CDS.

40m is the true front line of the CDS development!!!

Attachment 1: IMG_3642.jpg
IMG_3642.jpg
  3672   Thu Oct 7 16:34:06 2010 yutaUpdatePSLmeasured PMC's laser power-output relation

Result2:
 Attached is the visibility vs incident power(assuming output of the PD is proportional to the input laser power).
 Ideally, the graph should be flat. (In another words, attached graph in the elog #3667 shoud be linear.)
 But the visibility reduces with higher laser power in this graph. This is maybe because of the thermal effect. I'm thinking about how to confirm this.

 Quote:

It was a bit difficult to comprehend the result.
Is it good? or bad? Have you seen the thermal effect? or not?

- Put linear lines to show the visibility of the cavity.

- Calibrate the incident power and make another plot to show the visibility (%) vs the incident power (W).

Quote:

(Rana, Yuta)

Motivation:

 We wanted to see thermal effects on the PMC.

What I did yesterday:
 Changed the current of the NPRO from 2A to 0.8A and measured the power of the reflected/transmitted light from the PMC when locked.
 I also measured the power of the reflected light when PMC is not locked (It supposed to be proportional to the output power of the laser).

Result:
 Attached. Hmmmm......
 At several points of the laser current, I could'nt lock the PMC very well. The power of the reflected/transmitted light depend on the offset voltage of the PZT.
 When the laser power was weak(~<0.9A), the power of reflected/transmitted light changed periodically(~ several minutes).

 

 

Attachment 1: PMCvis.png
PMCvis.png
  3673   Thu Oct 7 17:19:55 2010 josephb, alex, rolfUpdateCDSc1sus status

As noted by Koji, Alex and Rolf stopped by.

We discussed the feasibility of getting multiple models using the same DAC.  We decided that we infact did need it. (I.e. 8 optics through 3 DACs does not divide nicely), and went about changing the controller.c file so as to gracefully handle that case.  Basically it now writes a 0 to the channel rather than repeating the last output if a particular model goes down that is sharing a DAC.

In a separate issue, we found that when skipping DACs  in a model (say using DACs 1 and 2 only) there was a miscommunication to the IOP, resulting in the wrong DACs getting the data.  the temporary solution is to have all DACs in each model, even if they are not used.  This will eventually be fixed in code.

At this point, we *seem* to be able to control and damp optics.  Look for a elog from Yuta confirming or denying this later tonight (or maybe tomorrow).

 

  3674   Thu Oct 7 17:53:07 2010 yutaUpdateComputersFarfalla with Firefox, fixed

(Kiwamu, Yuta)

Symptom:
 Farfalla(Acer Aspire one KAV60 netbook) couldn't run Firefox and returned the following error:
  Error: platform version '1.9.2.8' is not compatible with
  minVersion >= 1.9.2.9
  maxVersion <= 1.9.2.9

What we did:
1. Added the following line to ~/.cshrc.
  alias firefox "/usr/lib/firefox-3.6/firefox"
2. Made a cool launcher for firefox.

Result:
 Farfalla can fly into the web with Firefox now.

Notes:

 Even if it was then before, bash could run firefox. tsch couldn't.
 The command firefox was /cvs/cds/caltech/apps/linux/bin/firefox for tsch, because of the source /cvs/cds/caltech/cshrc.40m.
 I did this to zita which had the same symptom, too.

Next work:

 Farfalla wakes up on the wrong side of the bed. This has to be fixed.

  3675   Thu Oct 7 23:24:44 2010 yutaUpdateCDSchecking MC1 suspension damping

Background:
 The new CDS is currently being set up.
 We want to see if the damping servo of the suspensions are working correctly.
 But before that, we have to see if the sensors and the coils are working correctly.
 Among the 8 optics, MCs take top priority because of the green beam. for the alignment of the in-vac optics.

What I did:
 By seeing the 5 sensor outputs (C1:SUS-MC1_XXSEN_IN1, XX=UL,UR,LR,LL,SD) with the Data Viewer, I checked if all the coils are kicking in the supposed direction and all the sensors are sensing that kick correctly.

 All the matrices elements were set to the ideal values(-1 or 0 or 1) this time.

Result:
 They were perfect.
1. POSITION seemed to be POSITION
 When the offset(C1:SUS-MC1_SUSPOS_OFFSET) was added, all the sensor output moved to the same direction.
2. PITCH seemed to be PITCH
 When the offset(C1:SUS-MC1_PIT_COMM) was changed, UL&UR and LL&LR went to the different direction.
3. YAW seemed to be YAW
 When the offset(C1:SUS-MC1_YAW_COMM) was changed, UL&LL and UR&LR went to the different direction.
4. SIDE seemed to be SIDE
 When the offset(C1:SUS-MC1_SDSEN_OFFSET) was added, DC level of the SD sensor output changed.

Notes:

 c1mcs crashed many times during the investigation, and I had to kill and restart it again and again.
 It seemed to be easily crashed when filters are on, and so I couldn't check whether the damping servo is working correctly or not today.

Next work:

  - fix c1mcs (and maybe others)
  - check the damping servo by comparing the displacements of each 4 degrees of freedom when servo in off and on.

  3676   Fri Oct 8 07:41:42 2010 steveConfigurationSAFETY2W laser shutter is closed

The 2 W Innolight shutter is closed and enclosure door removed. Beam path blocked. Do not change this condition.

  3677   Fri Oct 8 10:38:03 2010 steveConfigurationSAFETY2W laser shutter is closed

Quote:

The 2 W Innolight shutter is closed and enclosure door removed. Beam path blocked. Do not change this condition.

The PSL output beam guide was upgraded from 2" to 8" OD . It is green ready. Shutter is open.

Attachment 1: P1060905.JPG
P1060905.JPG
Attachment 2: P1060910.JPG
P1060910.JPG
  3678   Fri Oct 8 12:21:11 2010 josephbUpdateCDSchecking MC1 suspension damping

Upon investigation, it appears that the c1mcs model was (and still is) timing out after a random amount of time. Or in other words, it at some point it was taking too long to do all the calculations for a single cycle and falling behind. The evidence for this is from the dmesg command when run on c1sus.

There's a bunch of lines like:

[ 8877.438002] c1mcs: cycle 568 time 62; adcWait 0; write1 0; write2 0; longest write2 0

[ 8877.438002] c1mcs: cycle 569 time 62; adcWait 0; write1 0; write2 0; longest write2 0

With a final line like: [ 8877.439003] c1mcs: ADC TIMEOUT 1 2405 37 2277

This last line indicates in fell so far behind it gave up.

However, this doesn't actually seem to be related to the amount of computation going on with the front end. I restarted the c1mcs model this morning by logging into the c1sus machine, and changing to the /opt/rtcds/caltech/c1/target/c1mcs/bin directory and running:

lsmod

sudo rmmod c1mcsfe

sudo insmod c1mcsfe.ko

The first line just lists the running modules. The second removes the c1mcs module, and the third starts it up again.

I proceeded to turn all the filters and and set all the matrix values while keeping an eye on the C1MCS-GDS_TP.adl screen and its timing indicator. It was running fine with all these turned on. Then I ran a dtt session from rosalba (going to /opt/apps/, typing bash, then source gds-env.bash, and finally diaggui) as well as a dataviewer and looked at 6 test point channels. It received data fine.

However, about 2 minutes after I had stopped doing this (although the dataviewer realtime session was still going) the USR timing jumped from about 20 microseconds to 35 microseconds, and the CPU Max timing jumped to the 50-60 microsecond range. At this point dmesg started reporting things like:

[54143.465613] c1mcs: cycle 1076 time 62; adcWait 0; write1 0; write2 0; longest write2 0

[54143.526004] c1mcs: cycle 2064 time 62; adcWait 0; write1 0; write2 0; longest write2 0

About a minute later the code gave up and reported a ADC timeout via dmesg. None of the other front ends seem to be affected.

I had to clear the test points manually after stopping dataviewer and dtt by going to rosalaba,using the sourced gds-env.bash, and running diag -l. I then typed "tp clear 36 *" to clear all the test points on the model with FEC number 36 (corresponding to c1mcs).

I removed and restarted c1mcs again, trying to turn on a few things at a time and letting it run for a few minutes to see if I could narrow down if its one particular filter perhaps reaching an underflow and starting to bog down the computations. However, after about 45 minutes of this, the model is still running and I've turned all the filters on and have been running about 8 test points with no problem, so the problem is clearly intermittent.

Quote:

Notes:
 c1mcs crashed many times during the investigation, and I had to kill and restart it again and again.
 It seemed to be easily crashed when filters are on, and so I couldn't check whether the damping servo is working correctly or not today.

Next work:

  - fix c1mcs (and maybe others)
  - check the damping servo by comparing the displacements of each 4 degrees of freedom when servo in off and on.

 

  3679   Fri Oct 8 12:29:21 2010 KevinUpdateComputersNew Netgear Switch

I removed some old equipment from the rack outside the control room and stacked them next to the filing cabinets in the control room. I also mounted the new Netgear switch in the rack.

  3680   Fri Oct 8 15:57:32 2010 josephbUpdateCDSc1ioo status

I've been trying to figure out why the c1ioo machine crashes when I try to run the c1ioo front end.

I tried removing some RFM components from the c1ioo model, and then the c1gpt model (Kiwamu's green locking model) as an easier test case.  Both cause the machine to lock up once they start running.  Lastly, I tried running the c1x02 and c1sus models on the c1ioo machine instead of the c1sus machine, after first turning off all models on c1sus.  This led to the same lockup. 

Since those models run fine on the c1sus machine, I could only conclude that a recent change in the fe code generator or the Gentoo kernel and the Sun X4600 computer don't work together at the moment.

After talking to Alex, he got the idea to check if the monitor() and mwait() were supported on the c1ioo machine.  These function calls were added relatively recently, and are   used to poll a memory location to see if something has been written there, and then do something when it is.  Apparently the Sun X4600 computers do not support this call.  Alex has modified the code to not use these functions calls, at least for now.  He'd like to add a check to the code so it does use those calls on machines which have them supported.

After this change, the c1ioo and c1gpt front end codes do in fact run.

ELOG V3.1.3-