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

PSI sics-cvs-psi-2006

Browse Source
This commit is contained in:
koennecke
2006-05-08 02:00:00 +00:00
committed by Douglas Clowes
parent ae77364de2
commit 6e926b813f
388 changed files with 445529 additions and 14109 deletions
Download Patch File Download Diff File Expand all files Collapse all files

113
doc/manager/amor.htm Normal file
View File

@ -0,0 +1,113 @@
<HTML>
<HEAD>
<TITLE>Special Commands for the Reflectometer(AMOR)</TITLE>
</HEAD>
<BODY>
<H1>Special Commands for the Reflectometer (AMOR)</H1>
<P>
There are some special command initializations for the reflectometer AMOR.
These commands are most likely not portable to other instruments because
they encompass the special geometry at AMOR and the AMOR development has
not fully matured. The following initialization commands are available:
<dl>
<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.
</dl>
</P>
<h2>AMOR Status Display Commands</h2>
<p>
MakeAmorStatus creates a SICS command which is used by the AMOR status
display for displaying proceesed data, especially in TOF-mode. This module
provides 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 appropriate 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.
<dt>amorstatus projectytof
<dd>Returns a UUencoded 2D array of y against TOF.
</dl>
</p>
</BODY>
</HTML>

23
doc/manager/command.htm
View File

@ -12,6 +12,9 @@ initialisation file. Such special commands are described here.
<DL>
<DT>MakeRuenBuffer
<DD>MakeRuenBuffer makes the R&#252;nBuffer system available.
<dt>MakeBatchManager [name]
<DD>Installs the new batch buffer management system. If no name is
given, the default will be exe.
<DT>MakeDrive
<DD>MakeDrive craetes the drive command.
<DT>MakeScanCommand name countername headfile recoverfil
@ -81,13 +84,17 @@ the token force command.
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>MakeHKLMot hkl
<DD>Creates the drivable H, k, l virtual motors using hkl, an object created by
MakeHKL for calculations.
<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.
circle motors two theta, omega, chi and phi and the counter. This is no longer
maintained.
<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
@ -154,7 +161,7 @@ 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
<DT>MakeMesure name scanobject hklobject omega s2t 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:
@ -165,8 +172,8 @@ afterwards. MakeMesure takes a lot of parameters:
<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>s2t
<DD>The name of the two theta motor for use in omega two theta scans.
<DT>fileroot
<DD>The full path to the data file directory without final /
<dt>datanumberobject
@ -186,7 +193,13 @@ selector which is controlled by this wavelength variable.
<dT>MakeXYTable myname
<DD>Creates a XYTable object with the name myname. This object can store a
list of x-y values.
</DL>
<dt>MakeNXScript [name]
<dd>Installs the NeXus dictionary scripting module. If no name is given, the
name will be nxscript.
<dt>MakeSinq
<dd>Install the listener module for the accelerator divisions broadcast messages. This
creates a command sinq.
</DL>
</p>
<h4>The Scan Command Header Description File</h4>
<p>

47
doc/manager/focus.htm Normal file
View File

@ -0,0 +1,47 @@
<HTML>
<HEAD>
<TITLE>Special FOCUS Initializations</TITLE>
</HEAD>
<BODY>
<H1>Special FOCUS Initializations</H1>
<P>
These initailizations are special to the FOCUS instrument:
<dl>
<dt>InstallFocusmerge datafile
<dd>Installs the module which is responsible for merging focus data into
merged detector banks.
<dt>MakeFocusAverager average hmc
<dd>Installs the average command and the focusraw command into SICS which
are used by the FOCUS status client in order to display processed
histogram memory data.
</dl>
</P>
<h2>Special Internal FOCUS Support Commands</h2>
<p>
<dl>
<dt>focusraw bankid
<dd>Dumps in UUencoded form the content of the detector bank bankid. This is
required in order to add the TOF-binning to the data and in order to handle
the virtual merged detector bank which is built from contributions of the
three physical detector banks.
<dt>average start stop bankid
<dd>Sums the detectors between start and stop of detector bankid into a
histogram. A standard display in the status client.
<dt>focusmerge puttwotheta nxscriptmod bankname alias
<dd>Writes two theta values for the detector bank bankname into
the file described by the nxscript module nxsciptmod to the
alias alias. A helper function for data file writing.
<dt>focusmerge putmerged nxscriptmod alias
<dd>Writes the virtual merged detector bank into alias in
nxscriptmod.
<dt>focusmerge putsum nxscriptmod bankname alias
<dd>Writes the summed counts for detector bank bankname under alias
into nxscriptmod.
<dt>focusmerge putelastic nxscriptmod alias theoelastic
<dd>Calculate the position of the elastic line and write it to alias in
nxscriptmod. If no elastic line can be calculated, the theoretical
elastic line, theoelastic, is used.
</dl>
</p>
</BODY>
</HTML>

97
doc/manager/four.htm Normal file
View File

@ -0,0 +1,97 @@
<HTML>
<HEAD>
<TITLE>Initialization for Four Circle Diffractometers</TITLE>
</HEAD>
<BODY>
<H1>Initialization for Four Circle Diffractometers</H1>
<P>
This section describes how the modules which are special for a four
circle single crystal diffractometer are configured into SICS. The
following feautures are available:
<dl>
<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>MakeHKLMot hkl
<DD>Creates the drivable H, k, l virtual motors using hkl, an
object created by MakeHKL for calculations.
<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. This is no longer
maintained.
<DT>MakeMesure name scanobject hklobject omega s2t 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>s2t
<DD>The name of the two theta motor for use in 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>MakeUBCalc name hklobject
<dd>This installs a UB matrix calculation module with the name name
into SICS. The second parameter is a hklobject as created with MakeHKL
to which any calculated UB's can be transferred.
<dt>MakeHklscan scanobject hklobject
<dd>Installs the hklscan command which allows to scan in reciprocal space.
Scanobject is the name of SICS internal scan object, hklobject the name of a
reciprocal space calculation object as configured with MakeHKL.
<dt>MakeTRICSSupport
<dd>Installs a command, tricssupport, which helps the TRICS status
display.
</dl>
</p>
<p>
Commands implemented by tricssupport:
<dl>
<dt>tricssupport oldframe file idet nFrame
<dd>Loads and sends the frame nFrame of detector idet from file file in
UUencoded form.
<dt>tricssupport interest
<dd>Enables this connection to receive notifications whenever a new frame
of data had been written
<dt>tricssupport newframe
<dd>Called from scripts. Triggers sending new frames to all registered
connections.
</dl>
</P>
There are also a lot of scripted command available for four circle
diffractometers. These may be copied from tricscom.tcl. These include:
<dl>
<dt>four
<dd>print the four all important angles
<dt>tricsscan start step np
<dd>Omega scan with a PSD
<dt>psdrefscan file step np mode preset
<dd>Read reflections from file, drive to them, do a omega scan with tricsscan
using the parameters specified.
<dt>detscan start step np
<dd>Do a detector calibration scan.
<dt>phscan start step np
<dd>Do a phi scan
<dt>hklscan2d
<dd>Scanning reciprocal space with the area detector
<dt>scan2d
<dd>Configure SICS for general scanning with the PSD. This is meant
to supersede many of the special scans above.
<dt>scan1d
<dd>Configure SICS for general scanning with the single detector.
</dl>
</BODY>
</HTML>

243
doc/manager/gencom.htm Normal file
View File

