NI TestStand Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Kyle_M

Simplify exporting arrays of properties

Status: New

Currently, to export properties which are part of an array, such as the limits of a multiple numeric limit test, you have to specify each index of the array separately, like in the first screen shot, or else you get all of the raw XML, which is difficult to interpret and use. 

 

exports2.JPG

 

exports1.JPG

 

 

This is both labor intensive and unituitive. . If instead we had the option to export the array with the "?" and have it parse the information out like in picture 1, it would be much simpler to use.

 

Regards,

 

Kyle Mozdzyn

Applications Engineering

National Instruments 

Regards,

Kyle M.
Applications Engineering
National Instruments
4 Comments
RayFarmer
Trusted Enthusiast

Or maybe format the XML so its easier to read and update such as:-

 

<Locals> Variable Value
texts    <Prop Name='TariffFiles' Type='Array' LBound='[0]' HBound='[2]' ElementType='String'>
                <Value ID='[0]'>text1</Value>
                <Value ID='[1]'>text2</Value>
                <Value ID='[2]'>text3</Value>
                </Prop>

Ray.

Regards
Ray Farmer
asbo
Member

I'd be fine with Ray's suggestion if a stylesheet was included to make dealing with that XML data sane in a viewer (like Excel).

Elaine_R.
Active Participant

I'd prefer for arrays and containers to maintain the row-based export that all other variables do, the addition of extra columns per value gets frustrating when working with sets of more than 3 or 4 values. the column sets for a multiple numeric limit step type get nuts when faced with 10+ subtests inside...

 

it'd be nicer, if somehow the name column can understand indexes when you select the [?] option. Ironically teststand formats perfectly if this is done manually... i.e when I type in Locals.MyArray[0] and press 'export' the file looks fine...

same with containers... it understands the raw values fine when they're spelled out. i.e. Locals.MyContainer.X  it just behaves counter intuitively when faced with top objects... it seems this should be solvable, as it is just a recursion issue...?

 

but if, for example,  I have a 3 element array it'd be wonderfull if TS just understood that when I choose the top level object it should add 3 row entries to my output property file for

 

 

Locals.MyArray[0]

Locals.MyArray[1]

Locals.MyArray[2]

 

or alternately

Locals.MyContainer.X

Locals.MyContainer.Y

Locals.MyContainer.Z

 

and for multiple numerics, it could be the same? but I agree that these could be trickier to parse....

MyMNLT.Measurements[0]

MyMNLT.Measurements[1]

MyMNLT.Measurements[2]

 

 

 

SW_Verifier_11
Member

This is a very important item for me.

 

I'm faced with I/O testing, and with that comes range testing.  Each value (there are hundreds of them) has to be checked for boundary and normal range conditions.  That means, at least 6 tests per value x ~200 values = 1200 numerical compairs. I also have to check the validity code of each value 1200 x 2 = 2400 Numerical Compairs.

 

Now account for the three data points per comparison, High & Low Value and Comparison type; 3 x 2400 = 7200 data items to manage!

 

One potential interum work around could be editing the Export Properties textfield outside of the tool with a text editor.

This woudl be much faster than the current add, edit, and repeat process . . .

 

Regards . . .