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

- Fixed a bug at the new counter driver

Browse Source 
SKIPPED:
	psi/el737hpdriv.c
	psi/el737hpv2driv.c
	psi/make_gen
	psi/psi.c
	psi/tas.c
	psi/tasdrive.c
	psi/tasinit.c
	psi/tasscan.c
	psi/tasutil.c
This commit is contained in:
cvs
2003-08-08 07:30:40 +00:00
parent 3ddb19d8a9
commit 189f7563b6
11 changed files with 272 additions and 705 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
counter.c
View File

@ -473,6 +473,7 @@
SetStatus(eOld);
return iRet;
}
/*-----------------------------------------------------------------------*/
/*-------------------------------------------------------------------------*/

41
doc/master.tex
View File

@ -191,13 +191,8 @@ This document also explains how to get hold the source code for most
\subsubsection{Backup}
The laboratory server is also the central backup server for SINQ. Backups are
performed with the Legato networker software onto a tape jukebox holding
5 tapes with 20GB capacity each. The following items are backed up through
this system:
\begin{itemize}
\item The laboratory server.
\item The instrument accounts on the instrument computers.
\item The lnsdata and lnslib shares of the lns00 Windows--NT server.
\end{itemize}
5 tapes with 20GB capacity each. Currently only the /home (holding
user home directories) and the /lnsarchive hierarchy are backed up.
This backup system is a protection against a major harddisk failure. It is no
archive system. Though backup tapes are held as long as possible it
cannot be guaranteed that files older then half a year can be recovered.
@ -205,6 +200,38 @@ This backup system is a protection against a major harddisk failure. It is no
system. No further documentation exists, but the setup can be viewed
through the nwadmin application.
The instrument accounts on the instrument computers must be backed up
as well because they sometimes contain valuable scripts. Unfortunately
there are not enough Networker licenses to go round and there is no
reliable linux client software for our version of Legato Networker.
Therefore the data in the instrument accounts is copied nightly to a
special account on lnsa15 which is subjected to the normal
backup. More details:
\begin{itemize}
\item There is a script which does the copying. It is {\bf backupinst}
in either /data/lnslib/bin or
/afs/.psi.ch/project/sinq/linux/bin. This script is called with {\bf
backupinst INST} where INST must be replaced by the instrument name in
capitals. This script essentially calls rsync with appropriate
arguments to synchronize the instrument account minus the data
directory (which is automatically copied anyway).
\item backupinst is triggered by a cron job. For this to work each
instrument computer must have an entry in crontab reading like:
\begin{verbatim}
0 3 * * * /data/lnslib/bin/backupinst TOPSI >/tmp/topsi.log 2>&1
\end{verbatim}
Please replace paths and instrument names to match the instrument.
\item The backup account on lnsa15 is named SINQINST, password:
333SINQINST555. It contains a directory for each supported
instruments. For backupinst to work properly there must be a line in
the .rhosts file of this account for each instrument computer which
reads:
\begin{verbatim}
instcomputer.psi.ch root
\end{verbatim} Please note that this has to be the pcXXXX name for
linux instrument computers, not the DNS alias.
\end{itemize}
\subsubsection{Motor Parameter Backup}
At SINQ the PSI EL--734 motor controllers are used. These motor controllers

18
doc/programmer/command.tex
View File

