NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Verification of sequence testing

Hi

We have a sequence I would like to verify by running it in a loop (say 100 times) to check the results of the steps in the sequence are repeatable on one UUT.

I am aware you can configure a sequence call to loop 100 times, and record results of each itertation. However the question is how to go about getting a table of data out so we can do some statistics on it to figure out the repeatabiity and amount of noise in the measurements.

 

The standard report format creates a list rather than a table. We could log to a databse - but then have to write a report to get a table out... is there an easy way of tacking this problem? (Our Test results are just single numeric limit tests).

 

 

Regards

Nick 

0 Kudos
Message 1 of 9
(3,115 Views)

Hi,

 

I think there a some solutions to solve this task.

On the one side there are Callbacks, which were called when the step is in a serveral conditions.

Just refer to the manual there is a quite good table that shows when a callbacks are called.

On the other side you are calling a sequence in a loop. What about creating in a .csv - file
in side a your sequence and adding a new line on each iterating? That might be quick and simple

 

hope this helps

 

Juergen

 

 

 

 

 

--Signature--
NIWeek 2017: Standardized HIL Test Automation With TestStand
NIWeek 2016: Capturing ATE Requirements With Requirements Gateway

Feedback or kudos are welcome
0 Kudos
Message 2 of 9
(3,110 Views)

One of the possible solutions :

 

Create the table and do post analysis within TestStand only.

 

For example :

 

Create a array in TS.(2d array of dimension 100 x nooftests)

Modify your test sequence to update the values in this array using the corresponding loop number as reference.

It can be a simple post expression in your test steps ( arrayexample[loop][testno] = sourcevariable)

 

You can do post anlysis using TS expressions or call a VI and pass this two dimensional array for further analysis.

 

You can create this variable in station globals so that values are retained even after testing is done.

Hope this helps.

 

Ravi

0 Kudos
Message 3 of 9
(3,095 Views)

Thanks for you suggestions 🙂 I will try some options and post back where I got.

 

I quite like the callback idea - as it could be easily added / removed for verification testing in a generic way that will be useful going forward.

Expression idea could work too... 

0 Kudos
Message 4 of 9
(3,074 Views)
Hi, have you looked at using a plain text report and dragging that in to excel (other spreadsheet programs are available!!) and then ordering by a column using the step name? That way all the same results will be next to each other.
Should make it a slightly manual step but not too painful. Not tried it myself - just a thought.
Thanks
Sacha
// it takes almost no time to rate an answer Smiley Wink
0 Kudos
Message 5 of 9
(3,050 Views)
I've done this hundreds of times. What database are you using? A query can written in a couple of minutes. I don't know about all databases but the result from a SQL Server query can be pasted directly into Excel and many stat packages. You'll have to write the query at some point anyway. Otherwise why save to one?
0 Kudos
Message 6 of 9
(3,030 Views)

@SachaE Yes - your reminded me I have done the plain text csv into Excel and filter in the past. A bit annoying as names and results are not all in one column as sequence calls push all sub tests right a column (I.e. they are indented). So Excels filter gets filled up with test data and data headers. Easy enough for one offs - but not a good solution going forward. 

 

@

0 Kudos
Message 7 of 9
(2,973 Views)

Managed to get the SQL example from the Lava link working by changing the where line 

WHERE 	(STEP_RESULT.UUT_RESULT =@UGID)

To

WHERE (STEP_RESULT.STEP_ID = @UGID) /*TS 2013 schema SET @UGID = 'ID#:HX6cYoNLqUu3g1+/Q5oDuD' */

That wasn't too bad - will have a play with the SQL...

0 Kudos
Message 8 of 9
(2,971 Views)
We were able to separate the validation data by using different the different user types. Production data was only applied to the operator type. It was another WHERE clause.

I was lucky enough to have a great guy in the IT department teach me a lot about SQL. There are also tons of tutorials on the web.
Message 9 of 9
(2,967 Views)