@ -0,0 +1,243 @@
<HTML>
<HEAD>
<TITLE>Initialization of General Commands</TITLE>
</HEAD>
<BODY>
<H1>Initialization of General Commands</H1>
<P>
This section gives details on the initialization of commands which are
common to many different instruments. The command set of SICS can be tailored
to cover many specific needs. Moreover this system allows to replace
functionality by other implementations suited to another users taste. This
is a list of common command initialization commands.
<DL>
<DT>MakeRuenBuffer
<DD>MakeRuenBuffer makes the R&#252;nBuffer system available.
<dt>MakeBatchManager [name]
<DD>Installs the new batch buffer management system. If no name is
given, the default will be exe.
<DT>MakeDrive
<DD>MakeDrive creates the drive and run command.
<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>TokenInit 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>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>MakeO2T nam OM 2TM
<dd>creates an omega 2Theta virtual motor
with name nam for omega 2Theta scans. OM defines an omega motor, 2TM a two
theta motor.
<dt>MakeDataNumber SicsDataNumber filename
<dd>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.
<dT>MakeXYTable myname
<DD>Creates a XYTable object with the name myname. This object can store a
list of x-y values.
<dt>MakeSinq
<dd>Install the listener module for the accelerator divisions broadcast
messages. This creates a command sinq.
<dt>MakeMaximize counter
<dd>Installs a command max into SICS which implements a more efficient
algorithm for locating the maximum of a peak then scanning and peak or
center.
<dt>MakeMaxDetector name
<dd>Installs name into SICS which implements a command for locating
maxima on a two dimensional histogram memory image.
<dt>MakeLin2Ang name motor
<dd>Creates a virtual motor name which translates an input angle into a
translation along a tangent to the rotation axis. The distance of the
translation table can be configured as variable: name length once this
is established.
<dt>MakeSWHPMotor realmotor switchscript mot1 mot2 mot3
<dd>Creates switched motors mot1, mot2 and mot3 for real motor
realmotor. For switching the script switchscript is used. This
can be used when several motors are operated through the same
motor driver. This implementation is not completely general now.
</dl>
</P>
<h2>Monochromators</h2>
<p>
A monochromator is represented in SICS through a monochromator object which
holds all the parameters associated with the monochromator and virtual
motors which drive wavelength or energy. The commands to configure such a
monochromator are:
<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>MakeWaveLength nam mono
<dd>creates a wavelength variable nam. The monochromator mono is used for
adjustment.
<dt>MakeEnergy nam mono
<dd>creates a energy variable nam. The
monochromator mono is used for adjustment.
<dt>MakeOscillator name motor
<dd>Installs a module name which oscillates motor between the software
limits of the motor. This is useful for suppressing preferred
orientation effects on powder diffractometers.name then supports the
commands: start, stop, status which are self explanatory.
</dl>
</p>
<H2>Reoccuring Tasks</H2>
<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>
<H2>The SICS Online Help System</H2>
<P>
SICS has a simple built in help system. Help text is stored in simple
ASCII text files which are printed to the client on demand. The help
system can search for help files in several directories. Typically one
would want one directory with general SICS help files and another one
with instrument specific help files. If help is invoked without any
options, a default help file is printed. This file is supposed to
contain a directory of available help topics together with a brief
description. The normal usage is: help topicname . The help system
will then search for a file named topicname.txt in its help
directories.
</P>
<p>
A SICS manager will need to configure this help system. A new
directory can be added to the list of directories to search with the
command:
<pre>
help configure adddir dirname
</pre>
The default help file can be specified with:
<pre>
help configure defaultfile filename
</pre>
Each of these command given without a parameter print the current
settings.
</P>
<H2>Aliases in SICS</H2>
<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>
<h3>Object Aliases</h3>
<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 oldname newname
<DD>This command installs newname as alias for the object oldname.
</dl>
SicsAlias can only be used within initialization scripts. SicsAlias is
considered deprecated and can be replaced with the superior runtime
aliases described below.
</p>
<h3>Runtime Aliases</h3>
<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 aliasname SICSobject
<dd>This defines aliasname to be the alias for the SICS object SICSobject.
It is not needed that SICSobject already exists. If SICSobject is already
an alias, it is translated before definition.
Multiple translation is possible, depending on the order of definition.
When an alias is used, and it does not point to an existing object,
the behaviour is the same as if an unknown object would have been used.
<dt>DefineAlias aliasname
<dd>This command deletes the alias aliasname.
</dl>
</p>
<h3>Command Aliases</h3>
<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>
<h2>The AntiCollision Module</h2>
<p>
In some cases motors have to be drive in a coordinated way. For instance,
at TRICS, the chi motor may need to move first before omega can be
driven in order to avoid collisions. Or at the ECB instruments, only one
of eight motors in a rack can be driven at any given time. The anti collision
module now allows to implement this. Anticollisions pattern of
operation: Each
collaborating motor is registered with the anti collision module. When trying
to start such a motor, the anti collider just takes a note where it shoud go.
On the first status check, a program is called which has to
arrange the running of the motors into a sequence. This sequence then is
executed by the anti collision module. The program which arranges the
motors into a sequence is a configurable parameter and usually implemented
as a script in SICS own marco language. In the SICS initialization file this
requires the commands:
<dl>
<dt>AntiCollisionInstall
<dd>Creates the anitcollision module.
<dt>anticollision register motorname
<dd>Registers motorname with the anti collision module.
<dt>anticollision script scriptname
<dd>This command configures the script which is responsible for
arranging the sequence of operations.
</dl>
The script configured into anticollision is called with pairs
or motor names and targets as parameters, Example:
<pre>
sans2rack mot1 target1 mot2 target2 .....
</pre>
Within the anticollision script, the following command may be
used in order to define the sequence.
<dl>
<dt>anticollision clear
<dd>Clears the sequence list
<dt>anticollision add level motor target
<dd>Add motor with target to level in the sequence.
</dl>
</p>
</BODY>
</HTML>

616
doc/manager/hwini.htm
View File

