40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 225 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  10000   Wed May 28 17:51:48 2014 manasaUpdateLSCX green broadband PD NOT working

Quote:

Grr.  I am very frustrated.  After lunch I redid alignment for both X and Y green systems (Yarm both at the end and on the PSL table, Xarm just on the PSL table).  After that realignment work, I cannot find a beatnote for the Xarm!!! 

At this point, I still hadn't touched anything on the X path (except the PZT input steering mirrors, remotely from the control room).  The beatnote was about the same size as it was on Friday, around -27dBm.  I went onto the PSL table and did the same alignment procedure that I had just done for the Yarm:  Remove the green trans PD and the accompanying lens so that I get far-field spots on the wall, and then steer the PSL green and the X green spots until they are nicely overlapped at both the camera (near-field) and on the wall.  I looked at the DC output of the beat PD, and centered the beam on the diode.  I put back the thorlabs DC transmission PD and the lens, and centered the beam on that.  However, after this work, I cannot find a beatnote for the X arm!  I still see the nice big Ygreen beatnote, and I have the PSL and Xend temperatures where they usually are (  abs(FSS Slow) < 0.1, and X end Slow around 10,090. )  I scanned -10,000 counts, and +5,000 counts from there, and still don't find a beatnote!

I went back inside, and I don't see an RF signal coming into the beatbox from the Xarm.  It's not the cable's fault though, since I then hooked the RF output of the beat PD to a 'scope, and still didn't see any beatnote.  The DC path of the PD is definitely seeing things, because when I switch the 'scope over to the DC output of the Xbeat PD, and I block/unblock the beam, I see the voltage step up and down as expected. 

I have not pulled out the Xgreen broadband PD, but unless someone else has a good idea of what to check, that might be one of the next things to do. 

Ideas of things I could try:

* Put the X broadband PD on the Y beatnote path to see if I see the same Y beatnote (use the port where the Y green trans PD is, since it has the coaligned beams, and a lens).

* Open the PD and see if anything on the RF path is fried.

* Move the Y PD over to the X path, to see if it sees the beatnote.

* ????

I made my attempts trying to figure out what was wrong.

Checking if we are at the right X end laser temperature: 
I aligned the arms and found the Y beatnote.I blocked the light falling on the X beat PD so that the RF analyser was only looking at the output from the Y beat PD. AT the RF analyser, I found the strong Y-PSL beatnote, the X-Y beat note and a weak  X-PSL beatnote. This confirmed that we have the X end laser at the right temperature to be able to detect the beatnote. Unblocking the light on the X beat PD did not bring in any additional peaks. 

Checking the RF cabling from the X beat PD to the beat box:
I swapped the RF cables such that the signal from the Y beat PD output was going to the X input on the beatbox. I could still see the beatnote on the RF analyser. This confirmed that there aren't any broken RF cables along the X path.

Checking X green PSL alignment:
I replaced the X beat PD with the Y beat PD to check if the alignment of X&PSL green are alright. I could find the X beat note this way without any alignment tweaking.

I suspect we probably have some RF component burnt in the X beat PD. Do we have any spares lying around? There is a Koji's box with a PD having the same serial number.

IFO status report for anyone who is looking to do some locking tonight : 
The Y beat PD is back along the Y path and I have confirmed the presence of Y-PSL beat note after replacing the PD.
The X beat PD has been removed and now rests on the electronics bench for checking. 

While aligning the arms today, I noticed that enabling LSC would cause misalignment of the ETMY suspension. I haven't tried to find out what has been causing this. Could be something similar to what was noticed with the ETMX suspension a couple of weeks ago elog9969 

  10001   Wed May 28 19:15:38 2014 KojiUpdateLSCX green broadband PD NOT working

If the PD is the suspect, just pull it from the table and bring it to the PD testing setup.

The transimpedance of the PD should be ~2000 Ohm for both of the RF and DC outputs.

The test setup gives you the systematic opportunity for examination of the signal line.
Check the signal level with the active probe.

Once the broken component is found replace it. You are supposed to have the replacement
components on the blue tower.

  10002   Thu May 29 02:16:02 2014 ericqUpdateLSCHigh Bandwidth power recycled Yarm.

I'll put more detail in the morning, but I was able to get the PRM/ITMY/ETMY coupled cavities locked with 32kHz bandwidth using the AO path. (However, this is a pretty low-finesse situation, since the BS is dumping so much power out of the PRC. Full buildup is only 3 or 4 times the single arm power)

Since our ALS is better than it was a month ago when I last played with this, I was able to hop straight from ALS to REFL11 I on resonance, with the PRY locked on 3f.

Here are some quick OLTF plots I took along the way.

 

 

quickOLTFs.pdf

I'm using this configuration to validate my loop modelling for the full double arm case. Right off the bat, this tells me that the "minus" polarity on the CM servo is the correct one. I didn't use REFLDC at all tonight, but I figure I can check it out by doing the transition backwards, so to speak.

  10003   Thu May 29 08:43:34 2014 manasaUpdatePEMAnt season already in

Ant season has set in. I spotted and killed  a few ants around the optics and the enclosure of the PSL table yesterday. TIme for our pest control crew to get busy!

  10004   Thu May 29 14:40:17 2014 KojiUpdateLSCHigh Bandwidth power recycled Yarm.

Wait. It is not so clear.

Do you mean that the IFO was locked with REFL11I for the first time?

Why is it still in the "low finesse" situation? Is it because of misalignment or the non-zero CARM offset?

  10005   Thu May 29 15:33:55 2014 ericqUpdateLSCHigh Bandwidth power recycled Yarm.

Quote:

Wait. It is not so clear.

Do you mean that the IFO was locked with REFL11I for the first time?

Why is it still in the "low finesse" situation? Is it because of misalignment or the non-zero CARM offset?

Sorry, the X arm is completely misaligned. This is the configuration I first tried in ELOG 9859, that is: a PRM->ITMY recycling cavity and ITMY->ETMY arm cavity. ITMX is completely misaligned, so the BS is dumping much of the recycling cavity light out, which is why I wrote "low finesse." This is the first time I've used REFL11 to control any of our cavities, though.

  10006   Fri Jun 6 14:56:09 2014 ericqUpdateelogAaaaaand we're back!

ELOG is back up and running after last Friday's disk-crash-a-thon. SVN is still a work in progress. Jenne and I are now restarting computers and such.

  10007   Mon Jun 9 09:41:06 2014 steveUpdatesafetysafety training

2014 surf students Nichin and Akhil received 40m specific basic safety training last week.

  10008   Mon Jun 9 09:51:11 2014 Sai AkhilUpdateElectronicsFrequency Error Measurement of UFC-6000 RF Frequency Counter

 Motivation: 

 
To test the precision of Mini-Circuits Model UFC-6000 RF Frequency Counter which will be used for recording the beat note for the Frequency Offset Locking Loop(FOLL).
 
 
Setup:
 
Mini Circuits RF Frequency Counter Model UFC-6000 has three I/O ports:
1)REF IN,2)USB INTERFACE,3)RF IN.
The USB INTERFACE is connected to the PC(Windows/Linux) through a USB cable.
The test RF input from an SRS Function Generator(Model DS 345 with tested precision up to 1mHz)is fed in through RF IN using an SMA cable with an SMA-BNC adaptor to connect to the Function Generator.
The REF IN is open since we want to test the counter.
 
 
What I did:
 
1. First interfaced the counter with the PC with windows OS.
 
2. Installed the user friendly GUI on my Laptop so as to record the data from the counter into a .txt file.
 
3. Gave an RF input through the function generator and recorded the response of the counter for different frequencies ranging from 1MHz to 30MHz.
 
