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.

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.

 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

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

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. 

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

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

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

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

To do this better:

1) Just step the analog input to the AOM (i.e. no RF switch) and measure the PMC trans output with a fast DC coupled PD. IMC should be unlocked and disable during this part. We want the PMC ringdown to be faster than 1 us.

2) Re-install a fast PD in the MC trans path without disrupting the existing MC trans QPD setup.

3) Measure IMC ringdown and fit the data to find the cavity losses.

4) Think about how to use the Isogai, et. al (2013) technique to better measure the losses, taking into account the mirror transmissions.

A recap of the ringdown measurements made at the 40m in mid 2012, the hardware that was installed for the same and results from the measurements.

IMC ringdown:

Hardware installed 
A trans PD was installed (elog 7122).
This PD does not exist in the trans path anymore.

Measurements
The polarity in the MC servo was flipped with the MC WFS disabled and the PD trans signal was used to look at the cavity ringdown. 
Ringdown time = 13 us
Cavity finesse from the measurement = 453 (inconsistent with actual finesse). 

Attachment: Ringdown measurement and fits

PMC ringdown:

Hardware installed
The AOM was installed before the PMC. The AOM was driven by the driver installed on the PSL table. (RF power ~1.5W @ 80MHz @1.0V modulation input). An RF switch was installed to control the AOM driver input. ZASWA-2-50DR+ was installed.
Note: The AOM was used by the ISS crew after this. So the RF switch has been removed and the AOM is no more a part of the ringdown setup.

Measurements
No measurements were made as we could not obtain relevant TTL signals to control the switch remotely.

 I also still think it's a bad idea for everything to be mounting /home/cds from an IP address.  Just make a new DNS entry for linux1 and leave everything as it was.

It's in the elog already: http://nodus.ligo.caltech.edu:8080/40m/9922

But it seems like things still haven't fully recovered, or have recovered to an old state?  Why is the cdsutils install I previously did in /ligo/apps now missing?  It seems like other directories are missing as well.

There's also a user:group issue with the /home/cds mounts.  Everything in those mount points is owned nobody:nogroup.

I also can't log into pianosa and rosalba.

 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.

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

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.

 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.

ETMX medm screen values are blank.

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

 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.

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

I have been looking into the DokuWiki situation, with no great progress so far.

The problem is with authentication. When you try to access the wiki, you get: "User authentication is temporarily unavailable. If this situation persists, please inform your Wiki Admin."

 As Evan points out, this goes away if you turn off ACL (Access Control Lists), but---as he also mentions---that just means that authentication is disabled, so the wiki becomes open. All signs point to this being a problem with the authentication mechanism. We use the 'authplain' plaintext method, where the usernames and hashed passwords are stored in a plaintext file.

Evan and I have both done plenty of testing with the config settings to see if the problem goes away. Even if you restore everything to default (but enable ACL using authplain and the existing user file), you still get an error.

I went as far as installing a brand new wiki on the web server, and, surprisingly, this also exhibits the problem. Interestingly, if I install an old enough version (2012-10-13), it works fine. After this revision, they transitioned their authentication methods from "backends" to "plugins", so this is a clue. As a side note, the other wikis on nodus (ATF and Cryo) are running earlier versions of DokuWiki, so they have no problems.

As it stood, our options were:

1. No wiki (not even read-only, since the issue prevents logging in and also prevents anonymous reading, somehow)
2. No ACL = open wiki. Also not good.

So, I created a temporary read-only version of the wiki using the aforementioned earlier DokuWiki release. It has a soft link to the real wiki data, but I deleted the user database so no one can log in and edit (I also disabled registration). It can be found at https://nodus.ligo.caltech.edu:30889/wiki_ro/.

I also created a backup of the real wiki as wiki_bak to avoid any potential disasters.

The simplest thing to do would be to just roll the wiki back to this working version, but that doesn't sound so smart. Clearly, it was working with the plugin structure before our snafu, and somehow our fixing everything else has broken it.

 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.

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. 

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.

 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.