@ -10,21 +10,392 @@ 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
port server program running on the instrument computer.
All such devices require on
initialisation the following parameters:
<ul>
<li><b>hostname</b> The name of the macintosh computer.
<li><b>hostname</b> The name of the instrument 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.
listening for requests. It is usually 4000.
<li><b>channel</b> The number of the RS-232 interface port
on the terminal server.
</ul>
</p>
<h3>Bus Access</h3>
<p>
SICS and its internals cover many common usage cases. However there are always
situations where SICS has to be bypassed and commands to be sent to a
controller directly. This can happen in order to satisfy a special request or
as first step in the integration of a special piece of hardware into SICS. In
order to do such things the following facilities are available:
<H4>Direct Access to RS232 Controllers or TCP/IP Controllers.</H4>
<p>
Both controllers listening on a TCP/IP port or RS-232 devices connected to a
terminal server can be directly accessed through the RS232 commands. The
first step in using this system is always to accounce the controller to SICS
using the command:
<pre>
MakeRS232Controller name terminalserver port
</pre>
in the SICS initialization file.
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>
Now various commands are available for interfacing with the RS232
controller. In the following description the SICS name of the
controller is replaced by the symbol rs232name.
<dl>
<dT>rs232name sendterminator
<dD>prints the current terminator used when sending data to the device
as hexadecimal numbers.
<dT>rs232name sendterminator h1h2..hn
<dD>sets the current terminator used when sending data to the device
to the characters described by the hexadecimal numbers h1 to hn. The
numbers are in the format 0xval, where val is the hex number.
<dT>rs232name replyterminator
<dD>prints the current terminator expected to terminate a response
from the device as a hexadecimal number.
<dT>rs232name replyterminator h1h2..hn
<dD>sets the current terminator expected to terminate a response from
the device to the characters described by the hexadecimal numbers h1
to hn.
The numbers are in the format 0xval, where val is the hex number.
<dt>rs232name timeout
<dd>prints the current timeout when waiting for a reponse from the
device.
<dt>rs232name timeout val
<dd>sets the timeout for waiting for responses from the device. The
value is in microseconds.
<dt>rs232name send data data data
<dd>sends the remainder of the line to the RS232 device and waits for
a response terminated with the proper reply terminator specified. This
commands waits at maximum timeout microseconds for a response. If a
valid response is obtained it is printed, otherwise an error message
occurs.
<dt>rs232name write data data data
<dd>writes the remainder of the line after write to the device without
waiting for a response.
<dt>rs232 available
<dd>checks if data is pending to be read from the device.
<dt>rs232 read
<dd>reads data from the device.
</dl>
</p>
<H4>Accessing Serial Ports (Old System)</H4>
<P>
In addition to the system describe above there is another system for accessing
serial ports which uses the SerPortServer program. The use of the system is
deprecated, new software should use the commands describe above. Nevertheless
the older sytem is described here for reference.
</p>
<p>
Serial port access is implemented as an extension to the Tcl macro language.
Essentially this is the same implementation as used in the program 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 SerPortServer.host port channel force
<li>Example: serialport p1 localhost 4000 5
</ul>
Such a command creates the command name1 and links it with serial port channel
channel on the instrument computer (localhost) running the SerPortServer program . Port is the port number on which the
SerPortServer 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 SerPortServer 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 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 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 serial port 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>
<h4>GPIB Controller Access</h4>
<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. Then 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
<dt>ni
<dd>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
documentation of the command set it is assumed that a GPIB controller
has been configured into the system under the name <b>gpib</b>. Please
note, that managers privilege is required in order to be allowed to
wrestle with this controller.
<dl>
<dt>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 connection. 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.
</dl>
<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>Controllers</h3>
<p>
For the same reason as stated above, it is necessary to represent controllers
within SICS. Controllers implement more then only device access but also
maintain common state or implement special behaviour.
</p>
<h4>ECB Controllers</h4>
<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. In fact, as
ECB documentation is not available, the only documentation on ECB is the
source code of tascom.
<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>
<H4>Siematic SPS Controllers</H4>
<P>
Siematic SPS controllers are used at SinQ for handling all the things which
fit 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 (Set a Digital I/O Bit).
<li>Read a status of instrument status packed into a bit (Read Digital I/O) .
<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>
<h4>General Controller Object and Choppers</h4>
<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> Motors</h3>
<p>
@ -42,12 +413,18 @@ 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
<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>Motor name el734hp rs232controllername motornum
<dd>Creates a motor object name using the newer motor drivers which access
the motor controller directly, without the serial port server.
rs232controllername is the name of a connection to the motor controll which
has been set up with MakeRS232, above. Motornum is the number of the motor in
the controller.
<DT>MakePIMotor name c804 pararray
<DD>Creates a motr name connected to a C804 motor controller from the
<DD>Creates a motor 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:
@ -136,7 +513,6 @@ at any given time. In SICS this is directed through the anticollider
module described elsewhere.
</DL>
</p>
<h3>Counting Devices</h3>
<p>
<DL>
@ -146,10 +522,21 @@ 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 mcstas
<dd>Creates a counter which interoperates with a
<a href="mcstas.htm">McStas</a> simulation. Please note,
that the McStas module mccontrol must have been initialized before this initialization
can work.
<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 EL737hp terminalserver port
<DD>Creates a counter object name which uses the faster driver which connects
directly to the terminal server without the serial port server program.
Terminalserver is the name of the instruments terminal server. Port is the
port number at which the terminal server publishes the port at which the EL737
controller is connected. Usually this 3000 + port number.
<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.
@ -183,12 +570,21 @@ HM. Histogram memory objects can be created using the command:
<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.
Currently these drivers are supported:
<dl>
<dt>SIM
<dd>for a simulated HM
<dt>SINQHM
<dd>for the SINQ histogram memory
<dt>tdc
<dd>for the Risoe histogram memory.
<dt>mcstas
<dd>for the integration with the <a href="mcstas.htm"> McStas</a> simulation.
</dl>
</DL>
Please care to note, that the SINQHM
requires a counter box for count control. This counter must have been
defined before creating the HM object.
As an example the configuration of a SINQHM HM with the name banana will be
shown:
<pre>
@ -246,188 +642,6 @@ 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>

6
doc/manager/ini.htm
View File

@ -20,7 +20,7 @@ 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.
normal shutdown of the server happens or variables change.
</p>
<p>
The SICS server configuration file is essentially a SICS macro language
@ -48,8 +48,8 @@ initialization.
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
<DD>Some macro definitions are used by so many instruments that
it was deemed appropriate to hold them in separate files. Such files
are included from instcom.tcl.
</dl>
</p>

1
doc/manager/inifile.htm
View File

@ -20,6 +20,7 @@ Go to:
<li> Advice about <a href=hwini.htm> hardware </a> configuration.
<li> A description of <a href = command.htm> command </a> initialisation.
<li> Managing the SICS <a href="helpman.htm"> help </a> system.
<li> Connecting SICS to <a href="mcstas.htm">McStas</a> Simulations.
</ul>
</p>
<!latex-on>

276
doc/manager/iscan.htm
View File

