eiger manual for 5.0

manual/manual-client/Eiger_short.tex

@@ -99,7 +99,7 @@ If one desires to set the zmqport manually, he offset has to be taken into accou
 
 {\tt{slsMultiReceiver}} uses two or more receivers in one single terminal: {\tt{./slsMultiReceiver startTCPPort numReceivers withCallback}}, where startTCPPort assumes the other ports are consecutively increased.
 
-The command {\tt{r\_framesperfile}} sets the number of frames written in the same file. By default now it is 10000. It can be changes. It needs to be lowered particularly if one wants to parallelize the following conversion of the files. 
+The command {\tt{r\_framesperfile}} (\tt{\textcolor{red}{rx\_framesperfile}}) sets the number of frames written in the same file. By default now it is 10000. It can be changes. It needs to be lowered particularly if one wants to parallelize the following conversion of the files. 
 
 
 \subsection{Mandatory setup - Client}
@@ -292,12 +292,13 @@ sls_detector_get receiver
 
 There is a more complex way of performing an acquisition, that is useful for debugging and in case one wants a non blocking behavior: 
 
-You can then reset to zero the number of frames caught, then  start the receiver and the detector:
+You can then reset to zero the number of frames caught (in releases<5.0), 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{enumerate}
+In release \textcolor{red}{5.0} it is not needed to reset the frames caughts.
 
 You can poll the detector status using:
 \begin{verbatim}
@@ -487,6 +488,23 @@ 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.} 
 
+In release \textcolor{red}{5.0} in 4-bit modes one can set a sort of ROI in the detector such to read half of the module (the central part) or a quarter of it with almost double or four times the frame rate. By default the \tt{\textcolor{red}{readnlines}} is set to \tt{256} meaning the whole chip. With \tt{\textcolor{red}{readnlines 128}} or \tt{\textcolor{red}{readnlines 64}} one sets to read half/quarter rows from the chip. In table~\ref{table:hfrpartial} the maximum frame rates, exposure time and period for the partial readout.\\
+
+
+\begin{tabular}{|c|c|c|c|c|c|c|}
+\hline
+ readnlines & \# pixels & Active area (cm$^2$) & Max frame rate (kHz) & Period ($\mu$s) & Dead time ($\mu$s) & \# buffered images\\
+\hline
+256 &1024 $\times$ 512 & 8 $\times$ 3.8 & 22.7 & 44.0 &4.1 & 30k\\
+\hline
+128 &1024 $\times$ 256 & 8 $\times$ 1.9 & 42.1 & 23.7 &4.2 & 60k\\
+\hline
+64 & 1024 $\times$ 128 & 8 $\times$ 0.95 & 73.5 & 13.6 &4.2 & 120k\\
+\hline
+\end{tabular}
+\label{table:hfrpartial}
+
+
 \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} 
@@ -638,17 +656,17 @@ The detector can be setup such to receive external triggers. Connect a LEMO sign
 \begin{verbatim}
 sls_detector_put 0-timing [auto/trigger/burst_trigger/gating]
 sls_detector_put 0-frames x
-sls_detector_put 0-cycles y
+sls_detector_put 0-cycles y  (\textcolor{red}{triggers})
 sls_detector_acquire 0-
 \end{verbatim}
 No timeout is expected between the start of the acquisition and the arrival of the first trigger. 
 
 Here are the implemented options so far:
 \begin{itemize}
