Wiederverwendbarer Code / VI

Hallo zusammen,

ich habe da mal eine grundsätzliche Frage zu Labview.

Wie binde ich am besten wiederverwendbare VI´s in Projekte die zu EXE - Dateien kompiliert werden ein. Diese EXE - Dateien laufen dann auf Systeme, die nur die Laufzeitumgebung von Labview installiert haben.

Folgendes Szenario:

Ich habe ein Haupt - VI das aus vielen SubVI´s besteht. In diese Haupt - VI wird dann projektabhängiger Code in Form von SubVI´s oder direkt ins Haupt - VI eingegeben. Am Ende des Projekts wird das Projekt zu eine EXE - Datei kompiliert.

Wenn ich jetzt aber in einem der SubVI´s des Haupt - VI´s einen Fehler entdecke und diesen entferne, müsste ich ja alle Projekte wieder neu kompilieren, damit dieser Fehler in allen Projekte beseitigt ist. Wie wäre das grundsätzliche Vorgehen, um dieses "aktualisieren" der Projekte zu verhindern bzw. den Arbeitsaufwand so gering wie möglich zu halten.

Dachte dabei an so Sachen wie:
Dynamisches Laden von SubVI´s
DLL aus Sub - VI´s erstellen und diese DLL wieder in Labview verwenden
Automatisiertes erzeugen von EXE - Dateien durch eine Arte "makefile"

Was wäre eurer Meinung nach der richtige Weg?

Vielen Dank im voraus für eure Hilfe
woiddale

Anzeige

Ich mache es momentan noch so, dass ich verschiedene "Module" (die wiederum aus einer Reihe von Sub VIs bestehen) in llbs zusammenfasse. Habe ich einen Fehler in einem Modul, kompiliere ich nur die llb neu und geb sie dem Kunden. Der kann den Patch einfach über die vorhandene Applikation drüberspielen. Noch eleganter geht es mittels LVOOP. Irgendwo im Netz (glaube sogar bei NI) kursiert das Plugin Beispiel.

@abrissbirne
Geht Deine Methode auch mit als EXE kompilierten VIs? Wie sieht das mit der EXE-Struktur von LV2010 aus?

Bei NI habe ich das hier gefunden:
Plugin-In Modules

Aber vom Überfliegen her, fand ich, dass es noch keine richtige Lösung bietet.

' schrieb:@abrissbirne
Geht Deine Methode auch mit als EXE kompilierten VIs? Wie sieht das mit der EXE-Struktur von LV2010 aus?

Ich habe eine Main Applikation. Diese ist als exe kompiliert. Die restlichen Module werden in llbs zusammengefasst. Wenn sich nu was ändert, wird einfach die llb ausgetauscht und es ist keine Neuinstallation notwendig.

' schrieb:Bei NI habe ich das hier gefunden:
Plugin-In Modules

Aber vom Überfliegen her, fand ich, dass es noch keine richtige Lösung bietet.

Ich finde das Beispiel leider gerade auch nicht.
Das Prinzip funktioniert in etwa so. Du baust deine Pluginstruktur objektorientert auf. Neue Plugins kannst du einfach in den entsprechenende Ordner kopieren. Deine Applikation scannt bei Programmstart diesen Ordner und kann über dynamic dispatch VIs neue Plugins einfach aufrufen, ohne das du deinen Quellcode anpassen musst. Und das Plugin wird erst in den Speicher geladen, wenn der User es wirklich braucht.

Auf der Cluster-Palette gibt es ein VI mit dem man einen Pfad in ein Klasseobjekt "verwandeln" kann und man bekommt zur Laufzeit die gewünschte Klasse, Die neue Klasse muss natürlich ihre Eigenschaften von einer Basisklasse, mit der das Hauptprogramm kompiliert wurde, geerbt haben.

Bei NI gibt's dazu folgendes Beispiel: Factory Pattern (@abrissbirne: Du meinst wohl dieses Beispiel, oder?)

' schrieb:Auf der Cluster-Palette gibt es ein VI mit dem man einen Pfad in ein Klasseobjekt "verwandeln" kann und man bekommt zur Laufzeit die gewünschte Klasse, Die neue Klasse muss natürlich ihre Eigenschaften von einer Basisklasse, mit der das Hauptprogramm kompiliert wurde, geerbt haben.

Bei NI gibt's dazu folgendes Beispiel: Factory Pattern (@abrissbirne: Du meinst wohl dieses Beispiel, oder?)

Die Factory ist Beispielsweise ein Vertreter für das dynamische Laden und vor allem mit Preprocessing dem initialisieren von Objekten (Konstruktor Ersatz). Hier ist ein Bsp. das sich auf Plugins bezieht: Extending LabVIEW-built applications with LVOOP plugins
Du kannst dir Bspw. ein OOP Framework bauen indem direkt alles enthalten ist (Queue Handling, Error Handling...).

Edit:
Hier das einfache Bsp.:Plugin DEMO

Hallo,
so wie ich das sehe, ist das mit den LLB´s an besten für das geeignet, was ich beschrieben habe. Plugins und LVOOP sind bestimmt sehr gute Mittel, wenn ich ein Programm erstellen will und es dann ohne große Probleme erweitern will, ohne die EXE neu kompilieren zu müssen. Mir geht es aber eigentlich ja nur darum, fehlerhaften Code einfach austauschen zu können ohne jedes mal die EXE neu kompilieren zu müssen.

Wenn ich jetzt z.B.: 20 Programme habe, die alle einige VI´s der LLB nutzen und ich in dieser LLB einen Fehler feststelle, kann ich einfach den Fehler beheben, die LLB neu erstellen und dann die LLB wieder verteilen, bzw. irgendwie automatisiert an die Rechner verteilen, auf denen diese 20 Programme laufen. Und schon ist der Fehler in den 20 Programmen behoben. Einzige Voraussetzung dafür ist dass die VI´s aus der LLB, die ich direkt in meiner EXE - Datei benutze, dynamisch geladen werden.

Oder sehe ich das irgendwas falsch?

Gruß
woiddale

Hallo zusammen,
habe da jetzt mal was versucht. Leider funktioniert es aber nicht ganz so wie gedacht.

Wenn ich folgendes main.vi habe:
   


und das folgende VI dynamisch lade,
   


funktioniert es im Editor genauso wie als EXE.
   


wenn ich dann aber die Diagrammdeaktivierungsstruktur um das "Fehler löschen" entferne,
   


funktioniert es im Editor schon noch, als EXE erhalte ich aber folgenden Fehler:
   

Warum geht es nicht? Bzw. wie muss ich es machen, damit es funktioniert. Dachte immer Labview würde seine eigenen VI´s immer finden. Muss ich der EXE irgendwie den Suchpfad mit teilen oder warum findet sie das "Fehler löschen" nicht?

Hier mal das ganze Projekt als Zip - Datei.

  bespiel.zip (Größe: 146,82 KB / Downloads: 164)


Vielen Dank für eure Hilfe
woiddale

' schrieb:Hallo zusammen,
habe da jetzt mal was versucht. Leider funktioniert es aber nicht ganz so wie gedacht.

Warum geht es nicht? Bzw. wie muss ich es machen, damit es funktioniert. Dachte immer Labview würde seine eigenen VI´s immer finden. Muss ich der EXE irgendwie den Suchpfad mit teilen oder warum findet sie das "Fehler löschen" nicht?

Der Fehlercode hat auch nix mit dem "Fehler löschen" VI zu tun. Höchst wahrscheinlich ändert sich der Aufrufpfad des SubVI in der Executable.