NI TestStand Idea Exchange

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

A nice feature of reporting is the ability to form the report file pathname using an expression.  However, since the path is resolved before the client Sequence file is executed, you cannot use properties populated in the client sequence file as part of the report pathname. Currently the only way to accomplish this without modifying the model or reportOptions callback is by including the <UUTStatus> macro in the path expression, which enables a portion of the process model which copies the report to a new path based on the result of the UUT:

 1.png

 

I propose that we add an option to force the report path to be re-evaluated after the client sequence to allow users to include properties evaluated in the client sequence file in the report file path without needing to include the <UUTStatus> macro.  (basically exposing the ReportOptions.NewFileNameForEachUUTStatus property in the dialog)

 

2.png

 You can copy the value of a selected variable to another element.

CopyValue.png

 

But you cannot paste the value into the selected element in an easy manner.

No_Paste_Value.png

 

What you have to do is click into the selected variable’s value field and then Paste, but this doesn’t produce the correct result (for strings anyway)......

 

PasteValue.png

 

You end up with is double quotes!!!

 

Resultant Paste.png

 

Also if you had ‘Copy Value’ on multiple selected elements and pasted them then you get

 

multiple selection.png

 

So it cannot handle multiple selections.

 

It would have been better if you could have selected the place where you wanted to paste the value(s) and a new menu item became available ie ‘Paste Value’.

 

New_PasteValue.png

 

This way should also be able to handle multiple selections.

 

The problem with double quotes shouldn’t occur and should be corrected with the current pasting of values.

 

It would be nice to integrate VeriStand into TestStand with a VeriStand Adapter.

 

veristand adapter.png

 

 

 

 

 

 

 

 

 

 

 

This would make developing with TestStand and VeriStand much easier. The adapter would provide a lot of the VeriStand .Net api natively to testand:

 

- Deploy a system

- Set/Get Channel(s)

- Stimulus Profiles

- etc.

 

The adapter would be especially nice for integrating the new Stimulus Profiles in VeriStand 2011. It would allow for you to create the Stimulus Profile sequence and the Real-Time sequence. The Real-Time sequences would only be able to use a subset of TestStand steps, and would have to be different than a normal TestStand sequence because they are executed by the VeriStand engine, but the Stimulus Profile sequence could be a normal TestStand sequence.

 

The integration of the Stimulus Profiles would leverage a lot of features TestStand already has like source control, requirements, reporting, etc. Also, it would just give the user a much more intuitive experience when using the two together. Their test development would be centralized in TestStand instead of having to switch between the two different editors. It would also give better access to the parameters being passed into the Real-Time sequences at the TestStand level.

 

There are probably more benefits that could be realized by integrating TestStand and VeriStand, and this is a feature I would love to see as a user of both TestStand and VeriStand.

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.

Currently, if you create a step type and name it OnNewStep, it will execute when an instance of the step is created.  This is pretty confusing to new users - why don't we just have an OnNewStep substep type (like prestep, edit, etc)? Custom steps would then just be meant to be called manually using the Step.ExecuteSubstep() Method as documented in the help.

 

onNewStep.png

 

We could keep the "onNewStep" custom step functionality to maintain backwards compatibility with older step types. 

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])

Having the ability to have line numbers for all steps in the left hand gutter would help in troubleshooting, code reviews, and any time when communicating about a sequence.  There seems to be a gutter there already, so adding there seems to be a place for them already.  Error messages can also post the line number too.

 

The NI-VISA Adapter could present steps that would related to the VISA Interactive Control application (Write, Read, Write from File, Read to File, Assert Trigger, Read STB and Clear). This would allow a developer to create a sequence that checks/calibrates a test station consisting of source, sense and fixture loop-back elements with out dependence on a particular adapter or version of an adapter.

 

I admit that the IVI adapter is already available, but not everyone uses ( or likes Smiley Tongue ) IVI technology.

 

20623i540AD8DC05484B78

 

It would be nice to be able to "fold" control flow blocks (like if - else -end, while - end etc.). Despite the vertical lines connecting the control flow steps on the same level, it is sometimes very hard to find where a long control block actually ends or what the condition for the "end" is you are currently looking at.

 

In such cases it would be helpful, if the entire control flow block could be hidden under its first line, tree-view like with a +/- icon to show/hide the interior of the block.

 

Regards

 

Peter

I've encountered on several occassions, especially with complex testing, customers who are frustrated by the inherent 'flicker' that happens when stepping into and out of subsequences of logic. This leads to people opting to not use sub sequences, or creating complex replacements for the execution view that has a more persistant way of presenting the executed step data.

 

I'd like to see an optional setting for execution viewing that allows for sub sequences to be shown as expandable nodes (perhaps defaulted to 'collapsed') so that low level test operators can see the overview results at the sequence-call level, but so advanced users can expand for details if they're interested without added pulldowns or tabs for additional information.  this could be one more API property similiar to showing one-stepgroup or showing all, so that developers can chose whether to be more efficient, or display-heavy....

 

expanded results on sequenceView

 

In scenarios with dynamic sequence loading, the display might simply show a 'no pre-loading possible' sort of message until the execution actually gets to that portion of the sequence.

 

Cheers, 

 

Elaine R.

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