Problem with Report Generation in TestStand 3.0

[Scharnhorst]

Hi

I have the same problem in my test sequence. If I run the VI standalone from LabVIEW the memory consumption is stable at around 40 mb. If I run the same VI as a step in teststand the memory consumption is a staggering 97 mb and continously rising with approximatly 4K every second. Note that this is a single step being executed, and one would imagine that memory usage would be stable at least at that time.

I have unchecked all check boxes reffering to result collection, database logging and reserve loaded VI's for execution. I have also chosen to unload VI's after step executes and unchecked the non-reentrant optimizer box.

Since I am not in the mood or have the time to write my own test executive I would REALLY appreciate a solution to this problem, preferably one that does not require me to by yet another version of this software.

So far I can only agree with the contents in the attached Word document above.

If any of you other people in this thread has come up with a solution, please E-mail me.

Regards
Thomas Fridman
Global test team, GE Healthcare

[Anand_Jain]

Hi

"I have unchecked all check boxes referring to result collection, database logging and reserve loaded VI's for execution. I have also chosen to unload VI's after step executes and unchecked the non-reentrant optimizer box."

From the above statement you should be calling minimal report generation code as there are no results to generate a report from.

So the problem statement is ( correct me if I am wrong)
You have a sequence which calls a VI in one step and if you call this in a loop you see the memory increase. You have result collection turned off.

If the statement is correct, can you please post the sequence file and the VI which is causing the problem. Also post your "TestStandModelReportOptions.ini" from /Cfg folder.

Can you please make so that the VI does not require any special Hardware and/or software to run (other than National Instruments Products).

Regards
Anand Jain
National Instruments.

[Scharnhorst]

Hi Anand,

The step is not run in a loop. It is just a long measurement taking several measurement points. All measurements are done from within the labview application and then exported to teststand for evaluation. The sequence requires a database to function and the VI library is approx 40 mb big. Do you still want me to post it? I am also wondering why memory is not released when you close the sequence file? It's not until you cloe the executeive or the sequence editor that the memory is given back to windows. The first time I noticed the problem was when teststand stopped reading the databse and gave me a frontend.dll error. The error then was replaced by a out of memory error apperaring at about 180 mb of ram on a P4 with 512 mb installed.
I have also had the problem that when passing a big labview cluster within the sequence, the sequence file itself grew enourmously to approximately 42 mb. I have now removed the cluster and the file is down to 2 mb. How is this possible. Does teststand create a new instance of each global variable for each time it is used?

Many questions....hoping for an equal amount of answers and solutions

Regards
Thomas Fridman
Globat test team, GE Healthcare

[Mikef]

We were running TestStand 3.0 (now 3.1) with the "On-The-Fly" reporting and had the same problems, but they were solved by:

In the Configure menu, Report Options, select "Conserve Memory and only display latest result"
In the Configure menu, Model Options, select "Discard Results..." box.

Mike

[Anand_Jain]

Hi

Can you please contact National Instruments Technical support so that they can help you better and also be able to look at your VI.

Regards
Anand Jain
National Instruments.

[AllenP]

I will be contacting you directly to investigate the situation further. I will post an answer on the forum once the solution has been reached.

Allen P.
TestStand R&D

Message Edited by AllenP on 04-20-2005 01:06 PM

[AllenP]

The reason for the memory leak is that the database handles were being left open and never being closed. Every execution created a new handle while the old one was never destroyed.