NI TestStand Idea Exchange

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

 

It would be a big convenience if, when you are configuring a TestStand Deployment, the Workspace automatically populated with the current workspace that was open when you try to deploy.  While not a major inconvenience, it is somewhat of a hassle to go and select the same file every time, especially if you are making small changes to test a system.

 

image.png

The idea here is to have a widow that you can execute expressions while at a breakpoint or paused.   I would also like to be able to execute the expression while not running the sequence.  Many times I am not sure how will be returned by an API expression and it would be nice just to execute it.  I know that not all expressions can be executed outside running the sequence, but many can.  This would be a nice feature so you can test expressions without running the whole sequence.

 

I didn't see this suggestion yet, but could we add the explain error feature in TestStand that is available in LabVIEW under Help » Explain Error...?

Have you ever wanted to run a customizable batch file or executable after a CVI Application has been deployed? In my case I do. In my case, I want to automatically run a batch file that sets the Environment Paths in Windows of my executables and DLL's after the installation is completed. To make this work currently I am requiring the person who is installing the application to manually run a batch file to set up the Environment Paths in Windows. Potentially error prone if the paths are not set for my applications. My batch file would be written as: "Set Path <etc> from the command line prompt. CVI 2010 does not have this capability.

 

In older versions of CVI I think this feature existed but I do not know which CVI version National Instruments removed it from.

 

There may be other cases that I might want to run an executable(s) that sets up the application up in a default situation for first time use only.

 

I am sure there are other cases where other CVI Developers who would want this capability too.

In TestStand this feature exists in the "TestStand Deployment Utility" under the Custom Commands tab. 

I wanted to gauge community interest in a set of step types for remotely setting up an RT Target.

 

1) RT Software Install

 

From a high level, we want to give our users the ability to specify:

  • RT Host
  • RT Target
  • RT Software to install

On a lower level, we have a few different ways to specify software to install. The first is to provide the user the ability to specify specific GUID's from the host or to install all available software from the host. The second is to allow the user to install all available, install selected software from a local file that maps distributions and GUID's, install a "Software Set" from a network location that matches a user-specified part number, or communicate to the RT Target and request a list of software that it can have installed.

 

2) RT Software Un-Install All

 

User specifies a Target Name (or IP), Password and whether to reboot the target after un-install

 

3) RT Reboot

 

User specifies a Target Name (or IP), Password and the target reboots

 

____________

 

 

We've heard interest in these or other remote automation Step Types before, so any feedback or questions would be really valuable!

 

Matt

Allow the configuration portion of steps that call DLLs to see mangled function names, such as those generated by many C++ compilers (@Initv, for instance).

 

I've encountered on several occassions, customers who assign serial numbers / partnumbers during the test process who still wish to do on-the-fly recording.... and are disatisfied with the default behavior of the reporting because their header persists in showing the blanks etc.

 

While I understand that it's easier to build file paths / headers once, and then append the body content onto them, it would be especially elegant, if there was:

 

(a) a way for me to manually trigger (via a callback perhaps) a refresh of the entire header or

(b) if at the very least, the header section & file path were overwritten/updated once at the very end.

 

Since it seems to me that the header has to be re-written at least partially to account for the failure-chain logic, it wouldn't seem that much more work (or that much more inefficient) to just refresh the whole thing?

TESTSTAND is capable of interfacing so many devices & instrument to a UUT.

 

Incase of ATE(Automatic test equipment), where lot of resources are made available to test the UUT, not all the resources or instruments will be used through out the test for a particular UNIT. Hence there should be facility to select the resources required for particular test, which will be then only initialized & used.

 

For example a simple power device requires only POWER SUPPLY, LOAD & DMM. Where as a data acquisition system requires POWER SUPPLY, DIO & AIO cards & so on.

 

Thus one should only select the resources required for test & hence no need to have init function separately for each sequence. This may sound a bit complicated but It really helps for LARGE ATEs, where optimization is KEY. Same thing can be implemented for TERMINATING resources once test is done.