| SICS manual for the SANS I instrument | ||
|---|---|---|
| <<< Previous | Next >>> | |
In SICS any client can issue commands to the SICS server. This is a potential cause for trouble with users issuing conflicting commands without knowing. In order to deal with this problem a token mechanism has been developed. A connection can grab a token and then has full control over the SICS server. Any other connection will not be privileged to do anything useful, except for looking at things. A token can be released manually with a special command or is automatically released when the connection dies. Another command exists which allows a SICS manager to force his way into the SICS server. The commands in more detail:
Reserves control over the instrument to the client issuing this command. Any other client cannot control the instrument now. However, other clients are still able to inspect variables.
Releases the control token. Now any other client can control the instrument again. Or grab the control token.
This command forces an existing grab on a token to be released. This command requires manager privilege. Furthermore a special password must be specified as third parameter in order to do this. This command does not grab control though.
SICS has a built in macro facility. This macro facility is aimed at instrument managers and users alike. Instrument managers may provide customised measurement procedures in this language, users may write batch files in this language. The macro language is John Ousterhout's [1] Tool Command Language (TCL) [2]. A set of important Tcl commands are described in section the Section called TCL command language interface. To execute batch files three commands are available:
This command tries to open the file batchfile and executes the script in this file. If not an absolute path name is defined the SICS server will search in the directory /home/SANS/bin. However, you don't have privileges to save files in this directory. For executing batch files located in a directory of your choice the commands BatchRoot and BatchRun resp. exe BatchPath and exe are available.
By this command the directory name, in which SICS is searching for a batch file, is stored in the SICS variable BatchRoot. Calling BatchRoot without parameters will return the actual contents of the variable.
This command tries to open the file filename located in the directory defined by BatchRoot and executes the script in this file.
By this command the directory name, in which SICS is searching for a batch file, is stored in the SICS variable exe BatchPath. Calling exe BatchPath without parameters will return the actual contents of the variable.
This command tries to open the file filename located in the directory defined by exe BatchPath and executes the script in this file. Compared to BatchRun, this command allows enhanced batch control through the SICSBatchEditor.
This command writes everything after ClientPut to the client which started the script.
Some users wish to have all communication of the SICS server with all the clients having user or manager privileges being collected in a file for further review. This is implemented via the commandlog command. This log allows to retrace each step of an experiment. It is usually switched off and must be configured by the instrument manager. commandlog understands the following syntax:
starts a new commandlog writing to <filename>. The log file can be found for the SANS server in the directory /home/SANS/log.
without further parameters displays the status of the commandlog.
closes the command log file.
SICS supports a couple of variables for documentation of a measurement. Currently available are:
user, adress, phone, fax, email, title, subtitle, environment, sample, comment
Each variable can be inquired by just typing its name. It can be set by typing the name followed by the new name, e.g. title nanocrystalline Fe. These variables can also be set by the [Set Experiment] dialog box, which can be started via the [New Parameter] option of the [User Parameter] menu item in the command line client. The user is required to fill this variables with utmost care, because if you want us to retrieve your data in ten years time you will be happy that the information will be there.
Many objects in SICS are drivable. This means they can run to a new value. Obvious examples are motors. Less obvious examples include composite adjustments such as setting a wavelength or a temperature. This class of ob jects can be operated by the drive, run , success family of commands. These commands cater for blocking and non-blocking modes of operation.
Can be called with one to n pairs of object new value pairs. This command will set the variables in motion and return to the command prompt without waiting for the requested operations to finish. This feature allows to do things to the instrument while for example a slow device is running into position.
Waits and blocks the command connection until all pending operations have finished (or an 'interrupt' occured).
can be called with one to n pairs of ob ject new value pairs. This command will set the variables in motion and wait until the driving has finished. A drive can be seen as a sequence of a run command as stated above immediatetly followed by a Success command.
In SICS each motor is an object with a name. Motors may take commands which basically come in the form <motorname> <command>. Most of these commands deal with the plethora of parameters which are associated with each motor. The syntax for manipulating variables is, again, simple. <motorname> <parametername> will print the current value of the variable. <motorname> <parametername> <newval> will set the parameter to the new value specified. A list of all parameters and their meanings is given below. The general principle behind this is that the actual (hardware) motor is kept as stupid as possible and all the intracacies of motor control are dealt with in software. Besides the parameter commands any motor understands these basic commands:
gives a listing of all motor parameters
resets the motor parameters to default values.
prints the current position of the motor.
initiates automatic printing of any position change of the motor. This command is mainly interesting for implementors of status display clients.
The motor parameters:
is the hardware lower limit. This is read from the motor controller and is identical to the limit switch welded to the instrument. Can usually not be changed.
is the hardware upper limit. This is read from the motor controller and is identical to the limit switch welded to the instrument. Can usually not be changed.
is the software lower limit. This can be defined by the user in order to restrict instrument movement in special cases.
is the software upper limit. This can be defined by the user in order to restrict instrument movement in special cases.
defines a software zero point for the motor. All further movements will be in respect to this zeropoint.
can be greater 0 for the motor being fixed and less than zero for the motor being movable.
defines the interrupt to issue when the motor fails. Some motors are so critical for the operation of the instrument that all operations shall be stopped when there is a problem. Others are less critical. This criticallity is expressed in terms of interrupts, denoted by integers in the range 0 - 4 translating into the interrupts: continue, AbortOperation, AbortScan, AbortBatch and Halt. This parameter can usually only be set by managers.
denotes the precision to expect from the motor in positioning. Can usually only be set by managers.
specifies the level of user privilege necessary to operate the motor. Some motors are for adjustment only and can be harmful to move once the adjustment has been done. Others must be moved for the experiment. Values are 0 - 3 for internal, manager , user, and spy. This parameter can only be changed by managers.
defunct.
allows to reverse the operating sense of the motor. For cases where electricians and not physicists have defined the operating sense of the motor. Usually a parameter not to be changed by ordinary users.
This section describes some commands special to SANS. One feature of SANS is that components are used as a whole rather than refering to single motors. For SANS the beamstop, the detector and the sample table is managed like this. Within a component each axis can be adressed specifically by using an axis = value pair. Axis defined for each component will be listed below. Additionally these components support common commands as well. These mainly deal with named positions. A named position is a set of values which can be driven to by just specifying its name. For instance: bs PositionA drives the BeamStop bs to the position defined as PositionA. All component drive commands do not block, i.e. you can type further commands. If it is needed to wait for a component to arrive, use the Success command right after your command.
Commands supported by all components (in the following, the name of the component will be represented by <COP>):
The name of the component alone will yield a listing of the current position of the component. This is also a way how to find out which axis the component supports.
drives the component back to the position before the last command. Please note, that back does not operate on itself, i.e. two times <COP> back will not do a trick.
This command promotes the current position of the component to a named position <name>. Afterwards this position can be reached by typing: <COP> <name> .
deletes the named position specified as second parameter.
returns the name <name> of the actual position of the component if the position was named before by <COP> pos <name>.
drives the component to the new position specified by 1-n sets of <axis n> = <val n> pairs. The equal sign is not mandatory and can be left out. The axis refers to the internal axis of the component which is seen in a listing as created by typing <COP>. A relative movement of an axis can be performed if an ++ or -- precedes the value for <val n>. A value ++10, for example would mean an increase of the actual axis position by 10.
SICS can support any type of sample environment control device if there is a driver for it. This includes temperature controllers, magnetic field controllers etc. The SICS server is meant to be left running continuously. Therefore there exists a facility for dynamically configuring and deconfiguring environment devices into the system. This is done via the EVFactory command. It is expected that instrument scientists will provide command procedures for configuring environment devices and setting reasonable default parameters.
In the SICS model a sample environment device has in principle two modes of operation. The first is the drive modus. The device is monitored in this modus when a new value for it has been requested. The second modus is the monitor modus. This modus is entered when the device has reached its target value. After that, the device must be continously monitored throughout any measurement. This is done through the environment monitor or emon. The emon command understands a few commands of its own.
Within SICS all sample environment devices share some common behaviour concerning parameters and abilities. Thus any given environment device accepts all of a set of general commands plus some additional commands special to the device.
In the next paragraphs the EVFactory, emon and the general commands understood by any sample environment device will be discussed. Reading this is mandatory for understanding SICS environment device handling. Then there will be another section later on in this manual discussing the special devices known to the system.
A sample environment device may fail to stay at its preset value during a measurement. This condition will usually be detected by the emon. The question is how to deal with this problem. The requirements for this kind of error handling are quite differentiated. The SICS model therefore implements several strategies for handling sample environment device failure handling. The strategy to use is selected via a variable which can be set by the user for any sample environment device separatetly. Additional error handling strategies can be added with a modest amount of programming. The error handling strategies currently implemented are:
Just print a warning and continue.
Pauses the measurement until the problem has been resolved.
Issues a SICS interrupt to the system.
Tries to run the environment device to a value considered safe by the user.
EVFactory command:
EVFactory is responsible for configuring and deconfiguring sample environment devices into SICS. The syntax is simple:
Creates a new sample environment device. It will be known to SICS by the name specified as second parameter <name>. The <type> parameter decides which driver to use for this device. The type will be followed by additional parameters which will be evaluated by the driver requested.
Deletes the environment device <name> from the system.
emon command:
The environment monitor emon takes for the monitoring of an environment device during measurements. It also initiates error handling when appropriate. The emon understands a couple of commands.
This command lists all environment devices currently registered in the system.
This is a specialist command which registers the environment device <name> with the environment monitor. Usually this will automatically be taken care of by EVFactory.
This is a specialist command which unregisters the environment device <name> with the environment monitor. Following this call the device will no longer be monitored and out of tolerance errors on that device no longer be handled.
Please note that each command discussed below MUST be prepended with the <name> of the environment device as configured in EVFactory! The general commands understood by any environment controller can be subdivided further into parameter commands and real commands. The parameter commands just print the name of the parameter if given without an extra parameter or set if a parameter is specified. For example:
| Temperature Tolerance prints the value of the variable Tolerance for the environment controller Temperature. |
| Temperature Tolerance 2.0 sets the parameter Tolerance for Temperature to 2.0. |
Parameters known to ANY envrironment controller are:
Is the deviation from the preset value which can be tolerated before an error is issued.
Determines who may change parameters for this controller. Possible values are:
| 0 only internal |
| 1 only Managers |
| 2 Managers and Users |
| 3 Everybody, including Spy |
The lower limit for the controller.
The upper limit for the controller.
The error handler to use for this controller. Possible values:
| 0 is Lazy |
| 1 for Pause |
| 2 for Interrupt |
| 3 for Safe |
| For an explanantion of these values see the section about error handling above. |
The interrupt to issue when an error is detected and interrupt error handling is set. Valid values are:
| 0 for continue |
| 1 for abort operation |
| 2 for for abort scan |
| 3 for abort batch processing |
| 4 halt system |
| 5 exit server |
| For an explanantion of these values see the section about error handling above. |
The value to drive the controller to when an error has been detected and safe error handling is set.
Additionally the following commands are understood:
Sends everything after send directly to the controller and return its response. This is a general purpose command which allows to manipulate controllers and controller parameters directly. The protocoll for these commands is documented in the documentation for each controller. Ordinary users should not tamper with this. This facility is meant for setting up the device with calibration tables etc.
lists all the parameters for this controller.
When only the name of the device is typed it will return its current value.
will drive the device to the new value <val>. Please note that the same can be achieved by using the drive command.
Switches logging on. If logging is on, at each cycle in the <emon> the current value of the environment variable will be recorded together with a time stamp. Be careful about this, for each log point a bit of memory is allocated. At some time the memory is exhausted! <name> log clear frees it again and log frequency (both below) allows to set the logging time intervall.
Switches logging off.
Clears all recorded time stamps and values.
This command retrieves a list of all recorded time stamps.
This command retrieves all recorded values.
Calculates the mean value and the standard deviation for all logged values and prints it.
With a parameter <val> sets, without a parameter requests the logging intervall for the log created. This parameter specifies the time intervall in seconds between log records. The default is 5 minutes. A value of 0 means a record for each cycle of the SICServer.
| [1] | http://cseng.awl.com/authordetail.qry?AuthorID=69 |
| [2] | http://www.tcltk.com |
| <<< Previous | Home | Next >>> |
| Instrument preparation before the first measurement | TCL command language interface |