NI TestStand Idea Exchange

Hello,

If you get memory problems, you had to tune your reports options, result collecting, load / unload modules ....

These tasks are very long, you have to point all memory consumers first ... It pollutes your test sequence only for memory purposes !

When you try to modify the result reccording, you will also have problems for your report generation ...

It should be nice to add a new feature allowing an automatic result list removing, after onTheFly reporting, ontheFly database writing have treted them ...

A kind of "OnTheFly and remove unused results"

When ontheFly reporting, and The OnTheFly database writing are over, the treated resultList should be put in a garbage structure !

Older test results could be removed if memory is needed ...

I know this could be not simple ... but this could help very much, for big sequences creation.

Thanks a lot.

Manu.net (TestStand memory dustman !)

View All (1)

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 --.>

View All (9)

I'm trying to pull out all parameters from a sequence when it errors and save it as an additional result. This is to help the debugging process in a custom report plugin.

It falls over when enums are used as they can't be pulled out as GetValVariants then converted to strings.

I suggest that the if a variant for enum is called it keeps the number and string text inside of it "[5] Item number 6" for example. This can then be interpretted into a string by Str().

Example expression:

Locals.ConcParams = Locals.ConcParams + "Parameter: " + RunState.Caller.Parameters.GetNthSubProperty("",Locals.X,0).Name + " Value: " + Str(RunState.Caller.Parameters.GetNthSubProperty("",Locals.X,0).GetValVariant("",0))

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.

If there's a way to do this already feel free to ignore this suggestion 🙂

I have a process that spawns N parallel measurements for a given DUT at one point during code, and then has a series of wait steps later, to collect all the results / errors / etc.

I have a reaonable timeout, with error generation enabled on the Wait steps as a safety mechanism in event a process hangs (rare, but not impossible). During normal execution these timeouts never trip, and all runs beautifully.

If I set a breakpoint/single-step my execution to troubleshoot one of the measurements during design/debug, often times it takes a while before I 'resume', and when I do, the timeout on the parallel wait immediately trips with error.

would there be some way to make the Wait step's timeout logic 'pause' while execution paused and 'resume' when sequence is executing normally? that way the error I'm trying to trap during debug won't get confused with an irrelevant error for 'you took too long'...

i know I can put conditional logic on the timeouts to discard the error if running inside the debugger, but it'd be cool if the step was just smarter in general

--Elaine R

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.

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,

View All (2)

Hi,

Recently I've discovered that it would be very useful if developers can have a function which allows them to re-initialise all variables and limits containers for all test steps to the default value.

By default value I mean the state as the variables and limits containers are just after the sequence file is open.

This function would be used in the situation when the test station is testing a lot of DUTs one after another and as a result of this the MainSequence is called, but not re-loaded, every DUT tested. Without this function, as it is now, developer have to explicitly reinitialise all variables they are interested in. However, it causes the risk of forget to refresh/reinitialise some variables, which could lead to long and costly debugging.

Proposal (sudo code):

FileGlobals.ReinitialiseToDefault()

Locals.ReinitialiseToDefault()

ResultsContainers.ReinitialiseToDefault()

LimitsContainers.ReinitialiseToDefault()

It looks like to implement it on the sequential model needs a lot of modifications. http://forums.ni.com/t5/NI-TestStand/Loading-default-limits-for-every-execution/m-p/2943434/highlight/false

View All (4)

Trying to minimize memory used by Teststand, I have selected from sequence properties "Disable Result Recording for All Steps". This works great except for sequence which DO need to record results. There is currently no way to override this sequence option to enable recording for the specific measurement steps. I would recommend added an option which allows the step to 'Override' the sequence disable result recording setting. In TestStand 2014 there is an option under the Step / Run Options / Result Recording Options to "Enabled (overriding sequence setting)" but this does NOT work to enable / override the sequence setting, the results don't get recorded. The only solution I found was to NOT enable the sequence "Disable Result Reporting" option on sequences with measurements, and select each step, disabling the Result Recording, except for the measurement steps.

Hi,

I'd like to return to the idea posted by me on the forum here: http://forums.ni.com/t5/NI-TestStand/Concession/m-p/1458500/highlight/true#M31968

It would be very good if teststand would offer the native testing against multiple limits. Let say the test will pass if the measurement is less than 5 and it pass under concesion when is less than 7, otherwise its fail.

So, summarising TS shall have the ability to delinie not only one set of limits per measurement along with the different kinds of passes.

View All (2)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

NI TestStand Idea Exchange

Be abble to automatically remove unused resultLists, after onTheFly reporting, onTheFly DB writing ...

Add Step Precondition To Watch View with 1 Click

Shortcut key for MainSequence run

TestStand Deployment Utility: Have the root directory as an Installation Destination in the Distributed Files tab

Enums as variants and strings

Start Modal additional VI reference input

Break the explicit association between PostResultListEntry callbacks and 'On the Fly' logging

64 Bit Sequence editor

Rendezvous Increment/Decrement size

Feature upgrade: Property Loader: Loading from excel files: Ability to load data from different sheets.

Feature proposal: in "On Run-Time Error" combo box in Execution tab in Station option one option shall be added

Add the explicit if-then-elseif-else syntax to the list of command allowable in the statements and function definitions.

Shared or Separate FileGlobals

Wait Steps with Timeouts Could be Execution-Pause Aware?

Tool to check for open handles or memory leaks

Preloading errors need better usability

New feature request: ReinitialiseToDefault() command

Override sequence disable result recording on all steps

Feature request: Passing and failing against multiple limits

Add to the post actions on fail a Fail execution option