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

[Ivan R]

Thank you to all who have left their valuable comments on this topic.
Here is the update. I have structured the main vi only to run the front panel and coordinate the data flow between subvi's. All the calculations, PID control and file writing is done by different subvi's. I've made sure that each sub-vi only has one function: such as data logging, pH calculations, time period calculations, etc.  But the pesky problem persists, when i run the main vi the memory usage as shown in the Windows Task Manager keeps going up and up. Sometimes it goes up by only 4kb/sec and sometimes as much as 500kb/sec. In addition, i have noticed that Labview racks up Page Faults in the order of 8-10 million after running for 24 hours. The number of Page Faults can also be seen in the Windows Task Manager.

I have asked my manager for permission to post the project, but since it is proprietary program I am not allowed. But i can provide more information, such as:
1) for the sake of space saving the main VI i am using Tab control to fit a large number of controls on a single screen.
2) the data from the controls is then put into arrays and passed into various subvi's.
3) once the subvi's are done the data is take out of the arrays and displayed in the indicators/controls.
4)the main vi runs in a while loop now, previously it was a timed while loop at about 30ms
5)some subvi's have "Elapsed Time" vi's that are there to control the amount of time the heater and air injectors are on.

I would be more than happy to provide any more information.

Thank you for your input.
Ivan R.

Message Edited by Ivan R on 07-16-2007 03:30 PM

[smercurio_fc]

Unfortunately, that doesn't help nail down the problem as it doesn't give specifics, which you can't provide due to the proprietary nature of your project. My suggestion is to use the Tools->Profile->Performance and Memory tool. This will allow you to see how much memory is being used in each of your VIs and should help you track down the problem. Also, you can Tools->Profile->Show Buffer Allocations to display dots at the points in the VIs where LabVIEW is allocating memory. These two, hopefully, will give you enough information to determine where the leak is.

A side suggestion: Normally passing in values of parameters as you are describing should be done by a cluster rather than an array. This is so that you don't have to remember which index corresponds to which parameter. With a cluster you can use Unbundle By Name and access the parameter by name. Separate clusters should be used for the input parameters and the output parameters. Also, it would be best to make these typedefs so if they need to be changed (like add or remove a parameter) you change them in one place.

[Ivan R]

Hi,

if you place an Advanced PID inside a while loop, could that cause any problems?

Thanks

Message Edited by Ivan R on 07-16-2007 05:00 PM

[smercurio_fc]

Unlikely since a PID normally runs inside a loop anyway.

A couple of comments regarding the code:

• You do not need to convert the array to a cluster and then unbundle it. Just use the "Index Array" function directly and resize it as needed.
• The excessive use of local variables is highly suspicious. While not likely to be causing your memory issue since based on what can be seen none of them are arrays, it's quite likely that you either have or will have a race condition. See here for a good example of this.