Daten einer Struktur aus LV einer DLL übergeben

' schrieb:habe jetzt mal verschiedene sachen ausprobiert:

Hast du sehr gut gemacht. :top:

Zitat:was mich jetzt stutzig macht, warum bei 16byte keine fehlermeldung kommt.

Mich nicht.

Zitat:müsste hier nicht auch eine fehlermeldung kommen?

Möglicherweise nicht.
Ich gehe schon davon aus, dass im Großen und Ganzen schon die 4er-Schritte im Speicher eingehalten werden. Halt nur von einem Parameter zum anderen. Gerade am Stack nicht die 4er-Schritte einzuhalten wäre eine "Quälerei" für den Prozessor. Jeder Parameter für sich beginnt immer an einer durch vier teilbaren Stelle. Ob da irgendwann mal 3 leere Bytes vorhanden sind, das interessiert keinen.
Die beste Überprüfung ob alles funktioniert ist, den Rückgabewert, der ja mittels des dritten Parameters (eines Pointer) zurückgegeben wird, zu verifizieren. Wenn der Rückgabewert stimmt, stimmt auch die Übergabe des Pointers. Wenn die Übergabe des Pointers stimmt, stimmt der Rest auch. Würde der Rückgabewert nicht plausibel sein, würde die Übergabe des Pointers nicht stimmen. Dann wird's kritisch.

Anzeige

' schrieb:Jawohl, alles klar. So würde es jeder haben wollen (die Datenübergabe mein ich).

Nein, bisher nicht. Mir ist zumindest keine bekannt, die ohne Tricks genau das macht.

Das Problem ist der Pointer an sich. In einer Datenflußsteuerung gibt es keine expliziten Pointer. Warum sich da also beim DLL-Knoten Arbeit machen? Schön wäre, wenn man einfach ein Cluster anschließen könnte und im Knoten sagen "Pointer auf Daten". Das geht aber nicht.

Gehen tuts schon mit "Adapt to Type" oder wie das auf Deutsch heissen mag. Nur ist die Struktur die LabVIEW dann an die DLL gibt selten das, was die DLL erwartet (ausser die DLL wurde spezifisch dafür geschrieben um mit LabVIEW Datentypen zu arbeiten).

Zitat:Lösung:
Einen Stream (= String) generieren, anschließen und "PChar, Zeiger auf Daten" wählen. Im Prinzip müsstes du alle Daten des Clusters per flatten to string hardcore-typ-konvertieren und hintereinander in einen String schreiben. Dann hast du genau das, was die DLL erwartet. Ob du mit flatten to string einen String erzeugst oder die Daten in ein Array of int8 konvertierst ist egal. Hauptsache es kommt ein Stream heraus, also ein zusammenhängender Datenbereich, auf dessen Anfang ein Pointer zeigen kann.

Die Wahl eines PChar Pointers ist wohl nur sehr selten sinnvoll (ausser es handelt sich hier um eine unglückliche Übersetzung in LabVIEW). Wenn PChar für einen Pascalstring steht, was ich hier mal annehme, fügt LabVIEW am Anfang des Pointers ein Byte ein, das die Länge der übergebenen Daten in Bytes angibt. Limitiert den Buffer auch gleich auf maximal 256 Bytes. Gebrauch eines C String Pointers erscheint mir dann auch sinnvoller.
Aber: Der Unterschied zwischen einem C String Pointer oder einem Bytearray ist nur irrelevant wenn es darum geht Daten an die DLL zu übergeben. Für C String Pointers die zurückgegeben werden an das LabVIEW Diagram, scannt LabVIEW am Ende des Aufrufs den Buffer nach einem NULL Character und reduziert die Bufferlänge auf diese Länge.

Zitat:Der Typ Bool ist je nach Programmiersprache int8 oder int32. In LV int32. Das mit den Bitpositionen geht zwar auch, dann ist es aber kein expliziter Bool. Der Typ Bool wird wie eine normale Int-Zahl gespeichert. Lediglich der Wertebereich ist anders. Bool kennt nur zwei Werte: "Null" und "ungleich Null" (wobei "ungleich Null" praktischerweise, aber auch nur in den Fällen einer Zuweisung, mit Eins gleichzusetzen ist)

Für Windows 32bit ist BOOL ein 32bit integer wo 0 == FALSE und !0 == TRUE gilt, während BOOLEAN ein 8 Bit Iinteger ist mit gleicher Bedeutung. C++ definiert auch noch bool als 8bit integer. Alle anderen Boolean Deklarationen sind kundenspezifisch und nur durch Lesen der entsprechenden Headerdateien oder Dokumentation eindeutig zu identifizieren.

Rolf Kalbermatter