Ranger
i.e.  ------ ~ f
      Guralp

C1:PSL-MZ_MZTRANSPD

AuthType Basic  
AuthName "LVC password"
AuthUserFile /cvs/cds/caltech/apache/etc/LVC.auth
Require valid-user

- Use LEDs of a wavelength that the OSEMs don't see. LEDs are also cool so that the
  Suspension won't drift in alignment.

- Use 2 power supplies so that the power is balanced.

- Make is +/-12 V twisted AWG 14 wire so that the EMI is contained. Should also
  be shielded cable.

• By means of the command "./usermod -u 1001 controls" we set the user ID of the user controls to 1001, as it is supposed to be.
  

• Ottavia was given IP address 131.215.113.097 by editing the file /etc/sysconfig/networ-scripts/ifcfg-eth0 (we also edited the netmask and the gateway address as in the Wiki)
  
• In linux1, which serves as name server, in the directory /var/named/chroot/var/named, we modified both the IP-to-name and name-to-IP register files 131.215.113.in-addr.arpa.zone and 131.215.11in-addr.martian.zone.
  
• We set the file /etc/resolv.conf so that the OS knows who is the name server.
  

• We created locally the empty directories /cvs/cds
  
• We edited the files /etc/fstab adding the line "linux1:/home/cds /cvs/cds nfs rw,bg,soft 0 0"
  
• We implemented the common variables of the controls environment by sourcing the cshrc.40m: in the file /home/controls/.cshrc we added the two lines "source /cvs/cds/caltech/cshrc.40m" and "setenv PATH ${PATH}:/cvs/cds/caltech/apps/linux64/matlab/bin/"
  

 I think I solved the problem (as you can probably see).

The cause was that this WYSIWYG interface for HTML is provided by an independent text editor called FCKeditor which is included in the elog. Although the elog installer has a bug and does not unzip properly the relative package. One has to do it by hand. (going to /elog/scripts/ and unzipping fckeditor.zip by hand in the same directory).

 As a reference. The elog runs on background in nodus.

To kill the process:

1) pkill -3 elogd

2) rm -f /var/run/elogd.pid

To restart it:

elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

During the cleanup of the lab. Steve found a box with two BNCs going to the ICS DAQ interface and an unconnected D-SUB on the floor under the AP table.  It seemed like a temperature sensor.

The BNCs were connected to C1:PEM-OSA_APTEMP and C1:PEM-OSA_SPTEMP.

Steve removed the box from the floor. These channels can be now used as spare DAQ channels. I labeled those cables.

So after having broke Allegra by updating the kernel, I was able to get it running again by copying the xorg.conf.backup file over xorg.conf in /etc/X11.  So at this point in time, Allegra is running with generic video drivers, as opposed to the ATI specific and proprietary drivers.

I added a PA current limiter.
It is only a voltage devider (composed with 3.09k and 1.02k resiste) between DAC and PA current adjustment input.
The output range of DAC is +/- 10[V] and  the conversion factor of PA current adjustment is 0.84[A/V] (measured value), so the PA current adjustment is limited +/- 2.1[A] ( 10[V]*1.02k/(1.02k+3.09k)*0.84[A/V] ).

Actually, the manual of the PA tells that the conversion factor is 0.25[A/V].
There is 3 possibility.
1) There are some mistakes in channels of digital system.
2) The PA manual is wrong.
  2-1) The conversion factor of current adjustment is wrong.
  2-2) The conversion factor of current monitor is wrong.
I measured the signal of current adjustment and current monitor directly, and confirm that they are consistent to the value monitord from MEDM.
Hence the PA manual must be wrong, but I don't know which factor is wrong (or both?).
If the suspect 2-2) is guilty, it means we adjust PA current with very small range.
This is a completly safety way, but a wast of resource.

Now, the slider to control current adjustment indicate the output of DAC.
I will improve this to indicate  current adjustment input, but it takes some time for me to learn about EPICS.

I have been getting ready for the annual safety inspection in the past 2-3 days.

c1susvme1 is behaving weirdly.  I've restarted it several times but its computation time is hanging out around 260 usec, making it useless for suspension control and locking.  I also found a PS/2 keyboard plugged in, which doesn't work, so I unplugged it.  It needs to be plugged into a PS/2 keyboard/mouse Y-splitter cable. 

I've setup the GC650 camera (ID 32223) to look at the mode cleaner transmission.  I've also added an alias to the camera server and client for this camera.

To use, type: "pserv1 &"on the machine you want to run the server on and "pcam1 &" on the machine you want to actually view the video.  At the moment, this only works for the 64-bit Centos 5 machines, Rosalba, Allegra and Ottavia.

