Tasking Library

Zum Kommunizieren zwischen parallelen Schleifen (Tasks):
http://www.LabVIEWportal.eu/viewtopic.php?f=70&t=655

Hoffe auf ne heiße Diskussion, eg

Anzeige

Update:
ich vermute es ist schwer die Funktionsweise zu verstehen, deshalb ein einfaches Beispiel:
die obere Schleife sendet "get" Befehl zur unteren. Die untere empfängt diesen Befehl, erzeugt eine Nummer und sendet diese Nummer zurück zur oberen Schleife (Befehl "nummer" mit Parameter).

http://www.LabVIEWportal.eu/viewtopic.php?p=4466#p4466

Hat's jemand ausprobiert? Fehlt noch Info? Zu schwer oder nicht zu gebrauchen?

Gruß, eg

' schrieb:ich vermute es ist schwer die Funktionsweise zu verstehen

Nee, find ich nicht. Schwieriger ist es hier zu posten.

Zitat:Hat's jemand ausprobiert?

Ja. Ich habs entpackt nach User.? geschoben - und hab mit dem Muster-MainVI unter LV-8.5 diesen Fehler bekommen. Siehe Bild.

Zitat:Fehlt noch Info?

Muss ich noch mehr selbst machen?

Zitat:nicht zu gebrauchen?

Prinzipiell schon brauchbar. Halt z.B. zum Anstoßen von Tasks, die im Hintergrund selbständig laufen sollen und länger dauern, als die "Benutzer-Task" blockiert sein soll.

Das mit dem OOP muss ich mir mal ankucken, wenn's in LV-8.5 fehlerfrei kompiliert werden kann. Aber was ich bisher gesehen habe, bin ich da skeptisch, ob ich mir das mit dem OOP so vorgestellt habe.

Big thank! Muss gucken!
Ich finde es gut, sogar sehr gut, dass du es heruntergeladen und zu öffnen probiert hast.

Sollte jetzt funken, bitte ausprobieren. Übrigens die Vorversion lief unter 8.6, nur unter 8.5 nicht.

Gruß, eg

' schrieb:Sollte jetzt funken, bitte ausprobieren.

Ja, geht jetzt.

Wie fang ich denn an?

Für den Datenaustausch zwischen unabhängigen Tasks (Klassen etc.) gibt es zwei Möglichkeiten: Entweder ich hole mir Daten oder ich lasse sie mir bringen. Holen = Eine Methode der anderen Klasse aufrufen und per Property die Daten herausholen. Bringen lassen = solange still warten, bis was an meiner Schnittstelle ansteht. Bringen lassen entspricht also der Methode mit den Queues.

Es stellen sich mir jetzt drei Fragen:

Erste Frage:
Warum in LV-OOP? So wie das da steht, geht das doch auch mit normalen SubVIs - und einem Cluster anstelle eine Klasse.

Zweite Frage:
Warum sind denn die einzelnen Methoden als ablauf-invariant deklariert?

Dritte Frage:
Warum überhaupt per OOP-Datenfluss? Kann man nicht alle fünf Funktionen (Open, Register, Read, Write, Close ...) in ein SubVI legen und mit einem Enumerator die Funktion auswählen? Oder ist das nicht im Sinne der LV-OOP?

[*guck*]

Ja, Eugen, wo sind sie denn alle? Halten wir jetzt DIalog?

Zur Frage Drei hab ich ja das wichtigste vergessen: Ist alles in einen VI, kann man sich nämlich den OOP-Datenfluss sparen. Die Handles/Referenzen liegen dann in einem Schieberegister innerhalb des VIs und sind nach außen hin - im wahrsten Sinne des Wortes - nicht sichtbar => Kapselung!

' schrieb:Ja, geht jetzt.

Toll, ich habe es eigentlich auch bei der Vorversion erwartet...

' schrieb:Wie fang ich denn an?