4.Analyzed the collected data by plotting the histograms(attached) in Matlab(script attached in .zip file)
 

What was Expected:
 
The measurement statistics of the instrument would give knowledge about the error and tolerance in the measurement which will be helpful to negotiate the error when the counter is being used in the setup. 
 
 
Results:
 
The obtained plots(for sampling time of 1s) are attached in a figure.
The measurement error of the frequency counter for 1s sampling time is:
 
data file     Frequency       Mean in MHz            Standard Error(+/-)in Hz    
 1MH.txt            1MHz            0.999999846             0.0109
 5MHz.txt          5MHz            5.000000293             0.0134
 10MHz.txt       10MHz         10.00000148              0.0108
 15MHz.txt       15MHz         15.0000018                0.0072
 20MHz.txt       20MHz         20.00000053              0.0259
 30MHz.txt       30MHz         30.00000146              0.0230
 
The measurement error of the UFC-6000 RF Frequency Counter is in the order of 0.01-0.02 Hz. This error varies at different frequencies as inferred from the table.
The error for different sampling times of the FC are also plotted.
 
Plan:
 
To complete interfacing the counter with the Raspberry-pi.
Make this Frequency Counter talk to EPICS through slow channels.
 
 
 
 
 
 
  10010   Mon Jun 9 11:42:00 2014 JenneUpdateCDSComputer status

Current computer status:

