automatic Retry run-time error step in TestStand

[alex b.]

Hi, I am using an instrument at many places in my sequence (let's say 5 times). I am using the Labview instrument driver. Sometimes (every 50 calls), the instrument driver call gives me a run-time error because the instrument is somehow busy. But usually by doing a retry on the step that caused the run-time error, it works. However, in few cases, the instrument is really defective. In order to make my sequence more robust, I want all that handled in TestStand (I want the operator to stay away from the big grey popup. Many of them freaks out when they see this…). I was thinking adding 2 callbacks to my sequence: 1)        Post run-time error: a.        If local “index” == 1, run cleanupb.        If “index” == 0, retry the current step (by manipulating the current step id)c.        Incrementing “index” to 12)        Post step:a.        If step.Result.Status != “Èrror”, ”index” = 0 Index is a local variable in my sequence This algo might work, but is there another way of doing this? You can loop on the failures, but not on the errors.  

Thanks

Alexandre

[j_dodek]

Hi Alexandre,

if you like this: (I want the operator to stay away from the big grey popup) you may disable this for you maschine ! Under StationOptions Tab Execution there is dropdown List "On Run-Time Error" there you can select "Run Cleanup". Now you can perform your error handling

there.

Hope this helps

Juergen

[Norbert_B]

Alexandre,

there are many ways to accomplish your task.

Here's a small list:

- Disable default error handling and "do error handling in your sequence" (using gotos with precondition) 

- Use the SequenceFilePostStepRuntimeError Callback

- Handle the retry-functionality within your codemodule

I'd suggest you to choose either the second or third option. As Juergen already stated, you can alter the behaviour of TS in regard to runtime errors. The default behaviour displays a dialog asking the operator on how to react. On automated systems, this setting is nonsense, therefore it is suggested to switch to "Run Cleanup". I wouldn't choose any other setting here.

Using the Callback Sequence is nice since it can be used in a very general way and you can call certain alternativ test strategies if the instrument fails to work.

Implementing the error handling within the codemodule nevertheless optimizes execution times and could be better in other aspects as well. But on the other side, you have to deside what should happen if the error cannot be solved by the module itself.....

hope this helps,

Norbert 

[j_dodek]

Hi Norbert,

Thanks for pointing the SequneceFile Callback ! I have forgotten it

You are right about the nonsense becaue

in all my stations in procduction field i have activated the pop. This is the

extremly good way to find MY own programming errors. If you disable

this you will never get suitable results.

I just want to point out that there is a Station wide setting where you can

can turn/off.

Thanks

Juergen

Juergen 

[alex b.]

Thanks all!

It confirms what I had in mind ( I just saw that my little algorithm using the Post runtime error and Post step callbacks was diplayed all fuzzy. Thanks to copy-paste from Word...).

Alexandre

[Swim32]

I know this is an old thread, but i have another method for the same thing, easier in my opinion:

- Make Custom Looping on the step

- Loop While Expression:let's say you want to try 4 times before stopping and only need one "pass" ( = one iteration without errors)

       (RunState.LoopIndex < 4 && RunState.LoopNumPassed < 1) && !Step.Result.Error.Occurred

-  Loop Status Expression:   RunState.LoopNumPassed >= 1 ? "Passed" : "Failed"

This way you don't need to modify your vi's and dont have the callbacks.

[foxx]

how can i track if in a "big sequence" a step had an error (= and looped for e.g. 2 times)