Modulares Programmieren mit LV

Hallo an alle,

ich arbeite an einem Projekt, von dem eine EXE erstellt und an den Kunden weitergegeben wird.

Findet der Kunde einen Fehler, wird nach der Fehlerbehebung wieder eine EXE erstellt und weitergegeben.

Als ich früher in C/C++ programmiert habe, habe ich einige Programmteile als DLL kompiliert und mein Programm
modularisiert.

Mein Ziel ist es, eine EXE zu erstellen, die auf Module dynamisch zugreift. Wenn in diesen Modulen Fehler entdeckt wurden, kann ich die Module leichter austauschen. Ausserdem lassen sich die Module auch weiterverwenden in ähnlichen Projekten.

Mein erster Versuch war, dass ich API-VIs erstellt habe, die die eigenlichen VIs dynamisch aufrufen.
Die aufzurufenden VIs sind in einer LLB zusammen mit allen benötigten VIs (user.lib, vi.lib) gespeichert.
Die VIs in der LLB (ausser den aus vi.lib) habe ich einen eigenen Namensraum gegeben.

Nach ersten Tests habe ich die EXE zusammen mit den Modul-LLBs auf einem weiteren Rechner getestet.
Während der Laufzeit konnte ich die Module aufrufen, allerdings beim Beenden der EXE kam manchmal eine Fehlermeldung von LV.

Wer hat Erfahrungen oder kann mir Tipps geben, wie man in LV am besten modular programmiert?

Gruss

Markus

Also, bei mir entsteht die Modularität durch SubVIs. Ich erstelle aus meinem HauptVI eine EXE und dann sind automatisch alle enthaltenen SubVIs mit dabei, die ich auf dem Blockdiagramm platziert habe.
Wenn ich SubVIs dynamisch aufrufe (mit "Call by reference node"), binde ich sie beim Erstellen der EXE manuell mit ein (unter "Source Files" -> "Always included"), da sie hier nicht automatisch mit eingebunden werden.

Was Du da machst ist mir irgendwie zu hoch. Da bin ich nicht durchgestiegen.....

Gruß Markus

' schrieb:Mein erster Versuch war, dass ich API-VIs erstellt habe, die die eigenlichen VIs dynamisch aufrufen.
Die aufzurufenden VIs sind in einer LLB zusammen mit allen benötigten VIs (user.lib, vi.lib) gespeichert.

Hi Markus

ich kann dir zwar nicht helfen, hätte aber eine Frage an dich
Hast du mir ein Stichwort, wie das mit den API-VIs funktioniert. Ich steh momentan vor dem Problem, dass ich zur Laufzeit der exe gerne .NET Assemblies austauschen möchte. Unter der Entwicklungsumgebung funktioniert das einwandfrei, da ich die VIs dynamisch laden kann und somit die Assemblies noch nicht in der LabVIEW AppDomain geladen wurden. Bei der exe jedoch wird mir dieser Mechanismus in der Standardkonfiguration ausgehebelt. Momentan bin ich dabei mir eine Wrapper dll zu schreiben, die mir ein dynamisches Austauschen ermöglicht. Wenn ich das umgehen könnte, wäre ich gar nicht traurig

Besten Dank und viele Grüsse,
Christian

Also ich mache es bei meinen Applikationen genauso. Mein API VIs weißen alle eine Producer/Consumer Architektur auf. Wenn ich das Programm beende, sende ich ein Event an alle offenen API VIs. Dort wird eine Shutdown routine (muss man selbst implementieren) ausgeführt, die alle offenen Ressourcen schließt. Wenn das Main VI das OK bekommt (alle API VIs sicher beendet) so führt dieses seine eigene Shutdown Routine aus und beendet sich. So kannst du die LLBs einfach austauschen und brauchts nicht immer eine neue EXE der kompletten Applikation zu erstellen.

' schrieb:Also, bei mir entsteht die Modularität durch SubVIs. Ich erstelle aus meinem HauptVI eine EXE und dann sind automatisch alle enthaltenen SubVIs mit dabei, die ich auf dem Blockdiagramm platziert habe.
Wenn ich SubVIs dynamisch aufrufe (mit "Call by reference node"), binde ich sie beim Erstellen der EXE manuell mit ein (unter "Source Files" -> "Always included"), da sie hier nicht automatisch mit eingebunden werden.

Hallo Y-P
genau das will ich ja nicht, die Module sollen NICHT als SubVIs in die EXE mit einkompliert werden. Ich will sie ja dynamisch (also durch Call by Reference) aufrufen. Die VIs sollen ausserhalb der EXE in separaten LLBs o. ä. liegen


