manual

manual/manual-client/Eiger_short.tex

@@ -6,6 +6,7 @@
 \usepackage{verbatim}
 \usepackage{xspace}
 \usepackage{hyperref}
+\usepackage{xcolor}
 \newcommand{\E}{EIGER\xspace}  
 \newcommand{\p}{sls\_detector\_put}
 \newcommand{\g}{sls\_detector\_get}
@@ -419,18 +420,9 @@ where the 'minimum time between frames' and the minimum period will be discussed
 \hline
 4 & 0 & \tiny {parallel} & 3.4 & 22  & 44 & 44.01 & 30k/50k\\
 \hline
-4 & 1 & \tiny {parallel} & 6 & 10.5 & 92 & 92.02 & 30k/100k\\
-\hline
-4 & 2 & \tiny {parallel} & 11.2 & 5.4 & 197& 197.01 & infinite\\
-\hline
 \hline
 8 & 0 & \tiny {parallel} & 3.4 & 11.1 & 89 & 89.01 & 15k/24k\\
 \hline
-8 & 1 & \tiny {parallel} & 6.1 & 5.7 & 181 & 181.01 & 15k/52k\\
-\hline
-8 & 2 & \tiny {parallel} & 11.2 &  2.9 &  342 & 342.01 & infinite\\
-\hline
-\hline
 16 & 0 & \tiny {parallel} & 3.4 & 6.1 & (126+38)* =164 & 164.02 & 8k/12k\\
 \hline
 16 & 0 & \tiny {nonparallel} &  127 & 5.6 & (126+52)*= 179 & 179.01& 8k/23k\\
@@ -439,14 +431,6 @@ where the 'minimum time between frames' and the minimum period will be discussed
 \hline
 16 & 1 & \tiny {nonparallel} & 255 & 3.3 &  303 & 303.01 & infinite\\
 \hline
-16 & 2 & \tiny {parallel} &  11.2 & 1.9 & 526 & 526.2 & infinite \\
-\hline
-16 & 2 & \tiny {nonparallel} & 505 & 1.8  & 555 & 555.01& infinite\\
-\hline
-%32 & 2 & parallel &  11 & 2&  & &\\
-%\hline
-%32 & 2 & nonparallel & 504 & $<2$&  & &\\
-%\hline
 \end{tabular}
 \caption{Readout settings. The {\tiny{min exptime}} possible is 5$-$10~$\mu$s. This is due to the time to pass the pixel enable signal in the whole chip. The time between frames ($\Delta$t) has been measured with the oscilloscope and the maximum frames rate (max FR) has been tested with an external gating from a pulse generator at known frequency. The minimum period is obtained as 1/$\textrm{max frame rate}$.}
 \label{tframes}
@@ -457,7 +441,6 @@ where the 'minimum time between frames' and the minimum period will be discussed
 \textbf{From software version 4.0.0, there is a very useful function {\tt{sls\_detector\_get measuredperiod}} which return the measured period AFTER the acquisition. This is important to check that the settings to obtain the targeted frame rate was correct.} 
 
 \textbf{If you run too fast, the detector could become noisier (see problem shooting), it is important to match the detector settings to your frame rate. This can be done having more parameters files and load the one suitable with your experiment.} We experienced that with low energy settings could not reach 6~kHz and no noise.
-
 In 16 bit mode, it could make sense, in case of noise and low threshold to either reduce the frame rate:
 \begin{equation} 
 \textrm{new period}  = \textrm{exptime} + \textrm{minimum time between frames} + (\textrm{10$-$20 }\mu \textrm{s})