All fast machines except c1iscey are up and running. I can't ssh to c1iscey, so I'll need to go down to the end station and have a look-see. On the c1lsc machine, neither the c1oaf nor the c1cal models are running (but for the oaf model, we know that this is because we need to revert the blrms block changes to some earlier version, see Jamie's elog 9911).

Daqd process is running on framebuilder.  However, when I try to open dataviewer, I get the popup error saying "Can't connect to rb", as well as an error in the terminal window that said something like "Error getting chan info".

Slow machines c1psl, c1auxex and c1auxey are not running (can't telnet to them, and white boxes on related medm screens for slow channels).  All other slow machines seem to be running, however nothing has been done to them to point them at the new location of the shared hard drive, so their status isn't ready to green-light yet.


Things that we did on Friday for the fast machines:

The shared hard drive is "physically" on Chiara, at /home/cds/.  Links are in place so that it looks like it's at the same place that it used to be:  /opt/rtcds/...... 

The first nameserver on all of the workstation machines inside of the file /etc/resolv.conf has been changed to be 192.168.113.104, which is Chiara's IP address (it used to be 192.168.113.20, which was linux1).  This change has also been made on the framebuilder, and in the framebuilder's /diskless/root/etc/resolv.conf file, which is what all of the fast front ends look to. 

On the framebuilder, and in the /diskless place for the fast front ends, presumably we must have changed something to point at the new location for the shared drive, but I don't remember how we did that [ERIC, what did we do???]


The slow front ends that we have tried changing have not worked out. 

First, we tried plugging a keyboard and monitor into c1auxey.  When we key the crate to reboot the machine, we get some error message about a "disk A drive error", but then it goes on to prompt pushing F1 for something, and F2 for entering setup.  No matter what we press, nothing happens.  c1auxey is still not running.

We were able to telnet into c1auxex, c1psl, and c1iool0.  On each of those machines, at the prompt, we used the command "bootChange".  This initially gives us a series of:

$ telnet c1susaux
Trying 192.168.113.55...
Connected to c1susaux.
Escape character is '^]'.

c1susaux > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : linux1
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.55:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.20
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1susaux
startup script (s)   : /cvs/cds/caltech/target/c1susaux/startup.cmd
other (o)            :

value = 0 = 0x0
c1susaux >

If we go through that again (it comes up line-by-line, and you must press Enter to go to the next line) and put a period a the end of the Host Name line, and the Host Inet (h) line, they will come up blank the next time around.  So, the next time you run bootChange, you can type "chiara" for the host name, and "192.168.113.104" for the "host inet (h)".  If you run bootChange one more time, you'll see that the new things are in there, so that's good.

However, when we then try to reboot the computer, I think the machines weren't coming back after this point.  (Unfortunately, this is one of those things that I should have elogged back on Friday, since I don't remember precisely).  Certainly whatever the effect was, it wasn't what I wanted, and I left with the machines that I had tried rebooting, not running.

  10011   Mon Jun 9 12:19:17 2014 ericqUpdateCDSComputer status

Quote:

The first nameserver on all of the workstation machines inside of the file /etc/resolv.conf has been changed to be 192.168.113.104, which is Chiara's IP address (it used to be 192.168.113.20, which was linux1).  This change has also been made on the framebuilder, and in the framebuilder's /diskless/root/etc/resolv.conf file, which is what all of the fast front ends look to. 

On the framebuilder, and in the /diskless place for the fast front ends, presumably we must have changed something to point at the new location for the shared drive, but I don't remember how we did that [ERIC, what did we do???]

In all of the fstabs, we're using chiara's IP instead of name, so that if the nameserver part isn't working, we can still get the NFS mounts.

On control room computers, we mount the NFS through /etc/fstab having lines like:

192.168.113.104:/home/cds /cvs/cds nfs rw,bg 0 0
fb:/frames /frames nfs ro,bg 0 0

Then, things like /cvs/cds/foo are locally symlinked to /opt/foo

For the diskless machines, we edited the files in /diskless/root. On FB, /diskless/root/etc/fstab becomes

master:/diskless/root                   /         nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/usr                             /usr      nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                            /home     nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                                    /proc     proc    defaults          0 0
none                                    /var/log        tmpfs   size=100m,rw    0 0
none                                    /var/lib/init.d tmpfs   size=100m,rw    0 0
none                                    /dev/pts        devpts  rw,nosuid,noexec,relatime,gid=5,mode=620        0 0
none                                    /sys            sysfs   defaults        0 0
master:/opt                             /opt      nfs    async,hard,intr,rw,nolock  0 0
192.168.113.104:/home/cds/rtcds         /opt/rtcds      nfs     nolock  0 0
192.168.113.104:/home/cds/rtapps        /opt/rtapps     nfs     nolock  0 0

("master" is defined in /diskless/root/etc/hosts to be 192.168.113.202, which is fb's IP)

and /diskless/root/etc/resolv.conf becomes:

search martian

nameserver 192.168.113.104 #Chiara

 

 

  10013   Mon Jun 9 19:02:34 2014 Evan, EricUpdateComputer Scripts / ProgramsSVN is back

The SVN Apache server was not happy trying to read from /cvs/cds/caltech/svn/; it complains "Value too large for defined data type" when trying to modify certain files.

To remedy this, Eric ran an rsync job to copy over the svn directory to /export/home/svn/, which is directly on nodus rather than on the NFS mount.

Accordingly, I edited the httpd-ssl.conf file in /cvs/cds/caltech/apache/etc/ so that SVNPath points to /export/home/svn. The original config file is preserved as httpd-ssl.conf.old_20140609.

Then I started the Apache server using the instructions on the 40 m wiki (search "Apache"). The SVN now appears to be working fine; you can svn up and svn ci as necessary.

However, this means that we now need to start backing up /export/home/svn/, rather than the NFS-mounted directory.

  10015   Mon Jun 9 22:26:44 2014 rana, zachUpdateCDSSLOW controls recovery

 All of the SLOW computers were in limbo since the fileserver/nameserver change, but me and Zach brought them back.

One of the troubles, was that we were unable to telnet into these computers once they failed to boot (due to not having a connection to their bootserver).

  1. Needed special DB9-RJ45 cable to connect from (old) laptop serial ports to the Motorola VME162 machines (e.g. c1psl, c1iool0, c1aux, etc.); thanks to Dave Barker for sending me the details on how to make these. Tara found 2 of these that Frank or PeterK had left there and saved us a huge hassle. Most new laptops don't have a serial port, but in principle there's a way to do this by using one of our USB-Serial adapters. We didn't try this, but just used an old laptop. The RJ45 connector must go into the top connector of the bottom 4; its labeled as 'console' on some of the VME computers. Thanks to K. Thorne for this very helpful hint and to Rolf for pointing me to KT.
  2. Installed 'minicom' on these machnes to allow communication via the serial port.
  3. Had to install RSH on chiara to allow the VME computers to connect to it. Also added the names of all the slow machines in /etc/hosts.equiv to allow for password-less login. Without this they were not able to load the vxWorks binary. It was tricky to get RSH to work, since its an insecure and deprecated service. 'rsh-server' doesn't work, but installing 'rsh-redone-server' did finally work for passwordless access. Must be that linux1 has RSH enabled, but of course, this was undocumented.
  4. Some of the SLOW machines didn't have their own target names or startup.cmd in their startup boot parameters (???). I fixed these.
  5. For C1VAC1, I have updated the boot parameters via bootChange, but I have not rebooted it. Waiting to do so when Koji and Steve are both around. We should make sure to not forget doing this on C1VAC2. Steve always tells us that it never works, but actually it does. It just crashes every so often.
  6. Leaving C1AUXEX and C1AUXEY for Q and Jacy to do, to see if this ELOG is good enough.
  7. The PSL crate still starts up with a SysFail light turned on red, but that doesn't seem to bother the c1psl operation. We (Steve) should go around and put a label on all the crates where SysFail is lit during 'normal' operation. Misleading warning lights are a bad thing.

We still don't have control completely of the MC Servo board, so we need the morning crew to start checking that out

An example session (using telnet, not the laptop/serial way) where we use bootChange to examine the correct c1aux config:

controls@pianosa|target> telnet c1aux
Trying 192.168.113.61...
Connected to c1aux.martian.
Escape character is '^]'.

c1aux > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : chiara
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.61:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.104
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1aux
startup script (s)   : /cvs/cds/caltech/target/c1aux/startup.cmd
other (o)            :

value = 0 = 0x0
c1aux >

  10016   Mon Jun 9 22:40:36 2014 JenneUpdateCDSFast front end computers up

Rana and I now seem to have the fast front end computers (c1lsc, c1sus, c1ioo, c1iscex and c1iscey) up and running!  Hooray!

It seemed that we needed to change the soft links back to hard links for rtcds and rtapps on the front end machines.  On c1ioo, we did:

cd /opt

sudo rm -rf rtcds

sudo rm -rf rtapps

sudo mkdir rtcds

sudo mkdir rtapps

sudo chown controls:1001 rtcds

sudo chown controls:1001 rtapps

mount /opt/rtcds

mount /opt/rtapps

At this time, the front end fstab had several other options in addition to "nolock" for both rtcds and rtapps.  They had rw,bg,user,nolock.  This state still had some permissions problems.  (Later, we have decided that perhaps our next step was unneccesary, since it still left us with (fewer) permissions problems. Taking out the rw,bg,user options from the front end fstab seems to have fixed all permissions issues, so maybe this next chmod step didn't need to be done.  But it was done, so I record it for completeness).

On chiara, we did:

cd /home/cds/rtcds

sudo chmod -R 777 *

Then on c1iscex, I didn't have to deal with the soft links, but I did need to mount the rtcds and rtapps directories so that I could see files in them.  I just did the last 2 operations from the c1ioo list above (mount /opt/rtcds and mount /opt/rtapps). 

Since we were still seeing some (fewer) permissions problems, we took out the extra options in the front ends' fstab that Rana had added.  Rebooting c1iscex after this, everything came back as expected.  Nice!

I think that, at this point, remotely rebooting (sudo shutdown -r now) the other front ends made everything come back nicely. Since we had gotten the fstab situation correct, we didn't have to by-hand mount any directories, and all of the models restarted on their own.  Finally!

 

 


For posterity, here are things that we'll want to remember:

Frame builder's fstab, in /etc/fstab (only the uncommented lines, since there are lots of comments):

/dev/sdb1               /               ext3            noatime         0 1
/swapfile               none            swap            sw              0 0
shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
/dev/sda1               /frames         ext3    noatime         0 0
192.168.113.104:/home/cds/                      /cvs/cds        nfs     _netdev,auto,rw,bg,soft      0 0
192.168.113.104:/home/cds/rtcds                  /opt/rtcds     nfs     _netdev,auto,rw,bg,soft 0 0
192.168.113.104:/home/cds/rtapps                 /opt/rtapps    nfs     _netdev,auto,rw,bg,soft 0 0

Fast front end fstabs, which are on the framebuilder in /diskless/root/etc/fstab:

master:/diskless/root                   /               nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/usr                             /usr            nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                            /home           nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                                    /proc           proc    defaults          0 0
none                                    /var/log        tmpfs   size=100m,rw    0 0
none                                    /var/lib/init.d tmpfs   size=100m,rw    0 0
none                                    /dev/pts        devpts  rw,nosuid,noexec,relatime,gid=5,mode=620        0 0
none                                    /sys            sysfs   defaults        0 0
master:/opt                             /opt            nfs     async,hard,intr,rw,nolock  0 0
192.168.113.104:/home/cds/rtcds         /opt/rtcds      nfs     nolock                     0 0
192.168.113.104:/home/cds/rtapps        /opt/rtapps     nfs     nolock                     0 0

  10017   Mon Jun 9 23:08:58 2014 JenneUpdateIOOMC board checkout

Rana mentioned this in his elog entry re: SLOW computer recovery, but I want to highlight it:

We cannot yet lock the mode cleaner.

It seems that we need to be aware of the sticky slider issue that we have seen for years (although don't deal with too often) that a burt restore will make it seem like an EPICS channel is at some value, but in fact it is at some other value.  For any sliders or buttons in question, change the value by some amount, and then change it back.  This forces things to refresh, and it'll then be at the value that is reported.

However, for the MC board, this seems to not be enough.  Changing the offset slider doesn't seem to actually change the offset value.  The fast output of the MC board is railed at 9.996 V.  So.  We need to check out the MC servo board and ensure that we are actually connected and talking to it through the c1iool0 (C1i-oh-oh-L-zero, to make the characters more clear) slow machine.

  10018   Tue Jun 10 09:25:29 2014 JamieUpdateCDSComputer status: should not be changing names

I really think it's a bad idea to be making all these names changes.  You're making things much much harder for yourselves.

Instead of repointing everything to a new host, you should have just changed the DNS to point the name "linux1" to the IP address of the new server.  That way you wouldn't need to reconfigure all of the clients.  That's the whole point of  name service: use a name so that you don't need to point to a number.

Also, pointing to an IP address for this stuff is not a good idea.  If the IP address of the server changes, everything will break again.

Just point everything to linux1, and make the DNS entries for linux1 point to the IP address of chiara.  You're doing all this work for nothing!

RXA: Of course, I understand what DNS means. I wanted to make the changes to the startup to remove any misconfigurations or spaghetti mount situations (of which we found many). The way the VME162 are designed, changing the name doesn't make the fix - it uses the number instead. And, of course, the main issue was not the DNS, but just that we had to setup RSH on the new machine. This is all detailed in the ELOG entries we've made, but it might be difficult to understand remotely if you are not familiar with the 40m CDS system.

  10020   Tue Jun 10 12:49:46 2014 AkhilUpdateComputer Scripts / ProgramsInterfacing UFC-6000 with Raspberry Pi completed

 Goal:

 To interface the Mini Circuits RF Frequency Counter(FC) Model UFC-6000 with Raspberry Pi on Linux platform. Also to create a User friendly interface, to control the FC with command lines.

 

Highlights of the Code(script attached):

The  code enables the user to communicate and control different parameters of the UFC like:

1)Frequency Range Selection( for the device to read different frequencies, AutoRange is set by default).

2)Sampling Time (The time intervals for which the data will be retrieved)

3)Read Device Status(Whether the device is reading data or not).

 

Description of the Code:

HID USB Interfacing by sending byte Values.

 

 1)Read The Freq or Range 

