Tasking Library

' schrieb: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).

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)

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!

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

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