diff --git a/doc/user/dmcman b/doc/user/dmcman index d03aae76..c2f3cfb9 100644 --- a/doc/user/dmcman +++ b/doc/user/dmcman @@ -16,9 +16,9 @@ %html -s report \begin{center} \begin{huge} -DMC--User Manual \\ +DMC and HRPT Reference Manual \\ \end{huge} -Version \date\\ +Version \today\\ Dr. Mark K\"onnecke \\ Labor f\"ur Neutronenstreuung\\ Paul Scherrer Institut\\ @@ -26,6 +26,25 @@ CH--5232 Villigen--PSI\\ Switzerland\\ \end{center} \clearpage + +\leftline{\large{Introduction}} +Both DMC and HRPT are neutron powder diffractometers with a similar +way of operation. Both instruments illuminate the sample with a +monochromated neutron beam. The neutron beam gets diffracted at the +sample and the difracted neutrons are collected in large +banana shaped position sensitive detectors positioned around the +sample. DMC has a counter array with 400 detectors, HRPT one with 1600 +detectors. The operation is simple: After adjustment of the wavelength +and the two--theta position of the detector the diffracted intensity +is collected for hours. HRPT can be installed at one out of two +two--theta positions in relation to the monochromator. HRPT's +monochromator may be exchanged through a monochrmoator lift +assembly. Consequently HRPT has only a fixed set of wavelength +available. DMC can be moved around the monochromator freely within the +geometrical limits of the beamline. Thus DMC's wavelength may be +adjusted to any value within its wavelength range. + + %html sicsinvoc.htm 1 %html general.htm 1 %html basic.htm 1 @@ -44,7 +63,8 @@ Switzerland\\ %html counter.htm 2 %html samenv.htm 1 %html dmcdev.htm 1 +%html hrptdev.htm 1 %html trouble.htm 1 %html dmco.htm 1 -\end{document} \ No newline at end of file +\end{document} diff --git a/doc/user/dmcman.tex b/doc/user/dmcman.tex deleted file mode 100644 index ae6a9790..00000000 --- a/doc/user/dmcman.tex +++ /dev/null @@ -1,1628 +0,0 @@ -\documentclass[12pt,a4paper]{report} -%%\usepackage[dvips]{graphics} -%%\usepackage{epsf} -\setlength{\textheight}{24cm} -\setlength{\textwidth}{16cm} -\setlength{\headheight}{0cm} -\setlength{\headsep}{0cm} -\setlength{\topmargin}{0cm} -\setlength{\oddsidemargin}{0cm} -\setlength{\evensidemargin}{0cm} -\setlength{\hoffset}{0cm} -\setlength{\marginparwidth}{0cm} - -\begin{document} -\begin{center} -\begin{huge} -DMC--User Manual \\ -\end{huge} -Version 0.1, 8.7.1997\\ -Dr. Mark K\"onnecke \\ -Labor f\"ur Neutronenstreuung\\ -Paul Scherrer Institut\\ -CH--5232 Villigen--PSI\\ -Switzerland\\ -\end{center} -\clearpage -% html: Beginning of file: `sicsinvoc.htm' - -\chapter{SICS Invocation} - -\label{f0} - -SICS is a client server system. This means there are at least two programs -necessary to run the experiment. The first -is the -SICServer which does the actual instrument control work. A user rarely needs -to bother about this server program as it is meant to run all the time. -See instructions below if things go wrong. - -Then there are one to many client programs which interact with the -instrument control server. These client programs implement the status -displays and a command line application which allows to influence the -course of the experiment. Graphical User Interfaces may be added at a -later time. -The user has only to deal with -these SICS client programs. SICS Clients and the SICServer communicate -with each other through TCP/IP sockets. - -Currently five SICS clients are available: -\begin{itemize} -\item A command line control client which allows to control the measurement. -\item A status display for DMC. -\item A status display for TOPSI. -\item A status display for SANS. -\item A status display for FOCUS. -\item A SICS variable watcher. -\end{itemize} - - -\section{Steps necessary for logging in to SICS} - - -The following actions have to be taken in order to interact with the -SICS server through a client: -\begin{itemize} -\item Start the client application. -\item Connect the client to a SICS server. -\item In case of command line clients: authorize yourself as -privileged SICS user. -\end{itemize} - -\section{Starting SICS client applications } - - - -These programs can be started on a DigitalUnix system by issuing the -following commands at the command prompt: -\begin{description} -\item[sics \&] for the control client. -\item[powderstatus \&] for the DMC status display client. -\item[topsistatus \&] for the TOPSI status display. -\item[sansstatus \&] for the SANS status display. -\item[focustatus] for the FOCUS status display. -\item[varwatch \&] for the variable watcher. -\end{description} -On a PC you may find icons for starting the different programs on the -desktop. -Each of these clients has usage instructions online which can be displayed -through the help/about menu entry. - -\section{Connecting} - - - -After startup any SICS client is not connected to a SICS server and thus not -active. A connection is established through the connect menu of the client. - -\section{Authorization} - - - -SICS is a multi user instrument control system. In order to prevent -malicious manipulations of the instrument SICS supports a hierarchy of user -rights. In order to run an experiment you need at least user level privilege. -In order to achieve this privilege you have to invoke the User Parameter/Set -Rights dialog. There you have to enter the apropriate username and password -kindly provided by your instrument scientist. - -\section{Restarting the Server} - - - -The SICS server should be running all the time. It is only down if something -went wrong. You can check for the presence of the SICS server by loging in -to the instrument computer and typing {\bf CheckSICS} at the command -prompt. The output will tell you what is happening. If you need to restart -the SICS server log in as the instrument user at the instrument computer and -invoke the apropriate command to start the server. These are: -\begin{description} -\item[DMC] Computer = lnsa05,User = DMC -\item[TOPSI] Computer = lnsa03,User = TOPSI -\item[SANS] Computer = lnsa07,User = SANS -\item[TRICS] Computer = lnsa12, User = TRICS -\item[HRPT] Computer = lnsa11, User = HRPT -\item[FOCUS] Computer = lnsa13, User = FOCUS -\end{description} -For starting the SICS server type {\bf startsics}. This is a shell script -which will starts all necessary server programs. This script works only on -the instrument computer and in the appropriate instrument account. - - If all this does not help look under trouble shooting -SICS (cf.\ Section~\ref{f1}). -% html: End of file: `sicsinvoc.htm' -% html: Beginning of file: `general.htm' - -\chapter{General SICS commands} - -\label{f2} - - - This section describes general SICS concepts and SICS commands available to all instruments. - -\section{Chapter Overview} - - - -\begin{itemize}\item This chapter starts with an overview over some basic (cf.\ Section~\ref{f3}) SICS concepts. -\item Than there are system (cf.\ Section~\ref{f4}) commands for closing the server, requesting status information etc. -\item The Token command (cf.\ Section~\ref{f5}) for managing control access to -the SICS server. -\item A few commands permit to change (cf.\ Section~\ref{f6}) user rights, set output files and the like. -\item SICS has a built in macro (cf.\ Section~\ref{f7}) facility which is accessible through a few commands. -\item Than there is the famous (cf.\ Section~\ref{f8}) LNS-R\"unbuffer system. -\item Motors and parameters need to be drive (cf.\ Section~\ref{f9})n. -\item Logging of client output to a file can be performed with the LogBook (cf.\ Section~\ref{f10}) command and the commandlog (cf.\ Section~\ref{f11}). -\item SICS has a facility to optimise (cf.\ Section~\ref{f12}) a peak with respect to several -parameters. -\end{itemize} - -% html: End of file: `general.htm' -% html: Beginning of file: `basic.htm' - -\section{Basic SICS concepts} - -\label{f3} - - -\subsection{General structure} - - - - SICS is a client server system. The application the user sees is usually some form of client. A client has two tasks: the first is to collect user input and send it to the SICS server who will execute the command. The clients second task is to listen to the the server messages and display them in a readable format. This aoproach has two advantages: clients can reside on machines across the whole network thus enabling remote control from everywhere in the world. The second advantage is that new clients (such as graphical user interface clients) can be written in any feasible language without changes to the server. - -\subsection{SICS Command Syntax } - - - - SICS is an object oriented system. This is reflected in the command syntax. SICS objects can be devices such as motors or counters, variables such as wavelength or Title and measurement procedures. Communication with these objects happens by sending messages to the target object. This is very simply done by typing something like: object message par1 par2 .. parn. For example, if we have a motor called A1:\begin{verbatim} - A1 list -\end{verbatim} - will print a parameter listing for the motor A1. In this example no parameters were needed. There exist a number of one-word commands as well. For -compatability reasons some commands have a form which resembles a function call such as:\begin{verbatim} - drive a1 26.54 -\end{verbatim} - This will drive motor a1 to 26.54. All commands are -ASCII-strings and usually in english. SICS is in general CASE INSENSITIVE. -However, this does not hold for parameters you have to specify. On a unix -system for instance file names are case sensitive and that had to be -preserved. Commands defined in the scripting language are lower case by -convention. - -\subsection{Authorisation} - - - - A client server system is potentially open to unauthorised hackers which might mess up the instrument and your valuable measurements. A known problem in instrument control is that less knowledgeable user accidentally change instrument adjustments which should better be left fixed. In order to solve these two problems SICS supports authorisation on a very fine level. As a user you have to specify a username and password in order to able to access SICS. Some clients already do this for you automatically. SICS support four levels of access to an instrument: -\begin{itemize} -\item {\bf Spy } may look at everything, request any value, but may not actually change anything. No damage potential here. -\item {\bf User } is privileged to perform a certain amount of operations necessary to run the instrument. -\item {\bf Manager } has the permission to mess with almost everything. A very dangerous person. -\item {\bf Internal } is not accessible to the outside world and is used to circumvent protection for internal uses. However some parameters are considered to be so critical that they cannot be changed during the runtime of the SICS-server, not even by Managers. -\end{itemize} - All this is stated here in order to explain the common error message: You are not authorised to do that and that or something along these lines. - -\subsection{SICS variables} - - - - Most of the parameters SICS uses are hidden in the objects to which they belong. But some are separate objects of their own right and are accessible at top level. For instance things like Title or wavelength. They share a common syntax for changing and requesting their values. This is very simple: The command {\em objectname } will return the value, the command {\em objectname newvalue } will change the variable. But only if the authorisation codes match. - - -\subsection{The SICS Command Line Client} - - -The most common client for controlling SICS is the {\bf SICS command line -client}. -This application can be started by typing the command: -\begin{verbatim} -sics & -\end{verbatim} -at the Unix prompt. Before this program is ready to collaborate with you you -have to connect it to an instrument using the options in the connect -pulldown menu. The screen is roughly divided in three areas: The top area -shows all input to and output from the server. The middle area shows the -command history. At the lower end is a text entry field which allows to type -commands to the SICS server. For more information about this client consult -the online help of this application. -% html: End of file: `basic.htm' -% html: Beginning of file: `system.htm' - -\section{System Commands} - -\label{f4} - -{\bf Sics\_Exitus }. A single word commands which shuts the server down. Only Managers may use this command. - - {\bf wait time } waits time seconds before the next command is executed. This does not stop other clients from issuing commands. - - {\bf ResetServer } resets the server after an interrupt. - - {\bf Dir } a single word command which lists all objects available in the SICS system in its current configuration. - - {\bf status } A single word command which makes SICS print its current -status. Possible return values can be: -Eager to execute commands, Scanning, Counting, Running, Halted. Note that if a command is executing which takes some time to complete - the server will return an ERROR: Busy message when further commands are issued. - -{\bf status interest} initiates automatic printing of any status change in the -server. This command is primarily of interest for status display client -implementors. - -{\bf backup file} saves the current values of SICS variables and selected - motor and device parameters to the disk file specified as parameter. The - path to this files is relative to the SICS server directory. The format - of the file is a list of SICS commands to set all these parameters again. - -{\bf restore file} reads a file produced by the backup command described -above and restores SICS to the state it was in when the status was saved with - backup. -% html: End of file: `system.htm' -% html: Beginning of file: `config.htm' - -\section{Configuration Commands} - -\label{f6} - - SICS allows to change the user rights of the current client server connection, control the amount of output a client receives and to specify additional logfiles where output will be placed. All this is accessed through the following commands: - - The SICS server logs all its activities to a logfile, regardless of what the user requested. This logfile is mainly intended to help in server debugging. However, clients may register an interest in certain server events and can have them displayed. This facility is accessed via the {\bf GetLog } command. It needs to be stressed that this log receives messages from {\bf all } active clients. GetLog understands the following messages: -\begin{itemize} -\item {\bf GetLog All } achieves that all output to the server logfile is also written to the client which issued this command. -\item {\bf GetLog Kill } stops all logging output to the client. -\item {\bf GetLog OutCode } request that only certain events will be logged to the client issuing this command. Enables only the level specified. Multiple calls are possible. -\end{itemize} - Possible values for OutCode in the last option are: -\begin{itemize} -\item {\bf Internal } internal errors such as memory errors etc. -\item {\bf Command } all commands issued from any client to the server. -\item {\bf HWError } all errors generated by instrument hardware. The SICS server tries hard to fix HW errors in order to achieve stable operations and may not generate an error message if it was able to fix the problem. This option may be very helpful when tracking dodgy devices. -\item {\bf InError } All input errors found on any clients input. -\item {\bf Error } All error messages generated by all clients. -\item {\bf Status } some commands send status messages to the client invoking the command in order to monitor the state of a scan. -\item {\bf Value } Some commands return requested values to a user. These messages have an output code of Value. -\end{itemize} - -{\bf config } allows to configure various aspects of the current client server connection. Basically three things can be manipulated: The connections output class, the user rights associated with it, and output files. - -\begin{itemize} \item The command {\bf config OutCode val } sets the output code for the connection. By default all output is sent to the client. But a graphical user interface client might want to restrict message to only those delivering requested values and error messages and suppressing anything else. In order to achieve this, this command is provided. Possible values Values for val are Internal,Command, HWError,InError,Status, Error, Value. This list is hierarchical. For example specifying InError for val lets the client receive all messages tagged InError, Status, Error and Value, but not HWError, Command and Internal messages. -\item Each connection between a client and the SICS server has user rights assocociated with it. These user rights can be configured at runtime with the command {\bf config Rights Username Password }. If a matching entry can be found in the servers password database new rights will be set. -\item Scientists are not content with having output on the screen. In order to -check results a log of all output may be required. The command {\bf config -File name } makes all output to the client to be written to the file -specified by name as well. The file must be a file accessible to the server, -i.e. reside on the same machine as the server. Up to 10 logfiles can be -specified. Note, that a directly connected line printer is only a special -filename in unix. -\item {\bf config close num} closes the log file denoted by num again. -\item {\bf config list} lists the currently active values for outcode and user -rights. -\end{itemize} - - -% html: End of file: `config.htm' -% html: Beginning of file: `macro.htm' - -\section{Macro Commands} - -\label{f7} - - 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 Tool Command Language (TCL). Tcl has control constructs, variables of its own, loop constructs, associative arrays and procedures. Tcl is well documented by several books and online tutorials, therefore no details on Tcl will be given here. All SICS commands are available in the macro language. Some potentially harmful Tcl commands have been deleted from the standard Tcl interpreter. These are: exec, source, puts, vwait, exit,gets and socket. The following commands allow access to the macro facility: - - {\bf FileEval name } tries to open the file name and executes the script in this file. Please note that the server is configured via such a file. - - {\bf ClientPut sometext1 ... } writes everything after ClientPut to the client which started the script. Useful for output to a client from macro scripts. - -{\bf SICSType object } allows to query the type of the object specified by object. Possible return values are -\begin{itemize} -\item {\bf DRIV } if the object is a SICS drivable object such as a motor -\item {\bf COUNT } if the object is some form of a counter. -\item {\bf COM } if the object is a SICS command. -\item {\bf NUM } if the object is a number. -\item {\bf TEXT } if object is something meaningless to SICS. -\end{itemize} - - {\bf SICSbounds var newval } checks if the new value newval lies within the limits for varaible var. Returns an error or OK depending on the result of the test. - - {\bf SICSStatus var } SICS devices such as counters or motor may be started and left running while the program is free to do something else. This command allows to enquire the status of such a running device. Return values are internal SICS integer codes. This command is only of use for SICS programmers. - -{\bf SetStatus newval } allows to set the SICS status to one of: Eager, UserWait, Count, NoBeam, Driving, Running, Scanning, Batch Hatl or Dead. This command is only available in macros. - - {\bf SetInt newval, GetInt } allow for the manipulation of interrupts from macro scripts. Not recommended! Possible return values or new values are: continue, abortop, abortscan, abortbatch, halt, free, end. This command is only permitted in macros. Should only be used by SICS programmers. -% html: End of file: `macro.htm' -% html: Beginning of file: `buffer.htm' - -\section{R\"unbuffer Commands} - -\label{f8} - - LNS scientists have got used to using R\"unbuffers for instrument control. A R\"unbuffer is an array of SICS commands which typically represent a measurement. This R\"unbuffer can be edited at run time. This is very similar to a macro. In contrast to a macro only SICS commands are allowed in R\"unbuffers. When done with editing the R\"unbuffer it can be entered in a R\"unlist. This is a stack of R\"unbuffers which get executed one by one. While this is happening it is possible (from another client) to modify the R\"unlist and edit and add additional R\"unbuffer on top of the stack. This allows for almost infinite measurement and gives more control than a static batch file. In order to cater for this scheme three commands have been defined: - - The {\bf Buf } object is responsible for creating and deleting R\"unbuffers. The syntax is: -\begin{itemize} -\item {\bf Buf new name } creates a new empty R\"unbuffer with the name name. name will be installed as a SICS object afterwards. -\item {\bf Buf copy name1 name2 } copies R\"unbuffer name1 to buffer name2. -\item {\bf Buf del name } deletes the R\"unbuffer name. -\end{itemize} - - After creation, the R\"unbuffer is accessible by his name. It than understands the commands: -\begin{itemize} -\item {\bf NAME append what shall we do with a drunken sailor } will add all text after append as a new line at the end of the R\"unbuffer. -\item {\bf NAME print } will list the contents of the R\"unbuffer. -\item {\bf NAME del iLine } will delete line number iLine from the R\"unbuffer. -\item {\bf NAME ins iLine BimBamBim } inserts a new line {\bf after } line iLine into the R\"unbuffer. The line will consist of everything given after the iLine. -\item {\bf NAME subst pattern newval } replaces all occurences of pattern in the R\"unbuffer by the text specified as newval. Currently this feature allows only exact match but may be expanded to Unix style regexp or shell like globbing. -\item {\bf NAME save filename } saves the contents of the R\"unbuffer into file filename. -\item {\bf NAME load filename } loads the R\"unbuffer with the data in file filename. -\item {\bf NAME run } executes the R\"unbuffer. -\end{itemize} - - The R\"unlist is accessible as object {\bf stack }. Only one R\"unlist per server is permitted. The syntax: -\begin{itemize} -\item {\bf stack add name } adds R\"unbuffer name to the top of the stack. -\item {\bf stack list } lists the current R\"unlist. -\item {\bf stack del iLine } deletes the R\"unbuffer iLine from the R\"unlist. -\item {\bf stack ins iLine name } inserts R\"unbuffer name after R\"unbuffer number iLine into the R\"unlist. -\item {\bf stack run } executes the R\"unlist and returns when all R\"unbuffers are done. -\item {\bf stack batch } executes the R\"unlist but does not return when done but waits for further R\"unbuffers to be added to the list. This feature allows a sort of background process in the server. -\end{itemize} - -% html: End of file: `buffer.htm' -% html: Beginning of file: `drive.htm' - -\section{Drive commands} - -\label{f9} - - Many objects in SICS are {\bf 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 an energy. This class of objects can be operated by the {\bf drive, run, Success } family of commands. These commands cater for blocking and non-blocking modes of operation. - - {\bf run var newval var newval ... } 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 perhaps a slow device is running into position. - - {\bf Success } waits and blocks the command connection until all pending operations have finished (or an interrupt occured). - - {\bf drive var newval var newval ... } can be called with one to n pairs of object 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. -% html: End of file: `drive.htm' -% html: Beginning of file: `logbook.htm' - -\section{LogBook command} - -\label{f10} - -Some users wish like to have all the input typed to SICS and all responses -collected in a file for further review. This is implemented via the LogBook -command. LogBook understands the following syntax: -\begin{description} -\item[ LogBook] alone prints the name of the current logfile and the status of event -logging. -\item[ LogBook file filename] This command sets the filename to which output will be printed. -Please note that this new filename will only be in effect after restarting -logging. -\item[ LogBook on] This command turns loggin on. All commands and all answers will be -written to the file defined with the command described above. Please note, -that this command will overwrite an existing file with the same name. -\item[ LogBook off] This command closes the logfile and ends logging. -\end{description} - -% html: End of file: `logbook.htm' -% html: Beginning of file: `commandlog.htm' - -\section{The Commandlog} - -\label{f11} - -The commandlog is a file where all communication with clients -having user or manager privilege is logged. This log allows to retrace each -step of an experiment. This log is usually switched off and must be -configured by the instrument manager. There exists a special command, -commandlog, which allows to control this log file. -\begin{description} -\item[commandlog new filename] starts a new commandlog writing to filename. Any prior files will be -closed. The log file can be found -in the directory specified by the ServerOption LogFileDir. Usually this is -the log directory. -\item[commandlog] displays the status of the commandlog. -\item[commandlog close] closes the commandlog file. -\item[commandlog auto] Switches automatic log file creation on. This is normally switched on. -Log files are written to the log directory of the instrument account. There - are time stamps any hour in that file and there is a new file any 24 hours. -\end{description} - -% html: End of file: `commandlog.htm' -% html: Beginning of file: `optimise.htm' - -\chapter{The Peak Optimiser} - -\label{f12} - -In instrument control the need arises to optimise a peak with respect to -several variables. Optimising means finding the maximum of the peak with -respect to several variables. - This is usefull during instrument calibration. -Four circle diffractometers use this facility on a day to day basis -for finding and verifying the exact position of reflections. In order to -support both usages a more general module has been implemented. The way of -operation is like this: -\begin{verbatim} -while errors gt precision and cycles lt maxcycles - for all variables - do a scan - Try find the maximum, two halfwidth points and the peak center. - if failure extend the scan. - if success shift the variable, remember last shift. - If shift lt precicison mark this variable as done - end for -end while -\end{verbatim} -Possible outcomes of this procedure are: success, the peak was lost or the -maximum number of cycles was reached. This routine requires that the -instrument is currently placed somewhere on the peak and not miles away. - -The Peak Optimiser is implemented as an object with the name opti. It -understand the following commands: -\begin{description} -\item[opti clear] clears the optimiser. -\item[opti addvar name step nStep precision] This command adds a variable to optimise to the optimiser. The user has -to specify the name of the variable, the step width to use for scanning, the -number of steps needed to cover the full peak when scanning and the -precision which should be achieved when optimising the peak. The step width -and number of steps parameters should cover the whole peak. However, the -Optimiser will extend the scan is the specified range is not sufficient. -\item[opti run] Starts the optimiser. It will then optimise the peak. This may take some -time. -\end{description} - The behaviour of the optimiser can be configured by modifying some -parameters. The synatx is easy: {\bf opti parameter} prints the value of the -parameter, {\bf opti parameter newval} sets a new value for the parameter. -The following parameters are supported: -\begin{description} -\item[maxcycles] The maximum number of cycles the optimiser will run when trying to -optimise a peak. The default is 7. -\item[threshold] When a peak cannot be identified after a scan on a variable, the -optimiser will check if there is a peak at all. In order to do that it -searches for a count rate higher then the threshold parameter. If such a -rate cannot be found the optimiser will abort and complain that he lost the -peak. -\item[channel] The counter channel to use for scanning. The default is to use the -counter. By modifying this parameter, the optimiser can optimise on a -monitor instead. -\item[countmode] The counting mode to use when scanning. Possible values are {\bf timer} or -{\bf monitor}. -\item[preset] The preset value to use for counting in the scan. Depending on the -status of the countmode parameter this is either a preset time or a preset -monitor. -\end{description} - -% html: End of file: `optimise.htm' -% html: Beginning of file: `token.htm' - -\section{The Token Command} - -\label{f5} - -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 -looking at things. A token can be released manully 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: -\begin{description} -\item[token grab] Reserves control over the instrument to the client isssuing this -command. Any other client cannot control the instrument now. However, other -clients are still able to inspect variables. -\item[token release] Releases the control token. Now any other client can control the -instrument again. Or grab the control token. -\item[token force password] 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. -\end{description} - -% html: End of file: `token.htm' -% html: Beginning of file: `dmchw.htm' - -\chapter{DMC Hardware Devices} - -\label{f13} - - -DMC controls a couple of : -\begin{itemize} -\item motors (cf.\ Section~\ref{f14}). -\item a histogram memory (cf.\ Section~\ref{f15}). -\item a -counter box (cf.\ Section~\ref{f16}) for -reading monitors. -\item and various -environment.htm (cf.\ Section~\ref{f17}) control devices. -\end{itemize} -Each of these -devices understands commands. The syntax understood by each of these devices -will be discussed. - - -% html: End of file: `dmchw.htm' -% html: Beginning of file: `motor.htm' - -\section{SICS motor handling} - -\label{f14} - - - In SICS each motor is an object with a name. Motors may take commands which basically come in the form {\em 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. {\em Motorname parametername } will print the current value of the variable. {\em 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: -\begin{itemize} -\item {\bf Motorname list } gives a listing of all motor parameters. -\item {\bf Motorname reset } resets the motor parameters to default values. - This is software zero to 0.0 and software limits are reset to hardware -limits. -\item {\bf Motorname position} prints the current position of the motor. -\item {\bf Motorname interest} initiates automatic printing of any position -change of the motor. This command is mainly interesting for implementors of -status display clients. -\end{itemize} - Please note that the actual driving of the motor is done via the drive (cf.\ Section~\ref{f9}) command. - - -\subsection{The motor parameters} - - -\begin{itemize} -\item {\bf HardLowerLim } 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. -\item {\bf HardUpperLim } 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. -\item {\bf SoftLowerLim } is the software lower limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftUpperLim } is the software upper limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftZero } defines a software zero point for the motor. All further movements will be in respect to this zeropoint. -\item {\bf Fixed } can be greater 0 for the motor being fixed and less -or equal than zero for the motor being movable. -\item {\bf InterruptMode } 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. Other 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. -\item {\bf Precision } denotes the precision to expect from the motor in positioning. Can usually only be set by managers. -\item {\bf AccessCode } 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. -\item {\bf Speed }, defunct. -\item {\bf Sign } 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. -\end{itemize} - - -% html: End of file: `motor.htm' -% html: Beginning of file: `histogram.htm' - -\section{Histogram memory} - -\label{f15} - - -Histogram memories are used in order to control large area sensitive -detectors or single detectors with time binning information. -Basically each detector maps to a defined memory location. The -histogram memory wizard takes care of putting counts detected in the -detector into the proper bin in memory. Some instruments resolve energy -(neutron flight time) as -well, than there is for each detector a row of memory locations mapping to -the time bins. As usual in SICS the syntax is the name of the histogram -memory followed by qualifiers and parameters. As a placeholder for the -histogram memories name in your system, HM will be used in the following -text. - -A word or two has to be lost about the SICS handling of preset values for -histogram memories. - Two modes of operation have to be distinguished: counting until a timer has passed, -for example: count for 20 seconds. This mode is called timer mode. In the other -mode, counting is continued until a control monitor has reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - -\subsection{ Configuration} - - - -A HM has a plethora of configuration options coming with it which define -memory layout, modes of operation, handling of bin overflow and the like. -Additionally there are HM model specific parameters which are needed -internally in -order to communicate with the HM. In -most cases the HM will already have been configured at SICS server startup -time. However, there are occasion where these configuartion option need to -enquired or modified at run time. The command to enquire the current value -of a configuration option is: {\bf HM configure option}, the command to set it is: -{\bf HM configure option newvalue}. A list of common configuration options and their -meaning is given below: -\begin{description} -\item[ HistMode] HistMode describes the modes of operation of the histogram memory. -Possible values are: -\begin{itemize} -\item Transparent, Counter data will be written as is to memory. For debugging -purposes only. -\item Normal, neutrons detected at a given detector will be added to the - apropriate memory bin. -\item TOF, time of flight mode, neutrons found in a given detector will be -put added to a memory location determined by the detector and the time -stamp. -\item Stroboscopic mode. This mode serves to analyse changes in a sample due -to an varying external force, such as a magnetic field, mechanical stress -or the like. Neutrons will be stored in memory according to detector -position and phase of the external force. -\end{itemize} -\item[ OverFlowMode] This parameter determines how bin overflow is handled. This happend -when more neutrons get detected for a particular memory location then are -allowed for the number type of the histogram memory bin. Possible values -are: -\begin{itemize} -\item Ignore. Overflow will be ignored, the memory location will wrap around -and start at 0 again. -\item Ceil. The memory location will be kept at the highest posssible value -for its number type. -\item Count. As Ceil, but a list of overflowed bins will be maintained. -\end{itemize} -\item[ Rank] Rank defines the number of histograms in memory. -\item[ Length ] gives the length of an individual histogram. -\item[ BinWidth] determines the size of a single bin in histogram memory in bytes. -\item[dim0, dim1, dim2, ... dimn] define the logical dimensions of the histogram. Must be set if the - the sum command (see below) is to be used. This is a clutch necessary to - cope with the different notions of dimensions in the SINQ histogram memory - and physics. -\end{description} -For time of flight mode the time binnings can be retrieved and modified with -the following commands. Note that these commands do not follow the configure -syntax given above. Please note, that the usage of the commands for -modifying time bins is restricted to instrument managers. -\begin{description} -\item[HM timebin] Prints the currently active time binning array. -\item[HM genbin start step n] Generates a new equally spaced time binning array. Number n time bins -will be generated starting from start with a stepwidth of step. -\item[HM setbin inum value] Sometimes unequally spaced time binnings are needed. These can be -configured with this command. The time bin iNum is set to the value value. -\item[HM clearbin] Deletes the currently active time binning information. -\end{description} - -\subsection{Histogram Memory Commands} - - - -Besides the configuration commands the HM understands the following -commands: -\begin{description} -\item[HM preset] with a new value sets the preset time or monitor for counting. Without a -value prints the current value. -\item[HM exponent] with a new value sets the exponent to use for the preset time -in Monitor mode. Without a -value prints the current value. -\item[CountMode ] with a new values sets the count mode. Possible values are Timer for a -fixed counting time and Monitor for a fixed monitor count which has to be -reached before counting finishes. Without a value print the currently active -value. -\item[HM init ] after giving configuration command sthis needs to be called in order to -transfer the configuration from the host computer to the actual HM. -\item[HM count] starts counting using the currently active values for CountMode and -preset. This command does not block, i.e. in order to inhibit further -commands from the console, you have to give Success afterwards. -\item[HM InitVal val] initialises the whole histogram memory to the value val. Ususally 0 in -order to clear the HM. -\item[ HM get i iStart iEnd] retrieves the histogram number i. A value of -1 for i denotes retrieval -of the whole HM. iStart and iEnd are optional amd -allow to retrieve a subset of a histogram between iStart and iEnd. -\item[HM sum d1min d1max d2min d2max .... dnmin dnmax] calculates the sum of an area on the detector. For each dimension a - minimum and maximum boundary for summing must be given. -\end{description} - -% html: End of file: `histogram.htm' -% html: Beginning of file: `counter.htm' - -\section{SICS counter handling} - -\label{f16} - - - This section deals with the SICS interface to single counters. -Where the SICS counter concept may include several monitors per -counter. A counter is, again, a named object which takes commands. -A word or two has to be lost about the SICS handling of preset values for counters. -Two modes of operation have to be distinguished: counting until a timer has passed, -for example: count for 20 seconds. This mode is called timer mode. In the other -mode, counting is continued until a control monitor has reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - The commands understood are: -\begin{itemize} -\item {\bf countername SetPreset val } sets the counting preset to val. -\item {\bf countername GetPreset } prints the current preset value. -\item {\bf countername SetExponent val } sets the exponent for the counting -preset in monitor mode to val. -\item {\bf countername GetExponent } prints the current exponent used -in monitor mode. -\item {\bf countername SetMode val } sets the counting mode to val. Possible values are Timer for timer mode operation and Monitor for waiting for a monitor to reach a certain value. -\item {\bf countername GetMode } prints the current mode. -\item {\bf countername GetCounts } prints the counts gathered in the last run. -\item {\bf countername GetMonitor n } prints the counts gathered in the monitor number n in the last run. -\item {\bf countername Count preset } starts counting in the current mode and the the preset preset. -\item {\bf countername status } prints a message containing the preset and -the current monitor or time value. Can be used to monitor the progress of -the counting operation. -\item {\bf countername gettime } Retrieves the actual time the counter -counted for. This excludes time where there was no beam or counting was -paused. -\item {\bf countername getthreshold m} retrieves the value of the threshold - set for the monitor number m. -\item {\bf countername setthreshold m val} sets the threshold for monitor m - to val. WARNING: this also makes monitor m the active monitor for evaluating - the threshold. Though the EL7373 counterbox does not allow to select the - monitor to use as control monitor in monitor mode, it allows to choose - the monitor used for pausing the count when the count rate is below the - threshold (Who on earth designed this?) -\end{itemize} - -% html: End of file: `counter.htm' -% html: Beginning of file: `samenv.htm' - -\chapter{ Sample Environment Devices} - -\label{f17} - - -\section{SICS Concepts for Sample Environment Devices} - -\label{f17:concept} - -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 continously. Therefore there -exists a facility for dynamically configuring and deconfiguring environment -devices into the system. This is done via the {\bf EVFactory} command. -It is expected that instrument scientists will provide command procedures or -specialised R\"unbuffers 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 {\bf emon}. The emon understands a few commands of its -own. - -Within SICS all sample environement 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 section the EVFactory, emon and the general commands understood -by any sample environment device will be discussed. This reading is mandatory -for understanding SICS environment device handling. Then there will be another -section discussing the special devices known to the system. - - -\section{SampleEnvironment Error Handling} - - -A \label{f17:error}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 differntiated. The SICS model therefore implements several -strategies for handling sample environment device failure handling. -The strategy to use is selected via 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: -\begin{description} -\item[Lazy] Just print a warning and continue. -\item[Pause] Pauses the measurement until the problem has been resolved. -\item[Interrupt] Issues a SICS interrupt to the system. -\item[Safe] Tries to run the environment device to a value considered safe by the -user. -\end{description} - -\section{General Sample Environment Commands} - -\label{f17:general} - -\subsection{EVFactory} - - - -EVFactory is responsible for configuring and deconfiguring sample environment -devices into SICS. The syntax is simple: -\begin{description} -\item[EVFactory new name type par par ...] Creates a new sample environment device. It will be known to SICS by the -name specified as second parameter. 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. -\item[EVFactory del name] Deletes the environment device name from the system. -\end{description} - -\subsection{emon} - - - -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. -\begin{description} -\item[emon list] This command lists all environment devices currently registered in the -system. -\item[emon register name] 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. -\item[emon unregister name] This is a specialist command which unregisters the environment device name -with the environment monitor. Usually this will automatically be taken care -of by EVFactory Following this call the device will no longer be monitored and -out of tolerance errors on that device no longer be handled. -\end{description} - -\subsection{General - Commands UnderStood by All Sample Environment Devices} - -\label{f17:all} - -Please note that each command discussed below MUST be prepended with the name -of the environment device as configured in EVFavtory! - -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: -\begin{quotation} -Temperature Tolerance\end{quotation} -prints the value of the variable Tolerance for the environment controller -Temperature. -\begin{quotation} -Temperature Tolerance 2.0\end{quotation} -sets the parameter Tolerance for Temperature to 2.0. Parameters known to ANY -envrironment controller are: -\begin{description} -\item[Tolerance] Is the deviation from the preset value which can be tolerated before an -error is issued. -\item[ Access] Determines who may change parameters for this controller. -Possible values are: -\begin{itemize} -\item 0 only internal -\item 1 only Managers -\item 2 Managers and Users. -\item 3 Everybody, including Spy. -\end{itemize} -\item[LowerLimit] The lower limit for the controller. -\item[UpperLimit] The upper limit for the controller. -\item[ErrHandler.] The error handler to use for this controller. Possible values: -\begin{itemize} -\item 0 is Lazy. -\item 1 for Pause. -\item 2 for Interrupt -\item 3 for Safe. -\end{itemize} - For an explanantion of these values see the section about error (cf.\ Section~\ref{f17:error}) handling -above. -\item[ Interrupt] The interrupt to issue when an error is detected and Interrupt error -handling is set. Valid values are: -\begin{itemize} -\item 0 for Continue. -\item 1 for abort operation. -\item 2 for abort scan. -\item 3 for abort batch processing. -\item 4 halt system. -\item 5 exit server. -\end{itemize} -\item[SafeValue] The value to drive the controller to when an error has been detected and -Safe error handling is set. -\end{description} - -Additionally the following commands are understood: -\begin{description} -\item[send par par ...] 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 -calibrartion tables etc. -\item[ list] lists all the parameters for this controller. -\item[ no command, only name.] When only the name of the device is typed it will return its -current value. -\item[ name val ] will drive the device to the new value val. Please note that the same -can be achieved by using the drive command. -\item[ name log on] 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! Log clear frees it again -and log frequency (both below) allows to set the logging time intervall. -\item[ name log off] Switches logging off. -\item[name log clear] Clears all recorded time stamps and values. -\item[name log gettime] This command retrieves a list of all recorded time stamps. -\item[name log getval] This command retrieves all recorded values. -\item[name log getmean] Calculates the mean value and the standard deviation for all logged -values and prints it. -\item[name log frequency val] With a parameter 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 any - cycle of the SICServer. - \end{description} - -\section{Special Environment Control Devices} - - - -This section lists the parameters needed for configuring a special environment -device into the system and special parameters and commands only understood by -that special device. All of the general commands listed above work as well! - -\subsection{ITC-4 and ITC-503 Temperature Controllers} - -\label{f17:itc4} - -These temperature controller are fairly popular at SINQ. It is manufactured by -Oxford Instruments. At the back side of this controller there is a RS-232 -socket which must be connected to a Macintosh computer running the SINQ -terminal server program via a serial cable. Please make sure with a different -Macintosh or a PC that the serial line is OK and the ITC-4 responding before -plugging it in. - -\subsubsection{ITC-4 Initialisation} - - - -An ITC-4 can be configured into the system by: -\begin{quotation} -EVFactory new Temp ITC4 computer port channel\end{quotation} -This creates an ITC-4 controller object named Temp within the system. The -ITC-4 is expected to be connected to the serial port channel at the -Macintosh computer computer running the SINQ terminal server program -listening at port port. For example: -\begin{quotation} -EVFactory new Temp ITC4 lnsp22.psi.ch 4000 6\end{quotation} -connects Temp to the Macintosh named lnsp22, serial port 5 (6 above is no typo!), - listening at port 4000. - -\subsubsection{ITC-4 Additional Parameters} - - - -The ITC-4 has a few more parameter commands: -\begin{description} -\item[timeout] Is the timeout for the Macintosh terminal server program waiting for -responses from the ITC-4. Increase this parameter if error messages -containg ?TMO creeping up. -\item[ sensor] Sets the sensor number to be used for reading temperature. -\item[ control] Sets the control sensor for the ITC-4. This sensor will be used -internally for regulating the ITC-4. -\item[divisor] The ITC4 does not understand floating point numbers, the ITC-503 does. -In order to make ITC4's read and write temperatures correctly floating point -values must be multiplied or divided with a magnitude of 10. This parameter -determines the appropriate value for the sensor. Is usually 10 for a sensor -with one value behind the comma or 100 for a sensor with two values after -the comma. -\item[multiplicator] The same meaning as the divisor above, but for the control sensor. -\end{description} - -\subsubsection{Installing an ITC4 step by step} - - - -\begin{enumerate}\item Connect the ITC temperature controller to port 6 on the Macintosh -serial port extension box. Port 6 is specially configured for dealing with -the ideosyncracies of that device. No null modem is needed. -\item Install the ITC4 into SICS with the command: \newline -evfactory new name Macintoshname 4000 7\newline -Thereby replace name with the name you want to address the ITC4 in SICS. A -good choice for a name is temperature, as such a value will be written to data files. -Please note, that SICS won't let you use that name if it already exists. For -instance if you already had a controller in there. Then the command:\newline -evfactory del name \newline -will help. Macintoshname is the name of the instrument Macintosh PC. -\item Configure the upper and lowerlimits for your controller appropriatetly. -\item Figure out which sensor you are going to use for reading temperatures. -Configure the sensor and the divisor parameter accordingly. -\item Figure out, which sensor will be used for controlling the ITC4. Set the -parameters control and multiplicator accordingly. Can be the same as the -sensor. -\item Think up an agreeable temperature tolerance for your measurement. This -tolerance value will be used 1) to figure out when the ITC4 has reached its -target position. 2) when the ITC4 will throw an error if the ITC4 fails to -keep within that tolerance. Set the tolerance parameter according to the -results of your thinking. -\item Select one of the numerous error handling strategies the control -software is able to perform. Configure the device accordingly. -\item Test your setting by trying to read the current temperature. -\item If this goes well try to drive to a temperature not to far from the -current one. -\end{enumerate} - -\subsubsection{ITC-4 Trouble Shooting} - - - -If the ITC-4 {\bf does not respond at all}, make sure the serial connection to -the Macintosh is working. Use standard RS-232 debugging procedures for doing -this. The not responding may also come up as a failure to connect to the ITC-4 -during startup. - - If error messages containing the string {\bf ?TMO} keep creeping up followed -by all signs of command not understood, then increase the timeout. The standard -timeout of 10 microseconds is to short at times. - -You keep on reading {\bf wrong values} from the ITC4. Mostly off by a -factor 10. Then set the divisor correctly. Or you may need to choose a -decent sensor for that readout. - -Error messages when {\bf trying to drive the ITC4}. These are usually the -result of a badly set multiplicator parameter for the control sensor. - -The ITC4 {\bf never stops driving}. There are at least four possible -causes for this problem: -\begin{enumerate} -\item The multiplicator for the control sensor was wrong and the ITC4 has now -a set value which is different from your wishes. You should have got error -messages then as you tried to start the ITC4. -\item The software is reading back wrong temperature because the sensor and -divisor parameters are badly configured. Try to read the temperature and if -it does have nothing to do with reality, set parameters accordingly. -\item The tolerance parameter is configured so low, that the ITC4 never -manages to stay in that range. Can also be caused by inappropriate PID -parameters in the ITC4. -\item -You are reading on one sensor (may be 3) and controlling on another one (may -be 2). Then it may happen that the ITC 4 happily thinks that he has reached -the temperature because its control sensor shows the value you entered as -set value. But read sensor 3 still thinks he is far off. The solution is to -drive to a set value which is low enough to make the read sensor think it is -within the tolerance. That is the temperature value you wanted after all. -\end{enumerate} - -\subsection{Haake Waterbath Thermostat} - -\label{f17:haake} - -This is sort of a buck full of water equipped with a temperature -control system. The RS-232 interface of this device can only be operated at -4800 baud max. This is why it has to be connected to the serial printer port -of the Macintosh serial port server computer. This makes the channel number to -use for initialisation a 1 always. The driver for this device has been -realised in the Tcl extension language of the SICS server. A prerequisite -for the usage of this device is that the file hakle.tcl is sourced in the -SICS initialisation file and the command inihaakearray has been published. - Installing the -Haake into SICS requires two steps: first create an array with -initialisation parameters, second install the device with evfactory. A -command procedure is supplied for the first step. Thus the initialisation -sequence becomes: -\begin{quotation} -inihaakearray name-o-array macintosh-computer name port channel\newline -evfactory new temperature tcl name-of-array\end{quotation} -An example for the SANS: -\begin{quotation} -inihaakearray eimer lnsp25.psi.ch 4000 1 \newline -evfactory new temperature tcl eimer\end{quotation} -Following this, the thermostat can be controlled with the other environment -control commands. - -The Haake Thermostat understands a single special subcommand: {\bf sensor}. -The thermostat may be equipped with an external sensor for controlling and -reading. The subcommand sensor allows to switch between the two. The exact -syntax is: -\begin{quotation} -temperature sensor val\end{quotation} -val can be either intern or extern. - -\subsection{Dilution Cryostat} - -\label{f17:dilu} - -This is a large ancient device for reaching very low temperatures. This -cryostat can be configured into SICS with the command: -\begin{verbatim} -EVFactory new Temp dillu computer port channel table.file -\end{verbatim} -Temp is the name of the dilution controller command in SICS, dillu is the -keyword which selects the dilution driver, computer, port and channel are -the parameters of the Macintosh-PC running the serial port server program. -table.file is the fully qualified name of a file containing a translation -table for this cryostat. The readout from the dilution controller is a -resistance. This table allows to interpolate the temperature from the -resistance measurements and back. Example: -\begin{verbatim} -evfactory new temperature dillu lnsp19.psi.ch 4000 1 dilu.tem -\end{verbatim} -installs a new dilution controller into SICS. This controller is connected -to port 1 at the Macintos-PC with the newtwork adress lnsp19.psi.ch. On this -macintosh-PC runs a serial port server program listening at TCP/IP port -4000. The name of the translation table file is dilu.tem. - -The dilution controller has no special commands, but two caveats: As of -current (October 1998) setting temperatures does not work due to problems -with the electronics. Second the dilution controller MUST be connected to -port 1 as only this port supports the 4800 maximum baud rate this device -digests. - -\subsection{Bruker Magnet Controller B-EC-1} - -\label{f17:bruker} - -This is the Controller for the large magnet at SANS. The controller is a -box the size of a chest of drawers. This controller can be operated in one -out of two modes: in {\bf field} mode the current for the magnet is controlled via -an external hall sensor at the magnet. In {\bf current} mode, the output current -of the device is controlled. This magnet can be configured into SICS with a -command syntax like this: -\begin{quotation} -evfactory new name bruker Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion (which will be used throughout the rest of the text) is magnet. -bruker is the keyword for selecting the bruker driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at SANS): -\begin{verbatim} -evfactory new magnet bruker lnsp25.psi.ch 4000 9 -\end{verbatim} - -creates a new command magnet for a Bruker magnet Controller connected to -serial port 9 at lnsp25. -In addition to the standard environment controller commands this magnet -controller understands the following special commands: -\begin{description} -\item[magnet polarity] Prints the current polarity setting of the controller. Possible -answers are plus, minus and busy. The latter indicates that the controller -is in the process of switching polarity after a command had been given to -switch it. -\item[magnet polarity val] sets a new polarity for the controller. Possible values for val are -{\bf minus} or {\bf plus}. The meaning is self explaining. -\item[magnet mode] Prints the current control mode of the controller. Possible -answers are {\bf field} for control via hall sensor or {\bf current} for -current control. -\item[magnet mode val] sets a new control mode for the controller. Possible values for val are -{\bf field} or {\bf current}. The meaning is explained above. -\item[magnet field] reads the magnets hall sensor independent of the control mode. -\item[magnet current] reads the magnets output current independent of the control mode. -\end{description} - -Warning: There is a gotcha with this. If you type only magnet a -value will be returned. The meaning of this value is dependent on the -selected control mode. In current mode it is a current, in field mode it is -a magnetic field. This is so in order to support SICS control logic. -You can read values at all times explicitly using magnet current or -magnet field. - -\subsection{The CryoFurnace.} - -\label{f17:ltc11} - -The CryoFurnace at PSI is equipped with a Neocera LTC-11 temperature -controller. This controller can control either an heater or an analag output -channel. Futhermore a choice of sensors can be selected for controlling the -device. The LTC-11 behaves like a normal SICS environment control device -plus a few additional commands. An LTC-11 can be configured into SICS with -the following command: -\begin{quotation} -evfactory new name ltc11 Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -ltc11 is the keyword for selecting the LTC-11 driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at DMC): -\begin{verbatim} -evfactory new temperature ltc11 lnsp18.psi.ch 4000 6 -\end{verbatim} - -creates a new command magnet for a LTC-11 temperature Controller connected to -serial port 6 at lnsp18. - -The additional commands understood by the LTC-11 controller are: -\begin{description} -\item[temperature sensor ] allows to query the current sensor used for temperature readout. -\item[temperature sensor val ] allows to select the sensor val for temperature readout. -\item[temperature controlanalog ] allows to query the sensor used for controlling the analog channel. -\item[temperature controlanalog val ] allows to select the sensor val for controlling the analog channel. -\item[temperature controlheat ] allows to query the sensor used for controlling the heater channel. -\item[temperature controlheat val ] allows to select the sensor val for controlling the heater channel. -\item[temperature mode] Allows to query if the LTC-11 controls the analog or heater channel. -\end{description} - -Further notes: As the CryoFurnace is very slow and the display at the -controller becomes unusable when the temperature is read out to often, the -LTC-11 driver buffers the last temperature read for 5 seconds. Setting the -mode of the LTC-11 is possible by computer, but not yet fully understood and - therefore unusable. - -\subsection{The Eurotherm Temperature Controller} - -\label{f17:euro} - -At SANS there is a Eurotherm temperature controller for the sample heater. - This and probably other Eurotherm controllers can be configured into SICS -with the following command. The eurotherm needs to be connected with a - nullmodem adapter. -\begin{quotation} -evfactory new name euro Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -euro is the keyword for selecting the Eurotherm driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. {\bf WARNING:} The eurotherm needs a RS-232 port with an unusual - configuration: 7bits, even parity, 1 stop bit. Currently only the SANS - Macintosh port 13 (the last in the upper serial port connection box) is - configured like this! Thus, an example for SANS and the name temperature - looks like: -\begin{verbatim} -evfactory new temperature euro lnsp25.psi.ch 4000 13 -\end{verbatim} - -There are two further gotchas with this thing: -\begin{itemize} -\item The eurotherm needs to operate in the EI-bisynch protocoll mode. This has -to be configured manually. For details see the manual coming with the machine. -\item The weird protocoll spoken by the Eurotherm requires very special control - characters. Therefore the send functionality usually supported by a SICS - environment controller could not be implemented. -\end{itemize} - -% html: End of file: `samenv.htm' -% html: Beginning of file: `dmcdev.htm' - -\chapter{DMC-specific command and device list} - -\label{f18} - - -\section{DMC specific commands} - - - -\begin{description}\item[StoreData] Does what it says. Writes the current state of the instrument -including counts to a NeXus data file. -\item[count mode preset] Does a count operation in mode with a preset of preset. - The parameters are optional. If they are not - given the count will be started with the current setting in the histogram -memory object. After the count, StoreData will be automatically called. -\item[ Repeat num mode preset.] Calls count num times. num is a required parameter. The other two are - optional and are handled as described above for count. -\item[ scan motor start step n mode preset] This command allows for scanning a motor against monitors 0 and 1. This - command may only be used by managers. Its only purpose is to facilitate - the adjustment of the instrument. In order to obtain a copy of the scan - results, a user must take great care to enable command logging. The - parameters are: a motor to be scanned, a start value for the scan, a - step width for the scan, the number of scan points, optionally a count - mode and a preset value for counting. Both these parameters have meanings - as described above for the count command. -\end{description} - -\section{DMC motor list} - - - -\begin{description}\item[OmegaM, A1] Omega monochromator. -\item[TwoThetaM, A2] Two Theta monochromator -\item[MonoX] X-translation table of the monochromator. -\item[MonoY] Y-translation table for the monochromator. -\item[CurveM] Monochromator curvature. -\item[MonoPhi] Phi angle of the monochromator. -\item[MonoChi] Chi angle for the monochromator. -\item[Table, A3] Sample rotation. -\item[TwoThetaD, A4] Two Theta detector. -\end{description} - -\section{Other DMC devices} - - - -\begin{description}\item[banana] Histogram memory. -\item[counter] EL737 counter box. -\end{description} - -\section{DMC Variables} - - - -\begin{description}\item[Instrument] Instrument name. -\item[Title] Experiment title. -\item[comment1, comment2, comment3] comment lines to be stored with the data. -\item[Collimation] Text line describing collimators in use. -\item[User] User name. -\item[Adress] User adress -\item[phone] User phone number. -\item[fax] User fax number -\item[email] User email adress. -\item[Sample] Sample name -\item[sample\_mur] Absorption coefficient of sample. -\end{description} - -% html: End of file: `dmcdev.htm' -% html: Beginning of file: `trouble.htm' - -\chapter{SICS Trouble Shooting } - -\label{f1} - - -There is no such thing as bug free software. There are always bugs, nasty -behaviour etc. This document shall help to solve these problems. The usual -symptom will be that a client cannot connect to the server or the server is -not responding. - -An essential prerequisite of SICS is that the server is 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: -\begin{verbatim} -startsics -\end{verbatim} -at the command prompt. startsics actually starts two programs: one is -the replicator application which is responsible for the automatic -copying of data files to the laboratory server. The other is the SICS -server. Both programs are started by means of a shell script called -{\bf keepalive}. keepalive is basically an endless loop which calls -the program again and agaian and thus ensures that the program will -never stop running. - - When the SICS server hangs, or you want to enforce an reinitiliazation of -everything the server process must be killed. The first thing to -do is to find the process. - -\section{Finding the SICS server} - - - -Log in as Instrument user on the instrument computer (for instance DMC on -lnsa05). Type the command: -\begin{verbatim} -/home/DMC> ps -A -\end{verbatim} -Note the capital A given as parameter. The reward will be listing like this: -\begin{verbatim} - 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 -\end{verbatim} -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 ?? } an entry for the SICS server. In this example the server -is running. If the server is down, no such entry would be present. - -\section{ Killing a hanging SICS server } - - - -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} 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}. Please note, that this number will -always be different. The command to force the server to stop is: -\begin{verbatim} -/home/DMC> kill -9 31912 -\end{verbatim} -Note, the second parameter is the number found with {\tt ps -A}. 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. - -\section{ Shutting the SICS server down completely} - - - -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 {\bf keepalive SICServer }. Kill that one as -described above, then kill the SICServer. For restarting SICS after this, -use the startsics command. - -\section{Restart Everything} - - - -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. -\begin{enumerate} -\item Reboot the Macintosh PC by switching it off at the silver button on the -left. Press deep and a few seconds to achieve an effect. The LED right to the -button should be off, before you press again to boot the Macintosh. -\item 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. -\item Wait 5 minutes. The Macintosh may take that time to come up again. -\item Restart the SICServer. Watch for any messages about things not being -connected or configured. -\item Restart and reconnect the client programs. -\end{enumerate} -If this fails (even after a second) time there may be a network problem which -can not be resolved by simple means. - -\section{ HELP debugging!!!!} - - - -The SICS server hanging or crashing should not happen. In order to sort such -problems out it is very helpful if any available debugging information is -saved and presented to the programmers. Information available are the log -files as written continously by the SICS server and posssible core files -lying around. They have just this name: core. In order to save them create a -new directory (for example dump2077) and copy the stuff in there. This looks -like: -\begin{verbatim} -/home/DMC> mkdir dump2077 -/home/DMC> cp log/*.log dump2077 -/home/DMC> cp core dump2077 -\end{verbatim} -The {\tt /home/DMC> } is just the command prompt. Please note, that core -files are only available after crashes of the server. These few commands -will help to analyse the cause of the problem and to eventually resolve it. -% html: End of file: `trouble.htm' -% html: Beginning of file: `dmco.htm' - -\chapter{DMC Command Summary} - -\label{f19} - - - -\section{Most Used Commands} - - -\begin{description} -\item[drive a4 value] (cf.\ Section~\ref{f9}) Drives the detector to a new 2 Theta value. Be careful and watch out for -rubbish trying to block the detectore pass through the experiment hall. -\item[drive lambda value.] Drives the wavelength to a new value. The whole instrument is going to -move. Add 10 extra levels of care to the above when doing this. -\item[ count mode preset] (cf.\ Section~\ref{f18}) Counts in mode with a preset value of preset. Stores data automatically. -\item[ Repeat num mode preset] Calls count num times. -\item[FileEval filename] (cf.\ Section~\ref{f7}) Runs a batch file with the specified filename. -\end{description} - -\section{Driving} - - - -\begin{description}\item[drive mot1 NewVal mot2 NewVal ....] (cf.\ Section~\ref{f9}) Drives motors. Followed by pairs of motor names and new values. -\item[run mot1 NewVal mot2 NewVal ....] Runs motors. -\end{description} -Known motors are: OmegaA, A1, TwoThetaM, A2, MonoX, MonoY, MonoChi, MonoPhi, -CurveM, Table, A3, TwoThetaD, A4. - -\section{ Counting } - - - -\begin{description}\item[banana CountMode \hbox{$[$}NewVal\hbox{$]$}] (cf.\ Section~\ref{f15}) Without a parameter displays the current counting mode. With parameter sets -the count mode. Possible values are Timer for waiting for time or Monitor for -waiting for a monitor. -\item[banana preset \hbox{$[$}NewVal\hbox{$]$}] Without a parameter displays the current preset for either time or monitor. -With a parameter sets the preset. -\item[banana count] Starts counting. -\item[StoreData] (cf.\ Section~\ref{f18}) Writes the current state of DMC to a NeXus file. -\item[ count mode preset] (cf.\ Section~\ref{f18}) Counts in mode with a preset of preset. Stores data automatically. -\item[ Repeat num mode preset] Calls count num times. -\end{description} - -\section{R\"unbuffer} - - - -\begin{description}\item[ Buf new name] (cf.\ Section~\ref{f8}) New buffer name -\item[Buf copy name1 name2] copies buffers. -\item[Buf del name] deletes buffer. -\end{description} -Buffers created with Buf new name are installed as command name and understand: -\begin{description} -\item[NAME append bla bla .......] Append text to buffer -\item[NAME del iLine] Deletes line. -\item[ NAME ins iLine bla bla ....] Inserts text after line. -\item[NAME print] prints contents of buffer to screen. -\item[NAME save file] Saves buffer to file. -\item[NAME read file] Read buffer contents from file. -\item[NAME run] Executes contents of buffer. -\end{description} -There can be a stack of R\"unbuffers. -\begin{description} -\item[RuLi add buffer] Adds an buffer to the stack. -\item[RuLi list] Lists the stack. -\item[RuLi del line] Deletetes buffer from stack. -RuLi ins iLine name - Inserts name after iLine. -\item[ RuLi run] Executes Stack. -\item[ RuLi batch] Executes stack permanently. New buffers may be added. -\end{description} - -\section{ General commands } - - - -\begin{description}\item[Success] (cf.\ Section~\ref{f9}) wait for the last operation to finish. -\item[wait time] (cf.\ Section~\ref{f4}) wait for time to pass.... -\item[Dir ] (cf.\ Section~\ref{f4}) lists all objects in the system. -\item[config Rights username password] (cf.\ Section~\ref{f6}) changes authorisation to that of the user identified by username, -password. -\item[FileEval filename] (cf.\ Section~\ref{f7}) executes batch file filename. -\end{description} - -\section{ Log Files} - - - -\begin{description}\item[LogBook file name] (cf.\ Section~\ref{f10}) sets log file name -\item[ LogBook on] switches logging on -\item[LogBook off] closes LogBook -\item[LogBook] lists current logging status -\end{description} - -\section{ Variables} - - - -Each variable (cf.\ Section~\ref{f18}) - can be inquired by just typing its name. It can be set by -typing the name followed by the new value. Currently available variables -are: -\begin{itemize} -\item Title -\item User -\item comment1 -\item comment2 -\item comment3 -\item User -\item adress -\item phone -\item email -\item Sample -\item sample\_mur -\end{itemize} - -% html: End of file: `dmco.htm' - -\end{document} \ No newline at end of file diff --git a/doc/user/foman.tex b/doc/user/foman.tex deleted file mode 100644 index 853e22ce..00000000 --- a/doc/user/foman.tex +++ /dev/null @@ -1,1800 +0,0 @@ -\documentclass[12pt,a4paper]{report} -%%\usepackage[dvips]{graphics} -%%\usepackage{epsf} -\setlength{\textheight}{24cm} -\setlength{\textwidth}{16cm} -\setlength{\headheight}{0cm} -\setlength{\headsep}{0cm} -\setlength{\topmargin}{0cm} -\setlength{\oddsidemargin}{0cm} -\setlength{\evensidemargin}{0cm} -\setlength{\hoffset}{0cm} -\setlength{\marginparwidth}{0cm} - -\begin{document} -\begin{center} -\begin{huge} -FOCUS--Reference Manual \\ -\end{huge} -Version April, 1999\\ -Dr. Mark K\"onnecke \\ -Labor f\"ur Neutronenstreuung\\ -Paul Scherrer Institut\\ -CH--5232 Villigen--PSI\\ -Switzerland\\ -\end{center} -\clearpage -\clearpage -\tableofcontents -\clearpage - -\chapter{Introduction} -% html: Beginning of file: `focus.htm' -\label{f0} -Welcome to the Time-Of-Flight spectrometer FOCUS at SINQ! This manual -describes how to operate FOCUS through the means of the instrument -control software system SICS. SICS means: Sinq Instrument Control -System. SICS is a client server system. This means there is a magic server -program running somewhere which does all the work. The user interacts -only with client applications which communicate with the server -through the network. Most instument hardware (motor controllers, -counter boxes etc.) is connected to the system through RS-232 serial -connections. These RS-232 ports are connected to a Macintosh-PC which -acts as a terminal server by means of a special program running on -it. The SICS server communicates with this terminal server and other -devices through the network. - -% html: End of file: `focus.htm' -\chapter{User Commands} -% html: Beginning of file: `sicsinvoc.htm' - -\section{SICS Invocation} - -\label{f1} - -SICS means SINQ Instrument Control System. -SICS is a client server system. This means there are at least two programs -necessary to run the experiment. The first -is the -SICServer which does the actual instrument control work. A user rarely needs -to bother about this server program as it is meant to run all the time. -See instructions below if things go wrong. - -Then there are client programs which interact with the -instrument control server. These client programs implement the status -displays and a command line application which forwards commands to the -SICS server and displays its response. Graphical User Interfaces may -be added at a later time. -The user has only to deal with -these SICS client programs. SICS Clients and the SICServer communicate -with each other through the TCP/IP network. - -Currently five SICS clients are available: -\begin{itemize} -\item A command line control client for sending commands to the SICS -server and displaying its repsonses. -\item A status display for the powder diffractometers DMC and HRPT. -\item A status display for TOPSI. -\item A status display for SANS. -\item A status display for FOCUS. -\item A status display for AMOR. -\item A SICS variable watcher. This application graphically logs the -change of a SICS variable over time. Useful for monitoring for -instance temperature controllers. -\end{itemize} - - -\subsection{Steps necessary for logging in to SICS} - - -The following actions have to be taken in order to interact with the -SICS server through a client: -\begin{itemize} -\item Start the client application. -\item Connect the client to a SICS server. -\item In case of command line clients: authorize yourself as -privileged SICS user. -\end{itemize} - -\subsection{Starting SICS client applications } - - - -These programs can be started on a DigitalUnix system by issuing the -following commands at the command prompt: -\begin{description} -\item[sics \&] for the control client. -\item[powderstatus \&] for the DMC status display client. -\item[topsistatus \&] for the TOPSI status display. -\item[sansstatus \&] for the SANS status display. -\item[focustatus] for the FOCUS status display. -\item[amor] for the AMOR status display and control application. -\item[varwatch \&] for the variable watcher. -\end{description} -On a PC you may find icons for starting the different programs on the -desktop. -Each of these clients has usage instructions online which can be displayed -through the help/about menu entry. - -\subsection{Connecting} - - - -After startup any SICS client is not connected to a SICS server and thus not -active. A connection is established through the connect menu of the client. - -\subsection{Authorization} - - - -SICS is a multi user instrument control system. In order to prevent -malicious manipulations of the instrument SICS supports a hierarchy of user -rights. In order to run an experiment you need at least user level privilege. -In order to achieve this privilege you have to invoke the User Parameter/Set -Rights dialog. There you have to enter the apropriate username and password -kindly provided by your instrument scientist. - -\subsection{Restarting the Server} - - - -The SICS server should be running all the time. It is only down if something -went wrong. You can check for the presence of the SICS server by loging in -to the instrument computer and typing {\bf CheckSICS} at the command -prompt. The output will tell you what is happening. If you need to restart -the SICS server log in as the instrument user at the instrument computer and -invoke the apropriate command to start the server. These are: -\begin{description} -\item[DMC] Computer = lnsa05,User = DMC -\item[TOPSI] Computer = lnsa07,User = TOPSI -\item[SANS] Computer = lnsa10,User = SANS -\item[TRICS] Computer = lnsa13, User = TRICS -\item[HRPT] Computer = lnsa11, User = HRPT -\item[FOCUS] Computer = lnsa12, User = FOCUS -\item[AMOR] Computer = lnsa14, User = AMOR -\item[DRUECHAL] Computer = lnsa16, User = DRUECHAL -\end{description} -For starting the SICS server type {\bf startsics}. This is a shell script -which will starts all necessary server programs. This script works only on -the instrument computer and in the appropriate instrument account. - - If all this does not help look under trouble shooting -SICS (cf.\ Section~\ref{f19}). -% html: End of file: `sicsinvoc.htm' -% html: Beginning of file: `drive.htm' - -\section{Drive commands} - -\label{f2} - - Many objects in SICS are {\bf 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 an energy. This class of objects can be operated by the {\bf drive, run, Success } family of commands. These commands cater for blocking and non-blocking modes of operation. - - {\bf run var newval var newval ... } 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 operate other devices of the instrument while perhaps a slow device is still running into position. - - {\bf Success } waits and blocks the command connection until all pending operations have finished (or an interrupt occured). - - {\bf drive var newval var newval ... } can be called with one to n pairs of object 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 immediatly followed by a Success command. -% html: End of file: `drive.htm' -% html: Beginning of file: `fomo.htm' - -\section{FOCUS motors} - -\label{f3} - - -\subsection{Physical Motors} - - -\begin{description} -\item[MTT] Monochromator two theta. Only readable up to know. Must be moved manually -by pushing the detector around. -\item[MSL ] Monochromator shielding lift. -\item[MTH] Monochromator theta. -\item[MTX] Monochromator x-translation, vertical to monochromator surface. -\item[MTY] Monochromator y-translation, parallel to monochromator surface. -\item[MGO] Monochromator tilting. -\item[M1CH] Monochromator 1 curvature horizontal. -\item[M1CV] Monochromator 1 curvature vertical. -\end{description} - -\subsection{Virtual motors} - - - -Virtual motors are instrument parameters which can be driven with the -drive and run commands, though they are not physical motors. Mostly -this encompasses coordinated movements of motors around several axis -or other lengthy and error prone hardware operations. -\begin{description} -\item[lambda] wavelength -\item[ei] incident energy in meV. -\item[fermispeed] fermi chopper speed. -\item[diskspeed] disk chopper speed. This works only when the chopper is NOT in -synchonized mode. -\item[phase] chopper phase difference. -\item[ratio] This is the ratio fermispeed/diskspeed. A value of two would mean that the diskchopper is running at half the speed of the fermichopper. - Please note that the phase is set to 0 -automatically while running this command by the chopper controller -software from Dornier. -\end{description} - -% html: End of file: `fomo.htm' -% html: Beginning of file: `chopper.htm' - -\section{Chopper Control} - -\label{f4} - -FOCUS is equipped with a Dornier Chopper system running two choppers: -a disk chopper and a fermi chopper. In most situations the diskchopper is -in slave mode. This means his speed is a predefined ratio of the -speed of the fermichopper. Furthermore, there is a phase difference between -the two choppers in order to allow for the fligh time of neutrons -between choppers. - -The program handling RS-232 requests at the chopper control computer -is rather slow. This would slow the SICS server to unacceptable -levels, if any request would be handled through the RS-232 interface. In order -to cope with the problem, the SICS server buffers chopper -information. This information is updated any minute if not set otherwise. - -The chopper system control is divided into several distinct objects: There -is the actual chopper controller which mainly serves for answering -status requests. Then there are a couple of virtual motors which -represent the four modifiable parameters of the chopper control -system. These can be driven through the normal drive (cf.\ Section~\ref{f2}) command. The commands understood by the -chopper controller object are: -\begin{description} -\item[choco list] prints a listing of all known chopper parameters. -\item[choco name] print only the value of parameter name. Possible values for name -can be extratcted from the list printed with choco list. -\item[chosta] This command procedure prints a status listing of the chopper -system in a nicely formatted stefan-happy form. -\end{description} - The following virtual motor variables exist for the chopper system. -\begin{description} -\item[fermispeed] fermi chopper speed -\item[diskspeed] disk chopper speed. Note, that driving this parameter while the -chopper system is in synchronous mode will throw an error condition. -\item[phase] The phase difference between the two choppers. -\item[ratio] The ratio of fermi to disk chopper speeds. -\item[updateintervall] The update intervall for the buffering of chopper data. Units are -seconds. Setting to low values here will compromise the responsiveness -of the SICS server. -\end{description} -Each of the variables kindly prints its current value when given as a -command. Modifying values happens through the normal drive -command. For instance the command: -\begin{verbatim} -drive fermispeed 10000 -\end{verbatim} -will drive the fermi chopper to 10000 RPM eventually and if no problem occurs. -Please check your input carefully for all chopper commands. -Dornier has provided no way to stop an erraneous command in its software. So, if you intend to run the chopper to 1000 RPM and mistyped it as 10000 then -you'll wait for 20 minutes until the chopper is at speed! -% html: End of file: `chopper.htm' -% html: Beginning of file: `count.htm' - -\section{Counting Commands.} - -\label{f5} - -\begin{description}\item[count mode preset] Does a count operation in mode with a preset of preset. - The parameters are optional. If they are not - given the count will be started with the current setting in the histogram -memory object. After the count, StoreData will be automatically called. -\item[ Repeat num mode preset.] Calls count num times. num is a required parameter. The other two are - optional and are handled as described above for count. -\end{description} -Both commands make sure, that measured data is written to files. -% html: End of file: `count.htm' -% html: Beginning of file: `logging.htm' - -\section{Logging your activity} - -\label{f6} - -SICS offers not less then three different ways of logging your -commands and the SICS server's responses: -\begin{itemize} -\item The SICS command line client allows to open a log file on your -local computer and on your account. This can be achieved through the -File/Open Logfile menu entry. Select a file name and hit save. From -then on, any output in the SICS clients terminal area will be written -into the selected file. There is a gotcha: ouptut may not be immediately -visible in the file. This is due to buffering of I/O by the operating -system. If you want to flush, either open a new file or exit the -client. Flushing I/O at each line written is possible, but would have -a massive and unacceptable performance impact. -\item You may create a similar per client log file on the computer running -the SICS server through the logbook (cf.\ Section~\ref{f21}) command. -\item Then there is a way to log all activity registered from users with -either user or manager privilege into a file. This means: all commands -which affect the experiment regardless from which client they have -been issued. This is accomplished with the -commandlog (cf.\ Section~\ref{f22}) command. -\end{itemize} - -% html: End of file: `logging.htm' -% html: Beginning of file: `logbook.htm' - -\subsection{LogBook command} - -\label{f21} - -Some users like to have all the input typed to SICS and responses -collected in a file for further review. This is implemented via the LogBook -command. LogBook is actually a wrapper around the config file command. -LogBook understands the following syntax: -\begin{description} -\item[ LogBook] alone prints the name of the current logfile and the status of event -logging. -\item[ LogBook file filename] This command sets the filename to which output will be printed. -Please note that this new filename will only be in effect after restarting -logging. -\item[ LogBook on] This command turns logging on. All commands and all answers will be -written to the file defined with the command described above. Please note, -that this command will overwrite an existing file with the same name. -\item[ LogBook off] This command closes the logfile and ends logging. -\end{description} - -% html: End of file: `logbook.htm' -% html: Beginning of file: `commandlog.htm' - -\subsection{The Commandlog} - -\label{f22} - -The commandlog is a file where all communication with clients -having user or manager privilege is logged. This log allows to retrace each -step of an experiment. This log is usually switched off and must be -configured by the instrument manager. There exists a special command, -commandlog, which allows to control this log file. -\begin{description} -\item[commandlog new filename] starts a new commandlog writing to filename. Any prior files will be -closed. The log file can be found -in the directory specified by the ServerOption LogFileDir. Usually this is -the log directory. -\item[commandlog] displays the status of the commandlog. -\item[commandlog close] closes the commandlog file. -\item[commandlog auto] Switches automatic log file creation on. This is normally switched on. -Log files are written to the log directory of the instrument account. There - are time stamps any hour in that file and there is a new file any 24 hours. -\item[commandlog tail n] prints the last n entries made into the command log. n is optional and defaults to 20. Up to 1000 lines are held in an internal buffer for this command. -\end{description} - -% html: End of file: `commandlog.htm' -% html: Beginning of file: `batch.htm' - -\section{Batch Processing in SICS} - -\label{f7} - -Users rarely wish to stay close to the instrument all the time but appreciate - if the control computer runs the experiment for them while they -sleep. SICS supports two different ways of doing this: -\begin{itemize} -\item SICS has a built in macro programming (cf.\ Section~\ref{f23}) facility based on the - popular scripting language Tcl. The most primitive usage of this -facility is processing batch files. -\item Second there is the LNS R\"unbuffer (cf.\ Section~\ref{f24}) system. -\end{itemize} - -% html: End of file: `batch.htm' -% html: Beginning of file: `macro.htm' - -\subsubsection{Macro Commands} - -\label{f23} - - 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 Tool Command Language (TCL). Tcl has control constructs, variables of its own, loop constructs, associative arrays and procedures. Tcl is well documented by several books and online tutorials, therefore no details on Tcl will be given here. All SICS commands are available in the macro language. Some potentially harmful Tcl commands have been deleted from the standard Tcl interpreter. These are: exec, source, puts, vwait, exit,gets and socket. A macro or batch file can be executed with the command: - - {\bf FileEval name } tries to open the file name and executes the script in this file. -Then there are some special commands which can be used within macro-sripts: - - {\bf ClientPut sometext1 ... } writes everything after ClientPut to - the client which started the script. This is needed as SICS supresses - the output from intermediate commands in scripts. Except error - messages and warnings. With clientput this scheme can be circumvented - and data be printed from within scripts. - -{\bf SICSType object } allows to query the type of the object specified by object. Possible return values are -\begin{itemize} -\item {\bf DRIV } if the object is a SICS drivable object such as a motor -\item {\bf COUNT } if the object is some form of a counter. -\item {\bf COM } if the object is a SICS command. -\item {\bf NUM } if the object is a number. -\item {\bf TEXT } if object is something meaningless to SICS. -\end{itemize} - - {\bf SICSbounds var newval } checks if the new value newval lies within the limits for varaible var. Returns an error or OK depending on the result of the test. - - {\bf SICSStatus var } SICS devices such as counters or motor may be - started and left running while the program is free to do something - else. This command inquires the status of such a running device. Return values are internal SICS integer codes. This command is only of use for SICS programmers. - -{\bf SetStatus newval } sets the SICS status to one of: Eager, UserWait, Count, NoBeam, Driving, Running, Scanning, Batch Hatl or Dead. This command is only available in macros. - - {\bf SetInt newval, GetInt } sets SICS interrupts from macro scripts. Not recommended! Possible return values or new values are: continue, abortop, abortscan, abortbatch, halt, free, end. This command is only permitted in macros. Should only be used by SICS programmers. -% html: End of file: `macro.htm' -% html: Beginning of file: `buffer.htm' - -\subsubsection{R\"unbuffer Commands} - -\label{f24} - - LNS scientists have got used to using R\"unbuffers for instrument - control. A R\"unbuffer is an array of SICS commands which - typically represent a measurement. This R\"unbuffer can be edited - at run time. This is very similar to a macro. In contrast to a macro - only SICS commands are allowed in R\"unbuffers. When done with - editing the R\"unbuffer it can be entered in a R\"unlist. This - is a stack of R\"unbuffers which get executed one by one. While - this is happening it is possible (from another client) to modify the - R\"unlist and edit and add additional R\"unbuffers on top of - the stack. This allows for almost infinite measurement and gives more - control than a static batch file. In order to cater for this scheme - three commands have been defined: - - The {\bf Buf } object is responsible for creating and deleting R\"unbuffers. The syntax is: -\begin{itemize} -\item {\bf Buf new name } creates a new empty R\"unbuffer with the name name. name will be installed as a SICS object afterwards. -\item {\bf Buf copy name1 name2 } copies R\"unbuffer name1 to buffer name2. -\item {\bf Buf del name } deletes the R\"unbuffer name. -\end{itemize} - - After creation, the R\"unbuffer is accessible by his name. It - then understands the commands: -\begin{itemize} -\item {\bf NAME append what shall we do with a drunken sailor } will add all text after append as a new line at the end of the R\"unbuffer. -\item {\bf NAME print } will list the contents of the R\"unbuffer. -\item {\bf NAME del iLine } will delete line number iLine from the R\"unbuffer. -\item {\bf NAME ins iLine BimBamBim } inserts a new line {\bf after } line iLine into the R\"unbuffer. The line will consist of everything given after the iLine. -\item {\bf NAME subst pattern newval } replaces all occurences of pattern in the R\"unbuffer by the text specified as newval. Currently this feature allows only exact match but may be expanded to Unix style regexp or shell like globbing. -\item {\bf NAME save filename } saves the contents of the R\"unbuffer into file filename. -\item {\bf NAME load filename } loads the R\"unbuffer with the data in file filename. -\item {\bf NAME run } executes the R\"unbuffer. -\end{itemize} - - The R\"unlist is accessible as object {\bf stack }. Only one R\"unlist per server is permitted. The syntax: -\begin{itemize} -\item {\bf stack add name } adds R\"unbuffer name to the top of the stack. -\item {\bf stack list } lists the current R\"unlist. -\item {\bf stack del iLine } deletes the R\"unbuffer iLine from the R\"unlist. -\item {\bf stack ins iLine name } inserts R\"unbuffer name after R\"unbuffer number iLine into the R\"unlist. -\item {\bf stack run } executes the R\"unlist and returns when all R\"unbuffers are done. -\item {\bf stack batch } executes the R\"unlist but does not return when done but waits for further R\"unbuffers to be added to the list. This feature allows a sort of background process in the server. -\end{itemize} - -% html: End of file: `buffer.htm' -% html: Beginning of file: `token.htm' - -\subsection{The Token Command} - -\label{f8} - -In SICS any client can issue commands to the SICS server. This -is a potential source of trouble with users possibly issuing conflicting -commands without knowing. In order to deal with this problem a -{\tt{}"{}}token{\tt{}"{}} mechanism has been developed. In this context the token is a -symbol for the control of an instrument. A connection can grab the -token and then has full control over the SICS server. Any other -connection will not be privileged to do anything useful, except -looking at things. A token can be released manully 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: -\begin{description} -\item[token grab] Reserves control over the instrument to the client isssuing this -command. Any other client cannot control the instrument now. However, other -clients are still able to inspect variables. -\item[token release] Releases the control token. Now any other client can control the -instrument again. Or grab the control token. -\item[token force password] 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. -\end{description} - -% html: End of file: `token.htm' -% html: Beginning of file: `focussps.htm' - -\section{FOCUS SPS Commands} - -\label{f9} - -The following commands are handled with the help of the Siemens SPS-system. - -\subsection{The Shutter} - -\label{f9:SHUDDER} - -Even the shutter can be controlled from within SICS. This is safe because - the shutter will not open if the door to the instrument is open. In Local - Beam Control (LBC) speak this status is named {\tt{}"{}}Enclosure is broken{\tt{}"{}}. Be - careful anyway because some idiots may climb the fence..... The following - SICS commands control the shutter: -\begin{description} -\item[shutter] The command shutter without arguments returns the status of the shutter. - This can be one of open, closed, Enclosure is broken. -\item[shutter open] opens the shutter when possible. -\item[shutter close] closes the shutter. -\end{description} - -\subsection{The Collimator} - -\label{f9:COLLI} - -FOCUS is equiped with a rotating collimator. This can be either idle or - moving. This collimator can be controlled from SICS with the following - commands: -\begin{description} -\item[colli] prints the current status of the collimator which can be either - idle or moving. -\item[colli idle] switches the collimator to idle mode. -\item[colli moving] swicthes the collimator into moving mode. -\end{description} - -\subsection{Flight Box} - -\label{f9:FBOX} - -The flight path in the detector box is normally filled with argon. - In order to detect a possible - leak an oxygen sensor is provided. The status of this sensor can be inquired - from within SICS with the command: -\begin{description} -\item[fbox] prints the status of the flightbox. Which can be either OK or Problem. -\end{description} - Obviously this cannot be controlled from the computer as any problem with - this requires massive mechanical intervention (searching the leak and - refilling argon). -% html: End of file: `focussps.htm' - -\chapter{Advanced Topics} -% html: Beginning of file: `samenv.htm' - -\section{ Sample Environment Devices} - -\label{f10} - - -\subsection{SICS Concepts for Sample Environment Devices} - -\label{f10:concept} - -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 continously. Therefore there -exists a facility for dynamically configuring and deconfiguring environment -devices into the system. This is done via the {\bf EVFactory} command. -It is expected that instrument scientists will provide command procedures or -specialised R\"unbuffers 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 mode. The device is monitored in this mode when a new value for it -has been requested. The second mode is the monitor mode. This mode 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 {\bf emon}. The emon understands a few commands of its -own. - -Within SICS all sample environement 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 section the EVFactory, emon and the general commands understood -by any sample environment device will be discussed. This reading is mandatory -for understanding SICS environment device handling. Then there will be another -section discussing the special devices known to the system. - - -\subsection{SampleEnvironment Error Handling} - - -A \label{f10:error}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 different. 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 separately. Additional error handling strategies -can be added with a modest amount of programming. The error handling strategies currently -implemented are: -\begin{description} -\item[Lazy] Just print a warning and continue. -\item[Pause] Pauses the measurement until the problem has been resolved. -\item[Interrupt] Issues a SICS interrupt to the system. -\item[Safe] Tries to run the environment device to a value considered safe by the -user. -\end{description} - -\subsection{General Sample Environment Commands} - -\label{f10:general} - -\subsubsection{EVFactory} - - - -EVFactory is responsible for configuring and deconfiguring sample environment -devices into SICS. The syntax is simple: -\begin{description} -\item[EVFactory new name type par par ...] Creates a new sample environment device. It will be known to SICS by the -name specified as second parameter. 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. -\item[EVFactory del name] Deletes the environment device name from the system. -\end{description} - -\subsubsection{emon} - - - -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. -\begin{description} -\item[emon list] This command lists all environment devices currently registered in the -system. -\item[emon register name] 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. -\item[emon unregister name] This is a specialist command which unregisters the environment device name -with the environment monitor. Usually this will automatically be taken care -of by EVFactory Following this call the device will no longer be monitored and -out of tolerance errors on that device no longer be handled. -\end{description} - -\subsubsection{General - Commands UnderStood by All Sample Environment Devices} - -\label{f10:all} - -Once the evfactory has been run successfully the controller is -installed as an object in SICS. It is accessible as an object then -under the name specified in the evfactory command. All environemnt -object understand the common commands given below. -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: -\begin{quotation} -Temperature Tolerance\end{quotation} -prints the value of the variable Tolerance for the environment controller -Temperature. This is in the same units as the controller operates, -i. e. for a temperature controller Kelvin. -\begin{quotation} -Temperature Tolerance 2.0\end{quotation} -sets the parameter Tolerance for Temperature to 2.0. Parameters known to ANY -envrironment controller are: -\begin{description} -\item[Tolerance] Is the deviation from the preset value which can be tolerated before an -error is issued. -\item[ Access] Determines who may change parameters for this controller. -Possible values are: -\begin{itemize} -\item 0 only internal -\item 1 only Managers -\item 2 Managers and Users. -\item 3 Everybody, including Spy. -\end{itemize} -\item[LowerLimit] The lower limit for the controller. -\item[UpperLimit] The upper limit for the controller. -\item[ErrHandler.] The error handler to use for this controller. Possible values: -\begin{itemize} -\item 0 is Lazy. -\item 1 for Pause. -\item 2 for Interrupt -\item 3 for Safe. -\end{itemize} - For an explanantion of these values see the section about error (cf.\ Section~\ref{f10:error}) handling -above. -\item[ Interrupt] The interrupt to issue when an error is detected and Interrupt error -handling is set. Valid values are: -\begin{itemize} -\item 0 for Continue. -\item 1 for abort operation. -\item 2 for abort scan. -\item 3 for abort batch processing. -\item 4 halt system. -\item 5 exit server. -\end{itemize} -\item[SafeValue] The value to drive the controller to when an error has been detected and -Safe error handling is set. -\end{description} - -Additionally the following commands are understood: -\begin{description} -\item[send par par ...] Sends everything after send directly to the controller and return its -response. This is a general purpose command for manipulating 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. -\item[ list] lists all the parameters for this controller. -\item[ no command, only name.] When only the name of the device is typed it will return its -current value. -\item[ name val ] will drive the device to the new value val. Please note that the same -can be achieved by using the drive command. -\item[ name log on] Switches logging on. If logging is on, at each cycle in the -{\bf 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! {\bf Log clear} -frees -it again -and {\bf log frequency} (both below) -allows to set the logging time intervall. -\item[ name log off] Switches logging off. -\item[name log clear] Clears all recorded time stamps and values. -\item[name log gettime] This command retrieves a list of all recorded time stamps. -\item[name log getval] This command retrieves all recorded values. -\item[name log getmean] Calculates the mean value and the standard deviation for all logged -values and prints them. -\item[name log frequency val] With a parameter 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 300 seconds. -\item[name log file filename] Starts logging of value data to the file filename. All normal logging to - memory will be - disabled. Logging will happen any 5 minutes initially. The logging frequency - can be changed with the name log frequency command. Each entry in the file is - of the form date time value. The name of the file must be specified relative - to the SICS server. -\item[name log close ] Stops logging data to the file. -\end{description} - -\subsection{Special Environment Control Devices} - - - -This section lists the parameters needed for configuring a special environment -device into the system and special parameters and commands only understood by -that special device. All of the general commands listed above work as well! - -\subsubsection{ITC-4 and ITC-503 Temperature Controllers} - -\label{f10:itc4} - -These temperature controller are fairly popular at SINQ. They are -manufactured by -Oxford Instruments. At the back of this controller is a RS-232 -socket which must be connected to a Macintosh computer running the SINQ -terminal server program via a serial cable. Please make sure with a different -Macintosh or a PC that the serial line is OK and the ITC-4 responding before -plugging it in. - -\paragraph{ITC-4 Initialisation} - - -An ITC-4 can be configured into the system by: -\begin{quotation} -EVFactory new Temp ITC4 computer port channel\end{quotation} -This creates an ITC-4 controller object named Temp within the system. The -ITC-4 is expected to be connected to the serial port channel at the -Macintosh computer computer running the SINQ terminal server program -listening at port port. For example: -\begin{quotation} -EVFactory new Temp ITC4 lnsp22.psi.ch 4000 7\end{quotation} -connects Temp to the Macintosh named lnsp22, serial port 6 -(7 above is no typo!), listening at port 4000. - -\paragraph{ITC-4 Additional Parameters} - - -The ITC-4 has a few more parameter commands: -\begin{description} -\item[timeout] Is the timeout for the Macintosh terminal server program waiting for -responses from the ITC-4. Increase this parameter if error messages -containg ?TMO appear. -\item[ sensor] Sets the sensor number to be used for reading temperature. -\item[ control] Sets the control sensor for the ITC-4. This sensor will be used -internally for regulating the ITC-4. -\item[divisor] The ITC4 does not understand floating point numbers, the ITC-503 does. -In order to make ITC4's read and write temperatures correctly floating point -values must be multiplied or divided with a magnitude of 10. This parameter -determines the appropriate value for the sensor. It is usually 10 for a sensor -with one value behind the comma or 100 for a sensor with two values after -the comma. -\item[multiplicator] The same meaning as the divisor above, but for the control sensor. -\end{description} - -\paragraph{Installing an ITC4 step by step} - - -\begin{enumerate}\item Connect the ITC temperature controller to port 6 on the Macintosh -serial port extension box. Port 6 is specially configured for dealing with -the ideosyncracies of that device. No null modem is needed. -\item Install the ITC4 into SICS with the command: \newline -evfactory new name Macintoshname 4000 7\newline -Thereby replace name with the name you want to address the ITC4 in SICS. A -good choice for a name is temperature, as such a value will be written to data files. -Please note, that SICS won't let you use that name if it already exists. For -instance if you already had a controller in there. Then the command:\newline -evfactory del name \newline -will help. Macintoshname is the name of the instrument Macintosh PC. -\item Configure the upper and lowerlimits for your controller appropriatetly. -\item Figure out which sensor you are going to use for reading temperatures. -Configure the sensor and the divisor parameter accordingly. -\item Figure out, which sensor will be used for controlling the ITC4. Set the -parameters control and multiplicator accordingly. Can be the same as the -sensor. -\item Think up an agreeable temperature tolerance for your measurement. This -tolerance value will be used 1) to figure out when the ITC4 has reached its -target position. 2) when the ITC4 will throw an error if the ITC4 fails to -keep within that tolerance. Set the tolerance parameter according to the -results of your thinking. -\item Select one of the numerous error handling strategies the control -software is able to perform. Configure the device accordingly. -\item Test your setting by trying to read the current temperature. -\item If this goes well try to drive to a temperature not to far from the -current one. -\end{enumerate} - -\paragraph{ITC-4 Trouble Shooting} - - -If the ITC-4 {\bf does not respond at all}, make sure the serial connection to -the Macintosh is working. Use standard RS-232 debugging procedures for doing -this. The not responding message may also come up as a failure to -connect -to the ITC-4 during startup. - - If error messages containing the string {\bf ?TMO} keep appearing - up followed -by signs that the command has not been understood, then increase the -timeout. The standard - timeout of 10 microseconds can be to short sometimes. - -You keep on reading {\bf wrong values} from the ITC4. Mostly off by a -factor 10. Then set the divisor correctly. Or you may need to choose a -decent sensor for that readout. - -Error messages when {\bf trying to drive the ITC4}. These are usually the -result of a badly set multiplicator parameter for the control sensor. - -The ITC4 {\bf never stops driving}. There are at least four possible -causes for this problem: -\begin{enumerate} -\item The multiplicator for the control sensor was wrong and the ITC4 has now -a set value which is different from your wishes. You should have got error -messages then as you tried to start the ITC4. -\item The software is reading back incorrect temperature values - because the sensor and -divisor parameters are badly configured. Try to read the temperature and if -it does have nothing to do with reality, set the parameters accordingly. -\item The tolerance parameter is configured so low, that the ITC4 never -manages to stay in that range. Can also be caused by inappropriate PID -parameters in the ITC4. -\item -You are reading on one sensor (may be 3) and controlling on another one (may -be 2). Then it may happen that the ITC 4 happily thinks that he has reached -the temperature because its control sensor shows the value you entered as -set value. But read sensor 3 still thinks he is far off. The solution is to -drive to a set value which is low enough to make the read sensor think it is -within the tolerance. That is the temperature value you wanted after all. -\end{enumerate} - -\subsubsection{Haake Waterbath Thermostat} - -\label{f10:haake} - -This is sort of a bucket full of water equipped with a temperature -control system. The RS-232 interface of this device can only be operated at -4800 baud max. This is why it has to be connected to the serial printer port -of the Macintosh serial port server computer. This makes the channel number to -use for initialisation a 1 always. The driver for this device has been -realised in the Tcl extension language of the SICS server. A prerequisite -for the usage of this device is that the file hakle.tcl is sourced in the -SICS initialisation file and the command inihaakearray has been published. - Installing the -Haake into SICS requires two steps: first create an array with -initialisation parameters, second install the device with evfactory. A -command procedure is supplied for the first step. Thus the initialisation -sequence becomes: -\begin{quotation} -inihaakearray name-of-array macintosh-computer name port channel\newline -evfactory new temperature tcl name-of-array\end{quotation} -An example for the SANS: -\begin{quotation} -inihaakearray eimer lnsp25.psi.ch 4000 1 \newline -evfactory new temperature tcl eimer\end{quotation} -Following this, the thermostat can be controlled with the other environment -control commands. - -The Haake Thermostat understands a single special subcommand: {\bf sensor}. -The thermostat may be equipped with an external sensor for controlling and -reading. The subcommand sensor allows to switch between the two. The exact -syntax is: -\begin{quotation} -temperature sensor val\end{quotation} -val can be either intern or extern. - -\subsubsection{Dilution Cryostat} - -\label{f10:dilu} - -This is a large ancient device for reaching very low temperatures. This -cryostat can be configured into SICS with the command: -\begin{verbatim} -EVFactory new Temp dillu computer port channel table.file -\end{verbatim} -Temp is the name of the dilution controller command in SICS, dillu is the -keyword which selects the dilution driver, computer, port and channel are -the parameters of the Macintosh-PC running the serial port server program. -table.file is the fully qualified name of a file containing a translation -table for this cryostat. The readout from the dilution controller is a -resistance. This table allows to interpolate the temperature from the -resistance measurements and back. Example: -\begin{verbatim} -evfactory new temperature dillu lnsp19.psi.ch 4000 1 dilu.tem -\end{verbatim} -installs a new dilution controller into SICS. This controller is connected -to port 1 at the Macintos-PC with the newtwork adress lnsp19.psi.ch. On this -macintosh-PC runs a serial port server program listening at TCP/IP port -4000. The name of the translation table file is dilu.tem. - -The dilution controller has no special commands, but two caveats: As of -current (October 1998) setting temperatures does not work due to problems -with the electronics. Second the dilution controller MUST be connected to -port 1 as only this port supports the 4800 maximum baud rate this device -digests. - -\subsubsection{Bruker Magnet Controller B-EC-1} - -\label{f10:bruker} - -This is the Controller for the large magnet at SANS. The controller is a -box the size of a chest of drawers. This controller can be operated in one -out of two modes: in {\bf field} mode the current for the magnet is controlled via -an external hall sensor at the magnet. In {\bf current} mode, the output current -of the device is controlled. This magnet can be configured into SICS with a -command syntax like this: -\begin{quotation} -evfactory new name bruker Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion (which will be used throughout the rest of the text) is magnet. -bruker is the keyword for selecting the bruker driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at SANS): -\begin{verbatim} -evfactory new magnet bruker lnsp25.psi.ch 4000 9 -\end{verbatim} - -creates a new command magnet for a Bruker magnet Controller connected to -serial port 9 at lnsp25. -In addition to the standard environment controller commands this magnet -controller understands the following special commands: -\begin{description} -\item[magnet polarity] Prints the current polarity setting of the controller. Possible -answers are plus, minus and busy. The latter indicates that the controller -is in the process of switching polarity after a command had been given to -switch it. -\item[magnet polarity val] sets a new polarity for the controller. Possible values for val are -{\bf minus} or {\bf plus}. The meaning is self explaining. -\item[magnet mode] Prints the current control mode of the controller. Possible -answers are {\bf field} for control via hall sensor or {\bf current} for -current control. -\item[magnet mode val] sets a new control mode for the controller. Possible values for val are -{\bf field} or {\bf current}. The meaning is explained above. -\item[magnet field] reads the magnets hall sensor independent of the control mode. -\item[magnet current] reads the magnets output current independent of the control mode. -\end{description} - -Warning: There is a gotcha with this. If you type only magnet a -value will be returned. The meaning of this value is dependent on the -selected control mode. In current mode it is a current, in field mode it is -a magnetic field. This is so in order to support SICS control logic. -You can read values at all times explicitly using magnet current or -magnet field. - -\subsubsection{The CryoFurnace.} - -\label{f10:ltc11} - -The CryoFurnace at PSI is equipped with a Neocera LTC-11 temperature -controller. This controller can control either an heater or an analag output -channel. Futhermore a choice of sensors can be selected for controlling the -device. The LTC-11 behaves like a normal SICS environment control device -plus a few additional commands. An LTC-11 can be configured into SICS with -the following command: -\begin{quotation} -evfactory new name ltc11 Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -ltc11 is the keyword for selecting the LTC-11 driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at DMC): -\begin{verbatim} -evfactory new temperature ltc11 lnsp18.psi.ch 4000 6 -\end{verbatim} - -creates a new command magnet for a LTC-11 temperature Controller connected to -serial port 6 at lnsp18. - -The additional commands understood by the LTC-11 controller are: -\begin{description} -\item[temperature sensor ] queries the current sensor used for temperature readout. -\item[temperature sensor val ] selects the sensor val for temperature readout. -\item[temperature controlanalog ] queries the sensor used for controlling the analog channel. -\item[temperature controlanalog val ] selects the sensor val for controlling the analog channel. -\item[temperature controlheat ] queries the sensor used for controlling the heater channel. -\item[temperature controlheat val ] selects the sensor val for controlling the heater channel. -\item[temperature mode] queries if the LTC-11 is in analog or heater control mode. -\end{description} - -Further notes: As the CryoFurnace is very slow and the display at the -controller becomes unusable when the temperature is read out to often, the -LTC-11 driver buffers the last temperature read for 5 seconds. Setting the -mode of the LTC-11 is possible by computer, but not yet fully understood and - therefore unusable. - -\subsubsection{The Eurotherm Temperature Controller} - -\label{f10:euro} - -At SANS there is a Eurotherm temperature controller for the sample heater. - This and probably other Eurotherm controllers can be configured into SICS -with the following command. The eurotherm needs to be connected with a - nullmodem adapter. -\begin{quotation} -evfactory new name euro Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -euro is the keyword for selecting the Eurotherm driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. {\bf WARNING:} The eurotherm needs a RS-232 port with an unusual - configuration: 7bits, even parity, 1 stop bit. Currently only the SANS - Macintosh port 13 (the last in the upper serial port connection box) is - configured like this! Thus, an example for SANS and the name temperature - looks like: -\begin{verbatim} -evfactory new temperature euro lnsp25.psi.ch 4000 13 -\end{verbatim} - -There are two further gotchas with this thing: -\begin{itemize} -\item The eurotherm needs to operate in the EI-bisynch protocoll mode. This has -to be configured manually. For details see the manual coming with the machine. -\item The weird protocoll spoken by the Eurotherm requires very special control - characters. Therefore the send functionality usually supported by a SICS - environment controller could not be implemented. -\end{itemize} - -\subsubsection{The PSI-EL755 Magnet Controller} - -\label{f10:el755} - -This is magnet controller developed by the electronics group at -PSI. It consists of a controller which interfaces to a couple of power -supplies. The magnets are then connected to the power supplies. The -magnetic field is not controlled directly but just the power output of -the power supply. Also the actual output of the power supply is NOT -read back but just the set value after ramping. This is a serious -limitation because the computer cannot recognize a faulty power supply -or magnet. The EL755 is connected to SICS with the command: -\begin{quotation} -evfactory new name el755 Mac-PC Mac-port Mac-channel index\end{quotation} - with Mac-PC, Mac-port and Mac-channel being the usual data items for - describing the location of the EL755-controller at the Macintosh - serial port server. index is special and is the number of the power - supply to which the magnet is connected. An example: -\begin{verbatim} -evfactory new maggi el755 lnsa09.psi.ch 4000 5 3 -\end{verbatim} -connects to power supply 3 at the EL755-controller connected to lnsa09 -at channel 5. The magnet is then available in the system as maggi. No -special commands are supported for the EL755. -% html: End of file: `samenv.htm' -% html: Beginning of file: `histogram.htm' - -\section{Histogram memory} - -\label{f11} - - -Histogram memories are used in order to control large area sensitive -detectors or single detectors with time binning information. -Basically each detector maps to a defined memory location. The -histogram memory wizard takes care of putting counts detected in the -detector into the proper bin in memory. Some instruments resolve energy -(neutron flight time) as -well, than there is for each detector a row of memory locations mapping to -the time bins. As usual in SICS the syntax is the name of the histogram -memory followed by qualifiers and parameters. As a placeholder for the -histogram memories name in your system, HM will be used in the following -text. - -A word or two has to be lost about the SICS handling of preset values for -histogram memories. - Two modes of operation have to be distinguished: counting until a timer has passed, -for example: count for 20 seconds. This mode is called timer mode. In the other -mode, counting is continued until a control monitor has reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - -\subsection{ Configuration} - - - -A HM has a plethora of configuration options coming with it which define -memory layout, modes of operation, handling of bin overflow and the like. -Additionally there are HM model specific parameters which are needed -internally in -order to communicate with the HM. In -most cases the HM will already have been configured at SICS server startup -time. However, there are occasion where these configuartion option need to -enquired or modified at run time. The command to enquire the current value -of a configuration option is: {\bf HM configure option}, the command to set it is: -{\bf HM configure option newvalue}. A list of common configuration options and their -meaning is given below: -\begin{description} -\item[ HistMode] HistMode describes the modes of operation of the histogram memory. -Possible values are: -\begin{itemize} -\item Transparent, Counter data will be written as is to memory. For debugging -purposes only. -\item Normal, neutrons detected at a given detector will be added to the - apropriate memory bin. -\item TOF, time of flight mode, neutrons found in a given detector will be -put added to a memory location determined by the detector and the time -stamp. -\item Stroboscopic mode. This mode serves to analyse changes in a sample due -to an varying external force, such as a magnetic field, mechanical stress -or the like. Neutrons will be stored in memory according to detector -position and phase of the external force. -\end{itemize} -\item[ OverFlowMode] This parameter determines how bin overflow is handled. This happend -when more neutrons get detected for a particular memory location then are -allowed for the number type of the histogram memory bin. Possible values -are: -\begin{itemize} -\item Ignore. Overflow will be ignored, the memory location will wrap around -and start at 0 again. -\item Ceil. The memory location will be kept at the highest posssible value -for its number type. -\item Count. As Ceil, but a list of overflowed bins will be maintained. -\end{itemize} -\item[ Rank] Rank defines the number of histograms in memory. -\item[ Length ] gives the length of an individual histogram. -\item[ BinWidth] determines the size of a single bin in histogram memory in bytes. -\item[dim0, dim1, dim2, ... dimn] define the logical dimensions of the histogram. Must be set if the - the sum command (see below) is to be used. This is a clutch necessary to - cope with the different notions of dimensions in the SINQ histogram memory - and physics. -\end{description} -For time of flight mode the time binnings can be retrieved and modified with -the following commands. Note that these commands do not follow the configure -syntax given above. Please note, that the usage of the commands for -modifying time bins is restricted to instrument managers. -\begin{description} -\item[HM timebin] Prints the currently active time binning array. -\item[HM genbin start step n] Generates a new equally spaced time binning array. Number n time bins -will be generated starting from start with a stepwidth of step. -\item[HM setbin inum value] Sometimes unequally spaced time binnings are needed. These can be -configured with this command. The time bin iNum is set to the value value. -\item[HM clearbin] Deletes the currently active time binning information. -\end{description} - -\subsection{Histogram Memory Commands} - - - -Besides the configuration commands the HM understands the following -commands: -\begin{description} -\item[HM preset] with a new value sets the preset time or monitor for counting. Without a -value prints the current value. -\item[HM exponent] with a new value sets the exponent to use for the preset time -in Monitor mode. Without a -value prints the current value. -\item[CountMode ] with a new values sets the count mode. Possible values are Timer for a -fixed counting time and Monitor for a fixed monitor count which has to be -reached before counting finishes. Without a value print the currently active -value. -\item[HM init ] after giving configuration command sthis needs to be called in order to -transfer the configuration from the host computer to the actual HM. -\item[HM count] starts counting using the currently active values for CountMode and -preset. This command does not block, i.e. in order to inhibit further -commands from the console, you have to give Success afterwards. -\item[HM InitVal val] initialises the whole histogram memory to the value val. Ususally 0 in -order to clear the HM. -\item[ HM get i iStart iEnd] retrieves the histogram number i. A value of -1 for i denotes retrieval -of the whole HM. iStart and iEnd are optional amd -allow to retrieve a subset of a histogram between iStart and iEnd. -\item[HM sum d1min d1max d2min d2max .... dnmin dnmax] calculates the sum of an area on the detector. For each dimension a - minimum and maximum boundary for summing must be given. -\end{description} - -% html: End of file: `histogram.htm' -% html: Beginning of file: `fowrite.htm' - -\section{FOCUS Data Storage} - -\label{f12} - -FOCUS writes data into portable binary NeXus files. The scheme implemented -involves opening a new file for any run and updating this file at -predefined intervalls during counting operations. All this is commonly -handled automatically by the count (cf.\ Section~\ref{f5}) -command. However, data file writing can be initiated and configured -manually from the command line through the following commands: -\begin{description} -\item[storefocus start] Write a new data file -\item[storefocus update] Updates the current data file. -\item[storefocus intervall] prints the current update intervall to use during counting. Units -is minutes. -\item[storefocus intervall newval] Sets the update intervall to newval minutes. -\item[killfile] This command will overwrite the last data file written and thus - effectively erase it. Therefore this command requires manager privilege. -\end{description} - -% html: End of file: `fowrite.htm' -% html: Beginning of file: `motor.htm' - -\section{SICS motor handling} - -\label{f13} - - - In SICS each motor is an object with a name. Motors may take commands which basically come in the form {\em 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. {\em Motorname parametername } will print the current value of the variable. {\em 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: -\begin{itemize} -\item {\bf Motorname list } gives a listing of all motor parameters. -\item {\bf Motorname reset } resets the motor parameters to default values. - This is software zero to 0.0 and software limits are reset to hardware -limits. -\item {\bf Motorname position} prints the current position of the motor. -All zero point and sign corrections are applied. -\item {\bf Motorname hardposition} prints the current position of the motor. -No corrections are applied. Should read the same as the controller box. -\item {\bf Motorname interest} initiates automatic printing of any position -change of the motor. This command is mainly interesting for implementors of -status display clients. -\end{itemize} - Please note that the actual driving of the motor is done via the drive (cf.\ Section~\ref{f2}) command. - - -\subsection{The motor parameters} - - -\begin{itemize} -\item {\bf HardLowerLim } 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. -\item {\bf HardUpperLim } 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. -\item {\bf SoftLowerLim } is the software lower limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftUpperLim } is the software upper limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftZero } defines a software zero point for the motor. All further movements will be in respect to this zeropoint. -\item {\bf Fixed } can be greater then 0 for the motor being fixed and less then -or equal to zero for the motor being movable. -\item {\bf InterruptMode } defines the interrupt to issue when the motor fails. Some motors are so critical for the operation of the instrument that all operations are to be stopped when there is a problem. Other 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. -\item {\bf Precision } denotes the precision to expect from the motor in positioning. Can usually only be set by managers. -\item {\bf AccessCode } 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. -\item {\bf Sign } reverses 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. -\end{itemize} - - -% html: End of file: `motor.htm' -% html: Beginning of file: `counter.htm' - -\section{SICS counter handling} - -\label{f14} - - -A counter in SICS is a controller which operates single neutron -counting tubes and monitors. -A counter can operate in one out of two modes: counting until a timer has - passed, -for example: count for 20 seconds. Counting in this context means that the noutrons coming in during these 20 seconds are summed together. This mode is called timer mode. In the other -mode, counting is continued until a specified neutron monitor has - reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - Again, in SICS the counter is an object which understands a set of -commands: -\begin{itemize} -\item {\bf countername SetPreset val } sets the counting preset to val. -\item {\bf countername GetPreset } prints the current preset value. -\item {\bf countername preset val} With a parameter sets the preset, without inquires the preset value. This is a duplicate of getpreset and setpreset which has been provided for consistency with other commands. -\item {\bf countername SetExponent val } sets the exponent for the counting -preset in monitor mode to val. -\item {\bf countername GetExponent } prints the current exponent used -in monitor mode. -\item {\bf countername SetMode val } sets the counting mode to val. Possible values are Timer for timer mode operation and Monitor for waiting for a monitor to reach a certain value. -\item {\bf countername GetMode } prints the current mode. -\item {\bf countername mode val} With a parameter sets the mode, -without inquires the mode value. This is a duplicate of getmode and -setmode which has been provided for consistency with other -commands. Possible values for val are either monitor or timer. -\item {\bf countername SetExponent val } sets the exponent for the counting -preset in monitor mode to val. -\item {\bf countername GetCounts } prints the counts gathered in the last run. -\item {\bf countername GetMonitor n } prints the counts gathered in the monitor number n in the last run. -\item {\bf countername Count preset } starts counting in the current mode and the the preset preset. -\item {\bf countername status } prints a message containing the preset and -the current monitor or time value. Can be used to monitor the progress of -the counting operation. -\item {\bf countername gettime } Retrieves the actual time the counter -counted for. This excludes time where there was no beam or counting was -paused. -\item {\bf countername getthreshold m} retrieves the value of the threshold - set for the monitor number m. -\item {\bf countername setthreshold m val} sets the threshold for monitor m - to val. WARNING: this also makes monitor m the active monitor for evaluating - the threshold. Though the EL7373 counterbox does not allow to select the - monitor to use as control monitor in monitor mode, it allows to choose - the monitor used for pausing the count when the count rate is below the - threshold (Who on earth designed this?) -\item {\bf countername send arg1 arg2 arg3 ...} sends everything behind -send to the counter controller and returns the reply of the counter -box. The command set to use after send is the command set documented -for the counter box elsewhere. Through this feature it is possible to -diretclly configure certain variables of the counter controller from -within SICS. -\end{itemize} - -% html: End of file: `counter.htm' -% html: Beginning of file: `ctrl.htm' - -\section{Serial Port Direct Access} - -\label{f15} - - At SINQ serial devices are connected to a Macintosh computer. This Mac runs - a serial port server which allows to read and write data through TCP/IP - sockets to a serial port connected to the Mac. This document describes a simple - interface for communicating with such serial devices. - -\subsection{Invocation} - - - - The interface to a serial device connected to a Mac is initialised with the - following command given at the Tcl prompt:\newline -{\em Controller name computer port channel}\newline -This command opens a connection to the serial port on the Mac and - installs a new command in order to interact with it. The parameters: -\begin{itemize} -\item name: is the name of the new command to generate for the connection in Tcl. -\item computer: is the computer name of the Macintosh. -\item port: is the TCP/IP port number at which the Macintosh - serial port server is is listening. Usually this is 4000. -\item channel: is the number of the RS-232 port to connect to. -\end{itemize} - - -\subsection{Usage} - - - - Once the connection has been initialised name is available as a new command - in Tcl. Let us assume, MC as the name for the purpose of this description. - MC then can be used as follows:\newline - {\em MC -tmo value}\newline - Configures the timeout for the connection to value. - Value is in microseconds.\newline - {\em MC arg1 arg2 ..... argn}\newline - Everything after MC is written to the serial port. The reply received from - the port is returned. - - All these commands can return errors. Mostly these refer to the wrong device - being specified on initialisation. The others are network problems. -% html: End of file: `ctrl.htm' -% html: Beginning of file: `system.htm' - -\subsection{System Commands} - -\label{f16} - -{\bf Sics\_Exitus }. A single word commands which shuts the server down. Only Managers may use this command. - - {\bf wait time } waits time seconds before the next command is executed. This does not stop other clients from issuing commands. - - {\bf ResetServer } resets the server after an interrupt. - - {\bf Dir } a single word command which lists all objects available in the SICS system in its current configuration. - - {\bf status } A single word command which makes SICS print its current -status. Possible return values can be: -Eager to execute commands, Scanning, Counting, Running, Halted. Note that if a command is executing which takes some time to complete - the server will return an ERROR: Busy message when further commands are issued. - -{\bf status interest} initiates automatic printing of any status change in the -server. This command is primarily of interest for status display client -implementors. - -{\bf backup file} saves the current values of SICS variables and selected - motor and device parameters to the disk file specified as - parameter. If no file parameter is given the data is written to the - system default status backup file. - The format - of the file is a list of SICS commands to set all these parameters - again. The file is written on the instrument computer relative to the - path of the SICS server. This is usually /home/INSTRUMENT/bin. - -{\bf restore file} reads a file produced by the backup command described -above and restores SICS to the state it was in when the status was saved with - backup. If no file argument is given the system default file gets - read. -% html: End of file: `system.htm' -% html: Beginning of file: `topscan.htm' - -\section{The Scan Command } - -\label{f17} - - -An important concept in neutron scattering instrument control is a -{\tt{}"{}}scan{\tt{}"{}}. For a simple scan a range of instrument positions is divided -into equidistant steps. The instrument then proceeds to drive to each -of these points and collects data at each of them. - -The general idea of the scan object for TOPSI is, that you configure the -scan by typing commands at the command line. Once, the configuration is -finished the requested scan is started. A data file will be written -automatically to the default location. The scan command can not only scan -over motors but also about some variables which relate to motors. For -instance lamda for the wavelength. Scan can scan over more then one variable. -The syntax of the scan command in some detail: -\begin{description} -\item[scan clear] Clears current scan parameters. -\item[scan list] lists current scan parameters. -\item[ scan var name start step] Defines a variable (motor) to be scanned. The name of the variable, a - start value and a stpe width need to be given. More then one scan variable -can be specified. -\item[ scan modvar name start step] Modifies the scan parameters for scan variable name to the new values -given. -\item[scan getvars] Returns a list of currently active scan variables terminated with the - string -END-. -\item[ scan NP num ] Sets the number of scan points. -\item[ scan Preset val] Sets the Preset value for the scan. Without a parameter, inquires the -current value. -\item[ scan Mode val] Sets the count mode for the scan. Without a parameter, inquires the -current value. Possible values are Timer or Monitor. -\item[ scan run ] Executes the scan. -\item[scan cinterest] This call enables automatic printing of scan counts to your connection -when new values arise. This command is primariliy of interest for status display -clients. -\item[scan pinterest] This function makes the scan command send a notification (the string -ScanVarChange) to you whenever the scan variables get modified. This command -is primarily of interest for status display clients. -\end{description} - -\subsection{ Center Scan } - - - -Center scan is a convenience command which starts a scan around a specified -center value. This mostly used for centering purposes. The syntax is like this: -\begin{quotation} -cscan var center delta np preset\end{quotation} -All parameters must be specified. The parameters and their meanings: -\begin{itemize} -\item {\bf var} is the variable which is to be center scanned. -Only one can be specified. -\item {\bf center} is the value to use as center of the scan. -\item {\bf delta} is the step width to use for the scan. -\item {\bf np} is the number of points to scan in each direction. -\item {\bf preset} is the preset to use for the counter. As the counter mode, -the mode currently configured active in the scan object is used. -\end{itemize} - -\subsection{ Simple Scan } - - - -Simple scan is a convenience command which starts a scan for one to several -variables with a simplified syntax. The syntax is like this: -\begin{quotation} -sscan var1 start end var2 start end ... np preset\end{quotation} -All parameters must be specified. The parameters and their meanings: -\begin{itemize} -\item {\bf var1 start end} This is how the variables to scan are specified. For -each variable scanned the name of the -variable, the start value and the end value of the scan must be -given. More then one triplet -can be given in order to allow for several scan variables. -\item {\bf np} is the number of points to scan. -\item {\bf preset} is the preset to use for the counter. As the counter mode, -the mode currently configured active in the scan object is used. -\end{itemize} - -\subsection{Peak And Center} - - - -These two commands are related to the scan command insofar as they act upon -the results of the last scan still in memory. The command {\bf peak} prints -the position, FWHM and maximum value of the peak in the last scan. The - command {\bf center} drives the first scan variable to the peak center of the - last scan. Both peak and center use a rather simple but effective method for - locating peaks. The prerequisite is that the peak is approximatly - gaussian shaped. The - algorithm first locates the peak maximum. Then it goes to the left and - right of the maximum and tries to find the points of half maximum peak height. - The two points are interpolated from the data and the peak position - calculated as the middle point between the two halfheight points. -% html: End of file: `topscan.htm' -% html: Beginning of file: `config.htm' - -\subsection{Configuration Commands} - -\label{f18} - - SICS has a command for changing the user rights of the current client server connection, control the amount of output a client receives and to specify additional logfiles where output will be placed. All this is accessed through the following commands: - - The SICS server logs all its activities to a logfile, regardless of what the user requested. This logfile is mainly intended to help in server debugging. However, clients may register an interest in certain server events and can have them displayed. This facility is accessed via the {\bf GetLog } command. It needs to be stressed that this log receives messages from {\bf all } active clients. GetLog understands the following messages: -\begin{itemize} -\item {\bf GetLog All } achieves that all output to the server logfile is also written to the client which issued this command. -\item {\bf GetLog Kill } stops all logging output to the client. -\item {\bf GetLog OutCode } request that only certain events will be logged to the client issuing this command. Enables only the level specified. Multiple calls are possible. -\end{itemize} - Possible values for OutCode in the last option are: -\begin{itemize} -\item {\bf Internal } internal errors such as memory errors etc. -\item {\bf Command } all commands issued from any client to the server. -\item {\bf HWError } all errors generated by instrument hardware. The SICS server tries hard to fix HW errors in order to achieve stable operations and may not generate an error message if it was able to fix the problem. This option may be very helpful when tracking dodgy devices. -\item {\bf InError } All input errors found on any clients input. -\item {\bf Error } All error messages generated by all clients. -\item {\bf Status } some commands send status messages to the client invoking the command in order to monitor the state of a scan. -\item {\bf Value } Some commands return requested values to a user. These messages have an output code of Value. -\end{itemize} - -The {\bf config } command configures various aspects of the current client server connection. Basically three things can be manipulated: The connections output class, the user rights associated with it, and output files. - -\begin{itemize} \item The command {\bf config OutCode val } sets the output code for the connection. By default all output is sent to the client. But a graphical user interface client might want to restrict message to only those delivering requested values and error messages and suppressing anything else. In order to achieve this, this command is provided. Possible values Values for val are Internal,Command, HWError,InError,Status, Error, Value. This list is hierarchical. For example specifying InError for val lets the client receive all messages tagged InError, Status, Error and Value, but not HWError, Command and Internal messages. -\item Each connection between a client and the SICS server has user rights assocociated with it. These user rights can be configured at runtime with the command {\bf config Rights Username Password }. If a matching entry can be found in the servers password database new rights will be set. -\item Scientists are not content with having output on the screen. In order to -check results a log of all output may be required. The command {\bf config -File name } makes all output to the client to be written to the file -specified by name as well. The file must be a file accessible to the server, -i.e. reside on the same machine as the server. Up to 10 logfiles can be -specified. Note, that a directly connected line printer is only a special -filename in unix. -\item {\bf config close num} closes the log file denoted by num again. -\item {\bf config list} lists the currently active values for outcode and user -rights. -\end{itemize} - - -% html: End of file: `config.htm' -% html: Beginning of file: `trouble.htm' - -\section{SICS Trouble Shooting } - -\label{f19} - - -There is no such thing as bug free software. There are always bugs, nasty -behaviour etc. This document shall help to solve these problems. The usual -symptom will be that a client cannot connect to the server or the server is -not responding. - -An essential prerequisite of SICS is that the server is 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: -\begin{verbatim} -startsics -\end{verbatim} -at the command prompt. startsics actually starts two programs: one is -the replicator application which is responsible for the automatic -copying of data files to the laboratory server. The other is the SICS -server. Both programs are started by means of a shell script called -{\bf keepalive}. keepalive is basically an endless loop which calls -the program again and again and thus ensures that the program will -never stop running. - - 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. - -\subsection{Stopping SICS} - - - -All SICS processes can be stopped through the command: -\begin{verbatim} -killsics -\end{verbatim} -given at the unix command line. You must be the instrument user - (for example DMC) on the instrument computer for this to work properly. - -\subsection{Finding the SICS server} - - - -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: -\begin{verbatim} -/home/DMC> ps -A -\end{verbatim} -Note the capital A given as parameter. The reward will be listing like this: -\begin{verbatim} - 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 -\end{verbatim} -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 ?? } an entry for the SICS server. In this example the server -is running. If the server is down, no such entry would be present. - -\subsection{ Killing a hanging SICS server } - - - -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} 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}. Please note, that this number will -always be different. The command to force the server to stop is: -\begin{verbatim} -/home/DMC> kill -9 31912 -\end{verbatim} -Note, the second parameter is the number found with {\tt ps -A}. 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. - -\subsection{ Shutting The SICS Server Down Completely} - - - -This is done for you by the killsics shell script. Just type -\begin{verbatim} -killsics -\end{verbatim} - 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 {\bf keepalive SICServer }. Kill that one as -described above, then kill the SICServer. For restarting SICS after this, -use the startsics command. - -\subsection{Restart Everything} - - - -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. -\begin{enumerate} -\item Reboot the Macintosh PC by switching it off at the silver button on the -left. Press deep and a few seconds to achieve an effect. The LED right to the -button should be off, before you press again to boot the Macintosh. -\item 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. -\item Wait 5 minutes. The Macintosh may take that time to come up again. -\item Restart the SICServer. Watch for any messages about things not being -connected or configured. -\item Restart and reconnect the client programs. -\end{enumerate} -If this fails (even after a second) time there may be a network problem which -can not be resolved by simple means. - -\subsection{Getting New SICS Software} - - - -Sometimes you might want to be sure that you have the latest SICS software. -This is how to get it: -\begin{enumerate} -\item Login to the instrument account. -\item If you are no there type cd to get into the home directory. -\item Type {\bf killsics} at the unix prompt in order to stop the SICS server. -\item Type {\bf sicsinstall exe} at the unix prompt for copying new - SICS software from the general distribution area. -\item Type {\bf startsics} to restart the SICS software. -\end{enumerate} - -\subsection{Hot Fixes} - - - -When there is trouble with SICS you may be asked by one of the SICS - programmers to copy the most recent development reason of the SICS server - to your machine. This is done as follows: -\begin{enumerate} -\item Login to the instrument account. -\item cd into the bin directory, for example: /home/DMC/bin. -\item Type {\bf killsics} at the unix prompt in order to stop the SICS server. -\item Type {\bf cp /data/koenneck/src/sics/SICServer .} at the unix prompt. -\item Type {\bf startsics} to restart the SICS software. -\end{enumerate} -{\bf !!!!!! 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!} - -\subsection{ HELP debugging!!!!} - - - -The SICS server hanging or crashing should not happen. In order to sort such -problems out it is very helpful if any available debugging information is -saved and presented to the programmers. Information available are the log -files as written continously by the SICS server and posssible core files -lying around. They have just this name: core. In order to save them create a -new directory (for example dump2077) and copy the stuff in there. This looks -like: -\begin{verbatim} -/home/DMC> mkdir dump2077 -/home/DMC> cp log/*.log dump2077 -/home/DMC> cp core dump2077 -\end{verbatim} -The {\tt /home/DMC> } is just the command prompt. Please note, that core -files are only available after crashes of the server. These few commands -will help to analyse the cause of the problem and to eventually resolve it. -% html: End of file: `trouble.htm' -\end{document} diff --git a/doc/user/sansman b/doc/user/sansman index c078344c..689b57f0 100644 --- a/doc/user/sansman +++ b/doc/user/sansman @@ -16,7 +16,7 @@ %html -s report \begin{center} \begin{huge} -SANS--User Manual \\ +SANS--Reference Manual \\ \end{huge} Version 0.1, 10.6.1997\\ Dr. Mark K\"onnecke \\ @@ -60,4 +60,4 @@ programmers reference. %html sanslist.htm 1 %html saco.htm 1 -\end{document} \ No newline at end of file +\end{document} diff --git a/doc/user/sansman.tex b/doc/user/sansman.tex deleted file mode 100644 index 5312ce6d..00000000 --- a/doc/user/sansman.tex +++ /dev/null @@ -1,1784 +0,0 @@ -\documentclass[12pt,a4paper]{report} -%%\usepackage[dvips]{graphics} -\usepackage{epsf} -\setlength{\textheight}{24cm} -\setlength{\textwidth}{16cm} -\setlength{\headheight}{0cm} -\setlength{\headsep}{0cm} -\setlength{\topmargin}{0cm} -\setlength{\oddsidemargin}{0cm} -\setlength{\evensidemargin}{0cm} -\setlength{\hoffset}{0cm} -\setlength{\marginparwidth}{0cm} - -\begin{document} -\begin{center} -\begin{huge} -SANS--User Manual \\ -\end{huge} -Version 0.1, 10.6.1997\\ -Dr. Mark K\"onnecke \\ -Labor f\"ur Neutronenstreuung\\ -Paul Scherrer Institut\\ -CH--5232 Villigen--PSI\\ -Switzerland\\ -\end{center} -\abstract{ -This is the users manual for the small angle scattering spectrometer SANS -situated at SINQ, PSI, Switzerland. This instrument is operated through the -SINQ instrument control software SICS. This is a client server system, with -a server implementing the control operations and clients implementing the -user interface. This manual describes the commands understood by SANS. -Further information is available in the SICS's manager manual and the SICS -programmers reference. -} -\clearpage - -% html: Beginning of file: `sicsinvoc.htm' - -\chapter{SICS Invocation} - -\label{f0} - -SICS is a client server system. This means there are at least two programs -necessary to run the experiment. The first -is the -SICServer which does the actual instrument control work. A user rarely needs -to bother about this server program as it is meant to run all the time. -See instructions below if things go wrong. - -Then there are one to many client programs which interact with the -instrument control server. These client programs implement the status -displays and a command line application which allows to influence the -course of the experiment. Graphical User Interfaces may be added at a -later time. -The user has only to deal with -these SICS client programs. SICS Clients and the SICServer communicate -with each other through TCP/IP sockets. - -Currently five SICS clients are available: -\begin{itemize} -\item A command line control client which allows to control the measurement. -\item A status display for DMC. -\item A status display for TOPSI. -\item A status display for SANS. -\item A status display for FOCUS. -\item A SICS variable watcher. -\end{itemize} - - -\section{Steps necessary for logging in to SICS} - - -The following actions have to be taken in order to interact with the -SICS server through a client: -\begin{itemize} -\item Start the client application. -\item Connect the client to a SICS server. -\item In case of command line clients: authorize yourself as -privileged SICS user. -\end{itemize} - -\section{Starting SICS client applications } - - - -These programs can be started on a DigitalUnix system by issuing the -following commands at the command prompt: -\begin{description} -\item[sics \&] for the control client. -\item[powderstatus \&] for the DMC status display client. -\item[topsistatus \&] for the TOPSI status display. -\item[sansstatus \&] for the SANS status display. -\item[focustatus] for the FOCUS status display. -\item[varwatch \&] for the variable watcher. -\end{description} -On a PC you may find icons for starting the different programs on the -desktop. -Each of these clients has usage instructions online which can be displayed -through the help/about menu entry. - -\section{Connecting} - - - -After startup any SICS client is not connected to a SICS server and thus not -active. A connection is established through the connect menu of the client. - -\section{Authorization} - - - -SICS is a multi user instrument control system. In order to prevent -malicious manipulations of the instrument SICS supports a hierarchy of user -rights. In order to run an experiment you need at least user level privilege. -In order to achieve this privilege you have to invoke the User Parameter/Set -Rights dialog. There you have to enter the apropriate username and password -kindly provided by your instrument scientist. - -\section{Restarting the Server} - - - -The SICS server should be running all the time. It is only down if something -went wrong. You can check for the presence of the SICS server by loging in -to the instrument computer and typing {\bf CheckSICS} at the command -prompt. The output will tell you what is happening. If you need to restart -the SICS server log in as the instrument user at the instrument computer and -invoke the apropriate command to start the server. These are: -\begin{description} -\item[DMC] Computer = lnsa05,User = DMC -\item[TOPSI] Computer = lnsa03,User = TOPSI -\item[SANS] Computer = lnsa07,User = SANS -\item[TRICS] Computer = lnsa12, User = TRICS -\item[HRPT] Computer = lnsa11, User = HRPT -\item[FOCUS] Computer = lnsa13, User = FOCUS -\end{description} -For starting the SICS server type {\bf startsics}. This is a shell script -which will starts all necessary server programs. This script works only on -the instrument computer and in the appropriate instrument account. - - If all this does not help look under trouble shooting -SICS (cf.\ Section~\ref{f1}). -% html: End of file: `sicsinvoc.htm' -% html: Beginning of file: `general.htm' - -\chapter{General SICS commands} - -\label{f2} - - - This section describes general SICS concepts and SICS commands available to all instruments. - -\section{Chapter Overview} - - - -\begin{itemize}\item This chapter starts with an overview over some basic (cf.\ Section~\ref{f3}) SICS concepts. -\item Than there are system (cf.\ Section~\ref{f4}) commands for closing the server, requesting status information etc. -\item The Token command (cf.\ Section~\ref{f5}) for managing control access to -the SICS server. -\item A few commands permit to change (cf.\ Section~\ref{f6}) user rights, set output files and the like. -\item SICS has a built in macro (cf.\ Section~\ref{f7}) facility which is accessible through a few commands. -\item Than there is the famous (cf.\ Section~\ref{f8}) LNS-R\"unbuffer system. -\item Motors and parameters need to be drive (cf.\ Section~\ref{f9})n. -\item Logging of client output to a file can be performed with the LogBook (cf.\ Section~\ref{f10}) command and the commandlog (cf.\ Section~\ref{f11}). -\item SICS has a facility to optimise (cf.\ Section~\ref{f12}) a peak with respect to several -parameters. -\end{itemize} - -% html: End of file: `general.htm' -% html: Beginning of file: `basic.htm' - -\section{Basic SICS concepts} - -\label{f3} - - -\subsection{General structure} - - - - SICS is a client server system. The application the user sees is usually some form of client. A client has two tasks: the first is to collect user input and send it to the SICS server who will execute the command. The clients second task is to listen to the the server messages and display them in a readable format. This aoproach has two advantages: clients can reside on machines across the whole network thus enabling remote control from everywhere in the world. The second advantage is that new clients (such as graphical user interface clients) can be written in any feasible language without changes to the server. - -\subsection{SICS Command Syntax } - - - - SICS is an object oriented system. This is reflected in the command syntax. SICS objects can be devices such as motors or counters, variables such as wavelength or Title and measurement procedures. Communication with these objects happens by sending messages to the target object. This is very simply done by typing something like: object message par1 par2 .. parn. For example, if we have a motor called A1:\begin{verbatim} - A1 list -\end{verbatim} - will print a parameter listing for the motor A1. In this example no parameters were needed. There exist a number of one-word commands as well. For -compatability reasons some commands have a form which resembles a function call such as:\begin{verbatim} - drive a1 26.54 -\end{verbatim} - This will drive motor a1 to 26.54. All commands are -ASCII-strings and usually in english. SICS is in general CASE INSENSITIVE. -However, this does not hold for parameters you have to specify. On a unix -system for instance file names are case sensitive and that had to be -preserved. Commands defined in the scripting language are lower case by -convention. - -\subsection{Authorisation} - - - - A client server system is potentially open to unauthorised hackers which might mess up the instrument and your valuable measurements. A known problem in instrument control is that less knowledgeable user accidentally change instrument adjustments which should better be left fixed. In order to solve these two problems SICS supports authorisation on a very fine level. As a user you have to specify a username and password in order to able to access SICS. Some clients already do this for you automatically. SICS support four levels of access to an instrument: -\begin{itemize} -\item {\bf Spy } may look at everything, request any value, but may not actually change anything. No damage potential here. -\item {\bf User } is privileged to perform a certain amount of operations necessary to run the instrument. -\item {\bf Manager } has the permission to mess with almost everything. A very dangerous person. -\item {\bf Internal } is not accessible to the outside world and is used to circumvent protection for internal uses. However some parameters are considered to be so critical that they cannot be changed during the runtime of the SICS-server, not even by Managers. -\end{itemize} - All this is stated here in order to explain the common error message: You are not authorised to do that and that or something along these lines. - -\subsection{SICS variables} - - - - Most of the parameters SICS uses are hidden in the objects to which they belong. But some are separate objects of their own right and are accessible at top level. For instance things like Title or wavelength. They share a common syntax for changing and requesting their values. This is very simple: The command {\em objectname } will return the value, the command {\em objectname newvalue } will change the variable. But only if the authorisation codes match. - - -\subsection{The SICS Command Line Client} - - -The most common client for controlling SICS is the {\bf SICS command line -client}. -This application can be started by typing the command: -\begin{verbatim} -sics & -\end{verbatim} -at the Unix prompt. Before this program is ready to collaborate with you you -have to connect it to an instrument using the options in the connect -pulldown menu. The screen is roughly divided in three areas: The top area -shows all input to and output from the server. The middle area shows the -command history. At the lower end is a text entry field which allows to type -commands to the SICS server. For more information about this client consult -the online help of this application. -% html: End of file: `basic.htm' -% html: Beginning of file: `system.htm' - -\section{System Commands} - -\label{f4} - -{\bf Sics\_Exitus }. A single word commands which shuts the server down. Only Managers may use this command. - - {\bf wait time } waits time seconds before the next command is executed. This does not stop other clients from issuing commands. - - {\bf ResetServer } resets the server after an interrupt. - - {\bf Dir } a single word command which lists all objects available in the SICS system in its current configuration. - - {\bf status } A single word command which makes SICS print its current -status. Possible return values can be: -Eager to execute commands, Scanning, Counting, Running, Halted. Note that if a command is executing which takes some time to complete - the server will return an ERROR: Busy message when further commands are issued. - -{\bf status interest} initiates automatic printing of any status change in the -server. This command is primarily of interest for status display client -implementors. - -{\bf backup file} saves the current values of SICS variables and selected - motor and device parameters to the disk file specified as parameter. The - path to this files is relative to the SICS server directory. The format - of the file is a list of SICS commands to set all these parameters again. - -{\bf restore file} reads a file produced by the backup command described -above and restores SICS to the state it was in when the status was saved with - backup. -% html: End of file: `system.htm' -% html: Beginning of file: `config.htm' - -\section{Configuration Commands} - -\label{f6} - - SICS allows to change the user rights of the current client server connection, control the amount of output a client receives and to specify additional logfiles where output will be placed. All this is accessed through the following commands: - - The SICS server logs all its activities to a logfile, regardless of what the user requested. This logfile is mainly intended to help in server debugging. However, clients may register an interest in certain server events and can have them displayed. This facility is accessed via the {\bf GetLog } command. It needs to be stressed that this log receives messages from {\bf all } active clients. GetLog understands the following messages: -\begin{itemize} -\item {\bf GetLog All } achieves that all output to the server logfile is also written to the client which issued this command. -\item {\bf GetLog Kill } stops all logging output to the client. -\item {\bf GetLog OutCode } request that only certain events will be logged to the client issuing this command. Enables only the level specified. Multiple calls are possible. -\end{itemize} - Possible values for OutCode in the last option are: -\begin{itemize} -\item {\bf Internal } internal errors such as memory errors etc. -\item {\bf Command } all commands issued from any client to the server. -\item {\bf HWError } all errors generated by instrument hardware. The SICS server tries hard to fix HW errors in order to achieve stable operations and may not generate an error message if it was able to fix the problem. This option may be very helpful when tracking dodgy devices. -\item {\bf InError } All input errors found on any clients input. -\item {\bf Error } All error messages generated by all clients. -\item {\bf Status } some commands send status messages to the client invoking the command in order to monitor the state of a scan. -\item {\bf Value } Some commands return requested values to a user. These messages have an output code of Value. -\end{itemize} - -{\bf config } allows to configure various aspects of the current client server connection. Basically three things can be manipulated: The connections output class, the user rights associated with it, and output files. - -\begin{itemize} \item The command {\bf config OutCode val } sets the output code for the connection. By default all output is sent to the client. But a graphical user interface client might want to restrict message to only those delivering requested values and error messages and suppressing anything else. In order to achieve this, this command is provided. Possible values Values for val are Internal,Command, HWError,InError,Status, Error, Value. This list is hierarchical. For example specifying InError for val lets the client receive all messages tagged InError, Status, Error and Value, but not HWError, Command and Internal messages. -\item Each connection between a client and the SICS server has user rights assocociated with it. These user rights can be configured at runtime with the command {\bf config Rights Username Password }. If a matching entry can be found in the servers password database new rights will be set. -\item Scientists are not content with having output on the screen. In order to -check results a log of all output may be required. The command {\bf config -File name } makes all output to the client to be written to the file -specified by name as well. The file must be a file accessible to the server, -i.e. reside on the same machine as the server. Up to 10 logfiles can be -specified. Note, that a directly connected line printer is only a special -filename in unix. -\item {\bf config close num} closes the log file denoted by num again. -\item {\bf config list} lists the currently active values for outcode and user -rights. -\end{itemize} - - -% html: End of file: `config.htm' -% html: Beginning of file: `macro.htm' - -\section{Macro Commands} - -\label{f7} - - 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 Tool Command Language (TCL). Tcl has control constructs, variables of its own, loop constructs, associative arrays and procedures. Tcl is well documented by several books and online tutorials, therefore no details on Tcl will be given here. All SICS commands are available in the macro language. Some potentially harmful Tcl commands have been deleted from the standard Tcl interpreter. These are: exec, source, puts, vwait, exit,gets and socket. The following commands allow access to the macro facility: - - {\bf FileEval name } tries to open the file name and executes the script in this file. Please note that the server is configured via such a file. - - {\bf ClientPut sometext1 ... } writes everything after ClientPut to the client which started the script. Useful for output to a client from macro scripts. - -{\bf SICSType object } allows to query the type of the object specified by object. Possible return values are -\begin{itemize} -\item {\bf DRIV } if the object is a SICS drivable object such as a motor -\item {\bf COUNT } if the object is some form of a counter. -\item {\bf COM } if the object is a SICS command. -\item {\bf NUM } if the object is a number. -\item {\bf TEXT } if object is something meaningless to SICS. -\end{itemize} - - {\bf SICSbounds var newval } checks if the new value newval lies within the limits for varaible var. Returns an error or OK depending on the result of the test. - - {\bf SICSStatus var } SICS devices such as counters or motor may be started and left running while the program is free to do something else. This command allows to enquire the status of such a running device. Return values are internal SICS integer codes. This command is only of use for SICS programmers. - -{\bf SetStatus newval } allows to set the SICS status to one of: Eager, UserWait, Count, NoBeam, Driving, Running, Scanning, Batch Hatl or Dead. This command is only available in macros. - - {\bf SetInt newval, GetInt } allow for the manipulation of interrupts from macro scripts. Not recommended! Possible return values or new values are: continue, abortop, abortscan, abortbatch, halt, free, end. This command is only permitted in macros. Should only be used by SICS programmers. -% html: End of file: `macro.htm' -% html: Beginning of file: `buffer.htm' - -\section{R\"unbuffer Commands} - -\label{f8} - - LNS scientists have got used to using R\"unbuffers for instrument control. A R\"unbuffer is an array of SICS commands which typically represent a measurement. This R\"unbuffer can be edited at run time. This is very similar to a macro. In contrast to a macro only SICS commands are allowed in R\"unbuffers. When done with editing the R\"unbuffer it can be entered in a R\"unlist. This is a stack of R\"unbuffers which get executed one by one. While this is happening it is possible (from another client) to modify the R\"unlist and edit and add additional R\"unbuffer on top of the stack. This allows for almost infinite measurement and gives more control than a static batch file. In order to cater for this scheme three commands have been defined: - - The {\bf Buf } object is responsible for creating and deleting R\"unbuffers. The syntax is: -\begin{itemize} -\item {\bf Buf new name } creates a new empty R\"unbuffer with the name name. name will be installed as a SICS object afterwards. -\item {\bf Buf copy name1 name2 } copies R\"unbuffer name1 to buffer name2. -\item {\bf Buf del name } deletes the R\"unbuffer name. -\end{itemize} - - After creation, the R\"unbuffer is accessible by his name. It than understands the commands: -\begin{itemize} -\item {\bf NAME append what shall we do with a drunken sailor } will add all text after append as a new line at the end of the R\"unbuffer. -\item {\bf NAME print } will list the contents of the R\"unbuffer. -\item {\bf NAME del iLine } will delete line number iLine from the R\"unbuffer. -\item {\bf NAME ins iLine BimBamBim } inserts a new line {\bf after } line iLine into the R\"unbuffer. The line will consist of everything given after the iLine. -\item {\bf NAME subst pattern newval } replaces all occurences of pattern in the R\"unbuffer by the text specified as newval. Currently this feature allows only exact match but may be expanded to Unix style regexp or shell like globbing. -\item {\bf NAME save filename } saves the contents of the R\"unbuffer into file filename. -\item {\bf NAME load filename } loads the R\"unbuffer with the data in file filename. -\item {\bf NAME run } executes the R\"unbuffer. -\end{itemize} - - The R\"unlist is accessible as object {\bf stack }. Only one R\"unlist per server is permitted. The syntax: -\begin{itemize} -\item {\bf stack add name } adds R\"unbuffer name to the top of the stack. -\item {\bf stack list } lists the current R\"unlist. -\item {\bf stack del iLine } deletes the R\"unbuffer iLine from the R\"unlist. -\item {\bf stack ins iLine name } inserts R\"unbuffer name after R\"unbuffer number iLine into the R\"unlist. -\item {\bf stack run } executes the R\"unlist and returns when all R\"unbuffers are done. -\item {\bf stack batch } executes the R\"unlist but does not return when done but waits for further R\"unbuffers to be added to the list. This feature allows a sort of background process in the server. -\end{itemize} - -% html: End of file: `buffer.htm' -% html: Beginning of file: `drive.htm' - -\section{Drive commands} - -\label{f9} - - Many objects in SICS are {\bf 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 an energy. This class of objects can be operated by the {\bf drive, run, Success } family of commands. These commands cater for blocking and non-blocking modes of operation. - - {\bf run var newval var newval ... } 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 perhaps a slow device is running into position. - - {\bf Success } waits and blocks the command connection until all pending operations have finished (or an interrupt occured). - - {\bf drive var newval var newval ... } can be called with one to n pairs of object 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. -% html: End of file: `drive.htm' -% html: Beginning of file: `logbook.htm' - -\subsection{LogBook command} - -\label{f10} - -Some users wish like to have all the input typed to SICS and all responses -collected in a file for further review. This is implemented via the LogBook -command. LogBook understands the following syntax: -\begin{description} -\item[ LogBook] alone prints the name of the current logfile and the status of event -logging. -\item[ LogBook file filename] This command sets the filename to which output will be printed. -Please note that this new filename will only be in effect after restarting -logging. -\item[ LogBook on] This command turns loggin on. All commands and all answers will be -written to the file defined with the command described above. Please note, -that this command will overwrite an existing file with the same name. -\item[ LogBook off] This command closes the logfile and ends logging. -\end{description} - -% html: End of file: `logbook.htm' -% html: Beginning of file: `commandlog.htm' - -\subsection{The Commandlog} - -\label{f11} - -The commandlog is a file where all communication with clients -having user or manager privilege is logged. This log allows to retrace each -step of an experiment. This log is usually switched off and must be -configured by the instrument manager. There exists a special command, -commandlog, which allows to control this log file. -\begin{description} -\item[commandlog new filename] starts a new commandlog writing to filename. Any prior files will be -closed. The log file can be found -in the directory specified by the ServerOption LogFileDir. Usually this is -the log directory. -\item[commandlog] displays the status of the commandlog. -\item[commandlog close] closes the commandlog file. -\item[commandlog auto] Switches automatic log file creation on. This is normally switched on. -Log files are written to the log directory of the instrument account. There - are time stamps any hour in that file and there is a new file any 24 hours. -\end{description} - -% html: End of file: `commandlog.htm' -% html: Beginning of file: `optimise.htm' - -\section{The Peak Optimiser} - -\label{f12} - -In instrument control the need arises to optimise a peak with respect to -several variables. Optimising means finding the maximum of the peak with -respect to several variables. - This is usefull during instrument calibration. -Four circle diffractometers use this facility on a day to day basis -for finding and verifying the exact position of reflections. In order to -support both usages a more general module has been implemented. The way of -operation is like this: -\begin{verbatim} -while errors gt precision and cycles lt maxcycles - for all variables - do a scan - Try find the maximum, two halfwidth points and the peak center. - if failure extend the scan. - if success shift the variable, remember last shift. - If shift lt precicison mark this variable as done - end for -end while -\end{verbatim} -Possible outcomes of this procedure are: success, the peak was lost or the -maximum number of cycles was reached. This routine requires that the -instrument is currently placed somewhere on the peak and not miles away. - -The Peak Optimiser is implemented as an object with the name opti. It -understand the following commands: -\begin{description} -\item[opti clear] clears the optimiser. -\item[opti addvar name step nStep precision] This command adds a variable to optimise to the optimiser. The user has -to specify the name of the variable, the step width to use for scanning, the -number of steps needed to cover the full peak when scanning and the -precision which should be achieved when optimising the peak. The step width -and number of steps parameters should cover the whole peak. However, the -Optimiser will extend the scan is the specified range is not sufficient. -\item[opti run] Starts the optimiser. It will then optimise the peak. This may take some -time. -\end{description} - The behaviour of the optimiser can be configured by modifying some -parameters. The synatx is easy: {\bf opti parameter} prints the value of the -parameter, {\bf opti parameter newval} sets a new value for the parameter. -The following parameters are supported: -\begin{description} -\item[maxcycles] The maximum number of cycles the optimiser will run when trying to -optimise a peak. The default is 7. -\item[threshold] When a peak cannot be identified after a scan on a variable, the -optimiser will check if there is a peak at all. In order to do that it -searches for a count rate higher then the threshold parameter. If such a -rate cannot be found the optimiser will abort and complain that he lost the -peak. -\item[channel] The counter channel to use for scanning. The default is to use the -counter. By modifying this parameter, the optimiser can optimise on a -monitor instead. -\item[countmode] The counting mode to use when scanning. Possible values are {\bf timer} or -{\bf monitor}. -\item[preset] The preset value to use for counting in the scan. Depending on the -status of the countmode parameter this is either a preset time or a preset -monitor. -\end{description} - -% html: End of file: `optimise.htm' -% html: Beginning of file: `token.htm' - -\section{The Token Command} - -\label{f5} - -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 -looking at things. A token can be released manully 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: -\begin{description} -\item[token grab] Reserves control over the instrument to the client isssuing this -command. Any other client cannot control the instrument now. However, other -clients are still able to inspect variables. -\item[token release] Releases the control token. Now any other client can control the -instrument again. Or grab the control token. -\item[token force password] 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. -\end{description} - -% html: End of file: `token.htm' -% html: Beginning of file: `sanscom.htm' - -\chapter{Special SANS commandos} - -\label{f13} - - -This section describes some commands special to SANS. One feature of SANS -is that components are used as a whole rather than referring to single -motors. For SANS the beamstop, the detector and the sample table are managed -like this. Within a component each axis can be addressed specificaly by using -an axis = value pair. Axis defined for each component will be listed below. -Additionally these components support a 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: {\bf BeamStop -PositionA} drives the BeamStop 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 (cf.\ Section~\ref{f9}) command right -after your command. - -\section{ Commands supported by all components} - - - -In the following the name of the component will be represented by COP. -\begin{description} -\item[ 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. -\item[ COP back] drives the component back to the position before the last command. -Please note, that back does not operate on istself, i.e. two times COP back -will not do a trick. -\item[ COP pos name ] This command promotes the current position of the component to a named -position name. Afterwards this position can be reached by typing: COP name. -\item[ COP defpos name mot val mot val ....] this command defines a named position named name. This must be followed -by a list of motor names to run and their values. The motor names must be -those listed as SANS motors (cf.\ Section~\ref{f14}). (Not yet -implemented). -\item[ COP drop name] deletes the named position specified as second parameter. -\item[ COP axis = val axis = val ........] drives the component to the new position specified by 1-n sets of axis -name = value pairs. The axis refer to the internal axis of the component -which are listed below or can be seen in a listing as created by typing COP. -\end{description} - -\section{ Specific components} - - - -This section lists the components which follow the component syntax described -above. Furthermore the axis available for each component are listed. Each -component has two names: a long one and a short one given in parantheses. -\begin{description} -\item[BeamStop (bs)] The beam stop in front of the detector. Supports tow axis: -\begin{itemize} -\item X, the horizontal movement. -\item Y, the vertical movement. -\end{itemize} -The beam stop has additional command assoicated with it: -\begin{itemize} -\item bsout, drives the beamstop out of the beam. -\item bsin, drives the beam into position. -\item bschange, inquires the current beam stop. -\item bschange par, changes the beam stop to the specified number. Valid numbers are: -\begin{itemize} -\item 1, no beam stop. -\item 2, small beam stop. -\item 3, medium beam stop. -\item 4, large beam stop. -\end{itemize} -\item bsfree, when changing the beam stop goes wrong the beam stop may be in -a locked state. This command releases this lock. Drive with great care then! -\end{itemize} -\item[detector (dt)] moves the detector around. The following axis are available: -\begin{itemize} -\item X, the movement along the tank. -\item Y, a movement sideways. -\item phi, the rotation of the detector. -\end{itemize} -\item[ sample (sa)] the sample table. Support the axis: -\begin{itemize} -\item Omega, sample table rotation. -\item X, translation X -\item Y, translation Y. ->LI>Z, translation Z. -\item phi, cradle 1. -\item chi, cradle 2. -\end{itemize} -\end{description} - -\section{The Shutter } - - - -Even the shutter can be opnend from within SICS. Please note, that this will - only work if the LBC says it is OK, i.e. the enclosure is locked. -\begin{itemize} -\item shutter, prints the shutter status. -\item shutter open, opens the shutter. -\item shutter close, closes the shutter. -\end{itemize} - -\section{ Usage examples } - - - -\begin{description}\item[ bs X = 12. Y 200] moves the beam stop to 12 horizontal position, Y vertical position. -\item[ bsout] drives the beam stop to the previously defined position out. -\item[ bsback] drives the beam stop to the position before the preceeding command. -\end{description} - -% html: End of file: `sanscom.htm' -% html: Beginning of file: `sansdev.htm' - -\chapter{SANS-Devices} - -\label{f15} - - -SANS control a couple of motors (cf.\ Section~\ref{f16}), a -histogram memory (cf.\ Section~\ref{f17}), a -counter box (cf.\ Section~\ref{f18}) for -reading monitors, a velocity selector (cf.\ Section~\ref{f19}), its -associated wavelength (cf.\ Section~\ref{f20}) variable and various -environment.htm (cf.\ Section~\ref{f21}) control devices. Each of these -devices understands commands. The syntax understood by each of these devices -will be discussed, followed by a list (cf.\ Section~\ref{f14}) - of devices following this syntax. - - -% html: End of file: `sansdev.htm' -% html: Beginning of file: `motor.htm' - -\chapter{SICS motor handling} - -\label{f16} - - - In SICS each motor is an object with a name. Motors may take commands which basically come in the form {\em 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. {\em Motorname parametername } will print the current value of the variable. {\em 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: -\begin{itemize} -\item {\bf Motorname list } gives a listing of all motor parameters. -\item {\bf Motorname reset } resets the motor parameters to default values. - This is software zero to 0.0 and software limits are reset to hardware -limits. -\item {\bf Motorname position} prints the current position of the motor. -\item {\bf Motorname interest} initiates automatic printing of any position -change of the motor. This command is mainly interesting for implementors of -status display clients. -\end{itemize} - Please note that the actual driving of the motor is done via the drive (cf.\ Section~\ref{f9}) command. - - -\section{The motor parameters} - - -\begin{itemize} -\item {\bf HardLowerLim } 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. -\item {\bf HardUpperLim } 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. -\item {\bf SoftLowerLim } is the software lower limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftUpperLim } is the software upper limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftZero } defines a software zero point for the motor. All further movements will be in respect to this zeropoint. -\item {\bf Fixed } can be greater 0 for the motor being fixed and less -or equal than zero for the motor being movable. -\item {\bf InterruptMode } 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. Other 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. -\item {\bf Precision } denotes the precision to expect from the motor in positioning. Can usually only be set by managers. -\item {\bf AccessCode } 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. -\item {\bf Speed }, defunct. -\item {\bf Sign } 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. -\end{itemize} - - -% html: End of file: `motor.htm' -% html: Beginning of file: `counter.htm' - -\chapter{SICS counter handling} - -\label{f18} - - - This section deals with the SICS interface to single counters. -Where the SICS counter concept may include several monitors per -counter. A counter is, again, a named object which takes commands. -A word or two has to be lost about the SICS handling of preset values for counters. -Two modes of operation have to be distinguished: counting until a timer has passed, -for example: count for 20 seconds. This mode is called timer mode. In the other -mode, counting is continued until a control monitor has reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - The commands understood are: -\begin{itemize} -\item {\bf countername SetPreset val } sets the counting preset to val. -\item {\bf countername GetPreset } prints the current preset value. -\item {\bf countername SetExponent val } sets the exponent for the counting -preset in monitor mode to val. -\item {\bf countername GetExponent } prints the current exponent used -in monitor mode. -\item {\bf countername SetMode val } sets the counting mode to val. Possible values are Timer for timer mode operation and Monitor for waiting for a monitor to reach a certain value. -\item {\bf countername GetMode } prints the current mode. -\item {\bf countername GetCounts } prints the counts gathered in the last run. -\item {\bf countername GetMonitor n } prints the counts gathered in the monitor number n in the last run. -\item {\bf countername Count preset } starts counting in the current mode and the the preset preset. -\item {\bf countername status } prints a message containing the preset and -the current monitor or time value. Can be used to monitor the progress of -the counting operation. -\item {\bf countername gettime } Retrieves the actual time the counter -counted for. This excludes time where there was no beam or counting was -paused. -\item {\bf countername getthreshold m} retrieves the value of the threshold - set for the monitor number m. -\item {\bf countername setthreshold m val} sets the threshold for monitor m - to val. WARNING: this also makes monitor m the active monitor for evaluating - the threshold. Though the EL7373 counterbox does not allow to select the - monitor to use as control monitor in monitor mode, it allows to choose - the monitor used for pausing the count when the count rate is below the - threshold (Who on earth designed this?) -\end{itemize} - -% html: End of file: `counter.htm' -% html: Beginning of file: `histogram.htm' - -\chapter{Histogram memory} - -\label{f17} - - -Histogram memories are used in order to control large area sensitive -detectors or single detectors with time binning information. -Basically each detector maps to a defined memory location. The -histogram memory wizard takes care of putting counts detected in the -detector into the proper bin in memory. Some instruments resolve energy -(neutron flight time) as -well, than there is for each detector a row of memory locations mapping to -the time bins. As usual in SICS the syntax is the name of the histogram -memory followed by qualifiers and parameters. As a placeholder for the -histogram memories name in your system, HM will be used in the following -text. - -A word or two has to be lost about the SICS handling of preset values for -histogram memories. - Two modes of operation have to be distinguished: counting until a timer has passed, -for example: count for 20 seconds. This mode is called timer mode. In the other -mode, counting is continued until a control monitor has reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - -\section{ Configuration} - - - -A HM has a plethora of configuration options coming with it which define -memory layout, modes of operation, handling of bin overflow and the like. -Additionally there are HM model specific parameters which are needed -internally in -order to communicate with the HM. In -most cases the HM will already have been configured at SICS server startup -time. However, there are occasion where these configuartion option need to -enquired or modified at run time. The command to enquire the current value -of a configuration option is: {\bf HM configure option}, the command to set it is: -{\bf HM configure option newvalue}. A list of common configuration options and their -meaning is given below: -\begin{description} -\item[ HistMode] HistMode describes the modes of operation of the histogram memory. -Possible values are: -\begin{itemize} -\item Transparent, Counter data will be written as is to memory. For debugging -purposes only. -\item Normal, neutrons detected at a given detector will be added to the - apropriate memory bin. -\item TOF, time of flight mode, neutrons found in a given detector will be -put added to a memory location determined by the detector and the time -stamp. -\item Stroboscopic mode. This mode serves to analyse changes in a sample due -to an varying external force, such as a magnetic field, mechanical stress -or the like. Neutrons will be stored in memory according to detector -position and phase of the external force. -\end{itemize} -\item[ OverFlowMode] This parameter determines how bin overflow is handled. This happend -when more neutrons get detected for a particular memory location then are -allowed for the number type of the histogram memory bin. Possible values -are: -\begin{itemize} -\item Ignore. Overflow will be ignored, the memory location will wrap around -and start at 0 again. -\item Ceil. The memory location will be kept at the highest posssible value -for its number type. -\item Count. As Ceil, but a list of overflowed bins will be maintained. -\end{itemize} -\item[ Rank] Rank defines the number of histograms in memory. -\item[ Length ] gives the length of an individual histogram. -\item[ BinWidth] determines the size of a single bin in histogram memory in bytes. -\item[dim0, dim1, dim2, ... dimn] define the logical dimensions of the histogram. Must be set if the - the sum command (see below) is to be used. This is a clutch necessary to - cope with the different notions of dimensions in the SINQ histogram memory - and physics. -\end{description} -For time of flight mode the time binnings can be retrieved and modified with -the following commands. Note that these commands do not follow the configure -syntax given above. Please note, that the usage of the commands for -modifying time bins is restricted to instrument managers. -\begin{description} -\item[HM timebin] Prints the currently active time binning array. -\item[HM genbin start step n] Generates a new equally spaced time binning array. Number n time bins -will be generated starting from start with a stepwidth of step. -\item[HM setbin inum value] Sometimes unequally spaced time binnings are needed. These can be -configured with this command. The time bin iNum is set to the value value. -\item[HM clearbin] Deletes the currently active time binning information. -\end{description} - -\section{Histogram Memory Commands} - - - -Besides the configuration commands the HM understands the following -commands: -\begin{description} -\item[HM preset] with a new value sets the preset time or monitor for counting. Without a -value prints the current value. -\item[HM exponent] with a new value sets the exponent to use for the preset time -in Monitor mode. Without a -value prints the current value. -\item[CountMode ] with a new values sets the count mode. Possible values are Timer for a -fixed counting time and Monitor for a fixed monitor count which has to be -reached before counting finishes. Without a value print the currently active -value. -\item[HM init ] after giving configuration command sthis needs to be called in order to -transfer the configuration from the host computer to the actual HM. -\item[HM count] starts counting using the currently active values for CountMode and -preset. This command does not block, i.e. in order to inhibit further -commands from the console, you have to give Success afterwards. -\item[HM InitVal val] initialises the whole histogram memory to the value val. Ususally 0 in -order to clear the HM. -\item[ HM get i iStart iEnd] retrieves the histogram number i. A value of -1 for i denotes retrieval -of the whole HM. iStart and iEnd are optional amd -allow to retrieve a subset of a histogram between iStart and iEnd. -\item[HM sum d1min d1max d2min d2max .... dnmin dnmax] calculates the sum of an area on the detector. For each dimension a - minimum and maximum boundary for summing must be given. -\end{description} - -% html: End of file: `histogram.htm' -% html: Beginning of file: `velocity.htm' - -\chapter{The Velocity Selector } - -\label{f19} - -The velocity selector is a turbine rotating at high speed. This turbine -annihilates all neutrons which do not manage to travel through the -turbine in a time intervall defined by the rotation speed of the turbine. -Thus neutrons in a certain speed range (energy range) are selected. The -distribution of neutrons is also dependent of a tilt angle between the -rotation axis of the turbine and the neutron beam. A high speed device like -a velocity selector has to account for gyroscopic forces when moving the -device. In praxis this means that the selector must be stopped before the -tilt angle can be changed. Furthermore there are forbidden areas of rotation -speeds. In these areas the velocity selector is in destructive resonance with -itself or its bedding. The command set for a velocity selector is defined -below. The name of the velocity selctor object is assumed to be nvs. - -\begin{description}\item[nvs rottolerance par] Sets or requests the tolerance the rotation speed may have before an -error is issued. -\item[nvs list] Displays rotation speed and tilt angle of the velocity selctor. -\item[nvs add min max] This command adds a forbiden region between min and max to the list -of forbidden regiosn of the velocity selector. These values are usually -configured in the configuration file. -\item[ nvs rot = newval tilt = newval] This command sets a new tilt angle and/or rotation speed for the -velocity selector. Either one or both of the keywords tilt or rot may be -given, followed by a number. -\item[ nvs interrupt val] Requests or sets an interrupt value. This interrupt will be issued when - an error on this velocity selector ocurred. With a parameter a new value -is set, without the current value is printed. -\item[ nvs userrights val] Requests or sets a userright value. This userright value defines -who may drive this velocity selector. With a parameter a new value -is set, without the current value is printed. -\item[ nvs tilttolerance val] Requests or sets a tilttolerance value. This parameter defines the -permissable tolerance for the tilt motor. With a parameter a new value -is set, without the current value is printed. -\item[nvs rotinterest] Enables printing of status messages about the current state of the - selector when it is driven. -\item[ nvs loss] Starts a loss current measurement on the velocity selector and prints the -result. -\item[nvs status] Prints a status summary of the velocity selector. -\end{description} -The commands described so far cover the actual handling of the velocity -selector. During a measurement users might want to use further functions -such as: -\begin{itemize} -\item Monitor the rotation speed of the velocity selector. -\item Log the rotation speeds of the velocity selector. -\item Initiate error handling when the velocity selector fails to stay within -a predefined tolerance of rotation speeds. -\end{itemize} -Now, these are tasks usually connected with sample environment devices. Now, -the SICS programmers have been lazy. Moreover they wanted to avoid -duplicating code -(and bugs). Consequently, they tricked the velocity selector to be a -sample environment device as well. This means besides the actual velocity -selector object (in this case called nvs) there exists another object for -monitoring the velocity selector. The name of this device is the name of the -velocity selector object with the string watch appended. For example if the -velocity selector has the SICS name nvs, the monitor object will be -nvswatch. The commands understood by the watch object are fully decribed in -the section about sample environment devices (cf.\ Section~\ref{f21:all}). -Please note, that all driving commands for the watch object have been -disabled. Driving can only be achieved through the velocity selector object. -% html: End of file: `velocity.htm' -% html: Beginning of file: `velolambda.htm' - -\chapter{Wavelength adjustment for a Velocity Selector} - -\label{f20} - -The wavelength selected by a neutron velocity selector depends on the tilt -angle of the selector and its rotation speed. This is what the velocity -selector wavelength command is for. It is usually installed into the system -as lambda. This variable can be driven using the normal -drive and run (cf.\ Section~\ref{f9}) commands. Additionally this command understands a few sub -commands. For the following discussion is assumed that the name of the -command is lambda. -\begin{description} -\item[lambda] The name of the variable alone prints the current wavelength in nm. -\item[lambda rot val] calculates the rotation speed for the wavelength given by val. -\item[lambda wl val] calculates the wavlength for the rotation speed given as parameter val. -\end{description} - -% html: End of file: `velolambda.htm' -% html: Beginning of file: `samenv.htm' - -\chapter{ Sample Environment Devices} - -\label{f21} - - -\section{SICS Concepts for Sample Environment Devices} - -\label{f21:concept} - -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 continously. Therefore there -exists a facility for dynamically configuring and deconfiguring environment -devices into the system. This is done via the {\bf EVFactory} command. -It is expected that instrument scientists will provide command procedures or -specialised R\"unbuffers 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 {\bf emon}. The emon understands a few commands of its -own. - -Within SICS all sample environement 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 section the EVFactory, emon and the general commands understood -by any sample environment device will be discussed. This reading is mandatory -for understanding SICS environment device handling. Then there will be another -section discussing the special devices known to the system. - - -\section{SampleEnvironment Error Handling} - - -A \label{f21:error}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 differntiated. The SICS model therefore implements several -strategies for handling sample environment device failure handling. -The strategy to use is selected via 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: -\begin{description} -\item[Lazy] Just print a warning and continue. -\item[Pause] Pauses the measurement until the problem has been resolved. -\item[Interrupt] Issues a SICS interrupt to the system. -\item[Safe] Tries to run the environment device to a value considered safe by the -user. -\end{description} - -\section{General Sample Environment Commands} - -\label{f21:general} - -\subsection{EVFactory} - - - -EVFactory is responsible for configuring and deconfiguring sample environment -devices into SICS. The syntax is simple: -\begin{description} -\item[EVFactory new name type par par ...] Creates a new sample environment device. It will be known to SICS by the -name specified as second parameter. 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. -\item[EVFactory del name] Deletes the environment device name from the system. -\end{description} - -\subsection{emon} - - - -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. -\begin{description} -\item[emon list] This command lists all environment devices currently registered in the -system. -\item[emon register name] 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. -\item[emon unregister name] This is a specialist command which unregisters the environment device name -with the environment monitor. Usually this will automatically be taken care -of by EVFactory Following this call the device will no longer be monitored and -out of tolerance errors on that device no longer be handled. -\end{description} - -\subsection{General - Commands UnderStood by All Sample Environment Devices} - -\label{f21:all} - -Please note that each command discussed below MUST be prepended with the name -of the environment device as configured in EVFavtory! - -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: -\begin{quotation} -Temperature Tolerance\end{quotation} -prints the value of the variable Tolerance for the environment controller -Temperature. -\begin{quotation} -Temperature Tolerance 2.0\end{quotation} -sets the parameter Tolerance for Temperature to 2.0. Parameters known to ANY -envrironment controller are: -\begin{description} -\item[Tolerance] Is the deviation from the preset value which can be tolerated before an -error is issued. -\item[ Access] Determines who may change parameters for this controller. -Possible values are: -\begin{itemize} -\item 0 only internal -\item 1 only Managers -\item 2 Managers and Users. -\item 3 Everybody, including Spy. -\end{itemize} -\item[LowerLimit] The lower limit for the controller. -\item[UpperLimit] The upper limit for the controller. -\item[ErrHandler.] The error handler to use for this controller. Possible values: -\begin{itemize} -\item 0 is Lazy. -\item 1 for Pause. -\item 2 for Interrupt -\item 3 for Safe. -\end{itemize} - For an explanantion of these values see the section about error (cf.\ Section~\ref{f21:error}) handling -above. -\item[ Interrupt] The interrupt to issue when an error is detected and Interrupt error -handling is set. Valid values are: -\begin{itemize} -\item 0 for Continue. -\item 1 for abort operation. -\item 2 for abort scan. -\item 3 for abort batch processing. -\item 4 halt system. -\item 5 exit server. -\end{itemize} -\item[SafeValue] The value to drive the controller to when an error has been detected and -Safe error handling is set. -\end{description} - -Additionally the following commands are understood: -\begin{description} -\item[send par par ...] 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 -calibrartion tables etc. -\item[ list] lists all the parameters for this controller. -\item[ no command, only name.] When only the name of the device is typed it will return its -current value. -\item[ name val ] will drive the device to the new value val. Please note that the same -can be achieved by using the drive command. -\item[ name log on] 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! Log clear frees it again -and log frequency (both below) allows to set the logging time intervall. -\item[ name log off] Switches logging off. -\item[name log clear] Clears all recorded time stamps and values. -\item[name log gettime] This command retrieves a list of all recorded time stamps. -\item[name log getval] This command retrieves all recorded values. -\item[name log getmean] Calculates the mean value and the standard deviation for all logged -values and prints it. -\item[name log frequency val] With a parameter 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 any - cycle of the SICServer. - \end{description} - -\section{Special Environment Control Devices} - - - -This section lists the parameters needed for configuring a special environment -device into the system and special parameters and commands only understood by -that special device. All of the general commands listed above work as well! - -\subsection{ITC-4 and ITC-503 Temperature Controllers} - -\label{f21:itc4} - -These temperature controller are fairly popular at SINQ. It is manufactured by -Oxford Instruments. At the back side of this controller there is a RS-232 -socket which must be connected to a Macintosh computer running the SINQ -terminal server program via a serial cable. Please make sure with a different -Macintosh or a PC that the serial line is OK and the ITC-4 responding before -plugging it in. - -\subsubsection{ITC-4 Initialisation} - - - -An ITC-4 can be configured into the system by: -\begin{quotation} -EVFactory new Temp ITC4 computer port channel\end{quotation} -This creates an ITC-4 controller object named Temp within the system. The -ITC-4 is expected to be connected to the serial port channel at the -Macintosh computer computer running the SINQ terminal server program -listening at port port. For example: -\begin{quotation} -EVFactory new Temp ITC4 lnsp22.psi.ch 4000 6\end{quotation} -connects Temp to the Macintosh named lnsp22, serial port 5 (6 above is no typo!), - listening at port 4000. - -\subsubsection{ITC-4 Additional Parameters} - - - -The ITC-4 has a few more parameter commands: -\begin{description} -\item[timeout] Is the timeout for the Macintosh terminal server program waiting for -responses from the ITC-4. Increase this parameter if error messages -containg ?TMO creeping up. -\item[ sensor] Sets the sensor number to be used for reading temperature. -\item[ control] Sets the control sensor for the ITC-4. This sensor will be used -internally for regulating the ITC-4. -\item[divisor] The ITC4 does not understand floating point numbers, the ITC-503 does. -In order to make ITC4's read and write temperatures correctly floating point -values must be multiplied or divided with a magnitude of 10. This parameter -determines the appropriate value for the sensor. Is usually 10 for a sensor -with one value behind the comma or 100 for a sensor with two values after -the comma. -\item[multiplicator] The same meaning as the divisor above, but for the control sensor. -\end{description} - -\subsubsection{Installing an ITC4 step by step} - - - -\begin{enumerate}\item Connect the ITC temperature controller to port 6 on the Macintosh -serial port extension box. Port 6 is specially configured for dealing with -the ideosyncracies of that device. No null modem is needed. -\item Install the ITC4 into SICS with the command: \newline -evfactory new name Macintoshname 4000 7\newline -Thereby replace name with the name you want to address the ITC4 in SICS. A -good choice for a name is temperature, as such a value will be written to data files. -Please note, that SICS won't let you use that name if it already exists. For -instance if you already had a controller in there. Then the command:\newline -evfactory del name \newline -will help. Macintoshname is the name of the instrument Macintosh PC. -\item Configure the upper and lowerlimits for your controller appropriatetly. -\item Figure out which sensor you are going to use for reading temperatures. -Configure the sensor and the divisor parameter accordingly. -\item Figure out, which sensor will be used for controlling the ITC4. Set the -parameters control and multiplicator accordingly. Can be the same as the -sensor. -\item Think up an agreeable temperature tolerance for your measurement. This -tolerance value will be used 1) to figure out when the ITC4 has reached its -target position. 2) when the ITC4 will throw an error if the ITC4 fails to -keep within that tolerance. Set the tolerance parameter according to the -results of your thinking. -\item Select one of the numerous error handling strategies the control -software is able to perform. Configure the device accordingly. -\item Test your setting by trying to read the current temperature. -\item If this goes well try to drive to a temperature not to far from the -current one. -\end{enumerate} - -\subsubsection{ITC-4 Trouble Shooting} - - - -If the ITC-4 {\bf does not respond at all}, make sure the serial connection to -the Macintosh is working. Use standard RS-232 debugging procedures for doing -this. The not responding may also come up as a failure to connect to the ITC-4 -during startup. - - If error messages containing the string {\bf ?TMO} keep creeping up followed -by all signs of command not understood, then increase the timeout. The standard -timeout of 10 microseconds is to short at times. - -You keep on reading {\bf wrong values} from the ITC4. Mostly off by a -factor 10. Then set the divisor correctly. Or you may need to choose a -decent sensor for that readout. - -Error messages when {\bf trying to drive the ITC4}. These are usually the -result of a badly set multiplicator parameter for the control sensor. - -The ITC4 {\bf never stops driving}. There are at least four possible -causes for this problem: -\begin{enumerate} -\item The multiplicator for the control sensor was wrong and the ITC4 has now -a set value which is different from your wishes. You should have got error -messages then as you tried to start the ITC4. -\item The software is reading back wrong temperature because the sensor and -divisor parameters are badly configured. Try to read the temperature and if -it does have nothing to do with reality, set parameters accordingly. -\item The tolerance parameter is configured so low, that the ITC4 never -manages to stay in that range. Can also be caused by inappropriate PID -parameters in the ITC4. -\item -You are reading on one sensor (may be 3) and controlling on another one (may -be 2). Then it may happen that the ITC 4 happily thinks that he has reached -the temperature because its control sensor shows the value you entered as -set value. But read sensor 3 still thinks he is far off. The solution is to -drive to a set value which is low enough to make the read sensor think it is -within the tolerance. That is the temperature value you wanted after all. -\end{enumerate} - -\subsection{Haake Waterbath Thermostat} - -\label{f21:haake} - -This is sort of a buck full of water equipped with a temperature -control system. The RS-232 interface of this device can only be operated at -4800 baud max. This is why it has to be connected to the serial printer port -of the Macintosh serial port server computer. This makes the channel number to -use for initialisation a 1 always. The driver for this device has been -realised in the Tcl extension language of the SICS server. A prerequisite -for the usage of this device is that the file hakle.tcl is sourced in the -SICS initialisation file and the command inihaakearray has been published. - Installing the -Haake into SICS requires two steps: first create an array with -initialisation parameters, second install the device with evfactory. A -command procedure is supplied for the first step. Thus the initialisation -sequence becomes: -\begin{quotation} -inihaakearray name-o-array macintosh-computer name port channel\newline -evfactory new temperature tcl name-of-array\end{quotation} -An example for the SANS: -\begin{quotation} -inihaakearray eimer lnsp25.psi.ch 4000 1 \newline -evfactory new temperature tcl eimer\end{quotation} -Following this, the thermostat can be controlled with the other environment -control commands. - -The Haake Thermostat understands a single special subcommand: {\bf sensor}. -The thermostat may be equipped with an external sensor for controlling and -reading. The subcommand sensor allows to switch between the two. The exact -syntax is: -\begin{quotation} -temperature sensor val\end{quotation} -val can be either intern or extern. - -\subsection{Dilution Cryostat} - -\label{f21:dilu} - -This is a large ancient device for reaching very low temperatures. This -cryostat can be configured into SICS with the command: -\begin{verbatim} -EVFactory new Temp dillu computer port channel table.file -\end{verbatim} -Temp is the name of the dilution controller command in SICS, dillu is the -keyword which selects the dilution driver, computer, port and channel are -the parameters of the Macintosh-PC running the serial port server program. -table.file is the fully qualified name of a file containing a translation -table for this cryostat. The readout from the dilution controller is a -resistance. This table allows to interpolate the temperature from the -resistance measurements and back. Example: -\begin{verbatim} -evfactory new temperature dillu lnsp19.psi.ch 4000 1 dilu.tem -\end{verbatim} -installs a new dilution controller into SICS. This controller is connected -to port 1 at the Macintos-PC with the newtwork adress lnsp19.psi.ch. On this -macintosh-PC runs a serial port server program listening at TCP/IP port -4000. The name of the translation table file is dilu.tem. - -The dilution controller has no special commands, but two caveats: As of -current (October 1998) setting temperatures does not work due to problems -with the electronics. Second the dilution controller MUST be connected to -port 1 as only this port supports the 4800 maximum baud rate this device -digests. - -\subsection{Bruker Magnet Controller B-EC-1} - -\label{f21:bruker} - -This is the Controller for the large magnet at SANS. The controller is a -box the size of a chest of drawers. This controller can be operated in one -out of two modes: in {\bf field} mode the current for the magnet is controlled via -an external hall sensor at the magnet. In {\bf current} mode, the output current -of the device is controlled. This magnet can be configured into SICS with a -command syntax like this: -\begin{quotation} -evfactory new name bruker Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion (which will be used throughout the rest of the text) is magnet. -bruker is the keyword for selecting the bruker driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at SANS): -\begin{verbatim} -evfactory new magnet bruker lnsp25.psi.ch 4000 9 -\end{verbatim} - -creates a new command magnet for a Bruker magnet Controller connected to -serial port 9 at lnsp25. -In addition to the standard environment controller commands this magnet -controller understands the following special commands: -\begin{description} -\item[magnet polarity] Prints the current polarity setting of the controller. Possible -answers are plus, minus and busy. The latter indicates that the controller -is in the process of switching polarity after a command had been given to -switch it. -\item[magnet polarity val] sets a new polarity for the controller. Possible values for val are -{\bf minus} or {\bf plus}. The meaning is self explaining. -\item[magnet mode] Prints the current control mode of the controller. Possible -answers are {\bf field} for control via hall sensor or {\bf current} for -current control. -\item[magnet mode val] sets a new control mode for the controller. Possible values for val are -{\bf field} or {\bf current}. The meaning is explained above. -\item[magnet field] reads the magnets hall sensor independent of the control mode. -\item[magnet current] reads the magnets output current independent of the control mode. -\end{description} - -Warning: There is a gotcha with this. If you type only magnet a -value will be returned. The meaning of this value is dependent on the -selected control mode. In current mode it is a current, in field mode it is -a magnetic field. This is so in order to support SICS control logic. -You can read values at all times explicitly using magnet current or -magnet field. - -\subsection{The CryoFurnace.} - -\label{f21:ltc11} - -The CryoFurnace at PSI is equipped with a Neocera LTC-11 temperature -controller. This controller can control either an heater or an analag output -channel. Futhermore a choice of sensors can be selected for controlling the -device. The LTC-11 behaves like a normal SICS environment control device -plus a few additional commands. An LTC-11 can be configured into SICS with -the following command: -\begin{quotation} -evfactory new name ltc11 Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -ltc11 is the keyword for selecting the LTC-11 driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at DMC): -\begin{verbatim} -evfactory new temperature ltc11 lnsp18.psi.ch 4000 6 -\end{verbatim} - -creates a new command magnet for a LTC-11 temperature Controller connected to -serial port 6 at lnsp18. - -The additional commands understood by the LTC-11 controller are: -\begin{description} -\item[temperature sensor ] allows to query the current sensor used for temperature readout. -\item[temperature sensor val ] allows to select the sensor val for temperature readout. -\item[temperature controlanalog ] allows to query the sensor used for controlling the analog channel. -\item[temperature controlanalog val ] allows to select the sensor val for controlling the analog channel. -\item[temperature controlheat ] allows to query the sensor used for controlling the heater channel. -\item[temperature controlheat val ] allows to select the sensor val for controlling the heater channel. -\item[temperature mode] Allows to query if the LTC-11 controls the analog or heater channel. -\end{description} - -Further notes: As the CryoFurnace is very slow and the display at the -controller becomes unusable when the temperature is read out to often, the -LTC-11 driver buffers the last temperature read for 5 seconds. Setting the -mode of the LTC-11 is possible by computer, but not yet fully understood and - therefore unusable. - -\subsection{The Eurotherm Temperature Controller} - -\label{f21:euro} - -At SANS there is a Eurotherm temperature controller for the sample heater. - This and probably other Eurotherm controllers can be configured into SICS -with the following command. The eurotherm needs to be connected with a - nullmodem adapter. -\begin{quotation} -evfactory new name euro Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -euro is the keyword for selecting the Eurotherm driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. {\bf WARNING:} The eurotherm needs a RS-232 port with an unusual - configuration: 7bits, even parity, 1 stop bit. Currently only the SANS - Macintosh port 13 (the last in the upper serial port connection box) is - configured like this! Thus, an example for SANS and the name temperature - looks like: -\begin{verbatim} -evfactory new temperature euro lnsp25.psi.ch 4000 13 -\end{verbatim} - -There are two further gotchas with this thing: -\begin{itemize} -\item The eurotherm needs to operate in the EI-bisynch protocoll mode. This has -to be configured manually. For details see the manual coming with the machine. -\item The weird protocoll spoken by the Eurotherm requires very special control - characters. Therefore the send functionality usually supported by a SICS - environment controller could not be implemented. -\end{itemize} - -% html: End of file: `samenv.htm' -% html: Beginning of file: `trouble.htm' - -\chapter{SICS Trouble Shooting } - -\label{f1} - - -There is no such thing as bug free software. There are always bugs, nasty -behaviour etc. This document shall help to solve these problems. The usual -symptom will be that a client cannot connect to the server or the server is -not responding. - -An essential prerequisite of SICS is that the server is 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: -\begin{verbatim} -startsics -\end{verbatim} -at the command prompt. startsics actually starts two programs: one is -the replicator application which is responsible for the automatic -copying of data files to the laboratory server. The other is the SICS -server. Both programs are started by means of a shell script called -{\bf keepalive}. keepalive is basically an endless loop which calls -the program again and agaian and thus ensures that the program will -never stop running. - - When the SICS server hangs, or you want to enforce an reinitiliazation of -everything the server process must be killed. The first thing to -do is to find the process. - -\section{Finding the SICS server} - - - -Log in as Instrument user on the instrument computer (for instance DMC on -lnsa05). Type the command: -\begin{verbatim} -/home/DMC> ps -A -\end{verbatim} -Note the capital A given as parameter. The reward will be listing like this: -\begin{verbatim} - 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 -\end{verbatim} -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 ?? } an entry for the SICS server. In this example the server -is running. If the server is down, no such entry would be present. - -\section{ Killing a hanging SICS server } - - - -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} 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}. Please note, that this number will -always be different. The command to force the server to stop is: -\begin{verbatim} -/home/DMC> kill -9 31912 -\end{verbatim} -Note, the second parameter is the number found with {\tt ps -A}. 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. - -\section{ Shutting the SICS server down completely} - - - -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 {\bf keepalive SICServer }. Kill that one as -described above, then kill the SICServer. For restarting SICS after this, -use the startsics command. - -\section{Restart Everything} - - - -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. -\begin{enumerate} -\item Reboot the Macintosh PC by switching it off at the silver button on the -left. Press deep and a few seconds to achieve an effect. The LED right to the -button should be off, before you press again to boot the Macintosh. -\item 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. -\item Wait 5 minutes. The Macintosh may take that time to come up again. -\item Restart the SICServer. Watch for any messages about things not being -connected or configured. -\item Restart and reconnect the client programs. -\end{enumerate} -If this fails (even after a second) time there may be a network problem which -can not be resolved by simple means. - -\section{ HELP debugging!!!!} - - - -The SICS server hanging or crashing should not happen. In order to sort such -problems out it is very helpful if any available debugging information is -saved and presented to the programmers. Information available are the log -files as written continously by the SICS server and posssible core files -lying around. They have just this name: core. In order to save them create a -new directory (for example dump2077) and copy the stuff in there. This looks -like: -\begin{verbatim} -/home/DMC> mkdir dump2077 -/home/DMC> cp log/*.log dump2077 -/home/DMC> cp core dump2077 -\end{verbatim} -The {\tt /home/DMC> } is just the command prompt. Please note, that core -files are only available after crashes of the server. These few commands -will help to analyse the cause of the problem and to eventually resolve it. -% html: End of file: `trouble.htm' -% html: Beginning of file: `sanslist.htm' - -\chapter{SANS Device list} - -\label{f14} - - -\section{ Motors } - - - -\begin{description}\item[BeamStopX] this motor controls the vertical movement of the beam stop. -\item[BeamStopY] this motor controls the horizontal movement of the beam stop. -\item[DetectorX] this motor controls the movement of the detector along the tank. -\item[DetectorY] this motor moves the detector sideways. -\item[DetectorRotation] rotates the detector. -\end{description} - -\section{Counters } - - - -There is only one named counter. It controls the following monitors: -To be filled in by Joachim Kohlbrecher. - -\section{Variables} - - - -\begin{description}\item[Instrument] holds the name of the Instrument, in SANS case: {\tt{}"{}}SANS at SINQ, PSI{\tt{}"{}}. -This cannot be changed by ordinary members of the public. -\item[Title] the title of the instrument. This will be written to the output file. -Should be set by the user to something sensible. -\item[User] the user of the instrument. This will be written to the output file. -Should be set by the user to something sensible. -\item[Comment1] one line of comment to be written to the outputfile. -Should be set by the user to something sensible. -\item[Comment2] another line of comment to be written to the outputfile. -Should be set by the user to something sensible. -\item[environment] a line of text describing special environment conditions to be written -to the output file. This is for those cases where the sample environment is not -computer controlled and therefore not visible to the program. Users are -responsible for filling this in. -\end{description} - -% html: End of file: `sanslist.htm' -% html: Beginning of file: `saco.htm' - -\chapter{SANS command summary} - -\label{f22} - - - -\section{Most Used Commands} - - -\begin{description} -\item[ bs X = xval Y = yval] (cf.\ Section~\ref{f13}) drive beam stop to xval yval -\item[ bs out] drive beamstop to safe position. -\item[ bs back] drive beamstop back -\item[ dt X = xval Y = yval psi = angle] (cf.\ Section~\ref{f13}) drive detector to xval,yval, angle -\item[ count mode preset] Counts in mode with a preset value of preset. Stores data automatically. -\item[ Repeat num mode preset] Calls count num times. -\item[FileEval filename] (cf.\ Section~\ref{f7}) Runs a batch file with the specified filename. -\end{description} - -\section{ General commands } - - - -\begin{description}\item[Success] (cf.\ Section~\ref{f9}) wait for the last operation to finish. -\item[wait time] (cf.\ Section~\ref{f4}) wait for time to pass.... -\item[Dir ] (cf.\ Section~\ref{f4}) lists all objects in the system. -\item[config Rights username password] (cf.\ Section~\ref{f6}) changes authorisation to that of the user identified by username, -password. -\item[FileEval filename] (cf.\ Section~\ref{f7}) executes batch file filename. -\end{description} - -\section{Velocity Selector} - - - -\begin{description}\item[nvs list] lists tilt angle and speed of the velocity selector. -\item[nvs rot] prints rotation speed of the velocity selector. -\item[nvs rot val] sets rotation speed of the velocity selector. -\item[nvs tilt] prints tilt angle of the velocity selector. -\item[nvs tilt val] sets tilt angle of the velocity selector. -\item[nvs tilt val rot val2] sets both tilt angle and rotation speed of the velocity selector. -\item[ lambda ] (cf.\ Section~\ref{f20}) prints current wavelength. -\item[drive lambda val] drives velocity selector to a new wavelength. -\end{description} - -\section{ BeamStop } - - - -\begin{description}\item[ bs X = xval Y = yval] (cf.\ Section~\ref{f13}) drive beam stop to xval yval -\item[ bsout] drive beamstop to safe position. -\item[ bsin] drive beamstop back -\item[ bs pos name] assign current position to name -\item[ bs drop name] delete named position name -\item[bschange par] With parameter change beam stop, without: inquire about current beam stop. -\end{description} - -\section{ detector } - - - -\begin{description}\item[ dt X = xval Y = yval psi = angle] (cf.\ Section~\ref{f13}) drive detector to xval,yval, angle -\item[ dt back] drive detector back -\item[ dt pos name] assign current position to name -\item[ dt drop name] delete named position name -\end{description} - -\section{ LogBook} - - - -\begin{description}\item[LogBook file name] (cf.\ Section~\ref{f10}) sets log file name -\item[ LogBook on] switches logging on -\item[LogBook off] closes LogBook -\item[LogBook] lists current logging status -\end{description} - -\section{ Variables} - - - -Each variable (cf.\ Section~\ref{f13}) - can be inquired by just typing its name. It can be set by -typing the name followed by the new value. Currently available variables -are: -\begin{itemize} -\item Title -\item User -\item Comment1 -\item Comment2 -\item environment -\end{itemize} - -% html: End of file: `saco.htm' - -\end{document} \ No newline at end of file diff --git a/doc/user/topman b/doc/user/topman index 78c77efe..f8ce294a 100644 --- a/doc/user/topman +++ b/doc/user/topman @@ -16,9 +16,9 @@ %html -s report \begin{center} \begin{huge} -TOPSI--User Manual \\ +TOPSI--Reference Manual \\ \end{huge} -Version 0.9, \today\\ +Version 1.0, \today\\ Dr. Mark K\"onnecke \\ Labor f\"ur Neutronenstreuung\\ Paul Scherrer Institut\\ @@ -28,6 +28,7 @@ Switzerland\\ \clearpage \tableofcontents \clearpage + %html sicsinvoc.htm 1 %html general.htm 1 %html basic.htm 1 @@ -49,4 +50,4 @@ Switzerland\\ %html trouble.htm 1 %html topco.htm 1 -\end{document} \ No newline at end of file +\end{document} diff --git a/doc/user/topman.tex b/doc/user/topman.tex deleted file mode 100644 index d081f02f..00000000 --- a/doc/user/topman.tex +++ /dev/null @@ -1,1601 +0,0 @@ -\documentclass[12pt,a4paper]{report} -%%\usepackage[dvips]{graphics} -%%\usepackage{epsf} -\setlength{\textheight}{24cm} -\setlength{\textwidth}{16cm} -\setlength{\headheight}{0cm} -\setlength{\headsep}{0cm} -\setlength{\topmargin}{0cm} -\setlength{\oddsidemargin}{0cm} -\setlength{\evensidemargin}{0cm} -\setlength{\hoffset}{0cm} -\setlength{\marginparwidth}{0cm} - -\begin{document} -\begin{center} -\begin{huge} -TOPSI--User Manual \\ -\end{huge} -Version 0.9, \today\\ -Dr. Mark K\"onnecke \\ -Labor f\"ur Neutronenstreuung\\ -Paul Scherrer Institut\\ -CH--5232 Villigen--PSI\\ -Switzerland\\ -\end{center} -\clearpage -\tableofcontents -\clearpage -% html: Beginning of file: `sicsinvoc.htm' - -\chapter{SICS Invocation} - -\label{f0} - -SICS is a client server system. This means there are at least two programs -necessary to run the experiment. The first -is the -SICServer which does the actual instrument control work. A user rarely needs -to bother about this server program as it is meant to run all the time. -See instructions below if things go wrong. - -Then there are one to many client programs which interact with the -instrument control server. These client programs implement the status -displays and a command line application which allows to influence the -course of the experiment. Graphical User Interfaces may be added at a -later time. -The user has only to deal with -these SICS client programs. SICS Clients and the SICServer communicate -with each other through TCP/IP sockets. - -Currently five SICS clients are available: -\begin{itemize} -\item A command line control client which allows to control the measurement. -\item A status display for DMC. -\item A status display for TOPSI. -\item A status display for SANS. -\item A status display for FOCUS. -\item A SICS variable watcher. -\end{itemize} - - -\section{Steps necessary for logging in to SICS} - - -The following actions have to be taken in order to interact with the -SICS server through a client: -\begin{itemize} -\item Start the client application. -\item Connect the client to a SICS server. -\item In case of command line clients: authorize yourself as -privileged SICS user. -\end{itemize} - -\section{Starting SICS client applications } - - - -These programs can be started on a DigitalUnix system by issuing the -following commands at the command prompt: -\begin{description} -\item[sics \&] for the control client. -\item[powderstatus \&] for the DMC status display client. -\item[topsistatus \&] for the TOPSI status display. -\item[sansstatus \&] for the SANS status display. -\item[focustatus] for the FOCUS status display. -\item[varwatch \&] for the variable watcher. -\end{description} -On a PC you may find icons for starting the different programs on the -desktop. -Each of these clients has usage instructions online which can be displayed -through the help/about menu entry. - -\section{Connecting} - - - -After startup any SICS client is not connected to a SICS server and thus not -active. A connection is established through the connect menu of the client. - -\section{Authorization} - - - -SICS is a multi user instrument control system. In order to prevent -malicious manipulations of the instrument SICS supports a hierarchy of user -rights. In order to run an experiment you need at least user level privilege. -In order to achieve this privilege you have to invoke the User Parameter/Set -Rights dialog. There you have to enter the apropriate username and password -kindly provided by your instrument scientist. - -\section{Restarting the Server} - - - -The SICS server should be running all the time. It is only down if something -went wrong. You can check for the presence of the SICS server by loging in -to the instrument computer and typing {\bf CheckSICS} at the command -prompt. The output will tell you what is happening. If you need to restart -the SICS server log in as the instrument user at the instrument computer and -invoke the apropriate command to start the server. These are: -\begin{description} -\item[DMC] Computer = lnsa05,User = DMC -\item[TOPSI] Computer = lnsa03,User = TOPSI -\item[SANS] Computer = lnsa07,User = SANS -\item[TRICS] Computer = lnsa12, User = TRICS -\item[HRPT] Computer = lnsa11, User = HRPT -\item[FOCUS] Computer = lnsa13, User = FOCUS -\end{description} -For starting the SICS server type {\bf startsics}. This is a shell script -which will starts all necessary server programs. This script works only on -the instrument computer and in the appropriate instrument account. - - If all this does not help look under trouble shooting -SICS (cf.\ Section~\ref{f1}). -% html: End of file: `sicsinvoc.htm' -% html: Beginning of file: `general.htm' - -\chapter{General SICS commands} - -\label{f2} - - - This section describes general SICS concepts and SICS commands available to all instruments. - -\section{Chapter Overview} - - - -\begin{itemize}\item This chapter starts with an overview over some basic (cf.\ Section~\ref{f3}) SICS concepts. -\item Than there are system (cf.\ Section~\ref{f4}) commands for closing the server, requesting status information etc. -\item The Token command (cf.\ Section~\ref{f5}) for managing control access to -the SICS server. -\item A few commands permit to change (cf.\ Section~\ref{f6}) user rights, set output files and the like. -\item SICS has a built in macro (cf.\ Section~\ref{f7}) facility which is accessible through a few commands. -\item Than there is the famous (cf.\ Section~\ref{f8}) LNS-R\"unbuffer system. -\item Motors and parameters need to be drive (cf.\ Section~\ref{f9})n. -\item Logging of client output to a file can be performed with the LogBook (cf.\ Section~\ref{f10}) command and the commandlog (cf.\ Section~\ref{f11}). -\item SICS has a facility to optimise (cf.\ Section~\ref{f12}) a peak with respect to several -parameters. -\end{itemize} - -% html: End of file: `general.htm' -% html: Beginning of file: `basic.htm' - -\section{Basic SICS concepts} - -\label{f3} - - -\subsection{General structure} - - - - SICS is a client server system. The application the user sees is usually some form of client. A client has two tasks: the first is to collect user input and send it to the SICS server who will execute the command. The clients second task is to listen to the the server messages and display them in a readable format. This aoproach has two advantages: clients can reside on machines across the whole network thus enabling remote control from everywhere in the world. The second advantage is that new clients (such as graphical user interface clients) can be written in any feasible language without changes to the server. - -\subsection{SICS Command Syntax } - - - - SICS is an object oriented system. This is reflected in the command syntax. SICS objects can be devices such as motors or counters, variables such as wavelength or Title and measurement procedures. Communication with these objects happens by sending messages to the target object. This is very simply done by typing something like: object message par1 par2 .. parn. For example, if we have a motor called A1:\begin{verbatim} - A1 list -\end{verbatim} - will print a parameter listing for the motor A1. In this example no parameters were needed. There exist a number of one-word commands as well. For -compatability reasons some commands have a form which resembles a function call such as:\begin{verbatim} - drive a1 26.54 -\end{verbatim} - This will drive motor a1 to 26.54. All commands are -ASCII-strings and usually in english. SICS is in general CASE INSENSITIVE. -However, this does not hold for parameters you have to specify. On a unix -system for instance file names are case sensitive and that had to be -preserved. Commands defined in the scripting language are lower case by -convention. - -\subsection{Authorisation} - - - - A client server system is potentially open to unauthorised hackers which might mess up the instrument and your valuable measurements. A known problem in instrument control is that less knowledgeable user accidentally change instrument adjustments which should better be left fixed. In order to solve these two problems SICS supports authorisation on a very fine level. As a user you have to specify a username and password in order to able to access SICS. Some clients already do this for you automatically. SICS support four levels of access to an instrument: -\begin{itemize} -\item {\bf Spy } may look at everything, request any value, but may not actually change anything. No damage potential here. -\item {\bf User } is privileged to perform a certain amount of operations necessary to run the instrument. -\item {\bf Manager } has the permission to mess with almost everything. A very dangerous person. -\item {\bf Internal } is not accessible to the outside world and is used to circumvent protection for internal uses. However some parameters are considered to be so critical that they cannot be changed during the runtime of the SICS-server, not even by Managers. -\end{itemize} - All this is stated here in order to explain the common error message: You are not authorised to do that and that or something along these lines. - -\subsection{SICS variables} - - - - Most of the parameters SICS uses are hidden in the objects to which they belong. But some are separate objects of their own right and are accessible at top level. For instance things like Title or wavelength. They share a common syntax for changing and requesting their values. This is very simple: The command {\em objectname } will return the value, the command {\em objectname newvalue } will change the variable. But only if the authorisation codes match. - - -\subsection{The SICS Command Line Client} - - -The most common client for controlling SICS is the {\bf SICS command line -client}. -This application can be started by typing the command: -\begin{verbatim} -sics & -\end{verbatim} -at the Unix prompt. Before this program is ready to collaborate with you you -have to connect it to an instrument using the options in the connect -pulldown menu. The screen is roughly divided in three areas: The top area -shows all input to and output from the server. The middle area shows the -command history. At the lower end is a text entry field which allows to type -commands to the SICS server. For more information about this client consult -the online help of this application. -% html: End of file: `basic.htm' -% html: Beginning of file: `system.htm' - -\section{System Commands} - -\label{f4} - -{\bf Sics\_Exitus }. A single word commands which shuts the server down. Only Managers may use this command. - - {\bf wait time } waits time seconds before the next command is executed. This does not stop other clients from issuing commands. - - {\bf ResetServer } resets the server after an interrupt. - - {\bf Dir } a single word command which lists all objects available in the SICS system in its current configuration. - - {\bf status } A single word command which makes SICS print its current -status. Possible return values can be: -Eager to execute commands, Scanning, Counting, Running, Halted. Note that if a command is executing which takes some time to complete - the server will return an ERROR: Busy message when further commands are issued. - -{\bf status interest} initiates automatic printing of any status change in the -server. This command is primarily of interest for status display client -implementors. - -{\bf backup file} saves the current values of SICS variables and selected - motor and device parameters to the disk file specified as parameter. The - path to this files is relative to the SICS server directory. The format - of the file is a list of SICS commands to set all these parameters again. - -{\bf restore file} reads a file produced by the backup command described -above and restores SICS to the state it was in when the status was saved with - backup. -% html: End of file: `system.htm' -% html: Beginning of file: `config.htm' - -\section{Configuration Commands} - -\label{f6} - - SICS allows to change the user rights of the current client server connection, control the amount of output a client receives and to specify additional logfiles where output will be placed. All this is accessed through the following commands: - - The SICS server logs all its activities to a logfile, regardless of what the user requested. This logfile is mainly intended to help in server debugging. However, clients may register an interest in certain server events and can have them displayed. This facility is accessed via the {\bf GetLog } command. It needs to be stressed that this log receives messages from {\bf all } active clients. GetLog understands the following messages: -\begin{itemize} -\item {\bf GetLog All } achieves that all output to the server logfile is also written to the client which issued this command. -\item {\bf GetLog Kill } stops all logging output to the client. -\item {\bf GetLog OutCode } request that only certain events will be logged to the client issuing this command. Enables only the level specified. Multiple calls are possible. -\end{itemize} - Possible values for OutCode in the last option are: -\begin{itemize} -\item {\bf Internal } internal errors such as memory errors etc. -\item {\bf Command } all commands issued from any client to the server. -\item {\bf HWError } all errors generated by instrument hardware. The SICS server tries hard to fix HW errors in order to achieve stable operations and may not generate an error message if it was able to fix the problem. This option may be very helpful when tracking dodgy devices. -\item {\bf InError } All input errors found on any clients input. -\item {\bf Error } All error messages generated by all clients. -\item {\bf Status } some commands send status messages to the client invoking the command in order to monitor the state of a scan. -\item {\bf Value } Some commands return requested values to a user. These messages have an output code of Value. -\end{itemize} - -{\bf config } allows to configure various aspects of the current client server connection. Basically three things can be manipulated: The connections output class, the user rights associated with it, and output files. - -\begin{itemize} \item The command {\bf config OutCode val } sets the output code for the connection. By default all output is sent to the client. But a graphical user interface client might want to restrict message to only those delivering requested values and error messages and suppressing anything else. In order to achieve this, this command is provided. Possible values Values for val are Internal,Command, HWError,InError,Status, Error, Value. This list is hierarchical. For example specifying InError for val lets the client receive all messages tagged InError, Status, Error and Value, but not HWError, Command and Internal messages. -\item Each connection between a client and the SICS server has user rights assocociated with it. These user rights can be configured at runtime with the command {\bf config Rights Username Password }. If a matching entry can be found in the servers password database new rights will be set. -\item Scientists are not content with having output on the screen. In order to -check results a log of all output may be required. The command {\bf config -File name } makes all output to the client to be written to the file -specified by name as well. The file must be a file accessible to the server, -i.e. reside on the same machine as the server. Up to 10 logfiles can be -specified. Note, that a directly connected line printer is only a special -filename in unix. -\item {\bf config close num} closes the log file denoted by num again. -\item {\bf config list} lists the currently active values for outcode and user -rights. -\end{itemize} - - -% html: End of file: `config.htm' -% html: Beginning of file: `macro.htm' - -\section{Macro Commands} - -\label{f7} - - 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 Tool Command Language (TCL). Tcl has control constructs, variables of its own, loop constructs, associative arrays and procedures. Tcl is well documented by several books and online tutorials, therefore no details on Tcl will be given here. All SICS commands are available in the macro language. Some potentially harmful Tcl commands have been deleted from the standard Tcl interpreter. These are: exec, source, puts, vwait, exit,gets and socket. The following commands allow access to the macro facility: - - {\bf FileEval name } tries to open the file name and executes the script in this file. Please note that the server is configured via such a file. - - {\bf ClientPut sometext1 ... } writes everything after ClientPut to the client which started the script. Useful for output to a client from macro scripts. - -{\bf SICSType object } allows to query the type of the object specified by object. Possible return values are -\begin{itemize} -\item {\bf DRIV } if the object is a SICS drivable object such as a motor -\item {\bf COUNT } if the object is some form of a counter. -\item {\bf COM } if the object is a SICS command. -\item {\bf NUM } if the object is a number. -\item {\bf TEXT } if object is something meaningless to SICS. -\end{itemize} - - {\bf SICSbounds var newval } checks if the new value newval lies within the limits for varaible var. Returns an error or OK depending on the result of the test. - - {\bf SICSStatus var } SICS devices such as counters or motor may be started and left running while the program is free to do something else. This command allows to enquire the status of such a running device. Return values are internal SICS integer codes. This command is only of use for SICS programmers. - -{\bf SetStatus newval } allows to set the SICS status to one of: Eager, UserWait, Count, NoBeam, Driving, Running, Scanning, Batch Hatl or Dead. This command is only available in macros. - - {\bf SetInt newval, GetInt } allow for the manipulation of interrupts from macro scripts. Not recommended! Possible return values or new values are: continue, abortop, abortscan, abortbatch, halt, free, end. This command is only permitted in macros. Should only be used by SICS programmers. -% html: End of file: `macro.htm' -% html: Beginning of file: `buffer.htm' - -\section{R\"unbuffer Commands} - -\label{f8} - - LNS scientists have got used to using R\"unbuffers for instrument control. A R\"unbuffer is an array of SICS commands which typically represent a measurement. This R\"unbuffer can be edited at run time. This is very similar to a macro. In contrast to a macro only SICS commands are allowed in R\"unbuffers. When done with editing the R\"unbuffer it can be entered in a R\"unlist. This is a stack of R\"unbuffers which get executed one by one. While this is happening it is possible (from another client) to modify the R\"unlist and edit and add additional R\"unbuffer on top of the stack. This allows for almost infinite measurement and gives more control than a static batch file. In order to cater for this scheme three commands have been defined: - - The {\bf Buf } object is responsible for creating and deleting R\"unbuffers. The syntax is: -\begin{itemize} -\item {\bf Buf new name } creates a new empty R\"unbuffer with the name name. name will be installed as a SICS object afterwards. -\item {\bf Buf copy name1 name2 } copies R\"unbuffer name1 to buffer name2. -\item {\bf Buf del name } deletes the R\"unbuffer name. -\end{itemize} - - After creation, the R\"unbuffer is accessible by his name. It than understands the commands: -\begin{itemize} -\item {\bf NAME append what shall we do with a drunken sailor } will add all text after append as a new line at the end of the R\"unbuffer. -\item {\bf NAME print } will list the contents of the R\"unbuffer. -\item {\bf NAME del iLine } will delete line number iLine from the R\"unbuffer. -\item {\bf NAME ins iLine BimBamBim } inserts a new line {\bf after } line iLine into the R\"unbuffer. The line will consist of everything given after the iLine. -\item {\bf NAME subst pattern newval } replaces all occurences of pattern in the R\"unbuffer by the text specified as newval. Currently this feature allows only exact match but may be expanded to Unix style regexp or shell like globbing. -\item {\bf NAME save filename } saves the contents of the R\"unbuffer into file filename. -\item {\bf NAME load filename } loads the R\"unbuffer with the data in file filename. -\item {\bf NAME run } executes the R\"unbuffer. -\end{itemize} - - The R\"unlist is accessible as object {\bf stack }. Only one R\"unlist per server is permitted. The syntax: -\begin{itemize} -\item {\bf stack add name } adds R\"unbuffer name to the top of the stack. -\item {\bf stack list } lists the current R\"unlist. -\item {\bf stack del iLine } deletes the R\"unbuffer iLine from the R\"unlist. -\item {\bf stack ins iLine name } inserts R\"unbuffer name after R\"unbuffer number iLine into the R\"unlist. -\item {\bf stack run } executes the R\"unlist and returns when all R\"unbuffers are done. -\item {\bf stack batch } executes the R\"unlist but does not return when done but waits for further R\"unbuffers to be added to the list. This feature allows a sort of background process in the server. -\end{itemize} - -% html: End of file: `buffer.htm' -% html: Beginning of file: `drive.htm' - -\section{Drive commands} - -\label{f9} - - Many objects in SICS are {\bf 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 an energy. This class of objects can be operated by the {\bf drive, run, Success } family of commands. These commands cater for blocking and non-blocking modes of operation. - - {\bf run var newval var newval ... } 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 perhaps a slow device is running into position. - - {\bf Success } waits and blocks the command connection until all pending operations have finished (or an interrupt occured). - - {\bf drive var newval var newval ... } can be called with one to n pairs of object 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. -% html: End of file: `drive.htm' -% html: Beginning of file: `logbook.htm' - -\section{LogBook command} - -\label{f10} - -Some users wish like to have all the input typed to SICS and all responses -collected in a file for further review. This is implemented via the LogBook -command. LogBook understands the following syntax: -\begin{description} -\item[ LogBook] alone prints the name of the current logfile and the status of event -logging. -\item[ LogBook file filename] This command sets the filename to which output will be printed. -Please note that this new filename will only be in effect after restarting -logging. -\item[ LogBook on] This command turns loggin on. All commands and all answers will be -written to the file defined with the command described above. Please note, -that this command will overwrite an existing file with the same name. -\item[ LogBook off] This command closes the logfile and ends logging. -\end{description} - -% html: End of file: `logbook.htm' -% html: Beginning of file: `commandlog.htm' - -\section{The Commandlog} - -\label{f11} - -The commandlog is a file where all communication with clients -having user or manager privilege is logged. This log allows to retrace each -step of an experiment. This log is usually switched off and must be -configured by the instrument manager. There exists a special command, -commandlog, which allows to control this log file. -\begin{description} -\item[commandlog new filename] starts a new commandlog writing to filename. Any prior files will be -closed. The log file can be found -in the directory specified by the ServerOption LogFileDir. Usually this is -the log directory. -\item[commandlog] displays the status of the commandlog. -\item[commandlog close] closes the commandlog file. -\item[commandlog auto] Switches automatic log file creation on. This is normally switched on. -Log files are written to the log directory of the instrument account. There - are time stamps any hour in that file and there is a new file any 24 hours. -\end{description} - -% html: End of file: `commandlog.htm' -% html: Beginning of file: `optimise.htm' - -\section{The Peak Optimiser} - -\label{f12} - -In instrument control the need arises to optimise a peak with respect to -several variables. Optimising means finding the maximum of the peak with -respect to several variables. - This is usefull during instrument calibration. -Four circle diffractometers use this facility on a day to day basis -for finding and verifying the exact position of reflections. In order to -support both usages a more general module has been implemented. The way of -operation is like this: -\begin{verbatim} -while errors gt precision and cycles lt maxcycles - for all variables - do a scan - Try find the maximum, two halfwidth points and the peak center. - if failure extend the scan. - if success shift the variable, remember last shift. - If shift lt precicison mark this variable as done - end for -end while -\end{verbatim} -Possible outcomes of this procedure are: success, the peak was lost or the -maximum number of cycles was reached. This routine requires that the -instrument is currently placed somewhere on the peak and not miles away. - -The Peak Optimiser is implemented as an object with the name opti. It -understand the following commands: -\begin{description} -\item[opti clear] clears the optimiser. -\item[opti addvar name step nStep precision] This command adds a variable to optimise to the optimiser. The user has -to specify the name of the variable, the step width to use for scanning, the -number of steps needed to cover the full peak when scanning and the -precision which should be achieved when optimising the peak. The step width -and number of steps parameters should cover the whole peak. However, the -Optimiser will extend the scan is the specified range is not sufficient. -\item[opti run] Starts the optimiser. It will then optimise the peak. This may take some -time. -\end{description} - The behaviour of the optimiser can be configured by modifying some -parameters. The synatx is easy: {\bf opti parameter} prints the value of the -parameter, {\bf opti parameter newval} sets a new value for the parameter. -The following parameters are supported: -\begin{description} -\item[maxcycles] The maximum number of cycles the optimiser will run when trying to -optimise a peak. The default is 7. -\item[threshold] When a peak cannot be identified after a scan on a variable, the -optimiser will check if there is a peak at all. In order to do that it -searches for a count rate higher then the threshold parameter. If such a -rate cannot be found the optimiser will abort and complain that he lost the -peak. -\item[channel] The counter channel to use for scanning. The default is to use the -counter. By modifying this parameter, the optimiser can optimise on a -monitor instead. -\item[countmode] The counting mode to use when scanning. Possible values are {\bf timer} or -{\bf monitor}. -\item[preset] The preset value to use for counting in the scan. Depending on the -status of the countmode parameter this is either a preset time or a preset -monitor. -\end{description} - -% html: End of file: `optimise.htm' -% html: Beginning of file: `token.htm' - -\section{The Token Command} - -\label{f5} - -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 -looking at things. A token can be released manully 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: -\begin{description} -\item[token grab] Reserves control over the instrument to the client isssuing this -command. Any other client cannot control the instrument now. However, other -clients are still able to inspect variables. -\item[token release] Releases the control token. Now any other client can control the -instrument again. Or grab the control token. -\item[token force password] 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. -\end{description} - -% html: End of file: `token.htm' -% html: Beginning of file: `topscan.htm' - -\chapter{The Scan Command } - -\label{f13} - - -The general idea of the scan object for TOPSI is, that you configure the -scan by typing commands at the command line. Once, the configuration is -finished the requested scan is started. A data file will be written -automatically to the default location. The scan command can not only scan -over motors but also about some variables which relate to motors. For -instance lamda for the wavelength. Scan can scan over more then one variable. -The syntax of the scan command in some detail: -\begin{description} -\item[scan clear] Clears current scan parameters. -\item[scan list] lists current scan parameters. -\item[ scan var name start step] Defines a variable (motor) to be scanned. The name of the variable, a - start value and a stpe width need to be given. More then one scan variable -can be specified. -\item[ scan modvar name start step] Modifies the scan parameters for scan variable name to the new values -given. -\item[scan getvars] Returns a list of currently active scan variables terminated with the - string -END-. -\item[ scan NP num ] Sets the number of scan points. -\item[ scan Preset val] Sets the Preset value for the scan. Without a parameter, inquires the -current value. -\item[ scan Mode val] Sets the count mode for the scan. Without a parameter, inquires the -current value. Possible values are Timer or Monitor. -\item[ scan run ] Executes the scan. -\item[scan cinterest] This call enables automatic printing of scan counts to your connection -when new values arise. This command is primariliy of interest for status display -clients. -\item[scan pinterest] This function makes the scan command send a notification (the string -ScanVarChange) to you whenever the scan variables get modified. This command -is primarily of interest for status display clients. -\end{description} - -\section{ Center Scan } - - - -Center scan is a convenience command which starts a scan around a specified -center value. This mostly used for centering purposes. The syntax is like this: -\begin{quotation} -cscan var center delta np preset\end{quotation} -All parameters must be specified. The parameters and their meanings: -\begin{itemize} -\item {\bf var} is the varibale which is to be center scanned. -Only one can be specified. -\item {\bf center} is the value to use as center of the scan. -\item {\bf delta} is the step width to use for the scan. -\item {\bf np} is the number of points to scan in each direction. -\item {\bf preset} is the preset to use for the counter. As the counter mode, -the mode currently configured active in the scan object is used. -\end{itemize} - -\section{ Simple Scan } - - - -Simple scan is a convenience command which starts a scan for one to several -variables with a simplified syntax. The syntax is like this: -\begin{quotation} -sscan var1 start end var2 start end ... np preset\end{quotation} -All parameters must be specified. The parameters and their meanings: -\begin{itemize} -\item {\bf var1 start end} This is how the variables to scan are specified. For -each variable scanned a triplet must be given which consists of the name of the -variable, the start value and the end value of the scan. More then one triplet -can be given in order to allow for several scan variables. -\item {\bf np} is the number of points to scan in each direction. -\item {\bf preset} is the preset to use for the counter. As the counter mode, -the mode currently configured active in the scan object is used. -\end{itemize} - -\section{Peak And Center} - - - -These two commands are related to the scan command insofar as they act upon -the results of the last scan still in memory. The command {\bf peak} prints -the position, FWHM and maximum value of the peak in the last scan. The - command {\bf center} drives the first scan variable to the peak center of the - last scan. Both peak and center use a rather simple but effective method for - locating peaks. The prerequisite is that the peak is about gauss shaped. The - algorithm first locates the peak maximum. Then it goes to the left and - right of the maximum and tries to find the points of half maximum peak height. - The two points are interpolated from the data and the peak position - calculated as the middle point between the two halfheight points. -% html: End of file: `topscan.htm' -% html: Beginning of file: `tophw.htm' - -\chapter{TOPSI Hardware Devices} - -\label{f14} - - -TOPSI controls a couple of : -\begin{itemize} -\item motors (cf.\ Section~\ref{f15}). -counter box (cf.\ Section~\ref{f16}) for -reading monitors. -\item and various -environment.htm (cf.\ Section~\ref{f17}) control devices. -\end{itemize} -Each of these -devices understands commands. The syntax understood by each of these devices -will be discussed. - - -% html: End of file: `tophw.htm' -% html: Beginning of file: `motor.htm' - -\section{SICS motor handling} - -\label{f15} - - - In SICS each motor is an object with a name. Motors may take commands which basically come in the form {\em 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. {\em Motorname parametername } will print the current value of the variable. {\em 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: -\begin{itemize} -\item {\bf Motorname list } gives a listing of all motor parameters. -\item {\bf Motorname reset } resets the motor parameters to default values. - This is software zero to 0.0 and software limits are reset to hardware -limits. -\item {\bf Motorname position} prints the current position of the motor. -\item {\bf Motorname interest} initiates automatic printing of any position -change of the motor. This command is mainly interesting for implementors of -status display clients. -\end{itemize} - Please note that the actual driving of the motor is done via the drive (cf.\ Section~\ref{f9}) command. - - -\subsection{The motor parameters} - - -\begin{itemize} -\item {\bf HardLowerLim } 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. -\item {\bf HardUpperLim } 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. -\item {\bf SoftLowerLim } is the software lower limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftUpperLim } is the software upper limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftZero } defines a software zero point for the motor. All further movements will be in respect to this zeropoint. -\item {\bf Fixed } can be greater 0 for the motor being fixed and less -or equal than zero for the motor being movable. -\item {\bf InterruptMode } 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. Other 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. -\item {\bf Precision } denotes the precision to expect from the motor in positioning. Can usually only be set by managers. -\item {\bf AccessCode } 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. -\item {\bf Speed }, defunct. -\item {\bf Sign } 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. -\end{itemize} - - -% html: End of file: `motor.htm' -% html: Beginning of file: `counter.htm' - -\section{SICS counter handling} - -\label{f16} - - - This section deals with the SICS interface to single counters. -Where the SICS counter concept may include several monitors per -counter. A counter is, again, a named object which takes commands. -A word or two has to be lost about the SICS handling of preset values for counters. -Two modes of operation have to be distinguished: counting until a timer has passed, -for example: count for 20 seconds. This mode is called timer mode. In the other -mode, counting is continued until a control monitor has reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - The commands understood are: -\begin{itemize} -\item {\bf countername SetPreset val } sets the counting preset to val. -\item {\bf countername GetPreset } prints the current preset value. -\item {\bf countername SetExponent val } sets the exponent for the counting -preset in monitor mode to val. -\item {\bf countername GetExponent } prints the current exponent used -in monitor mode. -\item {\bf countername SetMode val } sets the counting mode to val. Possible values are Timer for timer mode operation and Monitor for waiting for a monitor to reach a certain value. -\item {\bf countername GetMode } prints the current mode. -\item {\bf countername GetCounts } prints the counts gathered in the last run. -\item {\bf countername GetMonitor n } prints the counts gathered in the monitor number n in the last run. -\item {\bf countername Count preset } starts counting in the current mode and the the preset preset. -\item {\bf countername status } prints a message containing the preset and -the current monitor or time value. Can be used to monitor the progress of -the counting operation. -\item {\bf countername gettime } Retrieves the actual time the counter -counted for. This excludes time where there was no beam or counting was -paused. -\item {\bf countername getthreshold m} retrieves the value of the threshold - set for the monitor number m. -\item {\bf countername setthreshold m val} sets the threshold for monitor m - to val. WARNING: this also makes monitor m the active monitor for evaluating - the threshold. Though the EL7373 counterbox does not allow to select the - monitor to use as control monitor in monitor mode, it allows to choose - the monitor used for pausing the count when the count rate is below the - threshold (Who on earth designed this?) -\end{itemize} - -% html: End of file: `counter.htm' -% html: Beginning of file: `topdev.htm' - -\chapter{TOPSI Device list} - -\label{f18} - - -\section{ Motors } - - - -\begin{description}\item[BeamStopX] this motor controls the vertical movement of the beam stop. -\end{description} -With all these names, this chapter must be written by Daniel Clemens. - -\section{Counters } - - - -There is only one named counter. - -\section{Variables} - - - -\begin{description}\item[Instrument] holds the name of the Instrument, in SANS case: {\tt{}"{}}SANS at SINQ, PSI{\tt{}"{}}. -This cannot be changed by ordinary members of the public. -\item[Title] the title of the instrument. This will be written to the output file. -Should be set by the user to something sensible. -\item[User] the user of the instrument. This will be written to the output file. -Should be set by the user to something sensible. -\item[Comment1] one line of comment to be written to the outputfile. -Should be set by the user to something sensible. -\item[Comment2] another line of comment to be written to the outputfile. -Should be set by the user to something sensible. -\item[environment] a line of text describing special environment conditions to be written -to the output file. This is for those cases where the sample environment is not -computer controlled and therefore not visible to the program. Users are -responsible for filling this in. -\end{description} - -% html: End of file: `topdev.htm' -% html: Beginning of file: `samenv.htm' - -\chapter{ Sample Environment Devices} - -\label{f17} - - -\section{SICS Concepts for Sample Environment Devices} - -\label{f17:concept} - -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 continously. Therefore there -exists a facility for dynamically configuring and deconfiguring environment -devices into the system. This is done via the {\bf EVFactory} command. -It is expected that instrument scientists will provide command procedures or -specialised R\"unbuffers 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 {\bf emon}. The emon understands a few commands of its -own. - -Within SICS all sample environement 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 section the EVFactory, emon and the general commands understood -by any sample environment device will be discussed. This reading is mandatory -for understanding SICS environment device handling. Then there will be another -section discussing the special devices known to the system. - - -\section{SampleEnvironment Error Handling} - - -A \label{f17:error}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 differntiated. The SICS model therefore implements several -strategies for handling sample environment device failure handling. -The strategy to use is selected via 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: -\begin{description} -\item[Lazy] Just print a warning and continue. -\item[Pause] Pauses the measurement until the problem has been resolved. -\item[Interrupt] Issues a SICS interrupt to the system. -\item[Safe] Tries to run the environment device to a value considered safe by the -user. -\end{description} - -\section{General Sample Environment Commands} - -\label{f17:general} - -\subsection{EVFactory} - - - -EVFactory is responsible for configuring and deconfiguring sample environment -devices into SICS. The syntax is simple: -\begin{description} -\item[EVFactory new name type par par ...] Creates a new sample environment device. It will be known to SICS by the -name specified as second parameter. 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. -\item[EVFactory del name] Deletes the environment device name from the system. -\end{description} - -\subsection{emon} - - - -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. -\begin{description} -\item[emon list] This command lists all environment devices currently registered in the -system. -\item[emon register name] 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. -\item[emon unregister name] This is a specialist command which unregisters the environment device name -with the environment monitor. Usually this will automatically be taken care -of by EVFactory Following this call the device will no longer be monitored and -out of tolerance errors on that device no longer be handled. -\end{description} - -\subsection{General - Commands UnderStood by All Sample Environment Devices} - -\label{f17:all} - -Please note that each command discussed below MUST be prepended with the name -of the environment device as configured in EVFavtory! - -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: -\begin{quotation} -Temperature Tolerance\end{quotation} -prints the value of the variable Tolerance for the environment controller -Temperature. -\begin{quotation} -Temperature Tolerance 2.0\end{quotation} -sets the parameter Tolerance for Temperature to 2.0. Parameters known to ANY -envrironment controller are: -\begin{description} -\item[Tolerance] Is the deviation from the preset value which can be tolerated before an -error is issued. -\item[ Access] Determines who may change parameters for this controller. -Possible values are: -\begin{itemize} -\item 0 only internal -\item 1 only Managers -\item 2 Managers and Users. -\item 3 Everybody, including Spy. -\end{itemize} -\item[LowerLimit] The lower limit for the controller. -\item[UpperLimit] The upper limit for the controller. -\item[ErrHandler.] The error handler to use for this controller. Possible values: -\begin{itemize} -\item 0 is Lazy. -\item 1 for Pause. -\item 2 for Interrupt -\item 3 for Safe. -\end{itemize} - For an explanantion of these values see the section about error (cf.\ Section~\ref{f17:error}) handling -above. -\item[ Interrupt] The interrupt to issue when an error is detected and Interrupt error -handling is set. Valid values are: -\begin{itemize} -\item 0 for Continue. -\item 1 for abort operation. -\item 2 for abort scan. -\item 3 for abort batch processing. -\item 4 halt system. -\item 5 exit server. -\end{itemize} -\item[SafeValue] The value to drive the controller to when an error has been detected and -Safe error handling is set. -\end{description} - -Additionally the following commands are understood: -\begin{description} -\item[send par par ...] 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 -calibrartion tables etc. -\item[ list] lists all the parameters for this controller. -\item[ no command, only name.] When only the name of the device is typed it will return its -current value. -\item[ name val ] will drive the device to the new value val. Please note that the same -can be achieved by using the drive command. -\item[ name log on] 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! Log clear frees it again -and log frequency (both below) allows to set the logging time intervall. -\item[ name log off] Switches logging off. -\item[name log clear] Clears all recorded time stamps and values. -\item[name log gettime] This command retrieves a list of all recorded time stamps. -\item[name log getval] This command retrieves all recorded values. -\item[name log getmean] Calculates the mean value and the standard deviation for all logged -values and prints it. -\item[name log frequency val] With a parameter 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 any - cycle of the SICServer. - \end{description} - -\section{Special Environment Control Devices} - - - -This section lists the parameters needed for configuring a special environment -device into the system and special parameters and commands only understood by -that special device. All of the general commands listed above work as well! - -\subsection{ITC-4 and ITC-503 Temperature Controllers} - -\label{f17:itc4} - -These temperature controller are fairly popular at SINQ. It is manufactured by -Oxford Instruments. At the back side of this controller there is a RS-232 -socket which must be connected to a Macintosh computer running the SINQ -terminal server program via a serial cable. Please make sure with a different -Macintosh or a PC that the serial line is OK and the ITC-4 responding before -plugging it in. - -\subsubsection{ITC-4 Initialisation} - - - -An ITC-4 can be configured into the system by: -\begin{quotation} -EVFactory new Temp ITC4 computer port channel\end{quotation} -This creates an ITC-4 controller object named Temp within the system. The -ITC-4 is expected to be connected to the serial port channel at the -Macintosh computer computer running the SINQ terminal server program -listening at port port. For example: -\begin{quotation} -EVFactory new Temp ITC4 lnsp22.psi.ch 4000 6\end{quotation} -connects Temp to the Macintosh named lnsp22, serial port 5 (6 above is no typo!), - listening at port 4000. - -\subsubsection{ITC-4 Additional Parameters} - - - -The ITC-4 has a few more parameter commands: -\begin{description} -\item[timeout] Is the timeout for the Macintosh terminal server program waiting for -responses from the ITC-4. Increase this parameter if error messages -containg ?TMO creeping up. -\item[ sensor] Sets the sensor number to be used for reading temperature. -\item[ control] Sets the control sensor for the ITC-4. This sensor will be used -internally for regulating the ITC-4. -\item[divisor] The ITC4 does not understand floating point numbers, the ITC-503 does. -In order to make ITC4's read and write temperatures correctly floating point -values must be multiplied or divided with a magnitude of 10. This parameter -determines the appropriate value for the sensor. Is usually 10 for a sensor -with one value behind the comma or 100 for a sensor with two values after -the comma. -\item[multiplicator] The same meaning as the divisor above, but for the control sensor. -\end{description} - -\subsubsection{Installing an ITC4 step by step} - - - -\begin{enumerate}\item Connect the ITC temperature controller to port 6 on the Macintosh -serial port extension box. Port 6 is specially configured for dealing with -the ideosyncracies of that device. No null modem is needed. -\item Install the ITC4 into SICS with the command: \newline -evfactory new name Macintoshname 4000 7\newline -Thereby replace name with the name you want to address the ITC4 in SICS. A -good choice for a name is temperature, as such a value will be written to data files. -Please note, that SICS won't let you use that name if it already exists. For -instance if you already had a controller in there. Then the command:\newline -evfactory del name \newline -will help. Macintoshname is the name of the instrument Macintosh PC. -\item Configure the upper and lowerlimits for your controller appropriatetly. -\item Figure out which sensor you are going to use for reading temperatures. -Configure the sensor and the divisor parameter accordingly. -\item Figure out, which sensor will be used for controlling the ITC4. Set the -parameters control and multiplicator accordingly. Can be the same as the -sensor. -\item Think up an agreeable temperature tolerance for your measurement. This -tolerance value will be used 1) to figure out when the ITC4 has reached its -target position. 2) when the ITC4 will throw an error if the ITC4 fails to -keep within that tolerance. Set the tolerance parameter according to the -results of your thinking. -\item Select one of the numerous error handling strategies the control -software is able to perform. Configure the device accordingly. -\item Test your setting by trying to read the current temperature. -\item If this goes well try to drive to a temperature not to far from the -current one. -\end{enumerate} - -\subsubsection{ITC-4 Trouble Shooting} - - - -If the ITC-4 {\bf does not respond at all}, make sure the serial connection to -the Macintosh is working. Use standard RS-232 debugging procedures for doing -this. The not responding may also come up as a failure to connect to the ITC-4 -during startup. - - If error messages containing the string {\bf ?TMO} keep creeping up followed -by all signs of command not understood, then increase the timeout. The standard -timeout of 10 microseconds is to short at times. - -You keep on reading {\bf wrong values} from the ITC4. Mostly off by a -factor 10. Then set the divisor correctly. Or you may need to choose a -decent sensor for that readout. - -Error messages when {\bf trying to drive the ITC4}. These are usually the -result of a badly set multiplicator parameter for the control sensor. - -The ITC4 {\bf never stops driving}. There are at least four possible -causes for this problem: -\begin{enumerate} -\item The multiplicator for the control sensor was wrong and the ITC4 has now -a set value which is different from your wishes. You should have got error -messages then as you tried to start the ITC4. -\item The software is reading back wrong temperature because the sensor and -divisor parameters are badly configured. Try to read the temperature and if -it does have nothing to do with reality, set parameters accordingly. -\item The tolerance parameter is configured so low, that the ITC4 never -manages to stay in that range. Can also be caused by inappropriate PID -parameters in the ITC4. -\item -You are reading on one sensor (may be 3) and controlling on another one (may -be 2). Then it may happen that the ITC 4 happily thinks that he has reached -the temperature because its control sensor shows the value you entered as -set value. But read sensor 3 still thinks he is far off. The solution is to -drive to a set value which is low enough to make the read sensor think it is -within the tolerance. That is the temperature value you wanted after all. -\end{enumerate} - -\subsection{Haake Waterbath Thermostat} - -\label{f17:haake} - -This is sort of a buck full of water equipped with a temperature -control system. The RS-232 interface of this device can only be operated at -4800 baud max. This is why it has to be connected to the serial printer port -of the Macintosh serial port server computer. This makes the channel number to -use for initialisation a 1 always. The driver for this device has been -realised in the Tcl extension language of the SICS server. A prerequisite -for the usage of this device is that the file hakle.tcl is sourced in the -SICS initialisation file and the command inihaakearray has been published. - Installing the -Haake into SICS requires two steps: first create an array with -initialisation parameters, second install the device with evfactory. A -command procedure is supplied for the first step. Thus the initialisation -sequence becomes: -\begin{quotation} -inihaakearray name-o-array macintosh-computer name port channel\newline -evfactory new temperature tcl name-of-array\end{quotation} -An example for the SANS: -\begin{quotation} -inihaakearray eimer lnsp25.psi.ch 4000 1 \newline -evfactory new temperature tcl eimer\end{quotation} -Following this, the thermostat can be controlled with the other environment -control commands. - -The Haake Thermostat understands a single special subcommand: {\bf sensor}. -The thermostat may be equipped with an external sensor for controlling and -reading. The subcommand sensor allows to switch between the two. The exact -syntax is: -\begin{quotation} -temperature sensor val\end{quotation} -val can be either intern or extern. - -\subsection{Dilution Cryostat} - -\label{f17:dilu} - -This is a large ancient device for reaching very low temperatures. This -cryostat can be configured into SICS with the command: -\begin{verbatim} -EVFactory new Temp dillu computer port channel table.file -\end{verbatim} -Temp is the name of the dilution controller command in SICS, dillu is the -keyword which selects the dilution driver, computer, port and channel are -the parameters of the Macintosh-PC running the serial port server program. -table.file is the fully qualified name of a file containing a translation -table for this cryostat. The readout from the dilution controller is a -resistance. This table allows to interpolate the temperature from the -resistance measurements and back. Example: -\begin{verbatim} -evfactory new temperature dillu lnsp19.psi.ch 4000 1 dilu.tem -\end{verbatim} -installs a new dilution controller into SICS. This controller is connected -to port 1 at the Macintos-PC with the newtwork adress lnsp19.psi.ch. On this -macintosh-PC runs a serial port server program listening at TCP/IP port -4000. The name of the translation table file is dilu.tem. - -The dilution controller has no special commands, but two caveats: As of -current (October 1998) setting temperatures does not work due to problems -with the electronics. Second the dilution controller MUST be connected to -port 1 as only this port supports the 4800 maximum baud rate this device -digests. - -\subsection{Bruker Magnet Controller B-EC-1} - -\label{f17:bruker} - -This is the Controller for the large magnet at SANS. The controller is a -box the size of a chest of drawers. This controller can be operated in one -out of two modes: in {\bf field} mode the current for the magnet is controlled via -an external hall sensor at the magnet. In {\bf current} mode, the output current -of the device is controlled. This magnet can be configured into SICS with a -command syntax like this: -\begin{quotation} -evfactory new name bruker Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion (which will be used throughout the rest of the text) is magnet. -bruker is the keyword for selecting the bruker driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at SANS): -\begin{verbatim} -evfactory new magnet bruker lnsp25.psi.ch 4000 9 -\end{verbatim} - -creates a new command magnet for a Bruker magnet Controller connected to -serial port 9 at lnsp25. -In addition to the standard environment controller commands this magnet -controller understands the following special commands: -\begin{description} -\item[magnet polarity] Prints the current polarity setting of the controller. Possible -answers are plus, minus and busy. The latter indicates that the controller -is in the process of switching polarity after a command had been given to -switch it. -\item[magnet polarity val] sets a new polarity for the controller. Possible values for val are -{\bf minus} or {\bf plus}. The meaning is self explaining. -\item[magnet mode] Prints the current control mode of the controller. Possible -answers are {\bf field} for control via hall sensor or {\bf current} for -current control. -\item[magnet mode val] sets a new control mode for the controller. Possible values for val are -{\bf field} or {\bf current}. The meaning is explained above. -\item[magnet field] reads the magnets hall sensor independent of the control mode. -\item[magnet current] reads the magnets output current independent of the control mode. -\end{description} - -Warning: There is a gotcha with this. If you type only magnet a -value will be returned. The meaning of this value is dependent on the -selected control mode. In current mode it is a current, in field mode it is -a magnetic field. This is so in order to support SICS control logic. -You can read values at all times explicitly using magnet current or -magnet field. - -\subsection{The CryoFurnace.} - -\label{f17:ltc11} - -The CryoFurnace at PSI is equipped with a Neocera LTC-11 temperature -controller. This controller can control either an heater or an analag output -channel. Futhermore a choice of sensors can be selected for controlling the -device. The LTC-11 behaves like a normal SICS environment control device -plus a few additional commands. An LTC-11 can be configured into SICS with -the following command: -\begin{quotation} -evfactory new name ltc11 Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -ltc11 is the keyword for selecting the LTC-11 driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at DMC): -\begin{verbatim} -evfactory new temperature ltc11 lnsp18.psi.ch 4000 6 -\end{verbatim} - -creates a new command magnet for a LTC-11 temperature Controller connected to -serial port 6 at lnsp18. - -The additional commands understood by the LTC-11 controller are: -\begin{description} -\item[temperature sensor ] allows to query the current sensor used for temperature readout. -\item[temperature sensor val ] allows to select the sensor val for temperature readout. -\item[temperature controlanalog ] allows to query the sensor used for controlling the analog channel. -\item[temperature controlanalog val ] allows to select the sensor val for controlling the analog channel. -\item[temperature controlheat ] allows to query the sensor used for controlling the heater channel. -\item[temperature controlheat val ] allows to select the sensor val for controlling the heater channel. -\item[temperature mode] Allows to query if the LTC-11 controls the analog or heater channel. -\end{description} - -Further notes: As the CryoFurnace is very slow and the display at the -controller becomes unusable when the temperature is read out to often, the -LTC-11 driver buffers the last temperature read for 5 seconds. Setting the -mode of the LTC-11 is possible by computer, but not yet fully understood and - therefore unusable. - -\subsection{The Eurotherm Temperature Controller} - -\label{f17:euro} - -At SANS there is a Eurotherm temperature controller for the sample heater. - This and probably other Eurotherm controllers can be configured into SICS -with the following command. The eurotherm needs to be connected with a - nullmodem adapter. -\begin{quotation} -evfactory new name euro Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -euro is the keyword for selecting the Eurotherm driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. {\bf WARNING:} The eurotherm needs a RS-232 port with an unusual - configuration: 7bits, even parity, 1 stop bit. Currently only the SANS - Macintosh port 13 (the last in the upper serial port connection box) is - configured like this! Thus, an example for SANS and the name temperature - looks like: -\begin{verbatim} -evfactory new temperature euro lnsp25.psi.ch 4000 13 -\end{verbatim} - -There are two further gotchas with this thing: -\begin{itemize} -\item The eurotherm needs to operate in the EI-bisynch protocoll mode. This has -to be configured manually. For details see the manual coming with the machine. -\item The weird protocoll spoken by the Eurotherm requires very special control - characters. Therefore the send functionality usually supported by a SICS - environment controller could not be implemented. -\end{itemize} - -% html: End of file: `samenv.htm' -% html: Beginning of file: `trouble.htm' - -\chapter{SICS Trouble Shooting } - -\label{f1} - - -There is no such thing as bug free software. There are always bugs, nasty -behaviour etc. This document shall help to solve these problems. The usual -symptom will be that a client cannot connect to the server or the server is -not responding. - -An essential prerequisite of SICS is that the server is 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: -\begin{verbatim} -startsics -\end{verbatim} -at the command prompt. startsics actually starts two programs: one is -the replicator application which is responsible for the automatic -copying of data files to the laboratory server. The other is the SICS -server. Both programs are started by means of a shell script called -{\bf keepalive}. keepalive is basically an endless loop which calls -the program again and agaian and thus ensures that the program will -never stop running. - - When the SICS server hangs, or you want to enforce an reinitiliazation of -everything the server process must be killed. The first thing to -do is to find the process. - -\section{Finding the SICS server} - - - -Log in as Instrument user on the instrument computer (for instance DMC on -lnsa05). Type the command: -\begin{verbatim} -/home/DMC> ps -A -\end{verbatim} -Note the capital A given as parameter. The reward will be listing like this: -\begin{verbatim} - 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 -\end{verbatim} -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 ?? } an entry for the SICS server. In this example the server -is running. If the server is down, no such entry would be present. - -\section{ Killing a hanging SICS server } - - - -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} 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}. Please note, that this number will -always be different. The command to force the server to stop is: -\begin{verbatim} -/home/DMC> kill -9 31912 -\end{verbatim} -Note, the second parameter is the number found with {\tt ps -A}. 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. - -\section{ Shutting the SICS server down completely} - - - -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 {\bf keepalive SICServer }. Kill that one as -described above, then kill the SICServer. For restarting SICS after this, -use the startsics command. - -\section{Restart Everything} - - - -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. -\begin{enumerate} -\item Reboot the Macintosh PC by switching it off at the silver button on the -left. Press deep and a few seconds to achieve an effect. The LED right to the -button should be off, before you press again to boot the Macintosh. -\item 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. -\item Wait 5 minutes. The Macintosh may take that time to come up again. -\item Restart the SICServer. Watch for any messages about things not being -connected or configured. -\item Restart and reconnect the client programs. -\end{enumerate} -If this fails (even after a second) time there may be a network problem which -can not be resolved by simple means. - -\section{ HELP debugging!!!!} - - - -The SICS server hanging or crashing should not happen. In order to sort such -problems out it is very helpful if any available debugging information is -saved and presented to the programmers. Information available are the log -files as written continously by the SICS server and posssible core files -lying around. They have just this name: core. In order to save them create a -new directory (for example dump2077) and copy the stuff in there. This looks -like: -\begin{verbatim} -/home/DMC> mkdir dump2077 -/home/DMC> cp log/*.log dump2077 -/home/DMC> cp core dump2077 -\end{verbatim} -The {\tt /home/DMC> } is just the command prompt. Please note, that core -files are only available after crashes of the server. These few commands -will help to analyse the cause of the problem and to eventually resolve it. -% html: End of file: `trouble.htm' -% html: Beginning of file: `topco.htm' - -\chapter{TOPSI Command Summary} - -\label{f19} - - - -\section{Most Used Commands} - - -\begin{description} -\item[drive mot1 NewVal mot2 NewVal ....] (cf.\ Section~\ref{f9}) Drives motors. Followed by pairs of motor names and new values. -\item[scan clear] Clears current scan parameters. -\item[scan list] lists current scan parameters. -\item[ scan var name start step] Defines a variable (motor) to be scanned. The name of the variable, a - start value and a stpe width need to be given. More then one scan variable -can be specified. -\item[ scan np num ] Sets the number of scan points. -\item[ scan preset val] Sets the Preset value for the scan. Without a parameter, inquires the -current value. -\item[ scan mode val] Sets the count mode for the scan. Without a parameter, inquires the -current value. Possible values are Timer or Monitor. -\item[ scan run ] Executes the scan. -\item[cscan var center delta np preset] does a scan center scan for variable var around center. delta is the -step width to use, np is the number of points to collect at each side, preset -is the preset to use. -\item[ sscan var1 start end var2 start end .... np preset] simplified scan command. Scans variables var1, var2 .. from the -respective start values to the end values. Using np points and a preset of -preset. -\item[FileEval filename] (cf.\ Section~\ref{f7}) Runs the batch file specified as argument filename. -\end{description} - -\section{Driving} - - - -\begin{description}\item[drive mot1 NewVal mot2 NewVal ....] (cf.\ Section~\ref{f9}) Drives motors. Followed by pairs of motor names and new values. -\item[run mot1 NewVal mot2 NewVal ....] Runs motors. -\end{description} -Known motors are: OmegaA, A1, TwoThetaM, A2, MonoX, MonoY, MonoChi, MonoPhi, -CurveM, Table, A3, TwoThetaD, A4. - -\section{ Counting } - - - -\begin{description}\item[counter SetMode mode] Sets the mode of the counter. Possible parameters for mode are Timer -and Preset. -\item[counter GetMode] Prints the current counting mode of the counter. -\item[counter SetPreset val] Sets a new preset for the counter -\item[counter GetPreset] Prints the current value of preset. -\item[counter SetExponent val] Sets a new expoenent for the preset in monitor mode. -\item[counter GetExponent] Prints the current value of exponent. -\item[ counter Count preset] Starts counting with the preset value specified. -\item[counter GetCounts] Inquires the last counts measured. -\item[ counter GetMonitor n] Gets the last value measured in monitor n. -\end{description} - -\section{ Scan (cf.\ Section~\protect\ref{f13}) } - - - -\begin{description}\item[scan clear] Clears current scan parameters. -\item[scan list] lists current scan parameters. -\item[ scan var name start step] Defines a variable (motor) to be scanned. The name of the variable, a - start value and a stpe width need to be given. More then one scan variable -can be specified. -\item[ scan NP num ] Sets the number of scan points. -\item[ scan Preset val] Sets the Preset value for the scan. Without a parameter, inquires the -current value. -\item[ scan Mode val] Sets the count mode for the scan. Without a parameter, inquires the -current value. Possible values are Timer or Monitor. -\item[ scan run ] Executes the scan. -\item[cscan var center delta np preset] does a scan center scan for variable var around center. delta is the -step width to use, np is the number of points to collect at each side, preset -is the preset to use. -\item[ sscan var1 start end var2 start end .... np preset] simplified scan command. Scans variables var1, var2 .. from the -respective start values to the end values. Using np points and a preset of -preset. -\end{description} - -\section{R\"unbuffer} - - - -\begin{description}\item[ Buf new name] (cf.\ Section~\ref{f8}) New buffer name -\item[Buf copy name1 name2] copies buffers. -\item[Buf del name] deletes buffer. -\end{description} -Buffers created with Buf new name are installed as command name and understand: -\begin{description} -\item[NAME append bla bla .......] Append text to buffer -\item[NAME del iLine] Deletes line. -\item[ NAME ins iLine bla bla ....] Inserts text after line. -\item[NAME print] prints contents of buffer to screen. -\item[NAME save file] Saves buffer to file. -\item[NAME read file] Read buffer contents from file. -\item[NAME run] Executes contents of buffer. -\end{description} -There can be a stack of R\"unbuffers. -\begin{description} -\item[RuLi add buffer] Adds an buffer to the stack. -\item[RuLi list] Lists the stack. -\item[RuLi del line] Deletetes buffer from stack. -RuLi ins iLine name - Inserts name after iLine. -\item[ RuLi run] Executes Stack. -\item[ RuLi batch] Executes stack permanently. New buffers may be added. -\end{description} - -\section{ General commands } - - - -\begin{description}\item[Success] (cf.\ Section~\ref{f9}) wait for the last operation to finish. -\item[wait time] (cf.\ Section~\ref{f4}) wait for time to pass.... -\item[Dir ] (cf.\ Section~\ref{f4}) lists all objects in the system. -\item[config Rights username password] (cf.\ Section~\ref{f6}) changes authorisation to that of the user identified by username, -password. -\item[FileEval filename] (cf.\ Section~\ref{f7}) executes batch file filename. -\end{description} - -\section{ LogBook} - - - -\begin{description}\item[LogBook file name] (cf.\ Section~\ref{f10}) sets log file name -\item[ LogBook on] switches logging on -\item[LogBook off] closes LogBook -\item[LogBook] lists current logging status -\end{description} - -\section{ Variables} - - - -Each variable - can be inquired by just typing its name. It can be set by -typing the name followed by the new value. Currently available variables -are: -\begin{itemize} -\item Title -\item User -\item comment1 -\item comment2 -\item comment3 -\item User -\item adress -\item phone -\item email -\item sample -\end{itemize} - -% html: End of file: `topco.htm' - -\end{document} \ No newline at end of file diff --git a/doc/user/tricsman.tex b/doc/user/tricsman.tex deleted file mode 100644 index 90dbea6a..00000000 --- a/doc/user/tricsman.tex +++ /dev/null @@ -1,1884 +0,0 @@ -\documentclass[12pt,a4paper]{report} -%%\usepackage[dvips]{graphics} -%%\usepackage{epsf} -\setlength{\textheight}{24cm} -\setlength{\textwidth}{16cm} -\setlength{\headheight}{0cm} -\setlength{\headsep}{0cm} -\setlength{\topmargin}{0cm} -\setlength{\oddsidemargin}{0cm} -\setlength{\evensidemargin}{0cm} -\setlength{\hoffset}{0cm} -\setlength{\marginparwidth}{0cm} - -\begin{document} -\begin{center} -\begin{huge} -TRICS--Reference Manual \\ -\end{huge} -Version November, 1998\\ -Dr. Mark K\"onnecke \\ -Labor f\"ur Neutronenstreuung\\ -Paul Scherrer Institut\\ -CH--5232 Villigen--PSI\\ -Switzerland\\ -\end{center} -\clearpage -\clearpage -\tableofcontents -\clearpage - -% html: Beginning of file: `trics.htm' - -\chapter{The Four Circle Diffractometer TRICS} - -\label{f0} - - -\section{Introduction} - - -The four circle diffractometer TRICS is used for the study of crystal structures - by neutron diffraction at single crystals. TRICS can be operated in two -modes: 1.) with a single counter very much like a traditional four circle -diffractometer and 2.) with three position sensitive detectors operating -like a oscillation camera as used by protein crystallographers. The second -option has not yet been implemented due to the unavailability of suitable -detectors and electronics. This manual describes the operation of TRICS -using the SICS software. - -TRICS is situated at one of the beamlines for hot neutrons at the spallation -source SINQ at PSI, Switzerland. The incident beam first hits a -monochromator crystal. The selected wavelength is in principle fixed. A -monochromator lift with two monochromators and the possiblity to select -different reflections for diffraction at the monochromator however make it -possible to select between a few different neutron wavelength. The sample is -held in a standard eulerian cradle with the usual angles omega, chi and phi. -Up to three position sensitive detectors are held on a detector holder at -different angles in two theta. Or a single detector is fixed to this setup. -The three position sensitive detectors may be moved up and down on a sphere -around the sample. This allows to access different lattice planes when the -eulerian cradle has been replaced by some cryostat or other sample -environment devices to heavy to be used in conjunction with an eulerian -cradle. - -The control of a four circle diffractometer requires a tight integration -between measurement procedures and specialized data anlaysis software. For -the actual control of the instrument, its movements and the actual -measurement of reflections the SICS software is provided. Preliminary data - analysis and special four circle calculations are done with a set of F77 -programs. These are mostly programs which originate from the ILL, France. - -Given this setup the rest of this manual logically has to have three parts: -\begin{itemize} -\item A general part (cf.\ Section~\ref{f1}) describing the principal -operation of the SICS software. -\item A chapter describing the operation of TRICS with a - single counter (cf.\ Section~\ref{f2}). -\item A chapter describing the operation of TRICS with -position sensitive (cf.\ Section~\ref{f3}) -detectors. -\end{itemize} - -% html: End of file: `trics.htm' -% html: Beginning of file: `tricsgen.htm' - -\chapter{General Operation of the SICS instrument control software} - -\label{f1} - -This chapter contains information about: -\begin{itemize} -\item Basic SICS concepts (cf.\ Section~\ref{f5}) -\item Driving motors (cf.\ Section~\ref{f6}) -\item Configuring motor parameters (cf.\ Section~\ref{f7}). -\item TRICS motor list (cf.\ Section~\ref{f8}). -\item Counting and monitors (cf.\ Section~\ref{f9}). -\item Sample Environment Device Control (cf.\ Section~\ref{f10}). -\item Log I/O to a client logfile (cf.\ Section~\ref{f11}) at the server, all -command output to a commandlog (cf.\ Section~\ref{f12}) or to your local -machine using the open log file option in the File menu of the -SICS command line client. -\item Doing batch processing using batch files (cf.\ Section~\ref{f13}) or the LNS -specific R\"unbuffer (cf.\ Section~\ref{f14}) system. -\item {\bf Interrupt} SICS by hitting the interrupt button near the bottom of -the SICS command line client. -\item How to perform crystallographic computations (cf.\ Section~\ref{f15}) online. -\item Some specialist commands for configuring certain aspects of your -client connection (cf.\ Section~\ref{f16}) and for in depth interaction with -the SICS server (cf.\ Section~\ref{f17}). -\end{itemize} - -% html: End of file: `tricsgen.htm' -% html: Beginning of file: `basic.htm' - -\section{Basic SICS concepts} - -\label{f5} - - -\subsection{General structure} - - - - SICS is a client server system. The application the user sees is - usually some form of client. A client has two tasks: the first is to - collect user input and send it to the SICS server which then executes -the command. The clients second task is to listen to the the server - messages and display them in a readable format. This aproach has two - advantages: clients can reside on machines across the whole network - thus enabling remote control from everywhere in the world. The second - advantage is that new clients (such as graphical user interface - clients) can be written in any feasible language without changes to - the server. - -\subsection{SICS Command Syntax } - - - - SICS is an object oriented system. This is reflected in the command -syntax. SICS objects can be devices such as motors, single - counters, histogram memories or other hardware variables such as wavelength or Title and measurement procedures. Communication with these objects happens by sending messages to the target object. This is very simply done by typing something like: object message par1 par2 .. parn. For example, if we have a motor called A1:\begin{verbatim} - A1 list -\end{verbatim} - will print a parameter listing for the motor A1. In this example no parameters were needed. There exist a number of one-word commands as well. For -compatability reasons some commands have a form which resembles a function call such as:\begin{verbatim} - drive a1 26.54 -\end{verbatim} - This will drive motor a1 to 26.54. All commands are -ASCII-strings and usually in english. SICS is in general CASE INSENSITIVE. -However, this does not hold for parameters you have to specify. On a unix -system for instance file names are case sensitive and that had to be -preserved. Commands defined in the scripting language are lower case by -convention. - -\subsection{Authorisation} - - - - A client server system is potentially open to unauthorised hackers - who might mess up the instrument and your valuable measurements. A - known problem in instrument control is that less knowledgeable user - accidentally change instrument parameters which ought to be left fixed. In order to solve these two problems SICS supports authorisation on a very fine level. As a user you have to specify a username and password in order to able to access SICS. Some clients already do this for you automatically. SICS support four levels of access to an instrument: -\begin{itemize} -\item {\bf Spy } may look at everything, request any value, but may not actually change anything. No damage potential here. -\item {\bf User } is privileged to perform a certain amount of operations necessary to run the instrument. -\item {\bf Manager } has the permission to mess with almost everything. A very dangerous person. -\item {\bf Internal } is not accessible to the outside world and is used to circumvent protection for internal uses. However some parameters are considered to be so critical that they cannot be changed during the runtime of the SICS-server, not even by Managers. -\end{itemize} - All this is stated here in order to explain the common error message: You are not authorised to do that and that or something along these lines. - -\subsection{SICS variables} - - - - Most of the parameters SICS uses are hidden in the objects to which they belong. But some are separate objects of their own right and are accessible at top level. For instance things like Title or wavelength. They share a common syntax for changing and requesting their values. This is very simple: The command {\em objectname } will return the value, the command {\em objectname newvalue } will change the variable. But only if the authorisation codes match. - - -\subsection{The SICS Command Line Client} - - -The most common client for controlling SICS is the {\bf SICS command line -client}. -This application can be started by typing the command: -\begin{verbatim} -sics & -\end{verbatim} -at the Unix prompt. Before this program is ready to collaborate with you you -have to connect it to an instrument using the options in the connect -pulldown menu. The screen is roughly divided in three areas: The top area -shows all input to and output from the server. The middle area shows the -command history. At the lower end is a text entry field which allows you to type -commands to be sent to the SICS server. For more information about this client consult -the online help of this application. -% html: End of file: `basic.htm' -% html: Beginning of file: `drive.htm' - -\section{Drive commands} - -\label{f6} - - Many objects in SICS are {\bf 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 an energy. This class of objects can be operated by the {\bf drive, run, Success } family of commands. These commands cater for blocking and non-blocking modes of operation. - - {\bf run var newval var newval ... } 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 operate other devices of the instrument while perhaps a slow device is still running into position. - - {\bf Success } waits and blocks the command connection until all pending operations have finished (or an interrupt occured). - - {\bf drive var newval var newval ... } can be called with one to n pairs of object 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 immediatly followed by a Success command. -% html: End of file: `drive.htm' -% html: Beginning of file: `motor.htm' - -\section{SICS motor handling} - -\label{f7} - - - In SICS each motor is an object with a name. Motors may take commands which basically come in the form {\em 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. {\em Motorname parametername } will print the current value of the variable. {\em 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: -\begin{itemize} -\item {\bf Motorname list } gives a listing of all motor parameters. -\item {\bf Motorname reset } resets the motor parameters to default values. - This is software zero to 0.0 and software limits are reset to hardware -limits. -\item {\bf Motorname position} prints the current position of the motor. -All zero point and sign corrections are applied. -\item {\bf Motorname hardposition} prints the current position of the motor. -No corrections are applied. Should read the same as the controller box. -\item {\bf Motorname interest} initiates automatic printing of any position -change of the motor. This command is mainly interesting for implementors of -status display clients. -\end{itemize} - Please note that the actual driving of the motor is done via the drive (cf.\ Section~\ref{f6}) command. - - -\subsection{The motor parameters} - - -\begin{itemize} -\item {\bf HardLowerLim } 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. -\item {\bf HardUpperLim } 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. -\item {\bf SoftLowerLim } is the software lower limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftUpperLim } is the software upper limit. This can be defined by the user in order to restrict instrument movement in special cases. -\item {\bf SoftZero } defines a software zero point for the motor. All further movements will be in respect to this zeropoint. -\item {\bf Fixed } can be greater then 0 for the motor being fixed and less then -or equal to zero for the motor being movable. -\item {\bf InterruptMode } defines the interrupt to issue when the motor fails. Some motors are so critical for the operation of the instrument that all operations are to be stopped when there is a problem. Other 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. -\item {\bf Precision } denotes the precision to expect from the motor in positioning. Can usually only be set by managers. -\item {\bf AccessCode } 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. -\item {\bf Sign } reverses 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. -\end{itemize} - - -% html: End of file: `motor.htm' -% html: Beginning of file: `trimot.htm' - -\section{TRICS Motors} - -\label{f8} - -This chapter has still to be defined as there is a war waging in LNS about -names. Final names will be entered after the end of hostilities. More then -one name may be stated as SICS supports aliases. For now, -you have to do with: -\begin{itemize} -\item OM = A3 = omega motion of the eulerian cradle. -\item CH = chi circle of the eulerian cradle. -\item PH = phi circle of the eulerian cradle -\item TH = A4 = two theta angle of the detector. -\end{itemize} - -% html: End of file: `trimot.htm' -% html: Beginning of file: `counter.htm' - -\section{SICS counter handling} - -\label{f9} - - -A counter in SICS is a controller which operates single neutron -counting tubes and monitors. -A counter can operate in one out of two modes: counting until a timer has - passed, -for example: count for 20 seconds. Counting in this context means that the noutrons coming in during these 20 seconds are summed together. This mode is called timer mode. In the other -mode, counting is continued until a specified neutron monitor has - reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - Again, in SICS the counter is an object which understands a set of -commands: -\begin{itemize} -\item {\bf countername SetPreset val } sets the counting preset to val. -\item {\bf countername GetPreset } prints the current preset value. -\item {\bf countername preset val} With a parameter sets the preset, without inquires the preset value. This is a duplicate of getpreset and setpreset which has been provided for consistency with other commands. -\item {\bf countername SetExponent val } sets the exponent for the counting -preset in monitor mode to val. -\item {\bf countername GetExponent } prints the current exponent used -in monitor mode. -\item {\bf countername SetMode val } sets the counting mode to val. Possible values are Timer for timer mode operation and Monitor for waiting for a monitor to reach a certain value. -\item {\bf countername GetMode } prints the current mode. -\item {\bf countername mode val} With a parameter sets the mode, -without inquires the mode value. This is a duplicate of getmode and -setmode which has been provided for consistency with other -commands. Possible values for val are either monitor or timer. -\item {\bf countername SetExponent val } sets the exponent for the counting -preset in monitor mode to val. -\item {\bf countername GetCounts } prints the counts gathered in the last run. -\item {\bf countername GetMonitor n } prints the counts gathered in the monitor number n in the last run. -\item {\bf countername Count preset } starts counting in the current mode and the the preset preset. -\item {\bf countername status } prints a message containing the preset and -the current monitor or time value. Can be used to monitor the progress of -the counting operation. -\item {\bf countername gettime } Retrieves the actual time the counter -counted for. This excludes time where there was no beam or counting was -paused. -\item {\bf countername getthreshold m} retrieves the value of the threshold - set for the monitor number m. -\item {\bf countername setthreshold m val} sets the threshold for monitor m - to val. WARNING: this also makes monitor m the active monitor for evaluating - the threshold. Though the EL7373 counterbox does not allow to select the - monitor to use as control monitor in monitor mode, it allows to choose - the monitor used for pausing the count when the count rate is below the - threshold (Who on earth designed this?) -\item {\bf countername send arg1 arg2 arg3 ...} sends everything behind -send to the counter controller and returns the reply of the counter -box. The command set to use after send is the command set documented -for the counter box elsewhere. Through this feature it is possible to -diretclly configure certain variables of the counter controller from -within SICS. -\end{itemize} - -% html: End of file: `counter.htm' -% html: Beginning of file: `samenv.htm' - -\section{ Sample Environment Devices} - -\label{f10} - - -\subsection{SICS Concepts for Sample Environment Devices} - -\label{f10:concept} - -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 continously. Therefore there -exists a facility for dynamically configuring and deconfiguring environment -devices into the system. This is done via the {\bf EVFactory} command. -It is expected that instrument scientists will provide command procedures or -specialised R\"unbuffers 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 mode. The device is monitored in this mode when a new value for it -has been requested. The second mode is the monitor mode. This mode 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 {\bf emon}. The emon understands a few commands of its -own. - -Within SICS all sample environement 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 section the EVFactory, emon and the general commands understood -by any sample environment device will be discussed. This reading is mandatory -for understanding SICS environment device handling. Then there will be another -section discussing the special devices known to the system. - - -\subsection{SampleEnvironment Error Handling} - - -A \label{f10:error}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 different. 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 separately. Additional error handling strategies -can be added with a modest amount of programming. The error handling strategies currently -implemented are: -\begin{description} -\item[Lazy] Just print a warning and continue. -\item[Pause] Pauses the measurement until the problem has been resolved. -\item[Interrupt] Issues a SICS interrupt to the system. -\item[Safe] Tries to run the environment device to a value considered safe by the -user. -\end{description} - -\subsection{General Sample Environment Commands} - -\label{f10:general} - -\subsubsection{EVFactory} - - - -EVFactory is responsible for configuring and deconfiguring sample environment -devices into SICS. The syntax is simple: -\begin{description} -\item[EVFactory new name type par par ...] Creates a new sample environment device. It will be known to SICS by the -name specified as second parameter. 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. -\item[EVFactory del name] Deletes the environment device name from the system. -\end{description} - -\subsubsection{emon} - - - -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. -\begin{description} -\item[emon list] This command lists all environment devices currently registered in the -system. -\item[emon register name] 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. -\item[emon unregister name] This is a specialist command which unregisters the environment device name -with the environment monitor. Usually this will automatically be taken care -of by EVFactory Following this call the device will no longer be monitored and -out of tolerance errors on that device no longer be handled. -\end{description} - -\subsubsection{General - Commands UnderStood by All Sample Environment Devices} - -\label{f10:all} - -Once the evfactory has been run successfully the controller is -installed as an object in SICS. It is accessible as an object then -under the name specified in the evfactory command. All environemnt -object understand the common commands given below. -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: -\begin{quotation} -Temperature Tolerance\end{quotation} -prints the value of the variable Tolerance for the environment controller -Temperature. This is in the same units as the controller operates, -i. e. for a temperature controller Kelvin. -\begin{quotation} -Temperature Tolerance 2.0\end{quotation} -sets the parameter Tolerance for Temperature to 2.0. Parameters known to ANY -envrironment controller are: -\begin{description} -\item[Tolerance] Is the deviation from the preset value which can be tolerated before an -error is issued. -\item[ Access] Determines who may change parameters for this controller. -Possible values are: -\begin{itemize} -\item 0 only internal -\item 1 only Managers -\item 2 Managers and Users. -\item 3 Everybody, including Spy. -\end{itemize} -\item[LowerLimit] The lower limit for the controller. -\item[UpperLimit] The upper limit for the controller. -\item[ErrHandler.] The error handler to use for this controller. Possible values: -\begin{itemize} -\item 0 is Lazy. -\item 1 for Pause. -\item 2 for Interrupt -\item 3 for Safe. -\end{itemize} - For an explanantion of these values see the section about error (cf.\ Section~\ref{f10:error}) handling -above. -\item[ Interrupt] The interrupt to issue when an error is detected and Interrupt error -handling is set. Valid values are: -\begin{itemize} -\item 0 for Continue. -\item 1 for abort operation. -\item 2 for abort scan. -\item 3 for abort batch processing. -\item 4 halt system. -\item 5 exit server. -\end{itemize} -\item[SafeValue] The value to drive the controller to when an error has been detected and -Safe error handling is set. -\end{description} - -Additionally the following commands are understood: -\begin{description} -\item[send par par ...] Sends everything after send directly to the controller and return its -response. This is a general purpose command for manipulating 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. -\item[ list] lists all the parameters for this controller. -\item[ no command, only name.] When only the name of the device is typed it will return its -current value. -\item[ name val ] will drive the device to the new value val. Please note that the same -can be achieved by using the drive command. -\item[ name log on] Switches logging on. If logging is on, at each cycle in the -{\bf 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! {\bf Log clear} -frees -it again -and {\bf log frequency} (both below) -allows to set the logging time intervall. -\item[ name log off] Switches logging off. -\item[name log clear] Clears all recorded time stamps and values. -\item[name log gettime] This command retrieves a list of all recorded time stamps. -\item[name log getval] This command retrieves all recorded values. -\item[name log getmean] Calculates the mean value and the standard deviation for all logged -values and prints them. -\item[name log frequency val] With a parameter 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 300 seconds. -\item[name log file filename] Starts logging of value data to the file filename. All normal logging to - memory will be - disabled. Logging will happen any 5 minutes initially. The logging frequency - can be changed with the name log frequency command. Each entry in the file is - of the form date time value. The name of the file must be specified relative - to the SICS server. -\item[name log close ] Stops logging data to the file. -\end{description} - -\subsection{Special Environment Control Devices} - - - -This section lists the parameters needed for configuring a special environment -device into the system and special parameters and commands only understood by -that special device. All of the general commands listed above work as well! - -\subsubsection{ITC-4 and ITC-503 Temperature Controllers} - -\label{f10:itc4} - -These temperature controller are fairly popular at SINQ. They are -manufactured by -Oxford Instruments. At the back of this controller is a RS-232 -socket which must be connected to a Macintosh computer running the SINQ -terminal server program via a serial cable. Please make sure with a different -Macintosh or a PC that the serial line is OK and the ITC-4 responding before -plugging it in. - -\paragraph{ITC-4 Initialisation} - - -An ITC-4 can be configured into the system by: -\begin{quotation} -EVFactory new Temp ITC4 computer port channel\end{quotation} -This creates an ITC-4 controller object named Temp within the system. The -ITC-4 is expected to be connected to the serial port channel at the -Macintosh computer computer running the SINQ terminal server program -listening at port port. For example: -\begin{quotation} -EVFactory new Temp ITC4 lnsp22.psi.ch 4000 7\end{quotation} -connects Temp to the Macintosh named lnsp22, serial port 6 -(7 above is no typo!), listening at port 4000. - -\paragraph{ITC-4 Additional Parameters} - - -The ITC-4 has a few more parameter commands: -\begin{description} -\item[timeout] Is the timeout for the Macintosh terminal server program waiting for -responses from the ITC-4. Increase this parameter if error messages -containg ?TMO appear. -\item[ sensor] Sets the sensor number to be used for reading temperature. -\item[ control] Sets the control sensor for the ITC-4. This sensor will be used -internally for regulating the ITC-4. -\item[divisor] The ITC4 does not understand floating point numbers, the ITC-503 does. -In order to make ITC4's read and write temperatures correctly floating point -values must be multiplied or divided with a magnitude of 10. This parameter -determines the appropriate value for the sensor. It is usually 10 for a sensor -with one value behind the comma or 100 for a sensor with two values after -the comma. -\item[multiplicator] The same meaning as the divisor above, but for the control sensor. -\end{description} - -\paragraph{Installing an ITC4 step by step} - - -\begin{enumerate}\item Connect the ITC temperature controller to port 6 on the Macintosh -serial port extension box. Port 6 is specially configured for dealing with -the ideosyncracies of that device. No null modem is needed. -\item Install the ITC4 into SICS with the command: \newline -evfactory new name Macintoshname 4000 7\newline -Thereby replace name with the name you want to address the ITC4 in SICS. A -good choice for a name is temperature, as such a value will be written to data files. -Please note, that SICS won't let you use that name if it already exists. For -instance if you already had a controller in there. Then the command:\newline -evfactory del name \newline -will help. Macintoshname is the name of the instrument Macintosh PC. -\item Configure the upper and lowerlimits for your controller appropriatetly. -\item Figure out which sensor you are going to use for reading temperatures. -Configure the sensor and the divisor parameter accordingly. -\item Figure out, which sensor will be used for controlling the ITC4. Set the -parameters control and multiplicator accordingly. Can be the same as the -sensor. -\item Think up an agreeable temperature tolerance for your measurement. This -tolerance value will be used 1) to figure out when the ITC4 has reached its -target position. 2) when the ITC4 will throw an error if the ITC4 fails to -keep within that tolerance. Set the tolerance parameter according to the -results of your thinking. -\item Select one of the numerous error handling strategies the control -software is able to perform. Configure the device accordingly. -\item Test your setting by trying to read the current temperature. -\item If this goes well try to drive to a temperature not to far from the -current one. -\end{enumerate} - -\paragraph{ITC-4 Trouble Shooting} - - -If the ITC-4 {\bf does not respond at all}, make sure the serial connection to -the Macintosh is working. Use standard RS-232 debugging procedures for doing -this. The not responding message may also come up as a failure to -connect -to the ITC-4 during startup. - - If error messages containing the string {\bf ?TMO} keep appearing - up followed -by signs that the command has not been understood, then increase the -timeout. The standard - timeout of 10 microseconds can be to short sometimes. - -You keep on reading {\bf wrong values} from the ITC4. Mostly off by a -factor 10. Then set the divisor correctly. Or you may need to choose a -decent sensor for that readout. - -Error messages when {\bf trying to drive the ITC4}. These are usually the -result of a badly set multiplicator parameter for the control sensor. - -The ITC4 {\bf never stops driving}. There are at least four possible -causes for this problem: -\begin{enumerate} -\item The multiplicator for the control sensor was wrong and the ITC4 has now -a set value which is different from your wishes. You should have got error -messages then as you tried to start the ITC4. -\item The software is reading back incorrect temperature values - because the sensor and -divisor parameters are badly configured. Try to read the temperature and if -it does have nothing to do with reality, set the parameters accordingly. -\item The tolerance parameter is configured so low, that the ITC4 never -manages to stay in that range. Can also be caused by inappropriate PID -parameters in the ITC4. -\item -You are reading on one sensor (may be 3) and controlling on another one (may -be 2). Then it may happen that the ITC 4 happily thinks that he has reached -the temperature because its control sensor shows the value you entered as -set value. But read sensor 3 still thinks he is far off. The solution is to -drive to a set value which is low enough to make the read sensor think it is -within the tolerance. That is the temperature value you wanted after all. -\end{enumerate} - -\subsubsection{Haake Waterbath Thermostat} - -\label{f10:haake} - -This is sort of a bucket full of water equipped with a temperature -control system. The RS-232 interface of this device can only be operated at -4800 baud max. This is why it has to be connected to the serial printer port -of the Macintosh serial port server computer. This makes the channel number to -use for initialisation a 1 always. The driver for this device has been -realised in the Tcl extension language of the SICS server. A prerequisite -for the usage of this device is that the file hakle.tcl is sourced in the -SICS initialisation file and the command inihaakearray has been published. - Installing the -Haake into SICS requires two steps: first create an array with -initialisation parameters, second install the device with evfactory. A -command procedure is supplied for the first step. Thus the initialisation -sequence becomes: -\begin{quotation} -inihaakearray name-of-array macintosh-computer name port channel\newline -evfactory new temperature tcl name-of-array\end{quotation} -An example for the SANS: -\begin{quotation} -inihaakearray eimer lnsp25.psi.ch 4000 1 \newline -evfactory new temperature tcl eimer\end{quotation} -Following this, the thermostat can be controlled with the other environment -control commands. - -The Haake Thermostat understands a single special subcommand: {\bf sensor}. -The thermostat may be equipped with an external sensor for controlling and -reading. The subcommand sensor allows to switch between the two. The exact -syntax is: -\begin{quotation} -temperature sensor val\end{quotation} -val can be either intern or extern. - -\subsubsection{Dilution Cryostat} - -\label{f10:dilu} - -This is a large ancient device for reaching very low temperatures. This -cryostat can be configured into SICS with the command: -\begin{verbatim} -EVFactory new Temp dillu computer port channel table.file -\end{verbatim} -Temp is the name of the dilution controller command in SICS, dillu is the -keyword which selects the dilution driver, computer, port and channel are -the parameters of the Macintosh-PC running the serial port server program. -table.file is the fully qualified name of a file containing a translation -table for this cryostat. The readout from the dilution controller is a -resistance. This table allows to interpolate the temperature from the -resistance measurements and back. Example: -\begin{verbatim} -evfactory new temperature dillu lnsp19.psi.ch 4000 1 dilu.tem -\end{verbatim} -installs a new dilution controller into SICS. This controller is connected -to port 1 at the Macintos-PC with the newtwork adress lnsp19.psi.ch. On this -macintosh-PC runs a serial port server program listening at TCP/IP port -4000. The name of the translation table file is dilu.tem. - -The dilution controller has no special commands, but two caveats: As of -current (October 1998) setting temperatures does not work due to problems -with the electronics. Second the dilution controller MUST be connected to -port 1 as only this port supports the 4800 maximum baud rate this device -digests. - -\subsubsection{Bruker Magnet Controller B-EC-1} - -\label{f10:bruker} - -This is the Controller for the large magnet at SANS. The controller is a -box the size of a chest of drawers. This controller can be operated in one -out of two modes: in {\bf field} mode the current for the magnet is controlled via -an external hall sensor at the magnet. In {\bf current} mode, the output current -of the device is controlled. This magnet can be configured into SICS with a -command syntax like this: -\begin{quotation} -evfactory new name bruker Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion (which will be used throughout the rest of the text) is magnet. -bruker is the keyword for selecting the bruker driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at SANS): -\begin{verbatim} -evfactory new magnet bruker lnsp25.psi.ch 4000 9 -\end{verbatim} - -creates a new command magnet for a Bruker magnet Controller connected to -serial port 9 at lnsp25. -In addition to the standard environment controller commands this magnet -controller understands the following special commands: -\begin{description} -\item[magnet polarity] Prints the current polarity setting of the controller. Possible -answers are plus, minus and busy. The latter indicates that the controller -is in the process of switching polarity after a command had been given to -switch it. -\item[magnet polarity val] sets a new polarity for the controller. Possible values for val are -{\bf minus} or {\bf plus}. The meaning is self explaining. -\item[magnet mode] Prints the current control mode of the controller. Possible -answers are {\bf field} for control via hall sensor or {\bf current} for -current control. -\item[magnet mode val] sets a new control mode for the controller. Possible values for val are -{\bf field} or {\bf current}. The meaning is explained above. -\item[magnet field] reads the magnets hall sensor independent of the control mode. -\item[magnet current] reads the magnets output current independent of the control mode. -\end{description} - -Warning: There is a gotcha with this. If you type only magnet a -value will be returned. The meaning of this value is dependent on the -selected control mode. In current mode it is a current, in field mode it is -a magnetic field. This is so in order to support SICS control logic. -You can read values at all times explicitly using magnet current or -magnet field. - -\subsubsection{The CryoFurnace.} - -\label{f10:ltc11} - -The CryoFurnace at PSI is equipped with a Neocera LTC-11 temperature -controller. This controller can control either an heater or an analag output -channel. Futhermore a choice of sensors can be selected for controlling the -device. The LTC-11 behaves like a normal SICS environment control device -plus a few additional commands. An LTC-11 can be configured into SICS with -the following command: -\begin{quotation} -evfactory new name ltc11 Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -ltc11 is the keyword for selecting the LTC-11 driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. For example (at DMC): -\begin{verbatim} -evfactory new temperature ltc11 lnsp18.psi.ch 4000 6 -\end{verbatim} - -creates a new command magnet for a LTC-11 temperature Controller connected to -serial port 6 at lnsp18. - -The additional commands understood by the LTC-11 controller are: -\begin{description} -\item[temperature sensor ] queries the current sensor used for temperature readout. -\item[temperature sensor val ] selects the sensor val for temperature readout. -\item[temperature controlanalog ] queries the sensor used for controlling the analog channel. -\item[temperature controlanalog val ] selects the sensor val for controlling the analog channel. -\item[temperature controlheat ] queries the sensor used for controlling the heater channel. -\item[temperature controlheat val ] selects the sensor val for controlling the heater channel. -\item[temperature mode] queries if the LTC-11 is in analog or heater control mode. -\end{description} - -Further notes: As the CryoFurnace is very slow and the display at the -controller becomes unusable when the temperature is read out to often, the -LTC-11 driver buffers the last temperature read for 5 seconds. Setting the -mode of the LTC-11 is possible by computer, but not yet fully understood and - therefore unusable. - -\subsubsection{The Eurotherm Temperature Controller} - -\label{f10:euro} - -At SANS there is a Eurotherm temperature controller for the sample heater. - This and probably other Eurotherm controllers can be configured into SICS -with the following command. The eurotherm needs to be connected with a - nullmodem adapter. -\begin{quotation} -evfactory new name euro Mac-PC Mac-port Mac-channel\end{quotation} - -name is a placeholder for the name of the device within SICS. A good -suggestion is temperature. -euro is the keyword for selecting the Eurotherm driver. Mac-PC is the name of -the Macintosh PC to which the controller has been connected, Mac-Port is the -port number at which the Macintosh-PC's serial port server listens. -Mac-channel is the RS-232 channel to which the controller has been -connected. {\bf WARNING:} The eurotherm needs a RS-232 port with an unusual - configuration: 7bits, even parity, 1 stop bit. Currently only the SANS - Macintosh port 13 (the last in the upper serial port connection box) is - configured like this! Thus, an example for SANS and the name temperature - looks like: -\begin{verbatim} -evfactory new temperature euro lnsp25.psi.ch 4000 13 -\end{verbatim} - -There are two further gotchas with this thing: -\begin{itemize} -\item The eurotherm needs to operate in the EI-bisynch protocoll mode. This has -to be configured manually. For details see the manual coming with the machine. -\item The weird protocoll spoken by the Eurotherm requires very special control - characters. Therefore the send functionality usually supported by a SICS - environment controller could not be implemented. -\end{itemize} - -\subsubsection{The PSI-EL755 Magnet Controller} - -\label{f10:el755} - -This is magnet controller developed by the electronics group at -PSI. It consists of a controller which interfaces to a couple of power -supplies. The magnets are then connected to the power supplies. The -magnetic field is not controlled directly but just the power output of -the power supply. Also the actual output of the power supply is NOT -read back but just the set value after ramping. This is a serious -limitation because the computer cannot recognize a faulty power supply -or magnet. The EL755 is connected to SICS with the command: -\begin{quotation} -evfactory new name el755 Mac-PC Mac-port Mac-channel index\end{quotation} - with Mac-PC, Mac-port and Mac-channel being the usual data items for - describing the location of the EL755-controller at the Macintosh - serial port server. index is special and is the number of the power - supply to which the magnet is connected. An example: -\begin{verbatim} -evfactory new maggi el755 lnsa09.psi.ch 4000 5 3 -\end{verbatim} -connects to power supply 3 at the EL755-controller connected to lnsa09 -at channel 5. The magnet is then available in the system as maggi. No -special commands are supported for the EL755. -% html: End of file: `samenv.htm' -% html: Beginning of file: `logbook.htm' - -\section{LogBook command} - -\label{f11} - -Some users like to have all the input typed to SICS and responses -collected in a file for further review. This is implemented via the LogBook -command. LogBook is actually a wrapper around the config file command. -LogBook understands the following syntax: -\begin{description} -\item[ LogBook] alone prints the name of the current logfile and the status of event -logging. -\item[ LogBook file filename] This command sets the filename to which output will be printed. -Please note that this new filename will only be in effect after restarting -logging. -\item[ LogBook on] This command turns logging on. All commands and all answers will be -written to the file defined with the command described above. Please note, -that this command will overwrite an existing file with the same name. -\item[ LogBook off] This command closes the logfile and ends logging. -\end{description} - -% html: End of file: `logbook.htm' -% html: Beginning of file: `commandlog.htm' - -\section{The Commandlog} - -\label{f12} - -The commandlog is a file where all communication with clients -having user or manager privilege is logged. This log allows to retrace each -step of an experiment. This log is usually switched off and must be -configured by the instrument manager. There exists a special command, -commandlog, which allows to control this log file. -\begin{description} -\item[commandlog new filename] starts a new commandlog writing to filename. Any prior files will be -closed. The log file can be found -in the directory specified by the ServerOption LogFileDir. Usually this is -the log directory. -\item[commandlog] displays the status of the commandlog. -\item[commandlog close] closes the commandlog file. -\item[commandlog auto] Switches automatic log file creation on. This is normally switched on. -Log files are written to the log directory of the instrument account. There - are time stamps any hour in that file and there is a new file any 24 hours. -\item[commandlog tail n] prints the last n entries made into the command log. n is optional and defaults to 20. Up to 1000 lines are held in an internal buffer for this command. -\end{description} - -% html: End of file: `commandlog.htm' -% html: Beginning of file: `macro.htm' - -\section{Macro Commands} - -\label{f13} - - 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 Tool Command Language (TCL). Tcl has control constructs, variables of its own, loop constructs, associative arrays and procedures. Tcl is well documented by several books and online tutorials, therefore no details on Tcl will be given here. All SICS commands are available in the macro language. Some potentially harmful Tcl commands have been deleted from the standard Tcl interpreter. These are: exec, source, puts, vwait, exit,gets and socket. A macro or batch file can be executed with the command: - - {\bf FileEval name } tries to open the file name and executes the script in this file. -Then there are some special commands which can be used within macro-sripts: - - {\bf ClientPut sometext1 ... } writes everything after ClientPut to - the client which started the script. This is needed as SICS supresses - the output from intermediate commands in scripts. Except error - messages and warnings. With clientput this scheme can be circumvented - and data be printed from within scripts. - -{\bf SICSType object } allows to query the type of the object specified by object. Possible return values are -\begin{itemize} -\item {\bf DRIV } if the object is a SICS drivable object such as a motor -\item {\bf COUNT } if the object is some form of a counter. -\item {\bf COM } if the object is a SICS command. -\item {\bf NUM } if the object is a number. -\item {\bf TEXT } if object is something meaningless to SICS. -\end{itemize} - - {\bf SICSbounds var newval } checks if the new value newval lies within the limits for varaible var. Returns an error or OK depending on the result of the test. - - {\bf SICSStatus var } SICS devices such as counters or motor may be - started and left running while the program is free to do something - else. This command inquires the status of such a running device. Return values are internal SICS integer codes. This command is only of use for SICS programmers. - -{\bf SetStatus newval } sets the SICS status to one of: Eager, UserWait, Count, NoBeam, Driving, Running, Scanning, Batch Hatl or Dead. This command is only available in macros. - - {\bf SetInt newval, GetInt } sets SICS interrupts from macro scripts. Not recommended! Possible return values or new values are: continue, abortop, abortscan, abortbatch, halt, free, end. This command is only permitted in macros. Should only be used by SICS programmers. -% html: End of file: `macro.htm' -% html: Beginning of file: `buffer.htm' - -\section{R\"unbuffer Commands} - -\label{f14} - - LNS scientists have got used to using R\"unbuffers for instrument - control. A R\"unbuffer is an array of SICS commands which - typically represent a measurement. This R\"unbuffer can be edited - at run time. This is very similar to a macro. In contrast to a macro - only SICS commands are allowed in R\"unbuffers. When done with - editing the R\"unbuffer it can be entered in a R\"unlist. This - is a stack of R\"unbuffers which get executed one by one. While - this is happening it is possible (from another client) to modify the - R\"unlist and edit and add additional R\"unbuffers on top of - the stack. This allows for almost infinite measurement and gives more - control than a static batch file. In order to cater for this scheme - three commands have been defined: - - The {\bf Buf } object is responsible for creating and deleting R\"unbuffers. The syntax is: -\begin{itemize} -\item {\bf Buf new name } creates a new empty R\"unbuffer with the name name. name will be installed as a SICS object afterwards. -\item {\bf Buf copy name1 name2 } copies R\"unbuffer name1 to buffer name2. -\item {\bf Buf del name } deletes the R\"unbuffer name. -\end{itemize} - - After creation, the R\"unbuffer is accessible by his name. It - then understands the commands: -\begin{itemize} -\item {\bf NAME append what shall we do with a drunken sailor } will add all text after append as a new line at the end of the R\"unbuffer. -\item {\bf NAME print } will list the contents of the R\"unbuffer. -\item {\bf NAME del iLine } will delete line number iLine from the R\"unbuffer. -\item {\bf NAME ins iLine BimBamBim } inserts a new line {\bf after } line iLine into the R\"unbuffer. The line will consist of everything given after the iLine. -\item {\bf NAME subst pattern newval } replaces all occurences of pattern in the R\"unbuffer by the text specified as newval. Currently this feature allows only exact match but may be expanded to Unix style regexp or shell like globbing. -\item {\bf NAME save filename } saves the contents of the R\"unbuffer into file filename. -\item {\bf NAME load filename } loads the R\"unbuffer with the data in file filename. -\item {\bf NAME run } executes the R\"unbuffer. -\end{itemize} - - The R\"unlist is accessible as object {\bf stack }. Only one R\"unlist per server is permitted. The syntax: -\begin{itemize} -\item {\bf stack add name } adds R\"unbuffer name to the top of the stack. -\item {\bf stack list } lists the current R\"unlist. -\item {\bf stack del iLine } deletes the R\"unbuffer iLine from the R\"unlist. -\item {\bf stack ins iLine name } inserts R\"unbuffer name after R\"unbuffer number iLine into the R\"unlist. -\item {\bf stack run } executes the R\"unlist and returns when all R\"unbuffers are done. -\item {\bf stack batch } executes the R\"unlist but does not return when done but waits for further R\"unbuffers to be added to the list. This feature allows a sort of background process in the server. -\end{itemize} - -% html: End of file: `buffer.htm' -% html: Beginning of file: `hkl.htm' - -\section{4 Circle Diffractometer Setting Calculation} - -\label{f15} - -An essential part of operating a 4 circle diffractometer is the calculation -of the setting angles for the diffractometer for a given reciprocal lattice -point from the UB matrix and the wavelength. SICS does this through the hkl -object. The hkl object can calculate the required settings both for normal 4 -circle configuration and normal beam configuration. It is possible to -specify if low chi or high chi values are preferred. The wavelength can be -dealt with in two ways: it can be set manually. Or a variable controlling -the wavelength can be specified. The hkl object will then be updated -automatically with the newest value for the wavelength whenever the -wavelength changes. - -The hkl object understands the following commands: -\begin{description} -\item[hkl list] Prints a listing of all relevant settings calculation parameters. -\item[hkl current] Prints the value of the last calculated reflection. -\item[hkl lambda val] Manually sets the wavelength to val. No automatic updates of the -wavelength will be performed. -\item[hkl lambdavar val] Sets the name of the variable controlling the wavelength. The wavelength -in the hkl object will be automatically updated whenever the wavelength is -modified by driving variable val. This is a user command because the TRICS -spectrometer has more then one monochromator. -\item[hkl setub a11 a12 a13 a21 a22 a23 a31 a 32 a33] SetUB sets the UB matrix to the nine values given. -\item[hkl nb val] Switches the mode for normal beam calculation. If val is 1 a normal beam -calculation is performed, else normal four circle calculations are done. -\item[hkl quadrant val] Defines the chi quadrant to prefer. The parameter val can be 0 for low -chi and 1 for high chi. -\item[hkl calc h1 h2 h3 psi hamil] Calculates and prints the setting angles for the reflection (h1,h2,h3). -Optionally a psi value and a hamilton position can be specified. -\item[hkl run h1 h2 h3 psi hamil] Calculates the setting angles for the reflection (h1,h2,h3) and starts -the motors to run to that position. This command will return immediately and -will not wait for the diffractometer to arrive at the setting angles -requested. -Optionally a psi value and a hamilton position can be specified. -\item[hkl drive h1 h2 h3 psi hamil] Calculates the setting angles for the reflection (h1,h2,h3) and starts -the motors to drive to that position. This command will wait for the -diffractometer to arrive at the setting angles requested. -Optionally a psi value and a hamilton position can be specified. -\end{description} - -% html: End of file: `hkl.htm' -% html: Beginning of file: `config.htm' - -\section{Configuration Commands} - -\label{f16} - - SICS has a command for changing the user rights of the current client server connection, control the amount of output a client receives and to specify additional logfiles where output will be placed. All this is accessed through the following commands: - - The SICS server logs all its activities to a logfile, regardless of what the user requested. This logfile is mainly intended to help in server debugging. However, clients may register an interest in certain server events and can have them displayed. This facility is accessed via the {\bf GetLog } command. It needs to be stressed that this log receives messages from {\bf all } active clients. GetLog understands the following messages: -\begin{itemize} -\item {\bf GetLog All } achieves that all output to the server logfile is also written to the client which issued this command. -\item {\bf GetLog Kill } stops all logging output to the client. -\item {\bf GetLog OutCode } request that only certain events will be logged to the client issuing this command. Enables only the level specified. Multiple calls are possible. -\end{itemize} - Possible values for OutCode in the last option are: -\begin{itemize} -\item {\bf Internal } internal errors such as memory errors etc. -\item {\bf Command } all commands issued from any client to the server. -\item {\bf HWError } all errors generated by instrument hardware. The SICS server tries hard to fix HW errors in order to achieve stable operations and may not generate an error message if it was able to fix the problem. This option may be very helpful when tracking dodgy devices. -\item {\bf InError } All input errors found on any clients input. -\item {\bf Error } All error messages generated by all clients. -\item {\bf Status } some commands send status messages to the client invoking the command in order to monitor the state of a scan. -\item {\bf Value } Some commands return requested values to a user. These messages have an output code of Value. -\end{itemize} - -The {\bf config } command configures various aspects of the current client server connection. Basically three things can be manipulated: The connections output class, the user rights associated with it, and output files. - -\begin{itemize} \item The command {\bf config OutCode val } sets the output code for the connection. By default all output is sent to the client. But a graphical user interface client might want to restrict message to only those delivering requested values and error messages and suppressing anything else. In order to achieve this, this command is provided. Possible values Values for val are Internal,Command, HWError,InError,Status, Error, Value. This list is hierarchical. For example specifying InError for val lets the client receive all messages tagged InError, Status, Error and Value, but not HWError, Command and Internal messages. -\item Each connection between a client and the SICS server has user rights assocociated with it. These user rights can be configured at runtime with the command {\bf config Rights Username Password }. If a matching entry can be found in the servers password database new rights will be set. -\item Scientists are not content with having output on the screen. In order to -check results a log of all output may be required. The command {\bf config -File name } makes all output to the client to be written to the file -specified by name as well. The file must be a file accessible to the server, -i.e. reside on the same machine as the server. Up to 10 logfiles can be -specified. Note, that a directly connected line printer is only a special -filename in unix. -\item {\bf config close num} closes the log file denoted by num again. -\item {\bf config list} lists the currently active values for outcode and user -rights. -\end{itemize} - - -% html: End of file: `config.htm' -% html: Beginning of file: `system.htm' - -\section{System Commands} - -\label{f17} - -{\bf Sics\_Exitus }. A single word commands which shuts the server down. Only Managers may use this command. - - {\bf wait time } waits time seconds before the next command is executed. This does not stop other clients from issuing commands. - - {\bf ResetServer } resets the server after an interrupt. - - {\bf Dir } a single word command which lists all objects available in the SICS system in its current configuration. - - {\bf status } A single word command which makes SICS print its current -status. Possible return values can be: -Eager to execute commands, Scanning, Counting, Running, Halted. Note that if a command is executing which takes some time to complete - the server will return an ERROR: Busy message when further commands are issued. - -{\bf status interest} initiates automatic printing of any status change in the -server. This command is primarily of interest for status display client -implementors. - -{\bf backup file} saves the current values of SICS variables and selected - motor and device parameters to the disk file specified as - parameter. If no file parameter is given the data is written to the - system default status backup file. - The format - of the file is a list of SICS commands to set all these parameters - again. The file is written on the instrument computer relative to the - path of the SICS server. This is usually /home/INSTRUMENT/bin. - -{\bf restore file} reads a file produced by the backup command described -above and restores SICS to the state it was in when the status was saved with - backup. If no file argument is given the system default file gets - read. -% html: End of file: `system.htm' -% html: Beginning of file: `tricsingle.htm' - -\chapter{Running TRICS with a Single Counter} - -\label{f2} - -In this mode TRICS simulates a conventionell four circle diffractometer much -like a x-ray diffractometer as commercially available. The tasks which have -to be solved are: -\begin{itemize} -\item Locate Reflections -\item Index reflections and refine a UB-matrix. -\item Measure a couple of reflections. -\item Furthermore there are some specialities. -\end{itemize} - There are two ways to achieve all this: The older way uses some built in SICS functionality plus some external prograsm inherited from the ILL. This is called the ILL operation. Then a complete four circle packaage called DIFRAC from P. White and Eric Gabe was integrated into SICS. Thsi is The Difrac way of operation. - -\section{DIFRAC} - - - -The DIFRAC commands are accessed by prepending the difrac commands -with {\bf dif}. For example: {\tt{}"{}}dif td{\tt{}"{}} calls the difrac td -command. For more information on DIFRAC commands see the separate -DIFRAC manual. - -\section{ILL operation} - - - -\subsection{Locate Reflections} - - - -If you know x-ray single crystal diffractometers you'll expect sophisticated -reflection search procedures here. Nothing is available in this field in -SICS. It was deemed inapropriate for neutron research. The first reflections -must be found by hand. Something which may help in this is a quick scan -facility which allows to run a motor and print counts while the motor is -moving. This can be invoked by a command like this: -\begin{verbatim} -susca var start end time -\end{verbatim} - The parameters are: -\begin{itemize} -\item var: the motor or variable to scan. -\item start: the start position from which to scan. -\item end: the end position for this scan. -\item time: The maximum counting time. -\end{itemize} -Be aware that this is inprecise and liable to changes in the source current. -But it may help to locate the aproximate position of a peak. - -Once a peak has been found, its position can be optimised and centered with the -peak optimiser (cf.\ Section~\ref{f18}). - -The next thing to do is to store the reflection and find other ones. Once a -few reflections have been found, the need to be written to disk. This can be -accomplished with the object rliste which has the following subcommands: -\begin{description} -\item[rliste clear] clears all entries from the list -\item[rliste store] saves the current diffractometer position into the list -\item[rliste write file] Writes the contents of the reflection list to the file specified. -\end{description} - -\subsection{Indexing Reflections and Refining UB-Matrix} - - - -For these purposes the external programs INDEX and -RAFIN are provided. These programs are courtesy of the ILL, France. - -\subsection{Measuring Reflections} - - - -Before measuring reflections a list of reflections to measure must be -created. This is done with the external program -HKLGEN. Then reflections this reflection list can -be fed into SICS using the mess (cf.\ Section~\ref{f20}) command. mess -creates two output files: a .col file containing the reflection profiles of -all the relfections and a .dat files which contains the -HKL,F,sig(F),TH,OM,CH,PH for each reflection. Intensity has then be -integrated within SICS. The .col files can be processed by the program -REFRED which allows to perform more advanced data reduction chores and has a -choice of integration methods for reflection data. Please note, that SICS -does not automatically measure standard reflections. It is your task to add -suitable standard reflections into the reflection list. - -\section{Special Commands} - - - -As of current this section only holds the hklscan - commmand (cf.\ Section~\ref{f21}) which allows to express a scan in Miller indizes. This is - in fact a scan in reciprocal space. -% html: End of file: `tricsingle.htm' -% html: Beginning of file: `optimise.htm' - -\section{The Peak Optimiser} - -\label{f18} - -In instrument control the need may arise to optimise a peak with respect to -several variables. Optimising means finding the maximum of the peak with -respect to several variables. - This is useful during instrument calibration, for example. -Four circle diffractometers use this facility on a day to day basis -for finding and verifying the exact position of reflections. In order to -support both usages a more general module has been implemented. The -algorithm is like this: -\begin{verbatim} -while errors gt precision and cycles lt maxcycles - for all variables - do a scan - Try find the maximum, two halfwidth points and the peak center. - if failure extend the scan. - if success shift the variable, remember last shift. - If shift lt precicison mark this variable as done - end for -end while -\end{verbatim} -Possible outcomes of this procedure are: success, the peak was lost or the -maximum number of cycles was reached. This routine requires that the -instrument is currently placed somewhere on the peak and not miles away. - -The Peak Optimiser is implemented as an object with the name opti. It -understand the following commands: -\begin{description} -\item[opti clear] clears the optimiser. -\item[opti addvar name step nStep precision] This command adds a variable to optimise to the optimiser. The user has -to specify the name of the variable, the step width to use for scanning, the -number of steps needed to cover the full peak when scanning and the -precision which should be achieved when optimising the peak. The step width -and number of steps parameters should cover the whole peak. However, the -Optimiser will extend the scan is the specified range is not sufficient. -\item[opti run] Starts the optimiser. It will then optimise the peak. This may take some -time. -\end{description} - The behaviour of the optimiser can be configured by modifying some -parameters. The synatx is easy: {\bf opti parameter} prints the value of the -parameter, {\bf opti parameter newval} sets a new value for the parameter. -The following parameters are supported: -\begin{description} -\item[maxcycles] The maximum number of cycles the optimiser will run when trying to -optimise a peak. The default is 7. -\item[threshold] When a peak cannot be identified after a scan on a variable, the -optimiser will check if there is a peak at all. In order to do that it -searches for a count rate higher then the threshold parameter. If such a -rate cannot be found the optimiser will abort and complain that he lost the -peak. -\item[channel] The counter channel to use for scanning. The default is to use the -counter. By modifying this parameter, the optimiser can optimise on a -monitor instead. -\item[countmode] The counting mode to use when scanning. Possible values are {\bf timer} or -{\bf monitor}. -\item[preset] The preset value to use for counting in the scan. Depending on the -status of the countmode parameter this is either a preset time or a preset -monitor. -\end{description} - -% html: End of file: `optimise.htm' -\section{External FORTRAN 77 Programs} -\subsection{INDEX} - - The program indexes reflections on the basis of observed - 2Theta, Omega, Chi, Phi angles when the cell constants and - wavelength are known. - It does not take into account systematic extinctions. - - The process, when successful, has three steps. - - First, it calculates, for each set of observations, all possible - HKL's for which theta(calc) lies within theta(obs) +/- - delta theta. - delta theta is given - see below -. - For delta theta = 0, the value defaults to 0.05. - - Second, it finds for all combinations of two sets of observations, - the angle between the indexed HKL's for which angle(calc) lies - within angle (obs) +/- delta. - delta given - see below -. Delta = 0 causes default to 0.2 - - Finally, it finds all sets of indexed HKL's that explain all angles - between the observed sets of Omega, Chi and Phi. - - The user will normally be presented with several possible sets of - HKL's which fit within the limits given. - - they are already tested for right-handedness - - and he must now choose which set he likes the most. - - If he wishes he may now specify which set of reflections he likes - and the program will then set up the input file for the program - rafin, - see next section -. - The program ensures that the first two reflections are acceptable - to rafin. The user must say whether he wants the ub matrix - written directly into lsd ( for instant use ) and which file he - wants his rafin input to come from (usually rafin.dat). - The program rafin is then automatically started. - - - Input to index can be done either from the terminal or from a file - index.dat - The format is the same, an example is given here. -\begin{verbatim} -THIS IS A DUMMY EXAMPLE ( text ) -5.82 16.15 4.09 90 103.2 90 .84 .15 (cell constants, lambda delta) -16.18 9.01 34.71 14.74 0 (2Th, Om, Ch, Ph, delta theta) -13.21 7.8 .71 -56.13 0.1 (2Th, Om, Ch, Ph, delta theta) -etc. etc. -0 ( end list with 2Th = 0 ) -\end{verbatim} - - The program will only suggest sets of indexed HKL's if all - reflections are explained. If not, the user must himself look - through the list of observed and calculated angles to find a - partial list. - - -\subsection{RAFIN} - This program determines orientation matrix ( ub) from two or more - sets of orientation angles for reflections, and refines - (optionally) wavelength; zeroes of 2Theta, Omega or Chi; a, b, c, - alpha, beta or gamma. - - - To call the program, type :-- - rafin - after having set up the input file : - - The input data are on rafin. dat - (teletype input can be used, but is cumbersome) - - Use teco to make or correct the file. - - An example of the input file ( comments in parentheses ) :-- -\begin{verbatim} -0 1 (second no. 0/1 for ub not transferred/transferred to lsd) -0 (always) -0 -4 -2 28.01 13.75 81.59 42.05 (H K L 2Theta Omega Chi Phi) -4 -6 7 50.84 25.37 34.04 18.41 --2 -6 0 41.55 20.53 66.93 59.99 -4 0 4 19.74 9.94 -16.92 -5.40 -1 -5 -3 35.59 17.70 82.32 1.40 -6 0 0 18.47 9.26 -2.32 -46.95 -0 .8405 (0/1 do not/do refine lambda; and lambda) -0 0.0 1 0.0 1 0.0 (0/1 for do not/do refine, 2Theta zero, - -0/1 for do not/do refine, Om zero, - -0/1 for do not/do refine, Chi zero. -0 15.9158 0 7.1939 0 14.277 0 90 0 98.72 0 90 (ditto for a, b, c, alpha, beta and gamma) -2 0 0 (H K L list for angles to be calculated) -0 2 0 -0 0 2 -0 0 0 (end of list) --1 (end of input file) -\end{verbatim} - - Ensure that lsd is not running if you wish to transfer the - matrix and wavelength directly into its parameter section, - otherwise it may not be successful. - rafin will never modify the zeroes for you. This is for you to do - by adding them to the values in zer of par. Remember that for a - well aligned diffractometer, they will never change by very much. - - Note: the first two reflections should be far away enough in - reciprocal space to define a plane. They must be at least 45 deg - apart in Phi and only one may have Chi greater than 45 deg. - - Note also that higher angle (Theta) reflections usually give a - better fit. - - You cannot, obviously, refine lambda and your cell at the same - time. - - -\subsubsection{Acknowledgements} - - The index program was written by M.S.Lehmann, - and J.M.Savariault. - - The rafin program was implemented at the ill by A.Filhol and - M.Thomas. - It was implemented on the pdp 11 system by A.Barthelemy. - - - -\subsection{HKLGEN} - - THIS PROGRAM IS USED TO GENERATE A LIST OF HKL's which can be used - for input to the measurement routines of lsd. - Indices can be generated internally in lsd, but it is generally - considered easier to create a list, and measure from this. - - hklgen will generate HKL's according to min and max specified - indices, and will write them into output file(s) if they are inside - the Theta limits. - - If chi and phi limits are specified, the program will also look - to see if the hkl is measurable inside these machine limits. - - If not, it will see if the Friedel Pair is inside limits - - If this is also outside limits, it will see if the reflection can - be measured for hkl psi=180 - - - note this option means chi = 90 -> 180 i.e. up-side-down. - - If measurement is not possible for any of these conditions, the - hkl is declared blind. - - Comments like fr.pr hichi blind indicate these on tty output. - - To run the program do :-- - - hklgen - Input to the program is either from the terminal or from a file - hklgen.dat, already created by the user. - -\subsubsection{Input from Terminal} - The first question asked under this option is whether a file - hklgen.dat should be created. - If subsequent runs are envisaged, this might be a good idea. In - this case teco can be used to make small changes to the input and - the program can be quickly re-run. - hklgen then asks for the following parameters :-- -\begin{enumerate} -\item Title. Up to 80 characters to be displayed at the top of the - output. -\item Wavelength and the 9 'rules limiting possible reflections' - - see appendix C -- If you give wavelength = 0, the wavelength, - extinction rules, and orientation matrix will be taken from - lsd's parameter files. - chi and phi software limits are also taken but an - opportunity is given to over-write them. - -- If the wavelength is given explictly, followed by up to 9 - numbers for the extinction rules, the orientation matrix must - then be given line by line. -\item Theta limits. ( Note not 2-Theta limits ). - chi and phi limits ( if required ) must also be given in - this line. - -- If zeroes are given, no limits will be included in the - calculations. - -- If nothing is given, LSD's limits will be used if data was - taken from the parameter files, or it will default to zeroes - if the data above was given by the user. -\item Three numbers indicating the relative speed of variation of - h, k and l. - First number is the slowest changing index, third number is - the fastest changing index. - 1/2/3 is used to represent h/k/l. - e.g. 3 2 1 means L changes slowest, then K, with H changing - fastest. -\item Minimum and maximum indices in hkl are now requested. - You must give hmin hmax kmin kmax lmin lmax. - Note however that before starting the calculations, hklgen - calculates itself what is the maximum value for each index for - the specified Theta range and if this is inside these values, - they will be modified. - Therfore, if, for example 0 999 0 999 -999 999 is given, - hklgen will calculate the maximum values and give HKL's for - positive H, positive K, positive and negative L. -\item Four numbers concerning various outputs from the program. - a) The first npunch concerns the hkl output file. - 0 = no file for output - 1 = file for output containing hkl only in 3I4 format. - 2 = file for d15-ren ( not for d8-d9 ) - 3 = file for output containing hkl and setting angles. - b) The second ipara concerns machine geometry. - 0 = Bissecting geometry - (normal for d8-d9 ). - 1 = Normal beam geometry - ( rarely used on d8-d9 ) - 3 = d15 lifting counter mode ( used with npunch = 2 ) - c) The third number nbites concerns hkl output. - 1 = write hkl for each case in four separate files. - 0 = write all HKL's in one single file FOR00x. dat - ( x specified below ). - d) The fourth number nlist concerns terminal output. - 0 = write each hkl with angles and comment on terminal. - ( can take time and consume paper ). - 1 = suppress most of the output on tty. -\item If in previous line FOR00x. dat was specified for hkl output, - X must be given. - This is the last line in the input but is not always - necessary. -\end{enumerate} - The program then generates as specified, creating file(s) if - required. It gives a resume at the end and exits. - -\subsubsection{Input from file hklgen.dat} - - Input is given in exactly the same order as above, so for a more - detailed description of each parameter see previous section. - - Two possible examples are given below. -\begin{verbatim} -KNUDDERKRYSTAL LAVET AF AARKVARD, 120K (Text, 80 characters) -0.8405 0 0 0 0 0 0 0 0 0 (Wavelength and the 9 Extinction rules. ) -0.043361 -.04190 .5399 ( ub given in three separate lines --.046409 -.032053 .03721 - as wavelength is given explicitly --.00256 -.12861 -.02687 -0 36 -20 95 ( Theta limits and Chi limits - note - no limits on Phi. ) -2 1 3 ( relative speeds of hkl. - K slowest - L fastest. ) --99 -1 0 5 -99 99 ( Hmin,Hmax,Kmin, etc. - note all L's with all neg -1 0 0 1 ( a) Output file of hkl. - b) Bisecting geom - usual. - c) All HKL's in for00x.dat. - d) Suppress most tty output. ) -3 ( hkl file on for003.dat ) -\end{verbatim} - - hklgen is a program which has evolved in the hands of : - A.Filhol, S.Mason. A.Barthelemy and J.Allibon. - -\subsection{Encoding of Extinction Rules} -\begin{verbatim} -HKL - 0 : NO CONDITIONS - 1 : H + K + L = 2n - 2 : H, K, L all even or all odd - 3 : -H + K + L = 3n - 4 : H = K + L = 3n - 5 : H + K = 2n - 6 : K + L = 2n - 7 : H + L = 2n - 8 : H + K + L = 6n - 9 : H, K, L all even - 10 : H, K, L all odd - 11 : If H - K = 3n, then L = 6n -H K 0 - 0 : No conditions - 1 : H = 2n - 2 : K = 2n - 3 : H + K = 2n - 4 : H + K = 4n -0 K L - 0 : No conditions - 1 : K = 2n - 2 : K + L = 2n - 3 : K + L = 3n - 4 : K + L = 4n - 5 : L = 2n -H 0 L - 0 : No conditions - 1 : L = 2n - 2 : H = 2n - 3 : L + H = 2n - 4 : L + H = 4n -H H L - 0 : No conditions - 1 : L = 2n - 2 : H = 2n - 3 : 2H + L = 4n - -\end{verbatim} -% html: Beginning of file: `mesure.htm' - -\section{Reflection List Processor} - -\label{f20} - -This section describes the means for doing a standard single counter four -circle diffractometer measurement with SICS. A prerequisite for that is a -file with a list of reflections to measure. This is a simple file with -three floating point values per line giving the HKL of the reflection to -measure. Do not forget to put standard reflections into that file any now -and then. Another prerequisite is, that the UB-matrix had been determined -beforehand and that SICS has the updated values. Also check the value of -lambda in the hkl-object. - -The measurement procedure is rather simple: If a reflection is accessible -the diffractometer is positioned on that reflection. Then a scan is done for -the reflection and data written to file. The scans all run with a fixed scan -widths, counter preset and countmode. There is a choice of omega scan or -omega two theta scan. It is known that there are more sophisticated -measurement schemes for four circle diffraction, but as TRICS is only -temporarily operated with a single counter not much optimisation seemed -necessary. - -Three files will be written starting from a root such as tricsnumberyear. -For instance trics05601998 means file number 560 in 1998. The file ending in -.log will contain the console log. This is extremely verbose. Another file -ending with .col will contain the reflection, diffractometer settings and -the measured profile. The third file, ending with .rfl will contain for each -refelction, the HKL, the diffractometer settings and the intensity and sigma -intensity as calculated by the SICS internal integration routine. It does -a Grant Gabe integration (see J.Appl. Cryst (1978), 11, 114-120). - -For the purpose of the command description it is assumed, that this facility -is accessible as object mess within SICS. -Interaction with this object happens through the following commands: -\begin{description} -\item[mess start] Creates a new set of files and writes some header info. -\item[mess measure filename iSkip] Starts a measurement. Reads reflections from the file filename. iSkip is -an optional parameter which allows to skip iSkip lines in the file. This - is for recovery in cases of accidental or purposeful interruption -of the measurement. -\item[mess genlist filename iSkip] Mesures reflection from filename. The file is expected to have been - created by hklgen and to include all the angle settings. The optional -parameter iSkip determines the number of lines to skip in the file. This -feature allows to continue measurement on not fully processed files. -\item[mess reopen filename] Reopens an already existing file set for appending. Only the file root -without directory info or endings needs to be given. -\item[mess close] Closes the current data file set. -\item[mess file] Prints the current data file name. -\end{description} -Then there are a few parameter commands. They follow the general scheme: -\begin{description} -\item[mess parameter] Prints the current value of the parameter -\item[mess parameter value] Sets the parameter to the new value. -\end{description} -This object knows about the following parameters: -\begin{description} -\item[countmode] The counting mode to use. Possible values are timer or monitor. -\item[preset] The preset to use for counting -\item[mode] The measurement mode. Posssible values are omega for omega scans and -omega2theta for omega two theta scans. -\item[np] number of points to collect for each profile. -\item[step] The step width in omega to use for scanning. -\item[compact] Determines if the scan data output to the SICS is in normal -(compact = 0) or condensed (compact = 1) form. The default is 1. -\end{description} - -mess supports two geometries: the first is the usual bisecting geometry. The - second is the normal beam geometry where the detector is moved out of plane. - This si accounted for by two switches: -\begin{description} -\item[mess bi] switches into bissectiong mode. This is the default. -\item[mess nb] switches into normal beam mode. -\end{description} - -This object supports some file management functionality. It caters -for the problem that experiments may need to be continued. Thus reopening -files and continuation of reflection processing at a point way down the -reflection file is supported. Consequently the start of a new experiment -requires the following steps: -\begin{itemize} -\item Create a new set of files with {\bf mess start}. -\item Configure the scans with the parameter commands. -\item Start processing a reflection file with either the {\bf mess genlist} - or {\bf mess measure} commands. -\end{itemize} - If you need to continue reflection file processing after an abort or after -solving a problem the following steps are required: -\begin{itemize} -\item Determine the file number you were working at and the line number in the - reflection file where you wish to continue processing. -\item Set the file root with the {\bf mess reopen} command. -\item Configure the scan parameters again. -\item Restart the measurement with either {\bf mess genlist} or {\bf mess - measure} but specify the iSkip parameter according to the position in -the reflection file where processing should continue. -\end{itemize} - -% html: End of file: `mesure.htm' -% html: Beginning of file: `hklscan.htm' - -\section{Hklscan} - -\label{f21} - -Hklscan is a command which allows to scan in reciprocal space expressed as - Miller indizes on a four circle diffractometer. Prerequisite for this is - the existence of a scan object and the hkl-object for doing crystallographic - calculations. Make sure the properties of the hkl object (UB, wavelength, NB) - have some reasonable relation to reality, otherwise the diffractometer may - travel to nowhere. Also it is a good idea to drive the diffractometer to the - end points of the intended scan in reciprocal space. hklscan will abort if - the requested scan violates diffractometer limits. The commands implemented - are quite simple: -\begin{description} -\item[hklscan start fH fK fL] sets the start point for the HKL scan. Three values required, one for - each reciprocal axis. -\item[hklscan step sH sK Sl] sets the step width in reciprocal space. Three values required, one for - each reciprocal axis. -\item[hklscan run NP mode preset] executes the HKL scan. NP is the number of points to do, mode is the - counting mode and can be either timer or monitor and preset is the preset - value for the counter at each step. -\end{description} - Data is written automatically into a slightly modified TOPSI data format - file. The status display with topsistatus or scanstatus might be slightly - erratic as it uses two theta as x-axis. -% html: End of file: `hklscan.htm' -% html: Beginning of file: `tricspsd.htm' - -\chapter{TRICS with Position Sensitive Detectors} - -\label{f3} - -As there are no PSD's available for TRICS, not much can be found here. -In terms of software the following pieces are already available: -\begin{itemize} -\item Instructions for dealing wih -histogram memory (cf.\ Section~\ref{f22}). -\item NeXus (cf.\ Section~\ref{f23}) data handling for TRICS. -\end{itemize} - -% html: End of file: `tricspsd.htm' -% html: Beginning of file: `histogram.htm' - -\section{Histogram memory} - -\label{f22} - - -Histogram memories are used in order to control large area sensitive -detectors or single detectors with time binning information. -Basically each detector maps to a defined memory location. The -histogram memory wizard takes care of putting counts detected in the -detector into the proper bin in memory. Some instruments resolve energy -(neutron flight time) as -well, than there is for each detector a row of memory locations mapping to -the time bins. As usual in SICS the syntax is the name of the histogram -memory followed by qualifiers and parameters. As a placeholder for the -histogram memories name in your system, HM will be used in the following -text. - -A word or two has to be lost about the SICS handling of preset values for -histogram memories. - Two modes of operation have to be distinguished: counting until a timer has passed, -for example: count for 20 seconds. This mode is called timer mode. In the other -mode, counting is continued until a control monitor has reached a certain -preset value. This mode is called Monitor mode. The preset values in Monitor -mode are usually very large. Therefore the counter has an exponent data variable. -Values given as preset are effectively 10 to the power of this exponent. For -instance if the preset is 25 and the exponent is 6, then counting will be -continued until the monitor has reached 25 million. Note, that this scheme with -the exponent is only in operation in Monitor mode. - -\subsection{ Configuration} - - - -A HM has a plethora of configuration options coming with it which define -memory layout, modes of operation, handling of bin overflow and the like. -Additionally there are HM model specific parameters which are needed -internally in -order to communicate with the HM. In -most cases the HM will already have been configured at SICS server startup -time. However, there are occasion where these configuartion option need to -enquired or modified at run time. The command to enquire the current value -of a configuration option is: {\bf HM configure option}, the command to set it is: -{\bf HM configure option newvalue}. A list of common configuration options and their -meaning is given below: -\begin{description} -\item[ HistMode] HistMode describes the modes of operation of the histogram memory. -Possible values are: -\begin{itemize} -\item Transparent, Counter data will be written as is to memory. For debugging -purposes only. -\item Normal, neutrons detected at a given detector will be added to the - apropriate memory bin. -\item TOF, time of flight mode, neutrons found in a given detector will be -put added to a memory location determined by the detector and the time -stamp. -\item Stroboscopic mode. This mode serves to analyse changes in a sample due -to an varying external force, such as a magnetic field, mechanical stress -or the like. Neutrons will be stored in memory according to detector -position and phase of the external force. -\end{itemize} -\item[ OverFlowMode] This parameter determines how bin overflow is handled. This happend -when more neutrons get detected for a particular memory location then are -allowed for the number type of the histogram memory bin. Possible values -are: -\begin{itemize} -\item Ignore. Overflow will be ignored, the memory location will wrap around -and start at 0 again. -\item Ceil. The memory location will be kept at the highest posssible value -for its number type. -\item Count. As Ceil, but a list of overflowed bins will be maintained. -\end{itemize} -\item[ Rank] Rank defines the number of histograms in memory. -\item[ Length ] gives the length of an individual histogram. -\item[ BinWidth] determines the size of a single bin in histogram memory in bytes. -\item[dim0, dim1, dim2, ... dimn] define the logical dimensions of the histogram. Must be set if the - the sum command (see below) is to be used. This is a clutch necessary to - cope with the different notions of dimensions in the SINQ histogram memory - and physics. -\end{description} -For time of flight mode the time binnings can be retrieved and modified with -the following commands. Note that these commands do not follow the configure -syntax given above. Please note, that the usage of the commands for -modifying time bins is restricted to instrument managers. -\begin{description} -\item[HM timebin] Prints the currently active time binning array. -\item[HM genbin start step n] Generates a new equally spaced time binning array. Number n time bins -will be generated starting from start with a stepwidth of step. -\item[HM setbin inum value] Sometimes unequally spaced time binnings are needed. These can be -configured with this command. The time bin iNum is set to the value value. -\item[HM clearbin] Deletes the currently active time binning information. -\end{description} - -\subsection{Histogram Memory Commands} - - - -Besides the configuration commands the HM understands the following -commands: -\begin{description} -\item[HM preset] with a new value sets the preset time or monitor for counting. Without a -value prints the current value. -\item[HM exponent] with a new value sets the exponent to use for the preset time -in Monitor mode. Without a -value prints the current value. -\item[CountMode ] with a new values sets the count mode. Possible values are Timer for a -fixed counting time and Monitor for a fixed monitor count which has to be -reached before counting finishes. Without a value print the currently active -value. -\item[HM init ] after giving configuration command sthis needs to be called in order to -transfer the configuration from the host computer to the actual HM. -\item[HM count] starts counting using the currently active values for CountMode and -preset. This command does not block, i.e. in order to inhibit further -commands from the console, you have to give Success afterwards. -\item[HM InitVal val] initialises the whole histogram memory to the value val. Ususally 0 in -order to clear the HM. -\item[ HM get i iStart iEnd] retrieves the histogram number i. A value of -1 for i denotes retrieval -of the whole HM. iStart and iEnd are optional amd -allow to retrieve a subset of a histogram between iStart and iEnd. -\item[HM sum d1min d1max d2min d2max .... dnmin dnmax] calculates the sum of an area on the detector. For each dimension a - minimum and maximum boundary for summing must be given. -\end{description} - -% html: End of file: `histogram.htm' -% html: Beginning of file: `nextrics.htm' - -\section{TRICS NeXus File Writing Object} - -\label{f23} - -TRICS writes its data files in the upcoming NeXus data format standard for -neutron scattering and X-ray diffraction. The user may interact with this -object through the following commands: -\begin{description} -\item[nexus start] Starts a new NeXus file. -\item[nexus reopen filename] Reopens a NeXus file which has already been written to. -\item[nexus dumpframe] Writes a frame of data at the current settings to the NeXus file. -\item[nexus file] Prints the filename of the data file currently in use. -\end{description} - -% html: End of file: `nextrics.htm' -\end{document}