typecasting Labview variant in Teststand

[kwkengineer]

I'm looking for some help handling conversion from Variant to Data within Teststand.  In the example I have inlcuded the NumericArray that gets passed to a Variant shows up in Labview as "nondisplayable".  Don't know what that means, but it causes errors if I try to use that variant.  Also when reading a string back from Labview as a Variant Teststand seems to display all attribute data instead of just the original string.

I've looked for some API functions for typecasting, but didn't see anything.  I really thought the Labview adapter would do the work for me.

Any thoughts?

Thanks,

Kevin

[jallen88]

Kevin,

Have you taken a look at the following example? It passes a numeric and two strings inside a cluster, but you should be able to follow the same principles to send a string between LabVIEW and TestStand using the same method.

Community Example: Send Data from TestStand to LabVIEW as a Variant

[kwkengineer]

I did see that example.  I hoped there was a better way than having to programatically build a variable in teststand.  I mean, the data type in teststand says "Anything".  In addition this example doesn't address the two problems I'm illustrating in my example.

1. Reading the variant(string) from Labview.  See below, those strings don't match.

2. Writing a numeric array to Labview.  As shown below the Variant Array can be converted back to an Array correctly in Labview. However if I try to use the Variant directly in Labview, say pass it into a Network Stream write, the "Non Displayable" in the Variant value will cause an error.

Thanks,

Kevin

[jallen88]

Kevin,

Is there a reason you need to use Variants? You can pass numeric arrays and strings directly between LabVIEW and TestStand without casting them to variants. This is all built in through the use of the LabVIEW Adapter for TestStand. I'm afraid you might be adding an unnecessary level of complication.

[kwkengineer]

Come on, of course I need the complexity.

I have a LVOOP project that I'm reusing for a Test Sequence.  The LVOOP has some accessor methods that use variants so they can be dynamically dispatched regardless of the data type (the conversion is handled in the method).  I would have loved to call some of these accessor methods directly from Teststand, but because of the issues I've described I can't.  I've had to create specifc wrapper methods to call from Teststand. So now I've lost the dynamic dispatch capability for some of these steps.

Regardless.  I would like to know if this behaivor is a bug in the Labview adapter or if I'm doing something wrong.  Do you recommend I submit this issue to support instead of this forum?

[jallen88]

Kevin,

Would you mind attaching the files you are using so that I can reproduce on my end? I also would like to be able to look at the code to see if anything is being cast incorrectly.

[kwkengineer]

zip file is attached to original post

[jallen88]

Kevin,

Sorry for overlooking that in your original post. Here is a screenshot of when I ran your code. I cleaned up the front panel slightly.

You will notice that the String and Numeric Array passed from TestStand to LabVIEW show up correctly once they are converted into their corresponding data types (the indicators on the front panel are StrData and NumArray). The control variant numArray In shows up as Non Displayable because it must be converted into a numeric array for display.

The data is returned to TestStand correctly for the Numeric Array, but not for the String. This is due to how variant data is represented. It assumes a string represented as an array is a binary string. I am currently looking for a workaround and will report back.

[jallen88]

Kevin,

Here is the process I used to convert the LabVIEW Variant (holding a string) into a TestStand string.

1. Create a new Variable in TestStand of type: Array of Number. Name this TempArray.

2. Make the size of TempArray 256 (or whatever maximum size you expect the string to be).

3. Change the Numeric Representation of TempArray to U64.

4. Set the output of the code module to our newly created TempArray.

5. Add a Post-Expression to the step that converts TempArray into a string and stores it in LocalStrOut. The expression used is: Locals.LocalStrOut = Str(Locals.TempArray, "%c")

[CoastalLabVIEWER]

Does NI have a good reason why this type of thing (variant data) isn't better handled in TestStand?  I tried some code out today where I passed a 2D array of a custom type(Container of 2 Numerics) to LV with variant parameters to have it parse out a row of the data and TestStand magically converted the return data type to Container of array of Containers without so much as an error message.  It would save a lot of development effort if I didn't have to create custom controls on the LV side to support objects that I created in TestStand.