Einbinden von Treiberdateien .dll - Wie?

Hallo zusammen,

ich möchte meine erste Treiber-Datei (.dll) in LabView mit einem "Knoten zum Aufruf externer Bibliotheken" einbinden. Dabei handelt es sich um die Karte "cifx 50e-dp" von der Fa. Hilscher.
Anbei die Dokumentation mit Bildausschnitt, der Treiber (win10 & 32bit) und ein Beispiel-VI mit der Funktion "xChannellORead" von mir für die Treiber-Datei. Ich hoffe die Dokumentation ist richtig und vollständig.

Leider tut es noch nicht so wie es sollte.

Wie muss das VI richtig konfiguriert sein. Wie heißen die richtigen Einstellungen/Argumente unter Knoten zum Aufruf externer Bibliotheken -->Konfiguration --> Parameter? --> Leider ist das VI so nicht ausführbar.
(vgl. angehängtes Bild)
Welcher Name? Welcher Typ? Welcher Datentyp? Was Übergeben?
Welche Aufrufkonvention? Ausprobieren, ob LabView crashed?
Handelt es sich bei den Namen/Argumenten um Ein oder Ausgang? Woran erkenne ich das?

Über jedliche Hilfe und Anregung bin ich dankbar.

Mit freundlichen Grüßen
Thomas

Hallo Thomas,

ich bin wirklich kein Experte für DLL-Einbindung, aber
- hchannel sollte kein VOID sein, sondern zumindest ein U32 (für 32bit-Umgebung, oder besser Pointer-sized integer). Dieses Handle holst du dir doch mit einer anderen Funktion…
- pvdata erwartet einen Pointer auf einen Datenbuffer, hier sollte ein entsprechend groß definiertes Array (oder ein Cluster) angeschlossen werden. Wie der Buffer auszusehen hat, steht sicherlich auch irgendwo in der Anleitung…

Warte mal noch, bis RolfK diesen Thread entdeckt!

(03.01.2019 21:28 )t.hipp schrieb:  Leider ist das VI so nicht ausführbar.

Kein Wunder. Alle Eingänge sind ja auch nicht belegt.

Zitat:Welcher Name? Welcher Typ? Welcher Datentyp? Was Übergeben? Welche Aufrufkonvention?

Siehe Muster ...

Zitat:Ausprobieren, ob LabView crashed?

So blöd es klingt: Wenn LV crashed ist was falsch. Was aber nicht heißt, dass alles richtig ist, wenn es nicht crashed.

Zitat:Handelt es sich bei den Namen/Argumenten um Ein oder Ausgang? Woran erkenne ich das?

Der Rückgabewert ist immer ein Ausgang.
Alle Parameter eine Funktion sind per se immer Eingänge in die Funktion. Sie enthalten nämlich Werte, mit denen die Funktion etwas machen soll.
Manche Eingänge sind als Pointer definiert. Ein Pointer "zeigt" auf einen Datenbereich (kann sein ein Array, Cluster oder auch nur ein Wert - oder Kombi aus allem), in den die Funktion Daten ablegen kann. Dieser Bereich ist dann per Definition ein Ausgang. Daten ausgeben kann eine Funktion also nur über den Rückgabewert oder indirekt über ein Pointer (alle anderen Möglichkeiten indirekten Möglichkeiten wie File- oder Memory-Sharing lass ich jetzt mal weg ...).


Zu Aufrufkonvention:
Ist hier wohl WinAPI. Ob WinAPI oder C sollte in der Dokumentation stehen. Die hab ich aber nicht komplett durchgelesen ...

Beachte:
In der Parameterliste des Knotens ist der erste Parameter immer der Rückgabewert ...

Zum Rückgabewert:
Der Rückgabeparameter wird meistens dafür verwendet, dem Aufrufer mitzuteilen, ob die Funktion als solche richtig ausgeführt worden ist. Oft wird ein spezifischer Fehlerwert zurückgemeldet, der dann in der Dokumentation beschrieben ist - wo auch sonst

Hinweis 1:
CIFXHandle ist ein Handle, den die entsprechende Open-Funktion liefert. Handles sind oft ganz normale U32 (oder U64 in x64 ...)

Hinweis 2:
void* ist ein untypisierter Pointer. D.h. man weis nicht, ob der Zielbereich U8, U16, U32, String oder was auch immer ist. Ich würde in einem solchen Falle für Datentransfer array of u8 nehmen - und diesen Stream dann applikationsspezifisch weiterverarbeiten.

Und ganz wichtig: Beschreibung lesen, verstehen und anwenden.

Dann weiß man auch, dass man erst den Treiber öffnen, dann die Karte suchen und auswählen muss. Und wenn man sich's genau überlegt: Anders möchte man es gar nicht haben ...

Das Schöne an einer guten API wie dieser ist, dass sie auch die Funktion GetErrText bereitstellt ...

Am Schluss nicht vergessen alle Handles wieder zu schließen.

Echt Super!!
Herzlichen Dank für die vielen Hinweise, Anregungen, Beispiele, ... :-)

Ich denke, dass es jetzt soweit klar ist. Ich werde es die Woche mal an der realen Hardware ausprobieren. :-)
Denk das Mysterium .dll hat sich nen bisle gelichtet. :-)