NI TestStand Idea Exchange

Community Browser
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.

cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

When TestStand launches, it determines the active LabVIEW version and copies the TestStand API VIs into <LabVIEW>\vi.lib\AddOns if not already present. (SOURCE)

 

I suggest there should be an additional step here and TestStand should call that LabVIEW version to mass compile these VIs.


Currently, the VI version remains unchanged which means when you open a LabVIEW code module which uses these, you'll sometimes find you have a 'dirty dot' due to unsaved changes because of the recompilation. It also means that you wouldn't be able to run a sequence using the LabVIEW Run-Time Engine until you've switched to Development and converted the VIs.

This is a minor annoyance but it would be nice if TestStand could cut out the additional version conversion step.

 

I do wonder whether the transfer of the TestStand API VIs into the vi.lib could actually occur when LabVIEW is installed if a TestStand installation is detected. Perhaps this might be relevant for other addons which existing LabVIEW installations have.

The concept of TestStand Environments was introduced in TestStand 2016 and allows you to define multiple configurations on a single test station or development PC. It would be nice if there was an option to link a sequence file to a specific environment, similar to how you can set a sequence file to "Require Specific Model" In the Advanced tab of the Sequence File Properties. When a sequence file is loaded, the engine could check to see if the required environment matches the current environment and:

  • Automatically relaunch the app in the correct environment
  • Generate an error
  • Prompt the user for an action
  • Other??

It would be nice to choose the behavior when a required environment doesn't match.

 

If anyone has other thoughts or use cases, please share below.

-Trent

It's a relatively minor gripe, but wouldn't it be nice to be able to center justify a message in the MessagePopup step type?

 

Step.MsgFontData.Justify

...is strangely missing.  It could be an integer as in LabVIEW:

0 = Left

1 = Center

2 = Right

 

Yeah, I know it's easy to write code to produce a custom dialog, but it seems simple enough that it should be there natively.

 

Thanks as always,

Mr. Jim

It would be nice if I could right click a variable in the variables pane and choose from the context menu "highlight steps which reference this variable" or words to that effect and then the background of each step which referenced that variable would alter.

It would be really nice if it happend just by hovering my mouse over a variable.

 

I know this can be done by using a search but it is rather clunky

right now with TestStand Sequence Analyzer utility, it is limited to analyzing a whole sequence file at once (or as much of it as you analyze before you hit the stop button).

However, if I have a long sequence file this can take quite a while, and I don't really want to wait.

Add a feature where I can select areas to analyze and have sequence analyzer just analyze those areas (for example -- select a few (sub)sequences in my sequence file, or a few steps within a sequence).  This way I can limit the area of my analysis to where I know I made changes (or where I know my biggest problems are) and focus on those and not waste time analyzing everything else. 

I would recommend adding a "Right-Click" option for analyzing a "subseuqence" within a main sequence.

Many developers develop a Main Sequence with many Sequences in the Sequences window. Currently it's not possible to select "one" or "a subset" of the sequences to run through the analyzer .

Recommend adding this option to TestStand for selecting "right-clicking" a subsequence and running the analyzer on what is selected rather than ":all " of them.

The current placement creates confusion about what you’re actually closing out of when you click it. It makes me hesitate and wonder what I am about to close. 

 

If you click it when there are multiple files open, it just closes out of the tab on top. If you click it when there is only one file open, it closes out of the whole pane, including the Sequences and Variables windows.

 

TestStandX.png

 

It would eliminate any ambiguity if the X for each file were on the tab for that file and if there were a separate X for the pane, like you typically see in tabbed programs.

 

You could also just put an X next to the pin on each little window instead, like the X in the Step Settings pane and the Insertion Palette in the screenshot above. 

The separate compiled code flag is great when using VIs and source code control.

 

However TestStand (2016 SP1) deployment utility builder does not warn if the separate complied code flag is set - This means the VI will not run with the TestStand Deployment Licence without a LabVIEW development system installed. 

 

I do think the the Deployment utility should have a checkbox to force include the compiled code in all VIs and Controls so it can be run easily with the TestStand Deployment licence and LabVIEW runtime engine. 

 

