Parameterübergabe beim Call DLL Functions inLabVIEW

Hallo! Ich bin neu in diesem Foum, hoffe aber auf Eure Hilfe bzw. Rat.
Ich binde eine DLL über CLFN (LV 8.2.1f4) ein und habe folgendes Problem beim Parameterübergabe: die Function will 2 Arrays mit Pointers haben (also, mit Addressen, wo die durch die Function ermittelte Werte reingeschrieben werden). Meine kurze LV-Erfahrung sagt, dass es nicht geht. Stimmt es, oder gibt es dafür ein Trick? Die Header-Datei füge ich bei, davor eine kurze Erklärung, was die Funktion so macht.
Das ist die Declaration:

GPMILIB_API GPMI_Error_t
GPMI_Get_Multi_Item_LV( Packet_Handle_t hpacket,
unsigned int uinum_items,
char szname[][MAX_SIZE_ITEM_NAME],
void *pvvalue[],
unsigned int *puivalue_size_in_bytes[],
GPMI_Error_t err[] );

GPMILIB_API GPMI_Error_t - ist ein U32mit FehlerCode.
Packet_Handle_t - ist ein U32,
char szname[][] wandle ich um zum ByteArray mit entsprechende Abschlusszeichen für C-String. Das alles geht ganz gut.
GPMI_Error_t ist auch unproblematisch.

Das Array *pvvalue[] soll die Addressen von Values beinhalten. Die Funktion soll dorthin je ein Wert eintragen. Da das Wert verschiede Länge haben kann (mal double, mal U16), wird die Länge des Wertes im *puivalue_size_in_bytes[] mitgeteilt (dasselbe Prinzip - Array von Pointers/Addressen ).
Da die Addresse immer ein U32 ist, bindet der DLL Author die Adressen in Array und übergibt es so die Function. Die Länge ist in uinum_items angegeben.
_
GEht es überhaupt? Oder soll das Interface zur Funktion geändert werden?
Eure Rat ist für mich eine grosse Hilfe, da die Anwendung DLLs in unserem Project sehr oft vorkommt.

PS: Leider funktionniert das Hochladen nich - mir ist nicht gestattet, eine Datei dieses Datentypes hochzuladen (was könnte das bedeuten ?). Vielleicht rteicht aber diese Information bereits?

' schrieb:Hallo! Ich bin neu in diesem Foum, hoffe aber auf Eure Hilfe bzw. Rat.
Ich binde eine DLL über CLFN (LV 8.2.1f4) ein und habe folgendes Problem beim Parameterübergabe: die Function will 2 Arrays mit Pointers haben (also, mit Addressen, wo die durch die Function ermittelte Werte reingeschrieben werden). Meine kurze LV-Erfahrung sagt, dass es nicht geht. Stimmt es, oder gibt es dafür ein Trick? Die Header-Datei füge ich bei, davor eine kurze Erklärung, was die Funktion so macht.
Das ist die Declaration:

GPMILIB_API GPMI_Error_t
GPMI_Get_Multi_Item_LV( Packet_Handle_t hpacket,
unsigned int uinum_items,
char szname[][MAX_SIZE_ITEM_NAME],
void *pvvalue[],
unsigned int *puivalue_size_in_bytes[],
GPMI_Error_t err[] );

GPMILIB_API GPMI_Error_t - ist ein U32mit FehlerCode.
Packet_Handle_t - ist ein U32,
char szname[][] wandle ich um zum ByteArray mit entsprechende Abschlusszeichen für C-String. Das alles geht ganz gut.
GPMI_Error_t ist auch unproblematisch.

Das Array *pvvalue[] soll die Addressen von Values beinhalten. Die Funktion soll dorthin je ein Wert eintragen. Da das Wert verschiede Länge haben kann (mal double, mal U16), wird die Länge des Wertes im *puivalue_size_in_bytes[] mitgeteilt (dasselbe Prinzip - Array von Pointers/Addressen ).
Da die Addresse immer ein U32 ist, bindet der DLL Author die Adressen in Array und übergibt es so die Function. Die Länge ist in uinum_items angegeben.
_
GEht es überhaupt? Oder soll das Interface zur Funktion geändert werden?
Eure Rat ist für mich eine grosse Hilfe, da die Anwendung DLLs in unserem Project sehr oft vorkommt.

