detectors/slsDetectorPackage
25
0
Fork 0
mirror of https://github.com/slsdetectorgroup/slsDetectorPackage.git synced 2025-04-21 19:30:03 +02:00
Code Issues Actions Packages Releases Activity

Merge branch 'developer' into sharedmem

Browse Source
This commit is contained in:
maliakal_d 2018-06-28 08:51:25 +02:00
commit 72f47b2375
11 changed files with 376 additions and 126 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
manual/manual-client/Boards.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 432 KiB

BIN
manual/manual-client/Eiger_short.pdf Normal file
View File

Binary file not shown.

478
manual/manual-client/Eiger_short.tex
View File

@ -18,17 +18,28 @@
\tableofcontents
\section{Usage}
\subsection{Short description}
Figure ~\ref{boards} show the readout board basic components on an Eiger half module. An half module can read up to 4 readout chips.
\begin{figure}[t]
\begin{center}
\includegraphics[width=1\textwidth]{Boards}
\end{center}
\caption{Picture with most relevant components of the EIGER readout system. The readout system starts with the Front End Boards (FEB) which performs data descrambling (also converts the packets from 12 $\to$ 16 bits) and rate correction. The BackEndBoard (BEB) has 2x2GB DDR2 memories and can perform data buffering (storing images on board) and data summation (16 bit $\to$ 32 bits). The controls to the detector are passed through the 1Gb, while in most installations, the data are sent out through the 10GB ethernet connection.}
\label{boards}
\end{figure}
\subsection{Mandatory setup - Hardware}
An EIGER single module (500~kpixels) needs:
\begin{itemize}
\item A chilled (water+alcohol) at approximately 21~$^{\circ}$C, which needs to dissipate 85~W. For the 9M, a special cooling liquid is required: 2/3 deionized water and 1/3 ESA Type 48.
\item A chilled (water+alcohol) at 21~$^{\circ}$C for a single module (500k pixels), which needs to dissipate 85~W (every module, i.e. for two half boards). For the 9M, 1.5M, a special cooling liquid is required: 2/3 deionized water and 1/3 ESA Type 48. This is important as the high temperature generated by the boards accelerate the corrosion due to Cu/Al reaction and the blockage of the small channels where the liquid flows, in particular near the face of the detector and if it is a parallel flow and not a single loop. The 9M and 1.5M run at 19~$^{\circ}$C.
\item A power supply (12~V, 8~A). For the 9~M, a special cpu is give to remotely switch on and off the detector: see section~\ref{bchip100}.
\item 2$\times$1~Gb/s Ethernet connectors to control the detector and, optionally, receive data at low rate. A DHCP server that gives IPs to the 1~Gb/s connectors of the detector is needed. Note that flow control has to be enabled on the switch you are using.
\item 2$\times$10~Gb/s transceivers to optionally, receive data at high rate.
\item 2$\times$1~Gb/s Ethernet connectors to control the detector and, optionally, receive data at low rate. A DHCP server that gives IPs to the 1~Gb/s connectors of the detector is needed. Note that flow control has to be enabled on the switch you are using, if you plan to read the data out from there. If not, you need to implement delays in the sending out of the data.
\item 2$\times$10~Gb/s transceivers to optionally, receive data at high rate. The 10Gb/s transceiver need to match the wavelength (long/short range) of the fibers chosen by the beamline infrastructure.
\end{itemize}
The equipment scales linearly with the number of modules.
Figure~\ref{fig:1} shows the relationship between the \textbf{Client} (which sits on a beamline control PC), the \textbf{Receiver} (which can run in multiple instances on one or more PCs which receive data from the detector. The receiver(s) does not necessary have to be running on the same PC as the client.) It is important that the receiver is closely connected to the detector (they have to be on the same network). Note that if you implement the 1Gb/s readout only: client, receiver and detector have to be all three in the same network. If you implement the 10Gb/s readout, then client, the 1~GbE of the detector and the receiver have to stay on the 1GbE. But the receiver data receiving device and the 10GbE detector can be on their private network, minimizing the missing packets.
Figure~\ref{fig:1} shows the relationship between the \textbf{Client} (which sits on a beamline control PC), the \textbf{Receiver} (which can run in multiple instances on one or more PCs which receive data from the detector. The receiver(s) does not necessary have to be running on the same PC as the client.) The username under which the receiver runs is the owner of the data files, if using our implementation. It is important that the receiver is closely connected to the detector (they have to be on the same network). Note that if you implement the 1Gb/s readout only: client, receiver and detector have to be all three in the same network. If you implement the 10Gb/s readout, then client, the 1~GbE of the detector and the receiver have to stay on the 1GbE. But the receiver data receiving device and the 10GbE detector can be on their private network, minimizing the missing packets.
\begin{figure}[t]
\begin{center}
@ -41,7 +52,7 @@ Figure~\ref{fig:1} shows the relationship between the \textbf{Client} (which sit
The Client talks to control over 1~Gb Ethernet connection using TCP/IP to the detector and to the receiver. The detector sends data in UDP packets to the receiver. This data sending can be done over 1~Gb/s or 10~Gb/s.
\begin{itemize}
\item \textbf{Switch on the detector only after having started the chiller: the 500k single module and the 1.5M at cSAXS have a hardware temperature sensor, which will power off the boards if the temperature is too high. Note that the detector will be power on again as soon as the temperature has been lowered. The 9M will not boot up without the correct waterflow and temperature has it has an integrated flowmeter.}
\item \textbf{Switch on the detector only after having started the chiller: the 500k single module and the 1.5M at cSAXS/OMNY have a hardware temperature sensor, which will power off the boards if the temperature is too high. Note that the detector will be power on again as soon as the temperature has been lowered. The 9M will not boot up without the correct waterflow and temperature has it has an integrated flowmeter.}
\item \textbf{Switch on the detector only after having connected all the cables and network. EIGER is unable to get IP address after it has been switched on without a proper network set up. In that case switch off and on the detector again.}
\end{itemize}
@ -73,28 +84,22 @@ You can also Check temperatures and water flow in a browser (from the same subne
\subsection{Mandatory setup - Receiver}
The receiver is a process run on a PC closely connected to the detector. Open one receiver for every half module board (remember, a module has two receivers!!!) . Go to {\tt{slsDetectorsPackage/bin/}}, \textbf{slsReceiver} should be started on the machine expected to receive the data from the detector.
The receiver is a process run on a PC closely connected to the detector. Open one receiver for every half module board (remember, a module has two receivers!!!) . Go to {\tt{slsDetectorsPackage/build/bin/}}, \textbf{slsReceiver} should be started on the machine expected to receive the data from the detector.
\begin{itemize}
\item {\tt{./slsReceiver --rx\_tcpport xxxx}}
\item {\tt{./slsReceiver --rx\_tcpport yyyy}}
\end{itemize}
where xxxx, yyyy are the tcp port numbers. Use 1955 and 1956 for example. Note that in older version of the software {\tt{--mode 1}} was used only for the ``bottom'' half module. Now, the receiver for the bottom is open without arguments anymore, but still in the configuration file one needs to write {\tt{n:flippeddatax 1}}, where {\tt{n}} indicated the half module number, 1 if it is a module.
where xxxx, yyyy are the tcp port numbers. Use 1955 and 1956 for example. The receiver for the bottom is open without arguments but still in the configuration file one needs to write {\tt{n:flippeddatax 1}}, where {\tt{2n+1}} indicated the half module number, 1 if it is a module.
\\ Open as many receiver as half module boards. A single module has two half module boards.
From the software version 3.0.1, one can decide weather start a zmq callback from the receiver to the client (for example to visualize data in the slsDetectorGui or another gui). If the zmq steam is not required (cased of the command line for example, one can switch off the streaming with {\tt{./sls\_detector\_put rx\_datastream 0}}, enable it with {\tt{./sls\_detector\_put rx\_datastream 1}}. In the case of inizialising the stream to use the slsDetectorGui, nothing needs to be taken care of by the user. If instead you want to stream the streaming on different channels, the zmq port of the client can be set stealing from the slsDetectorGui stream having {\tt{./sls\_detector\_put zmqport 300y}}. Note taht if this is done globally (not for every half module n independently, then the client automatically takes into account that for every half module, there are 2 zmq stream. The receiver stream {\tt{./sls\_detector\_put rx\_zmqport 300y}} has to match such that the GUI can work.
From the software version 3.0.1, one can decide weather start a zmq callback from the receiver to the client (for example to visualize data in the slsDetectorGui or another gui). If the zmq steam is not required (cased of the command line for example, one can switch off the streaming with {\tt{./sls\_detector\_put rx\_datastream 0}}, enable it with {\tt{./sls\_detector\_put rx\_datastream 1}}. In the case of inizialising the stream to use the slsDetectorGui, nothing needs to be taken care of by the user. If instead you want to stream the streaming on different channels, the zmq port of the client can be set stealing from the slsDetectorGui stream having {\tt{./sls\_detector\_put zmqport 300y}}. Note that if this is done globally (not for every half module n independently, then the client automatically takes into account that for every half module, there are 2 zmq stream. The receiver stream {\tt{./sls\_detector\_put rx\_zmqport 300y}} has to match such that the GUI can work.
If one desires to set the zmqport manually, he offset has to be taken into account: {\tt{./sls\_detector\_put 0:rx\_zmqport 300y}}, {\tt{./sls\_detector\_put 1:rx\_zmqport 300y+2}} and so on..
There is an example code that can be compiled in {\tt{manual/manual-api/mainReceiver.cpp}} and gives the executable {\tt{./detReceiver}}, use it with two or more receivers to open all receivers in one single terminal: {\tt{./detReceiver startTCPPort numReceivers withCallback}}, where startTCPPort assumes the other ports are consecutively increased.
\subsection{Mandatory setup - Client}
\underline{In the case of cSAXS, the detector software is installed on:}\\
\underline{/sls/X12SA/data/x12saop/EigerPackage/slsDetectorsPackage}
The command line interface consists in these main functions:
\begin{description}
\item[sls\_detector\_acquire] to acquire data from the detector
@ -166,15 +171,15 @@ Other important settings that are configured in the {\tt{setup.det}} file are:
\begin{itemize}
\item {\tt{tengiga 0/1}}, which sets whether the detector is enabled to send data through the 1~or the 10~Gb Ethernet.
\item {\tt{flags parallel/nonparallel}}, which sets whether the detector is set in parallel acquisition and readout or in sequential mode. This changes the readout time of the chip and affects the frame rate capability (faster is {\tt{parallel}}, with higher noise but needed when the frame rate is $>2$~kHz.
\item {\tt{dr 32/16}} sets the detector in autosumming mode (32 bit counter or not autosumming, 12 bit out of the chip). This is strictly connected to what is required for the readout clock of chip. See next point.
\item {\tt{dr 32/16/8/4}} sets the detector in autosumming mode (32 bit counter or not autosumming, 12 bit out of the chip). This is strictly connected to what is required for the readout clock of chip. See next point.
\item {\tt{clkdivider 0/1/2}}. Changes the readout clock: 200, 100, 50~MHz (also referred to as full, half, quarter speed). Note that autosumming mode ({\tt{dr 32}} only works at {clkdivider 2}=quarter speed). By selecting Refer to readout timing specifications in~section\ref{timing} for how to set the detector.
\item {\tt{flags continuous/storeinram}}. Allows to take frame continuously or storing them on memory. Normally {\tt{continuous}} should be used. Enabling the {\tt{stroreinram}} mode allows you to obtain the maximum frame rate, but at the expenses to have to receive the data all at the end of the acquisition. Refer to readout timing specifications in section~\ref{timing} for how to set the detector.
\item {\tt{flags continuous/storeinram}}. Allows to take frame continuously or storing them on memory. Users should use the {\tt{continuous}} flags. Enabling the {\tt{stroreinram}} flag makes the data to be sent out all at the end of the acquisition. Refer to readout timing specifications in section~\ref{timing} for how to set the detector. Examples will be given in section~\ref{}.
\end{itemize}
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}
\section{API versioning} \label{api}
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}
@ -194,12 +199,18 @@ Killing and starting the server on the boards allows you to check the firmware v
\section{Setting up the threshold}
\begin{verbatim}
sls_detector_put 0-trimen N xxxx yyyy zzzz
sls_detector_put 0-settings standard #[veryhighgain/highgain/lowgain/verylowgain] also possible
sls_detector_put 0-threshold energy_in_eV
sls_detector_put 0-settings standard
sls_detector_put 0-threshold energy_in_eV standard
\end{verbatim}
The first line requires to specify how many ({\tt{N}}) and at which energies in eV {\{tt{xxxx}}, {\tt{yyyy}}, {\tt{zzzz}} and so on) trimmed files were generated (to allow for an interpolation). This line should normally be included into the {\tt{mydetector.config}} file and should be set for you by one of the detector group.
NORMALLY, in this new calibration scheme, only {\tt{settings standard}} will be provided to you, unless specific cases to be discussed.
The threshold at 6000 eV , for example would be set as:{\tt{sls\_detector\_put 0-threshold 6000}}.
The threshold at 6000 eV , for example would be set as:{\tt{sls\_detector\_put 0-threshold 6000 standard}}.
For \E, at the moment normally only {\tt{standard}} settings are possible.
{\tt{lowgain}}, {\tt{verylowgain}}, {\tt{veryhighgain}} and {\tt{highgain}} are theoretically possible, but we never calibrate like this. They could be implemented later if needed.
Notice that setting the threshold actually loads the trimbit files (and interpolate them between the closest calibration energies) so it is time consuming.
The threshold is expressed in (eV) as the proper threshold setting, i.e. normally is set to 50\% of the beam energy.
We have added a special command, {\tt{thresholdnotb}}, which allows to scan the threshold energy without reloading the trimbits at every stage. One can either keep the trimbits at a specific value (es.32 if the range of energies to scan is large) or use the trimbits from a specific energy (like a central energy).
\begin{verbatim}
@ -216,12 +227,7 @@ sls_detector_put 0-period 0[time_is_s]
\end{verbatim}
In this acquisition 10 consecutive 1~s frames will be acquired. Note that {\tt{period}} defines the sum of the acquisition time and the desired dead time before the next frame. If {\tt{period}} is set to 0, then the next frame will start as soon as the detector is ready to take another acquisition. \\
For \E, at the moment 5 settings are possible: {\tt{standard}}, {\tt{lowgain}}, {\tt{verylowgain}}, {\tt{veryhighgain}} and {\tt{highgain}}. According to the setting chosen, one can reach different requirements (low noise or high rate). Refer to the settings requirements for your detector.\\
Notice that the option {\tt{settings standard/highgain/lowgain/veryhighgain/verylowgain}} actually loads the trimbit files so it is time consuming. Only setting the {\tt{threshold}} does not load trimbit files.
The threshold is expressed in (eV) as the proper threshold setting, i.e. normally is set to 50\% of the beam energy.
\underline{At cSAXS, the {\tt{settingsdir}} and {\tt{caldir}} are in}\\\underline{/sls/X12SA/data/x12saop/EigerPackage/calibrations/}\\
%\underline{At cSAXS, the {\tt{settingsdir}} and {\tt{caldir}} are in}\\\underline{/sls/X12SA/data/x12saop/EigerPackage/calibrations/}\\
You need to setup where the files will be written to
\begin{verbatim}
@ -247,23 +253,28 @@ sls_detector_get receiver
\end{verbatim}
There is a more complex way of performing an acquisition, that is useful for debugging and in case one wants a non blocking behavior:
\begin{itemize}
You can then reset to zero the number of frames caught, then start the receiver and the detector:
\begin{enumerate}
\item {\tt{sls\_detector\_put 0-resetframescaught 0}}
\item {\tt{sls\_detector\_put 0-receiver start}}
\item {\tt{sls\_detector\_put 0-status start}}
\end{itemize}
\end{enumerate}
You can poll the detector status using:
\begin{verbatim}
sls_detector_get 0-status
\end{verbatim}
When the detector is {\tt{idle}}, then you need to stop the receiver doing:
\begin{itemize}
When the detector is {\tt{idle}}, then the acquisition is done but the receiver could still be receiving data. If you want, you can check if the receiver is finished receiving as many frames as you were expecting (this is optional but required for many many frames acquisition or when using some delays to send data at very high frame rate.
\begin{enumerate}
\setcounter{enumi}{3}
\item {\tt{sls\_detector\_get framescaught}}
\end{enumerate}
Then you can stop the receiver as well now:
\begin{enumerate}
\setcounter{enumi}{4}
\item {\tt{sls\_detector\_put 0-receiver stop}}
\end{itemize}
You can then reset to zero the number of frames caught, if you desire:
\begin{itemize}
\item {\tt{sls\_detector\_put 0-resetframescaught 0}}
\end{itemize}
\end{enumerate}
The detector will not accept other commands while acquiring. If an acquisition wishes to be properly aborted, then:
\begin{itemize}
@ -275,7 +286,7 @@ this same command can be used after a non proper abortion of the acquisition to
IMPORTANT: to have faster readout and smaller dead time, one can configure {\tt{clkdivider}}, i.e. the speed at which the data are read, i.e. 200/100/50~MHz for {\tt{clkdivider 0/1/2}} and the dead time between frames through {\tt{flags parallel}}, i.e. acquire and read at the same time or acquire and then read out.
The configuration of this timing variables allows to achieve different frame rates. NOTE THAT IN EIGER, WHATEVER YOU DO, THE FRAME RATE LIMITATIONS COME FROM THE NETWORK BOTTLENECK AS THE HARDWARE GOES FASTER THAN THE DATA OUT.
In the case of REAL CONTINUOUS readout, i.e. continuous acquire and readout from the boards (independent on how the chip is set), the continuous frame rates are listed in table~\ref{tcont}:
In the case of REAL CONTINUOUS readout, i.e. continuous acquire and readout from the boards (independent on how the chip is set), the continuous frame rates are listed in table~\ref{tcont}.
\begin{table}
\begin{tabular}{|c|c|c|c|}
\hline
@ -294,10 +305,9 @@ GbE & dynamic range & continuos maximum frame rate(Hz) & minimum period ($\mu$s)
10 & 4 & \textbf{10240} & 98\\
\hline
\end{tabular}
\caption{Frame rate limits for the CONTINUOS streaming out of images.}
\caption{Frame rate limits for the CONTINUOS streaming out of images, i.e. the data rate out is just below 1Gb/s or 10Gb/s.}
\label{tcont}\end{table}
Note that in the {\tt{continuous}} flag mode, some buffering is still done on the memories, so a higher frame rate than the proper real continuous one can be achieved. Still, this extra buffering is possible till the memories are not saturated.
The number of images that can be stored on memories are listed in table~\ref{timgs}:
Note that in the {\tt{continuous}} flag mode, some buffering is still done on the memories, so a higher frame rate than the proper real continuous one can be achieved. Still, this extra buffering is possible till the memories are not saturated. The number of images that can be stored on the DDR2 on board memories are listed in table~\ref{timgs}.
\begin{table}
\begin{tabular}{|c|c|}
\hline
@ -314,72 +324,184 @@ dynamic range & images\\
\label{timgs}
\end{table}
The maximum frame rate achievable with 10~GbE, {\tt{dr 16}}, {\tt{flags continuous}}, {\tt{flags parallel}},{\tt{clkdivider 0}}, \textbf{6.1~kHz}. This is currently limited by the connection between the Front End Board and the Backend board. We expect the 32 bit mode limit to be \textbf{2~kHz} ({\tt{clkdivider 2}}).
The maximum frame rate achievable with 10~GbE, {\tt{dr 16}}, {\tt{flags continuous}}, {\tt{flags parallel}},{\tt{clkdivider 0}}, \textbf{6.1~kHz}. This is currently limited by the connection between the Front End Board and the Backend board. We expect the 32 bit mode limit, internally, to be \textbf{2~kHz} ({\tt{clkdivider 2}}).
In dynamic range {\tt{dr 8}} the frame rate is \textbf{11~kHz} and for{\tt{dr 4}} is \textbf{22~kHz}. For 4 and 8 bit mode the frame rate are directly limited by the speed of the detector chip and not by the readout boards.
In table~\ref{tframes} is a list of all the readout times in the different configurations:
\subsection{Minimum time between frames and Maximum frame rate}
We need to leave enough time between an exposure and the following. This time is a combination of the time required by the chip, by the readout boards and eventually extra time to reduce some appearance of cross talk noise between the digital and analog parts of the chip.
\textbf{It is essential to set the {\tt{period}} of the detector, defined as the {\tt{exptime}} plus an extra time, that needs to be at least the chip/board readout time. If this is set wrong (it is $<$ {\tt{exptime}} plus chip/board readout time), then the detector takes the minimum time it can, but you are in a not controlled frame rate situation.}
The expected time difference between frames given by the pure chip readout time is in Table~\ref{tchipro}.
\begin{tiny}
\begin{table}
\begin{flushleft}
\begin{tabular}{|c|c|c|c|c|c|c|c|}
\begin{tabular}{|c|c|c|c|}
\hline
\tiny{dr} & \tiny{clkdivider} & \tiny{flags} & \tiny{readout t($\mu$s)} & \tiny{max frame rate (kHz)} & \tiny{max exptime ($\mu$s)} & \tiny{min period ($\mu$s)} & \tiny{max imgs (nominal/our network)}\\
\tiny{dr} & \tiny{clkdivider} & \tiny{expected chip readout t($\mu$s)} & \tiny{measured chip readout t($\mu$s)}\\
\hline
4 & 0 & parallel & 3.4 & 22 & 40 & 44 & 30k/50k\\
\hline
4 & 0 & nonparallel & 44 & 21 & 3 & 49 & 30k/50k\\
\hline
4 & 1 & parallel & 6 & 10.5 & 85 & 92 & 30k/100k\\
\hline
4 & 1 & nonparallel & 88.7 & 10.5 & 3 & 93 & 30k/100k\\
\hline
4 & 2 & parallel & 11.2 & 5.4 & 185 & 197 & infinite\\
\hline
4 & 2 & nonparallel & 176.5 & 5.4 & 3 & 180 & infinite\\
4 & 0 & 41 & 40\\
4 & 1 & 82 & 84\\
4 & 2 & 123 & 172\\
\hline
\hline
8 & 0 & parallel & 3.4 & 11.1 & 85 & 89 & 15k/24k\\
\hline
8 & 0 & nonparallel & 85.7 & 11.1 & 3 & 91 & 15k/24k\\
\hline
8 & 1 & parallel & 6.1 & 5.7 & 174 & 181 & 15k/52k\\
\hline
8 & 1 & nonparallel & 170.5 & 5.7 & 3 & 175 & 15k/52k\\
\hline
8 & 2 & parallel & 11.2 & 2.9 & 330 & 342 & infinite\\
\hline
8 & 2 & nonparallel & 340.3 & 2.9 & 3 & 344 & infinite\\
8 & 0 & 82 & 82\\
8 & 1 & 164 & 167\\
8 & 2 & 328 & 336\\
\hline
\hline
16 & 0 & parallel & 3.4 & 6 & 164 & 168 & 8k/12k\\
\hline
16 & 0 & nonparallel & 126 & 3.4& 164 & 295 & 8k/23k\\
\hline
16 & 1 & parallel & 6.1 & 2.9& 339 & 346 & 8k/28k\\
\hline
16 & 1 & nonparallel & 255 & 1.7& 339 & 592 & infinite\\
\hline
16 & 2 & parallel & 11 & 1.5& 66 & 78 & infinite \\
\hline
16 & 2 & nonparallel & 504 & 0.85 & 7 & 512 & infinite\\
\hline
\hline
32 & 2 & parallel & 11 & 2& & &\\
\hline
32 & 2 & nonparallel & 504 & $<2$& & &\\
12 & 0 & 123 &122\\
12 & 1 & 246 & 251\\
12 & 2 & 491 & 500\\
\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.}
\caption{Readout time required from the chip to readout the pixels. The numbers are obtained using equation~\ref{dtnonparallel}.}
\label{tchipro}
\end{flushleft}
\end{table}
\end{tiny}
The {\tt{period}} is s is defined as:
\begin{equation} \label{period}
\textrm{period} = \textrm{exptime} + \textrm{minimum time between frames}
\end{equation}
where the 'minimum time between frames' and the minimum period will be discussed in Table~\ref{tframes}.
\begin{tiny}
\begin{table}
\begin{flushleft}
\begin{tabular}{|c|c|c|c|c|c|c|}
\hline
\tiny{dr} & \tiny{clkdivider} & \tiny{flags} & \tiny{t between frames($\mu$s) } & \tiny{max frame rate (kHz)} & \tiny{min period ($\mu$s)} & \tiny{max imgs (nominal/our network)}\\
\hline
4 & 0 & parallel & 3.4 & 22 & 44 & 30k/50k\\
\hline
4 & 1 & parallel & 6 & 10.5 & 92 & 30k/100k\\
\hline
4 & 2 & parallel & 11.2 & 5.4 & 197 & infinite\\
\hline
\hline
8 & 0 & parallel & 3.4 & 11.1 & 89 & 15k/24k\\
\hline
8 & 1 & parallel & 6.1 & 5.7 & 181 & 15k/52k\\
\hline
8 & 2 & parallel & 11.2 & 2.9 & 342 & infinite\\
\hline
\hline
16 & 0 & parallel & 3.4 & 6.1 & (126+38)* =164 & 8k/12k\\
\hline
16 & 0 & nonparallel & 126 & 5.6 & (126+52)*= 179 & 8k/23k\\
\hline
16 & 1 & parallel & 6.1 & 3.9 & 257 & 8k/28k\\
\hline
16 & 1 & nonparallel & 255 & 3.3 & 303 & infinite\\
\hline
16 & 2 & parallel & 11 & 1.9 & 526 & infinite \\
\hline
16 & 2 & nonparallel & 504 & 1.8 & 555 & 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 has been measured with the oscilloscope and the maximum frames rate has been tested with an external gating from a pulse generator at known frequence. The minimum period is obtained as 1/$\textrm{max frame rate}$.}
\label{tframes}
\end{flushleft}
\end{table}
\end{tiny}
\textbf{As if you run too fast, the detector could become noisier, 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 {\tt{highgain}} settings could not be used at 6~kHz.
\textbf{We recommend to use the detector in 32 bit mode with {\tt{clkdivider 2}}, {\tt{flags parallel}}. We recommend to use the detector in 16 bit mode with {\tt{clkdivider 1}}, {\tt{flags parallel}}}. In general, choose first the desired dead time: this will tell you if you want to run in parallel or non parallel mode. Then, choose the maximum frame rate you want to aim, not exceeding what you aim for not to increase the noise.
\textbf{As if you run too fast, the detector could become noisier, 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})
\end{equation}
to let the signal settle or, if the frame rate is important, leave the {\tt{period}} at the same value but reduce the {\tt{exptime}}:
\begin{equation}
\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.
\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:
\begin{equation} \label{dtparallel}
\textrm{time between frames, parallel} = 4 \mu s \cdot (clkdivider+1)
\end{equation}
This time is independent on the {\tt{dr}}.
In {\tt{nonparallel}} mode, it is easily possible to calculate the required asic readout time.
Indeed a block of (8*256) pixels are readout, the bits pixel are the {\tt{dr}} and the speed of readout is 5ns/bit *({\tt{clkdivider}}+1) :
\begin{equation}\label{dtnonparallel}
\textrm{asics readout time} = 5ns/bit \cdot 2^{(clkdivider+1)} \cdot dr \cdot (8*256) + 4 \mu s \cdot (clkdivider+1)
\end{equation}
While we expose the next frame, we still need to readout the previous frame, so we need to guarantee that the period is large enough at least to readout the frame. So the maximum frame rate has to be $1/(\textrm{asic readout time})$. The minimum period has to be equal to the asic readout time.
\subsubsection{16 bit mode}
A similar situation happens in 16 bit mode, where this is more complicated because of three things:
\begin{enumerate}
\item The chip actual {\tt{dr}} is 12 bit
\item The chip is readout as 12-bit/pixel, but the FEB inflates the pixel values to 16-bits when it passes to the BEB. This means that effectively the FEB to BEB connection limits the data throughput in the same way as if the {\tt{dr}} of the chip would really be 16 bits.
\item While in 4 and 8 bit mode it makes no sense to run in {\tt{nonparallel}} mode as the exptime/dead time ratio would be not advantageous, in 16 bit mode, one can choose how to run more freely.
\end{enumerate}
If we are in parallel mode, the dead time between frames, is also here described by equation~\ref{dtparallel}. If we are in {\tt{nonparallel}} mode, the dead time between frames is defined by \ref{dtnonparallel} ONLY for {\tt{clkdivider}} 1 and 2. So the maximum frame rate has to be $1/(\textrm{chip readout time})$ in this case. Only for {\tt{clkdivider}} 0 we hit some limitation in the bandwidth of The FEB $\to$ BEB connection. In this case, the maximum frame rate is lowered compared to what expected.
\subsubsection{32 bit mode}
The autosumming mode of Eiger is the intended for long exposure times (frame rate of order of 100Hz, PILATUS like). A single acquisition is broken down into many smaller 12-bit acquisitions, each of a {\tt{subexptime}} of 2.621440~ms by default. Normally, this is a good default value to sustain an intensity of $10^6$ photons/pixel/s with no saturation. To change the value of {\tt{subexptime}} see section~\ref{advanced}.
The time between 12-bit subframes are listed in table~\ref{t32bitframe}.
\begin{tiny}
\begin{table}
\begin{flushleft}
\begin{tabular}{|c|c|c|c|c|c|}
\hline
\tiny{dr} & \tiny{clkdivider} & \tiny{flags} & \tiny{t difference between subframes($\mu$s)} & \tiny{max internal subframe rate (kHz)} & \tiny{maximum frame rate (Hz)}\\
\hline
32 & 2 & parallel & 12 & 2 & 170\\
\hline
32 & 2 & nonparallel & 504 & $<2$ & 160\\
\hline
\end{tabular}
\caption{Timing for the 32bit case. The maximum frame rate has been computed assuming 2 subframes of default {\tt{subexptime}} of 2.62144 ms.}
\label{t32bitframe}
\end{flushleft}
\end{table}
\end{tiny}
\textbf{The exposure time brokend up rounding up to the full next complete subframe that can be started.}
The number of subframes composing a single 32bit acquisition can be calculated as:
\begin{equation}
\textrm{\# subframes}= (int) (\frac{\textrm{exptime (s)}}{\textrm{subexptime (s) + difference between frames (s)}}+0.5)
%\label{esubframes}
\end{equation}
This also means that {\tt{exptime}}$<${\tt{subexptime}} will be rounded to{\tt{subexptime}}. If you want shorter acquisitions, either reduce the {\tt{subexptime}} or switch two 16-bit mode (you can always sum offline if needed).
The UDP header will contain, after you receive the data, the effective number of subframe per image (see section~\ref{UDP}) as "SubFrame Num or Exp Time", i.e. the number of subframes recorded (32 bit eiger).
The effective time the detector has recorded data can be computed as:
\begin{equation}
\textrm{effective exptime}=(\textrm{subexptime})\cdot (\textrm{\# subframes})
%\label{esubframes}
\end{equation}
In the future release, a configurable extra time difference between subframes will be introduced for the parallel mode, so that some noise appearing in detectors at low threshold can be removed. This will enlarge the time difference between frames form the default 12~$\mu$s to something configurable, expected to be 15-40~$\mu$s (for the 9M it is currently 200~$\mu$s due to a noisier module).
\section{External triggering options}\label{triggering}
The detector can be setup such to receive external triggers. Connect a LEMO signal to the TRIGGER IN connector in the Power Distribution Board (see Fig.). The logic 0 for the board is passed by low level 0$-$0.7~V, the logic 1 is passed to the board with a signal between 1.2$-$5~V. Eiger is 50~$\Omega$ terminated. By default the positive polarity is used (negative should not be passed to the board).
\begin{figure}[t]
\begin{center}
\includegraphics[width=.4\textwidth]{tiggerIN}
\end{center}
\caption{\textbf{Trigger INPUT} (looking at a single module from the back, top) is the \textbf{rightmost, down}.}
\label{triggerIN}
\end{figure}
\section{External triggering options}
The detector can be setup such to receive external triggers. Connect a LEMO signal to the TRIGGER IN connector in the Power Distribution Board. The logic 0 for the board is passed by low level 0$-$0.7~V, the logic 1 is passed to the board with a signal between 1.2$-$5~V. Eiger is 50~$\Omega$ terminated. By default the positive polarity is used (negative should not be passed to the board).
\begin{verbatim}
sls_detector_put 0-timing [auto/trigger/burst_trigger/gating]
sls_detector_put 0-frames x
@ -400,7 +522,7 @@ 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{Autosumming and rate corrections}
\section{Autosumming and rate corrections} \label{advanced}
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.
@ -417,7 +539,7 @@ In the EIGER on board server, this look-up table is generated assuming that the
n_d= n_i \cdot exp(-n_i \cdot \tau),
\label{rate}
\end{equation}
where $\tau$ represents an effective parameter for the dead time and the loss in efficiency. The look-up table is necessary as we are interested to obtain $c_i(c_d)$ and equation~\ref{rate} is not invertible. One needs to notice that the paralizable counter model to create a look-up tables applies only if photons arrive with a continuous pattern (like at the SLS). If photons are structured in fewer but intenser bunches, deviations may arise. This is the case for some operation modes at the ESRF. For those cases we are studying how to correct, probably from a simulated correction tables if an analytical curve cannot be found.
where $\tau$ represents an effective parameter for the dead time and the loss in efficiency. The look-up table is necessary as we are interested to obtain $c_i(c_d)$ and equation~\ref{rate} is not invertible. One needs to notice that the paralyzable counter model to create a look-up tables applies only if photons arrive with a continuous pattern (like at the SLS). If photons are structured in fewer but intenser bunches, deviations may arise. This is the case for some operation modes at the ESRF. For those cases we are studying how to correct, probably from a simulated correction tables if an analytical curve cannot be found.
\textbf{In the new calibration scheme, $\tau$ is given as a function of the energy. It is loaded from the trimbit files and interpolation between two trimbit files are performed.} 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.
Online rate corrections can be activated for {\tt{dr=32}}. They are particularly useful in the autosumming mode as every single subframe is corrected before summing it. To correct for rate, the subframe duration has to be known to the correction algorithm. Rate corrections for {\tt{dr=16}} will be activated as well in the next firmware release.
@ -454,20 +576,39 @@ Here is a list of limits that should be checked:
If \textbf{dr} is 32 and \textbf{clkdivider} is not 2, whatever the detector gets out is wrong (the boards cannot properly keep up)
\item If the variable \textbf{frames} is greater than what the memory can store (table~\ref{timgs}) and the frame rate exceed the continuos streaming (table~\ref{tcont}), limits on the maximum number of images need to be implemented if the period is lower than the one listed in table~\ref{tcont}. Check table~\ref{tframes} to see the different cases.
\item Running at a speed that does not support the frame rate you are asking: see table~\ref{tframes} to check if the frame rate (\textbf{period}) you are asking is compatible with the \textbf{clkdivider} you are asking.
\item Running at a redout time that does not support the frame rate you are asking. Check table~\ref{tframes} to check if the frame rate (\textbf{period}) you are asking is compatible with the \textbf{flags} you are asking.
\item Running at a readout time that does not support the frame rate you are asking. Check table~\ref{tframes} to check if the frame rate (\textbf{period}) you are asking is compatible with the \textbf{flags} you are asking.
\item The minimum allowed value for \textbf{exptime} should be 10~$\mu$s.
\item By default the {\textbf{subexptime}} is set to 2.621440~ms. Values smaller than 500~$\mu$s do not make sense. The maximum value is 5.2~s. This limits should be checked.
\end{enumerate}
Here is a list of parameters that should be reset:
\begin{enumerate}
\item \textbf{resetframescaught} should be reset to zero after every acquisition taken with {\tt{receiver start}},{\tt{status start}},{\tt{receiver stop}}. If the acquisition is taken with {\tt{sls\_detector\_acquire}}, there is no need to reset this.
\item After changing the {\tt{timing}} mode of the detector, one should reset to '1' the unused value, in that specific timing mode, between \textbf{frames} and \textbf{cycles}. See section~\ref{triggering} for how to use the timing. At the present moment the detector will acquire more frames than planned if the variable not used between \textbf{frames} and \textbf{cycles} is not reset. In future releases, the unused variable will be ignored. Still resetting is a good practice.
\end{enumerate}
\section{1Gb/s, 10Gb/s links}
\subsection{Checking the 1Gb/s, 10Gb/s physical links}\label{led}
LEDs on the backpanel board at the back of each half module signal:
\begin{itemize}
\item the 1Gb/s physical link is signaled by the most external LED (should be green)
\item the 10Gb/s physical link is signaled by the second most external LED next to the 1Gb/s one (should be green)
\item the 1Gb/s physical link is signaled by the most external LED (should be green). For top half modules is at the extreme left. For bottom half modules is at the extreme right.
\item the 10Gb/s physical link is signaled by the second most external LED next to the 1Gb/s one (should be green).
\end{itemize}
\begin{figure}[t]
\begin{center}
\includegraphics[width=.7\textwidth]{LEDSim}
\end{center}
\caption{1 and 10GB LEDs position.}
\label{fLEDs}
\end{figure}
\subsection{Delays in sending for 1Gb/s, 10Gb/s, 10Gb flow control, receiver fifo}
Extremely advanced options allow to:
@ -539,9 +680,15 @@ 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.
It can help to increase the fifo size of the receiver to {\tt{rx\_fifodepth}} to 1000 images
\begin{verbatim}
./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".
\section{Offline processing and monitoring}
\subsection{Data out of the detector: UDP packets}
\subsection{Data out of the detector: UDP packets}\label{UDP}
The current UDP header format is described in figure~\ref{UDPheader}.
\begin{figure}[t]
@ -608,9 +755,9 @@ Header Version : 1 byte
Note that if one wants to reconstruct the real time the detector was acquiring in 32 bit (autosumming mode), one would have to multiply the SubExptime (ns) for the SubFrame Number.
\subsection{Offline image reconstruction}
The offline image reconstruction is in {\tt{slsDetectorsPackage/slsImageReconstruction}}.
The offline image reconstruction{\tt{slsImageReconstruction}} is not part of the package anymore.
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).\\
The detector writes 2 raw files 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:
@ -626,7 +773,7 @@ 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 {\tt{[singlemodulelongside\_x]}} {\tt{[option to interpolate gap pixels]}} 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]
@ -694,7 +841,7 @@ Start the server again:
\begin{verbatim}
./eigerDetectorServer &
\end{verbatim}
\textbf{Note that the server appropiate for the software version used is located inside the package: {\tt{slsDetectorsPackage/serverBin/eigerDetectorServerxx.yy.}}}.
\textbf{Note that the server appropriate for the software version used is located inside the package: {\tt{slsDetectorsPackage/serverBin/eigerDetectorServerxx.yy.}}}.
To copy the detector server on many boards, a script can be implemented on the lines of:
\begin{verbatim}
@ -716,7 +863,7 @@ cd executables
./boot_recovery
\end{verbatim}
\end{enumerate}
In both case, after booting, only the central one should be on green and red alternating.
In both case, after booting, only the central LED should be on green and red alternating.
From a terminal, do:
\begin{verbatim}
@ -777,17 +924,9 @@ To load the special noise file look at {\tt{settingsdir/eiger/standard/eigernois
sls_detector_put trimbits ../settingsdir/eiger/standard/eigernoise
\end{verbatim}
\section{Running the (9M at cSAXS. For now)}
\begin{itemize}
\item login as {\tt{x12saop@xbl-daq-27}}
\item {\tt{setup\_eiger}} \#loads environmental variables and brings you to the right directory to execute commands
\item slsReceiverScript3 1991 36 \# from one shell.. opens 36 receivers
\item p config ../../eiger\_9m\_10gb\_xbl-daq-27\_withbottom.config
\end{itemize}
\section{Troubleshooting}
\subsection{Cannot successfully finish an acquisition}
\subsubsection{only master module return from acquisition}
\subsubsection{Only master module return from acquisition}
When no packets are received AND detector states in 'running status'. Widest list of causes.
Query the status of each half module till the maximum number {\tt{N}}, {\tt{for i in \$(seq\ 0\ N); do sls\_detector\_get \$i:status; done}}, to check if there are half modules that are still running.
@ -798,7 +937,7 @@ If only the master modules return but ALL the other half modules do not:
\item It can be that the synchronization cable is not connected or the termination board at the synchronization does not work. Check.
\end{itemize}
\subsubsection{a few modules do not return from acquisition}
\subsubsection{A few modules do not return from acquisition}
If only a few modules are still running but the others return, it is a real problem with a backend board or a synchronization bug.
If you can, ssh into the board, kill and start the eigerDetectorServer again (see Section~\ref{server} for how to do this). Keep the terminal with the output from the eigerDetectorServer and repeat the acquisition.
\begin{itemize}
@ -808,11 +947,33 @@ If you can, ssh into the board, kill and start the eigerDetectorServer again (se
\subsection{No packets (or very little) are received}
In both cases running \textbf{wireshark} set to receive UDP packets on the ethernet interface of the receiver (filter the UDPport$>=$xxxx, where xxxx is written in the configuration file) can help you understanding if NO packets are seen or some packets are seen. You have to set the buffer size of the receiving device in wireshark to 100Mbyte minimum. If no packets are received, check that your receiving interface and detector UDPIPs are correct (if in 10Gb). Most of the time in this case it is a basic configuration problem.
If some packets are received, but not all, then it is an optimization problem:
It can help looking at the receiver output, shown in an example here:
\begin{verbatim}
Missing Packets : 224064
Complete Frames : 3499
Last Frame Caught : 3499
\end{verbatim}
The {\tt{Last Frame Caught}}, meaning the packet from the last frame that was sent out by the detector, can help in understanding the problem:
\begin{enumerate}
\item If some packets are received, but not all, it could be a network optimization problem. In this case, the {\tt{Last Frame Caught}} will be a value close to the expected number of frames with missing frames distributed over the whole frame range. In this case:
\begin{itemize}
\item For receiving data over 1Gb, the switch must have FLOW CONTROL enabled
\item If using 10GbE, check that the 10Gb link is active on the backpanel board. Then refer to Section~\ref{10g} to see how to configure the 10Gb ports on the receiving machine correctly.
\end{itemize}
\item If the {\tt{Last Frame Caught}} value is much lower than the expected frames and you are missing a bunch of frames from a point onwards, and you are using {\tt{receiver start, status start}}: then it can be that you are stopping the receiver too early. In particular when you are using {\tt{delay}} it might be that there is some time between when the detector is already done and in {\tt{idle}} state but the receiver is still receiving data. Check with {\tt{./sls\_detector\_get framescaught}} if the receiver is already done before doing {\tt{./sls\_detector\_put receiver stop}}.
\item If the {\tt{Last Frame Caught}} value is much lower than the expected frames and you are missing a bunch of frames from a point onwards and you are running at a higher frame rate than the continuous framerate (see table~\ref{tcont}) with more images than the size of the memory (see table~\ref{timgs}). It might be that you are running out of memory to store images. There is no protection for this. see point~\ref{outmemory}
\end{enumerate}
\subsection{'Got Frame Number Zero from Firmware'}\label{outmemory}
In this case, you have run out of memory size (see table~\ref{timgs} for the size) on the boards so you are trying to store on the DDR2 memories more images that they can contain and the network is not fast enough to send everything out from the 10GbE.
So if you see:
\begin{verbatim}
Got Frame Number Zero from Firmware. Discarding Packet
\end{verbatim}
it means that you run out of memory at the previous acquisition. The cure is taking 2 or 3 SINGLE images in a raw to clear out the memories.
\subsection{The module seems dead, no lights on BEBs, no IP addresses}
\begin{itemize}
@ -828,7 +989,7 @@ If the 1G LED (see Section~\ref{led}) on the backpanel board is not green:
\item The IP address is assigned only at booting up of the boards. Try to reboot in case the board booted before it could have an IP address.
\item Check that you did not run out of IP addresses
\end{itemize}
Check that the board is not in recovery mode (i.e. the central LED on the back is stable green). In this case reboot the board with the soft reset or power cycle it.
Check that the board is not in recovery mode (i.e. the central LED on the back is stable green, see Fig~\ref{fLEDs}). In this case reboot the board with the soft reset or power cycle it.
If the 1Gb LED on the backpanel board is green (see Section~\ref{led}):
\begin{itemize}
@ -843,6 +1004,10 @@ It is connected to the TCPport which the receiver uses:
%%%#To display only open UDP ports try the following command: netstat -vaun
\end{itemize}
\subsection{The client ignores the commands}
Make sure that in the configuration file you do not have {\tt{lock 1}} activated, as this will let only one username from one IP address talk to the detector.
To deactivate it, you need to run {\tt{lock 0}} from the client session where you locked it.
\subsection{Zmq socket is blocked}
It is connected to the TCPport which is used. In rare cases, it might be that the TCP port crashes. To find out which process uses the TCPPOrt do: \textbf{netstat -nlp | grep xxxx}, where xxxx is the tcpport number. To display open ports and established TCP connections, enter: \textbf{netstat -vatn}. Kill the process.
@ -855,14 +1020,18 @@ Note that occasionally if there is a shared memory of a different size (from an
This needs to be cleaned with {\tt{ipcs -m}} and then {\tt{ipcrm -M xxx}}, where xxx are the keys with nattch 0. Alternative in the main slsDetectorFolder there is a script that can be used as {\tt{sh cleansharedmemory.sh}}. Note that you need to run the script with the account of the client user, as the shared memory belongs to the client. It is good procedure to implement an automatic cleanup of the shared memory if the client user changes often.
\subsection{Measure the HV}
For every system but not the 9M:
For every system:
\begin{itemize}
\item Software-wise measure it (now the software returns the measured value), with {\tt{sls\_detector\_get vhighvoltage}}. The returned value is the HV (for proper Eiger setting is approximately 150~V) if it is correctly set. If two master modules are presents (multi systems), the average is returned (still to be tested). If one asks for the individual $n$ half module bias voltage through {\tt{sls\_detector\_get n:vhighvoltage}}, if the $n$ module is a master, the actual voltage will be returned. If it is a slave, -999 will be returned.
\item Hardware-wise measure value of HV on C14 on the power distribution board. Check also that the small HV connector cable is really connected.
\item Hardware-wise (opening the detector) measure value of HV on C14 on the power distribution board. Check also that the small HV connector cable is really connected.
\end{itemize}
The 2M system at ESRF has a HV enable signal that needs to be shortcut in order to overwrite vacuum protections (when not in vacuum).
The 1.5M for OMNY has a relay system that enables HV only when the vacuum is good.
For both systems, it makes sense not to set the HV while running the configuration file but set it at a later stage when sure about the vacuum.
\subsection{The image now has a vertical line}
Check if the vertical line has a length of 256 pixels and a width of 8 columns. In this case it is a dataline beeing bad. It can be either a wirebond problem or a frontend board problem. try to read the FEB temperature (see Section~\ref{}) and report the problem to the SLSDetector group. Most likely it will be a long term fix by checking the hardware.
Check if the vertical line has a length of 256 pixels and a width of 8 columns. In this case it is a dataline being bad. It can be either a wirebond problem or a frontend board problem. try to read the FEB temperature (see Section~\ref{}) and report the problem to the SLSDetector group. Most likely it will be a long term fix by checking the hardware.
\subsection{The image now has more vertical lines}
@ -872,7 +1041,7 @@ If you see strange lines in vertical occurring at period patterns, it is a memor
Depending on your network setup, to speed up the ssh to the boards from a pc with internal dhcp server running: \textbf{iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE; echo "1" > /proc/sys/net/ipv4/ip\_forward}, where eth1 has to be the 1Gb network device on the pc
\subsection{Check firmware version installed on BEB}
Follow some steps described in Section~\label{server}.
You can either ask in the client as described in section~\ref{api}, or login to the boards directly. Follow some steps described in Section~\ref{server}.
\begin{verbatim}
ssh root@bebxxx #password is root
killall eigerDetectorServer # kill server and stopserver
@ -882,7 +1051,7 @@ cd executables/
Scroll up in the terminal till you find {\tt{Firmware Version: xx}}
\subsection{Check if half-module is a master, a slave, a top or a bottom}
Follow some steps described in Section~\label{server}.
Follow some steps described in Section~\ref{server}.
\begin{verbatim}
ssh root@bebxxx #password is root
killall eigerDetectorServer # kill server and stopserver
@ -894,7 +1063,21 @@ Scroll up in the terminal till you find:\\
*************** MASTER/SLAVE ***************\\
*************** NORMAL/SPECIAL ***************\\
\subsection{'Cannot connect to socket'}
This error is typically due to the detector server not running. For why, see section~\ref{servernot}.
\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.
\subsection{'Acquire has already started' error message}
If you see the client returning the following error message:\\
``Acquire has already started. If previous acquisition terminated unexpectedly, reset busy flag to restart.(sls\_detector\_put busy 0)''\\
You need to run the command:
\begin{verbatim}
./sls_detector_put busy 0
\end{verbatim}
\section{Client checks - command line}
@ -1037,7 +1220,74 @@ where {\tt{number}} is a string that should be interpreted as an int for 0/1 me
\end{enumerate}
\section{Complete data out rate tables}
In table~\ref{tframescomplete} is a list of all the readout times in the different configurations.
\begin{tiny}
\begin{table}
\begin{flushleft}
\begin{tabular}{|c|c|c|c|c|c|c|}
\hline
\tiny{dr} & \tiny{clkdivider} & \tiny{flags} & \tiny{readout t($\mu$s)} & \tiny{max frame rate (kHz)} & \tiny{min period ($\mu$s)} & \tiny{max imgs (nominal/our network)}\\
\hline
4 & 0 & parallel & 3.4 & 22 & 44 & 30k/50k\\
\hline
4 & 0 & nonparallel & 44 & 21 & 49 & 30k/50k\\
\hline
4 & 1 & parallel & 6 & 10.5 & 92 & 30k/100k\\
\hline
4 & 1 & nonparallel & 88.7 & 10.5 & 93 & 30k/100k\\
\hline
4 & 2 & parallel & 11.2 & 5.4 & 197 & infinite\\
\hline
4 & 2 & nonparallel & 176.5 & 5.4 & 180 & infinite\\
\hline
\hline
8 & 0 & parallel & 3.4 & 11.1 & 89 & 15k/24k\\
\hline
8 & 0 & nonparallel & 85.7 & 11.1 & 91 & 15k/24k\\
\hline
8 & 1 & parallel & 6.1 & 5.7 & 181 & 15k/52k\\
\hline
8 & 1 & nonparallel & 170.5 & 5.7 & 175 & 15k/52k\\
\hline
8 & 2 & parallel & 11.2 & 2.9 & 342 & infinite\\
\hline
8 & 2 & nonparallel & 340.3 & 2.9 & 344 & infinite\\
\hline
\hline
16 & 0 & parallel & 3.4 & 6.1 & 164 & 8k/12k\\
\hline
16 & 0 & nonparallel & 126 & 5.6& 179 & 8k/23k\\
\hline
16 & 1 & parallel & 6.1 & 3.9& 257 & 8k/28k\\
\hline
16 & 1 & nonparallel & 255 & 3.3& 303 & infinite\\
\hline
16 & 2 & parallel & 11 & 1.9 & 526 &infinite \\
\hline
16 & 2 & nonparallel & 504 & 1.8 & 555 & infinite\\
\hline
\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.}
\label{tframescomplete}
\end{flushleft}
\end{table}
\end{tiny}
Table~\ref{tx} shows the bandwidth of data trasnferring between the FEB and BEB and of the DDR2 memory access. the GTX lanes are only capable of 25.6~Gbit/s. This limits the 12/16 bit frame rate. The 2$\times$DDR2 memories have a bandwidth or 2$\cdot$25.6~Gb/s=51.2~Gb/s. Due to this memory access bandwidth, the 32 bit autosumming mode can only run in {\tt{clkdivider}} 2.
\begin{figure}[t]
\begin{center}
\includegraphics[width=1.\textwidth]{TansmissionRates}
\end{center}
\caption{Transmission bandwidth for the FEB $\to$BEB transfer (second column) and the DDR2 memories (fourth column). }
\label{tx}
\end{figure}
\end{document}

BIN
manual/manual-client/LEDSim.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 863 KiB

BIN
manual/manual-client/TansmissionRates.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

BIN
manual/manual-client/tiggerIN.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 167 KiB

BIN
slsDetectorSoftware/jungfrauDetectorServer/bin/jungfrauDetectorServer_developer
View File

Binary file not shown.

10
slsDetectorSoftware/jungfrauDetectorServer/gitInfo.txt
View File

@ -1,9 +1,9 @@
Path: slsDetectorsPackage/slsDetectorSoftware/jungfrauDetectorServer
URL: origin git@github.com:slsdetectorgroup/slsDetectorPackage.git
Repository Root: origin git@github.com:slsdetectorgroup/slsDetectorPackage.git
Repsitory UUID: 4d4e4a4ce7a91af094251ed0903575ba7e73ef5f
Revision: 153
Branch: versioning
Repsitory UUID: bab7d8e3fba7119b3da122cd4769f2447d6da28a
Revision: 154
Branch: developer
Last Changed Author: Dhanya_Thattil
Last Changed Rev: 3847
Last Changed Date: 2018-05-28 18:02:50.000000002 +0200 ./RegisterDefs.h
Last Changed Rev: 3890
Last Changed Date: 2018-06-01 10:38:17.000000002 +0200 ./RegisterDefs.h

8
slsDetectorSoftware/jungfrauDetectorServer/gitInfoJungfrau.h
View File

@ -1,6 +1,6 @@
#define GITURL "git@github.com:slsdetectorgroup/slsDetectorPackage.git"
#define GITREPUUID "4d4e4a4ce7a91af094251ed0903575ba7e73ef5f"
#define GITREPUUID "bab7d8e3fba7119b3da122cd4769f2447d6da28a"
#define GITAUTH "Dhanya_Thattil"
#define GITREV 0x3847
#define GITDATE 0x20180528
#define GITBRANCH "versioning"
#define GITREV 0x3890
#define GITDATE 0x20180601
#define GITBRANCH "developer"

4
slsDetectorSoftware/jungfrauDetectorServer/slsDetectorFunctionList.c
View File

@ -518,9 +518,9 @@ int powerChip (int on){
}
}
return ((bus_r(CHIP_POWER_REG) & CHIP_POWER_ENABLE_MSK) >> CHIP_POWER_ENABLE_OFST);
//return ((bus_r(CHIP_POWER_REG) & CHIP_POWER_ENABLE_MSK) >> CHIP_POWER_ENABLE_OFST);
/**temporary fix until power reg status can be read */
//return ((bus_r(CHIP_POWER_REG) & CHIP_POWER_STATUS_MSK) >> CHIP_POWER_STATUS_OFST);
return ((bus_r(CHIP_POWER_REG) & CHIP_POWER_STATUS_MSK) >> CHIP_POWER_STATUS_OFST);
}

2
slsDetectorSoftware/jungfrauDetectorServer/slsDetectorServer_defs.h
View File

@ -10,7 +10,7 @@
#define GOODBYE (-200)
#define PROGRAMMING_MODE (-200)
#define MIN_REQRD_VRSN_T_RD_API 0x171220
#define REQRD_FRMWR_VRSN 0x20180226
#define REQRD_FRMWR_VRSN 0x180226
/* Struct Definitions */