+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Cluster-Funktion analog Build Array (/Thread-Cluster-Funktion-analog-Build-Array)
Cluster-Funktion analog Build Array - monoceros84 - 19.11.2007 10:58
Hi,
gibt es eine Cluster Funktion (oder einen Workaround), die analog dem Build Array arbeitet? Also Elemente anhängt, statt sie nur zu ersetzen?
Grund: Ein Programm, das jetzt weiterentwickelt wird, sieht folgendermaßen aus. Es hat ein GUI-VI, das in einem Cluster alle Referenzen auf Controls und Indikatoren enthält. Mit Hilfe dieser Referenzen wird in diversen SubVIs auf die Oberflächenelemente zugegriffen - sichtbar/ unsichtbar, Eigenschaften ändern usw. Bisher lief das Programm auf einem PC. Durch den Einsatz der 'To More Specific Class'-Funktion war es ohne Probleme möglich, das Cluster automatisiert zu erstellen und nachher auf die Elemente zuzugreifen.
Nun soll das Programm aber auf einem Realtime-Target laufen, wo 'To More Specific Class' nicht mehr verfügbar ist. Um nach wie vor alle Eigenschaften eines Controls verwenden zu können, müssen die Referenzen wirklich an die Bundle-Funktion gelegt werden - ein automatisches Ablaufen ist nicht mehr möglich.
Da es sich hier aber um mehrere hundert Controls handelt, wird ein Platzieren aller Referenzen im Blockdiagramm einfach undurchsichtig... Meine Idee war eine Schleife mit interner Case-Struktur zu nutzten, ähnlich wie im Anhang. In jedem Case liegt eine Referenz, die dann zum Cluster hinzugefügt wird. Das spart Platz ohne Ende. Allerdings läuft es z.Z. nur als Array wie gewünscht, was alle Referenzen in eine allgemeinere Klasse wandelt. Dann hat man statt einer Referenz auf einen String nur noch eine Referenz auf ein Control. Spezielle Eigenschaften sind nicht mehr zugänglich.
Ich hoffe, ihr erkennt mein Problem und habt eine Idee...
[attachment=9802]
Cluster-Funktion analog Build Array - monoceros84 - 20.11.2007 09:37
Gibt es denn hier wirklich keine Entsprechung???
Cluster-Funktion analog Build Array - Achim - 20.11.2007 10:05
Hi,
nein, ich schätze nicht...das Problem ist einfach, das ein Cluster von der Struktur her was statisches ist, ein Array aber dynamisch. Ein Array ist ein Zusammenstellung gleichartiger Elemente, d.h. sie haben gemeinsame Eigenschaften. Ein Cluster ist ist ne wilde Zusammenstellung...wie soll da ein vernünftiges/allgemeingültiges (!) Handling programmatisch funktionieren? Da müsste es unendlich viele Exceptions geben...
Vielleicht hat ja jemand noch ne Idee, ansonsten wird dir nichts anderes übrigbleiben, als alles einzeln einzusammeln. Du kannst dabei ja ein bisschen gruppieren (evtl. in gestapelten Sequenzschritten), um die Übersicht zu erhöhen!
Aber ganz allgemein: Ich halte es nicht für sinnvoll, auf einem Realtime-System so viel mit verschiedenen Eigenschaften zu hantieren. Sinn und Zweck eines Realtime-Systems soll doch eine optimierte Datenverwaltung/Datenerfassung sein, und keine "kosmetischen Operationen". D.h. die "Messung" ist in Echtzeit und steuert relativ unabhängig vom Benutzer einen Prozess...der kann ja doch nicht in Echtzeit reagieren, d.h. jede Benutzerreaktion bremst dir dein System aus. Der Benutzer muss doch bei so schnellen Vorgängen gar nicht alles wissen..."was er nicht weiß, macht ihn nicht heiß...". Wäre es nicht sinnvoll, die von dir gewünschten Eigenschaften getrennt zu betrachten, sozusagen Offline?
Gruß
Achim
Cluster-Funktion analog Build Array - monoceros84 - 20.11.2007 11:19
Danke Achim. Dann muss ich es wohl so lassen, wie es ist...
Zwecks Realtime-Target und User-Interaktion: Das ganze wird ein Teststand, auf dem mehrere Tests nahezu völlig autonom sequentiell abgearbeitet werden. Also genau das, was du beschrieben hast. Vor, nach und zwischen den Tests wird aber die GUI angesprochen. Zum Beispiel erfolgt ein Login und eine Auswahl der durchzuführenden Tests am Anfang, eine Statusausgabe dazwichen, ein Report am Ende usw. Es ist also nicht zu befürchten, dass Tests ausgebremst werden. Nur wieso soll man für diesen zusätzlichen Schnickschnack noch einen extra Realtime-Host verwenden, wenn das auch so (bis auf paar Kleinigkeiten) ganz gut geht. So wird immens an Hardware gespart - es ist lediglich ein PXI-System für jeden Teststand nötig. Der User-Interaktion kann über Remote Panels von einem zentralen PC (oder sogar von einem anderen Büro aus) geschehen. Es ist sogar möglich, dass Mitarbeiter in Außenstellen den aktuellen Status anschauen. Soviel Flexibilität mit so wenig Hardware ist schon genial - deswegen dieses System...