+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: DLL & externer Code (/Forum-DLL-externer-Code)
+---- Thema: LabVIEW und Java via JVM/JNI/Jace (/Thread-LabVIEW-und-Java-via-JVM-JNI-Jace)
LabVIEW und Java via JVM/JNI/Jace - Hep - 15.04.2010 18:16
Grüß Euch!
Seit einiger Zeit versuche ich, ein in Java geschriebenes Open Source Projekt mit LabVIEW anzusteuern. Genauer möchte ich bilder im OME-TIFF format via bio-formats (s. http://www.openmicroscopy.org/site) speichern. Vom OSProjekt aus gibt es auch die c++ bindings, sodass man die Funktionen via java virtual machine, mit Jace als dll bekommt.
Um von LabVIEW aus darauf komfortabel zugreifen zu können, versuche ich eine Wrapper-Dll zu schreiben, die mit der o.g. dll kommuniziert. Diese startet bis jetzt die JVM und schreibt ein Bild aus Zufallszahlen. Zum Test habe ich ein c++ konsolenprogramm geschrieben, das wie nachher LabVIEW die dll ansteuert. Damit funktioniert alles wunderbar.
Rufe ich meine wrapper dll aber mit LabVIEW auf, bekomme ich Probleme:
Starte ich nur die JVM, so endet die Funktion ohne Fehler und gibt mir auch zufällig gewählte Zahlen wie z.B. 42 zurück. Wenn ich dann aber LabVIEW schließe, bekomme ich den Fehler <The instruction at “0x08f2f83a” referenced memory at “0x081f9b64”. The memory could not be “read”>. Das passiert genau dann wenn jace::helper::createVM(..) nicht auskommentiert ist.
Die JVM scheint also irgendwie ziellose Pointer zu erstellen, die das c++ programm nicht stören, LV aber schon..
Wenn ich zusätzlich versuche, das Zufallsbild zu schreiben, bekomme ich bei der Ausführung Fehler - aber ich nehme an dass das an der falsch initialisierten JVM liegt..
Hat jemand von Euch erfahrung mit LabVIEW und JVM? Das näheste, das ich dazu gefunden habe, war der Artikel
http://digital.ni.com/public.nsf/allkb/BEE...6256BC80068A49A
der mir aber auch nicht weiterhelfen konnte..
für die JVM gibt es eine JVM.dll, die ich als includepfad beim erstellen der lvlib angegeben habe, da LabVIEW scheinbar nicht standardmäßig die PATH-Systemvariable durchsucht (!?)
viele Grüße + Danke
Heinrich
(verwendete Versionen: Visual Studio 2008, LV2009)
[der .cpp code ist grad nicht sehr schön weil ich grad dauernd am rumkommentieren zum fehlersuchen bin - main wird nicht verwendet, nur createJVM und minWrite]
LabVIEW und Java via JVM/JNI/Jace - rolfk - 16.04.2010 06:29
Wie sieht das LabVIEW Interface zu int minWrite(int argc, const char *argv[]) aus?
Dieser argv Parameter ist nichts was LabVIEW's Call Library Node direkt machen kann!!
Und stimmen die konfigurierten Calling Conventions in der Call Library Node mit denen des DLL Projekts überrein? Da Du die nicht explicit im C Source definierst werden die Projektsettings genommen, die wenn Du gar nichts angibst bei Visual Studio zumindest früher normalerweise cdecl war.
LabVIEW und Java via JVM/JNI/Jace - Hep - 19.04.2010 09:04
Ich habe den call library node verwendet und argv als c-string-zeiger definiert - dann war das wohl falsch? dann werde ich mal schauen wie ich das richtig mache (allerdings kommt der memory-fehler auch wenn ich minWrite nicht aufrufe)
Ich habe es eben auch so gelesen, dass die aufrufkonvention cdecl ist, und habe angenommen dass das der aufrufkonvention C im call library node entspricht, und dieses ausgewählt..
LabVIEW und Java via JVM/JNI/Jace - rolfk - 19.04.2010 09:56
' schrieb:Ich habe den call library node verwendet und argv als c-string-zeiger definiert - dann war das wohl falsch? dann werde ich mal schauen wie ich das richtig mache (allerdings kommt der memory-fehler auch wenn ich minWrite nicht aufrufe)
Ich habe es eben auch so gelesen, dass die aufrufkonvention cdecl ist, und habe angenommen dass das der aufrufkonvention C im call library node entspricht, und dieses ausgewählt..
const char * argv[] ist nicht ein C String pointer sondern ein Pointer auf ein Array von C String Pointern. (Könnte auch ein Pointer auf einen C string Pointer sein, da C keinen Unterschied macht zwischen char *var und char var[], respektive die zweite Variante war in vielen früheren C Compilern unbekannt) aber argc und argv sind die üblichen Weisen um Aufrufparameter an die Hauptfunktion eines Executables zu übergeben und dort ist es immer ein Array von Strings.
Da aber LabVIEW Strings nicht gleich C Strings sind kann man nicht einfach ein LabVIEW Stringarray machen und das an die Funktion geben und der const char *argv[] ist ganz sicher kein C String Pointer, d.h. deine Funktion is mit der Call Library Node grundsätzlich nicht aufrufbar.
Wenn der Memoryfehler auch beim Aufrufen von nur der createJVM() geschieht hast Du ein seriöses Problem. Die Funktionsparameter sind ja eindeutig, da kann es also beinahe nicht liegen. Deshalb muss es wohl etwas sein was Du in dieser Funktion tust. Was kann ich Dir leider nicht sagen da ich erstens nicht gut beschlagen bin in C++ und zweitens die Library die Du aufrufst nicht kenne. Von meinen C Kenntnissen her finde ich einiges an dem Code sehr fragwürdig aber kann nicht beurteilen ob es ein Problem ist. Beispielsweise deklarierst Du eine Variable jace::OptionList list; und referenzierst Du die danach. Es ist mir nicht deutlich ob die Deklaration dieser Variablen diese auch gleich initilialisiert oder nicht. Falls nicht müsste der anschliessende Aufruf natürlich schwer in die Hosen gehen.
LabVIEW und Java via JVM/JNI/Jace - Hep - 08.09.2010 09:09
Der Vollständigkeit halber: ich habe es nur hinbekommen, von einem c++ program meine wrapper dll aufzurufen und die Funktionalität der java library zu bekommen. Sobald ich mit einem labview programm die selbe dll aufrufe, funktioniert es nicht. und das auch ohne Argumente in den aufrufenden Funktionen.
Also war der erste Versuch die Funktionalität in einder eigenen dll nachzuschreiben und diese von labview aufzurufen. das funktioniert, ist halt mühsame arbeit und wenig elegant.
Dann hat sich eine zweite Variante ergeben: es gibt in Labview (zumindest ab 2009) den Matlab script knoten. Damit kann man auch m-files aufrufen, die man schön übersichtlich programmieren kann. in einem solchen habe ich die java library aufgerufen und bekomme auch in LabView zugriff auf die komplette Funktionalität.
Ein Problem hierbei ist nur, dass der Knoten alle numerischen Werte in Double konvertiert, d.h. wenn man z.B: u16 daten hat, müssen die immer hin-und her konvertiert werden.
viele Grüße
Heinrich