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

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

22
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}
@ -264,12 +264,12 @@ function has to be overloaded to return this interface on demand.
A default object descriptor can be created with:
\begin{verbatim}
pObjectDescriptor CreateDescriptor(type);
pObjectDescriptor CreateDescriptor(type);
\end{verbatim}
with type being the object type identifier. A descriptor can be
deleted with:
\begin{verbatim}
DeleteDescriptor(pDes);
DeleteDescriptor(pDes);
\end{verbatim}
@ -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.

78
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}).
@ -85,13 +102,16 @@ values are supposed to be identical to the positions of the limit
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.
into fPos. This ought to be the position from the motor
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.