LabVIEW計測器ドライバのガイドライン（セクション6.2）で次のコメントを見つけました。
推奨パターンよりも多くの端子が必要な場合は、VI の制御器と表示器のグループ化を再検討してください。エラーインとエラーアウトを除いて、クラスタを使用して端末の数を最小限に抑えることは避けてください。クラスタでは、多くの場合、ユーザーがクラスタからデータをアンバンドルおよび再バンドルする必要があります。
ナショナルインスツルメンツがクラスタ化を推奨していない場合、「VI の制御器と表示器のグループ化を再検討する」とはどういう意味ですか?
クラスタを使うのがとても好きで、VI が改善されたと思います。何か不足していますか？
NIのドキュメントでは、これはおそらく不適切な言い回しだと思います。多数の異なる値が一度に計測器またはそのドライバーに書き込まれたり読み取られたりすることが理にかなっている場合は、クラスターが適切なデータ型です。ユーザーが 1 つの値を変更してクラスター内のデータを書き戻せるようにするために、クラスター内のデータを読み出さなければならない状況を回避したいと考えています。計測器ドライバーのような配布可能/再利用可能なコードでクラスターを使用するためのその他の優れた一般原則は次のとおりです。
こうすることで、既存のコードを壊すことなく、クラスター内の内容を変更できます。
バンドリングとアンバンドリングは、プロセッサとメモリへの影響が比較的小さいため、タイトなループで作業していない限り、パフォーマンスは心配ありません。
ただし、コネクタ ペインが斑入りのヤマアラシのように見えるようになると、多くの人がすべてを「メガクラスター」入力にドロップし始めます。これは (しばらくの間) 機能しますが、関数で不要なものがコード内でコピーされるため、最終的には多くの不必要なメモリの膨張とデバッグの苦痛につながります。
さらに悪いことに、異なるVI に対して異なるメガクラスターが作成され、構造間で変換する必要が生じる可能性があります。
通常、入力と出力が過剰になり始めたら、1 つの VI をいくつかにリファクタリングして、それぞれがより小さく、より明確に定義された機能を持つようにするのが最善だと思います。
データ型としてのクラスターは問題ありません。NI が推奨していないのは、データをサブ vi に渡すためだけにデータをクラスタにバンドルすることです。多数の vis (またはサブ vis) 間で共有する必要があるデータがある場合は、機能的なグローバルを使用するか、アーキテクチャを変更してデータを正規化することを検討する必要があります。
エラー入力クラスタとエラー出力クラスタがデータを論理的にグループ化し、階層的な VI パラメータを許可するように、クラスタの使用もこのモデルに従うべきだと思います。そして、「メガクラスター」は避けるべきだと私は同意します。個人的には、元 C++ 開発者として、グローバルは好きではありません (場合によっては避けられないこともありますが)。メッセージ キューを介してスレッド間通信を行う明示的なマルチスレッド LabVIEW コードを多数記述しています。(これは私の Windows 開発者時代の遺産だと思います。) クラスターまたは型定義がなければ、メッセージングはほぼ不可能です。そして確かに、端末のピン数を減らすためにクラスターを使用していることは間違いありません。それが過度ではなく、論理的に理にかなっている限り、それで問題はないと思います。