Suggested because I have pulling my hair out wondering why a VI on a deployment machine won't run. 

Turns out a type def control had separate compile code flag set!  I even wrote code to clear this flag on VIs and all subVIs - it never occurred to me to check controls!

 

Also please update the error message in TestStand:

----------------------------------------
Details:

Parameter 'UUTServiceType': -This was a bit of a clue... but the TestStand type matched when I recreated it.
Unable to load VI 'Dialog - Prompt to connect UUT.vi' with the LabVIEW Run-Time Engine version 17.0.
The version of a subVI might not match the version of the run-time engine and the Version Independent Runtime feature is disabled or a VI dependency might be missing.
Try the following steps to troubleshoot the issue:

1. Open the VI in the LabVIEW development system. If the VI is broken, fix any errors in the VI.
2. Force compile the VI by clicking the run arrow while holding the 'Ctrl' key.
3. In LabVIEW, select File >> Save All to ensure that all subVIs are saved in the same LabVIEW version.

4. Check that the separate compiled code flag is not set on the VI or its dependent subVIs and controls (typedefs) when using the LabVIEW Runtime engine. 
----------------------------------------
Error Code:

-17600; Failed to load a required step's associated module.
----------------------------------------
Location:

Step 'Prompt User to Connect UUT' of sequence 'MainSequence' in 'My testsystem.seq'
----------------------------------------

 

{edit1} I also have just realised that running the code with the LabVIEW runtime in adaptor settings worked fine on my development PC as the control's code was in my local object cache. So I was also wondering why it worked fine on my development machine and not on the deployment machine when using the LabVIEW runtime.

Therefore the Runtime adapter should have a setting  to either Disable the Runtime using the local object cache

or an option ot clear the local object cache before running the sequence. This means this issue would have been reproducable on my development machine with the LabVIEW runtime adapter. 

 

I feel this idea is almost is close to being a bug.... 

 

 

 

The Search Directories.Insert method should only insert the directory if it is not already there.

 

The Method includes an index argument, if the directory is already there, then it should move the existing directory to the requested index.

 

While we were working on the shipping examples for DQMH, we discovered that the insert method was creating duplicates every time it was called. We implemented a work around that includes a for loop to check each of the items in the search directories list to see if it is the directory we are trying to insert, if it is, we delete it. Once the for loop ends, then we insert the directory where we want it.

 

You can see a video of the issue and how we worked around it here: DQMH 3.1 Only inserts the Delacor examples directory into Search Directories once

In order to keep file clean, sequence analyzer helps in finding "potentially unused variables". To delete such variables, each warning in sequence analyzer result has to be double clicked and then delete has to be pressed to finally remove that variable.

 

In many cases with large sequence file, there could be dozens of unused variables and in a single work-space there are dozens of .seq files.

 

Is it possible to provide a button or some option to remove all unused variables from a sequence file?

Trying to minimize memory used by Teststand, I have selected from sequence properties "Disable Result Recording for All Steps".  This works great except for sequence which DO need to record results.  There is currently no way to override this sequence option to enable recording for the specific measurement steps.  I would recommend added an option which allows the step to 'Override' the sequence disable result recording setting.  In TestStand 2014 there is an option under the Step / Run Options / Result Recording Options to "Enabled (overriding sequence setting)" but this does NOT work to enable / override the sequence setting, the results don't get recorded.  The only solution I found was to NOT enable the sequence "Disable Result Reporting" option on sequences with measurements, and select each step, disabling the Result Recording, except for the measurement steps.

Find yourself placing a Sequence Call step and trying to determine the appropriate value to enter for a numeric parameter called "Direction"?  Tired of creating sequences with numeric parameters named like the following: "Direction_0_Up_1_Down_2_Left_3_Right"?

 

The solution is to support the creation of variables with enumerated type within TestStand.  Enums could be created as custom variables and then used as wherever a self-documenting variable is required.

 

 

Enum type creation:

 24440i0A04C051A35273A4

 

 

 

As seen from a Sequence Call step to a subsequence that uses an Enum as a parameter: 

 

