NI TestStand Idea Exchange

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

Hi,

 

Exactly as in the subject.

 

Sometimes the names variables are long and could be deeply nested into containers.

 

Now it is difficult to use them as both windows: the main one and Selected are unresizable.

 

After proposed change the property loader would have all default features(behaviours) as you can expect from the window at this place.

 

Current situation presented on the picrure below.

 

850e24cef49a832f99913a8177a26e8e.png

 

The "start modal Dialog" should get an additional input for a VI reference. With this input the start and End modal Dialog VIs could be stored in an FGV, what would clean up the blockdiagram.

Hi,

 

As in subject.

 

It would be good if TS would have an adapter which takls with WebServices.

 

On this Web page under the New Users are links to the various documentation but these links are not very helpful as there just send you to www.ni.com/manuals which cover every manual for every NI product. You are actually quicker doing a basic search for TestStand manuals than using these links. What should happen is you should be directed to the relevant document. ie for the TestStand Reference manual 2010 you would be directed here.

 

* Why not include Configuration files, such as TestExec.ini by default in Deployment Utility?

 

* Also using default settings, nothing appears in the Start Menu/All Programs menu on the target machine. Why not have the main sequence file to be installed so that it appears in the Start Menu/All Programs menu on the target machine?

 

 

Eugene

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.

Like described in this article I have to build Custom Data Types manually to pass enum strings to TestStand.

It would be very nice if I could import LabVIEW Enum TypeDefs into Teststand as Custom Data Types. This way I could save a lot of time.

support capture of std output and std error to variables while displaying normal 'dos' window

maybe by integrating duplication or cloning of the std output and std error streams, like the tee function provides in unix

 

**Added 4/19/2010**

It is nice to have a dos window visible while running executables that take a while to complete.

Often it is important to capture output from executable for parsing.

Currently, if you assign output to a variable, the dos window is not visible.

When editing in CVI, I often find it useful to copy the contents of 'Find Results' into an edit window so I can edit/parse/filter/sort the information.  I would like to be able to do the same thing in the TestStand Sequence Editor.  Saving the Find Results to a plain text file would be an acceptable alternative.

 

Thanks,

JoeN

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

Because a customer asked me about it... And in looking around on the forums I'm surprised there's no opensource 3rd party solution yet to fill this gap Smiley Happy

 

TS has the ability via that little .ocx component to 'ploty' via the graphcontrol tool in an HTML or XML report.  But after many years, there is no 'plotxy'.   As this seems to be a common need for customers, maybe this could be rolled in with other changes? (if it isn't already?)

Finding syntactical errors -- missing arguments, arguments of the wrong type, ... -- involves either manual inspection or running a sequence to see where it croaks.  TestStand could use the equivalent of a broken run arrow from the LabVIEW environment.  As in the LabVIEW environment, clicking on that broken run arrow would present a list of the syntactical errors, and double-clicking on one of the entries in that list would take you to the entry itself.

I would like a built-in tool in the Sequence Editor that would check my sequence file to verify that all expressions used in every step are valid and that all variables called exist. It would be nice to find errors during development/edit time rather than at run-time. I think this could significantly improve the usefulness of TestStand.

Now, when error happens (not during the execution but during the parsing) TS sequence editor displays message like below.

 

Untitled000.png

 

This message can be very meaningless and misleading as it doesn't indicate what is really wrong, it doesn't lead to any file.

It is very difficult to track, because it can happen that after switching the to the development mode this step can be perfectly fine.

 

Request: please do better description and explanation why particular VIs doesn't work with the RTE.

Hi,

 

As in subject.

 

Sometimes the names of the variables are too long and it would be good to see them in full name. Right now they look pretty squeezed. If the developers could do the "maximise" operation it could help.

 

Capture3.PNG

 

 

 

 

The Database Options dialog in TestStand 2013 and 2016SP1 (the versions I have tried) have the key focus set to the 'OK' button. Pressing the 'Enter' key at any point while navigating that dialog will close it and not save the changes.

 

This becomes very frustrating when editing the 'Command Text' of a database statement as you might want to insert line breaks to make editing/reading the statement easier.

 

I have had this happen at least 10 times already today and is very frustrating and is only a very minor change to the Database Options dialog.

 

Hopefully we could get it as a patch?

If you double click a LabVIEW step in TestStand, currently it will sometimes enable you to edit the name of the step.  I think it would be better to have a double click open the LabVIEW VI that is called by the step as that feels more natural then right clicking the step and selecting edit code.

 

 

The Start Modal Dialog VI currently needs to be placed on the block diagram of the VI that needs to be modal.  This means that you can't put it in a subVI with logic around it.  If a VI reference input were added to the VI (with the default being the calling VI) then you could keep the same functionality but have the option of calling this from a subVI.  

 

For those that are running into this, there used to be a workaround here:

http://forums.ni.com/t5/NI-TestStand/Make-Window-Modal-from-SubVI/m-p/492445/highlight/true#M14451

But the link in this forum is now broken.  I'll post back if I find the answer.  

Although LV ring type represents itself like that:

 

Untitled001.jpg

 

TS presents it like a number:

 

Untitled002.JPG

 

Please resolve the names from the ring type in the step settings.

 

K.

The behavior of the TestStand - End Modal Dialog.vi should be changed.  The current behavior is for it to not execute if an error occurred before it runs.  Instead, it should always execute, even if an error occurred before it runs.  With the current behavior, if an error gets passed to the VI, it can cause TestStand to hang.  In general, close or end functions and VIs should always execute even if an error occurred before they run because unintended consequences such as errors, crashes, or hangs can happen if they don't execute.  Yes, you can use the Clear Errors.vi before the TestStand - End Modal Dialog.vi and Merge Errors function to work around this behavior, but it would eliminate the need to do this if the behavior of the VI were changed.