NI TestStand Idea Exchange

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

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?

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

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.

View All (3)

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.

View All (2)

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.

We source control testexec.ini, becuase I want to replicate the custom path information, which is stored in testexec.ini, among our other stations. But, whenever I start teststand, it tries to write to testexec.ini for some reason, and I get the "can't write to testexec.ini" message because this file is set to read only when checked in (which in our case is most of the time). I have become so accustomed to clicking this message that I dont' even think about it.

But, I do have a request to the developers. Please store path information (paths configured under configure/search directories) to a file all by itself, or to a file that does not share so much other information that testexec.ini stores (which is a lot). I notice there is a file called teststandperistedoptions.opt, that appeared around TS2010, that perhaps a lot of the testexec.ini stored stuff can be migrated to? That way I won't get this message every time I start teststand.

At least one other person has had a similar issue.

http://forums.ni.com/t5/NI-TestStand/TestExec-ini-version-control/td-p/1048091

Thanks

David Jenkinson

View All (3)

With the release of TS4.5 there is new way of .net invocation.

The new look of the .net panel was first strange to me.

I was always searching constructor stuff for defining a handle
But after understanding. It is very easy use.

Add especially the feature with the dots is pretty good.
It seems you are doing your stuff in programming language like VS.
But this leads to a “missing” feature. Which is not possible in VS.

In TS 4.5 you may store every return value in a variable.

If your invocation consisting of many “.” calls. You only see the return of the bold function.
So this feature makes some return values “invisible”.
Maybe a tree or using some other colours should make them visible again

Regards

Juergen

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.

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

Include Configuration files, such as TestExec.ini by default in Deployment Utility

Import Enum Item List into a Custom Data Type

enhance call executable step

Wait Steps with Timeouts Could be Execution-Pause Aware?

Copy all 'Find Results' to the clipboard or save to a file in TestStand

XY Graph for TS Report

TestStand needs the equivalent of a broken run arrow

Sequence File Validation

Remove Key Focus from Database Options Dialog (allowing the use of Enter to create line breaks)

Better error handling when TS works with the LV RTE

The "Import/Export Properties..." window (in Tool bar) shall be resizable.

Double Click LabVIEW Step Opens LabVIEW VI

Start Modal Dialog VI should have VI Reference input so it can be called from subVI

Resolve Ring LV data type to names not to numbers

TestStand - End Modal Dialog.vi should execute even if an error occurred before it runs

paths stored in testexec.ini to somewhere else

Enhancement to .net invocation

Optimize the Array Subset function

set the teststand config from the cmd line

File installation destinations should be the same as the default installation base directories in the TestStand Deployment Utility