Event-driven VI Example (LV 2014)

Event-driven VI Example (LV 2014) - Druckversion

+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Code Beispiele (/Forum-LabVIEW-Code-Beispiele)
+--- Thema: Event-driven VI Example (LV 2014) (/Thread-Event-driven-VI-Example-LV-2014)

Event-driven VI Example (LV 2014) - Lucki - 08.02.2015 15:28

Ich habe mir mal die Mühe gemacht, ein Musterbeispiel aus dem (schon lange vergriffenen) Buch David J. Ritter "LabVIEW GUI Essential Techniques" zu modernisieren. Das Beispiel war in Version 5.1, damals gab es noch gar keine Ereignisstruktur. Der Code ist gegenüber dem Original ganz anders; unverändert geblieben ist nur das FP und die Funktion.
Das aufzurufende VI ist "Event-Driven_Main.vi"
Geeignet als Lehrbeipiel für:
Event driven State-Machines mit Queues.
Öffnen und Schließen von Sub-Vis als Popup.
Es ist möglicherweise nicht perfekt. Kritiken sind hochwillkommen!
Gruß Ludwig.
PS: Falls das Interesse die Erwartungen übersteigt, könnten evtl noch einige Erklärungen nachgereicht werden...
Oder auf niedrigere Version kompilieren...

RE: Event-driven VI Example (LV 2014) - Trinitatis - 09.02.2015 19:15

(08.02.2015 15:28 )Lucki schrieb: ...
Oder auf niedrigere Version kompilieren...

Hallo Ludwig,

da sachste was! Smile

wenn es nicht zu viel Mühe macht, wäre es nett, wenn du das Paket auf mein Niveau runterspeichern könntest.

Danke!

Gruß, Marko

PS: gespannt auf die Antwort...

RE: Event-driven VI Example (LV 2014) - teegee - 09.02.2015 23:39

Ich hab das Beispiel im Buch und die Loesung nicht gesehen aber die moderne Version schaut nett aus.

Ein paar Sachen, die mir beim Anschauen aufgefallen sind.

- Das sequence diagram in Main ist wohl eines der seltenen Beispiele, wo eine state-machine overkill ist Smile

Gute Wahl.
- Die Queues werden in sub-VIs erzeugt. Das macht den Zugriff in sub-VIs einfach, da sie nicht als Parameter uebergeben werden muessen. Der Uebersicht halber wuerde ich alle Get-Queue VIs in ein disabled diagram auf das Main BD legen.
- Im VI Ref Manager haette ich anstatt eines named cluster die Funktion Set/Get Variant Attribute benutzt. Bei der Anzahl der Elemente im Array macht das wahrscheinlich absolut nichts aus, aber da es sich um ein Beispiel handelt, ist dieses VI eine gute Gelegenheit dafuer.
- Das sequence diagram im VI Ref Manager (Return a Reference / True) gefaellt mir nicht. Es macht wenig Sinn die Haelfte vom code zu verstecken, nur um ein bisschen Platz zu sparen.

RE: Event-driven VI Example (LV 2014) - Lucki - 10.02.2015 09:31

@trinitatis
Hier die herunterkompilierte Version auf 2011:
[attachment=52072]
@teegee
Danke für die Anregungen, ich werde mich ernsthaft damit auseinandersetzen, aber das dauert.
Das Originalbeispiel ist zwar nicht so alt, dass es von der Version her auf lv2014 überhaupt nicht mehr laufen kann. Es läuft aber trotzdem nicht, irgendwelche Funktionen scheinen sich inzwischen verändert zu haben. Aber nichtsdestotrotz - hier das Original (Version 6.?):
[attachment=52073]
Das Buch ist übrigens neu nur noch in einem einzigen Exemplar verfügbar - also schnell zugreifen:
[attachment=52074]

RE: Event-driven VI Example (LV 2014) - Trinitatis - 10.02.2015 11:17

(10.02.2015 09:31 )Lucki schrieb: @trinitatis
Hier die herunterkompilierte Version auf 2011:

Danke!

Gruß, Marko

RE: Event-driven VI Example (LV 2014) - dimitri84 - 10.02.2015 11:46

(10.02.2015 09:31 )Lucki schrieb: Das Buch ist übrigens neu nur noch in einem einzigen Exemplar verfügbar - also schnell zugreifen:

$3,99 Porto?! Übertrieben teuer ... ohne mich!

RE: Event-driven VI Example (LV 2014) - GerdW - 10.02.2015 12:53

Die 3,99 passen aber prima zum Verkaufspreis, da schreibt sich der Rechnungsbetrag viel einfacher… Smile

RE: Event-driven VI Example (LV 2014) - Lucki - 10.02.2015 15:13

(09.02.2015 23:39 )teegee schrieb: - Die Queues werden in sub-VIs erzeugt. Das macht den Zugriff in sub-VIs einfach, da sie nicht als Parameter uebergeben werden muessen. Der Uebersicht halber wuerde ich alle Get-Queue VIs in ein disabled diagram auf das Main BD legen.

