- Added tabledrive: table driven path for MARS

- Initial MARS development - Upgraded Manager Manual SKIPPED: psi/make_gen psi/psi.c psi/tabledrive.c psi/tabledrive.h psi/tabledrive.w psi/utils/SerPortServer.c
2005-07-22 14:56:18 +00:00
parent d96fb7377d
commit 76abbe1042
39 changed files with 1822 additions and 672 deletions
--- a/confvirtualmot.c
+++ b/confvirtualmot.c
@ -206,7 +206,7 @@ static int ConfCheckLimits(void *pData, float fVal, char *error, int errLen){
  while(iRet != 0)
  {
    LLDnodeDataTo(self->motorList,&tuktuk);
-    status = tuktuk.pDriv->CheckLimits(tuktuk.data,fVal,error,errLen);
+    status = tuktuk.pDriv->CheckLimits(tuktuk.data,tuktuk.value,error,errLen);
    if(status != 1){
      return status;
    }
--- a/doc/manager/amor.htm
+++ b/doc/manager/amor.htm
@ -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>
--- a/doc/manager/command.htm
+++ b/doc/manager/command.htm
@ -84,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
@ -157,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:
@ -168,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
+<DT>s2t
-<DD>The name of the omega two theta virtual motor for omega two theta scans.
+<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
@ -189,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>
--- a/doc/manager/focus.htm
+++ b/doc/manager/focus.htm
@ -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>
--- a/doc/manager/four.htm
+++ b/doc/manager/four.htm
@ -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>
--- a/doc/manager/gencom.htm
+++ b/doc/manager/gencom.htm
@ -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>
--- a/doc/manager/hwini.htm
+++ b/doc/manager/hwini.htm
@ -10,20 +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 the instrument computer 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 instrument computer.
 <li><b>port</b> The port number where the serial port server program is
 listening for requests. It is usually 4000.
-<li><b>channel</b> The number of the RS-232 interface on the Macintosh. 0 is
+<li><b>channel</b> The number of the RS-232 interface port 
-the standard Macintosh modem port, 1 is the standard Macintosh printer port, 
+ on the terminal server. 
 2 is the first connector on the interface extension box. This leads to much
 confusion which can be healed with a simple rule: If a device is connected
 to the Macintosh serial port extension box, then its channel number is the
 interface number on the box plus one.  
 </ul>
 </p>
 <h3>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>
@ -41,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
+<DD>This command creates an analog motor named name which is controlled 
-El734DC motor controller. The
+ 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:
@ -135,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,13 +523,20 @@ 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 McStas simulation. Please note,
+<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. 
@ -186,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
+Currently these drivers are supported: 
-, SINQHM for the SINQ histogram memory and tdc for the Risoe histogram memory.
+<dl>
- Please care to note, that the SINQHM
+<dt>SIM 
-requires a EL737 counter box for count control. This counter must have been
+<dd>for a simulated HM
-defined before creating the HM object.
+<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>
@ -249,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>
--- a/doc/manager/ini.htm
+++ b/doc/manager/ini.htm
@ -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
+<DD>Some macro definitions are used by so many instruments that
-it was deemed appropraite to hold them in separate files. Such files
+it was deemed appropriate to hold them in separate files. Such files
 are included from instcom.tcl. 
 </dl>
 </p>
--- a/doc/manager/iscan.htm
+++ b/doc/manager/iscan.htm
@ -4,18 +4,14 @@
 </HEAD>
 <BODY>
 <H1>The Internal Scan Commands</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>
 <h2>Scan Concepts</h2>
 <p>
-Scanning in SICS evolved a little over time. It turned out that scans
+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
@ -36,16 +32,31 @@ 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>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
@ -65,13 +76,13 @@ 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
@ -102,7 +113,7 @@ 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,
@ -119,15 +130,21 @@ 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
@ -173,7 +190,10 @@ starts.
 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 file and to the user.
+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.    
@ -183,9 +203,10 @@ The exact invocations of the functions:
 <li>writeheader scanobjectname userobjectname
 <li>prepare scanobjectname userobjectname
 <li>drive scanobjectname userobjectname point
-<li>count 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
@ -194,14 +215,20 @@ userdata in the configuration. point is the number of the current scan point.
 </p>
 <h2>User Defined Scans(Old Style)</h2>
 <p>
 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
 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
+order to allow for this commands have been defined which allow to append 
-to the scan data file and to store measured data in the scan data
+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:
@ -235,6 +262,39 @@ 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
@ -247,7 +307,8 @@ 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 in a coordinated movement operate at the same speed. The
+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
@ -273,6 +334,34 @@ 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>
--- a/doc/manager/macroman.htm
+++ b/doc/manager/macroman.htm
@ -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
+Work has begun to implement SICS internal interfaces in Tcl. This opens the
-macro language. For the notion of object interfaces see the 
+ port for writing even device drivers in Tcl. Another use is to define 
-SICS programmers documentation. This may be implemented in future when needed. 
+ 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>
--- a/doc/manager/manager.htm
+++ b/doc/manager/manager.htm
@ -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 general SICS setup section.
-<Li> To the <a href = inifile.htm> server initialision</a> section.
+<ul>
-<li> To the section describing <a href=special.htm>special commands</a> for
+<li><a href="setup.htm">SICS Installation</a>
-SICS administrators or programmers.
+<li><a href="move.htm">Exchanging Hardware</a>
-<li> Commands for <a href=status.htm>status display</a> support.
+<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> To the <a href="mcstas.htm">McStas simulation SICS</a> integration.
 <Li> Hints for <a href = "move.htm">moving</a> the SICS server or for Exchanging the serial port server. 
 </ul>
 </p>
 <!latex-on>
--- a/doc/manager/managerman
+++ b/doc/manager/managerman
@ -26,6 +26,7 @@ CH--5232 Villigen--PSI\\
 Switzerland\\
 \end{center}
 \clearpage
 \clearpage
 \tableofcontents
 \clearpage
@ -40,24 +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 gencom.htm 2
 %html helpman.htm 2
 %html mcstas.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 nxscript.htm 2
-%html nxupdate.htm 2
+\section{Instrument Specific SICS Initializations}
-%html ../user/trouble.htm 1
+%html four.htm 3
-%html move.htm  1
+%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}
--- a/doc/manager/mcstas.htm
+++ b/doc/manager/mcstas.htm
@ -7,7 +7,7 @@
 <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 SICS
+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.
@ -56,9 +56,6 @@ in a certain way:
  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.
 <li>Though  McStas can be made to dump its data by sending it a USR2 signal, it is 
 much cleaner and simpler to have McStas dump its data regularly through the use of the 
 Progress_bar component. 
 </ul>
 </p>
 <h2>The McStas Reader</h2>
@ -85,7 +82,7 @@ groups, the name attribute is used a path component.
 <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.
+ <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 
@ -99,15 +96,15 @@ groups, the name attribute is used a path component.
 </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 <a href="sicsdata.htm">SICSdata</a> object first. Then
+ 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.   
 </dl> 
 <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>
@ -144,7 +141,7 @@ line and finally starts the simulation. This script is expected to return either
  often. 
  <dt>mccontrol configure update monitorscale
  <dd>Configures the scaling factor to use on the monitor in monfile. Normal monitors have 
-   a efficeincy of 1E-6, the McStas monitor counts every neutron. This can be compensated 
+   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
--- a/doc/manager/move.htm
+++ b/doc/manager/move.htm
@ -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
+prefabricated account with the credentials: instbck/INSTBCKLNS on
-lnsa15. 
+lnsl15. 
-<li>Run <b>sicsinstall <tt>instrument</tt> </b> in the new instruemnt
+<li>Create the directory structure.
-account, thereby replacing instrument with the name of the instrument
+<li>Create and edit a suitable DataNumber file for the instrument and put it
-you are moving.
+ into data/YYYY. YYYY is the year.
 <li>Create and edit a suitable DataNumber file for the instrument. 
 <li>Edit the instrument configuration files and adapt the path names
-to match the new situation.
+to match the new configuration.
 <li>Configure the histogram memory to boot from the new computer, se
 histogram memory documsntation for instructions how to do that.    
 <li>Try to start and debug.
 </ol>
 </P>
@ -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
+<li>Create a new .monitrc file by running makemonit.
-the name of the new serial port server.
+<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,
+<li>Get a new histogram memory computer from either Gerd Theidel,
-the test setup in WHGA/247 or in cases of greatest need, from SLS.
+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.  
+found in the histogram memory documentation. Up to date boot 
-<li>Include the new HM into the /etc/hosts file of the instrument
+ configuration parameters should be available under 
-computer. 
+ /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.
--- a/doc/manager/nxscript.htm
+++ b/doc/manager/nxscript.htm
@ -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. 
@ -112,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
@ -132,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>
--- a/doc/manager/option.htm
+++ b/doc/manager/option.htm
@ -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
--- a/doc/manager/sans.htm
+++ b/doc/manager/sans.htm
@ -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>
--- a/doc/manager/scan.htm
+++ b/doc/manager/scan.htm
@ -0,0 +1,11 @@
 <HTML>
 <HEAD>
 <TITLE>The SICS Scan System</TITLE>
 </HEAD>
 <BODY>
 <H1>The SICS Scan System</H1>
 <P>
 </P>
 </BODY>
 </HTML>
--- a/doc/manager/setup.htm
+++ b/doc/manager/setup.htm
@ -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
+<DD> The directory where some executables live.
-server is kept along with local copies of all necessary clients, the server
+<dt>inst_sics
-initialisation files and special macro files defined for the instrument.
+<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
+All commands listed in this section have to issued with the privilege of the 
-apropriate command line and status display clients for each instrument. A user can make
+ instrument user account.
 this directory (and much more) available by including the line <b>
 source /data/lnslib/bin/lns.login</b> into her .login file. 
 </p>
 <h2> SICS Installation</h2>
 <p>
-All executables and files necessary to run SICS for each instrument is
+In order to watch over all these servers, the <a 
-avaialable under the /data/lnslib/distribution/sics hierarchy. 
+ href="http://www.tildeslash.com/monit">monit</a> software is used. This is
-The bin directory
+ a program which watches server processes and restarts them as necessary. 
-holds general executable files and a directory for each instrument which
+ Monit can also be used to watch over hardware and the file system. Monit 
-holds instrument specific files. SICS installation on a unix system is
+ writes a log file and can trigger e-mail alerts on certain 
-greatly simplified by using the <b>sicsinstall</b> korn shell script. This
+ problematic conditions. 
-script is available to each user. sicsinstall can be invoked simply by
+</p>
-typing sicsinstall at the command prompt. sicsinstall needs a subcommand in
+<p>
-order to know what it is expected to do:
+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
+<dt>makemonit instrument terminalserver data-mount-point hm1 hm2 ..
-<DD>copies knew executables from the development area to the distribution
+<dd>instrument is the instrument name in lowercase, terminalserver is the 
-directory. This command is meant to be used by computing staff only.
+ name of the terminal server used for serial port access, data-mount-point is 
-<DT>devfull
+ the name of file system onto which the instruments data is written. This is 
-<DD>as dev, but copies all files. This command is meant to be used by computing staff only.
+ followed by a list of all the histogram memory computers used by the 
-<DT>dmc
+ instrument.
-<DD>copies all files necessary for the instrument DMC.
+<dt>monitinit
-<DT>topsi
+<dd>monitinit is an alias which calls makemonit with all required parameters 
-<DD>copies all files necessary for the instrument TOPSI.
+ for a given instrument in standard configuration.
-<DT>sans
+</dl> 
-<DD>copies all files necessary for the instrument SANS.
+</p>
-<DT>hrpt
+<p>
-<DD>copies all files necessary for the instrument HRPT.
+Monit itself can be controlled with the following commands:
-<DT>amor
+<dl>
-<DD>copies all files necessary for the instrument AMOR
+<dt>monit
-<DT>focus
+<dd>Starts the monit daemon and all configured processes. This is only 
-<DD>copies all files necessary for the instrument FOCUS
+ necessary after a reboot of the system.
-<DT>tasp
+<dt>monit status
-<DD>copies all files necessary for the instrument TASP
+<dd>This shows a status message listing the status of all configured servers 
-<DT>druechal
+ and the checked hardware.  The monit status is also available on the WWW from
-<DD>copies all files necessary for the instrument DRUECHAL
+ http://lns00.psi.ch/monit/instrument. Replace instrument with the appropriate
-<DT>trics
+ instrument name.
-<DD>copies all files necessary for the instrument TRICS
+<dt>monit stop target
-<DT>save inst
+<dd>Stops the server process target. The following targest exist:
-<DD>copies all the instrument configuration files from the instrument
+<dl>
-account back to to the distribution area. Replace inst with the name
+<dt>all
-of the instrument in lower case. This call is necessary to save
+<dd>All processes
-modified instrument configurations.
+<dt>sicsserver
-<DT>doc
+<dd>The SICS server
-<DD>updates only the documentation on your disk.
+<dt>SerPortServer
-<DT>exe
+<dd>The serial port server.
-<DD>copies only new executable files from the distribution area. This is the
+<dt>sync
-recommended option when you want to be sure, that you have the latest
+<dd>The file synchronisation server.
-version of SICS before reporting a bug.
+<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> 
 Most of these options require you to be in the home directory of the
 instrument account. sicsinstall checks for this and warns you if this is not
 the case.  Directory structures are checked for and created as needed.
 </p>
 </BODY>
 </HTML>
--- a/doc/manager/tas.htm
+++ b/doc/manager/tas.htm
@ -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>
--- a/doc/manager/template.htm
+++ b/doc/manager/template.htm
@ -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>
--- a/doc/manager/trouble.htm
+++ b/doc/manager/trouble.htm
@ -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
+<dl>
-behaviour etc. This document shall help to solve these problems. The usual
+<dt>monit restart sicsserver
-symptom will be that a client cannot connect to the server or the server is
+</dl>
 not responding. 
 </p>
 <p>
 An essential prerequisite of SICS is that the servers are up
 and running. The system is configured to restart the SICServer whenever it
 fails. Only after a reboot or when the keepalive processes were killed (see
 below) the SICServer must be restarted. This is done for all instruments by
 typing: 
 <pre>
 startsics 
 </pre>
 at the command prompt. startsics actually starts several programs, see
 the Setup section for details. All programs are started by means of a 
 shell script called
 <b>keepalive</b>. keepalive is basically an endless loop which calls
 the program again and agaian and thus ensures that the program will
 never stop running.   
 </p>
 <p> 
 When the SICS server hangs, or you want to enforce an reinitialization  of 
 everything  the server process must be killed. This can be accomplished either manually or through a shell script. 
 </p>
 <h2>Stopping SICS</h2>
 <p>
 All SICS processes can be stopped through the command:
 <pre>
 killsics
 </pre>
 given at the unix command line. You must be the instrument user 
 (for example DMC) on the instrument computer for this to work properly.
 </p>
 <h2>Finding the SICS server</h2>
 <p>The first thing when killing the SICS server manually is to find the 
 server process.
 Log in as  Instrument user on the instrument computer (for instance DMC on
 lnsa05). Type the command:
 <pre>
 /home/DMC> ps -A
 </pre>
 Note the capital A given as parameter. The reward will be listing like this:
 <pre width =132>
  PID TTY      S           TIME CMD
    0 ??       R       01:56:28 [kernel idle]
    1 ??       I        1:24.44 /sbin/init -a
    3 ??       IW       0:00.20 /sbin/kloadsrv
   24 ??       S       40:39.58 /sbin/update
   97 ??       S        0:04.87 /usr/sbin/syslogd
   99 ??       IW       0:00.03 /usr/sbin/binlogd
  159 ??       S        1:43.70 /usr/sbin/routed -q
  285 ??       S        1:00.45 /usr/sbin/portmap
  293 ??       S        6:03.45 /usr/sbin/ypserv
  299 ??       I        0:00.37 /usr/sbin/ypbind -s -S psunix,lnsa05.psi.ch
  307 ??       I        0:00.52 /usr/sbin/mountd -i
  309 ??       I        0:00.07 /usr/sbin/nfsd -t8 -u8
  311 ??       I        0:00.09 /usr/sbin/nfsiod 7
  317 ??       S        5:51.54 /usr/sbin/automount -f /etc/auto.master -M /psi
  370 ??       I        0:28.58 -accepting connections (sendmail)
  389 ??       S        1:41.15 /usr/sbin/xntpd -g -c /etc/ntp.conf
  419 ??       S        6:00.16 /usr/sbin/snmpd
  422 ??       S        1:00.91 /usr/sbin/os_mibs
  438 ??       S       34:29.67 /usr/sbin/advfsd
  449 ??       I        3:16.29 /usr/sbin/inetd
  482 ??       IW       0:11.53 /usr/sbin/cron
  510 ??       IW       0:00.02 /usr/lbin/lpd
  525 ??       I        5:31.67 /usr/opt/psw/psw_agent -x/dev/null -f/usr/opt/psw/psw_agent.conf
  532 ??       I        0:00.74 /usr/opt/psw/psw_sensor_syswd 1 -x/dev/null
  555 ??       I        0:00.58 /usr/bin/nsrexecd
  571 ??       I        0:20.27 /usr/dt/bin/dtlogin -daemon
  583 ??       S        1:38.27 lpsbootd -F /etc/lpsodb -l 0 -x 1
  585 ??       IW       0:00.04 /usr/sbin/getty /dev/lat/620 console vt100
  586 ??       IW       0:00.03 /usr/sbin/getty /dev/lat/621 console vt100
  587 ??       I       35:59.85 /usr/bin/X11/X :0 -auth /var/dt/authdir/authfiles/A:0-aaarBa
  657 ??       I        0:01.46 rpc.ttdbserverd
 4705 ??       IW       0:00.05 dtlogin   -daemon
 9127 ??       I        0:00.37 /usr/bin/X11/dxconsole -geometry 480x150-0-0 -daemon -nobuttons -verbose -notify -exitOnFail -nostdin -bg gray
 9317 ??       IW       0:00.73 dtgreet -display :0
 14412 ??       S        0:39.71 netscape
 15524 ??       I        0:00.57 rpc.cmsd
 21678 ??       S        0:00.11 telnetd
 31912 ??       S        0:10.65 /home/DMC/bin/SICServer /home/DMC/bin/dmc.tcl
  584 console  IW +     0:00.21 /usr/sbin/getty console console vt100
 21978 ttyp1    S        0:00.63 -tcsh (tcsh)
 22269 ttyp1    R  +     0:00.10 ps -A
 </pre>
 This is a listing of all running processes on the machine where this command
 has been typed. Note, in this case, at the bottom in the line starting with 
 <tt> 31912 ?? </tt> an entry for the SICS server. In this example the server
 is running. If the server is down, no such entry would be present. 
 </p>
 <h2> Killing a hanging SICS server </h2>
 <p>
 Suppose, the situation is that the SICS server does not respond anymore. It
 needs to be forcefully exited. Please note, that it is always better to
 close the server via the <tt>Sics_Exitus</tt> command typed with manager
 privilege in one of the command clients. In order to kill the server it is
 needed to find him first using the scheme given above. The information
 needed is the number given as first item in the same line where the server
 is listed. In this case: <tt>31912</tt>. Please note, that this number will
 always be different. The command to force the server to stop is:
 <pre>
 /home/DMC> kill -9 31912
 </pre>
 Note, the second parameter is the number found with <tt>ps -A</tt>.  The
 SICServer will be restarted automatically by the system. Occasionally, it
 may happen, that you cannot connect to the SICS server after such an
 operation. This is due to some network buffering problems. Doing the killing
 again usually solves the problem.
 </p>
 <h2> Shutting The SICS Server Down Completely</h2>
 <p>
 This is done for you by the killsics shell script. Just type 
 <pre>
 killsics
 </pre>
 at the unix command line. Here is what killsics does for you:  
 In order to completely shutdown the SICS server two process must be killed:
 the actual SICS server and the process which automatically restarts the
 SICServer. The latter must be killed first. It can be found in the ps -A
 listing as a line reading <b>keepalive SICServer </b>. Kill that one as
 described above, then kill the SICServer. For restarting SICS after this,
 use the startsics command.  
 </p>
 <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.
+mechanics or electronics people were closer to the instrument then a
-<OL>
+ 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 
+<li>Restart all of SICS with the sequence: monit stop  all; monit quit; monit
-connected or configured.
+<li>Wait for a couple of minutes for the system to come up. 
-<LI> Restart and reconnect the client programs.
+</ul>
 </OL>
 If this fails (even after a second) time there may be a network problem which
 can not be resolved by simple means.
 </p>
-<h2>Getting New SICS Software</h2>
+<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. 
+In order to find out if some hardware is broken or if the SICS server 
-This is how to get it:
+ initializes badly it is useful to look at the SICS servers startup messages. 
-<ol>
+The following steps are required:
-<li>Login to the instrument account.
+<ul>
-<li>If you are no there type cd to get into the home directory. 
+<li>monit stop sicsserver
-<li>Type <b>killsics</b> at the unix prompt in order to stop the SICS server.
+<li>cd ~/inst_sics
-<li>Type <b>sicsinstall exe</b> at the unix prompt for copying new
+<li>./SICServer inst.tcl | more
-  SICS software from the general distribution area.
+</ul>
-<li>Type <b> startsics</b> to restart the SICS software. 
+Replace inst by the name of the instrument, as usual. Look at the screen 
-</ol>
+ 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 
+Sometimes the SerPortServer program hangs and inhibits the communication with 
- programmers to copy the most recent development reason of the SICS server
+ the RS-232 hardware. This can be diagnosed by the following procedure: Find 
- to your machine. This is done as follows:
+ out at which port either a EL734 motor controller or a E737 counter box
-<ol>
+ lives. Then type:<b>asyncom localhost 4000 portnumber</b> This yields a
-<li>Login to the instrument account.
+ new prompt at which you type <b>ID</b>. If all is well a string identifying 
-<li>cd into the bin directory, for example: /home/DMC/bin.
+ the device will be printed. If not a large stack dump will come up. 
-<li>Type <b> killsics</b> at the unix prompt in order to stop the SICS server.
+ The asyncom  program can be exited by typing <b>quit</b>. If there is 
-<li>Type <b>cp /data/koenneck/src/sics/SICServer .</b> at the unix prompt.
+ a problem with the
-<li>Type <b> startsics</b> to restart the SICS software. 
+ SerPortServer program type: <b>monit restart SerPortServer</b> in order to 
-</ol>
+ restart it.  
 <b>!!!!!! WARNING !!!!!!!. Do this only when advised to do so by a competent 
 SICS programmer. Otherwise you might be copying a SICS server in an 
 instable experimental state!</b>
 </p>
 <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
--- a/doc/manager/var.htm
+++ b/doc/manager/var.htm
@ -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>
--- a/doc/user/autosms.htm
+++ b/doc/user/autosms.htm
@ -0,0 +1,31 @@
 <HTML>
 <HEAD>
 <TITLE>Automatic SMS Notification</TITLE>
 </HEAD>
 <BODY>
 <H1>Automatic SMS Notification</H1>
 <P>
 On some instruments an automatic notification system is installed which 
 can be configured to send an SMS when the instrument is stopped. An 
  instrument is considered stopped when there has been no counting or driving 
  activity for a configurable amount of time and there is beam at SINQ. This 
  system can be controlled with the follwoing commands:
 <dl>
 <dt>autosms
 <dd>Shows if the autosms system is enabled or disabled
 <dt>autosms on | off
 <dd>Switches automatic notfications on or off.
 <dt>autosms number [val]
 <dd>Without a parameter, displays the telphone number for the SMS, with a parameter
 configures the telephone number. Telephone numbers must be all numbers without
 hyphens or anything else.
 <dt>autosms maxidle [val]
 <dd>Without a parameter, queries the  idle time before a SMS is sent. With a 
  parameter sets a new value for the inactivity period which triggers a message. 
 </dl> 
 Please use the configurable settle time with environment controllers such as 
 temperature controllers in order to avoid false messages while waiting for the 
  temperature to settle. 
 </P>
 </BODY>
 </HTML>
--- a/doc/user/sinq.htm
+++ b/doc/user/sinq.htm
@ -0,0 +1,24 @@
 <HTML>
 <HEAD>
 <TITLE>The Sinq Module</TITLE>
 </HEAD>
 <BODY>
 <H1>The SINQ Module</H1>
 <P>
 On some instruments a module is installed which listens to the broadcast messages 
 of the accelerator division. This gives information about the rinag and sinq status.
 The following commands are recognized:
 <dl>
 <dt>sinq
 <dd>Prints the last full text ring status message. Please note that this may be 
  empty for some minutes right after a restart of SICS. 
 <dT>sinq beam
 <dd>Returns the current beam on SINQ
 <dt>sinq beamavg
 <dd>Returns the average beam on SINQ as measured the last 5 minutes.
 <dt>sinq ring
 <dd>Returns the acclerator ring current.
 </dl>
 </P>
 </BODY>
 </HTML>
--- a/doc/user/system.htm
+++ b/doc/user/system.htm
@ -72,5 +72,9 @@ when useless data files have been created during tests. As this is
 critical command in normal user operations, this command requires
 managers privilege. 
 </p>
 <p>
 <b>sicsidle</b> prints the number of seconds since the last invocation of a counting
 or driving operation. Used in scripts.
 </p>
 </body>
 </html>
--- a/hkl.c
+++ b/hkl.c
@ -60,6 +60,8 @@
         self->fUB[5], self->fUB[6], self->fUB[7], self->fUB[8]);
      fprintf(fd,"%s hm %d\n",name, self->iHM);
      fprintf(fd,"%s scantolerance %f\n", name,self->scanTolerance);
      fprintf(fd,"%s nb %d\n", name, self->iNOR);
      fprintf(fd,"%s phiom %d\n", name, self->iOMPHI);
      return 1;
   }
