[...]When I don't deliver the VI error path to "Step.Result.Error" it works!
this "workaround" can bite you some time in the future...and that could hurt.
So you should think about "what does that error mean for the system".
If the error is something internal to the code module, the code module has to correct it.
If the error is on system level, you must not drop it! Dropping it could lead to invalid tested UUTs, which, in worst case, test faulty ones as "Passed".
What you have to do is to implement a proper PostStepRuntimeError callback which revokes the error for specific situations, handle it (e.g. by logging) in others. In specific cases, the callback can shutdown the complete system to prevent hardware failures in the test system.
So depending on the "severity", you have to react.
I wanted to point out that proper error handling is
b) most often not simple
Of course, you are correct that an automated test system must not call blocking dialogs.... but simply not handling (aka "ignoring") errors isnt a solution either...
I have to confess that we only use TestStand as a simple sequencer
I outsourced the complete error handling and reporting to LabView (and Java). This is caused on the one hand in our "specific" design tests and on the other hand in inexperiance to handle TestStand in a suitable way.
Now I'm really smarter concerning TestStand...
This post has been edited by a Community Manager to remove inappropriate language.
If you are just trying to get rid of dialogs, you should not ignore runtime errors. ignoring runtime errors are for the case where the sequence itself is expecting and has code to handle the error. If you just want to not show a dialog on runtime errors you can change the station option for "On Runtime Error" to be "Run Cleanup" instead.