Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Imho sollte das alles bereits möglich sein...
Das einzige, was es für dich wirklich zu beachten gilt, ist denke ich der nicht vorhandene Polymorphismus...Aber durch Verwendung der Dynamic Dispatch Methoden kannst du durchaus eine Baseclass Lib erstellen, die die Grundlegenden Methoden implementiert. Kind-Klassen (bedenke Einfachvererbung) können dann die eigentliche Implementierung übernehmen...
Gruß
Freddy
Anzeige
05.06.2010, 21:03 (Dieser Beitrag wurde zuletzt bearbeitet: 06.06.2010 17:34 von BNT.)
Liebe LVF User
Zum Thema LVOOP habe ich als GSI Mitarbeiter im GSI-Wiki mal was zusammengeschrieben.
Es ist zwar in English, aber das wird wohl kaum jemanden abhalten, der in der Informatik tätig ist, hoffe ich.
Im Rahmen eines Wettbewerbs der LVUG habe ich meine ersten Schritte mit LVOOP 8.2 gemacht. Einige Links zum Thema Entwurfsmuster für LVOOP habe ich auf der folgenden Seite zusammengeschrieben. LVOOP Entwurfsmuster
Auf der folgenden Seite habe ich das Thema mit dem Fokus auf die Behandlung von LabVIEW Objekten als Entitäten vertieft. Auf dieser Seite findet ihr auch Vorträge und Veröffentlichungen, sowie einen Snapshot der HGF Base Class Library mit ausgearbeiteten Basisklassen und Beispielen. HGF Basisklassen-Bibliothek
Daraus aufbauend habe ich die Diplomarbeit von Frederik Berck betreut, der auf Basis der HGF Base Class Library einen Prototyp für ein Mobiles Agenten System entwickelt hat. Seine Diplomarbeit kann von dieser Seite heruntergeladen werden und beschreibt auch die wichtigen Entwurfsmuster. Ein weiterer Schnappschuss mit den Quellen wird in Kürze veröffentlicht. LVOOP basiertes Mobiles Agentensystem
Die wesentlichen zitierten Bibliotheken sind GPL lizensiert.
Ich hoffe, diese Beispiele machen klar, was mit LVOOP machbar ist, und animieren weitere LabVIEW Anwender, sich auf das Konzept von LVOOP einzulassen. Ich habe in der Vergangenheit auch viele Erfahrungen mit klassischen objektorientierten Sprachen, C++ und JAVA, gemacht, und programmiere schon seit LabVIEW 6 auch in LabVIEW objektorientiert, siehe CS Framework ).
LVOOP hat mir am Anfang tatsachlich ca. zwei Wochen Kopfweh bereitet, bis ich mich mal richtig darauf eingelassen hatte. Danach macht es wirklich Freude mit LVOOP zu arbeiten!
Wer Interesse an einer Schulung zum Thema objektorientiertes Programmieren mit LabVIEW oder der Durchführung von solchen Projekten hat, möge sich einfach melden.
Gruß Holger
PS: Safari macht bei mir Probleme mit den Links. Mit dem MS-Internet-Explorer funktionieren sie korrekt. Gruß Holger
Liebe LVF Fans
Ich habe mal einen neuen LabVIEW 2009 SP1 Snapshop meiner HGF-Basisklassenbibliothek mit Beispielen für den Download bereitgestellt. Die Bibliothek ist jetzt nicht mehr monolitisch sonder in kleinere Pakete aufgeteilt, die aufeinander aufbauen.
Nein, es gibt noch keine wirklich belastbaren Erfahrungen. Das ganze Projekt habe ich in LV 8.2 begonnen, um herauszufinden, wie man mit dem LVOOP-Ansatz große skalierbare, ereignisgesteuerte und verteilte Applikationen realisieren könnten. Dabei war das Ziel auch mit LVOOP konsequent dem Datenflusskonzept zu folgen, und auf Referenzen zu verzichteten. Es handelte sich also eher um eine akademische Übung. Ab LV 2009 scheint es ganz gut zu laufen und die wichtigsten notwendigen Features wurden von NI implementiert. Vielen Dank für die positive Resonanz.
Es gibt also bisher nur die veröffentlichten Beispiele, die die Anwendung der HGF Klassen illustrieren. Stabilität und Performanz müssen noch untersucht werden.
Du hast ganz richtig beobachtet, dass es in den Beispielen viele String-Konstanten gibt. Dabei handelt es sich aber überwiegend um Klassennamen und Objektnamen. Zusätzlich werden die Initialisierungsparameter für ein Objekt als Variant-Attribute dem createObject.vi der HGF_Factory.lvclass übergeben und mit Hilfe der Namenkonvention Klassenname.Attributname an das initialize.vi durchgereicht. Sonst werden einfach die Objekte mit Hilfe der Drähte Datenfluss konform benutzt. Die String-Konstanten werden in einem Framework selber nur Parameter sein, die z.B. von einer Datenbank oder ASCII-Konfigurationsdatei gelesen werden. Die Initialisierungsparameter könnten aber auch von einem anderen z.B. C++- oder JAVA-basierten Programm via TCP/IP-Sockets geliefert werden, um die Erzeugung neuer Objekte zu veranlassen. Daher werden die Parameternamen als Strings mit der genannten Konvention benutzt. Es ist halt einfach ein generischer Ansatz in heterogenen Umgebungen. In LabVIEW kann man Objekte einfach mit Hilfe des Flatten to String.vi persistent speichern und mit Unflatten From String.vi wieder laden, aber halt nicht in anderen Programiersprachen.
Das Typeüberprüfungen bzw. Typecasts oft erst in einem SubVI, also erst zur Laufzeit durchgefürt werden, ist eine Konsequenz der generischen Behandlung von LabVIEW Objekten, die irgendwo in der Klassen-Hierachie aufgehängt sind. Das ist aber konform zum LVOOP Design von NI.
Ich stehe mit der Entwicklung des Gesamtprojekt noch ziemlich am Anfang. Die veröffentlichte Basisklassenbibliothek bis hin zu dem Agentensystem ist nur die Basis. Das ganze möchte ich im weiteren zu einem Framework ausbauen. Wie schnell das geht, hängt von meinen sonstigen Verpflichtungen ab, und natürlich von einem neuen Großprojekt, dass sich auf diesen Ansatz einlassen möchte. Es gibt noch sehr viel zu tun. Es ist auch sicherlich das eine oder andere Redesign notwendig. Ich hoffe auf konstruktive Kritik in diesem Forum.
Zur Zeit entwickle ich eine Vision-Applikation, die die HGF_Imaq-Klassen benutzt. Die einfache Implementierung, Standardansatz mit GUI- und DAQ-Loop, Producer-Consumer-Pattern und LabVIEW-Objekte als einfache passive Daten, schein stabil zu laufen. Das wird sich im kommenden Experiment zeigen. Im nächsten Schritt werde ich dieselbe Applikation mit Hilfe des HGF_ThreadPool umsetzen. Sobald diese stabil läuft, werde ich auf die Agenten umschalten. Über die Ergebnisse werde ich hier berichten.
An die Moderatoren:
Wenn dieses Thema größeres Interesse und Anwender findet, könnte dafür ein eigenes Forum eröffnet werden.
Gruß Holger
Edit:
Ich vergaß zur Einarbeitung Stellung zu nehmen. Ich hatte zu diesem Thema an der GSI einen dreitägigen Workshop organisiert. Der Kurs war ziemlich knackig und die LV erfahrenen Teilnehmer haben die komplette Zeit benötigt, um alle HGF-Basisklassen zu verstehen und zu jedem Entwurfsmuster eine einfache kleine Anwendung zu programmieren bis hin zu einem sehr einfachen Agenten. Danach geht die Arbeit dann aber erst richtig los, wenn man auf sich allein gestellt ist. Zum Debugging: Wer schon einmal eine LV-Applikation mit vielen Threads, VITs und Ereignismechanismen entwickelt hat wird damit schon fertig werden.
Ich würde beim nächsten Mal einen einwöchigen Workshop bevorzugen.
' schrieb:Die Anforderung Klassen übers Netz zu laden erklärt die Strings natürlich. Mir kam es nur "komisch" vor, immer diese Stringkonstante mit Classname auf die Factory und danach der Typecast per Classkonstante auf die Zielklasse. Naiv betrachtet frage ich mich da natürlich, warum das nicht per Dynamic Dispatch gemacht wird? (Da habe ich allerdings so ein Bauchgefühl, daß mir da wahrscheinlich noch der entscheidende Durchblick fehlt, warum es eben nicht damit geht)
Es muss immer dann ein Typecast auf eine Kindklasse gemacht werden, wenn das aufzurufende SubVI eben kein Dynamic Dispach VI ist. Ein Dynamic Dispach VI benutze ich allerdings nur dann, wenn ich in Kindklassen dieses VI auch wirklich überschreiben möchte. An einigen Stelle wird nur ein statischen SubVI als öffentliche Methode bereit gestellt und intern das Dynamik Dispatch VI aufgerufen. An diesen Stellen behalte ich mir ein Pre- oder Post-Processing vor. Der Anwender darf nur ein öffentliches VI aufrufen. Die Kindklassen überschreiben es.
' schrieb:Wo ich noch nicht dahinter gestiegen bin, warum sind im HGF_BaseClasses.lvlib:HGF_Factory.lvclass:classes.vi zuätzlich zum "Get LV Class Default Value.vi" noch Konstanten drinnen? Nur zur Vereinfachung des Aufrufs/Builds? In den Beispielen habe ich nach der Factory eigentlich immer die passenden Classkonstanten gesehen, also sind die verwendeten LVClasses eh schon geladen/statisch verlinkt?!?
In LabVIEW 8.2 funktionierte das "Get LV Class Default Value.vi" noch nicht im Executable. Das wurde erst später ermöglicht. Aber in der Tat, wenn man die Fabriken in die Build-Spezifikationen einbindet, hat man alle notwendigen Klassen in der gewünschten Version an Bord. Beim dynamischen Laden von Klassen muss man immer damit rechnen, dass darin Unsinn gemacht werden kann. Daher auch der Laufzeitcheck der Vertrauenswürdigkeit der Agenten-Klassenbibliotheken.
Die Fabriken in den Beispielen werden fast ausschließlich zur Illustration des Mechanismus benutz, um den Neuling an das Konzept zu gewöhnen. Ernst wird es in dem stationären Geräte-Agenten, wo das Objekt erst generisch in der Default-Transition der Zustandsmaschine erzeugt wird. Auch immer dann, wenn Objekte generisch aus einer Datenbank heraus erzeugt werden sollen oder die notwendigen Parameter z.B. über das Netzwerk gesendet werden, ist die Fabrik notwendig, um initialisierte LV-Objekte zu instanziieren.
' schrieb:Was mich auch noch wundert, daß du eine so große Klassenbibliothek ohne "Preserve Runtime Class" hinbekommen hast! Ist das noch ein Relikt aus pre LV2009 Zeiten? Ich vermute die ausprogrammierte "isFriend" Logik ebenso oder reicht da die LV-eigene Library/LvClass-Friends Logik nicht/noch nicht(/zu buggy?) aus?
Genau, auch hier wieder ein Relikt aus LV 8.2. "Preserve Runtime Class" kam erst später. Auch der Community-Scope wurde erst in LV 2009 bereitgestellt.
Es handelt sich also bei der HGF Klassenbibliothek tatsächlich um einen Prototypen, der die Machbarkeit demonstrieren sollte. Ich denke das ist ganz gut gelungen. Insbesondere, wenn ein Student mit einer Diplomarbeit beteiligt ist, der nur endliche Zeit zur Verfügung hat, kann man nicht mit jeder neuen LabVIEW Version ein Redesign veranlassen, wenn es nicht einen wirklich wichtigen Grund gibt.
Außerdem wollte ich das Projekt gern einmal veröffentlichen, um mich der kritischen Diskussion anderer LabVIEW Entwickler zu stellen. Z.B. ist der Entwurf für die VISA-Geräteklassen, HGF_VisaDevice.lvclass, zu kurz gegriffen. Stattdessen sollte die HGF_DeviceBase ein Interface-Objekt als Attribute erhalten, also als Composite entworfen werden. Da ich aber erst genau eine Beispielklase, HGF_NInstrSim.lvclass, implementiert habe, hält sich der Aufwand für das Redesign in Grenzen.
Es gibt noch mehr Stellen die des Redesign bedürfen, insbesondere die SharedVariable-Klassen stellen einen Kompromiss im Hinblick auf die kurze Zeit für die Diplomarbeit dar. Das werde ich demnächst in Angriff nehmen. Vielleicht erhalte ich ja Hilfe aus der Community?
Hi Holger,
hab Deinen Vortrag beim VIP gesehen und das war ein wenig viel für die Redezeit.
Wir nutzen LVOOP unter ETS Pharlab und mussten feststellen, daß die Performance jämmerlich ist. Unser Desktop RT hat 2x3GHz und die Hauptschleife (TimedStructure) läuft mit 1ms. Beide Cores laufen mit fast 70% Last.
Wenn ihr beginnt Performance Tests zu machen und die Zeit habt den Code auch mal auf einem Desktop RT laufen zu lassen, würden mich mal die Performanceunterschiede interessieren.
