NI TestStand

Showing results for 
Search instead for 
Did you mean: 

TestStand custom UI (API) examples or pseudo code is lacking.

Go to solution

Ok... maybe I'm just in a complainy mood.


My basic ask is for an example or pseudocode that demonstrates running multiple sequences from LabVIEW using the TS API, NOT the TS native controls.


My approach is to use a UI that allows the user to select a set of sequences that can run multiple times, repeated, or even run repeatedly for a specific amount of time. All things that a LV built UI can do and provide easily. Then to use the power of the TS API to run each sequence file in order, allowing the TS API to perform the test parameters (results) and reporting functions. Exactly what TS is good at.


So what I need is:

1) Calling a sequence from LabVIEW using a specified process model

2) Cleaning that process up when the sequence is complete so another sequence can be run

3) Maybe some examples of report control showing merging multiple runs together and storing to a specific location

-Yes, I know that's a lot. #3 would be a nice to have. I could probably handle all of that post process in LabVIEW.


The examples that come with TS within the "Executing Sequences Using API" (specifically the LabVIEW examples) uses the assumption that when being called from within a step in TS, that the "Sequence Context" reference is just used. That is not the same as how a developer would use that example when being called from a custom UI. I dare say that the examples in this section are redundant. Why would a developer use a VI to make API calls from within a step of a sequence when the capability is already there....  just call the sequence. If the intent was to demonstrate calling a sequence from LabVIEW, yes, technically the requirement was met, just maybe not in the most practical manner because it's not that easy.


As alluded to, the examples demonstrating and referencing using the TestStand Native Controls (something that is most recommended) is just providing a different means of interacting with TS itself. Basically a new UI plugin. Unfortunately there are assumptions made of how the user interacts with TS and not how a programmer would want to interact with TS. (Did that make sense? - Maybe it's better explained in the ramblings section below.)


From here on, it is rambling, complaining stuff. Kudos to all who read it.


I have searched for information with regards to using the TestStand API within LabVIEW and what I've found is almost a circular reference when it comes to examples. Refer to this discussion: 

The pat answer to someone desiring to develop their own UI seems to be "reference the UI examples that shipped with TS". 
I find this sorely lacking because those examples are more plugin variations on the same TS theme. While using the TS native controls looks great and easy from a point of view, there are cases where we as developers want to create a custom UI that uses ALL of the power of TS. That's what it's there for.
I don't want this to be a gripe session (it is); I'd like to find solutions, but here are my gripes:
1) The UI examples that ship with TS assume the developer wants to create a simplified TS interface, not a full featured custom UI that can run multiple sequences automatically, repeatedly, or over a set period of time, based on how the UI presents the sequences (probably as an array of sequences with paths) so that TS can handle all of the things it's good at such as results and reports.
2) There are no examples (or pseudocode - that I have found in a LOT of research) that demonstrate effective calling of methods and properties from a programming language (LabVIEW specifically) that address the calls and properties that are required to run a sequence directly using the TestStand API.
3) This is a complaint and it's on me. The documentation for the TS API is not as professional as I feel it should be.
3a) Get rid of all of the "you"s.
with regards to the last parameter.
"callingSequenceContext As Variant

[In] [Optional] If you are calling this method from inside of an execution,..." .


Leave me out of it.

It should be:

"callingSequenceContext As Variant

[In] [Optional] If calling this method from inside of an execution,..."


I have noticed this style of writing used throughout the NI website. It's my opinion, take that for what it's worth, but as professionals across the board, we should strive for professional sounding documentation. Along the same lines, I absolutely HATE when someone asks me, "How are "WE" doing today?" I may not care how you're doing and I resent the implication that your happiness or lack thereof could be reflected to me.  (Still reading?)


3b) Provide more links.
Case in point:
I have enough experience I can usually find where to get the parameters from, but a website is supposed to be helpful. Provide links for each of the parameters so a less experienced developer can find where to get it from. Don't frustrate the users!
My apologies and my appreciation for any suggestions provided.
0 Kudos
Message 1 of 7

How are we doing today?


I'm glad that the forums could act as a therapist for you..... sorry you are frustrated by all of this.


Also.... I tried to join the zoom meeting you linked but.... no dice! Apparently JB was not holding the meeting at the moment.


Ultimately, the reason that the native TS UI controls exist is to save developers a lot of time and pain.  Essentially underneath the hood there is a lot of communication between the manager controls and many of the UI controls.  For example, if a sequence file is not loaded into one control then the execute button should be greyed and hidden....however, I'm sure you are aware of all this.


I agree that it can be frustrating learning a new API.  I felt the same way my first time on MSDN.  However, after much use and getting used to it then it seemed to come naturally.  As is true with the TestStand API.  Personally I think their documentation is superior compared to most API documentation out there.  Maybe it is a bit "folksy" as you point out but that's my style I guess.


I will try to address your 3 needs:

1- There are many examples out there to call a sequence through the API if your google fu is up for the task.  Ultimately, you need to understand what it really takes to actually execute a sequence file.  You need an engine, you need to open a sequence file and you need to start an execution.  Understanding this is basic TestStand 101.  Doing it through the API is a different beast.  Methodically I would go to the engine object, because most things start there if I'm not using the manager controls, and then I would look for a method that starts an execution.  from there it is just a matter of understanding the parameters and working back from there.  Sometimes I admit that it is a little bit of trial and error.

