This website is being translated through machine translation by a third-party service. Basler does not warrant the accuracy, reliability or timeliness of any information translated by this system and will not accept liability for loss or damage incurred as a result. Content that has not yet been translated appears in English. Switch to English version
The AccessMode parameter indicates the mode of access the current application has to the device:
Control: The application has control access to the device. Other applications are still able to monitor the device and can request to take over control or gain exclusive access to the device.
Exclusive: The application has exclusive access to the device. No other application can control or monitor the device.
Monitor: The application has monitoring, i.e., read-only, access to the device.
NotInitialized: Access to the device hasn't been initialized.
Use the MaxTransferSize parameter to specify the maximum USB data transfer size in bytes. The default value is appropriate for most applications. Increase the value to lower the CPU load.
USB host adapter drivers may require decreasing the value if the application fails to receive the image stream. The maximum value depends on the operating system.
Use the NumMaxQueuedUrbs parameter to specify the maximum number of USB request blocks (URBs) to be enqueued simultaneously.
Increasing this value may improve stability and reduce jitter, but requires more resources on the host computer.
Decreasing this value can be helpful if you get error messages related to insufficient system memory, e.g., "Failed to probe and lock buffer=0xe2010130" or "Failed to submit transfer status=0xe2100001".
Use the ReceiveThreadPriorityOverride parameter to enable assigning a custom priority to the thread which receives incoming stream packets. Only available if the socket driver is used.
Use the TransferLoopThreadPriority parameter to specify the priority of the threads that handle USB requests from the stream interface.
In pylon, there are two threads belonging to the USB transport layer, one for the image URBs (USB request blocks) and one for the event URBs. The transport layer enqueues the URBs to the xHCI driver and polls the bus for delivered URBs.
You can control the priority of both threads via the TransferLoopThreadPriority parameter.
On Windows, by default, the parameter is set to the following value:
25 if the host application is run with administrator privileges.
15 or lower if the host application is run without administrator privileges.
On Linux and macOS, the default parameter value and the parameter value range may differ.
The transfer loop priority should always be higher than the grab engine thread priority (InternalGrabEngineThreadPriority parameter) and the grab loop thread priority (GrabLoopThreadPriority parameter).
The TypeIsWindowsFilterDriverAvailable parameter indicates whether the pylon GigE Vision Filter Driver is currently available (1) or not available (0).
The TypeIsWindowsIntelPerformanceDriverAvailable parameter indicates whether the pylon GigE Vision Performance Driver is currently available (1) or not available (0).
Packet resend mechanisms (GigE Vision only) optimize the network performance by detecting and resending missing data packets.
The pylon GigE Vision Filter and Socket Drivers have advanced and robust packet resend mechanisms.
They allow for fine-tuning and can send multiple consecutive resend requests until a maximum number of requests has been reached.
If the driver detects that packets (e.g., leader, payload, or trailer packets) are missing, it waits for a specified period of time. If the packets don't arrive within the time specified, the driver may send a single or multiple resend requests to try to retrieve a lost packet.
If a consecutive range of payload packets is missing, the driver will automatically send a single "batch resend request" for the range of missing packets. In addition, the driver may automatically send a resend request for a resend request that has been considered lost.
Use the PacketTimeout parameter to specify how long (in milliseconds) the filter driver waits for the next expected packet before it initiates a resend request.
Make sure that the parameter is set to a longer time interval than the inter-packet delay.
Use the FrameRetention parameter to specify the maximum time in milliseconds to receive all packets of a frame. The timer starts when the first packet has been received. If the transmission is not completed within the time specified, the corresponding frame is delivered with the status "Failed".
Use the FirewallTraversalInterval parameter to prevent a firewall from blocking GigE Vision packets.
The parameter is available for both the stream grabber and the event grabber, i.e., for handling GigE Vision Streaming Protocol (GVSP) packets and Message Channel Source Port (MCSP) packets. It must be configured separately for both types of packets. For more information, see the code sample below.
If enabled, the grabber will send specific packets to simulate a traffic conversation that prevents firewall blocking.
By default, a packet will be sent every 10 seconds for GVSP packets and every 30 seconds for MCSP packets during a given streaming session.
You can set the parameter in milliseconds to optimize it for your firewall.
When the FirewallTraversalInterval parameter is set to zero, the Firewall Traversal feature is considered disabled.
Use the TransmissionType parameter to define how stream data is transferred within the network. You can set the parameter to the following values:
Unicast (default): The stream data is sent to a single device in the local network, usually the camera's GigE network adapter (see destination address). Other devices can't receive the stream data.
LimitedBroadcast: The stream data is sent to all devices in the local network (255.255.255.255), even if they aren't interested in receiving stream data. In large local networks, this uses a large amount of network bandwidth. To use this transmission type, you must set up the controlling and monitoring applications.
SubnetDirectedBroadcasting: The stream data is sent to all devices in the same subnet as the camera, even if they aren't interested in receiving stream data. If the subnet is small, this may save network bandwidth. Because devices outside the subnet can't receive the stream data, this transmission type can be useful, e.g., for security purposes.
For subnet-directed broadcasting, the stream grabber uses a subnet broadcast address. The subnet broadcast address is obtained by performing a bitwise OR between the camera's IP address and the bit complement of the camera's subnet mask (see destination address). To use this transmission type, you must set up the controlling and monitoring applications.
For more information about IP addresses, subnet masks, and subnet broadcast addresses, visit the Online IP Subnet Calculator website.
Multicast: The stream data is sent to selected devices in the local network. This saves network bandwidth because data is only sent to those devices that are interested in receiving the data. Also, you can specify precisely which devices you want to send the data to.
To use multicast, the stream destination address must be set to a multicast group address (224.0.0.0 to 239.255.255.255). Also, you must set up the controlling and monitoring applications. Then, the pylon API automatically takes care of creating and managing a multicast group that other devices can join. - UseCameraConfig: The stream transmission configuration is read from the camera. Use this option only if you want to set up a monitoring application.
When using limited broadcast, subnet-directed broadcast, or multicast, you usually want to send the image data stream from one camera to multiple destinations.
To achieve this, you must set up exactly one controlling application and one or more monitoring applications.
The controlling application starts and stops image acquisition. It can also change the camera configuration.
The monitoring applications receive the stream data. Monitoring applications open the camera in read-only mode. This means that they can't start and stop image acquisition or change the camera configuration.
For testing purposes, you can use one instance of the pylon Viewer as the controlling application and another instance of the pylon Viewer as the monitoring application.
To use different instances of the pylon Viewer as controlling and monitoring applications:
Start the pylon Viewer and open a GigE device.
Start another instance of the pylon Viewer. This will act as the monitoring application:
Windows: Start the pylon Viewer. In the Devices pane of the pylon Viewer, right-click the GigE device opened in step 1 and then click Open Device … > Monitor Mode.
Linux: At the command line, type: /opt/pylon5/bin/PylonViewerApp -m
macOS: At the command line, type: ./Applications/pylon Viewer.app/Contents/MacOS/pylon Viewer -m
Info
For more information about setting up controlling and monitoring applications, see the GigE Multicast/Broadcast section in the pylon API Documentation.
The DestinationAddr parameter indicates the IP address to which the stream grabber sends all stream data.
The value and the access mode of the parameter depend on the TransmissionType parameter value:
TransmissionType Parameter Value
DestinationAddr Parameter Value
DestinationAddr Access Mode
Unicast
IP address of the camera's GigE network adapter
Read-only
LimitedBroadcast
255.255.255.255
Read-only
SubnetDirectedBroadcasting
(Camera's IP address) OR NOT (camera's subnet mask)
Read-only
Multicast
Default: 239.0.0.1 Allowed range: 224.0.0.0 to 239.255.255.255a
Read/Write
Some addresses in this range are reserved. If you are unsure, use an address between 239.255.0.0 and 239.255.255.255. This range is assigned by RFC 2365 as a locally administered address space.
The pylon API provides statistics parameters that allow you to check whether your camera is set up correctly, your hardware components are appropriate, and your system performs well.
At camera startup, all statistics parameters are set to 0. While continuously grabbing images, the parameters are continuously updated to provide information about, e.g., lost images or buffers that were grabbed incompletely.
The Statistic_Buffer_Underrun_Count parameter counts the number of frames lost because there were no buffers in the queue.
The parameter value increases whenever an image is received, but there are no queued, free buffers in the driver input queue and therefore the frame is lost.
The Statistic_Failed_Buffer_Count parameter counts the number of buffers that returned with status "failed", i.e., buffers that were grabbed incompletely.
The error code for incompletely grabbed buffers is 0xE1000014 on GigE cameras and 0xE2000212 on USB 3.0 cameras.
The Statistic_Failed_Packet_Count parameter counts packets that were successfully received by the stream grabber, but have been reported as "failed" by the camera.
The most common reason for packets being reported as "failed" is that a packet resend request couldn't be satisfied by the camera. This occurs, e.g., if the requested data has already been overwritten by new image data inside the camera's memory.
The Failed Packet Count does not count packets that are considered lost because all resend requests have failed. In this case, the Failed Buffer Count will be increased, but not the Failed Packet Count.
The Statistic_Missed_Frame_Count parameter counts the number of frames that were acquired but skipped because the camera's internal frame buffer was already full.
Many Basler cameras are equipped with a frame buffer that is able to store several complete frames. A high Missed Frame Count indicates that the host controller doesn't support the bandwidth of the camera, i.e., the host controller does not retrieve the acquired images in time. This causes the camera to buffer images in its internal frame buffer. When the internal frame buffer is full, the camera will start skipping newly acquired sensor data.
The Statistic_Resend_Packet_Count parameter counts the number of packets requested by resend requests.
Info
If you are using the Filter Driver and the driver hasn't received the "leader" of a frame, i.e., the packet indicating the beginning of a frame, it will disregard the complete frame. No resend requests will be sent and no statistics parameters will be increased. This means that if the "leader" packet is lost, the complete frame will be lost without notice. Basler recommends checking the Frame Counter chunk to detect lost frames.
The Statistic_Resend_Request_Count parameter counts the number of packet resend requests sent.
Depending on the driver type and the stream grabber settings, the stream grabber may send multiple requests for one missing packet, or it may send one request for multiple packets. Therefore, the Resend Request Count and the Resend Packet Count will most likely be different.
The Statistic_Resynchronization_Count parameter counts the number of stream resynchronizations.
If the host gets out of sync within the streaming process, it initiates a resynchronization, and the camera's internal buffer is flushed.
A host may get out of sync if it requests stream packets with a specific sequence of IDs, but the device delivers packets with a different sequence. This may occur when the connection between the camera and the host is faulty. A host being out of sync results in massive image loss.
A host resynchronization is considered the most serious error case in the USB 3.0 and USB3 Vision specification.
On GigE cameras, the Statistic_Total_Buffer_Count parameter counts the number of buffers that returned with "success" or "failed" status, i.e., all successfully or incompletely grabbed buffers. On other cameras, e.g., USB cameras, the number of buffers processed is counted.
The error code for incompletely grabbed buffers is 0xE1000014 on GigE cameras and 0xE2000212 on USB 3.0 cameras.
The Statistic_Total_Packet_Count parameter counts all packets received, including packets that have been reported as "failed", i.e., including the Failed Packet Count.