NI TestStand Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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?

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

When using the TestStand API, I always find myself switching back and forth between TestStand and the TestStand reference help.  While the intellisense function help is usually enough, many times I like seeing the more detailed information in the help.  I would really like to have the option of displaying context specific help in a TestStand pane, similar to the context help window in LabVIEW.

 

This pane could dynamically update to display function information when using expressions, or show general information about the active pane or dialog (for newer users).  Much of the linking for the second case is already done, since the F1 key will pull up relevant help for the active pane currently.

 

TestStand context help pane.png

Currently, to export properties which are part of an array, such as the limits of a multiple numeric limit test, you have to specify each index of the array separately, like in the first screen shot, or else you get all of the raw XML, which is difficult to interpret and use. 

 

exports2.JPG

 

exports1.JPG

 

 

This is both labor intensive and unituitive. . If instead we had the option to export the array with the "?" and have it parse the information out like in picture 1, it would be much simpler to use.

 

Regards,

 

Kyle Mozdzyn

Applications Engineering

National Instruments 

It would be nice to beable to define a variable as constant.This could apply to Locals, FileGlobals, StationGlobals.

 

Once set mark it so as to be easily identifible as a Const.

 

The API would also need to include either a Property or Method so that one could determine if a variable is a Constant.

 

17017i0EE4006F51D2E91C

Currently, if you have LabVIEW code modules that use maps or sets you have to use something like an Action Engine to interact with the map, you cannot pass a map from LabVIEW into TestStand and vice-versa.

 

Maps are an incredibly useful data structure and having support for them natively in TestStand would be very helpful, not just for LabVIEW but also due to how prevalent maps (dictionaries) are used in Python as well.

 

JorrEl_0-1674075180101.png

 

Wouldn't be nice to beable to define one's own set of Expression Functions. This seems to be the one area of TestStand that cannot be customised. eg. Locals.name = NameOf(Step), Locals.IsValid = DoSomethingNotDefinedByDefaultFunction(Locals.name),.....(carry on with expression) Regards Ray Farmer

Since not every path on the hard drive can be in the drop down list, and some may be higher up in the tree from paths that are in the drop down list (and some may not be there at all) it would be great if we could specify relative paths and/or environment variables.

For example:

TestStand Application Data (for Windows 7) = "C:\ProgramData\National Instruments\TestStand". But, I want to install a file structure starting at "C:\ProgramData". Currently, my only options are to write a custom command to copy the files over after install to some other directory that's in the combo box. But this isn't great because things can be easily left behind on uninstall.

With a relative path, I could specify the subdirectory of to be "..\.." and with Windows environment variable support, I could specify %ALLUSERSPROFILE%. Either would take me to "C:\ProgramData".

Having tried both of these in TS2010sp1 installer builds, neither of these seem to be supported, and it would be awesome if they were in the future.

Thanks!

I was in the middle of creating an ugly expression that was parsing a string and building a file path from other standard file paths and realized that I can clean up the expressing by creating a few local variables.  But then I thought do I really want to create these local variables in my sequence that only exist for the purpose of this one expression.  Then I thought, what if I can define a variable within the expression itself, kind of how a variable is defined in C or something similar.  It only exists during the evaluation of the expression.

When you set the Post Action On Pass | On Fail in a step to use Call sequence, the only ways to pass data to this sequence is either use some sort of Global (StationGlobals / FileGlobals) or use Locals with the setting "Propagate to SubSequence".

 

There should be a cleaner way and that is to beable to pass parameters as you do with SequenceCall step type.

 

new Post Action.PNG

 

 

regards

Ray Farmer

When working with multiple long sequences it would be nice to bookmark locations making it easy to find where you were previously working.  The bookmark could be line highlighting or an icon on the left gutter.  Bookmarks would be saved with sequence.  Multiple colors or icon would be available.

 

 

SequenceEditorStepHighliting.jpg

Hello,

 

For the moment the runtime error handling can be managed by using ...

 

  • Runtime error options
  • Ignore runtime error flags
  • Manually, for action steps, by handling actions returns

It should be nice to add such a kind TRY CATCH block, in order to modify the error handling in a local section of a sequence.

 

TRY

    Steps ...

    Steps ...

CATCH

     case 35  // Error code = 35

     end

     case default // All other error codes

     end

End

 

Doing so, could be a way to handle runtime errors, in an other way that the global configured way.

 

Manu.

It would be helpful to be able to change the font colors that are displayed for steps in the sequence editor.  This would allow users to identify steps quicker for more efficient editing and debugging.

 

StepColors.PNG

In some cases it could be handy, if you were able to convert a container you've constructed in the variable pane into a type directly from the variables pane.

type_from_variable.png

One case could be, if you chose to store some settings in the sequence file, but the settings are dependent upon fx equipment or the product variant. It can be handy to have a variable with the settings, and an array of settings specific to various configurations from which you can choose. But the 'settings' container and the type in the array of settings containers, of course have to align. And this is best achieved by a custom data type.

Often sequences start out for one configuration only, and later on the need for multiple configurations occurs - and that's why I think it could be handy - if you were able to convert a container, already in the variable pane, into a custom data type.

Please make the mouse navigation buttons work with the teststand navigation buttons Teststand navigation.JPG (Go Back & Go Foreward) 

Just like it would work in Internet Explorer.

Mouse.jpg

Hi there,

 

This post is just in order to know why there is a user interface available in LabVIEW language (simple or full-featured) suitable for sequential model and NOT for Batch and Parallel models, while these are available in CVI language ?

 

The customer, who is an allaince member and a famous TestStand user (MESULOG) submitted this idea because he had to translate code from CVI to LabVIEW, and thnik this would be a great thing to add to the next release.

 

Cheers,

 

Mathieu,

 

 

The MOST annoying part of working with TestStand is the fact that the developer has to re-enter e-v-e-r-y bloody value for a given parameter when the prototype changes in a LabVIEW VI.  I seem to recall that older versions of TestStand would allow the user to do that, but the more recent version don't.  Maybe my mind is playing tricks on me and this was never possible..

 

In any case... When dealing with two parameters which have over 300 (yes!! THREE HUNDRED) entries, this is a bloody nightmare!!  Doing it once is nightmareish.. Doing it multiple times is a death sentence!!!  Sidenote:  I inherited the code and cannot change its structure...

 

In this particular case, the valeus are all Locals.

 

The first idea on this subject is to allow editing the original parameters when making changes to a prototype (LabVIEW or any other source).  Or as the sister idea to this one, allow to Copy & Pate the contents of a container!  See this thread!

 

 

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 ; )