LabVIEW
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
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
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.
- 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.
- 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
