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

- made fixes to hkl

Browse Source 
- Introduced a help system
- introduced a module for handling automatic updates of files during
  long measurements
- Added a circular buffer and handling facilities to varlog
- Upgraded documentation


SKIPPED:
	psi/faverage.h
	psi/nxamor.tex
	psi/pimotor.h
	psi/pimotor.tex
This commit is contained in:
cvs
2003-12-10 13:50:44 +00:00
parent 7a5f0193ab
commit bc02cb79e7
80 changed files with 2680 additions and 664 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
doc/programmer/amor2t.tex
View File

@@ -10,7 +10,7 @@ This object implements this complex movement as a virtual motor.
The following formulas are used for the necessary calculations:
\begin{eqnarray}
delta height & = & h_{s} - R \sin \alpha \\
delta height & = & h_{s} - \sin \alpha \\
delta x & = & |x_{c} - x_{s}| - R \cos \alpha \\
omega & = & -2 MOM + 2 SOM \\
\end{eqnarray}
@@ -18,7 +18,7 @@ with
\begin{eqnarray}
h_{s} & = & \tan(2MOM)|x_{c} - x_{s}| \\
R & = & \sqrt{hs^{2} - |x_{c} - x_{s}|^{2}} \\
\alpha & = & 180 -90 - \beta - 2SOM \\
\alpha & = & ATT - 2SOM \\
\beta & = & 180 - 90 - 2MOM \\
MOM & = & polarizer \omega \\
SOM & = & sample \omega \\
@@ -141,6 +141,34 @@ $\langle$amorinterface {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@@\\
\mbox{}\verb@ Mark Koennecke, September 1999@\\
\mbox{}\verb@----------------------------------------------------------------------------*/@\\
\mbox{}\verb@@\\
\mbox{}\verb@/* distance detector sample */@\\
\mbox{}\verb@#define PARDS 0@\\
\mbox{}\verb@/* constant height of sample: height = PARDH + MOTSOZ + MOTSTZ */@\\
\mbox{}\verb@#define PARDH 1@\\
\mbox{}\verb@/* distance diaphragm 4 - sample */@\\
\mbox{}\verb@#define PARDD4 2@\\
\mbox{}\verb@/* distance to diaphragm 5 */@\\
\mbox{}\verb@#define PARDD5 3@\\
\mbox{}\verb@/* interrupt to issue when a motor fails on this */@\\
\mbox{}\verb@#define PARINT 4@\\
\mbox{}\verb@/* base height of counter station */@\\
\mbox{}\verb@#define PARDDH 5@\\
\mbox{}\verb@/* height of D4 */@\\
\mbox{}\verb@#define PARD4H 6@\\
\mbox{}\verb@/* height of D5 */@\\
\mbox{}\verb@#define PARD5H 7@\\
\mbox{}\verb@/* base height of analyzer */@\\
\mbox{}\verb@#define PARANA 8@\\
\mbox{}\verb@/* distance of analyzer from sample */@\\
\mbox{}\verb@#define PARADIS 9@\\
\mbox{}\verb@/* flag analyzer calculation on/off */@\\
\mbox{}\verb@#define ANAFLAG 10@\\
\mbox{}\verb@/* constant for second detector */@\\
\mbox{}\verb@#define PARDDD 11@\\
\mbox{}\verb@/* constant part of AOM */@\\
\mbox{}\verb@#define PARAOM 12@\\
\mbox{}\verb@@\\
\mbox{}\verb@@$\langle$putput {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@@\\
\mbox{}\verb@@$\langle$amoredata {\footnotesize ?}$\rangle$\verb@@\\

2
doc/programmer/choco.tex
View File

@@ -105,7 +105,7 @@ the error can be ignored or was fully resolved.
\item[pParList] is text string containing a comma separated list of
all parameters understood by this driver.
\item[pPrivate] Is a pointer to a driver specific specific data
structure. This data structure will not be messed with by upper level code.
structure. This data structure shall not be messed with by upper level code.
\end{description}
\subsubsection{The Controller Object}

28
doc/programmer/devexec.tex
View File

@@ -212,6 +212,29 @@ take care of invoking the apropriate commands on all registered counting
devices.
\subsubsection{Locking the Device Executor}
In some instances user code may wish to lock the device executor. An
example is a long running data saving operation. In order to do this
two functions are provided:
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap4}
$\langle$devlock {\footnotesize ?}$\rangle\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
\mbox{}\verb@@\\
\mbox{}\verb@ void LockDeviceExecutor(pExeList self);@\\
\mbox{}\verb@ void UnlockDeviceExecutor(pExeList self);@\\
\mbox{}\verb@@\\
\mbox{}\verb@@$\diamond$
\end{list}
\vspace{-1ex}
\footnotesize\addtolength{\baselineskip}{-1ex}
\begin{list}{}{\setlength{\itemsep}{-\parsep}\setlength{\itemindent}{-\leftmargin}}
\item Macro referenced in scrap ?.
\end{list}
\end{minipage}\\[4ex]
\end{flushleft}
\subsubsection{The Rest}
The rest of the interface includes initialisation and deletion routines
and some access routines. With the devexec being such an important system
@@ -219,7 +242,7 @@ component a function {\bf GetExecutor} is provided which retrieves a pointer
to the global SICS device executor.
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap4}
\begin{minipage}{\linewidth} \label{scrap5}
\verb@"devexec.h"@ {\footnotesize ? }$\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
@@ -308,7 +331,8 @@ to the global SICS device executor.
\mbox{}\verb@ connection with non blocking operation such as motors started@\\
\mbox{}\verb@ with run.@\\
\mbox{}\verb@ */@\\
\mbox{}\verb@ @\\
\mbox{}\verb@/*--------------------------- Locking ---------------------------------*/@\\
\mbox{}\verb@ @$\langle$devlock {\footnotesize ?}$\rangle$\verb@ @\\
\mbox{}\verb@/* -------------------------- Executor management -------------------------*/@\\
\mbox{}\verb@ @\\
\mbox{}\verb@ pExeList GetExecutor(void);@\\

22
doc/programmer/evcontroller.tex
View File

