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

PSI sics-cvs-psi_pre-ansto

Browse Source
This commit is contained in:
koennecke
2003-06-13 00:00:00 +00:00
committed by Douglas Clowes
parent 2e3ddfb6c6
commit 3ffd0d8af4
1099 changed files with 318432 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
doc/manager/alias.htm Normal file
View File

@ -0,0 +1,59 @@
<HTML>
<HEAD>
<TITLE>Aliases in SICS</TITLE>
</HEAD>
<BODY>
<H1>Aliases in SICS</H1>
<P>
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>
<h2>Object Aliases</h2>
<p>
An object alias is another name for a first class object installed
into the SICS interpreter. For instance a second name for a motor. For
instance the motor twotheta is quite often aliased to a4. Such an
alias can be used like a normal SICS objects. Even in commands which
access internal SICS interfaces like the drive command or
others. Object aliases are installed into SICS with the SICSAlias
command:
<DL>
<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 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>
Command aliases are shortcuts for lengthy commands. For instance one
might want to define A4LL as a shortcut for "a4 softlowerlim". This is
just to save typing or adapt SICS to MAD users who appear to have an
unlimited memory for 2-4 letter acronyms. It is possible to redefine a
SICS object with this for instance to define tt as an alias for
temperature. However if one tries to use tt in a drive command it will
fail because it is just a text replacement. A command alias can be
installed into SICS at any time with manager privilege and the
command:
<DL>
<DT>alias shortcut bla bla bla ....
<DD>This define shortcut as an alias for everything behind it.
</DL>
A shortcut may take parameters.
</p>
</BODY>
</HTML>

55
doc/manager/client.htm Normal file
View File

@ -0,0 +1,55 @@
<HTML>
<HEAD>
<TITLE>SICS Client Configuration</TITLE>
</HEAD>
<BODY>
<H1>SICS Client Configuration</H1>
<P>
Currently, SICS clients are written in Tcl/TK. This means that these programs
are just scripts wich can be edited. Such editing is necessary in order to let
the clients know how to connect to a server. All client configuration
information is kept in an array named INI which is at the very top of the file.
Configurable values in INI are:
<DL>
<DT> DefUser
<DD> The SICS user name for the initial logon to the server when connecting.
<DT>DefPasswd
<DD> The password of the default user for logon.
<DT>ServerPort
<DD> The port number where the server is listening.
<DT>InterruptPort
<DD> The interrupt port number of the server.
<DT>box
<DD> The computer on which the SICS server is running.
<DT>usPasswd
<DD>The password of the SICS user. This is used as password when setting
user rights from the menu.
<DT>muPasswd
<DD>The password of the SICS managers. This is used as password when setting
user rights from the menu.
<DT>logpath
<DD>Only for the command line client. On request of the SICS users each
command line client logs all I/O into a logfile. This logfile resides on the
computer running the SICS server. This allows SICS managers to check what
user have done to the machine. The logpath element defines the path to the
directory where the automatically
created log files are kept on the computer running the SICS server.
</DL>
The rest of the parameters and the file is programmers only. Reasonable values
for those parameters can be found in the server configuration file. And of course,
you need to know where the server is running.
</P>
<p>
At the very top of the client script there is the full path name of the Tcl/TK
interpreter to run in. This must be a wish for the command line client and a
blt_wish for the status display client. This may need to be changed if a client
comes up with: command not found. Valid copies of these executables can be
found in /data/lnslib/bin. Tcl/TK needs own libraries of scripts as well. The
places where these libraries sit is defined through the environment variables
TCL_LIBRARY and TK_LIBRARY. Suitable libraries are under /data/lnslib. For
details inspect /data/lnlib/bin/lns.login. When moving a client to a machine
where the clients need to run stand alone this stuff needs to be copied and
TCL_LIBRARY and TK_LIBRARY properly defined in the .login file.
</p>
</BODY>
</HTML>

68
doc/manager/cliinst.htm Normal file
View File

@ -0,0 +1,68 @@
<HTML>
<HEAD>
<TITLE>Installing SICS Java Clients on PC's</TITLE>
</HEAD>
<BODY>
<H1>Installing SICS Java Clients on PC's</H1>
<P>
Some of the newer SICS clients are written in Java. Java is a platform
independent system. This means the SICS client applications can be run as
native PC systems as well. Both at home and at SINQ. In order to do this two
pieces of software are required:
<ul>
<li>A Java Runtime system.
<li>The SICS application.
</ul>
And the two of them need to be married which each other in some secret way.
This document tells you how to do it.
</P>
<h2>Installing SICS Java Clients on IBM compatible PC's</h2>
<p>
A prerequisite for the installation of the software is either the Windows 95
or Windows NT operating system. Pure DOS or Windows 3.* systems won't do.
</p>
<p>
Installing the java runtime on your computer is easy: On the laboratory
Windows NT server, lns00, there exists a share called lnslib. Below lnslib
there is a directory called java. In this directory there is a executable
file called jdk115-win32. Simply double clicking that one will invoke an
installer which installs java on your PC's harddisk.
Answer questions as required and soon you will be done.
</p>
<p>
In the same directory: lns00//lnslib/java, the SICS client application files
can be found as well. Currently available are:
<ul>
<li>sicsclient.jar or zip for the SICS Command Line Client
<li>powderstatus.jar or zip for the powder diffractometer status display (DMC and
HRPT).
<li>sansstatus.jar or zip for the SANS status display.
</ul>
Copy those files wherever you like on your harddisk. But remember where you
put them. You may even consider to use the ones stored at lns00.
</p>
<p>
Now the java run time and the SICS application need to be married. This is
done via batch files. Template batch files to be configured by you are
stored at lns00//lnslib/java. Currently availabel are:
<ul>
<li>sics.bat for the Sics Command Line Client
<li>powderstatus.bat for the Powder Diffractometer Status Display
<li>sansstatus.bat for the SANS Status Display
</ul>
Copy the required batch files to a place somewhere on your path. Copying
alone does not do the job, the batch files need to be configured. Edit the
batch file with notepad. Make the variable jheim point to the directory
where you installed the java run time kit. Set the variabel sheim to the
directory to which you copied the SICS application jar file.
</p>
<p>
Then you should be done. You may start the application by invoking the batch
file from the command line. You may also create a shortcut on your desktop
to the batch file using standard windows procedures. If you start the
application from the desktop you also get a DOS window each time. If you
dislike this go into Properties/shortcut of the shortcut on the desktop and
configure the textfield labelled Run to Minimized.
</p>
</BODY>
</HTML>

217
doc/manager/command.htm Normal file
View File

@ -0,0 +1,217 @@
<html>
<head>
<title>Command Initialisation</title>
</head>
<body>
<h2>Command Initialisation</h2>
<p>
Besides the general SICS commands which are available for all instruments,
there exist instrument specific commands. Such instrument specific
objects are configured into the system through special commands in the
initialisation file. Such special commands are described here.
<DL>
<DT>MakeRuenBuffer
<DD>MakeRuenBuffer makes the R&#252;nBuffer system available.
<DT>MakeDrive
<DD>MakeDrive craetes the drive command.
<DT>MakeScanCommand name countername headfile recoverfil
<DD>MakeScanCommand initialises the SICS internal scan command. It will be
accessible as name in the system. The next parameter is the name of a valid
counter object to use for counting. The next parameter is the full pathname of
a header description file. This file describes the contents of the header of
the data file. The format of this file is described below. The parameter
recoverfil is the full pathname of a file to store recover data. The internal
scan command writes the state of the scan to a binary file after each scan point.
This allows for restarting of aborted scans.
<DT>MakePeakCenter scancommand
<DD>MakePeakCenter initialises the peak analysis commands peak and center. The
only parameter is the name of the internal scan command.
<DT>DMCInit
<DD>DMCInit creates the DMC StoreData command. This command writes NeXus files
for DMC.
<DT>InitSANS dictionary-filename
<DD>InitSANS creates the StoreData command for SANS. This command writes
the current state of the instrument into a NeXus file. The structure of the
NeXus file is described in a special dictionary file which is a required
parameter to this command. For details about the format of this file see
the NXDICT-API documentation.
<DT> Publish name access
<DD> The SICS server uses Tcl as its internal macro language. However, it was felt
that the whole Tcl command set should not be available to all users
from the command line without any protection. There are reasons for this: careless use
of Tcl may clog up memory, thereby grinding the system to a halt. Invalid Tcl statements
may cause the server to hang. Last not least, Tcl contains commands to manipulate files
and access the operating system. This is a potential security problem when the server
is hacked. However, in order to make macro procedures available the Publish
command exists. It makes a Tcl command name available to SICS users with the
access code access. Valid values for access are: Internal, Mugger, User and Spy.
<DT> MakeMulti name
<DD> SANS uses a special syntax feature where several motors are grouped into a
component group. For example beamstop or detector. MakeMulti creates such a
group with the name name. Once such a group has been created, it has to be
configured. For this a few configuration commands are available:
<DL>
<DT>name alias motname compname
<DD> This command makes motor motname available as component motor compname.
For example: <b>bs alias bsx x</b> makes motor bsx available as x in the beamstop
group. Then the bsx motor can be driven by the command <b>bx x = 12.</b>.
<DT> name pos posname motname value motname value ....
<DD> The group command supports the notion of named positions. This means that
a special combination of angles can be accessed through a name. This commands
defines such a named position with the name posname. posname is followed by pairs
of motorname value which define the position.
<DT>name endconfig
<DD>Once a group has been completely defined the configuration process must be
ended with endconfig.
</DL>
<DT>MakeMono name M1 M2 M3 M4
<DD>This command creates a crystal monochromator object. Such a
monochromator object is necessary for the usage of the wavelength or energy
variables. The parameter name defines the name of the monochromator object
in the system. M1 and M2 are the names of the Theta and two Theta motors
respectively. M3 is an optional parameter defining a motor for driving the
horizontal curvature. M4 is an optional parameter defining a motor for
driving the vertical curvature of the monochromator.
<DT>InitToken tokenpassword
<DD> This command initialises the token control management system with the
token command. The single parameter tokenpassword specifies the password for
the token force command.
<DT>MakeHKL theta omega chi phi
<DD>MakeHKL creates the hkl command for the calculation of settings for a four
circle diffractometer. The four parameters are the names of the motors
driving the two theta, omega, chi and phi circles of the diffractometer.
These motors must already exists before this command may succeed.
<DT>MakeDifrac tth om chi phi cter
<DD>This command installs the Difrac subsystem into SICS. Difrac is a
whole F77 package for controlling a four circle
diffractometer. Afterwards Difrac commands are available in SICS with
the prefix dif, for example dif ah calls the difrac ah command. Difrac
is described in more detail elsewhere. The parameters are the four
circle motors two theta, omega, chi and phi and the counter.
<DT>MakeOptimise name countername
<DD>This command installs the Peak Optimiser into the SICS server. The Peak
Optimiser is an object which can locate the maximum of a peak with respect
to several variables. The arguments are: name, the name under which the Peak
Optimiser can be accessed within SICS and countername, which is the name of
an already configured SICS counter box.
<DT>MakeTRICSNEXUS datanumber fileroot dictionaryfile
<DD>MakeTRICSNEXUS creates the object for writing TRICS NeXus files. This
command creates a new command with the name nexus which is is used for
interacting with this object. MakeTRICSNEXUS expects three parameters: The
first one is the name of a data number object used for automatic data file
name creation. The second is the full pathname to the directory where the
dat should go. The third one is the full path name of the NXDICT dictionary
file to use for positioning data in the NeXus file. Besides these explicit
parameter the nexus object relies on the presence of a plethora of other
objects in the system. The MakeTRICSNEXUS command should be at the end of
the file.
<DT>MakeAmor2T name da
<DD>This creates a virtual two theta motor for the reflectometer
AMOR. The two parameters are the name of the object in SICS and a
Tcl-array with configuration parameters. The needed elements of this
array are:
<DL>
<DT>mom
<DD>The monochromator omega motor.
<DT>som
<DD>The sample omega motor.
<DT>coz
<DD> The height movement of the detector.
<DT>cox
<DD> The movement of the detector along the optical bench.
<DT>stz
<DD> The height movement of the sample connected to the omega circle.
<DT>soz
<DD> The height movement of the sample table.
<DT>d4b
<DD>The motor moving the whole diaphragm 4 up.
<DT>d5b
<DD>The motor moving the whole diaphragm 5 up.
<DT>com
<DD>The omega mevement of the detector.
</DL>
An example:
<pre>
set a2t(mom) mom
set a2t(som) som
set a2t(coz) coz
set a2t(cox) cox
set a2t(stz) stz
set a2t(soz) soz
set a2t(d4b) d4b
set a2t(d5b) d5b
set a2t(com) com
MakeAmor2T a2t a2t
</pre>
creates a virtual AMOR two theta motor with the name a2t.
<dt>MakeStoreAmor hm
<dd>Creates an object for writing reflectometer data files. The name
of the command is storeamor. The parameter hm denotes the histogram
memory object.
<dt>MakeAmorStatus name scan hm
<dd>This creates a helper object for the reflectometer status display
with name name. This object performs some operations on behalf of the
status display for the reflectometer AMOR. The parameter scan denotes
the name of the scan object. The parameter hm the name of the
histogram memory object.
<DT>MakeMesure name scanobject hklobject omega o2t fileroot datanumberobject
<DD>MakeMesure installs the single counter four circle diffractometer
measurement procedure into SICS. It will be accessible as object name
afterwards. MakeMesure takes a lot of parameters:
<dl>
<Dt>scanobject
<DD>The name of the internal scan object.
<DT>hklobject
<DD>The name of the object which does crystallographic calculations.
<DT>omega
<DD>The name of the motor driving omega.
<DT>o2t
<DD>The name of the omega two theta virtual motor for omega two theta scans.
<DT>fileroot
<DD>The full path to the data file directory without final /
<dt>datanumberobject
<DD>The name of the SICS data number object for creating unique file
numbers.
</dl>
<DT>MakeSANSWave name velo_name
<DD>> Installs a velocity selector wavelength variable into SICS. The
variable will have the name given as first parameter. Usually lambda is a
good idea. The second parameter, velo_name, is the name of the velocity
selector which is controlled by this wavelength variable.
<DT>MakeHklscan scan hkl
<DD>Installs a command named hklscan which allows scans in reciprocal space
expressed as Miller Indizes on a four circle diffractometer. scan must be
the name of a scan object as created by MakeScanCommand. hkl is the name of
a hkl calculation object as created by makeHKL.
<dT>MakeXYTable myname
<DD>Creates a XYTable object with the name myname. This object can store a
list of x-y values.
</DL>
</p>
<h4>The Scan Command Header Description File</h4>
<p>
The SICS internal scan command allows to configure the contents of the header of
the ASCII scan data file through a template header file. This section describes
the contents of this file. This header description file consists of normal
text mixed with a few special keywords. The normal test will be copied to
output verbatim. The keywords indicate that their place will be replaced by
values at run time. Currently only one keyword per line is supported.
Keywords recognized are:
<DL>
<DT>!!DATE!!
<DD>Will be replaced with the file creation date.
<DT>!!VAR(name)!!
<DD>Will be replaced with the value of the SICS variable name.
<DT>!!DRIV(name)!!
<DD>Will be replaced with the value drivable variable name. Drivable variables are
all motors and all variables which may be used in a drive or run command.
<DT>!!ZERO(name)!!
<DD>Will be replaced with the value of the softzero point for motor name.
<DT>!!FILE!!
<DD>Will be replaced by the creation name of the file.
</DL>
Please note that text behind such a keyword in the line will not be copied to
the output.
</p>
</body>
</html>

