LabVIEW
How does the "Flatten to string" function actually work?
Hi Tester,
what exactly is your problem?
When I flatten your string I get a different output:
(The string length is prepended with 4 bytes.)
Hi Tester,
I still cannot reproduce your problem:
Can you replicated my litte snippets and post the results?
EDIT: Oh i see this is not a string but the format is actually <Variant:{....}>
Very often you will read comments like this:
When there is a problem with your VI then you should attach your VI! We cannot debug images with LabVIEW!
Providing an example VI to demonstrate the problem is usually the first step to get help!
Gerd, the probe on the Variant does of course not display the garbled binary string but the proper content inside the Variant. The LabVIEW Variant display is smart enough to deal with that.
To the OP, it is unfortunate that there is actually a double encoding in this app. The normal flatten format is well documented and understood (although not trivial at all to decode in something like C#, but that is the problem with any serialization/deseriliation format). The internal Variant format however is a different beast and nowhere documented and to make matters worse it will also depend on the used LabVIEW version. NI specifically reserved the right to modify this format at will by not documenting the binary format of it. The LabVIEW Byte String to Variant funtion is smart enough to observe the embedded version number and adapt accordingly but there is no external library to my knowledge that can do the same and no documentation about the different versions either. There even is a little known gem somewhere in vi.lib that is a special version of the Variant to Byte String function and allows to actually set the desired version of the flattened stream data.
If the input data to Variant to Byte String would be always a string then it would be manageable but why would someone even bother to flatten (serialize) something like that at all? And then even twice?
The second Flatten is in this context almost a NOP. It simply prepends the 32 bit integer with the number of bytes contained in the flattened variant stream, supposedly so the remote side can easily extract a message from the wire by first reading 4 bytes and converting that to a 32 bit integer and then reading as many bytes to pass to the Byte String to Variant function. Then it will likely use the Variant inspection functions to do some sort of reflection like operation to get back at the data.
Well the Variant format is highly dynamic. The problem here is not so much that that even exists and is not documented but that someone who wrote that application decided to use this format to do interapplication communication. That is still fine as long as you know you will stay in LabVIEW on both sides but it is certainly a choice made.
When dealing with sending data over a wire I of course will evaluate first if there is even a remote chance that sometimes down the line someone somehow might want to interface to that from something else than LabVIEW and if that is the case then of course you would not use the Variant format on such a link.
That said even if he hadn't used the Variant to Byte String function but simply the Flatten to Byte String one you would be in for a hard ride despite that that is basically fully documented (well almost as it could contain Waveforms and other special data types that can contain Variants too). I've written my share of code both in LabVIEW and outside of LabVIEW in C, Java and Lua to deal with the flattened format and its highly recursive nature is a sure way to get your brain cells into knots after a short while.
Personally if there is a chance that data needs to be shared on the wire with non-LabVIEW clients I would definitely propose to use something like Json or XML format which are supported too.
If concise data streams are wanted I usually resorted to my own binary data protocol with some header structure that indicates protocol version, protocol element type and such and then the actual data put on the wire exactly like I wanted.
I"m not saying that the actual binary format couldn't be deduced. The variant in essence flattens both the actual type descriptor and the contained flattened data into a single stream. The LabVIEW type descriptor is actually documented in that document you pointed out as is the flattened data format. It's just how these two are exactly put in the overal structure and the fact that everything is made even more complicated by the fact that LabVIEW Variants can have so called attributes which are basically key-value dictonaries with the key being a string and the value being a Variant again and which have to be flattened too. I never have felt inclined enough to really spend any time on this though and I don't find it necessary either.