Reading the Freq is done by reading the 1st and 2nd LCD of the Frequency counter.

1st line containing Range information, 2nd line is the Frequency result

the code should be send is 2

1st byte: 2

The returned 64 byte array is as follows:

1st byte: 2

2nd byte to Byte17 the ascii value of 16 characters of the 1st LCD line

Byte18 to Byte33  the ascii value of 16 characters of the 2nd LCD line

 

2) Set the Range  

By default Freq Counter is in "AutoRange" mode.

To set the range manually send the code 4

1st byte: 4

2nd byte: the range value. can be any legal range value. for auto range  need to be 255.

the 64 byte array is:

1st byte: 4

 

3)Set the Sample Time   

By default Freq Counter Sample Time is 1 sec.

you can set the sample time from 0.1 sec and up in step of 0.1 sec.To set the Sample Time send the code 3

1st byte: 3

2nd byte: the sample value in sec double 10.

for example: to set the sample time  to 0.4 sec 2nd byte need to be: 4

the 64 byte array is:

1st byte: 3

 

These bytes can be changed by changing the values of buffer[0] and buffer[1]  in function /*Send Report to the device*/ in the main program.

The data is written into a .txt file(example attached) and the user can  control the recording of data. The frequency data can now be made to talk to EPICS through slow channels.

The data from the .txt file can be used for error analysis at different sampling periods.

 

Results:

The interface of the FC with the Pi is now complete.

 

Plan:

 Make this FC talk to EPICS through slow channels.

 

 

 

 

 

 

  10023   Wed Jun 11 08:57:49 2014 SteveUpdatePEM air cond maintenance tomorrow morning

Quote:

  The 4th week of no wet mopping of the floor  and no wet wiping  the vacuum envelope.

 

We cleaned the intakes of the south arm IFO air condition. The bottom duct have quite a bit accumulation Atm1

See wet wiped contrast on Atm2

We found 3 holes around pipes ( coming from CES ) on the east wall that has to be sealed.

After closer examination of these holes, they are sealed off well.

 Air condition maintenance will be finished by 11:30am tomorrow.

 

Yesterday, Kelvin mopped with chemicals the whole floor area of the  lab. This was triggered by some  visiting  ants at our PSL last week. It was 6 months since we had the last fully wet mopped IFO floor.

The cleaning- mopping water became   very dirty at the end.

  10025   Wed Jun 11 14:36:57 2014 JenneUpdateCDSSLOW controls recovery

 

 I have brought back c1auxex and c1auxey.  Hopefully this elog will have some more details to add to Rana's elog 10015, so that in the end, we have the whole process documented.

The old Dell computer was already in a Minicom session, so I didn't have to start that up - hopefully it's just as easy as opening the program.  (Edit, JCD, 9July2014:  Startup a terminal session, and then type "minicom" and press enter to get a Minicom session).

I plugged the DB9-RJ45 cable into the top of the RJ45 jacks on the computers.  Since the aux end station computers hadn't had their bootChanges done yet, the prompt was "VxWorks Boot".  For a computer that was already configured, for example the psl machine, the prompt was "c1psl", the name of the machine.  So, the indication that work needs to be done is either you get the Boot prompt, or the computer starts to hang while it's trying to load the operating system (since it's not where the computer expects it to be).  If the computer is hanging, key the crate again to power cycle it.  When it gets to the countdown that says "press any key to enter manual boot" or something like that, push some key.  This will get you to the "VxWorks Boot" prompt. 

Once you have this prompt, press "?" to get the boot help menu.  Press "p" to print the current boot parameters (the same list of things that you see with the bootChange command when you telnet in).  Press "c" to go line-by-line through the parameters with the option to change parameters.  I discovered that you can just type what you want the parameter to be next to the old value, and that will change the value.  (ex.  "host name   : linux1   chiara"   will change the host name from the old value of linux1 to the new value that you just typed of chiara). 

After changing the appropriate parameters (as with all the other slow computers, just the [host name] and the [host inet] parameters needed changing), key the crate one more time and let it boot.  It should boot successfully, and when it has finished and given you the name for the prompt (ex. c1auxex), you can just pull out the RJ45 end of the cable from the computer, and move on to the next one.

 

  10026   Wed Jun 11 14:41:11 2014 JenneUpdateSUSBurt restored c1scxepics

ETMX had default 1's for gains, 0's for matrix elements, etc., so I did a burt restore to May 25th, 2pm, which was a few days before the Crash.  It looks fine now.

  10027   Wed Jun 11 15:57:18 2014 JenneUpdateCDSNote on cables for talking to slow computers

We have (now) in the lab 2 cables that are RJ45-DB9.  The gray one is LIGO-made, while the blue one is store-bought.  

The gray LIGO-made one works, but the blue store-bought one does not.  I checked their pinouts, and they are completely different.  On the sketch below, the pictures of the connectors is me looking at them face-on, with the cables going out the back of the page.  The DB9 is female. 

06111401.PDF

  10028   Wed Jun 11 16:01:31 2014 SteveUpdateCDSc1Vac1 and c1vac2 rebooted

Quote:

 

 I have brought back c1auxex and c1auxey.  Hopefully this elog will have some more details to add to Rana's elog 10015, so that in the end, we have the whole process documented.

The old Dell computer was already in a Minicom session, so I didn't have to start that up - hopefully it's just as easy as opening the program.

I plugged the DB9-RJ45 cable into the top of the RJ45 jacks on the computers.  Since the aux end station computers hadn't had their bootChanges done yet, the prompt was "VxWorks Boot" (or something like that).  For a computer that was already configured, for example the psl machine, the prompt was "c1psl", the name of the machine.  So, the indication that work needs to be done is either you get the Boot prompt, or the computer starts to hang while it's trying to load the operating system (since it's not where the computer expects it to be).  If the computer is hanging, key the crate again to power cycle it.  When it gets to the countdown that says "press any key to enter manual boot" or something like that, push some key.  This will get you to the "VxWorks Boot" prompt. 

Once you have this prompt, press "?" to get the boot help menu.  Press "p" to print the current boot parameters (the same list of things that you see with the bootChange command when you telnet in).  Press "c" to go line-by-line through the parameters with the option to change parameters.  I discovered that you can just type what you want the parameter to be next to the old value, and that will change the value.  (ex.  "host name   : linux1   chiara"   will change the host name from the old value of linux1 to the new value that you just typed of chiara). 

After changing the appropriate parameters (as with all the other slow computers, just the [host name] and the [host inet] parameters needed changing), key the crate one more time and let it boot.  It should boot successfully, and when it has finished and given you the name for the prompt (ex. c1auxex), you can just pull out the RJ45 end of the cable from the computer, and move on to the next one.

 

 Koji, Jenne and Steve

 

Preparation to reboot:

1, closed VA6, V5 disconnected cable to valves ( closed all annuloses )

2, closed V1, disconnected it and stopped Maglev rotation

3, closed V4, disconnected its cable

   See Atm1,  This set up is insured us so there can not be any accidental valve switching to vent the vacuum envelope if reboot-caos strikes.[moving=disconnected]

4, RESET c1Vac1 and c1Vac2 one by one and together. They both went at once. We did NOT power recycled.

    Jenne entered the new "carma" words on  the old Dell laptop and checked the good answers. The reboot was done.

    Note: c1Vac1 green-RUN indicator LED is yellow. It is fine as yellow.

5, Checked and TOGGLED valve positions to be correct value ( We did not correct the the small turbo pumps monitor positions, but they  were alive )

6,  V4 was reconnected and opened. Maglev was started.

7,  V1 cable reconnected and opened at full rotation speed of 560 Hz

8,  V5 cable reconnected,  valve opened..............VA6 cable connected and opened........

9,   Vacuum Normal valve configuration was reached.

 

  10030   Thu Jun 12 10:41:58 2014 SteveUpdatePSLPMC-T trend of 4 years

Quote:

Quote:

Also, while I was working on the PSL table, I heard noise that sounded like a bearing rolling around.  I suspected the HEPAs, since the one on the north east corner of the table has a problem when it's turned up high (we've known about this for a long time), however turning off the HEPAs didn't affect the noise.  The noise is strongest near the back of the PSL controller on the shelf above the table, and the PSL controller box is vibrating.  So, I suspect that the fan on the PSL controller box is about to give out.

EDIT:  To clarify, I mean the Innolight's controller.

 The bearing is chirping in the back of the 2W Innolight laser controller. It is loud enough to hear it. I placed 4 soft  rubber feet under the controller to avoid shaking other things on self.

The HEPA filter bearing becomes noisy at 50V

 Keep it at 20V for low noise

  The aging of the laser came up when the noisy bearing showed.  ~10% down in in 4 years. That is pretty good.

  10033   Thu Jun 12 15:31:47 2014 JamieUpdateCDSNote on cables for talking to slow computers

Quote:

We have (now) in the lab 2 cables that are RJ45-DB9.  The gray one is LIGO-made, while the blue one is store-bought.  

The gray LIGO-made one works, but the blue store-bought one does not.  I checked their pinouts, and they are completely different.  On the sketch below, the pictures of the connectors is me looking at them face-on, with the cables going out the back of the page.  The DB9 is female. 

 There are RJ45-DB9 adapters in the big spinny rack next to the linux1 rack that are for this exact purpose.  Just use a stanard ethernet cable with them.

  10034   Thu Jun 12 16:56:31 2014 NichinUpdateElectronicsPD Inspection

I and Eric Gustafson inspected the automated PD frequency response measurement system which Alex Cole built last summer. We just lifted the tops off the tables [AS table, POY table and ITMX table] and looked at the alignment checking to see if the correct optical fibers from the fiber splitter were illuminating the correct photodiodes. We did not change anything at all and put the covers back on the tables.

The PDF attached shows the state of each PD fiber pair.  The fibers labeled REFL11 and REFL55 were reversed and illuminating the wrong photodiodes.

We will do a manual measurement of REFL33 tomorrow using the network analyzer and the modulatable laser but not the RF switch.  Afterward we will check to make sure the RF cables are connected to the correct channels of the RF switch according to the switch list (/users/alex.cole/switchList).

  10035   Fri Jun 13 09:20:37 2014 SteveUpdateSUSrestored damping at PRM and ETMY

ETMX medm screen values are blank.

  10036   Fri Jun 13 11:33:55 2014 AkhilUpdateElectronicsCharacterization of UFC-6000 RF Frequency Counter

 Goal:

To characterize the Mini-Circuits RF FC (Model UFC-6000) and plot Bode Plots at varying Modulation frequencies.

Work Done:

Here are the list of measurements(files attached) taken from FC using SRS(Model DS345) Synthesized Function Generator for a Sinusoidal signal at different Modulation Frequencies ranging from 0.01 Hz to 1 KHz:

Carrier Frequency                          Modulation Depth                                                        Attached measurement Folder 

5 MHz                                                     Δ f = 5 MHz                                                                            Bode_5

10 MHz                                                   Δ f = 10 MHz                                                                          Bode_10

20 MHz                                                   Δ f = 20 MHz                                                                           Bode_20 

 

The measured data will be used to estimate:

1) Transfer Function of FC 