-\item {\tt{auto}} is the software controlled acquisition (does not use triggers), where {\tt{exptime}} and {\tt{period}} have to be set. Set number of cycles (i.e. triggers) to 1 using {\tt{cycles}}. Set number of frames using {\tt{frames}}.
-\item {\tt{trigger}} 1 frame taken for 1 trigger. Your {\tt{frames}} needs to be  1 always, {\tt{cycles}} can be changed and defines how many triggers are considered.  {\tt{exptime}} needs to be set. In the GUI this is called trigger exposure series.  
-\item {\tt{burst\_trigger}} gets only 1 trigger, but allows to take many frames. With {\tt{frames}} one can change the number of frames. {\tt{cycles}} needs to be 1.  {\tt{exptime}} and {\tt{period}} have to be set. In the gui it is called trigger readout.
-\item{\tt{gating}} allows to get a frame only when the trigger pulse is gating. Note that in this case the exp time and period only depend on the gating signal. {\tt{cycles}} allows to select how many gates to consider.  Set number of frames to 1 using {\tt{frames}}. IMPORTANT: Up to firmware 23, the last subframe is oblige to finish being taken, despite the gate signal going down. This will be configurable from later fw and software version. Also, in gating mode, due to timimg of the state machine, you need to leave 500~$\mu$s deadtime between the end on an acquisition and the next. This is as the state machine is unable to check for changes in the status in the first 500~$\mu$s. ATTENTION: if you are in 16 bit mode and you are applying online rate corrections, as now the exptime is generated by the trigger, you might not have correct rate corrections. If you know what the exposure time is in the gating signal, then you can set the {\tt{exptime}} once and the rate corrections will be correct. In 32 bit mode, it does not matter as the rate corrections depends on the {\tt{subexptime}} which is software set independently from the gate exptime.
+\item {\tt{auto}} is the software controlled acquisition (does not use triggers), where {\tt{exptime}} and {\tt{period}} have to be set. Set number of {\tt{cycles}} (\textcolor{red}{triggers}) to 1. Set number of frames using {\tt{frames}}.
+\item {\tt{trigger}} 1 frame taken for 1 trigger. Your {\tt{frames}} needs to be  1 always, {\tt{cycles}} ({\tt{\textcolor{red}{triggers}}}) can be changed and defines how many triggers are considered.  {\tt{exptime}} needs to be set. In the GUI this is called trigger exposure series.  
+\item {\tt{burst\_trigger}} gets only 1 trigger, but allows to take many frames. With {\tt{frames}} one can change the number of frames. {\tt{cycles}} ({\tt{\textcolor{red}{triggers}}}) needs to be 1.  {\tt{exptime}} and {\tt{period}} have to be set. In the gui it is called trigger readout.
+\item{\tt{gating}} allows to get a frame only when the trigger pulse is gating. Note that in this case the exp time and period only depend on the gating signal. {\tt{cycles}} (\tt{\textcolor{red}{triggers}}) allows to select how many gates to consider.  Set number of frames to 1 using {\tt{frames}}. IMPORTANT: Up to firmware 23, the last subframe is oblige to finish being taken, despite the gate signal going down. This will be configurable from later fw and software version. Also, in gating mode, due to timimg of the state machine, you need to leave 500~$\mu$s deadtime between the end on an acquisition and the next. This is as the state machine is unable to check for changes in the status in the first 500~$\mu$s. ATTENTION: if you are in 16 bit mode and you are applying online rate corrections, as now the exptime is generated by the trigger, you might not have correct rate corrections. If you know what the exposure time is in the gating signal, then you can set the {\tt{exptime}} once and the rate corrections will be correct. In 32 bit mode, it does not matter as the rate corrections depends on the {\tt{subexptime}} which is software set independently from the gate exptime.
 
 ATTENTION: From release 4.1.1 with the {\tt{trigger}} option it is possible to have software triggers as a debugging tool (instead of the hardware trigger signal. One should start the acquisition (with the blocking {\tt{sls\_detector\_acquire}} if wanted and with another client one can send the softare trigger {\tt{sls\_detector\_put status trigger}}. This option allows for example to perform a motor scan (moving a motor in between single images) and still writing all images to the same file. 
 When using 32-bit mode, by default the acquisition ends the last complete subframe that was started when still the acquisition time was valid. This has been chosen as many people wants to know the exact acquisition time for when the detector was taking data and also, if {\tt{ratecorr}} are active, the last subframe will be correctly corrected, while otherwise it will be corrected with a wrong subdeadtime. 
@@ -658,13 +676,13 @@ However, from 4.1.0, in gating mode, an option to immediately terminate the subf
 
 Hardware-wise, the ENABLE OUT signal outputs when the chips are really acquiring. This means that the single subframes will be output in 32 bit mode. The TRIGGER OUT outputs the sum-up-signal at the moment (which is useless). This will be changed in the future to output the envelop of the enable signal. 
 
-We are planning to change some functionality, i.e. unify the {\tt{trigger}} and {\tt{burst\_trigger}} trigger modes and make both {\tt{frames}} and {\tt{cycles}} configurable at the same time.
+We are planning to change some functionality, i.e. unify the {\tt{trigger}} and {\tt{burst\_trigger}} trigger modes and make both {\tt{frames}} and {\tt{cycles}} (\tt{\textcolor{red}{triggers}}) configurable at the same time.
 
 There is the possibility to use {\tt{timing trigger/burst\_trigger}} and send software single commands to fake the trigger. This is done with:
 \begin{verbatim}
 sls_detector_put 0-timing [trigger/burst_trigger]
 sls_detector_put 0-frames x
-sls_detector_put 0-cycles y
+sls_detector_put 0-cycles y (\textcolor{red}{triggers})
 sls_detector_status trigger
 \end{verbatim}
  Note that this functionality is very (!) useful if you need to do something between and acquisition and the next. This can be used to do a fast threshold scan for example. See section~\ref{sec:fastthresholdscan}.
@@ -745,7 +763,7 @@ If \textbf{dr} is 32 and \textbf{clkdivider} is not 2, whatever the detector get
 Here is a list of parameters that should be reset:
 \begin{enumerate}
 \item  \textbf{resetframescaught} (only for releases < 5.x) 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.
+\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} (\tt{\textcolor{red}{triggers}}). 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} (\tt{\textcolor{red}{trigger}}) is not reset. In future releases, the unused variable will be ignored. Still resetting is a good practice.
       
 \end{enumerate}
 
