NI TestStand Idea Exchange

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

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%

 

 

Handling arrays in TestStand is pretty limiting and more often that not you have to pop into a code module to perform any sort of array handling.

The following is the default functions that can be used in expressions:

[Array
GetArrayBounds(array, lower, upper) Retrieves the upper and lower bounds of an array.
GetNumElements(array) Returns the number of elements in an array.
InsertElements(array, index, numElements) Inserts new elements into a one-dimensional array.
RemoveElements(array, index, numElements) Removes elements from a one-dimensional array.
SetArrayBounds(array, lower, upper) Changes the bounds of an array.
SetNumElements(array, numElements) Sets the number of elements in a one-dimensional array.

]

 

 

I would like to see this expanded to avoided have to resort to using code module.
The following is some suggestion:


Array Subset function
Array Max & Min
Replace Array Subset function
Search 1D Array
Sort 1D Array

 

 

regards

Ray Farmer

When loading large sequence files, TestStand does not display progress and appears to "lock up" both TestStand and the LabVIEW OI.  Sequences with hundreds of steps can take minutes to load.  Operators often incorrectly conclude the application has stopped respoding during long pre-loads.

 

I am suggesting to implement a responsive progress display, allowing the LabVIEW OI to proceed execution, and post the following UI Messages during step pre-load.

 

UIMessageCodes

  1. UIMsg_ProgressPercent–(Value: 11) TestStand step modules post this message to the user interface to notify it to update its progress indicator associated with an execution.
  2. UIMsg_ProgressText–(Value: 12) TestStand step modules post this message to the user interface to notify it to update its progress message associated with an execution.

 

20869i87D31F1755A9EB9F

Currently, the Installation Destination 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

 

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.

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.

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

For our test we use 48 TestSockets in a Batch process model.

Every TestSocket will gather data for every millisecond while the test of maximal 3 minutes is preformed. A few times per second we like to call a LabVIEW VI and preform some tests on the last few seconds of this data. To give the CPU some time to do other things a 100msec wait time is in between all the tests. While LabVIEW only needs the last few seconds of the array to preform the test, TestStand will take a subset of the array and give this to LabVIEW. But this subset it already taken more than 1.5 seconds in TestStand.

 

Attached is a small Benchmark test that shows (and hopefully explain) this behaviour.

We just make an local array of 180000 data points. (3 minutes with 1msec sample rate)

A for loop of 100 times is done to average the results.

In the loop two VI's are called.

  • One with 100msec wait.
  • The second to receive the array. In LabVIEW the array isn't touched.

 

If we just start with an array from 10000 data points. (the first 10 seconds)

This will take 107.5 msec and about 12.5% of my CPU resources.

Seems good, but the data grows to about 3 minutes, lets test 180000 data points.

This will take 138.5 msec and about 40% of my CPU resources.

We already use 40% of my CPU without doing anything more than give LabVIEW the data.

 

As we don't need the complete data array, it seems not smart to copy everything to LabVIEW. TestStand is capable to take a subset from the numeric array and send this part to LabVIEW.

So if we want to analyse the last 5 seconds, we give the data to LabVIEW like this:

Locals.Array[175000 .. ]

This is only half of the data as the first test, so expected it will be about same in execution speed.

The average execution is now 1.6 seconds, so 1.5 seconds is used for the array subset.

Also the CPU is fully taken by this process. This way our application can't work.

 

As a workaround I send in the complete array into LabVIEW and take a subset in there. This is at the moment faster than take a subset in TestStand, but I would expect that this process can be faster done inside TestStand.

 

I would like to post the idea of an optimized array subset function.

This will optimize the performance of TestStand greatly while working with larger array's.

Especially if you have more TestSockets than CPU cores, like me.

Hi!

 

I was working on a project which required LabVIEW 2011 and TestStand 2010. The software had lots of LV modules already created. I reused some of them. However, I needed to trim whitespaces in TestStand which were coming from the string outputs of these LV modules. Nevertheless, I was surprised to discover that there is no TRIM string function in TestStand at all. I had to create a simple VI which just trimmed the whitespaces. I couldn't modify the previously created modules because they were used elsewhere and could affect the outcome of the other test systems. Why does TestStand lack this simple functionality?

 

Regards,

 

L_A_B