"anonymizing" a cluster

[ned]

I have an application that handles communication between a control loop and the user interface by passing messages over a pair of queues that contain variants. In order to allow these two loops to run on separate machines, I've added a VI to each loop that dequeues an element, flattens it to a string, sends it over a TCP/IP connection, and does the reverse on the receiving end. This all works great, and since I'm flattening the variants directly to a string I can use it for any data whatsoever that comes over the network.

However, sometimes I'm sending clusters back and forth, and the cluster element names are included in the flattened string, which adds unnecessary network traffic. Is there any easy way to "anonymize" my clusters, either before they're queued or before sending them over the network?

[Darren]

The easiest thing I can think of is to unbundle the cluster elements, then re-bundle them with a Bundle function, with no datatype specified on the middle terminal. This should remove label names from the cluster data, leaving you with only the data types.

-D

[crelf]

Hmmm......

I assume that you don't then use these names at the other end to rebuild you cluster. Are all the datatypes in the clusters the same? If so, you could convert the cluster to an array first (there's a primative to do that) and then send it over (of course, you need to rebuild it on the other end). Even if they are different types, you could unbundle your cluster elements first and then convert them to variants and then send over as an array of variants? I'm just musing, but I hope that I've given you a few ideas

The easiest thing I can think of is to unbundle the cluster elements, then re-bundle them with a Bundle function, with no datatype specified on the middle terminal.

:thumbup: Actually - I like that better than my suggestions.

[Mellroth]

The easiest thing I can think of is to unbundle the cluster elements, then re-bundle them with a Bundle function, with no datatype specified on the middle terminal. This should remove label names from the cluster data, leaving you with only the data types.

-D

If you use the bundle primitive, I think it uses the names of the connecting wires as the cluster element names. Or does this only apply to when inputs are from controls/constants?

I don't have LabVIEW available at the moment, so I'll have to check this tomorrow...

/J

[Mikkel]

Maybe I don't understand what you are trying to do but:

Why are you using variants at all? If you flatten your clusters directly to string, and let your queues contain strings, doesn't this solve the problem? (If you flatten a cluster to string it does not contain element names, but if you flatten the cluster variant it will, at least in LV8.0).

-Mikkel

[jpdrolet]

I have an application that handles communication between a control loop and the user interface by passing messages over a pair of queues that contain variants. In order to allow these two loops to run on separate machines, I've added a VI to each loop that dequeues an element, flattens it to a string, sends it over a TCP/IP connection, and does the reverse on the receiving end. This all works great, and since I'm flattening the variants directly to a string I can use it for any data whatsoever that comes over the network.

However, sometimes I'm sending clusters back and forth, and the cluster element names are included in the flattened string, which adds unnecessary network traffic. Is there any easy way to "anonymize" my clusters, either before they're queued or before sending them over the network?

You don't seem to use the type descriptor so you can use _Variant to Flattened String_ instead of Flatten to string. Then you'll transmit only data, without the datatype (which includes names)

[Darren]

Yup, I didn't realize the item names were carried along the wire after an Unbundle. LabVIEW's too smart for its own good! Since this is the case, I agree that jpdrolet's approach is the best...I just tried it and it works.

-D

[jaegen]

Yup, I didn't realize the item names were carried along the wire after an Unbundle. LabVIEW's too smart for its own good! Since this is the case, I agree that jpdrolet's approach is the best...I just tried it and it works.

-D

But couldn't you create a "generic" cluster with unnamed members, and wire that into the middle of the bundle function? This way the names would get "erased". This has its disadvantages of course (you need to create and maintain this "generic" cluster).

Actually, now that I look at this, here is a better solution:

But note that the type cast won't work if you have strings or arrays in your cluster.

Jaegen

[ned]

You don't seem to use the type descriptor so you can use _Variant to Flattened String_ instead of Flatten to string. Then you'll transmit only data, without the datatype (which includes names)

Right, except that what I'm trying to do here is directly replace an existing queue (carrying a variant) with a TCP/IP connection. If I flatten the variant to a string, then when I read from the TCP/IP connection I can put the data directly into a variant and place it on the queue as though it had come from the queue locally, and the network VI doesn't need to know anything about the type of data in it (thus making the VI easily reusable). If I use Variant to Flattened String, then the receiving network VI needs to be able interpret the data, even though I'm just going to turn it right back into a variant and enqueue it. Also, I'm using variant attributes, which are conveniently transferred when flattening a variant to a string, but aren't available using Variant to Flattened String.

[jpdrolet]

Right, except that what I'm trying to do here is directly replace an existing queue (carrying a variant) with a TCP/IP connection. If I flatten the variant to a string, then when I read from the TCP/IP connection I can put the data directly into a variant and place it on the queue as though it had come from the queue locally, and the network VI doesn't need to know anything about the type of data in it (thus making the VI easily reusable). If I use Variant to Flattened String, then the receiving network VI needs to be able interpret the data, even though I'm just going to turn it right back into a variant and enqueue it. Also, I'm using variant attributes, which are conveniently transferred when flattening a variant to a string, but aren't available using Variant to Flattened String.

The OGTK is at the rescue. Use Variant tools to set the name of each cluster element to an empty string.

However, I think that the solution adds more overhead than simply letting the names. Also, the variant attributes are lost unless you set (or copy/reset) them after the names are removed.