18
doc/manager/cron.htm Normal file
View File

@ -0,0 +1,18 @@
<HTML>
<HEAD>
<TITLE>Reoccuring Tasks</TITLE>
</HEAD>
<BODY>
<H1>Reoccuring Tasks</H1>
<P>
Sometimes it may be necessary to execute a SICS command at regular
time intervalls. This can be achieved with the sicscron command:
<DL>
<DT>sicscron intervall bla blab blab
<DD>This command installs a reoccuring task into SICS. The first
parameter is the intervall in seconds between calls to the SICS
command. Everything behind that is treated as the command to execute.
</DL>
</P>
</BODY>
</HTML>

436
doc/manager/hwini.htm Normal file
View File

@ -0,0 +1,436 @@
<html>
<head>
<title> SICS Hardware Configuration</title>
</head>
<body>
<h2>SICS Hardware Configuration</h2>
<p>
Hardware is configured into the SICS system by executing special hardware
configuration commands from the server initialisation file. These commands
are described here. Much SICS hardware is hooked up to the system via RS-232
interfaces. The SICS server communicates with such devices through a serial
port server program running on a Macintosh PC. All such devices require on
initialisation the following parameters:
<ul>
<li><b>hostname</b> The name of the macintosh computer.
<li><b>port</b> The port number where the serial port server program is
listening for requests. It is given on the Macintosh screen when the serial
port server is running. It is usually 4000.
<li><b>channel</b> The number of the RS-232 interface on the Macintosh. 0 is
the standard Macintosh modem port, 1 is the standard Macintosh printer port,
2 is the first connector on the interface extension box. This leads to much
confusion which can be healed with a simple rule: If a device is connected
to the Macintosh serial port extension box, then its channel number is the
interface number on the box plus one.
</ul>
</p>
<h3> Motors</h3>
<p>
The following commands are available to install motors into the system:
<DL>
<DT> Motor name SIM lowlim uplim err speed
<DD> This command creates a simulated
motor with the lower limits lowlim, the upper limit uplim, an ratio of
randomly generated errors err and a driving speed of speed. Use this for
testing and instrument simulation. If err is less then 0, the motor will
not create failures and thus can be used in a instrument simulation server.
<DT>Motor name EL734 host port chan no
<DD>This command creates a stepper motor named name which is controlled through a
El734 motor controller. The
parameters host, port, chan have the meanings defined above. no is the
number of the motor in the EL734 motor controller.
<DT>Motor name EL734DC host port chan no
<DD>This command creates an analog motor named name which is controlled through a
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.
<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
initialization information. The follwoing elements are required in this
array:
<dl>
<dt>Computer, port, channel
<dd>The standard connection parameters.
<dt>upperlimit, lowerlimit
<dd>The limits for this motor.
<dt>motor
<dd>The number of the motor in the motor controller.
</dl>
<dt>Motor name pipiezo pararray
<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.
<dt>Motor name ecb ecbcontroller ecb-number lowerlimit upperlimit
<dd>This creates a motor which is controlled through the Risoe ECB
electronic. The parameters:
<dl>
<dt>ecbcontroller
<dd>The ECB controller to which this motor is connected to. See below
for more on ECB controllers.
<dt>ecb-number
<dd>Number of the motor in the ECB system.
<dt>lowerlimit
<dd>The lower hardware limit for this motors operation
<dt>upperlimit
<dd>The upper hardware limit for this motors operation
</dl>
In contrast to normal motors, the ECB motors have quite a number of
hardware parameters which must be configured. The general syntax to
configure them is: motorname parametername value. The following
parameters are available:
<dl>
<dt>encoder
<dd>0 if there is no encoder for this motor, 1-3 for the encoder used
for this motor.
<dt>control
<dd>The control bit flag. This falg determines if the motor sets a
control bit in the ECB controller. This control bit can be used to
drive air cushions and the like. If required set to 1, else leave at
0.
<dt>delay
<dd>Delay time to wait after setting a control bit.
<dt>range
<dd>The speed range for the motor: 0 for slow, 1 for fast
<dt>multi
<dd>The ECB controller supports up to 24 motors. In some instances
this is not enough. Then one ECB channel can be multiplexed into
several motors. This flag (),1) determines if this is the case.
<dt>multchan
<dd>The multiplexer channel for a multiplexed motor.
<dt>port
<dd>The ECB port a multiplexed motor is using.
<dt>acceleration
<dd>The speed with which the motor accelerates to its final speed.
<dt>rotation_dir
<dd>Rotation direction of the motor.
<dt>startspeed
<dd>Starting speed of the motor.
<dt>maxspeed
<dd>The maximum speed for this motor.
<dt>auto
<dd>Speed in automatic mode
<dt>manuell
<dd>Speed used when driving the motor through the manual control box.
<dt>offset
<dd>When using an encoder: the offset between the motor zero and the
encoder zero.
<dt>dtolerance
<dd>hardware tolerance of the motor.
<dt>step2dig
<dd>conversion factor from encoder steps to physical values.
<dt>step2deg
<dd>Conversion factor from motor pseudo encoder steps to physical
values.
<dt>backlash
<dd>In order to correct for backlash, Risoe motors always approach a
target position from the same direction. In order to do this the motor
has to overshoot and drive back when driving in the wrong
direction. The parameter backlash determines how much to overshoot.
</dl>
ECB motors have another quirck: 8 motors in a rack share a power
supply! This has the consequence that only one of the 8 motors can run
at any given time. In SICS this is directed through the anticollider
module described elsewhere.
</DL>
</p>
<h3>Counting Devices</h3>
<p>
<DL>
<DT>MakeCounter name SIM failrate
<DD>This command creates a simulated single counter
accessible as object name. Failrate is the per centage of invocations
at which the counter will generate a random failure for testing error
treatment code. If failrate is less then 0, there are no
failures. This can be used in a instrument simulation server.
<DT>MakeCounter name EL737 host port chan
<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.
<dt> MakeCounter name ecb ecb-controller
<dd>Installs a counetr on top of the Risoe ECB hardware. The only
parameter is the name of the ECB controller to use.
<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
over presets and the like. This command installs a virtual counter
which does exactly that. The parameters are:
<dl>
<dt>name
<dd>The name of the virtual counter in SICS
<dt>counter The name of the master counter
<dt>hm1, hm2, hm3
<dd>Up to three slave counting devices.
</dl>
</dl>
</p>
<h4>Histogram Memory</h4>
<p>
Due to the large amount of parameters, histogram memories are configured
differently. A histogram memory object is created using a special
creation command. This command is described below. Then a lot of options need to
be configured. The commands used for setting these options and their meanings
are defined in the <a href =
../user/histogram.htm> user </a> documentation because histogram memories
may be reconfigured at runtime. The sequence of configuartion options is
ended with the command hmname init. This last command actually initialises the
HM. Histogram memory objects can be created using the command:
<DL>
<DT> MakeHM name type
<DD> The parameter name specifies the name under which the HM will be
avialable in the system. type specifies which type of driver to use.
Currently three types of drivers are supported: SIM for a simulated HM
, SINQHM for the SINQ histogram memory and tdc for the Risoe histogram memory.
Please care to note, that the SINQHM
requires a EL737 counter box for count control. This counter must have been
defined before creating the HM object.
</DL>
As an example the configuration of a SINQHM HM with the name banana will be
shown:
<pre>
MakeHM banana SINQHM
banana configure HistMode Normal
banana configure OverFlowMode Ceil
banana configure Rank 1
banana configure dim0 400
banana configure BinWidth 4
banana preset 100.
banana CountMode Timer
banana configure HMComputer psds04.psi.ch
banana configure HMPort 2400
banana configure Counter counter
banana init
</pre>
</p>
<h3>Velocity Selectors</h3>
<p>
A velocity selector is configured in a three step process. First a Tcl array
is filled with the necessary configuration options for the actual velocity
selector driver. In a second step the
velocity selector is created with a special command. In a third step the
forbidden regions for the velocity selector are defined. Currently two
drivers for velocity selctors are known: a SIM driver for a simulated
velocity selector and a DORNIER driver for a Dornier velocity selector
hooked to a SINQ serial port setup. The last one needs a parameter array
containing the fields Host, Port, Channel and Timeout. Host, Port and
Channel have the meanings as defined at the very top of this section.
Timeout is the maximum time to wait for responses from the velocity selector.
A large value is required as the dornier velocity selector is very slow.
The second step is performed through the following commands:
<DL>
<DT>VelocitySelector name tilt-motor SIM
<DD> This command installs a simulated velocity selector with the name name
into the system. tilt-motor is used for driving the tilt angle of the
selector. tilt-motor must exist before this command can be executed
successfully.
<DT>VelocitySelector name tilt-motor DORNIER arrayname
<DD> This command installs a dornier velocity selector into the system. name
and tilt-motor have the same meanings as described above. arrayname is the
Tcl-array with the driver configuration parameters.
</DL>
As an example the configuration of a dornier velocity selector named
nvs is shown:
<pre>
set dornen(Host) lnsp25.psi.ch
set dornen(Port) 4000
set dornen(Channel) 6
set dornen(Timeout) 5000
VelocitySelector nvs tilt DORNIER dornen
nvs add -20 28800
nvs add 3800 4500
nvs add 5900 6700
nvs add 8100 9600
</pre>
</p>
<h3>Chopper</h3>
<p>
Chopper systems are handled via a generic controller object. This basicly
consists of two components: One object represents the actual
controller. This basic object allows to query parameters only. Then
there is for each parameter which can be controlled from SICS in this
controller an adapter object. These adapter object are virtual motors
which can be driven with the normal run or drive commands. Currently
two drivers for this scheme exists: one for a simulated device, the
other for the Dornier Chopper Controller at FOCUS. The first step when
initializing this system is the installation of the general controller
object into SICS. This is done with the commands:
<pre>
MakeChopper name sim
MakeChopper name docho mac port channel
</pre>
The first command simply installs a simulated controller.
The second command install a controller with a driver for the FOCUS
Dornier Chopper system. Mac, port and channel are the usual Macintosh
terminal server parameters which describe where the chopper controller
is connected to through its RS-232 interface. After both commands the
controller is available as command name within SICS.
</p>
<p>
A drivable parameter at this controller is installed with a command
similar to this:
<pre>
ChopperAdapter vname cname pname lower upper
</pre>
vname is the name under which the virtual motor will appear in
SICS. cname is the name of the controller object installed into SICS
with the commands in the previous paragraph. pname is the name of the
drivable parameter in the controller. upper and lower are the upper
and lower limits for this parameter. More then one of these commands
can be given for each general controller.
</p>
<p>
After this, the parameter can be modified by a command like:
<pre>
drive vname newvalue
</pre>
</p>
<h3>RS232 Controller Direct Access</h3>
<p>
RS232 controllers connected to a terminal server can be directly accessed
by SICS through the TCP/IP network, bypassing the SerPortServer
program. See the <a href="rs232.htm">description</a> of this facility
for more details. Such a controller can be configured into the system
through the command:
<pre>
MakeRS232Controller name terminalserver port
</pre>
For example:
<pre>
MakeRS232Controller hugo psts213 3004
</pre>
name is the SICS name for the controller, terminalserver is the name
of the terminal server the device is connected to and port is the port
number at which the terminal server publishes the RS232 channel to
which the device is connected. This is usally the port number plus 3000.
</p>
<p>
To be expanded. Please note, that environment devices such as temperature
controllers are dynamically configured into the system at run time.
Therefore the necessary commands are described in the user documentation.
</p>
<h3>GPIB Controller Access</h3>
<p>
GPIB is yet another bus system. Up to 30 devices can share the bus and
transfer data on it. SICS likest to speak to GPIB devices through the
National Instrument ENET-100 TCP/IP bridge. In order for this to work
the National Instruments driver software must have been installed on
the computer running SICS. SICS has to be compiled with the define
HAVENI defined and the proper paths to the header file and library
configured. The an GPIB controller can be installed into SICS with the
command:
<pre>
MakeGPIB name drivertype
</pre>
Name is the name under which the GPIB controller is addressable within
SICS afterwards. drivertype is the driver to use for the GPIB
device. Supported values are:
<dl>
<dt>sim
<dd>Simulation
<dd>ni
<>National instruments driver, see above.
</dl>
The GPIB controller supports a couple of commands for communicating
with devices on the GPIB bus directly. Use with extra care because it
is very easy to lock things up on the GPIB bus. In the following
documantation of the command set it is assumed that a GPIB controller
has been configured into the system under the name <b>gpib</>. Please
note, that managers privilege is required in order to be allowed to
wrestle with this controller.
<dL>
<dt>
</dl>gpib attach controller-no gpib-address gpib-secondary timeout
eos eot
<dd>This attaches the GPIB controller to a certain device at a certain
address for later communication. The return value is an integer
handle which will be used later on a s a handle devID when referring
to the conenction. The parameters are:
<dl>
<dt>controller-no
<dd>The number of the GPIB controller on the computer. There may be
more then one GPIB controllerinstalled on a given system. Usually this
is 0.
<dt>gpib-address
<dd>The GPIB address of the device on the bus.
<dt>gpib-secondary
<DD>GPIB devices may have a seconadry address. This can be specified
with this parameter. Usually this is 0.
<dt>timeout
<dd>The time to wait for answers on the GPIB bus. 13 is 10 seconds and
ussually a good value.
<dt>eot
<dd>A parameter determining the termination mode on this
connection. Consult NI documentation for this or leave at 0.
<dt>eoi
<dd> A terminator. Set to 1 or understand NI documentation for this
parameter.
</dt>
<dt>gpib detach devID
<dd>Breaks the connection described through devID. devID is the return
value from attach.
<dt>gpib clear devID
<dd>Tries to clear the GPIB buffers for the conenction described
through devID. Usually in vain.
<dt>gpib send devID bal bla bla
<dd>sends data to the device at devID.
<dt>gpib sendwithterm devID string terminator
<dd>Sends string to the device at devID. The terminator character
identified through the integer terminator is automatically
appended. Use this to send things which require a
terminator. Terminators included in strings sent by send get messed up
through Tcl!
<dt>gpib read devID
<dd>Reads data from the device at devID and returns it as a string.
<dt>gpib readtillterm devID terminator
<dd>Read from teh device devID unti the terminator character described
through the interger terminator is read. Then return the data read as
a string.
</dl>
</p>
<h3>ECB Controllers</h3>
<p>
ECB controllers are at the heart of the Risoe data aquisition
system. These are essentially Z80 processors wired to the GPIB
bus. Functions can be invoked in this processor by sending a function
code followed by the contents of 4 8 bit registers. As a result the
contents of the registers after the function call are returned. A ECB
can be made knwon to SICS through the initialisation command:
<pre>
MakeECB name gpib-controller gbib-controller-number gpib-address
</pre>
The parameters:
<dl>
<dt>name
<dd>The name used as a token for this controller later on.
<dt>gpib-controller
<dd>the name of the GPIB interface to use. See above.
<dt>gbib-controller-no
<dd>The number of the GPIB board in the system
<dt>gpib-address
<dd>The GPIB address of the ECB on the GPIB bus.
</dl>
Once installed, the ECB controller understands a few commands:
<dl>
<dt>ecb1 func funcode d e bc
<dd>Invoke ECB function funcode with the registers d e b c.Returns the
contents of the registers d e b c. Function codes and register
contents are documented, if at all, in the ECB documentation.
<dt>ecb1 clear
<dd>Tries, usually in vain, to clear the communications interface to
the ECB.
<dt>ecb1 toint char
<dd>A helper function which converts the character char to an
integer. Tcl does not seem to be able to do that.
</dl>
</p>
</body>
</html>

