Auch wenn das schon gelöst ist, aber eine Frage die mich trotzdem noch beschäftigt hat: Warum den Cluster schon auf der Oberfläche? Ehe man mit lokalen Variablen rumspielen muss wäre es doch eventuell einfacher erst im Program selbst den Cluster zu erzeugen und auf der Oberfläche nur über rein optische Elemente den Eindruck eines einzigen Clusters bieten.
Gruß Kiesch
Hallo Kiesch,
dein Einwand ist nicht unberechtigt
Aber auch hier: mit einem Cluster hast du im Blockdiagramm nur einen Draht und damit (potenziell) mehr Übersichtlichkeit...
' schrieb:Auch wenn das schon gelöst ist, aber eine Frage die mich trotzdem noch beschäftigt hat: Warum den Cluster schon auf der Oberfläche? Ehe man mit lokalen Variablen rumspielen muss wäre es doch eventuell einfacher erst im Program selbst den Cluster zu erzeugen und auf der Oberfläche nur über rein optische Elemente den Eindruck eines einzigen Clusters bieten.
Gruß Kiesch
Diesen Cluster könnte man auch als Type-Definition speichern. Wenn man nun die auf dem Frontpanel eingegebenen Daten mittels des Type-def Clusters noch an mehrere Sub-VIs übergibt und später den Cluster erweitern möchte, braucht man nur die Type-Def zu ändern und schon sind die Front-Panel das Haupt-VI und aller betroffenen Sub-VIs auf dem neuesten Stand.
Tja Kiesch, die Frage ist wirklich gut. Dann will ich mal versuchen sie zu beantworten... ;-)
Mit einem Cluster im FP erhalte ich im BD direkt ein einzelnes Element, was per se schoneinmal übersichtlicher ist als 7 einzelne LEDs.
Natürlich fasse ich die 7 Datenflüsse im BD zu einem Cluster zusammen um längere Strecken zu überbrücken und eine gute Lesbarkeit des BD zu bewahren. Ich muss jedoch auch wieder unbundle machen um schreiben zu können, da die LEDs ja als einzelne Elemente vorhanden sind. Hätte ich die LEDs hingegen in einem FP-Cluster zusammengefasst, dann könnte ich diese direkt mit meinem BD-Clusterdatenstrom ansteuern.
Ich hab mal ein kleines Prinzipbild gemacht um es zu veranschaulichen:
[
attachment=24203]