linse/sics
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

- Enhanced and debugged histogram memory for AMOR

Browse Source 
* 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
2001-08-17 14:33:05 +00:00
parent a538361516
commit db6c355f44
56 changed files with 4060 additions and 426 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
doc/manager/alias.htm
View File

@ -5,7 +5,8 @@
<BODY>
<H1>Aliases in SICS</H1>
<P>
SICS knows two different kinds of aliases: object aliases and command
SICS knows three different kinds of aliases: object aliases,
runtime aliases and command
aliases. This is confusing but finds its explanation in the structure
of SICS internals.
</P>
@ -22,7 +23,20 @@ command:
<DT>SicsAlias newname oldname
<DD>This command installs newname as alias for the object oldname.
</dl>
SicsAlias can only be used within initialization scripts.
SicsAlias can only be used within initialization scripts. SicsAlias is
considrered deprecated and can be replaced with the superior runtime
aliases described below.
</p>
<h2>Runtime Aliases</h2>
<p>
Runtime aliases are full object aliases which can be configured into the
system at run time by a SICS manager. The syntax looks like this:
<dl>
<dt>definealias SICSobject aliasname
<dd>This defines aliasname to be the alias for the SICS object SICSobject.
<dt>definealias aliasname
<dd>This command deltes the alias aliasname.
</dl>
</p>
<h2>Command Aliases</h2>
<p>

3
doc/manager/hwini.htm
View File

@ -46,7 +46,6 @@ number of the motor in the EL734 motor controller.
El734DC motor controller. The
parameters host, port, chan have the meanings defined above. no is the
number of the motor in the EL734DC motor controller.
</DL>
<DT>MakePIMotor name c804 pararray
<DD>Creates a motr name connected to a C804 motor controller from the
manufacturer Physik Instrumente. Pararray is a Tcl array holding the
@ -64,6 +63,7 @@ number of the motor in the EL734DC motor controller.
<dd>Creates a piezo electric positioning device. Again the controller is a
Physik Instrumente controller. pararray has the same meaning as for the
C804 controller given above.
</DL>
</p>
<h3>Counting Devices</h3>
@ -79,7 +79,6 @@ failures. This can be used in a instrument simulation server.
<DD>This command creates a single
counter name, using an EL737 driver. The counter is at host host, listening
at port port and sits at serial port chan.
</DL>
<DT>MakeHMControl name counter hm1 hm2 hm3
<dd>At some instruments (for instance TRICS) multiple counters or
histogram memories are controlled by a master counter which watches

58
doc/manager/iscan.htm
View File

@ -91,26 +91,48 @@ NeXus files.
</P>
<p>
<h2>User Defined Scans</h2>
In some cases users wish to exert more influence about the scan. Especially
about what gets counted. In order to cater for this a hook was implemented
in the internal scan command. This hook allows to run a tcl procedure at each
scan point. This Tcl procedure is required to return a string containing
up to 11 values for counters and monitors. The first value will be the one
used as counts in the data file. The others will be placed as monitors.
Please note, that only the first three monitors are written to file as of
current. In order to use this facility the following steps are required:
<p>
In some cases users wish to control the scan more closely, i.e. do
multiple counting operations at the same point etc. This is especially
true when magnets are involved. In order to do this a facility has
been provided which allows the user to specify a macro routine which
is called at each point. This macro routine then performs all
necessary operations and then is responsible for storing its data. In
order to this commands have been defined which allow to append a line
to the scan data file and to store measured data in the scan data
structure. The last feature is necessary in order to make scan status
displays and scan analysis, such as center detection, work. The
following steps are required:
<ol>
<li>Write The Tcl-macro procedure to run. Make sure that is creates proper
output.
<li>Test the Tcl-procedure in SICS.
<li>Install the Tcl-procedure into the scan object with the
xxscan command name syntax.
<li>Make the scan command use the Tcl procedure by setting channel to -10 with
the xxscan setchannel -10 command.
<li>Write a suitable macro procedure for the actions required at each
scan point. The procedure signature looks like this:
<pre>
proc myScanPoint {point} {
}
</pre> And will be called with the number of the current scan point as
a parameter. Besides all usual Tcl and SICS commands the following
special commands may be used:
<dl>
<dt>xxxscan line text
<dd>Appends all the text after line to the scan data file.
<dt>xxxscan storecounts c1 c2 c3 c4 ...
<dd>Stores the first number given as count data, all the others as
monitor values in the internal scan data structure.
</dl>
<li>Test the procedure.
<li>Switch the internal scan command command into user scan mode with
the command:
<b>xxxscan configure user</b>
<li>Assign your procedure to the internal scan command with the
command: <b>xxxscan command myScanPoint</b>
<li>Use normal scan commands for doing your scan.
<li>Switch the internal scan command into normal mode with the
command:
<B>xxxscan configure standard</b>.
</ol>
A hint: If you need to control the counting operation as well (because you
are not using a counter to count) just run the scan object with a very low
preset and do the counting yourself in your procedure.
In all this replace xxxscan with the name of the internal scan
command.
</p>
</BODY>
</HTML>

