NI TestStand Idea Exchange

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

Modifying names in interface are never good idea, but some times it is must.

No matter is the change made in LabVIEW Front Panel or in TestStand type cluster mapping. Or the cluster type is changed for some other reason. The changes needs to be applied in LabVIEW module call parameters.

When you have multiple sequence files and multiple calls to same VI or with same cluster type in each of them, you would not really want to go trough the steps one by one.

 

Ideas:

- Cluster mapping changes apllied with LabVIEW Protorype reload

- Cluster mapping changes applied to hole sequence file or/and to all same VI calls in the sequence file

- Need of cluster mapping change applying notified with Analyzer

When test cycles run and fail for some reason, sometimes LabVIEW will either crash or get hung and wont close.

 

Even when exiting or restarting Teststand, LabVIEW does not close properly...or re-open properly, locking any HW resources. Non-technical savvy operators are unsure / do not know what to do.

 

If the operators were notified with a pop-up informing them of a windows restart is needed to clear LabVIEW PRIOR to even the login prompt, that saves a lot of false start/false fails and headaches.

 

We have implemented this in the "FrontEndCallbacks.seq" and works great for false-fail runs.

 

Teststand should have this implemented built-in.

If you are using a custom environment file for TestStand 2016 and later, it would be great if, on startup, the splash screen indicated the loaded Env file name and path.

 

As you can see below, in our custom TestStand RTOI we are showing the loaded environment file on the splash screen when it loaded.  The TestStand 2019 splash screen is shown for comparison.

Download All

You can run TestStand sequences headless currently from LabVIEW, but it would be nice to have more detailed documentation and examples on how to do it properly since it is not straightforward.  There are some end users that do not need to see the TestStand execution in the operator interface and just want to run a sequence without showing all of the TestStand UI components.

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.

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!

To import/export properties in TestStand the JSON format would be much more intuitive than the proprietary CSV format.
It would also better fit to the structur of the TestStands property structur.

The property loader step allows the source location to be defined via an expression.  However, if that expression does not evaluate to a file on disk at compile time you get an error.  This isn't always desired behavior, for instance, when used in a plugin architecture.

 

Expression.PNG

 

The current workaround is to include a dummy file which could unnecessarily complicate the software & deployments.  A dummy file also has the potential to mask errors that should be presented to the user. 

 

The only validation TestStand does of the property loader source location file is that it exists.  It doesn't do any validation on the file contents.  So is there any benefit?  TestStand properly throws an error if the expression doesn't evaluate to a valid file.

 

Alternatively, a developer could deselect the sequence analyzer rule "Property Loader source should be proper", but this would disable it for all analysis not just the ones that use expressions

Hi all,

 

At times when I am filling out an expression, I'd like to be able to refer other developers to a specific sequence or step within the file.

 

I think it'd be useful to be able to add clickable "hyperlinks" to other steps or sequences within the same file.

ExpressionCommentLink.png

Would anyone else use this if it were a feature?

 

Thanks as always,

Mr. Jim

When user opens the Offline Processing Utility and at the same time starts to type on the keyboard the user can accidently rename the profile.

(Attached a screen-recording to visualize)

It would be great if there was no selected row or column when starting/opening ORPU. The renaming of the profile disturbs the production since the database logging will not work as expected.

 

When we start ORPU we already have the '/tray' enabled but somehow its still possible to accidently rename the Profile.

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.

Hi all,

 

There are times, for instance, when I am paused at a breakpoint and I want to copy the full name expression of some deeply nested variable that only appears at runtime.

 

I wish there was an option on the context menu that would allow me to copy the full path of some variable.

 

For instance, in the following illustration I want to be able to copy the string

"Parameters.ModelPluginConfiguration.Plugins[0].PluginSpecific.RuntimeVariables.PerSocket[0]"

I've added a context menu option called "Copy Path", but maybe that's the wrong nomenclature.

 

Am I ignorant of some functionality that already does this? (Besides typing it in the watch window?)

 

Thanks as usual,

 

Mr. Jim

 

CopyVariablePath.png

 

Hello,

 

CSV Input Stream allow to parse CSV files to input data into a Stream Loop for instance. By default, the separator is a comma (,). I use a non english version of Excel to edit a CSV file, and every CSV format write a semi-colon as separator (;):

A;0;0;2
A;10;30000;5
A;20;15;7
B;75;42;1
B;100;12;0

 

Using an expression, I am able to dynamically (at run-time) change the property SeparatorChar:

Locals.MyInputStream.AsCsvFileInputRecordStream.SeparatorChar = ";"

 

I think it could be more convenient to have a direct access to this parameter in the configuration pane, allowing also to check the content of the file  before execution with Parse Record Prototype funtions.

 

Best regards,

Problem:

I create a model plugin and add some model callbacks to it.  Then I want to access those model callbacks from my client file.  I have to now add them to the process model so they show up in the list when I go to add callbacks.  I get that I can add it as a blue sequence and it will work   However, that is confusing to other developers if they don't know the plugin has the callback in it.  It is painful to change the process model every time I create a new plugin because the process model could be used on hundreds of machines whereas my plugin may only be needed for 1 or 2 machines.

 

Solution:

Option 1: Show all callbacks from any plugins in the callback dialog list

 

Option 2: create a configurable list of model callbacks.  Basically add any sequence files marked as model to the list and it will show all the callbacks from the sequence files in the list to the client, unless it cannot find the file in any search directory.  Then it wouldn't show.

 

Option 3: From the add callback dialog allow the user to browse to a sequence file which contains model callbacks

 

I think adding this functionality will greatly help in making the plugins more abstracted from the process models.  Just saying.

 

Cheers,

When assigning a type to a property, the list of types is in an unordered pile. In the next release, can someone please alphabetize it?

 

(PS. Do not ask about the context of this image. It's not pretty. 😏 )

 

PileOTypes.png

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.

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 

I would like to see the possibility to add Tools (Menu > Tools) to Toolbars. See the recording below:

tools.gif

 

As you can see from Tools section I can select only "Customize". It could be great to have the ability to use custom tools when customizing toolbars and menus.

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.