57
doc/manager/ini.htm Normal file
View File

@ -0,0 +1,57 @@
<html>
<head>
<title> Overview of SICS Initialization </title>
</head>
<body>
<h2>Overview of SICS Initialization</h2>
<p>
The command to start the SICServer is: <b> SICServer inifile </b>. So, what
happens at the initialization of the SICS server? First, internally, a set
of standard SICS commands is initialized, than a set of special
initialization commands. These are special commands which help to configure
the SICS server to match the actual hardware present on the hall floor and
to define the commands available later on. Following this, the SICS server
will read the initialization file specified on the command line or servo.tcl
as a default. Using the data supplied in this file, the server will be
configured. At this stage all special initialization commands, all
Tcl-mechanisms and all SICS commands already initialized are available.
After this is done, the server will delete the initialisation commands from
its internal command list (No need to carry them around all the time). Now a
status backup file will be read. This file contains normal SICS statements
which initialise parameter values to the values they had before the last
shutdown of the server. Such a file is automatically written whenever a
normal shutdown of the server happens.
</p>
<p>
The SICS server configuration file is essentially a SICS macro language
file. This implies that all general SICS commands and Tcl mechanisms are
available. Additionally the configuration file (and only the configuration
file) may use special commands for the installation of:
<ul>
<li>SICS server options.
<LI>SICS variables.
<LI>Special commands.
<LI>Hardware
</ul>
</p>
<p>
Actually the SICS servers configuration is rarely stored in one file
but in several files which are included by the main configuration
file. In general the following files are present:
<DL>
<dt>inst.tcl
<DD>Replace inst with the name of the instrument in lowercase. This is
the main initialization file. It should contain all the hardware
initialization.
<dt>instcom.tcl
<DD>Again replace inst with name of the instrument in
lowercase. This file holds instrument specific commands defined in the
Tcl macro language. This file is automatically included by inst.tcl.
<dt>scancommand.tcl, tecs.tcl, log.tcl
<DD>Some macro definitions which are used by so many instruments that
it was deemed appropraite to hold them in separate files. Such files
are included from instcom.tcl.
</dl>
</p>
</body>
</html>

26
doc/manager/inifile.htm Normal file
View File

@ -0,0 +1,26 @@
<HTML>
<HEAD>
<TITLE>SICS Xerver Configuration</TITLE>
</HEAD>
<BODY>
<H1>SICS Server Configuration</H1>
<P>
There is only one executable image of the SICS server for all instruments. The
commands and hardware available for a particular instrument is defined
through the instrument initialisation file. The contents of this file are
described below.
</P>
<!latex-off>
<p>
Go to:
<ul>
<li> An <a href = ini.htm> Overview </a> about SICS initialisation.
<li> A description of SICS <a href = option.htm>options</a>.
<li> A discussion of SICS <a href = var.htm> variables</a>.
<li> Advice about <a href=hwini.htm> hardware </a> configuration.
<li> A description of <a href = command.htm> command </a> initialisation.
</ul>
</p>
<!latex-on>
</BODY>
</HTML>

138
doc/manager/iscan.htm Normal file
View File

@ -0,0 +1,138 @@
<HTML>
<HEAD>
<TITLE>The Internal Scan Command</TITLE>
</HEAD>
<BODY>
<H1>The Internal Scan Command</H1>
<P>
Scans are preformed from a variety of commands in SICS. All these commands
are just Tcl--wrappers around an internal scan object implemented in C. This
section describes this internal scan command and how it works. This internal
scan command is installed into the SICS server via the <a href=command.htm>MakeScanCommand
command</a> in the initialisation file. This command install the internal
scan object under a user defined name. For the rest of this document it is
assumed that this name is xxscan.
</P>
The scan object (named here xxscan, but may have another name) understands
the following commands:
<DL>
<DT>xxscan add name start step
<DD>This command adds the variable specified by the argument name to the
list of variables scanned in the next scan. The arguments start and step
define the starting point and the sptep width for the scan on this variable.
<DT>xxscan clear
<DD>clears the list of scan variables. Must be called before each scan with
different parameters.
<DT>xxscan run NP mode preset
<DD>Executes a scan. The arguments are: NP the number of scan points, mode
the counter mode to use (this can be either timer or monitor) and preset
which is the preset value for the counter. Scan data is written to an output
file.
<DT>xxscan silent NP mode preset
<DD>Executes a scan. The arguments are: NP the number of scan points, mode
the counter mode to use (this can be either timer or monitor) and preset
which is the preset value for the counter. The difference to run is, that
this scan does not produce an output file.
<DT>xxscan recover
<DD>Recovers an aborted scan. The scan object writes a file with all data
necessary to continue the scan after each scan point. If for some reason a
scan has been aborted due to user intervention or a system failure, this
scheme allows to continue the scan when everything is alright again. This
works only if the scan has been started with run, not with silent.
<DT>xxscan getfile
<DD>This command retuns the name of the current data file.
<DT>xxscan setchannel n
<DD>Sometimes it is required to scan not the counter but a monitor. This
command sets the channel to collect data from. The argument n is an integer
ID for the channel to use.
<DT>xxscan getcounts
<DD>Retrieves the counst collected during the scan.
<DT>xxscan getvardata n
<DD>This command retrieves the values of a scan variable during the scan
(the x axis). The argument n is the ID of the scan variable to retrieve data
for. ID is 0 for the first scan variable added, 1 for the second etc.
<DT>xxscan interest
<DD>A SICS client can be automatically notified about scan progress. This is
switched on with this command. Three types of messages are sent: A string
NewScan on start of the scan, a string ScanEnd after the scan has finished
and a string scan.Counts = {109292 8377 ...} with the scan values after each
finished scan point.
<DT>xxscan uninterest
<DD> Uninterest switches automatic notification about scan progress off.
<DT>xxscan integrate
<DD> Calculates the integrated intensity of the peak and the variance of teh
intensity for the last scan. Returns either an error, when insufficient scan
data is available or a pair of numbers. Peak integration is performed along
the method described by Grant and Gabe in J. Appl. Cryst. (1978), 11,
114-120.
<DT>xxscan window [newval]
<DD>Peak Integration uses a window in order to determine if it is still in the
peak or in background. This command allows to request the size of this
window (without argument) or set it (with argument giving the new window
size).
<DT>xxscan simscan pos FWHM height
<DD>This is a debugging command. It simulates scan data with a hundred
points between an x axis ranging from 10 to 20. A gauss peak is produced
from the arguments given: pos denotes the position of the peak maximum, FWHM
is the full width at half maximum for the peak and height is its height.
<DT>xxscan command tclcommand
<DD>Sets the tcl command procedure to invoke at each scan point. See below
for the description of user defined scans. Invoked without argument command
returns the name of the current command procedure.
<dt>xxscan configure mode
<dd>Confugures the several possible scan modes for the scan
object. Currently there are two:
<ul>
<li><b>standard</b>, the default mode writing ASCII files.
<li><b>amor</b>, a special mode the reflectometer AMOR which writes
NeXus files.
</ul>
</DL>
</P>
<p>
<h2>User Defined Scans</h2>
<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 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>
In all this replace xxxscan with the name of the internal scan
command.
</p>
</BODY>
</HTML>

9
doc/manager/keepalive Executable file
View File

@ -0,0 +1,9 @@
#!/usr/bin/ksh
#---------------------------------------------------------------------------
# script starts a program and restarts it whenever it dies.
#
# Mark Koennecke, Juli 1998
#--------------------------------------------------------------------------
while true; do
$1
done

82
doc/manager/macroman.htm Normal file
View File

@ -0,0 +1,82 @@
<HTML>
<HEAD>
<TITLE>Programming SICS Macros</TITLE>
</HEAD>
<BODY>
<H2>Programming SICS Macros</H2>
<P>
The SICS server has a built in macro language. This macro language is basically
John Ousterhout's Tool Command Language Tcl. Tcl is described elsewhere.
A sound knowledge of Tcl is required for programming SICS macros. The SICS macro
language can be used for the following purposes:
<UL>
<li>Add hoc measurement procedures.
<LI>Trial measurement procedures.
<LI>Syntax adaptions to one's own favourite syntax.
<LI>Building of cmore complex commands from the SICS primitives.
</ul>
The general procedure for defining a macro requires defining the macro in a new
file, source this file from the configuration script and the use of the Publish
command to make it available. New commands can best be defined as Tcl procedures,
but the obTcl object oriented extension to Tcl is known to work as well. The SICS
macro language allows to access:
<ul>
<li>Most Tcl commands.
<li>All SICS commands.
</ul>
In the following sections a few pecularities of the SICS macro system will be
discussed.
</P>
<h3>Input/Output</h3>
<p>
It would be quite verbose and confusing for the user if all output from SICS
commands called from a macro would appear on the screen during macro execution.
Therefore all
normal SICS output to a client is suppressed while executing a macro. Except
error messages and warnings which will always be written to the
client executing the macro. The output of a SICS command is available within the
macro script through the normal Tcl mechanism as a return value. This allows for
processing of SICS output within a macro. If the output to the client executing
the macro is required this can be done with the ClientPut command, detailed in the
user documantation.
</p>
<h3>Error Handling</h3>
<p>
Tcl has the feature that it aborts execution of a script when an error occurs.
If a macro script needs to handle errors either from Tcl or from SICS commands
this can be achieved by using the Tcl catch mechanism. A script can inquire the current interrupt value of the
connection with the command <b>GetInt</b>. If a script can handle an error condition
it may set the interrupt on the connection object with the <b>SetInt</b> command.
The textual representations of interrupts for these commands are:
continue, abortop, abortscan, abortbatch, halt, free, end.
</p>
<h3>Interacting with SICS within a Script</h3>
<p>
There exist a few commands which allow to inquire or manipulate SICS
internals. Most of these commands are only available in macro scripts.
<DL>
<DT>SICSType thing.
<DD> SICSType lets SICS find out if thing has some meaning within SICS. Possible return
values are: DRIV for a drivable variable, COM for a SICS command, NUM for a numeric
value and TEXT for anything else.
<DT>SICSBounds var newval
<DD>SICSBounds checks if newval violates the hardware or software limits of
the variable var.
<DT>SetStatus newval
<DD>SetStatus sets the SICS status line to a new value. Possible values for
newval are: Eager, UserWait, Count, NoBeam, Paused, Driving, Running,
Scanning, Batch, Halt, Dead.
<DT>SICSStatus var
<DD>SICSStatus returns a integer value representing the current status of
the object var. var must be a drivable or countable object. The integer code returned
are defined in the SICS programmers documentation.
</DL>
</p>
<p>
Currently it is not possible to define object interfaces from within the SICS
macro language. For the notion of object interfaces see the
SICS programmers documentation. This may be implemented in future when needed.
</p>
</BODY>
</HTML>

