detectors/slsDetectorPackage
24
1
Fork 0
mirror of https://github.com/slsdetectorgroup/slsDetectorPackage.git synced 2026-01-21 06:05:27 +01:00
Code Issues Actions Packages Releases Activity

cleaned up gh-pages moved stuff from devdoc

Browse Source
This commit is contained in:
mazzol_a
2026-01-13 11:11:12 +01:00
parent 41afc284da
commit fe994b612f
1654 changed files with 250585 additions and 52435 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
10.0.0/_sources/ToString.rst.txt Normal file
View File

@@ -0,0 +1,6 @@
ToString
==============
String conversion
.. doxygenfile:: ToString.h

387
10.0.0/_sources/binaryfileformat.rst.txt Normal file
View File

@@ -0,0 +1,387 @@
.. _binary file format:
Binary File Format
====================
This is the default file format that can be configured using command `fformat <commandline.html#term-fformat-binary-hdf5>`_.
.. code-block:: bash
sls_detector_put fformat binary
Master File
--------------
* File Name: [fpath]/[fname]_master_[findex].json :ref:`Details here<file name format>`
* It is in json format and created for every acquisition.
* It contains :ref:`attributes<master file attributes>` relevant to the acquisition. This can vary with detector type shown in :ref:`master json file examples <json master file examples>` here.
* It shows the :ref:`**SLS Receiver Header** <sls receiver header format>` format used in data files.
* Enabled/disabled using command `fmaster <commandline.html#term-fmaster-0-1>`_.
Data File
----------
* File Name: [fpath]/[fname]_dx_fy_[findex].raw :ref:`Details here<file name format>`
* It store multiple frames sequentially, with total number of frames determined by `rx_framesperfile <commandline.html#term-rx_framesperfile-n_frames>`_ parameter.
* Each frame includes a :ref:`**sls_receiver_header** <sls receiver header format>` structure, followed by the actual frame data.
* More details on :ref:`slsReceiverHeader<sls receiver header format>` and the actual image data is described in the :ref:`Detector Image Size and Format <data format>` section.
.. _json master file examples:
JSON Master File Examples
---------------------------------------------------
Eiger
^^^^^
.. code-block:: text
{
"Version": 7.2,
"Timestamp": "Wed Nov 13 15:46:30 2024",
"Detector Type": "Eiger",
"Timing Mode": "auto",
"Geometry": {
"x": 2,
"y": 1
},
"Image Size in bytes": 262144,
"Pixels": {
"x": 512,
"y": 256
},
"Max Frames Per File": 10000,
"Frame Discard Policy": "nodiscard",
"Frame Padding": 1,
"Scan Parameters": "[disabled]",
"Total Frames": 1,
"Receiver Roi": {
"xmin": 4294967295,
"xmax": 4294967295,
"ymin": 4294967295,
"ymax": 4294967295
},
"Dynamic Range": 16,
"Ten Giga": 0,
"Exptime": "1s",
"Period": "1s",
"Threshold Energy": -1,
"Sub Exptime": "2.62144ms",
"Sub Period": "2.62144ms",
"Quad": 0,
"Number of rows": 256,
"Rate Corrections": "[0]",
"Frames in File": 1,
"Frame Header Format": {
"Frame Number": "8 bytes",
"SubFrame Number/ExpLength": "4 bytes",
"Packet Number": "4 bytes",
"Bunch ID": "8 bytes",
"Timestamp": "8 bytes",
"Module Id": "2 bytes",
"Row": "2 bytes",
"Column": "2 bytes",
"Reserved": "2 bytes",
"Debug": "4 bytes",
"Round Robin Number": "2 bytes",
"Detector Type": "1 byte",
"Header Version": "1 byte",
"Packets Caught Mask": "64 bytes"
}
}
Jungfrau
^^^^^^^^
.. code-block:: text
{
"Version": 7.2,
"Timestamp": "Wed Nov 13 13:03:53 2024",
"Detector Type": "Jungfrau",
"Timing Mode": "auto",
"Geometry": {
"x": 1,
"y": 1
},
"Image Size in bytes": 1048576,
"Pixels": {
"x": 1024,
"y": 512
},
"Max Frames Per File": 10000,
"Frame Discard Policy": "nodiscard",
"Frame Padding": 1,
"Scan Parameters": "[disabled]",
"Total Frames": 1000,
"Receiver Roi": {
"xmin": 4294967295,
"xmax": 4294967295,
"ymin": 4294967295,
"ymax": 4294967295
},
"Exptime": "10us",
"Period": "2ms",
"Number of UDP Interfaces": 1,
"Number of rows": 512,
"Frames in File": 10,
"Frame Header Format": {
"Frame Number": "8 bytes",
"SubFrame Number/ExpLength": "4 bytes",
"Packet Number": "4 bytes",
"Bunch ID": "8 bytes",
"Timestamp": "8 bytes",
"Module Id": "2 bytes",
"Row": "2 bytes",
"Column": "2 bytes",
"Reserved": "2 bytes",
"Debug": "4 bytes",
"Round Robin Number": "2 bytes",
"Detector Type": "1 byte",
"Header Version": "1 byte",
"Packets Caught Mask": "64 bytes"
}
}
Gotthard2
^^^^^^^^^^^^
.. code-block:: text
{
"Version": 7.2,
"Timestamp": "Wed Nov 13 14:18:17 2024",
"Detector Type": "Gotthard2",
"Timing Mode": "auto",
"Geometry": {
"x": 1,
"y": 1
},
"Image Size in bytes": 2560,
"Pixels": {
"x": 1280,
"y": 1
},
"Max Frames Per File": 20000,
"Frame Discard Policy": "nodiscard",
"Frame Padding": 1,
"Scan Parameters": "[disabled]",
"Total Frames": 10,
"Receiver Roi": {
"xmin": 4294967295,
"xmax": 4294967295,
"ymin": 4294967295,
"ymax": 4294967295
},
"Exptime": "0ns",
"Period": "0ns",
"Burst Mode": "burst_internal",
"Frames in File": 10,
"Frame Header Format": {
"Frame Number": "8 bytes",
"SubFrame Number/ExpLength": "4 bytes",
"Packet Number": "4 bytes",
"Bunch ID": "8 bytes",
"Timestamp": "8 bytes",
"Module Id": "2 bytes",
"Row": "2 bytes",
"Column": "2 bytes",
"Reserved": "2 bytes",
"Debug": "4 bytes",
"Round Robin Number": "2 bytes",
"Detector Type": "1 byte",
"Header Version": "1 byte",
"Packets Caught Mask": "64 bytes"
}
}
Mythen3
^^^^^^^
.. code-block:: text
{
"Version": 7.2,
"Timestamp": "Wed Nov 13 14:39:14 2024",
"Detector Type": "Mythen3",
"Timing Mode": "auto",
"Geometry": {
"x": 1,
"y": 1
},
"Image Size in bytes": 15360,
"Pixels": {
"x": 3840,
"y": 1
},
"Max Frames Per File": 10000,
"Frame Discard Policy": "nodiscard",
"Frame Padding": 1,
"Scan Parameters": "[disabled]",
"Total Frames": 1,
"Receiver Roi": {
"xmin": 4294967295,
"xmax": 4294967295,
"ymin": 4294967295,
"ymax": 4294967295
},
"Dynamic Range": 32,
"Ten Giga": 1,
"Period": "2ms",
"Counter Mask": "0x7",
"Exptime1": "0.1s",
"Exptime2": "0.1s",
"Exptime3": "0.1s",
"GateDelay1": "0ns",
"GateDelay2": "0ns",
"GateDelay3": "0ns",
"Gates": 1,
"Threshold Energies": "[-1, -1, -1]",
"Frames in File": 1,
"Frame Header Format": {
"Frame Number": "8 bytes",
"SubFrame Number/ExpLength": "4 bytes",
"Packet Number": "4 bytes",
"Bunch ID": "8 bytes",
"Timestamp": "8 bytes",
"Module Id": "2 bytes",
"Row": "2 bytes",
"Column": "2 bytes",
"Reserved": "2 bytes",
"Debug": "4 bytes",
"Round Robin Number": "2 bytes",
"Detector Type": "1 byte",
"Header Version": "1 byte",
"Packets Caught Mask": "64 bytes"
}
}
Moench
^^^^^^
.. code-block:: text
{
"Version": 7.2,
"Timestamp": "Wed Nov 13 14:41:32 2024",
"Detector Type": "Moench",
"Timing Mode": "auto",
"Geometry": {
"x": 1,
"y": 1
},
"Image Size in bytes": 320000,
"Pixels": {
"x": 400,
"y": 400
},
"Max Frames Per File": 100000,
"Frame Discard Policy": "discardpartial",
"Frame Padding": 1,
"Scan Parameters": "[disabled]",
"Total Frames": 1,
"Receiver Roi": {
"xmin": 4294967295,
"xmax": 4294967295,
"ymin": 4294967295,
"ymax": 4294967295
},
"Exptime": "10us",
"Period": "2ms",
"Number of UDP Interfaces": 1,
"Number of rows": 400,
"Frames in File": 1,
"Frame Header Format": {
"Frame Number": "8 bytes",
"SubFrame Number/ExpLength": "4 bytes",
"Packet Number": "4 bytes",
"Bunch ID": "8 bytes",
"Timestamp": "8 bytes",
"Module Id": "2 bytes",
"Row": "2 bytes",
"Column": "2 bytes",
"Reserved": "2 bytes",
"Debug": "4 bytes",
"Round Robin Number": "2 bytes",
"Detector Type": "1 byte",
"Header Version": "1 byte",
"Packets Caught Mask": "64 bytes"
}
}
Chip Test Board
^^^^^^^^^^^^^^^
.. code-block:: text
{
"Version": 7.2,
"Timestamp": "Wed Nov 13 15:32:59 2024",
"Detector Type": "ChipTestBoard",
"Timing Mode": "auto",
"Geometry": {
"x": 1,
"y": 1
},
"Image Size in bytes": 48018,
"Pixels": {
"x": 3,
"y": 1
},
"Max Frames Per File": 20000,
"Frame Discard Policy": "nodiscard",
"Frame Padding": 1,
"Scan Parameters": "[disabled]",
"Total Frames": 1,
"Receiver Roi": {
"xmin": 4294967295,
"xmax": 4294967295,
"ymin": 4294967295,
"ymax": 4294967295
},
"Exptime": "0ns",
"Period": "0.18s",
"Ten Giga": 0,
"ADC Mask": "0x2202",
"Analog Flag": 1,
"Analog Samples": 8003,
"Digital Flag": 0,
"Digital Samples": 1000,
"Dbit Offset": 0,
"Dbit Reorder": 1,
"Dbit Bitset": 0,
"Transceiver Mask": "0x3",
"Transceiver Flag": 0,
"Transceiver Samples": 1,
"Frames in File": 1,
"Frame Header Format": {
"Frame Number": "8 bytes",
"SubFrame Number/ExpLength": "4 bytes",
"Packet Number": "4 bytes",
"Bunch ID": "8 bytes",
"Timestamp": "8 bytes",
"Module Id": "2 bytes",
"Row": "2 bytes",
"Column": "2 bytes",
"Reserved": "2 bytes",
"Debug": "4 bytes",
"Round Robin Number": "2 bytes",
"Detector Type": "1 byte",
"Header Version": "1 byte",
"Packets Caught Mask": "64 bytes"
}
}

105
10.0.0/_sources/commandline.rst.txt Normal file
View File

@@ -0,0 +1,105 @@
Command line interface
==============================================
Usage
-------------
The syntax is *'[detector index]-[module index]:[command]'*, where the indices are by default '0', when not specified.
.. _cl-module-index-label:
Module index
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Modules are indexed based on their order in the hostname command. They are used to configure a specific module within a detector and are followed by a ':' in syntax.
.. code-block::
# Applies to all modules of detector 0
sls_detector_put exptime 5s
# Applies to only the 4th module
sls_detector_put 3:exptime 5s
Detector index
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This index is useful when configuring multiple detectors from a single host. Each detector uses a unique shared memory identified by a detector index, derived again from the hostname command. It is followed by a '-'.
.. code-block::
# For detector with index 2 in shared memory
sls_detector_put 2-hostname bchip133+bchip123+bchip456
# Without '-', the detector index defaults to 0
sls_detector_put hostname bchip133+bchip123+bchip456
# Accessing all modules with detector index 2
sls_detector_put 2-exptime
# Starting acquisition only for detector with index 2
sls_detector_put 2-start
# Applies only to the 2nd detector, 4th module
sls_detector_put 1-3:exptime 5s
Command Execution
^^^^^^^^^^^^^^^^^^^^^^^
Commands can be executed using:
* **sls_detector_put**: setting values
* **sls_detector_get**: getting values
* **sls_detector**: automatically infers based on the number of arguments.
* **sls_detector_help**: gets help on the specific command
* **sls_detector_acquire**: initiates acquisition with the detector. This command blocks until the entire acquisition process is completed.
Help
--------
.. code-block::
# get list of commands
sls_detector_get list
# search for a particular command using a word
sls_detector_get list | grep adc
# get help for a particular command
sls_detector_get -h fpath
sls_detector_help fpath
# list of deprecated commands
list deprecated
Autocompletion
---------------
bash_autocomplete.sh or zsh_autocomplete.sh must be sourced from the main package folder to enable auto completion of commands and arguments for the command line on that shell.
.. code-block::
source bash_autocomplete.sh
Commands
-----------
.. include:: ../commands.rst
Deprecated commands
------------------------
.. note ::
All the dac commands are preceded with the **dac** command. Use command **daclist** to get correct list of dac command arguments for current detector.
.. csv-table:: Deprecated commands
:file: ../deprecated.csv
:widths: 35, 35
:header-rows: 1

242
10.0.0/_sources/configcommands.rst.txt Normal file
View File

@@ -0,0 +1,242 @@
.. _setup commands:
Setup Commands
================================
Introduction
-------------
To connect to any device, one needs a unique combination of **IP address** (which identifies the device) and **port number** (which specifies the service).
This package typically deals with two types of network interfaces:
* **1 GbE public interface** - Accessible from anywhere on the network. Connectivity can be verified by pinging this interface from any PC.
* **10 GbE private interface** - Dedicated to high-speed data transfer with a specific PC. In addition to the 1 GbE public interface (MTU 1500), the device may include one or more private 10 GbE interfaces (MTU 9000), which are not accessible from other machines.
Client to Module
-----------------
.. figure:: images/Client_module_commands.png
:target: _images/Client_module_commands.png
:width: 700px
:align: center
:alt: Client Module Commands
Client Module TCP Commands
The client configures and controls modules via the 1 GbE public TCP interface.
* Should be able to ping the module's hostname from any PC on the network.
* If one cannot ping, ensure that it is powered on.
* If the command cannot connect to the port (`hostname command <commandline.html#term-hostname>`_ failed), the onboard servers may not have started yet.
Each physical module has its own unique IP address. As the IPs are already different, all modules can share the same default ports:
* 1952 - Default Module TCP Control Port
* 1953 - Default Module TCP Stop port
.. code-block:: bash
# Therefore, one can use
hostname bchip100+bchip101+
# instead of
hostname bchip100:1952+bchip101:1954+
**Simulators**, however, usually run on the same PC. See `virtual servers <https://slsdetectorgroup.github.io/devdoc/virtualserver.html>`_ for more details. In that case, each instance must use a different port. By incrementing port numbers, you can also use the virtual command for convenience.
.. code-block:: bash
# Therefore, one can use
virtual 2 1952
# instead of
hostname localhost:1952+localhost:1954+
Client to Receiver
--------------------
.. figure:: images/Client_receiver_commands.png
:target: _images/Client_receiver_commands.png
:align: center
:alt: Client Receiver Commands
Client Receiver TCP Commands
Each module has a receiver, which can be either local or remote.
The client can configure and control receivers via the 1 GbE public TCP interface:
* Should be able to ping the receiver's hostname from any PC on the network.
* If one cannot ping, ensure that it is powered on.
* If the command cannot connect to the port (`rx_hostname command <commandline.html#term-rx_hostname-hostname-or-ip-address>`_ failed), the receivers may not have started yet.
Since multiple receiver processes typically run on the same PC, they share the same IP. Here, each receiver process must use a different TCP port for a unique connection.
* 1954 - Default Receiver TCP port
Configuring the receiver with the command `rx_hostname command <commandline.html#term-rx_hostname-hostname-or-ip-address>`_, sets up a receiver for every module in shared memory automatically ie. every module's receiver TCP port will automatically increment in shared memory. The starting port is defined by the command `rx_tcpport <commandline.html#term-rx_tcpport-port>`_ with the default being 1954.
A multi-module command (without colon or module index) sets incremental ports starting from the specified port number.
.. code-block:: bash
hostname bchip100+bchip101+bchip102+bchip103+
rx_tcport 2000 # sets the receiver port to 2000, 2001, 2002, 2003
For example, using default TCP ports (1954, 1955):
.. code-block:: bash
hostname bchip100+bchip101+
rx_hostname localhost
# Equivalent to:
rx_hostname localhost:1954+localhost:1955+
# or set to another set of ports (automatically incremented)
rx_tcpport 1984
rx_hostname localhost
# instead of
rx_hostname localhost:1984+localhost:1985+
Module to Receiver
-------------------
.. figure:: images/Module_receiver_commands.png
:target: _images/Module_receiver_commands.png
:align: center
:alt: Module Receiver Commands
Module Receiver UDP Commands
**10GbE Interface**
The module typically sends images to the receiver via a 10 GbE private interface on the receiver PC, which has an MTU of 9000 to support jumbo packets. The private interface is not reachable from other machines, so it cannot be pinged from anywhere.
**Multiple UDP Packets**
Images are split into UDP packets for transmission. Unlike TCP, UDP is connectionless and does not guarantee delivery. Therefore, the receiver PC must be tuned for reliable reception. See `Troubleshooting <https://slsdetectorgroup.github.io/devdoc/troubleshooting.html>`_.
**UDP Configuration**
Unlike TCP, the module (hardware) requires explicit configuration for sending images via UDP, including:
* Source and destination IPs
* Source and destination MAC addresses
* Source and destination ports
**UDP Destination**
Info on where to send the image from the module to.
**UDP Desination IP** - The IP of the receiver PC's 10 GbE interface, usually found via ``ifconfig``. Command: `udp_dstip <commandline.html#term-udp_dstip-x.x.x.x-or-auto>`_. For 1GbE interface and for this command, one can use 'auto' as an argument, which will pick up the IP from the `rx_hostname command <commandline.html#term-rx_hostname-hostname-or-ip-address>`_.
**UDP desintation MAC** - Also obtained from the interface using ``ifconfig``. For built-in receivers, the module configures this automatically from the ``UDP destination IP``. For custom receivers, it must be explicitly provided. Command: `udp_dstmac <commandline.html#term-udp_dstmac-x-x-x-x-x-x>`_
**UDP destination port** - Ensure uniqueness if multiple users share the interface. Command: `udp_dstport <commandline.html#term-udp_dstport-n>`_
* 50001 - Default Receiver UDP port
**UDP Source**
As it is a one-way communication (module to receiver with no reply or acknowledgements), info on the source of the image is more for debugging purposes and prevent packet rejection.
**UDP source IP** - Must be on the same subnet as the destination IP (same first three octets) to prevent packet rejection by the receiver interface. For 1GbE interface and for this command (except for Eiger), one can use ``auto`` as an argument, which will pick up the IP from the `hostname command <commandline.html#term-hostname>`_. Command: `udp_srcip <commandline.html#term-udp_srcip-x.x.x.x-or-auto>`_
.. code-block:: bash
# 10 GbE interface
hostname bchip100
udp_dstip 10.0.2.1
udp_srcip 10.0.2.19
rx_hostname localhost
# 1 GbE interface
hostname bchip100
rx_hostname localhost
udp_dstip auto # this command uses IP from rx_hostname. So, it comes after.
udp_srcip auto # this command uses IP from hostname
**UDP source MAC** - By default, it is set to ``aa:bb:cc:dd:xx:yy`` where ``xx`` and ``yy`` are module row and column indices to differentiate the modules while debugging. Command: `udp_srcmac <commandline.html#term-udp_srcmac-x-x-x-x-x-x>`_
**UDP source port** - This is hardcoded in every module to the same value in the detector server and cannot be changed.
Note: If there is a second UDP port on the module, use 'udp_dstport2' or 'udp_dstip2'etc. See `here <https://slsdetectorgroup.github.io/devdoc/dataformat.html>`_ for more detector specific info.
Receiver to GUI
-----------------
.. figure:: images/Receiver_gui_commands.png
:target: _images/Receiver_gui_commands.png
:align: center
:alt: Receiver GUI Commands
Receiver GUI Commands
Enabling the GUI automatically streams images from the receiver via ZMQ sockets. Even without the GUI, streaming can be activated explicitly using the command `rx_zmqstream <commandline.html#term-rx_zmqstream-0-1>`_. ZMQ streaming uses TCP/IP, so the ports must be configured appropriately.
**Receiver ZMQ Port** - Port from which the receiver streams ZMQ packets. Command: `rx_zmqport <commandline.html#term-rx_zmqport-port>`_
* 30001 - Default Receiver ZMQ Port (stream out from)
**Client ZMQ Port** - Port that the client ZMQ socket listens to. Command: `zmqport <commandline.html#term-zmqport-port>`_
* 30001 - Default Client ZMQ Port (listens to)
**Client ZMQ IP** - IP address the client ZMQ socket listens to. Command: `zmqip <commandline.html#term-zmqip-x.x.x.x>`_. By default, this is set to the IP of ``rx_hostname``, but can be set to any IP address that the client can reach.
* Default: Receiver’s hostname (rx_hostname)
.. note ::
``zmqport`` and ``zmqip`` need to be set up in shared memory before starting up the Gui. If the Gui is already running, change it in the Advanced Tab directly in the Gui.
``rx_zmqstream`` is set to 1 when the GUI is started, but has to be manually set back to 0 to disable zmq streaming in the receiver for better performance when not using the Gui.
The GUI hwm (high water mark, which is like a measurement of the number of enqueued zmq packets) values are set to a low number (from library default of possibly 1000 to 2) to reduce the zmq buffer to display only some of the images. Resetting it back to -1 or 1000 should only matter if one plans to not use the Gui and still zmq stream without wanting to drop zmq images (eg. for external processing chain).
Receiver to External Processing
--------------------------------
.. figure:: images/Receiver_external_process_commands.png
:target: _images/Receiver_external_process_commands.png
:align: center
:alt: Click to zoom
Receiver External Process Commands
Images from the receiver can also be streamed to an external processing chain for further processing or storage. In this setup:
* The external processor listens to the ZMQ ports and IPs that the receiver streams from.
* The client ZMQ sockets now listen to the ports and IPs that the external processor streams from instead of the receiver.
**Receiver ZMQ Port** - Port from which the receiver streams ZMQ packets. Command: `rx_zmqport <commandline.html#term-rx_zmqport-port>`_
* 30001 - Default Receiver ZMQ Port (stream out from)
**Client ZMQ Port** - Port that the client ZMQ socket listens to. Command: `zmqport <commandline.html#term-zmqport-port>`_. In this set up, it should listen to the zmq port that the external process is streaming out from.
* 30001 - Default Client ZMQ Port (listens to)
**Client ZMQ IP** - IP address the client ZMQ socket listens to. Command: `zmqip <commandline.html#term-zmqip-x.x.x.x>`_. By default, this is set to the IP of ``rx_hostname``, but in this set up, it should listen to the zmq IP that the external process is streaming out from.
* Default: Receiver’s hostname (rx_hostname)

