- Fixed a bug at the new counter driver

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

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.