48
doc/manager/manager.htm Normal file
View File

@ -0,0 +1,48 @@
<html>
<head>
<title> SICS-Manager documentation </title>
</head>
<body>
<h1>SICS Manager Documentation</h1>
<hr size=4 width="66%">
<p ALIGN=CENTER>
Mark K&ouml;nnecke
</p>
<p ALIGN=CENTER>
Labor f&#252;r Neutronenstreuung
</p>
<p ALIGN=CENTER>
Paul Scherrer Institut
</p>
<p ALIGN=CENTER>
CH-5232 Villigen-PSI
</p>
<p ALIGN=CENTER>
Switzerland
</p>
<p>
This document describes the general setup of SICS, the configuration of the
SICS server and its clients and the writing of macros in the
SICS macro language. This document is aimed at SICS system managers and
instrument scientists. This document requires that the SICS user documentation
has been read and understood beforehand. For writing macros it is essential
to understand John Ousterhouts Tool Command Language,
which is described elsewhere.
</p>
<!latex-off>
<p>
Where to you want to go today?
<ul>
<li> To the general <a href =setup.htm> setup</a> section.
<Li> To the <a href = inifile.htm> server initialision</a> section.
<li> To the section describing <a href=special.htm>special commands</a> for
SICS administrators or programmers.
<li> Commands for <a href=status.htm>status display</a> support.
<li> To the <a href="macroman.htm">macro</a> programming section.
<LI> <a href = trouble.htm>Troubleshooting</a> hints.
<Li> Hints for <a href = "move.htm">moving</a> the SICS server or for Exchanging the serial port server.
</ul>
</p>
<!latex-on>
</body>
</html>

59
doc/manager/managerman Normal file
View File

@ -0,0 +1,59 @@
\documentclass[12pt,a4paper]{report}
%%\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}
\begin{document}
%html -d hr " "
%html -s report
\begin{center}
\begin{huge}
SICS--Managers--Manual \\
\end{huge}
Version: \today\\
Dr. Mark K\"onnecke \\
Labor f\"ur Neutronenstreuung\\
Paul Scherrer Institut\\
CH--5232 Villigen--PSI\\
Switzerland\\
\end{center}
\clearpage
\tableofcontents
\clearpage
\chapter{Introduction}
This document describes the general setup of SICS, the configuration of the
SICS server and its clients and the writing of macros in the
SICS macro language. This document is aimed at SICS system managers and
instrument scientists. This document requires that the SICS user
documentation
has been read and understood beforehand. For writing macros it is essential
to understand John Ousterhouts Tool Command Language,
which is described elsewhere.
%html setup.htm 1
%html inifile.htm 1
%html ini.htm 1
%html option.htm 1
%html var.htm 1
%html hwini.htm 1
%html command.htm 1
%html special.htm 1
%html serial.htm 2
%html status.htm 2
%html sps.htm 2
%html iscan.htm 2
%html alias.htm 2
%html cron.htm 2
%html rs232.htm 2
%html ../user/trouble.htm 1
%html move.htm 1
\end{document}

64
doc/manager/motor.tex Normal file
View File

@ -0,0 +1,64 @@
\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}
\parskip .5cm
\begin{document}
\begin{center}
\begin{huge}
Saving EL734 Motor Parameters on Unix
\end{huge}
16-October-1998\\
\end{center}
EL734 motor controllers occasionally loose their built in parameters.
Therefore it is necessary to save their parameters and to have a way to load
them to the motor controller when need arises. This can be done with
David Maden's EL734\_test
program. This program has now been made available on DigitalUnix. For each
SICS instrument motor parameters are stored at two independent locations:
\begin{itemize}
\item In the motor directory of the instrument account. For example:
/home/DMC/motor
\item On lnsa10 in the lnslib account in a motor/instrument directory. For
example: /data/lnslib/motor/dmc
\end{itemize}
In each of these directories there is an instrument specific shell script
which does the job. It has a name such as instrumentmotor, for example
dmcmotor . This shell script expects one argument which must be one of the
keywords load or save. With the option save specified motor parameters are
read from the controller and stored into files. With the option load the
stored motor parameters are loaded into the motor controller. Thus the
procedure for saving and restoring motor parameters becomes:
\begin{enumerate}
\item change to the directory with the motor parameters
(/home/INSTRUMENT/motor or /data/lnslib/motor/instrument).
\item type: instrumentmotor save for saving motor parameters to disk.
\item type instrumentmotor load for loading motor parameters to the
controller.
\end{enumerate}
\begin{Large}
It is the instrument scientists responsability to save motor parameters to
disk after changes to both locations.
\end{Large}
In order to make this more interesting, files at lnsa10 are write protected.
In order to overwrite those you need to use the unix command chmod.
Saving motor parameters generates files with names like motNUM1@NUM2.par
with NUM1, NUM2 being numbers. This means: motor number NUM1 at EL734 motor
controller at Macintosh channel NUM2. These files can be edited when you
know what you are doing. The command syntax is described in the El734 motor
controller manual.
\end{document}

59
doc/manager/move.htm Normal file
View File

@ -0,0 +1,59 @@
<HTML>
<HEAD>
<TITLE>Replacing Hardware</TITLE>
</HEAD>
<BODY>
<H1>Moving SICS</H1>
<H2> Moving the SICS Server to a new Computer</h2>
<P>
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 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>

82
doc/manager/mug Normal file
View File

@ -0,0 +1,82 @@
\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}
\parskip .5cm
\begin{document}
%html -d hr " "
%html -s article
\begin{center}
\begin{huge}
Notes To SICS Instrument Scientists\\
\end{huge}
3-Juli-1998\\
\end{center}
%html ../user/sicsinvoc.htm
%html sicsnews.htm
\section{User Names and Passwords}
\begin{itemize}
\item All instruments have know an account {\bf lnsuser 98lns2} with user
privilege.
\item Manager passwords are:
\begin{itemize}
\item TOPSI: Mugger Daniel
\item DMC: Manager Lucas
\item SANS: Manager Joachim
\end{itemize}
User names and passwords can be changed by editing the instrument
configuration file.
\end{itemize}
\section{SICS on the WWW}
\subsection{Client access}
Following decisions made at a recent SICS user meeting, SICS clients are
made avaialable on the WWW. Access is restricted to the PSI domain. A
username and a password is needed in order to access the clients. This is
currently set to: sinquser 98sinq2.
The URL's for the clients are:
\begin{description}
\item[Command Line Client]http://lns00.psi.ch/sics/client/sicsclient.html
\item[DMC Status]http://lns00.psi.ch/sics/client/powderstatus.html
\item[TOPSI Status]http://lns00.psi.ch/sics/client/topsistatus.html
\item[SANS Status]http://lns00.psi.ch/sics/client/sansstatus.html
\end{description}
\subsection{Documentation}
All SICS User documentation is accessible at:\\
http://lns00.psi.ch/sics/index.html \\
Postscript versions of the SICS user
documentation inhabit the doc directory of your instrument account.
The SICS manager documentation is also available on WWW. URL:\\
http://lns00.psi.ch/sics/manager/manager.htm \\Access
to this directory is
restricted to the psi.ch domain. A username and password must be given in
order to be given access to these pages. These values are currently set to:
bigboss DJLmanager (can be remembered as: Daniel, Joachim, Lukas manager).
There is now a WWW document which informs about new SICS features, bug fixes
etc. This is available at:\\
http://lns00.psi.ch/sics/manager/sicsnews.htm \\
The same access restrictions as given for the manager documentation above
apply.
Installation instructions for SICS clients on PC's can be found at:\\
http://lns00.psi.ch/sics/cliinst.htm\\
Currently only real PC's are covered,
but instructions for Mac's will follow some day or another. Any volunteers?
\end{document}

173
doc/manager/mug.tex Normal file
View File

@ -0,0 +1,173 @@
\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}
\parskip .5cm
\begin{document}
\begin{center}
\begin{huge}
Notes To SICS Instrument Scientists\\
\end{huge}
3-Juli-1998\\
\end{center}
% html: Beginning of file: `../user/sicsinvoc.htm'
\section{SICS Invocation}
\label{f0}
SICS is a client server system. This means there are two programs. The first
is a
SICServer which does the actual instrument control work. A user rarely needs
to bother about this server program as it is meant to run all the time.
See instructions below if things go wrong. The user has only to deal with
the SICS client programs. These implement the user interface to SICS.
SICS Clients and the SICServer communicate with each other through TCP/IP
sockets.
Currently four SICS clients are available:
\begin{itemize}
\item A command line control client which allows to control the measurement.
\item A status display for DMC.
\item A status display for TOPSI.
\item A status display for SANS.
\end{itemize}
These programs can be started on a DigitalUnix system by issuing the
following commands at the command prompt:
\begin{description}
\item[sics \&] for the control client.
\item[powderstatus \&] for the DMC status display client.
\item[topsistatus \&] for the TOPSI status display.
\item[sansstatus \&] for the SANS status display.
\end{description}
On a PC you may find icons for starting the different prograsm on the
desktop.
Each of these clients has usage instructions online which can be displayed
through the help/about menu entry.
\subsection{Connecting and Logging in}
After startup any SICS client is not connected to a SICS server and thus not
active. A connection is established through the connect menu of the client.
SICS is a multi user instrument control system. In order to prevent
malicious manipulations of the instrument SICS supports a hierarchy of user
rights. In order to run an experiment you need at least user level privilege.
In order to achieve this privilege you have to invoke the User Parameter/Set
Rights dialog. There you have to enter the apropriate username and password
kindly provided by your instrument scientist.
\subsection{Restarting the Server}
The SICS server should be running all the time. It is only down if something
went wrong. You can check for the presence of the SICS server by loging in
to the instrument computer and typing {\bf CheckSICS} at the command
prompt. The output will tell you what is happening. If you need to restart
the SICS server log in as the instrument user at the instrument computer and
invoke the apropriate command to start the server. These are:
\begin{description}
\item[DMC] Computer = lnsa05,User = DMC, Command = DMCServer
\item[TOPSI] Computer = lnsa03,User = TOPSI, Command = TOPSIServer
\item[SANS] Computer = lnsa07,User = SANS, Command = SANSServer
\end{description}
If all this does not help look under trouble shooting
SICS.
% html: End of file: `../user/sicsinvoc.htm'
% html: Beginning of file: `sicsnews.htm'
\section{SICS News Ticker}
\label{f2}
This page contains information about the latest bug fixes, releases and other
miscellaneous information about SICS.
\subsection{Juli 1998}
\begin{description}
\item[Status OutOfMemory] Bug in status display clients fixed which caused OutOfMemory after
some time of automatic update.
\item[topsistatus ] TOPSI has got a java status client now as well. Can be invoked with
{\bf topsistatus}. On the WWW also.
\item[commandlog] On popular demand the SICS server can now write a log file which logs all
communication between clients with user or manager privilege and the SICserver.
This log is off by default. There is a new SICS command
commandlog which serves to configure this log.
\item[8-fold counterboxes.] SICS now reads all eight monitors.
\item[sicsinstall] There is now a shell script which automatizes updating and installing SICS. For more
information see the setup section of the SICS managers guide.
\end{description}
% html: End of file: `sicsnews.htm'
\section{User Names and Passwords}
\begin{itemize}
\item All instruments have know an account {\bf lnsuser 98lns2} with user
privilege.
\item Manager passwords are:
\begin{itemize}
\item TOPSI: Mugger Daniel
\item DMC: Manager Lucas
\item SANS: Manager Joachim
\end{itemize}
User names and passwords can be changed by editing the instrument
configuration file.
\end{itemize}
\section{SICS on the WWW}
\subsection{Client access}
Following decisions made at a recent SICS user meeting, SICS clients are
made avaialable on the WWW. Access is restricted to the PSI domain. A
username and a password is needed in order to access the clients. This is
currently set to: sinquser 98sinq2.
The URL's for the clients are:
\begin{description}
\item[Command Line Client]http://lns00.psi.ch/sics/client/sicsclient.html
\item[DMC Status]http://lns00.psi.ch/sics/client/powderstatus.html
\item[TOPSI Status]http://lns00.psi.ch/sics/client/topsistatus.html
\item[SANS Status]http://lns00.psi.ch/sics/client/sansstatus.html
\end{description}
\subsection{Documentation}
All SICS User documentation is accessible at:\\
http://lns00.psi.ch/sics/index.html \\
Postscript versions of the SICS user
documentation inhabit the doc directory of your instrument account.
The SICS manager documentation is also available on WWW. URL:\\
http://lns00.psi.ch/sics/manager/manager.htm \\Access
to this directory is
restricted to the psi.ch domain. A username and password must be given in
order to be given access to these pages. These values are currently set to:
bigboss DJLmanager (can be remembered as: Daniel, Joachim, Lukas manager).
There is now a WWW document which informs about new SICS features, bug fixes
etc. This is available at:\\
http://lns00.psi.ch/sics/manager/sicsnews.htm \\
The same access restrictions as given for the manager documentation above
apply.
Installation instructions for SICS clients on PC's can be found at:\\
http://lns00.psi.ch/sics/cliinst.htm\\
Currently only real PC's are covered,
but instructions for Mac's will follow some day or another. Any volunteers?
\end{document}

