IMAQ property node

[taroK]

Hello,

I would like to acquire movies with a high-speed camera (1240 x 1080 pixels, 500 Hz), and found 'Sequence and Save to AVI.vi' in 'NI Example Finder'. This program works fine when I only acquire a small number of frames (~500 frames). However, the program runs very slowly when the frame number is increased to 3000.

I looked into the code, and it turned out that the most time-consuming part was the 'imgPopScalingAndROI.vi' used by 'IMAQ Sequence VI' . The setters of IMAQ propety node takes forever (> 5 mins). Is this a bug? Are there any ways around this problem?

I am using 64-bit windows 7 and 64-bit labview. This PC has 32GB of RAM. Thank you.

[Rob_Ward]

Hey taroK

Just doing some calculations, you are acquiring 1240*1080*500Hz*3 = 2GB/s.  When you acquire 500 samples (i.e. run for 1 sec -> 2GB) then the program runs fine, but when you acquire 3000 samples (i.e. run for 6 sec -> 12GB) then the program slows.  By doing benchmark timing you found the problem to be in the imgPopScalingAndROI.vi specifically at the property nodes.

At first glance with the sheer amount of data you are handling it is unsurprising for the performance of your computer to slow but since the spec of your PC should handle it it would be nice to investigate this futher if possible.  Can I ask - if you remove this sub-vi from your program does this fix the timing issues?  Not that this is a solution but since this vi is after you acquired and processed the data it is not 100% necessary to include this step. 

Can I also ask what hardware you are using so that I may be able to replicate the problem you are having.  If I get the same problem this may be reported as a corrective action request.

Regards,

[taroK]

I am using NI PCIe-1433 frame grabber with an optronis high speed camera (http://www.optronis.com/fileadmin/user_upload/datenblaetter/CL600x2_engl.pdf).

I removed imgPopScalingAndROI.vi from the code, and it now runs much faster. However, I also noticed that 'IMAQ Close.vi' also takes minutes..

[Rob_Ward]

taroK,

thanks for that information.  Could you verify that you are using your camera in monochrome mode, rather than RGB colour, to be within the 850MB/s bandwidth of the card?  That would make all the numbers now add up so we can discount any buffer overflow as the soruce of the problem.

Thats good that it has sped up your code, but I do want to find where this bug is.  I had a look at the IMAQ close.vi and I am guessing again that the problem you mention now comes from the Call Library Function Node in imgClose.vi when doing benchmark timing?  Can you please confirm this.  This may suggest a problem with the imaq.dll and/or driver that needs to be looked at.

Many thanks, and as much information you can provide as possible is of invaluable help.

Kind Regards,
.

[taroK]

Yes, I am taking monochrome movies and the 'Call Library Function Node' takes minutes. Hope this info helps solve the problem.

[Rob_Ward]

Can I ask which version of LabVIEW you are running and what version of the IMAQ drivers you have? The NI Vision Acquisition Software 2012.08 is available to download from here: http://joule.ni.com/nidu/cds/view/p/id/2975/lang/en its always a good idea to have the latest drivers installed.

Regards,

[taroK]

I am using Labview 2011 and Vision Acquisition Software 2012.08.

[Rob_Ward]

taroK,

thanks for this information.  I have come across a previous issue like the one you discuss, and one of the ideas was that the last image never gets fully transferred; therefore the card waits until the timeout to return and quits.

The reason for this is that when IMAQ close is called, the card waits until the counters: numImagesAcquired = numImagesTransferred to give the framegrabber time to transfer its last image before it is shutdown. If for some reason the last image never finishes being sent from the camera, the framegrabber would wait until the timeout to receive this. It's also very likely that the timeout wouldn't be reported if it occurs inside of the IMAQ close.

I did notice that your camera is not supported by NI Hardware (www.ni.com/camera ), but your camera might have a camera file on the firmware which is why you probably never needed one in the first place (http://digital.ni.com/public.nsf/allkb/05DCE3868362783586256FC8004F123C ).  There still may be some compatibility issues with this so you can make your own camera file using the NI Camera File Generator which may overcome the hanging issue on imgClose.

Can I also ask - is your camera visible in MAX - If not is does it then become visible after you develop the camera file?

Regards,

[Rob_Ward]

"I did notice that your camera is not supported by NI"  should read "I did notice that your camera is not tested by NI".  Your camera is supported - otherwise it wouldn't have worked in the first place.

[taroK]

I am using the camera file provided by the camera company, which is attached to this message. Please note that the extension has been changed from icd to txt because icd files could not be attached. With this camera file, the camera is recognized by MAX. I can grab or snap images from MAX. 

The counter issue might be relevant, and I am going to look into it. The number of frames in the acquired looks correct, though. Many thanks for your help.