LVOOP im Kommen!

Hallo

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.