86
doc/manager/mug.txt Normal file
View File

@ -0,0 +1,86 @@
SICS Invocation
SICS is a client server system. This means there are two programs. The first
is a SICServer which does the actual instrument control work. A user rarely
needs to bother about this server program as it is meant to run all the
time. See instructions below if things go wrong. The user has only to deal
with the SICS client programs. These implement the user interface to SICS.
SICS Clients and the SICServer communicate with each other through TCP/IP
sockets.
Currently four SICS clients are available:
* A command line control client which allows to control the measurement.
* A status display for DMC.
* A status display for TOPSI.
* A status display for SANS.
These programs can be started on a DigitalUnix system by issuing the
following commands at the command prompt:
sics &
for the control client.
powderstatus &
for the DMC status display client.
topsistatus &
for the TOPSI status display.
sansstatus &
for the SANS status display.
On a PC you may find icons for starting the different prograsm on the
desktop. Each of these clients has usage instructions online which can be
displayed through the help/about menu entry.
Connecting and Logging in
After startup any SICS client is not connected to a SICS server and thus not
active. A connection is established through the connect menu of the client.
SICS is a multi user instrument control system. In order to prevent
malicious manipulations of the instrument SICS supports a hierarchy of user
rights. In order to run an experiment you need at least user level
privilege. In order to achieve this privilege you have to invoke the User
Parameter/Set Rights dialog. There you have to enter the apropriate username
and password kindly provided by your instrument scientist.
Restarting the Server
The SICS server should be running all the time. It is only down if something
went wrong. You can check for the presence of the SICS server by loging in
to the instrument computer and typing CheckSICS at the command prompt. The
output will tell you what is happening. If you need to restart the SICS
server log in as the instrument user at the instrument computer and invoke
the apropriate command to start the server. These are:
DMC
Computer = lnsa05,User = DMC, Command = DMCServer
TOPSI
Computer = lnsa03,User = TOPSI, Command = TOPSIServer
SANS
Computer = lnsa07,User = SANS, Command = SANSServer
If all this does not help look under trouble shooting SICS.
SICS News Ticker
This page contains information about the latest bug fixes, releases and
other miscellaneous information about SICS.
Juli 1998
Status OutOfMemory
Bug in status display clients fixed which caused OutOfMemory after some
time of automatic update.
topsistatus
TOPSI has got a java status client now as well. Can be invoked with
topsistatus. On the WWW also.
commandlog
On popular demand the SICS server can now write a log file which logs
all communication between clients with user or manager privilege and
the SICserver. This log is off by default. There is a new SICS command
commandlog which serves to configure this log.
8-fold counterboxes.
SICS now reads all eight monitors.
sicsinstall
There is now a shell script which automatizes updating and installing
SICS. For more information see the setup section of the SICS managers
guide.

131
doc/manager/nxscript.htm Normal file
View File

@ -0,0 +1,131 @@
<HTML>
<HEAD>
<TITLE>Scripting NeXus Files</TITLE>
</HEAD>
<BODY>
<H1>Scripting NeXus Files</H1>
<P>
This section describes the scripting interface to NeXus
files, called nxscript. Scripting the generation of NeXus files has
the advantage that
it can be customised very quickly to special needs. Moreover it might
help to reduce the amount of instrument specific code required for an
instrument. This scripting interface uses the NeXus dictionary API for
the actual writing process. This has the following consequences:
<ul>
<li>The interface needs two filenames: the
NeXus filename and the dictionary filename when opening files.
<li>Writing commands have the general form: alias object. This means
that object is written to the NeXus file using the specified alias.
<li>Another property is that some writing commands write several bits
of information in one go. In such cases the aliases for the additional
bits are derived from the base alias by appending specific
strings. Thus dictionary files need to have a special form for this
scripting interface to work.
<li>Nxscript also tries to figure out the dimensions of
multidimensional datasets such as histogram memories by itself. In
such cases the dimension attribute in the dictionary file must be
omitted.
<li>Nxscript assumes the following policy for data writing:
irrespective of errors write everything you can. Thus this interface
will complain bitterly and verbosely if something does not work, but
never return an error.
</ul>
</P>
<h2>Usage</h2>
<p>
Before this facility can be used nxscript has to be installed into the
SICServer from the instrument configuration file. This is done through
the command:
<dl>
<dt>MakeNXScript ?name?
<dd>This creates a NeXus scripting object. If the name is omitted, an
object named nxscript is created. If a name is given, this name is
used for the scripting object. Having scripting objects with different
names is also the only possibility to have more then one NeXus file
writing operation going at a given time.
</dl>
In the following sections it is assumed that an object <b>nxscript</b>
had been configured into SICS.
</p>
<h3>File Opening and Closing</h3>
<p>
<dl>
<dt>nxscript create5 nexusFile dictFile
<dd>Creates a new NeXus file based on HDF-5 with the name
nexusFile. The dictionary file dictFile is used.
<dt>nxscript create4 nexusFile dictFile
<dd>Creates a new NeXus file based on HDF-4 with the name
nexusFile. The dictionary file dictFile is used.
<dt>nxscript reopen nexusFile dictFile
<dd>Reopens an existing NeXus with the name
nexusFile for modification or appending.
The dictionary file dictFile is used.
<dt>nxscript close
<dd>Closes the current NeXus file. This command MUST be given at the
end of each script in order to make sure that all data is written
properly to disk.
</dl>
</p>
<h3>Writing Things</h3>
<p>
<dl>
<dt>nxscript puttext alias bla bla bla ....
<dd>Writes everything after alias as text data to the alias. The
definition string for the alias should not contain a dimension
description, this is automatically appended.
<dt>nxscript putfloat alias value
<dd>Writes a single floating point value to alias alias.
<dt>nscript putmot aliasName motorName
<dd>Writes the position of the motor motorName into the NeXus file as
described by aliasName. Theposition is a zero point corrected position. If
another alias aliasname_null exists in the dictionary, the zero
point of the motor is also written to file.
<dt>nxscript putcounter aliasBase counterName
<dd>Writes counter data to a NeXus file. Data is taken from the single
counter counterName. What is written depends on the aliases present in
the dictionary file:
<dl>
<dt>aliasBase_preset
<dd>The preset value.
<dt>aliasBase_mode
<dd>The counter mode
<dt>aliasBase_time
<dd>The actual time counted, without breaks due to insufficient beam.
<dt>aliasbase_00 ... aliasBase_09
<dd>The monitor readings for monitors 0 to 9. Please note that 00
would denote the normal counting tube at a scanning type of
experiment.
</dl>
<dt>nxscript puthm hmAlias hmName ?start? ?length?
<dd>Writes data from the histogram memory hmName to a NeXus file using
the alias hmAlias. The definition string for the alias should not
contain neither -rank nor -dim information as this will be appended by
nxscript. If the optional parameters start and end are given, a
subset of the data is written. It is the users responsability that the
values requested make sense to the histogram memory. In the case of
subset writing, the dimensions have to be specified in the definition
string belonging to the alias. Nxscript sets a variable timedim in the
dictionary though which contains the length of a time binning if
appropriate. This is a special help for writing extra detectors at
SANS and AMOR.
<dt>nxscript puttimebinning aliasName hmName
<dd>Writes the time binning at histogram memory hmName to file using
the alias aliasName. The length of the time binning data is
automatically appended to the definition string for the alias.
<dt>nxscript putarray aliasName arrayName length
<dd>Writes the Tcl array arrayName to file using the aliasName. The
definiton string belonging to aliasName does not need to contain a
-dim argument as this is set by this routine. The parameter length is
the length of the array. Only rank 1 arrays are supported.
<dt>nxsript putglobal attName bla bla bla
<dd>This writes an global attribute attName. Everything after attName
is concatenated to a string which then respresents the value of the
attribute.
<dt>nxscript makelink targetAlias victimAlias
<dd>This creates a symbolic link for victimAlias in the group
designated by targetAlias.
</dl>
</p>
</BODY>
</HTML>

65
doc/manager/option.htm Normal file
View File

@ -0,0 +1,65 @@
<html>
<head>
<TITLE>Sics options</TITLE>
</head>
<body>
<h2>SICS Options and Users</h2>
<p>
The SICS server has an internal options database which holds such values
as port number to listen too and the like. Additionally there exists a user
database. Currently these values are configured from the initialisation
file. The commands to do this are:<ul>
<li> <b> ServerOption name value </b> defines the server option name to be
value.
<li> <b> SicsUser name password accesscode </b> defines a user with name
and password and an access right accesscode. Accesscode is an integer from 1
to 3 for User, Manager and Spy rights. A user with Spy right may look at
everything but cannot change anything. A user with user privilege may change
most of the SICS parameters, perform measurements etc. A user with manager
privilege may do everything to the system.
</ul>
The Sics server currently uses the following options:<ul>
<li> <b> ReadTimeOut </b> The server checks in each cycle of the main loop
fro pending commands. Het waits for new commands for a specific period of
time. This value is the ReadTimeOut. It should be as short as possible. This
value may need to be increased if there are network performance problems. A
good value is 100.
<li> <b> ReadUserPasswdTimeout </b> This is the time a client has to send a
username password pair after a connection request. If nothing comes in in
that time, the connection request is terminated.
<li> <b>LogFileBaseName </b> defines the path and the base name for the
server log file.
<li> <b> ServerPort </b> defines the port number the server is listening
to. Should be greater than 1024 and less than 64000. The port number should
also be different from any other server port number in use on the system.
Otherwise evil things may happen.
<li> <b> InterruptPort </b> The SICS server can handle interrupts coming in
as UDP messages on a special port. This option defines this UDP port
number. The choice of possible port numbers is limited by the constraints
given above in the ServerPort section. Espacillay this port number MUST be
different from the ServerPort number. The UDP messages accepted are expected to consist of the string
SICSINT followed by an interrupt number. For interrupt numbers see file
interrupt.h.
<li> <b> DefaultTclDirectory </b> specifies where Tcl defined commands are
stored. When this is properly defined Tcl will autoload commands.
<li> <b> statusfile </b> defines the file to which he current state will be
saved on close down of the server and restored from at startup time.
<li><b>TelnetPort</b> The port number where the SICS server will be
listening for telnet connections. If this option is missing login via telent
to the SICS server is disabled.
<li><b>TelWord</b> In order to login to SICS via telnet a magic word is
needed. The login word, This option defines this word. If this option is
missing telnet login to SICS is disabled.
<li><b>LogFileDir</b> This server option defines the directory where
commandlog log files are kept.
<li><b>RedirectFile</b> This defines a filename to which all output to
stdout and stderr is logged by the SICS server. This is mainly a
debugging feature.
<li><b>TecsPort</b> The port number at which the Tecs temperature
control server is listening.
</ul>
</p>
</body>
</html>

103
doc/manager/serial.htm Normal file
View File