Bei diesen SubVIs handelt es sich um Funktionale Globale Variablen für die Queue-Referenzen. Als Nachteil von Queues habe ich immer empfunden, dass sich die fetten Referenzdrähte immer durch das ganze Projekt ziehen und die BD-Optik versauen. Die fallen jetzt weg. Und das Besondere in diese FGVs ist noch, dass sie sich beim ersten Aufruf mit ihrem eigenem Code selbst initialisieren:
[attachment=52081]
Das mit dem Disabled-Struktur hatte ich ursprünglich gemacht, allerdings nicht für die 3 Queue-Referenz-FGVs, sondern für die drei echten SubVIs. Diese werden nämlich nur über Methodenknoten von Haupt-VI aus aufgerufen und erscheinen deshalb nirgendwo im Projekt-Manager. (Genau genommen: Sie erscheinen nur dann im Projekt-Manager in den Abhängigkeiten, solange das Haupt-VI läuft). Ich habe das deshalb wieder herausgenommen, weil ich befürchtete, dass das meinen Dilletantismus offenbart Big Grin

- ich habe ja nie an einem teuren Lehrgang von Ni teilgenommen. Jetzt sind die 3 SubVIs im Projektmanager dort, wo sich auch das Haupt-VI befindet. Der Nachteil ist jetzt, dass man nicht erkennt, welche von den 4 Vis das anzuklickende Haupt-VI ist. (Falls jemand einen besseren Vorschlag hat, wie man solche SubVIs in den Projektmanager integriert - her damit)
(Anmerkuung: Die gepostete 2011-Version ist ohne Projektmanager)

Zitat:- Im VI Ref Manager haette ich anstatt eines named cluster die Funktion Set/Get Variant Attribute benutzt. Bei der Anzahl der Elemente im Array macht das wahrscheinlich absolut nichts aus, aber da es sich um ein Beispiel handelt, ist dieses VI eine gute Gelegenheit dafuer.

Bei dem VI-Referenz-Array handelt es sich um ein Cluster-Array. In jedem Cluster befindet sich außer der eigentlichen Referenz noch der Name des VIs und dessen Pfad. Ein Attribut, welches Du für den Namen vorschlägst, kann ich doch nur in einem Variant unterbringen: Ohne Variant kein Attribut möglich. Dehalb verstehe ich Deinen Vorschlag nicht.

Zitat:- Das sequence diagram im VI Ref Manager (Return a Reference / True) gefaellt mir nicht. Es macht wenig Sinn die Haelfte vom code zu verstecken, nur um ein bisschen Platz zu sparen.

Der Code ist aber nicht mehr "versteckt" als das z.B bei jeder Case-Struktur auch der Fall ist. Diese ist genau so gestapelt wie die gestapelte Sequenz, und die Aufregung, dass das so ist, hält sich bei der Cases-Struktur in Grenzen bzw. ich habe nie etwas davon gehört. Da es sich hier nur um eine Art bla-bla-Code für die Fehlermeldung handelt, würde ich das Diagramm deswegen nicht aufblähen wollen. Es ist aber Geschmackssache.

Gruß Ludwig

RE: Event-driven VI Example (LV 2014) - teegee - 11.02.2015 01:45

(10.02.2015 15:13 )Lucki schrieb: Bei dem VI-Referenz-Array handelt es sich um ein Cluster-Array. In jedem Cluster befindet sich außer der eigentlichen Referenz noch der Name des VIs und dessen Pfad. Ein Attribut, welches Du für den Namen vorschlägst, kann ich doch nur in einem Variant unterbringen: Ohne Variant kein Attribut möglich. Dehalb verstehe ich Deinen Vorschlag nicht.

Meinen Vorschlag habe ich mal angehaengt:
[attachment=52083]

(10.02.2015 15:13 )Lucki schrieb: Der Code ist aber nicht mehr "versteckt" als das z.B bei jeder Case-Struktur auch der Fall ist. Diese ist genau so gestapelt wie die gestapelte Sequenz, und die Aufregung, dass das so ist, hält sich bei der Cases-Struktur in Grenzen bzw. ich habe nie etwas davon gehört. Da es sich hier nur um eine Art bla-bla-Code für die Fehlermeldung handelt, würde ich das Diagramm deswegen nicht aufblähen wollen. Es ist aber Geschmackssache.

Im Falle "VI name nicht gefunden" werden alle Werte des clusters auf "default" gesetzt. Das kann man doch einfach mit einem "Use Default if unwired" erschlagen. Das hab ich in meiner Loesung so gemacht. Dafuer muessen natuerlich die indicators aus der case Struktur raus, aber das mach ich eh immer, so dass alle indicators zu jeder Zeit auf dem BD sichtbar und zurueckverfolgbar sind.