@ -1,7 +1,7 @@
\chapter{Writing new SICS Commands}
If you wish to write a new command or add a completely new piece of hardware to
SICS, this is the chapter to study. There are two ways to implement
new commands into SICS: hrough the internal Tcl scripting language and
new commands into SICS: through the internal Tcl scripting language and
in ANSI--C. This section describes command writing in ANSI--C. You
should consider using Tcl when:
\begin{itemize}
@ -328,12 +328,12 @@ command in the first place.
Be careful with commands for deleting objects though. SICS objects may
be aliased, used by other objects or connected through the callback
interface (see \ref{inter}). SICS does not implement proper
bookeeping on all these relationships and thus deleting a command from
bookkeeping on all these relationships and thus deleting a command from
SICS without taking this into account may cause SICS to dump core on
you.
\section{Interacting with the Client Connection}
\section{Interacting with the Client Connection}\label{gow}
A SICS command writer needs to interact with the client connection for
a variety of reasons:
\begin{itemize}
@ -349,7 +349,7 @@ has to be passed frequently into lower level code as an argument.
\subsection{Writing and Reading to the Client}
All I/O to the client has to be processed through the I/O functions
for connections defined in conman.h and implemented in conman.c. The
most bable of these are SCWrite and SCPrompt.
most common of these are SCWrite and SCPrompt.
These function will now be inspected in more detail:
\begin{verbatim}
int SCWrite(SConnection *pCon, char *pText, int eCode);
@ -370,7 +370,7 @@ SCWrite does with the message:
code specified.
\item The message is written to all log files configured for the client
connection.
\item If the client privilege is useer or manager, the data isw ritten
\item If the client privilege is user or manager, the data is written
to the command log.
\item The message is written to the server log together with the socket
number of the connection.
@ -438,7 +438,7 @@ On occasion a SICS object may come to the conclusion that an error is
so bad that the measurement needs to be stopped. Clearly a means is
needed to communicate this to upper level code. This means is setting
an interrupt on the connection.
The current interrupt active interrupt is located at the connection object
The current active interrupt is located at the connection object
and can be retrieved with {\bf SCGetInterrupt} and set with {\bf
SCSetInterrupt}. Interrupt codes are defined in interrupt.h and are ordered
into a hierarchy:
@ -511,7 +511,7 @@ StartMotor starts the motor name to run to the new value
fNew. StartCounter starts the counter name. The counter must have been
loaded with proper presets etc. with the appropriate function
calls. The device executor hides behind the pExeList pointer. This is
always accessible through the global pointer: pServ->pExecutor.
always accessible through the global pointer: \verb+pServ->pExecutor+.
Once a counter or motor has been started, quite often the command can
only continue if the operation has finished. But during this time the
@ -569,7 +569,7 @@ process. And she might not be all to happy if the new command just
continues with the next step rather then aborting the process.
\section{SICS Interfaces}\label{interface}
\section{SICS Interfaces}\label{interface}\label{inter}
The point about SICS interfaces can best be deduced from an example:
Everybody expects that a motor can be operated through a drive command
or scanned in a scan. But there are other things which should be
@ -605,7 +605,7 @@ considered:
\item The driveable interface should be implemented by virtual
motors. Virtual motors are objects which realize complex movements
possibly involving multiple motors. Examples include driving
wavelength (theta,two theta and possbly curvature motors have to be
wavelength (theta,two theta and possibly curvature motors have to be
moved) or omega two theta.
\item Any time objects are introduced into SICS which repesent
completely new hardware.

40
doc/programmer/kernelguide.tex
View File

@ -34,11 +34,12 @@ SICS sense is defined by a function, the task function. It is of the type:
int TaskFunction(void *pData);
\end{verbatim}
When it is time for the task to execute this function is called, with a
parameter to a the tasks own data structure. This data structure must have
been defined by the user of this module. The task function returns 1, if it
shall continue to live, or 0 if it should be deleted from the task list.
These task functions are kept in a list. The elements of this list are
visited cyclically, when the scheduler runs.
pointer to the tasks own data structure as a parameter. This data
structure must have been defined by the user of this module. The task
function returns 1, if it shall continue to live, or 0 if it should be
deleted from the task list. These task functions are kept in a
list. The elements of this list are visited cyclically, when the
scheduler runs.
The API to this object consists of functions for creating a task manager,
adding tasks to the task list and to run the task list. Other functions
@ -102,7 +103,7 @@ SICS should be changed. For instance to Token--Ring or AppleTalk or
whatever.
The network reader implements the polling for network message in the SICS
server. It is organized as one of the SICS system tasks. Polling in a POSIX
environment is all about the select system call. The select system call
environment is all about the select() system call. The select() system call
allows to enquire if an open TCP/IP socket has data pending to be read, can
be written to etc. For more details see the unix man pages for the select
system call. An earlier version of the SICS server had a list of connection
@ -135,13 +136,15 @@ the system and the network reader registers a new client command port.
The normal client command ports are accepted connections from a client. The
SICS server expects commands to be sent from the clients. Thus any data
pending on such a socket will be read, split into single commands at the \\n
and put into the connections command stack for execution. At this place
there is also the check for the special interrupt string on command
connections (see \ref{prot1}).
pending on such a socket will be read and split into single commands at
the newline character. Now the network reader checks if the command
represents an interrupt(see \ref{prot1}) and if so process the interrupt
immediately. If not then command is put into the connections command
stack for execution.
The SICS server accepts only interrupts on its UDP port. This will be checked
for when handling data pending on the servers UDP port.
The SICS server accepts interrupts also on its UDP port. This will be checked
for when handling data pending on the servers UDP port. This feauture
is implemented but not well tested and not used in the moment.
User type sockets are a feature for dealing with extremely slow hardware
connections. Some hardware devices require a long time to answer requests.
@ -287,14 +290,15 @@ For the SICS concept for handling sample environment devices see
\section{The Server}
The server module defines a server data structure. A pointer to this
data structure is the sole global variable in the SICS system. Its name is
{\bf {\huge pServ}}. This data structure contains pointers to the most
{\bf pServ}. This data structure contains pointers to the most
important SICS components: the interpreter, the task switcher, the device
executor, the environment monitor and the network reader. This module also
contains the code for initializing, running and stopping the server.
\section{The Performance Monitor}
This facility provides the data for the Performance (see user documentation)
This facility provides the data for the ``Performance''
(see user documentation)
command. The Performance Monitor is a task which increments a counter each
time it is executed. After a predefined integration time (20 seconds) a new
value cycles/per second is calculated. This is the data retrievable by the
@ -307,7 +311,7 @@ monitor may well be removed from the system without harm.
\section{The Object Factory}
During SICS initialization the SICS interpreters command list needs to be
initialized. This is the task of the object factory. Its function
IniIniCommand initializes all fixed, general SICS commands and all object
InitIniCommands initializes all fixed, general SICS commands and all object
creation commands. Then the server initialization file is processed from the
server initialization code. After this is done, the server initialization
code calls KillIniCommands which removes the now surplus object creation
@ -387,3 +391,9 @@ the status file has to implement a function which will
automatically be called when a status file is written. For details,
consult the chapter on SICS object implementation.

49
doc/programmer/overview.tex
View File

@ -14,7 +14,8 @@ System, had to meet the following specifications:
\item Enhanced portability across instrument hardware. This means that it
should be easy to add other types of motors, counters or other hardware to
the system.
\item Support authorization on the command and variable level. This means
\item Support authorization on the command and parameter modification
level. This means
that certain instrument settings can be protected against random changes by
less knowledgable users.
\item Good maintainability and extendability.
@ -78,7 +79,7 @@ This is a real concern at SINQ where VMS,
Intel-PC, Macintosh and Unix users have to be satisfied.
As many instrument scientists still prefer
the command line for interacting with instruments, the most used client is a
visual command line client. Status displays are another sort of specialized
visual command line client. Status displays are another kind of specialized
client programs. Graphical user interfaces are under consideration for some
instruments. As an example for a client a screen shot of the status display
client for a powder diffractometer is given in picture \ref{dmc}
@ -86,7 +87,7 @@ client for a powder diffractometer is given in picture \ref{dmc}
\begin{figure}
%% \epsfxsize=0.65\textwidth
\epsfxsize=160mm
%% \epsffile{dmc.eps}
\epsffile{dmccom.eps}
\caption{Example for a SICS client: Powder Diffractometer Status Display}\label{dmc}
\end{figure}
@ -129,10 +130,10 @@ In more detail the SICS server kernel has the following tasks:
\item Monitor HW--operations.
\item Monitor environment devices.
\end{itemize}
Any server serving multiple clients has the problem how to organize multiple
clients accessing the same server and how to stop one client reading data,
which another client is just writing. The approach used for the SICS server
is a combination of polling and cooperative multitasking. This scheme is
Any program serving multiple clients has the problem how to organize multiple
clients accessing the same server and how to prevent one client from
reading data, while another client is writing. The approach used for
the SICS server is a combination of polling and cooperative multitasking. This scheme is
simple and can be implemented in an operating system independent manner. One
way to look at the SICS server is as a series of tasks in a circular queue
executing one after another. The servers main loop does nothing but
@ -151,8 +152,7 @@ client connection and create the associated data structures. If the port
belongs to an open client connection the network reader will read the
command pending and put it onto a command stack existing for each client
connection. When it is time for a client task to execute, it will fetch a
command from its very own command stack and execute it. When the net reader
finds an user interrupt pending, the interrupt is executed.
command from its very own command stack and execute it.
This is how the SICS server deals with client requests.
The scheme described above relies on the fact that most SICS command need
@ -181,7 +181,7 @@ an hardware request all other clients requests to drive the hardware will
return an error. The device executor is also responsible for monitoring the
progress of an hardware operation. It does so by adding a special task into
the system which checks the status of the operation each time this tasks
executes. When the hardware operation is finished (one way or another) this
executes. When the hardware operation is finished this
device executor task will end. A special system facility allows a client
task to wait for the device executor task to end while the rest of the task
queue is still executing. In this way time intensive hardware operations can
@ -258,7 +258,7 @@ can be configured to tell SICS clients or other SICS objects about his new
position.
SICS uses NeXus$^{2}$, the upcoming standard for data exchange for neutron
and x\_ray scattering as its raw data format.
and x--ray scattering as its raw data format.
\section{SICS Working Examples}
@ -279,10 +279,10 @@ done by a special system component, the task switcher.
\subsection{The Request for a new Client Connection}
\begin{itemize}
\item The network reader recognizes pending data on its main server port.
\item The network reader accepts the connection and tries to read a
\item The network reader accepts the connection and tries to read an
username/password pair.
\item If such a username/password pair comes within a suitable time
intervals it is checked for validity. On failure the connection is closed
\item If such an username/password pair comes within a suitable time
interval it is checked for validity. On failure the connection is closed
again.
\item If a valid connection has been found: A new connection object is
created, a new task for this client connection is introduced into the
@ -312,7 +312,7 @@ task to the task switcher.
\item The next task executes.
\end{itemize}
\subsection{A Drive Command in Blocking Mode}
\subsection{A ``Drive'' Command in Blocking Mode}
\begin{itemize}
\item The network reader finds data pending at one of the client ports.
\item The network reader reads the command, splits it into single lines and
@ -342,8 +342,8 @@ requesting the wait state. The client connection and task executing the drive co
\item The device executor task will keep on monitoring the progress of the motor
driving whenever the task switcher allows it to execute.
\item In due time the device executor task will find that the motor finished
driving. The task will then die. The clients grab of the hardware driving
permission will be released.
driving. The task will then finish executing. The clients grab of the
hardware driving permission will be released.
\item At this stage the drive command wrapper function will awake and
continue execution. This means inspecting errors and reporting to the client
how things worked out.
@ -353,7 +353,7 @@ other commands.
\item The next task executes.
\end{itemize}
\subsection{A Drive Command Interrupted}
\subsection{A ``Drive Command Interrupted}
\begin{itemize}
\item The network reader finds data pending at one of the client ports.
\item The network reader reads the command, splits it into single lines and
@ -396,7 +396,7 @@ task to the task switcher.
\item The next task executes.
\end{itemize}
\subsection{A Run Command in Non Blocking Mode}
\subsection{A ``Run'' Command in Non Blocking Mode}
\begin{itemize}
\item The network reader finds data pending at one of the client ports.
\item The network reader reads the command, splits it into single lines and
@ -408,13 +408,13 @@ itself to the SICS interpreter.
\item The SICS interpreter inspects the first word of the command. Using
this key the interpreter finds the drive command wrapper function and passes
control to that function.
\item The run command wrapper function will check further arguments,
\item The ``run'' command wrapper function will check further arguments,
checks the
clients authorisation if appropriate for the action requested. Depending on
the checks, the wrapper function will create an error message or do its
work.
\item Assuming everything is OK, the motor is located in the system.
\item The drive command wrapper function asks the device executor to run the
\item The ``run'' command wrapper function asks the device executor to run the
motor.
\item The device executor verifies that nobody else is driving, then starts
the motor and grabs hardware control. The device executor also starts a task
@ -432,10 +432,11 @@ permission will be released. Any errors however, will be reported.
All this seems to be pretty complex and time consuming. But it is the complexity needed to
do so many things, especially the non blocking mode of operation requested
by users. Tests have shown that the task switcher manages +900 cycles
per second through the task list on a DigitalUnix machine and 50
cycles per second on a pentium 133mhz machine running linux. Both data
per second through the task list on a DigitalUnix machine and 500
cycles per second on a pentium 2GHZ machine running linux. Both data
were obtained with software simulation of hardware devices. With real
SINQ hardware these numbers drop 4 cycles per second. This shows
SINQ hardware these numbers drop to as low as 4 cycles per second if
the hardware is slow in responding. This shows
clearly that the communication with the hardware is the systems
bottleneck and not the task switching scheme.

2
doc/programmer/programmer.tex
View File

@ -14,6 +14,8 @@
\setlength{\textheight}{8.9in}
\setlength{\textwidth}{6.2in}
\setlength{\marginparwidth}{0.5in}
\setlength{\parindent}{0cm}
\setlength{\parskip}{.2cm}
\begin{document}
\title{The SICS Programmers Reference}

8
doc/programmer/proto.tex
View File

@ -9,20 +9,20 @@ The SICS server implements the most primitive telnet server possible
and does not support any of the fancy options possible with
telnet. Using the telnet protocoll involves:
\begin{itemize}
\item Open a scoket conenction to SICS telnet port
\item Open a socket connection to SICS's telnet port
\item Send a login word followed by a username and a password. The
login word is set in SICS initialization file as the SicsOption
TelWord.
\item On success a welcome message is printed, otherwise SICS
terminates the connection.
\item Now commands can be sent, but watch for the telnet protocoll
specification in RFC-?????.
specification in the telnet RFC.
\end{itemize}
\section{Connection using a plain Connection}
This protocoll involves:
\begin{itemize}
\item Open a scoket conenction to SICS telnet port
\item Open a socket connection to SICS's plain port
\item Send a username and a password.
\item On success OK is printed, otherwise SICS
terminates the connection.
@ -59,3 +59,5 @@ resolved in file interrupt.h.

76
doc/programmer/sicsdriver.tex
View File

@ -29,6 +29,23 @@ All drivers use a common pattern for error handling. Please read the
section on the motor driver where this pattern is explained in more
detail. The same pattern is applied in most drivers.
Please be aware that the hardware drivers have a significant impact on
SICS's overall performance. Most of the time SICS will be sitting
there and wait for a counter or a motor to finish. And often the
devices controlling such things respond pretty slow. The most often
called function is the status check function of the driver. It is
advisable to optimize this is good as possible. Suggestions for this
include:
\begin{itemize}
\item Reduce the amount of data to be read from the controller as much
as possible.
\item Make the status function a state machine: in the first state a
status request command is sent and the second state is entered. In teh
second state, the function checks if data is available on the
communication port and process if this is so, else it returns the
appropriate busy code.
\end{itemize}
This section describes the actual drivers. How these drivers are
integrated into SICS is described in the chapter on the site data
structure (see \ref{site}).
@ -86,12 +103,15 @@ switches on the real thing. Read them from the motor or initialize
them from parameters when initializing the motor driver.
\item[GetPosition] reads the position of the motor and puts the result
into fPos. This ought to be the position from the motor
controller. Software zeros are applied later by code in motor.c.
controller. Software zeros are applied later by code in
motor.c. GetPosition returns either OKOK when the request succeeded
or HWFault on failure.
\item[RunTo] Starts the motor to run towards the new position
fNewVal. fNewVal must be a value valid for the controller. Software
zero points have already been taken account of by code in
motor.c. This function shall NOT wait for the completion of the
driving operation.
driving operation. RunTo returns either OKOK when the request succeeded
or HWFault on failure.
\item[GetStatus] This function is called repeatedly by upper level
code to poll for the progress of the driving operation. Possible
return values of this function are:
@ -135,7 +155,7 @@ upper level code in motor.c: If an error in any function occurs,
GetError gets called. An error message is printed. Then TryAndFixIt is
called with the error code returned in iCode as a parameter. If
TryAndFixIt returns MOTFAIL, the code gives up. If TryAndFixIt
returns MOTREDO, the failed operation is retried. At max retries are
returns MOTREDO, the failed operation is retried. At max 3 retries are
performed. If the operation does not succeed after three
retries, a motor failure is reported.
@ -149,7 +169,7 @@ no such parameters have these functions do nothing and return 1.
\section{The Counter Driver}
A counter driver is a driver for some box which allows to count for a
preset time or monitor and manages single counters and monitors. Such
a driver is reprsented by a data structure:
a driver is represented by a data structure:
\begin{verbatim}
typedef struct __COUNTER {
/* variables */
@ -216,13 +236,13 @@ cached in lCounts.
paused.
\item[iErrorCode] A private variable holding error codes.
\item[GetStatus] This function is called while upper
elvel code polls for the counter to finish. It has to return the
level code polls for the counter to finish. It has to return the
status of the counting operation and update the current value of the
control variable in fControl. Possible return values are:
\begin{description}
\item[HWBusy] when counting.
\item[HWIdle] when finished counting or idle.
\item[HWNoBeam] when counting is interrupted due to lack of beam.
\item[HWNoBeam] when counting is halted due to lack of beam.
\item[HWPause] if counting is paused.
\item[HWFault] if the status cannot be obtained.
\end{description}
@ -233,11 +253,11 @@ previously confugured. Do NOT wait for counting to finish!
\item[Halt] stop counting.
\item[ReadValues] read all counters and monitors into lCounts.
\item[GetError] retrieves information about an error which occurred on
the counter. An integer error code is returned in iCode. Up to iBufLen
the counter. An integer error code is returned in iCode. Up to iErrLen
characters of descriptive error information is copied into
buffer. This information is printed as error message by upper level
error. This information is printed as error message by upper level
code.
\item[TryAndFixIt] Given an error code in iError, try to repair the
\item[TryAndFixIt] Given an error code in iCode, try to repair the
problem as far as this is possible in software. iError should be an
error code as returned by GetError in iCode. This function has the
following return codes:
@ -248,8 +268,8 @@ following return codes:
\item[Set] set parameter name associated with counter iCter to fVal.
\item[Get] return in fVal the value of parameter name associated with
iCter. These two functions allow to set counter driver parameters.
\item[Send] send pText to the counter controller and return iReplylen
characters of repsonse from the counter controller in pReply. This is
\item[Send] send pText to the counter controller and return iReplyLen
characters of response from the counter controller in pReply. This is
a bypass to set controller parameters manually.
\item[KillPrivate] properly delete counter driver private data
pData. Also close any connections to the hardware.
@ -295,9 +315,9 @@ is replaced by a standard one based on GetValue if not present.
at max iReplBuflen bytes of result in pReplyBuffer. This is breakout
which allows to send arbitray data to the controller.
\item[GetError] retrieves information about an error which occurred on
the device. An integer error code is returned in iCode. Up to iBufLen
the device. An integer error code is returned in iCode. Up to iErrLen
characters of descriptive error information is copied into
buffer. This information is printed as error message by upper level
pError. This information is printed as error message by upper level
code.
\item[TryAndFixIt] Given an error code in iError, try to repair the
problem as far as this is possible in software. iError should be an
@ -308,7 +328,7 @@ following return codes:
\item[DEVFAULT] The problem cannot be fixed in software.
\end{description}
\item[Init] initializes a connection to a controller and puts the
thing into the right mode (or mood?).
thing into the right mode.
\item[Close] closes a connection to a controller.
\item[pPrivate] A pointer to a driver specific data structure which
can be filled with meaning by instances of drivers.
@ -317,7 +337,7 @@ with pPrivate.
\end{description}
\section{Histogram Memory}
\section{Histogram Memory Drivers}
Histogram memories are devices in which neutron events for area
detector or time--of--flight detectors are assigned to their correct
bins. Then these usually large data sets have to be transferred to
@ -392,7 +412,7 @@ structure given below:
} HistDriver;
\end{verbatim}
All functions take a pointer to their driver data structure as an
argument. If not stated otherwise they retun 1 on success, 0 on failure.
argument. If not stated otherwise they return 1 on success, 0 on failure.
\begin{description}
\item[data] Is a pointer to an HMdata object which does all the
dimension handling, buffers histogram memory content, deals with time
@ -423,8 +443,8 @@ operation. Possible return values to this call are:
\end{itemize}
\item[GetError] will be called whenever an error has been detected on
the device. The task is to put an internal error code into the iCode
parameter. The string parameter error will be filled with a text description
of the error. But maximum iLen characters will be transferred to the error
parameter. The string parameter perror will be filled with a text description
of the error. But maximum iErrlen characters will be transferred to the error
string in order to protect against memory corruption. Therefore iLen must be
the maximum field length of error.
\item[TryAndFixIt] is the next function called in case of an error on
@ -435,20 +455,20 @@ TryAndFixIt returns one of the following values:
\begin{itemize}
\item COREDO when the error could be fixed, but the upper level code will
need to rerun the command which failed.
\item COFAIL when the software is unable to fix the problem and a real
\item COTERM when the software is unable to fix the problem and a real
mechanic with a hammer is needed (or somebody able to reboot!).
\item MOTOK when the error was fixed and nor further action is necessary.
\end{itemize}
\item[GetData] transfers all the data collected in the HM into the
host computers memory buffer.
\item[GetHistogram] copies data betwen iStart and iend from histogram
\item[GetHistogram] copies data between iStart and iEnd from histogram
bank i into the data space pData. Please make sure that pData is big
enough to hold the data.
\item[SetHistogram] presets the histogram bank i i with the data
\item[SetHistogram] presets the histogram bank i with the data
given in lData. A conversion from different binwidth
to long is performed as well. iStart and iStop define the start and end of
the stretch of histogram to replace.
\item[GetMonitor] returns the counts in the monitor i. Returns a
\item[GetMonitor] returns the counts in the monitor i. GetMonitor returns a
negative value on error. The error will have been printed to pCon.
\item[GetTime] returns the actual counting time.
\item[Preset] initializes the histogram memory to the value given by
@ -496,7 +516,7 @@ described below. The velocity selector driver data structure includes:
}VelSelDriv;
\end{verbatim}
All functions take a pointer to their driver data structure as an
argument. If not stated otherwise they retun 1 on success, 0 on failure.
argument. If not stated otherwise they return 1 on success, 0 on failure.
The fields:
\begin{description}
\item[pPrivate] a pointer to a driver private data structure.
@ -524,7 +544,7 @@ NOT wait until finished.
operation. It returns:
\begin{description}
\item[VSACCEL] when the velocity selector is accelerating.
\item[VSFAIL] is the status cannot be read.
\item[VSFAIL] if the status cannot be read.
\item[VSOK] when the velocity seelctor has reached its target speed.
\end{description}
The current rotation speed is returned in *fCur. iCall is a value
@ -537,15 +557,15 @@ to be started first.
\end{description}
\item[GetDriverText] returns iTextLen bytes of additional status
information in pText. This is a list name: value pairs separated by
komma. This is meant to hold additional selector readouts such as
commata. This is meant to hold additional selector readouts such as
vacuum states, temperatures etc.
\item[GetLossCurrent] initiates a measurement of the loss current of
the velocity seelctor. The result is returned in *fLoss.
the velocity selector. The result is returned in *fLoss.
\item[Init] initiates a connection to a velocity selector.
\end{description}
It may be possible that this driver is not very general. It was
developed for Dornier velocity seelctors because these were the only
developed for Dornier velocity selectors because these were the only
one seen.
\section{General Controller Driver}
@ -583,7 +603,7 @@ restricted to this usage. The driver:
}Codri;
\end{verbatim}
All functions take a pointer to their driver data structure as an
argument. If not stated otherwise they retun 1 on success, 0 on failure.
argument. If not stated otherwise they return 1 on success, 0 on failure.
The fields:
\begin{description}
\item[Init] initializes a connection to the controller and the driver.

