How does the "Flatten to string" function actually work?

[TesterTest]

Is there a tutorial for a LabView Dummy like me to understand what you have been doing?
I have no idea how to set up an example like you did 😞

[GerdW]

Hi Tester,

I have no idea how to set up an example like you did

Have you seen my messages and the images inside them?

Yamaeda just used an error cluster instead of a string as input…

[rolfk]

---

@Yamaeda wrote:

So, Variant to flatten data and Flatten data gives the exact same result. As mentioned it's a pure byte conversion sent as text, in this case:

---

You are correct if you apply it to the original data type. Variant to Flattened data will extract the data from the Variant and flatten it. Flattened String will produce the same IF it gets provided the original data. If you however pass the Variant to it, it will create a much longer flattened string as it will embed the type descriptor and any possible variant attributes (or a 0x00000000 value to indicate that there are no attributes) into the data strream.

So the situation is actually the opposite of what I earlier claimed. Use of the Variant to Flattened String will only flatten the actual data into the output string and that is therefore documented. It's still not easy as parsing flattened data is a pretty cumbersome process no matter how well documented the format is. Converting it to JSON instead would allow to leverage of the virtually millions of possible JSON parser libraries out there so you don't have to reinvent the wheel (although developers like to do that of course, which the millions of JSON parser libraries out there proof )

To the OP, if you had posted more than some very tiny image snippets this problem could have been discussed a lot more effectively. Something like this:

And this here is a so called LabVIEW snippet. It shows as pic but one can also download it and simply drag it into a LabVIEW diagram of a LabVIEW version that is the same or a newer version and then one has a VI diagram to actually play with. Even better is of course to attach the (thumbed) down VI. Thumbed down because we do not want to see your top secret application IP but it is very useful to have something to actually play with when trying to help.

[TesterTest]

Please don't stone me - I basicaly opened LabView for the first time two days ago and you have no idea how confusing this stuff is to me.
I made progress with the dll since then by using this:


I tried to return the array because I found that there is some weird mix up in the return value as string - but it is still there even as array. You can see the Hex values in string3 and here is the C# output:

so
0000 0006 476F 746F 5859 0000 0012 402C CD4F DF3B 645A 4025 CD4F DF3B 645A 0000 0000 0000 63C9 846C
gets turned into
0000 0006 476F 746F 5859 0000 0012 402C CD4F DF3B 645A 4033 E6A7 EF9D B22D 0000 0000 0000 63C9 846C when used as return value. That can't be right. Any ideas whats going on here?

[rolfk]

The attached VI and project would be more helpful. I can't really see much in the images even when scaled to original size.

[TesterTest]

Here is the vi - I hope that helps

[rolfk]

Well that about the string is pretty logical. .Net uses throughout UTF16LE strings. LabVIEW however uses 8-bit Multybyte strings. So the .Net wrapper inside the DLL will convert the LabVIEW 8-bit string to a .Net string using MultibyteToWideChar() and that will of course interpret some of the binary values as extended ASCI characters that need to be converted to their Unicode equivalent and that results in a different binary code point, and theoretically even multiple codeponts.

One thing you should do in your code is to actually change the Array - Numeric control datatype to be an Array of U8 instead of an Array of Double. I'm not sure why that would introduce the changes you observe but it is absolutely unneccessary and potentially hurtful to transfer the bytes as double values back to .Net. And of course make sure that .Net actually sees an array of bytes and not something else.

Also the name of that control is probably not so useful. Call it something like bytestream instead.

One unfortunate thing about LabVIEW is that it has traditionally treated Strings and Arrays of U8 as interchangeable. That was sort of true 30 years ago when it was introduced and works for standard western language setups and the typical instrument communication still most of the times but quickly gets in the way when doing more complex network communication or other than western language computer setups. But backward compatibility which is valued pretty highly in the LabVIEW world has so far prevented to make a clear cut and break this association. It is among other things one of the main reasons why they have started to develop LabVIEW NXG but unfortunately its development goes much slower than initially hoped and it cuts with so many things that made LabVIEW a great environment, including seamless multiplatform support. 

[TesterTest]

changed it, receiving byte[*] now in C# instead of double[*] but the wrong bytes are still present.

[rolfk]

From the look at the resulting string it would seem that the y value is different, all the rest stays the same. Are you sure you pass 10.901 into that parameter? And that it is actually a double and not something else on the .Net side of things?

[TesterTest]

Oh wow that would embarrassing - I'll check when I have access to the files again but yeah this could obviously have happened (which I kind of hope it did because that would mean the dll works fine but also I wished I would not have to admit such a stupid mistake) 😄