gcc -L/usr/lib/ -ldl -lresolv -lm -ldl -lnsl -lsocket elogd.c -o elogd
G = 1e-9
p = 0, 0
z = 0.7 0.7
i.e. ------ ~ f
Excited all optics
Sun Dec 7 16:07:32 PST 2008
1) Goto http://localhost:631/
2) Click on "Add Printer"
3) Choose HP JetDirect
4) Use the correct address (socket://126.96.36.199:9100)
5) Choose HP and the 5550 postscript driver as the options
6) Try to only print useful stuff and not kill too many trees.
The attached plot shows that someone broke the MC_SUM_MON channel around 10:30 AM this past Wednesday the 11th. This is the EPICS monitor of the MC error point.
Come forward now with your confession and I promise that I won't let Steve hurt you.
The control room video is showing us a false ETMY image. Who worked on the ETMY camera or video today??!!
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
I added the following repos which I found on allegra to megatron and then did a 'yum install sshfs' on both machines:
-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
fb:controls>VMIC RFM 5565 (0) found, mapped at 0x2868c90
VMIC RFM 5579 (1) found, mapped at 0x2868c90
Could not open 5565 reflective memory in /dev/daqd-rfm1
16 kHz system
Spawn testpoint manager
Channel list length for node 0 is 4168
Test point manager (31001001 / 1): node 0
Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304.
He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.
This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:
./tdsdata 16384 2 C1:IOO-MC_F > /users/rana/test.txt
I loaded the data I got with the above command and there were no data dropouts. Possibly the dropout problem is only
associated with testpoints and so we have to wait for the TP fix.
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 seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running. This
is because I couldn't get the compiled matlab functionality to work.
Even so, this running script has been dying lately because of some bogus 'NDS' error. So for today I
have set the NDS server for mDV on megatron to be fb40m:8088 instead of nodus.ligo.caltech.edu. If this seems to fix the problem
I will make this permanent by putting in a case statement to check whether or not the mDV'ing machine is a 40m-martian or not.
On Monday evening, I ran this command: trianglewave C1:IOO-MC_REFL_OFFSET 0 4 120 600;ezcawrite C1:IOO-MC_REFL_OFFSET 1.76
trianglewave C1:IOO-MC_REFL_OFFSET 0 4 120 600;ezcawrite C1:IOO-MC_REFL_OFFSET 1.76
which I thought (from the syntax help) would move that offset slider with a period of 120 seconds for 600 seconds. In actuality, the last argument is the
run time in number of periods. So the offset slider has been changing by 8 Vpp for most of the last day. Oops. The attached image shows what effect
this had in the MC transmitted power (not negligible). This would also make the locking pretty difficult.
In the second plot you can see the zoom in view for ~30 minutes. During the first part, the MCWFS are on and there are large fluctuations
in the transmitted power as the WFS offset changes. This implies that the large TEM00 carrier offset we induce with the slider couples into
the WFS signals because of imbalances in the quadrant gains - we need someone to balance the RF gains in the WFS quadrants by injecting
an AM laser signal and adjusting the digital gains.
Since there is still a modulation of the MC RFPD DC with the WFS on, we can use this to optimize the REFL OFFSET slider. The third plot
shows a 8 minute second trend of this. Looks like the slider offset of zero would be pretty good.
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/)
The LSC time had gone too high. I deleted ~20 filters and rebooted. CPU time came down to 50 usec.
The filters all looked like old trash to me, but its possible they were used.
I didn't delete anything from the DARM, CARM, etc. banks but did from the PD and TM filter banks. You can always go back in time by using the