NI TestStand Idea Exchange

Hi,

I suggest being able to group steps in a sequence:

Steps that are grouped should in interactive mode be forced to be handled together, e.g. "Run selected steps" would always select all the steps in the group. This way you could re-use certain steps multiple times down the sequence without allowing such steps to be executed by themselves (or the opposite, make sure certain steps were never executed without surrounding safeguards).

Today we'd usually enclose such must-work-together steps inside sub-sequences, but that solution does not safeguard against selecting a single step within that sub-sequence for execution by itself, and sometimes putting steps in a sub-sequence is non-optimal (one such case is when you have disabled tracing into subsequences, but this particular set of steps you'd like to have tracing on - I know there are ways to go about this, but these are cumbersome and non-trivial to spot when editing the sequence).

I wouldn't add any extra configuration options to a group, it should simply be a group/ungroup thing - all settings still being on a per step basis.

The use cases for a group could be expanded into making it easier to select a co-working set of steps for copying and pasting, it would be a good way to document co-working steps and so on.

Cheers,

Steen

This would be a useful feature to recover from a unreposive code module. Particularly useful, if the code module communicates with the firmware inside the DUT which could become unresponsive due to unforeseen erronous conditions.

This option should be optiional. It should be configurable with different timeout values. Once set and configured, then TestStand shall stop executing the code module, return from it and generate an error.

Hi,

Sometimes I can find difficult to access arrays using indexes. Although straightforward it can be difficult to maintain in certain situations, like calibration data for a lot of frequencies. Lets imagine you have a table of sixty calibration factors per frequency and forty frequencies, generated by third party software to the excel file.

It would improve accessibility if we could name columns and rows and use their names instead/along with the indexes.

We can access the array data like AnArray[4][6] now. In this idea we could access the data like that: AnArray["63dB”]["125MHz"].

When we would like to import the data using property loader it would be easier to access the data with defined names of colums and rows rather than indexes. (data binding)

Hi,

Firstly, I've discussed the topic how to programatically disable assesing results here.

I've realised there is no such option. Only one alternative is to swich the comparison type to LOG going thru the steps one-by -one.

It would be good to have the override method not to compare ALLresults in the sequence (during execution).

Hello,

It would be nice to VIEW errors which occurs in the process Model or callbacks using a special dedicated window.

Recently, i have send updates to one of my customers, using FTP transfert.

The updates consists of processModel updates, dotNet assemblies ...

During the FTP upload by my final customer, the dotNet assemblies were marked, by windows 7, as "Bloqued" . (For security reasons ...)

These assemblies were called in my process model.

When the final user tryed to launch his application (Operator interface), nothing occurs ! The dotNet assemblies calls fell in error, but without any message. I had to investigate using debugging tools to find out the problem.

It should be nice, in case of "anormal errors" in process model calls, or in callbacks (like frontend callbacks) to launch an error window to view this kind of errors.

You may say, you should have test the errors and handle them correctlty ... and you're certainly right !

But i get a look to the default processModels provided with TestStand ... and they are coded as i do !!!!

So even with the 'default process model', if an internal dotNet error occurs (missing sub assemblies, no more ressources ... ) the same kind of anormal behaviour could occured !

So having the way to view process Model, or hidden callbacks errors will perhaps be interesting ! 

Thanks a lot.

Manu.

When I get called to look at an issue that has occurred with a test, the account logged into TestStand is typically a restricted user (i.e. Operator). Since the Operator account has very limited options, in order to really do much immediate troubleshooting I need to stop the test and re-run it in the Administrator account. At best this is inconvenient and inefficient if the spot the error occurred is late in the test. However, it is extremely frustrating when it's an intermittent run-time error and I can't do any real-time debug because Operator is logged in. The only real alternative I can think of (when the problem is intermittent) is to leave it logged in as Administrator so I can debug whenever it happens to occur. This is not really an acceptable practice in most cases.

It would be fantastic if there were an override that let's an Administrator provide the proper credentials to perform the desired task that would normally be off-limits to the Operator. The basic premise of this suggestion is similar to the functionality within Windows; if you try to connect to a secured location or perform a task that requires administrator privileges, a dialog box pops up asking you to enter authorized credentials.

I run into many situations where I wish this feature was present. The issue is not always within TestStand (could be a database connection issue, etc.), but it is TestStand that throws the error and in Operator mode the only option is "Run Cleanup". Significant time, effort, frustration, and efficiency could be saved if I could simply enter my credentials as an administrator to perform the tasks I need to do.

Regards

On an unrelated side note, I find it humorous that "TestStand" is considered a misspelled word when using the forum spell checker.  🙂