![]() C++ | ![]() .Net API (C#) | ![]() Python |
Cvb::GevServer | Stemmer.Cvb.GevServer | cvb.gevserver |
The Common Vision Blox GigE Vision Server (CVB GEV Server) presents any source of data, like a frame grabber or proprietary camera, images, or even merged containers of different types and sources, as a GigE Vision camera.
Using the CVB GEV Server can be as simple as assigning an image source and starting the server. The tool takes care of the rest. However, if you wish, you also have the option of fine-tuning its behavior, from defining custom payload containers and image preprocessing to defining your own GenICam GenAPI functions. The latter allows you to easily control the PC and hardware running the CVB GEV Server remotely.
A CVB GEV Server instance acts as one GEV camera using one NIC. Only one instance is allowed per IP address; One instance can send one data stream. The following steps describe the typical process of a CVB GEV Server instance:
If the device only holds a static or dynamically scalable image, no complex payload is needed and no chunk is needed, the simple Cvb::GevServer::Server
class can be used. It provides all necessary functionality to stream images and control the server via GenICam features. If the device needs to stream complex payloads, e.g. multiple images, 3D point clouds, metadata (chunk) or other data types, the Cvb::GevServer::ServerGev3
class must be used. It is fully compliant with the GigE Vision 3.0 standard and uses GenDC as the payload format. This is currently only available in CVB++.
Each server - regardless of the class used - has a lifetime consisting of the following phases:
Before anything can be done a CVB GEV Server instance has to be created. There are two versions available:
Cvb::ServerGev3
, where all use cases can be accomplishedCvb::Server
, where several simple cases can be done.The latter one can be instantiated with the following three functions:
where
For total freedom with respect to the transferred payload type, size and format, the Cvb::ServerGev3
class can be used. It uses the payload format GenDC, where different payloads are fused to a single container format. This class (currently CVB++ only) is instantiated like this:
When a server instance is created the following happens: By default the server determines the fastest available transfer driver (filter or socket driver). No IP address is assigned to the server at this time and thus the server is not running yet.
After creating a CVB GEV Server instance the server is in the configuration phase. In this phase the image source can be set, the acquisition mode can be changed and/or GenICam features can be added.
After the configuration is finished the server has to be started. Now the CVB GEV Server library dynamically creates a GenICam XML description for the current instance. After that is done the server goes online in an idle state. Each server object has a function ".Start()" which opens the service on the given IP.
On the client side, the CVB GEV Server is available on discovery (if correctly configured).
As soon as a client connects the server goes to the Connected state. There is always only one controlling client to which the acquisition control is transferred to. As long as the connection exists no other client can connect to the server. When the client starts the acquisition the server state changes to Acquiring. The state of the server can be queried with
A started server now can handle payload sending. This is done by issuing sending requests to the server instance. The simple server stream accepts the payload object directly. The payload must fulfill the configuration of the server (maximum image size and pixel format). A Cvb::Image
can be pushed to the server stream as follows:
GenDC payloads require a different handling, as fully described in this section.
The client streaming can be implemented as described in the Acquisition and Configuration chapter.
When the acquisition is stopped by the client, the server goes back to the Connected state. The server can be stopped by the application at any time. This will close the connection to the client and stop the service. The server can be started again after that.
Different modes and options are available to configure the CVB GEV Server instance. The following sections describe the most important ones.
The transfer driver is referred to as the driver type in the CVB GEV Server interface. It defines which driver is used to stream images to the client. The two possibilities are:
If installed, the CVB GEV Server uses the Filter Driver by default. If not, it automatically falls back to the Socket Driver. The driver type is specified when the server instance is created and cannot be changed afterwards. Also ServerGev3
currently only supports the Socket Driver. If possible, use the filter driver as it minimizes the overhead of the normal Windows IP stack and reduces the CPU load significantly. Only use the Socket Driver if for example loopback transfer is needed.
In the ServerGev3
class the payload is predefined via a GenDC descriptor. A detailed introduction in the usage within CVB can be found in this chapter.
For the correct operation a GenDC descriptor and a matching flow set pool must be registered to the server instance before starting it. The flow set pool defines how many buffers of which size are preallocated for the streaming. This pool is then iteratively used for sending payloads. A GenDC descriptor has to be defined to communicate the payload format and size to the user. The GenDC descriptor - by definition of the standard - always starts at the beginning of a sent buffer. Both descriptor and pool must be compatible with regards to flow counts and sizes. See this example (Step 1, 2, 3 and 6) on how to create flow set pools from a given flow set info. The registration in code is done as follows:
If the payload is a GenDC payload, the sending is defined by issuing the desired flow set index to the server stream, which was previously filled with data. The flow set index is the index of the flow set in the flow set pool, which was registered with the server instance. As within GenDC the data size can vary, a vector of sizes has to be passed with the actual fill levels of the flows to be sent. Then, the sending is done as follows:
The CVB GEV Server provides an interface to create and modify GenICam GenAPI Features presented to the client. This chapter gives an instruction how to work with these features and how they can be accessed by an application using the CVB GigE Vision Server library. See the chapter about GenICam for a detailed introduction on the GenICam standard behind the API.
GEV Server creates the minimum needed set of nodes that is required to connect to the CVB GEV Server and for acquisition is provided. So only the application specific custom features have to be provided.
Currently the following node types are available in the CVB GEV Server and can be created by the user inside the server application.
Node Type | Description |
---|---|
Boolean Node | A boolean node represents a true/false value. |
Category Node | A Category node is useful to group features and is normally only used in user interfaces. In the GenICam Browser they appear as top level category for a set of leaf nodes. |
Command Node | A Command node is used to submit commands to the device. Commands are used for prolonged actions which are executed asynchronously. |
Enumeration and EnumEntry Nodes | A predefined set of symbolic (string) values which are mapped to an integer number Enumeration nodes. |
Integer and IntReg Nodes | Integer nodes represent integer values. IntReg nodes are backed in the register map. |
IntSwissKnife Node | To perform mathematical computations on the client side, not on a low computational power cam. |
StringReg Node | To store ASCII strings. |
ChunkIntRegister Node | To attach integer values from the chunk data. |
ChunkFloatRegister Node | To attach floating point values from the chunk data. |
Those nodes are always assigned to the servers node map. On the user side, they appear within the "Device" node map which is automatically created by the CVB GEV Server.
Every node map regardless of transport technology used has three mandatory nodes. Depending on the associated device there can be more mandatory nodes.
The root category is the first node for a graphical user interface to access. With this node it queries which nodes are available. Thus every node that should be publicly accessible must be within this category. Also it is recommended to only have Category nodes as the direct children of the Root category which resemble the names of the GenICam Standard Features Naming Convention document.
This integer node is used by the transport layer to lock all features which have an effect on the payload size. The payload size is the overall frame size transferred by the camera. This is necessary to make sure that the preallocated buffers stay valid as long as streaming is in progress. Thus if you have a feature which must not be changed when the server is sending data you can use the TLParamsLocked node in the. Locked features which are readable and writable become read-only. Write-only features become not available (e.g. Command nodes).
Nodes can be created and added to the server node map as follows:
The main identification of the CVB GEV Server is the vendor and model name. To distinguish between different versions or instances of the tool the Device Version field is used. If you do not add your own custom features you do not need to change the user version. By default the CVB GEV Server device version is its DLL version. If custom features are added it is recommended to enter an additional user version which makes this instance with its feature set uniquely identifiable. If this is not done, different xml descriptions can lead to invalid register access. The user version can be set on the CVB GEV Server object with
Several configuration options are available to tune the behavior of the CVB GEV Server. The most important ones are described in the following sections.
On the receiving side larger packet sizes reduce the CPU load. The same is true for the sender and thus the server side. The larger the packets the fewer packets need to be sent. This reduces the number of events to be processed and it improves the net transfer rate as fewer header data needs to be sent.
Applications using the CVB GEV Server library need at least full access rights in a firewall for the entire application. Ports are requested dynamically from the system for streaming data and therefore a simple port rule would not be sufficient. Per application settings for a local firewall also introduce a significant performance penalty as the firewall still has to touch all the packets to check which is the sending/receiving application. It is recommended to use a dedicated network card for the image data transfer and disable the firewall for the whole interface.
Example | Description |
---|---|
QMLGevServer (C++ version) | The QmlGevServer example starts a QML GevServer which can load a device and stream the device image. (QML C++ version) |
CLIGevServerSpeedtest | Speed test with predefined payloads |
QMLGevServer (Python version) | The QmlGevServer example starts a QML GevServer which can load a device and stream the device image. (QML Python version) |