@ -3,31 +3,72 @@
<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>
<H1>The Internal Scan Commands</H1>
<h2>Scan Concepts</h2>
<p>
Scans in SICS involve an internal scan module and a lot of scripts which
wrap the internal scan module into a syntax liked by the users.
</p>
<p>
The internal scan module in SICS evolved a little over time. It turned
out that scans
are a demanding job for a programmer because of the plethora of
special scans people wish to perform and the many data file formats which
have to be supported. This requires a very high degree of
configurability. Under several refactorings the internal scan command
has grown to become:
<ul>
<li>A controller for the scan process.
<li>A container to store scanned variables and counts during the
process of a scan. This includes commands to store and retrieve such
values.
<li>A container for the configuration of the scan. A scan is
configured by specifying functions to be called at the various steps
during the scan. These are preconfigured to the standard scan
functions. An API is provided to replace some or all of the scan
functions by user defined ones.
</ul>
The internal scan object is augmented by a library of standard scan
functions. The transition to the new model is not yet clean in order
not to break to much old code.
</p>
<p>
The standard scan command can be configured into SICS using the command:
<dl>
<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 file after each scan point.
This allows for restarting of aborted scans.
</dl>
</p>
<p>
The scan object (named here xxscan, but may have another name) understands
the following commands:
<DL>
<DT>xxscan clear
<DD>clears the list of scan variables. Must be called before each scan with
different parameters.
<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>xxxscan log var
<dd>This command adds a variable to be logged during the scan. Can be slave
motors such as stt, om, chi, phi during four circle work. These variables
are not driven, just logged. var is the SICS variable to log. Only drivable
parameters may be logged in such a way.
<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 continue NP mode preset
<dd>Continues an interrupted scan. Used by the recovery feauture.
<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
@ -40,27 +81,44 @@ 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.
<DD>This command returns 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.
<DD>Retrieves the counts collected during the scan.
<dt>xxscan getmonitor i
<dd>Prints the monitor values collected during the scan for the
monitor number i
<dt>xxscan gettime
<dd>Prints the counting times for the scan points in the current scan.
<dt>xxscan np
<dd>Prints the number of points in the current 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 noscanvar
<dd>Prints the number of scan variables
<dt>xxscan getvarpar i
<dd>Prints the name , start and step of the scan variable number i
<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 uuinterest
<dd>As above but the array of counts is transferred in UU encoded
format.
<dt>xxscan dyninterest
<dd>As above but scan points are printed one by one as a list
containing: point number first_scan_var_pos counts.
<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
<DD> Calculates the integrated intensity of the peak and the variance of the
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,
@ -77,20 +135,96 @@ 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
for the description of user defined scans (Old Style).
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
<dd>Configures 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.
<li><b>script</b> Scan functions are overriden by the user.
<li><b>soft</b> The scan stores and saves software zero point corrected
motor positions. The standard is to save the hardware positions as
read from the motor controller.
<li><b>user</b> configures the old style user overridable scans.
</ul>
<dt>xxscan storecounts counts time mon1 mon2 ...
<dD>This stores an entry of count values into the scan data
structure. To be used from user defined scan functions. The scan
pointer is incremented by one.
<dt>xxscan storecounter
<dd>Store the counts and monitors in the counter object configured for
the scan into the scan data structure. Increments the scan pointer by
one.
<dt>xxscan appendvarpos i pos
<dd>Append pos to the array of positions for scan variable i. To be
used from user defined scan functions.
<dt>xxscan callback scanstart | scanpoint | scanend
<dd>Triggers callbacks configured on the scan object. May be used by
user functions implementing own scan loops.
<dt>xxscan function list
<dd>Lists the available configurable function names. The calling style
of these functions is described in the next section about stdscan.
<dt>xxscan function functionname
<dd>Returns the currently configured function for functionname.
<dt>xxscan function functionname newfunctionname
<dd>Sets a new function to be called for the function functionname in
the scan.
</DL>
</P>
<h2>User Definable Scan Functions</h2>
<p>The last commands in the last section allowed to overload the
functions implementing various operations during the scan with user
defined methods. This section is the reference for these
functions. The following operations during a scan be configured:
<dl>
<dt>writeheader
<dd>Is supposed to write the header of the data file
<dt>prepare
<dd>Prepare does all the necessary operations necessary before a scan
starts.
<dt>drive
<dd>Is called to drive to the next scan point
<dt>count
<dd>Is called at each scan point to perform the counting operation
<dt>collect
<dd>Is called for each scan point. This function is supposed to store
the scan data into the scan data structure.
<dt>writepoint
<dd>Is called for each scan point and is meant to print information
about the scan point to the data ile and to the user.
<dt>finish
<dd>Is called after the scan finishes and may be used to dump a data file
or perform other clean up operations after a scan.
<dt>userdata
<dd>This is the name of a user defined object which may be used to
store user data for the scan.
</dl>
The exact invocations of the functions:
<ul>
<li>writeheader scanobjectname userobjectname
<li>prepare scanobjectname userobjectname
<li>drive scanobjectname userobjectname point
<li>count scanobjectname userobjectname point mode preset
<li>collect scanobjectname userobjectname point
<li>writepoint scanobjectname userobjectname point
<li>finish scanobjectname userobjname
</ul>
scanobjectname is the name of the scan object invoking the
function. This can be used for querying the scan
object. userobjectname is the name of a entity as specified as
userdata in the configuration. point is the number of the current scan point.
</p>
<h2>User Defined Scans(Old Style)</h2>
<p>
<h2>User Defined Scans</h2>
This feauture allows to override only the counting operation during a scan.
This feauture is deprecated in favour of the user overridable scan functions
described above. As it is still used, however, here is the documentation
for reference.
</p>
<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
@ -98,8 +232,8 @@ 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
order to allow for 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:
@ -133,6 +267,106 @@ command:
In all this replace xxxscan with the name of the internal scan
command.
</p>
<h2>The Scan Command Header Description File</h2>
<p>
As if all this configurability is not enough, there is another
level of configurability.
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 is only
possible when the scan functions are left in their default configuration.
If scan functions are overloaded it is the users repsonsability to take
care of data file writing.
This section describes
the contents of the template 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>
<h2>Differential Scans</h2>
<p>
When aligning or when searching peaks a very fast scan is
required. This is the differential scan. It starts a motor and
collects counts while the motor is running. The counts collected are
the monitor normalized difference to the previous reading. This
functionality can be configured into SICS with the command:
<pre>
MakeDiffScan
</pre> in the configuration file. An optional parameter defines
another name then diffscan (the default) for this object. Differential
scans can only be run against one motor as it cannot be guaranteed that
motors involved in a coordinated movement operate at the same speed
without mechanical coupling. The
procedure to use diffscan is:
<ul>
<li>Configure a scan variable into a SICS scan object: xxscan add var
start step
<li>Run diffscan as: diffscan scanobjectname end_position_of_scan
This runs the differential scan. Scanobjectname is the name of a SICS
internal scan object. It will be used to store the results of the
scan. While the scan is running some basic information is printed. The
scan will range from the start given in the xxscan add command to the
end position given in this call.
</ul>
The diffscan object has two configurable parameters:
<dl>
<dt>monitor
<dd>The monitor number to normalize against. For maximum precision
this should be a monitor with a lot of intensity on it.
<dt>skip
<dd>The number of SICS main loop cycles to skip between readings. This
can be used to control the amount of data generated during a
differential scan. This may become a problem if there is fast hardware.
</dl>
A word of warning: positions found in differential scans may not be
totally correct. The differential scan might even miss peaks when the
relationship between motor speed and sampling rate is bad.
</p>
<p>
Diffscan is usally wrapped in a common script command:
<dl>
<dt>fastscan motor start stop speed
<dd>which does a fast scan for motor from start to stop. Before the scan
the motors speed is set to speed. The motor is set to its original speed
after termination of the scan.
</dl>
This script can be copied from one of the older instrument command files.
</p>
<h2>Peak Analysis</h2>
<p>
There are several other feautures which can be configured into SICS
which interact very closely with the scan module:
<dl>
<DT>MakePeakCenter scancommand
<DD>MakePeakCenter initialises the peak analysis commands peak and center. The
only parameter is the name of the internal scan command.
</dl>
</p>
<h2>Common Scan Scripts</h2>
<p>
There exists a library of script functions around the scan module which are
commonly used. They provide an object oriented wrapper around the internal
scan command and the <b>cscan</b> and <b>sscan</b> commands. These
commands can be made available by including the scancommand.tcl file into
the instruments configuration file.
</p>
</BODY>
</HTML>

85
doc/manager/macroman.htm
View File

@ -3,7 +3,7 @@
<TITLE>Programming SICS Macros</TITLE>
</HEAD>
<BODY>
<H2>Programming SICS Macros</H2>
<H1>Programming SICS Macros</H1>
<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.
@ -13,7 +13,7 @@ language can be used for the following purposes:
<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.
<LI>Building of more 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
@ -28,7 +28,7 @@ In the following sections a few pecularities of the SICS macro system will be
discussed.
</P>
<h3>Input/Output</h3>
<h2>Input/Output</h2>
<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.
@ -39,19 +39,25 @@ 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.
user documentation.
</p>
<h3>Error Handling</h3>
<h2>Error Handling</h2>
<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
this can be achieved by using the Tcl catch mechanism.
</p>
<P>
If things are seriously wrong or the users wishes to interrupt an operation
SICS interrupts are used. Scripts implementing measurement procedures may
need to test and even modify interrupt values.
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>
<h2>Interacting with SICS within a Script</h2>
<p>
There exist a few commands which allow to inquire or manipulate SICS
internals. Most of these commands are only available in macro scripts.
@ -73,10 +79,69 @@ the object var. var must be a drivable or countable object. The integer code ret
are defined in the SICS programmers documentation.
</DL>
</p>
<h2>SICS Interfaces in Tcl</h2>
<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.
Work has begun to implement SICS internal interfaces in Tcl. This opens the
port for writing even device drivers in Tcl. Another use is to define
virtual motors quickly in Tcl. At the time of writing, July 2005, this
is only developed for the object interface and the drivable interface.
For the meaning of internal SICS interfaces please consult the SICS
programmers documentation. Be warned: with the feautures described in this
section, you can mess up SICS badly.
</p>
<h3>The Object Interface</h3>
<p>
<dl>
<dt>MakeTclInt name
<dd>Creates an object name. This object then understands the following
commands:
<dl>
<dt> name savescript scriptname
<dd>Configures a script which will be called when it is time to dump
the status of the SICS server. This script will be called with the
name of the object as its only parameter.
<dt>name backup bla bla bla....
<dd>To be used from savescripts. Writes everything behind backup into the
status file.
</dl>
The use of this facility is to place special commands into the status file
which may, for instance, request calculations to be made or drive parameters
not caught in the standard SICS objects to special values. For example:
at SANS2 this is used in order to store attenuator and collimator
values. Both are implemented as scripted commands and thus do take part
in the standard SICS object saving scheme.
</dl>
</p>
<h3>Overriding the Drivable Interface with Tcl</h3>
<p>
The drivable interface of any given drivable object can be overriden with
tcl functions. This includes an object created with MakeTclInt. The syntax is:
<dl>
<dt>TclReplaceDrivable objname key scriptname tclName
<dd>This replaces the drivable interface function defined by key with the
script scriptname in the driveable interface of the SICS object object.
tclName is the name of an arbitrary Tcl object which can hold user data.
Possible function keys and their function signatures are:
<dl>
<dt>halt
<dd> haltscript, no parameters
<dt>checklimits
<dd>checklimitsscript targetvalue
<dt>setvalue
<dd>setvaluscript targetvalue
<dt>checkstatus
<dd>checkstatusscript, no parameters
<dt>getvalue
<dd>getvaluescript, no parameters
</dl>
All procedures, excpet getvaluescript, are supposed to return the
approriate SICS return codes (HW*) as integer numbers. Getvaluescript
is supposed to return the position of the device.
<dt>TclDrivableInvoke objname key
<dd>A debugging aid: Invokes the scripted function denoted by key of the
object objname and prints the results. The function keys are the same
as given above.
</dl>
</p>
</BODY>
</HTML>