@ -853,6 +855,27 @@ static int calculateNormalBeamOmega(MATRIX z1, pHKL self,
     if(self->iNOR == 0)
     {
       status = calculateBisecting(z1,self,pCon,fSet, myPsi, iRetry);
       /*
        * Betrand mode: wrap phi rotation into omega
        */
       if(self->iOMPHI > 0) {
       		if(ABS(fSet[2] - .0) < .1 || ABS(fSet[2] - 180.) < .1){
       			fSet[1] -= fSet[3];
       			fSet[3] = .0;
       			if(fSet[1] < 0.){
       			  fSet[1] += 360.;
       			}
 			if(fSet[1] > 360.0){
 			  fSet[1] -= 360.;
                        }     
       		} else {
       			snprintf(pBueffel,511,
       				"ERROR: for omphi mode chi must be 0 or 180, is %f",
       				fSet[2]);
       			SCWrite(pCon,pBueffel,eError);
       			return 0;
       		}
       }
     } 
     else if(self->iNOR == 1)
     {
@ -1333,8 +1356,9 @@ ente:
     if(strcmp(argv[1],"list") == 0 )
     {
        sprintf(pBueffel,
-           "lambda = %f   Normal Beam = %d  Quadrant = %d HM = %d", 
+           "lambda = %f   Normal Beam = %d  PHIOM = %d Quadrant = %d HM = %d", 
-                self->fLambda, self->iNOR, self->iQuad,self->iHM);
+                self->fLambda, self->iNOR, self->iOMPHI,
                	self->iQuad,self->iHM);
        SCWrite(pCon,pBueffel,eValue);
        sprintf(pBueffel,"UB = { %f %f %f",
                self->fUB[0], self->fUB[1],self->fUB[2]);
@ -1547,8 +1571,9 @@ ente:
     {
        if(argc < 3)
        {
-          SCWrite(pCon,"ERROR: Insufficient number of arguments to HKL nb",eError);
+		  snprintf(pBueffel,511,"%s.nb = %d",argv[0],self->iNOR);
-          return 0;       
+		  SCWrite(pCon,pBueffel,eValue);
          return 1;       
        }
        if(!SCMatchRights(pCon,usUser))
        {
@ -1571,6 +1596,29 @@ ente:
        SCSendOK(pCon);
        return 1;
     }
 /*------------- phi omega mode (to be removed)  */
     else if(strcmp(argv[1],"phiom") == 0)
     {
        if(argc < 3)
        {
 		  snprintf(pBueffel,511,"%s.phiom = %d",argv[0],self->iOMPHI);
 		  SCWrite(pCon,pBueffel,eValue);
          return 1;       
        }
        if(!SCMatchRights(pCon,usUser))
        {
          return 0;
        }
        if(!isNumeric(argv[2]))
        {
          sprintf(pBueffel,"ERROR: %s was not recognized as a number", argv[2]);
          SCWrite(pCon,pBueffel,eError);
          return 0;
        }
        self->iOMPHI = atoi(argv[2]);
        SCSendOK(pCon);
        return 1;
     }
 /*------------- quadrant  */
     else if(strcmp(argv[1],"quadrant") == 0)
     {
--- a/hkl.h
+++ b/hkl.h
@ -28,6 +28,7 @@
 /*------------------------------------------------------------------------*/
  int SetWavelengthVariable(SConnection *pCon, pHKL self, pSelVar pVar);
  int SetWavelengthManual(pHKL self, float fVal);
  void SetHKLScanTolerance(pHKL self, float value);
  int SetUB(pHKL self, float fUB[9]);
  int GetUB(pHKL self, float fUB[9]);
  int SetNOR(pHKL self, int iNOB);
@ -47,6 +48,6 @@
  int HKLAction(SConnection *pCon, SicsInterp *pSics, void *pData,
                int argc, char *argv[]);  
-  void SetHKLScanTolerance(pHKL self, float fVal);
+
 #endif  
--- a/hkl.i
+++ b/hkl.i
@ -15,6 +15,7 @@
                         int iManual;
                         double fLastHKL[5];
                         int iNOR;
                         int iOMPHI;
                         int iQuad;
                         int iHM;
                         pMotor pTheta;
--- a/hkl.tex
+++ b/hkl.tex
@ -26,6 +26,7 @@ $\langle$hkldat {\footnotesize ?}$\rangle\equiv$
 \mbox{}\verb@                         int iManual;@\\
 \mbox{}\verb@                         double fLastHKL[5];@\\
 \mbox{}\verb@                         int iNOR;@\\
 \mbox{}\verb@                         int iOMPHI;@\\
 \mbox{}\verb@                         int iQuad;@\\
 \mbox{}\verb@                         int iHM;@\\
 \mbox{}\verb@                         pMotor pTheta;@\\
@ -104,6 +105,7 @@ $\langle$hklint {\footnotesize ?}$\rangle\equiv$
 \mbox{}\verb@/*------------------------------------------------------------------------*/@\\
 \mbox{}\verb@  int SetWavelengthVariable(SConnection *pCon, pHKL self, pSelVar pVar);@\\
 \mbox{}\verb@  int SetWavelengthManual(pHKL self, float fVal);@\\
 \mbox{}\verb@  void SetHKLScanTolerance(pHKL self, float value);@\\
 \mbox{}\verb@  int SetUB(pHKL self, float fUB[9]);@\\
 \mbox{}\verb@  int GetUB(pHKL self, float fUB[9]);@\\
 \mbox{}\verb@  int SetNOR(pHKL self, int iNOB);@\\
--- a/hkl.w
+++ b/hkl.w
@ -21,6 +21,7 @@ The object uses the following object data structure:
                         int iManual;
                         double fLastHKL[5];
                         int iNOR;
                         int iOMPHI;
                         int iQuad;
 	                 int iHM;
                         pMotor pTheta;
--- a/mcstas/dmc/DataNumber
+++ b/mcstas/dmc/DataNumber
@ -1,3 +1,3 @@
- 81 
+ 89 
 NEVER, EVER modify or delete this file
 You'll risk eternal damnation and a reincarnation as a cockroach!|n
--- a/mcstas/dmc/MKMonitor.comp
+++ b/mcstas/dmc/MKMonitor.comp
@ -91,7 +91,7 @@ TRACE
      p2sum += p*p;
      currentCount++;
      if(dumpCount > 0 && currentCount > dumpCount){
-      	dumpTotal(controlfile,Nsum);
+      	dumpTotal(controlfile,(long)Nsum);
      	currentCount = 0;
      }
      SCATTER;
--- a/mcstas/dmc/vdmccom.tcl
+++ b/mcstas/dmc/vdmccom.tcl
@ -163,7 +163,7 @@ proc copydmcdata { } {
 	mcreader open $home/dmc.xml
 	mcreader insertmon \
 	"/$mcversion/DMC_diff/dmc.xml/PSD_sample/values" \
-	counter 1 [expr 1./1000]
+	counter 1 [expr 1./700]
 	mcreader insertmon \
 	"/$mcversion/DMC_diff/dmc.xml/Det9/det9.dat/values" \
 	counter 5
@ -171,7 +171,7 @@ proc copydmcdata { } {
 	if { $hmScale <= 0} {
 		set hmScale 1e9
 	} else {
-		set hmScale [expr $hmScale * 1e7]
+		set hmScale [expr $hmScale * 1e5]
 	}
 	clientput "HM scale = $hmScale"
 	mcreader inserthm \
@ -188,7 +188,7 @@ mccontrol configure mcstart rundmcoptsim
 mccontrol configure mccopydata copydmcdata
 mccontrol configure update 60
 mccontrol configure mcmonfile $home/monfile
-mccontrol configure monitorscale [expr 1. /1000]
+mccontrol configure monitorscale [expr 1. /700]
 mccontrol configure mcdump mcstasdump
 #--------------------------------------------------------------------------
 # A count command for VDMC
--- a/mcstas/dmc/vdmcstatus.tcl
+++ b/mcstas/dmc/vdmcstatus.tcl
@ -14,7 +14,7 @@ sicsdatapostfix .hdf
 sicsdatapostfix setAccess 0
 sicsdataprefix powder
 sicsdataprefix setAccess 0
-starttime 2005-07-08 10:41:56
+starttime 2005-07-19 17:15:54
 starttime setAccess 2
 comment3 UNKNOWN
 comment3 setAccess 2
@ -121,9 +121,9 @@ a1 precision 0.010000
 a1 AccessCode 2.000000
 a1 movecount 10.000000
 banana CountMode monitor
-banana preset 2.000000
+banana preset 4000.000000
 # Counter counter
-counter SetPreset 2000.000000
+counter SetPreset 40000000.000000
 counter SetMode Monitor
 # Motor twothetad
 twothetad sign 1.000000
--- a/tasdrive.c
+++ b/tasdrive.c
@ -64,6 +64,7 @@ static int readTASMotAngles(ptasUB self, SConnection *pCon,
  /*
    Analyzer
  */
  if(self->tasMode != ELASTIC){
 	  status = MotorGetSoftPosition(self->motors[A5],pCon,&val);
  	if(status == 0){
    	return status;
@ -77,7 +78,9 @@ static int readTASMotAngles(ptasUB self, SConnection *pCon,
 	if(ABS(val/2. - theta) > .1){
    	SCWrite(pCon,"WARNING: theta analyzer not half of two theta",eWarning);
  	}
-  
+  } else {
  		ang->analyzer_two_theta = ang->monochromator_two_theta;
  }
  /*
    crystal
@ -123,6 +126,9 @@ static float TASGetValue(void *pData, SConnection *pCon){
      SCWrite(pCon,"ERROR: out of memory calculating Q-E variables",eError);
      return -999.99;
    }
    if(self->math->tasMode == ELASTIC){
    	self->math->current.kf = self->math->current.ki;
    }
    self->math->mustRecalculate = 0;
  }
  val = getTasPar(self->math->current,self->code);
@ -148,6 +154,9 @@ static float TASQMGetValue(void *pData, SConnection *pCon){
      SCWrite(pCon,"ERROR: out of memory calculating Q-E variables",eError);
      return -999.99;
    }
    if(self->math->tasMode == ELASTIC){
    	self->math->current.kf = self->math->current.ki;
    }
    self->math->mustRecalculate = 0;
  }
  val = getTasPar(self->math->current,self->code);
@ -165,10 +174,16 @@ static int TASCheckLimits(void *pData, float fVal, char *error, int iErrLen){
 /*---------------------------------------------------------------------------------*/
 static int TASHalt(void *pData){
  ptasMot self = (ptasMot)pData;
-  int i;
+  int i, length = 12;
  assert(self);
-  for(i = 0; i < 12; i++){
+  /**
   * disregard non existing analyzer motors
   */
  if(self->math->tasMode == ELASTIC){
  	length = 8;
  }
  for(i = 0; i < length; i++){
    if(self->math->motors[i] != NULL){
      self->math->motors[i]->pDrivInt->Halt(self->math->motors[i]);
    }
@ -233,7 +248,9 @@ static int startMotors(ptasMot self, tasAngles angles,
  /*
    analyzer
  */
-  val = self->math->motors[A5]->pDrivInt->GetValue(self->math->motors[A5],pCon);
+  if(self->math->tasMode != ELASTIC){
 	  val = self->math->motors[A5]->pDrivInt->GetValue(self->math->motors[A5],
 	  pCon);
    	if(ABS(val - angles.analyzer_two_theta/2.) > MOTPREC){
    	status = self->math->motors[A5]->pDrivInt->SetValue(self->math->motors[A5],
 								pCon,
@ -267,7 +284,8 @@ static int startMotors(ptasMot self, tasAngles angles,
 	if(self->math->motors[ACH] != NULL){
 	    curve = maCalcHorizontalCurvature(self->math->machine.analyzer,
 					    angles.analyzer_two_theta);
-    val = self->math->motors[ACH]->pDrivInt->GetValue(self->math->motors[ACH],pCon);
+    	val = self->math->motors[ACH]->pDrivInt->GetValue(self->math->motors[ACH],
    		pCon);
    	if(ABS(val - curve) > MOTPREC){
      	status = self->math->motors[ACH]->pDrivInt->SetValue(self->math->motors[ACH],
 								pCon,
@ -277,6 +295,8 @@ static int startMotors(ptasMot self, tasAngles angles,
 	     }
 	   }
 	 }
  }
  if(driveQ == 0){
    return OKOK;
  }
@ -415,12 +435,16 @@ static int calculateAndDrive(ptasMot self, SConnection *pCon){
 }
 /*-----------------------------------------------------------------------------*/
 static int checkMotors(ptasMot self, SConnection *pCon){
-  int i, status;
+  int i, status, length = 12;
  self->math->mustRecalculate = 1;
  if(self->math->tasMode == ELASTIC){
  		length = 8;
  }
  for(i = 0; i < 12; i++){
    if(self->math->motors[i] != NULL){
-      status = self->math->motors[i]->pDrivInt->CheckStatus(self->math->motors[i],pCon);
+      status = self->math->motors[i]->pDrivInt->CheckStatus(self->math->motors[i],
      	pCon);
      if(status != HWIdle && status != OKOK){
 	return status;
      }
--- a/tasub.c
+++ b/tasub.c
@ -67,6 +67,8 @@ static int tasUBSave(void *pData, char *name, FILE *fd){
  saveReflections(self,name,fd);
  if(self->tasMode == KICONST){
     fprintf(fd,"%s const  ki\n",name);
  }else if(self->tasMode == ELASTIC){
  	fprintf(fd,"%s const elastic\n",name);
  } else {
    fprintf(fd,"%s const  kf\n",name);
  }
@ -175,11 +177,15 @@ static int readTASAngles(ptasUB self, SConnection *pCon,
  /*
    Analyzer
  */
  if(self->tasMode != ELASTIC){
 	  status = MotorGetSoftPosition(self->motors[A6],pCon,&val);
  	if(status == 0){
    	return status;
  	}
  	ang->analyzer_two_theta = val;
  } else {
  	ang->analyzer_two_theta = ang->monochromator_two_theta;
  }
  /*
    crystal
@ -526,7 +532,7 @@ static int addReflection(ptasUB self, SicsInterp *pSics,
 			 SConnection *pCon, 
 			 int argc, char *argv[]){
  tasReflection r;
-  int status;
+  int status, count = 11;
  char pBueffel[256];
  tasAngles angles;
  Tcl_DString list;
@ -560,7 +566,10 @@ static int addReflection(ptasUB self, SicsInterp *pSics,
    return 0;
  } 
-  if(argc >= 11){
+  if(self->tasMode == ELASTIC){
  	count = 10;
  }
  if(argc >= count){
    status = Tcl_GetDouble(InterpGetTcl(pSics),argv[5],&r.angles.a3);
    if(status != TCL_OK){
      snprintf(pBueffel,255,"ERROR: failed to convert %s to number",argv[5]);
@ -592,6 +601,7 @@ static int addReflection(ptasUB self, SicsInterp *pSics,
      return 0;
    } 
 	r.qe.ki = energyToK(r.qe.ki);
    if(self->tasMode != ELASTIC){
    	status = Tcl_GetDouble(InterpGetTcl(pSics),argv[10],&r.qe.kf);
    	if(status != TCL_OK){
      	snprintf(pBueffel,255,"ERROR: failed to convert %s to number",argv[10]);
@ -599,6 +609,9 @@ static int addReflection(ptasUB self, SicsInterp *pSics,
      	return 0;
    	} 
    	r.qe.kf = energyToK(r.qe.kf);
    } else {
    	r.qe.kf = r.qe.ki;
    }
  } else {
    if(argc > 5){
      SCWrite(pCon,
@ -612,6 +625,9 @@ static int addReflection(ptasUB self, SicsInterp *pSics,
    r.qe.ki = maCalcK(self->machine.monochromator,r.angles.monochromator_two_theta);
    r.qe.kf = maCalcK(self->machine.analyzer,r.angles.analyzer_two_theta);
  }
  if(self->tasMode == ELASTIC){
  	r.qe.kf = r.qe.ki;
  }
  if(ABS(r.qe.ki - r.qe.kf) > .01) {
    SCWrite(pCon,"WARNING: KI != KF!",eWarning);
  }
@ -918,11 +934,19 @@ static int calcRefAngles(ptasUB self, SConnection *pCon,
  char pBueffel[256];
  int status;
  if(self->tasMode == ELASTIC){
 	  if(argc < 6){
    	SCWrite(pCon,"ERROR: need Qh, Qk, Ql, EI for calculation",
 	    	eError);
    	return 0;
 	  }
  } else {
 	  if(argc < 7){
    	SCWrite(pCon,"ERROR: need Qh, Qk, Ql, EI, EF for calculation",
 	    	eError);
    	return 0;
  	}
  } 
  status = Tcl_GetDouble(InterpGetTcl(pSics),argv[2],&q.qh);
  if(status != TCL_OK){
    snprintf(pBueffel,255,"ERROR: failed to convert %s to number",argv[2]);
@ -947,12 +971,16 @@ static int calcRefAngles(ptasUB self, SConnection *pCon,
    SCWrite(pCon,pBueffel,eError);
    return 0;
  } 
  if(self->tasMode != ELASTIC){
 	  status = Tcl_GetDouble(InterpGetTcl(pSics),argv[6],&q.kf);
  	if(status != TCL_OK){
    	snprintf(pBueffel,255,"ERROR: failed to convert %s to number",argv[6]);
    	SCWrite(pCon,pBueffel,eError);
    	return 0;
  	}
  } else {
  	q.kf = q.ki;
  }
  q.ki = energyToK(q.ki);
  q.kf = energyToK(q.kf);
@ -975,11 +1003,18 @@ static int calcRefAngles(ptasUB self, SConnection *pCon,
    return 0;
    break;
  }
  if(self->tasMode != ELASTIC){
 	  snprintf(pBueffel,255," %8.2f   %8.2f %8.2f %8.2f %8.2f   %8.2f",
 		   angles.monochromator_two_theta, 
 	   		angles.a3, angles.sample_two_theta,
 	   		angles.sgl, angles.sgu,
 	   	angles.analyzer_two_theta);
  } else {
 	  snprintf(pBueffel,255," %8.2f   %8.2f %8.2f %8.2f %8.2f",
 		   angles.monochromator_two_theta, 
 	   		angles.a3, angles.sample_two_theta,
 	   		angles.sgl, angles.sgu);
  }
  SCWrite(pCon,pBueffel,eValue);
  return 1;
 }
@ -992,11 +1027,19 @@ static int calcQFromAngles(ptasUB self, SConnection *pCon,
  char pBueffel[256];
  int status;
  if(self->tasMode != ELASTIC){
 	  if(argc < 8){
    	SCWrite(pCon,"ERROR: need a2, a3, a4, sgu, sgl, a6 for calculation",
 	    	eError);
    	return 0;
  	}
  } else {
 	  if(argc < 7){
    	SCWrite(pCon,"ERROR: need a2, a3, a4, sgu, sgl for calculation",
 	    	eError);
    	return 0;
  	}
  } 
  status = Tcl_GetDouble(InterpGetTcl(pSics),argv[2],
 			 &angles.monochromator_two_theta);
  if(status != TCL_OK){
@ -1028,12 +1071,16 @@ static int calcQFromAngles(ptasUB self, SConnection *pCon,
    SCWrite(pCon,pBueffel,eError);
    return 0;
  } 
  if(self->tasMode != ELASTIC){
 	  status = Tcl_GetDouble(InterpGetTcl(pSics),argv[7],&angles.analyzer_two_theta);
  	if(status != TCL_OK){
    	snprintf(pBueffel,255,"ERROR: failed to convert %s to number",argv[7]);
    	SCWrite(pCon,pBueffel,eError);
   	 return 0;
  	}
  } else {
  		angles.analyzer_two_theta = angles.monochromator_two_theta;
  } 
  status = calcTasQEPosition(&self->machine,angles,&q);
  switch(status){
  case UBNOMEMORY:
@ -1042,6 +1089,9 @@ static int calcQFromAngles(ptasUB self, SConnection *pCon,
    break;
  }
  if(self->tasMode == ELASTIC){
  		q.kf = q.ki;
  }
  snprintf(pBueffel,255,"%8.4f %8.4f %8.4f %8.4f %8.4f",
 	   q.qh, 
 	   q.qk,
@ -1265,6 +1315,9 @@ static int tasUpdate(SConnection *pCon, ptasUB self){
    SCWrite(pCon,"ERROR: out of memory calculating Q-E variables",eError);
    return 0;
  }
  if(self->tasMode == ELASTIC){
  	self->current.kf = self->current.ki;
  }
  self->mustRecalculate = 0;
  SCSendOK(pCon);
  return 1;
@ -1369,8 +1422,11 @@ int TasUBWrapper(SConnection *pCon,SicsInterp *pSics, void *pData,
 	self->tasMode = KICONST;
      } else if(strcmp(argv[2],"kf") == 0){
 	self->tasMode = KFCONST;
      } else if(strcmp(argv[2],"elastic") == 0){
 	self->tasMode = ELASTIC;
      } else {
-	SCWrite(pCon,"ERROR: unknown triple axis mode, accepted are ki, kf",
+	SCWrite(pCon,
 		"ERROR: unknown triple axis mode, accepted are ki, kf, elastic",
 		eError);
 	return 0;
      }
@ -1379,6 +1435,8 @@ int TasUBWrapper(SConnection *pCon,SicsInterp *pSics, void *pData,
    } else {
      if(self->tasMode == KICONST){
 	snprintf(pBueffel,131,"%s.const = ki",argv[0]);
      } else if(self->tasMode == ELASTIC){
      	snprintf(pBueffel,131,"%s.const = elastic", argv[0]);
      } else {
 	snprintf(pBueffel,131,"%s.const = kf",argv[0]);
      }
--- a/tasublib.c
+++ b/tasublib.c
@ -581,20 +581,34 @@ int calcTasPowderPosition(ptasMachine machine, tasAngles angles,
 void setTasPar(ptasQEPosition qe, int tasMode, int tasVar, double value){
  double et;
-  assert(tasMode == KICONST || tasMode == KFCONST);
+  assert(tasMode == KICONST || tasMode == KFCONST || tasMode == ELASTIC);
  switch(tasVar){
  case KF:
  	if(tasMode == ELASTIC){
  		qe->kf = qe->ki;
  	} else {
 	    qe->kf = value;
  	}
    break;
  case EF:
  	if(tasMode == ELASTIC){
  		qe->kf = qe->ki;
  	}else {
 	    qe->kf = energyToK(value);
  	}
    break;
  case KI:
    qe->ki = value;
    if(tasMode == ELASTIC){
    	qe->kf = value;
    }
    break;
  case EI:
    qe->ki = energyToK(value);
    if(tasMode == ELASTIC){
    	qe->kf = qe->ki;
    }
    break;
  case QH:
    qe->qh = value;
@ -612,6 +626,8 @@ void setTasPar(ptasQEPosition qe, int tasMode, int tasVar, double value){
    } else if(tasMode == KFCONST){
      et = KtoEnergy(qe->kf) + value;
      qe->ki = energyToK(et);
    }else if(tasMode == ELASTIC){
    	qe->kf = qe->ki;
    } else {
      assert(0);
    }
--- a/tasublib.h
+++ b/tasublib.h
@ -21,6 +21,10 @@
 /*========================== defines for tasMode ====================*/
 #define KICONST 1
 #define KFCONST 2
 #define ELASTIC 3 
 /*
 * in elastic mode A5, A5 will be disregarded and ki = kf at all times
 */
 /*=========================== TAS Variables =========================*/
 #define EI 1
 #define KI 2
`@ -1,3 +1,3 @@`
	`81`	`89`
	`NEVER, EVER modify or delete this file`	`NEVER, EVER modify or delete this file`
	`You'll risk eternal damnation and a reincarnation as a cockroach!\|n`	`You'll risk eternal damnation and a reincarnation as a cockroach!\|n`