2) Quantization noise from Power Spectral Density(PSD) vs Hz

 

To Do Next:

1)Complete interfacing the Pi with EPICS.

2)Make bode plots (Matlab script attached) and PSD plots and estimate the control parameters for optimal design of FOLL PID loop.

 

 

  10037   Fri Jun 13 18:16:00 2014 NichinUpdateElectronicsChanges to the PD frequency response measurement system

 

As we had planned yesterday (ELOG 10034) I and Eric Gustafson wanted to manually measure the transimpedence for REFL33. But on closer inspection I found the RF signal cable coming from the Photodiode REF DET (mounted on the POY table), that we were supposed to plug into the network analyzer, did not have an SMA connector at the end. There was just the Teflon and metal part sticking out of the insulation. So we disconnected the cable labeled REF DET from the PD and pulled it out to fix it. (POY table and from near the 1Y1 rack)

 

 

Being unable to locate any SMA male connectors in the 40m lab [pasternack PE4025], we headed over to Downs where Rich Abbott did a quick and awesome job of soldering the SMA connector and also teaching me in the process. I will write an ELOG on how to do a clean solder of the SMA connectors to the RF cable shortly for future reference.

 

 

Coming back to the 40m we rerouted the REF DET cable from near the 1Y1 rack and into the POY table. This job was done mostly by Eric. We were also unable to locate a torque wrench to tighten the cable at the PD’s end and had to leave it finger tight. Eric is planning to buy a new torque wrench as we will need it often.

 

 

Also, I cross checked the SwithList located at /users/alex.cole/switchList with the RF switch connections at 1Y1 rack and turns out it is consistent, except that at CH2 of the first switch where MC REFL was to be connected, there is a unlabeled cable. It might belong to the correct PD, but must be made sure of. The rest of the channels that are not mentioned in the list were unconnected on the RF switch.

 

Now instead of disconnecting REFL 33 to make measurements with the NA, we had to take out AS55 from the RF switch, as the former was very hard to remove without the torque wrench. Then Eric removed the optical fiber which was illuminating the AS55 (AS table) from its mount to hook it up to the power meter. But then we were not sure of how to operate the Laser diode controller (LDC 3744C) and decided to leave stuff as it is and continue either tomorrow or on Monday. Right now we closed the optical fiber of AS55 with a cap and it remains unmounted. The RF cables of REF DET and AS55 were left hanging near the 1Y1 rack.

  10038   Fri Jun 13 19:09:44 2014 KojiUpdateIOOA blown fuse found on the euro card crate at 1X2 (IOO) rack.

[Rana Zach Koji]

We tracked down the MC locking issue to be associated with the power supply problem.
Replacing a fuse which had incomplete connection with the new one, the MC started locking.

We still have the MC autolocker not running correctly. This is solely a software problem.


We went down to the IOO electronics rack to investigate the electronics there. After spending
some time to poking around the test points of the MC servo board, we noticed that the -24V
power indicator on the MC demodulator module was not lit. In fact, Steve mentioned on Wednesday
that the -24V Sorensen supply had lower current than nominal. This actually was a good catch
but should have been written in the ELOG!!!

We traced the power supply wires for the crate and found one of the three -24V supply has no
voltage on it. Inspection of the corresponding fuse revealed that it had a peculiar failure mode.
The blown LED was not lit. The connection was not reliable and the -24V power supply was flickering.

We then replaced the fuse.This simply solved all of the issues on the MC servo board. The electronics
should be throughly inspected if it still has the nominal performance or not, as the boards were exposed
to the single supply more than a week. But we decided to try locking ability first of all.

Yes, we now can lock the MC as usual.