32
doc/manager/manager.htm
View File

@ -33,14 +33,32 @@ which is described elsewhere.
<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 general SICS setup section.
<ul>
<li><a href="setup.htm">SICS Installation</a>
<li><a href="move.htm">Exchanging Hardware</a>
<li><a href="trouble.htm">Troubleshooting SICS</a>
</ul>
<Li> To the SICS Initialization File section.
<ul>
<li><a href="ini.htm">SICS Initialization Overview</a>
<li><a href="option.htm">SICS Server Options</a>
<li><a href="var.htm">SICS Variables</a>
<li><a href="hwini.htm">Hardware Configuration</a>
<li><a href="gencom.htm">Initialization of General Commands</a>
<li><a href="iscan.htm">The SICS Scan System</a>
<li><a href="nxscript.htm">Scripting NeXus Files</a>
<li>Initialization of Instrument Specific Commands.
<ul>
<li><a href="four.htm">Four Circle Commands</a>
<li><a href="tas.htm">Triple Axis Commands</a>
<li><a href="amor.htm">Reflectometer Commands</a>
<li><a href="sans.htm">Small Angle Scattering<a/> Commands.
<li><a href="focus.htm">FOCUS<a/> Commands.
</ul>
</ul>
<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.
<li> To the <a href="mcstas.htm">McStas simulation SICS</a> integration.
</ul>
</p>
<!latex-on>

32
doc/manager/managerman
View File

@ -26,6 +26,7 @@ CH--5232 Villigen--PSI\\
Switzerland\\
\end{center}
\clearpage
\clearpage
\tableofcontents
\clearpage
@ -40,23 +41,26 @@ to understand John Ousterhouts Tool Command Language,
which is described elsewhere.
%html setup.htm 1
%html inifile.htm 1
%html move.htm 2
%html trouble.htm 2
\chapter{The SICS Initialization File}
%html ini.htm 1
%html option.htm 1
%html var.htm 1
%html hwini.htm 1
%html command.htm 1
%html helpman.htm 2
%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 gencom.htm 2
%html iscan.htm 2
%html nxscript.htm 2
%html nxupdate.htm 2
%html ../user/trouble.htm 1
%html move.htm 1
\section{Instrument Specific SICS Initializations}
%html four.htm 3
%html tas.htm 3
%html amor.htm 3
%html sans.htm 3
%html focus.htm 3
%html macroman.htm 1
%html mcstas.htm 1
\end{document}

BIN
doc/manager/managerman.dvi Normal file
View File

Binary file not shown.

2341
doc/manager/managerman.tex Normal file
View File

File diff suppressed because it is too large Load Diff

80
doc/manager/managerman.toc Normal file
View File

@ -0,0 +1,80 @@
\contentsline {chapter}{\numberline {1}Introduction}{4}
\contentsline {chapter}{\numberline {2}SICS programs, Scripts and Prerequisites}{5}
\contentsline {section}{\numberline {2.1}Hardware}{5}
\contentsline {section}{\numberline {2.2}Server programs}{5}
\contentsline {chapter}{\numberline {3}General SICS Setup}{7}
\contentsline {section}{\numberline {3.1}System Control}{8}
\contentsline {section}{\numberline {3.2}Moving SICS}{9}
\contentsline {subsection}{\numberline {3.2.1} Moving the SICS Server to a new Computer}{9}
\contentsline {subsection}{\numberline {3.2.2}Exchanging the Serial Port Server}{9}
\contentsline {subsection}{\numberline {3.2.3}Exchanging the Histogram Memory}{10}
\contentsline {section}{\numberline {3.3}SICS Trouble Shooting }{10}
\contentsline {subsection}{\numberline {3.3.1}Check Server Status}{10}
\contentsline {subsection}{\numberline {3.3.2}Inspecting Log Files}{10}
\contentsline {subsection}{\numberline {3.3.3}Restarting SICS}{11}
\contentsline {subsection}{\numberline {3.3.4}Restart Everything}{11}
\contentsline {subsection}{\numberline {3.3.5}Starting SICS Manually}{11}
\contentsline {subsection}{\numberline {3.3.6}Test the SerPortServer Program}{11}
\contentsline {subsection}{\numberline {3.3.7}Trouble with Environment Devices}{12}
\contentsline {subsection}{\numberline {3.3.8} HELP debugging!!!!}{12}
\contentsline {chapter}{\numberline {4}The SICS Initialization File}{13}
\contentsline {section}{\numberline {4.1}Overview of SICS Initialization}{13}
\contentsline {section}{\numberline {4.2}SICS Options and Users}{14}
\contentsline {section}{\numberline {4.3}SICS Variables }{15}
\contentsline {section}{\numberline {4.4}SICS Hardware Configuration}{16}
\contentsline {subsection}{\numberline {4.4.1}Bus Access}{16}
\contentsline {subsubsection}{Direct Access to RS232 Controllers or TCP/IP Controllers.}{16}
\contentsline {subsubsection}{Accessing Serial Ports (Old System)}{17}
\contentsline {subsubsection}{GPIB Controller Access}{19}
\contentsline {subsection}{\numberline {4.4.2}Controllers}{20}
\contentsline {subsubsection}{ECB Controllers}{20}
\contentsline {subsubsection}{Siematic SPS Controllers}{21}
\contentsline {subsubsection}{General Controller Object and Choppers}{22}
\contentsline {subsection}{\numberline {4.4.3} Motors}{23}
\contentsline {subsection}{\numberline {4.4.4}Counting Devices}{24}
\contentsline {subsubsection}{Histogram Memory}{25}
\contentsline {subsection}{\numberline {4.4.5}Velocity Selectors}{26}
\contentsline {section}{\numberline {4.5}Initialization of General Commands}{27}
\contentsline {subsection}{\numberline {4.5.1}Monochromators}{28}
\contentsline {subsection}{\numberline {4.5.2}Reoccuring Tasks}{28}
\contentsline {subsection}{\numberline {4.5.3}The SICS Online Help System}{29}
\contentsline {subsection}{\numberline {4.5.4}Aliases in SICS}{29}
\contentsline {subsubsection}{Object Aliases}{29}
\contentsline {subsubsection}{Runtime Aliases}{29}
\contentsline {subsubsection}{Command Aliases}{30}
\contentsline {subsection}{\numberline {4.5.5}The AntiCollision Module}{30}
\contentsline {section}{\numberline {4.6}The Internal Scan Commands}{31}
\contentsline {subsection}{\numberline {4.6.1}Scan Concepts}{31}
\contentsline {subsection}{\numberline {4.6.2}User Definable Scan Functions}{34}
\contentsline {subsection}{\numberline {4.6.3}User Defined Scans(Old Style)}{35}
\contentsline {subsection}{\numberline {4.6.4}The Scan Command Header Description File}{35}
\contentsline {subsection}{\numberline {4.6.5}Differential Scans}{36}
\contentsline {subsection}{\numberline {4.6.6}Peak Analysis}{37}
\contentsline {subsection}{\numberline {4.6.7}Common Scan Scripts}{37}
\contentsline {section}{\numberline {4.7}Scripting NeXus Files}{37}
\contentsline {subsection}{\numberline {4.7.1}Usage}{38}
\contentsline {subsubsection}{File Opening and Closing}{38}
\contentsline {subsubsection}{Writing Things}{38}
\contentsline {section}{\numberline {4.8}Automatic Updating of NeXus Files}{39}
\contentsline {subsection}{\numberline {4.8.1}Prerequisites for Using the Automatic Update Manager}{39}
\contentsline {subsection}{\numberline {4.8.2}Installing Automatic Update}{40}
\contentsline {subsection}{\numberline {4.8.3}Configuring Automatic Update}{40}
\contentsline {section}{\numberline {4.9}Instrument Specific SICS Initializations}{40}
\contentsline {subsection}{\numberline {4.9.1}Initialization for Four Circle Diffractometers}{40}
\contentsline {subsection}{\numberline {4.9.2}Triple Axis Spectrometer Specific Commands}{42}
\contentsline {subsection}{\numberline {4.9.3}Special Commands for the Reflectometer (AMOR)}{42}
\contentsline {subsubsection}{AMOR Status Display Commands}{43}
\contentsline {subsection}{\numberline {4.9.4}SANS Special Commands}{44}
\contentsline {subsection}{\numberline {4.9.5}Special FOCUS Initializations}{45}
\contentsline {subsubsection}{Special Internal FOCUS Support Commands}{45}
\contentsline {chapter}{\numberline {5}Programming SICS Macros}{46}
\contentsline {section}{\numberline {5.1}Input/Output}{46}
\contentsline {section}{\numberline {5.2}Error Handling}{47}
\contentsline {section}{\numberline {5.3}Interacting with SICS within a Script}{47}
\contentsline {section}{\numberline {5.4}SICS Interfaces in Tcl}{47}
\contentsline {subsection}{\numberline {5.4.1}The Object Interface}{47}
\contentsline {subsection}{\numberline {5.4.2}Overriding the Drivable Interface with Tcl}{48}
\contentsline {chapter}{\numberline {6}The McStas SICS Interface}{49}
\contentsline {section}{\numberline {6.1}McStas Requirements and SICS Requirements}{50}
\contentsline {section}{\numberline {6.2}The McStas Reader}{50}
\contentsline {section}{\numberline {6.3}The McStas Controller}{51}

