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.