Now the newly revealed issue is MC autolocker. It was running on op340m but op340m does not want to run it now.
It should be closely investigated.

Also turning on WFS unlocks the MC. Currently the WFS outputs are turned off.
We need usual align MC / check spot position / adjust WFS QPD spots combo.

  10039   Sat Jun 14 18:43:15 2014 ranaUpdateIOOMC Autolocker upgrades

 Somehow the caget/caput commands are really slow. I'm not sure if this is new behavior or not, but after changing values, it takes ~1-2 seconds to move on to the next command.

On op340m, once I ran autolockMCmain40m in the foreground, I could see that there were a lot of error messages that weren't being caught in the log file. On Solaris, the TDS and EZCA binaries work well, but the caget/pu stuff is missing a lot of the new flags and the new CDSUTILS python scripts are not there. So I decided to stop running on there and move over to running the MC autolocker on megatron. I also changes the mcup and mcdown scripts to BASH from CSH. There are still some PERL commands in there from Rob/Matt/Sam, so I also added the proper commands so that the pick up the scripts/general/perlmodules/ directory.

Yes, yes, I know. You would all feel warm in your tummy if we did everything in python because its the best language ever, but how about we lock the interferometer first and then we can rewrite all the last decades worth of scripts?

Looked at the trend from the last time the MCWFS were one (2 weeks ago!) and aligned the MC suspension back to that point. After that the WFS come on fine and MC looks good. I fixed the nameserver/DNS/fstab stuff on megatron, asia, and belladonna.

I've left AutoLockMC.csh (too painful to convert to BASH) running on megatron via an open terminal on pianosa. If it looks OK for the weekend, Q should move the crontab line from op340m over to megatron and then update the Wiki appropriately.

CDSUTILS is also gone from the path on all the workstations, so we need Jamie to tell us by ELOG how to set it up, or else we have to use ezcaread / ezcawrite forever.

  10045   Mon Jun 16 21:22:16 2014 JenneUpdateComputer Scripts / ProgramsRossa having a bad day

[Jenne, Rana]

Today, Rossa has been hanging at bootup.  You get the desktop, and most of the gui things, and can move the mouse pointer around, but clicking the mouse or using the keyboard have no effect.  Once you try clicking something, the mouse pointer turns into the spinning ball, and stays like that.

If, upon rebooting (soft rebooting from another machine, through an ssh session), you hold down the Shift key, you should get to a Grub menu.  If you arrow-key down and select the next-most-recent version (not the recovery mode, but just the regular earlier version), and press Enter, Rossa starts up nice and happily.

I am not sure how to make Rossa always boot into this version of things, or how to get rid of the newest version so that the version that works is the most recent, but I'm hoping one of my Linux buddies will help me out on this one.  I think (maybe) that I need to find out what package was recently updated and could have caused problems, and then revert that one package.  (I think I can look at tail /var/log/apt/history.log to tell me what has recently been updated).

  10046   Mon Jun 16 21:56:53 2014 JenneUpdateComputer Scripts / Programsfstab updates, MC autolocker running, FSS slow loop alive

[Rana, Jenne]

Mc autolocker:

MC autolocker is running.  The trouble was with caput and caget and cavput on Pianosa.  Rana has switched those lines in mcup and mcdown over to ezcaread and ezcawrites, and that seems to have fixed things. For the MC2tickleON and -OFF scripts, we left the caput and caget and cavput, and saw that they do run successfully on Ottavia.  (We tried testing again on Pianosa, and now it seems to be okay with cavput, but we promise it was hanging up on this earlier this evening.)  Anyhow, it's all a bit confusing, but it seems to be running fine now.

The autolocker is now running on Ottavia, and Rana is putting it into Ottavia's cronjob list, and commented it out on op340m.

 

fstab changes:

We have removed the option "all_squash" from /etc/exports on Chiara (both lines).  We then checked that the files have ownership "controls controls" on Chiara, Pianosa and Rossa.  Ottavia still has ownership of "nobody nogroup", so we still need to figure that out. 

 

FSS slow loop:

We confirmed that the slow loop is running.  Also, since caput and caget seem to take a while, and the real PID integral gain is the value that we set times a sampling rate, the effective gain had changed.  So, Rana compensated by changing C1:PSL-FSS_SLOWKI from 0.03 to 0.1. 

 

Other thoughts:

