Geek Answers Handbook

Are clusters broken in LabVIEW?

I found this comment in the LabVIEW driver tool manual (section 6.2):

If you need more terminals than the recommended templates, review the grouping of controls and indicators on the VI. With the exception of errors and errors, avoid using clusters to minimize the number of terminals. Clusters often require the user to split and cancel data from a cluster.

If "National Instruments" discourages clusters, what does it mean to "revise the grouping of controls and indicators on the airspace"?

I really like the use of clusters, and I think they improved my VIs. Did I miss something?

+4
source share
4 answers

I think this is probably a poor formulation in the NI documentation. If it makes sense that in a single pass several different values ​​are written or read from the tool or its driver, then the cluster is an appropriate data type. You want to try to avoid a situation where the user must read the data in the cluster so that they can write it back with the changed value. Other good general principles for using clusters, of course, in a distributed / reusable code such as a tool, are:

  • Save cluster as strict typedef
  • Always bind / untie cluster members by name.

This way you can change what's in the cluster without breaking existing code.

+9
source

Linking and sharing is a relatively trivial processor and memory bumps, so performance is not a concern if you are not working in a narrow loop.

However, when the connector panel begins to look like a colorful porcupine, many people will start to drop everything on the megacluster tab. Although this does work (for a while), it ultimately leads to a lot of unnecessary bursts of memory and debugging pain, as things that are not needed in the function are still not copied in the code.

Worse, you may have different megaclones for different VIs, and then you need to transfer between structures.

I usually think this is best when the inputs and outputs begin to become excessive, come back and reorganize one VI into several, each with a smaller, more clearly defined function.

+6
source

Clusters as a data type are accurate. What NI is discouraging is clustering data for the sole purpose of transferring data in sub-vi. If you have data that needs to be shared between multiple vis (or sub-vis), you should consider using a functional global or modifying your architecture to normalize your data.

+4
source

Just as error and error clusters group data logically and allow VI hierarchical parameters, I think that using clusters should also follow this model. And I agree: mega-clusters should be avoided. Personally, as a former C ++ developer, I don't like global variables (although in some cases they are inevitable). I write a lot of explicit multithreaded LabVIEW code, making cross-threading through message queues. (I think this is a legacy of my Windows development days.) Without a cluster or def type. Messaging is almost impossible. And for sure, I definitely use clusters to reduce the number of contacts on the terminal. I do not see this as a problem, because it is not excessive and has a logical meaning.

+1
source

More articles:


All Articles