- 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

doc/manager/trouble.htm

@@ -6,6 +6,41 @@
 
 <h1>SICS Trouble Shooting </h1>
 <hr size=4 width="66%">
+<H2>Inspecting Log Files</h2>
+<p>
+Suppose something went wrong over the weekend or during the night and
+you are not absolutely sure what the problem was. In such a case it is
+helpful to look at the SICS log files. They live in the log directory
+of the instrument account. For each day (or after each restart of the
+SICS server) a new log file is created. They are named according to the
+following convention:
+<pre>
+autoYYYY-mm-dd@hh-MM-ss.log
+</pre> 
+with YYYY denoting the year, mm the month, dd the day, hh the hour of
+creation, MM the minute of creation and ss the seconds of
+creation. The most recent log file can be looked at with the
+<b>sicstail</b> command. <b>sicstail num</b> shows the last num lines
+of the log file. Within SICS and especially in the SICS command line
+client, the last 1000 lines of the log are accessible through the
+<b>commandlog tail num</b> command. The command log is also accessible
+through the WWW at lns00. The log file is equipped with hourly time
+stamps which allow to find out when exactly a problem began to
+appear. 
+</p>
+<p>
+Quite often the inspection of the log files will indicate problems
+which are not software related such as:
+<ul>
+<li>Communication problems (usually network)
+<li>Positioning problems of motors.
+<li>BAD_EMERG_STOP: the motor emergency stop was engaged. It must be
+released before the motors move again. 
+<li>BAD_STP: a motor had been switched off. 
+</ul>
+</p>
+<h2>Restarting SICS</h2>
+<hr size=4 width="66%">
 <p>
 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
@@ -13,7 +48,7 @@ symptom will be that a client cannot connect to the server or the server is
 not responding. 
 </p>
 <p>
-An essential prerequisite of SICS is that the server is up
+An essential prerequisite of SICS is that the servers are up
 and running. The system is configured to restart the SICServer whenever it
 fails. Only after a reboot or when the keepalive processes were killed (see
 below) the SICServer must be restarted. This is done for all instruments by
@@ -21,10 +56,9 @@ typing:
 <pre>
 startsics 
 </pre>
-at the command prompt. startsics actually starts two programs: one is
-the replicator application which is responsible for the automatic
-copying of data files to the laboratory server. The other is the SICS
-server. Both programs are started by means of a shell script called
+at the command prompt. startsics actually starts several programs, see
+the Setup section for details. All programs are started by means of a 
+shell script called
 <b>keepalive</b>. keepalive is basically an endless loop which calls
 the program again and agaian and thus ensures that the program will
 never stop running.   
@@ -142,12 +176,8 @@ 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.
 <LI> Restart the SICServer. Watch for any messages about things not being 
 connected or configured.
 <LI> Restart and reconnect the client programs.