Do we have an autoburt saver on another computer, in addition to op340m?  (It's in the op340m crontab list)  We really only want one of these at a time.

 

  10047   Mon Jun 16 23:15:44 2014 JenneUpdateLSCIFO alignment recovery

I noticed today, and Rana said that he saw Saturday, that the MC refl value when the MC is unlocked is unusually high.  It typically goes to about 4.5 V, but now is going up to 6.5V.  Since the PMC output is the same as usual (max seen has been about 0.82 today), something must have happened between the PMC and the IMC. 

Late last week, EricG and Nichin were looking at things on the AS table.  Was anything touched on the AS table?  Was anything touched on the PSL table?  'Fess up please, so that we can pinpoint what the change was.

 

Also, this afternoon, I touched up the MC alignment a bit, although it still needs work (I've asked Manasa to look at it tomorrow).  Rana centered the WFS to my MC alignment (this will need to be redone after the MC is truely aligned), and we turned the WFS on.  I also locked both arms individually, and locked MICH and PRMI sideband.  The PRMI wasn't especially stable unless I turned on the POP ASC.  I assume (hope) that this is just because I was doing it during the day, and not because there is something actually different about the PRMI since the computer meltdown.

 

Rana and I also took some notes on things that need to be done, starting tomorrow (the first line and the yellow line are scribbles):

Note_061614_230723_0.jpg

  10048   Tue Jun 17 12:04:40 2014 manasaUpdateComputer Scripts / ProgramsMC autolocker NOT running, FB needs some attention

MC autolocker and Ottavia

I assume that the MC was left with a fully functioning autolocker enabled and running on ottavia last night.

But as of this morning, the MC autolocker is NOT running alright. The MC was in an unlocked state and the autolocker has been doing nothing to the servo sliders.  I think this was the state of MC since last night as seen on the stripchart.

Since the autolocker has been left to run on ottavia, I tried to look at the cronlogs to see if it running the autolocker script at all. I looked at the list on ottavia and it has the MCautlocker on it cronjobs list and yet doing nothing.

Later, I did a softreboot on ottavia when I could not ssh into it from rossa or pianosa. ssh to ottavia now works just fine.

I am leaving Ottavia at this and returning to the more important job of fixing the MC. I locked the MC manually and am now working on the alignment.

 

Framebuilder

Also, the CDS FE status screen had red lights blinking as if it required an 'mxstream restart'. I did the same and it did not fix the problem. So I tried to restart fb using the usual 'telnet fb 8087'; but could not restart fb that way.

Attached: FE status screen

  10049   Tue Jun 17 16:52:40 2014 ericqUpdateComputer Scripts / Programsautolocker confusion

Quote:

the MC autolocker is NOT running alright.

I'm kind of confused by the current auto locker situation. Somebody renamed the script from autolockMCmain40m to AutoLockMC.csh and did not update the crontab with the new filename. 

Furthermore it doesn't seem like  scripto_cron,a script which keeps the auto locker alive, runs ok on ottavia. When I run this on the command line, it claims that the process is already running, and returns some bunk PID that doesn't correspond to any running process. The script has a line stating setenv OSTYPE solaris , so maybe there's something funky going on with it's pgrep-ing or other command parsing.   

Lastly, if I try running AutoLockMC.csh directly on ottavia, I get a bunch of complaints about pmath and pezcabit not being found. 

  10050   Tue Jun 17 17:04:26 2014 ericqUpdateComputer Scripts / ProgramsFB troubles

Quote:

Also, the CDS FE status screen had red lights blinking as if it required an 'mxstream restart'. I did the same and it did not fix the problem. So I tried to restart fb using the usual 'telnet fb 8087'; but could not restart fb that way.

 FB is acting strange. When ssh-ing in, certain commands cause an inescapable hang, which can't be ctrl-c'd out of. Telling it to reboot does nothing. This kind of situation was seen by me before, when we were getting all the front ends back, I eventually hard rebooted it, hoping it was a one time thing. Guess it's not. 

Looking at the dmesg output, daqd seems to be segfault-ing all over the place. This may be related... Here are some examples:

451314.730502] daqd[17339]: segfault at 7ff589ae3b30 ip 00007ff589ae3b30 sp 00007ff49931dfb8 error 15 in libmyriexpress.so[7ff589ae3000+1000]

[530516.313238] daqd[18442] general protection ip:7f3f2ce73a6c sp:7f3e29949d50 error:0

[530516.313250] daqd[18420] general protection ip:7f3f2ce73a6c sp:7f3e2a19fd50 error:0 in libc-2.10.1.so[7f3f2ce3f000+14c000]

[530516.313262]  in libc-2.10.1.so[7f3f2ce3f000+14c000]

[530516.327083] daqd[18412]: segfault at 3b04c9cd0 ip 00007f3f2ce73a6c sp 00007f3e2a4a7d50 error 4 in libc-2.10.1.so[7f3f2ce3f000+14c000]

[537695.364481] daqd[18489]: segfault at 12dbbcae0 ip 00007fa35a3b8a0a sp 00007fa298381af0 error 6 in libmyriexpress.so[7fa35a399000+28000]

[577316.821618] daqd[18758]: segfault at 7f5c4d3e9b30 ip 00007f5c4d3e9b30 sp 00007f5b5cc23fb8 error 15 in libmyriexpress.so[7f5c4d3e9000+1000]

I'm not inclined to go reboot it right now, but not sure how to address these problems...

 

 

  10051   Tue Jun 17 17:14:14 2014 ManasaUpdateLSCIFO alignment recovery

 1. Recovered MC alignment and locked it manually after the ottavia cron failed to help.

2. Measured the MC spots and could not get the MC spots better looking than this.

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[1.6609930611758554, -1.4655939584833202, 1.3133188677545831, -1.9483764375494121, -1.6539541350121174, -0.8862744551298497]

3. Realigned the beams to the MC WFS and enabled WFS servo.

MC Trans SUM is ~17000 counts and MC REFL is ~0.5 counts.

To-do list

MC spots

MC WFS

IOO QPDS center

BBPD char

Recover REFL 33

MC REFL

MC autolocker cron

  10052   Tue Jun 17 19:39:29 2014 ranaUpdateComputer Scripts / Programsautolocker confusion

I renamed the Autolocker and described it in the elog from this weekend. To run it, you have to run it from the scripts/MC/ directory (as always). I restarted the autolocker on Ottavia with nohup.

> nohup ./AutoLockMC.csh &

To figure out how to get cron to run it, we will have to debug the difference between linux and solaris pgrep, so that's in progress.

  10053   Tue Jun 17 21:49:13 2014 JenneUpdateLSCIFO alignment recovery

PRMI locking with REFL33 is fine.  As it was yesterday, it's a little wobbly without the ASC (just PRM oplev), but I don't know that it's any different than it used to be.  It'll hold for long periods of time, so I feel okay about it. 

When the PRMI is locked, you can push the "up" button on the ASC screen, and it'll turn down the PRM oplev gain by a large factor, and engage the ASC.  When you lose lock, press the "down" button to undo these changes.  (Probably the ifoconfig script should include the ASC down script).  These up and down scripts for the ASC are already included in the carm_up script (the ASC up), and the watch scripts which run a down script (including ASC down) for the whole IFO when ALS loses lock.  If the ASC is engaged, I get bored of watching it before the PRMi loses lock on its own, so I think it's okay.  (Let's say that means I've watched it stay locked for at least a few tens of seconds, but it looks like it always has with the ASC - like it'll stay forever).

The only thing that seems different about the PRMI is that I've increased the PRCL gain from -0.02 to -0.04.  This is a value that it was at some weeks ago, and then we turned it down for loop osc reasons, but now it doesn't want to catch lock with the lower value, and if I turn it down after it's locked, it has trouble holding on.  I have included this change into the PRMI sideband configure script.

I haven't tried anything creative like locking with REFL 165.  I also didn't lock with 11 or 55, since 33 just worked.

  10054   Wed Jun 18 11:28:19 2014 ManasaUpdateComputer Scripts / Programsautolocker confusion

Quote:

I renamed the Autolocker and described it in the elog from this weekend. To run it, you have to run it from the scripts/MC/ directory (as always). I restarted the autolocker on Ottavia with nohup.

> nohup ./AutoLockMC.csh &

To figure out how to get cron to run it, we will have to debug the difference between linux and solaris pgrep, so that's in progress.

I am NOT convinced that the autolocker script is running or doing anything. The MC was unlocked as of this morning and the autolocker wasn't doing anything to any of the MC servo buttons and sliders. The autolocker control shows that it is 'alive' but it still blinks 'MC down' even after I locked the MC manually. I am suspecting that this might have to do something with the caget and caput in autolock script itself rather than the CRON. I will look into this problem later today.

Moral of the story: The autolocker is not doing its job.

  10055   Wed Jun 18 11:57:44 2014 not JenneUpdateLSCIFO alignment recovery

Quote:

I noticed today, and Rana said that he saw Saturday, that the MC refl value when the MC is unlocked is unusually high.  It typically goes to about 4.5 V, but now is going up to 6.5V.  Since the PMC output is the same as usual (max seen has been about 0.82 today), something must have happened between the PMC and the IMC. 

Late last week, EricG and Nichin were looking at things on the AS table.  Was anything touched on the AS table?  Was anything touched on the PSL table?  'Fess up please, so that we can pinpoint what the change was.

 

 Nope, we did not touch any of the PDs other than AS55. I have mentioned in  my elog:10037 what we did exactly.

We just looked at all the other PDs to check if they were being illuminated by the correctly labeled fiber. Nothing other than that.

  10056   Wed Jun 18 13:29:48 2014 ranaUpdateComputer Scripts / Programsautolocker confusion

 

 Moral is wrong.

AutoLocker was working fine last night and we observed it to run and do the appropriate mcdown and mcup stuff. Probably something is breaking with it after several hours.

If you have suspicions about the script, best to look through the logs during the first few hours when we had it running yesterday.

  10057   Wed Jun 18 13:39:01 2014 ranaUpdateCDScdsutils reverted to version 238

 

 After some email consult with Jamie, I got cdsutils working again by reverting to v238. The newest versions are not compatible with our python 2.6 on Ubuntu 10. And our Ubuntu 12 machines do not have NDS2 clients that work yet.

The read/write commands work at the moment, but the NDS based ones don't yet work on pianosa due to some NDSSERVER flag/setup issue maybe, Jamie ??

controls@pianosa|~ > z

usage: cdsutils <cmd> <args>

Advanced LIGO Control Room Utilites

Available commands:

    read         read EPICS channel value

  write        write EPICS channel value

  switch       switch buttons in standard LIGO filter module

  avg          average one or more NDS channels for a specified amount of seconds

  servo        servos channel with a simple integrator (pole at zero)

  trigservo    servos channel with a simple integrator (pole at zero)


  version      print version info and exit

  help         this help


Add '-h' after individual commands for command help.

controls@pianosa|~ > z read C1:LSC-DARM_GAIN

0.0

controls@pianosa|~ 2> z avg 3 C1:IOO-MC_F

Error in write(): Connection refused

Error in write(): Connection refused

NDSSERVER variable incorrectly defined, or no NDS servers available.

controls@pianosa|~ 1> echo $NDSSERVER

fb

  10058   Wed Jun 18 15:25:06 2014 NichinUpdateElectronicsBBPD Transimepedence plot

 Motivation:

To measure the transimpedence of  the Broadband photodiode (D1002969-v8), using a New focus photodiode (1611) as reference. The amplitude modulated Jenne Laser (1.2mW) was used @20mA

The steps involved in getting the transimpedence:

Acquiring data

  • The following conditions were set on Network Analyzer Agilent 4395:

1) Frequency sweep range: 500KHz to 300 MHz.

2) Number of Points sampled in  the range: 301

