How to reduce the delay of camera when capture image?

[Stan1378]

I use SDK to capture image, and I hope it can save image every 30~50ms. 

But is has some delay.

(Camera : Mightex_MCE-B013-U)

Ex: I set 50ms capture time between 2 images.

My monitor will show 11 images at once, then stop for 3 seconds. Later, will show 29 images.

Could you tell me how to adjust my VI. To fit the time I had set.

Just like this Sample VI.

[Bob_Schor]

To capture images at 30-50 msec (or 20-33 FPS), your camera must operate in "video" mode and have a mechanism to save multiple images, possibly in a video format or as a series of multiple still images.  You are using the manufacturer's software, which is probably optimized for C or C++, not for LabVIEW.

Bob Schor

[Stan1378]

I can’t understand what you mean. Indeed, I’m recording the image by video mode. Just like the sample program (picture below)

       

It seems that there isn’t any burst mode. I choose SDK to set the period of capture time between every image. However, the monitor display can’t meet the time I have set.

In order to solve this problem. Should I change Labview to C or C++ or adjust this IV can also make it or this camera not able to do it.

[Kyle97330]

I see you're using a function that saves the image to a file.

What might be happening is that your file system can't handle the amount of data at the speed you're saving it.  So the first few frames go through and are getting cached, but then eventually it holds everything up to deal with the backlog, and then resumes when it's caught up.

Is there an alternate function where it captures the frame but returns it as a bitmap?  Or maybe you can change some of the inputs there to make it save faster (by changing compression or size settings, maybe)?

[Bob_Schor]

@Stan:

     Thank you for attaching your code.  You are effectively using LabVIEW to call a DLL that is tied to the (presumably C/C++) routines made by the manufacturer.  I have no idea if they have code made for "continuous video streaming to disk", but it doesn't look like you are using it.  Streaming usually involves two processes running simultaneously and in parallel -- one process that acquires images and puts them in a (circular) buffer and another process that takes images out of the buffer and writes them to the disk.  Generally, the image acquisition takes essentially not  time -- if you are recording at 50 FPS, then every 20 msec the camera has roughly 1 MB of data which it needs to transfer to the PC, and if the transfer is by USB3, this should take < 2 msec.  So every 20 msec, you have 18 "free time" that another process could use to write the 1 MB of data to disk, plenty of time!

     The key, of course, is to have these two processes happening simultaneously.  This is done by having the Camera Acquisition Loop run "all by itself" -- every 20 msec, it "produces" 1 MB of data, which it puts into a Queue and "exports" out of the loop.  It goes to a second loop that spools the data to disk, "consuming" the data by removing it from the Queue and writing it to disk.  This Producer/Consumer process is called the Producer/Consumer Design Pattern (and there's a LabVIEW Template for that).

@Kyle:

     The data transfer needs of this task are modest.  The problem is that everything is taking place within the vendor's software, which might not support parallel acquisition of images and streaming it to disk (this seems hard to believe, but @Stan chose this route, and has access to the Vendor's software and its DLL.  Still, it seems odd that they would produce a camera capable of reasonable frame rates that couldn't be saved to disk at the same rate.

Note:

     LabVIEW's Vision Development Module and Vision Acquisition Software, while requiring additional licenses, are certainly capable of recording video streams if they conform to certain Industry standards (such as GenICam).

Bob Schor