Are clusters discouraged in LabVIEW?

Question

I found this comment in the LabVIEW instrument driver guidelines (section 6.2):

If you need more terminals than the recommended patterns, reconsider the grouping of the controls and indicators on the VI. Except for error in and error out, avoid using clusters to minimize the number of terminals. Clusters often require the user to unbundle and rebundle data from the cluster.

If National Instruments is discouraging clusters, what does "reconsider the grouping of the controls and indicators on the VI" mean?

I really like using clusters, and I think they've improved my VIs. Am I missing something?

Answer 1

I think this is probably poor phrasing in NI's documentation. If it makes sense that a number of different values are written to or read from the instrument or its driver in one go then a cluster is the appropriate data type. You want to try and avoid the situation where the user has to read the data in the cluster out just so they can write it back in with one value changed. The other good general principles for using clusters, certainly in distributable/reusable code like an instrument driver, are:

• Save the cluster as a strict typedef
• Always bundle/unbundle cluster elements by name.

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

Answer 2

Bundling and unbundling are relatively trivial processor and memory hits, so performance isn't a worry unless you're working in a tight loop.

However, when the connector pane starts looking like a variegated porcupine, many people will start dropping everything into a "megacluster" input. While this does work (for a while), it eventually leads to a lot of unnecessary memory bloat and debugging pain, as things that aren't needed in a function still get copied around in the code.

Even worse, one can end up with different megaclusters for different VI's, and then need to translate between structures.

I usually find it best, when the inputs and outputs start getting excessive, to go back and refactor one VI into several, each with a smaller, more clearly defined function.

Answer 3

Clusters as a data type are fine. What NI is discouraging is the bundling data into clusters for the sole purpose of passing data to a sub-vi. If you have data that must be shared between numerous vis ( or sub-vis) then you should consider using a functional global, or changing your architecture to normalize your data.

Answer 4

Just as the error-in and error-out clusters group data logically and allow for hierarchical VI parameters, I think use of clusters should also follow this model. And I agree, 'mega-clusters' should be avoided. Personally, as a former C++ developer, I don't like globals (though they're unavoidable in some instances). I write a lot of explicit multi-threaded LabVIEW code, doing inter-thread communication via message queues. (I guess this is a legacy of my Windows developer days.) Without a cluster, or a type def., messaging would be nigh impossible. And for sure, I definitely use clusters to reduce the number of pins on a terminal. I don't see a problem with that as long is it's not excessive and makes logical sense.