Note, you will generally want to start the client first (pcam1 or pcam2) to see if a server is already running somewhere.  The server will complain that it can't connect to a camera if it already is in use.

I've setup the GC750 camera (ID 44026) to look at the the right most analog quad TV.  This can be run by using "pserv2 &" and "pcam2 &". 

If the image stops playing you can try starting and stoping the server to see if will start back up. 

You can also try increasing or decreasing the exposure, to see if that helps.  The increase and decrease buttons change the exposure by a factor of 2 for each press.

  Lastly, the button "Read Epic Channel" reads in the current value from the channel: "C1:PEM-stacis_EEEX_geo" and uses it as the exposure value, in microseconds (in principle 10 to 1000000 should work).

For example, to exposre for 10000 microseconds, use "ezcawrite C1:PEM-stacis_EEEX_geo 10000" and press the "Read Epic Channel" button.

Today I checked out the SR560 around the lab. I confirmed that the one with the label "channel A noisy" is effectively mulfuctioning.

It was coonected to the lock-in amplifier set up for the drum mode peak readout.

I repleaced that with a working one.

#!/bin/csh -f
setenv POSIXLY_CORRECT
while (! { ezcawrite.bin $* })
      echo "Retry $0 $*"
end

I made the following change to correct the sign of the 126MON channel:

allegra:c1aux>ezcawrite C1:PSL-126MOPA_126MON.EGUF -410
C1:PSL-126MOPA_126MON.EGUF = -410
allegra:c1aux>ezcawrite C1:PSL-126MOPA_126MON.EGUL 410
C1:PSL-126MOPA_126MON.EGUL = 410
allegra:c1aux>

I added the following repos which I found on allegra to megatron and then did a 'yum install sshfs' on both machines:

allegra:yum.repos.d>l
total 28
-rw-r--r-- 1 root root  428 Feb 12 16:47 rpmforge.repo
-rw-r--r-- 1 root root  684 Feb 12 16:47 mirrors-rpmforge
-rw-r--r-- 1 root root 1054 Feb 12 16:47 epel-testing.repo
-rw-r--r-- 1 root root  954 Feb 12 16:47 epel.repo
-rw-r--r-- 1 root root  626 Feb 12 16:47 CentOS-Media.repo
-rw-r--r-- 1 root root 1869 Feb 12 16:47 CentOS-Base.repo
-rw-r--r-- 1 root root  179 Feb 12 16:47 adobe-linux-i386.repo

This also required me to import the rpmforge GPG key:

sudo rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt

I found that tdsdata doesn't work.

When I star tdsdata, he takes a few ~ 10 seconds of data, and he dies with a message "Segmentation fault".
I tried to get data for some times and some channels, and this problem was observed everytime.
I also tried tdsdata on allegra, op440m and mafalda, and it didn't work on all of them.

Yesterday, I got a new version of tdsdata (which modified the problem of Message ID: 1328) and tried to build 
thme on my directory (/cvs/cds/caltech/users/kakeru.....)
This may have some relation to this problem.

The power supply of a lock-in amp, which is on the Y-arm side of PSL clean room, was pulled out by my mistake.

Then I reconnected it, but I don't know whether it is re-adjusted properly.

I'm sorry about this. If you are using that amp, it should be checked.

Yoichi, Alberto

this afternoon we centered the optical levers for all the optics.

To do that we first ran the alignment scripts for all the cavities.

Because of the network interference we've had from the CLIO system for the past 3-4 days, I asked the guys to remove

the test stand from the 40m lab area. It is now in the 40m control room. Since it needed an ethernet connection to get out

for some reason we've let them hook into GC. Also, instead of using a real timing signal slaved to the GPS, Jay suggested

just skipping it and having the Timing Slave talk to itself by looping back the fiber with the timing signal. Osamu will enter

more details, but this is just to give a status update.

The ndsproxy tcl task on nodus was eating up all the CPU and making the elog slow. I killed it and restarted it.

It looks like it hasn't been making a log file since January. Someone who has some skill in decoding the cryptic csh stdout redirection

syntax should look into this (its in target/ndsproxy/)

I modified the Video.db file used by c1aux located in  /cvs/cds/caltech/target/c1aux.

I added the following channels to the db file, intended for either read in or read out by the digital camera scripts.

C1:VID-ETMY_X_COM
C1:VID-ETMY_Y_COM

C1:VID-ETMY_X_STDEV

C1:VID-ETMY_Y_STDEV

C1:VID-ETMY_XY_COVAR

C1:VID-ETMY_EXPOSURE

C1:VID-ETMY_GAIN

C1:VID-ETMY_X_UL

C1:VID-ETMY_Y_UL

C1:VID_ETMY_X_SIZE

C1:VID_ETMY_Y_SIZE

A better naming scheme can probably be devised, but these will do for now.