24442i5CDD825A78B161E5

 

The settings field can easily become too long to see every active option and there's not necesarily any consistency between steps if they have differing options. What I mean by that is if you only set the "Do Not Record Result" (my favorite) option in one step, it will be on the left of the settings field. But if you now set several options on another step, the settings are not lined up so that it becomes hard to see at a quick glance which steps I forgot to not record (because TS still doesn't default to not recording steps). You have to analyze the settings line for each step.

Current settings.PNG

 

I propose something more graphical and ordered. Here's my idea of at least ordered. The text could be replaced with icons representing each setting.

Ordered settings.PNG

 

Then it would be graphical, ordered, and concise. What more can you ask for?

In TestStand you can create a comment in a variable, but that comment will be deleted even if the data type of the variable is changed. This does not make too much sense because it happens that the customer needs to change  the data type, and then he has to re-write the comment completely. This feedback comes straight from multiple customers and it makes sense that it should be so.

 

Thank you everybody. Best,

 

Corrado

Why not make it possible for Teststand to generate reports in PDF format?

It would make it a lot easier to send a testreport of a specific board to people not connected to the actual tester.

 

Today we use XML but this requires the stylesheet to be present on the readers pc.

Graphs are also not showing correct unless you do a manual setup of the settings in Internet Explore.

 

PDF would make my life a lot simpler

 

/Michael

 

Do you ever write an expression in TestStand with a bunch of parenthesis () and get lost halfway through trying to figure out which pairs are open and which are closed.  Well, I do.  Every Day.  And I spend accumulated hours a week just trying to keep track of which ) goes with which (.  If I'm lucky I can look for a little red item in the expression, or click on the check expression checkbox, but when I have a 'only runtime evaluatable' expression I'm out of luck (which is rather often) ).  Some languages/editors have a parenthesis matching, where the ) your cursor is on causes the matching ( to get bold or flash.  Others start coloring each pair a different color, so it's easy to see them all.  Why can't TestStand do something like this????

TSparenthesis.png

 

I think it would be a great idea to allow the sequence adapter to expand containers like the CVI and LabVIEW adapters do when you are editing the module for the step. 

 

 

See attachment.

The "Report Options" dialog box provides a lot of flexibilty in the way reports are generated for sequences executing under the Batch model.  A new report can be generated for each UUT, for each socket, etc.  One option that appears to be lacking, is to flat out not generate a Batch Report.  Doing a brief search, I found at two other folks who were trying to do the same thing:

 

http://forums.ni.com/t5/NI-TestStand/Disable-Batch-Report-TestStand-2014/td-p/3091476

 

http://forums.ni.com/t5/NI-TestStand/How-do-I-disable-batch-report-in-the-batch-model/td-p/238387

 

Suggest adding another check box to the Report File Pathname on the Report Options dialog box to disable batch reports.

When creating custom step types, it is highly recommended to use Post-Step for calling execution module instead of Default Module.

Thus, when instanciating a custom step type, parameters passing is not saved within the sequence but only in the step type definition.

This allows to change parameters passing without having to update all the step types instances.

 

In some big test benches, it is intersesting to have low-level step types and high step types based on low level step types.

High level step types execution modules are sequences using low level step types.

 

Since sequence adapter is not available for Post-Step, we are obliged to call the sequence through Default Module.

Thus it can generate problems when adding parameters in sequence call.

 

I suggess to allow Sequence Call in SubStep creation :

 

SequenceAdapterInPostStep.png

 

Jean-Louis Schricke, MESULOG

TestStand Architect

Right now, you really can't reliably use anything other than a basic ASCII character set in TestStand, which means that some SI units (such as ohms) cannot be represented in their preferred way (with an omega).  It also means that you can't put non-english characters in your sequence file and reliably have them show up if your sequence file is opened on a different computer with a different language localization (which causes a huge problem if your customer demands support for non-English languages, and has more than one site -- that speaks a different language -- around the world).

 

Make TestStand support Unicode, so we can use the full greek character set for things like units, and so we can type characters from any language in our sequence files, and not have them change to a different character if we open them on a computer with a different localization.

 

TSomega.png