1
doc/manager/managerman
View File

@ -53,7 +53,6 @@ which is described elsewhere.
%html iscan.htm 2
%html alias.htm 2
%html cron.htm 2
%html client.htm 1
%html ../user/trouble.htm 1
%html move.htm 1
\end{document}

96
doc/manager/move.htm
View File

@ -1,59 +1,59 @@
<HTML>
<HEAD>
<TITLE>Moving SICS</TITLE>
<TITLE>Replacing Hardware</TITLE>
</HEAD>
<BODY>
<H1>Moving SICS</H1>
<H2> Moving the SICS Server to a new Computer</h2>
<P>
Moving the SICS server from one computer to another involves quite a
few steps:
<OL>
<LI>Recreate the directory structure on the new computer.
<LI>Copy all necessary files across:
<ul>
<li> A copy of the SICServer.
<li> A copy of the instrument configuration file.
<li> All macro scripts used by this instrument.
<li> The DataNumber file.
<li> The necessary data file dictionary or header description files.
<li> The client programs.
</ul>
All necessary files should be available from backup or under the
/data/lnslib/sics/instrument tree on lnsa10.
<LI>Edit the instrument configuration file and make all pathnames reflect the
new directory structure. It should be enough to adapt the home variable at the
top, but better check. All paths references must be renewed if the directory
structure is changed from the one described <a href = "setup.htm">above</a>.
<LI>Edit the client scripts to reflect the new location of the server. Only the
box and logpath parameters should need to be changed.
<LI> Edit the DataNumber file and set the number above the last valid data file
number used. Otherwise the automatic numbering scheme
for data files gets messed up.
<LI>Test the new Installation!
</OL>
This requires the following steps:
<ol>
<li>Create a new local account on the host computer. There is a
prefabricated account with the credentials: INSTBCK/INSTBCKLNS on
lnsa15.
<li>Run <b>sicsinstall <tt>instrument</tt> </b> in the new instruemnt
account, thereby replacing instrument with the name of the instrument
you are moving.
<li>Create and edit a suitable DataNumber file for the instrument.
<li>Edit the instrument configuration files and adapt the path names
to match the new situation.
<li>Configure the histogram memory to boot from the new computer, se
histogram memory documsntation for instructions how to do that.
<li>Try to start and debug.
</ol>
</P>
<h2>Exchanging the Macintosh Serial Port Server</h2>
<p>In its current configuration at SINQ, SICS requires a Macintosh PC running a serial
port server program. Exchanging this Macintosh requires the following steps:
<OL>
<LI>Exchange the Macintosh physically. Plug everything as it was before the
exchange. Not every Macintosh can be used. Any other Macintosh from another
instrument or the spare Macintosh from the EDV-cabin will do. Other
Macintoshs require some serious screwing and software installation
procedures.
<LI>Edit the instrument configuration file and replace all references to the name of
the old Macintosh PC with the name of the new Macintosh PC.
<LI>Test it!
</OL>
If you do not plug the serial devices back onto the Macintosh as they were, you
need to adapt the channel numbers in the configuration file as well. The standard
plugging scheme for the serial port extension box on the Macintosh is like this:
<OL>
<LI>Motor Controller 1
<LI>Motor Controller 2
<LI>Counter Box
</OL>
<h2>Exchanging the Serial Port Server</h2>
<p>
<ol>
<li>Fetch a new one and make sure that all cables are plugged as
they were in the old one.
<li>Edit the startsics script to start the SerPortServer program with
the name of the new serial port server.
<li>Done!
</ol>
</p>
<h2>Exchanging the Histogram Memory</h2>
<p>
<ol>
<li>Get a new histogram memory computer from either Peter Rasmussen,
the test setup in WHGA/247 or in cases of greatest need, from SLS.
<li>Put into the rack.
<li>Configure the HM boot parameters through the console conneted to
the serial port belonging to the HM. Instructions for this can be
found in the histogram memory documentation.
<li>Include the new HM into the /etc/hosts file of the instrument
computer.
<li>Adapt the instrument configuration file to reflect the new name of
the HM.
<li>Start and debug.
</ol>
</p>
</BODY>
</HTML>

