Simple vi running a lot of memory

[Ivan R]

Hi,

I have a simple vi that takes measurements from Fieldpoint (FP1601) and AI110, then the vi computes the output pH base on the input voltage.
The problem is that if I run the vi for an extended period of time, the memory usage keeps going up and up...
I have included a 150 ms wait time, and somewhat relieved the problem. However i think it just slowed down the vi, so that the memory does not get
used up as fast, but it still goes up.

Any advice?

Attached is the exact vi.

[smercurio_fc]

Your delay won't do you any good because it's outside the loop, so the delay only happens once, right at the start of the program. There's nothing inherent in your VI that would cause the memory to just keep growing since LabVIEW knows how many times you're doing the loop so it's not continuously building arrays. The problem may be in the FieldPoint module. Could be a memory leak. Unfortunately I don't have FieldPoint so I can't provide further information. I would guess that the VI you're using does a setup, read, and close all in one. If that's the case you should split out each of those steps so that the setup is performed at the beginning, you then take all your readings, and when you're ready to stop the program you close the Fieldpoint session.

You should be aware that since you're autoindexing each of the arrays you do not need to wire to the "N" input. When you auto-index LabVIEW knows how many time it needs to run the loop. Also, the base assumption here is that all arrays are the same size. Otherwise the loop only runs as many times as the smallest array.

One thing you said which makes me suspicious. You said you run the VI for "an extended period of time". Your VI uses a for-loop so it runs a fixed amount of times and then stops. Are you using the continuous run button in the toolbar? If so, don't do that. That button should only be used for special debugging cases. If you need to run this VI continuously sorround it with a while loop that's wire to a front-panel button that you use to stop the VI.

[altenbach]

A few more comments:

It looks to me this is a subVI. Can you show us the calling program? How big are the arrays?

Probably not a cause for the problem. but your formula node contains a lot of dead wood. You don't need to set all values to zero first and then re-define them as a function of the inputs. Also VB1 and VB2 outputs are not needed, just branch the wire going to the input terminals of the same names.

It is also not clear why you mix SGL with DBL everywhere. All these coercions cause extra data copies.

Is the "FP read (polymorphic)" a stock VI from NI, or is this something you modified?

[Ivan R]

Thank you for the fast replies.

Yes, this is a subvi, and the calling program passes arrays of 4 elemenents to this subvi.
Within the calling program the subvi is located inside the main timed loop. Currently the timing of the main loop is 30 ms, could that also be the problem?
I've changed the subvi and currently the memory usage seems stable after 10 minutes of running.

Here is the subvi with changes and additions suggested by your comments. However i am not sure what altenbach is refering to with DBL and SGL, all of my variables are SGL's.

Thank you.

[smercurio_fc]

If it's a subVI it doesn't make much sense to put a while loop since execution of this subVI is being controlled by your main program. My comment about the while loop was based on the presumption that this was a top-level VI that you were testing and that you were using the continuous run button.

altenbach's statement about the SGL/DBL has to do with the fact that the outputs of the formula node generate DBL data types. At the for-loop boundary you get an array of DBL, which gets coerced down to an array of SGL. That's why there's dots at the left of the indicator's terminal. If you were to change your formula node to this:

float32 VTC;
float32 phslope=(pH2-pH1)/(VB2-VB1);
float32 phoffset=pH1-(phslope*VB1);
VTC=Volt*(Tk/(Tcal+273.15));
float32 currentph=VTC*phslope+phoffset;

then the formula node would output SGL. You would need to insert a "To Single Precision Float" from the Numeric->Conversion palette at the output of the FP Read to make that an SGL so that everything is SGL.

As far as the memory issue is concerned, why do you believe the problem is with this subVI? Aside from my previous comment about the FP Read, I don't see it as being here, and without seeing the higher-level code, I don't know what else to say.

[mikeporter]

In general the only comment I would make is that this subVIs processing would be more efficient if you did all the processing in arrays using LV functions rather that the formula node inside a loop. Also you need to spend some time working on the wiring in a couple places it's very hard to tell what is connected to what.

But beyond that I would have to agree with my friend smercurio and wonder why you suspect this VI?

Mike...