LabVIEW 中是否不鼓励使用集群？
我在 LabVIEW 仪器驱动指南（第 6.2 节）中找到了这条评论:
如果您需要的端子数量多于推荐模式，请重新考虑VI上控件和指示器的分组。 除了错误输入和错误输出外，避免使用集群以尽量减少终端数量。 集群通常要求用户从集群中解绑和重新捆绑数据。
如果 NI 不鼓励集群，那么“重新考虑 VI 上控件和指示器的分组”是什么意思？
我真的很喜欢使用集群，并且我认为它们改进了我的 VI。 我错过了什么吗？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为 NI 文档中的措辞可能很糟糕。 如果一次性向仪器或其驱动程序写入或读取多个不同的值是有意义的，那么簇就是合适的数据类型。 您想要尝试避免出现这样的情况：用户必须将集群中的数据读出，以便他们可以在更改一个值的情况下将其写回。 使用集群的其他良好通用原则（当然是在可分发/可重用代码（如仪器驱动程序）中）是：
这样您就可以更改集群中的内容，而不会破坏现有代码。
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:
That way you can change what's in the cluster without breaking existing code.
捆绑和分拆对处理器和内存的影响相对较小，因此性能不必担心，除非您在紧密循环中工作。
然而，当连接器面板开始看起来像杂色豪猪时，许多人会开始将所有内容放入“巨型集群”输入中。 虽然这确实有效（一段时间），但它最终会导致大量不必要的内存膨胀和调试痛苦，因为函数中不需要的东西仍然会在代码中复制。
更糟糕的是，对于不同的 VI，最终可能会产生不同的巨型集群，然后需要在结构之间进行转换。
我通常发现，当输入和输出开始变得过多时，最好返回并将一个 VI 重构为多个 VI，每个 VI 都有一个更小、定义更清晰的功能。
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.
集群作为一种数据类型很好。 NI 不鼓励将数据捆绑到集群中，其唯一目的是将数据传递到子 vi。 如果您的数据必须在多个可见性（或子可见性）之间共享，那么您应该考虑使用功能性全局变量，或更改您的体系结构以标准化您的数据。
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.
正如错误输入和错误输出集群对数据进行逻辑分组并允许分层 VI 参数一样，我认为集群的使用也应该遵循此模型。 我同意，应该避免“巨型集群”。 就个人而言，作为一名前 C++ 开发人员，我不喜欢全局变量（尽管在某些情况下它们是不可避免的）。 我编写了大量显式多线程 LabVIEW 代码，通过消息队列进行线程间通信。 （我想这是我的 Windows 开发人员时代的遗产。）如果没有集群或类型定义，消息传递几乎是不可能的。 当然，我肯定会使用集群来减少终端上的引脚数量。 我不认为这有什么问题，只要它不过分并且符合逻辑即可。
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.