Für den Datenaustausch zwischen unabhängigen Tasks (Klassen etc.) gibt es zwei Möglichkeiten: Entweder ich hole mir Daten oder ich lasse sie mir bringen. Holen = Eine Methode der anderen Klasse aufrufen und per Property die Daten herausholen. Bringen lassen = solange still warten, bis was an meiner Schnittstelle ansteht. Bringen lassen entspricht also der Methode mit den Queues.

Hier geht es um die gemischte Methode. Du kannst immer warten, bis etwas kommt. Oder du kannst die Quelle anstossen dir etwas zu geben.

' schrieb:Es stellen sich mir jetzt drei Fragen:

Erste Frage:
Warum in LV-OOP? So wie das da steht, geht das doch auch mit normalen SubVIs - und einem Cluster anstelle eine Klasse.

Weil ich es schön und übersichtlich finde. Im Prinzip gibt es sehr wenige Unterschiede (z.B. Ableitung) zwischen LVOOP und Cluster (anders bei GOOP). Übrigens dazu - die erste Version hatte einen Cluster und wurde ohne LVOOP implementiert.

' schrieb:Zweite Frage:
Warum sind denn die einzelnen Methoden als ablauf-invariant deklariert?

Weil diese Library parallel an mehreren Stellen deines Progs aufgerufen werden kann. Soweit ich weiss sind alle nativen LV VIs ablaufinvariant (du meinst hier Reentrant?).

' schrieb:Dritte Frage:
Warum überhaupt per OOP-Datenfluss? Kann man nicht alle fünf Funktionen (Open, Register, Read, Write, Close ...) in ein SubVI legen und mit einem Enumerator die Funktion auswählen? Oder ist das nicht im Sinne der LV-OOP?

Klar, aber das mag ich nicht so. Warum eigentlich nicht pro Methode ein VI? Ich mag auch keine Funktionale Globale VIs mit uninitialisiertem Schieberegister.

' schrieb:[*guck*]

Ja, Eugen, wo sind sie denn alle? Halten wir jetzt DIalog?

Frage lieber den Robi, er wollte überhaupt Interessenten örtlich zusammenführen, es klappt nicht mal virtuell

Und ja... Funktionale globale VIs sind eine Verarsche für LV, sind zwar datenflußgeschützt, aber nicht G-Language kompatibel (IMHO, hoffentlich wird Christian damit angeregt hier teilzunehmen).

P.S. zum Verständnis: diese Library ist fast nur eine Zusammenfassung vieler VIs aus der Synchrinisationspalette in eine Klasse mit nem bequemen Interface. Diese Library wurde nur aus einem Grund erstellt - alles was ich in vielen meiner Projekte nutze - zusammenfassen und in User.lib abspeichern.

' schrieb:Weil diese Library parallel an mehreren Stellen deines Progs aufgerufen werden kann. Soweit ich weiss sind alle nativen LV VIs ablaufinvariant (du meinst hier Reentrant?).

Ja gut. Reentrant (das meinte ich hier) hat halt den Vorteil, dass keiner warten muss, bis er das VI verwenden darf.

Zitat:Klar, aber das mag ich nicht so.

Dieses Argument geht vor: Des Menschen Wille ist sein Himmelreich.

Zitat:Warum eigentlich nicht pro Methode ein VI?

Das gefällt mir nicht, weil ich dann immer so viele SubVIs offen hab.

Zitat:es klappt nicht mal virtuell

Virtuell? Das klappt nicht. Oder willst du deinen abendlichen Schoppen virtuell trinken?

Zitat:Funktionale globale VIs sind eine Verarsche für LV, sind zwar datenflußgeschützt, aber nicht G-Language kompatibel

Ja. Und?
"Datenklassen" sind auch in Delphi verpöhnt. Da muss nach Aussage der OOP-Fachleute alles als private deklariert und per Property handlebar sein. Nee. Ich kann auf meine Pointer noch selbst aufpassen.