NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

How can I exit and restart LabVIEW from within Teststand?

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

0 Kudos
Message 1 of 11
(2,206 Views)
Sounds like a bandaid. What is the exact nature of the problem? What versions of TestStand and LabVIEW are you using?
0 Kudos
Message 2 of 11
(2,204 Views)

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

 

0 Kudos
Message 3 of 11
(2,196 Views)

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

Regards
Ray Farmer
0 Kudos
Message 4 of 11
(2,191 Views)

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

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 5 of 11
(2,186 Views)

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

0 Kudos
Message 6 of 11
(2,185 Views)

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
Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 7 of 11
(2,182 Views)

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

 

0 Kudos
Message 8 of 11
(2,177 Views)

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

0 Kudos
Message 9 of 11
(2,163 Views)

Hi Doug,

 

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

0 Kudos
Message 10 of 11
(1,470 Views)