We are using custom software with an external trigger to image workpieces arriving at 8-second intervals.
Basically, imaging works without problems,
but the first imaging process after connecting the camera takes nearly 3 seconds.
Subsequent imaging processes take about 1.7 seconds.
The above times represent the time taken for the following processes:
Capture
Pointmap acquisition
Feature point extraction
Saving result data
Saving parameters
Processes 1, 2, and 5 are performed via nxlib.
We have collected logs.
Could you please check if there is a difference in processing time via nxlib
between the first image and subsequent images?
We have attached two logs collected under the following conditions:
Log for the first and second images
(tmp_NxTreeEdit20260615(first,second).enslog)
Log for the nth and (n+1)th images in subsequent imaging cycles
(tmp_NxTreeEdit20260615(n,n+1).enslog)
Thank you for your detailed post, but unfortunately the logs you attached contain no actual data.
Firstly, the first long imaging cycle (~3s) is a known and expected behavior. The delay occurs because several internal resources are initialized lazily upon the first execution of the capture and processing commands:
Rectification Lookup Table: The SDK calculates an internal lookup table to speed up image rectification. This is computed on the very first execution of ComputeDisparityMap (or RectifyImages).
Algorithm Memory Buffers: The stereo matching algorithm (PatchMatch) allocates significant memory buffers for descriptors and intermediate calculations. For a high-resolution camera like the C57, this can involve hundreds of megabytes of RAM or VRAM.
CUDA/OpenGL Context Initialization: If GPU acceleration is enabled, the first call triggers the creation of the CUDA context and the compilation/caching of necessary kernels. Similarly, if you are rendering the pointmap, the OpenGL context is initialized on the first run.
A common practice in external-triggered industrial workflows is to perform a “warm-up” capture immediately after connecting to the camera and initializing the SDK. You can trigger and compute the first frame, discard the result, and only then begin your actual 8-second production cycle. This ensures all heavy allocations happen before your first real workpiece arrives.
Secondly, a steady-state processing time of 1.7s for a C57 is somewhat a bit longer than expected. You can look through our guide Optimize Settings for Performance/Quality, but I would also happy to see real profiling data to make some recommendations. It would also helpful if you would share your PC/GPU specifications and your ComputeDisparityMap parameters, and we can look into performance tuning options.
Q1. When using an external trigger, is there a way to activate a warm-up trigger without physically turning on the sensor?
Since the sensor is installed in a high location, it is difficult to physically trigger it by activating the sensor before the workpiece arrives .
Also, I do not want to resort to simply sacrificing the first workpiece.)
Q2.When starting my custom software, I set the trigger mode to software mode and perform a “warm-up capture.”
Then, I change the trigger mode to the external trigger “FallingEdge.”
Is this method effective?
(Would this method allow for imaging from the first workpiece with a short processing time?)
Regarding the phrase “after connecting to the camera and initializing the SDK” mentioned above, could you please explain the conditions under which a “warm-up capture” is required?
For example, is a “warm-up capture” necessary if the camera is disconnected and then reconnected?
Or, once the camera is powered on and connected, is a “warm-up capture” unnecessary for subsequent operations?
I apologize for the additional request, but could you please let me know?