Numeric Limit Test result recorded to database in different manner dependent on adapter used.

[herrlin]

1.0   Problem statement:

If a step using the Adapter: Sequence, uses the Type: NumericLimitTest, its results are not logged to the database in the same manner as a step that uses the Adapters:  LabVIEW or <None> (other adapters may fall in this bin but these are the only others I use). This forces data associated with NumericLimitTest to be retrieved in different manners, duplicating the effort of data analysis tools.

2.0   Details

2.1     Steps that use:

• Adapters: LabVIEW or <None>
• Type: NumericLimitTest

Log measurement results in the following manner:

Measurement information is stored in an explicit column for its type (high low limit, compare operator) this is the desired method for ease of data retrieval and analysis.

DB Table [PROP_RESULT] (Stores measurement name and measurement value)

ORDER_NUMBER	NAME	PATH	CATEGORY	TYPE_VALUE	TYPE_NAME	DISPLAY_FORMAT	DATA
0	Numeric	Numeric	2	0	NumericLimitTest		0

DB Table [PROP_NUMERICLIMIT] (Stores limit test specific information)

COMP_OPERATOR	HIGH_LIMIT	LOW_LIMIT	UNITS	STATUS
GELE	11	9	NULL	Failed

2.2     Steps that use:

• Adapters: Sequence
• Type: NumericLimitTest

Log measurement results in the following manner:

All step information is logged to the [PROP_RESULT] table in an Entity Attribute Value model format. (Difficult to work with from a SQL retrieval perspective)

DB Table [PROP_RESULT] (Stores data a measurement name, measurement value, measurement attribute(s) name and attribute(s) values)

ORDER_NUMBER	NAME	PATH	CATEGORY	TYPE_VALUE	TYPE_NAME	DISPLAY_FORMAT	DATA
1	Numeric	Numeric	2	3	Number	%#.2f	14.95969
2	Units	Units	2	1	String	NULL	V
3	Limits	Limits	2	0	Container	NULL	NULL
4	Low	Limits.Low	2	3	Number	%#.2f	14
5	High	Limits.High	2	3	Number	%#.2f	16
6	Comp	Comp	2	1	String	NULL	GELE

3.0   Suspected causes  

1. It is suspected that this might be related to the fact that Sequence Call steps appear to not only be Adapter based but also have a type associated with them, aka SequenceCall type. This type is changed to NumericLimitTest when it desired to evaluate a measurement associated with the sequence call.

4.0   Development Environment Configuration:

• TS Version: Confirmed issue using both, TS2012 and TS2014
• Database Schema (result recoding config): Using a slightly modified version of the Generic Insert routine (see mod schema attached). I feel this is not related to the mods however I have not had the time to confirm at this point.  The mods are only to add additional information to the UUT_Resutls table.

5.0   Desired Outcome:

To be able to use steps with the adapter: Sequence of type: NumericLimitTest that log data in the same format as described in part 2.1 of this document.

The following workaround could be used but an alternative is desired so that this could be corrected at the test station level so that existing sequence file would not have to be individually updated and validated.

6.0   Known Workarounds

Use only steps of adapter: Sequence of type: SequenceCall and pass values from sequence call to steps of an adapter: <None> of type: NumericLimitTest for evaluation and logging of the measurement.

[herrlin]

I think I figured this one out.

In Database Options window on the Statements Tab there is a Traversing Options.  On the Traversing Options for the STEP_SEQCALL statement the “Skip Remaining Steps Result Statement for this Step” was checked, this seems to be the default for all the default schemas except “SQL Server Stored Proc (NI).”  Unchecking this option resulted in the results being stored in the same fashion as the other NumericLimitTest using other adaptors.

This doesn’t seem to have had any negative consequences as far as how other results from steps that use the sequence adaptor act.  Although, it would be nice for if a NI Eng could reflect on why this option is selected by default and if they see any consequences to deselecting this option.

Thanks