mirror of
https://github.com/slsdetectorgroup/slsDetectorPackage.git
synced 2025-06-23 18:17:59 +02:00
manual
This commit is contained in:
@ -92,6 +92,23 @@ Other important settings that are configured in the {\tt{setup.det}} file are:
|
||||
One should notice that, by default, by choosing the option {\tt{dr 32}}, then the software automatically sets the detector to {\tt{clkdivider 2}}. By choosing the option {\tt{dr 16}}, the software automatically sets the detector to {\tt{clkdivider 1}}. One needs to choose {\tt{clkdivider 0}} after setting the {\tt{dr 16}} option to have the fastest frame rate.
|
||||
We would recommend expert users (beamline people) to write their parameters file for the users.
|
||||
|
||||
|
||||
\section{API versioning}
|
||||
The eigerDetectorServer running on the boards has a versioning API scheme that will make it crash if used with a wrong firmware.
|
||||
You can also check your versioning by hand with the code:
|
||||
\begin{verbatim}
|
||||
sls_detector_get softwareversion
|
||||
\end{verbatim}
|
||||
gets the server (slsDetectorSoftware) version (answer is something like: {\tt{softwareversion 111920160722}}.
|
||||
\begin{verbatim}
|
||||
sls_detector_get thisversion
|
||||
\end{verbatim}
|
||||
returns the client version. teh answer can be {\tt{thisversion 111220160718}}.
|
||||
\begin{verbatim}
|
||||
/sls_detector_get detectorversion
|
||||
\end{verbatim}
|
||||
returns the firmware version . The answer can be {\tt{detectorversion 11}}.
|
||||
|
||||
\section{Setting up the threshold}
|
||||
\begin{verbatim}
|
||||
sls_detector_put 0-trimen N xxxx yyyy zzzz
|
||||
@ -233,65 +250,6 @@ Hardware-wise, the ENABLE OUT signal outputs when the chips are really acquiring
|
||||
|
||||
We are planning to change some functionality, i.e. unify the {\tt{trigger}} and {\tt{burst}} trigger modes and make both {\tt{frames}} and {\tt{cycles}} configurable at the same time.
|
||||
|
||||
\section{Offline processing and monitoring}
|
||||
\subsection{Offline image reconstruction}
|
||||
The offline image reconstruction is in {\tt{slsDetectorsPackage/slsImageReconstruction}}.
|
||||
|
||||
The detector writes a raw file per receiver. An offline image reconstruction executable has been written to collate the possible files together and produce cbf files. The executable uses the CBFlib-0.9.5 library (downloaded from the web as it download some architecture dependent packages at installation).\\
|
||||
\underline{At cSAXS, the CBFlib-0.9.5 has been compiled -such that the required packages are}\\\underline{ downloaded in /sls/X12SA/data/x12saop/EigerPackage/CBFlib-0.9.5.}\\
|
||||
|
||||
To use it for a single module:
|
||||
\begin{verbatim}
|
||||
cbfMaker [filename with dir]
|
||||
\end{verbatim}
|
||||
eg.
|
||||
{\tt{cbfMaker /scratch/run\_63\_d1\_f000000000000\_3.raw}}\\
|
||||
|
||||
To use it for a 1.5 multi modules:
|
||||
\begin{verbatim}
|
||||
cbfMaker [filename] [pixels x] [pixels y] ([singlemodulelongside_x] [start det])
|
||||
\end{verbatim}
|
||||
eg.
|
||||
{\tt cbfMaker /scratch/run\_63\_d0\_f000000000000\_3.raw 3072 512 1 0}.\\
|
||||
The {\tt{[singlemodulelongside\_x]}} and {\tt{[start det]}} param are optional. Defaults are ``1'', the detector long side is on the x coordinate and start to reconstruct from module 0.
|
||||
The executables:
|
||||
\begin{verbatim}
|
||||
bcfMaker1.5M [file_name_with_dir]
|
||||
bcfMaker9M [file_name_with_dir]
|
||||
\end{verbatim}
|
||||
contain the hardcoded geometry for the 1.5M (3 modules horizontal on the long side) and for the 9M at cSAXS: 6(short side)$\times$3 (long side) modules.\\
|
||||
Missing packets in a frame and border pixels ($\times 2$ and $\times 4$ are given with value $-1$ at the present time.
|
||||
|
||||
It is important to know, that the pixels at the edge between 2 chips count more as double size. We can virtually introduced 1 virtual pixel per double larger pixel, so to have an even number of counts everywhere. Virtual pixels (not filled ) between module gaps are also inserted.
|
||||
|
||||
\begin{verbatim}
|
||||
GapPixelsBetweenChips_x = 2;
|
||||
GapPixelsBetweenChips_y = 2;
|
||||
GapPixelsBetweenModules_x = 8;
|
||||
GapPixelsBetweenModules_y = 36;
|
||||
\end{verbatim}
|
||||
|
||||
\subsection{Read temperatures from boards}
|
||||
|
||||
With an updated kernel on the linux boards (ask to the SLS detector group for specifications), it is possible to monitor the temperature on the Back End Boards:
|
||||
\begin{verbatim}
|
||||
temp_fpga #gets the temperature of the fpga
|
||||
temp_fpgaext #gets the temperature close to the fpga
|
||||
temp_10ge #gets the temperature close to the 10GE
|
||||
temp_dcdc #gets the temperature close to the dc dc converter
|
||||
temp_sodl #gets the temperature close to the left so-dimm memory
|
||||
temp_sodr #gets the temperature close to the right so-dimm memory
|
||||
temp_fpgafl #gets the temperature of the left front end board fpga
|
||||
temp_fpgafr #gets the temperature of the left front end board fpga
|
||||
|
||||
\end{verbatim}
|
||||
|
||||
You need to use the command specifying from which board you desire the temperature readings, for example:
|
||||
\begin{verbatim}
|
||||
./sls_detector_get 0:temp_fpga
|
||||
./sls_detector_get 1:temp_fpga
|
||||
\end{verbatim}
|
||||
|
||||
\section{Autosumming and rate corrections}
|
||||
|
||||
In the case of autosumming mode, i.e, {\tt{dr 32}}, the acquisition time ({\tt{exptime}} is broken in as many subframes as they fit into the acquisition time minus all the subframes readout times. By default the {\tt{subexptime}} is set to 2.621440~ms. This implies that 12 bit counter of \E will saturate when the rate is above or equal to 1.57~MHz/pixel. The minimum value is of order of 10~ns (although as explained values smaller than 500~$\mu$s do not make sense). The maximum value is 5.2~s.
|
||||
@ -312,7 +270,7 @@ To deactivate:
|
||||
\begin{verbatim}
|
||||
sls_detector_put 0-ratecorr 0
|
||||
\end{verbatim}
|
||||
Default values for tau can be loaded from the calibration files. In this case, one needs to make sure the appropriate tau value is written in the calibration file, then need to load the appropriate {\tt{settings}} or {\tt{calibrations}} at least once before. Now to activate the rate corrections with the value written in the calibrations, once would do:
|
||||
Default values for tau can be loaded from the trimbit files. In this case, one needs to make sure the appropriate tau value is written in the trimbit files, then need to load the appropriate {\tt{settings}} and {\tt{vthreshold}} before. Now to activate the rate corrections with the value written in the trimbit file or interpolated from there, once would do:
|
||||
\begin{verbatim}
|
||||
sls_detector_put 0-ratecorr -1
|
||||
\end{verbatim}
|
||||
@ -392,6 +350,73 @@ Very important is to activate the flow control in 10Gb (in 1Gb it is on by defau
|
||||
\end{verbatim}
|
||||
Set the transmission delays as explained in the manual.
|
||||
|
||||
\section{Offline processing and monitoring}
|
||||
\subsection{Offline image reconstruction}
|
||||
The offline image reconstruction is in {\tt{slsDetectorsPackage/slsImageReconstruction}}.
|
||||
|
||||
The detector writes a raw file per receiver. An offline image reconstruction executable has been written to collate the possible files together and produce cbf files. The executable uses the CBFlib-0.9.5 library (downloaded from the web as it download some architecture dependent packages at installation).\\
|
||||
\underline{At cSAXS, the CBFlib-0.9.5 has been compiled -such that the required packages are}\\\underline{ downloaded in /sls/X12SA/data/x12saop/EigerPackage/CBFlib-0.9.5.}\\
|
||||
|
||||
To use it for a single module:
|
||||
\begin{verbatim}
|
||||
cbfMaker [filename with dir]
|
||||
\end{verbatim}
|
||||
eg.
|
||||
{\tt{cbfMaker /scratch/run\_63\_d1\_f000000000000\_3.raw}}\\
|
||||
|
||||
To use it for a 1.5 multi modules:
|
||||
\begin{verbatim}
|
||||
cbfMaker [filename] [pixels x] [pixels y] ([singlemodulelongside_x] [start det])
|
||||
\end{verbatim}
|
||||
eg.
|
||||
{\tt cbfMaker /scratch/run\_63\_d0\_f000000000000\_3.raw 3072 512 1 0}.\\
|
||||
The {\tt{[singlemodulelongside\_x]}} and {\tt{[start det]}} param are optional. Defaults are ``1'', the detector long side is on the x coordinate and start to reconstruct from module 0.
|
||||
The executables:
|
||||
\begin{verbatim}
|
||||
bcfMaker1.5M [file_name_with_dir]
|
||||
bcfMaker9M [file_name_with_dir]
|
||||
\end{verbatim}
|
||||
contain the hardcoded geometry for the 1.5M (3 modules horizontal on the long side) and for the 9M at cSAXS: 6(short side)$\times$3 (long side) modules.\\
|
||||
Missing packets in a frame and border pixels ($\times 2$ and $\times 4$ are given with value $-1$ at the present time.
|
||||
|
||||
It is important to know, that the pixels at the edge between 2 chips count more as double size. We can virtually introduced 1 virtual pixel per double larger pixel, so to have an even number of counts everywhere. Virtual pixels (not filled ) between module gaps are also inserted.
|
||||
|
||||
\begin{verbatim}
|
||||
GapPixelsBetweenChips_x = 2;
|
||||
GapPixelsBetweenChips_y = 2;
|
||||
GapPixelsBetweenModules_x = 8;
|
||||
GapPixelsBetweenModules_y = 36;
|
||||
\end{verbatim}
|
||||
|
||||
\subsection{Read temperatures/HV from boards}
|
||||
|
||||
With an updated kernel on the linux boards (ask to the SLS detector group for specifications), it is possible to monitor the temperature on the Back End Boards:
|
||||
\begin{verbatim}
|
||||
temp_fpga #gets the temperature of the fpga
|
||||
temp_fpgaext #gets the temperature close to the fpga
|
||||
temp_10ge #gets the temperature close to the 10GE
|
||||
temp_dcdc #gets the temperature close to the dc dc converter
|
||||
temp_sodl #gets the temperature close to the left so-dimm memory
|
||||
temp_sodr #gets the temperature close to the right so-dimm memory
|
||||
temp_fpgafl #gets the temperature of the left front end board fpga
|
||||
temp_fpgafr #gets the temperature of the right front end board fpga
|
||||
|
||||
\end{verbatim}
|
||||
|
||||
You need to use the command specifying from which board you desire the temperature readings, for example:
|
||||
\begin{verbatim}
|
||||
./sls_detector_get 0:temp_fpga
|
||||
./sls_detector_get 1:temp_fpga
|
||||
\end{verbatim}
|
||||
In 500k--2M pixel systems there is a hardware temperature safety switch, which will cut power to the BEBs when raching a too high temperature. For the 9M system, there is a temperature sensor read by the bchip100 PCU which will shutdown the detector when above a certain temperature.
|
||||
|
||||
The HV can also be set and read through the software:
|
||||
\begin{verbatim}
|
||||
./sls_detector_put vhighvoltage 150
|
||||
./sls_detector_get vhighvoltage
|
||||
\end{verbatim}
|
||||
Note that the get {\tt{vhighvoltage}} would return the measured HV from the master module only.
|
||||
|
||||
\appendix
|
||||
|
||||
\section{Kill the server, copy a new server, start the server}
|
||||
@ -437,7 +462,28 @@ If you need to program a new kernel (only needed when told to do so):
|
||||
sleep 300; #or till the screen over netcat has told you Successuful
|
||||
\end{verbatim}
|
||||
|
||||
do the same for the other boards. You can program in parallel many boards, but you cannot load two bitfiles on the same board till loading and copying one process has finished. So load all left febs together, then proceed to the left febs, then the bebs. Power off completely everything. Power it on.
|
||||
do the same for the other boards. You can program in parallel many boards, but you cannot load two bitfiles on the same board till loading and copying one process has finished. So load all left febs together, then proceed to the right febs, then the bebs. Power off completely everything. Power it on.
|
||||
|
||||
\section{Pulsing the detector}
|
||||
\begin{description}
|
||||
\item [pulsechip n] sets the chip into test mode with \textit{resmat} = 0 and \textit{externalenable} =1. Pulses chip by togglying the enable n number of times. The acquire is then done with no pixel matrix reset before the acquisition. If n$=-1$, the chip will be set into normal mode. This is necessary to restore normal chip operations after the test.
|
||||
\item[pulse n x y] Pulses pixel at coordinates (x,y) n number of times.
|
||||
\item[pulsenmove n x y] Pulses pixel n number of times and moves relatively by x value (x axis) and y value (y axis)
|
||||
\end{description}
|
||||
|
||||
Analog pulsing {\tt{N}} counts in the whole detector:
|
||||
\begin{verbatim}
|
||||
for i in $(seq 0 7) ; do
|
||||
px=$((-255+i))
|
||||
sls_detector_put pulse 0 $px 0
|
||||
for j in $(seq 0 255) ; do
|
||||
sls_detector_put pulsenmove N 0 1
|
||||
done;
|
||||
done;
|
||||
sls_detector_p resmat 0
|
||||
sls_detector_acquire
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
\section{Running the (9M at cSAXS. For now)}
|
||||
\begin{itemize}
|
||||
|
Reference in New Issue
Block a user