Interpreting Variants as Flattened Binary Strings from TestStand

[SSMiller]

I successfully saved numerous kinds of LabVIEW data in TestStand variables by converting them to Variants, flattening those Variants to Strings, and then passing them to TestStand as 'Binary Strings.' This works wonderfully, in so far as the data always seems to be stored and read back by LabVIEW accurately.

The trouble is with human readability. When at look at the value of the string in TestStand, it is understandably unreadable. What's more, when I cut and paste the string from TestStand to LabVIEW (in order to check the value with a quick conversion utility), the string looks significantly different than what shows up on the input terminal of a LabVIEW action step reading the TestStand variable directly. My first question is, what machinations must I perform on this cut and pasted string to be able to Unflatten back to a variant, other than reading it in using a LabVIEW action step? Surely TestStand is performing some operation that I should be able to duplicate in code.

My second question regards using "Flatten to XML" over "Flatten to String." This makes the stored variant much more human readable. The problem I have run into is that when I "Unflatten from XML", a generic Variant constant doesn't seem to be good enough (throws an error about not being the same data type). It only appears to work when I unflatten using the exact kind of Variant as when it was flattened! (i.e. if I convert a double to a variant then flatten to XML, I can't unflatten with a variant constant, I have to convert some double to a variant and unflatten with that) This kind of defeats the whole purpose of using variants. Does anyone know a workaround?

Lastly, all of this is to say I would like be able to store variants from LabVIEW in TestStand in a way that is human readable. This allows for versatility, convenience and broad usability, without worrying about custom step types, container/cluster compatibility, etc. etc. and still allow quickly checking that the data looks right manually. Has anyone successfully achieved this?

[Benjamin.S · Accepted solution]

Hi SSMiller,

I have some info and links below that may be helpful if you're still having difficulties with this issue.

1. Could you show pictures showing the differences between the cut and pasted TestStand string and what is in LabVIEW directly? I wonder if copy paste doesn't work for certain characters as a fault of Windows, or if the string is just different because the values are different.

2. General tips that I think you mostly covered.

Write Readable Variant Data to a Text File

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LATSA2&l=en-US

3. While the suggestion in this suggested solution posted in the comments may be a little harsh, I would suggest giving it a try in regards to working around the data type issue

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-Unflatten-From-XML-create-any-Variant/idi-p/1141...

Best,

Ben

[SSMiller]

First, thank you very much for your reply.

I've included an image as requested:

The above is an example of the LabVIEW version and the TestStand binary version of the same string, converted to a variant, and then flattened to string (redundant, but illustrative). As you can see, there is significant difference, mostly (I think), because TestStand doesn't support non-printable characters and LabVIEW does. In my original post, I was mostly interested if anyone knew what algorithm or process TestStand uses to convert the strings from LabVIEW to its native format, if it was some standard, or proprietary, and how I might undo it/reverse it/implement it in LabVIEW for quick cut-and-paste value checks, etc.

At this point, I think the easiest thing to do would be to use flattened XML. The tip in the link of your point 3 is super useful, and one of those things that seems dreadfully obvious in hindsight.