Set Callback Parameter in Other Sequence

[aparab]

Hi,

I have to set  the  Continuetesting = False  if a SequenceFilePostStepRuntimeError Occurs

well I try to do it in   SequenceFilePostStepRuntimeError   Callback  
(when a runtime error occurs)

just  am not able to set it "False"

My Expr: RunState.SequenceFile.Data.Seq["PreUUT"].Parameters.ContinueTesting=False

any methods to do this right

[~jiggawax~]

Not sure I'm following your question correctly.  The SequenceFilePostStepRuntimeError is an engine callback that can get called by any step in the sequence file, including any steps in any model callbacks you are overriding.  So how would setting a parameter in some sequence be helpful if a step in another sequence errors out?  Is the error generated by a step in the PreUUT callback?  If so then you can just use Caller.Sequence.Parameters.ContinueTesting=False. 

If the error is not generated by a step in PreUUT then I would save it off to a FileGlobal (i.e. FileGlobals.ContinueTestingFlag=False).  Then in PreUUT assign that fileglobal to the ContinueTesting parameter.

Hope this helps,

[aparab]

Thanks Jigg for the fast response,

It is so

1.  If I detect a runtime error  in any step (any of my Test Steps) , it jumps to my "SequenceFilePostStepRuntimeError"  Callback .

2.  My Idea is to  Set ContinueTesting=False on condition 1  in the   "SequenceFilePostStepRuntimeError"  Callback .

3.  so now I donot test  another UUT and  the Test is aborted.

[Norbert_B]

I dont recommend you to abort a test in an case of error. Prefer "terminate".

Terminate will also add a popup in the default process model ("Handle Termination") which will already address the "continue testing" question. Is this not sufficient?

Norbert

[aparab]

thanks Norbert for the suggestion,

well at our place  we want all automation from teststand  but want  the test process to be as simple as possible for the operator.

he/she  wont (wont have time ) read  the instructions  terminate or abort, but traditionally just presses the Green or Red button(just a mechanical(brain) operator)

If error Press red -> abort the DUT  start again

Green -> go ahead with another DUT (loop)

and thts why  i   have to simplify the decision making  as much as i can

well  thts  the Game Plan...(hope tht  phrase makes something interesting)

one more ?

I have to change the DUT type i.e. have to enter PREUUT Loop  whts a better method to follow without  quitting the test and starting again.

eg i have to test 10 DUTs of Type1 once they have been tested  change of DUT (Type2) should I "GOTO"  from PreUUT to PreUUT Loop

or any other viable method

[aparab]

All in all  I am looking for method by which I can change the parameters in Subsequences(Callbacks also)  from other Subseq.  all in the same seq file.

that was the initial  Query.

[~jiggawax~]

The attached sequence file demonstrates what you are looking for.

Let me know if you have any questions.

Enjoy,

[aparab]

Thanks Jigg,

Well I had  Implemented the same  with File globals

but   would prefet to use the Globals cautiously.   can the same be done with parameters

[~jiggawax~]

First of all, congratulations!  Finally someone understands the importance of limiting FileGlobal usage.  It is worse to try and use the parameters in this case.  Because then you are changing the process model (which calls PreUUT).

My rule of thumb:

Use FileGlobals only in green or purple sequences.  All blue sequences should be parameterized.  It is very very very rare that I will use a FileGlobal in a blue sequence.

My next rule of thumb:

Avoid StationGlobals at all cost.  I usually get flak for this because people say "Why are they there then?"  But, I have never seen a case where I needed them yet and I've written hundreds of automations and have written several frameworks.  They are there to track the current user....haha.

Anyhow, point is- without modifying the process model you cannot change the parameters to any green sequences (unless you do it through the API dynamically which I would advise against).  Forget every modifying the parameters to the purple sequences unless you work for NI on the TestStand R&D team.

Regards,

[Norbert_B]

---

@~jiggawax~ wrote:
[...]

Avoid StationGlobals at all cost.  I usually get flak for this because people say "Why are they there then?"  [...]

---

My answer for this question is:

"For rather static and persistent configuration settings which refer to the whole machine setup (so for all kinds of UUTs you are going to test). Reason: StationGlobals are written to disk each time you shut down the engine and read each time the engine initializes. Convolution of StationGlobals will affect your loading times."

Most developers understand this, sadly they usually still keep on using StationGlobals as modifying things is "too much work for now".... 😞

Norbert