<!--quoteo(post=100915:date=02.07.2010 , 07:48:48:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 02.07.2010 , 07:48:48) [url=index.php?act=findpost&pid=100915][/url]</div><div class='quotemain'><!--quotec-->ich kann dir zwar nicht helfen, hätte aber eine Frage an dich
Hast du mir ein Stichwort, wie das mit den API-VIs funktioniert. Ich steh momentan vor dem Problem, dass ich zur Laufzeit der exe gerne .NET Assemblies austauschen möchte. Unter der Entwicklungsumgebung funktioniert das einwandfrei, da ich die VIs dynamisch laden kann und somit die Assemblies noch nicht in der LabVIEW AppDomain geladen wurden. Bei der exe jedoch wird mir dieser Mechanismus in der Standardkonfiguration ausgehebelt. Momentan bin ich dabei mir eine Wrapper dll zu schreiben, die mir ein dynamisches Austauschen ermöglicht. Wenn ich das umgehen könnte, wäre ich gar nicht traurig [/quote]

Da kann ich Dir leider nicht weiterhelfen, da ich mit .NET keine Ahnung habe.

Gruss Markus

Dein Ansatz ist genau richtig! Ich denke du musst nur noch schauen was diesen Fehler verursacht und das Problem beseitigen, abrissbirne hat hier einen guten Vorschlag geliefert.

Ein Nachteil an dieser Geschichte ist, dass durch das hinzufügen der vi.lib und user.lib die llb-Dateien sehr groß werden können. Aber ohne hinzufügen findet er die VI´s nicht auch wenn sie in der EXE drin sein sollten.

' schrieb:Ich will sie ja dynamisch (also durch Call by Reference) aufrufen. Die VIs sollen ausserhalb der EXE in separaten LLBs o. ä. liegen

Da kann ich Dir leider nicht weiterhelfen, da ich mit .NET keine Ahnung habe.

Gruss Markus

mit .NET brauchst du mir auch nicht zu helfen, das bekomm ich selber hin (hoff ich zumindest)
Ich hab hab mich auf das Call by Reference in einer executable bezogen. Das hab ich noch nie gemacht und wüsste jetzt auch nicht direkt unter was ich das bei ni.com suchen sollte...

' schrieb:Ein Nachteil an dieser Geschichte ist, dass durch das hinzufügen der vi.lib und user.lib die llb-Dateien sehr groß werden können. Aber ohne hinzufügen findet er die VI´s nicht auch wenn sie in der EXE drin sein sollten.

Du kannst diese in eine Datei ablegen. Beim "Compilieren" der LLB gibst du den Pfad für die Hilfsdateien an. Innerhalb deiner Release musst du dann den relativen Pfad auf diese Datei auch so anlegen und dann können alle LLBs auf diese Bibliotheken zugreifen.

<!--quoteo(post=100933:date=02.07.2010 , 10:04:56:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 02.07.2010 , 10:04:56) [url=index.php?act=findpost&pid=100933][/url]</div><div class='quotemain'><!--quotec-->Ich hab hab mich auf das Call by Reference in einer executable bezogen. Das hab ich noch nie gemacht und wüsste jetzt auch nicht direkt unter was ich das bei ni.com suchen sollte...[/quote]
In LabVIEW hat es ein Beispiel "Plug In Example", sollte doch auch mit einer Exe gehen. (wenn der Pfad stimmt, habe es aber auch nie gemacht)

Ist das nicht das gesuchte?
Was mich verunsichert, warum schreibt ihr von API-Vi ?

' schrieb:wenn der Pfad stimmt, habe es aber auch nie gemacht)

Ist das nicht das gesuchte?

Hi RoLe
danke für den Link
so hab ich das auch gemacht. In der IDE funktioniert das alles einwand frei. Bei einer executable funktioniert das aber irgendwie nicht mehr.
Da kann ich die dll nicht mehr austauschen, da sie schon geladen wurde. Und wenn einmal eine .NET Assembly in der AppDomain geladen wurde bekommst du die da nie mehr raus (ausser du schliesst die AppDomain)
Irgendwie klang die Anfangsfrage so, dass man das Laden irgendwie anders gestallten kann. Die Frage ist nur wie (auch mich hat das Wort API-VI irritiert, da ich noch nie was davon gehört habe und hoffte Hinweise darauf zu bekommen)