"Run VI Asynchronously" - Error Handling

[Stefan_Bieder]

Dear all,

I have problems with the error handling for the step type "Run VI Asynchronously".

If the VI, which is run asynchronously, generates an error, I want the sequence to fail and I want the error description included within the report. 

Attached, you can find an example sequence: The user can decide by means of a message box, whether a VI is to be run asynchronously or as normal "Action". The VI simply always generates an error.

Running the VI as normal "Action"gives the wanted result. Running the VI asynchronously results in a passed sequence even though an "Run-Time Error" window pops up with the correct error description. But although I "Run Cleanup", the sequence passes. Does anyone knows, how I can manage to get the wanted behaviour?

Thanks in advance

Stefan

[dug9000]

Use a wait step (one of the synchronization step types) somewhere before the end of your main sequence. The wait step will get the results of the asynchronous sequence for which it waits (including error and pass failed state). On the wait step, choose "wait for thread" select the asynchronous VI as the sequence call, or use the option of storing the thread in an Object Reference variable and use that variable as the one to wait on with the Wait step. Because the VI is running asynchronously there is no guarantee it will finish before the mainsequence does unless you add a wait step like this, that is why it doesn't really make sense for the state of the asynchronous thread to automatically carry over to the mainsequence unless you wait on it.

The run VI asynchronously step type is really just a special way of configuring a Sequence Call with the New Thread option and automatically creating a subsequence for it to call with that VI in it.

Hope this helps,

-Doug

[AndreasStark]

Hi Stefan,

what exactly is the application you are trying to implement?

Right now your problem is that TestStand already logs the result of the step before the VI is executed. This is simply the asynchronous nature. You can launch your VI successfully, so the launch step is successful.

If you want to accomplish the behaviour you describe you either need to implement a step in your sequence that checks the status of your asynchronous thread. This step can fail if the async operation failed and cause the sequence to fail.

If you want to do parallel operations you can use the batch model and define your UUT as a batch (then you would have to modify the nomenclature of your report). In your batch sequence you could use the "RunState.TestSockets.MyIndex" property and then launch sequence 1 or 2 depending on the test socket.

But as I mentioned at first, it really depends on your application.

Regards,

[Stefan_Bieder]

Hi Andreas,

thanks for your explanations.

My application for using "Run VI Asynchronously" step is running a measurement VI in the background, that continuously acquires and evaluates a digital modualated signal using the NI PXI-5661.This VI stores the measurement results in a functional global variable. Within other TestStand steps, this functional global variable is simply read out.

Since an error can occur within the measurement VI, I need to have the sequence fail in this case and to log the error description in the report.

By the way, right now, I use the standard SequentialModel.

Regards,

Stefan

[AndreasStark]

Hi Stefan,

if you use a functional global then you could simply store the error cluster as well and use it as the error out from your read steps.

Another question:

Is the asynchronuos thread executed per UUT or is it running as long as your TestStand execution runs?

Regards,

[Stefan_Bieder]

Hi Andreas,

storing the error cluster within another functional global variable is a good idea. I think, I will follow this way!

To answer your question: The asynchronuos thread is executed per UUT.

Thanks for your help!

Regards,

Stefan