LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Simple vi running a lot of memory

Thank you for the previous post,

I am using local variables of a control to read the value, then supply it to various subvi's and if the value changes I display it in the same control. Is that a bad idea?
Second, here are the general images of my program front panel and the block diagram.
The block diagram shows all the buffer allocations.
I have eliminated all the array-to-cluster vi's and now just index the arrays.

Ivan
Download All
0 Kudos
Message 11 of 16
(658 Views)
Is that strip charts that you have on there? Have you checked what you're setting the buffer length to?

If you're writing a new value to a control then yes, you need to do it via a local variable or by using a property node. However, if you're reading a control you're almost always better off using a wire. The rule of thumb: if you can use a wire instead of a local variable use a wire.

What I meant with the Index Array was this:


Not sure what that "Array Break" VI is. Looks like just another Index Array operation. If that's the case simply use an Index Array function instead of going through a subVI.

Unfortunately, without the code all that we have left to offer are trivial suggestions, like Index Array. And, since you can't show us the code all we can do is offer suggestions as to what to look for.

Message Edited by smercurio_fc on 07-17-2007 05:16 PM

Message 12 of 16
(652 Views)
After some thinking... I finally realized that i cannot find the pesky problem.

The charts buffer only 5000 points, it was at 100k but after lowering it to 5k the memory problem did not change.
The code should run without the Fieldpoint installed... i hope.

the main vi is labeled "main - multithread.vi"  Multithread refers to the number of setups i am running.

Thank you for any help and suggestions.

Ivan R.


0 Kudos
Message 13 of 16
(632 Views)

I get dizzy just looking at all these local variables. Many are just substitute for the disconnected terminals. Why not wire directly to the terminals???

One thing I don't understand are all these "request deallocation" everywhere.

  1. First of all, this function does NOT need to be in the last frame of a sequence, but can be anywhere. In fact the sequences in your subVIs are completely without purpose. This node only "requests" a deallocation, meaning the deallocation will happen once the call is finished.
  2. Secondly, all your subVIs operate on fixed size array so it seems completely wrong to deallocate after each call just to require new allocation of the same amount of memory in the next call one iteration later. I would remove ALL these "request deallocation" so the subVIs can retain their allocation between calls. Seems much more reasonable and efficient.

I feel that you have simply way too much code fragmentation, leading to subVIs with way too many connectors. Wouldn't it be more reasonable to e.g. combine all these array into a reasonable structure? For most subVIs, it would be sufficient to have a single SGL, a single boolean, and a single channel array as inputs. I probably would even use 2D arrays, one dimension being the parameters and one the setup#.

You have all these disconnected "code islands" with no control over execution order. You should at least ensure that the initializations below the main loop happen before the loop starts.

There are way too many duplicates to maintain on the FP. Your three tabs are identical siblings. All you probably need is a single set of control and indicators and an unfinitely thin tab control above it. Maintain all chart histories in shift registers and use plain waveform graphs. Also keep everything else in shift registers. Changing the fake tab, would then simply switch the dataset to be currently displayed, always in the SAME set of indicators.

One of the most confusing and error-prone "feature" is your use of duplicate terminal names. This, in combination with the use of local variables makes the code completely unmaintainable. In the code fragment below, we see two terminals and two local variables, all called "2 - Temp(c)" How do you keep track of all these??? (The same problem re-occurs numerous times in other places!!). Ben would probably say that you are trying to herd cats here.

Well, enough for now. The above should get you started.

Message Edited by altenbach on 07-18-2007 09:43 PM

Message 14 of 16
(623 Views)
Wow. That was my first response. My second was: Definitely needs to read the LabVIEW programming style guide.

altenbach, I suspect all those Request Deallocation calls were added in when the user was experiencing memory problems. Seems like it was a hack fix to see if that would solve the problem.

As for the code, I echo altenbach's comments. The comments about local variables has been pointed out by both of us several times in this thread. I add a few more:
  • You should seriously think about putting some architecture into this code. Right now I don't see any. I would recommend reading up on state machines.
  • Your make extensive use of the Elapsed Time function. You should read this thread.
  • Once you make the code improvements provided to you, if you still run into memory growing issues, then go back to what I had previously suggested about using the built-in memory profiler. Those tools were added in for tracking down these kinds of problems. You can also try to simply disable parts of your code to prevent certain things from running to help pinpoint the problem. In LabVIEW 7.1 you don't have the diagram disable structure but you can accomplish the same thing by using a case structure that's hard-wired to a boolean.

Message Edited by smercurio_fc on 07-19-2007 09:04 AM

Message 15 of 16
(606 Views)
Thanks for your input.
This is my first major code in Labview,  and i agree that a lot of the things could be done differently, but due to the lack of experience i didn't know what else to try.
I will try all of the suggestions you have mentioned.
Smercurio... you are correct about the Request Deallocation, I added them only yesterday in an attempt to fix the memory problem.

I truly appreciate all the input, and will update the situation once i go through and rework the code.

Thanks.
Ivan R


0 Kudos
Message 16 of 16
(585 Views)