165
doc/manager/mcstas.htm Normal file
View File

@ -0,0 +1,165 @@
<HTML>
<HEAD>
<TITLE>The McStas SICS Interface</TITLE>
</HEAD>
<BODY>
<H1>The McStas SICS Interface</H1>
<P>
It is useful to drive a simulation of an instrument with the same interface as is used at
the original instruments. One of the better packages for performing simulations of neutron
scattering instruments, including samples, is McStas. This section describes the SICS
interface to McStas simulations. The interface consists of three parts:
<ul>
<li>A McStas controller module which controls the actual simulation.
<li>A McStas reader which is responsible for reading simulated data into
SICS counters and histogram memories.
<li>Counter and histogram memory drivers which redirect their actions to the
McStas controller module.
</ul>
The general ideas is that all parameters are handled through the normal SICS simulation
drivers. The counting operations, however, are linked with the McStas simulation. In order
to be portable, many aspects are controlled by scripts. These scripts are configured at the
McStas Controller. Several scripts must be defined:
<dl>
<dt>startmcstas
<dd>This script will be invoked when counting starts and has to collect the necessary
settings from SICS, construct a McStas command line and start the simulation. As a return
value this script has to return the PID of the started mcstat process.
<dt>mcstastest pid
<dd>Tests if the McStas simulation is still running.
<dt>mcstasdump pid
<dd>Has to send a signal to McStas which causes it to dump its data without terminating.
Current versions of McStas do this on receiving the USR2 signal.
<dt>mcstasstop pid
<dd>Stops the McStas simulation.
<dt>mcstasread
<dd>Reads the McStas simulation output and transfers monitor and histogram memory data
into the appropriate SICS objects.
</dl>
</p>
<h2>McStas Requirements and SICS Requirements</h2>
<p>
In order for the McStas SICS interface to work the McStas simulation has to be configured
in a certain way:
<ul>
<li>All parameters which have to pass between SICS and McStas have to be declared as
simulation parameters in the DEFINE INSTRUMENT section of the instrument definition file.
Alternatively SICS can write the data to be passed to McStas into a file. But then this
file must be read in the INITIALIZE section of the instrument definition and values must
be assigned to the appropriate McStas variables.
<li>In order for the NeXus-XML based reading to work McStas must dump its data into a single file:
use the <b>-f filename</b> option. The format must be <b> --format=XML</b>.
<li> In order to count on monitor, a modified monitor component, MKMonitor MUST be used in the
simulation. This component writes the collected total counts into a file. This file is
the read by SICS in order to determine the control monitor. Evaluating the McStas dump \
file each time proved to be to inaccurate. The name of the file containing the monitor
must be configured through: mccontrol configure mcmonfile name-of-file.
<li>The mcstas simulation executable must be declared with allowexec in order to be able
to start with the Tcl exec command.
</ul>
</p>
<h2>The McStas Reader</h2>
<p>
In order to enable transfer from McStas result files into SICS objects a reader object is
needed. This module supports XML formatted McStas files, with the output dumped into
one file. The McStas options to achieve this are: <b>-f filename --format="XML"</b>
This module supports the following commands:
<dl>
<dt>mcreader open filename
<dd>Opens a McStas simulation file for reading.
<dt>mcreader close
<dd>Closes a McStas file after use.
<dt>mcreader insertmon path object monitornumber scale
<dd>This transfers a monitor value from a previously opened McStas file into a SICS
monitor field. The McStas field read is the values tag belonging to the component. The
parameters:
<dl>
<dt>path
<dd>The path to the correct values field in the simulation file. The format is the same
as the path format for NXopenpath in the NeXus-API (which will internally be used). For
groups, the name attribute is used a path component.
<dt>object
<dd>The counter object into which the monitor is read. This is a limitation, with the
this McStas interface only counters can store monitors.
<dt>monitornumber
<dd>Monitornumber is the monitor\ channel into which the value is to be stored.
<dt>scale
<dd>Scale is an optional scale factor for the monitor. Real monitors have a
sensitivity of E-6, McStas monitors have an efficiency of 1.0. This factor allows to
correct for this.
</dl>
<dt>mcreader inserthm path hmobject scale
<dd>Inserts array data stored under path in the histogram memory array of hmobject which
must be a valid SICS histogram memory object. The path is the same as given for insertmon,
but of course the data part of the detector must be addressed. Scale is again an optional
scale factor which allows to scale the McStas counts to real counts.
</dl>
The mccreader module also supports reading data from any ASCII file into SICS. Mcreader
close and open are not required then. For reading histogram memory data, the appropriate
data has to be parsed into a SICSdata object first. Then
data can be trasnferred using the following commands:
<dl>
<dt>mcreader insertmondirect counter num value
<dd>Assigns value to the monitor num at the counter object counter. Monitor 0 is the
actual counts data.
<dt>mcreader inserthmfromdata hm data
<dd>Inserts the data in the SICSData object data into the histogram memory hm.
</dl>
</p>
<H2>The McStas Controller</h2>
<p>
The actual control of the "counting" operation of the McStas simulation is done by the
McStas controller module in SICS. Internally this module implements the routines for
counting virtual neutrons. Towards the SICS interpreter, an interface is exhibited which
allows to configure and test the McStas controller. The McStas Controller delegates many
tasks to script procedures written in SICS's internal Tcl scripting language. This is done
in order to achieve a degree of generality for various types of instruments and in order
to allow easier adaption to differing demands. This is the SICS interface implemented:
<dl>
<dt>mccontrol configure mcstart startscriptname
<dd>Configures the script which starts the McStas simulation. Startscriptname is the name
of a Tcl procedure which collects the necessary information from SICS, builds a command
line and finally starts the simulation. This script is expected to return either an error or
the PID of the started process. Startscriptname will be called with the parameters mode and
preset which represent the counting characteristics.
<dt>mccontrol configure mcisrunning runtestscriptname
<dd>Configures the name of a script which tests if the McStas process is still running.
Runtestscriptname is called with the PID as a parameter. This returns 0 in the case the
McStas simulation was stopped or 1 if it is still running.
<dt>mccontrol configure mcdump dumpscriptname
<dd>Configures the name of the script which causes McStas to dump intermediate results.
The script will be called with the PID of the started McStas process as a parameter.
<dt>mccontrol configure mckill killscript
<dd>Configure the name of a procedure which kills the current McStas simulation
process. KillScript will be called with the PID of the McStas simulation as a parameter.
<dt>mccontrol configure mccopydata copyscript
<dd>This configures the name of a script which has the task to read the results of
a McStas simulation and assign values to SICS monitors and histogram memories.
<dt>mccontrol configure update updateintervallinseconds
<dd>This configures the minimum time between McStas dumps in seconds. The idea is that
SICS buffers values during a simulation run and does not interrupt the McStas process to
often.
<dt>mccontrol configure update monitorscale
<dd>Configures the scaling factor to use on the monitor in monfile. Normal monitors have
a efficiency of 1E-6, the McStas monitor counts every neutron. This can be compensated
for by this scaling factor. Note that this scaling factor may be dependent on the
wavelength used.
<dt>mccontrol configure mcmonfile filename
<dd>This configures the file which mccontrol is going to read in order to watch the
simulation control monitor.
<dt>mccontrol list
<dd>Prints a listing of the configuration parameters.
<dt>mccontrol run scriptkey
<dd>Invokes one of the scripts configure for testing purposes. scripkey can be one of:
mcstart, mcisrunning, mcdump, mckill and mccopydata.
<dt>mccontrol finish
<dd>This calls waitpid on the PID of the McStas process. This should be done in
the mckill script. Otherwise it may occur that the McStas simulation turns into
a Zombie process.
</dl>
Standard scripts for many of the script routines required are provided for the unix
environment in the file mcsupport.tcl. Please note, that all system executables called
from scripts must be registrered with SICS using the allowexec command.
</p>
</BODY>
</HTML>

