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.

Hi,

Recently I wanted to iterate through ALL my subproperties in the container.

I've discovered that the function GetNthSubPropertyName accessing only first level of subproperties and it doesn't get deeper into hierarchy.

I wonder if it could be an extension to this function - and to all similar functions - allowing iterating automatically over ALL subproperties. For example a new option could be applied here.

Recently I've discovered misleading TestStand behavior.

In the case where in the sequence we have two steps with the same name and we'd like to refer to the SECOND step via its name like shown below:

TestStand allows us to do this, but during the execution, this reference is bind to the FIRST instance of the step:

In this caseTest D should fail showing result 12 not 10.

So, TS allows me to pick a step I want, however it looks like TS binds it to the first match on the list; so it is a lie.

In my opinion TS should either:

--don't let me do this, or

--implicitly bind it using unique step ID.

Anyway the current behavior (TS2014) is ambiguos and shall be treated as a bug.

Hi,

As in subject: allow the *.llbs, build as the Source Distributions in LV Application Builder, to work  with TestStand as indemendent application instances.

K.

Hello,

I have a sequence which must loop a very long time, with cyclic access to hardware components.

In order to limit the amount of memory used by my application i decide to use the famous "Disable result recording" flag.

Beside this problem, my sequence don't have to collapse in case of runtime error (Due to hardware manipulations during execution),

and operators don't have to aknowledge the "error dialog box" ... every time an error occurs !

To handle my runtime errors, i deceide to :

• The main sequence is a loop calling the different fonctionnalities by sequence calls 
• I configure the sequence calls with "ignore RTE", so my mainSequence never stops on runtime error 
• I Configure the "runtime error handling" with the Run cleanup ... so no popup disturbs the operator

This is OK, but i also want to treat my errors (Tracing at least) ... and then i get the folowing problem ...

• The errors are no more accessible using Runstate.previousStep.result.error... ... Runstate.sequence.main.... .... , because i have used the "Disable result recording" flag.
• Storing a runtime error in locals is not possible in post expressions ... because post expressions are not executing after a runtime error

Perhaps the only way to handle my problem would be to use the SequenceFilePostStepRuntimeError callback ... 

But doing so, would need to use stationGlobals or FilesGlobals to get back the error in my main sequence. (A complicate architecture only to get an error !)

So, it would be nice, to be abble to ...

• Let the result recording working
• This make the runstate.previousstep.result.error... works fine
• And sometimes, be abble to flush the result tree (Using a new API function. Something like <Execution>.FlushResults( ....) )

PS : My sequence don't use any report, database writing ... thats why disabling results recording is possible !

I don't know if i am clear ? (And with my bad english ???) 

Manu.