c structure

[pixelmap]

Thanks for all of the  feedback.The current situation is that the server is sending a two part message; the first is a twelve byte message indicating the size of the message  payload to follow. The message payload is really just a cluster containing the actual message type and data associated with the message type in the form of a variant data type. This cluster is then written to a TCP socket using Write TCP. At the client end we have currently a Labview created client that unwraps the data. What we want is to replace this client with a C++ client. Based on your suggestion it may be that I should try to remove the use of the variant data type and only use clusters instead as they more closely map to structures. I'm not sure how much extra work I will need to do to get rid of all of the variant data types on the server and change to clusters. Its all looking a little bit scary!!!.

The suggestion of using XML is one I have also been thinking about, but I'm not sure exactly how I go about implementing it at the moment.

Another requirement that has come to light is that we have to take a snaphot of the server user interface as a Jpeg and transfer it over to the client so that the client knows exactly what the user settings are. We can take the snapshot as jpeg, transfer the jpeg and read it with our labview client, but how do we get the C++ client to understand the format of the Jpeg data used by Labview.

Again thanks, if you have any suggestions or comments please fee free to reply, but I don't expect anyone to solve it for me.

[Mark_Yedinak]

Another alternative that was suggested earlier was to use flatten to string. This will give you a raw binary representation of your cluster. Naturally the C++ code will have to know what to do with those bytes. It can get a bit tricky with string elements in the cluster since LabVIEW does not have a string length and the data will not be padded.

As for the jpeg issue why don't you have your LabVIEW code save the image to file and then send the file. The file saved is a standard jpeg file and anything that can open a jpeg file will be able to work with it.

[nathand]

---

@Mark Yedinak wrote:

Another alternative that was suggested earlier was to use flatten to string. This will give you a raw binary representation of your cluster. Naturally the C++ code will have to know what to do with those bytes. It can get a bit tricky with string elements in the cluster since LabVIEW does not have a string length and the data will not be padded.

---

If you flatten a cluster containing a string, the string length will be prepended to the string contents, as per the Flatten to String documentation: "Arrays and strings in hierarchical data types such as clusters always include size information."  The "Variant to Flattened String" may help you out.  It takes a variant and gives you the data as a flattened string, similar to if you took the data out of the variant and then flattened it (this is different, however, than flattening a variant to a string, because that string contains information about the variant including attributes and the type of data it contains).  If you modify your header to include the datatype, then you should be able to use Variant to Flattened Data and interpret it properly on the receiving side based on the type sent in the header.

[rolfk]

---

@pixelmap wrote:

Thanks for all of the  feedback.The current situation is that the server is sending a two part message; the first is a twelve byte message indicating the size of the message  payload to follow. The message payload is really just a cluster containing the actual message type and data associated with the message type in the form of a variant data type. This cluster is then written to a TCP socket using Write TCP. At the client end we have currently a Labview created client that unwraps the data. What we want is to replace this client with a C++ client. Based on your suggestion it may be that I should try to remove the use of the variant data type and only use clusters instead as they more closely map to structures. I'm not sure how much extra work I will need to do to get rid of all of the variant data types on the server and change to clusters. Its all looking a little bit scary!!!.

The suggestion of using XML is one I have also been thinking about, but I'm not sure exactly how I go about implementing it at the moment.

Another requirement that has come to light is that we have to take a snaphot of the server user interface as a Jpeg and transfer it over to the client so that the client knows exactly what the user settings are. We can take the snapshot as jpeg, transfer the jpeg and read it with our labview client, but how do we get the C++ client to understand the format of the Jpeg data used by Labview.

Again thanks, if you have any suggestions or comments please fee free to reply, but I don't expect anyone to solve it for me.

---

---

You don't want to pass flattened Variants to anything else but LabVIEW code. The format of that while reverse engineerable isn't to well documented and has the chance of changing when going to a new LabVIEW version.

Parsing flattened LAbVIEW clusters in C is not trivial but for sure a managable task. The other way around is a little more involved since C doesn't really have a standard flattened data format. If you cast a structure containing pointers to memeory buffer, you simply get the pointer values in the memory buffer, not the contents of those pointers. LabVIEW will insert an i32 indicating the number of elements to follow and then flatten the actual string or array data into the stream as well. Your C code needs to do the same when creating a flattened structure to be interpreted by LabVIEW as a flattened cluster, and you need to write that code, C doesn't do it for you.

JPEG is not a LabVIEW format but a fairly standardized data format. The simples aproach is to convert the data in LabVIEW into a stream of bytes and then on your C side, stream it to disk and read it as JPEG file. Or if you have an image display function that understands JPEG and accepts a byte stream instead of a file name, you can directly feed it in to be displayed.

[pixelmap]

Thanks for all your help.

The latest state is that I have removed the use of Variants. Though it works fine for a Labview client talking to a Labview server as they speak the same 'variant' language, so to speak, I found it too difficult to come up with a suitable solution when using a C client talking to a Labview server.  Instead I transfer clusters of data over TCP/IP. That is a lot easier to work with as the fields are fairly easily identifiable. I have created a simple C++ client that can send strings, doubles, enums and ints over TCP/IP to a Labview client. I am still having a problem with the transfer of screen shots from the server back to the client. If I use InvokeMethod / Front Panel Get Image, I am presented with an image format defined as imagedata.ctl. It is this data format that I have tried to transfer over the TCP/IP link. Again, although it is understood by Labview, my C client (aka me) hasn't a clue how to interpret it. Is there any way that I can transfer the screen shots as Jpeg or some other universally recognised format? Or do I have to save as Jpeg to a file and then transfer the file? Any suggestions or comments welcome.

Thanks again,

Dave

[CoastalMaineBird]

I am presented with an image format defined as imagedata.ctl.

--- CTL is not necessarily an image format; CTL is a file extension for CONTROL files: TypeDefs and such.

An IMAGEDATA.ctl happens to describe a particular control containing a type code, a color map, a rectangle, and the image data itself.

AFAIK, there's no easy way to turn that into JPEG,PNG, etc., without going thru a file.  If you know the innards of PNG File structure, you might be able to take the image data itself and construct the file data for transmission.

But the only way I know to use the official coonversion methods go thru a file.  You could use a RAM DISK for speed.

[rolfk]

As far as I know, there are no publically availabel ready made functions to turn an imagedata cluster directly into a JPG or PNG data stream. So the easy way is indeed to write the JPG or PNG file to disk and stream it from there over the network.

I have at some point experimented with my own image importer and exporter library supporting among other formats also PNG and JPG, using the open source C libraries for the respective format, and adding a memory stream variant to the import and export methods didn't look that complicated. But that library has never seen a state that I would consider sufficient to put out for use in any form. One of the actual problems was to convert/adapt between the possible data formats and the actual binary data, in respect to color palette, bit depth, alpha channel and what else different parameters.

I may take another look at my archives and see what is there, but I can't advice anyone to hold his or her breath for them.

[pixelmap]

Hi Steve,

Thanks for the feedback and the clarification. I will look into the options that you suggest.

I am struggling a little with the Labview model of the world at the moment, but I do appreciate that others find it very productive.

Thanks again,

Dave

[pixelmap]

Hi Rolf,

Thanks for taking the time to respond. I will take on board what you say about saving to JPG and streaming over network. Such a pity that there isn't a common way of exchanging data between Labview and other dev environments. I know its not Labviews problem per se, but I do think a common way of representing data would be very useful.

Thank again,

Dave