IMAQ Start.vi hangs with many buffers

[NateBraska]

Hello zobfish,

Were you able to get it back to the original state with the hangs, so no more blue screen?

Has this ever working at a reasonably fast rate with >5000 buffers in the past, or is there something suggesting that this is indeed an unexpected behavior? I strongly recommend using the simplest VI you can make and see how it is affected with this many buffers to see if it is necessarily a surprising effect.

I would look at the "Profile Performance and Memory" tool. You can find it under "Tools" > "Profile" > "Performance and Memory..." It should list all the memory that all the VI's are using. Also, if you could run your working VI, such as with <3000 buffers, how is your RAM affected? Most importantly, during which part of your VI's execution does usage increase? You can either watch the Profile Performance and Memory tool or just the task manager.

Best Regards,

Nathan B

Applications Engineer

National Instruments

[zobfish]

Hello Nathan,

Yes, no problems with blue screens once a reverted back from a parallel loop.  It has never worked with >5000 frames.

I've already given my report on performance via the task manager, so here's some reports via the LabVIEW profiler (attached) of a VI that I stripped down to just include the IMAQ functionality (filename is Dalsa_DualLED_Win7_64_strip.vi).  Hopefully you can make sense of it.

[Joseph_Loo]

Can you bring up the task manager from windows using resources and check the memory usage in both the parallel and non-paralll version.

[NateBraska]

Hello Zobfish,

Those files do not seem to have any unusual memory statistics and I do see how the time is increasing so much when you set the buffer to 3000 from 1000.

Is there a reason that you are setting it to such a large buffer size? I see that you are using LabVIEW 64-bit, and fortunately the NI Vision Module works with LabVIEW 64-bit (the only module that does, in fact; see this KnowledgeBase), so you should be able to use as much RAM as the OS will allow.

I think the issue is, when you set such a large buffer size and LabVIEW has to allocate a contiguous block of memory for the buffer, the computer has to defragment the memory to have a large enough space. And with such a large buffer size, this will take quite a while. This KnowledgeBase article mentions how LabVIEW has to allocate a contiguous memory block.

Have you been able to set it to a higher buffer size and see if it will run, even if it takes such a long time? I would expect it to give you an error or even crash LabVIEW if you used too much memory. Otherwise, it probably is just taking all this time to reorganized the RAM.

Best Regards,

Nathan B

Applications Engineer

National Instruments

[zobfish]

Thank you all, especially Nathan, for sticking with me.

I've investigated the problem of contiguous memory allocation before, but have never found any workaround for it.  Would you be able to suggest any?  I've set the program at higher buffer numbers (I think i remember it being 7 or 8k) and let it run for 10-15 minutes before without it passing.  I have never got an error or a crash before, though, which I agree seems to suggest that it is just taking its time.

Interestingly enough, I went back to XP 32bit (same system, just a different boot on a different HD) and tried out the same program with LV 8.6 (built in 8.6, not a downgrade) and while it has the same problem, it is able to successfully (i.e. pass in a reasonable amount of time) several thousand more buffers than the Win7 64bit version.  This version hasn't even been rigged with the 3GB switch OR extended memory.  Curious?

As for the parallel loop questions, I will investigate and get back to you.

-zob

[zobfish]

Another option - an alternative to pre-buffering all the frames, that is - might be streaming to disk.  I do not have any experience with this in LabView, though, so would anyone be able to confirm whether this would be an option and is feasible for my application?  If it is, then could you recommend some resources?

[NateBraska]

Hi zob,

This is almost sounding like it is not a memory issue. I missed how small of a resolution you are taking in the first post. If my math is correct, then you should be using just less than 1 GB of data for the buffers (at even the higher thousands of buffers) and therefore able to run successfully on the 32-bit machine.

This sounds like it could possibly be just a LabVIEW issue. Could you have made any errors in the most recent testing VI, that you did not make in the 8.6 version?

Let me know how the investigation goes.

Best Regards,

Nathan B

Applications Engineer

National Instruments

[zobfish]

I am confident that both are the same and free of extraneous errors.  I will recheck another time and let you know if the case is otherwise, but let us operate under the assumption that this isn't a mistake (though wouldn't that be nice!).

In response to the possibility of it not being a memory-related issue, I believe we still can't rule it out.  While your calculations are indeed correct (nice work, by the way - the .bin files ultimately produced are typically ~750 MB towards the upper buffer limits of the program), the problem you brought up previously regarding contiguous memory allocation would still remain an issue, no?  I agree, though, that total memory volume consumption should not be an issue.  If this is indeed the case, might there be a third party "memory defragmenter" (correct terminology?) program that could be run just before the buffer memory allocation VIs (e.g. via a C implementation VI)?