3) Type of sweep: Logarithmic

  • Set the NA to give the corresponding transfer function value (output of BBPD over output of 1611) and also Phase response in degrees.
  • Save the data into floppy disk for processing on the computer.

Plotting

  • The matlab code attached (Trans_plot.m) will then give plots for the absolute values of transimpedence in V/A.
  • Logic involved in the code will be presented clearly in a separate Elog. 

 Results

The Plots of transimpedence obtained are attached. The data and matlab code used is in the zip file.

The transimpedence of  Broadband photodiode (D1002969-v8) was around 1200 - 1300 V/A for most of the range (2), but the value started falling as the frequency approached 200 MHz. 

  10059   Wed Jun 18 16:44:55 2014 ManasaUpdateElectronicsBBPD installed for BEATX detection

This BBPD is the spare that we pulled out and is installed for ALSX-PSL beat note detection.

  10060   Wed Jun 18 17:38:14 2014 JenneUpdateComputer Scripts / Programsautolocker running again

The MC autolocker is once again running on Ottavia, with the nohup command.  

It was hanging for a long time (at least minutes) on the cavput and the caputs in the MC2 tickle on and off scripts.  I claim that there isn't a good reason to not just use ezcawrite, or whatever the latest and greatest fully functioning function is, so I've changed the cavput to a series of ezcawrites, and all of the caputs are also ezcawrites.  Now I don't see any hanging, and the MC locks itself.

This does not solve the scripto_cron issue, so if Ottavia is rebooted, or the autolocker is otherwise killed, it will not start itself up. 

  10061   Wed Jun 18 18:00:36 2014 ericqUpdateComputer Scripts / Programscontrol room bashrc change

Some time ago, Rana changed the PS1 prompt codes on the control room computers. However, the exit codes of commands weren't being displayed, and there was some lingering color changing after the line. Hence, I changed it to look like this:

PS1='\[\033[0;35m\]\u'
PS1="$PS1\[\033[0;30m\]@"
PS1="$PS1\[\033[0;33m\]\h"
PS1="$PS1\[\033[0;97m\]|"
PS1="$PS1\[\033[0;92m\]\W"                                                 
PS1="$PS1\[\033[0;31m\] \${?##0}"
PS1="$PS1\[\033[0;97m\]>\[\033[0m\] "

The \${?##0} means: display the exit code if it is not zero (which means success). Thus, it only displays the exit code when its something other than what is expected.

  10062   Wed Jun 18 18:16:26 2014 NichinUpdateElectronicsChanges to the PD frequency response measurement system

[Nichin, Eric G, Koji]

Continuing out work from elog:10037, we wanted to check if the frequency response of AS55. Having figured out exactly how to use the Laser diode controller (LDC 3744C), we hooked up a fiber power meter to the optical fiber illuminating AS55 (that we disconnected from its mount last Friday ) and raised up the current to 150mA to get almost 0.8mW power reading.

When aligning the fiber to illuminate the PD, we found that the beam was pretty wide. So we pulled out the collimator and tweaked it to get a focused beam. The fiber was mounted back and was aligned to get a maximum DC reading. The multimeter readout 30mV finally. Taking the transimpedence as 200ohm approx., the hot current is about 1.5mA.

Network analyzer was now connected to the modulation input of the laser and the RF output from REF DET and AS55 (inputs to RF switch at rack 1Y1) were connected as input to measure the transfer function. We got just noise on the scope of NA. So, then we tried REFL33 as the Input and still got nothing (We were also not sure if this PD was properly illuminated, we did not check). However the REF DET was giving a nice response on the scope. Turns out all the PDs were disconnected form the Demodulator (D990511) on rack 1Y2.

On closer inspection the RF cable between domodulator and RF switch that was labelled AS55 had a loose SMA connector at the switch end. I will have to fix that tomorrow . For the time being Koji connected the cable labelled REFL33 to the AS55 demodulator and we finally got a response form the AS55 PD on the NA. However no readings were recorded. The power supply to REF DET was turned off in the end as Eric G claimed that it has been ON for almost a year now, which is not a good thing. Also, we removed the modulation input from NA to the diode laser and terminated the input with a 50ohm terminator.

We planned to pull out and check each and every RF cable (especially the SMA ends for faulty soldering and loose connections) and fix/ replace them as needed.

  10063   Wed Jun 18 19:30:28 2014 JenneUpdateComputer Scripts / ProgramsRossa having a better day

I have modified the /etc/default/grub file, so that we're loading up the previous linux kernel version on reboot.  Now Rossa boots up (at least one time so far) without any fancy button-pushing.

(Note, if things go south again, we have to push "shift" starting after the Dell screen is gone.  Holding it down while the Dell screen is still up doesn't seem to make it register that you want the grub menu).

The grub file USED to look like:

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

but now it looks like:

GRUB_DEFAULT=2
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Note that the first line, GRUB_DEFAULT has changed from 0 (first item in grub menu, if you successfully hit shift and get to it) to 2 (the third item in the list).  I think that the GRUB_HIDDEN_TIMEOUT_QUIET=false is supposed to force it to show the countdown time when you can push shift, but I didn't see any difference there.

To edit this file, you must use "sudo [text editor] grub".  I like emacs, so I used "sudo emacs grub".  After an edit, before a reboot, you must run "sudo update-grub".  Then you can reboot (sudo shutdown -r now is what I use), and hopefully it will boot as you directed.

Right now, the 0th (first) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic".  The 2nd (third) entry is "Ubuntu, with Linux 2.6.32-58-generic".  If we install a new kernel version, the 61 version will bump down in the list, and we'll be booting that, which I assume will fail.  We should not update Rossa until we're ready to go to Ubuntu 12, and when we do, we must ensure that the grub file first line reads GRUB_DEFAULT=0.  (As a side note, the 1st (really 2nd) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic (recovery mode)", which we don't want.  The 58 version has a recovery mode as the next line item, since it alternates version-N, version-N recovery mode, version-(N-1), version-(N-1) recovery mode, etc.)

  10064   Wed Jun 18 21:37:11 2014 KojiUpdateIOOMC REFL investigation

[Jenne Koji]

We decided to check the situation of the REFL MC beam path.

- No resolution of the weird MC REFL DC increase
- The reflection from the PD was adjusted to hit the beam dump
- The MC WFS paths were aligned again


Detail:

We found that the reflected beam from the PD was hitting the mount of the beam dump.
So the entire MC REFL path was steered down such that the last steering mirror does not neet to steer the beam.
When the alignment was adjusted so that the reflection from PD hit the beam dump, the beam spot on the small mirror right before the PD
got a bit marginal but it seemed still OK after some tweak.

Then we looked at the reflection value. It is still about 6.5. No change.

As we messed up the entire MC REFL path, we aligned the MC WFS paths again.
This was done with the unlocked MC REFL beam. Once the cavity was locked,
it turned out that it was enough for the WFS too keep the MC locked.

ELOG V3.1.3-