NI TestStand Idea Exchange

The built-in Wait step currently causes TestStand to simply stop at that step until the specified period has elapsed. For steps longer than a few seconds, it would be nice to have some sort of indicator to show how much time is left to wait (and to show that the computer hasn't locked up on those waits that are more than 15 seconds).

It would be really nice to have a check box option to show some sort of wait indicator, even if it was simply using the progress indicator in the lower right corner of the screen (something that simple could even just always be enabled).

On a related note, could the progress bar be made wider so that there is more resolution as to how much progress has been made? If there was a ten minute wait for something, the bar would be moving very slowly and hard to tell progression was being made.

Almost all of our analog measurements are specified in %: example

a Power Supply DMM measurement limit is 24.00Vdc +/- 5%

We typically have 100+ measurements like this in a project

Why not include it in the default step types as an optional selection?

I sure would use it, so would my team.

I agree that it should not alter existing programs using the default step, but I believe that this feature should have been in Teststand when it was first released.

I have run across this in both analog measurements, and the results from an ADC

Think a limit of 0x234 +3%, -7%

I have a bunch of times that I need to round a numeric variable in TestStand

example: Locals.A = round(Locals.B)

However, it's actually more complicated than that because I need to round it at the Nth position after the decimal point (for example).   This means my expression becomes something like Locals.A = pow(10,-Locals.Digits) * round (Locals.A * pow(10,Locals.Digits) )   (for Locals.Digits == 3, this means that Locals=A becomes 0.123 when Locals.B is 0.1234)

This is a lot more code than I really want to write.  If I am doing the same thing in MS Excel, I just say $B5 = round($B4,$A$1) or something like that.  Notice how the digits of precision to round to is built into the round function.  I'd love if TestStand round function could be expanded the same way

Round(Number, [option], [Digits])

We have several sequences which are too long to execute (test stand crashes during the initial load) using the preload option.  These are often sequences with 50-100 subsequences which define contiguous tests to be performed.

If Test Stand had a 64 bit version additional memory would be a solution to this problem.

Hi,

When you develop custom step types in LV, you often need to unload all modules in order to modify your LV code (it's faster than going on your step type definition, clic Properties -> substeps -> specify code module -> edit...).

A keyboard shortcut to 'Unload all modules' would be so nice to even speed up the process ! 

Currently, the Installation Destionation options are as follows: 

There is no way to install files to the root directory, or its subdirectories, with the exception of those already present in the Installation Destination. For instance, make it possible to install a file to the following directory: C:\ProgramData\IVI Foundation\IVI

When you are running an execution and you want to check if a step will execute or not depending on the precondition you have to go to the step, browse to the precondition, copy it and paste it in the Watch View...

Wouldn't it be great if you could add your step precondition the the watch view with a single click (like VS "Add Watch")... ideally I'd have another entry in the menu below called "Debug" ot "Watch View" with submenu-items: "Add Precondition to Watch View", "Add Pre-expression to Watch View", "Add Pre-expression to Watch View"

Vote for me!!!

<<- N --.>

When a step cannot be preloaded due to the prototype being out of date (if, for example, a VI was updated after it had been placed in a sequence), an error message pops up telling the user what is wrong. This can then be used to track down where the step is that is causing the issue. Some of the error descriptions get quite lengthy.

While this does provide the user with information as to where the error is occuring, the only option is to click "OK", which then closes the message. In long sequences with many subsequence calls and steps (many of which may be similarily named), it is cumbersome to find the specific step that was listed in the error message that is now no longer viewable. At times I find myself having to get to the general area where I thought the error was listed as occuring, and then click RUN again just to get the error message to pop up again, and then continue narrowing it down (repeating this process several times). This is very cumbersome.

There is a simple solution to this issue. The easiest method would be to simply include a second button in the error message that brings you directly to the step that is causing the issue (with it selected in the step window). This would solve the main issue of trying to find the step that was listed in the error message as being the problem.

To go a step further, there could be a button that simply activates the "reload step prototype" that you have to do once you are at the step that is out of date.

To go even a step further, and solve another issue I would like to see remedied, there could be the option of reloading all steps that call that module (since they are now likely all out of date and need the prototype refreshed). Currently, if a VI is called repeated throughout the sequence, then each one must be found and have its prototype reloaded manually. This is very tedious.

There may be other preloading errors besides the "prototype out of date" issue (ex: VI not found, etc.) that could use the same functionality of a button that brings you to the offending step, but this is what I am running into at the moment.

Regards,

The output messages are a good way of sending status messages from the test solution to the end user.  However the control is not available as one of the controls that can be added to user interfaces.

Can this control be made available to be quickly added to a UI and linked to the execution view manager.

Also adding some kind of API interface to be able to capture these messages to a log file would remove the need to implement any custom logging mechanisms.  If possible ability to open multiple file logs within the engine at the same time with each file given some kind of filter rules (for example Severity=”error” or ExecutionId=5).  If logs had to be attributed to an execution ID then they could automatically be closed when the execution ended, otherwise the user would have to manually close each file which could get forgotten and TestStand end up with lots of open file references.

HI

It would be nice to make Sequences public or private within a SequnenceFile.

With this you where able to make powerful SequenceFiles librarys.  The biggest advantage of this

is you can show the consumer of the library only the "important" public sequences. The

private ones where invisible. This will help to avoid errors.

Regards

juergen

Hi,

Many times I need to run the MainSequence after a change somewhere in a subsequence. Because there is no shortcut key for that action (First go to the MainSequence then Execute->Run MainSequence) it is pretty time consuming. It would be nice to have that shortcut key in TestStand.

Best Regards,

Jick

When developing code for the customization of the User (Operator) Interface, I would like the capability to provide my own custom dialog box for “Loop on Selected Steps” by overriding the standard dialog box that TestStand provides. TestStand provides this standard dialog box when the command kind “Loop On Selected Steps Using” is executed.

The problem in our production environment often is our production technicians are required to (manually) perform interactively with a series of sequence steps and repeat those steps 29 times (Our strict regulatory guidelines). Most of our technicians are technologically challenged in our production environment. In our environment, I have developed the TestStand User Interface to where the TestStand Execution and Sequence Views are hidden to production operators but visible to the developers (engineers) and administrators for trouble shooting capability.

If a custom dialog box cannot be done, at least provide the capability to where I can programmability change the properties of the “Loop On Selected Steps”. At least allow the dialog box to be programmability set to where I can set the number of loops, set the stop condition, stop expression, enable/disable the controls or hide the dialog box without the operator needing to manually entering those values into the dialog box.

Recently I had a problem with a testprogram slowing down after 3 hours of execution.

It was traced to opening a .wav file and not closing it. The .wav file was opened and played 3 time but only closed once.

The problem was discovered by using Windows 7 task manager and looking in the process information display. The number of .wav file instances increased with every run.

Vi analyzer did not find this.

It would be nice to have a tool that monitors the teststand execution and highlights suspicious behavior, like growing resources.

Instrument handles are also an area that can cause memory leaks. If an Ni-Daq is used and not closed, resource usage grows with each run.

The default process models internally enable/disable the PostResultListEntry callbacks in ways that aren't intuitive to users seeking to quickly edit a callback to customize/override behavior. 

It would be nice to see that instead of simply turning off the callback (leaving users to wonder why their override doesn't work like all the others, except if they read the help/ or think to turn on 'on the fly reporting') as part of the process model based on the options....

(1) leave the callbacks on and move the 'on the fly' logic into an IF defined section within the sequence

(2) make a second PostResultListEntrys  style callback that's explicitly for 'on the fly' that is in addition to other PostResultListEntry behaviors that a user may want to enable/add.

I've had several customers now who have designed custom event loggers / reports around the ProcessModelPostStep callback (with some rather convoluted logic where they dig for results)  simply due to the fact that they couldn't understand why their PostResultListEntry callbacks didn't work.... or that they didn't feel comfortable editing the process model in order to remove the logic that force the callback to be disabled when not 'on the fly' and also keep the 'on the fly' reporting unharmed if they want it later.

Cheers,

Elaine R.

I would like to see Shared or Separate FileGlobals available to all Types of Sequence File not just limited to Batch or Parallel Process Models.

Regards

Ray Farmer

Presently we can login into Teststand using the windows login. Carrying this forward it will be good if all Teststand configurations ( ex report type,process model,search directories) are user specific.

This will need maintaining separate config files for each user.

On start Teststand will check the windows user name logged in and accordingly copy relevant config files and configure the Teststand.

It'd be neat, in the scenario when a parallel thread is called, if there was some smooth way of gathering the results back into the main thread of the execution for the sake of the report. 

I've handled this historically by passing a parameter into the subsequence/thread with the ResultList-index of the parent-step, and then doing some notification based handshaking during cleanup of both threads to quickly copy the Result container out of the sub and back to the parent via API calls. But I bet the R&D types could do this far slicker and reduce the whole thing to a checkbox... ;-)

When I create reports they usually look like:

I just think it'd be a simple feature to add for users who might be uncomfortable with the API  & ResultList? (Naturally if the sequence doesn't wait at the end it may never be safe to 'pass back' results. But if you're already killing time on the back stretch, why not copy the block up?

Cheers,

Elaine