116
10.0.0/_sources/consuming.rst.txt Normal file
View File

@@ -0,0 +1,116 @@
Consuming slsDetectorPackage
===============================
Depending on how you want to build your integration with
slsDetectorPackage there are a few different ways to
consume our package. The recommended way is to use one of the
CMake approaches.
One can test with :ref:`detector simulators<Virtual Detector Servers>` before testing the API with a real detector or when a real detector is not at hand.
CMake: slsDetectorPackage as submodule in your project
---------------------------------------------------------------
If you are using CMake to build your integration and want to build everything
in one go, we support adding slsDetectorPackage as a subfolder in your cmake project.
A minimal CMakeLists.txt could look like this:
.. code-block:: cmake
project(myDetectorIntegration)
cmake_minimum_required(VERSION 3.14)
add_subdirectory(slsDetectorPackage)
#Add your executable
add_executable(example main.cpp)
target_compile_features(example PRIVATE cxx_std_11)
#Link towards slsDetectorShared
target_link_libraries(example slsDetectorShared)
A fully working example can be found at:
https://github.com/slsdetectorgroup/cmake-subfolder-example
CMake: find_package(slsDetectorPackage)
------------------------------------------
If you have compiled and installed slsDetectorPackage we also support
find_package in CMake. If installed in a system wide location no path
should be needed, otherwise specify cmake prefix path.
.. code-block:: cmake
cmake_minimum_required(VERSION 3.14)
project(myintegration)
find_package(slsDetectorPackage 5.0 REQUIRED)
add_executable(example main.cpp)
target_link_libraries(example slsDetectorShared)
Then assuming the slsDetectorPackage is installed in /path/to/sls/install
you should be able to configure and build your project in this way.
.. code-block:: bash
cmake ../path/to/your/source -DCMAKE_PREFIX_PATH=/path/to/sls/install
make
A minimal example is available at: https://github.com/slsdetectorgroup/minimal-cmake
CMake: find_package and conda
----------------------------------
.. note::
conda can also be used for installing dependencies such as zmq, Qt4 etc.
find_package(slsDetectorPackage) also works if you have installed slsDetectorPackage using conda.
The only difference is that you point CMake to $CONDA_PREFIX
.. code-block:: bash
#assuming myenv contains slsdetlib
conda activate myenv
cmake ../path/to/your/source -DCMAKE_PREFIX_PATH=$CONDA_PREFIX
make
Depending on your system compiler you might also have to install gxx_linux-64 to compiled.
No tools minimal approach
-----------------------------
While not recommended it is still possible to specify the include and library paths
manually when invoking g++. This can sometimes be handy for a quick try.
.. code-block:: cpp
#include "sls/Detector.h"
#include <iostream>
int main(){
sls::Detector det;
//Get all values and print them
std::cout << "Hostname: " << det.getHostname() << "\n";
std::cout << "Type: " << det.getDetectorType() << "\n";
std::cout << "Udp ip: " << det.getSourceUDPIP() << "\n";
//Get mac addr
const int module = 0;
auto mac = det.getSourceUDPMAC()[module];
std::cout << "Mac addr of module "<< module << " is " << mac.str() << '\n';
}
.. code-block:: bash
g++ -I/install/path/include/ -L/install/path/lib64/ myapp.cpp -lSlsDetector -lSlsSupport -Wl,-rpath=../install/path/lib64

14
10.0.0/_sources/container_utils.rst.txt Normal file
View File

@@ -0,0 +1,14 @@
ContainerUtils
==================
Helper functions to handle standard container compliant
containers. Supports array, vector, sls::Result etc.
While not a part of the public API we aim not to change this
interface too much. However, we don't give the same strong
guarantees as for Detector etc.
Any reoccurring container operation should probably be added to
this file.
.. doxygenfile:: container_utils.h

330
10.0.0/_sources/dataformat.rst.txt Normal file
View File

@@ -0,0 +1,330 @@
.. _data format:
Detector Image Size and Format
================================
Each UDP port creates its own output file, which contains the data of the image transmitted over that port. More on number of files and naming for each file in the `File format <fileformat.html>`_ section.
Jungfrau
-------------
Single Port Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. image:: images/Jungfrau_module.png
:target: _images/Jungfrau_module.png
:width: 650px
:align: center
:alt: Jungfrau Module Single Port Configuration
By default, only the outer 10GbE interface is enabled, transmitting the full image over a single UDP port. This results in one file per module containing the complete image.
Total image size = 524,288 bytes
- 8 chips (2 x 4 grid)
- 256 x 256 pixels (chip size)
- 2 bytes (pixel width)
Double Port Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. image:: images/Jungfrau_two_port.png
:target: _images/Jungfrau_two_port.png
:width: 500px
:align: center
:alt: Jungfrau Module Two Port Configuration
If both interfaces are enabled using the `numinterfaces <commandline.html#term-numinterfaces-1-2>`_ command on compatible hardware and firmware, the image splits into top and bottom halves sent over two UDP ports:
- The top half transmits via the inner interface (`udp_dstport2 <commandline.html#term-udp_dstport2-n>`_ and `udp_dstip2 <commandline.html#term-udp_dstip2-x.x.x.x-or-auto>`_).
- The bottom half uses the outer interface(`udp_dstport <commandline.html#term-udp_dstport-n>`_ and `udp_dstip <commandline.html#term-udp_dstip-x.x.x.x-or-auto>`_).
The number of files per module equals the active UDP ports—two files per module when both interfaces are used.
Image size per UDP port or File = 262,144 bytes
- **Complete Image size / 2**
Read Partial Rows
^^^^^^^^^^^^^^^^^^
.. image:: images/Jungfrau_read_rows.png
:target: _images/Jungfrau_read_rows.png
:width: 550px
:align: center
:alt: Jungfrau Module Read Partial Rows Configuration
The number of image rows per port can be adjusted using the `readnrows <commandline.html#term-readnrows>`_ command. By default, 512 rows are read, but a smaller value centers the readout vertically (e.g., 8 rows reads 4 above and 4 below the center). Increasing the value symmetrically expands the region toward the top and bottom. Permissible values are multiples of 8.
Total image size = 32,768 bytes
- 8 chips (2 x 4 grid)
- **8** x 256 pixels (chip size: **8 rows**)
- 2 bytes (pixel width)
Note: Still in prototype stage, writes complete image (padded or not depending on `rx_padding <commandline.html#term-rx_padding-0-1>`_ parameter) to file. Only the summary written to console in the receiver handles the `readnrows <commandline.html#term-readnrows>`_ to calculate to calculate complete images received. Only reduces network load, not file size. Use `rx_roi <commandline.html#term-rx_roi-xmin-xmax-ymin-ymax>`_ for file size.
Moench
-------------
Single Port Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. image:: images/Moench_module.png
:target: _images/Moench_module.png
:width: 550px
:align: center
:alt: Moench Module Single Port Configuration
By default, only the outer 10GbE interface is enabled, transmitting the full image over a single UDP port. This results in one file per module containing the complete image.
Total image size = 320,000 bytes
- 400 x 400 pixels (chip size)
- 2 bytes (pixel width)
Double Port Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. image:: images/Moench_two_port.png
:target: _images/Moench_two_port.png
:width: 400px
:align: center
:alt: Moench Module Two Port Configuration
If both interfaces are enabled using the `numinterfaces <commandline.html#term-numinterfaces-1-2>`_ command on compatible hardware and firmware, the image splits into top and bottom halves sent over two UDP ports:
- The top half transmits via the inner interface (`udp_dstport2 <commandline.html#term-udp_dstport2-n>`_ and `udp_dstip2 <commandline.html#term-udp_dstip2-x.x.x.x-or-auto>`_).
- The bottom half uses the outer interface(`udp_dstport <commandline.html#term-udp_dstport-n>`_ and `udp_dstip <commandline.html#term-udp_dstip-x.x.x.x-or-auto>`_).
The number of files per module equals the active UDP ports—two files per module when both interfaces are used.
Image size per UDP port or File = 160,000 bytes
- **Complete Image size / 2**
Read Partial Rows
^^^^^^^^^^^^^^^^^^
.. image:: images/Moench_read_rows.png
:target: _images/Moench_read_rows.png
:width: 400px
:align: center
:alt: Moench Module Read Partial Rows Configuration
The number of image rows per port can be adjusted using the `readnrows <commandline.html#term-readnrows>`_ command. By default, 400 rows are read, but a smaller value centers the readout vertically (e.g., 16 rows reads 8 above and 8 below the center). Increasing the value symmetrically expands the region toward the top and bottom. Permissible values are multiples of 16.
Total image size = 12,800 bytes
- **16** x 400 pixels (chip size: **16 rows**)
- 2 bytes (pixel width)
Note: Still in prototype stage, writes complete image (padded or not depending on `rx_padding <commandline.html#term-rx_padding-0-1>`_ parameter) to file. Only the summary written to console in the receiver handles the read n rows to calculate complete images received. Only reduces network load, not file size. Use `rx_roi <commandline.html#term-rx_roi-xmin-xmax-ymin-ymax>`_ for file size.
Eiger
-------------
Default Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. image:: images/Eiger_module.png
:target: _images/Eiger_module.png
:width: 350px
:align: center
:alt: Eiger Module Default Configuration
Each Eiger module has two independent identical readout systems (other than firmware), each with its own control port and `hostname <commandline.html#term-hostname>`_ to be configured with. They are referred to as the 'top' and 'bottom' half modules. The bottom half module is flipped vertically.
Each half module has 2 parallel UDP ports for 2 chips each. The left UDP port is configured with `udp_dstport <commandline.html#term-udp_dstport-n>`_, while the right UDP port is configured with `udp_dstport2 <commandline.html#term-udp_dstport2-n>`_. This is vice versa for the bottom half module.
Image size per UDP port or File = 262,144 bytes
- 2 chips (1 x 2 grid)
- 256 x 256 pixels (chip size)
- 2 bytes (default pixel width)
The myth, the legend, the bottom ports: Demystifying them
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. figure:: images/Eiger_bottom_1.png
:target: _images/Eiger_bottom_1.png
:width: 350px
:align: center
:alt: Eiger Bottom as Firmware gets it
How the firmware gets the images
.. figure:: images/Eiger_bottom_2.png
:target: _images/Eiger_bottom_2.png
:width: 350px
:align: center
:alt: Eiger Bottom after the firmware flips it horizontally
After the firmware flips it horizontally
.. figure:: images/Eiger_bottom_3.png
:target: _images/Eiger_bottom_3.png
:width: 350px
:align: center
:alt: After the software swaps the udp ports
After the software swaps the udp ports
.. figure:: images/Eiger_bottom_4.png
:target: _images/Eiger_bottom_4.png
:width: 400px
:align: center
:alt: After the gui has flipped the bottom vertically
After the gui has flipped the bottom vertically
Note: The same process happens for the bottom 2 udp ports of the quad.
Pixel width
^^^^^^^^^^^^^
The pixel width can be configured to 4, 8, 16 (default) or 32 bits using the command `dr <commandline.html#term-dr-value>`_. This affects image size per UDP port or file.
Flip rows
^^^^^^^^^^
One can use the command `fliprows <commandline.html#term-fliprows-0-1>`_ to flip the rows vertically for the bottom or top half module. It is sent out to the reciever, but does not flip rows in the output file itself, but rather streams out this info via the json header and thus instructs the GUI to display them correctly.
1GbE/ 10GbE Interfaces
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Both UDP ports `udp_dstport <commandline.html#term-udp_dstport-n>`_ and `udp_dstport2 <commandline.html#term-udp_dstport2-n>`_ are used in Eiger as shows in the figure. Both of them can be set to use either the 1GbE or the 10GbE interface for data. The 1GbE interface is used also for control and configuration. For data, the 1GbE interface is enabled by default. It can be disabled by enabling the `tengiga <commandline.html#term-tengiga-0-1>`_ command and updating both the `udp_dstport <commandline.html#term-udp_dstport-n>`_ , `udp_dstport2 <commandline.html#term-udp_dstport2-n>`_ , `udp_dstip <commandline.html#term-udp_dstip-x.x.x.x-or-auto>`_ commands to match the 1GbE or 10GbE interface. This setting only affects packetsize and number of packets, but does not affect the total image size.
Reducing network load
^^^^^^^^^^^^^^^^^^^^^^
**Activate**: By default, the `hostname <commandline.html#term-hostname>`_ command activates the respective half module it connects to, enabling all UDP ports. To deactivate an entire half module (i.e., both UDP ports), use the `activate <commandline.html#term-activate-0-1>`_ command. This disables both UDP ports for that half module, so no data is transmitted from it — only half of the module is read out. To specify which half module to activate or deactivate, use the module index (for Eiger, each half module has its own module index).
**Datastream**: The `datastream <commandline.html#term-datastream-left-right-0-1>`_ command with arguments to specify which port can be used to disable the data streaming from one or both the two UDP ports in a half module. This allows for more flexible configurations, such as reading only two chips or one UDP port of a half module. To specify which half module to activate or deactivate, use the module index (for Eiger, each half module has its own module index).
Note: Only the activated ports will write data as it does not make sense to write an empty file.
**Read Partial Rows**: The number of image rows per port can be adjusted using the `readnrows <commandline.html#term-readnrows>`_ command. By default, 256 rows are read, but a smaller value centers the readout vertically (e.g., 8 rows reads 4 above and 4 below the center). Increasing the value symmetrically expands the region toward the top and bottom. Permissible values depend on dynamic range and 10GbE enable.
.. image:: images/Eiger_read_rows.png
:target: _images/Eiger_read_rows.png
:width: 400px
:align: center
:alt: Eiger Module Read Partial Rows Configuration
Total image size per UDP Port = 8,192 bytes
- 2 chips (1 x 2 grid)
- **8** x 256 pixels (chip size: **8 rows**)
- 2 bytes (default pixel width)
Note: Still in prototype stage, writes complete image (padded or not depending on `rx_padding <commandline.html#term-rx_padding-0-1>`_ parameter) to file. Only the summary written to console in the receiver handles the `readnrows <commandline.html#term-readnrows>`_ to calculate complete images received. Only reduces network load, not file size. Use `rx_roi <commandline.html#term-rx_roi-xmin-xmax-ymin-ymax>`_ for file size.
Quad
^^^^^^
The Eiger quad is a special hardware configuration that uses only the top half-module to create a quad layout. In this setup, the second half of the top module—normally associated with the right-side UDP port—is used to represent the inverted bottom half of the quad.
As with any standard half-module, it includes one control TCP port (with a hostname) and two UDP data ports (top and bottom). When the quad option is enabled, the firmware automatically flips the second UDP port vertically.
In this configuration, the fliprows command cannot be used to flip the entire half-module. Instead, the receiver automatically includes row-flipping information only for the second UDP port in the JSON header, so the GUI can apply the correct orientation during display
.. image:: images/Eiger_quad.png
:target: _images/Eiger_quad.png
:width: 300px
:align: center
:alt: Eiger Quad Configuration
Image size per UDP port = same as a normal Eiger UDP port
Mythen3
-------------
Default Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. image:: images/Mythen3_module.png
:target: _images/Mythen3_module.png
:align: center
:alt: Mythen3 Module Default Configuration
Each Mythen3 module is a 1D detector with 10 chips, each with 128 channels. Each channel has 3 counters that are enabled by default.
Image size = 15,360 bytes
- 10 chips (1 x 10 grid)
- 128 channels
- 3 counters
- 4 bytes (default pixel width)
Counters
^^^^^^^^^^^
If all 3 counters are enabeld, the frame size for each channel is multiplied by 3. The counters are stored consecutively per channel. One can disable one or more of the counters using the `counters <commandline.html#term-counters-i0-i1-i2-...>`_ command. The frame size will then be reduced accordingly.
Image size = 10,240 bytes
- 10 chips (1 x 10 grid)
- 128 channels
- 2 counters (0, 1 enabled)
- 4 bytes (default pixel width)
Pixel width
^^^^^^^^^^^^^
The pixel width can be configured to 8, 16 or 32 (default) bits using the command `dr <commandline.html#term-dr-value>`_. 32 bits is actually 24 bits in the chip. This setting does affect image size.
1GbE/ 10GbE Interfaces
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The UDP port can be set to use either the 1GbE or the 10GbE interface for data. The 1GbE interface is used also for control and configuration. For data, the 10GbE interface is enabled by default. It can be disabled by using the `tengiga <commandline.html#term-tengiga-0-1>`_ command and updating the `udp_dstport <commandline.html#term-udp_dstport-n>`_ and `udp_dstip <commandline.html#term-udp_dstip-x.x.x.x-or-auto>`_ commands to match the 1GbE or 10GbE interface. This setting only affects packetsize and number of packets, but does not affect the total image size.
Gotthard2
-------------
Default Configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. image:: images/Gotthard2_module.png
:target: _images/Gotthard2_module.png
:align: center
:alt: Gotthard2 Module Default Configuration
Each Gotthard2 module is a 1D detector with 10 chips, each with 128 channels.
Image size = 2,560 bytes
- 10 chips (1 x 10 grid)
- 128 channels
- 2 bytes (pixel width)
Veto Info
^^^^^^^^^^^
One can enable veto data in the chip of the Gotthard2 module using the `veto <commandline.html#term-veto-0-1>`_ command. By default, this is disabled. This does not affect the image size as veto information is not sent out through the same 10GbE interface.
One can either stream out the veto info through the low latency link (2.5 gbps) or for debugging purposes through another 10GbE interface.
For debugging purposes, the veto info can be enabled using the `numinterfaces <commandline.html#term-numinterfaces-1-2>`_ command and the following parameters are updated: `udp_dstport2 <commandline.html#term-udp_dstport2-n>`_ and `udp_dstip2 <commandline.html#term-udp_dstip2-x.x.x.x-or-auto>`_. The veto data from this port is of course written to a separate file and is not combined in the virtual HDF5 file mapping (complete image mapped).

76
10.0.0/_sources/dependencies.rst.txt Normal file
View File

@@ -0,0 +1,76 @@
Dependencies
=========================
While we value few dependencies some libraries are required in
order to not have to reinvent the wheel. Due to the state of package
management in C++ we decided to bundle some of them with our source
code. These are found in the libs/ directory.
-----------------------
Core
-----------------------
To use the basic building blocks, meaning sls_detector_get/put and
the shared libraries these are needed:
* Linux, preferably recent kernel (currently no cross platform support)
* CMake >= 3.14
* C++17 compatible compiler. (We test with gcc and clang)
.. note ::
For v9.x.x of slsDetectorPackage and older, C++11 compatible compiler.
-----------------------
Python bindings
-----------------------
* Python >= 3.8
* pybind11 2.13.6 (packaged in libs)
.. note ::
Refer :ref:`pybind11 notes. <pybind for different slsDetectorPackage versions>`
-----------------------
ZeroMQ
-----------------------
* Zeromq 4.3.4 (packaged in libs)
.. note ::
Refer :ref:`zeromq notes. <zeromq for different slsDetectorPackage versions>`
-----------------------
GUI
-----------------------
* Qt 5.9
* Qwt 6.1.5 (packaged in libs)
-----------------------
Moench executables
-----------------------
* libtiff
-----------------------
Documentation
-----------------------
The documentation that you are reading now is built with
* Doxygen (to extract C++ classes etc.)
* Breathe (Sphinx plugin to handle doxygen xml)
* Sphinx with sphinx_rtd_theme
-----------------------
Packaged in libs/
-----------------------
* catch2 (unit testing)
* rapidjson (streaming from receiver)
* pybind11 (python bindings)
* qwt (gui plotting)
* libzmq (streaming to/from receiver)

18
10.0.0/_sources/detector.rst.txt Normal file
View File

@@ -0,0 +1,18 @@
Detector
==============================================
The sls::Detector is the public API to control
detectors from C++. This API is also used internally
for the Python bindings and the command line interface.
If a receiver has been configured, this is also controlled
through this class.
Most, if not all, functions are called in parallel
and the return value is a thin std::vector wrapper
containing results from all modules. (:ref:`Result class<Result Class>`)
Here are some :ref:`examples <Cplusplus Api Examples>` on how to use the API.
.. doxygenclass:: sls::Detector
:members:
:undoc-members:

119
10.0.0/_sources/examples.rst.txt Normal file
View File

