- 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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user