9
doc/manager/setup.htm
View File

@ -17,13 +17,14 @@ The following hardware is usually present for any SICs instrument:
</ul>
The terminal server software is provided by Lantronix, see the
appropriate manuals for the device for a description. The histogram
memories are 6800 VME onboard computers running the VXworks realtime
memories are 68000 VME onboard computers running the VXworks realtime
operating system and some home grown histogramming software documented
elsewhere.
</p>
<h2>Server programs</h2>
<p>
On the instrument computer the following software must run:
For proper operation of an instrument the following software components are
required:
<dl>
<dt>SerPortServer
<dd>This is a TCP/IP server which implements a special protocoll for
@ -40,8 +41,8 @@ software is Markus Zolliker.
instrument control program. Then the server starts a script which
synchronizes the local data directory with the central data storage on
the labarotory server. FileSync is configured through an
initilaization file usually called fs.ini. See the comments therein
for more information.
initialization file usually called fs.ini. See the comments in the
initialization file for more information.
<dt>SICServer
<dd>This is the actual instrument control server. The configuration of
this program is documented in this manual.

48
doc/manager/trouble.htm
View File

@ -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.

2
doc/manager/var.htm
View File

@ -25,7 +25,7 @@ last two digits of the year and an ending. All these components are
controlled by variables.
</p>
<p>
The exact syntax for creating variables lokks like this:
The exact syntax for creating variables looks like this:
<ul>
<li> <b> VarMake name type access </b> creates a simple variable name. The
variable type can be Text, Int or Float. The access parameter defines who

376
doc/master.tex Normal file
View File

