diff --git a/manual/manual-client/Eiger_short.tex b/manual/manual-client/Eiger_short.tex index 48366bc1d..1dd58633a 100755 --- a/manual/manual-client/Eiger_short.tex +++ b/manual/manual-client/Eiger_short.tex @@ -176,6 +176,7 @@ One can configure all the detector settings in a parameter file {\tt{setup.det}} \begin{verbatim} sls_detector_put 0-parameters setup.det \end{verbatim} +Note that the parameter file for any realease before 4.1.1 has not the possibility to understand parameters to be set differently for different half modules, i.e. {\tt{0:txndelay\_left xxxxx},\tt{1:txndelay\_left yyyyy}}. In the case of \E, the proper bias voltage of the sensor has to be setup, i.e. the {\tt{setup.det}} file needs to contain the line {\tt{vhighvoltage 150}}. Other detector functionality, which are rarely changed can be setup here. Other important settings that are configured in the {\tt{setup.det}} file are: @@ -609,18 +610,19 @@ 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-triggers y +sls_detector_put 0-cycles y 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 triggers (i.e. triggers) to 1 using {\tt{triggers}}. 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{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{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{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. +\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. +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. However, from 4.1.0, in gating mode, an option to immediately terminate the subframe when the gate signal goes down it is implemented to stop the acquisition at the same time. This option is {\tt{./sls\_detector\_put interruptsubframe 1}} while the default option is {\tt{./sls\_detector\_put interruptsubframe 0}}. @@ -628,13 +630,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{triggers}} 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}} 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-triggers y +sls_detector_put 0-cycles y 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}. @@ -715,7 +717,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} 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{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{triggers} 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}. 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} @@ -1257,7 +1259,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 triggers 21 +./sls_detector_put cycles 21 ./sls_detector_put receiver start ./sls_detector_put status start for i in $(seq 0 20); @@ -1515,8 +1517,8 @@ frames number where {\tt{number}} is a string to be interpreted as an integer. \item \begin{verbatim} -sls_detector_get triggers -triggers number +sls_detector_get cycles +cycles number \end{verbatim} where {\tt{number}} is a string to be interpreted as an integer.