I went into local.php and changed $conf['useacl'] = 1; to $conf['useacl'] = 0; and it looks like the auth issue goes away (I've changed it back). This isn't a fix (we want to use access control), but it gives us a clue as to where the problem is.

 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.

It looks like auth is broken on the AIC wiki (though working fine on ATF and Cryo). I did some poking around but can't see how anything we did could have broken it.

As of this writing, the DokuWiki appears to be working.

As you and I suspected, it looks like this was a clusterwhoops with the permissions for the NFS mount. Let's recap what happened in the past 24 hours:

1. Yesterday, 8 PM: I restart the Apache server, thereby resurrecting the SVN (now conveniently located at /export/home/svn). The DokuWikis remain borked.
2. Yesterday, 7 to 11 PM: Zach, Rana, and Jenne perform deep magic to get the front-end machines up and running again. This should be irrelevant for this Apache/SVN/DokuWiki witchcraft.
3. Today, morning: the townsfolk happily resume their svn up and svn ci festival.
4. Today, ca. 3 PM: Zach runs stopapache.sh to bring down Apache, thinking he can bring it back up momentarily with startapache.sh. But NFS is a jealous and vengeful god, and Apache now complains that it doesn't have permission to write to its logfiles, and therefore can't start httpd.
5. Today, 5 PM: "How can this be?", Zach and I ask. Apache had no problem starting up yesterday night, and to our knowledge nobody futzed with chiara's NFS mount of /home/cds. This change remains mysterious to us.

Despite the aforementioned mystery, Zach and I pressed on and tried to diagnose the permissions issue. We found that even if you are logged into nodus or pianosa or rossa or whatever as the controls user, the NFS mount saw us as the user nobody (in the group nogroup). If we created a file on the NFS mount, it was owned by nobody/nogroup. If we tried to modify a file on the NFS mount that was owned by controls/controls or controls/staff, we got a "permission denied" error, even if we tried with superuser privileges.

It turns out this has to do with the vagaries of NFS (scroll down to gotcha #4). We have all_squash enabled in /etc/exports , which means that no matter your username or group on nodus, rossa, pianosa, or harpischordsa, NFS coerces your UID/GID to chiara's nobody/nogroup. Anyway, the fix was to go into chiara's /etc/exports and change this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,insecure)

to this

/home/cds 192.168.113.0/255.255.255.0(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001,insecure)

 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.

Not sure if someone is already on this, but the nodus DokuWikis are still down (AIC, ATF, Cryo, etc.)

I get:

DokuWiki Setup Error

The datadir ('pages') does not exist, isn't accessible or writable. You should check your config and permission settings. Or maybe you want to run the installer

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.

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.

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

 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 >

#!/bin/bash   ### this is a comment  PATH=$PATH:/home/user/path    echo "How cool is this?" 

EDIT: it looks like the code highlighting is sort of broken :-(.

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.

How is the modulation depth assumed in the calculation?

If you don't know the modulation depth, you can't calibrate the transimpedance of each PD individually.

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

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.

My SURF week-1 work...

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. 

The steps involved in getting the transimpedence are as follows:

Acquiring data

• Get 2 sets of data from Network Analyzer Agilent 4395: One set of data will be for the transfer function of Ref PD over RF out. The other set for Test PD over Ref PD.
• The following conditions were set:

1) Frequency sweep range: 1MHz to 200 MHz.

2) Number of Points sampled in  the range: 201

3) Type of sweep: Logarithmic

• Set the NA to give the corresponding transfer function values in dB and also Phase response in degrees.
• Save the data into floppy disk for processing on the computer (The wireless way of acquiring data was not working when the experiment was conducted )

Plotting

• The matlab code attached (TransimpedencePlot.m) will then give plots for the absolute values of transimpedence in V/A.
• Logic involved in the code:
  • Transimpedence = Voltage response / (Responsivity of the photodiode * Power incident) 
  • Responsivity for BBPD is taken as 0.1 A/W and for NF1611 as 0.68 A/W as given in their datasheets.
  • Voltage response of Test PD w.r.t RF output of NA (in dB) = Voltage response of Test PD w.r.t Ref PD (in dB) + Voltage response of Ref PD w.r.t RF output of NA (in dB) 

 Results

The Plots of transimpedence obtained are attached (results.pdf) . The results obtained for BBPD is consistent with the ones obtained before, but the same method and code gives a different transimpedence for 1611.

The transimpedence of NF 1611 was obtained to be around 4-5 V/A which is very much off-track compared to the one given in the datasheet (elog: 2906).

The transimpedence of  Broadband photodiode (D1002969-v8) was around 1200 - 1300 V/A for most of the range, but the value started falling as the frequency approached 100 MHz. This result is consistent with DCC document: T1100467-v2.

 Motivation: 

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

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.

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.

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?

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!