c structure

[CoastalMaineBird]

Well, I'm certain that will NOT work:
You're reversing the order of everything in the cluster.
The first byte of the c structure will come out in the SPARE field.
You can't just willynilly reverse everything, you have to reverse bytes WITHIN each field.

[tbd]

Well, I reversed the postions of everything in the cluster - did you look at it before replying?

[tbd]

Ok, here's the last bit illustrating the idea - casting a serialized C-stru directly to a LV cluster.  It may not be a great idea, but it's (possibly) feasible, on-topic, avoids element-by-element endian-handling - and it's all LabVIEW!

Cheers!

Message Edited by tbd on 08-24-2007 10:49 PM

[CoastalMaineBird]

Well, I went by your picture - I don't have LV on this machine so I don't know what your code actually does.  My apologies.
As you said, it's not pretty, but I don't think there is a pretty solution.

[tbd]

Thanks CMB - no harm done.

---

... I don't think there is a pretty solution.

---

I can't imagine one, though, now somebody'll come-along and "blind-side" all of us. 

Cheers.

[pixelmap]

I'm looking at trying to develop a C/C++ TCP/IP client which has to communicate with a Labview TCP/IP server. I'm a bit worried about the actual data types I can use. Is there any utility out there that allows one to convert labview cluster data into C/C++ structs and also convert C/C++ structs to Labview data?  The labview server is already 80 % complete and uses a mix of cluster data types including variants.

The customer wants the client to look very professional and has insisted on C/ C++ or possibly C#.  Labview seems to have a lot of powerful facilities, so I think this is a problem that must have been solved in real world applications. Thanks for your help.

[Mark_Yedinak]

---

@pixelmap wrote:

I'm looking at trying to develop a C/C++ TCP/IP client which has to communicate with a Labview TCP/IP server. I'm a bit worried about the actual data types I can use. Is there any utility out there that allows one to convert labview cluster data into C/C++ structs and also convert C/C++ structs to Labview data?  The labview server is already 80 % complete and uses a mix of cluster data types including variants.

The customer wants the client to look very professional and has insisted on C/ C++ or possibly C#.  Labview seems to have a lot of powerful facilities, so I think this is a problem that must have been solved in real world applications. Thanks for your help.

---

If you paln to use this data in different applications written in different languages it would be in your best interest to define a simple protocol for passing the data. Yes, you do get some over head but you avoid lots of issues of how each language represents the data. An easy and straight forward protocol would use a header which has a 2 or 4 byte data ID (this could also be a type) and a 4 byte length field. After the header you send the number of bytes given in the length field. If you want to send a structure/cluster you have a simple function that picks the data elements out and adds the header. Your list of data IDs is predefined and acts as part of your API. The nice thing about this is that it is very portable and allows multiple systems and languages to receive/send the data.

Another alternative would be to use XML. Either way, some representations of the data that is language indendent would be your best option. You would also have to agree on byte order. In that sense using network byte order is a safe bet.

[nathand]

A struct and a LabVIEW cluster are essentially the same thing; there's no utility needed for conversion.  LabVIEW may have opposite endianness from a C application running on the same machine, but it's not hard to byte- and word-swap.  LabVIEW may also align items within a cluster differently than C, but again, this is easily solved by adding dummy elements to the cluster as padding if necessary.

However, variants may be a problem.  I don't know how LabVIEW will send a flattened variant over the network; you'd be better off sending some header indicating the data type, followed by the variant data converted to a standard type.

[Mark_Yedinak]

---

@nathand wrote:

A struct and a LabVIEW cluster are essentially the same thing; there's no utility needed for conversion.  LabVIEW may have opposite endianness from a C application running on the same machine, but it's not hard to byte- and word-swap.  LabVIEW may also align items within a cluster differently than C, but again, this is easily solved by adding dummy elements to the cluster as padding if necessary.

However, variants may be a problem.  I don't know how LabVIEW will send a flattened variant over the network; you'd be better off sending some header indicating the data type, followed by the variant data converted to a standard type.

---

Conceptually they are the same thing but they are not interchangeable on a byte level. Different compilers can pack and align things differently. It would be safest to either parse the data explicitly knowing how it is laid out or use a simple protocol as I suggested. I wouldn't rely on a simple LabVIEW typecast to convert a C structure into a LabVIEW cluster or vise versa.

[nathand]

---

@Mark Yedinak wrote:

Conceptually they are the same thing but they are not interchangeable on a byte level. Different compilers can pack and align things differently. It would be safest to either parse the data explicitly knowing how it is laid out or use a simple protocol as I suggested. I wouldn't rely on a simple LabVIEW typecast to convert a C structure into a LabVIEW cluster or vise versa.

---

I wouldn't use a typecast, but, assuming all padding is correct, unflatten from string will work and can adjust byte order if necessary.  Compilers arrange data in standard ways - if they differed, we'd never get library calls working properly.  If a library does expect different packing it should put that explicitly in the header file.  I pass clusters to DLLs that expect structs all the time, and it works.  Going over the network isn't terribly different.  Not that there's a great difference between our suggestions - the layout of a flattened cluster essentially defines a simple protocol, it just happens to be one that should require very little parsing in C.