@@ -467,7 +450,54 @@ to let the signal settle  or,  if the frame rate is important, leave the {\tt{pe
 \textrm{new exptime}  = \textrm{old exptime} - (\textrm{10$-$20 }\mu \textrm{s})
 \end{equation}
 
-In general, choose first the desired dead time: this will tell you if you want to run in parallel or non parallel mode, although most likely it is parallel mode. Then, choose the maximum frame rate you want to aim, not exceeding what you aim for not to increase the noise. In 4 and 8 bit modes it makes no sense to run nonparallel as the exposure time is too small compared to the readout time. 
+In general, choose the maximum frame rate you want to aim, not exceeding what you aim for not to increase the noise. In 4 and 8 bit modes it makes no sense to run nonparallel as the exposure time is too small compared to the readout time. 
+
+Here below are the final tables for settting the detcetor correctly:
+
+\begin{itemize}
+\item CONTINUOUS redout (imagesnot stored on board memories,  frames can be achieved. {\tt{flags parallel}}, {\tt{clkdivider 0}} are always set. In 32-bit no extra {\tt{subdeadtime}} is assumed. The difference between {\tt{exptime}} and {\tt{period}} has to be $\approx$5 $\mu$s:
+\begin{center}
+  \begin{tabular}{ |c| c| } 
+    \hline
+    max frame rate & settings\\
+    \hline
+    \textcolor{red}{170 Hz} &  \textcolor{red}{32-bit} \\
+    & Nframes=infinite\\
+    \hline
+      \textcolor{red}{2.56 kHz} &  \textcolor{red}{16-bit}\\
+     & Nframes=infinite\\
+     \hline
+      \textcolor{red}{5.1 kHz} &  \textcolor{red}{8-bit}\\
+     & Nframes=infinite\\
+     \hline
+      \textcolor{red}{10.2 kHz} &  \textcolor{red}{4-bit}\\
+     & Nframes=infinite\\
+     \hline
+  \end{tabular}
+\end{center}
+\item BUFFERED redout (images stored on board memories, such that the maximum frame rate can be achieved for a limited amount of frames. {\tt{flags parallel}}, {\tt{clkdivider 0}} are always set. In 32-bit no extra {\tt{subdeadtime}} is assumed. The difference between {\tt{exptime}} and {\tt{period}} has to be $\approx$5 $\mu$s:
+\begin{center}
+  \begin{tabular}{ |c| c| } 
+    \hline
+    max frame rate & settings\\
+    \hline
+     \textcolor{red}{170 Hz} &  \textcolor{red}{32-bit} \\
+    & Nframes=infinite\\
+    \hline
+     \textcolor{red}{6.1 kHz} &  \textcolor{red}{16-bit}\\
+    & Nframes=7600\\
+    \hline
+     \textcolor{red}{11.1 kHz} &  \textcolor{red}{8-bit}\\
+    & Nframes=15000\\
+    \hline
+     \textcolor{red}{22 kHz} &  \textcolor{red}{4-bit}\\
+    & Nframes=30000\\
+    \hline
+  \end{tabular}
+\end{center}
+\end{itemize}
+
+
 
 \subsubsection{4 and 8 bit mode}
 In {\tt{parallel}} mode, the minimum time between frames is due to the time required to latch the values of the counter with capacitors. These values are determined in firmware and they can be estimated as:
@@ -760,6 +790,19 @@ sysctl net.core.rmem_default=$((100*1024*1024))
 sysctl net.core.rmem_max=$((100*1024*1024))
 \end{verbatim}
 
+Other way to setup the same,  increase the socket receiving buffer size and the maximum length of the input queue:
+\begin{verbatim}
+echo $((100*1024*1024)) > /proc/sys/net/core/rmem_max
+echo 250000 > /proc/sys/net/core/netdev_max_backlog
+\end{verbatim}
+to make the settings permanent, edit /etc/sysctl.conf:
+ \begin{verbatim}
+# 100MiB
+net.core.rmem_max = 104857600
+net.core.netdev_max_backlog = 250000
+\end{verbatim}
+and run \textbf{sysctl -p}.
+
 Last, you can disable power saving in the CPU frequency (chose the appropriate command for your system):
 \begin{verbatim}
 cpupower frequency-info
@@ -776,6 +819,7 @@ It can help to increase the fifo size of the receiver to {\tt{rx\_fifodepth}} to
 ./sls_detector_put rx_fifodepth 1000
 \end{verbatim}
 One needs to keep into account that in 16 bit mode for 1 image we expect each slsReceiver  to allocate 0.5MB. So for 1000 images, we expect  500MB memory for each receiver. This can be monitored in Linux with "top" or "free -m". To receive the max number of images possible on the detector, a minimum of 8~GB of memories are required.
+For very high frame rate, very long measurements, we had to increase the {\tt{rx\_fifodepth}} to 10000 images but this only in 4, 8, 16 bit mode. In 32 bit mode it will assign 40~GB of memory, which is more than what normal PC would have. So make sure you do not require too much memory.  
 
 Last, it is very important that not too many files are created. There is high possibility to loose packets in the time to close and open files for the writer. IN 3.1.x, the default number of images written per file, in Eiger is 2000. This is defined by the line:
 \begin{verbatim}
@@ -881,7 +925,7 @@ Note that the number of images per file is hardcoded and needs to match whatever
 The default is 2000.
 
 \subsubsection{cbf}
-The cbf executable executable uses the CBFlib-0.9.5 library (downloaded from the web as it download some architecture dependent packages at installation).Edit the Makefile to correclty point at it.\\
+The cbf executable executable uses the CBFlib-0.9.5 library (downloaded from the web as it downloads architecture dependent packages at installation).Edit the Makefile to correclty point at it.\\
 \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:
@@ -936,7 +980,7 @@ make cbfMaker; make cbfMakerOMNY;
 \end{verbatim}
 
 \subsubsection{hdf5}
-In case of HDF5 output file, we rely on having the HDF5 1.10.1 library installed. Edit the Makefile to correclty point at it. Different compression methods are being tried so different external filters might be to be installed. This work is not finished yet.
+In case of HDF5 output file, we rely on having the HDF5 1.10.1 library installed and {\tt{HDF5-External-Filter-Plugins}} installed. With HDF5 1.10.3, no need of the external plugings package is needed, but a small modification to the file is needed. Edit the Makefile to correclty point at it. Different compression methods are being tried so different external filters might be to be installed. This work is not finished yet.
 
 To choose HDF5, with ZLIB implementation, open {\tt{slsImageReconstruction/src/main\_csaxs.cpp}} and make sure that 
 \begin{verbatim}
@@ -1313,10 +1357,14 @@ for i in $(seq 0 36); do sls_detector_put $i:vhighvoltage; done
 \subsection{'Cannot connect to socket'}
 This error is typically due to the detector server not running. For why, see section~\ref{servernot}.
 
+\subsection{Running at low frame rate, the communication to receiver stops}
+If running in 32-bit mode (or even in 16-bit mode), if more memory than what your machine can handle is asked for, the receiver process could be terminated by the kernel of your machine. It would loook like you had executed a clean control-c on the receiver executable. This has been the case, when setting up by mistake
+\tt{rx\_fifodepth} to 10000 images in 32 bit mode. In 32 bit mode it will assign 40~GB of memory, which is more than what normal PC would have. So make sure you do not require too much memory. The same is tru also for smaller values of {\tt{rx\_fifodepth}} if your  machine has not much memory.  
+
 \subsection{Detector server is not running}\label{servernot}
 The detector server could not be running: either the detector was powered off, or it powered off itself due to too high temperature or, in the case of the 9M, if the waterflow sensor detected no flux and powered it off (the chiller stops occasionally as cSAXS).
 
-If the powering and the temperature are OK, instead, it can be that the firmware version is incompatible to the server version and/or the client software version. So check the consistency of firmware/software/server versions.
+If the powering and the temperature are OK, instead, it can be that the firmware version is incompatible to the server version and/or the client software version. In software packages 3.x.y, the eigerDetectorServer was killed automatically. So check the consistency of firmware/software/server versions if using this version of the software. From 4.x.y onwards, the server, if associated to a wrong firmware, does not kill itself.   
 
 \subsection{'Acquire has already started' error message}
 If you see the client returning the following error message:\\