14
doc/programmer/site.tex
View File

@ -82,16 +82,16 @@ Configure in the histogram memory driver.
\end{itemize}
On success a pointer to
new driver is returned, on failure NULL.
\item[CreateVelSelDriv] creates a driver for a velocity selector. The
\item[CreateVelolcitySelector] creates a driver for a velocity selector. The
driver is identified by nname, array is the name of a Tcl array in
pTcl holding initialization parameters for name.
\item[MakeController] generates a driver for a SICS general controller
\item[CreateControllerDriver] generates a driver for a SICS general controller
object. \verb+argv[0]+ is the driver identifier, the rest of argc,
\verb+argv[]+ are further initialization parameters. Any errors in
parsing argc, argv can be reported to pCon. On success a pointer to
new driver is returned, on failure NULL.
\item[InstallEnvironmentController] installs a sample environment
controller into pSics. \verb+argv[3]+ is the driver indentifier,
controller into pSics. \verb+argv[3]+ is the driver identifier,
\verb+argv[2]+ is the SICS name of the environment device command, the
rest are initialization parameters. This function must also install
the command into pSics with AddCommand. This is because for many PSI
@ -103,8 +103,8 @@ controller is returned, on failure NULL.
to the value of option. Returns 1 on success and 0 on failure. SICS
general scan object is a data structure holding function pointers for
various steps in the scan. These functions can be overloaded in order
to provide for special scans. See the documentation ins scan.tex,
scan.h and scan.c from more details.
to provide for special scans. See the documentation in scan.tex,
scan.h and scan.c for more details.
\end{description}
@ -115,8 +115,8 @@ controller object.
The site data structure suffers a little from inconsistencies
introduced through varying concepts for initializing SICS objects introduced
during the development of SICS. If you need to bypass the schemes
introduced through varying concepts for initializing SICS objects implemented
in various stage of the development of SICS. If you need to bypass the schemes
introduced here, consider implementing an own factory command and
install it through AddSiteCommand, RemoveSiteCommand.

