Break during Shutdown

[TerrenceJ]

I've developed a custom UI based on the TestStand 2012 API and have found a strange behavior. I noticed that occasionally my application would not shutdown properly when an execution is running. I find that the Engine.Shutdown(false) method fails to display the "Prompt for Action" dialog if the execution breaks before the "When exiting" time limit.

My sequences have a feature that causes breaks on certain test failures to allow the operator to choose to repeat the test or to continue. Thus a break during a the shutdown time limit period is not uncommon.

I would expect the Engine Shutdown behavior to be deterministic and always either send the UIMsg_ShutDownComplete UIMsg_ShutDownCancelled message eventually based on the time limit. My only workaround to this is to force the execution to resume when I see a break while in shutdown mode.

The attached sequence demonstrates the issue. If the "Prompt for Action" time limit is greater than 0, the dialog will not be seen while execution is paused.

Any ideas on how to remidy this?

Thanks.

[dgriffin91]

From my understanding the RunState.Execution.Break() is going to break everything. So it is not a surprise that the "Prompt for Action" dialog fails to display.

When these breaks occur during the shutdown time period what do you want to happen?

[TerrenceJ]

Thanks for the response.

I would expect the shutdown timeout value to work as it intuitively should. That is, if the execution is running when the Shutdown occurs, after the timeout period (say 10 seconds), if the execution is still running or broken, the Prompt for Action dialog should display.

It makes no sense to me that an Execution.Break would affect the shutdown of the Engine.

I see the Shutdown sequence as described in Shutting Down the Engine as a contract. When Engine.Shutdown(false) is called the client expects either the UIMsg_ShutDownComplete or the UIMsg_ShutDownCancelled UIMessage. There seems to be race condition between a break occurring and the timeout period. How else can the client handle such a situation deterministically? The client has no way to know what is happening otherwise.

Thanks.

[dgriffin91]

As mentioned in the above "Shutting Down the Engine" link NI recommends that you call the ApplicationMgr.Shutdown method to shut down the engine for an application you develop with the TestStand User Interface (UI) Controls.

Additionally, I could not generate the Prompt for Action dialog with the above zip file even if I remove the break. Do you have another zip file that shows the sequence file executing correctly?

[TerrenceJ]

I am not using the ApplicationMgr in this project, only the Core API. Though I wouldn't be surprised if the ApplicationMgr also exhibited this issue.

The previous exampled would not show the Prompt for Action dialog when the break is removed because the execution will end before the 10 second (default) timeout period.  The enclosed sequence will demonstrate the dialog after the timeout period expires.

Thanks...

[dgriffin91]

So it seems that the RunState.Execution.Break() causes the timeout to pause. 

See the attached Shutdown Sequence. In this sequence I wait five seconds between the RunState.Engine.ShutDown and the RunState.Execution.Break. Then if you restart the sequence it only takes five seconds for the prompt for action dialog. Thus, the RunState.Execution.Break is pausing the timeout clock.

[TerrenceJ]

Thanks for the response...  Yep, I agree. 

To me this is a bug in TestStand (or at the very least the documentation). What is the recommended procedure for handling a break after Shutdown(false) was called?

Thanks.

[dgriffin91]

So do you not want to handle the break and then continue the shutdown of the engine? I ask this becuase as soon as you handle the break the engine shutdown will continue. I guess I am having trouble understanding what you want to happen when the break occurs and why you want that to happen. Really, I guess my question is what is your overall goal?

[TerrenceJ]

The behavior I expected to see (and that which I would prefer) would be: once the Shutdown(false) is called, the 10 second shutdown timer would start its countdown. After it expires the Prompt for Action dialog would be displayed. This would happen regardless of whether a break so happended to have occurred during that period.

As for handling the break automatically; there could be unintended concequences if I were to resume automatically. In my system a break may occur when the operator is given a choice to re-test a failing test. Continuing from the break skips retest, pressing a UI Retest button repeats it. If my shutdown sequence were to automatically Continue, the Prompt for Action Dialog can then appear. If the user had pressed Close by mistake and chooses then to cancel the shutdown, they have lost the opportunity to retest the failing test.

The Prompt for Action dialog is very well suited to handle the situation regardless of whether the test is running or broken. But I suspect that there is something in the way that it is implmented that doesn't allow it to operate when the execution is broken.

What I would like out of this question is an understanding from TestStand as to what exactly the expected behavior is (rather than discovering through trial and error), perhaps reconsideration of the implementation (I recognize this is unlikely), and an update to the documentation of the shutdown proceedure and the Prompt for Action timeout to state that a break stops the shutdown proceedure.

As for my situation I'm considering workarounds. Most obvious would be to never call Shutdown while an execution is running, I would have to prompt the user myself in that situation. Perhaps I should use StationOptions.GetTimeLimit() and mimic the standard behavior with my tweak as described above.. Alternatively I could recognize the break happening during shutdown and prompt the user for action, taking into consideration my retest capability.

Thank again.

[dgriffin91]

 I didn't mean have the break handled automatically. Why can't the operator handle the break? If he wants to retest he can retest. If he wants to continue then let the timeout occur. 

Also, why are you trying to shutdown the engine while executions are running? Is there a reason that you can't wait to shutdown the engine until after every execution is complete?