I need some help....quick, Please!

[SimpleJack]

All,

I am all about solving my own issues, but I have spent so much time with this and I am at a hard deadline.

To make a long story short, my Teststand sequence calls labview vi's and works great. However, I have this intermittant hanging issue when calling a specific VI.

Here is the weird thing, my VI works fine and stable when running in labview. I am running a batch model in Teststand. If I set the model options to test only 1 unit in the batch, it works fine. As soon as I set it to 2 or more the vi with the system exec hangs. I have set the synchronization multiple ways with no luck.

If i turn tracing on, it is hanging at the systemexec vi and not outputing anything.

Please help. Labview 2009, latest teststand.

[JÞB · Accepted solution]

Ive run into similar issues running console applications from TestStand.  I have done a work around a couple of ways And it may be worthwile to attempt them.

First try setting the step properties to load the offending vi when called and unload it after execution

Second write a wrapper vi that uses a dynamic call to the offending vi and call the wrapper rather than the dynamic vi from TestStand.  

Of course a "Belt and suspenders" approach should be bullet-proof.

[SteelerFan]

Jeff,

You are a lifesaver. Changing the load conditions seems to have greatly reduced the issue by 99%. Although few and far between it still happens.

I guess the only thing left to do if I want to totally eliminate it is to "wrap it up".

One more question, could the fact that I am running this application on a semi-slow PC also exacerbate the issue?

THANK YOU!

Ryan

[JÞB]

Caution: Unproven working hypothysis ahead! Read with care.

My working hypothysis:

Calling a DLL from a console application by invoking System Exec.vi requires that Windows releases some (non thread safe?) DLLs BEFORE they can be reinstantiate.  Windows clean-up of resources is a lower level task. A VI that is still in the OS memeory may prevent or delay windows from releasing the resource.  Higher priority OS tasks may delay reseasing the resources.  THEREFORE: dumping the VI calling System Exec.vi from memory (either by dynamic call or by TS Load options or BOTH) improves the likelyhood that the OS releases the resource needed to reinstantiate the DLL.  Writing all vi's with an eye to prevent CPU hogging (use wait for next ms multiple in loops etc...) facilitates OS resource clean-up as well.

Again. I'm no master of Windows.  This hypothisis may be TOTALLY insuffient as to cause and effect.  But, like the "Dark-Sucking Theory" of lightbulbs, it provides a guidance for action that permit predictable responses to actions taken.

For those unfamilliar with "Dark-Sucking Theory" of lightbulbs.  Lightbulbs suck darkness and do not emit light.  Hence they appear greyish when they get full and stop working, when the dark sucking regulator fails a briliant flash is observed momentarrilly as the Bulb fills instantl, Replacement of a full bulb with a fresh one permits dark to be sucked again etc.... A TOTALLY incorrect theory! but a valid working hypothisis.

[Manooch_H]

SimpleJack -

I'm attempting to reproduce the behavior you're experiencing but have had no luck thus far. Could you perhaps provide the get_settings.txt file that the VI references and explain where to save it to disk along with the steps to take to reproduce this problem?

Thanks.

[SimpleJack]

Hi Manooch,

I think the issue has been solved. Changing the unload option fixed most of the issues, but the other 1% was my configuration settings on the device I was testing.

Thank you for the help!