UUID als Datentyp für eine DLL erstellen

Hallo zusammen,

ich versuche seit Tagen eine C++ API in LabView zum laufen zu bekommen. Das Header-file kann man sich hier an sehen:

http://codelaboratories.com/research/vie...camera-api

die zugehörige DLL-Datei habe ich. Neben allen anderen Funktionen würde ich zunächst einmal gern die Funktion

GUID CLEyeGetCameraUUID(CameraIndex as int)

umsetzen. Scheitere aber an dem Datentyp der GUID (respektive UUID also 16-Byte-Zahl, die hexadezimal notiert und in fünf Gruppen unterteilt wird bspw. 550e8400-e29b-11d4-a716-446655440000).
Ist das überhaupt machbar?
Nutze ich dann einen Cluster-Datentypen? Wenn ja, wie formatiere ich den damit dieser 16-Byte-Zahlen akzeptiert?

Bin für jede noch so kleine Hilfe dankbar.

Beste Grüße,
Jan

Die LabVIEW Call Library Node kann nur Skalars und Strings als Returnwert behandeln. Und es gibt keine Skalars die 128 Bit gross sind. Man muss diesen Parameter also also Pointersized Integer konfigurieren und dann mittels Aufruf der LabVIEW C Funktion MoveBlock mit einer zweiten Call Library Node die 16 Byte aus dem Pointer in einen genügend grossen Cluster kopieren.

Zum Thema MoveBlock gibts hier, im LabVIEW Forum bei forums.ni.com und auf lavag.org viele Beiträge. Auch Google will Dir da einiges an Informationen liefern.

Hallo Rolf,

vielen Dank für Deine Antwort. Ich habe jetzt die MoveBlock Funktion verwendet, so wie Du es empfohlen hast. Einen 16 Byte Cluster initialisiere ich mit 16 X 8 Bit Werten. Kann ich dies überhaupt tun, auch wenn ich Hexadezimalwerte erwarte?
Die vi liefert, so wie sie jetzt ist allerdings auch noch einen Fehler an meinem ersten DLL Knoten (also der welcher auf die Kamera Dll verweist -links im Bild). Müsste nicht eher ein Fehler in der MoveBlock funktion angezeigt werden? Im Anhang mal eine Abbildung der jetzigen Vi.

Beste Grüße,
Jan

: @jabami: Was soll "Novize" bei der LabVIEW-Version in Deinem Profil sein? Bitte .
Noch was: Arbeitet Ihr beiden neuerdings in Japan (wenn ich mir so die Uhrzeiten Eurer Posts anschaue)?

Gruß Markus

Was für ein Fehler? Und wie ist die MoveBlock Funktion konfiguriert?

Hallo Rolf,

die Fehlermeldung (ist für mich) relativ nichtssagend. Ich verstehe eben nur nicht warum sie nicht durch den MoveBlock DLL-Knoten ausgelös wird sondern eben durch den Knoten davor. Es macht den Anschein als wenn der Pointer den Knoten nicht "verlässt". Gibt es eine Möglichkeit sich den Pointer direkt anzeigen zu lassen?

Ich habe zum einen die MoveBlock Konfiguration angehängt, als auch die Fehlermeldung samt Ihrer Beschreibung. Danke fürs drüberschauen.

Gruß,
Jan

Anzeige

Hallo zusammen,

oh man ich versteh es einfach nicht. Ich habe eine .dll mit zugehöriger Header Datei (siehe erster Post). Ich kann eine Funktion aus dieser dll ansprechen, nämlich die einfachste. In diesem Fall: CLEyeGetCameraCount. Diese Funktion gibt mir als integerwert einfach die anzahl angeschlossener Kameras aus. In meinem Fall eine 1.
Nun will ich die nächste Fnktion ansprechen die mir die UUID der angeschlossenen Kamera ausgibt. Ich füttere die Funktion mit dem Kameraindex (hier 1) und setze den Dll-Knoten Rückgabewert auf "zeigergroßer integer". Jetzt kann ich diesen Pointer in eine zweite MoveBlock Dll-Knoten einbringen der mir dann die hinterlegten Daten (hier die UUID) in ein vorher initialisierten 128 bit Cluster schreibt. Den Bit-Cluster initialisiere ich mit 8 mal 8 bit Integer Werten (U8). Erwarten würde ich nun das am Ausgang meiner MoveBlock konstruktion die UUID in den Cluster geschrieben wird. Stattdessen erhalte ich Fehlermeldungen an meinem ersten DLL-Knoten. Also dem der die eigentliche Funktion implementiert. Wo ist hier mein Denkfehler? Ich komm partout nicht dahinter....

Euch noch einen schönen Abend,
Jan

(16.02.2012 21:34 )jabami schrieb:  Hallo Rolf,

die Fehlermeldung (ist für mich) relativ nichtssagend. Ich verstehe eben nur nicht warum sie nicht durch den MoveBlock DLL-Knoten ausgelös wird sondern eben durch den Knoten davor. Es macht den Anschein als wenn der Pointer den Knoten nicht "verlässt". Gibt es eine Möglichkeit sich den Pointer direkt anzeigen zu lassen?

Ich habe zum einen die MoveBlock Konfiguration angehängt, als auch die Fehlermeldung samt Ihrer Beschreibung. Danke fürs drüberschauen.

