LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Not enough memory for this operation" problem

I have recently updated an old LabView 4.1 program to 7.0. When running the program, I have been getting a string of "Not enough memory" warnings. Unfortunately, I have not been able to track down the source of this problem. When I run the program with highlight execution enabled - the error doesn't seem to happen. Also, the program has a very large complicated diagram (probably around 8 screens worth - I didn't write it), so it is very hard to dissect through anyway.

Any ideas on how to track down the source of this problem.

thanks
0 Kudos
Message 1 of 10
(3,731 Views)
Just to clarify, did you save the program and all subVIs after updating (e.g. using "save all". Keep a backup of the 4.1 version somewhere else, of course).

Freshly converted, but not yet saved VIs run significantly slower and less efficient. Once everything is saved under 7.0, things should act a bit more normal.
0 Kudos
Message 2 of 10
(3,730 Views)
thanks for the advice,

It looks like I already looked into that though... All subVis are updated, compiled and saved under 7.0. I'm still getting the same error. I wonder what other kinds of things can cause the 'not enough memory' problem to come up? The program that my predecessor wrote does have a nested while loop and within it, a number of calls to the same vi. Can this be a problem? A big problem is is that this program was made without event handler where it really should be (4.1 doesn't have event handlers I guess). I don't want to try and rewrite from scratch though.
0 Kudos
Message 3 of 10
(3,730 Views)
Hi Peter,

It is definitely possible that this application may be designed in the way that it does use too much memory. Can you give us more details about the algorithm behind the application, and your system specs? Also, what kind of memory allocation are you doing (i.e, writing to file, creating large arrays, etc)? Having highlight execution doesn't necessarily give much detail because when you enable it your VI will run much slower, so if you are running out of memory, it will happen much much later. To troubleshoot, I would focus on parts of the application where there is a write to memory or any open references that keep getting called and are not closed.

Jeremy L.
National Instruments
Jeremy L.
National Instruments
0 Kudos
Message 4 of 10
(3,730 Views)
Thanks Jeremy,

I've actually tried the LabView 7.0 version now on another computer. The error doesn't happen at all and everything runs smoothly. The main difference between the two computers is that the one on which it isn't working is WinXP, while the one on which it runs smoothly is Win2K(pro). Can that be an issue?
0 Kudos
Message 5 of 10
(3,730 Views)
Generally, the OS shouldn't be an issue, unless there are other differences "under the hood" of the OSes you are using. Are you sure this is the only difference you have? Is there any difference in hardware (i.e, RAM, HD seek speed) or possibly the number of applications running in the background? Lastly, I would check out both systems in Task Manager and see how much memory the app is taking up in each system. Hopefully this can give us some more clues as to what else may be different in the systems.

Jeremy L.
National Instruments
Jeremy L.
National Instruments
0 Kudos
Message 6 of 10
(3,730 Views)
Thanks Jeremy,

You're right - it's not the OS. I tried running the built application on the computer in question and another XP machine, and it has no problems on the other machine.

No hints come at me from Task Manager - no spikes in memory usage or anything. I'm at a loss - this is a brand new Dell - with very little else going on (I disabled a few things like McAfee and such, but nothing helped).
0 Kudos
Message 7 of 10
(3,730 Views)
Hmm, did you also check for any physical differences between the two machines like RAM and hard disk space? It is discomforting to see nothing in Task Manager. A lack of memory should be reflected there. Another thing to look at in your task manager would be Physical Memory and Kernel Memory (Total and Available). The available memory is the most important number to watch. The only other idea I could think of at this point is if this development machine is having problems with fragmented disk space, and needs to be defragged.

Jeremy L.
National Instruments
Jeremy L.
National Instruments
0 Kudos
Message 8 of 10
(3,730 Views)
Hmmm..

No defrag problem - it's a brand new computer.

Anyway, here is the real dilemma. When I run highlight execution - the error DOES NOT occur. When I do not highlight, it does occur. As such, there seems to be no way to pinpoint where the error is occurring (or is there).

Also, it seems to me that this is not a memory problem. Is there any reason LabView would pop up this error for some other kind of problem.

thanks
0 Kudos
Message 9 of 10
(3,730 Views)
Hi Peter,

The only other reasons I can think of right now as to why you would get this error are from odd typecasting and/or DAQ memory issues. As I looked back on this thread, I noticed that we haven't really talked much about your application and what it does. Can you provide some more details about your application and about any possible memory intensive areas in it? That would definitely help me in narrowing down the problem rather than posting possible causes. I have included a link about type casting and this error below. I'm not sure if this is relevant, but it's only a short read. Thanks for your patience!

Link

Jeremy L.
National Instruments
Jeremy L.
National Instruments
0 Kudos
Message 10 of 10
(3,730 Views)