zu viele Übergabevariablen/zu wenig Connectors

Hallo Experten,

folgende Situation:
Ich habe ein Haupt-VI mit üppig gefülltem Frontpanel. Von einem Sub-VI aus brauche ich zahlreiche Werte vom Frontpanel des Haupt-VIs und muss ständig auch welche aktuallisieren.

Mit bisher genutzen Übergabevariablen (inkl. Referenzen) geht das ganz gut, solange die Zahl überschaubar bleibt. Was aber wenn es zu viele werden, bzw. die Connectors nicht mehr ausreichen?

Eine Lösung wäre eine Clusterbildung, aber das Bündeln und Entbündeln nimmt mir auch zu viel Platz weg. Mir schwebt eher vor eine Art objektorientierte Übergabe der Frontpanel- oder Haupt-VI-Referenz (nur eine Übergabevariable), im Sub-VI würde ich dann gern auf die Children dieser Referenz, also die Bedienelemente usw., direkt zugreifen.

Geht so was? Hat jemand eine Idee?
Bitte postet bevorzugt keinen Code sondern stattdessen Screenshots, aufgrund meiner antiken LabView-Version.

Danke schon mal für alle Hinweise!

Hallo db,

Zitat:Eine Lösung wäre eine Clusterbildung, aber das Bündeln und Entbündeln nimmt mir auch zu viel Platz weg.

Du nennst doch selbst schon die beste Lösung. Wieso also nicht nutzen?
Das Platzargument relativiert sich, sobald man UnbundleByName verwendet und sofort die Klarnamen der Werte sieht...

Zitat:Mir schwebt eher vor eine Art objektorientierte Übergabe der Frontpanel- oder Haupt-VI-Referenz

Was ist an einem Cluster nicht "objektorientiert"? Selbst die LV-OOP-Implementierung sieht wie ein besserer Cluster aus...
Ich hoffe, du greifst nicht dauernd auf PropertyNodes der FP-Elemente zu!? Dies wird auf Dauer dein VI ausbremsen...

Zitat:Ich habe ein Haupt-VI mit üppig gefülltem Frontpanel.

Ein VI kann auch ein üppig gefülltes FP haben und trotzdem Daten in schönen Clustern verwalten...

(21.06.2012 15:57 )GerdW schrieb:  Hallo db,

Zitat:Eine Lösung wäre eine Clusterbildung, aber das Bündeln und Entbündeln nimmt mir auch zu viel Platz weg.

Du nennst doch selbst schon die beste Lösung. Wieso also nicht nutzen?
Das Platzargument relativiert sich, sobald man UnbundleByName verwendet und sofort die Klarnamen der Werte sieht...

Finde ich trotzdem suboptimal. Wenn dein Diagramm z.B. schon so aussieht:
   
Dann willst du noch in dem begrenzten Platz ein riesiges Cluster bilden mit 20 oder mehr Elementen? In dem Sub-VI "Create Snap Cluster" habe ich das schon teilweise etwas unschön - von hinten durch die Brust ins Auge - ausgelagert, aber halt nicht wirklich elegant. Zusätzlich muss ich das Cluster ja verborgen auf dem Frontpanel hinterlegen oder wie bei dem Fehlercluster live im Diagramm initialisieren, beides braucht Platz.

Zitat:

Zitat:Mir schwebt eher vor eine Art objektorientierte Übergabe der Frontpanel- oder Haupt-VI-Referenz

Was ist an einem Cluster nicht "objektorientiert"? Selbst die LV-OOP-Implementierung sieht wie ein besserer Cluster aus...
Ich hoffe, du greifst nicht dauernd auf PropertyNodes der FP-Elemente zu!? Dies wird auf Dauer dein VI ausbremsen...

PropertyNodes nutze ich sparsam, eher lokale Variablen! Aber was ist der beste Weg, ich kann sicher auch hier noch was lernen?

Zitat:

Zitat:Ich habe ein Haupt-VI mit üppig gefülltem Frontpanel.

Ein VI kann auch ein üppig gefülltes FP haben und trotzdem Daten in schönen Clustern verwalten...

Da gebe ich dir recht, aber das zieht ganz schön Arbeit nach sich um im Nachhinein das ganze VI anzupassen.

Hallo db,

Zitat:Wenn dein Diagramm z.B. schon so aussieht

Dann wurde im Vorfeld viel falsch gemacht...

