Python client to unflatten received string from TCP Labview server

[Sam_Sharp]

If you're using LV2013 or later, I'd recommend using flatten to JSON. It will convert just about any data type into a human-readable (but more efficient than XML) string which you can easily parse in other languages.

Trying to use flatten/unflatten to string is definitely not recommended when talking to other programming languages - it's all based on the internal LV structures and could change between LV versions etc.

[altenbach]

---

@Sam_Sharp wrote:
I'd recommend using flatten to JSON. It will convert just about any data type ...

---

How does it handle dynamic data?

[Sam_Sharp]

---

@altenbach wrote:

---

@Sam_Sharp wrote:
I'd recommend using flatten to JSON. It will convert just about any data type ...

---

How does it handle dynamic data?

---

I did say just about any data type... I just checked and it isn't supported but I didn't look at the OP's VI to see that there was DDTs in there. I would suggest converting to a more standard data type - e.g. 2D array (but you can use clusters).

[maik.holzhey]

Discarding the dynamic data format and the express vi - kind of - solved the problem. I use the conversion: number to fractional string and decode 'ascii' data. This conversion is still buggy but the (readable) values are correct when you plot them. So investigating the best dataformat (or a self-developed,customized protocol) for this will be a bit more try and error but it will eventually work.

The data can now be decoded to correct values, but still the implementation is quick and dirty. But in theory possible.

[altenbach]

I am sure python should be able to interpret flat binary DBL data. All you need to remember is that LabVIEW is big endian.

[Mark_Yedinak]

There is no need to convert the data to ASCII before sending. You can send it in a binary form. You just need to use basic data types. You can easily send arrays of floating point or double values. You can simply flatten the data and send it. Here is an example.

For Pyhton to interpret the data the following should be used.

1D Array

First 4 bytes represent the length (number of elements) of the array. Following that are the values, each represented byte 8 bytes (double) in ANSI/IEEE Standard 754-1985 format. Single precision values would be four bytes long.

2D Array

First 4 bytes is the length of the array. The next 4 bytes indicate the dimension of the array.

Following that are the values, each represented byte 8 bytes (double) in ANSI/IEEE Standard 754-1985 format. Single precision values would be four bytes long.

Whenever I need to send data between languages I use th etrick above. I flatten the data and then display it in a string indicator showing the hex values. From there is it easy to see the format of the data.

[altenbach]

---

@Mark_Yedinak wrote:

For Pyhton to interpret the data the following should be used.

1D Array

First 4 bytes represent the length (number of elements) of the array. Following that are the values, each represented byte 8 bytes (double) in ANSI/IEEE Standard 754-1985 format.

---

If you leave in the size header (You can turns that off in the flatten primitive), it will be redundant if you also send the strings size. One is enough. You simply need to make sure that you multiply by the correct value (e.g. 8 for DBL) depending on the representation to determine the string size. (Of course you can use both as another verification that all data has successfully arrived).

Standard IEEE does not define byte order, so you might need to play with that. LabVIEW is somewhat unique that it is big endian even on a little endian OS such as Windows. Fortunately, the flatten primitive also contains a byte order input to correct for that. You have a 50% chance to get it right on the first attempt. 😄

What is the OS you are running python on?

[Mark_Yedinak]

The nice thing about LabVIEW is that it uses big edian which is also network byte order. Generally most languages will have a primative which allows you to specify the byte order of the incoming TCP data.

You are correct, you could simply send the total length and then the data without the size information from the Flatten To String. Most of the times I loke to include an additional header to the data. This header usually contains the total length of the message followed by a message type followed by the data. That way it is easy to send data of different formats if needed.

[altenbach]

---

@Mark_Yedinak wrote:

The nice thing about LabVIEW is that it uses big edian which is also network byte order. Generally most languages will have a primative which allows you to specify the byte order of the incoming TCP data.

---

I am actually not exactly sure if "network byte order" implies anything for the packet payload. Yes, the various numeric fields in the ethernet, IP, and TCP header (etc.) are big endian, but the payload is just a generic series of bytes to be interpreted by the receiving code. I would have to do some testing.

[Mark_Yedinak]

True, the data is arbitray but the header information should be consistent and defined. Its convenient to have LabVIEW use network byte order internally since it translate to TCP communications very easily.