How can I exit and restart LabVIEW from within Teststand?

[BanjoBoy]

Hi,

I'm new to Teststand, but is it possible to exit and restart LabVIEW from within Teststand?

We got problems with Teststand and/or LabVIEW after running our test sequence a number of times, but if we exit and restart Teststand (and this also exit and restart LabVIEW) we don't see any problem.

So I would like to only exit and restart LabVIEW and keep Teststand to see if this will solve our problem.

Thanks

Bent

[Dennis_Knutson]

Sounds like a bandaid. What is the exact nature of the problem? What versions of TestStand and LabVIEW are you using?

[BanjoBoy]

Teststand v4.2.1 and LabVIEW v8.6.1 running on Windows XP Professional Service Pack 3.

We got many different problem like:

1) Run-Time Error in Teststand Error Code -17500 with no details

2) TestExec.exe crash with Windows error Send / No Send error report.

3) LabVIEW: Generic error. An error occurred loading VI 'nameof.vi'. LabVIEW load error code 23: There is not enough memory to load this VI.

4) and more errors like these.

The problem is NOT consistent and accure after a number of runs. But to trace the problem back to either Teststand or LabVIEW or our programming, I would like to exit and close LabVIEW after every run and then restart it at the beginning of the next run. Because when we exit/close both Teststand and LabVIEW after one run and restart it for the next run we does NOT expirence any crashes, Rin-Time Errors or any other problem.

So is it possible to get Teststand to exit and close LabVIEW and then restart it again?

Thanks

Bent

[RayFarmer]

Hi,

You can do an Engine.UnloadAllModules at the end of your test run.

When you say many runs, how many? Whats the size of your sequencefile in terms of Steps that record results?

Regards

Ray Farmer

[Norbert_B]

---

BanjoBoy wrote:
[...]

We got many different problem like:

1) Run-Time Error in Teststand Error Code -17500 with no details

2) TestExec.exe crash with Windows error Send / No Send error report.

3) LabVIEW: Generic error. An error occurred loading VI 'nameof.vi'. LabVIEW load error code 23: There is not enough memory to load this VI.

4) and more errors like these.

 [...]

---

Bent,

this sounds like leaking issues to me. So i bet that you have at least one (most probably several) leak(s) in your application. This can be limited to your LV modules, but might affect TS as well (references).

Finding leaks is one of the most time consuming tasks for debugging. The first thing to look for is

- Memory consumption: Is it rising over time? Can the increase be limited to the execution of a special module? Are datasets handled properly?

- References: Are all references closed as required? Some references can be closed by simply setting them to NULL (Nothing in TS), some require special shutdown routines (like a reference to a sequence file requires the ReleaseSequenceFile)

hope this helps,

Norbert

[BanjoBoy]

---

Ray Farmer wrote:

Hi,

You can do an Engine.UnloadAllModules at the end of your test run.

When you say many runs, how many? Whats the size of your sequencefile in terms of Steps that record results?

Regards

Ray Farmer

---

The number of runs are not fixed, sometime only a few times. We have 167 steps that record results per run.

Are you sure that Engine.UnloadAllModules will exit and close down LabVIEW?

Thanks

Bent

[Norbert_B]

---

BanjoBoy wrote:
[...]

Are you sure that Engine.UnloadAllModules will exit and close down LabVIEW?

Thanks

Bent

---

Bent

no, the UnloadAllModules does not garantee any shutdown of the LV runtime engine (LV RTE). It only tells the LV RTE, that your modules are not required anymore by TS. Therefore, if there are no other VIs running in the LV RTE, it is most likely that it will terminate and unload.

Norbert

EDIT: Please note that i see such approach as a workaround, not a solution regarding the original problem

Message Edited by Norbert B on 02-11-2010 04:17 AM

[BanjoBoy]

---

Norbert B wrote:

...snip...

EDIT: Please note that i see such approach as a workaround, not a solution regarding the original problem

---

My idea was to limit where to look for the solution and NOT to solve it. I have been asked to help and have not programmed it, so just to try limit it and to allow our production to continue while finding and solving the problem. Thanks for you advise, I'll try it.

Regards

Bent

[dug9000]

Are you running your LV VIs in the LabVIEW development environment or the LabVIEW runtime engine? I think some of those replying thought you meant the runtime engine when it sounds like you mean the development environment. Just want to clarify as some of the advice won't really apply in that case.

If you are running your VIs in the development environment then there is a way to do what you are asking. You will need to run your real mainsequence in a new execution using a sequence call step (this is so that it will restart labview after you make it quit, otherwise it will give a runtime error). Then in your root execution, after your real mainsequence is done, you can use the ActiveX adapter to connect to and tell LabVIEW to quit. Then use a wait step to give labview some time to exit. I've attached an example sequence which illustrates this, and shows you all the settings you will need on the sequence call step.

That said, the fact that testexec.exe is sometimes crashing too might indicate your problem is either making testexec.exe run out of memory too or is corrupting the memory of the testexe.exe process too. It might still be worth a try to do the LabVIEW restarting though.

Hope this helps,

-Doug

[Rex123]

Hi Doug,

could you please transfer your example to teststand 4.0, I have the same problem too. thank you.