zu viele Übergabevariablen/zu wenig Connectors

(25.06.2012 09:39 )Lucki schrieb:  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.

Danke für den Hinweis, auf die Aussage werde ich ggf. mal drauf zurückgreifen.

Zitat: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...

Was ich hier so zwischen den Zeilen rauslese scheine ich da noch ein zusätzliches generelles Strukturproblem meines Programms zu haben. Warum ist es schlimm, wenn ein SubVI in einem Event-Case eine gewisse Zeit benötigt? Bei mir ist das definitiv so, die Sub-VIs benötigen deutlich mehr als die 2 sec. In der Zeit finden Messungen, Berechnungen usw. statt, es ist auch gar nicht geplant, dass neue Events in dieser Zeit zugelassen sind. Im Gegenteil, in den SubVIs läuft eine Sequenz, die unter keinen Umständen irgendwie unterbrochen werden sollte.
Was wäre eine gute Alternative, sollte dies so wie ich es implementiert habe wirklich ein Problem sein?

(26.06.2012 08:19 )dbausdd schrieb:  

Zitat: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...

Was ich hier so zwischen den Zeilen rauslese scheine ich da noch ein zusätzliches generelles Strukturproblem meines Programms zu haben. Warum ist es schlimm, wenn ein SubVI in einem Event-Case eine gewisse Zeit benötigt? Bei mir ist das definitiv so, die Sub-VIs benötigen deutlich mehr als die 2 sec. In der Zeit finden Messungen, Berechnungen usw. statt, es ist auch gar nicht geplant, dass neue Events in dieser Zeit zugelassen sind. Im Gegenteil, in den SubVIs läuft eine Sequenz, die unter keinen Umständen irgendwie unterbrochen werden sollte.
Was wäre eine gute Alternative, sollte dies so wie ich es implementiert habe wirklich ein Problem sein?

Gibt es hierzu keinen Lösungsvorschlag?

Hallo db,

Zitat:es ist auch gar nicht geplant, dass neue Events in dieser Zeit zugelassen sind.

Man kann leider nicht sehen, wie du die Events definiert hast. LabVIEW merkt sich jedenfalls UI-Events, auch wenn das FP gerade blockiert ist. Und es kann ziemlich störend sein, wenn mein Programm nicht sofort (in irgendeiner Art und Weise) auf FP-Events reagiert, weil es gerade mit dem Abarbeiten eines subVI beschäftigt ist. Wenn das Event dann fertig ist, wird plötzlich ein anderes Event bearbeitet, welches man schon wesentlich früher generiert hatte und worauf das Programm nun Sekunden später erst reagiert. Sowas würde mich als User sehr stören...

Zitat:Was wäre eine gute Alternative

Eine saubere Statemachine, event-driven, Befehlsweitergabe per Queue...

Der direkte Löungsvorschlag ist: Wenn jemend vor Referenzen, Eigenschaftsknoten u. dgl. warnt, weil dann das Programm verlangsamt wird, nie vergessen die Enschränkung hinzuzufügen: Falls das Programm überhaupt zeitkritisch ist, und wenn ja, ob es so zeitkritisch ist, daß diese paar Mikrosekunden überhaupt eine Rolle spielen.
Wenn das nicht der Fall ist, dann gebe ich jedenfalls der Klarheit und übersichtlichkeit des Codes den Vorzug, auch wenn das Programm dadurch (- für den Benutzer unmerklich -) langsamer wird.
Es ist bekanntlich die wichtigste Eigenschaft deutscher Mentalität, überall Gefahren lauern zu sehen, vor allem Angst zu haben und vor allem und jedem zu warnen. Da bleibt natürlich auch ein deutsches Labview-Forum nicht außen vor.

Ich gebe euch beiden Recht!
Wenn ich ein Frontpanel-Button klicke und nix passiert, bzw. erst zeitverzögert, dann nervt das nur.
Andererseits ist mein Programm nicht zeitkritisch, daher sind Verzögerungen kein Problem.

Letztendlich nutze ich eine State-Machine, sie ist event-driven (siehe Bild), nur Befehle sammel ich nicht per Queue. Die allermeisten meiner Ereignisse laufen nach Frontpanel-Aktivitäten ab, z.B. wenn bestimmte Buttons gedrückt wurden. In dem gezeigten Bild ist das auch so, nach einem Knopfdruck läuft eine Messung ab. Und diese Messung soll wie auch schon beschrieben weder unterbrochen werden, noch sollen in der Zeit andere Einstellungen vornehmbar sein. Im Gegenteil, damit die Messung auch so läuft wie ich das will, darf gar nichts anderes im Programm in der Zeit passieren. Ich habe aber zugegebenermaßen noch nicht ausprobiert, einen anderen Knopf in der Zeit zu drücken, so weiß ich gar nicht was mit dem dahinterliegenden Event passiert (ignorieren oder später ausführen).
Unterm Strich ist die von mir genutzte Architektur unter den Vorausetzungen gar nicht so falsch, zumindest glaube ich das bis heute.