Zitat:Dann willst du noch in dem begrenzten Platz ein riesiges Cluster bilden mit 20 oder mehr Elementen?

Der eine Clusterdraht belegt nicht viel Platz! Das Unbundle benötigt auch nicht mehr Platz als deine ganzen lokalen Variablen!

Zitat:PropertyNodes nutze ich sparsam, eher lokale Variablen!

Lokale Variablen nutzen dir bei deiner Fragestellung nichts, du willst ja mit subVIs arbeiten!

Zitat:was ist der beste Weg

Den gibt es selten bei der Softwareentwicklung...

Zitat:aber das zieht ganz schön Arbeit nach sich um im Nachhinein das ganze VI anzupassen.

Grundregel der Softwareentwicklung: Wenn man sich vorher kein ordentliches Design überlegt, bezahlt man das später mit erhöhtem Supportaufwand mehrfach!

Mal überlegen: du hast lt. Eigenbeschreibung 8 Jahre LabVIEW-Erfahrung?
Und willst nicht mit typdefinierten Clustern arbeiten?

Danke, Deine Hinweise haben mir viel gebracht . Ich wollte nicht belehrt werden, sondern habe nach Hilfe gefragt!

Wenn ein Projekt über längere Zeit wächst, am Anfang der jetzige Zustand noch nicht annähernd abzusehen war, ja, dann kommt halt so was raus. Man beachte auch ich bin schon bei Ereignis 53, und das sind noch nicht alle. Jetzt könnte ich das gesamte Frontpanel in ein Cluster reinschmeißen oder viel Zeit verbringen einzelne Teile in Cluster zusammenzufassen. Ob das sinnvoll ist, weiß ich nicht. Schließlich habe ich auf dem Frontpanel ja Bedien- und Anzeigeelemente, in den Sub-VIs brauche ich teilweise dessen Referenzen, damit während das Sub-VI noch läuft das Frontpanel des Haupt-VIs aktuallisiert wird. Müsst ich ausprobieren, ob das überhaupt so funktioniert.

Zitat:Und willst nicht mit typdefinierten Clustern arbeiten?

Mit typdefinierten Clustern habe ich in der Tat noch nicht gearbeitet, aber ich werde mich mal damit auseinandersetzen.

Zitat:Der eine Clusterdraht belegt nicht viel Platz! Das Unbundle benötigt auch nicht mehr Platz als deine ganzen lokalen Variablen!

An gezeigter Stelle ein Cluster bilden fällt für mich aus. Das habe ich vorher schon geschrieben warum. Darum geht es mir ja eigentlich. Cluster zerlegen im Unterprogramm sehe ich auch nicht als Problem.

Letztendlich bin ich jetzt immer noch nicht weiter. So wie ich mir das vorgestellt habe über eine VI-Referenz-Übergabe scheint es ja nicht so einfach zu laufen.

Hallo db,

Zitat:Ich wollte nicht belehrt werden, sondern habe nach Hilfe gefragt!

Du zeigst uns ein VI, welches völlig an allen NI-Guidelines vorbei programmiert ist (und die gibt es schon ziemlich lange) und erwartest, dass dir jemand Empfehlungen gibt, wie man ein solches Konstrukt noch verschlimmbessern kann?
Wenn dir schon ein 28-ConnectorPane nicht ausreicht (welches an sich schon von NI nicht empfohlen wird), dann hast du definitiv etwas falsch gemacht...
Wenn du partout mit der VI-Referenz arbeiten willst, dann mach das doch!

Du musst so vorgehen:
Vi-Referenz->Referenz auf das FP->Referenz auf alle Controls->einzelnes Control anhand seines Labels suchen
Ist mindestens genauso aufwendig und kann sehr langsam werden (jede Menge PropertyNode-Aufrufe und UI-Thread-Switches).

Zitat:An gezeigter Stelle ein Cluster bilden fällt für mich aus

Dies habe ich auch nicht empfohlen.
Der Cluster wird stattdessen schon weit außerhalb deiner Haupt-Whileschleife definiert und jedes Event und jedes subVI greift darauf zu...

Ich würde trotzdem ein sauberes Redesign empfehlen, um folgende Punkte abzuändern:

Zitat:Man beachte auch ich bin schon bei Ereignis 53

Man kann Events manchmal zusammenfassen.
Man kann Events "benutzerdefiniert" anlegen und in subVIs abarbeiten lassen.

Zitat:damit während das Sub-VI noch läuft das Frontpanel des Haupt-VIs aktuallisiert wird

