Jump to content

"anonymizing" a cluster


ned

Recommended Posts

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?

Link to comment

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

Link to comment

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.

Link to comment
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

Link to comment

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 :)

Link to comment
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)

post-447-1163017746.png?width=400

Link to comment
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).

post-932-1163023091.png?width=400

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

post-932-1163023243.png?width=400

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

Jaegen

Link to comment
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.

Link to comment
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.

post-447-1163026253.png?width=400

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.