TestStand memory issues to look out for?

[ademedeiros]

Hi All,

I have an application which runs 32 parallel tests, these tests are very long (45-60days). There is some sort of memory issue that I am encountering which is causing memory usage to increase by roughly 3-4MB per day.

Here's what i've done so far.

• Not using any built in reporting, using LV Database toolkit for reporting. 
• Disabled result recording for every step.
• Disable Result Recording for All Steps in "Sequence Properties"
• Gone through every VI and followed NI best practices as outlined here.
• Ensured that all references are closed in my modifed OI.
• Using the simplified OI, modified to use UI message events, which I then poll data from the sequence using Teststand "GET" function in LV.
• OI uses subpanels which are started asynchronously

Are there any particulars about TestStand that may be causing this issue? Possibly some setting that I have overlooked?

I am using LabVIEW 2014 SP1 and TestStand 2014 both 32-bit.

Thanks in advance!

[Kimchi-Taco]

Hello,

Please tell us more about your application.  If you can provide a simplified version of your code it might make it easier for us to test them out.  Can you tell me what drivers you are implementing in your TestStand application?  Have you been able to pinpoint segments of the code and/or software (i.e. LabVIEW, CVI) in your application that takes a long time executing?  Are there sequences that generate large amounts of data?  If so, you may want to consider these possibilities:

1. For report generation, the report string can be very large, and requires contiguous memory.
2. The growing ResultList array which stores test results can cause you to run out of memory.

To solve these types of problems, change the report and/or database options to conserve memory:

1. Reduce the number of results being added to the report
   1. Disable result logging for unwanted steps
   2. Disable result logging for loops (ex waiting for a signal)
2. Report Options: 
   1. enable on-the-fly (not available for ATML format in TestStand 2010 and previous) - generates the report as you execute rather than all at the end.  Prevents report loss when errors occur.
   2. enable the Conserve Memory and Only Display Latest Results option (not available for XML or ATML format in TestStand 2010 and previous) - TestStand displays only the latest results in the report tab.  The rest of the report is not in memory and is stored on disk
3. Database Options: enable on-the-fly
4. Model Options: enable Discard Results or Disable Results When Not Required by Model - deletes result information from ResultList once the result processors are done with it.  This option only has an effect when on-the-fly is enabled

Thanks,

[ademedeiros]

Hi Jonathan,

Thanks for your response.

For drivers, I am using DAQmx for a PXI system and NI VISA. I have not been able to pin-point the error, but I am fairly certain it comes from a few while loops in the code. The program at a basic level executes while loops repeatedly until some timeout is reached. In these while loops it repeatedly requests data from an LXI PSU.

I have a "background" sequence which constantly polls data from the PXI system. During every loop iteration, this writes to an initialized 64 element numeric array.

I am not using any built-in reporting or database logging. All logging is done via my VI's in LV. I have disabled report generation for every step, and disabled it in "Sequence Properties." I have enabled on-the-fly reporting, but report is disabled in "Results Processing."

I do see the option for Discard Results or Disable Results When Not Required by Model, would this have any effect even though all reporting is disabled?

Thanks!

Andrew