@@ -0,0 +1,119 @@
.. _Cplusplus Api Examples:
Examples
===========
Setup
------------
The examples here assume that you have compiled and installed slsDetectorPackage
to ~/sls/install and that the option for SLS_USE_SIMULATOR was enabled. This also builds
the virtual detector servers that we will be using for testing.
We also add ~/sls/detector/install/bin to the path for convenience.
Compile examples
-------------------
The source code of the examples is available at:
https://github.com/slsdetectorgroup/api-examples
.. code-block:: bash
git clone https://github.com/slsdetectorgroup/api-examples.git
mkdir build && cd build
cmake ../api-examples -DCMAKE_PREFIX_PATH=~/sls/detector/install
make
Below follows a short description of what is included in the examples.
Running a config file [e1]
-----------------------------
.. code-block:: cpp
#include "sls/Detector.h"
...
sls::Detector det;
det.loadConfig("path/to/config/file.config");
To configure the connection between PC and detector the easiest
is to run a config file. For this example we first launch a virtual Jungfrau server and
then set up the detector.
**Launch a virtual detector server**
.. code-block:: bash
jungfrauDetectorServer_virtual
This launches a virtual Jungfrau detector server. As default it uses port 1952 and 1953
for communication over TCP. Most commands go on 1952 and only a few such as stop and status on 1953.
**Run example to configure**
.. code-block:: bash
./e1-config one_det_no_receiver.config
- 12:01:06.371 INFO: Shared memory deleted /slsDetectorPackage_multi_0_sls_0
- 12:01:06.371 INFO: Shared memory deleted /slsDetectorPackage_multi_0
- 12:01:06.372 INFO: Shared memory created /slsDetectorPackage_multi_0
- 12:01:06.376 INFO: Loading configuration file: one_det_no_receiver.config
- 12:01:06.376 INFO: Adding detector localhost
- 12:01:06.377 INFO: Shared memory created /slsDetectorPackage_multi_0_sls_0
- 12:01:06.377 INFO: Checking Detector Version Compatibility
- 12:01:06.378 INFO: Detector connecting - updating!
hostname [localhost]
Jungfrau detector with 1 modules configured
Using the return type sls::Result [e2]
-----------------------------------------
Since many our detectors have multiple modules we cannot return
a single value when reading from the Detector. Hostname, Ip and also
for example exposure time can differ between modules.
Therefore we return Result<T> which is a thin wrapper around
std::vector.
.. code-block:: cpp
sls::Result<int> res1{1, 1, 1};
std::cout << "res1: " << res1 << '\n';
res1.squash();
# return -1 if different
res1.squash(-1);
# throw exception with custom message if different
res1.tsquash("Values are different);
Setting exposure time [e3]
-----------------------------------------
For setting times, like exposure time, period, delay etc.
we use std::chrono::duration.
Example 3 shows how to set and read exposure time as well
as converting to floating point.
.. code-block:: cpp
#include "sls/Detector.h"
#include <chrono>
...
std::chrono::microseconds t0{500};
det.setExptime(t0);

75
10.0.0/_sources/fileformat.rst.txt Normal file
View File

@@ -0,0 +1,75 @@
.. _file format:
File format
================================
If `fwrite <commandline.html#term-fwrite-0-1>`_ is enabled, the receiver will write data to files.
Number of Files
----------------
Every acquisition will create a master file and data files.
An acquisition can have multiple data files for a single frame. The number of files is determined by the number of UDP ports per module and the number of modules.
* Every modules has its own receiver process. Every receiver process can have 1 or 2 UDP ports.
* Each UDP port will create its own file. Therefore, each receiver can write 1 or 2 files.
* So, for example a detector with 4 modules with 2 UDP ports each will create a total of 8 files with file names containing UDP port index **'_d0'** to **'_d7'**.
A new file containing **'_f[file_index]'** in file name is also created when reaching the maximum frames per file. Configured using `rx_framesperfile <commandline.html#term-rx_framesperfile-n_frames>`_.
.. _file name format:
Naming
-------
| Master File Name: [fpath]/[fname]_master_[findex].[ext]
| Data File Name: [fpath]/[fname]_dx_fy_[findex].[ext]
* fpath: file path set using command `fpath <commandline.html#term-fpath-path>`_. Default: '/'
* fname: file name prefix using command `fname <commandline.html#term-fname-name>`_. Default: "run"
* findex: acquisition index using command `findex <commandline.html#term-findex-n_value>`_. Automatically incremented for every acquisition with `sls_detector_acquire <commandline.html#term-acquire>`_ (if `fwrite <commandline.html#term-fwrite-0-1>`_ enabled).
* x: unique udp port index. New file per UDP port.
* y: file index. New file created after reaching max frames per file.
* ext: file extension. Default: "raw"(data file) or "json"(master file)
Some file name examples:
.. code-block:: bash
# first file
path-to-file/run_d0_f0_0.raw
# first file for second UDP port
path-to-file/run_d1_f0_0.raw
# second file after reaching max frames in first file
path-to-file/run_d0_f1_0.raw
# second acquisition, first file
path-to-file/run_d0_f0_1.raw
Formats
--------
There are 2 file formats supported by the receiver:
* Binary - extension .json (master file) or .raw (data files)
* HDF5 - extension .h5
The default is binary. HDF5 can be enabled by compiling the package with HDF5 option enabled. The file format is set using the command `fformat <commandline.html#term-fformat-binary-hdf5>`_.
Content
--------
| `Master File`: Contains the metadata of the acquisition. The content is described in :ref:`master file attributes <master file attributes>`.
| `Data File`: Contains the metadata for each image (:ref:`slsReceiverHeader<sls receiver header format>`) and the `data of the image` transmitted over that port. The image data is described in :ref:`Detector Image Size and Format <data format>` section.
| More content and examples are found in the :ref:`HDF5 file format <hdf5 file format>` and :ref:`Binary file format <binary file format>` sections.

364
10.0.0/_sources/firmware.rst.txt Normal file
View File

@@ -0,0 +1,364 @@
.. _firmware upgrade:
Firmware Upgrade
=================
Eiger
-------------
Download
^^^^^^^^^^^^^
- `bcp script <https://github.com/slsdetectorgroup/slsDetectorFirmware/blob/master/binaries/eiger/bcp>`__
- detector server corresponding to package in slsDetectorPackage/serverBin
- `bit files <https://github.com/slsdetectorgroup/slsDetectorFirmware>`__
Upgrade
^^^^^^^^
#. Tftp must be already installed on your pc to use the bcp script.
#. Copy new servers to the board. See :ref:`how to upgrade detector servers<Detector Server Upgrade>` for more detals. A reboot should have started the new linked servers automatically. For Eiger, do not reboot yet as we need to program the firmware via bit files.
* This step is crucial when registers between firmwares change. Failure to do so will result in linux on boards to crash and boards can't be pinged anymore.
#. Bring the board into programmable mode using either of the 2 ways. Both methods result in only the central LED blinking.
* **Manual:**
Do a hard reset for each half module on back panel boards, between the LEDs, closer to each of the 1G ethernet connectors. Push until all LEDs start to blink.
* Software:
.. code-block:: bash
# Option 1: if the old server is still running:
sls_detector_put execcommand "./boot_recovery"
# Option 2:
ssh root@bebxxx
cd executables
./boot_recovery
#. Start a terminal for each half module and run the following to see progress.
.. code-block:: bash
nc -p 3000 -u bebxxx 3000
# Press enter twice to see prompt with board name.
> bebxxx
# After each bcp command, wait for this terminal to print "Success".
#. In another terminal, run the following to update firmware. Please update bit files with great caution as it could make your board inaccessible, if done incorrectly.
.. code-block:: bash
#update back end fpga
bcp download.bit bebxxx:/fw0
#update front left fpga
bcp download.bit bebxxx:/febl
#update front right fpga
bcp download.bit bebxxx:/febr
#update kernel (only if required by us)
bcp download.bit bebxxx:/kernel
#. Reboot the detector.
.. code-block:: bash
# In the first terminal where we saw "Succeess"
# reconfig febX is necessary only if you have flashed a new feb firmware
reconfig febl
reconfig febr
# will reboot controller
reconfig fw0
.. note ::
If the detector servers did not start up automatically after reboot, you need to add scripts to do that. See :ref:`Automatic start<Automatic start servers>` for more details.
Jungfrau
-------------
Download
^^^^^^^^^^^^^
- detector server corresponding to package in slsDetectorPackage/serverBin
- `pof files <https://github.com/slsdetectorgroup/slsDetectorFirmware>`__
Upgrade
^^^^^^^^
.. warning ::
In case you have had issues in the past with programming via software:
* 6.1.2 server has a fix for seamless fpga programming
* We recommend first updating the on-board detector server to 6.1.2 (with client 6.1.x) using command `updatedetectorserver <commandline.html#term-updatedetectorserver-server_name-with-full-path>`_.
* Then use command 'programfpga' to only update firmware or use command 'update' to update firmware and server to the latest release.
Check :ref:`firmware troubleshooting <blackfin firmware troubleshooting>` if you run into issues while programming firmware.
Program from console
.. code-block:: bash
# These instructions are for upgrades from v5.0.0. For earlier versions, please contact us.
# Always ensure that the client and server software are of the same release.
# copies server, links new server to jungfrauDetectorServer,
# removes old server from respawn, sets up new lnked server to respawn
# programs fpga, reboots
# older versions: v5.0.0 - 6.0.0 using tftp from tftp folder of pc
sls_detector_put update jungfrauDetectorServervxxx pcxxx xx.pof
# v6.1.1 - present (copies server from the full path provided)
sls_detector_put update jungfrauDetectorServervxxx xx.pof
# Or only program firmware
sls_detector_put programfpga xxx.pof
Mythen III
-----------
Download
^^^^^^^^^^^^^
- detector server corresponding to package in slsDetectorPackage/serverBin
- `rbf files <https://github.com/slsdetectorgroup/slsDetectorFirmware>`__
Upgrade
^^^^^^^^
Program from console
.. code-block:: bash
# Always ensure that the client and server software are of the same release.
# copies server, links new server to mythen3DetectorServer,
# removes old server from respawn, sets up new lnked server to respawn
# programs fpga, reboots
# older versions: v5.0.0 - 6.0.0 using tftp from tftp folder of pc
sls_detector_put update mythen3DetectorServervxxx pcxxx xxx.rbf
# v6.1.1 - present (copies server from the full path provided)
sls_detector_put update mythen3DetectorServervxxx xxx.rbf
# Or only program firmware
sls_detector_put programfpga xxx.rbf
.. note ::
If the detector servers did not start up automatically after reboot, you need to add scripts to do that. See :ref:`Automatic start<Automatic start servers>` for more details.
Gotthard II
-------------
Download
^^^^^^^^^^^^^
- detector server corresponding to package in slsDetectorPackage/serverBin
- `rbf files <https://github.com/slsdetectorgroup/slsDetectorFirmware>`__
Upgrade
^^^^^^^^
Program from console
.. code-block:: bash
# Always ensure that the client and server software are of the same release.
# copies server, links new server to gotthard2DetectorServer,
# removes old server from respawn, sets up new lnked server to respawn
# programs fpga, reboots
# older versions: v5.0.0 - 6.0.0 using tftp from tftp folder of pc
sls_detector_put update gotthard2DetectorServervxxx pcxxx xxx.rbf
# v6.1.1 - present (copies server from the full path provided)
sls_detector_put update gotthard2DetectorServervxxx xxx.rbf
# Or only program firmware
sls_detector_put programfpga xxx.rbf
.. note ::
If the detector servers did not start up automatically after reboot, you need to add scripts to do that. See :ref:`Automatic start<Automatic start servers>` for more details.
Moench
-------
Download
^^^^^^^^^^^^^
- detector server corresponding to package in slsDetectorPackage/serverBin
- `pof files <https://github.com/slsdetectorgroup/slsDetectorFirmware>`__
Upgrade
^^^^^^^^
.. warning ::
In case you have had issues in the past with programming via software:
* 6.1.2 server has a fix for seamless fpga programming
* We recommend first updating the on-board detector server to 6.1.2 (with client 6.1.x) using command `updatedetectorserver <commandline.html#term-updatedetectorserver-server_name-with-full-path>`_.
* Then use command 'programfpga' to only update firmware or use command 'update' to update firmware and server to the latest release.
Check :ref:`firmware troubleshooting <blackfin firmware troubleshooting>` if you run into issues while programming firmware.
Program from console
.. code-block:: bash
# Always ensure that the client and server software are of the same release.
# copies server, links new server to moenchDetectorServer,
# removes old server from respawn, sets up new lnked server to respawn
# programs fpga, reboots
# older versions: v5.0.0 - 6.0.0 using tftp from tftp folder of pc
sls_detector_put update moenchDetectorServervxxx pcxxx xx.pof
# v6.1.1 - present (copies server from the full path provided)
sls_detector_put update moenchDetectorServervxxx xx.pof
# Or only program firmware
sls_detector_put programfpga xxx.pof
Ctb
----
Download
^^^^^^^^^^^^^
- detector server corresponding to package in slsDetectorPackage/serverBin
- `pof files <https://github.com/slsdetectorgroup/slsDetectorFirmware>`__
Upgrade
^^^^^^^^
Check :ref:`firmware troubleshooting <blackfin firmware troubleshooting>` if you run into issues while programming firmware.
Program from console
.. code-block:: bash
# Always ensure that the client and server software are of the same release.
# copies server, links new server to ctbDetectorServer,
# removes old server from respawn, sets up new lnked server to respawn
# programs fpga, reboots
# older versions: v5.0.0 - 6.0.0 using tftp from tftp folder of pc
sls_detector_put update ctbDetectorServervxxx pcxxx xx.pof
# v6.1.1 - present (copies server from the full path provided)
sls_detector_put update ctbDetectorServervxxx xx.pof
# Or only program firmware
sls_detector_put programfpga xxx.pof
.. _blackfin firmware troubleshooting:
Firmware Troubleshooting with blackfin
----------------------------------------
1. v4.x.x client after programming will most likely reboot the blackfin processor, regardless of error.
2. v5.x.x-rcx client after programming will not reboot the blackfin processor, if error occurred.
3. If a reboot occured with an incomplete firmware in flash, the blackfin will most likely not find the mtd3 drive. To see if this drive exists:
.. code-block:: bash
# connect to the board
telnet bchipxxx
# view of mtd3 existing
root:/> more /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "bootloader(nor)"
mtd1: 00100000 00020000 "linux kernel(nor)"
mtd2: 002c0000 00020000 "file system(nor)"
mtd3: 01000000 00010000 "bitfile(spi)"
4. If one can see the mtd3 drive, one can already try to flash again using the **programfpga** command (without rebooting blackfin or detector).
5. If one can't list it, read the next section to try to get the blackfin to list it.
How to get back mtd3 drive remotely (udpating kernel)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You have 2 alternatives to update the kernel.
1. Commands via software (>= v6.0.0)
.. code-block:: bash
sls_detector_put updatekernel /home/...path-to-kernel-image
2. or command line
.. code-block:: bash
# step 1: get the kernel image (uImage.lzma) from slsdetectorgroup
# and copy it to pc's tftp folder
# step 2: connect to the board
telnet bchipxxx
#step 3: go to directory for space
cd /var/tmp/
# step 3: copy kernel to board
tftp pcxxx -r uImage.lzma -g
# step 4: verify kernel copied properly
ls -lrt
# step 5: erase flash
flash_eraseall /dev/mtd1
# step 6: copy new image to kernel drive
cat uImage.lzma > /dev/mtd1
# step 7:
sync
# step 8:
reboot
# step 9: verification
telnet bchipxxx
uname -a # verify kernel date
more /proc/mtd # verify mtd3 is listed

91
10.0.0/_sources/hdf5fileformat.rst.txt Normal file
View File

@@ -0,0 +1,91 @@
.. _hdf5 file format:
HDF5 File Format
================================
Compilation
-------------
#. Compile the package with HDF5 option enabled
#. Using cmk script: ./cmk.sh -hj9 -d [path of hdf5 dir] (-d is optional and for custom installation folder)
#. Enable using cmake option **-DSLS_USE_HDF5=ON** and **-DCMAKE_INSTALL_PREFIX=/path/to/custom/hdf/installation** (optional).
Setup
-------
#. Start Receiver process
#. Load config file
#. Set file format using command `fformat <commandline.html#term-fformat-binary-hdf5>`_.
.. code-block:: bash
sls_detector_put fformat hdf5
Master File
-------------
* File Name: [fpath]/[fname]_master_[findex].h5 :ref:`Details here<file name format>`
* It contains :ref:`attributes<master file attributes>` relevant to the acquisition. This can vary with detector type.
.. code-block:: text
/ # Root level
|---> entry # entry group
| |---> data # data group
| |---> column # dataset of each sls_receiver_header member
| |---> data
| |---> detector header version
| |---> detector specific 1
| |---> detector specific 2
| |---> detector specific 3
| |---> detector specific 4
| |---> detector type
| |---> exp length or sub exposure time
| |---> frame number
| |---> mod id
| |---> packets caught
| |---> packets caught bit mask
| |---> row
| |---> timestamp
| |---> instrument # instrument group
| |---> beam # beam group
| |---> detector # detector group
| |---> Master File Attribute 1 # dataset of each master file attribute
| |---> Master File Attribute 2
| |---> Master File Attribute 3
| |---> Master File Attribute ..
| |---> sample # sample group
If more than 1 data file per frame:
* The dataset of each :ref:`**SLS Receiver Header** <sls receiver header format>` member is a virtual dataset.
* **data** dataset is a virtual dataset.
More details regarding master file attributes can be found :ref:`here<master file attributes>`.
Data File
-----------
* File Name: [fpath]/[fname]_dx_fy_[findex].h5 :ref:`Details here<file name format>`
* More details on :ref:`slsReceiverHeader<sls receiver header format>` and the actual image data is described in the :ref:`Detector Image Size and Format <data format>` section.
Virtual Data File
------------------
* File Name: [fpath]/[fname]_virtual_[findex].h5 :ref:`Details here<file name format>`
* For multiple modules, a virtual file linking data from all the modules is created. The individual files are expected to be present.
* It is linked in the master file.

126
10.0.0/_sources/index.rst.txt Normal file
View File

@@ -0,0 +1,126 @@
.. slsDetectorPackage documentation master file, created by
sphinx-quickstart on Mon Jul 29 17:38:15 2019.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
slsDetectorPackage
==============================================
.. toctree::
:maxdepth: 3
:caption: Installation:
installation
dependencies
consuming
.. toctree::
:caption: how to
:maxdepth: 2
softwarearchitecture
configcommands
quick_start_guide
dataformat
multidet
.. toctree::
:caption: C++ API
:maxdepth: 2
detector
result
receiver_api
examples
.. toctree::
:caption: Python API
:maxdepth: 2
pygettingstarted
pydetector
pyenums
pyexamples
pyPatternGenerator
pattern
.. toctree::
:caption: Command line
:maxdepth: 1
commandline
.. toctree::
:caption: Developer
container_utils
type_traits
ToString
.. toctree::
:caption: Firmware
:maxdepth: 2
firmware
.. toctree::
:caption: Detector Server
:maxdepth: 2
servers
serverupgrade
virtualserver
serverdefaults
.. toctree::
:caption: Detector UDP Header
:maxdepth: 2
udpheader
udpconfig
udpdetspec
.. toctree::
:caption: Receiver
:maxdepth: 2
slsreceiver
receivers
.. toctree::
:caption: Receiver Files
:maxdepth: 3
fileformat
slsreceiverheaderformat
dataformat
masterfileattributes
binaryfileformat
hdf5fileformat
.. toctree::
:caption: Receiver ZMQ Stream
:maxdepth: 2
zmqjsonheaderformat
.. toctree::
:caption: Troubleshooting
troubleshooting
.. Indices and tables
.. ==================
.. * :ref:`genindex`
.. * :ref:`modindex`
.. * :ref:`search`

399
10.0.0/_sources/installation.rst.txt Normal file
View File

@@ -0,0 +1,399 @@
.. _Installation:
Installation
===============
.. contents::
:local:
:depth: 2
:backlinks: top
Overview
--------------
The ``slsDetectorPackage`` provides core detector software implemented in C++, along with Python bindings packaged as the ``slsdet`` Python extension module. Choose the option that best fits your environment and use case.
:ref:`conda pre-built binaries`:
Install pre-built binaries for the C++ client, receiver, GUI and the Python API (``slsdet``), simplifying setup across platforms.
:ref:`pip`:
Install only the Python extension module, either by downloading the pre-built library from PyPI or by building the extension locally from source. Available only from v9.2.0 onwards.
:ref:`build from source`:
Compile the entire package yourself, including both the C++ core and the Python bindings, for maximum control and customization. However, make sure that you have the :doc:`dependencies <../dependencies>` installed. If installing using conda, conda will manage the dependencies. Avoid installing packages with pip and conda simultaneously.
.. _conda pre-built binaries:
1. Install pre-built binaries using conda (Recommended)
--------------------------------------------------------
Conda is not only useful to manage python environments but can also
be used as a user space package manager. Dates in the tag (for eg. 2020.07.23.dev0)
are from the developer branch. Please use released tags for stability.
We have four different packages available:
============== =============================================
Package Description
============== =============================================
slsdetlib shared libraries and command line utilities
slsdetgui GUI
slsdet Python bindings
moenchzmq moench
============== =============================================
.. code-block:: bash
#Add channels for dependencies and our library
conda config --add channels conda-forge
conda config --add channels slsdetectorgroup
conda config --set channel_priority strict
#create and activate an environment with our library
#replace 6.1.1 with the required tag
conda create -n myenv slsdetlib=6.1.1
conda activate myenv
#ready to use
sls_detector_get exptime
...
.. code-block:: bash
#List available versions
# lib and binaries
conda search slsdetlib
# python
conda search slsdet
# gui
conda search slsdetgui
# moench
conda search moenchzmq
.. _pip:
2. Pip
-------
The Python extension module ``slsdet`` can be installed using pip. This is available from v9.2.0 onwards.
.. code-block:: bash
#Install the Python extension module from PyPI
pip install slsdet
# or install the python extension locally from source
git clone https://github.com/slsdetectorgroup/slsDetectorPackage.git --branch 9.2.0
cd slsDetectorPackage
pip install .
.. _build from source:
3. Build from source
-------------------------
3.1. Download Source Code from github
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: bash
git clone https://github.com/slsdetectorgroup/slsDetectorPackage.git --branch 6.1.1
.. note ::
For v6.x.x of slsDetectorPackage and older, refer :ref:`pybind11 notes on cloning. <pybind for different slsDetectorPackage versions>`
.. _build from source using cmake:
3.2. Build from Source
^^^^^^^^^^^^^^^^^^^^^^^^^^
One can either build using cmake or use the in-built cmk.sh script.
3.2.1. Build using CMake
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: bash
# outside slsDetecorPackage folder
mkdir build && cd build
# configure & generate Makefiles using cmake by listing all your options
# (alternately use ccmake described below)
# cmake3 instead of cmake for some systems
# eg. enable gui option (without conda)
cmake ../slsDetectorPacakge -DSLS_USE_GUI=ON
# eg. enable python from virtual env, hdf5 and simulator options
cmake ../slsDetectorPackage -DSLS_USE_PYTHON=ON -DPython_FIND_VIRTUALENV=ONLY -DSLS_USE_HDF5=ON -DSLS_USE_SIMULATOR=ON
# compiled to the build/bin directory
make -j12 #or whatever number of cores you are using to build
To install in a clean custom directory and to use the slsDetectorPackage
libraries and headers in your project, specify the install directory
(eg. /your/install/path).
.. code-block:: bash
# outside slsDetecorPackage folder
mkdir build && cd build
# configure & generate Makefiles
cmake ../slsDetectorPackage -DCMAKE_INSTALL_PREFIX=/your/install/path
# compile
make -j12
# install headers and libs in /your/install/path directory
make install
.. note ::
Please refer to `api examples <https://github.com/slsdetectorgroup/api-examples>`__
on how to compile your project using the installed headers and libs.
Instead of the cmake command, one can use ccmake to get a list of options to configure and generate Makefiles at ease.
.. code-block:: bash
# ccmake3 for some systems
ccmake ..
# choose the options
# first press [c] - configure (until you see [g])
# then press [g] - generate
=============================== ===============================
Example cmake options Comment
=============================== ===============================
-DSLS_USE_PYTHON=ON Python
-DPython_FIND_VIRTUALENV=ONLY Python from the conda env
-DSLS_USE_GUI=ON GUI
-DSLS_USE_HDF5=ON HDF5
-DSLS_USE_SIMULATOR=ON Simulator
=============================== ===============================
.. note ::
For v7.x.x of slsDetectorPackage and older, refer :ref:`zeromq notes for cmake option to hint library location. <zeromq for different slsDetectorPackage versions>`
3.2.2. Build using in-built cmk.sh script
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: bash
The binaries are generated in slsDetectorPackage/build/bin directory.
Usage: $0 [-b] [-c] [-d <HDF5 directory>] [-e] [-g] [-h] [-i]
[-j <Number of threads>] [-k <CMake command>] [-l <Install directory>]
[-m] [-n] [-p] [-r] [-s] [-t] [-u] [-z]
-[no option]: only make
-b: Builds/Rebuilds CMake files normal mode
-c: Clean
-d: HDF5 Custom Directory
-e: Debug mode
-g: Build/Rebuilds gui
-h: Builds/Rebuilds Cmake files with HDF5 package
-i: Builds tests
-j: Number of threads to compile through
-k: CMake command
-l: Install directory
-m: Manuals
-n: Manuals without compiling doxygen (only rst)
-p: Builds/Rebuilds Python API
-r: Build/Rebuilds only receiver
-s: Simulator
-t: Build/Rebuilds only text client
-u: Chip Test Gui
-z: Moench zmq processor
# display all options
./cmk.sh -?
# new build and compile in parallel (recommended basic option):
./cmk.sh -cbj5
# new build, python and compile in parallel:
./cmk.sh -cbpj5
#For rebuilding only certain sections
./cmk.sh -tg #only text client and gui
./cmk.sh -r #only receiver
.. note ::
For v7.x.x of slsDetectorPackage and older, refer :ref:`zeromq notes for cmk script option to hint library location. <zeromq for different slsDetectorPackage versions>`
3.3. Build on old distributions using conda
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If your linux distribution doesn't come with a C++17 compiler (gcc>8) then
it's possible to install a newer gcc using conda and build the slsDetectorPackage
using this compiler
.. code-block:: bash
#Create an environment with the dependencies
conda create -n myenv gxx_linux-64 cmake
conda activate myenv
# outside slsDetecorPackage folder
mkdir build && cd build
cmake ../slsDetectorPackage -DCMAKE_PREFIX_PATH=$CONDA_PREFIX
make -j12
.. note ::
For v7.x.x of slsDetectorPackage and older, refer :ref:`zeromq notes for dependencies for conda. <zeromq for different slsDetectorPackage versions>`
3.4. Build slsDetectorGui (Qt5)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1. Using pre-built binary on conda
.. code-block:: bash
conda create -n myenv slsdetgui=7.0.0
conda activate myenv
2. Using system installation on RHEL7
.. code-block:: bash
yum install qt5-qtbase-devel.x86_64
yum install qt5-qtsvg-devel.x86_64
3. Using system installation on RHEL8
.. code-block:: bash
yum install qt5-qtbase-devel.x86_64
yum install qt5-qtsvg-devel.x86_64
yum install expat-devel.x86_64
4. Using conda
.. code-block:: bash
#Add channels for dependencies and our library
conda config --add channels conda-forge
conda config --add channels slsdetectorgroup
conda config --set channel_priority strict
# create environment to compile
# on rhel7
conda create -n slsgui gxx_linux-64 gxx_linux-64 mesa-libgl-devel-cos6-x86_64 qt
# on fedora or newer systems
conda create -n slsgui qt
# when using conda compilers, would also need libgl, but no need for it on fedora unless maybe using it with ROOT
# activate environment
conda activate slsgui
# compile with cmake outside slsDetecorPackage folder
mkdir build && cd build
cmake ../slsDetectorPackage -DSLS_USE_GUI=ON
make -j12
# or compile with cmk.sh
cd slsDetectorPackage
./cmk.sh -cbgj9
.. note ::
For v7.x.x of slsDetectorPackage and older, refer :ref:`zeromq notes for dependencies for conda. <zeromq for different slsDetectorPackage versions>`
3.5. Build this documentation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The documentation for the slsDetectorPackage is build using a combination
of Doxygen, Sphinx and Breathe. The easiest way to install the dependencies
is to use conda
.. code-block:: bash
conda create -n myenv python=3.12 sphinx sphinx_rtd_theme breathe doxygen numpy
.. code-block:: bash
# using cmake or ccmake to enable DSLS_BUILD_DOCS
# outside slsDetecorPackage folder
mkdir build && cd build
cmake ../slsDetectorPackage -DSLS_BUILD_DOCS=ON
make docs # generate API docs and build Sphinx RST
make rst # rst only, saves time in case the API did not change
4. Pybind and Zeromq
-------------------------
.. _pybind for different slsDetectorPackage versions:
| **Pybind11 for Python**
| v8.0.0+:
| pybind11 is built
| * by default from tar file in repo (libs/pybind/v2.1x.0.tar.gz)
| * or use advanced option SLS_FETCH_PYBIND11_FROM_GITHUB [`link <https://github.com/pybind/pybind11>`__].
| * v9.0.0+: pybind11 (v2.13.6)
| * v8.x.x : pybind11 (v2.11.0)
|
| v7.x.x:
| pybind11 packaged into 'libs/pybind'. No longer a submodule. No need for "recursive" or "submodule update".
|
| Older versions:
| pybind11 is a submodule. Must be cloned using "recursive" and updated when switching between versions using the following commands.
.. code-block:: bash
# Note: Only for v6.x.x versions and older
# clone using recursive to get pybind11 submodule
git clone --recursive https://github.com/slsdetectorgroup/slsDetectorPackage.git
# update submodule when switching between releases
cd slsDetectorPackage
git submodule update --init
.. _zeromq for different slsDetectorPackage versions:
| **Zeromq**
| v8.0.0+:
| zeromq (v4.3.4) is built
| * by default from tar file in repo (libs/libzmq/libzmq-4.3.4.tar.gz)
| * or use advanced option SLS_FETCH_ZMQ_FROM_GITHUB [`link <https://github.com/zeromq/libzmq.git>`__].
|
| v7.x.x and older:
| zeromq-devel must be installed and one can hint its location using
| * cmake option:'-DZeroMQ_HINT=/usr/lib64' or
| * option '-q' in cmk.sh script: : ./cmk.sh -cbj5 -q /usr/lib64
| * 'zeromq' dependency added when installing using conda

362
10.0.0/_sources/masterfileattributes.rst.txt Normal file
View File

@@ -0,0 +1,362 @@
.. _master file attributes:
Master File Attributes
=======================
These attributes are the same in binary and HDF5 file, but vary depending on detector type.
Eiger
^^^^^
+-----------------------+-------------------------------------------------+
| **Key** | **Description** |
+-----------------------+-------------------------------------------------+
| Version | Version of the master file |
| | Current value:8.0 |
+-----------------------+-------------------------------------------------+
| Timestamp | Timestamp of creation of master file |
+-----------------------+-------------------------------------------------+
| Detector Type | Detector type |
+-----------------------+-------------------------------------------------+
| Timing Mode | Timing Mode |
+-----------------------+-------------------------------------------------+
| Geometry | Number of UDP ports in x and y dimension for |
| | complete detector |
+-----------------------+-------------------------------------------------+
| Image Size in bytes | Image size in bytes per UDP port |
+-----------------------+-------------------------------------------------+
| Pixels | Number of pixels in x and y dimension |
| | per UDP port |
+-----------------------+-------------------------------------------------+
| Max Frames Per File | Maximum frames per file |
+-----------------------+-------------------------------------------------+
| Frame Discard Policy | Receiever Frame discard policy |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Frame Padding | Receiver Frame padding enable |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Scan Parameters | Scanning mode on detector |
+-----------------------+-------------------------------------------------+
| Total Frames | Total number of frames and triggers expected |
+-----------------------+-------------------------------------------------+
| Receiver Roi | Receiver ROI in file including xmax and ymax |
+-----------------------+-------------------------------------------------+
| Dynamic Range | Bits per pixel |
+-----------------------+-------------------------------------------------+
| Ten Giga | 10GbE enable for data |
+-----------------------+-------------------------------------------------+
| Exptime | Exposure time |
+-----------------------+-------------------------------------------------+
| Period | Period between frames |
+-----------------------+-------------------------------------------------+
| Threshold Energy | Threshold energy |
+-----------------------+-------------------------------------------------+
| Sub Exptime | Sub exposure time in 32 bit mode |
+-----------------------+-------------------------------------------------+
| Sub Period | Sub period between frames in 32 bit mode |
+-----------------------+-------------------------------------------------+
| Quad | Quad enable (hardware) |
+-----------------------+-------------------------------------------------+
| Number of rows | Number of rows enabled for readout |
+-----------------------+-------------------------------------------------+
| Rate Corrections | Rate Corrections |
+-----------------------+-------------------------------------------------+
| Frames in File | Number of frames written to file by Receiver 0 |
+-----------------------+-------------------------------------------------+
| Frame Header Format | Expected frame header format for the data files |
+-----------------------+-------------------------------------------------+
Jungfrau
^^^^^^^^
+-----------------------+-------------------------------------------------+
| **Key** | **Description** |
+-----------------------+-------------------------------------------------+
| Version | Version of the master file |
| | Current value:8.0 |
+-----------------------+-------------------------------------------------+
| Timestamp | Timestamp of creation of master file |
+-----------------------+-------------------------------------------------+
| Detector Type | Detector type |
+-----------------------+-------------------------------------------------+
| Timing Mode | Timing Mode |
+-----------------------+-------------------------------------------------+
| Geometry | Number of UDP ports in x and y dimension for |
| | complete detector |
+-----------------------+-------------------------------------------------+
| Image Size in bytes | Image size in bytes per UDP port |
+-----------------------+-------------------------------------------------+
| Pixels | Number of pixels in x and y dimension |
| | per UDP port |
+-----------------------+-------------------------------------------------+
| Max Frames Per File | Maximum frames per file |
+-----------------------+-------------------------------------------------+
| Frame Discard Policy | Receiever Frame discard policy |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Frame Padding | Receiver Frame padding enable |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Scan Parameters | Scanning mode on detector |
+-----------------------+-------------------------------------------------+
| Total Frames | Total number of frames and triggers expected |
+-----------------------+-------------------------------------------------+
| Receiver Roi | Receiver ROI in file including xmax and ymax |
+-----------------------+-------------------------------------------------+
| Exptime | Exposure time |
+-----------------------+-------------------------------------------------+
| Period | Period between frames |
+-----------------------+-------------------------------------------------+
| Number of UDP | Number of UDP Interfaces enabled per module |
| Interfaces | |
+-----------------------+-------------------------------------------------+
| Number of rows | Number of rows enabled for readout |
+-----------------------+-------------------------------------------------+
| Frames in File | Number of frames written to file by Receiver 0 |
+-----------------------+-------------------------------------------------+
| Frame Header Format | Expected frame header format for the data files |
+-----------------------+-------------------------------------------------+
Gotthard II
^^^^^^^^^^^^
+-----------------------+-------------------------------------------------+
| **Key** | **Description** |
+-----------------------+-------------------------------------------------+
| Version | Version of the master file |
| | Current value:8.0 |
+-----------------------+-------------------------------------------------+
| Timestamp | Timestamp of creation of master file |
+-----------------------+-------------------------------------------------+
| Detector Type | Detector type |
+-----------------------+-------------------------------------------------+
| Timing Mode | Timing Mode |
+-----------------------+-------------------------------------------------+
| Geometry | Number of UDP ports in x and y dimension for |
| | complete detector |
+-----------------------+-------------------------------------------------+
| Image Size in bytes | Image size in bytes per UDP port |
+-----------------------+-------------------------------------------------+
| Pixels | Number of pixels in x and y dimension |
| | per UDP port |
+-----------------------+-------------------------------------------------+
| Max Frames Per File | Maximum frames per file |
+-----------------------+-------------------------------------------------+
| Frame Discard Policy | Receiever Frame discard policy |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Frame Padding | Receiver Frame padding enable |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Scan Parameters | Scanning mode on detector |
+-----------------------+-------------------------------------------------+
| Total Frames | Total number of frames and triggers expected |
+-----------------------+-------------------------------------------------+
| Receiver Roi | Receiver ROI in file including xmax and ymax |
+-----------------------+-------------------------------------------------+
| Exptime | Exposure time |
+-----------------------+-------------------------------------------------+
| Period | Period between frames |
+-----------------------+-------------------------------------------------+
| Burst Mode | Burst mode of detector |
+-----------------------+-------------------------------------------------+
| Frames in File | Number of frames written to file by Receiver 0 |
+-----------------------+-------------------------------------------------+
| Frame Header Format | Expected frame header format for the data files |
+-----------------------+-------------------------------------------------+
Mythen3
^^^^^^^
+-----------------------+-------------------------------------------------+
| **Key** | **Description** |
+-----------------------+-------------------------------------------------+
| Version | Version of the master file |
| | Current value:8.0 |
+-----------------------+-------------------------------------------------+
| Timestamp | Timestamp of creation of master file |
+-----------------------+-------------------------------------------------+
| Detector Type | Detector type |
+-----------------------+-------------------------------------------------+
| Timing Mode | Timing Mode |
+-----------------------+-------------------------------------------------+
| Geometry | Number of UDP ports in x and y dimension for |
| | complete detector |
+-----------------------+-------------------------------------------------+
| Image Size in bytes | Image size in bytes per UDP port |
+-----------------------+-------------------------------------------------+
| Pixels | Number of pixels in x and y dimension |
| | per UDP port |
+-----------------------+-------------------------------------------------+
| Max Frames Per File | Maximum frames per file |
+-----------------------+-------------------------------------------------+
| Frame Discard Policy | Receiever Frame discard policy |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Frame Padding | Receiver Frame padding enable |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Scan Parameters | Scanning mode on detector |
+-----------------------+-------------------------------------------------+
| Total Frames | Total number of frames and triggers expected |
+-----------------------+-------------------------------------------------+
| Receiver Roi | Receiver ROI in file including xmax and ymax |
+-----------------------+-------------------------------------------------+
| Dynamic Range | Bits per pixel |
+-----------------------+-------------------------------------------------+
| Ten Giga | 10GbE enable for data |
+-----------------------+-------------------------------------------------+
| Period | Period between frames |
+-----------------------+-------------------------------------------------+
| Counter Mask | Mask of counters enabled |
+-----------------------+-------------------------------------------------+
| Exptime1 | Exposure time of counter 1 |
+-----------------------+-------------------------------------------------+
| Exptime2 | Exposure time of counter 2 |
+-----------------------+-------------------------------------------------+
| Exptime3 | Exposure time of counter 3 |
+-----------------------+-------------------------------------------------+
| GateDelay1 | Gate delay of counter 1 |
+-----------------------+-------------------------------------------------+
| GateDelay2 | Gate delay of counter 2 |
+-----------------------+-------------------------------------------------+
| GateDelay3 | Gate delay of counter 3 |
+-----------------------+-------------------------------------------------+
| Gates | Number of gates |
+-----------------------+-------------------------------------------------+
| Threshold energies | Threshold energy of all 3 counters |
+-----------------------+-------------------------------------------------+
| Frames in File | Number of frames written to file by Receiver 0 |
+-----------------------+-------------------------------------------------+
| Frame Header Format | Expected frame header format for the data files |
+-----------------------+-------------------------------------------------+
Moench
^^^^^^
+-----------------------+-------------------------------------------------+
| **Key** | **Description** |
+-----------------------+-------------------------------------------------+
| Version | Version of the master file |
| | Current value:8.0 |
+-----------------------+-------------------------------------------------+
| Timestamp | Timestamp of creation of master file |
+-----------------------+-------------------------------------------------+
| Detector Type | Detector type |
+-----------------------+-------------------------------------------------+
| Timing Mode | Timing Mode |
+-----------------------+-------------------------------------------------+
| Geometry | Number of UDP ports in x and y dimension for |
| | complete detector |
+-----------------------+-------------------------------------------------+
| Image Size in bytes | Image size in bytes per UDP port |
+-----------------------+-------------------------------------------------+
| Pixels | Number of pixels in x and y dimension |
| | per UDP port |
+-----------------------+-------------------------------------------------+
| Max Frames Per File | Maximum frames per file |
+-----------------------+-------------------------------------------------+
| Frame Discard Policy | Receiever Frame discard policy |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Frame Padding | Receiver Frame padding enable |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Scan Parameters | Scanning mode on detector |
+-----------------------+-------------------------------------------------+
| Total Frames | Total number of frames and triggers expected |
+-----------------------+-------------------------------------------------+
| Receiver Roi | Receiver ROI in file including xmax and ymax |
+-----------------------+-------------------------------------------------+
| Exptime | Exposure time |
+-----------------------+-------------------------------------------------+
| Period | Period between frames |
+-----------------------+-------------------------------------------------+
| Number of UDP | Number of UDP Interfaces enabled per module |
| Interfaces | |
+-----------------------+-------------------------------------------------+
| Number of rows | Number of rows enabled for readout |
+-----------------------+-------------------------------------------------+
| Frames in File | Number of frames written to file by Receiver 0 |
+-----------------------+-------------------------------------------------+
| Frame Header Format | Expected frame header format for the data files |
+-----------------------+-------------------------------------------------+
Chip Test Board
^^^^^^^^^^^^^^^
+-----------------------+-------------------------------------------------+
| **Key** | **Description** |
+-----------------------+-------------------------------------------------+
| Version | Version of the master file |
| | Current value:8.0 |
+-----------------------+-------------------------------------------------+
| Timestamp | Timestamp of creation of master file |
+-----------------------+-------------------------------------------------+
| Detector Type | Detector type |
+-----------------------+-------------------------------------------------+
| Timing Mode | Timing Mode |
+-----------------------+-------------------------------------------------+
| Geometry | Number of UDP ports in x and y dimension for |
| | complete detector |
+-----------------------+-------------------------------------------------+
| Image Size in bytes | Image size in bytes per UDP port |
+-----------------------+-------------------------------------------------+
| Pixels | Number of pixels in x and y dimension |
| | per UDP port |
+-----------------------+-------------------------------------------------+
| Max Frames Per File | Maximum frames per file |
+-----------------------+-------------------------------------------------+
| Frame Discard Policy | Receiever Frame discard policy |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Frame Padding | Receiver Frame padding enable |
| | for partial frames |
+-----------------------+-------------------------------------------------+
| Scan Parameters | Scanning mode on detector |
+-----------------------+-------------------------------------------------+
| Total Frames | Total number of frames and triggers expected |
+-----------------------+-------------------------------------------------+
| Receiver Roi | Receiver ROI in file including xmax and ymax |
+-----------------------+-------------------------------------------------+
| Exptime | Exposure time |
+-----------------------+-------------------------------------------------+
| Period | Period between frames |
+-----------------------+-------------------------------------------------+
| Ten Giga | Ten giga enable |
+-----------------------+-------------------------------------------------+
| ADC Mask | Mask of channels enabled in ADC |
+-----------------------+-------------------------------------------------+
| Analog Flag | Analog readout enable |
+-----------------------+-------------------------------------------------+
| Analog Samples | Number of analog samples |
+-----------------------+-------------------------------------------------+
| Digital Flag | Digital readout enable |
+-----------------------+-------------------------------------------------+
| Digital Samples | Number of digital samples |
+-----------------------+-------------------------------------------------+
| Dbit Offset | Digital offset of valid data in bytes |
+-----------------------+-------------------------------------------------+
| Dbit Reorder | Reorder such that it groups each signal (0-63) |
| | from all the different samples together |
+-----------------------+-------------------------------------------------+
| Dbit Bitset | Digital 64 bit mask of bits enabled in receiver |
+-----------------------+-------------------------------------------------+
| Transceiver Mask | Mask of channels enabled in Transceiver |
+-----------------------+-------------------------------------------------+
| Transceiver Flag | Transceiver readout enable |
+-----------------------+-------------------------------------------------+
| Transceiver Samples | Number of transceiver samples |
+-----------------------+-------------------------------------------------+
| Frames in File | Number of frames written to file by Receiver 0 |
+-----------------------+-------------------------------------------------+
| Frame Header Format | Expected frame header format for the data files |
+-----------------------+-------------------------------------------------+

230
10.0.0/_sources/multidet.rst.txt Normal file
View File

@@ -0,0 +1,230 @@
.. _using multiple detectors:
Using multiple detectors
==========================
The slsDetectorPackage supports using several detectors on the same computer.
This can either be two users, that need to use the same computer without interfering
with each other, or the same user that wants to use multiple detectors at the same time.
The detectors in turn can consist of multiple modules. For example, a 9M Jungfrau detector
consists of 18 modules which typically are addressed at once as a single detector.
.. note ::
To address a single module of a multi-module detector you can use the module index.
- Command line: :ref:`cl-module-index-label`
- Python: :ref:`py-module-index-label`
Coming back to multiple detectors we have two tools to our disposal:
#. Detector index
#. The SLSDETNAME environment variable
They can be used together or separately depending on the use case.
Detector index
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When configuring a detector you can specify a detector index. The default is 0.
**Command line**
.. code-block:: bash
# Given that we have two detectors (my-det and my-det2) that we want to use,
# we can configure them with different indices.
# Configure the first detector with index 0
$ sls_detector_put hostname my-det
# Set number of frames for detector 0 to 10
$ sls_detector_put frames 10
#
#Configure the second detector with index 1 (notice the 1- before hostname)
$ sls_detector_put 1-hostname my-det2
# Further configuration
...
# Set number of frames for detector 1 to 19
$ sls_detector_put 1-frames 19
# Note that if we call sls_detector_get without specifying the index,
# it will return the configuration of detector 0
$ sls_detector_get frames
10
The detector index is added to the name of the shared memory segment, so in this case
the shared memory segments would be:
.. code-block:: bash
#First detector
/dev/shm/slsDetectorPackage_detector_0
/dev/shm/slsDetectorPackage_detector_0_module_0
#Second detector
/dev/shm/slsDetectorPackage_detector_1
/dev/shm/slsDetectorPackage_detector_1_module_0
**Python**
The main difference between the command line and the Python API is that you set the index
when you create the detector object and you don't have to repeat it for every call.
The C++ API works int the same way.
.. code-block:: python
from slsdet import Detector
# The same can be achieved in Python by creating a detector object with an index.
# Again we have two detectors (my-det and my-det2) that we want to use:
# Configure detector with index 0
d = Detector()
# If the detector has already been configured and has a shared memory
# segment, you can omit setting the hostname again
d.hostname = 'my-det'
#Further configuration
...
# Configure a second detector with index 1
d2 = Detector(1)
d2.hostname = 'my-det2'
d.frames = 10
d2.frames = 19
$SLSDETNAME
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
To avoid interfering with other users on shared PCs it is best to always set the SLSDETNAME environmental variable.
Imagining a fictive user: Anna, we can set SLSDETNAME from the shell before configuring the detector:
**Command line**
.. code-block:: bash
# Set the SLSDETNAME variable
$ export SLSDETNAME=Anna
# You can check that it is set
$ echo $SLSDETNAME
Anna
# Now configures a detector with index 0 and prefixed with the name Anna
# /dev/shm/slsDetectorPackage_detector_0_Anna
$ sls_detector_put hostname my-det
.. tip ::
Set SLSDETNAME in your .bashrc in order to not forget it when opening a new terminal.
**Python**
With python the best way is to set the SLSDETNAME from the command line before starting the python interpreter.
Bash:
.. code-block:: bash
$ export SLSDETNAME=Anna
Python:
.. code-block:: python
from slsdet import Detector
# Now configures a detector with index 0 and prefixed with the name Anna
# /dev/shm/slsDetectorPackage_detector_0_Anna
d = Detector()
d.hostname = 'my-det'
You can also set SLSDETNAME from within the Python interpreter, but you have to be aware that it will only
affect the current process and not the whole shell session.
.. code-block:: python
import os
os.environ['SLSDETNAME'] = 'Anna'
# You can check that it is set
print(os.environ['SLSDETNAME']) # Output: Anna
#Now SLSDETNAME is set to Anna but as soon as you exit the python interpreter
# it will not be set anymore
.. note ::
Python has two ways of reading environment variables: `**os.environ**` as shown above which throws a
KeyError if the variable is not set and `os.getenv('SLSDETNAME')` which returns None if the variable is not set.
For more details see the official python documentation on: https://docs.python.org/3/library/os.html#os.environ
Checking for other detectors
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If using shared accounts on a shared computer (which you anyway should not do), it is good practice to check
if there are other detectors configured by other users before configuring your own detector.
You can do this by listing the files in the shared memory directory `/dev/shm/` that start with `sls`. In this
example we can see that two single module detectors are configured one with index 0 and one with index 1.
SLSDETNAME is set to `Anna` so it makes sense to assume that she is the user that configured these detectors.
.. code-block:: bash
# List the files in /dev/shm that starts with sls
$ ls /dev/shm/sls*
/dev/shm/slsDetectorPackage_detector_0_Anna
/dev/shm/slsDetectorPackage_detector_0_module_0_Anna
/dev/shm/slsDetectorPackage_detector_1_Anna
/dev/shm/slsDetectorPackage_detector_1_module_0_Anna
We also provide a command: user, which gets information about the shared memory segment that
the client points to without doing any changes.
.. code-block:: bash
#in this case 3 simulated Mythen3 modules
$ sls_detector_get user
user
Hostname: localhost+localhost+localhost+
Type: Mythen3
PID: 1226078
User: l_msdetect
Date: Mon Jun 2 05:46:20 PM CEST 2025
Other considerations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The shared memory is not the only way to interfere with other users. You also need to make sure that you are not
using the same:
* rx_tcpport
* Unique combination of udp_dstip and udp_dstport
* rx_zmqport
* zmqport
.. attention ::
The computer that you are using need to have enough resources to run multiple detectors at the same time.
This includes CPU and network bandwidth. Please coordinate with the other users!

122
10.0.0/_sources/pattern.rst.txt Normal file
View File

@@ -0,0 +1,122 @@
Pattern
========================
This is a test and development feature implemented only for Ctb, Xilinx_Ctb and Mythen3.
A pattern is a sequence of 64-bit words which is executed using a clock on the FPGA. Each of the 64 bits is connected to a pin or internal signal of the FPGA. The purpose of a pattern is to provide a way to change these 64 signals with precise timing. Commands run by the detector server could manipulate the same signals as the pattern, but they cannot enforce a change in a specific clock cycle.
**Usage**
A pattern is written to memory on the FPGA using the patword command.
.. code-block::
patword 0x0000 0x000000000000000A
patword 0x0001 0x000000000000000B
patword 0x0002 0x000000000000000C
patword 0x0003 0x000000000000000D
patword 0x0004 0x000000000000000E
The example above writes a five-word pattern into FPGA memory. The first argument is the memory address, the second argument is the content to be written into this address. Before executing a pattern one has to set the address limits of the pattern:
.. code-block::
patlimits 0x0000 0x0004
This instructs the firmware to execute the commands from address 0 to 4 (including 0 and 4). The execution can be started from the pyctbgui or with the commands
.. code-block::
start [Ctb, Xilinx_Ctb]
patternstart [Mythen3]
The maximal number of patword addresses is 8192. However, it is possible to extend the length of the pattern sequence using loops and wait commands. Loops can be configured with the following commands:
.. code-block::
patloop 0 0x0001 0x0003
patnloop 0 7
The first argument of both commands is the ID of the loop. Ctb and Xilinx_Ctb can have 6 loops (ID 0-5), Mythen3 can have 4 loop definitions. The commands above configure the loop with ID 0 to run 7 times and jump from the patword with address 3 to the patword with address 1. Important: If patnloop is set to 1, the addresses 0x1-0x3 will execute exactly once; if it is set to 0, the pattern addresses will be skipped.
The same idea is used to introduce wait times. The example below causes the patword at address 0x0002 to be active for 9 clock cycles before the execution continues.
.. code-block::
patwait 0 0x0002
patwaittime 0 9
Waits can be placed inside a loop and loops can be nested.
**patioctrl**
The function of each bit in the sequence of 64-bit words depends on the connected detector and firmware version. Some of the 64 bits might connect directly to pads of a chip. The patioctrl command is used to configure the direction of some of these signals (not all of them !! See tables below). Signals where the corresponding bit in the argument of patioctrl is set to 1 will be driven from the FPGA.
**patsetbit and patmask**
The functions patsetbit and patmask can be used to ignore a specific bit of the pattern.
Example:
.. code-block::
patmask 0x0101
patsetbit 0x0001
Patmask configures bit 0 and 8 of the pattern to be set to their value in patsetbit. These bits will be ignored during pattern execution and will always be 0 (bit 8) and 1 (bit 0).
The mappings of bit positions in the pattern word to signals/pads of the FPGA are listed below for the three detector types where patterns are used. In the case of the two CTB's, connections of the signals to actual pads of a chip depend on the layout of the used detector adapter board. Therefore, each type of detector adapter board adds an additional mapping layer.
**CTB Pattern Bit Mapping**
.. table::
+----+---+------+----+----------+-------------------+----------------+
| 63 | 62| 61-57| 56 | 55-48 | 47-32 | 31-0 |
+----+---+------+----+----------+-------------------+----------------+
| A | D| --- | T | EXTIO | DO, stream source | DIO |
+----+---+------+----+----------+-------------------+----------------+
DIO: Driving the 32 FPGA pins corresponding to the lowest 32 bits of the patioctrl command. If bits in patioctrl are 0, the same bit positions in DIO will switch to input pins and connect to dbit sampling. Additionally, some of these 32 bits have an automatic override by detector-specific statemachines which is active whenever one of these statemachines is running (currently bits 7,8,11,14 and 20).
DO: Directly connected to 16 FPGA pins. Output only. Not influenced by patioctrl. Also connected to bit 47-32 in all Ctb dbit samples. All of them can be used as dbit sample trigger. In addition, every bit of DO can be selected as trigger for sending out a udp packet with samples to the receiver.
EXTIO: Similar to DIO, but not used as input to the fpga. With the corresponding patioctrl bits set to 0 these pins will switch to a high impedance mode and be ignored by the firmware.
T: trigger output
D: enable signal for digital sampling
A: adc enable
**Xilinx_CTB Pattern Bit Mapping**
.. table::
+-------+----------------+
| 63-32 | 31-0 |
+-------+----------------+
| --- | DIO |
+-------+----------------+
DIO: Driving the 32 FPGA pins corresponding to the lowest 32 bits of the patioctrl command. If bits in patioctrl are 0, the same bit positions in DIO will switch to input pins and connect to dbit sampling. Additionally, some of these 32 bits have an automatic override by detector-specific statemachines which is active whenever these sm's are running (currently bits 7,8,11,14 and 20).
**Mythen3 Pattern Bit Mapping**
.. table::
+-------+--------+-------+--------+------------+----------+----------+-----+-----+
| 63-33 | 32 | 31-25 | 24 | 23 | 22 | 21 | 20 | 19 |
+-------+--------+-------+--------+------------+----------+----------+-----+-----+
| --- | signARD| --- | CHSclk | cnt_rst | sto_rst | STATLOAD | STO | SIN |
+-------+--------+-------+--------+------------+----------+----------+-----+-----+
.. table::
+---------+-----+-------+-------+----+-------+---------+--------+
| 18 | 17 | 16-14 | 13 | 12 | 11 | 10 | 9-0 |
+---------+-----+-------+-------+----+-------+---------+--------+
| SR_MODE | clk | EN | PULSE | RD | CHSIN | ANAMode | TBLOAD |
+---------+-----+-------+-------+----+-------+---------+--------+
For Mythen3 the pattern word only connects to output pins of the FPGA when the pattern is running. Afterwards the signals will switch back to other logic in the FPGA. Both CTB's hold the last executed pattern word until a new pattern is started.

34
10.0.0/_sources/pyPatternGenerator.rst.txt Normal file
View File

@@ -0,0 +1,34 @@
PatternGenerator
=====================================================
Python class to generate patterns for the Chip Test Board.
.. code-block:: python
from slsdet import PatternGenerator
p = PatternGenerator()
p.SB(5)
p.PW()
p.SB(8,9)
p.PW()
p.CB(5)
Created a pattern like this:
.. code-block:: bash
patword 0x0000 0x0000000000000020
patword 0x0001 0x0000000000000320
patword 0x0002 0x0000000000000300
patioctrl 0x0000000000000000
patlimits 0x0000 0x0002
...
.. py:currentmodule:: slsdet
.. autoclass:: PatternGenerator
:members:
:undoc-members:
:show-inheritance:
:inherited-members:

10
10.0.0/_sources/pydetector.rst.txt Normal file
View File

@@ -0,0 +1,10 @@
Detector
=====================================================
.. py:currentmodule:: slsdet
.. autoclass:: Detector
:members:
:undoc-members:
:show-inheritance:
:inherited-members:

89
10.0.0/_sources/pyenums.rst.txt Normal file
View File

@@ -0,0 +1,89 @@
Enums
===========
These enums are defined in slsDetectorDefs in the C++ package and
exposed to Python through pybind11.
::
# Most settings are represented as enums that can be
# explicitly imported
from slsdet import Detector, fileFormat
d = Detector()
d.fformat = fileFormat.BINARY
# Altough not recommended for convenience all enums
# and some other things can be impored using *
from slsdet import *
d.speed = speedLevel.FULL_SPEED
# To list the available enums, use dir()
import slsdet.enums
for enum in dir(slsdet.enums):
# filter out special memebers
if not enum.startswith('_'):
print(enum)
.. py:currentmodule:: slsdet
.. autoclass:: runStatus
:undoc-members:
.. autoclass:: detectorType
:undoc-members:
.. autoclass:: frameDiscardPolicy
:undoc-members:
.. autoclass:: fileFormat
:undoc-members:
.. autoclass:: dimension
:undoc-members:
.. autoclass:: externalSignalFlag
:undoc-members:
.. autoclass:: timingMode
:undoc-members:
.. autoclass:: dacIndex
:undoc-members:
.. autoclass:: detectorSettings
:undoc-members:
.. autoclass:: clockIndex
:undoc-members:
.. autoclass:: speedLevel
:undoc-members:
.. autoclass:: readoutMode
:undoc-members:
.. autoclass:: burstMode
:undoc-members:
.. autoclass:: timingSourceType
:undoc-members:
.. autoclass:: M3_GainCaps
:undoc-members:
.. autoclass:: portPosition
:undoc-members:
.. autoclass:: streamingInterface
:undoc-members:
.. autoclass:: vetoAlgorithm
:undoc-members:
.. autoclass:: gainMode
:undoc-members:

313
10.0.0/_sources/pyexamples.rst.txt Normal file
View File

@@ -0,0 +1,313 @@
Examples
================
Some short examples on how to use slsdet. If something is missing don't hesitate to
open an issue in our our `github repo
<https://github.com/slsdetectorgroup/slsDetectorPackage>`_.
------------------------------------
Setting exposure time
------------------------------------
Setting and reading back exposure time can be done either using a Python
datetime.timedelta, DurationWrapper or by setting the time in seconds.
::
# Set exposure time to 1.2 seconds
>>> d.exptime = 1.2
>>> d.exptime = 5e-07
# Setting exposure time using timedelta (upto microseconds precision)
import datetime as dt
>>> d.exptime = dt.timedelta(seconds = 1.2)
>>> d.exptime = dt.timedelta(seconds = 1, microseconds = 3)
# With timedelta any arbitrary combination of units can be used
>>> t = dt.timedelta(microseconds = 100, seconds = 5.3, minutes = .3)
# using DurationWrapper to set in seconds
>>> from slsdet import DurationWrapper
>>> d.exptime = DurationWrapper(1.2)
# using DurationWrapper to set in ns
>>> t = DurationWrapper()
>>> t.set_count(500)
>>> d.exptime = t
# To set exposure time for individual detector one have to resort
# to the C++ style API.
# Sets exposure time to 1.2 seconds for module 0, 6 and 12
>>> d.setExptime(1.2, [0, 6, 12])
>>> d.setExptime(dt.timedelta(seconds = 1.2), [0, 6, 12])
# to get in seconds
>>> d.period
181.23
# to get in DurationWrapper
>>> d.getExptime()
[sls::DurationWrapper(total_seconds: 181.23 count: 181230000000)]
------------------------------------
Converting numbers to hex
------------------------------------
Python support entering numbers in format by using the 0x prefix. However, when reading
back you will get a normal integer. This can then be converted to a hex string representation
using the built in hex() function.
.. code-block :: python
from slsdet import Detector
>>> d = Detector()
>>> d.patwait0 = 0xaa
>>> d.patwait0
170
# Convert to string
>>> hex(d.patwait0)
'0xaa'
For multiple values one can use a list comprehension to loop over the values.
.. code-block :: python
>>> values = [1,2,3,4,5]
>>> [(v) for v in values]
['0x1', '0x2', '0x3', '0x4', '0x5']
# or to a single string by passing the list to .join
>>> ', '.join([hex(v) for v in values])
'0x1, 0x2, 0x3, 0x4, 0x5'
------------------------
Simple threshold scan
------------------------
Assuming you have set up your detector with exposure time, period, enabled
file writing etc.
.. code-block:: python
from slsdet import Eiger
d = Eiger()
threshold = range(0, 2000, 200)
for th in threshold:
d.vthreshold = th
d.acquire()
If we want to control the shutter of for example, the big X-ray box we can add
this line in our code. It then opens the shutter just before the measurement
and closes is afterwards.
::
with xrf_shutter_open(box, 'Fe'):
for th in threshold:
d.vthreshold = th
d.acquire()
-----------------------
Reading temperatures
-----------------------
::
d.temp
>>
temp_fpga : 43.19°C, 51.83°C
temp_fpgaext : 38.50°C, 38.50°C
temp_10ge : 39.50°C, 39.50°C
temp_dcdc : 42.50°C, 42.50°C
temp_sodl : 39.50°C, 40.50°C
temp_sodr : 39.50°C, 40.50°C
temp_fpgafl : 40.87°C, 37.61°C
temp_fpgafr : 34.51°C, 35.63°C
d.temp.fpga
>> temp_fpga : 40.84°C, 39.31°C
t = d.temp.fpga[0]
t
>> 40.551
t = d.temp.fpga[:]
t
>> [40.566, 39.128]
-----------------------
Non blocking acquire
-----------------------
There are mainly two ways to achieve a non blocking acquire when calling from the Python API. One is to manually start
the detector and the second one is to launch the normal acquire from a different process. Depending on your measurement
it might also be better to run the other task in a seperate process and use acq in the main thread.
But lets start looking at the at the manual way:
::
import time
from slsdet import Detector, runStatus
n_frames = 10
t_exp = 1
# Set exposure time and number of frames
d = Detector()
d.exptime = t_exp
d.frames = n_frames
# Start the measurement
t0 = time.time()
d.startDetector()
d.startReceiver()
# Wait for the detector to be ready or do other important stuff
time.sleep(t_exp * n_frames)
# check if the detector is ready otherwise wait a bit longer
while d.status != runStatus.IDLE:
time.sleep(0.1)
# Stop the receiver after we got the frames
# Detector is already idle so we don't need to stop it
d.stopReceiver()
lost = d.rx_framescaught - n_frames
print(
f"{n_frames} frames of {t_exp}s took {time.time()-t0:{.3}}s with {lost} frames lost "
)
Instead launching d.acq() from a different process is a bit easier since the control of receiver and detector
is handled in the acq call. However, you need to join the process used otherwise a lot of zombie processes would
hang around until the main process exits.
::
import time
from multiprocessing import Process
from slsdet import Detector, runStatus
d = Detector()
#Create a separate process to run acquire in
p = Process(target=d.acquire)
#Start the thread and short sleep to allow the acq to start
p.start()
time.sleep(0.01)
#Do some other work
while d.status != runStatus.IDLE:
print("Working")
time.sleep(0.1)
#Join the process
p.join()
------------------------------
Setting and getting times
------------------------------
::
import datetime as dt
from slsdet import Detector
from slsdet.utils import element_if_equal
d = Detector()
# The simplest way is to set the exposure time in
# seconds by using the exptime property
# This sets the exposure time for all modules
d.exptime = 0.5
# exptime also accepts a python datetime.timedelta (upto microseconds resolution)
t = dt.timedelta(milliseconds = 2.3)
d.exptime = t
# or combination of units
t = dt.timedelta(minutes = 3, seconds = 1.23)
d.exptime = t
# using DurationWrapper to set in seconds
>>> from slsdet import DurationWrapper
>>> d.exptime = DurationWrapper(1.2)
# using DurationWrapper to set in ns
>>> t = DurationWrapper()
>>> t.set_count(500)
>>> d.exptime = t
# exptime however always returns the time in seconds
>>> d.exptime
181.23
# To get back the exposure time for each module
# it's possible to use getExptime, this also returns
# the values as DurationWrapper
>>> d.getExptime()
[sls::DurationWrapper(total_seconds: 181.23 count: 181230000000)]
# In case the values are the same it's possible to use the
# element_if_equal function to reduce the values to a single
# value
>>> t = d.getExptime()
>>> element_if_equal(t)
sls::DurationWrapper(total_seconds: 1.2 count: 1200000000)
--------------
Reading dacs
--------------
::
from slsdet import Detector, Eiger, dacIndex
#using the specialized class
e = Eiger()
>>> e.dacs
========== DACS =========
vsvp : 0 0
vtrim : 2480 2480
vrpreamp : 3300 3300
vrshaper : 1400 1400
vsvn : 4000 4000
vtgstv : 2556 2556
vcmp_ll : 1000 1000
vcmp_lr : 1000 1000
vcal : 0 0
vcmp_rl : 1000 1000
rxb_rb : 1100 1100
rxb_lb : 1100 1100
vcmp_rr : 1000 1000
vcp : 1000 1000
vcn : 2000 2000
vishaper : 1550 1550
iodelay : 650 650
# or using the general class and the list
d = Detector()
for dac in d.daclist:
r = d.getDAC(dac, False)
print(f'{dac.name:10s} {r}')

301
10.0.0/_sources/pygettingstarted.rst.txt Normal file
View File

@@ -0,0 +1,301 @@
Getting Started
==================
--------------------
Which Python?
--------------------
We require at least Python 3.8 and strongly recommended that you don't use the system
Python installation. The examples in this documentation uses `conda
<https://docs.conda.io/en/latest/miniconda.html>`_ since it provides good support
also for non Python packages but there are also other alternatives like, pyenv.
Using something like conda also allows you to quickly switch beteen different Python
environments.
---------------------
Building from Source
---------------------
If you are not installing slsdet binaries from conda, but instead building from
source, please refer to :ref:`the installation section<Installation>` for details.
Don't forget to compile with the option SLS_USE_PYTHON=ON to enable the Python
bindings or if you use the cmk.sh script -p.
.. note ::
Ensure that the sls det python lib compiled is for the expected python version.
For example, build/bin/_slsdet.cpython-39-x86_64-linux-gnu.so for Python v3.9.x
---------------------
PYTHONPATH
---------------------
If you install slsdet binaries using conda everything is set up and you can
directly start using the Python bindings. However, if you build
from source you need to tell Python where to find slsdet to use it. This
can be done by adding your build/bin directory to PYTHONPATH.
.. code-block:: bash
export PYTHONPATH = /path/to/your/build/bin:$PYTHONPATH
--------------------------------------
Which detector class should I use?
--------------------------------------
We provide a generic class called Detector and detector specific
versions like, Eiger, Jungfrau etc. The most or all functionality
is there in the base class except the convenient access to dacs
and temperatures.
::
from slsdet import Detector, Eiger
d = Detector()
e = Eiger()
# Both classes can be used to control an Eiger detector
d.exptime = 0.5
e.period = 1
# But Eiger gives a simpler interface to the dacs
>>> e.dacs
========== DACS =========
vsvp : 0
vtrim : 2480
vrpreamp : 3300
vrshaper : 1400
vsvn : 4000
vtgstv : 2556
vcmp_ll : 1000
vcmp_lr : 1000
vcal : 0
vcmp_rl : 1000
rxb_rb : 1100
rxb_lb : 1100
vcmp_rr : 1000
vcp : 1000
vcn : 2000
vishaper : 1550
iodelay : 650
.. note ::
Depending on user feedback we might move some detector specific
functionality to the specialized classes.
----------------------------------
Hey, there seems to be two APIs?
----------------------------------
To make the Python API approachable, both if you come from the command line
or are using the C++ API, we provide two interfaces to the detector.
One is property based and tries to stay as close to the command line syntax
as is possible, and the other one directly maps the C++ API found in Detector.h.
There is also an underlying design reason for the two APIs since we auto
generate the bindings to the C++ code using a mix of pybind11 and clang-tools.
The property based API covers most of the functionality but in some cases
you have to reach for the C++ like interface.
::
d = Detector()
# C++ like API
d.setExptime(0.1)
# or a bit more pythonic
d.exptime = 0.1
The c++ style API offers more control over access to individual modules
in a large detector.
::
# Set exposure time for module 1, 5 and 7
d.setExptime(0.1, [1,5,7])
.. _py-module-index-label:
----------------------------------
Accessing individual modules
----------------------------------
Using the C++ like API you can access individual modules in a large detector
by passing in the module index as an argument to the function.
::
# Read the UDP destination port for all modules
>>> d.getDestinationUDPPort()
[50001, 50002, 50003]
# Read it for module 0 and 1
>>> d.getDestinationUDPPort([0, 1])
[50001, 50002]
>>> d.setDestinationUDPPort(50010, 1)
>>> d.getDestinationUDPPort()
[50001, 50010, 50003]
From the more pythonic API there is no way to read from only one module but you can read
and then use list slicing to get the values for the modules you are interested in.
::
>>> d.udp_dstport
[50001, 50010, 50003]
>>> d.udp_dstport[0]
50001
#For some but not all properties you can also pass in a dictionary with module index as key
>>> ip = IpAddr('127.0.0.1')
>>> d.udp_dstip = {1:ip}
--------------------
Finding functions
--------------------
To find out which properties and methods that a Python object have you
can use dir()
::
>>> from slsdet import Detector
>>> d = Detector()
>>> dir(d)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__',
'__eq__', '__format__', '__ge__', '__getattribute__', '__gt__',
'__hash__', '__init__', '__init_subclass__', '__le__', '__len__',
'__lt__', '__module__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
'__str__', '__subclasshook__', '_adc_register', '_frozen',
'_register', 'acquire', 'adcclk', 'adcphase', 'adcpipeline',
'adcreg', 'asamples', 'auto_comp_disable', 'clearAcquiringFlag',
'clearBit', 'clearROI', 'client_version', 'config',
'counters', 'daclist', 'dacvalues', 'dbitclk', 'dbitphase' ...
Since the list for Detector is rather long it's an good idea to filter it.
The following example gives you properties and methods containing time in
their name.
::
>>> [item for item in dir(d) if 'time' in item]
['compdisabletime', 'exptime', 'exptimel', 'frametime', 'getExptime',
'getExptimeForAllGates', 'getExptimeLeft', 'getSubExptime', 'patwaittime',
'patwaittime0', 'patwaittime1', 'patwaittime2', 'runtime', 'setExptime',
'setSubExptime', 'subdeadtime', 'subexptime']
The above method works on any Python object but for convenience we also
included two functions to find names. View prints the names one per line
while find returns a list of names.
::
from slsdet.lookup import view, find
>>> view('exptime')
exptime
exptimel
getExptime
getExptimeForAllGates
getExptimeLeft
getSubExptime
setExptime
setSubExptime
subexptime
>>> find('exptime')
['exptime', 'getExptime', 'getExptimeForAllGates', 'getExptimeLeft',
'getSubExptime', 'setExptime', 'setSubExptime', 'subexptime']
------------------------------------
Finding out what the function does
------------------------------------
To access the documentation of a function directly from the Python prompt use help().
.. code-block :: python
>>> help(Detector.period)
Help on property:
Period between frames, accepts either a value in seconds or datetime.timedelta
Note
-----
:getter: always returns in seconds. To get in DurationWrapper, use getPeriod
Example
-----------
>>> # setting directly in seconds
>>> d.period = 1.05
>>>
>>> # setting directly in seconds
>>> d.period = 5e-07
>>>
>>> # using timedelta (up to microseconds precision)
>>> from datatime import timedelta
>>> d.period = timedelta(seconds = 1, microseconds = 3)
>>>
>>> # using DurationWrapper to set in seconds
>>> from slsdet import DurationWrapper
>>> d.period = DurationWrapper(1.2)
>>>
>>> # using DurationWrapper to set in ns
>>> t = DurationWrapper()
>>> t.set_count(500)
>>> d.period = t
>>>
>>> # to get in seconds
>>> d.period
181.23
>>>
>>> d.getExptime()
[sls::DurationWrapper(total_seconds: 181.23 count: 181230000000)]
----------------------
Where are the ENUMs?
----------------------
To set some of the detector settings like file format you have
to pass in an enum.
::
>>> d.setFileFormat(fileFormat.BINARY)
The enums can be found in slsdet.enums
::
import slsdet
>>> [e for e in dir(slsdet.enums) if not e.startswith('_')]
['M3_GainCaps', 'burstMode', 'clockIndex', 'cls', 'dacIndex', 'detectorSettings',
'detectorType', 'dimension', 'externalSignalFlag', 'fileFormat',
'frameDiscardPolicy', 'gainMode', 'name', 'polarity', 'portPosition',
'readoutMode', 'runStatus', 'speedLevel', 'streamingInterface', 'timingMode',
'timingSourceType', 'vetoAlgorithm']
# Even though importing using * is not recommended one could
# get all the enums like this:
>>> from slsdet.enums import *

171
10.0.0/_sources/quick_start_guide.rst.txt Normal file
View File

@@ -0,0 +1,171 @@
Quick Start Guide
=================
Detector
--------
Start up detector (with cooling if required). Ensure both control server and stop server is running on-board.
Or use a detector simulator to test. Click :ref:`here<Virtual Detector Servers>` for further instructions.
Receiver
--------
| One has to start the slsReceiver before loading config file or using any receiver commands (prefix: **rx_** )
For a Single Module
.. code-block:: bash
# default port 1954
slsReceiver
# custom port 2012
slsReceiver -p 2012
For Multiple Modules
.. code-block:: bash
# slsMultiReceiver [-p: starting port, -n: number of receivers]
slsMultiReceiver -p 2012 -n 2
Client
------
Refer :ref:`Sample Config file` to create config file.
.. code-block:: bash
# load config file
sls_detector_put config /path/sample.config
# set number of frames
sls_detector_put frames 5
# acquire
sls_detector_acquire
.. _Sample Config file:
Sample Config file
^^^^^^^^^^^^^^^^^^
There are sample config files for each detector in slsDetectorPackage/examples folder.
For a Single Module
.. code-block:: bash
# connects to module
hostname bchipxxx
# connects to receiver at default port
rx_hostname mpc1922
# or to connect to specific port
# rx_hostname mpc1922:2012
# sets destination udp ports (not needed, default is 50001)
udp_dstport 50012
# 1g data out
# source udp ips must be same subnet at destintaion udp ips
# udp_srcip 192.168.1.112
# destination udp ip picked up from rx_hostname (if auto)
# udp_dstip auto
# 10g data out
udp_srcip 10.30.20.200
udp_dstip 10.30.20.6
# set file path
fpath /tmp
For a Single Module with custom Receiver (not slsReceiver)
.. code-block:: bash
# connects to module
hostname bchipxxx
# sets destination udp ports (not needed, default is 50001)
udp_dstport 50012
# source udp ips must be same subnet at destintaion udp ips
udp_srcip 192.168.1.112
# destination udp ip
udp_dstip 192.168.1.100
# source udp mac
udp_srcmac aa:bb:cc:dd:ee:ff
# destination udp mac
udp_dstmac 3c:ab:98:bf:50:60
# set file path
fpath /tmp
For Multiple Modules
.. code-block:: bash
# connects to mulitple modules
hostname bchipxxx+bchipyyy+
# tcp port increases for each module (multi detector command)
rx_tcpport 2012
# connects to receivers at ports 2012 and 2014
rx_hostname mpc1922
# increasing udp ports (multi detector command)
udp_dstport 50012
# source udp ips must be same subnet at destintaion udp ips
0:udp_srcip 192.168.1.112
1:udp_srcip 192.168.1.114
# destination udp ip picked up from rx_hostname (if auto)
udp_dstip auto
# set file path
fpath /tmp
.. note ::
The **hostname** and **detsize** command in a multi module system can affect the row and column values in the udp/zmq header. The modules are stacked row by row until they reach the y-axis limit set by detsize (if specified). Then, stacking continues in the next column and so on.
Data
-----
Check out the :ref:`UDP header section<detector udp header>` for details on output UDP header data format.`
Check out the :ref:`Detector image size and format section<data format>` for details on output data format.
Receiver
---------
When using `slsReceiver`, `slsMultiReceiver` or `slsFrameSynchronizer`, check out the following sections:
- :ref:`File format<file format>`
- :ref:`slsReceiver header format<sls receiver header format>`
- :ref:`Master file attributes<master file attributes>`
Gui
----
Compile with SLS_USE_GUI=ON in cmake or -g option in cmk.sh script. One can also just use the conda binary. Refer :ref:`installation instructions<Installation>`.
.. code-block:: bash
slsDetectorGui
.. note ::
| The streaming high water mark (commmand: rx_zmqhwm) and the receiving high water mark (command: zmqhwm) is by default the lib zmq's default (currently 1000).
| At Gui startup, these values are set to 2. Hence, for very fast detectors, many frames will be dropped to be able to view the latest in the gui.
| One can still change this setting in the gui in the Plot tab (ZMQ Streaming), from the command line or API.
| Both hwm's can be set to a -1 to use the lib's default.
| Since the dummy end of acquisition packet streamed from receiver might also be lost, receiver restreams until gui acknowledges.

6
10.0.0/_sources/receiver_api.rst.txt Normal file
View File

@@ -0,0 +1,6 @@
Receiver
==============================================
.. doxygenclass:: sls::Receiver
:members:
.. :undoc-members:

38
10.0.0/_sources/receivers.rst.txt Normal file
View File

@@ -0,0 +1,38 @@
Custom Receiver
=================
The receiver essentially listens to UDP data packets sent out by the detector.
To know more about detector receiver setup in the config file, please check out :ref:`the detector-receiver UDP configuration in the config file<detector udp header config>` and the :ref:`detector udp format<detector udp header>`.
| Please note the following when using a custom receiver:
* **udp_dstmac** must be configured in the config file. This parameter is not required when using an in-built receiver.
* Cannot use "auto" for **udp_dstip**.
* No **rx_** commands in the config file. These commands are for configuring the slsReceiver.
The main difference is the lack of **rx_** commands or file commands (eg. **f**write, **f**path) and the **udp_dstmac** is required in config file.
Example of a custom receiver config file
.. code-block:: bash
# detector hostname
hostname bchip052
# udp destination port (receiver)
udp_dstport 50004
# udp destination ip (receiver)
udp_dstip 10.0.1.100
# udp source ip (same subnet as udp_dstip)
udp_srcip 10.0.1.184
# udp destination mac
udp_dstmac 22:47:d5:48:ad:ef

6
10.0.0/_sources/result.rst.txt Normal file
View File

@@ -0,0 +1,6 @@
.. _Result Class:
Result
==============================================
.. doxygenfile:: Result.h

91
10.0.0/_sources/serverdefaults.rst.txt Normal file
View File

@@ -0,0 +1,91 @@
Default Values
==============================================
Mythen3
-------------
.. csv-table:: Default values
:file: mythen3.csv
:widths: 35, 35
:header-rows: 1
DACS
^^^^^^^^^^^^^
.. csv-table:: Mythen3 DACS
:file: mythen3-dacs.csv
:widths: 35, 35
:header-rows: 1
Gotthard2
-------------
.. csv-table:: Default values
:file: gotthard2.csv
:widths: 35, 35
:header-rows: 1
DACS
^^^^^^^^^^^^^
.. csv-table:: Gotthard 2 DACS
:file: gotthard2-dacs.csv
:widths: 35, 35
:header-rows: 1
Moench
-------------
.. csv-table:: Default values
:file: moench.csv
:widths: 35, 35
:header-rows: 1
DACS
^^^^^^^^^^^^^
.. csv-table:: Moench DACS
:file: moench-dacs.csv
:widths: 35, 35
:header-rows: 1
Ctb
-------------
.. csv-table:: Default values
:file: ctb.csv
:widths: 35, 35
:header-rows: 1
Eiger
-------------
.. csv-table:: Default values
:file: eiger.csv
:widths: 35, 35
:header-rows: 1
DACS
^^^^^^^^^^^^^
.. csv-table:: Eiger DACS
:file: eiger-dacs.csv
:widths: 35, 35
:header-rows: 1
Jungfrau
-------------
.. csv-table:: Default values
:file: jungfrau.csv
:widths: 35, 35
:header-rows: 1
DACS
^^^^^^^^^^^^^
.. csv-table:: Jungfrau DACS
:file: jungfrau-dacs.csv
:widths: 35, 35
:header-rows: 1

100
10.0.0/_sources/servers.rst.txt Normal file
View File

@@ -0,0 +1,100 @@
.. _detector_servers:
Getting Started
===============
Detector Servers include:
* Control server [default port: 1952]
* Almost all client communication.
* Stop server [default port: 1953]
* Client requests for detector status, stop acquisition, temperature, advanced read/write registers.
When using a blocking acquire command (sls_detector_acquire or Detector::acquire), the control server is blocked until end of acquisition. However, stop server commands could be used in parallel.
Location
---------
slsDetectorPackage/serverBin/ folder in every release.
.. _Detector Server Arguments:
Arguments
---------
.. code-block:: bash
Possible arguments are:
-v, --version : Software version
-p, --port <port> : TCP communication port with client.
-g, --nomodule : [Mythen3][Gotthard2]
Generic or No Module mode. Skips detector type checks.
-d, --devel : Developer mode. Skips firmware checks.
-u, --update : Update mode. Skips firmware checks and initial detector setup.
-i, --ignore-config : [Eiger][Jungfrau][Gotthard2][Moench]
Ignore config file.
-m, --master <master> : [Eiger][Mythen3][Gotthard2]
Set Master to 0 or 1. Precedence over config file. Only for virtual servers except Eiger.
-t, --top <top> : [Eiger] Set Top to 0 or 1. Precedence over config file.
-s, --stopserver : Stop server. Do not use as it is created by control server
.. _Automatic start servers:
Automatic start
------------------
One can start the on-board detector server automatically upon powering on the board.
#. Create a soft link to the binary on board:
.. code-block:: bash
ln -sf someDetectorServervx.x.x someDetectorServer
#. Do the following depending on the detector type :
Eiger
.. code-block:: bash
# create script in rc5.d on the board
vi /etc/rc5.d/S50board_com.sh
# enter the following (edit server name)
#! /bin/sh
/home/root/executables/eigerDetectorServer &> /dev/null &
exit 0
Jungfrau | Moench | CTB
.. code-block:: bash
# Edit inittab on board
vi /etc/inittab
# enter the following line
ttyS0::respawn:/./xxxDetectorServer
Gotthard II | Mythen III
.. code-block:: bash
# create script in init.d on board
vi /etc/init.d/S99detServer.sh
# enter the following (edit server name)
#! /bin/sh
cd /root >> /dev/null
/root/xxxDetectorServer >> /dev/null &
#. Sync, reboot and verify:
.. code-block:: bash
sync
# physically reboot for Gotthard II or Mythen III
reboot
# verify
ps -ef | grep xxxDetectorServer

67
10.0.0/_sources/serverupgrade.rst.txt Normal file
View File

@@ -0,0 +1,67 @@
.. _Detector Server Upgrade:
Upgrade
========
**Location:** slsDetectorPackage/serverBin/ folder for every release.
.. note ::
For Mythen3, Gotthard2 and Eiger, you need to add scripts to automatically start detector server upon power on. See :ref:`Automatic start<Automatic start servers>` for more details.
.. note ::
Eiger requires a manual reboot. Or killall the servers and restart the new linked one. If you are in the process of updating firmware, then don't reboot yet.
6.1.1+ (no tftp required)
---------------------------------------
#. Program from console
.. code-block:: bash
# the following command copies new server, creates a soft link to xxxDetectorServerxxx
# [Jungfrau][CTB][Moench] also deletes the old server binary and edits initttab to respawn server on reboot
# Then, the detector controller will reboot (except Eiger)
sls_detector_put updatedetectorserver /complete-path-to-binary/xxxDetectorServerxxx
#. Copy the detector server specific config files or any others required to the detector:
.. code-block:: bash
sls_detector_put execcommand "tftp pcxxx -r configxxx -g"
5.0.0 - 6.1.1
--------------
#. Install tftp and copy detector server binary to tftp folder
#. Program from console
.. code-block:: bash
# the following command copies new server from pc tftp folder, creates a soft link to xxxDetectorServerxxx
# [Jungfrau][CTB][Moench] also edits initttab to respawn server on reboot
# Then, the detector controller will reboot (except Eiger)
sls_detector_put copydetectorserver xxxDetectorServerxxx pcxxx
#. Copy the detector server specific config files or any others required to the detector:
.. code-block:: bash
sls_detector_put execcommand "tftp pcxxx -r configxxx -g"
Troubleshooting with tftp
^^^^^^^^^^^^^^^^^^^^^^^^^
#. tftp write error: There is no space left. Please delete some old binaries and try again.
#. text file busy: You are trying to copy the same server.
< 5.0.0
--------
Please contact us.

218
10.0.0/_sources/slsreceiver.rst.txt Normal file
View File

@@ -0,0 +1,218 @@
In-built Receiver
================================
The receiver essentially listens to UDP data packets sent out by the detector. It's main features are:
- **Listening**: Receives UDP data from the detector.
- **Writing to File**: Optionally writes received data to disk.
- **Streaming via ZMQ**: Optionally streams out the data using ZeroMQ.
Each of these operations runs asynchronously and in parallel for each UDP port.
.. note ::
* Can be run on the same or different machine as the client.
* Can be configured by the client. (set file name/ discard policy, get progress etc.)
* Has to be started before the client runs any receiver specific command.
Receiver Variants
-----------------
There are three main receiver types. How to start them is described :ref:`below<Starting up the Receiver>`.
+----------------------+--------------------+-----------------------------------------+--------------------------------+
| Receiver Type | slsReceiver | slsMultiReceiver |slsFrameSynchronizer |
+======================+====================+=========================================+================================+
| Modules Supported | 1 | Multiple | Multiple |
+----------------------+--------------------+-----------------------------------------+--------------------------------+
| Internal Architecture| Threads per porttt | Multiple child processes of slsReceiver | Multi-threading of slsReceiver |
+----------------------+--------------------+-----------------------------------------+--------------------------------+
| ZMQ Streaming | Disabled by default| Disabled by default | Enabled, not optional |
+----------------------+--------------------+-----------------------------------------+--------------------------------+
| ZMQ Synchronization | No | No | Yes, across ports |
+----------------------+--------------------+-----------------------------------------+--------------------------------+
| Image Reconstruction | No | No | No |
+----------------------+--------------------+-----------------------------------------+--------------------------------+
.. _Starting up the Receiver:
Starting up the Receiver
-------------------------
.. code-block:: bash
Usage: slsReceiver Options:
-v, --version : Version.
-p, --port : TCP port to communicate with client for configuration. Non-zero and 16 bit.
-u, --uid : Set effective user id if receiver started with privileges.
Usage: slsMultiReceiver Options:
-v, --version : Version.
-n, --num-receivers : Number of receivers.
-p, --port : TCP port to communicate with client for configuration. Non-zero and 16 bit.
-c, --callback : Enable dummy callbacks for debugging. Disabled by default.
-u, --uid : Set effective user id if receiver started with privileges.
Usage: slsFrameSynchronizer Options:
-v, --version : Version.
-n, --num-receivers : Number of receivers.
-p, --port : TCP port to communicate with client for configuration. Non-zero and 16 bit.
-c, --print-headers : Print callback headers for debugging. Disabled by default.
-u, --uid : Set effective user id if receiver started with privileges.
For a Single Module
.. code-block:: bash
slsReceiver # default port 1954
slsReceiver -p 2012 # custom port 2012
For Multiple Modules
.. code-block:: bash
# each receiver (for each module) requires a unique tcp port (if all on same machine)
# option 1 (one for each module)
slsReceiver
slsReceiver -p 1955
# option 2
slsMultiReceiver -p 2012 -n 2
# option 3
slsFrameSynchronizer -p 2012 -n 2
Client Commands
-----------------
* Client commands to the receiver begin with **rx_** or **f_** (file commands).
* **rx_hostname** has to be the first command to the receiver so the client knows which receiver process to communicate with.
* Can use 'auto' for **udp_dstip** if using 1GbE interface or the :ref:`virtual simulators<Virtual Detector Servers>`.
To know more about detector receiver setup in the config file, please check out :ref:`the detector-receiver UDP configuration in the config file<detector udp header config>` and the :ref:`detector udp format<detector udp header>`.
The following are the different ways to establish contact using **rx_hostname** command.
.. code-block:: bash
# ---single module---
# default receiver port at 1954
rx_hostname xxx
# custom receiver port
rx_hostname xxx:1957 # option 1
rx_tcpport 1957 # option 2
rx_hostname xxx
# ---multi module---
# using increasing tcp ports
rx_tcpport 1955
rx_hostname xxx
# custom ports
rx_hostname xxx:1955+xxx:1958+ # option 1
0:rx_tcpport 1954 # option 2
1:rx_tcpport 1955
2:rx_tcpport 1956
rx_hostname xxx
# custom ports on different receiver machines
0:rx_tcpport 1954
0:rx_hostname xxx
1:rx_tcpport 1955
1:rx_hostname yyyrxr
| Example commands:
.. code-block:: bash
# to get a list of receiver commands (these dont include file commands)
sls_detector_get list | grep rx_
# some file commands are:
fwrite
foverwrite
findex
fpath
fname
fmaster
fformat
# to get help on a single commands
sls_detector_get -h rx_framescaught
Example of a config file using in-built receiver
.. code-block:: bash
# detector hostname
hostname bchip052+bchip053+
# udp destination port (receiver)
# sets increasing destination udp ports starting at 50004
udp_dstport 50004
# udp destination ip (receiver)
0:udp_dstip 10.0.1.100
1:udp_dstip 10.0.2.100
# udp source ip (same subnet as udp_dstip)
0:udp_srcip 10.0.1.184
1:udp_srcip 10.0.2.184
# udp destination mac - not required (picked up from udp_dstip)
#udp_dstmac 22:47:d5:48:ad:ef
# connects to receivers at increasing tcp port starting at 1954
rx_hostname mpc3434
# same as rx_hostname mpc3434:1954+mpc3434:1955+
Performance
-------------
Please refer to Receiver PC Tuning options and slsReceiver Tuning under `Troubleshooting <https://slsdetectorgroup.github.io/devdoc/troubleshooting.html>`_.
Using Callbacks
----------------
One can get a callback in the receiver for each frame to:
* manipulate the data that will be written to file, or
* disable file writing in slsReceiver and take care of the data for each call back
When handling callbacks, the control should be returned as soon as possible, to prevent packet loss from fifo being full.
**Example**
* `main cpp file <https://github.com/slsdetectorgroup/api-examples/blob/master/e4-receiver_callbacks.cpp>`_
* `cmake file <https://github.com/slsdetectorgroup/api-examples/blob/master/CMakeLists.txt>`_.
* how to install the slsDetectorPackage with cmake is provided :ref:`here <build from source using cmake>`.
* compile the example **e4-rxr** by:
.. code-block:: bash
cmake ../path/to/your/source -DCMAKE_PREFIX_PATH=/path/to/sls/install
make

40
10.0.0/_sources/slsreceiverheaderformat.rst.txt Normal file
View File

@@ -0,0 +1,40 @@
.. _sls receiver header format:
SLS Receiver Header Format
====================================================
It is 112 bytes and consists of:
* 48 bytes of the SLS Detector Header
* 64 bytes of packet mask
.. code-block:: cpp
typedef struct {
uint64_t frameNumber;
uint32_t expLength;
uint32_t packetNumber;
uint64_t detSpec1;
uint64_t timestamp;
uint16_t modId;
uint16_t row;
uint16_t column;
uint16_t detSpec2;
uint32_t detSpec3;
uint16_t detSpec4;
uint8_t detType;
uint8_t version;
} sls_detector_header;
struct sls_receiver_header {
sls_detector_header detHeader; /**< is the detector header */
sls_bitset packetsMask; /**< is the packets caught bit mask */
};
| **sls_detector_header** (described in :ref:`the current detector header <detector udp header>`)
| The **packetNumber** from detector UDP header is modified in **sls_receiver_header** to number of packets caught by receiver for that frame and the bit mask for each packet caught is the **packetsMask**. The packetsMask is a total of 512 bits due to the largest number of packets per frame among our detectors.
| For eg. Jungfrau has 128 packets per frame. If **packetNumeber** is 128, then this frame is complete. If it is 127 or less, it is a partial frame due to missing packets. If one would still like to use it, the **packetsMask** will specify which packet has been received or is missing.

147
10.0.0/_sources/softwarearchitecture.rst.txt Normal file
View File

@@ -0,0 +1,147 @@
.. _software architecture:
Software Architecture
================================
Introduction
------------------------------------
.. figure:: images/System_communication_architecture.png
:target: _images/System_communication_architecture.png
:width: 700px
:align: center
:alt: System communication architecture
Software Communication Architecture
**Detector**
A detector can consist of a single module or multiple modules combined.
**Module**
Each module sends its data via UDP over distinct ports. Since UDP does not provide acknowledgements, data is transmitted as fast as possible, which can lead to packet loss if the network is not properly configured, among other causes. A single image streamed out could be split into multiple UDP packets and each module can have one or two UDP ports to transmit in parallel different physical sections of the image.
**Receiver**
UDP data is received by one or more receivers—either built-in or custom. In the diagram above, there is one built-in receiver per module (1:1). For example, a detector with two modules (two hostnames) will have two built-in receivers. Each receiver could listen to one or two UDP ports (depending on the module it listens to). For each UDP port, the receiver reassembles these packets into sub-images and optionally saved to file.
**ZMQ**
Each UDP port in the receiver can also stream out independently sub-images via ZMQ (core: TCP/IP).
* Directly to the GUI for display.
* To an external processing chain for post-processing and optional storage, which can in turn stream the processed data back to the GUI.
**Client**
A single client can configure and control individual modules and receivers, or multiple of them in parallel. This communication is handled over TCP/IP, ensuring acknowledgements.
It can also listen to multiple ZMQ sockets from the Receiver(s) or the external processing chain to assemble the full image for GUI display or Client call backs.
Next, each component is examined in detail.
Module
-------
.. figure:: images/Module_architecture.png
:target: _images/Module_architecture.png
:width: 700px
:align: center
:alt: Module architecture
Module Architecture
**Detector Server**
The module contains an onboard CPU (type depends on the detector — e.g., Nios for Mythen3, Blackfin for Jungfrau). The detector server and detector configuration files are stored here, with the server compiled in C using the CPU-specific compiler. Running the binary starts a Control Server and a Stop Server. Client control/configuration requests go to the Control Server via the TCP control port, while stop/status requests go to the Stop Server via the TCP stop port as the Control Server may be busy with an acquisition. For more details see :ref:`detector server <detector_servers>` and :ref:`detector simulators<Virtual Detector Servers>` to play around with.
**Firmware**
The module also includes an FPGA with VHDL firmware (file format depends on the detector — e.g., Mythen3 uses .rbf, Jungfrau uses .pof). Client requests trigger register read/write operations in the FPGA, which manages chip readout and processing. Data from the chips is sent through a UDP generator in the FPGA and output as UDP packets via the UDP port. A single image may be split across multiple packets. A module could have 1 or 2 UDP ports to transmit in parallel different physical sections of the image.
Upgrade
^^^^^^^^
.. figure:: images/Soft_upgrade_components.png
:target: _images/Soft_upgrade_components.png
:width: 700px
:align: center
:alt: Software Upgrade Components
Software Upgrade Components
There are mainly three components to the soft upgrade:
* Detector Server upgrade: The server running on the module.
* Firmware upgrade: The VHDL code running on the FPGA.
* slsDetectorPackage upgrade: The client code running on the host PC to control the module(s) and receiver(s) if any.
Please use the `update command <commandline.html#term-update>`_ when updating both the server and firmware simulataneously and `programfpga command <commandline.html#term-programfpga-fname.pof-fname.rbf-full-path-opitonal-force-delete-normal-file>`_ when only updating the firmware. See :ref:`firmware upgrade <firmware upgrade>` for details.
When only updating the detector server, use the `updatedetectorserver command <commandline.html#term-updatedetectorserver-server_name-with-full-path>`_ command. See :ref:`detector server upgrade <Detector Server Upgrade>` for details.
.. note::
**Compatibility**
When updating anything on the module via the client (server or firmware), the server and client will have to be compatible (same major version). If not, the client and server will not communicate properly.
Since they are ideally compatible before the upgrade, upgrade the server and firmware first, then the slsDetectorPackage.
Receiver
--------
.. figure:: images/Receiver_architecture.png
:target: _images/Receiver_architecture.png
:align: center
:alt: Receiver Architecture
Receiver Architecture
The receiver mainly consists of:
* A TCP server that listens to client TCP requests for configuration and control.
* One or 2 listeners that listen to a UDP port each, reassembling the UDP packets into sub-images in memory.
* One or 2 data processors that processes the sub-images with optional callbacks for online processing and file writing.
* One or 2 data streamers that stream the processed sub-images to the GUI or external processing chain via ZMQ.
Few characteristics of the receiver:
* It can be run on the same host as the client or on a different host.
* There is a receiver process for every module and a file for every UDP port.
* Each receiver process is independent and asynchronized for performance. So are the UDP ports.
Client
--------
.. figure:: images/Client_architecture.png
:target: _images/Client_architecture.png
:align: center
:alt: Client Architecture
Client Architecture
Users can control the detector and receivers through four interfaces:
* their C++ API,
* their Python API,
* the command-line interface, or
* the Qt-based GUI.
Regardless of the interface, each ultimately invokes our Detector class—either directly (CLI and GUI) or through our C++/Python libraries (when using their APIs). The Detector class then calls the appropriate module functions, either for a specific module or in parallel for all modules. Each module object sends requests over TCP to its corresponding module and, if needed, to the receiver.
**Shared Memory**
As the command-line interface is supported, shared memory is used to store essential information such as the module hostname and TCP port, or the receiver hostname and TCP port. This ensures the system knows which components to communicate with, without requiring the user to re-enter this information for every command-line call.
.. note::
Only the client maintains shared memory. Care must be taken when multiple users operate from the same PC. See :ref:`multi detector and user section <using multiple detectors>` for more details.

504
10.0.0/_sources/troubleshooting.rst.txt Normal file
View File

@@ -0,0 +1,504 @@
Troubleshooting
=================
If something is missing, don't hesitate to
open an issue at our `github repo issues
<https://github.com/slsdetectorgroup/slsDetectorPackage/issues>`_.
Common
------
1. Total Failure of Packet Delivery
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#. Data cable plugged into the wrong interface on board (Jungfrau)
* Please ensure that the data cable is plugged into the rightmost interface (default for single interface). The inner one is disabled for PCB v1.0 and must be selected via command for PCB v2.0.
#. Link up and speed
* Check ethtool and find if Link Deteced:Yes and Speed is acceptable (>10k).
* Check to see if the 10G link is up (blue or red LED on board, close to SFP+). If not:
* Check transeiver and fibers are compatible (all MMF 850nm or all SMF 1030nm)
* Check fiber
* Check fiber polarity (if short range, unplug the link anywhere, and look at the light/dark pattern: dark has to mate with light)
* For Jungfrau, check if the blue sfp light is blinking rapidly (even when it is not sending data). If so, most likely the link is down and something is wrong with the board. If it connected to a switch, then you do not see it with the ethtool command if link is down. One option is to connect it directly to a pc to see if link is down.
* With nc, try "nc -u -p 50001 -l" in receiving pc, and from another pc try "echo hallo | nc -u 10.1.2.172 50001" to send something to the recieving pc interface to see if the link is up and see if the other nc console receives the hallo.
#. Detector is not acquiring (Not Eiger)
* Take an acquisition with many images and using the following steps instead of acquire:
.. code-block:: bash
sls_detector_put status start
# keep executing this command to see if the number of frames left keeps decreasing,
# which means the detector is acquiring.
sls_detector_get framesl
# If you are using multiple modules, the previous command can return -1 because each module will return different values. Then, check for a single module instead: sls_detector_get 0:framesl
#. Detector is not sending data (Except Eiger)
* Check the board to see if the green LED close to SFP is blinking (detector is sending data). If not, detector is not operated properly (period too short/long, no trigger in trigger mode) or misconfigured and needs reboot.
#. Power supply
* Check if power supply has enough current.
* For Jungfrau, refer to :ref:`Jungfrau Power Supply Troubleshooting<Jungfrau Troubleshooting Power Supply>`.
#. Ethernet interface not configured for Jumbo frames (10Gb)
* Ensure that the interfaces (on NIC and the switch) used in receiver pc have MTU 9000 (jumbo frames) enabled.
#. Check if 'rx packets' counter in 'ifconfig' do not increment for interface.
* If no, check switch configuration if present. Port counters of switch can also help to identify problem.
* If yes, but receiver software does not see it:
* Check no firewall (eg. firewalld) is present or add rules
.. code-block:: bash
# Stop and disable firewall
service firewalld stop
systemctl disable firewalld
# Check status
service firewalld status
* Check that selinux is disabled ( or add rules)
#. Source UDP IP in config file (Not Eiger)
* Ensure it is valid and does not end if 0 or 255. Also ensure that the source ip 'udp_srcip' is in the same subnet as destination ip 'udp_dstip' and the masking in the interface configuration ensures this rule.
* Eg. If interface IP is 102.10.10.110 and mask is 255.255.255.0, udp_srcip has to be 102.10.10.xxx (same subnet)
* Use ifconfig and route commands to verify etheret interface configuration
#. Netstat and netcat
* Try with netstat to see if its really listening to the right interface. Or netcat to see if you get packets.
#. Wireshark or Tcpdump
* Use one of these to confirm that you receive packets (with the right filtering ie. source and destination ports, ip).
2. Partial or Random Packet Loss (Performance)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. note ::
The following suggestions are for convenience. Please do not follow blindly, research each parameter and adapt it to your system.
#. Receiver PC is not tuned for socket buffer size and input packet queue or other parameters.
* Refer to :ref:`Receiver PC Tuning<Receiver PC Tuning>`
#. Wiring
* Faulty wiring or connecting cable to incorrect interface.
#. Pinging the subnet (receiving only a few number of packets each time)
* If a switch is used between a receiver pc and detector instead of plugging the cables directly, one might have to ping any ip in the subnet of the Ethernet interface constantly so that it does not forget the ip during operation.
* Eg. if rx_udpip is 10.2.3.100, then ping constantly 10.2.3.xxx, where xxx is any ip other than 100.
* Using slsReceiver, you can use a command that does this for you:
.. code-block:: bash
# arping the interface in a separate thread every minute
sls_detector_put rx_arping 1
#. Only the slaves get no data
* Check trigger cabling and trigger configuration
* When you cannot stop Jungfrau slaves in sync mode, refer to :ref:`Cannot stop slaves<Jungfrau Troubleshooting Sync Slaves Cannot Stop>`.
.. _Receiver PC Tuning:
Receiver PC Tuning Options
^^^^^^^^^^^^^^^^^^^^^^^^^^
.. note ::
| xth1 is example interface name in the following examples.
| These settings are lost at pc reboot.
#. Increase maximum receive socket buffer size and socket input packet queue.
* Temporarily (until shut down)
.. code-block:: bash
# check size
sysctl -a | grep rmem
sysctl -a | grep backlog
# set max and default (use 1Gb for Jungfrau and 100Mb for others)
sysctl net.core.rmem_max=$((100*1024*1024))
sysctl net.core.rmem_default=$((100*1024*1024))
sysctl net.core.netdev_max_backlog=250000
* Permanently
.. code-block:: bash
# edit /etc/sysctl.conf file
# set max and default (use 1Gb for Jungfrau and 100Mb for others)
net.core.rmem_max = 104857600
net.core.rmem_default= 104857600
net.core.netdev_max_backlog = 250000
# save file and run the following
sysctl -p
.. note ::
This is the most basic setting, which is sometimes more than enough.
#. For 10Gb,
* MTU must be set up to 9000 for jumbo frames on detector, switch and server NIC
* Set up static MAC address tables with separated VLANs
#. Write to memory if not a large disk and pc not fast enough.
.. code-block:: bash
mount -t tmpfs none /ramdisk_folder
# or
mount -t tmpfs none /mnt/ramdisk -o size=10G
# check how many GB memory you can allocate, to avoid swapping otherwise
#. Modify ethtool settings.
* rx ring parameters
.. code-block:: bash
# check
ethtool -g xth1
# set to max value in your pc settings
ethtool -G xth1 rx 4096
* coalesce settings (might not always work)
.. code-block:: bash
# check
ethtool -c xth1
# enable adaptive xoalescence parameters
ethtool -C xth1 adaptive-rx on
# set to max value in your pc settings
ethtool -C xth1 rx-usecs 100
* pause parameters
.. code-block:: bash
# check
ethtool -a xth1
# set to max value in your pc settings
ethtool -A xth1 rx on
* generic receiver offload (might not always work)
.. code-block:: bash
# check
ethtool -k xth1
# enable generic receiver offload
ethtool -K xth1 gro
* **permanent ethtool settings**
There are two main methods.
1. ``systemd service`` (recommended for Fedora and modern RHEL)
This is the preferred method on systems using systemd and NetworkManager, such as Fedora and RHEL 8+.
Create a systemd service template:
.. code-block:: ini
# /etc/systemd/system/ethtool@.service
[Unit]
Description=Set RX buffer size with ethtool
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=/usr/sbin/ethtool -G %i rx 8192
Type=oneshot
[Install]
WantedBy=multi-user.target
Enable the service for a specific interface:
.. code-block:: bash
sudo systemctl enable ethtool@xth1.service
This ensures the setting is applied at every boot once the network is online.
2. ``ETHTOOL_OPTS in ifcfg scripts`` (legacy method for RHEL 7 and earlier)
This method applies only to systems using the legacy network-scripts backend, typically RHEL 7 and earlier.
.. code-block:: bash
# edit the corresponding ``ifcfg-*`` file
# file: /etc/sysconfig/network-scripts/ifcfg-eth0
# add or modify the following line:
ETHTOOL_OPTS="-K gro on; -G rx 4096; -L combined 4; -C rx-usecs 100; -C adaptive-rx on"
# restart the interface
ifdown eth0 && ifup eth0
#. Disable power saving in CPU frequency scaling and set system to performance
* Check current policy (default might be powersave or schedutil)
.. code-block:: bash
# check current active governor and range of cpu freq policy
cpupower frequency-info --policy
# list all available governors for this kernel
cpupower frequency-info --governors
* Temporarily (until shut down)
.. code-block:: bash
# set to performance
sudo cpupower frequency-set -g performance
# or
cpufreq-info
for i in ‘seq 0 7‘; do cpufreq-set -c $i -g performance; done
* Permanently
.. code-block:: bash
# edit /etc/sysconfig/cpupower to preference
# enable or disable permanently
sudo systemctl enable cpupower
#. Give user speicific user scheduling privileges.
.. code-block:: bash
# edit /etc/security/limits.conf
# add following line or similar depending on your distribution
username rtprio 99
.. note ::
This is also set if slsReceiver is run as root user.
#. Some more advanced options:
.. warning ::
Please do not try if you do not understand
#. reduce the number of queue per NIC to the number of expected streams: ethtool -L xth0 combined 2
#. assign each queue to its stream: ethtool -U xth0 flow-type tcp4 dst-port 50004 action 1
#. assign to each queue (IRQ) one CPU on the right socket: echo "3"> /proc/irq/47/smp_affinity_list #change the numbers looking at /proc/interrupts
#. disable irqbalance service
#. Be sure that the switch knows the receiver mac address. Most switches reset the mac lists every few minutes, and since the receiver only receives, there is not a periodic refresh of the mac list. In this case, one can set a fixed mac list in the switch, or setup some kind of script arping or pinging out from that interface (will be available in 7.0.0).
#. assign the receiver numa node (also with -m) to the socket where the NIC is attached. To know it, cat /sys/class/net/ethxxx/device/numa_node
#. ensure file system performance can handle sustained high data rate:
* One can use dd:
.. code-block:: bash
dd if=/dev/zero of=/testpath/testfile bs=1M count=100000
* Or better fio (which needs to be installed)
.. code-block:: bash
fio --name=global –directory=/testpath/ --rw=write --ioengine=libaio --direct=0 --size=200G -- numjobs=2 --iodepth=1 --bs=1M –name=job
slsReceiver Tuning
^^^^^^^^^^^^^^^^^^
#. Starting receiver as root to have scheduling privileges.
#. For 10g, enable flow control
.. code-block:: bash
sls_detector_put flowcontrol10g 1
#. Increase slsReceiver ring buffer depth
This can be tuned depending on the number of receivers (modules) and memory available.
.. code-block:: bash
# sugggested not to use more than half memory of CPU socket in case of NUMA systems) for this
sls_detector_get rx_fifodepth
# sets number of frames in fifo to 1024 ~1GB per receiver. Default is 2500
sls_detector_put rx_fifodepth 1024
#. Increase number of frames per file
This can reduce time taken to open and close files.
.. code-block:: bash
sls_detector_get rx_framesperfile
sls_detector_put rx_framesperfile 20000
# writes all frames into a single file
sls_detector_put rx_framesperfile 0
#. Disable file write
This can ensure it is not the file system performance hampering high date rate.
.. code-block:: bash
sls_detector_put fwrite 0
Shared memory error
^^^^^^^^^^^^^^^^^^^
For errors due to access or size, use any of the following suggestions.
#. Delete shared memory files and try again
#. Use environment variable to use a different shared memory ending in jfxx
.. code-block:: bash
# shared memory ending in jfxx
export SLSDETNAME=jfxx
#. USe a different multi shared memory ID
.. code-block:: bash
sls_detector_put 2-config xxxx.config
# or
sls_detector_put 2-hostname bchipxxx
To list all shared memory files of sls detector package.
.. code-block:: bash
ll /dev/shm/slsDetectorPackage*
-rw-------. 1 l_d l_d 136 Oct 1 11:42 /dev/shm/slsDetectorPackage_multi_0
-rw-------. 1 l_d l_d 3476 Oct 1 11:42 /dev/shm/slsDetectorPackage_multi_0_sls_0
-rw-------. 1 l_d l_d 3476 Oct 1 11:42 /dev/shm/slsDetectorPackage_multi_0_sls_1
Cannot connect to detector
^^^^^^^^^^^^^^^^^^^^^^^^^^
Ensure both control and stop servers are running on the detector.
.. code-block:: bash
ps -ef | grep jungfrauDetectorServer*
Cannot connect to receiver
^^^^^^^^^^^^^^^^^^^^^^^^^^
Start receiver before running a client command that needs to communicate with receiver.
Receiver: cannot bind socket
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#. slsReceiver or slsMultiReceiver is already open somewhere.
* Kill it and restart it.
#. Tcp port is in use by another application.
* Start Receiver with a different tcp port and adjust it config file
.. code-block:: bash
# restart receiver with different port
slsReceiver -t1980
# adjust in config file
rx_hostname pcxxxx:1980
.. _common troubleshooting multi module data:
Cannot get multi module data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Possible causes could be the following:
#. Network
* If you have a direct connection, check to see if the network cables are connected correctly to corresponding interfaces on the PC side. Check also the network configuration and that the detectors and receivers are in the corresponding subnet.
#. Power Supply
* Check power supply current limit.
* For Jungfrau, refer to :ref:`Jungfrau Power Supply Troubleshooting<Jungfrau Troubleshooting Power Supply>`.
Cannot ping module (Nios)
^^^^^^^^^^^^^^^^^^^^^^^^^
If you executed "reboot" command on the board, you cannot ping it anymore unless you power cycle. To reboot the controller, please use the software command ("rebootcontroller"), which talks to the microcontroller.
Gotthard2
---------
Cannot get data without a module attached
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You cannot get data without a module attached as a specific pin is floating. Attach module to get data.
Mythen3
--------
Detector status is waiting even in auto timing mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check if the control board or the flat band cable is connected properly. If not, connect them properly and try again.
Jungfrau
---------
Temperature event occured
^^^^^^^^^^^^^^^^^^^^^^^^^
This will occur only if:
* temp_threshold (threshold temperature) has been set to a value
* temp_control (temperature control) set to 1
* and the temperature overshooted the threshold temperature.
**Consequence**
* sls_detector_get temp_event will give 1 # temperature event occured
* the chip will be powered off
**Solution**
* Even after fixing the cooling, any subsequent powerchip command will fail unless the temperature event has been cleared.
* Clear the temperature event
.. code-block:: bash
# gives the current chip power status (zero currently as chip powered off)
sls_detector_get powerchip
# clear temperature event
sls_detector_put temp_event 0
# power on the chip
sls_detector_put powerchip 1
.. _Jungfrau Troubleshooting Power Supply:
Cannot get multi module data
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#. Check :ref:`Common Multi Module Troubleshooting<common troubleshooting multi module data>`
#. Power Supply
* Jungfrau needs a ~4A per module for a short time at startup. If not, it reboots misconfigured.
* Comment out this line in the config file: powerchip 1
* Powering on the chip increases the power consumption by a considerable amount. If commenting out this line aids in getting data (strange data due to powered off chip), then it could be the power supply current limit. Fix it (possibly to 8A current limit) and uncomment the powerchip line back in config file.
.. _Jungfrau Troubleshooting Sync Slaves Cannot Stop:
Cannot stop slaves in sync mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#. If cabling is accessible, ensure termination board and flatband cable between the masters and the slaves are connnected properly. Then try to stop.
#. If cabling is inaccessible, unsync first so that the slaves can get the stop directly from the client using the command. Then, don't use sync mode until the cabling is fixed.
.. code-block:: bash
# unsync, slaves command will fail as it is still in waiting state
sls_detector_put sync 0
# stop should now be successful as master does not determine the stop anymore
sls_detector_put stop

7
10.0.0/_sources/type_traits.rst.txt Normal file
View File

@@ -0,0 +1,7 @@
TypeTraits
==============
Template meta functions in the same spirit as type_traits
from the standard library.
.. doxygenfile:: TypeTraits.h

37
10.0.0/_sources/udpconfig.rst.txt Normal file
View File

@@ -0,0 +1,37 @@
.. _detector udp header config:
Config file
============
Commands to configure the UDP in the config file:
.. note ::
These command are recommended to be placed before "rx_hostname" if it is used.
Source Port
-----------
Hardcoded in detector server, starting at 32410.
udp_srcip - Source IP
---------------------
IP address of detector UDP interface to send packets from. Do not use for Eiger 1Gb interface (uses its hardware IP). For others, must be in the same subnet as **udp_dstip**.
udp_srcmac - Source MAC
-----------------------
MAC address of detector UDP interface to send packets from. Do not use for Eiger (uses hardware mac). For others, it is not necessary, but can help for switch and debugging to put unique values for each module.
udp_dstport - Desintation Port
-------------------------------
Port in receiver pc to listen to packets from the detector.
udp_dstip - Destination IP
--------------------------
IP address of interface in receiver pc to listen to packets from detector. If **auto** is used (only when using slsReceiver/ slsMultiReceiver), the IP of **rx_hostname** is picked up.
udp_dstmac - Destination MAC
----------------------------
MAC address of interface in receiver pc to list to packets from detector. Only required when using custom receiver, else slsReceiver/slsMultiReceiver picks it up from **udp_dstip**.

152
10.0.0/_sources/udpdetspec.rst.txt Normal file
View File

@@ -0,0 +1,152 @@
.. _detector specific fields:
Detector Specific Fields
========================
Please check out :ref:`the current detector header <detector udp header>` to see
where the detector specific fields are placed.
Eiger
------
.. table:: Detector Specific Field
+----------+------------------------------+
| expLength| Sub Frame Number |
+----------+------------------------------+
| detSpec1 | 0x0 |
+----------+------------------------------+
| detSpec2 | 0x0 |
+----------+------------------------------+
| detSpec3 | e14a |
+----------+------------------------------+
| detSpec4 | Round Robin Interface Number |
+----------+------------------------------+
Jungfrau
---------
.. table:: Detector Specific Field
+----------+------------------------------+
| detSpec1 | Bunch Id [#]_ |
+----------+------------------------------+
| detSpec2 | 0 |
+----------+------------------------------+
| detSpec3 | DAQ info |
+----------+------------------------------+
| detSpec4 | 0 |
+----------+------------------------------+
.. table:: DAQ Info Field
+----------+--------------------+----------------------------------------------+
| Bits | Name | Description |
+----------+--------------------+-----+----------------------------------------+
| 0 | High gain | 1 | High Gain enabled |
| | +-----+----------------------------------------+
| | | 0 | High Gain disabled |
+----------+--------------------+-----+----------------------------------------+
| 1 | Fix gain stage 1 | 1 | Gain stage 1 fixed. The switch that |
| | | | selects the gains stage 1 is active all|
| | | | the time. |
| | +-----+----------------------------------------+
| | | 0 | Gain stage 1 unset. The switch that |
| | | | selects the gains stage 1 is inactive |
| | | | all the time. |
+----------+--------------------+-----+----------------------------------------+
| 2 | Fix gain stage 2 | 1 | Gain stage 2 fixed. The switch that |
| | | | selects the gains stage 2 is active all|
| | | | the time. |
| | +-----+----------------------------------------+
| | | 0 | Gain stage 2 unset. The switch that |
| | | | selects the gains stage 2 is inactive |
| | | | all the time. |
+----------+--------------------+-----+----------------------------------------+
| 4 | Comparator reset | 1 | On-chip comparator in reset state. |
| | | | Dynamic-gain switching is therefore |
| | | | disabled. |
| | +-----+----------------------------------------+
| | | 0 | On-chip comparator active. |
+----------+--------------------+-----+-----+-----+----------------------------+
| 7-5 | Jungfrau chip |Bit 7|Bit 6|Bit 5| Description |
| | version +-----+-----+-----+----------------------------+
| | | 0 | 0 | 0 | v1.0 |
| | +-----+-----+-----+----------------------------+
| | | 0 | 0 | 1 | v1.1 |
| | +-----+-----+-----+----------------------------+
| | | 0 | 1 | X | Reserved |
| | +-----+-----+-----+----------------------------+
| | | 1 | X | X | Reserved |
+----------+--------------------+-----+-----+-----+----------------------------+
| 11-8 | Storage cell select|Storage cell used for this exposure. This |
| | |field defines the storage cell that was used |
| | |to acquire the data of this frame |
+----------+--------------------+-----+----------------------------------------+
| 12 | Force switching | 1 | Forced switching to gain stage 1 at the|
| | to gain stage 1 | | start of the exposure period. |
| | +-----+----------------------------------------+
| | | 0 | Disabled forced gain switching to gain |
| | | | stage 1. Dynamic gain switching |
| | | | conditions apply. |
+----------+--------------------+-----+----------------------------------------+
| 13 | Force switching | 1 | Forced switching to gain stage 2 at the|
| | to gain stage 2 | | start of the exposure period. |
| | +-----+----------------------------------------+
| | | 0 | Disabled forced gain switching to gain |
| | | | stage 2. Dynamic gain switching |
| | | | conditions apply. |
+----------+--------------------+-----+-----+-----+----------------------------+
| 23-16 | 10-Gigabit event |The 8-bit event code contains value of the |
| | code |event received over the 10 GbE interface by |
| | |JUNGFRAU detector at the moment of the frame |
| | |acquisition. |
+----------+--------------------+-----+----------------------------------------+
| 31 | External input flag| 1 | External input flag detected in the |
| | | | last exposure. |
| | +-----+----------------------------------------+
| | | 0 | External input flag not detected in the|
| | | | last exposure. |
+----------+--------------------+-----+----------------------------------------+
Gotthard2
----------
.. table:: Detector Specific Field
+----------+------------------------------+
| detSpec1 | Train Id [#]_ |
+----------+------------------------------+
| detSpec2 | Bunch Id [#]_ |
+----------+------------------------------+
| detSpec3 | 0 |
+----------+------------------------------+
| detSpec4 | 0 |
+----------+------------------------------+
Mythen3
----------
.. table:: Detector Specific Field
+----------+------------------------------+
| detSpec1 | 0 |
+----------+------------------------------+
| detSpec2 | 0 |
+----------+------------------------------+
| detSpec3 | 0 |
+----------+------------------------------+
| detSpec4 | 0 |
+----------+------------------------------+
.. [#] **Bunch Id**: bunch identification number received by the detector at the moment of frame acquisition.
.. [#] **Train Id**: train identification number received by the detector at the moment of frame acquisition.
.. [#] **Bunch Id**: bunch identification number to identify every single exposure during a burst acquisition.

147
10.0.0/_sources/udpheader.rst.txt Normal file
View File

@@ -0,0 +1,147 @@
.. _detector udp header:
Format
=======
The UDP data format for the packets consist of a common header of 48 bytes for all detectors, followed by the data for that one packet.
Current Version
---------------------------
**v2.0 (slsDetectorPackage v7.0.0+)**
.. code-block:: cpp
typedef struct {
uint64_t frameNumber;
uint32_t expLength;
uint32_t packetNumber;
uint64_t detSpec1;
uint64_t timestamp;
uint16_t modId;
uint16_t row;
uint16_t column;
uint16_t detSpec2;
uint32_t detSpec3;
uint16_t detSpec4;
uint8_t detType;
uint8_t version;
} sls_detector_header;
.. table:: <---------------------------------------------------- 8 bytes per row --------------------------------------------->
:align: center
:widths: 30,30,30,15,15
+---------------------------------------------------------------+
| frameNumber |
+-------------------------------+-------------------------------+
| expLength | packetNumber |
+-------------------------------+-------------------------------+
| **detSpec1** |
+---------------------------------------------------------------+
| timestamp |
+---------------+---------------+---------------+---------------+
| modId | row | column | **detSpec2** |
+---------------+---------------+---------------+-------+-------+
| **detSpec3** | **detSpec4** |detType|version|
+-------------------------------+---------------+-------+-------+
.. note ::
Since there is no difference in the format of the UDP header from the detector
from the previous version (v2.0), the version number stays the same.
Only the struture member names have changed in sls_detector_defs.h
Description
------------
* **Detector specific field** descriptions are found :ref:`here<detector specific fields>`.
* **frameNumber**: framenumber to which the current packet belongs to.
* **expLength**: measured exposure time of the frame in tenths of microsecond. It is instead the sub frame number for Eiger.
* **packetNumber**: packet number of the frame to which the current data belongs to.
* **timestamp**: time measured at the start of frame exposure since the start of the current measurement. It is expressed in tenths of microsecond.
* **modId**: module ID picked up from det_id_[detector type].txt on the detector cpu.
* **row**: row position of the module in the detector system. It is calculated by the order of the module in hostname command, as well as the detsize command. The modules are stacked row by row until they reach the y-axis limit set by detsize (if specified). Then, stacking continues in the next column and so on.
* **column**: column position of the module in the detector system. It is calculated by the order of the module in hostname command, as well as the detsize command. The modules are stacked row by row until they reach the y-axis limit set by detsize (if specified). Then, stacking continues in the next column and so on.
* **detType**: detector type from enum of detectorType in the package.
* **version**: current version of the detector header (0x2).
.. _detector enum:
Detector Enum
--------------
================ ========
Detector Type Value
================ ========
GENERIC 0
EIGER 1
GOTTHARD* 2
JUNGFRAU 3
CHIPTESTBOARD 4
MOENCH 5
MYTHEN3 6
GOTTHARD2 7
================ ========
* deprecated since v10.0.0
Previous Versions
-----------------
**v2.0 (Package v4.0.0 - 6.x.x)**
.. table:: <---------------------------------------------------- 8 bytes ---------------------------------------------------->
:align: center
:widths: 30,30,30,15,15
+---------------------------------------------------------------+
| frameNumber |
+-------------------------------+-------------------------------+
| expLength | packetNumber |
+-------------------------------+-------------------------------+
| bunchid |
+---------------------------------------------------------------+
| timestamp |
+---------------+---------------+---------------+---------------+
| modId | **row** | **column** | **reserved** |
+---------------+---------------+---------------+-------+-------+
| debug | roundRNumber |detType|version|
+-------------------------------+---------------+-------+-------+
**v1.0 (Package v3.0.0 - 3.1.5)**
.. table:: <---------------------------------------------------- 8 bytes ---------------------------------------------------->
:align: center
:widths: 30,30,30,15,15
+---------------------------------------------------------------+
| frameNumber |
+-------------------------------+-------------------------------+
| expLength | packetNumber |
+-------------------------------+-------------------------------+
| bunchid |
+---------------------------------------------------------------+
| timestamp |
+---------------+---------------+---------------+---------------+
| modId | xCoord | yCoord | zCoord |
+---------------+---------------+---------------+-------+-------+
| debug | roundRNumber |detType|version|
+-------------------------------+---------------+-------+-------+

158
10.0.0/_sources/virtualserver.rst.txt Normal file
View File

@@ -0,0 +1,158 @@
.. _Virtual Detector Servers:
Simulators
===========
Compilation
-----------
* Using CMake, turn on the option
.. code-block:: bash
SLS_USE_SIMULATOR=ON
* Using cmk.sh script,
.. code-block:: bash
./cmk.sh -bsj9 # option -s is for simulator
Binaries
^^^^^^^^
.. code-block:: bash
eigerDetectorServer_virtual
jungfrauDetectorServer_virtual
gotthard2DetectorServer_virtual
mythen3DetectorServer_virtual
moenchDetectorServer_virtual
ctbDetectorServer_virtual
Arguments
---------
The arguments are the same as the :ref:`normal server arguments<Detector Server Arguments>`.
When using multiple modules, use different ports for each virtual server.
.. code-block:: bash
# will start control server at port 1912 and stop server at port 1913
jungfrauDetectorServer --port 1912 &
# will start second control server at port 1914 and stop server at port 1915
jungfrauDetectorServer --port 1914 &
Client
------
.. code-block:: bash
# hostname should include the port (if not default)
sls_detector_put hostname localhost:1912+localhost:1914+
# or use virtual command, instead of hostname
# connects to 2 servers at localhost
# (control servers: 1912, 1914; stop servers: 1913, 1915)
sls_detector_put virtual 2 1912
Use the same in the config file.
Detector API has a method 'isVirtualDetectorServer' to check if on-board detector server is virtual.
Sample Config file
^^^^^^^^^^^^^^^^^^
There are sample config files for each detector in slsDetectorPackage/examples folder.
For a Single Module (Basic)
.. code-block:: bash
hostname localhost
rx_hostname localhost
udp_dstip auto
For a Single Module (With Options)
.. code-block:: bash
# connects to control port 1912
hostname localhost:1912+
# connects to receiver at ports 2012
rx_hostname mpc1922:2012+
# sets destination udp ports (not needed, default is 50001)
udp_dstport 50012
# source udp ips must be same subnet at destintaion udp ips
# takes the same ip as hostname
udp_srcip auto
# destination udp ip picked up from rx_hostname (if auto)
udp_dstip auto
# set file path
fpath /tmp
For Multiple Modules
.. code-block:: bash
# connects to control ports 1912, 1914 and stop ports 1913, 1915
virtual 2 1912
# or hostname localhost:1912+localhost:1914+
# increasing receiver tcp ports (multi detector command)
rx_tcpport 2012
# connects to reciever at port 2012 and 2013
rx_hostname mpc1922
# sets increasing destination udp ports
udp_dstport 50012
# source udp ips must be same subnet at destintaion udp ips
0:udp_srcip 192.168.1.112
1:udp_srcip 192.168.1.114
# destination udp ip picked up from rx_hostname (if auto)
udp_dstip auto
# set file path
fpath /tmp
Receivers
----------
Same as if you would use an actual detector
For a Single Module
.. code-block:: bash
slsReceiver -t2012
For Multiple Modules
.. code-block:: bash
# slsMultiReceiver [starting port] [number of receivers] [print each frame header for debugging]
slsMultiReceiver 2012 2 0
Gui
----
| Same as if you would use an actual detector.
| Compile with SLS_USE_GUI=ON in cmake or -g option in cmk.sh script.
.. code-block:: bash
slsDetectorGui
Limitations
-----------
#. Data coming out of virtual server is fake.
#. A stop will stop the virtual acquisition only at the start of every new frame.
#. Triggers are counted as number of virtual frames. trigger command to send a software trigger (Mythen3 & Eiger) is not implemented in virtual server.
#. firmware version and serial number will give 0.

137
10.0.0/_sources/zmqjsonheaderformat.rst.txt Normal file
View File

@@ -0,0 +1,137 @@
ZMQ: Json Header Format
========================
**Change in field names from slsDetectorPackage v6.x.x to v7.0.0**
* detSpec1 <- bunchId
* detSpec2 <- reserved
* detSpec3 <- debug
* detSpec4 <- roundRNumber
**Format**
.. code-block:: bash
{
"jsonversion": unsigned int,
"bitmode": unsigned int,
"fileIndex": unsigned long int,
"detshape": [
unsigned int,
unsigned int
],
"shape": [
unsigned int,
unsigned int
],
"size": unsigned int,
"acqIndex": unsigned long int,
"frameIndex": unsigned long int,
"progress": double,
"fname": string,
"data": unsigned int,
"completeImage": unsigned int,
"frameNumber": unsigned long long int,
"expLength": unsigned int,
"packetNumber": unsigned int,
"detSpec1": unsigned long int,
"timestamp": unsigned long int,
"modId": unsigned int,
"row": unsigned int,
"column": unsigned int,
"detSpec2": unsigned int,
"detSpec3": unsigned int,
"detSpec4": unsigned int,
"detType": unsigned int,
"version": unsigned int,
"flipRows": unsigned int,
"quad": unsigned int,
"addJsonHeader": {
string : string
}
}
+--------------+----------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------+
| jsonversion | Version of the json header. |
| | Value at 4 for v6.x.x and v7.x.x |
+--------------+----------------------------------------------+
| bitmode | Bits per pixel [4|8|16|32] |
+--------------+----------------------------------------------+
| fileIndex | Current file acquisition index |
+--------------+----------------------------------------------+
| detshape | Geometry of the entire detector |
+--------------+----------------------------------------------+
| shape | Geometry of the current port streamed out |
+--------------+----------------------------------------------+
| size | Size of image of current port in bytesout |
+--------------+----------------------------------------------+
| acqIndex | Frame number from the detector (redundant) |
+--------------+----------------------------------------------+
| frameIndex | Frame number of current acquisition |
| | (Starting at 0) |
+--------------+----------------------------------------------+
| progress | Progress of current acquisition in % |
+--------------+----------------------------------------------+
| fname | Current file name |
+--------------+----------------------------------------------+
| data | 1 if there is data following |
| | 0 if dummy header |
+--------------+----------------------------------------------+
| completeImage| 1 if no missing packets for this frame |
| | in this port, else 0 |
+--------------+----------------------------------------------+
| frameNumber | Frame number |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| expLength | subframe number (32 bit eiger) |
| | or real time exposure time in 100ns (others) |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| packetNumber | Number of packets caught for that frame |
+--------------+----------------------------------------------+
| detSpec1 | See :ref:`here<Detector Specific Fields>` |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| timestamp | Timestamp with 10 MHz clock |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| modId | Module Id |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| row | Row number in detector |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| column | Column number in detector |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| detSpec2 | See :ref:`here<Detector Specific Fields>` |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| detSpec3 | See :ref:`here<Detector Specific Fields>` |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| detSpec4 | See :ref:`here<Detector Specific Fields>` |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| detType | Detector type enum |
| detSpec3 | See :ref:`Detector enum<detector enum>` |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| version | Detector header version. At 2 |
| | [From detector udp header] |
+--------------+----------------------------------------------+
| flipRows | 1 if rows should be flipped. |
| | Usually for Eiger bottom. |
+--------------+----------------------------------------------+
| quad | 1 if its an Eiger quad. |
+--------------+----------------------------------------------+
| addJsonHeader| Optional custom parameters that is required |
| | for processing code. |
+--------------+----------------------------------------------+