PS: Leider funktionniert das Hochladen nich - mir ist nicht gestattet, eine Datei dieses Datentypes hochzuladen (was könnte das bedeuten ?). Vielleicht rteicht aber diese Information bereits?

Nein Array of C Pointers ist kein durch die Call Library Node unterstützter Parametertyp. Du wirst das Interface anpassen müssen, entweder indem Du mit LabVIEW Datentypen arbeitest (Handles, aber das verlangt dass Deine DLL mit LabVIEW.lib gelinkt wird und dann funktioniert sie nur noch wenn sie von LabVIEW oder einer LabVIEW applikation aufgerufen wird), oder eine Anpassung mit der Du die einzelnen Strings enumerieren kannst.

Rolf Kalbermatter

:profil:Version .2 ????

Und wenn du eine Datei zwecks Foreneinstellungen nicht hochladen kannst, gibt es immer noch Möglichkeiten. Z.B. Zip-Datei. Oder Dateiendung ändern, z.B. auf *.txt.

Gruß, Jens

' schrieb:Nein Array of C Pointers ist kein durch die Call Library Node unterstützter Parametertyp. Du wirst das Interface anpassen müssen, entweder indem Du mit LabVIEW Datentypen arbeitest (Handles, aber das verlangt dass Deine DLL mit LabVIEW.lib gelinkt wird und dann funktioniert sie nur noch wenn sie von LabVIEW oder einer LabVIEW applikation aufgerufen wird), oder eine Anpassung mit der Du die einzelnen Strings enumerieren kannst.

Rolf Kalbermatter

Danke, ich werde es mit dem DLL-Entwickler besprechen. Verstehe ich es richtig mit ENUM, dass man die Strings als reservierte Speicher ansehen kann (wie ByteArray) , wohin die Function etwas schreibt?

' schrieb:
:profil:Version .2 ????

Und wenn du eine Datei zwecks Foreneinstellungen nicht hochladen kannst, gibt es immer noch Möglichkeiten. Z.B. Zip-Datei. Oder Dateiendung ändern, z.B. auf *.txt.

Gruß, Jens

Ich hatte zwar auch an die Änderung des Datentyps gedacht, aber war mir nicht sicher, ob es richtig verstanden wird. Ich werde aber auch im Profile nachschaeu, warum ich solche Voreinstellungen habe.
Gruss

' schrieb:Ich hatte zwar auch an die Änderung des Datentyps gedacht, aber war mir nicht sicher, ob es richtig verstanden wird. Ich werde aber auch im Profile nachschaeu, warum ich solche Voreinstellungen habe.
Gruss

Was Jens sagen wollte:

1. Deine Profilinformationen sind fehlerhaft. Jens glaubt nicht an eine Version ".2" so wie du es in deinem Profil angegeben hast. Also änder es am besten gleich auf die richtige LabVIEW Version um.

2. anstatt die *.DLL datei direkt hochzuladen kannst du diese auch in ein zip-archiv packen. dieses kannst du hier problemlos hochladen. alternativ kannst du die endung der *.dll datei umbenennen in *.txt (diese datei kannst du hochladen). derjenige der deine dll verwenden will, muss sie dann eben wieder zurück umbenennen.

Ja, ich denke so war das gemeint. ich glaube nciht, dass du dein profil so umstellen kannst, dass du dlls direkt hochladen kannst.

LG
Torsten

Anzeige

' schrieb:Ja, ich denke so war das gemeint. ich glaube nciht, dass du dein profil so umstellen kannst, dass du dlls direkt hochladen kannst.

Genauso isses gemeint (wobei dll-Datei eigentlich gehen sollte...).

Was hier an Dateiendungen hochgeladen werden darf oder nicht, dass kann nur forenweit der Admin (also Dennis) einstellen und nicht der User selbst.

Gruß, Jens

' schrieb:Danke, ich werde es mit dem DLL-Entwickler besprechen. Verstehe ich es richtig mit ENUM, dass man die Strings als reservierte Speicher ansehen kann (wie ByteArray) , wohin die Function etwas schreibt?