2- This is definitely a touchy subject in TestStand.  Rule of thumb... if you opened it... close it.  No property node should have an empty terminal coming out of it on the top right corner.  If it is empty it needs to go to a close reference node.  The only real tricky one is closing the sequence file properly.  I'll assume you use Engine.GetSequenceFileEx to open the file.  If this is the case then you'll need to follow these instructions:  Look closely at the solution.  Close reference AFTER the release.  Release always needs to happen, that is called out specifically in the GetSequenceFileEx method documentation.


3- Not even sure where to begin with this one.  You can override report callbacks to change the report location based on UUT part number or serial number.  Or you can change the settings in the report options to merge reports into a single report.  Or you can create your own plugin.  It's very flexible depending on your specific needs.


I think ultimately the problem with TestStand is that it is so flexible, it is almost impossible to have an example of every way someone might use it.  Typically there is an out-of-the-box way to use it and that's sort of what's expected.  And for most cases it works just fine.  It's the deviations that it begins to get tricky.


I threw the attached example together in about 5 minutes for reference.  It's in LV 2019.


Hope this helps,

~Will work for kudos and/or BBQ~
Message 2 of 7

LMAO!!  WE are doing fine!




The link was supposed to be this one for point #3:


Too much angst and further proof that I cannot multitask....  I guess I need to listen to my wife too.


Yes, it was therapeutic yesterday to utilize the forum.  It helped!!  I did apologize yesterday and I will do it again.


I also agree about learning APIs. I probably had the same issues when I learned some of the others that I know, especially MS ones. I think the straw that broke my back yesterday was that I went through systematically, made all of the calls to the engine that I thought would make sense based on the examples that I was referencing and then when I ran it, I kept getting an error that an input parameter was null. 


This was on the "IEngine.NewExecution". I had valid references for the sequenceFileParam and the processModelParam. I gave "MainSequence" for the sequenceNameParam, "F" for breakAtFirstStep, "0" for executionTypeMaskParam and the other arguments, I left blank.


With an exception being returned that an input parameter was null, checking all of them except the optional ones, and seeing valid, non-null, values, I let my frustrations boil over.


I looked at your example and except for minor differences, it's pretty much what I have. 


I like your use of the SequenceFile.GetModelSequenceFile to get the reference to the process model and since I am using the standard "SequentialModel.seq" I can use that.


The biggest difference between our VIs is that you use "Test UUTs" as the entry point to the PROCESS MODEL!!  I totally missed that and thought that what was required was the entry point within the sequence that I wanted to run!!  So, I was passing "Main Sequence"!! Looking back at the "Executing Sequences Using API.seq", "Execute With Process Model", I see that the entry point used there is "Single Pass".  As always, a small thing, a huge consequence!!


Thanks for the additional calls for the report location and viewing. I agree that I want to stay out of that area of the API and IF I want to merge reports, or do anything special I will do it in LabVIEW.


TestStand is powerful and flexible. It can bring out the best in us and the worst. 


It looks like with that minor tweak, it's working.  NOW, I have an issue with the fact that I'm running LabVIEW 2019 32-bit and TestStand 2019 64-bit. As I ran the process, I got a popup asking me to locate the "modelsupport2.dll". I found it but it was the 64-bit version and I discovered really fast that LabVIEW 32-bit runs TestStand 32-bit processes. It makes sense, but it's not always something that is thought about!!  


Do you know if that would be resolved by going to LV 64-bit?!  Or is there a parameter in the ini file that would force LV to run TS 64-bit processes?!  SO CLOSE!!


Thanks you for your help and laughs.


Finally, if I could find a way to give Kudos to all who read the tirade from yesterday, I would.  Actually, if the readers were to respond with a short "read it" or "what an ***" then I could give a Kudo.


My appreciation and my apologies. - Thanks jiggawax!!

Message 3 of 7

Then I STILL got the wrong link.


Ignore the link. That's not the link we're looking for. there is no link.....

0 Kudos
Message 4 of 7

No need to apologize... we've all been there.


I'm glad WE (haha) are making progress.  I haven't used 64-bit much but I assume that would be the case.  You could copy my VI, open it in 64-bit LV and run it and see if it calls the 64-bit engine.  I do know that both the 64 and 32 bit TS engines are active at the same time... meaning, because TS is built on activex controls, they are both registered simultaneously, but only for the same version (i.e. 2017 or 2019 not both).


Personally I would be a little weary crossing bitness like that.  The customers I help that use 64 bit are all-in, meaning both LV, TS and C# are the same bitness.



~Will work for kudos and/or BBQ~
0 Kudos
Message 5 of 7

For our project we're using VeriStand too (for a real-time chassis) and I think that's only available in 32-bit? So then, we needed 32-bit LabVIEW, but someone, (before I came to the project) decided we would use 64-bit TestStand....


Luckily everything is at least the 2019 version.


I've been in meetings since my previous reply, but I have the rest of the day to get real work done so I'll play around with it and report back.





0 Kudos
Message 6 of 7
Accepted by topic author m3rl3n

Hey M3rl3n,


VeriStand is only available in 32-bit due to the Real-time dependencies. So because of this and the fact that you are hoping to create an engine in LabVIEW you will be restricted to 32-bit everything. So LabVIEW will need to be 32-bit to work with VeriStand and since the TestStand engine is being initialized from a 32-bit LabVIEW process it will create a 32-bit TestStand Engine. 


TestStand does have cross bitness support but only when the LabVIEW adapter is set to use a specific bitness of the LabVIEW Development Environment to execute VIs.

Dane S.
Product Support Engineer
National Instruments
Message 7 of 7