- Enhanced and debugged histogram memory for AMOR
* added PROJECT both in HM and driver code * added single detector support. - Removed several bugs in the AMOR data bit. - Updated documentation
This commit is contained in:
cvs
@ -34,6 +34,12 @@ implementors.
|
||||
path of the SICS server. This is usually /home/INSTRUMENT/bin.
|
||||
</p>
|
||||
<p>
|
||||
<b>backup motSave</b> toggles a flag which controls saving of motor
|
||||
positions. If this flag is set, commands for driving motors to the
|
||||
current positions are included in the backup file. This is useful
|
||||
for instruments with slipping motors.
|
||||
</p>
|
||||
<p>
|
||||
<b>restore file</b> reads a file produced by the backup command described
|
||||
above and restores SICS to the state it was in when the status was saved with
|
||||
backup. If no file argument is given the system default file gets
|
||||
|
||||
@ -10,8 +10,68 @@
|
||||
There is no such thing as bug free software. There are always bugs, nasty
|
||||
behaviour etc. This document shall help to solve these problems. The usual
|
||||
symptom will be that a client cannot connect to the server or the server is
|
||||
not responding.
|
||||
not responding. Or error messages show up. This section helps to solve such
|
||||
problems.
|
||||
</p>
|
||||
<h2>Looking at Log Files</h2>
|
||||
<p>
|
||||
The first thing to do, especially when confronted with confusing statements
|
||||
from either users or instrument scientists, is to look at the SICS servers
|
||||
log files. The last 1000 lines of the instrument log are accessible from
|
||||
any SICS client or through the WWW interface. The SICS commands:
|
||||
<dl>
|
||||
<dt>commandlog tail
|
||||
<dd> shows the last 20 lines of the log.
|
||||
<dt>commandlog tail n
|
||||
<dd>shows the last n lines of the log.
|
||||
</dl>
|
||||
will show you the information available. In order to see more, log in to the
|
||||
instrument account. There the following unix commands might help:
|
||||
<ul>
|
||||
<li><b>sicstail</b> shows the last 20 lines of the current log file and its
|
||||
name
|
||||
<li><b>sicstail n</b> shows the last n lines of the current log file.
|
||||
</ul>
|
||||
In order to see some more, cd into the log directory of the instrument
|
||||
account. In there are files with names like:
|
||||
<pre>
|
||||
auto2001-08-08@00-01-01.log
|
||||
</pre>
|
||||
This means the log file has been started at August, 8, 2001 at 00:01:01.
|
||||
There is a new log file daily. Load appropriate files into the editor and
|
||||
look what really happened.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The log files show you all commands given and all the responses of the system.
|
||||
Additionally there are hourly time stamps in the file which allow to narrow
|
||||
in when the problem started. Things to watch out for are:
|
||||
<dl>
|
||||
<dt>MOTOR ALARM
|
||||
<dd>This message means that the motor failed to reach his position for a
|
||||
couple of times. This is caused by either a concrete shielding element
|
||||
blocking the movement of the instrument, badly adjusted motor parameters,
|
||||
mechanical failures or the air cushions not operating properly.
|
||||
<dt>EL734__BAD_EMERG_STOP
|
||||
<dd>Somebody has pushed the emergency stop button. This must be released
|
||||
before the instrument can move again. Moreover the motor controller will
|
||||
not respond to further commands in this mode. Thus restarting SICS on this
|
||||
error message will make SICS fail to initialize the motors affected!
|
||||
<dt>EL***__BAD_PIPE, BAD_RECV, BAD_ILLG, BAD_TMO, BAD_SEND
|
||||
<dd>Network communication problems. Can generaly be solved by restarting
|
||||
SICS.
|
||||
<dt>EL737__BAD_BSY
|
||||
<dd>A counting operation was aborted while the beam was off. Unfortunately,
|
||||
the counter box does not respond to commands in this state and ignores the
|
||||
stop command sent to it during the abort operation. This can be resolved by
|
||||
the command:
|
||||
<pre>
|
||||
counter stop
|
||||
</pre>
|
||||
when the beam is on again.
|
||||
</dl>
|
||||
</p>
|
||||
<h2>Starting SICS</h2>
|
||||
<p>
|
||||
An essential prerequisite of SICS is that the server is up
|
||||
and running. The system is configured to restart the SICServer whenever it
|
||||
@ -43,108 +103,12 @@ given at the unix command line. You must be the instrument user
|
||||
(for example DMC) on the instrument computer for this to work properly.
|
||||
</p>
|
||||
|
||||
<h2>Finding the SICS server</h2>
|
||||
<p>The first thing when killing the SICS server manually is to find the
|
||||
server process.
|
||||
Log in as Instrument user on the instrument computer (for instance DMC on
|
||||
lnsa05). Type the command:
|
||||
<pre>
|
||||
/home/DMC> ps -A
|
||||
</pre>
|
||||
Note the capital A given as parameter. The reward will be listing like this:
|
||||
<pre width =132>
|
||||
PID TTY S TIME CMD
|
||||
0 ?? R 01:56:28 [kernel idle]
|
||||
1 ?? I 1:24.44 /sbin/init -a
|
||||
3 ?? IW 0:00.20 /sbin/kloadsrv
|
||||
24 ?? S 40:39.58 /sbin/update
|
||||
97 ?? S 0:04.87 /usr/sbin/syslogd
|
||||
99 ?? IW 0:00.03 /usr/sbin/binlogd
|
||||
159 ?? S 1:43.70 /usr/sbin/routed -q
|
||||
285 ?? S 1:00.45 /usr/sbin/portmap
|
||||
293 ?? S 6:03.45 /usr/sbin/ypserv
|
||||
299 ?? I 0:00.37 /usr/sbin/ypbind -s -S psunix,lnsa05.psi.ch
|
||||
307 ?? I 0:00.52 /usr/sbin/mountd -i
|
||||
309 ?? I 0:00.07 /usr/sbin/nfsd -t8 -u8
|
||||
311 ?? I 0:00.09 /usr/sbin/nfsiod 7
|
||||
317 ?? S 5:51.54 /usr/sbin/automount -f /etc/auto.master -M /psi
|
||||
370 ?? I 0:28.58 -accepting connections (sendmail)
|
||||
389 ?? S 1:41.15 /usr/sbin/xntpd -g -c /etc/ntp.conf
|
||||
419 ?? S 6:00.16 /usr/sbin/snmpd
|
||||
422 ?? S 1:00.91 /usr/sbin/os_mibs
|
||||
438 ?? S 34:29.67 /usr/sbin/advfsd
|
||||
449 ?? I 3:16.29 /usr/sbin/inetd
|
||||
482 ?? IW 0:11.53 /usr/sbin/cron
|
||||
510 ?? IW 0:00.02 /usr/lbin/lpd
|
||||
525 ?? I 5:31.67 /usr/opt/psw/psw_agent -x/dev/null -f/usr/opt/psw/psw_agent.conf
|
||||
532 ?? I 0:00.74 /usr/opt/psw/psw_sensor_syswd 1 -x/dev/null
|
||||
555 ?? I 0:00.58 /usr/bin/nsrexecd
|
||||
571 ?? I 0:20.27 /usr/dt/bin/dtlogin -daemon
|
||||
583 ?? S 1:38.27 lpsbootd -F /etc/lpsodb -l 0 -x 1
|
||||
585 ?? IW 0:00.04 /usr/sbin/getty /dev/lat/620 console vt100
|
||||
586 ?? IW 0:00.03 /usr/sbin/getty /dev/lat/621 console vt100
|
||||
587 ?? I 35:59.85 /usr/bin/X11/X :0 -auth /var/dt/authdir/authfiles/A:0-aaarBa
|
||||
657 ?? I 0:01.46 rpc.ttdbserverd
|
||||
4705 ?? IW 0:00.05 dtlogin -daemon
|
||||
9127 ?? I 0:00.37 /usr/bin/X11/dxconsole -geometry 480x150-0-0 -daemon -nobuttons -verbose -notify -exitOnFail -nostdin -bg gray
|
||||
9317 ?? IW 0:00.73 dtgreet -display :0
|
||||
14412 ?? S 0:39.71 netscape
|
||||
15524 ?? I 0:00.57 rpc.cmsd
|
||||
21678 ?? S 0:00.11 telnetd
|
||||
31912 ?? S 0:10.65 /home/DMC/bin/SICServer /home/DMC/bin/dmc.tcl
|
||||
584 console IW + 0:00.21 /usr/sbin/getty console console vt100
|
||||
21978 ttyp1 S 0:00.63 -tcsh (tcsh)
|
||||
22269 ttyp1 R + 0:00.10 ps -A
|
||||
</pre>
|
||||
This is a listing of all running processes on the machine where this command
|
||||
has been typed. Note, in this case, at the bottom in the line starting with
|
||||
<tt> 31912 ?? </tt> an entry for the SICS server. In this example the server
|
||||
is running. If the server is down, no such entry would be present.
|
||||
</p>
|
||||
|
||||
<h2> Killing a hanging SICS server </h2>
|
||||
<p>
|
||||
Suppose, the situation is that the SICS server does not respond anymore. It
|
||||
needs to be forcefully exited. Please note, that it is always better to
|
||||
close the server via the <tt>Sics_Exitus</tt> command typed with manager
|
||||
privilege in one of the command clients. In order to kill the server it is
|
||||
needed to find him first using the scheme given above. The information
|
||||
needed is the number given as first item in the same line where the server
|
||||
is listed. In this case: <tt>31912</tt>. Please note, that this number will
|
||||
always be different. The command to force the server to stop is:
|
||||
<pre>
|
||||
/home/DMC> kill -9 31912
|
||||
</pre>
|
||||
Note, the second parameter is the number found with <tt>ps -A</tt>. The
|
||||
SICServer will be restarted automatically by the system. Occasionally, it
|
||||
may happen, that you cannot connect to the SICS server after such an
|
||||
operation. This is due to some network buffering problems. Doing the killing
|
||||
again usually solves the problem.
|
||||
</p>
|
||||
|
||||
<h2> Shutting The SICS Server Down Completely</h2>
|
||||
<p>
|
||||
This is done for you by the killsics shell script. Just type
|
||||
<pre>
|
||||
killsics
|
||||
</pre>
|
||||
at the unix command line. Here is what killsics does for you:
|
||||
In order to completely shutdown the SICS server two process must be killed:
|
||||
the actual SICS server and the process which automatically restarts the
|
||||
SICServer. The latter must be killed first. It can be found in the ps -A
|
||||
listing as a line reading <b>keepalive SICServer </b>. Kill that one as
|
||||
described above, then kill the SICServer. For restarting SICS after this,
|
||||
use the startsics command.
|
||||
</p>
|
||||
<h2>Restart Everything</h2>
|
||||
<p>
|
||||
If nothing seems to work any more, no connections can be obtained etc, then
|
||||
the next guess is to restart everything. This is especially necessary if
|
||||
mechanics or electronics people were closer to the instrument then 400 meters.
|
||||
<OL>
|
||||
<LI> Reboot the Macintosh PC by switching it off at the silver button on the
|
||||
left. Press deep and a few seconds to achieve an effect. The LED right to the
|
||||
button should be off, before you press again to boot the Macintosh.
|
||||
<LI> Reboot the histogram memory. It has a tiny button labelled RST. That' s
|
||||
the one. Can be operated with a hairpin, a ball point pen or the like.
|
||||
<LI> Wait 5 minutes. The Macintosh may take that time to come up again.
|
||||
@ -155,6 +119,43 @@ connected or configured.
|
||||
If this fails (even after a second) time there may be a network problem which
|
||||
can not be resolved by simple means.
|
||||
</p>
|
||||
<h2>Checking SICS Startup</h2>
|
||||
<p>
|
||||
Sometimes it happens that the SICServer hangs while starting up or hardware
|
||||
components are not properly initialized. In such cases it is useful to
|
||||
look at the SICS servers startup messages. In order to do so, both the
|
||||
SICServer and its keepalive process must be killed first. On the instrument
|
||||
acount issue the command:
|
||||
<pre>
|
||||
ps -A | grep SICS
|
||||
</pre>
|
||||
A message like this will be printed:
|
||||
<pre>
|
||||
23644 ?? I 0:00.00 ksh keepalive SICServer focus.tcl
|
||||
23672 ?? R 59:24.05 SICServer focus.tcl
|
||||
7119 ttyp6 S + 0:00.00 grep SICS
|
||||
</pre>
|
||||
Remember the numbers in the first columns (the PID's) and kill both
|
||||
programs by issuing the command:
|
||||
<pre>
|
||||
kill -9 pid pid
|
||||
</pre>
|
||||
Example:
|
||||
<pre>
|
||||
kill -9 23644 23672
|
||||
</pre>
|
||||
Note, the numbers are those displayed with the ps -A command.
|
||||
Then cd into the bin directory of the instrument account and issue
|
||||
the unix command:
|
||||
<pre>
|
||||
SICServer inst.tcl | more
|
||||
</pre>
|
||||
Replace inst.tcl with the name of the appropriate instrument initialisation
|
||||
file. This allows to page through SICS startup messages and will help to
|
||||
identify the troublesome component. The proceed to check the component and
|
||||
the connections to it.
|
||||
</p>
|
||||
|
||||
<h2>Getting New SICS Software</h2>
|
||||
<p>
|
||||
Sometimes you might want to be sure that you have the latest SICS software.
|
||||
|
||||
Reference in New Issue
Block a user