Calling TestStand API Method Development vs. run-time

[allenhunsaker]

In LabVIEW, I am calling the ActiveX TestStand Engine which contains a method 'NewExecution' using a file 'Configure Result Processing.seq that works on my Development PC but does not work after installing the distribution on a production PC using only the run-time engine. LabVIEW and TestStand are both 2019 32-bit. See the code snippet below.

I have searched my development PC HD for any instance of that sequence and cannot find it. Perhaps I misunderstand what this code is doing. My predecessor wrote the code, so I do not know from where he got the sequenceNameParameter value you see in the snippet.

An error occurs when executing this code that says.

ILTE Operator Interace.vi is the LabVIEW code from which the code snippet occurs.

Any ideas about what is wrong. Is there some option in the Distribution Wizard for the run-time that I need to check? are there files I need to include for the installation?

[~jiggawax~]

My guess is that on the deployed machine you haven't installed the process models or you haven't set up your station model correctly.

The first call you have is getting this sequence file:

https://www.ni.com/docs/en-US/bundle/teststand-api-reference/page/teststand-api-ref/engine_getstatio...  Which is your process model.... default is SequentialModel.seq

Then it is invoking the result processing configuration entry point using this method:

https://www.ni.com/docs/en-US/bundle/teststand-api-reference/page/teststand-api-ref/engine_newexecut...

Which gives you the result processing dialog.  

The other option is that this code was maybe written for a custom process model?

Also, just so you are clear: there is not a single difference between the TestStand engine in deployed state vs development state.  The difference in licensing is just what api methods can be called.  Neither of these should be restricted by either license.

[Scott_Richardson]

Does the code work on your development PC when you configure the LabVIEW adapter to only use the runtime engine?

The code is a little odd in that is creates the execution and immediately closes the execution references. Closing the execution reference could potentially destroy the execution object. Normally code should wait for the execution to complete in some way, so either storing the execution somewhere for later checking or just using API to wait for it to complete. A quick test might be to leak the execution reference to see if that changes the behavior.

You are passing an automation refnum to processModelParam, so not sure if the LabVIEW Dev vs Runtime handles this differently if the value is not specified. You could check your code to determine what is being passed for that. that it is a proper reference. Not sure what might happen if that was not assigned for your workflow. The help suggests a NULL object reference in LabVIEW, but not sure how to do that.

I agree with jiggawax that licensing should not matter for this.

[allenhunsaker]

Okay.. that's helpful...

This is a custom sequential process model named IL_SequentialModel.seq

How would invoking the TestStand Engine know what process model to use?

Is there an option in TestStand to pick or override the default process model?

Would the custom Process Model contain the New Execution reference to the Result Processing sequence?

I'm a long-time user of TestStand (since it was called Test Executive before NI bought it) but have never had occasion to mess with the default process model. There's a lot of this I'm going to have to learn.

[allenhunsaker]

Yes, the code works whether in development mode or in run-time mode. Also, a previous version of this code also written by my predecessor, works fine with run-time engine on one of the production systems. I am not allowed to mess with that system at all since they only have two and the one I am trying to get on to the new code is down because of this problem.

This LabVIEW code is used to invoke a TestStand sequence selected by the user for whatever product they are testing. The process model must be invoked somehow when the LabVIEW exe is launched. I am assuming some callbacks are involved as LabVIEW exe launches. Not sure how that happens exactly but it makes sense.

So, I'm thinking that the callbacks in the ProcessModel might have a mistake. If so, then I will have to track down that callback sequence I guess.

Or there is some option when building the Distribution that I need to check.

[~jiggawax~]

In the Sequence editor you can go to Configure>>Station Options and click on the Model tab.  That's what sets the default process model.  This is stored in the GeneralEngine.cfg file in your cfg folder for TestStand.  That probably needs to be set on the machine you are having issues with.  You can deploy that file or manually set it up.

Also, because you have a custom process model, I have no clue what dependencies you'd need without looking at it.  You need to make sure they are all deployed properly and in the right locations and that the search directories are set up correctly.

[allenhunsaker]

The Gap in my understanding is how this works.

If I create a custom process model and a several different custom test sequence then,

Create a LabVIEW UI for the operator to choose the test sequence.

How does the VI invoke TestStand, simply by using the Test Stand Engine ActiveX in LabVIEW I assume.

But, from what you said, how does LabVIEW launch a specific TestStand Process Model.

Does including the ActiveX automatically launch the selected TestStand sequence and run PreUUT callback.

How this works in general from LabVIEW is still a mystery to me.

BTW, I have the Custom Process created in TestStand 2022. Is it possible to save it in TestStand 2019. Not doing any backward saving in TestStand as of yet.

[Oli_Wachno]

---

@allenhunsaker wrote:

[....]

How does the VI invoke TestStand, simply by using the Test Stand Engine ActiveX in LabVIEW I assume.

But, from what you said, how does LabVIEW launch a specific TestStand Process Model.

[...]

---

You tell the Engine to run a specific sequence file using the Engine.NewExecution Method

One of the arguments of thos method is actually the ProcessModel to be used.

Maybe you find the example more helpful than your existing code.

---

@allenhunsaker wrote:

Does including the ActiveX automatically launch the selected TestStand sequence and run PreUUT callback.

How this works in general from LabVIEW is still a mystery to me.

Going through the examples should make a lot of things clearer for you.

Just think of LabVIEW telling TestStand to go ahead and do its' thing as you'd expect it to do when started from the Sequence Editor 🙂

[allenhunsaker]

OK, I'll go through the examples. but the question was about knowing EXACTLY what I would do in LabVIEW that would start the TestStand sequence. Or specifically start the Process Model sequence. but thx again for your help.

[~jiggawax~]

Allen,

Have you taken the TestStand courses?  This is covered in those, specifically the architect course.

There are a few things you need to understand: Client Files, Executions and UIs

Client Files

In TestStand a Client File is a sequence file that is assigned a process model or is meant to work with a process model.  It has to contain a MainSequence sequence that overrides the MainSequence call in your process model.  Most TestStand development is done in a Client File.  Client Files can be attached to a process model in multiple ways.  One is explicitly set it for the Client File.  The second is to use the Station Model (if not explicit it defaults to the station model).  It's important to understand this because when you start an execution in TestStand that's how it knows which process model and entry point to call.

Executions

Executions occur when you "run" a sequence or sequence file.  The TS Engine basically creates a copy of your sequence file or sequence or step and then "scripts" through it.  There are 2 types of executions in TestStand: Normal and Interactive.  Interactive means you are running without a process model and you explicitly just want the TestStand engine to run this sequence only or these steps only.  Normal execution will execute an Entry Point in the Process Model and then Callback to your Client File (meaning the starting sequence file) at certain times (the most common being MainSequence).

UIs:

Here's a GLA Summit presentation I did on UIs: https://www.youtube.com/watch?v=O-iQ5o4LYV0&ab_channel=GLASummit

The main takeaway here is that a UI hosts the TS Engine and then you can use either ActiveX controls to do all the heavy lifting for you or you have to explicitly call into the APIs and do the heavy lifting yourself.  In your scenario above you are doing the API route (generally not recommended).

Hope this helps,