33
doc/manager/move.htm
View File

@ -9,16 +9,13 @@
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.
prefabricated account with the credentials: instbck/INSTBCKLNS on
lnsl15.
<li>Create the directory structure.
<li>Create and edit a suitable DataNumber file for the instrument and put it
into data/YYYY. YYYY is the year.
<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.
to match the new configuration.
<li>Try to start and debug.
</ol>
</P>
@ -28,22 +25,24 @@ histogram memory documsntation for instructions how to do that.
<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>Create a new .monitrc file by running makemonit.
<li>Exchange all references to the old terminal server in the instrument
configuration files to the new terminal 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>Get a new histogram memory computer from either Gerd Theidel,
the test setup in the electronics barrack.
<li>Put into the rack.
<li>Configure the HM boot parameters through the console conneted to
<li>Configure the HM boot parameters through the console connected 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.
found in the histogram memory documentation. Up to date boot
configuration parameters should be available under
/afs/psi.ch/group/sinqhm/boot/INST where INST is a place holder for the
instrument in upper case.
<li>Adapt the instrument configuration file to reflect the new name of
the HM.
<li>Start and debug.

73
doc/manager/nxscript.htm
View File

@ -57,6 +57,9 @@ 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 createxml nexusFile dictFile
<dd>Creates a new NeXus file based on XML 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.
@ -76,6 +79,10 @@ 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>nxscript putint alias value
<dd>Writes a single integer value to alias alias.
<dt>nxscript updatedictvar alias value
<dd>Updates the dictionary value alis to value.
<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
@ -108,7 +115,7 @@ 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
appropriate. This is a special feauture 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
@ -128,5 +135,69 @@ attribute.
designated by targetAlias.
</dl>
</p>
<H1>Automatic Updating of NeXus Files</H1>
<P>
Some instruments perform measurements for quite long counting
times. In such cases it is advisable to save the data measured so far
to file in order to protect against hardware or software failures. To
this purpose an automatic file upgrade manager is provided. On
installation the automatic update object is connected wth a counting
device through the the callback interface. This makes sure that the
update manager is automatically notified when counting starts or
finishes.
</P>
<h2>Prerequisites for Using the Automatic Update Manager</h2>
<p>
In order to use automatic updating, three programs must be
provided. Each of these programs can be a script which uses the
nxscript facility. It can also be a SICS command.
<dl>
<dt>startScript
<dd>This program is supposed to write the static part of the file. It
is called once when the file is created.
<dt>updateScript
<dd>This program is supposed to create and update the variable data
elements in the NeXus file. This is called frequently.
<dt>linkScript
<dd>This program is supposed to create the links within the NeXus
file. This is called once after startscript and updateScript have been
run.
</dl>
</p>
<h2>Installing Automatic Update</h2>
<p>
An automatic update object is installed into SICS with:
<pre>
updatefactory name countername
</pre>
name is a placeholder for the name under which SICS knows the
automatic update object. name is available as a SICS command later on.
countername is a placeholder for a counter
object (counter or HM) which triggers automatic updating of NeXus
files. This object has to support both the countable and callback
interfaces of SICS. Suitable SICS objects include counter and
histogram memory objects.
</p>
<h2>Configuring Automatic Update</h2>
<p>
The SICS command created with updatefactory (see above) supports a few
parameters which allow for the configuration of the whole
process. Parameters follow the normal SICS syntax. Futhermore there is
a subcommand list, which lists all configuration
parameters. Supported parameters are:
<dl>
<dt>startScript
<dd>The program supposed to write the static part of the file.
<dt>updateScript
<dd>The program supposed to create and update the variable data
elements in the NeXus file.
<dt>linkScript
<dd>This program supposed to create the links within the NeXus
file.
<dt>updateintervall
<dd>The time intervall in seconds between updates. The defualt is
1200, eg. 20 minutes.
</dl>
</p>
</BODY>
</HTML>

2
doc/manager/option.htm
View File

@ -47,7 +47,7 @@ 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
listening for telnet connections. If this option is missing login via telnet
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

44
doc/manager/sans.htm Normal file
View File

@ -0,0 +1,44 @@
<HTML>
<HEAD>
<TITLE>SANS Special Commands</TITLE>
</HEAD>
<BODY>
<H1>SANS Special Commands</H1>
<P>
Some special initializations for SANS Instruments:
<dl>
<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>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. This module contains
a hard coded formula which may only be applicable to the SANS at PSI.
<dt>MakePSDFrame
<dd>This installs a command into SICS which allows to retrieve a detector
image from the histogram memory, even in TOF-mode.
</dl>
Many other commands for controlling collimators, attenuators, beamstops
and shutters are implemented in Tcl. These commands use non standardizable
hardware such as the Siematic SPS.
</P>
</BODY>
</HTML>

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

@ -0,0 +1,11 @@
<HTML>
<HEAD>
<TITLE>The SICS Scan System</TITLE>
</HEAD>
<BODY>
<H1>The SICS Scan System</H1>
<P>
</P>
</BODY>
</HTML>

4
doc/manager/scrap1.htm Normal file
View File

@ -0,0 +1,4 @@
<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.

176
doc/manager/setup.htm
View File

