DLL- Datentypen nicht in LabVIEW vorhanden

(09.05.2011 14:52 )rolfk schrieb:  Also im ursprünglichen C Code kommen die TCanFlags vor den TCanData. Also scheint mir da noch was falsch.

Oh, das hab ich irgendwie vertauscht. Ich habs jetzt richtig gestellt.

(09.05.2011 14:52 )rolfk schrieb:  Dann sollte man natürlich noch sicher sein dass die Structure by Reference übergeben wird, also als Pointer und nicht etwa by Value.

Will sagen der Functionsprototype sollte irgendwie so aussehen: something FunctionsName(..., TCanMeg *msg, ...);

So sieht mein Prototyp auch aus:
int32_t CanTransmit(uint32_t index, void *msg, int32_t count);

Dabei wird die msg scheinbar immer als pointer übergeben, unabhängig davon ob ich Handles by Value, Pointers to handles oder Array Data Pointer auswähle. Array Data Pointer scheidet wohl aus. Aber mit keiner Einstellung scheint es zu gehen...

(10.05.2011 10:22 )jak888 schrieb:  So sieht mein Prototyp auch aus:
int32_t CanTransmit(uint32_t index, void *msg, int32_t count);

Dabei wird die msg scheinbar immer als pointer übergeben, unabhängig davon ob ich Handles by Value, Pointers to handles oder Array Data Pointer auswähle. Array Data Pointer scheidet wohl aus. Aber mit keiner Einstellung scheint es zu gehen...

void * ist nicht gerade sehr deutlich. Gemäss C kann das so ein bischen alles sein. Aber gut nehmen wir an dass damit eigentlich TCanMsg *msg gemeint ist, was auch wahrscheinlich ist.

Wenn Du Adapt to Type machst, stellt sich LabVIEW automatisch auf den angeschlossenen Datentyp ein. Die Parameter Pointer to Handles oder Handles by Value sind dabei relevant wenn Du einen LabVIEW Handle Datentyp anschliesst, also einen String oder ein Array. Bei einem Cluster sind die irrelevant. Von der Call Library Node und dem Datencluster scheint nun alles in Ordnung zu sein. Wenns noch immer nicht funktioniert, kanns an ein paar Dingen liegen:

1) Einer der anderen Parameter zu der Funktion ist falsch
2) msg ist nicht wirklich eine TCanMsg structure, sondern etwas anderes. Da es als void Pointer deklariert ist gibt es keinerlei Weise das zu befestigen oder auszuschliessen. Das muss man aus der Dokumentation der Funktion herauslesen/raten/vermuten oder was auch immer.
3) Ein anderer Fehler verhindert dass diese Funktion gut ausgeführt werden kann.

Hallo,

nachdem ich ausgiebig an dem Thema weitergeforscht habe und auch noch mehrfach mit dem Hersteller Kontakt aufgenommen habe, hat sich dieser dazu bereit erklärt eine entsprechende LabVIEW kompatible Wrapper.dll zu schreiben. Nachdem der Hersteller diese fertig gestellt hatte, hat er die DLL in LabVIEW importiert, wobei ich auch nicht weiß wie, woraufhin LabVIEW ein SubVI für jede der DLL Funktionen erstellt hat.
Er hat den Teil, der für mich am wichtigsten war- nämlich das Senden von Can Messages- getestet. Der Teil hat bei ihm auch funktioniert.

Nun habe ich daraus zwar neue Hoffnung geschöpft, aber das Problem, dass nichts funktioniert, besteht weiterhin. Dabei drängt sich Frage natürlich auf: Warum?

Wenn ich den primitivsten Aufbau eines Programmes fahre, also Gerät öffnen und eine Nachricht senden, bekomme ich bei der Ausführung der CanTransmit Funktion folgende Fehlermeldung:

Error 1097 occurred at Call Library Function Node in labtcan.lvlib:LV Can Device Open.vi->Main.vi
Possible reason(s):

LabVIEW: An exception occurred within the external code called by a Call Library Function Node. The exception might have corrupted the LabVIEW memory. Save any work to a new location and restart LabVIEW.

Nun habe ich versucht den Programmordner zu verschieben, alles mittels save as... woanders hin zu sichern und auch einfach ein komplett neues Projekt anzufangen. Leider blieb alles ohne erfolg, der Fehler tritt weiterhin auf. Hat jemand eine Idee, wie ich das problem lösen könnte, bzw. was der Hersteller anders macht als ich?

Beste Grüße

So,

ich bin jetzt endlich mit dem Problem weitergekommen:

Ich bin davon ausgegangen, dass die LV Version des Herstellers eine andere war als meine. Er hat mir gegenüber einmal erwähnt, dass er mit LV wenig am Hut hätte, also wer weiß, woher er auf einmal die LV Version bekommen hatte. Ich nehme an, dass dadurch Kompatibilitätsprobleme entstanden sind.

Jedenfalls habe ich mein Problem wie folgt gelöst: Ich habe nicht die mitgelieferten VIs verwendet, sondern selbst neue VIs erstellt. Nachdem ich die wichtigsten VIs von Hand erstellt hatte, habe ich sie in einem Programm getestet und sie scheinen zu funktionieren. Genaueres kann ich aber vermutlich erst nächste Woche sagen, wenn ich wieder mit meinem geliebten MSO 4104B vereint bin.

Ich meld mich nochmal, wenn ich Software habe.

kann mir vielleicht trotzdem nochmal jemand erklären, wie man beim importieren von dlls gleich die SubVIs miterstellen lassen kann?

(23.05.2011 16:23 )jak888 schrieb:  kann mir vielleicht trotzdem nochmal jemand erklären, wie man beim importieren von dlls gleich die SubVIs miterstellen lassen kann?

Tools->Import->Shared Library (DLL).

Dieses Tool benötigt ein C Header File als Input. Es funktioniert gut für einfache Header Files mit nicht zu komplexen Funktionen und Datentypen, stolpert aber über einige komplexe C Deklarationen wie sie beispielsweise in den Standard WINAPI SDK Headers vorkommen und kann mit Funktionspointern überhaupt nicht umgehen, aber das ist durch die Call Library Node eh nicht unterstützt.