ID |
Date |
Author |
Type |
Category |
Subject |
111
|
Fri Nov 16 14:11:26 2007 |
tobin | Update | Computers | op140 |
Alan called to say that Phil Ehrens will be coming by to take op140 off our hands. |
112
|
Fri Nov 16 14:31:43 2007 |
tobin | Update | Computers | op140 disks |
Phil Ehrens stopped by and took op140's disks. |
Attachment 1: DSC_0173.JPG
|
|
117
|
Tue Nov 20 11:10:07 2007 |
tobin | Update | Computers | epics access from matlab |
I installed "labca", which allows direct access to EPICS channels from within Matlab. It comes with both Linux and Solaris binaries (and source) but I've only tried it on linux.
To set it up, run these shell commands:
pushd /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86
setenv PATH ${PATH}:`pwd`
cd /cvs/cds/caltech/users/tf/build/labca_2_1/lib/linux-x86
setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:`pwd`
popd Then start matlab, and within matlab type:
addpath /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86/labca
help labca
foo = lcaGet('C1:PSL-FSS_RCTRANSPD') It seems like reasonably well-written software, and is being actively maintained right now. If we like it, I can build a more recent version, install it in a more permanent location, etc. |
118
|
Tue Nov 20 13:06:57 2007 |
tobin | Configuration | Computers | linux1 has new disk |
Alex put the new hard disk into linux1 along with a fresh install of linux (CentOS). The old disk was too damaged to copy.
Alex speculates that the old disk failed due to overheating and that linux1 could use an extra fan to prevent this in the future. |
119
|
Tue Nov 20 18:02:54 2007 |
John | Summary | Computers | PSL_Main screen |
I've updated the PSL_MAIN screen. The old version may be found in cvs/cds/caltech/medm/old/medm/psl. |
Attachment 1: PSL_Screen.tif
|
|
120
|
Tue Nov 20 18:35:20 2007 |
John | HowTo | Computers | MatLab in Emacs |
If you can't get MatLab to run in emacs try adding the following to the .emacs file
(setq matlab-shell-command-switches '("-nojvm"))
This stops the gui opening.
To start MatLab type M-x matlab-shell.
To enter MatLab mode M-x matlab-mode.
I've done this on LINUX3.
To run MatLab in emacs under windows one can use MatLabShell http://www.cs.umb.edu/~ram/matlabShell/index.html |
132
|
Wed Nov 28 16:46:28 2007 |
rana | Configuration | Computers | scientific linux 5.0 |
I tried installing Scientific Linux on Tiramisu. The installation process was so bad (really)
that I quit after 15 minutes. Its back to booting Ubuntu as if nothing had ever happened. Let
us never speak of Scientific Linux again. |
140
|
Thu Nov 29 14:29:22 2007 |
tobin | Configuration | Computers | linux1 httpd/conlogger fixed |
I think I fixed the conlogger web interface on linux1.
Steps necessary to do this:
0. Run "/etc/init.d/httpd start" to start up httpd right now
1. Run "/usr/sbin/ntsysv" and configure httpd to be started automatically in the future
2. Copy /cvs/cds/caltech/conlogger/bin/conlog_web.pl to /var/www/cgi-bin and chown to controls
8. Hack the conlog_web.pl to (0) use /usr/bin/perl (1) not use Apache::Util, and (2) function with the newer version of CGI.pm
9. Enjoy!
The following steps are optional, and may be inserted between steps 2 and 8:
3. Try to install Apache::Util (via "perl -MCPAN -e shell" followed by "Install Apache::Util")
4. Notice that the installation dies because there is no C compiler installed
5. Bang head in disgust and abomination over a Linux distribution shipping without a C compiler installed by default
6. "yum install gcc"
7. Annoyed by further dependencies, go to step 8 |
149
|
Fri Nov 30 19:46:58 2007 |
rana | Configuration | Computers | EPICS Time Bad again |
The time on the EPICS screens is off by 10 minutes again. Por Que?
Its because the ntpd on scipe25 wasn't restarted after the last boot. If someone
knows how to put the ntpd startup into that machine, please do so.
This time I started it up by just going sshing in as controls and then entering:
sudo /usr/sbin/ntpd -c /etc/ntp.conf
which runs it as root and points to the right file.
It takes a few minutes to get going because all of the martian machines have to first fail to
connect to the worldwide pool servers (e.g. 0.pool.ntp.org) before they move on and try linux1
which has a connection to the world. Once it gets it you'll see the time on the EPICS screens
freeze. It then waits until the ntp time catches up with its old, wrong time before updating
again.
According to the Wikipedia, this time is then good to 128 ms or less. |
153
|
Sun Dec 2 17:37:33 2007 |
rana | Omnistructure | Computers | Network Cabling in the Office |
We all know that we've spent many integrated man hours trying to figure out why our network connections
in the office area don't work. Usually its because of the bad hub around the Tobin/Osamu desk.
I pried open some of the wall conduit today and it looks pretty easy to fish cables through. I think
its time we finally did that. It may be a little disruptive, but I propose we get Larry to come over
and figure out what needs to happen for us to get regular 100 Mbit ports on the walls. These can
then all go over and get connected to a switch in the rack that holds linux1.
Opinions / comments ? |
158
|
Mon Dec 3 16:24:47 2007 |
tobin | HowTo | Computers | GNU screen |
GNU screen is a utility that can be quite handy for managing long-running psuedo-interactive terminal programs on remote machines. In particular, I think it might be useful in developing and testing "Matlab DMT" tools on Mafalda. |
164
|
Wed Dec 5 10:57:08 2007 |
alberto | HowTo | Computers | Connecting the GPIBto USB interface to the Dell laptop |
The interface works only on one of the USB ports of the laptop (the one on the right, looking at the computer from the back). |
192
|
Sun Dec 16 16:52:40 2007 |
dmass | Update | Computers | Computer on the end Fixed |
I had Mike Pedraza look at the computer on the end (tag c21256). It was running funny, and turns out it was a bad HD.
I backed up the SURF files as attachments to their wiki entries. Nothing else seemed important so the drive was (presumably) swapped, and a clean copy of xp pro was installed. The username/login is the standard one.
Also - that small corner of desk space is now clean, and it would be lovely if it stayed that way. |
217
|
Thu Dec 27 18:18:56 2007 |
rana | Update | Computers | Update on GigE Camera |
Quote: | So I finally got the linux software to compile on mafalda. I got the software to dump all the information regarding the camera onto a file. I tried to take a tiff snap and came up empty. So I looked at the configuration file and realized that the camera thinks that the frame-rate is a nan. Am reading up the manual to fix the frame-rate manually and then will attempt to take another snap.
All the files are in a folder called Prosilica in /home/controls/ on mafalda. All the executables are in /home/controls/Prosilica/bin-pc/x86/* . On another note, I am looking for a name for the camera. Any suggestions are welcome. |
Suggestion #1: put this in the target area in a directory called /prosilica/. /home/controls is not backed up.
Suggestion #2: put a readme file in there on any work that was necessary to get it to compile.
Suggestion #3: make a wiki page for the camera with all the info that camera code developers will need |
228
|
Wed Jan 9 10:47:15 2008 |
fricke | Update | Computers | ethernet wiring in office/control room |
The electrical people have been here for three days, installing ethernet cables and drops in the 40m office area, in the old conduits where there was power and 10base2. Soon we will have reliable ethernet connections, instead of relying on switches hanging from the ceiling, etc! |
274
|
Sat Jan 26 18:12:45 2008 |
rana | HowTo | Computers | extra processes and crashes |
There were a load of extra processes on op440m; they were all related to rogue DV processes (frameMemRead, framer4, xmgrace, etc.)
You can check this by running top. IF there's lots of them you can kill them by using 'pkill'.
I'm attaching the screen cap of a 'top' session. You can also see that the cron of updatedb is running and taking upp all the CCPU. Thee result is that the delay puts misspellings and doouble characters intoo my elog entry. Clearly wwe'll have to fix the cron setup. |
275
|
Sat Jan 26 18:48:43 2008 |
John | Summary | Computers | Restart iscepics |
iscepics died this afternoon. We restarted it and restored settings from yesterday. I've written up instructions in the wiki. |
281
|
Mon Jan 28 17:16:54 2008 |
Andrey | Configuration | Computers | Matlab libraries DO NOT WORK properly sometimes |
Working in Matlab, I encountered at two different times today the license distribution problem:
??? License checkout failed.
License Manager Error -4
Maximum number of users for Curve_Fitting_Toolbox reached.
Try again later.
To see a list of current users use the lmstat utility or contact your License Administrator.
Troubleshoot this issue by visiting:
http://www.mathworks.com/support/lme4a |
294
|
Sat Feb 2 14:11:27 2008 |
John | Summary | Computers | OPTLEVmaster screen |
I changed the layout of the optlev master screen. The old version is /cvs/cds/caltech/medm/old/C1ASC_OPTLEVmaster080202.adl |
302
|
Fri Feb 8 17:09:52 2008 |
Max Jones | Update | Computers | Changes to NoiseBudget |
Today I altered the following files
caltech/NB/matlab/utilities/get_dtt_dataset
In DARM_CTRL case I changed the second channel name to DARM_ERR. Messy but it may be effective.
caltech/NB/matlab/noise/getUGF.m
I commented out lines of code specifically pertaining to non-existent DARM_DAQ channel. Marked in
code around approximately line 60.
Please address all comments or concerns to me (williamj(at symbl)caltech.edu). Thank you. |
318
|
Thu Feb 14 17:21:53 2008 |
Max Jones | Update | Computers | Noise budget code changes |
In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code. |
319
|
Fri Feb 15 10:28:44 2008 |
rana | Update | Computers | Noise budget code changes |
Quote: | In cvs/cds/caltech/NB/matlab/utilities/LSCmodel.m at line 146
I have hardwired in changes to struct lsc. Please see code. |
The IFOin variable (which I admit is not documented) should refer to a file called
C1IFOparams.m in the ReferenceData directory. This does not yet exist but can be
created by merging L1IFOparams.m with our knowledge of the 40m IFO. |
320
|
Fri Feb 15 22:16:04 2008 |
Andrey | Update | Computers | MATLAB is not working: "Licence checkout failed" |
For some unknown to me reason,
Matlab stopped working about 20 minutes ago on all computers in the control room (both UNIX control machines and Windows).
It says: "License checkout failed. License Manager Error -15. MATLAB is unable to connect to the license server."
I do not know how to revive Matlab.
At the same time, I consider that I made a significant progress in building my theoretical/computational model in the last 2 days. I was able to compute the time-evolution of accelerometer signals through stacks and pendulums using Matlab command "lsim", and I am now able to calculate RMS of spectrum of differential arm length in different frequency intervals. It seemed to me that everything is ready in my program to make the three-dimensional theoretical/computational plot (RMS as a function of Q-factors of ETMX and ITMX), but unfortunately Matlab stopped working. It seemed to me that all that was remaining was to run a loop with all possible values of Q-factors. Let's hope that Matlab will be working after the weekend.
Andrey. |
345
|
Thu Feb 28 16:19:37 2008 |
josephb | Configuration | Computers | Mafalda rewired and multiple cameras running |
1) Mafalda is now connected via an orange Cat5E ethernet cord to the gigabit ethernet switch in rack in the office space. It has been labeled at both ends with "mafalda".
2) Both the GC650M camera (from MIT) and the GC750M are working. I can run the sampleviewer code and get images simultaneously. Unforutnately, the fps on both cameras seems to drop roughly in half (not an exact measurement) when displaying both simultaneously at full resolution.
3)Discovered the Gigabit ethernet card in Mafalda doesn't support jumbo packets (packets of up to 9k bytes), which is what they recommend for optimum speed.
4)However, connecting the cameras through only gigabit switches to Mafalda did seem to increase the data rate anyways, roughly by a factor of 2. (Used to take about 80 seconds to get 1000 frames saved, now takes roughly 40 seconds).
5)Need to determine the bottleneck on the cameras. It may be the ethernet card, although its possible to connect multiple gigabit cards to single computer (depending on the number of PCI slots it has). Given the ethernet cards are cheap ($300 for 20) compared to even a single camera (~$800-1500), it might be worth while outfitting a computer with multiple. |
346
|
Thu Feb 28 19:37:41 2008 |
rob | Configuration | Computers | multiple cameras running and seisBLRMS |
Quote: | 1) Mafalda is now connected via an orange Cat5E ethernet cord to the gigabit ethernet switch in rack in the office space. It has been labeled at both ends with "mafalda".
2) Both the GC650M camera (from MIT) and the GC750M are working. I can run the sampleviewer code and get images simultaneously. Unforutnately, the fps on both cameras seems to drop roughly in half (not an exact measurement) when displaying both simultaneously at full resolution.
3)Discovered the Gigabit ethernet card in Mafalda doesn't support jumbo packets (packets of up to 9k bytes), which is what they recommend for optimum speed.
4)However, connecting the cameras through only gigabit switches to Mafalda did seem to increase the data rate anyways, roughly by a factor of 2. (Used to take about 80 seconds to get 1000 frames saved, now takes roughly 40 seconds).
5)Need to determine the bottleneck on the cameras. It may be the ethernet card, although its possible to connect multiple gigabit cards to single computer (depending on the number of PCI slots it has). Given the ethernet cards are cheap ($300 for 20) compared to even a single camera (~$800-1500), it might be worth while outfitting a computer with multiple. |
I found the SampleViewer running and displaying images from the two cameras. This kept mafalda's network so busy that the seisBLRMS program fell behind by a half-hour from its nominal delay (so 45 minutes instead of 12), and was probably getting steadily further behind. I killed the SampleViewer display on linux2, and seisBLRMS is catching up. |
352
|
Mon Mar 3 13:58:10 2008 |
steve | Update | Computers | RFM Network are down |
The CODAQ_RFNETWORK are down, except C1SUSVME & AWG |
353
|
Mon Mar 3 19:34:40 2008 |
rana | Update | Computers | RFM Network are down |
Quote: | The CODAQ_RFNETWORK are down, except C1SUSVME & AWG |
All of the FE machines were found to be down this afternoon. I called Alex and he suggested several
things which didn't work (restart EPICS tasks, power cycle RFM switch, etc.).
Then he suggested that I go around and power cycle every crate!!! And that sometimes the order of this
matters!!! I think he was just recording this conversation so that he could have a laugh by playing it on Youtube.
However, power cycling all of the FE crates seemed to work. Alex's theory is that 'something goes bad in the
RFM cards sometimes'.
Its all green now. |
354
|
Tue Mar 4 00:42:51 2008 |
rana | Update | Computers | FB0 still down ? |
The framebuilder is still down. I tried restarting the daqd task and resetting the RFM
switch like it says in the Wiki but it still doesn't work right. The computer itself is
running (I can ssh to it) and the daqd process is running but there's a red light for
it on the RFM screen and dataviewer won't connect to it.
If Alex isn't over by ~10 AM, we should call him and ask for help. |
355
|
Tue Mar 4 10:08:21 2008 |
rob | Update | Computers | green lights unreliable when c0daqctrl down |
So far I've tried powering off the framebuilder, power-cycling the RAID (it was showing an error message about bad IDE channel #4), and rebooting the LSC (just for fun). When I reset the LSC, its green light on the RFM_NETWORK screen did not turn red, making all these lights suspect. The iscepics40m process is what controls these red/green lights, so maybe it's gone wonky. It appears to be running however, on c1dcuepics, and it also seems to be functioning correctly in other ways (it's communicating correctly with the LSC).
Update: Alex and Jay came by. The solution was to reset the c0daqctrl processor, which apparently was not done in Rana's rebooting spree. Or maybe it needed to be done last. |
358
|
Tue Mar 4 23:22:32 2008 |
rob | DAQ | Computers | c1susvme1&2 rebooted |
I found that some channels from c1susvme1 and c1susvme2 were not being recording by the DAQ (and were not showing up in DV). I rebooted these processors, which fix the problem. If you see other cases of this (signal exactly zero, but not a testpoint problem), just reboot the corresponding processor. |
364
|
Fri Mar 7 17:10:01 2008 |
Max Jones | Update | Computers | Noise Budget work |
Noise budget has been moved to the svn system. A checked out copy is in the directory caltech. From now on, I will try to use the work cycle as outlined in the svn manual. Changes made today include the following:
getNoiseBudget
/matlab/noise/NoiseBudget
Details of the modifications made may be found on the svn system. Please let me know if anyone has a suggestion or concern. Thank you - Max. |
382
|
Fri Mar 14 16:56:03 2008 |
Dmass | Bureaucracy | Computers | New 40m control machine. |
I priced out a new control machine from Dell and had Steve buy it.
GigE cards (jumbo packet capable) will be coming seperately.
Specs:
Quad core (2+GHz)
4 Gigs @ 800MHz RAM
24" LCD
low end video card (Nvidia 8300 - analog + digital output for dual head config)
No floppy drive on this one (yet?) |
399
|
Mon Mar 24 20:15:03 2008 |
John | Summary | Computers | c1susvme2 |
c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.
After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.
We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look. |
400
|
Tue Mar 25 10:44:24 2008 |
rob | Update | Computers | c1susvme2 |
Quote: | c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.
After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.
We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look. |
I rebooted it again this morning. The ASS machine is currently not running its process, for whatever reason (someone turn it off?). Let's leave it like this for a day and see how the c1susvme2 does. The other recent change is Steve's install of a cooling fan--maybe that's causing the problem. |
401
|
Tue Mar 25 13:21:25 2008 |
Andrey | Update | Computers | c1susvme2 is not behaving itself again |
|
403
|
Tue Mar 25 16:34:47 2008 |
rob | Update | Computers | c1susvme2 |
Quote: |
Quote: | c1susvme2 isn't behaving itself. It keeps getting out of sync and/or giving a red status light.
After going through the usual restart procedures a few times (unsuccessfully) we power cycled the c1susvme & c1sosvme crates. We think everything came back okay.
We still can't get the status and CRC (cyclic redundancy check) to return to normal on c1susvme2. If Alex is around tomorrow please ask him to take a look. |
I rebooted it again this morning. The ASS machine is currently not running its process, for whatever reason (someone turn it off?). Let's leave it like this for a day and see how the c1susvme2 does. The other recent change is Steve's install of a cooling fan--maybe that's causing the problem. |
Now c1susvme1 is joining the action. Since leaving the ASS off doesn't change anything, we can probably absolve it of blame. I now suspect the 4-pin LEMO cables going from the CLK DRIVER modules to the clock fanout modules. These cables are being squeezed/shaken by Steve's new fan setup, and may have been the culprit all along. John will do some testing to see if they are indeed the problem. |
405
|
Wed Mar 26 22:26:15 2008 |
John | Update | Computers | c1susvme |
I removed the fan and tweaked the timing cables to see if they were the source of our problems. I saw no effect. I'm leaving the fan off for the moment to see if that helps. It is on top of the filing cabinet next to my desk. |
406
|
Fri Mar 28 16:18:18 2008 |
rob | Update | Computers | c1susvme2 status |
c1susvme2 is getting worse and worse. it won't run for more than ~45 minutes without fatally de-syncing. for now I've turned off c1iovme (which sends the MCL signal) to see if that's causing the problem. next I'll swap the boards for c1susvme1 and c1susvme2 to see if it's the cpu (or maybe the RFM card) itself, rather than the timing/pentek systems. |
408
|
Mon Mar 31 14:14:16 2008 |
rob | Update | Computers | c1susvme2 status |
Quote: | c1susvme2 is getting worse and worse. it won't run for more than ~45 minutes without fatally de-syncing. for now I've turned off c1iovme (which sends the MCL signal) to see if that's causing the problem. next I'll swap the boards for c1susvme1 and c1susvme2 to see if it's the cpu (or maybe the RFM card) itself, rather than the timing/pentek systems. |
I swapped the processors for c1susvme1 and c1susvme2. So for now, to startup, you should ssh into c1susvme1 and run the startup.cmd for c1susvme2, and vice versa. |
412
|
Thu Apr 3 18:46:04 2008 |
Andrey | Configuration | Computers | "Network switch board" and "c1pem1 crate" were touched |
While working with the weather station, I did two things that potentially (with a very small probability) might influence the smooth work of other processors/computers.
I did the following on Wednesday, April 2nd, in times between 1PM and 3PM.
(1) I turned off for several seconds and returned into the initial position the switch-key on the rack with computer (processor) 'c1pem1' in order to reboot processor 'c1pem1'. The turning off/on of that key-switch was repeated several times.
(2) I pulled gently the whole "Network-Switch Board" towards me in order to replace an ethernet cat 5 cable going into the board form the processor 'c1pem1'. Some other connections of other ethernet cables might be flimsy, and then other people in 40-meter might have problems with computers other than 'c1pem1'. It should not happen, but in case of extraordinary behaviour of any other computer in our lab, people should check the connectors on the network-switch board. It is located near the middle of Y-arm. See picture. |
Attachment 1: Computer_Rack.JPG
|
|
416
|
Mon Apr 7 16:42:56 2008 |
rana | Update | Computers | eLog intermittent |
Phil Ehrens restarted Dziban again this morning. Looks like its still crashing each Monday around 8 AM.
Here is the latest suspect:
http://open.itworld.com/5040/reboot-unix-nlsunix-071225/page_1.html |
419
|
Tue Apr 15 18:44:25 2008 |
rana | Configuration | Computers | Rosalba |
There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.
Its a 64-bit Linux and so that's going to cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.
I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.
We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow. |
421
|
Wed Apr 16 10:20:01 2008 |
Andrey | Update | Computers | Rosalba and linux3 |
Quote: | There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.
Its a 64-bit Linux and so that may cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.
I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.
We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow. |
The ethernet cable for linux3 was installed on Wednesday morning. Now linux3 has Internet connection again. |
444
|
Thu Apr 24 22:06:47 2008 |
Andrey | Summary | Computers | Ethernet Cables and Hubs |
Today in the morning (between 8.30AM and noon) Joe and I were working on understanding which ethernet cables connect "processors controlling the work of equipment in the interferometer room" and "Internet hub in the computer room".
Firstly, we took off several times the blue ethernet cables from the router located near ETMX in the morning. We were trying to understand which port in the hub is responsible for the interaction with that processor.
Secondly, we were working on reviving the connection with the computer controlling vacuum in the interferometer.
Later in the middle of the day (around 2PM) Joe continued some work with ethernet cables without me. We plan on continuing the cable work on Friday morning. A better and more detailed elog will appear then. |
447
|
Fri Apr 25 11:33:40 2008 |
Andrey | Configuration | Computers | Computer controlling vaccum equipment |
Old computer (located in the south-end end of the interferometer room) that was almost unable to fulfill his duties of controlling vacuum equipment has been replaced to "Linux-3". MEDM runs on "Linux-3".
We checked later that day together with Steve Vass that vacuum equipment (like vacuum valves) can be really controlled from the MEDM-screen 'VacControl.adl'.
Unused flat LCD monitor, keyboard and mouse (parts of the former LINUX-3 computer) were put on the second shelf of the computer rack in the computer room near the HP printer. |
449
|
Fri Apr 25 13:53:11 2008 |
josephb | Summary | Computers | Network setup |
This is the promised more in detail summary from Andrey's log ID 444.
What we did was go around to each hub, one at a time, unplug the network connection, and figure out which light on which hub went out. We then, went back to the control room, confirmed that we were still able to talk to the devices connected to the hub, and if not, rebooted them. This process was repeated for each hub.
As it stands, the hubs located at the ends of arms (in racks 1X4 and 1Y9) are connected to the really old 24 port 10 Base T hub located in 1Y7. In addition, the 5 port SMC hub is plugged into the 8 port SMC switch in 1Y5 (which actually has enough ports to simply move all the connections over to it, so I'm not sure why there are two...).
All other hubs/switches are connected back to the control room 24 port switch.
Attached is a simple diagram of the network connections for the 40m lab. |
Attachment 1: 40m_network_90.pdf
|
|
453
|
Sat Apr 26 11:21:15 2008 |
ajw | Omnistructure | Computers | backup of /cvs/cds restarted |
The backup of /cvs/cds (which runs as a cron job on fb40m; see /cvs/cds/caltech/scripts/backup/000README.txt)
has been down since fb40m was rebooted on March 3.
I was unable to start it because of conflicting ssh keys in /home/controls/.ssh .
With help from Dan Kozak, we got it to work with both sets of keys
( id_rsa, which allows one to ssh between computers in our 113 network without typing a password,
and backup2PB which allows the cron job to push the backup files to the archive in Powell-Booth).
It still goes down every time one reboots fb40m, and I don't have a solution.
A simple solution is for the script to send an email whenever it can't connect via ssh keys
(requiring a restart of ssh-agent with a passphrase), but email doesn't seem to work on fb40m.
I'll see if I can get help on how to have sendmail run on fb40m. |
456
|
Sun Apr 27 18:11:58 2008 |
rob | DAQ | Computers | br40m? |
The testpoint manager (which runs on fb40m) crashed this afternoon. Upon re-starting it, I found there was a rogue dtt process on op440m and also a daqd daemon running on br40m. One or both of these caused the tpman to crash. br40m is the frame broadcaster, which is never used here as we don't run DMT. I killed the daqd process there.
The way to find if there is a rogue process is to watch the output to the console from the tpman when you start it:
Allocate new TP handle 56 by 131.215.113.203
Allocate new TP handle 57 by 131.215.113.203
Allocate new TP handle 58 by 131.215.113.203
Allocate new TP handle 59 by 131.215.113.203
Allocate new TP handle 60 by 131.215.113.203
Allocate new TP handle 61 by 131.215.113.203
Allocate new TP handle 62 by 131.215.113.203
Allocate new TP handle 63 by 131.215.113.203
Allocate new TP handle 64 by 131.215.113.203
Allocate new TP handle 65 by 131.215.113.203
Allocate new TP handle 66 by 131.215.113.203
Allocate new TP handle 67 by 131.215.113.203
Allocate new TP handle 68 by 131.215.113.203
If you see something like this, with a new TP handle being allocated every few seconds, you need to log in to the corresponding host and kill whatever process has run away. |
457
|
Sun Apr 27 22:57:15 2008 |
ajw | DAQ | Computers | br40m? |
Quote: |
The testpoint manager (which runs on fb40m) crashed this afternoon. Upon re-starting it, I found there was a rogue dtt process on op440m and also a daqd daemon running on br40m. One or both of these caused the tpman to crash. br40m is the frame broadcaster, which is never used here as we don't run DMT. I killed the daqd process there.
The way to find if there is a rogue process is to watch the output to the console from the tpman when you start it:
Allocate new TP handle 56 by 131.215.113.203
Allocate new TP handle 57 by 131.215.113.203
Allocate new TP handle 58 by 131.215.113.203
Allocate new TP handle 59 by 131.215.113.203
Allocate new TP handle 60 by 131.215.113.203
Allocate new TP handle 61 by 131.215.113.203
Allocate new TP handle 62 by 131.215.113.203
Allocate new TP handle 63 by 131.215.113.203
Allocate new TP handle 64 by 131.215.113.203
Allocate new TP handle 65 by 131.215.113.203
Allocate new TP handle 66 by 131.215.113.203
Allocate new TP handle 67 by 131.215.113.203
Allocate new TP handle 68 by 131.215.113.203
If you see something like this, with a new TP handle being allocated every few seconds, you need to log in to the corresponding host and kill whatever process has run away. |
I *think* Alex is responsible for the daqd daemon running on br40m (he set up some new stuff recently, a data concentrator and broadcaster); I'll make sure he sees this post. |
463
|
Thu May 1 12:46:02 2008 |
josephb | Configuration | Computers | Nodus gateway is up |
The computer Nodus is now acting as a gateway machine between the GC network and the martian network in the 40m. It has the same passwords as the rana gateway machine.
Its name on the GC side is nodus (ip: 131.215.115.52) and on the martian side is nodus113 (ip: 131.215.113.200). Will need to update the hosts file on the control room machines so you can just use the name nodus113 rather than the full ip.
Software is still being added to the computer, and it will remain in parallel with the rana gateway machine until everything has been working properly for a week or so. |