@ -3,7 +3,7 @@
<TITLE>SICS Setup</TITLE>
</HEAD>
<BODY>
<H1>SICS programs, Scripts and Prerequisites<h1>
<H1>SICS programs, Scripts and Prerequisites</h1>
<p>
<h2>Hardware</h2>
The following hardware is usually present for any SICs instrument:
@ -17,7 +17,8 @@ The following hardware is usually present for any SICs instrument:
</ul>
The terminal server software is provided by Lantronix, see the
appropriate manuals for the device for a description. The histogram
memories are 68000 VME onboard computers running the VXworks realtime
memories are 68000 VME or MEN-A12 onboard computers
running the VXworks realtime
operating system and some home grown histogramming software documented
elsewhere.
</p>
@ -31,10 +32,10 @@ required:
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.
source code. The SerPortServer program is on its way out.
<dt>TecsServer
<dd>This is a TCP/IP server which watches over temperature
controllers. The only knwon source of documentation about this
controllers. The only known 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
@ -51,28 +52,6 @@ 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>
@ -90,9 +69,10 @@ 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.
<DD> The directory where some executables live.
<dt>inst_sics
<dd>All instrument configuration files and the SICServer live in
this directory. Replace inst by the name of the instrument as appropriate.
<DT>data
<DD>The data directory is the central place where all data files collected
at the instrument are stored. This directory contains subdirectories
@ -110,81 +90,107 @@ initialization file.
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>lib
<dd>Contains some files needed for running SICS clients locally.
<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.
<DT>tmp
<DD> A directory for temporary and PID files.
<DT>help
<DD>A directory for help files for the help system.
</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>
<h2>System Control</h2>
<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.
All commands listed in this section have to issued with the privilege of the
instrument user account.
</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:
In order to watch over all these servers, the <a
href="http://www.tildeslash.com/monit">monit</a> software is used. This is
a program which watches server processes and restarts them as necessary.
Monit can also be used to watch over hardware and the file system. Monit
writes a log file and can trigger e-mail alerts on certain
problematic conditions.
</p>
<p>
Monit itself is controlled through a configuration file, .monitrc, which lives
in the instrument accounts home directory. Monit also uses another Tcl program runwithpid which is responsible for starting and stopping server programs.
In order to configure all this, there is another program: makemonit which
creates the monit configuration file and copies and edits the runwithpid
program. The syntax of makemonit is:
<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.
<dt>makemonit instrument terminalserver data-mount-point hm1 hm2 ..
<dd>instrument is the instrument name in lowercase, terminalserver is the
name of the terminal server used for serial port access, data-mount-point is
the name of file system onto which the instruments data is written. This is
followed by a list of all the histogram memory computers used by the
instrument.
<dt>monitinit
<dd>monitinit is an alias which calls makemonit with all required parameters
for a given instrument in standard configuration.
</dl>
</p>
<p>
Monit itself can be controlled with the following commands:
<dl>
<dt>monit
<dd>Starts the monit daemon and all configured processes. This is only
necessary after a reboot of the system.
<dt>monit status
<dd>This shows a status message listing the status of all configured servers
and the checked hardware. The monit status is also available on the WWW from
http://lns00.psi.ch/monit/instrument. Replace instrument with the appropriate
instrument name.
<dt>monit stop target
<dd>Stops the server process target. The following targest exist:
<dl>
<dt>all
<dd>All processes
<dt>sicsserver
<dd>The SICS server
<dt>SerPortServer
<dd>The serial port server.
<dt>sync
<dd>The file synchronisation server.
<dt>tecs
<dd>The TecsServer for controlling environment devices.
<dt>simserver
<dd>A simulation server(not on all instruments).
</dl>
<dt>monit start target
<dd>Starts a server process, targest are the same as described above.
<dt>monit restart target
<dd>Stops and starts the process target. Targets are as listed above.
<dt>monit quit
<dd>Stops monit alltogether. Please note, that servers stay running with
this command. In order to sop everything the sequence: monit stop all;
monit quit is required.
<dt>startsics
<dd> This script starts all the necessary server programs for driving
the instrument through monit.
<dt>killsics
<dd>This script shuts down all instrument control servers properly through
monit.
<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>
</BODY>
</HTML>

37
doc/manager/tas.htm Normal file
View File

@ -0,0 +1,37 @@
<HTML>
<HEAD>
<TITLE>Triple Axis Spectrometer Specific Commands</TITLE>
</HEAD>
<BODY>
<H1>Triple Axis Spectrometer Specific Commands</H1>
<P>
One aim for the implementation of the triple axis spectrometer in SICS
was to implement as closely as possible the command set of the ILL program
MAD. For this, there are two implementations: an older one where
most things werde done in C-code. And a newer one which implements
a relaxter MAD emulation. The problem with the MAD emulation is that
MAD relies on the order of variables and motors in memory. The newer
MAD emulation obeys this only for the qh, qk, ql and en variables.
This section describes the newer more portable TAS setup. There are
some C-modules and a lots of scripts which implement the MAD emulation.
</P>
<p>
The TAS requires the following initializations in its instrument file:
<dl>
<dt>MakeTasUB tasub
<dd>Installs the TAS crystallographic calculation module into SICS. It will
have the name tasub (recommended).
<dt>MakeTasScan iscan tasub
<dd>Installs the module with the TAS specific scan functions into SICS. The
TAS implements its own data format resembling the ILL TAS data format.
</dl>
Moreover it is required to add the peak center module, drive, exe and a lot of
variables: polfile, alf1-4, bet1-4, ETAM ETAS ETAA.
</p>
<p>
The scripts for the MAD emulation live in the file tasubcom.tcl. This file
will need little editing in order to cope with another triple axis machine,
just a couple of path variables will need to be changed.
</p>
</BODY>
</HTML>

4
doc/manager/template.htm
View File

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

218
doc/manager/trouble.htm
View File

@ -6,6 +6,12 @@
<h1>SICS Trouble Shooting </h1>
<hr size=4 width="66%">
<H2>Check Server Status</h2>
<p>
One of the first things to do is to check the server status with:
monit status.
</p>
<hr size=4 width="66%">
<H2>Inspecting Log Files</h2>
<p>
Suppose something went wrong over the weekend or during the night and
@ -29,6 +35,11 @@ stamps which allow to find out when exactly a problem began to
appear.
</p>
<p>
There is also another log file, log/monit.log, which logs messages from
the monit daemon. This can be used to determine when server processes
were restarted or when hardware failed.
</p>
<p>
Quite often the inspection of the log files will indicate problems
which are not software related such as:
<ul>
@ -42,178 +53,65 @@ released before the motors move again.
<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.
<dl>
<dt>monit restart sicsserver
</dl>
</p>
<hr size=4 width="66%">
<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>
mechanics or electronics people were closer to the instrument then a
nautical mile.
<uL>
<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.
<li>Restart all of SICS with the sequence: monit stop all; monit quit; monit
<li>Wait for a couple of minutes for the system to come up.
</ul>
</p>
<h2>Getting New SICS Software</h2>
<hr size=4 width="66%">
<h2>Starting SICS Manually</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>
In order to find out if some hardware is broken or if the SICS server
initializes badly it is useful to look at the SICS servers startup messages.
The following steps are required:
<ul>
<li>monit stop sicsserver
<li>cd ~/inst_sics
<li>./SICServer inst.tcl | more
</ul>
Replace inst by the name of the instrument, as usual. Look at the screen
output in
order to find out why SICS does not initialize things or where the
initialization hangs. Do not forget to kill the SICServer thus started when
you are done and to issue the command: <b>monit start sicsserver</b> in order
to place the SICS server back under monits control again.
</p>
<h2>Hot Fixes</h2>
<hr size=4 width="66%">
<h2>Test the SerPortServer Program</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>
Sometimes the SerPortServer program hangs and inhibits the communication with
the RS-232 hardware. This can be diagnosed by the following procedure: Find
out at which port either a EL734 motor controller or a E737 counter box
lives. Then type:<b>asyncom localhost 4000 portnumber</b> This yields a
new prompt at which you type <b>ID</b>. If all is well a string identifying
the device will be printed. If not a large stack dump will come up.
The asyncom program can be exited by typing <b>quit</b>. If there is
a problem with the
SerPortServer program type: <b>monit restart SerPortServer</b> in order to
restart it.
</p>
<hr size=4 width="66%">
<h2>Trouble with Environment Devices</h2>
<p>
The first stop for trouble with temperature or other environment devices
is Markus Zolliker. A common problem is that old environment controllers
have not be deconfigured from the system and still reserve terminal server
ports. Thus take care to deconfigure your old devices when swapping.
</p>
<hr size=4 width="66%">
<h2> HELP debugging!!!!</h2>
<p>
The SICS server hanging or crashing should not happen. In order to sort such

19
doc/manager/var.htm
View File

@ -12,12 +12,6 @@ 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
@ -31,19 +25,6 @@ The exact syntax for creating variables looks like this:
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>