@@ -1248,6 +1266,14 @@ sls_detector_put pulsechip N #to pulse N
 sls_detector_put pulsechip -1 #to get out of testing mode 
 \end{verbatim}
 Note that the answer will be $2 \cdot \textrm{{\tt{N}}} +2$ in this case.
+Or in \textcolor{red}{5.x}:
+\begin{verbatim}
+sls_detector_put vthreshold 4000
+sls_detector_put vtrim 4000
+sls_detector_put pulsechip N #to pulse N
+sls_detector_put pulsechip -1 #to get out of testing mode
+\end{verbatim}
+Note that the answer will be $2 \cdot \textrm{{\tt{N}}} +4$ in this case.
 
 \item  \textbf{Pulse analogically:} You want to really check the analogical part of the detector, not just the readout.
 
@@ -1266,8 +1292,25 @@ sls_detector_put resmat 0
 sls_detector_acquire
 \end{verbatim}
 You read {\tt{N}} in every pixel if you are setup correctly. 
+or in realese \textcolor{red}{5.x}:
+\begin{verbatim}
+sls_detector_put vcal 3600
+sls_detector_put vthreshold 1700
+sls_detector_put vrpreamp 3100
+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 100 0 1;
+done;
+done;
+sls_detector_put partialreset 1
+\end{verbatim}
 \end{itemize}
  
+
+
+
 \section{Load a noise pattern with shape}
 For debug purposes, we have created a noise pattern with a shape. If you reconstruct correctly your image, you should be able to read ".EIGER'' in the same direction for both the top and bottom in normal human readable orientation.
 To load the special noise file look at {\tt{settingsdir/eiger/standard/eigernoise.sn0xx}} in the package. 
@@ -1293,7 +1336,7 @@ We have also been requested if we could speed up the threshold scan. At the mome
 ./sls_detector_put enablefwrite 0
 ./sls_detector_put resetframescaught 0 
 ./sls_detector_put index 0
-./sls_detector_put cycles 21
+./sls_detector_put cycles 21  (\textcolor{red}{triggers})
 ./sls_detector_put receiver start
 ./sls_detector_put status start 
 for i in $(seq 0 20);