DLL mit BSTR-Variable einbinden

Hallo liebe Forengemeinde,

im Zuge meiner Diplomarbeit muss ich mich jetzt etwas intensiver mit LabVIEW auseinandersetzen.
Es soll dabei ein digitaler Messschieber über ein USB-Interface ausgelesen werden. Als Interface verwende ich die USB-Box von http://www.caliper2pc.de.
Es wird ein kleines Softwarepaket mitgeliefert, welches auch eine DLL enthält, welche ich jetzt in LabVIEW implementieren möchte.
Doch leider funktioniert das ganze nicht so reibungslos, wie ich mir das vorgestellt habe und LabVIEW bricht immer mit einem Fehler 1097 ab, egal welche Aufrufkonventionen ich verwende, bzw. welche Rückgabeparamter.
Ich stehe mit dem Entwickler in sehr engem Mailkontakt, doch leider kann er mir keinen Support für LabVIEW geben, da er von LabVIEW keine Ahnung hat.
Bisher habe ich jedoch in Erfahrung bringen können, dass die DLL wohl in Visual C++ geschrieben wurde und die Returntypen der für mich interessanten Funktionen (GetChannel) BSTR ist.
Nun habe ich schon in etlichen Foren zum Thema BSTR und Labvie gelesen, aber keinen wirklich hilfreichen Tipp gefunden.
Gibt es eventuell die Möglichkeit eines der Beispielprogramme (C# oder VB) direkt in LabVIEW zu implementieren?
Oder gibt es doch einen Kniff, wie ich die DLL mit Ihren Ecken und Kanten (?) in LabVIEW verwenden kann?
Ich freu mich auf eure Hilfe.

Liebe Grüße

Micha

Anzeige

Liest Du Dich mal hier duch. Die darin vorgestellte LabvIEW Library kann auch BSTR erzeugen.

Rolf Kalbermatter

Hallo Rolf,

danke für deine Antwort. Durch den von dir genannten Beitrag hatte ich mich auch schon durchgewühlt, doch leider hab ich noch nicht verstanden, in wiefern mir deine Bibliothek weiterhelfen kann. Denn scheinbar gibt es bereits ein Problem, wenn der DLL-Knoten versucht auf die DLL zuzugreifen, da es mit fehlerhaften Parametern passiert.
Oder soll ich einen CString ausgeben lassen und den dann mit deiner Bibliothek umwandeln? Das würde jeglicher Logik, die ich bisher verwendet habe, widersprechen.

Grüße

Micha

' schrieb:Hallo Rolf,

danke für deine Antwort. Durch den von dir genannten Beitrag hatte ich mich auch schon durchgewühlt, doch leider hab ich noch nicht verstanden, in wiefern mir deine Bibliothek weiterhelfen kann. Denn scheinbar gibt es bereits ein Problem, wenn der DLL-Knoten versucht auf die DLL zuzugreifen, da es mit fehlerhaften Parametern passiert.
Oder soll ich einen CString ausgeben lassen und den dann mit deiner Bibliothek umwandeln? Das würde jeglicher Logik, die ich bisher verwendet habe, widersprechen.

Grüße

Micha

Kannst dir auch eine wrapper DLL schreiben. Diese ruft deine Funktionen der mitgelieferten DLL auf und verarbeitet die Rückgabewerte so, dass du sie in LV ohne Probleme auslesen kannst. Dafür gibt es String Conversation Macros String Conversation.

abrissbirne

' schrieb:Hallo Rolf,

danke für deine Antwort. Durch den von dir genannten Beitrag hatte ich mich auch schon durchgewühlt, doch leider hab ich noch nicht verstanden, in wiefern mir deine Bibliothek weiterhelfen kann. Denn scheinbar gibt es bereits ein Problem, wenn der DLL-Knoten versucht auf die DLL zuzugreifen, da es mit fehlerhaften Parametern passiert.
Oder soll ich einen CString ausgeben lassen und den dann mit deiner Bibliothek umwandeln? Das würde jeglicher Logik, die ich bisher verwendet habe, widersprechen.

Grüße

Micha

Also als Returnwert der Funktion wird sie den String ja selber anlegen. Den musst Du daher als Pointer sized Integer (32bit unsigned Integer in pre LabVIEW 8.6) definieren.

Danach kannst Du mit der Funktion "Convert UTF16 Pointer to ASCII.vi" den String daraus auslesen. Zuletzt nicht vergessen den Poiner mit "Deallocate BSTR Pointer.vi" wieder freizugeben. Sonst müllst Du dir den Speicher sehr schnell voll.

Rolf Kalbermatter

Danke ihr beiden,

eine Wrapper-DLL wollte ich vermeiden, aber so wie es ausschaut, scheint das ganze nicht annähernd so komfortable zu funktionieren, wie ich mir das vorgestellt hatte, abgesehn von den LabVIEW-Problemen.

Habe ich das richtig verstanden, dass die DLL wahrscheinlich nur einen Pointer liefert und dieser Pointer dann in der Bibliothek von Rolf in einen String umgewandelt wird. Das heißt also, dass die zur Verfügung gestellte Bibliothek, bzw. deren Konverter, nichts anderes machen, als auf den Speicherbereich zuzugreifen, auf den der Zeiger zeigt und den Inhalt dann in einen ASCII-Code umwandeln?

Nunja, ich hab mal versucht das ganze in meinem Minimalbeispiel zu integrieren, doch leider ändert das überhaupt nichts an der Fehlermeldung 1097, diese scheint also durch etwas anderes verursacht zu werden.

Vielleicht habe ich aber auch etwas falsch aufgebaut, es wäre schön, wenn Ihr mal drüberschauen könntet. Eventuell fällt euch ja noch eine andere Lösung ein?!

Grüße

Micha

Ich würde die Calling Convention mal auf stdcall setzen. Da es eine Windows/VB DLL zu sein scheint ist stdcall (Standard Call) normalerweise der Standard.

Rolf Kalbermatter

Ich habe mir jetzt eine Wrapper-Dll in C# geschrieben und das funktioniert nach ein paar kleineren Problemen auf Rechnern ohne .NET-SDK auch ganz gut.
Sollte Interesse an dem Quellcode der Wrapper-Dll bestehen, dann geb ich den auch gern bekannt.

Die Sache mit der Bibliothek hat leider nur mäßig funktioniert. Entweder habe ich einen Error bekommen, oder wenn es lief, dann hat er mir lustige Zeichen in dem String-Feld angezeigt, aber nicht das, was er sollte!

Ich dank euch erstmal für die Hilfe und werde mich im Zuge meiner Diplomarbeit sicher nochmal melden.

Bis dahin!