Unload of modules only works first time round the loop?

[Chrisma]

I have a menu-based sequence in Teststand 4.0 runnin Labview VI menus nested one below another. The code for the top menu is this:

Do While           Locals.StartTest == True

Action               Action, HardwareTestMenu.vi

If                      Locals.StartTest == True

  If                    Locals.TestArray[0] == True

   SequenceCall Call Test_TA3_Menu in TA3_test.seq

   Statement     Runstate.Engine.UnloadAllModules()

  End

  If                    Locals.TestArray[1] == True.....................................................

with repetition for each other menu option. We repeatedly run these options for different units and had a problem where we were running out of memory. That's why I inserted the UnloadAllModules to get the memory back after each test is run.

My problem is that using the task manager you can see this release the memory the first time the menu option sequence runs but then all consequent times it doesn't work and the memory still keeps clocking up.

The sequence call runs exactly the same each time with no errors.

Any ideas why this is and how I can stop it running away with all my memory?

thanks in advance,

Chrisma

[StevenH]

Hi Chrisma,

Would it not be better to configure the steps which call the code modules so that they load the code modules dynamically and then unload the code module once the step has executed?

Let me know how you get on with this.

Best Regards,

Steve

[Chrisma]

Thanks Steve, but I already tried that. Loading dynamically causes my VI menus to jerk on and off the screen violently and unloading after execution still doesn't release the memory until after I close the top menu sequence. It's appearing to me like the unload options just don't work! I seem to have tried ever combination of both full sequence and step settings of these load/unload options.

[StevenH]

Hi Chrisma,

Would it be possible for you to upload a snippet of the Sequence File which illustrates this problem, along with the code modules which are called?

This way I can try to run the sequence from this end, and I can look into the issue from there.

Thanks,

Steve

[Chrisma]

OK, sounds like a plan. I'll try to reproduce it in a cut down version and upload it when I have something that's not as huge as what we have at present!

Chris

[dug9000]

Chrisma,

Keeping a module loaded should not cause it to use more and more memory each time it's called unless the code module itself is leaking the memory each time it's called, and, even in that case, unloading the module does not necessarily free the memory. I strongly suspect that module loading is not the cause nor solution to your leaking problem. Have you tried to narrow down what exactly is leaking memory?

Also, do you have result collection turned on (this is on by default)? If so and if you are running many steps over and over again within one execution, you might want to clear the result list or disable result collection if the results are not needed. As the result list grows in size so too does the memory usage. You can also disable result collection on a per step, per sequence, or per station level with step, sequence or station options dialogs.

Hope this helps,

-Doug

[Chrisma]

OK guys,thanks for your continued help. I've had a chance to look at this again and I've systematically removed each of the active components of the sequence to watch the memory usage without it. The active components are:

1. Excel sheet open, read, write and close.

2. Writing to a Labview Realtime VI.

3. Reading from a Labview VI.

4. Displaying Labview VI's for interim results.

Unfortunately all 4 items use memory that never gets released. The display VI's are the worst but each uses memory in some measure. Only when I remove calls to all 4 do I get my memory back after running the sequence.

I'll go back to Steve's suggestion and try to create a cut down version that I can attach that still has the same problem.

Chris

[Andrew McL]

Hi Chris,

Please let us know how you get on with adding a reduced version of your code. I had another thought, which maybe totally unrelated. In your LabVIEW VIs, are you calling the Excel sheet load from LabVIEW or from TestStand (say by using the activex steps)? If you are calling Excel from LabVIEW, how are you doing this? Are you using the Report Generation toolkit? If you are using the Report Generation Toolkit, which version are you using?

These may seem like strange questions but may help us find the root of the problem.

Many thanks,

[Chrisma]

Thanks Andrew. Attached is a reduced copy of the sequence. It has the Excel stuff still in there - it's all called from TestStand directly - no Labview involved with Excel. It also has the display VI's which will flash up. It has a call to an input VI that just returns and error because its interface doesn't exist but the output VI has been removed altogether. It only includes the PT1000 test so just enable this in the menu and hit start. When run repeatedly in sequence editor I find it gobbles about 20Mb per run. The real thing will do about double that and obviously once multiplied by the number of tests in the menu we're losing about 250Mb per test.

The excel sheet is also included as it reads from this initially.