Gruß,
Jan

Welche Aufrufkonvention hast Du eingestellt? Die LabVIEW MoveBlock Funktion muss mit C Aufrufkonvention angerufen werden. Deine CLEye API weiss ich jetzt so nicht, aber da sie im Header scheinbar keine explizite Deklaration festlegt wird es wohl Mcrosoft C default sein, und das wäre auch C! Aber der Programmierer kann im Projektfile die Defaultkonvention überschraiben, sodass es nicht sicher ist, ohne das Projektfile, was ja wohl vom Hersteller nicht herausgegeben wird.

Die Konfioguration der MoveBlock Funktion sieht falsch aus. Der erste Parameter ist soweit korrekt, aber der zweite sollte nicht als ILVData sondern als einer der anderen drei Untertypen von Adapt to Type eingestellt sein (die Unterschiede der ersten drei Typen ist nur bei Daten die LabVIEW Handles sind von Wichtigkeit). Der Letzte Parameter ist auch kein Integerpointer sondern ein ganz einfacher Signed Integer, Passed by Value.

Hallo Rolf,

ich hab es jetzt 2 Wochen immer mal wieder versucht. Ich gebe auf. Ich bin mir mittlerweile sicher das LabView den GUID Datentyp in keinster Weise unterstützt, auch nicht durch die MoveBlock funktion. Ich glaube es liegt einfach daran, das eine GUID ein zusammengesetzter Datentyp ist und somit eben nicht nur einen Zeiger besitzt (so jedenfalls meine Laienhafte Vermutung). Das Problem ist wohl nur durch das Schreiben und implementieren einer Wrapper .dll zu lösen. Da ich aber so gut wie keine C# oder C++ Programmierkenntnisse besitze muss ich passen.

Dennoch Danke für die entgegengebrachte Hilfe,

Beste Grüße,
Jan

(03.03.2012 18:00 )jabami schrieb:  Hallo Rolf,

ich hab es jetzt 2 Wochen immer mal wieder versucht. Ich gebe auf. Ich bin mir mittlerweile sicher das LabView den GUID Datentyp in keinster Weise unterstützt, auch nicht durch die MoveBlock funktion. Ich glaube es liegt einfach daran, das eine GUID ein zusammengesetzter Datentyp ist und somit eben nicht nur einen Zeiger besitzt (so jedenfalls meine Laienhafte Vermutung). Das Problem ist wohl nur durch das Schreiben und implementieren einer Wrapper .dll zu lösen. Da ich aber so gut wie keine C# oder C++ Programmierkenntnisse besitze muss ich passen.

Dennoch Danke für die entgegengebrachte Hilfe,

Beste Grüße,
Jan

Ein GUID, zumindest in Windows C API Notation, ist ganz einfach eine C Struktur mit insgesamt 16 Bytes. Da ist nichts magisches dran und das geht mit LabVIEW absolut sicher. Das einzige Problem könnte sein, dass die Funktion diesen Buffer als Funktionsrückgabewert zurückgibt anstelle durch einen Parameter. Wo die Funktion diesen Buffer anlegt und wie lange sie ihn gültig hält ist ganz einfach ausserhalb der Kontrolle von LabVIEW, Das könnte ein statischer Buffer sein (einfach zu implementieren, wenig Chancen auf Fehler, aber problematisch wenn das API Multithreaded aufgerufen wird), ein dynamischer Speicherbereich, der einmal angelegt wird und bis zum ausladen der DLL bestehen bleibt (gleiche Vor- und Nachteile wie statischer Speicher aber komplizierter zum implementieren für den DLL Programmierer), oder ein dynamischer Speicherbereich der jedesmal angelegt wird (Laufzeitverzögerung durch das jeweilege Anlegen und initialisieren des Buffers und Speicherlecks wenn der Aufrufer der Funktion vergisst diesen Speicherbereich danach wieder freizugeben, aber dies ist die einzige multithreading safe Variante).

Es ist wahr dass selbst bei relativ trivialen Funktionen eine WrapperDLL oftmals Vorteile bietet da man das eigentliche API mittels C Syntax ansprechen kann und das LabVIEW API so gestalten kann dass es LabVIEW freundlich ist. Man muss dabei aber C verstehen und was man niemals vergessen sollte, um das Call Library node Interface wirklich benützen zu können ausser für triviale C Funktionen, ist diese Kenntnis effektiv ebenfalls nötig. Überspitzt gesagt ist die Call Library Node für jemanden der keine Wrapper DLL machen kann nicht das richtige Spielzeug!

Da Du immer nur Bilder der VIs angehängt hast musste ich mich darauf beschränken zu vermuten was Du falsch gemacht hast und konnte ich Dir nur allgemeine Hilfestellungen bieten. Ein Bild sagt mehr dann tausend Woirte ist zwar wahr, aber gerade im Fall der Call Library Node enthält es nur einen Bruchteil der relevanten Informationen. Denn die Parameterkonfiguration ist darin nur sehr grob ersichtlich aber die feineren Details bestimmen gerade hier ob es funktioniert, nichts tut oder ganz einfach kracht und LabVIEW mit einer allgemeinen Schutzverletzung zum Speicher rauswirft.