09-11-2012 03:21 PM
Hello,
Thank you in advance for any help. This post is actually an attempt at restarting/resolving a discussion brought up by zobfish (a co-worker of mine) earlier this year. The issue was never resolved and I am dealing with it again (confirmed by zobfish that this is the same issue). I am not as seasoned in labview, so please be patient if I make an idiot out of myself...Here is the link to the earlier thread:
http://forums.ni.com/t5/LabVIEW/IMAQ-Start-vi-hangs-with-many-buffers/td-p/1826217
Perhaps it should be said that I am not using the same computer or labview version referred to in the zobfish's thread. I am, however, using the same labview code. Zobfish overcame this problem by running the labview code on a HD with 64-bit windows XP instead of windows 7. I do not have the same option, I'm stuck with windows 7 and having the same problem with this code.
I have stripped all IMAQ components out of the main program and run them independently and the problem remains (see attachment 1 below for the stripped down version). Here is a recap:
- At low buffer sizes, the code runs fine.
- Once the buffer size reaches 3k - 4k frames the program appears to hang.
- Memory and CPU usage are just fine when running the program regardless of buffer size (attachment 2, this is with 4k buffers running in the program).
- (relevent?) When the program hangs the only way to stop it is by closing labview and restarting the computer (or killing the labview process in the process manager)
As zobfish said in his thread, the program seems to get caught in the IMAQ Start.vi (see attachment 3). Upon digging down into the IMAQ Start.vi it appears that, more specifically, it hangs up in the "Call Library Function Node" of the imgSessionConfigure.vi (See attachment 3 again).
If anyone could give me an idea as to why this is occurring or any possible fixes. I would greatly appreciate it. Other than zobfish's post, I have not seen this documented anywhere else in these forums.
Many thanks in advance,
-A
09-13-2012 09:50 AM
Anyone have any ideas? Any explanations, work arounds or suggestions would be helpful.
09-16-2012 08:53 PM
Hi awinde,
When I increase the number of buffers to about 4000, I receive an error at IMAQ Configure Buffer stating that I do not have enough memory. What do you get if you probe the error wire directly after that function? Also, you may want to add a simple error handler to check for other errors and warnings.
09-17-2012 01:29 PM
Hi Cole,
Thank you for taking the time to reply and the suggestions! I ran my code at 4000 and 8000 buffers with a probe placed after IMAQ configure buffer (and a breakpoint before IMAQ Start.vi so it would not hang). I also added a general error handler after IMAQ configure buffer that connects to a case structure to display any errors. Neither the probe or error handler picked up any error for either buffer size. I attached pictures of the probe window + program (when screenshot was taken the breakpoint had already been reached) and the resource monitor for the 8000 buffers for your verification, if needed.
In summary, as best I can tell, the program reaches IMAQ Start.vi without any problems every time I run the code although the for loop does take FOREVER.
Best,
A
09-18-2012 04:31 PM
Hi awinde,
The only thing out of the ordinary for this type of acquisition that I noticed is that you have the IMAQ Configure List function set to 'one-shot' whereas for this type of acquisition I would expect you to have 'continuous'. Otherwise, the code you have here very closely resembles the example codes for this type of acquisition as provided by the example finder.
09-19-2012 12:42 PM
I altered the code to "continuous" without any change in performance. Thanks for the suggestion, I'm at a total loss.
09-20-2012 05:24 PM
Hi awinde,
I'm sorry to hear that has been causing you so many problems. I see that you do have a 64 bit computer, are you using 64 bit LabVIEW as well? I have been testing code with a 32 bit PC, however, I would like to more closely replicate your system.
09-21-2012 06:34 AM
Hi Cole, I appreciate you sticking with me. Yes, I am using 64-bit labview (version 11.0.1f1) on 64-bit windows 7.
(In case it is helpful, my co-worker (zobfish, see link above) had this same problem on 64-bit labview (version 10.0) on 64 bit windows 7 running on a separate computer. As I mentioned, he overcame this by switching to 32 bit labview 8.6 running on 32 bit windows xp.)