Tasking Library

' schrieb:aber Hallo!

Old Style Globals, bzw. Action Engines sind IMHO immer noch die fortschrittlichste Technik der sich ein LV-Programmierer bedienen kann. Es gibt nichts besseres, wenn es darum geht die Daten dort zu behalten wo sie gebraucht werden. Wenn man natürlich drauf steht baumdicke "Kabelstränge" von der 1. Initialisierung bis zum Ende des VIs quer durch sein Blockdiagramm zu ziehen, dann kann man das gerne machen, ich steh da nich so drauf. Man kann auch ein riesen Framework aus 200 VIs und von mir aus auch LVOOP Klassen aufbauen um Daten hin und her zu schubsen, schneller und effektiver geht's aber mit einer OSG:)kleiner Seitenhieb: LVOOP Objekte können übrigens keine Member Variablen selbst speichern. Wenn du sowas haben willst musst du eine OSG verwenden(AQ hat das "liebevoll" LVOOP style Globals genannt)

Ich wollte eigentlich nicht über die Vor- und Nachtele der Programmiertechniken (OSG vs. LVOOP) diskutieren, aber warum eigentlich nicht.
Also 200 VIs packst du nicht in eine einzige OSG, sonst hast du viele viele Auswahlmöglichkeiten und Einstellmöglichkeiten, die nicht in eine Enum-Liste passen. Ich meine klar, ne Liste kann mehr Elemente beinhalten, aber man braucht ja auch ausser dem Kommando noch die Parameter. Somit brauchst du mehr von OSGs, die die gleiche Daten in Form eines Clusters zueinander übergeben.

Die Werte der Member Variables befinden sich im Klassen-Wire, warum sollte man die noch extra irgendwo abspeichern. Oder besser gesagt, ich verstehe nicht so ganz was gemeint ist.

' schrieb:Old-Style Globals sind SEHR WOHL Datenfluss-kompatibel:
da für jedes VI gilt (sofern es nicht reentrant ist) dass es nur einmal im Speicher vorhanden ist und "parallele" Aufrufe nacheinander abgearbeitet werden (wodurch die Race Conditions verhindert werden) und der SubVI Call immer genau dann erfolgt wenn die Daten gebraucht werden ist da nicht der geringste Widerspruch zum Datenfluss-Konzept, der einzige Unterschied zu einem "Draht" ist, dass man "den Draht im diesem Fall nicht sieht" und näher kommt man in LV nicht an einen Pointer - selbstverständlich ohne sich um die manchmal tatsächlich grauenerregende Pointer-Arithmetik Gedanken machen zu müssen. Für mich sind OSGs der "anschlusslose, intelligente Draht in der gleiche Farbe wie dein BD-Hintergrund":D- wireless Strom sotusay, davon träumen die Elektriker seit Jahrhunderten!

Keine Frage, dass sie zumindest so funktionieren, aber von aussen sehen sie nicht so aus. Ich will auch keinen überzeugen sie nicht zu verwenden. Ich habe nur gesagt, dass OSGs für mich fremd aussehen, obwohl ich auf die schnelle diese immer wieder gerne verwende.

' schrieb:Und nu bin ich mal ganz offen, und ich hoffe du verzeihst mir (manchmal schaun mich die Leute 5 Jahre lang nicht mehr mit dem Ar*** an, wenn ich "mal ein offenes Wort" spreche):
Das Konzept ist als Konzept, an sich interessant, ich hab auch schonmal an sowas gedoktort, und anschließend wieder verworfen, denn es taugt überhaupt nix, ausser um sich selbst weiterzubilden, Know how in Sachen Architektur aufzubauen und tieferes Verständnis für die Zusammenhänge in LV zu entwickeln. Das k.o. Kriterium bei deiner Achitektur ist: du wandelst alle Daten in Strings um, und ganz ehrlich: du möchtest mir jetzt nicht ernsthaft weismachen, dass ein Konzept, das FREIWILLIG auf die Type-Propagation verzichtet und alle Daten in ihrer Binärrepräsentation zu behandeln (du MUSST am Ende der Queue immer wissen was du reingeschoben hast, sonst kommt zwangsläufig Müll dabei raus - und das stell mal bei 10+ Tasks sicher!!) einer OSG überlegen ist. Und gleichzeitig zu schreiben dass OSG's eine Verarsche sind, ganz ehrlich Eugen, da fällt mir nur noch ein "STEINIGT IHN" ein

Also erstens - es ist wirklich so, dass ich Kritik zur Verwendung und Verbesserungsvorschläge hier brauche.
Zweitens - Strings sind im Unterschied zu den Typedef-Enums speicherfressender und langsamer, dafür aber universell. Anders (abgesehen von Variant o.ä.) kann ich mir keine Library solcher Art, die projektunabhängig verwendet werden kann, vorstellen.

' schrieb:Witzigerweise hab ich am Freitag an genau der gleichen Problematik gebastelt (ich benutze recht viele Action Engies um Queues zu erstellen und wollte aus einer dieser Action Engines eine Klasse machen um sie als Basisklasse zu verwenden...) und ich bin zu dem Schluss gekommen - und ich vermute mal da bist du auch drüber gestolpert, sonst hättest du die Daten, die du übertragen willst, nicht als String geflattet - Queues verhindern die Type Propagation von Objekten. Mein Fazit war mal wieder: "ach verdammte Scheisse, wär ja gar nich so schlecht dieses OOP, wenn man's denn nur vernünftig einsetzen könnte *heul*". d.h. so lange man nicht über das dynamic dispatch Terminal den Datentyp der Queue beim "Dequeue Element" festlegen kann, bleibt die Umsetzung in LVOOP einfach nur ein Muster ohne Wert, eine Spielerei, nicht tauglich für "in Production Projekte" ...

so far,
CB

LVOOP ist, meiner Meinung nach, eine Erweiterung von Clusters. Ich glaube du hast viel zu viel AQ-Belaber bei LAVA gelesen um den Eindruck zu bekommen, dass LVOOP ein Super-Wooper-Wunder ist. Betrachte es einfacher, und du wirst sehen dass es eine bessere Sache als Cluster ist. Zumindest ist der Icon einer Klassenkonstante nicht so gross, wie eine Riesencluserkonstante. Was die Ableitungen angeht, da bin ich noch nicht so weit, dass ich es fachlich diskutieren kann.

Aber ganz sicher - vielen Dank für die Teilnahme am Gespräch. Ich warte auf weitere Kommentare



P.S. habe aus dem Topic eine Umfrage gemacht, denn ich überhaupt an irgendeiner Veröffentlichung irgenwelcher Libraries zweifle. Ich werde lieber direkte Fragen im Forum stellen, falls ich welche hab.