@ -0,0 +1,103 @@
<HTML>
<HEAD>
<TITLE>Accessing Macintosh Serial Ports</TITLE>
</HEAD>
<BODY>
<H1>Accessing Macintosh Serial Ports</H1>
<P>
Occasionally, it may be necessary to access the serial ports of the Macintosh PC
directly in order to give commands to the motor controller, counter box or any
device directly. Furthermore such a faclility is useful for coding
environment device drivers in the SICS server macro language. The implementation
of serial port access is highly SINQ specific and relies on the SINQ hardware
concept. Besides, serial port access is realized in a different
way then usual SICS objects. Usually SICS objects live in the SICS interpreter.
Serial port access is implemented as an extension to the Tcl macro language.
Essentially this is the same implementation as used in the psish.
This section describes how to use serial port access. Several steps have to be performed:
<ol>
<li>Install the serialport command into the SICS server. This requires two lines to be added to
the server startup script:
<ul>
<li>SerialInit
<li>TclPublish serialport UserRights
</ul>
Where UserRights stands for one of the possible SICS user rights. See documentation
for TclPublish above.
<li> Each separate serial port will be represented by a name in the SICS server
after it has been initialized. This name is also a command. These port names live
in the Tcl interpreter and must be made accessible with TclPublish. For example for
a port named p1 include this line in the server startup script:
<ul>
<li>TclPublish p1 User
</ul>
Replace User with the correct access code you want for a serial port. It is recommended
to restrict serial port access to SICS managers only.
<li> After starting the SICS server the command serialport is now available.
<li> Now a serial port can be initialized with a command like this:
<ul>
<li>serialport name1 macintosh.name port channel force
<li>Example: serialport p1 lnsp20.psi.ch 4000 5
</ul>
Such a command creates the command name1 and links it with serial port channel
channel on the Macintosh-PC macintosh.name. Port is the port number on which the
Macintosh serial port server is listening for connections (usually 4000).
The last flag force is optional. If something is there, the connection to that
port is done on a separate socket of its own. This has to do with some
feature of the software interface to the Macintosh serial port server. This
software interface tries to direct messages for multiple channels through one
socket connection between the host and the Macintosh server. This is perfectly
fine as long as none of the commands through this socket takes a long time
to execute. However, if a RS-232 device takes a long time to respond, the whole
socket is blocked. Fortunately, the Macintosh serial port server runs a separate
thread of execution for each different socket. By forcing a new socket it can
be achieved that such a slow device is decoupled from the rest. Exactly this
is achieved with the force flag.
<li> Once the port has been initialised (for example p1) it is ready to operate.
The port object allows to send data to the serial port and receive data from
it. Furthermore some configuration is possible. The syntax is like this:
<DL>
<DT>portname -tmo number
<DD>Sets the timeout for the serial port. This is the maximum amount of time
the Macintosh serial port server waits for data to arrive from the RS-232 device.
Increase this if a lot of <code>_BAD_TMO</code> error messages creep up.
<DT>portname -sendterm string
<DD> Sets the terminator which will be automatically added to the string which is
sent. Some RS-232 devices require special terminators in order to accept a command.
The serial port implementation ensures that such a terminator is sent after
each message. This command allows to configure this terminator. Please note,
that the terminator string needs to be enclosed in quotes. An example:
<ul>
<li><code>p1 -sendterm "\r\n"</code>
</ul>
This sets the terminator to carriage return - line feed.
<DT>portname -replyterm string.
<DD>The Macintosh terminal server expects the RS-232 device to send a terminator
when it is done with sending answers. It even supports multiple lines to be
sent as a reply. This expected reply terminator is set with this command.
The string may may be four characters long. An example: <code>1\r\n</code> sets
the expected terminator to one of <code>\r\n</code>. One of them is expected. Thus the
first character is the count of terminators to expect, followed by the characters
possible as terminators. This string must usually be quoted.
<DT>portname blablalakjdl
<DD>When none of the options -tmo, -replyterm, -sendterm, is found everything after
portname is sent to the RS-232 device. The reply from the RS-232 device is printed.
</DL>
</ol>
The defaults set for the configuration parameters of the serial port connection
are suited for the EL734, EL737 and ITC4 devices usually encountered at SINQ. For
other RS-232 devices consult the manuals hopefully delivered with the device.
The defaults are: 100 for timeout, <code>1\r\n</code> for the reply terminator and
<code>\r\n</code>for the send terminator.
</p>
<p>
Please note, that the SICS server serial port access is a convenience feature for
SICS managers and instrument scientists. It is needed for implementing
environment device drivers in the Tcl macro language. If serial port connections must be
debugged the Macintosh versaterm software or on a IBM-PC the kermit program
are much better suited to the task.
</P>
</BODY>
</HTML>

190
doc/manager/setup.htm Normal file
View File

@ -0,0 +1,190 @@
<HTML>
<HEAD>
<TITLE>SICS Setup</TITLE>
</HEAD>
<BODY>
<H1>SICS programs, Scripts and Prerequisites<h1>
<p>
<h2>Hardware</h2>
The following hardware is usually present for any SICs instrument:
<ul>
<li>An instrument computer
<li>A Lantronix terminal server with 8-16 serial ports for connecting:
<li>Motor controllers
<li>Counter boxes
<li>Temperature controllers.
<li>Optionally 1-n histogram memory computers are present.
</ul>
The terminal server software is provided by Lantronix, see the
appropriate manuals for the device for a description. The histogram
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>
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
communicating with serial ports. The actual communication with the
serial ports is done through the Lantronix terminal server. Both the
serial port protocoll and the SerPortServer are only documented in the
source code.
<dt>TecsServer
<dd>This is a TCP/IP server which watches over temperature
controllers. The only knwon source of documentation about this
software is Markus Zolliker.
<dt>FileSync
<dd>This is a little UDP server which waits for UDP messages from the
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
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.
</dl>
Additionally a client program is needed which connects to the
instrument control server and provides a user interface to it.
</p>
<h2>Scripts</h2>
<p>
To get all this software up and running a couple of shell scripts have
been provided:
<dl>
<dt>startsics
<dd> This script starts all the necessary server programs for driving
the instrument.
<dt>killsics
<dd>This script shuts down all instrument control servers properly.
<dt>keepalice, keepaliveserp
<dd>The server programs are automatically restarted when they
die. This is done through these scripts. keepaliveserp is a special
script for the serial port server.
<dt>instsync
<dd>replace inst by the name of the instrument in lower case. This
script is invoked by the FileSync server and is responsible for
synchronizing the local data store with the one on the labaratory
server. This is usally done by calling the unix program rsync with
appropriate parameters.
</dl>
</p>
<H1>General SICS Setup</H1>
<P>
SICS is a client server system. This implies that there is a server program
which implements all the functionlity and client programs which implement
the user interface. The client program is the only thing the user is
intended to see. This also means that the location of the client programs is
quite independent from the computer where the server runs. In the following
the layout of a server installation is described as established at SINQ.
</P>
<p>
For each instrument there is a data aquisition computer. On this computer
there exists a user name and consequently a home directory for the
instrument. In the following text this instrument root directory will be called
sicsroot. This root directory has the following subdirectories:
<DL>
<DT>bin
<DD> The bin directory is the place where the actual executable for the SICS
server is kept along with local copies of all necessary clients, the server
initialisation files and special macro files defined for the instrument.
<DT>data
<DD>The data directory is the central place where all data files collected
at the instrument are stored. This directory contains subdirectories
for each year. These directories hold the data collected at the
instrument in this year plus a file named
DataNumber which keeps the current serial number of the data files. This
file should never be edited. At the start of each year the instruement manager
must create a new directory with an empty DataNumber
file. Additionally the
path variables both for the data file directory and the DataNumber
file have to be set to the new directory in the instrument
initialization file.
<DT>log
<DD> The log directory contains the server log files and the automatically
generated client log files. Any now and then, and especially when disk space
problems loom, the client*.log files should be deleted by the instrument
manager.
<DT> doc
<DD> This directory holds a copy of the SICS user documentation for the
instrument. These are html files which can be viewed with WWW-browsers such
as lynx or netscape.
<DT> sim
<DD> The sim directory is meant to hold all files necessary for a SICServer
initialised for the instrument but configured with simulated hardware. This
facility is meant for testing of command files.
<DT>motor
<DD>This directory holds a script for reading and restoring the motor
parameter from the EL734 motor controllers. And the motor parameters
stored in parameter files. It is the instrument scientists
responsability to save the motor parameters after changes to the
configuration of the instrument.
</DL>
Besides these directories there should be nothing on the instrument account.
All evaluated data, personal command files etc. should be held on the normal
user account of the instrument user.
</p>
<p>
For this purpose the /data/lnslib/bin directory holds copies of the
apropriate command line and status display clients for each instrument. A user can make
this directory (and much more) available by including the line <b>
source /data/lnslib/bin/lns.login</b> into her .login file.
</p>
<h2> SICS Installation</h2>
<p>
All executables and files necessary to run SICS for each instrument is
avaialable under the /data/lnslib/distribution/sics hierarchy.
The bin directory
holds general executable files and a directory for each instrument which
holds instrument specific files. SICS installation on a unix system is
greatly simplified by using the <b>sicsinstall</b> korn shell script. This
script is available to each user. sicsinstall can be invoked simply by
typing sicsinstall at the command prompt. sicsinstall needs a subcommand in
order to know what it is expected to do:
<dl>
<DT>dev
<DD>copies knew executables from the development area to the distribution
directory. This command is meant to be used by computing staff only.
<DT>devfull
<DD>as dev, but copies all files. This command is meant to be used by computing staff only.
<DT>dmc
<DD>copies all files necessary for the instrument DMC.
<DT>topsi
<DD>copies all files necessary for the instrument TOPSI.
<DT>sans
<DD>copies all files necessary for the instrument SANS.
<DT>hrpt
<DD>copies all files necessary for the instrument HRPT.
<DT>amor
<DD>copies all files necessary for the instrument AMOR
<DT>focus
<DD>copies all files necessary for the instrument FOCUS
<DT>tasp
<DD>copies all files necessary for the instrument TASP
<DT>druechal
<DD>copies all files necessary for the instrument DRUECHAL
<DT>trics
<DD>copies all files necessary for the instrument TRICS
<DT>save inst
<DD>copies all the instrument configuration files from the instrument
account back to to the distribution area. Replace inst with the name
of the instrument in lower case. This call is necessary to save
modified instrument configurations.
<DT>doc
<DD>updates only the documentation on your disk.
<DT>exe
<DD>copies only new executable files from the distribution area. This is the
recommended option when you want to be sure, that you have the latest
version of SICS before reporting a bug.
</dl>
Most of these options require you to be in the home directory of the
instrument account. sicsinstall checks for this and warns you if this is not
the case. Directory structures are checked for and created as needed.
</p>
</BODY>
</HTML>

329
doc/manager/sicsinstall Executable file
View File

