Using Callback functionality for sequence calls from additional Process Model Executions

[stefanha]

Hi,

we are using our own custom process model which implements many different callback sequences.

When these callback sequences are called by the process model from within the Testsocket executions or the process model's "main" execution, the behavior is as expected:
If the client file also contains the callback sequence, that code is executed instead.

However when the process model's "main" execution creates additional parallel executions and a callback sequence is called from in there, the TS callback functionality does not seem to be in place because in that case the sequence from the process model sequence file is always executed no matter if the client sequence file also contains that sequence.

I have dynamically created the Runstate.ProcessModelClient container at the beginning of that additional execution but that did not help.

How can I use the TestStand callback functionality for sequence calls from within additional process model executions?

Thanks,

Stefan

[Norbert_B]

Hi Stefan,

have you tried it in the same manner as the NI ParallelModel spawns the TestSocket Executions?

In case you did, you should share a simple example showing the way how you do it exactly.

[stefanha]

Hello Norbert,

the NI ParallelModel does a lot of things to "prepare" the TestSocket Executions.

For most of which I do not have the requirements to do the same thing each time I spawn a parallel execution from the process model, so it's kinda hard to replicate everything in order to figure out which one of the steps is actually required.

I have narrowed it down to the essentials in the attached sequence files.

The attached example calls a callback sequence from 3 different locations:

1. From the "main" execution of the ProcessModel directly

2. From a TestSocket execution, which is spawned from the ProcessModel without without any additional preparation steps

3. From a sequence, which was spawned as a generic "New Execution" from the ProcessModel

It shows that only the 3rd one of the calls does not have the Callback functionality in place, because in that case the template sequence from the ProcessModel instead of the overwriting sequence from the client is executed.

Looking at the example, it seems like the Callback functionality is only in place for executions which have originally been created as Execution Entry Points?

And following up to that, are the any significant drawbacks or sideeffecks to calling additional parallel ProcessModel executions as Execution Entry Points?

BR,

Stefan

[Norbert_B · Accepted solution]

Stefan,

Honestly, I never really thought about this.

The NI process models (Parallel and Batch) use Execution Entry Points to spawn each socket as each socket should provide the following features:

• Run independently from other sockets with a socket synchronization after each UUT for the BatchModel
• Enable full callback functionality from a client sequence file
• Have an individual report object for UUT report

Part of that spawning is to pass the ProcessModelClient as an implicit parameter to the new Execution Entry Point sequence. If you debug your example, you will find that using a break point in the Callback sequence of the client file, both Runstate as well as Runstate.Root.Runstate will have a ProcessModelClient container.

Calling your new execution without calling into an Execution Entry Point isn't "prepared" to use a ProcessModelClient container. You will not pass this and a break point in the Callback of your ProcessModel will lack this container. But since it is lacking, the whole callback mechanism seems to break.

So to answer your questions:

1. Looking at the example, it seems like the Callback functionality is only in place for executions which have originally been created as Execution Entry Points?
   I agree with this assessment as it passes the ProcessModelClient container in the background. You can do this manually (parameter and copy), but it seems to be more effort than to limit your selection of calling New Executions to use Execution Entry Point only.

2. And following up to that, are the any significant drawbacks or sideeffecks to calling additional parallel ProcessModel executions as Execution Entry Points?
   There might be some impact on performance, but I assume that these are pretty low. Besides, all disadvantages can also be seen as advantages:

   • Individual report object

   • Full integration to ProcessModelPlugins

[stefanha]

Thanks Norbert for the detailed explanation.

I have not been able to get the functionality working by manually transfering and copying the ProcessModelClient container.

Maybe either something else was missing or timing when the container was created manually as the first step of the sequence is already too late.

So I went with the approach of creating the Execution Entry Point, which worked completely fine in all tests so far.

Eventhough we do not want to use any of the TS reporting functionality etc. in there because these additional executions are mostly endless loops for individual tasks and no Testsockets for testing actual UUTs, since we have turned off most of that anways, I have not been able to detect any noticeable negative impact regarding performance or else.

So we will stick with your proposed solution of calling additional ProcessModelExecutions as Execution Entry Points.

BR,

Stefan