@ -0,0 +1,376 @@
\documentclass[12pt,a4paper]{article}
%%\usepackage[dvips]{graphics}
%%\usepackage{epsf}
\setlength{\textheight}{24cm}
\setlength{\textwidth}{16cm}
\setlength{\headheight}{0cm}
\setlength{\headsep}{0cm}
\setlength{\topmargin}{0cm}
\setlength{\oddsidemargin}{0cm}
\setlength{\evensidemargin}{0cm}
\setlength{\hoffset}{0cm}
\setlength{\marginparwidth}{0cm}
\setlength{\parindent}{0pt}
\setlength{\parskip}{0.5cm}
\newtheorem{error}{Error}
\begin{document}
\begin{center}
{\huge Sinq Systems Overview and Documentation Guide}
\\
Revision: \today \\
Author: Mark K\"onnecke
\end{center}
\tableofcontents
\clearpage
\section{Introduction}
This document gives an overview about all the hardware and software systems
involved in SINQ instrument control. It describes the relationships between
the various pieces and points to additional documentation, if available.
A copy of all documents referred in this paper is stored at: /data/lnslib/distribution/sics/doclib. If they exist in electronic form, this is. The SICS user
and manager information is available on the WWW starting from http://lns00.psi.ch/.
\section{Hardware Overview}
For each SINQ instrument the following computing hardware is available:
\begin{itemize}
\item A dedicated instrument workstation. Most of them are Compaq Alpha stations
running True64Unix. One workstation is still running OpenVMS. Two instruments,
POLDI and RITA--2, are controlled through Intel--PC's running Linux.
\item A TCP/IP terminal server providing access to serial ports.
\item Optionally, there are 1-3 histogram memory computers installed for those
instruments which have area detectors. These histogram memory computers are
Motorolla 6800 VME board processors running the vxWorks realtime
operating system.
\end{itemize}
Most instrument hardware is accessed through RS--232 interfaces and the terminal
server. Histogram memories are accessed through the TCP/IP network. Generally
ethernet is used as the main instrument bus.
In addition to the computers at the instrument the following systems are
available:
\begin{itemize}
\item A True64Unix laboratory server (lnsa15) for data management and
primary data anlalysis.
\item True64Unix PSI server systems for data processing.
\item A WWW--server currently installed on lns00.
\item pss123 is a Sun workstation holding the vxWorks development environment.
\end{itemize}
\section{Software Overview}
\subsection{Software at the Instrument}
The main software component at the instrument is the Sinq Instrument Control
Software (SICS). This is a client server system controlling the operation
of the instrument. A central server running on the instrument workstation
implements all the functionality of instrument control. Clients to this
server implement the user interface to the instrument. The protocoll between
clients and the SICS server is a ASCII command protocoll through either
telnet or plain sockets.
RS--232 devices are not directly accessed through the terminal server but
through a special server program, the SerPortServer program. The reasons
for this are both historical and practical as this system permits access
to a given serial port for several clients which is a valuable aid for
debugging. Clients to this SerPortServer such as the SICS server communicate
with the server through a special ASCII protocoll transported through TCP/IP.
The only documentation
for both the SerPortServer and the ASCII protocoll is the source code.
There exists another support program, the FileSync server, on any instrument
computer. This is a little Java server which listens at a UDP port for a
message from SICS. If such a message is recognized or any two hours, this
server starts a shell script which copies new data files to the laboratory
server. This program is again documented only in its configuration file and
the Java source code.
Then there is the TecsServer. This is a server which maintains and configures
Lakeshore temperature controllers used as standard temperature controllers
at SINQ. The only documentation for this program is Markus Zolliker.
On many instruments there are histogram memory computers. These usually run the
following programs:
\begin{description}
\item[bootUtil] a utility running when the histogram memory is booted which
starts all the other tasks and configures the histogram memory from its
command line parameters.
\item[sinqHMfiller] this task reads data from the electronics and stores it
into the right histogram.
\item[SinqHMserver] This process handles the TCP/IP communication with
clients of the histogram memory. It spawns child processes for doing so.
\end{description}
The histogram memory software, its setup and the TCP/IP protocoll for its
control is described in great detail in the documents titled:
\newline\centerline{Software Support Notes for the SINQ Histogram Memory}
and \newline
\centerline{The Sinq histogram memory, SinqHM}
both authored by David Maden. The sources for these documents are distributed
with the source code for the histogram memory.
The SICS software is described in a variety of documentation:
\begin{itemize}
\item There is user documentation for various instruments.
\item The installation and setup of SICS on an instrument computer is
described in the "SICS Manager Manual".
\item The programming concepts of SICS are discussed in the "SICS Programmers
Reference".
\item An 90\% complete description of SICS source code modules is available
as "SICS Reference Manual".
\end{itemize}
One instrument, TASP, is run with the TASMAD software from ILL which runs
on VMS systems. A user documentation for this system is available at: \newline
\centerline{http://sinq.web.psi.ch/sinq/doc/tasmad.html}
Some configuration issues are explained in this docuement as well. Further
documentation exists only in form of David Maden and an analysis of the
source code.
The RITA--2 instrument from Ris\o{ } runs the TASCOM software.
This software is quite well documented in various documents which can be
obtained at WHGA/247 or directly from the Ris\o{ } team and Per Skarup.
\subsection{Facilities at the Laboratory Server(LNSA15)}
\subsubsection{Central Data Repository}
Under the /data/lnslib/data directory there exists a central storage area for
data files measured at the instruments. Newly measured data files are
automatically mirrored to this area once a measurement has finished.
Not surprisingly there is a subdirectory for each instrument at SINQ.
These instrument directories contain further subdirectories for each year
of SINQ operation which hold the actual data files.
\subsubsection{The SINQ File Database}
Right early on it was decided to separate the file archival function from the
file search facility. For this decision there are two reasons:
\begin{itemize}
\item If more search criteria are required, only the database will need to be
rebuilt.
\item Most SINQ data files are binary. A special tool was needed anyway in
order to extract the searchable information from the data files.
\end{itemize}
The SINQ File database is described in more detail in the document:\newline
\centerline{The SINQ File Database}
which is part of the source distribution for the system. Here only an
overview of the SINQ database system is given.
The SINQ File Database consists of the following components:
\begin{itemize}
\item The database itself. This is the SQL database system mSQL from
Hughes Technology.
\item Any night the unix utility cron starts a shell script which is
responsible for updating the database. This is done with two special
utility programs:
\begin{itemize}
\item nx\_dbupdate scans a given directory for new files which are not
yet in the database. If such a file is found, the data fields for the
database are extracted and entered into the database.
\item The Java program ScanScan does the same job as nx\_dbupdate for
ASCII files.
\end{itemize}
\item A querying system. Curently the only query interface is a WWW--interface
installed at the WWW--server.
\end{itemize}
\subsubsection{The NeXus Data Server}
In order to provide access to SINQ data file to various clients on the
network a NeXus Data Server was installed. This piece of software
is required in order to support the "Load Old File" facility in the
Java status display clients for various instruments.
\subsubsection{The CVS Repository}
CVS is a shortcut for Concurrent Version control System. This is a system for
keeping track of various versions of software. As a lot of source code has
to be maintained at SINQ and we aspire to have several people working at
it such a control system became necessary. The LNS setup is described in
the document:\newline
\centerline{The LNS CVS Repository}
This document also explains how to get hold the source code for most
of the software used at SINQ.
\subsubsection{Backup}
The laboratory server is also the central backup server for SINQ. Backups are
performed with the Legato networker software onto a tape jukebox holding
5 tapes with 20GB capacity each. The following items are backed up through
this system:
\begin{itemize}
\item The laboratory server.
\item The instrument accounts on the instrument computers.
\item The lnsdata and lnslib shares of the lns00 Windows--NT server.
\end{itemize}
This backup system is a protection against a major harddisk failure. It is no
archive system. Though backup tapes are held as long as possible it
cannot be guaranteed that files older then half a year can be recovered.
The backup software is described in the documentation coming with the
system. No further documentation exists, but the setup can be viewed
through the nwadmin application.
\subsubsection{Motor Parameter Backup}
At SINQ the PSI EL--734 motor controllers are used. These motor controllers
hold a set of parameters for each motor. As a safeguard against instrument
scientists gone wild or a loss of parameters due some electronic or
electrical incident these motor parameters are saved weekly. This happens
on wednesdays mornings. The unix utility crom triggers the process and
starts the script savemot which in turn does all necessary things. The
actual saving of the motor parameters is accomplished with David Maden's
el734 program. The saved parameters end up in the /data/lnslib/motors
hierarchy. There exists a directory for each backup date which in turn
holds a subdirectory for each instrument which holds the files with
the saved parameters. All necessary shell scripts and programs can be
found in the /data/lnslib/motors/bin directory.
\subsubsection{License Server}
Unfortunately some people use the proprietary IDL programming system. This
system requires a license server to run on some computer. This license
server is also installed together with the actual IDL distribution on the
laboratory server. LNS has bought a number of network licenses of IDL.
This means at any time only a certain number of people can use IDL on the
network. When IDL starts up it requests a license from the license server
and gives it back when it finishes. This only works if the license server
still has enough spare licenses. This implies that any IDL user should
close his program when she is done and not leave it running all weekend.
The installation of the license server is described in the IDL installation
instructions. License servers are black magic and should be handled by
wizards only. There are only two things which can be done easily:
\begin{enumerate}
\item Check if it is running. the command: \begin{verbatim}
ps -A | grep lmgrd
\end{verbatim} should yield at least two entries.
yield at least two entries.
\item Start it if it is not running:
\begin{enumerate}
\item Become root
\item Run: /usr/opt/idl/idl/bin/idlstart
\end{enumerate}
\end{enumerate}
\subsection{Software at the WWW--server}
The WWW--server running at lns00 does not provide static information only but also
active content calculated at runtime. The following services are
implemented:
\begin{itemize}
\item Keyword search in the SICS documentation.
\item Searching the SINQ file database for files matching various criteria.
\item Display of the current instrument status for a couple of instruments.
\item An experimental WWW control system for powder diffractometers.
\end{itemize}
Most of these services are provided through java servlets. In order to do this
a servlet engine was needed. The combination Apache WWW-server and Apache
JServ was choosen. However, it is planned to exchange the latter component
by the Jakarta engine in the near future.
The database search servlets are described in more detail in the document:
\newline \centerline{The SINQ File Database}
the status display and control servlets in the document:\newline
\centerline{The SICS WWW--servlet System}
. Both documents are part of their respective source code packages.
The SICS documentation searching system is built on top of the program SWISH-E which is available
from http://sunsite.berkeley.edu/SWISH-E.
The actual search is performed through a TCL--cgi script which calls the swishe
application with appropriate parameters. This script can be found as
swishsearch.cgi together with a batch file to start it properly
(swishsearch.bat) in the cgi-bin directory of the WWW hierarchy on lns00.
Prerequisite for such a search is the existence of an index file. This must
be created offline after any major change to the documentation. In order to
create this index, cd into the sics directory of the WWW hierarchy and run:
\begin{verbatim}
d:\bin\swishe sics.config
\end{verbatim}
This must be done on the lns00 computer. The placement of the index file,
swishe executable and the root for serving documents are configured in
sics/sicssearch.html and swishsearch.cgi. For more information about
swish-e see the homepage mentioned.
\section{Access Patterns}
In order to understand the system better it is useful to look at the flow
of information and the collaboration of the individual components in more
detail.
\subsection{Data Files}
\begin{enumerate}
\item Data Files are generated by the instrument control programs at the
instrument computer.
\item Data Files are automatically mirrored to the central repository
on the laboratory server lnsa15. This happens through the FileSync server,
a shell script and last not least the unix rsync utility. All this is installed
at the instrument computer.
\item Nightly new files are scanned for relevant information and their
characteristics are entered into the database system on lnsa15.
\end{enumerate}
\subsection{SICS servers}
SICS instrument control servers usually communicate with the terminal servers
through the SerPortServer program, with temperature controllers through the
TecsServer and directly via TCP/IP with the histogram memory computers.
\subsection{SICS Java Clients}
The SICS Java clients access the SICS servers on the selected instruments
workstation. Most Java clients can display data from previously measured
files. Such data is accessed through the NeXus Data Server running on the
laboratory server lnsa15.
\subsection{WWW Services}
The file search service on the WWW--server lns00 accesses the database
server running on the laboratory server lnsa15.
The instrument status display servlets on the WWW--server lns00 access the
SICS instrument control servers on the appropriate instrument computers
for data.
\section{Maintainance Tasks}
\subsection{Yearly Maintainance}
The only maintainance task at SINQ shutdown is to disable the cron job on
lnsa15 which performs the motor parameter backup.
Whith each new year a couple of things must be done in order to keep the
system ship shape:
\begin{enumerate}
\item On each instrument computer:
\begin{itemize}
\item Create a new subdirectory for data files for the new year.
\item In the new subdirectory create a DataNumber file with the data file
number set to 0.
\item Edit the path names in the data file mirroring script to point to the
new years subdirectory. This script is usually called {\tt instsync} with
inst replaced by the name of the instrument.
\item Edit the instrument configuration file and adapt the path names for
the data directory and the DataNumber file for the new year.
\end{itemize}
\item On the laboratory server lnsa15:
\begin{itemize}
\item Reenable the motor parameter backup cron job.
\item Create new subdirectories for the new year in the data hierarchy.
\item In /data/lnslib/lib/nxdb create new configuration files for the new
year. Edit them to point to the new years subdirectory. Edit the
updatenxdb shell script to use the newly created configuration files.
Keep the old ones as they may come in handy if the whole database may
require an update.
\end{itemize}
\item On the WWW--server lns00:
\begin{itemize}
\item Add the new year into the html--pages for the data file search.
\item Check the configuration file for the status servlets, sics.conf,
for necessary updates caused by computer changes.
\end{itemize}
\end{enumerate}
Do these things quite early on in the year. People start measuring background
quite early!
\subsection{Exchange of Instrument Computers}
In order to keep up with ageing 1-2 computers have to be exchanged any year.
A instrument computer change requires the following adaptions:
\begin{enumerate}
\item Edit the instrument configuration file and change all occurences of
the old computers name to the new name.
\item On lnsa15 as user lnslib: enter the new computer name into the
.rhosts file. This is required for the mirroring to work.
\item For the Java clients edit lnet/SINQConfig.java to point to the
new computer and rebuild all clients. Redistribute them as well.
\item For the WWW status, adapt the sics.conf file on lns00 and restart
the WWW-server.
\end{enumerate}
\end{document}

6
doc/user/system.htm
View File

@ -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

195
doc/user/trouble.htm
View File

@ -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.