+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Code Beispiele (/Forum-LabVIEW-Code-Beispiele)
+--- Thema: Tasking Library (/Thread-Tasking-Library)
Tasking Library - eg - 08.12.2008 12:49
Zum Kommunizieren zwischen parallelen Schleifen (Tasks):
http://www.LabVIEWportal.eu/viewtopic.php?f=70&t=655
Hoffe auf ne heiße Diskussion, eg
Tasking Library - eg - 08.12.2008 13:38
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
Tasking Library - IchSelbst - 08.12.2008 22:40
' schrieb:ich vermute es ist schwer die Funktionsweise zu verstehenNee, 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.
Tasking Library - eg - 08.12.2008 22:44
Big thank! Muss gucken!
Ich finde es gut, sogar sehr gut, dass du es heruntergeladen und zu öffnen probiert hast.
Tasking Library - eg - 09.12.2008 02:34
Sollte jetzt funken, bitte ausprobieren. Übrigens die Vorversion lief unter 8.6, nur unter 8.5 nicht.
Gruß, eg
Tasking Library - IchSelbst - 09.12.2008 20:51
' 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?
Tasking Library - IchSelbst - 09.12.2008 20:55
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!
Tasking Library - eg - 09.12.2008 21:12
' schrieb:Ja, geht jetzt.Toll, ich habe es eigentlich auch bei der Vorversion erwartet...
' schrieb:Wie fang ich denn an?Hier geht es um die gemischte Methode. Du kannst immer warten, bis etwas kommt. Oder du kannst die Quelle anstossen dir etwas zu geben.
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.
' schrieb:Es stellen sich mir jetzt drei Fragen: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.
Erste Frage:
Warum in LV-OOP? So wie das da steht, geht das doch auch mit normalen SubVIs - und einem Cluster anstelle eine Klasse.
' schrieb:Zweite Frage: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?).
Warum sind denn die einzelnen Methoden als ablauf-invariant deklariert?
' schrieb:Dritte Frage:Klar, aber das mag ich nicht so. Warum eigentlich nicht pro Methode ein VI? Ich mag auch keine Funktionale Globale VIs mit uninitialisiertem Schieberegister.
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?
' schrieb:[*guck*]Frage lieber den Robi
Ja, Eugen, wo sind sie denn alle? Halten wir jetzt DIalog?
, er wollte überhaupt Interessenten örtlich zusammenführen, es klappt nicht mal virtuell 
Tasking Library - eg - 09.12.2008 21:20
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.
Tasking Library - IchSelbst - 09.12.2008 21:42
' 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 virtuellVirtuell? 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 kompatibelJa. 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.