NI TestStand Idea Exchange

About NI TestStand Idea Exchange

Do you have a feature idea for how to improve NI TestStand? Submit and vote on ideas now!

  1. Browse by label or search in the TestStand Idea Exchange to see if your idea has previously been submitted. If your idea exists sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea. Note: the TestStand Idea Exchange is not the appropriate forum to submit technical support questions.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!

The TestStand R&D team is committed to reviewing every idea submitted via the TestStand Idea Exchange. However, we cannot guarantee the implementation of any TestStand Idea Exchange submission until further documented.

Top Authors
Showing results for 
Search instead for 
Did you mean: 

LV Primitives in TS

Status: New

How cool would it be to sequence any LabVIEW VI in TestStand? I realize one could make a wrapper around any VI, but that adds not only a layer of complexity, but customization. I am a staunch follower of the KISS philosophy, and custom wrappers are not so simple; well, at least not as simple as no wrapper at all ; )


I'm not so shure about that.

After a short while you would end up not opening LV to program LV but to use TS as a LV editor... sounds weird.


Strongly agree, wrapper VIs add an extra layer of complexity that is wildly unnecessary.  I only write VIs when I have to and writing a VI to simply allow me to use another VI because I can't use primitives seems excessive.

Trusted Enthusiast

What sort of things are you wanting to call directly from TestStand?


Yesterday I wrote a wrapper around the 'Get File Size' primitive because I needed to get a file's size in TestStand (to automatically archive MDBs as they fill up) and I can't call Labview primitives.  This is just my most recent example, this comes up all the time.

Knight of NI

Strip Path and Build Path are the two I would likely use the most.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Active Participant

I would much rather see those functions natively written in TS.  That way we don't have the overhead of calling LV code, and fighting issues of LV runtime engines, and getting LV VI.lib included as part of the deployment (it causes huge issues especailly if you are dealing with multiple possible runtime engines of different LV versions).



I run into this need on a constant basis. TestStand has come a long way and has quite a bit of functionality in it's own right, but it's still a sequencer at heart and needs outside code (VI's, DLL's, etc.) to perform many tasks. LabVIEW provides this capability, but when we have so much inherent and useful functions (VI's) in LabVIEW that cannot be accessed without creating a VI wrapper (around a single VI) to perform the EXACT SAME TASK it's just bewildering!


There are several posts on nearly this same topic, none of which (that I've found) has gotten a response from NI. It would be great to get an official response from NI on this!

Trusted Enthusiast

+1 for this.

Find myself having to wrap LV primitives just for the sake of it which creates additional code to maintain.

Some examples:

- Read/Write Spreadsheet file

- Array manipulation (e.g. reverse 1D array)

- Signal generation (e.g. to generate a ramp of test setpoints)

LabVIEW Champion, CLA, CLED, CTD

Another common need is the Format into String as this supports SI units.