Nun ich weiss jetzt mal nicht wie die Funktion die Arrays zurückgibt. Grundsätzlich gibt es zwei Möglichkeiten die beide ihre Schattenseiten haben:

Erstens die DLL Funktion alloziert nichts selber sonderen erwartet dass das Array und die Pointer darin vom Aufrufer angelegt wird. Das ist wie man normalerweise in C mit Pointern umgeht. Der Aufrufer stellt den oder die Buffer in genügender Grösse zur Verfügung um der Funktion Raum zu geben um die Information hineinzuschreiben. Vorteil ist dass das Memory Handling eindeutig ist da der Aufrufer den Speicher anlegt und danach auch wieder freigibt. Nachteil ist, dass man entweder genau wissen muss wie gross die Buffer sind oder dass man den WorstCase abdecken muss der in den meisten Fällen viel zu viel Memory alloziert.

Zweitens kann die Funktion die Pointer innerhalb des zurückgegebenen Arrays selber anlegen. Vorteil ist dass nur soviel Speicher angelegt wird wie wirklich nötig ist. Nachteil ist dass die Speicherverwaltung nun an zwei Orten stattfindet, in der Funktion werden sie angelegt und der Aufrufer darf danach nicht vergessen um es alles wieder freizugeben.

Enumerierung der Strings hat nichts mit ENUM zu tun. Das sieht mehr in etwa so aus:

Die ursprüngliche Funktion:

[code]typedef struct {

' schrieb:Was Jens sagen wollte:

1. Deine Profilinformationen sind fehlerhaft. Jens glaubt nicht an eine Version ".2" so wie du es in deinem Profil angegeben hast. Also änder es am besten gleich auf die richtige LabVIEW Version um.

2. anstatt die *.DLL datei direkt hochzuladen kannst du diese auch in ein zip-archiv packen. dieses kannst du hier problemlos hochladen. alternativ kannst du die endung der *.dll datei umbenennen in *.txt (diese datei kannst du hochladen). derjenige der deine dll verwenden will, muss sie dann eben wieder zurück umbenennen.

Ja, ich denke so war das gemeint. ich glaube nciht, dass du dein profil so umstellen kannst, dass du dlls direkt hochladen kannst.

LG
Torsten

Ich wollte nur eine *.h Datei hochladen, um mein Problem besser darstellen zu können. Die DLL wäre dazu nicht unbedingt notwendig. Aus der Antwort von Rolfk sehe ich, dass das Problem auch ohne komplette *.h Datei erkannt war. Gewiss, konnte ich *.h in *.txt umbenennen...
Ach so, das steht .2 in meinem Profile? OK, das ändere ich ins 8.2 wie es sein muss. Danke !
LG

[quote='']Nun ich weiss jetzt mal nicht wie die Funktion die Arrays zurückgibt. Grundsätzlich gibt es zwei Möglichkeiten die beide ihre Schattenseiten haben:

Erstens die DLL Funktion alloziert nichts selber sonderen erwartet dass das Array und die Pointer darin vom Aufrufer angelegt wird. Das ist wie man normalerweise in C mit Pointern umgeht. Der Aufrufer stellt den oder die Buffer in genügender Grösse zur Verfügung um der Funktion Raum zu geben um die Information hineinzuschreiben. Vorteil ist dass das Memory Handling eindeutig ist da der Aufrufer den Speicher anlegt und danach auch wieder freigibt. Nachteil ist, dass man entweder genau wissen muss wie gross die Buffer sind oder dass man den WorstCase abdecken muss der in den meisten Fällen viel zu viel Memory alloziert.

Zweitens kann die Funktion die Pointer innerhalb des zurückgegebenen Arrays selber anlegen. Vorteil ist dass nur soviel Speicher angelegt wird wie wirklich nötig ist. Nachteil ist dass die Speicherverwaltung nun an zwei Orten stattfindet, in der Funktion werden sie angelegt und der Aufrufer darf danach nicht vergessen um es alles wieder freizugeben.

Enumerierung der Strings hat nichts mit ENUM zu tun. Das sieht mehr in etwa so aus:

Die ursprüngliche Funktion:

[code]typedef struct {