@@ -36,10 +36,16 @@ $\langle$evdata {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ pObjectDescriptor pDes;@\\
\mbox{}\verb@ pIDrivable pDrivInt;@\\
\mbox{}\verb@ pEVInterface pEnvir;@\\
\mbox{}\verb@ pICallBack pCall;@\\
\mbox{}\verb@ int callCount;@\\
\mbox{}\verb@ pEVDriver pDriv;@\\
\mbox{}\verb@ EVMode eMode;@\\
\mbox{}\verb@ float fTarget;@\\
\mbox{}\verb@ time_t start;@\\
\mbox{}\verb@ time_t lastt;@\\
\mbox{}\verb@ char *pName;@\\
\mbox{}\verb@ char *driverName;@\\
\mbox{}\verb@ char *errorScript;@\\
\mbox{}\verb@ ObPar *pParam;@\\
\mbox{}\verb@ int iLog;@\\
\mbox{}\verb@ pVarLog pLog;@\\
@@ -63,11 +69,17 @@ the second field a pointer to an Drivable interface. Each environment
controller needs to implement that in order to allow SICS drive the device
to a new value. The third field is a pointer to an environment interface.
This is needed in order to enable monitoring of the device when it has
reached its target value. The fourth field is a pointer to the driver for
reached its target value. Then there is a pointer to a callback
interface. The fifth field is a pointer to the driver for
the actual hardware. Next is the mode the device is in. Of course there
must be floating point value which defines the current target value for the
device. pName is a pointer to a string representing the name of the
controller. Then there is a
device. start and lastt are used to control the settling time.
pName is a pointer to a string representing the name of the
controller. driverName is the name of the driver used by this
device. errorScript is the name of a script command to run when the
controller goes out of tolerance.
Then there is a
parameter array. iLog is a boolean which says if data should be logged
for this controller or not. pLog is the a pointer to a Varlog structure
holding the logging information. Then there is a switch, iWarned, which is
@@ -91,6 +103,8 @@ $\langle$evdriv {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ typedef struct __EVDriver {@\\
\mbox{}\verb@ int (*SetValue)(pEVDriver self, float fNew);@\\
\mbox{}\verb@ int (*GetValue)(pEVDriver self, float *fPos);@\\
\mbox{}\verb@ int (*GetValues)(pEVDriver self, float *fTarget,@\\
\mbox{}\verb@ float *fPos, float *fDelta);@\\
\mbox{}\verb@ int (*Send)(pEVDriver self, char *pCommand,@\\
\mbox{}\verb@ char *pReplyBuffer, int iReplBufLen); @\\
\mbox{}\verb@ int (*GetError)(pEVDriver self, int *iCode,@\\
@@ -287,6 +301,8 @@ See the documentation for commands understood.
\mbox{}\verb@#define UPLIMIT 4@\\
\mbox{}\verb@#define LOWLIMIT 5@\\
\mbox{}\verb@#define SAFEVALUE 6@\\
\mbox{}\verb@#define MAXWAIT 7@\\
\mbox{}\verb@#define SETTLE 8@\\
\mbox{}\verb@@\\
\mbox{}\verb@@$\langle$evdata {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@@$\diamond$

46
doc/programmer/histogram.tex
View File

@@ -17,7 +17,9 @@ $\langle$Modes {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ eHNormal,@\\
\mbox{}\verb@ eHTOF,@\\
\mbox{}\verb@ eHStrobo,@\\
\mbox{}\verb@ eHRPT@\\
\mbox{}\verb@ eHRPT,@\\
\mbox{}\verb@ ePSD,@\\
\mbox{}\verb@ eSANSTOF@\\
\mbox{}\verb@ } HistMode;@\\
\mbox{}\verb@@$\diamond$
\end{list}
@@ -29,6 +31,7 @@ $\langle$Modes {\footnotesize ?}$\rangle\equiv$
\end{list}
\end{minipage}\\[4ex]
\end{flushleft}
These modes are specific to the SINQ histogram memory.
A histogram memory can be operated in transparent mode. It has not yet been
defined what this means but it is sort of storing raw data from the detector
without any summing or processing. Normal mode is better defined, this is
@@ -99,6 +102,11 @@ command. Then on initialisation first the logical histogram memory
evaluates the general options and then the driver in its Config
function evaluates the driver specific options.
The histogram memory supports several dimensions, a time binning
option and optional buffering of histogram memory data read from the
actual HM. All this data management stuff is handled in a separate
class, HMdata. See the documentation for HMdata for more details.
\subsubsection{The Histogram memory driver}
Adhering to the Sics paradigm of dividing any device into a logical device
@@ -113,16 +121,7 @@ $\langle$HistType {\footnotesize ?}$\rangle\equiv$
\begin{list}{}{} \item
\mbox{}\verb@@\\
\mbox{}\verb@ typedef struct __HistDriver {@\\
\mbox{}\verb@ /* configuration data */@\\
\mbox{}\verb@ HistMode eHistMode;@\\
\mbox{}\verb@ OverFlowMode eFlow;@\\
\mbox{}\verb@ int iRank;@\\
\mbox{}\verb@ int iDims[MAXDIM];@\\
\mbox{}\verb@ int nDim;@\\
\mbox{}\verb@ int iLength;@\\
\mbox{}\verb@ int iBinWidth;@\\
\mbox{}\verb@ float fTime[MAXCHAN];@\\
\mbox{}\verb@ int iTimeChan;@\\
\mbox{}\verb@ pHMdata data;@\\
\mbox{}\verb@ /* counting operations data */@\\
\mbox{}\verb@ CounterMode eCount;@\\
\mbox{}\verb@ float fCountPreset;@\\
@@ -183,15 +182,6 @@ $\langle$HistType {\footnotesize ?}$\rangle\equiv$
\end{minipage}\\[4ex]
\end{flushleft}
Quite a lot, but a histogram memory is quite a complex piece of equipment.
The configuration information is in the elements EhistMode, eOverFlowMode,
iRank, iDims and iBinWidth fields. iDim and nDim desribe the logical
dimensions of the histogram memory. These may be different from the
dimensions used for data transfer. For instance the SANS detector is
handled internally as 1600+ numbers where it really is a filed o
128*128.
Additionally there is an array of
floating point values which denote the time binning for time-o-flight
operation or the stroboscopic binning axis in stroboscopic mode.
The fields fPreset and CounterMode hold the counting parameter data.
@@ -324,11 +314,6 @@ $\langle$HistST {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ pICountable pCountInt;@\\
\mbox{}\verb@ pICallBack pCall;@\\
\mbox{}\verb@ pStringDict pOption;@\\
\mbox{}\verb@ HistInt *iLocalData;@\\
\mbox{}\verb@ int iLocalLength;@\\
\mbox{}\verb@ int iLocalUpdate;@\\
\mbox{}\verb@ time_t tLocal;@\\
\mbox{}\verb@ int iUpdateIntervall;@\\
\mbox{}\verb@ } HistMem;@\\
\mbox{}\verb@@$\diamond$
\end{list}
@@ -451,6 +436,7 @@ $\langle$Protos {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ float GetHistCountTime(pHistMem self,SConnection *pCon);@\\
\mbox{}\verb@ int HistDoCount(pHistMem self, SConnection *pCon);@\\
\mbox{}\verb@ int HistBlockCount(pHistMem self, SConnection *pCon);@\\
\mbox{}\verb@ void HistDirty(pHistMem self); @\\
\mbox{}\verb@@\\
\mbox{}\verb@@$\diamond$
\end{list}
@@ -488,6 +474,9 @@ $\langle$Protos {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ int GetHistogram(pHistMem self, SConnection *pCon,@\\
\mbox{}\verb@ int i,int iStart, int iEnd, HistInt *lData, int iDataLen);@\\
\mbox{}\verb@ HistInt *GetHistogramPointer(pHistMem self,SConnection *pCon);@\\
\mbox{}\verb@ int GetHistogramDirect(pHistMem self, SConnection *pCon,@\\
\mbox{}\verb@ int i, int iStart, int iEnd, @\\
\mbox{}\verb@ HistInt *lData, int iDataLen);@\\
\mbox{}\verb@ int PresetHistogram(pHistMem self, SConnection *pCon, HistInt lVal);@\\
\mbox{}\verb@@$\diamond$
\end{list}
@@ -514,6 +503,11 @@ initialises the HM from the lData provided. GetHistogram reads an histogram
into lData but maximum iDataLen items. PresetHistogram presets the HM to the
value lVal. Can be used to clear the HM.
GetHistogram and GetHistogramPointer try to buffer the data when
possible and configured. The configuration happens through the
definition of an update intervall. GetHistogramDirect never buffers
but goes for the histogram memory directly.
The histogram memory object buffers the histograms for a adjustable
period of time. GetHistogramPointer retrieves a pointer to the local
histogram buffer. It also makes sure, that the histogram has been
@@ -620,7 +614,7 @@ following.
\mbox{}\verb@----------------------------------------------------------------------------*/@\\
\mbox{}\verb@#ifndef SICSHISTDRIV@\\
\mbox{}\verb@#define SICSHISTDRIV@\\
\mbox{}\verb@#define MAXCHAN 4096@\\
\mbox{}\verb@#include "hmdata.h"@\\
\mbox{}\verb@@\\
\mbox{}\verb@@$\langle$HistType {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@@$\langle$HistDrivProt {\footnotesize ?}$\rangle$\verb@@\\

3
doc/programmer/hkl.tex
View File

@@ -24,6 +24,7 @@ $\langle$hkldat {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ double fLastHKL[5];@\\
\mbox{}\verb@ int iNOR;@\\
\mbox{}\verb@ int iQuad;@\\
\mbox{}\verb@ int iHM;@\\
\mbox{}\verb@ pMotor pTheta;@\\
\mbox{}\verb@ pMotor pOmega;@\\
\mbox{}\verb@ pMotor pChi;@\\
@@ -51,6 +52,8 @@ The fields are more or less self explaining:
or is updated automatically from a wavelength variable.
\item[fLastHKL] the HKL of the last reflection calculated.
\item[iNor] a flag for normal beam calculation mode.
\item[iHM] a flag for histogram memory mode. In this mode two theta
limits are checked alos for detector 2 and 3.
\item[pTheta] The two theta motor. All motor are needed for boundary
checking.
\item[pOmega] The omega axis motor.

16
doc/programmer/interface.tex
View File

@@ -60,6 +60,7 @@ $\langle$obdes {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ /*---------------------------------------------------------------------------*/@\\
\mbox{}\verb@ pObjectDescriptor CreateDescriptor(char *name);@\\
\mbox{}\verb@ void DeleteDescriptor(pObjectDescriptor self);@\\
\mbox{}\verb@ pObjectDescriptor FindDescriptor(void *pData);@\\
\mbox{}\verb@ @\\
\mbox{}\verb@/*============================================================================@\\
\mbox{}\verb@ Objects which do not carry data need a dummy descriptor. Otherwise@\\
@@ -207,6 +208,8 @@ $\langle$count {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ typedef struct {@\\
\mbox{}\verb@ int ID;@\\
\mbox{}\verb@ int (*Halt)(void *self);@\\
\mbox{}\verb@ void (*SetCountParameters)(void *self, float fPreset,@\\
\mbox{}\verb@ CounterMode eMode);\@\\
\mbox{}\verb@ int (*StartCount)(void *self, SConnection *pCon);@\\
\mbox{}\verb@ int (*CheckCountStatus)(void *self, SConnection *pCon);@\\
\mbox{}\verb@ int (*Pause)(void *self, SConnection *pCon);@\\
@@ -313,6 +316,11 @@ $\langle$cifunc {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ void *pUserData, KillFuncIT pKill);@\\
\mbox{}\verb@ int RemoveCallback(pICallBack pInterface, long iID);@\\
\mbox{}\verb@ int RemoveCallback2(pICallBack pInterface, void *pUserData);@\\
\mbox{}\verb@@\\
\mbox{}\verb@ int CallbackScript(SConnection *pCon, SicsInterp *pSics, void *pData,@\\
\mbox{}\verb@ int argc, char *argv[]); @\\
\mbox{}\verb@@\\
\mbox{}\verb@ pICallBack GetCallbackInterface(void *pData); @\\
\mbox{}\verb@@$\diamond$
\end{list}
\vspace{-1ex}
@@ -360,8 +368,16 @@ RegisterCallBack.
search key for deletion is the pointer to user data. All callbacks related
to this user data in the interface specified will be removed.
{\bf CallbackScript} allows to connect callbacks to scripts. Please
note, that those scripts will have a dummy connection to clients only
and will not be able to write to clients. All output occurring in
these scripts will be directed to stdout though, in order to support
debugging.
All these functions are implemented in the file callback.c.
\subsubsection{The Environment Interface}
This interface is used by the environment monitor in order to monitor
the status of a environment controller. The interface looks like this:

3
doc/programmer/nserver.tex
View File

@@ -18,6 +18,7 @@ $\langle$servdat {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ pEnvMon pMonitor;@\\
\mbox{}\verb@ mkChannel *pServerPort;@\\
\mbox{}\verb@ pNetRead pReader;@\\
\mbox{}\verb@ int simMode;@\\
\mbox{}\verb@ } SicsServer;@\\
\mbox{}\verb@@$\diamond$
\end{list}
@@ -40,6 +41,8 @@ This module monitors sample environment controllers.
the SICS server is listening for connections.
\item[pReader] points to a data structure which defines the network
communication object.
\item[simMode] a flag which is true when the SICS server is a simulation
server.
\end{description}

2
doc/programmer/nxamor.tex
View File

@@ -60,6 +60,8 @@ time-of-flight mode.
\mbox{}\verb@----------------------------------------------------------------------*/@\\
\mbox{}\verb@#ifndef NXAMOR@\\
\mbox{}\verb@#define NXAMOR@\\
\mbox{}\verb@#include <scan.h>@\\
\mbox{}\verb@#include <HistMem.h>@\\
\mbox{}\verb@@$\langle$namor {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@#endif@\\
\mbox{}\verb@@$\diamond$

28
doc/programmer/nxdict.tex
View File

@@ -194,7 +194,7 @@ NexUs API which holds the dictionary information within a NeXus file.
One additional data type is needed for this API:
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap1}
$\langle$tata {\footnotesize 4a}$\rangle\equiv$
$\langle$tata {\footnotesize ?}$\rangle\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
\mbox{}\verb@@\\
@@ -213,7 +213,7 @@ NXdict will be used as a handle for the dictionary currently in use.
\subsubsection{Dictionary Maintainance Function}
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap2}
$\langle$dicman {\footnotesize 4b}$\rangle\equiv$
$\langle$dicman {\footnotesize ?}$\rangle\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
\mbox{}\verb@@\\
@@ -264,7 +264,7 @@ $\langle$dicman {\footnotesize 4b}$\rangle\equiv$
\subsubsection{Data Handling functions}
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap3}
$\langle$dicdata {\footnotesize 5}$\rangle\equiv$
$\langle$dicdata {\footnotesize ?}$\rangle\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
\mbox{}\verb@@\\
@@ -347,7 +347,7 @@ The NXDICT data handling functions go in pairs. The version ending in
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap4}
$\langle$dicutil {\footnotesize 6}$\rangle\equiv$
$\langle$dicutil {\footnotesize ?}$\rangle\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
\mbox{}\verb@@\\
@@ -411,7 +411,7 @@ the current approach poses a serious performance problem.
Thus, the NXdict data structure looks like this:
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap5}
$\langle$dicdat {\footnotesize 7}$\rangle\equiv$
$\langle$dicdat {\footnotesize ?}$\rangle\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
\mbox{}\verb@@\\
@@ -1155,7 +1155,7 @@ $\langle$deftok {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ {"-type",DTYPE},@\\
\mbox{}\verb@ {"-rank",DRANK},@\\
\mbox{}\verb@ {"-attr",DATTR},@\\
\mbox{}\verb@ {NULL,0} };@\\
\mbox{}\verb@ {"",0} };@\\
\mbox{}\verb@@\\
\mbox{}\verb@/*-----------------------------------------------------------------------*/@\\
\mbox{}\verb@ static void NXDIDefToken(ParDat *sStat)@\\
@@ -1543,7 +1543,7 @@ $\langle$nxpasds {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ iRank = atoi(pParse->pToken);@\\
\mbox{}\verb@ break;@\\
\mbox{}\verb@ case DDIM:@\\
\mbox{}\verb@ iRet = NXDIParseDim(pParse, iDim);@\\
\mbox{}\verb@ iRet = NXDIParseDim (pParse, (int *) iDim);@\\
\mbox{}\verb@ if(iRet == NX_ERROR)@\\
\mbox{}\verb@ {@\\
\mbox{}\verb@ LLDdelete(iList);@\\
@@ -1599,7 +1599,7 @@ $\langle$nxpasds {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ /* we need to create it, if we may */@\\
\mbox{}\verb@ if(pParse->iMayCreate)@\\
\mbox{}\verb@ {@\\
\mbox{}\verb@ iRet = NXmakedata(hfil,pName,iType, iRank,iDim);@\\
\mbox{}\verb@ iRet = NXmakedata (hfil, pName, iType, iRank, (int *) iDim);@\\
\mbox{}\verb@ if(iRet != NX_OK)@\\
\mbox{}\verb@ { @\\
\mbox{}\verb@ /* a comment on this one has already been written! */@\\
@@ -1669,7 +1669,7 @@ $\langle$parsetype {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ {"DFNT_UINT16",DFNT_UINT16},@\\
\mbox{}\verb@ {"DFNT_INT32",DFNT_INT32},@\\
\mbox{}\verb@ {"DFNT_UINT32",DFNT_UINT32},@\\
\mbox{}\verb@ {NULL,-122} };@\\
\mbox{}\verb@ {"",0} };@\\
\mbox{}\verb@@\\
\mbox{}\verb@@\\
\mbox{}\verb@@\\
@@ -2737,15 +2737,15 @@ $\langle$free {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@#include "napi.h" /* make sure, napi is included */@\\
\mbox{}\verb@@\\
\mbox{}\verb@/*-------------------- NXDict data types & defines ----------------------*/@\\
\mbox{}\verb@@$\langle$tata {\footnotesize 4a}$\rangle$\verb@@\\
\mbox{}\verb@@$\langle$tata {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@#define NXquiet 0@\\
\mbox{}\verb@#define NXalot 1@\\
\mbox{}\verb@/*-------------------- Dictionary Maintainance ----------------------------*/@\\
\mbox{}\verb@@$\langle$dicman {\footnotesize 4b}$\rangle$\verb@@\\
\mbox{}\verb@@$\langle$dicman {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@/*----------------- Dictionary added data transfer -----------------------*/ @\\
\mbox{}\verb@@$\langle$dicdata {\footnotesize 5}$\rangle$\verb@@\\
\mbox{}\verb@@$\langle$dicdata {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@/*-------------------- Utility Functions --------------------------------*/@\\
\mbox{}\verb@@$\langle$dicutil {\footnotesize 6}$\rangle$\verb@@\\
\mbox{}\verb@@$\langle$dicutil {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@#endif@\\
\mbox{}\verb@@$\diamond$
\end{list}
@@ -2804,7 +2804,7 @@ $\langle$free {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ dictionaries.@\\
\mbox{}\verb@*/@\\
\mbox{}\verb@/*-------------------------------------------------------------------------*/@\\
\mbox{}\verb@@$\langle$dicdat {\footnotesize 7}$\rangle$\verb@@\\
\mbox{}\verb@@$\langle$dicdat {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@/*-------------------------------------------------------------------------*/@\\
\mbox{}\verb@ static char *NXDIReadFile(FILE *fd)@\\
\mbox{}\verb@ {@\\

1
doc/programmer/pimotor.tex
View File

@@ -50,6 +50,7 @@ $\langle$pimoti {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@----------------------------------------------------------------------------*/@\\
\mbox{}\verb@#ifndef PIMOTOR@\\
\mbox{}\verb@#define PIMOTOR@\\
\mbox{}\verb@#include <motor.h>@\\
\mbox{}\verb@@$\langle$pimoti {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@#endif@\\
\mbox{}\verb@@\\

44
doc/programmer/reference.tex
View File

@@ -87,6 +87,7 @@ There are two sections: Building the SICS applications and building the Java
The first step is to untar the sics.tar file. As a result a directory sics
with several subdirectories will be created. These subdirectories are:
\begin{description}
\item[psi]PSI specific commands and code.
\item[hardsup] contains David Madens and other hardware drivers.
\item[motor] contains the unix version of David Madens el734\_test program.
\item[doc/programmer]holds programming documentation for SICS.
@@ -95,7 +96,9 @@ The first step is to untar the sics.tar file. As a result a directory sics
\item[bin] Holds the final binary files.
\item[tcl] Some Tcl helper code.
\item[doc/manager]The SICS managers documentation.
\item[difrac] The DIFRAC four circle diffraction subsystem.
\item[difrac] The DIFRAC four circle diffraction subsystem. This is
not used anymore.
\item[matrix] A matrix manipulation package.
\end{description}
For most programs makefiles are provided.
Makefiles may need a little editing to correct the location of libraries.
@@ -134,6 +137,8 @@ Again the first step is the untaring of tha java.tar file. This creates a
\item[spread] Another layout manager package.
\item[topsi] The topsi and general scan status display.
\item[amor] The AMOR user interface program.
\item[tas] The Triple Axis user interface program.
\item[trics] The TRICS user interface program.
\end{description}
Furthermore there are some Java source file in the main directory together
with some htm files and makefiles. For each of the Java clients a makefile
@@ -149,11 +154,11 @@ Furthermore there are some Java source file in the main directory together
\item[Jar-File] make -f make.powder jar
\end{description}
\section{Kernel Objects and Modules}
This section describes the modules defining the SICS kernel.
\include{task}
\include{nserver}
\include{site}
\include{ini}
\include{passwd}
\include{network}
@@ -171,6 +176,9 @@ This section describes the modules defining the SICS kernel.
\include{interrupt}
\include{ofac}
\include{servlog}
\include{help}
\include{Busy}
\include{hmcontrol}
\subsection{The commandlog}
This is yet another logging facility of SICS. The idea is that all I/O
going to connections with user or manager level rights is logged.
@@ -187,6 +195,7 @@ writing to it. The rest is implemented as file statics in commandlog.c.
This section describes the SICS objects implementing commands and objects
common to all SICS instruments.
\include{scan}
\include{userscan}
\include{center}
\include{danu}
\include{drive}
@@ -202,6 +211,13 @@ common to all SICS instruments.
\include{token}
\include{udpquieck}
\include{xytable}
\include{lin2ang}
\include{lomax}
\include{nxscript}
\include{nxupdate}
\include{sicsdata}
\include{simsync}
\include{anticollider}
\section{SICS Hardware Objects}
This section deals with objects and modules representing instrument
@@ -228,24 +244,31 @@ right as utility functions. However, the preferred and supported way of
accessing SICS hardware objects is through the interface functions.
\include{velo}
\include{velodorn}
\include{evcontroller}
\include{itc4}
\include{bruker}
\include{tclev}
\include{evdrivers}
\include{motor}
\include{pimotor}
\include{counter}
\include{hmdata}
\include{histogram}
\include{sinqhmdriv}
\include{histsim}
\include{choco}
\include{switchedmotor}
\include{tcldriveable}
\include{rs232controller}
\include{gpib}
\section{PSI Specific Hardware}
\include{velodorn}
\include{itc4}
\include{bruker}
\include{pimotor}
\include{sinqhmdriv}
\include{serial}
\include{serialwait}
\include{sps}
\include{frame}
\include{ecb}
\section{Powder Diffraction Specific Objects}
\include{dmc}
@@ -275,6 +298,9 @@ The files nxsans.h and nxsans.c implement the NeXus writing functions for SANS.
\include{tricsnex}
\include{difrac}
\section{Triple Axis Specific Code}
\include{tas}
\section{Helper Objects}
This section describes helper objects which implement useful data
structures or utilities.

49
doc/programmer/scan.tex
View File

@@ -66,6 +66,7 @@ $\langle$scandata {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ SConnection *pCon;@\\
\mbox{}\verb@ char pRecover[1024];@\\
\mbox{}\verb@ char pHeaderFile[1024];@\\
\mbox{}\verb@ int (*PrepareScan)(pScanData self);@\\
\mbox{}\verb@ int (*WriteHeader)(pScanData self);@\\
\mbox{}\verb@ int (*WriteScanPoints)@\\
\mbox{}\verb@ (pScanData self, @\\
@@ -78,6 +79,7 @@ $\langle$scandata {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ (pScanData self,@\\
\mbox{}\verb@ int iP);@\\
\mbox{}\verb@ long lPos;@\\
\mbox{}\verb@ int posSoft;@\\
\mbox{}\verb@ void *pCounterData;@\\
\mbox{}\verb@ char pCounterName[512];@\\
\mbox{}\verb@ int iChannel;@\\
@@ -140,6 +142,9 @@ line is permitted.
finding data.
\item[pCon] The connection object to use for error reporting during scan
execution.
\item[PrepareScan] checks limits of scan variables and memorizes
important scan information. Sometimes this is not wanted, that is why
it is parametrized here.
\item[WriteHeader] is a pointer to a function which writes the header part
of the scan file. Replace this function if another data format is needed.
\item[WriteScanPoints] is a pointer to a function which will be called after
@@ -154,22 +159,24 @@ This function together with ScanDrive and the data writing functions allow for
\item[CollectScanData] reads all the scan data into the scan's data
structures after any scan point. Overload this if a different storage
scheme is required especiallay for polarising scans.
\item[posSoft] is a flag which is true if scan variable are stored with
soft position, i.e. with zeropoints applied.
\item[pCounterData] is a pointer to a counter structure. This defines the
counter to use and is initialized at creation of the scan data structure.
\item[pCountername] is the name of the counter used.
\item[iChannel] is the channel to use for counting. 0 is the main counter,
everything baove one of the monitors.
everything above one of the monitors.
\item[pCount, iCounts] is a dynamic array containing iCounts sets of
counting infomation. For each scan point this array holds the counts
measured. iCounts is also the current scan position.
\item[iWindow] the width of the window used for peak integration. See
integrate.w,c for more details.
\item[pCommand] It turned out that a way is needed to define user defined
speciality scans. This is implemented by setting the channel number to -10
and then have the scan command execute a Tcl script for each scan point.
This Tcl script has to return a Tcl list containing the values to enter for
counter and monitor for the scan point. pCommand now is the name of the
Tcl procedure to invoke.
speciality scans, especially for those magnetic polarized guys. The way
it is done is that scan has to be configured user. In this mode, ScanCount
will call a script which does everything necessary at the scan point,
including adding data to the data file. pCommand now holds the name of
the script to invoke.
\item[pSpecial] Usually NULL. A entry which allows customized scans to keep
some additional data in the scan data structure.
\end{description}
@@ -206,6 +213,7 @@ $\langle$scaninter {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ char *pName, int iLength);@\\
\mbox{}\verb@ int GetScanVarStep(pScanData self, int iWhich, @\\
\mbox{}\verb@ float *fStep);@\\
\mbox{}\verb@ int isScanVarSoft(pScanData self);@\\
\mbox{}\verb@ int GetScanMonitor(pScanData self, int iWhich, @\\
\mbox{}\verb@ long *lData, int iDataLen);@\\
\mbox{}\verb@ int GetScanNP(pScanData self);@\\
@@ -221,7 +229,23 @@ $\langle$scaninter {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ /*@\\
\mbox{}\verb@ resets the configurable scan functions to their default values.@\\
\mbox{}\verb@ */@\\
\mbox{}\verb@@\\
\mbox{}\verb@ int NonCheckPrepare(pScanData self);@\\
\mbox{}\verb@ /*@\\
\mbox{}\verb@ a function for the PrepareScan field in the scan data structure@\\
\mbox{}\verb@ which does not check the boundaries of the scan as the default@\\
\mbox{}\verb@ PrepareScan does.@\\
\mbox{}\verb@ */@\\
\mbox{}\verb@ int AppendScanLine(pScanData self, char *line);@\\
\mbox{}\verb@ /*@\\
\mbox{}\verb@ AppendScanLine appends a line to the scan data file. When finished@\\
\mbox{}\verb@ it updates the position pointer in the file to point behind the@\\
\mbox{}\verb@ added line. @\\
\mbox{}\verb@ */@\\
\mbox{}\verb@ int StoreScanCounts(pScanData self, char *data);@\\
\mbox{}\verb@ /*@\\
\mbox{}\verb@ parses the numbers in data and stores them as the count and@\\
\mbox{}\verb@ monitor data for the current scan point.@\\
\mbox{}\verb@ */ @\\
\mbox{}\verb@/*------------------------ Interpreter Interface --------------------------*/@\\
\mbox{}\verb@ int ScanFactory(SConnection *pCon, SicsInterp *pSics, void *pData,@\\
\mbox{}\verb@ int argc, char *argv[]);@\\
@@ -279,6 +303,17 @@ summed counts and the variance. See the section on integrate for more
details.
\item[ResetScanFunctions] reinstalls the default functions for scan
processing into the ScanData structure.
\item[NonCheckPrepare] Before a scan is started, various data
structures in the scan object are initialized. Thereby the scan
boundaries are checked against the motor limits. For some scans this
is not feasible. This version omits this check and must be entered as
the PrepareScan function field in the scan data structure by code
using the scan module.
\item[AppendScanLine] appends a line to the scan file. This is useful
for user configured scans, for instance in polarisation mode.
\item[StoreScanCounts] parses the data given in data and stores the
numbers as count values as the count data for the current scan point.
Another feature for supporting user configurable scans.
\item[SimScan] creates a simulated gaussian peak with the given
parameters. Used for debugging several things.
\item[ScanFactory] is the SICS interpreter object creation function

12
doc/programmer/sinqhmdriv.tex
View File

@@ -30,6 +30,10 @@ $\langle$SQType {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@ pSINQHM pMaster;@\\
\mbox{}\verb@ int iLastHMError;@\\
\mbox{}\verb@ int iLastCTError;@\\
\mbox{}\verb@ HistMode eHistMode;@\\
\mbox{}\verb@ int iBinWidth;@\\
\mbox{}\verb@ OverFlowMode eFlow;@\\
\mbox{}\verb@ int extraDetector;@\\
\mbox{}\verb@ } SinqHMDriv;@\\
\mbox{}\verb@@$\diamond$
\end{list}
@@ -59,7 +63,10 @@ The driver implements all the functions specified in the driver interface.
Please note that these contain functions for the deletion of driver private
data structures which will be automatically called form DeleteHistDriver.
Therefore the only function to define is CreateSINQDriver which sets things
up.
up. Another function is isSINQHMDriv which tests if the driver given as an
argument actually is a SINQHM driver. This is currently only used in
amorstat.c which has to circumvent normal SICS mechanisms for performance
reasons.
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap2}
@@ -68,6 +75,7 @@ $\langle$Protos {\footnotesize ?}$\rangle\equiv$
\begin{list}{}{} \item
\mbox{}\verb@@\\
\mbox{}\verb@ pHistDriver CreateSINQDriver(pStringDict pOption);@\\
\mbox{}\verb@ int isSINQHMDriv(pHistDriver test);@\\
\mbox{}\verb@@$\diamond$
\end{list}
\vspace{-1ex}
@@ -94,7 +102,7 @@ $\langle$Protos {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@----------------------------------------------------------------------------*/@\\
\mbox{}\verb@#ifndef SINQHMDRIVER@\\
\mbox{}\verb@#define SINQHMDRIVER@\\
\mbox{}\verb@@\\
\mbox{}\verb@#include "hardsup/sinqhm.h"@\\
\mbox{}\verb@@$\langle$SQType {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@/*-------------------------------------------------------------------------*/@\\
\mbox{}\verb@@$\langle$Protos {\footnotesize ?}$\rangle$\verb@@\\

262
doc/programmer/site.tex
View File

@@ -1,129 +1,143 @@
\chapter{Site Adaptions}\label{site}
Any new site adapting SICS will have different hardware and thus
require different drivers. Moreover additional commands may need to be
added in order to support special hardware, instrument specific
computations or status displays and local usage patterns. In order to
separate such site specific code from the SICS kernel, the site data
structure was conceived. Any new site is supposed to create a library
which provides site specific code and the site data structure which
allows SICS to locate the code. A site data structure can be retrieved
using:
\begin{verbatim}
pSite getSite(void);
\end{verbatim}
The site data structure is meant to be a singleton. It is a site's
programmers task to provide an implementation of getSite which returns
a nice site structure.
\subsubsection{Site Abstraction Layer}
With ANSTO using SICS as well it became necessary to separate the
general parts of SICS from the installation specific components. Each
installation will have a separate set of drivers and, to some
extent, instrument specific commands. Such code has to be in a
separate library. Access to this library is through an interface which
consists of a structure containing pointers to functions which allow
for the creation of site specific drivers and commands. Moreover, the
site specific library has to implement a function, getSite, which
returns the appropriate data structure for the site for which SICS is
being compiled. This data structure looks like this:
The site data structure is a structure which holds pointers to
functions. A user has to implement suitable functions along the
signatures given and assign them to this data structure.
\begin{verbatim}
typedef struct {
void (*AddSiteCommands)(SicsInterp *pSics);
void (*RemoveSiteCommands)(SicsInterp *pSics);
pMotor (*CreateMotor)(SConnection *pCon,
int argc, char *argv[]);
pCounterDriver (*CreateCounterDriver)(
SConnection *pCon,
int argc,
char *argv[]);
HistDriver *(*CreateHistogramMemoryDriver)(
char *name, pStringDict pOption);
pVelSelDriv (*CreateVelocitySelector)(char *name,
char *array, Tcl_Interp *pTcl);
pCodri (*CreateControllerDriver)(SConnection *pCon,
int argc,
char *argv[]);
pEVControl (*InstallEnvironmentController)(
SicsInterp *pSics,
SConnection *pCon,
int argc,
char *argv[]);
int (*ConfigureScan)(pScanData self,
char *option);
void (*KillSite)(void *pData);
}Site, *pSite;
\end{verbatim}
The members of this data structure:
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap1}
$\langle$sitedata {\footnotesize ?}$\rangle\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
\mbox{}\verb@@\\
\mbox{}\verb@ typedef struct {@\\
\mbox{}\verb@ void (*AddSiteCommands)(SicsInterp *pSics);@\\
\mbox{}\verb@ void (*RemoveSiteCommands)(SicsInterp *pSics);@\\
\mbox{}\verb@ pMotor (*CreateMotor)(SConnection *pCon,@\\
\mbox{}\verb@ int argc, char *argv[]);@\\
\mbox{}\verb@ pCounterDriver (*CreateCounterDriver)(@\\
\mbox{}\verb@ SConnection *pCon,@\\
\mbox{}\verb@ int argc, @\\
\mbox{}\verb@ char *argv[]);@\\
\mbox{}\verb@ HistDriver *(*CreateHistogramMemoryDriver)(@\\
\mbox{}\verb@ char *name, pStringDict pOption);@\\
\mbox{}\verb@ pVelSelDriv (*CreateVelocitySelector)(char *name, @\\
\mbox{}\verb@ char *array, Tcl_Interp *pTcl);@\\
\mbox{}\verb@ pCodri (*CreateControllerDriver)(SConnection *pCon,@\\
\mbox{}\verb@ int argc,@\\
\mbox{}\verb@ char *argv[]);@\\
\mbox{}\verb@ pEVControl (*InstallEnvironmentController)(@\\
\mbox{}\verb@ SicsInterp *pSics,@\\
\mbox{}\verb@ SConnection *pCon,@\\
\mbox{}\verb@ int argc,@\\
\mbox{}\verb@ char *argv[]);@\\
\mbox{}\verb@ int (*ConfigureScan)(pScanData self,@\\
\mbox{}\verb@ char *option);@\\
\mbox{}\verb@ void (*KillSite)(void *pData);@\\
\mbox{}\verb@}Site, *pSite;@\\
\mbox{}\verb@@$\diamond$
\end{list}
\vspace{-1ex}
\footnotesize\addtolength{\baselineskip}{-1ex}
\begin{list}{}{\setlength{\itemsep}{-\parsep}\setlength{\itemindent}{-\leftmargin}}
\item Macro referenced in scrap ?.
\end{list}
\end{minipage}\\[4ex]
\end{flushleft}
\begin{description}
\item[AddSiteCommand] adds site specific commands coded in C to the
SICS interpreter pSics.
\item[RemoveSiteCommands] removes object creation commands after SICS
has processed the instrument initialization file. See \ref{factory}
for details on the scheme.
\item[CreateMotor] creates a motor object. \verb+argv[0]+ contains the
motors name, \verb+argv[1]+ the identifier for the motor driver and
the rest of argv, argc holds further driver initialisation
parameters. Any errors in processing the arguments can be reported to
pCon. If CreateMotor can create a suitable motor object, a pointer to
it is returned, if not NULL must be returned.
\item[CreateCounterDriver] creates a driver for a counter. argc, argv
is the full array of arguments given to the MakeCounter factory
function. Of interest are: \verb+argv[1]+ the counter name,
\verb+argv[2]+, the driver identifier and the rest of the
initialization arguments. On success a pointer to
new driver is returned, on failure NULL.
\item[AddSiteCommands] adds site specific object creation and
instrument specific commands to the SICS interpreter, pSics.
\item[RemoveSiteCommands] will be called to remove surplus object
creation commands after the SICS interpreter has processed the
initialization files. Please note, that SICS does not support the
removal of objects at runtime in general. This is due to the fact that
any possible object may be used by or linked to others and and it
would be a bookeeping nightmare to keep track of all those relations.
\item[CreateMotor] creates a motor using the arguments in argc and
argv. It returns a pointer to the new motor structure on success or
NULL in case of a failure. This function has to return a complete
motor in order to allow for special configurations of the motor to
take place in its initialization.
\item[CreateCounterDriver] returns a driver for a new counter box
driver if the parameters are valid or NULL if not. Driver arguments
are in the argc, argv pair.
\item[CreateHistogramMemoryDriver] creates a driver for a histogram
memory. The driver is identified through name, the options database is
in pOptions. Histogram memory initialization follows the following
pattern:
\begin{itemize}
\item At first the raw driver is created. This code has to initializie
defaults in the options data base.
\item Then, with calls to {\em hmname configure opt val} the options
database is populated with the histogram memories configuration
options. The options database is pOptions a dictionary of name value
pairs.
\item In the last step, with {\bf hmname init} the options are parsed
and the driver is supposed to connect to the histogram memory. See
Configure in the histogram memory driver.
\end{itemize}
On success a pointer to
new driver is returned, on failure NULL.
\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[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 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
environment devices special interpreter wrapper functions are
provided. Any errors encountered while processing the arguments has to
be reported to pCon. On success a pointer to the environment
controller is returned, on failure NULL.
\item[ConfigureScan] configures the SICS general scan object self according
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 in scan.tex,
scan.h and scan.c for more details.
\end{description}
All the simulation drivers for the hardware are part of the SICS
kernel and need not be initialized from these functions. SICS also
handles sample environment devices built in Tcl or on the general
controller object.
The site data structure suffers a little from inconsistencies
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.
Good luck!
memory. The driver type is specified through name.
Driver options are in pOptions.
\item[CreateVelocitySelector] create a driver for a velocity selector.
The parameter name is the name of the driver, array is the name of a
Tcl array holding configuration parameters for the driver and pTcl is
the Tcl interpreter in which array lives.
\item[CreateControllerDriver] creates a driver for the general
controller module within SICS. argc and argv hold the parameters,
starting with the name of the driver to create.
\item[InstallEnvironmentController] installs a a sample
environment device such as a temperature controller or magnet
controller etc. into the interpreter pSics. pCon is a connection
object to which errors can be
reported, argc and argv are the controller parameters starting with
the driver name. This method does not get away with creating a driver
but must install the command into SICS because some environment
devices overload the standard Wrapper function with special ones. The
newly created object is still returned for further processing. In the
case of failure NULL is returned. Errors will have been printed to
pCon.
\item[ConfigureScan] allows for modules which configure the scan
object. option is the option to xxscan configure to process, the scan
object to configure is passed in in self. This returns 1 on success
and 0 on failures or options which are not recognized.
\item[KillSite] is a function to remove the site data structure when
SICS is done with it. pData must point to the site data structure.
KillSite's purpose is to free all memory associated with
the site data structure. This is mostly a cleanup thing, to keep the
fortify logs clear off inconsequential and confusing data.
\end{description}
\begin{flushleft} \small
\begin{minipage}{\linewidth} \label{scrap2}
\verb@"site.h"@ {\footnotesize ? }$\equiv$
\vspace{-1ex}
\begin{list}{}{} \item
\mbox{}\verb@@\\
\mbox{}\verb@/*-----------------------------------------------------------------------@\\
\mbox{}\verb@ S i t e A b s t r a c t i o n L a y e r@\\
\mbox{}\verb@@\\
\mbox{}\verb@With ANSTO using SICS as well it became necessary to separate the@\\
\mbox{}\verb@general parts of SICS from the installation specific components. Each@\\
\mbox{}\verb@installation will have a separate set of drivers and, to some@\\
\mbox{}\verb@extent, instrument specific commands. Such code has to be in a@\\
\mbox{}\verb@separate library. Access to this library is through an interface which@\\
\mbox{}\verb@consists of a structure containing pointers to functions which allow@\\
\mbox{}\verb@for the creation of site specific drivers and commands. Moreover, the@\\
\mbox{}\verb@site specific library has to implement a function, getSite, which@\\
\mbox{}\verb@returns the appropriate data structure for the site for which SICS is@\\
\mbox{}\verb@being compiled. @\\
\mbox{}\verb@------------------------------------------------------------------------*/@\\
\mbox{}\verb@#ifndef SICSSITE@\\
\mbox{}\verb@#define SICSSITE@\\
\mbox{}\verb@#include <sics.h>@\\
\mbox{}\verb@#include <motor.h>@\\
\mbox{}\verb@#include <countdriv.h>@\\
\mbox{}\verb@#include <HistDriv.i>@\\
\mbox{}\verb@#include <stringdict.h>@\\
\mbox{}\verb@#include <velo.h>@\\
\mbox{}\verb@#include <tcl.h>@\\
\mbox{}\verb@#include <codri.h>@\\
\mbox{}\verb@#include <evcontroller.h>@\\
\mbox{}\verb@#include <scan.h>@\\
\mbox{}\verb@@$\langle$sitedata {\footnotesize ?}$\rangle$\verb@@\\
\mbox{}\verb@/*-------------------------------------------------------------------*/@\\
\mbox{}\verb@pSite getSite(void);@\\
\mbox{}\verb@#endif@\\
\mbox{}\verb@@$\diamond$
\end{list}
\vspace{-2ex}
\end{minipage}\\[4ex]
\end{flushleft}

3
doc/programmer/velodorn.tex
View File

@@ -46,6 +46,7 @@ $\langle$dh {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@@\\
\mbox{}\verb@ int GetDornierStatus(void **pData, pDornierStatus pDornier);@\\
\mbox{}\verb@ int DornierSend(void **pData, char *pCommand, char *pReply, int iLen);@\\
\mbox{}\verb@ int DecodeNewDornierStatus(char *pText, pDornierStatus pDornier);@\\
\mbox{}\verb@@$\diamond$
\end{list}
\vspace{-1ex}
@@ -69,6 +70,8 @@ $\langle$dh {\footnotesize ?}$\rangle\equiv$
\mbox{}\verb@@\\
\mbox{}\verb@ Mark Koennecke, Juli 1997@\\
\mbox{}\verb@@\\
\mbox{}\verb@ updated to support new format fo status messages, Mark Koennecke, July 2003@\\
\mbox{}\verb@@\\
\mbox{}\verb@ copyright: see implementation file.@\\
\mbox{}\verb@------------------------------------------------------------------------------*/@\\
\mbox{}\verb@#ifndef VELODORN@\\