Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
danke das Du Dich nochmal zu dem Problem geäussert hast. Ich hab Dir im Anhang mal die Dateien angehängt mit denen ich bisher gearbeitet habe. Wie Du sehen wirst ist das alles nicht soviel. Mir ging es prinzipiell darum die CLEyeMulticam.dll in Labview anzusprechen. Testen wirst Du das wohl aber nicht können, da Du ja die Hardware bräuchtest. Den Treiber kann man sich im übrigen hier herunterladen.
danke das Du Dich nochmal zu dem Problem geäussert hast. Ich hab Dir im Anhang mal die Dateien angehängt mit denen ich bisher gearbeitet habe. Wie Du sehen wirst ist das alles nicht soviel. Mir ging es prinzipiell darum die CLEyeMulticam.dll in Labview anzusprechen. Testen wirst Du das wohl aber nicht können, da Du ja die Hardware bräuchtest. Den Treiber kann man sich im übrigen hier herunterladen.
im Anhang die beiden vorerst von mir erstellten VI's: PS3_CameraCount.vi und PS3_GetCameraUUID.vi. CameraCount funktioniert bei mir (ist ja auch trivial und Minimalst). An GetCameraUUID beiss ich mir wie gesagt die Zähne aus. Wie bereits zuvor beschrieben, kann ich mir auch den Pointer aus dem ersten Node nicht anzeigen lassen. Theoretisch müsste das ja möglich sein wenn der gesamte MoveBlock Teil einfach weggelassen wird. Aber bereits in einem solchen Fall bekomm ich den zuvor beschriebenen Fehler. Der Parameter für den Funktionsaufruf ist richtig. Das hab ich mehrfach überprüft. Ich hab im Anhang auch noch ein C# Beispiel angehängt das die beschriebene .dll nutzt.
Beste Grüße,
Jan
05.03.2012, 20:14 (Dieser Beitrag wurde zuletzt bearbeitet: 05.03.2012 20:17 von rolfk.)
im Anhang die beiden vorerst von mir erstellten VI's: PS3_CameraCount.vi und PS3_GetCameraUUID.vi. CameraCount funktioniert bei mir (ist ja auch trivial und Minimalst). An GetCameraUUID beiss ich mir wie gesagt die Zähne aus. Wie bereits zuvor beschrieben, kann ich mir auch den Pointer aus dem ersten Node nicht anzeigen lassen. Theoretisch müsste das ja möglich sein wenn der gesamte MoveBlock Teil einfach weggelassen wird. Aber bereits in einem solchen Fall bekomm ich den zuvor beschriebenen Fehler. Der Parameter für den Funktionsaufruf ist richtig. Das hab ich mehrfach überprüft. Ich hab im Anhang auch noch ein C# Beispiel angehängt das die beschriebene .dll nutzt.
Beste Grüße,
Jan
Ok das hilft! Ein paar Dinge sind hierbei erwähnenswert:
1) Das program.txt File spezifiziert keine Calling Convention und gemäss MSDN bedeutet dies für .Net Sprachen (Visual Basic, C#, C++) dass stdcall verwendet wird. Deshalb muss man das in der Call Library Node für die Funktionen dieser DLL ebenfalls so einstellen. Deshalb crashte der Aufruf der GetCameraUUID Funktion auch da der Stack korrumpiert wurde. Für die CameraCount Funktion machte es nichts aus da diese Funktion keine Parameter hat.
Achtung: Die Call Library Node für die MoveBlock Funktion muss auf cdecl bleiben, da LabVIEW alle seine Funktionen als cdecl exportiert.
2) Der erste Parameter zu MoveBlock muss als Integersized Pointer konfiguriert sein, soweit hast Du das richtig, aber Du stellst dazu auch ein dass dieser Wert als Referenz übergeben werden muss was falsch ist. Du willst nicht einen Pointer auf den Pointer an diese Funktion geben sondern direkt den Pointer den die GetCameraUUID Funktion zurückgegeben hat.
3) Der zweite Parameter zu MoveBlock sollte nicht ein Cluster mit 16 Floatingpointzahlen sein sondern einer mit 16 Bytes, und ein Byte entspricht einem U8. Alternativ kannst Du ihn auch als Array of 16 * U8, passed as Array Pointer konfigurieren, und dieses Array direkt so aus der Funktion führen. Solange Du diese GUID nicht selbst optisch interpretieren willst sondern nur verwendest um an andere Funktionen zu übergeben ist das kein Problem. Oder Du kannst das Array auch nach der Call Library Node mit der Array to Cluster Node umwandeln. Nicht vergessen auf diese Funktionen einen Rechtsklick zu machen und die Clustergrösse auf 16 einzustellen.
vielen lieben Dank für Deine hilfreichen Tips. Habe sie umgesetzt, aber die VI beendet immernoch mit einem Fehler (siehe vorherige Posts.) Ich hab Dir meine Änderungen nochmals angehängt.
vielen lieben Dank für Deine hilfreichen Tips. Habe sie umgesetzt, aber die VI beendet immernoch mit einem Fehler (siehe vorherige Posts.) Ich hab Dir meine Änderungen nochmals angehängt.
Beste Grüße,
Jan
Wo krachts denn? Du hast Punkt 2) meines Posts nicht gut durchgelesen.
auch wenn ich den Adress(Pointer) der Moveblock Funktion zu "Wert" ändere, anstatt "Zeiger auf Wert" , gibt die VI einen Fehler aus. Dieser wird allerdings schon in dem ersten .dll Knoten generiert, daher glaube ich nicht das es an der MoveBlock Funktion hapert. Irgendetwas ist mit dem Funktionsaufruf im ersten "Call Library Knoten" falsch. Und ich weiss nicht was. Hab bereits mit mehreren Parametern gespielt - leider ohne Erfolg. Hast Du noch eine Idee?
Beste Grüße,
Jan
07.03.2012, 08:50 (Dieser Beitrag wurde zuletzt bearbeitet: 07.03.2012 08:53 von rolfk.)
auch wenn ich den Adress(Pointer) der Moveblock Funktion zu "Wert" ändere, anstatt "Zeiger auf Wert" , gibt die VI einen Fehler aus. Dieser wird allerdings schon in dem ersten .dll Knoten generiert, daher glaube ich nicht das es an der MoveBlock Funktion hapert. Irgendetwas ist mit dem Funktionsaufruf im ersten "Call Library Knoten" falsch. Und ich weiss nicht was. Hab bereits mit mehreren Parametern gespielt - leider ohne Erfolg. Hast Du noch eine Idee?
Beste Grüße,
Jan
Ok ich habe noch mal alle Files in Deinem ZIP Archive angeschaut. Und dabei scheint es dass das Headerfile zur DLL die Funktionsaufrufe etwas anders und deutlicher deklariert, als das was auf der Webseite zu sehen ist, die Du zuerst verlinkt hast. Demgemäss sind die Funktionen der CLEye DLL eben doch als cdecl deklariert. Wie sich das mit dem .Net Vorbild in Program.txt zusammenreimen lässt, das keine Aufrufkonvention im IMPORT Statement festlegt und daher gemäss MSDN stdcall verwenden würde weiss ich jetzt auch nicht. Aber da das DLL Header File wohl vom Hersteller kommt, und das .Net Vorbild vielleicht von weiss ich wem, gehe ich davon aus dass cdecl doch die richtige Konvention für alle CLEye Funktionen ist.
abgesehen davon, dass das zur VErfügung gestellte Programm "programm.txt" aus der gleichen Quelle stammt wie der Treiber selbst, habe ich auch alle Kombinationen aus Aufrufkombinationen getestet. Cdecl und Standard. Hast Du noch weitere Ideen woran es liegen könnte?
abgesehen davon, dass das zur VErfügung gestellte Programm "programm.txt" aus der gleichen Quelle stammt wie der Treiber selbst, habe ich auch alle Kombinationen aus Aufrufkombinationen getestet. Cdecl und Standard. Hast Du noch weitere Ideen woran es liegen könnte?
/
UUID als Datentyp für eine DLL erstellen
