Is there option to Break on error

[lordsathish]

Like LabVIEW does TestStand has options to break on error.

There are option to break on step failure... But could find this one. 

[Scott_Richardson]

This is not a direct setting for this because there are two things that must be decided on an error. The first is what to do next: prompt, goto cleanup, ignore error, or abort. Then we need to decide to break or not. The first settings default behavior is decided by the Station Options>>Execution>>On Run-time Error setting. If you choose prompt, you are given the option to select what to do next and you can decide to break or not. Is there a reason that you do not want to use this prompt?

You can programatically control the decision to break by placing a SequenceFilePostStepRuntimeError callback sequence in a specific sequence file or a ProcessModelPostStepRuntimeError callback sequence in a model file. These sequences are called when an error occurs but the scoping is different. In the callback sequence you can add a step that calls RunState.Execution.Break(). However, this will force a break in the execution in the callback when an error occurs and not the sequence that errored. You can manually step out of the callback to get back to the erroring sequence.

For TS 4.0 and later UI, you can use the ApplicationMgr_BreakOnRunTimeError event to catch the error and then decide what to do. So if you are working with a UI, the solution should be relatively easy. This option is not easily accessible for the sequence editor because you cannot update the sequence editor source code. It is more complicated, but it should be possible to create a component that gets the application manager using GetInternalOption and then creates an event handler to catch this event. Customers have done this for other things, so this should be possible.

[Evan P.]

Hi,

Head to Configure»Station Options... Select the Execution tab and see the On Run-Time Error: option. By default when a sequence encounters an error, a Run-Time Error dialog is shown (as indicated by the default value of this field -- 'Show Dialog'). This dialog will break execution to give you information about the run-time error. It also gives you an option of how to handle the error (Cleanup, Retry, Ignore, Abort) and the option to break (after choosing "OK" to close the dialog). Your selection for the break field will persist until you restart TestStand.

Keep in mind that a code module error or step failure does not logically translate into a sequence run-time error. If you would like to break sequence execution on a particular step error, the simplest way is to set a conditional breakpoint with the condition to Step.Result.Error.Occurred.

Hope this helps...

EDIT: I wrote this post as Scott was posting apparently 🙂 - Since our content is a bit different, I'll leave this post up.

Message Edited by Evan P. on 12-04-2008 09:44 AM

[lordsathish]

Hi ppl...

Thanks for your replies. I know this feature that the default error dialog has an option to break. But I'm not using it. Instead i'm using the PostStepRunTimeError CallBack... In this call back I'm replicating the same dialog. But it does not have option to break. I want to use this break on error only during development. So i didnt not include it in the CallBack... for testing the code while developing it, is there any station options to set Break on error by default....?

[jsiegel]

After reading Scott's comment about using the Engine.GetInternalOption() function to access the ApplicationMgr_BreakOnRunTimeError event, I decided to try it myself.  For the first step of a test sequence, I pass RunState.Engine.GetInternalOption(InternalOption_ApplicationManager) to a LabVIEW code module.  The VI registers a callback VI for the ApplicationManager.BreakOnRunTimeError event.  The callback VI dispays an error dialog and sets the showDialog event data to False and the BreakExecution event data value to the value selected by the dialog.  For the second step of the sequence, I generate a runtime error by setting Step.Result.Error.Occurred=True.

This scheme almost works--when the second step generates the runtime error, my callback VI correctly displays the dialog and then the sequence execution continues or breaks, depending on my dialog selection.  But the event doesn't seem to get cleared.  if I run the sequence a second time (without telling TestStand to unload modules), I get the dialog in my callback VI twice.  If I run the sequence a third time, I get three dialogs.  etc.  Unloading all modules (from the TestStand File menu) seems to clear out the events.

I vaguely recall reading once that if you handle runtime error events yourself, you have to tell TestStand that you have done so.  Is that what I should be doing here?  What am I missing?

[Scott_Richardson]

lordsathish -

Your only option is to call Execution.Break, but it will break in the callback and not the context of the step that caused the error. I have written a suggestion to add new API to help with this, specifically to possibly add a SequenceContext.Break method, which would allow you to define a break condition in the parent context.

I do not know if this suggestion is appropriate, but if your non-development users will always be using a UI and not the Sequence Editor, you could use the BreakOnRunTimeError event directly in your UI and prompt them as you see fit, including allowing developers to break if you want. If developers are using the Sequence Editor, you can use the default dialog that TestStand displays.

jsiegel -

For UIMessages, you should call UIMessage.Acknowledge, but BreakOnRunTimeError is not a UIMessage, it is an event that is caused by a UIMessage. I suspect the reason you are seeing multiple event calls is because each time you run your sequence, you are registering the callback again. You should only register the callback once in the beginning and unregister the callback once when no longer needed. Unloading modules likely unloads the VI and unregisters the callback.

I believe our documentation recommends that VIs that are used to handle events should not do all that much, especially with API calls back into TestStand or displaying prompts. There are some hang conditions that can occur when doing this, but you are not seeing this at least. If in a UI, we typically recommend posting a corresponding LabVIEW message back to the UI to handle the event, but deferred.

Message Edited by Scott Richardson on 12-08-2008 02:15 PM