@ -0,0 +1,329 @@
#! /usr/bin/ksh
#----------------------------------------------------------------------------
# script for installing SICS software on to a system.
# The source of the data must be visible to the filesystem.
# This script installs SW into directories beyond your current directory
# So, on an instrument account it would be feasible to run this from the
# home directory. The script checks if we are at home, else it will print
# a warning.
#
# this script understands a few arguments:
#
# dev - copies new executables from development area to
# distribution area
# devfull - copies all files from development area to
# distribution area
# dmc - installs all files for running dmc
# topsi - install all files for topsi
# focus - install all files for focus
# sans - installs all files for sans
# trics - installs all files for TRICS
# hrpt - installs all files for HRPT
# poldi - installs all files for POLDI
# doc - updates only the documentation
# exe - installs only new executables
# debug - copies only the server to current directory
# lib - copies clients from the distribution area to
# the common program library.
#
# Mark Koennecke, Juli 1998
# DM. 7-Sep-2000. Add POLDI.
#----------------------------------------------------------------------------
#=========================== data area ====================================
devdir=~koenneck # development directory
disdir=~lnslib/src/sics # distribution directory
dirdir="bin data doc log motor" # SICS directories
bindir=~lnslib/bin # common directory for binaries
clients="sicsclient.jar powderstatus.jar sansstatus.jar topsistatus.jar"
clients="$clients varwatcher.jar focusstatus.jar nndb.jar amor.jar fsync.jar"
clientdir=~koenneck/bin/sics
# directory where the client jar files live
docmaster=~koenneck/src/sics/doc # where the docs reside
#======================= Functions ========================================
#------------------ check if in home directory
checkhome() {
if [[ $HOME != $(pwd) ]] then
echo "You are not in your home directory."
echo "This may cause a non standard SICS installation"
printf "Do you want me to continue (Y,y) or abort (any other character): "
read answer
if [[ ($answer = Y) || ($answer = y) ]] then
echo "OK, you have been warned ..."
else
echo "Script aborting ..."
exit 0
fi
fi
}
#------------------- print usage
usage() {
echo "USAGE:"
echo "This script copies SICS software. You need to tell this program"
echo "what to do by specifying one of the keywords below:"
echo ""
echo "dev - copies new executables from development area to"
echo " distribution area (MK only)"
echo "devfull - copies all files from development area to"
echo " distribution area (MK only)"
echo "dmc - installs all files for running dmc"
echo "topsi - install all files for topsi"
echo "sans - installs all files for sans "
echo "trics - installs all files for trics "
echo "hrpt - installs all files for hrpt "
echo "amor - installs all files for amor"
echo "focus - installs all files for focus"
echo "poldi - installs all files for poldi"
echo "doc - updates only the documentation"
echo "exe - installs only new executables"
echo "lib - copies new clients to common program area"
echo ""
echo "Mark Koennecke, LNS, Juli-October 1998, March 2000"
}
#------------------ copy new executables
copydev () {
echo "Copying new executable files from development area to distribution.."
cp $devdir/bin/sics/* $disdir/gen
for cl in $clients; do
cp $clientdir/$cl $disdir/gen
done
}
#------------------ copy to common program area
copylib() {
echo "Copying new client files to common LNS program area"
cp $disdir/gen/* $bindir
rm $bindir/SICServer
rm $bindir/TecsServer
# this is to overwrite the client start shell scripts with ones that point
# to lnslib
cp $disdir/bin/lib/* $bindir
}
#------------------ copy all new stuff
copydevfull () {
echo "Copying ALL files from development area to distribution.."
copydev
echo "Copying documentation"
cp $docmaster/user/*.htm $disdir/doc
cp $docmaster/user/*.html $disdir/doc
cp $docmaster/user/*.ps $disdir/doc
cp $docmaster/manager/*.htm $disdir/manager
}
#------------------ copy only new executables
copyexe () {
echo "Copying new executable files"
miau.py ~lnslib/src/sics/gen/genlist.dat
}
#----------------- copy documentation
copydoc () {
echo "Copying documentation"
cp $disdir/doc/*.htm doc
cp $disdir/doc/*.html doc
cp $disdir/doc/*.ps doc
}
#----------------- DMC special files
copydmc () {
echo "Copying DMC special files"
miau.py ~lnslib/src/sics/dmc/dmclist.dat
if [ -e data/DataNumber ]; then
echo "DataNumber found, OK"
else
echo "WARNING: Creating new DataNumber file with 0, adjust as needed"
echo " 0" > data/DataNumber
fi
echo "Done, configuration files may need editing"
}
#----------------- TOPSI special files
copytopsi () {
echo "Copying TOPSI special files"
miau.py ~lnslib/src/sics/topsi/topsilist.dat
if [ -e data/DataNumber ]; then
echo "DataNumber found, OK"
else
echo "WARNING: Creating new DataNumber file with 0, adjust as needed"
echo " 0" > data/DataNumber
fi
echo "Done, configuration files may need editing"
}
#----------------- SANS special files
copysans() {
echo "Copying SANS special files"
miau.py ~lnslib/src/sics/sans/sanslist.dat
if [ -e data/DataNumber ]; then
echo "DataNumber found, OK"
else
echo "WARNING: Creating new DataNumber file with 0, adjust as needed"
echo " 0" > data/DataNumber
fi
echo "Done, configuration files may need editing"
}
#----------------- TRICS special files
copytrics() {
echo "Copying TRICS special files"
miau.py ~lnslib/src/sics/trics/tricslist.dat
if [ -e data/DataNumber ]; then
echo "DataNumber found, OK"
else
echo "WARNING: Creating new DataNumber file with 0, adjust as needed"
echo " 0" > data/DataNumber
fi
echo "Done, configuration files may need editing"
}
#----------------- HRPT special files
copyhrpt() {
echo "Copying HRPT special files"
miau.py ~lnslib/src/sics/hrpt/hrptlist.dat
if [ -e data/DataNumber ]; then
echo "DataNumber found, OK"
else
echo "WARNING: Creating new DataNumber file with 0, adjust as needed"
echo " 0" > data/DataNumber
fi
echo "Done, configuration files may need editing"
}
#----------------- FOCUS special files
copyfocus() {
echo "Copying FOCUS special files"
miau.py ~lnslib/src/sics/focus/focuslist.dat
if [ -e data/DataNumber ]; then
echo "DataNumber found, OK"
else
echo "WARNING: Creating new DataNumber file with 0, adjust as needed"
echo " 0" > data/DataNumber
fi
echo "Done, configuration files may need editing"
}
#----------------- AMOR special files
copyamor() {
echo "Copying AMOR special files"
miau.py ~lnslib/src/sics/amor/amorlist.dat
if [ -e data/DataNumber ]; then
echo "DataNumber found, OK"
else
echo "WARNING: Creating new DataNumber file with 0, adjust as needed"
echo " 0" > data/DataNumber
fi
echo "Done, configuration files may need editing"
}
#----------------- POLDI special files
copypoldi() {
echo "Copying POLDI special files"
miau.py ~lnslib/src/sics/poldi/poldilist.dat
if [ -e data/DataNumber ]; then
echo "DataNumber found, OK"
else
echo "WARNING: Creating new DataNumber file with 0, adjust as needed"
echo " 0" > data/DataNumber
fi
echo "Done, configuration files may need editing"
}
#------------------ check SICS directories
checkdir() {
echo "Checking directory structure, creating as needed"
for dd in $dirdir; do
if [ -d $dd ]; then
echo "$dd present"
else
echo "Creating $dd"
mkdir $dd
fi
done
}
#======================= End of Functions ====================================
#
#-------------- the case for checking the command parameter
printf "\n Starting `basename $0` ...\n\n"
case ${1-nix} in
dev)
copydev
;;
devfull)
copydevfull
;;
exe)
checkhome
checkdir
copyexe
;;
doc)
checkhome
checkdir
copydoc
;;
dmc)
checkhome
checkdir
copyexe
copydoc
copydmc
;;
topsi)
checkhome
checkdir
copyexe
copydoc
copytopsi
;;
sans)
checkhome
checkdir
copyexe
copydoc
copysans
;;
trics)
checkhome
checkdir
copyexe
copydoc
copytrics
;;
hrpt)
checkhome
checkdir
copyexe
copydoc
copyhrpt
;;
amor)
checkhome
checkdir
copyexe
copydoc
copyamor
;;
focus)
checkhome
checkdir
copyexe
copydoc
copyfocus
;;
poldi)
checkhome
checkdir
copyexe
copydoc
copypoldi
;;
lib)
copylib
;;
debug)
cp $devdir/SICServer .
;;
*)
usage
;;
esac
printf "\n End of `basename $0`.\n\n"
#========================= End of sicsinstall ================================

33
doc/manager/sicsnews.htm Normal file
View File

@ -0,0 +1,33 @@
<HTML>
<HEAD>
<TITLE>SICS News Ticker</TITLE>
</HEAD>
<BODY>
<H1>SICS News Ticker</H1>
<P>
This page contains information about the latest bug fixes, releases and other
miscellaneous information about SICS.
</P>
<p>
<h2>Juli 1998</h2>
<DL>
<DT>Status OutOfMemory
<DD>Bug in status display clients fixed which caused OutOfMemory after
some time of automatic update.
<DT>topsistatus
<DD>TOPSI has got a java status client now as well. Can be invoked with
<b>topsistatus</b>. On the WWW also.
<DT>commandlog
<DD>On popular demand the SICS server can now write a log file which logs all
communication between clients with user or manager privilege and the SICserver.
This log is off by default. There is a new SICS command <a href="../commandlog.htm">
commandlog</a> which serves to configure this log.
<DT>8-fold counterboxes.
<DD>SICS now reads all eight monitors.
<DT>sicsinstall
<DD>There is now a shell script which automatizes updating and installing SICS. For more
information see the <a href="setup.htm">setup section</a> of the SICS managers guide.
</DL>
</p>
</BODY>
</HTML>

264
doc/manager/sicsstat.tcl Normal file
View File

@ -0,0 +1,264 @@
# Motor phi
phi SoftLowerLim 0.000000
phi SoftUpperLim 360.000000
phi SoftZero 0.000000
phi Fixed -1.000000
phi InterruptMode 0.000000
phi AccessCode 2.000000
# Motor chi
chi SoftLowerLim 0.000000
chi SoftUpperLim 360.000000
chi SoftZero 0.000000
chi Fixed -1.000000
chi InterruptMode 0.000000
chi AccessCode 2.000000
# Motor omega
omega SoftLowerLim -180.000000
omega SoftUpperLim 360.000000
omega SoftZero 0.000000
omega Fixed -1.000000
omega InterruptMode 0.000000
omega AccessCode 2.000000
# Motor twotheta
twotheta SoftLowerLim 5.000000
twotheta SoftUpperLim 120.000000
twotheta SoftZero 0.000000
twotheta Fixed -1.000000
twotheta InterruptMode 0.000000
twotheta AccessCode 2.000000
banana CountMode timer
banana preset 100.000000
sample_mur (null)
sample_mur setAccess 2
email UNKNOWN
email setAccess 2
fax UNKNOWN
fax setAccess 2
phone UNKNOWN
phone setAccess 2
adress UNKNOWN
adress setAccess 2
# Counter counter
counter SetPreset 1000.000000
counter SetMode Timer
# Motor som
som SoftLowerLim 0.000000
som SoftUpperLim 360.000000
som SoftZero 0.000000
som Fixed -1.000000
som InterruptMode 0.000000
som AccessCode 2.000000
# Motor sax
sax SoftLowerLim -30.000000
sax SoftUpperLim 30.000000
sax SoftZero 0.000000
sax Fixed -1.000000
sax InterruptMode 0.000000
sax AccessCode 2.000000
# Motor tilt
tilt SoftLowerLim -15.000000
tilt SoftUpperLim 15.000000
tilt SoftZero 0.000000
tilt Fixed -1.000000
tilt InterruptMode 0.000000
tilt AccessCode 0.000000
# Motor detectorrotation
detectorrotation SoftLowerLim -20.000000
detectorrotation SoftUpperLim 20.000000
detectorrotation SoftZero 0.000000
detectorrotation Fixed -1.000000
detectorrotation InterruptMode 0.000000
detectorrotation AccessCode 2.000000
# Motor detectory
detectory SoftLowerLim -20.000000
detectory SoftUpperLim 20.000000
detectory SoftZero 0.000000
detectory Fixed -1.000000
detectory InterruptMode 0.000000
detectory AccessCode 2.000000
# Motor detectorx
detectorx SoftLowerLim -20.000000
detectorx SoftUpperLim 20.000000
detectorx SoftZero 0.000000
detectorx Fixed -1.000000
detectorx InterruptMode 0.000000
detectorx AccessCode 2.000000
# Motor beamstopy
beamstopy SoftLowerLim -20.000000
beamstopy SoftUpperLim 20.000000
beamstopy SoftZero 0.000000
beamstopy Fixed -1.000000
beamstopy InterruptMode 0.000000
beamstopy AccessCode 2.000000
# Motor beamstopx
beamstopx SoftLowerLim -20.000000
beamstopx SoftUpperLim 20.000000
beamstopx SoftZero 0.000000
beamstopx Fixed -1.000000
beamstopx InterruptMode 0.000000
beamstopx AccessCode 2.000000
# Motor d2t
d2t SoftLowerLim -20.000000
d2t SoftUpperLim 20.000000
d2t SoftZero 0.000000
d2t Fixed -1.000000
d2t InterruptMode 0.000000
d2t AccessCode 2.000000
# Motor d2l
d2l SoftLowerLim -20.000000
d2l SoftUpperLim 20.000000
d2l SoftZero 0.000000
d2l Fixed -1.000000
d2l InterruptMode 0.000000
d2l AccessCode 2.000000
# Motor d2r
d2r SoftLowerLim -20.000000
d2r SoftUpperLim 20.000000
d2r SoftZero 0.000000
d2r Fixed -1.000000
d2r InterruptMode 0.000000
d2r AccessCode 2.000000
# Motor d1t
d1t SoftLowerLim -20.000000
d1t SoftUpperLim 20.000000
d1t SoftZero 0.000000
d1t Fixed -1.000000
d1t InterruptMode 0.000000
d1t AccessCode 2.000000
# Motor d1l
d1l SoftLowerLim -20.000000
d1l SoftUpperLim 20.000000
d1l SoftZero 0.000000
d1l Fixed -1.000000
d1l InterruptMode 0.000000
d1l AccessCode 2.000000
# Motor d1r
d1r SoftLowerLim -20.000000
d1r SoftUpperLim 20.000000
d1r SoftZero 0.000000
d1r Fixed -1.000000
d1r InterruptMode 0.000000
d1r AccessCode 2.000000
# Motor tasse
tasse SoftLowerLim -130.000000
tasse SoftUpperLim 130.000000
tasse SoftZero 0.000000
tasse Fixed -1.000000
tasse InterruptMode 0.000000
tasse AccessCode 2.000000
# Motor sdm
sdm SoftLowerLim -5.000000
sdm SoftUpperLim 5.000000
sdm SoftZero 0.000000
sdm Fixed -1.000000
sdm InterruptMode 0.000000
sdm AccessCode 2.000000
# Motor sgu
sgu SoftLowerLim -20.000000
sgu SoftUpperLim 20.000000
sgu SoftZero 0.000000
sgu Fixed -1.000000
sgu InterruptMode 0.000000
sgu AccessCode 2.000000
# Motor sgl
sgl SoftLowerLim -20.000000
sgl SoftUpperLim 20.000000
sgl SoftZero 0.000000
sgl Fixed -1.000000
sgl InterruptMode 0.000000
sgl AccessCode 2.000000
# Motor mgu
mgu SoftLowerLim -50.000000
mgu SoftUpperLim 50.000000
mgu SoftZero 0.000000
mgu Fixed -1.000000
mgu InterruptMode 0.000000
mgu AccessCode 2.000000
# Motor stu
stu SoftLowerLim -30.000000
stu SoftUpperLim 30.000000
stu SoftZero 0.000000
stu Fixed -1.000000
stu InterruptMode 0.000000
stu AccessCode 2.000000
# Motor stl
stl SoftLowerLim -30.000000
stl SoftUpperLim 30.000000
stl SoftZero 0.000000
stl Fixed -1.000000
stl InterruptMode 0.000000
stl AccessCode 2.000000
# Motor mtu
mtu SoftLowerLim -30.000000
mtu SoftUpperLim 30.000000
mtu SoftZero 0.000000
mtu Fixed -1.000000
mtu InterruptMode 0.000000
mtu AccessCode 2.000000
# Motor mtl
mtl SoftLowerLim -30.000000
mtl SoftUpperLim 30.000000
mtl SoftZero 0.000000
mtl Fixed -1.000000
mtl InterruptMode 0.000000
mtl AccessCode 2.000000
# Motor a6
a6 SoftLowerLim -30.000000
a6 SoftUpperLim 30.000000
a6 SoftZero 0.000000
a6 Fixed -1.000000
a6 InterruptMode 0.000000
a6 AccessCode 2.000000
# Motor a5
a5 SoftLowerLim -30.000000
a5 SoftUpperLim 30.000000
a5 SoftZero 0.000000
a5 Fixed -1.000000
a5 InterruptMode 0.000000
a5 AccessCode 2.000000
# Motor a4
a4 SoftLowerLim -130.000000
a4 SoftUpperLim 130.000000
a4 SoftZero 0.000000
a4 Fixed -1.000000
a4 InterruptMode 0.000000
a4 AccessCode 2.000000
# Motor a3
a3 SoftLowerLim 0.000000
a3 SoftUpperLim 360.000000
a3 SoftZero 0.000000
a3 Fixed -1.000000
a3 InterruptMode 0.000000
a3 AccessCode 2.000000
# Motor a2
a2 SoftLowerLim 30.000000
a2 SoftUpperLim 120.000000
a2 SoftZero 0.000000
a2 Fixed -1.000000
a2 InterruptMode 0.000000
a2 AccessCode 2.000000
# Motor a1
a1 SoftLowerLim 30.000000
a1 SoftUpperLim 120.000000
a1 SoftZero 0.000000
a1 Fixed -1.000000
a1 InterruptMode 0.000000
a1 AccessCode 2.000000
user Daniel_the_Clementine
user setAccess 2
temperature ine
0
00
00
<EFBFBD>
temperature setAccess 2
sample DanielOxid
sample setAccess 2
title TopsiTupsiTapsi
title setAccess 2

23
doc/manager/special.htm Normal file
View File

@ -0,0 +1,23 @@
<HTML>
<HEAD>
<TITLE>Special Commands for SICS Administrators and Programmers</TITLE>
</HEAD>
<BODY>
<H1>Special Commands for SICS Administrators and Programmers</H1>
<P>
This section describes a few commands which need not be known to SICS users.
<!latex-off>
<UL>
<li> Access Macintosh <a href="serial.htm"> serial </a>ports.
<li> An internal <a href=iscan.htm> scan command</a>.
<li> Accessing Siematic <a href="sps.htm">SPS</a> controllers.
<li> <a href="alias.htm">Aliases</a>.
<li> <a href="cron.htm">Reoccuring tasks</a>.
<li> Direct access to <a href="rs232.htm">RS232 controllers</a> through
the terminal server.
</uL>
<!latex-on>
</P>
</BODY>
</HTML>

58
doc/manager/sps.htm Normal file
View File

@ -0,0 +1,58 @@
<HTML>
<HEAD>
<TITLE>Siematic SPS Controllers</TITLE>
</HEAD>
<BODY>
<H1>Siematic SPS Controllers</H1>
<P>
Siematic SPS controllers are used at SinQ for handling all the things which
fit in nowhere else. Such as operating air cushions on some instruments,
reading variables from ADC's, reading status of shutters or other parts of
the instrument and the like. Those SPS units have an RS-232 connector and
understand a simple ASCII command protocoll.
The Siematic SPS and its command protocoll are
special to PSI and this section is probably of no interest to SICS managers
outside. The SPS basiaclly support three operations:
<ul>
<li>Push a button.
<li>Request status of instrument status packed into a bit.
<li>Read an ADC.
</ul>
This is so user unfriendly that the usage of the SPS will mostly be packaged
into Tcl-macros.
</P>
<p>
A SPS unit can be configured into the SICS server with the command:<br>
<b>MakeSPS name macintosh port channel</b> <br>
The parameters are: the name of the SPS in SICS, the serial port server
computer, the port where the serial port server is listening and the
channel number of the SPS unit at the serial port server computer. An
example: <br>
MakeSPS sps1 lnsp25.psi.ch 4000 6 <br>
configures a SPS unit at lnsp25.psi.ch at channel 5. The serial port server
is listening at port number 4000. The SPS unit will be accessible as sps1 in
SICS.
</p>
<p>
After configuartion the following four commands are understood by name,
shown with sps1 as example:
<DL>
<DT>sps1 push byte bit
<DD>Corresponds to pushing the button mapped to the bit bit in the byte
byte.
<DT>sps1 adc num
<DD> Reads the value in the ADC num. num can be between 0 to 7 for a maximum
of eight ADC's. Please note, that the values read are raw values which
usually must be converted in some way to physically meaningful values.
<DT>sps1 status bit
<DD>Reads the status of the bit bit. bit can be in the range 0 - 128.
<DT>sps1 stat2 byte bit
<DD>Reads the status bit bit in status byte byte. Is equivalent to status,
but adds some syntatctic sugar.
</DL>
For all conversion factors, for all mappings of bytes and bits, consult the
electronician who coded the SPS.
</p>
</BODY>
</HTML>

36
doc/manager/startsics Executable file
View File

@ -0,0 +1,36 @@
#!/usr/bin/ksh
#-------------------------------------------------------------------------
# shell sript to start the servers necessary for running SICS.
# checks if they are not already running.
#
# Mark Koennecke, Juli 1998
#------------------------------------------------------------------------
inst=test
shome=$HOME/src/sics
# start SICServer
ps waux > /tmp/ps.lis
grep SICServer /tmp/ps.lis > /dev/null
if [ $? -eq 1 ] ; then
echo "Starting SICServer"
cd $shome
com="SICServer $inst.tcl"
keepalive "$com" &
else
echo "SICServer exists"
fi
rm /tmp/ps.lis
# start replicator service
ps waux > /tmp/ps.lis
grep replicator.jar /tmp/ps.lis > /dev/null
if [ $? -eq 1 ] ; then
echo "Starting Data Replicator"
cd $shome
com1="jre -classpath /usr/lib/classes.zip:$shome/replicator.jar Replicator "
com2=$sheim/replicator.conf
com=$com1$com2
keepalive "$com" &
else
echo "Data Replicator exists"
fi
rm /tmp/ps.lis

63
doc/manager/status.htm Normal file
View File

@ -0,0 +1,63 @@
<HTML>
<HEAD>
<TITLE>Commands supporting SICS status displays</TITLE>
</HEAD>
<BODY>
<H1>Commands For Supporting SICS Status Displays</H1>
<P>
The implementation of many status displays is greatly simplified by
letting the SICS server do some of the hard work. The operation of
these commands is usually invisible to users. Some even do not
generate output accessible to the user because they send uuencoded
information. This section documents these commands for completeness
and as a reference for status display client writers.
</P>
<h2>The Reflectometer AMOR</h2>
<p>
The reflectometer AMOR probably has the most extensive of such
modules. It does a lot of things. It is configured into SICS with the
MakeAmorStatus command. Let us assume that it is configured into the
system as amorstatus. This object supports the following commands:
<dl>
<dt>amorstatus interest
<dd>This registers this connection for receiving automatic
notifications. Automatic notifications send are:
<DL>
<dt>SCANSTART
<dd> At scan start a message <b>ScanClear</b> is sent followed by the
uuencoded new x-axis for the plot.
<dt>SCANPOINT
<dd>At each scan point the arrays of counts in both detector are sent
in uuencoded form labelled arrow_spinupup and arrow_spinuplo.
<DT>COUNTSTART
<DD>The start of counting on the histogram memory. Send a message
<b>TOFClear</b> and then the uuencoded time binning labelled
arrow_time.
<DT>FILELOADED
<DD>activated each time user defined model data is loaded into the
SICS server. This data gets send as arrow_name in uuencoded form. Both
x- and y-axis are sent in floating point.
</DL>
Please note that floating point data is transformed to fixed point by
multiplication of 65653 before transfer. The first number in each
uuencoded message is an integer describing the length of the data. In
case of double data such as fileloaded the y-data follows immediatetly
after the x-data. Also the approriate data is automatically sent after
the interest command.
<dt>amorstatus collapse
<dd>sums all counts in all detectors in time and sends the data back
as an uuencoded image. The first two numbers in the message define the
dimensions of the data.
<dt>amorstatus sample name x1 x2 y1 y2
<dd>Sums the detector counts on an area defined by the rectangle x1,
x2, y1, y2. The length of this is the time binning. The data is sent
back in uuencoded form labelled arrow_name.
<dt>amorstatus clear
<dd> Clears all user loaded data.
<dt>amorstatus load filename scale
<dd> loads user defined data for distribution to the status display
clients. The y data is scaled according to the scale factor provided.
</dl>
</p>
</BODY>
</HTML>

11
doc/manager/template.htm Normal file
View File

@ -0,0 +1,11 @@
<HTML>
<HEAD>
<TITLE>The Tcl-interface to the SINQ histogram memory</TITLE>
</HEAD>
<BODY>
<H1>The Tcl-interface to The SINQ histogram memory</H1>
<P>
</P>
</BODY>
</HTML>

237
doc/manager/trouble.htm Normal file
View File

@ -0,0 +1,237 @@
<html>
<head>
<title>SICS Trouble Shooting</title>
</head>
<body>
<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
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 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
typing:
<pre>
startsics
</pre>
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.
</p>
<p>
When the SICS server hangs, or you want to enforce an reinitialization of
everything the server process must be killed. This can be accomplished either manually or through a shell script.
</p>
<h2>Stopping SICS</h2>
<p>
All SICS processes can be stopped through the command:
<pre>
killsics
</pre>
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 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> Restart the SICServer. Watch for any messages about things not being
connected or configured.
<LI> Restart and reconnect the client programs.
</OL>
If this fails (even after a second) time there may be a network problem which
can not be resolved by simple means.
</p>
<h2>Getting New SICS Software</h2>
<p>
Sometimes you might want to be sure that you have the latest SICS software.
This is how to get it:
<ol>
<li>Login to the instrument account.
<li>If you are no there type cd to get into the home directory.
<li>Type <b>killsics</b> at the unix prompt in order to stop the SICS server.
<li>Type <b>sicsinstall exe</b> at the unix prompt for copying new
SICS software from the general distribution area.
<li>Type <b> startsics</b> to restart the SICS software.
</ol>
</p>
<h2>Hot Fixes</h2>
<p>
When there is trouble with SICS you may be asked by one of the SICS
programmers to copy the most recent development reason of the SICS server
to your machine. This is done as follows:
<ol>
<li>Login to the instrument account.
<li>cd into the bin directory, for example: /home/DMC/bin.
<li>Type <b> killsics</b> at the unix prompt in order to stop the SICS server.
<li>Type <b>cp /data/koenneck/src/sics/SICServer .</b> at the unix prompt.
<li>Type <b> startsics</b> to restart the SICS software.
</ol>
<b>!!!!!! WARNING !!!!!!!. Do this only when advised to do so by a competent
SICS programmer. Otherwise you might be copying a SICS server in an
instable experimental state!</b>
</p>
<h2> HELP debugging!!!!</h2>
<p>
The SICS server hanging or crashing should not happen. In order to sort such
problems out it is very helpful if any available debugging information is
saved and presented to the programmers. Information available are the log
files as written continously by the SICS server and posssible core files
lying around. They have just this name: core. In order to save them create a
new directory (for example dump2077) and copy the stuff in there. This looks
like:
<pre>
/home/DMC> mkdir dump2077
/home/DMC> cp log/*.log dump2077
/home/DMC> cp core dump2077
</pre>
The <tt>/home/DMC> </tt> is just the command prompt. Please note, that core
files are only available after crashes of the server. These few commands
will help to analyse the cause of the problem and to eventually resolve it.
</p>
</body>
</html>

86
doc/manager/var.htm Normal file
View File

@ -0,0 +1,86 @@
<html>
<head>
<title>SICS Variables</title>
</head>
<body>
<h2>SICS Variables </h2>
<p>
In SICS most parameters necessary for instrument control are kept with the SICS
object implementing the functionality. However, there are some odd bits of
information which need to be known, mostly additional information about and
from the user, which should go into data files. Such information is kept in
SICS variables, created with the command VarMake detailed below.
</p>
<p>
Another usage for variables is to control composite movements of instrument
components. For instance for changing the wavelength it is necessary to
drive at least two motors, Theta and TwoTheta. Such behaviour is implemented
with some SICS special variables. Their creation is described below.
</p>
<p>
Variables are also used in order to control the SINQ automatic file name
creation scheme for data files. At SINQ, data files are put into a special
directory. The actual name consists of a prefix, a sequential number, the
last two digits of the year and an ending. All these components are
controlled by variables.
</p>
<p>
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
may may change the variable. Possible values are: Internal, Manager, User
and Spy.
<li> <b> MakeWaveLength nam mono </b> creates a wavelength variable nam.
The monochromator mono is used for adjustment.
<li> <b> MakeEnergy nam mono </b> creates a energy variable nam. The
monochromator mono is used for adjustment.
<li> <b> MakeO2T nam OM 2TM </b> creates an omega 2Theta dummy variable
with name nam for omega 2Theta scans. OM defines an omega motor, 2TM a two
theta motor.
<li><b>MakeDataNumber SicsDataNumber filename</b> This command makes a
variable SicsDataNumber available which holds the current sequential data
file number. filename is the complete path to the file were this data
number is stored. This file should never, ever be edited without good
reason, i.e. resetting the sequential number to 0 at the beginning of a
year.
</ul>
</p>
<p>
There are quite a few SICS variables which have special usages and should be
present. Some of them may need to be set by the user, all of them should be
inspectable by the user. Many of these variables are used when writing
NeXus data files. These special variables are:
<DL>
<DT> sample
<DD> The sample name. To be set by the user.
<DT> title.
<DD> The experiment title.
<DT> User
<DD> The name of the user to be specified in a data file.
<DT> Instrument.
<DD> The name of the instrument.
<DT> SicsDataPath
<DD>The full path name of the instruments data directory. Should have a / at
the end.
<DT> SicsDataPrefix
<DD> The prefix to use for data file names.
<DT> SicsDataPostFix
<DD> The ending to use for the data file name. Including the '.'.
<DT> Adress
<DD> The users adress.
<DT> phone
<DD> The users phone number.
<DT> email
<DD> The users e-mail adress.
<DT> fax
<DD> The users fax number.
</DL>
</p>
<p>
Some of the variables stated above should never be changed by a user. This
can be achieved by the variable lock command described in the user
documentation.
</p>
</body>
</html>