Exposing only parts of a cluster

[codcoder]

Hi, 

So I have this situation where I want to flatten a cluster to a byte array for data transfer. But as things are there are empty spaces between some of the parameters, call it reserved according to the format specification the cluster mirrors.

So to make the flatten process as simple as possible I want to be able to traverse the cluster in a loop so the cluster must self-contain all information.

I am currently solving this by including dummy parameters between the real ones to reflect these reserved areas.

But of course, as you all probably agree upon, I do not want to expose the dummy parameters to the user (the vi will be accessed by Teststand btw).

Som my question is: can some controls in a cluster be private somehow? And if not is there any other smart way to solve it? 

My current solution to this is to create a "public cluster" without these dummy controls and move data between. So a secondary question is there any smart way to do that? I want to keep my code as flat as possible so my idea is simply to use bundle/unbundle but create it using vi scripting.

Edited October 14, 2023 by codcoder
Spelling error

[sam]

you can use the following

1: Flatten to string will give you a binary representation.  Much more smaller, faster, dare I say accurate where numbers are conserned.   But not human readable, you may have to convert it to base64 if you're doing url encoding etc.

2: flatten to xml.   slower, larger, human readable.  take care that numbers with decimal places

3: Flatten to json.  similar to xml, lesser is size, easier to read for some people

4: do your own, but I'd not recommend it..   

 

[Stagg54]

It feels like you are trying to be too clever. Brute force seems like the easier way. Yes it's less elegant. Unless your cluster is enormous, I would probably just brute force it.

[codcoder]

14 hours ago, Stagg54 said:

It feels like you are trying to be too clever. Brute force seems like the easier way. Yes it's less elegant. Unless your cluster is enormous, I would probably just brute force it.

So yes I went for "brute force".

But I managed to solve it using VI scripting, i.e. automatically creating undbundle-by-name from the public cluster to bundle-by-name to the private cluster. So even if the creation process is obscure the result is easy to read by someone who knows only little LabVIEW. Which was what I was aiming for.

[LogMAN]

There is no way to change the scope for elements inside a cluster. You can only hide them on the front panel.

Your solution to unbundle the private cluster and bundle the public cluster is the best way to hide internal complexity.

If you just want to omit certain parameters without explicitly unbundling/bundling, you could also serialize to and from JSON. Of course, this comes at a performance cost.

Note, however, that this only works if the element names are exactly the same.

Here is an example using JSONtext

Convert Clusters using JSONtext.vi

Edited October 18, 2023 by LogMAN

[crossrulz]

11 hours ago, codcoder said:

So yes I went for "brute force".

But I managed to solve it using VI scripting, i.e. automatically creating undbundle-by-name from the public cluster to bundle-by-name to the private cluster. So even if the creation process is obscure the result is easy to read by someone who knows only little LabVIEW. Which was what I was aiming for.

Sounds like an OOP solution is what you really want.

[codcoder]

17 hours ago, crossrulz said:

Sounds like an OOP solution is what you really want.

Well yes from a data structure point of view it is.

It would make sense to store the private cluster as the private data of the class and use a public cluster as an exposed API. But solving the same issue with a library isn't that different.

It doesn't however solve the issue of connecting the public and private data in some smart way. But @LogMAN provided an interesting solutionf or that! I'll look into it!

Edited October 19, 2023 by codcoder

[ShaunR]

You could just draw the cluster on a picture control. You could then easily filter out the "reserved". You wouldn't need to change the UI every time it changes and I expect the user doesn't care what the underlying cluster is.

 

Draw Cluster.vi

Edited October 19, 2023 by ShaunR

[codcoder]

Interesting take but does it fly with TestStand?

[ShaunR]

18 hours ago, codcoder said:

Interesting take but does it fly with TestStand?

Nope. But if you are interfacing to TS then changing clusters will break the connector anyway. You are much better off using strings (like JSON or XML) to TS.