183
evcontroller.c
View File

@ -1143,6 +1143,114 @@
}
return 0; /* not reached */
}
/*-----------------------------------------------------------------------*/
static pEVControl InstallCommonControllers(SicsInterp *pSics,
SConnection *pCon,
int argc, char *argv[])
{
pEVControl pNew = NULL;
pEVDriver pDriv = NULL;
char pBueffel[512],pError[132];
int iRet;
int (*Wrapper)(SConnection *pCon, SicsInterp *pSics, void *pData,
int argc, char *argv[]) = EVControlWrapper;
if(strcmp(argv[3],"sim") == 0) /* SIM driver */
{
/* Create a Sim Driver */
pDriv = CreateSIMEVDriver(argc-4,&argv[4]);
if(!pDriv)
{
SCWrite(pCon,
"ERROR: failed to create Environment Device driver",
eError);
return NULL;
}
}
else if(strcmp(argv[3],"tcl") == 0) /* Tcl driver */
{
/* Create a Tcl driver */
pDriv = CreateTclDriver(argc-4,&argv[4],argv[2], pCon);
if(!pDriv)
{
SCWrite(pCon,"ERROR: failed to create TCL device driver",eError);
return NULL;
}
/* got a driver, initialise everything */
pNew = CreateEVController(pDriv,argv[2],&iRet);
if(!pNew)
{
SCWrite(pCon,"ERROR creating Environment Controller",eError);
DeleteEVDriver(pDriv);
return NULL;
}
if(!iRet)
{
SCWrite(pCon,"ERROR: problem initialising Environment controller",
eError);
pDriv->GetError(pDriv,&iRet,pError,131);
sprintf(pBueffel,"HW reported: %s",pError);
SCWrite(pCon,pBueffel,eError);
}
Wrapper = TclEnvironmentWrapper;
pNew->iTcl = 1;
/* make ev parameters available to Tcl */
UpdateTclVariable(pNew->pDriv,"tolerance",
ObVal(pNew->pParam,TOLERANCE));
UpdateTclVariable(pNew->pDriv,"upperlimit",
ObVal(pNew->pParam,UPLIMIT));
UpdateTclVariable(pNew->pDriv,"lowerlimit",
ObVal(pNew->pParam,LOWLIMIT));
}
else if(strcmp(argv[3],"gencon") == 0) /* general controller */
{
/* Create a driver */
pDriv = MakeControllerEnvironmentDriver(argc-4,&argv[4]);
if(!pDriv)
{
SCWrite(pCon,
"ERROR: failed to create Controller Environment driver",
eError);
return NULL;
}
} else {
return NULL; /* not recognized */
}
if(pNew == NULL) /* not yet initialized */
{
pNew = CreateEVController(pDriv,argv[2],&iRet);
if(!pNew)
{
SCWrite(pCon,"ERROR creating Environment Controller",eError);
DeleteEVDriver(pDriv);
return NULL;
}
if(!iRet)
{
SCWrite(pCon,"ERROR: problem initialising Environment controller",
eError);
pDriv->GetError(pDriv,&iRet,pError,131);
sprintf(pBueffel,"HW reported: %s",pError);
SCWrite(pCon,pBueffel,eError);
}
}
/* install command */
iRet = AddCommand(pSics,argv[2],Wrapper,
DeleteEVController,
pNew);
if(!iRet)
{
sprintf(pBueffel,"ERROR: duplicate command %s not created",
argv[2]);
DeleteEVController((void *)pNew);
SCWrite(pCon,pBueffel,eError);
return NULL;
}
return pNew;
}
/*-------------------------------------------------------------------------
EVControlFactory implements a SICS command which creates and deletes
Controllers at run-time. Syntax:
@ -1156,7 +1264,6 @@
int argc, char *argv[])
{
pEVControl pNew = NULL;
pEVDriver pDriv = NULL;
char pBueffel[512],pError[132];
int iRet;
CommandList *pCom = NULL;
@ -1223,78 +1330,8 @@
SCWrite(pCon,pBueffel,eError);
return 0;
}
if(strcmp(argv[3],"sim") == 0) /* SIM driver */
{
/* Create a Sim Driver */
pDriv = CreateSIMEVDriver(argc-4,&argv[4]);
if(!pDriv)
{
SCWrite(pCon,
"ERROR: failed to create Environment Device driver",
eError);
return 0;
}
}
else if(strcmp(argv[3],"tcl") == 0) /* Tcl driver */
{
/* Create a driver */
pDriv = CreateTclDriver(argc-4,&argv[4],argv[2], pCon);
if(!pDriv)
{
SCWrite(pCon,"ERROR: failed to create TCL device driver",eError);
return 0;
}
/* got a driver, initialise everything */
pNew = CreateEVController(pDriv,argv[2],&iRet);
if(!pNew)
{
SCWrite(pCon,"ERROR creating Environment Controller",eError);
DeleteEVDriver(pDriv);
return 0;
}
if(!iRet)
{
SCWrite(pCon,"ERROR: problem initialising Environment controller",
eError);
pDriv->GetError(pDriv,&iRet,pError,131);
sprintf(pBueffel,"HW reported: %s",pError);
SCWrite(pCon,pBueffel,eError);
}
/* install command */
iRet = AddCommand(pSics,argv[2],TclEnvironmentWrapper,
DeleteEVController,
pNew);
if(!iRet)
{
sprintf(pBueffel,"ERROR: duplicate command %s not created",
argv[2]);
DeleteEVController((void *)pNew);
SCWrite(pCon,pBueffel,eError);
return 0;
}
pNew->iTcl = 1;
/* make ev parameters available to Tcl */
UpdateTclVariable(pNew->pDriv,"tolerance",
ObVal(pNew->pParam,TOLERANCE));
UpdateTclVariable(pNew->pDriv,"upperlimit",
ObVal(pNew->pParam,UPLIMIT));
UpdateTclVariable(pNew->pDriv,"lowerlimit",
ObVal(pNew->pParam,LOWLIMIT));
}
else if(strcmp(argv[3],"gencon") == 0) /* general controller */
{
/* Create a driver */
pDriv = MakeControllerEnvironmentDriver(argc-4,&argv[4]);
if(!pDriv)
{
SCWrite(pCon,
"ERROR: failed to create Controller Environment driver",
eError);
return 0;
}
}
else
pNew = InstallCommonControllers(pSics,pCon,argc,argv);
if(pNew == NULL)
{
site = getSite();
if(site != NULL){

535
sicsstatus.tcl
View File

@ -1,536 +1,3 @@
a5l.length 80.000000
flightpathlength 0.000000
flightpathlength setAccess 1
flightpath 0.000000
flightpath setAccess 1
delay 2500.000000
delay setAccess 1
hm CountMode timer
hm preset 100.000000
hm genbin 120.000000 35.000000 512
hm init
datafile focus-1001848.hdf
datafile setAccess 3
hm2 CountMode timer
hm2 preset 10.000000
hm1 CountMode timer
hm1 preset 100.000000
dbfile UNKNOWN
dbfile setAccess 2
# Motor th
th sign 1.000000
th SoftZero 0.000000
th SoftLowerLim -120.000000
th SoftUpperLim 120.000000
th Fixed -1.000000
th InterruptMode 0.000000
th precision 0.010000
th AccessCode 2.000000
th poscount 20.000000
#Crystallographic Settings
hkl lambda 0.703790
hkl setub -0.124702 0.001618 -0.041357 -0.104448 -0.001326 0.049388 0.000751 0.084094 0.001574
hkl hm 0
det3dist 300.000000
det3dist setAccess 1
det3zeroy 128.000000
det3zeroy setAccess 1
det3zerox 128.000000
det3zerox setAccess 1
det2dist 300.000000
det2dist setAccess 1
det2zeroy 128.000000
det2zeroy setAccess 1
det2zerox 128.000000
det2zerox setAccess 1
det1dist 300.000000
det1dist setAccess 1
det1zeroy 128.000000
det1zeroy setAccess 1
det1zerox 128.000000
det1zerox setAccess 1
mono2theta 36.77
mono2theta setAccess 1
monodescription unknownit crystal
monodescription setAccess 1
# Motor om
om sign 1.000000
om SoftZero 0.000000
om SoftLowerLim -73.000000
om SoftUpperLim 134.000000
om Fixed -1.000000
om InterruptMode 0.000000
om precision 0.010000
om AccessCode 2.000000
om poscount 20.000000
# Motor stt
stt sign 1.000000
stt SoftZero 0.000000
stt SoftLowerLim -120.000000
stt SoftUpperLim 120.000000
stt Fixed -1.000000
stt InterruptMode 0.000000
stt precision 0.010000
stt AccessCode 2.000000
stt poscount 20.000000
# Motor ch
ch sign 1.000000
ch SoftZero 0.000000
ch SoftLowerLim 0.000000
ch SoftUpperLim 360.000000
ch Fixed -1.000000
ch InterruptMode 0.000000
ch precision 0.010000
ch AccessCode 2.000000
ch poscount 20.000000
# Motor ph
ph sign 1.000000
ph SoftZero 0.000000
ph SoftLowerLim -360.000000
ph SoftUpperLim 360.000000
ph Fixed -1.000000
ph InterruptMode 0.000000
ph precision 0.010000
ph AccessCode 2.000000
ph poscount 20.000000
# Motor dg3
dg3 sign 1.000000
dg3 SoftZero 0.000000
dg3 SoftLowerLim -10.000000
dg3 SoftUpperLim 40.000000
dg3 Fixed -1.000000
dg3 InterruptMode 0.000000
dg3 precision 0.010000
dg3 AccessCode 2.000000
dg3 poscount 20.000000
# Motor dg2
dg2 sign 1.000000
dg2 SoftZero 0.000000
dg2 SoftLowerLim -10.000000
dg2 SoftUpperLim 40.000000
dg2 Fixed -1.000000
dg2 InterruptMode 0.000000
dg2 precision 0.010000
dg2 AccessCode 2.000000
dg2 poscount 20.000000
# Motor dg1
dg1 sign 1.000000
dg1 SoftZero 0.000000
dg1 SoftLowerLim -10.000000
dg1 SoftUpperLim 40.000000
dg1 Fixed -1.000000
dg1 InterruptMode 0.000000
dg1 precision 0.010000
dg1 AccessCode 2.000000
dg1 poscount 20.000000
# Motor muca
muca sign 1.000000
muca SoftZero 0.000000
muca SoftLowerLim 30.000000
muca SoftUpperLim 36.000000
muca Fixed -1.000000
muca InterruptMode 0.000000
muca precision 0.010000
muca AccessCode 2.000000
muca poscount 20.000000
# Motor phi
phi sign 1.000000
phi SoftZero 0.000000
phi SoftLowerLim -360.000000
phi SoftUpperLim 360.000000
phi Fixed -1.000000
phi InterruptMode 0.000000
phi precision 0.010000
phi AccessCode 2.000000
phi poscount 20.000000
# Motor chi
chi sign 1.000000
chi SoftZero 0.000000
chi SoftLowerLim 0.000000
chi SoftUpperLim 360.000000
chi Fixed -1.000000
chi InterruptMode 0.000000
chi precision 0.010000
chi AccessCode 2.000000
chi poscount 20.000000
# Motor omega
omega sign 1.000000
omega SoftZero 0.000000
omega SoftLowerLim -73.000000
omega SoftUpperLim 134.000000
omega Fixed -1.000000
omega InterruptMode 0.000000
omega precision 0.010000
omega AccessCode 2.000000
omega poscount 20.000000
# Motor twotheta
twotheta sign 1.000000
twotheta SoftZero 0.000000
twotheta SoftLowerLim -120.000000
twotheta SoftUpperLim 120.000000
twotheta Fixed -1.000000
twotheta InterruptMode 0.000000
twotheta precision 0.010000
twotheta AccessCode 2.000000
twotheta poscount 20.000000
lastscancommand cscan a4 0. .2 10 2
lastscancommand setAccess 2
banana CountMode timer
banana preset 100.000000
sample_mur 0.000000
sample_mur setAccess 2
email UNKNOWN
email setAccess 2
fax UNKNOWN
fax setAccess 2
phone UNKNOWN
phone setAccess 2
adress UNKNOWN
adress setAccess 2
# Counter counter
counter SetPreset 2.000000
counter SetPreset 100.000000
counter SetMode Monitor
# Motor som
som sign 1.000000
som SoftZero 0.000000
som SoftLowerLim -360.000000
som SoftUpperLim 360.000000
som Fixed -1.000000
som InterruptMode 0.000000
som precision 0.010000
som AccessCode 2.000000
som poscount 20.000000
# Motor sax
sax sign 1.000000
sax SoftZero 0.000000
sax SoftLowerLim -30.000000
sax SoftUpperLim 30.000000
sax Fixed -1.000000
sax InterruptMode 0.000000
sax precision 0.010000
sax AccessCode 2.000000
sax poscount 20.000000
# Motor tilt
tilt sign 1.000000
tilt SoftZero 0.000000
tilt SoftLowerLim -15.000000
tilt SoftUpperLim 15.000000
tilt Fixed -1.000000
tilt InterruptMode 0.000000
tilt precision 0.010000
tilt AccessCode 0.000000
tilt poscount 20.000000
#----- MultiMotor st
st recovernampos henry d1r 5. d1l -5. d1t 0.
#----- MultiMotor sampletable
sampletable recovernampos henry d1r 5. d1l -5. d1t 0.
# Motor detectorrotation
detectorrotation sign 1.000000
detectorrotation SoftZero 0.000000
detectorrotation SoftLowerLim -20.000000
detectorrotation SoftUpperLim 20.000000
detectorrotation Fixed -1.000000
detectorrotation InterruptMode 0.000000
detectorrotation precision 0.010000
detectorrotation AccessCode 2.000000
detectorrotation poscount 20.000000
# Motor detectory
detectory sign 1.000000
detectory SoftZero 0.000000
detectory SoftLowerLim -20.000000
detectory SoftUpperLim 20.000000
detectory Fixed -1.000000
detectory InterruptMode 0.000000
detectory precision 0.010000
detectory AccessCode 2.000000
detectory poscount 20.000000
# Motor detectorx
detectorx sign 1.000000
detectorx SoftZero 0.000000
detectorx SoftLowerLim -20.000000
detectorx SoftUpperLim 20.000000
detectorx Fixed -1.000000
detectorx InterruptMode 0.000000
detectorx precision 0.010000
detectorx AccessCode 2.000000
detectorx poscount 20.000000
# Motor beamstopy
beamstopy sign 1.000000
beamstopy SoftZero 0.000000
beamstopy SoftLowerLim -20.000000
beamstopy SoftUpperLim 20.000000
beamstopy Fixed -1.000000
beamstopy InterruptMode 0.000000
beamstopy precision 0.010000
beamstopy AccessCode 2.000000
beamstopy poscount 20.000000
# Motor beamstopx
beamstopx sign 1.000000
beamstopx SoftZero 0.000000
beamstopx SoftLowerLim -20.000000
beamstopx SoftUpperLim 20.000000
beamstopx Fixed -1.000000
beamstopx InterruptMode 0.000000
beamstopx precision 0.010000
beamstopx AccessCode 2.000000
beamstopx poscount 20.000000
# Motor d2t
d2t sign 1.000000
d2t SoftZero 0.000000
d2t SoftLowerLim -20.000000
d2t SoftUpperLim 20.000000
d2t Fixed -1.000000
d2t InterruptMode 0.000000
d2t precision 0.010000
d2t AccessCode 2.000000
d2t poscount 20.000000
# Motor d2l
d2l sign 1.000000
d2l SoftZero 0.000000
d2l SoftLowerLim -20.000000
d2l SoftUpperLim 20.000000
d2l Fixed -1.000000
d2l InterruptMode 0.000000
d2l precision 0.010000
d2l AccessCode 2.000000
d2l poscount 20.000000
# Motor d2r
d2r sign 1.000000
d2r SoftZero 0.000000
d2r SoftLowerLim -20.000000
d2r SoftUpperLim 20.000000
d2r Fixed -1.000000
d2r InterruptMode 0.000000
d2r precision 0.010000
d2r AccessCode 2.000000
d2r poscount 20.000000
# Motor d1t
d1t sign 1.000000
d1t SoftZero 0.000000
d1t SoftLowerLim -20.000000
d1t SoftUpperLim 20.000000
d1t Fixed -1.000000
d1t InterruptMode 0.000000
d1t precision 0.010000
d1t AccessCode 2.000000
d1t poscount 20.000000
# Motor d1l
d1l sign 1.000000
d1l SoftZero 0.000000
d1l SoftLowerLim -20.000000
d1l SoftUpperLim 20.000000
d1l Fixed -1.000000
d1l InterruptMode 0.000000
d1l precision 0.010000
d1l AccessCode 2.000000
d1l poscount 20.000000
# Motor d1r
d1r sign 1.000000
d1r SoftZero 0.000000
d1r SoftLowerLim -20.000000
d1r SoftUpperLim 20.000000
d1r Fixed -1.000000
d1r InterruptMode 0.000000
d1r precision 0.010000
d1r AccessCode 2.000000
d1r poscount 20.000000
# Motor monochi
monochi sign 1.000000
monochi SoftZero 0.000000
monochi SoftLowerLim -30.000000
monochi SoftUpperLim 30.000000
monochi Fixed -1.000000
monochi InterruptMode 0.000000
monochi precision 0.010000
monochi AccessCode 2.000000
monochi poscount 20.000000
# Motor monophi
monophi sign 1.000000
monophi SoftZero 0.000000
monophi SoftLowerLim -30.000000
monophi SoftUpperLim 30.000000
monophi Fixed -1.000000
monophi InterruptMode 0.000000
monophi precision 0.010000
monophi AccessCode 2.000000
monophi poscount 20.000000
# Motor monoy
monoy sign 1.000000
monoy SoftZero 0.000000
monoy SoftLowerLim -30.000000
monoy SoftUpperLim 30.000000
monoy Fixed -1.000000
monoy InterruptMode 0.000000
monoy precision 0.010000
monoy AccessCode 2.000000
monoy poscount 20.000000
# Motor monox
monox sign 1.000000
monox SoftZero 0.000000
monox SoftLowerLim -30.000000
monox SoftUpperLim 30.000000
monox Fixed -1.000000
monox InterruptMode 0.000000
monox precision 0.010000
monox AccessCode 2.000000
monox poscount 20.000000
# Motor tasse
tasse sign 1.000000
tasse SoftZero 0.000000
tasse SoftLowerLim -130.000000
tasse SoftUpperLim 130.000000
tasse Fixed -1.000000
tasse InterruptMode 0.000000
tasse precision 0.010000
tasse AccessCode 2.000000
tasse poscount 20.000000
# Motor sdm
sdm sign 1.000000
sdm SoftZero 0.000000
sdm SoftLowerLim -5.000000
sdm SoftUpperLim 50.000000
sdm Fixed -1.000000
sdm InterruptMode 0.000000
sdm precision 0.010000
sdm AccessCode 2.000000
sdm poscount 20.000000
# Motor sgu
sgu sign 1.000000
sgu SoftZero 0.000000
sgu SoftLowerLim -20.000000
sgu SoftUpperLim 20.000000
sgu Fixed -1.000000
sgu InterruptMode 0.000000
sgu precision 0.010000
sgu AccessCode 2.000000
sgu poscount 20.000000
# Motor sgl
sgl sign 1.000000
sgl SoftZero 0.000000
sgl SoftLowerLim -20.000000
sgl SoftUpperLim 20.000000
sgl Fixed -1.000000
sgl InterruptMode 0.000000
sgl precision 0.010000
sgl AccessCode 2.000000
sgl poscount 20.000000
# Motor mgu
mgu sign 1.000000
mgu SoftZero 0.000000
mgu SoftLowerLim -50.000000
mgu SoftUpperLim 50.000000
mgu Fixed -1.000000
mgu InterruptMode 0.000000
mgu precision 0.010000
mgu AccessCode 2.000000
mgu poscount 20.000000
# Motor stu
stu sign 1.000000
stu SoftZero 0.000000
stu SoftLowerLim -30.000000
stu SoftUpperLim 30.000000
stu Fixed -1.000000
stu InterruptMode 0.000000
stu precision 0.010000
stu AccessCode 2.000000
stu poscount 20.000000
# Motor stl
stl sign 1.000000
stl SoftZero 0.000000
stl SoftLowerLim -30.000000
stl SoftUpperLim 30.000000
stl Fixed -1.000000
stl InterruptMode 0.000000
stl precision 0.010000
stl AccessCode 2.000000
stl poscount 20.000000
# Motor mtu
mtu sign 1.000000
mtu SoftZero 0.000000
mtu SoftLowerLim -30.000000
mtu SoftUpperLim 30.000000
mtu Fixed -1.000000
mtu InterruptMode 0.000000
mtu precision 0.010000
mtu AccessCode 2.000000
mtu poscount 20.000000
# Motor mtl
mtl sign 1.000000
mtl SoftZero 0.000000
mtl SoftLowerLim -30.000000
mtl SoftUpperLim 30.000000
mtl Fixed -1.000000
mtl InterruptMode 0.000000
mtl precision 0.010000
mtl AccessCode 2.000000
mtl poscount 20.000000
# Motor a6
a6 sign 1.000000
a6 SoftZero 0.000000
a6 SoftLowerLim -30.000000
a6 SoftUpperLim 30.000000
a6 Fixed -1.000000
a6 InterruptMode 0.000000
a6 precision 0.010000
a6 AccessCode 2.000000
a6 poscount 20.000000
# Motor a5
a5 sign 1.000000
a5 SoftZero 0.000000
a5 SoftLowerLim -30.000000
a5 SoftUpperLim 30.000000
a5 Fixed -1.000000
a5 InterruptMode 0.000000
a5 precision 0.010000
a5 AccessCode 2.000000
a5 poscount 20.000000
# Motor a4
a4 sign 1.000000
a4 SoftZero 0.000000
a4 SoftLowerLim -130.000000
a4 SoftUpperLim 130.000000
a4 Fixed -1.000000
a4 InterruptMode 0.000000
a4 precision 0.010000
a4 AccessCode 2.000000
a4 poscount 20.000000
# Motor a3
a3 sign 1.000000
a3 SoftZero 0.000000
a3 SoftLowerLim -360.000000
a3 SoftUpperLim 360.000000
a3 Fixed -1.000000
a3 InterruptMode 0.000000
a3 precision 0.010000
a3 AccessCode 2.000000
a3 poscount 20.000000
# Motor a2
a2 sign 1.000000
a2 SoftZero 0.000000
a2 SoftLowerLim -73.000000
a2 SoftUpperLim 137.000000
a2 Fixed -1.000000
a2 InterruptMode 0.000000
a2 precision 0.010000
a2 AccessCode 2.000000
a2 poscount 20.000000
# Motor a1
a1 sign 1.000000
a1 SoftZero 0.000000
a1 SoftLowerLim 15.000000
a1 SoftUpperLim 120.000000
a1 Fixed -1.000000
a1 InterruptMode 0.000000
a1 precision 0.010000
a1 AccessCode 2.000000
a1 poscount 20.000000
batchroot /data/koenneck/src/sics
batchroot setAccess 2
user Daniel_the_Clementine
user setAccess 2
sample DanielOxid
sample setAccess 2
title TopsiTupsiTapsi
title setAccess 2
starttime UNKNOWN
starttime setAccess 2