NI TestStand Idea Exchange

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

I think it would enhance readability if, in the step settings of a label step, the label description text were no longer bold.

I cringe every time I fill one of these out or read it back to myself.

(Yes, I'm aware of the ability to mouse over the step itself and read the tooltip)

 

Maybe my use case is unusual, but I'll often write a few sentences in there to describe what a sequence or code block does.

 

Thanks,

 

Mr. Jim

 

 

Ow, my eyes:

 

BoldLabelText.png

when manipulating data between different system, JSON string are very usefull to have a standardize, simple and readable exchange format.

 

Python or LabVIEW can dump structure (dictionnaires or Cluster) to JSON and vice versa.

It can be very usefull to allow to dump a TestStand variable or container to JSON and vice versa.

 

It can be good to have also a way to have native function in string functions to read, write or add a specific value in a JSON string.

 

MaximeR

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.

CreateSameProperty.png

 

Let's say we have a parameter to a subsequence of a named type, and we want to create a so-named Local or FileGlobal with the same type.

One way to do this with our current workflow is to:

  • Type the same property name in the parameter value
  • Right-click the parameter
  • Click on "Create Locals.whatever"
  • mouse over the types menu
  • Glance through most of the types, select the custom type

 

I'm proposing a simpler workflow for cases when you just want to duplicate or "clone" the property with the same name and type in Locals or FileGlobals:

  • Right-click the empty parameter value
  • Select "Create Locals.whatever" or "Create FileGlobals.whatever"

The respective menu options would appear if the so-named variable does not already exist.

The subproperty is created in the Locals or FileGlobals with the same type as the parameter.

StartTimeUnix.png

 

Looking at any step result, there's a TS.StartTime property, but it's referenced against the "the number of seconds since the application initialized the TestStand Engine"

 

What this means is that each step result is referenced against a somewhat arbitrary and changing epoch that isn't recognizable outside any one instance of the TestStand application, let alone by external applications.

 

I'd like to propose adding TS.StartTimeUnix, which contains the absolute time the step started.

I've added this in our model customization plugins, but to convert the epoch to UNIX I have to perform this calculation:

 

Seconds(False)-Seconds(True) + Parameters.Result->TS.StartTime

 

Why I'm asking for this:

In our step result database table, we've added a column for STEP_START_DATE_TIME which is absolute UTC time. To populate this I have to go through the gymnastics above. I revisited this code today and thought, "What silliness. This should be something natively supported." (Other than that I have no strong opinion on the matter)

Hi there,

 

When using the Find/Replace dialog in TestStand, it would be nice to have a checkbox under "Elements to Search" that allows the user to choose whether or not to include sequence file attributes in the the results. I guess I could put together a regex to accomplish what I need to, but a checkbox would be nice.

 

FindOption.png

 

Why am I asking for this?

I'm used to quickly working my way through find results by using the CTRL+G / CTRL+Shift+G shortcuts. When I hit one of these attributes there's about a 4 second delay before the sequence file attributes dialog opens. This is super annoying in the workflow of the find results, and the vast majority of the time I'm not interested in searching the ignored Sequence Analyzer messages.

 

Thanks,

 

Mr. Jim

 

IgnoredMessages.png

 

 

 

Problem description:

The parameters out of the step settings window and the called subsequence are not linked. If you delete any parameter out of the middle of the parameter list and the calling sequence use the "default" flag for this parameter(s), this default flag(s) will be shifted to the next parameter in the list and the original value will be overwritten. To reproduce this issue:

 

  1. Create a test sequence
  2. Create a subsequence and add six parameters (type does not matter)
  3. Insert "Sequence call" in the Mainsequence and configure it to the previous created subsequence
  4. In the "StepSettings" window configure the parameters of the called sequence. Parameter 1+2 with any value. Parameter 3+4 with default checkbox. Parameter 5+6 with any value
  5. Save your work
  6. Open the subsequence and delete the parameter 3+4 (these two that are configured with "default" in the calling sequence")
  7. Go back to the MainSequence and click on the sequence call of the subsequence (reload option is visible in the step settings window)
  8. click on the blinking red reload button

You can see that the name of parameters you have deleted in the subsequence disappear, but the "default" flag(s) are shifted to the parameters 5+6 and the previous configured values were overwritten. If you delete any parameter that is configured without the default flag the deletion works fine. 

 

Problem: If you want to delete a parameter that is used in many subsequences by searching for it and delete it directly out of searchResult window, you cannot guarantee that your sequence is running without any problems

 

Idea: Add a "checkup function" on the "reload" module in the stepSettings menu that all parameters are checked by name and value before any values will be overwritten. This checkup has to be done on each change of the called subsequence

There is rudimentary Command Line Interface (CLI) integration in the TestStand Deployment utility.  Its undocumented, and is one flag.  "build".  Which is useful, but the fact that my only option to determine if the build succeeded is manually parse the build output log is cumbersome and error prone.

 

In a world where continuous automation and build automation are becoming daily buzzwords, additions to the CLI are sorely missing.

 

I don't necessarily need to be able to do much from the CLI, but having control and the ability to read back status on a build would be tremendous.

 

https://forums.ni.com/t5/NI-TestStand/Running-the-deployment-utility-from-the-command-line/td-p/1624948

All the major IDEs I use (LabVIEW, LabWindows/CVI, Visual Studio, etc.) support specifying post build actions as a part of the deployment.

 

TestStand does not.

 

Since the TestStand Deployment Utility (at least as of TestStand 2019) does not implement any kind of signing implementation, I'm resorting to manually signing my installers with my official signing certificate after the fact.

TestStand should use Workspace and Projects properly when determining the folders and files used for deployment.  It should not default to reproducing the on disk source structure for your deployment.

 

  1. I develop in a folder called: C:\Development\ProjectFolder\. 
  2. I create a workspace, a project, and add the ProjectFolder to the project.
  3. I load the workspace into the Deployment Utility.
  4. In the Installer Options tab I set my Default Installation Base Directory to "Windows Volume (C:)"
  5. In the Installer Options tab I set my Default Installation Subdirectory to "ProductionSW"

 

I would expect the Project Folder and its contents to be the ROOT of my deployment placed in the C:\ProductionSW\ folder.  My resulting installer should create C:\ProductionSW\ProjectFolder\

 

However the Distributed File Tree Views show:

View Workspace

  • Workspace.tsw
    • Project.tpj
      • ProjectFolder
        • source Files and Folders

View Source

  • C:
    • Development
      • ProjectFolder
        • source Files and Folders

View Build Preview

  • Installation Directory
    • Development
      • ProjectFolder
        • source Files and Folders

By default when I build the deployment it installs my software at C:\ProductionSW\Development\ProjectFolder\

 

The Development folder is not in the workspace or project.  It is not referenced in any of the source files (as all paths are relative).  I understand why it's in the View Source as that's where it resides on disk.  However, the workspace/project should be used as the basis for the deployment not where things are on disk. 

 

The source starts at ProjectFolder and that is what I expect to be deployed to my Default Installation Base Directory\Default Installation Subdirectory folder.

 

If the workspace and project aren't used to define your project code then what good are they in the Deployment Utility?

We have dozens of custom analyzers.  Every time we want to update a tsarules file, we are force to manually check each box to include in the export.  It would be nice to add common toolbar items to perform such task.  This includes commands like Select All, Unselect All, etc..

 

Thanks

 

I would like to request to add the possibility to start Tool (Menu>Tools) from Quick Drop. E.g. I would like to create a tool which sets selected steps to overwrite reporting option and run this tool with Quick Drop.

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.

It would be nice to have the option of making an Enumeration of Expression type and be able to use the Enumeration directly in an Evaluate() expression.

vrv_0-1605611723913.png

 

The expression might look like this investigating if "operator" have technician rights Evaluate(Enums.MyConstants.Techincian)

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

Please include Wait(x mSec) or Delay(x mSec) operation as one of the method in sequence context, so that this can be used in Function Statement step, Post action of any step to force the step to wait for few mSec after completing it's operation. This is to avoid explicit inclusion of Wait step and majorly useful during looping a step and provide delay between each iteration.

We have multiple sequences in a file to perform steps that are common to particular subsystems.  It would be nice to have the ability to group sequences within TestStand.  I could envision this to look like a treeview or folder/file structure within the Sequence Pane.  Currently, we have to use a common naming convention to group the sequences together like below:

 

GPIO_Inputs_[Seq1]

GPIO_Outputs_[Seq1]

GPIO_Outputs_[Seq2]

Communications_CAN_[Seq1]

Communications_Ethernet_[Seq1]

Communications_Ethernet_[Seq2]

Communications_UART_Port0_[Seq1]

Communications_UART_Port1_[Seq1]

Communications_UART_Port1_[Seq2]

 

With grouping, it could look similar to below:

 

Communications

    CAN

        [Seq1]

    Ethernet

        [Seq1]

        [Seq2]

    UART

        Port0

            [Seq1]

        Port1

            [Seq1]

            [Seq2]

GPIO

    Inputs

        [Seq1]

    Outputs

        [Seq1]

        [Seq2]

 

In addition, there could be a toolbar menu item to switch between showing the grouping or all so you could sort to find

 

 

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

The TestStand API doesn't provide a simple, robust mechanism allowing developers to programatically run sequences outside of the ActiveX UIs.

 

On many an occasion I've wanted to wrap the following basic functionality:

  • Run a specific sequence file (with or without a [typically custom] process model)
  • Wait for it to complete.
  • Retrieve the result.

It's something I've needed to do in all of the following situations:

  • Integrating into a customer's existing framework
  • Integrating into my own automated test framework
  • Providing a simple API to a customer
  • Creating customized UIs that rely on UI messages and events rather than the ActiveX Controls

The solution I've ended up defaulting to in the past has been some variation on:

  • Start with the full-featured C# UI.
  • Scrape out all visible ActiveX Controls, and hide the window so that it's running in the background.
  • Integrate a TCP/IP (or equivalent) client into the application that has the ability to listen for requests and then implement them through the AxApplicationMgr.
  • Build a TCP/IP server assembly that launches the client application and exposes the necessary API for simple interactions.

The approach above is time-consuming, error-prone, and feels like a hack -- but given that TestStand does not expose any easy mechanism for simply running a sequence, this is what I've ended up having to resort to.