Events sollten immer schnell abgearbeitet sein und nicht durch subVIs blockiert werden! (Steht so in der Kontexthilfe!)

Anzeige

Danke, geht doch! Das war doch jetzt viel konstruktiver.

Zitat:Du musst so vorgehen:
Vi-Referenz->Referenz auf das FP->Referenz auf alle Controls->einzelnes Control anhand seines Labels suchen
Ist mindestens genauso aufwendig und kann sehr langsam werden (jede Menge PropertyNode-Aufrufe und UI-Thread-Switches).

So habe ich das auch schon hinbekommen. Gefällt mir auch nicht richtig, gerade weil man die Elemente einzeln suchen muss und die Daten auf diesem Weg immer nur als Variant vorliegen, also noch entsprechend umgewandelt werden müssen. Aber es funktioniert immerhin so.

Zitat:

Zitat:Man beachte auch ich bin schon bei Ereignis 53

Man kann Events manchmal zusammenfassen.
Man kann Events "benutzerdefiniert" anlegen und in subVIs abarbeiten lassen.

Das mache ich schon, sowohl zusammenfassen als auch benutzerdefinierte. Es passieren wirklich 53 (und noch mehr) unterschiedliche Dinge, da sehe ich keine anderen Möglichkeiten.

Zitat:Ich würde trotzdem ein sauberes Redesign empfehlen

Da gebe ich dir uneingeschränkt recht, sollte sich ein Zeitfenster finden werde ich mich da mal ransetzen.

Also hier auch was Konstruktives - so hoffe ich.
Ich weiß nicht, wie es sich bei Version 7 verhält, aber bei Version 11 habe ich durch eigenes Nachmessen folgendes festgestellt:
Die Behauptung, das globale Variable langsam sind, ist weiter nichts als üble Nachrede. Wahrscheinlich war es früher mal richtig, und was sich einmal in den Köpfen eingebrannt hat ist schwer wieder herauszubekommen.
Von da aus gibt es überhaupt keine Bedenken, globale Variablen zu verwenden.
Ich würde GVs allerdings aus verschiedenen anderen Gründen nicht zum zeitkritischen Datenaustausch verwenden. Die meisten Variablen in einem Programm sind aber keine echten Daten, sondern eher sich selten ändernde Werte und somit eher Konstanten als Daten. (Beispiele: Variable, die nur bei der Initialisierung beschrieben werden. Variable, die sich nur durch Bedienung ändern. Und: Referenzen).
Die Verwendung von globalen Variablen in solchen Fällen ist der Königsweg, um das Drahtwirrwar von und zu SubVIs entscheidend zu beseitigen und die Übersichtlichkeit eines VIs zu verbessern.
Gegenüber FGVs haben globale Variable den Vorteil, dass man alle GVs in einem einzigen VI definieren kann. Bei FGVs bräuchte man für jede Variable ein eigenes SubVI.

Bitte an alle: Jetzt kein weitere Diskussion über das Für und Wider von GVs im Allgemeinen, und bitte auch keine Warnungen über Wettlauferscheinungn usw. Wer es dennoch nicht lassen kann, möge sich bitte auf einen Link zu einem der (gefühlt) 10^6 einschlägigen Warnungen hier im Forum beschränken.

Was mir im Thread auffiel: Da wird vor SubVis in einem Ereigniscase gewarnt, so als ob das 10 mal so lange dauern würde als der direkte Code. Dabei fällt aber wohl keinem auf, dass sich in dem abgebildeten Ereigniscase eine Wartefunktion von sage und schreibe 2 sec befindet, was die Diskusion über den Zeitbdearf der SubVIs völlig verblassen lässt.

Hallo Lucki,

ich habe nicht vor der Verwendung von subVIs in Events generell gewarnt. Ich bezog mich auf die Aussage:

Zitat:in den Sub-VIs brauche ich teilweise dessen Referenzen, damit während das Sub-VI noch läuft das Frontpanel des Haupt-VIs aktuallisiert wird.

Ergo: ein subVI, welches die Abarbeitung eines Event-Cases unnötig verzögert...

(25.06.2012 11:01 )GerdW schrieb:  Hallo Lucki,
ich habe nicht vor der Verwendung von subVIs in Events generell gewarnt. Ich bezog mich auf die Aussage:
...

Danke und Entschudigung, ich lese oft nicht aufmerksam genug und falle dann auf die Nase..