Increasing memory usage with LabView operator interface, is this normal?

[Andrewbft]

I have created a LabView User Interface. When running the same sequence over and over again, the memory usage of Labview increases by 3M every time. Is this normal or is there a way of reducing or removing this?

[SachaE]

Hi,
do you see this with one of the existing operator interfaces?
What sequence are you running?
It could be that something is not being correctly released by your operator interface, or the sequence you're running has a memory leak.
Does the memory return to normal after the execution finishes? (i.e. if I'm understanding you correctly, then you're doing separate runs of say Test UUTs or similar, and until you close the operator interface it's not releasing the memory?)
I would expect the memory useage to increase during runs as the resultlist increases in size, but after the report is generated, this should drop again.
Which version of TestStand, and which version of LabVIEW are you using? Which operating system are you using?
If it's the LabVIEW memory usea
ge that's increasing, then I'd be pretty sure it's the operator interface not releaseing a handle to something. If it's one of the pre-built operator interfaces you're using, then we should be able to replicate the situation, and help to debug from there.

Thanks

Sacha Emery
National Instruments (UK)

[Angel Olivares]

Hi,
I have exactly the same problem. When I run the Operator Interface (written in LabVIEW) my total used memory gets higher and higher making my process time everytime slower. The only chance to decrease memory is to end the Operator Interface Task that is running. I use Windows 2000, LV 7.0 and TestStand 3.0.
In all my specs files I have disabled the property "Record Results" in oprder to avoid spending memory, but after doing this the behaviour is the same.
Some ideas? Thanks,

Angel

[Wojtek]

Hello,
I've seen a simular problem, and got a illuminating response. I see that the 1st time running the OI, leads to a big jump in memory usage(preloading a load of stuff and cashing it I assume), then on the next few run memory usage goes up by 100-300Kb on average
See Message thread "Memory Leaks in TS3.0 OI's"

The main response I got it quoted below................

Hi

If you are sure that you are leaking when you generate html/XML reports, then you should consider upgrading to 3.1.
The changes to work around a leak in IE is very extensive and is not available for TestStand 3.0
Below is the text from TestStand 3.1 readme which gives you more details.

"In TestStand, the sequence editor report tab and the Custom UI Report control use the Microsoft Internet Explorer ActiveX control to display html and XML reports. Each time the Internet Explorer control updates the report, the Internet Explorer control does not always release its internally allocated memory. If the control is updated continuously over an extended period of time, the TestStand process memory use increases. TestStand 3.0 used the control in a way such that the failure to release memory occurs more often. TestStand 3.1 contains workarounds that limit the amount of memory the control fails to release. Note that when using on-the-fly reports, the Internet Explorer control is only used when the control is visible. "

You can also consider using txt reports, which will also confirm that it is related to html/XML reports and not anything else.

I hope helps.
Regards
Anand Jain
National Instruments.

[Angel Olivares]

Hi,
one collegue gave me an advice. I've set the expression: SetNumElements(Locals.ResultList,0) in all the subsequences that are running in my sequences in which some process is waiting for in a loop the confirmation of the operator (like press button to confirm, insert a disk, and so on). Nevertheless I still have to check this in the production at least 4 or 5 hours to have a definitily answer. If hope this helps.

Angel

[Anand_Jain]

Hi

Before you think it might be related to reports I would suggest that you narrow the problem down.

There could be multiple leaks.
One way to check this is to disable reporting and database logging.
See if you still continue to leak.
That would indicate that some other code is leaking.

If some other code is leaking, I would suggest breaking it down some more
ie
1. Run without the process model or with the default process model.
2. Run examples sequences with your process model etc

I hope this helps.
Regards
Anand Jain
National Instruments

[Angel Olivares]

Hi,
I'm not using the report options neither the database collection. I have a thread running in parallel which is doing the work of saving all the stuff. I'll follow your advice in order to check if I found the leak.
Thanks,

Angel

[Angel Olivares]

Hi Anand,
I explain you a little bit more. I'm not using reporting nor database logging. I have a sequence in my process model that saves the values of the client sequence file in the harddisk. I've disable in all the steps the RecordResult option, in order to save memory. I have also inserted always before all the Gotos, the expression "SetNumElements(Locals.ResultList,0) although I think this is useless since the RecordResult properties are disabled. I use an event thread sequence in the process model that check if somebody want to terminate the execution (pressing the Cancel Button, digital Input) but also at the end of every thread I set the RecordResults to 0. I use the PostStepFailure CB of the StationCallbacks in order to analyse the failures in case of requirement, but I also set the RecordResults to 0 at the end of every execution. I've run the sequence tracing it and checking step by step how the memory increase and decrease and it's always getting higher. I've taken some lines of my code into another sequence where I configure with IVI a couple of power supplies and I've run the SequentialModel shipped with TestStand and the memory increases between 4 and 8 bytes. Only when I close the sequence the memory release. Is there no TestStand API command able to release the used memory? My real problem is that after running my test after some ours the tack time gets slower and slower.
Thanks in advance,

Angel