NI TestStand Idea Exchange

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.

Hope it will be good to have AddArrayElements in TestStand (OperatorslFunctions) which will reduce effort using Loops to do the same function.

There should be an Engine Callback that is executed as the very last step in the order of step execution that will execute regardless of any and all settings or step results: the PostStep "No-Matter-What" Engine Callback.  I have a requirement to perform certain actions at the end of every client sequence step regardless of step, station, report settings as well as step results (Status, Error).  Right now, the callback that gives the best coverage is ProcessModelPostResultListEntry, but this does not fire when client sequence developers set Result Recording Option for a step to False.  My requirements call for my actions to execute whether or not the developer of the client sequence desires the results to land in the TestStand report or not.  As with other callbacks, if it is blank, the engine can skip it. 

The PostStepNoMatterWhat callback would execute regardless of all these, but as an aid to Framework developers, NI should provide a matrix for each of the default Process Models that shows which of the engine callbacks will execute given the following data:

1. Step.Result.Status {Done, Skipped, Passed, Failed}
2. Result Recording Option {Enabled, Disabled}
3. Step.Result.Error.Occurred {True, False}
4. Run Mode {Normal, Skipped}
5. Ignore Run-Time Errors {Enabled, Disabled}
6. On-The-Fly Reporting {Enabled, Disabled}
7. Error Dialog Selection {Ignore, Run Clean-up, Abort}