IMAQdx deletes the images, but LostPacketCount = 0?

I use the example of OR 'Grab and Setup.vi attributes' with a run of camera XIMEA USB3 at 60 fps on Windows 7 (i5 - 4310M, 2.7 GHz, 8 GB)

«Description: The Grab and configuration example VI attributes allows the user view the current attributes and settings, update the attribute parameters, acquire images continuously and display images in an image control.»

I made a few changes. I have two image display windows instead of one. In the "': Frame made" event, when the "ActualBufferNumber" is the same, the image is displayed on my left picture frame and when it is odd, he appears on the right. "  My scene evolves at 60 fps synced to the release of material from the signal from the camera ("exhibition-start"), so the same and odd field images are significantly different, and it is easy to differentiate.

It just works as expected. However, at random times, usually several minutes apart, that the acquisition process apparently ignores a framework such as the left and right images are exchanged.  Sometimes he jumps a framework, we get, then jumps immediately another frame, as well as an output image flashes and then returns to the initial display.   I display the IMAQdx 'LostPacketCount' and it is always 0. When the program runs, watch Windows Task Manager using LabVIEW between 14 and 17% of CPU and system total CPU is never more than 41%, so it doesn't seem that the CPU is overloaded.  In addition, the moments of drops of framework do not match the peak CPU use. I'm following up separately from the 60 Hz frame-sync camera output signal and it's precisely stable (with ~ 50 nsec jig on the nominal 16.667 period msec) that you would expect from a hardware trigger, there is no stuttering or gaps here.

'Acquisition of configure' entry I started with 3 stamps, then 6, then 100, but the frequency of the events of frame-depot does not seem sensitive number of buffers. Do I have to have unrealistic expectations of the capture and display 60 fps without frame drops? How to debug this problem?

UPDATE:  I tried to run another one "Grab and detect jumps Buffers.vi" which leans on the signal "Stamp Out number" of "IMAQdx is Image2.vi" and it detects correctly ignored by executives. The output of "Jump buffer Count" shows that change between folders in Outlook on the acquisition of 60 frames per second in general fall 5 pictures.

Tags: NI Hardware

Similar Questions

Maybe you are looking for