PDA

View Full Version : Framerate issue



SLcroc
December 21, 2015, 19:23:55
Hello,

i'm looking to get the best framerate with my products (DMM 42BUC03 or DFK 22BUC03).
for example, the 22BUC should go to 150 fps.
they are connected by USB on a Win7 64 OS, and i'm using the LabVIEW 2014 x64 programming environment.
The exposure is set to 1 ms.

the problem is : i never reach a such framerate...
the best i could have is only 10 to 12 fps, with the smallest resolution (but a higher res dont drop the fps, or eventually not too much).

the fps drops when i use the "IC_Grab_Picture.vi".
precisely in this sub-vi, the fps drops when i call the "MemorySnapImage" (in an invoke node).

Finally, i'll use these cam in two different ways : from an external trig, or in a live/continuous mode.


Why the function to snap/get the image data is so long ?
How to get the highest fps ?
Do you have a such simple program/camera initialization, which is working fine at a high fps ?


Thanks for your help.

Stefan Geissler
December 22, 2015, 09:52:25
There are some reasons:
1.) LabVIEW is not that fast. A programming language like C#, VB or C++ creates faster code. But this is not the main reason.
2.) The IC_Grab_Picture uses MemorySnapImage, which takes in worst case only ever second image, because it take the next available image in the stream.
3.) I do not know, whether you have image processing in your loop. Therefore this could be time consuming too and slows down your loop.
4.) You use a long exposure time. If the exposure is longer than the frame rate's time interval , the frame rate must go down.
5.) Frame drops caused by idle states. In case you use an Intel CPU, you may try Processor Idle State Manager. It tries to prevent the CPU going into C3 state. The program can be downloaded from http://www.theimagingsource.com/en_US/support/downloads/ An USB 3.0 PCIe controller solves this problem too.

It is a good idea to install IC Capture and see, which frame rates you can achieve. The "real" frame rate is shown in the title bar of IC Capture. http://www.theimagingsource.com/en_US/support/downloads/details/iccapture/

I point to points 5 and 4.

In order to get all images in time, in particular if you run the camera triggered, you must use a callback (event). The IC ActiveX has the "ImageAvailable" event. It is called automatically, if
- IC.LiveCaptureContinuous is set to true
- a new frame is ready.

LabVIEW event handling is somewhat mysterious for me, therefore, I do not have a sample.

SLcroc
December 22, 2015, 21:17:51
2.) The IC_Grab_Picture uses MemorySnapImage, which takes in worst case only ever second image, because it take the next available image in the stream.
so, in worst case a 1/2 * framerate.



3.) I do not know, whether you have image processing in your loop. Therefore this could be time consuming too and slows down your loop.
the loop is empty just for testing and debugging the image grabbing process.



4.) You use a long exposure time. If the exposure is longer than the frame rate's time interval , the frame rate must go down.
the exposure time is not the problem as i've tried with different value from 0.1 to 100 ms.
no change in fps under the 20 to 30 ms, from where the fps decrease if we continue to raise exposure time.



5.) Frame drops caused by idle states. In case you use an Intel CPU, you may try Processor Idle State Manager. It tries to prevent the CPU going into C3 state. The program can be downloaded from http://www.theimagingsource.com/en_US/support/downloads/ An USB 3.0 PCIe controller solves this problem too.
all my tested PC were with Intel (Xeon, i5 and i7), i'll check this idle state problem.
but i dont understand why a USB 3.0 PCIe controller could solves it ?
my cameras are all USB 2.0, on a HUB, or directly on the computer during this debugging. i've tried different USB socket on my PC (2.0 or 3.0), there is no difference.



It is a good idea to install IC Capture and see, which frame rates you can achieve. The "real" frame rate is shown in the title bar of IC Capture. http://www.theimagingsource.com/en_US/support/downloads/details/iccapture/

Yes this is exactly the point i forgot to tell you.
this fps in the title bar was my first "calibration" for testing my LabVIEW loop, which is indicating the exact same fps value.
so the problem seems not to come on LabVIEW side, but this is the language i use.

another point is, i dont see my cameras in NI MAX.




I point to points 5 and 4.

In order to get all images in time, in particular if you run the camera triggered, you must use a callback (event). The IC ActiveX has the "ImageAvailable" event. It is called automatically, if
- IC.LiveCaptureContinuous is set to true
- a new frame is ready.

probably the point 5 (CPU idle state).
i'll take a look to the ImageAvailable event too.


thanks Stefan for your help ;)

Stefan Geissler
December 23, 2015, 09:47:52
Hi


but i dont understand why a USB 3.0 PCIe controller could solves it ?

The PCI Express bus is not stopped by idle states as the PCI bus. As far as I know.

What happens, if you connect the camera directly to the computer, without hub? Long time ago, I had a support case, where the hub was the bottleneck.

SLcroc
December 23, 2015, 16:39:42
Hi,

ok for USB 2/3.
my camera is connected directly on computer during these tests, even on USB 2 or 3 (the camera is USB 2) the issue is (was) still there.
Is a "standard" (from MBoard, not from a PCIe) USB 3 should solve it ?

i've tried the idle state fix, and it solves the drop of frames !
i'm now with the announced FPS, from 76 to 160 FPS depending on the resolution.
and the FPS slowly decrease with a slowly increase of the exposure, nice.

i've encountered another problem, but i have to check this if its a bug or a sort of mistake from me in the parameters of the camera.
if i increase too much (35 ms) the exposure, the camera (who is running @ 160 FPS) go back into the "6 Hz" mode, and idle state continue to show "enabled" in the tray.
i have to unplug the camera, reboot LabVIEW environment, then re-plugin the camera to have the 160 FPS.

i'll try to limit the exposure with the FPS i set. Coz @ 160 FPS, a 35 ms exposure is a little stupid.
i guess it will work at high exposure + low FPS.


another point concerning the HUB.
when i have for my application the 4 cameras connected on a USB HUB, i have to slow down the FPS of each camera, or they freeze/bug/crash.
maybe because of the limited bandwith of the USB cable ?


thanks again.

Stefan Geissler
December 23, 2015, 18:00:11
I am not sure, whether I understand correctly. But if you connect all four cameras to the hub, make sure, the hub is powered. Each camera consumes up to 250mA.

If all cameras stream at the same point of time, you must reduce the frame rates, otherwise the bandswidths of USB 2.0 is exhausted.

I will be out of office until January 4th.