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?