TestStand Failure Chain

[Zuc_Lab]

Hi,

I will check that container Thanks!

I have changed a bit the sequence for testing what I need (the step Id of all the chain), I upload it here. My problem now is in the SubSequence call, since the step Pass/fail in it seems not to go any further then a CallStackDepth equal to 2 as SequenceCallThread, which is called in a Separated Thread. By trying some combinations, I have seen that this behaviour is related to the fact that the Wait for thread step is after that Pass/fail. If I move it before the step everything change (in my real sequence I can’t do that unfortunatly). I can’t get why this happens because the threads are separated so I have expected to have a way to understand for each step in which thread it is so that I can compute the correct CallStackDepth for that step.

What am I missing?

I hope to be clear in my issue, Thank you for the help!

Best Regards,

Zuc

[Zuc_Lab]

Hi,

I don't get exactly the difference between CallStackDepth and CallStackSize and neither the reason why, for avoiding exception and out of index errors, I have to consider the -1 in the computation of the Stack size of MainSequenceCallback thread but not in the one of a sequence called in a separated Thread in the MainSequence, but I have ended up with this sequence that can help someone who is in need like me.

Fell free to ask and suggest ways to improve it!

Does anyone have any advise on how to record my variable Locals.IdPath to a MySqlDatabase using teststand? Or is it better to use an external component like a .NET library?

Thank you for the help!

Best Regards,

Zuc

[Oli_Wachno]

Hi,

I have to admit, I don't totally understand what you are describing, yet I took a look at your sequence file.

You have placed the call stack evaluation into a ProcessModel callback, which is a good idea code-replication-wise. Yet doing so, you are actually changing the context of the call stack evaluation from your client sequence file to the ProcessModel, so your code is not analyzing what you want it to 😉

Set breakpoints and you'll see!

[Zuc_Lab]

HI Oli,

My doubt is about how TestStand manages the Threads, since if you see the Call Stack tab during the execution the only way to have the ID of the Failed step and the one of the Sequence (which is running in a separated thread) which as called that step is to set the CalStackSize to two (so in the for loop you will run 3 times). But if you do the same for a sequence called in the MainSequence if you use the same confition in the For loop you will encounter an out of bounds error. It seems like you have gone futher in the CallStack array.

I don't get this difference in behaviour in TS, it sees the CallStach as a zero based array or not?

"so your code is not analyzing what you want it to" what do you mean with this sentence?

Best Regards,

Zuc

[Oli_Wachno]

---

@Zuc_Lab wrote:

[...]

"so your code is not analyzing what you want it to" what do you mean with this sentence?

Best Regards,

Zuc

---

The point I was trying to make is, that by using the SequenceFilePostStepFailure Engine Callback, IMHO Thread information will vary depending on the ProcessModel used and the number of sockets.

Having said that: please allow some time if you want me to dig deeper into this. This is not a thing, I am doing on a regular base 😉

[Oli_Wachno]

Hey Zuc,

please check the attached file. I intentionally left some additional code, variables and breakpoints in there for the sake of debugging.

To my understanding, this does (most of) the job.

If you take a look at the assembled call stack string in the SequenceFilePostStepFailure, you will see, what I meant by "different context": since the code is moved to the Engine Callback, the CallStack has an additional element, but I guess you'll find a way to handle this

Cheers

Oli