NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Some specific TestStand questions for a Trade Study (Using TestStand with a mostly-LabVIEW based system)

As the title suggests, I'm putting together a trade study to determine if TestStand is "worth it", in terms of cost, bulk, and learning curve, in a system that will be mostly LabVIEW, with the occasional Python and DLL call. Assume for the moment that the team has some exposure to TestStand but are CLD's or better in LabVIEW.

 

  1. Does TestStand have an internal method to "hand off" data somehow from one step to another? For example, if a thing returns a string, can TestStand store that string in a general purpose buffer and hand it off to the next thing? Or, is that done with file I/O only?
  2. In LabVIEW, calling a DLL can be time consuming and is dependent on the DLL being properly documented. This is especially true if someone else wrote the C++ DLL and that person isn't available to help expose and explain the inputs/outputs, and in this case, you have to keep trying until you get it right. Does TestStand somehow make this process easier?
  3. It seems that the way TestStand works out of the box isn't conducive to multiple UUTs running at the same time. If I have 30 UUT's, how difficult is it for TestStand to pull in 30 UUT serial numbers at once, and then display all 30 running on the sequencer front panel?
  4. Can the stock TestSand sequencer window contain a section that constantly shows a few parallel processes like temperature, humidity, a count-down timer, etc? I'm not talking about running a window that is a LabVIEW VI.
  5. Is a TestStand deployed program (the user version you'd deploy to the production floor) have complicated licensing and runtime engine requirements? LabVIEW is easy in this regard, and hoping for same.

Thanks for any words of wisdom.

0 Kudos
Message 1 of 4
(505 Views)

Before answering your concrete questions, let me comment on your post:

1.) IMHO all your questions are very developer centric, which I perceive as a bias for a trade study. To get the full picture you should as well give some information on your use case like organization, standardization structure and scale of your business (e.g. number of test systems deployed locally/ globally) 

2.) Due to the way those questions are phrased, I see that there is only very little knowledge of TestStand in your organization. I would recommend sending one or two developers to a TestStand training to get to know TestStand. 

 


@rds2112 wrote:

[...]

  1. Does TestStand have an internal method to "hand off" data somehow from one step to another? For example, if a thing returns a string, can TestStand store that string in a general purpose buffer and hand it off to the next thing? Or, is that done with file I/O only?

The TestStand engine maintains a dedicated data model (today you might even call it Digital Twin 😉) which also features variables of different scopes. So you can use variables to hand over data from all across your test program

 


@rds2112 wrote:

In LabVIEW, calling a DLL can be time consuming and is dependent on the DLL being properly documented. This is especially true if someone else wrote the C++ DLL and that person isn't available to help expose and explain the inputs/outputs, and in this case, you have to keep trying until you get it right. Does TestStand somehow make this process easier?

With DLLs as you describe them , same thing in TestStand. So it is in C# or whatever language you using a DLL in. 

 


@rds2112 wrote:
  1. It seems that the way TestStand works out of the box isn't conducive to multiple UUTs running at the same time. If I have 30 UUT's, how difficult is it for TestStand to pull in 30 UUT serial numbers at once, and then display all 30 running on the sequencer front panel?

The "User Interface" TestStand come with, is the Sequence Editor. So it is an Editor which is not meant to be used by operators on the production floor. Furthermore you don't want to pay the license fees to do so!

 

TestStand (more precisely the TestStand Engine) provide a user-modifiable infrastructure as a base for custom implementations. This also hold true for the User Interface: since NI can't possibly cover all requirements for any use cases, they provide an Editor to create sequences and sample code, users can extend to their on needs.

BTW.... showing data for 30 UUTs at the same time is a challenge for any user interface. Interpreting this amount of data is a challenge for the user!

 


@rds2112 wrote:

 

Can the stock TestSand sequencer window contain a section that constantly shows a few parallel processes like temperature, humidity, a count-down timer, etc? I'm not talking about running a window that is a LabVIEW VI.

In the Sequence Editor you can use Watch Expressions to monitor data while your test is running. Yet, they are meant to be used for debugging. So... this is the responsibility of the custom user interface.

Talkig about parallel processes in general: the TestStand engine features multi-threading.

 


@rds2112 wrote:

Is a TestStand deployed program (the user version you'd deploy to the production floor) have complicated licensing and runtime engine requirements? LabVIEW is easy in this regard, and hoping for same.

 


Depends ob what you think is complicated: on your deployed TestSystem, you will need a TestStand Base Deployment License (aka TestStand Runtime) which is perpetual (important these days) costs a fraction of the actual Development license. The license itself has to be activated online or is placed on a license server if your organization has a VLA or EA

 

I highly recommend consiering the following factors for your study:

  • Number of Developers (today, future)
  • Number of TestSystems to be deployed
  • Benefits of standardizing on a framework with commonly used functionalities across the organization.
  • Benefits for evelopers being able to concentrate on writing test software itself not having to care too much about logisitcs due to the use of a framework, which handles all f that
  • Maintenance of the framework itself
  • ...

 

My background: coming from Lowlevel programming, I have been using LabVIEW for over 20 years now. I have been a TestStand user for 15 years. I try to be a very non-dogmatic person, fully aware that there is no "one to rule them all" tool. Yet my experience shows that TestStand scales far better than homegrown solutions.

Today I am als architecting corporate test infrasturcture and need to consider also more financial and scalability factors for a multi-national production unit.

 

Message 2 of 4
(461 Views)

Thank you VERY MUCH for your detailed response Oli_Wachno, I've learned a lot. And yes, I do not know TestStand beyond looking at it from the perspective of a few people who have used it to sequence LabVIEW VIs because they don't know how to make decent state machines in LabVIEW. Not that that's a bad thing. For team perspective on LabVIEW, we have a lot of CLDs and a CLA or two and I, like you, am a Champion with 20+ years of LabVIEW experience (I.M. me for info, this is my NI "work account" where I am not allowed to branch off into social media stuff or include links).

 

To your points in order that they appear:

You're 100% spot on - this is a biased trade study - very developer-centric. So right out of the bat, we are like, "hell with TestStand just use LabVIEW". But I'm trying REAL HARD to gain insight on how TestStand could help us for an upcoming 5+ year project. Astute of you to pick up on the bias, as that's a hot topic to me. And as stated, most of us are TestStand novices (at best) yet LabVIEW experts.

 

"Digital Twin", LOL, do you work where I work? They love that stuff here. Anyway, good to know that TestStand has variables that can be used in this way. Thanks, this is the kind of quick info we need for this survey/trade study.

 

The DLL calling is what I thought it would be. There's no magic behind the scenes.

 

Starting to grasp the deployable-ness of TestStand and the user-facing interface capabilities. Yes, even I 😉 know that you wouldn't deploy the sequencer to the production floor. But the deployable interface examples I've seen look like something you'd see on page 2 of a LabVIEW book. I'd like to see what's really possible. If it's nearly-limitless, like LabVIEW, then fine. If NOT, I'd like to know. Or, if it's nearly-limitless-but-a-ton-more-work to get a nice TestStand user-facing GUI, then I'd like to know.

BTW, 30 UUTs on the same screen would be a customer requirement. It could be as simple as 30 tri-color LED's, then a button to click on one UUT to get a detailed history/running status. We have tons of experience with that - just not in TS.

 

Watch Expressions! Thanks for that. This is exactly what I was looking for. As long as the test-bench (sequencer) view can do that, we're good. Obviously the user-facing version would be its own thing.

 

OK, so, about deploying to the sites, you said "The license itself has to be activated online or is placed on a license server" which scares me. With LabVIEW, I can make an installer that contains the RTE, and the "Accept" nonsense, etc, then we're off and running. Zero issues. The deployed sites will have NO internet / LAN connectivity. Hopefully, whatever licensing we need for TestStand at the sites can be done with a disconnected license, which is still a lot more pain than LabVIEW's RTE/Installer. I'll contact NI about this specific topic, but happy to know your insights.

 

To address some of your bulletized items, we have 20+ developers with 10+ expert-level LabVIEW. Test Systems to Deploy will be 3 or 4 (by this, I mean user-facing production systems), and bench-systems (development mode) will be 2 or 3, but with 2+ developers using those systems. As you see, the "seats" is minimal, but the impact can be huge on a deployed system running some tests 24-7 for weeks at a time on a life-saving end product on security hardened off-line systems - so as soon as something looks convoluted or full of licensed 3rd party plug-ins, management will strike it down. I'm trying to have that not happen.

0 Kudos
Message 3 of 4
(426 Views)

  1. It seems that the way TestStand works out of the box isn't conducive to multiple UUTs running at the same time. If I have 30 UUT's, how difficult is it for TestStand to pull in 30 UUT serial numbers at once, and then display all 30 running on the sequencer front panel?

 


Yes, TestStand supports multiple UUTs running at the same time using a process model.  The Batch and Parallel process models support this concept; in these models each UUT is mapped to a Socket.  When you set the Model Station option to Batch or Parallel, an additional setting is exposed that lets you set the number of Sockets your test equipment can handle.  

 

Configure > Station Options > Model

eejallen_0-1703114258429.png

 

 

Configure > Model Options

eejallen_1-1703114305154.png

 

Then when you run a test sequence the process model will prompt for the UUT serial numbers for each socket and while test is running each socket execution is displayed in a window pane.

eejallen_2-1703114564780.png

 

Message 4 of 4
(331 Views)