PeakCAN-BasicAPI.dll in LV einbinden

wunderschönen Abend,

einen PeakCAN-USB-Dongle möchte ich über die PCAN-BasicAPI.dll aus LabView ansprechen. Zum Initializieren eines USB-Kanals rufe die Funktion CAN-Initialize der dll auf und stelle die Parameter entsprechend der API-Doku ein.:

C++:

Code:

TPCANStatus __stdcall CAN_Initialize(
        TPCANHandle Channel,
        TPCANBaudrate Btr0Btr1,
        TPCANType HwType = 0,
        DWORD IOPort = 0,
        WORD Interrupt = 0
);

Wobei die letzten drei Parameter optional sind und bei USB nicht verwendet werden.

Delphi:

Code:

class function Initialize(
    Channel: TPCANHandle;
    Btr0Btr1: TPCANBaudrate
    ): TPCANStatus; overload; static;

Dabei erscheint am Ausgangs-Fehler-Cluster immer der Fehelercode x5ED bzw. d1517. Ich verwende die Standart WinAPi-Aufrufkonvention. Wenn ich die Fehlerprüfung der dll ausschalte stürtzt mir LabView ab. Prof. Google konnte mir zu diesem Fehlercode auch nicht viel sagen, außer dass es möglicherweise irgendwie mit der WinAPI zusammen hängt

   

Kann mir bitte jemand sagen wie dieser Fehler zu stande kommt und wie ich ihn vermeiden kann? Vielen Dank.

schöne Grüße
Stefan

Anzeige

(14.11.2012 17:50 )SchwindelInside schrieb:  wunderschönen Abend,

einen PeakCAN-USB-Dongle möchte ich über die PCAN-BasicAPI.dll aus LabView ansprechen. Zum Initializieren eines USB-Kanals rufe die Funktion CAN-Initialize der dll auf und stelle die Parameter entsprechend der API-Doku ein.:

C++:

Code:

TPCANStatus __stdcall CAN_Initialize(
        TPCANHandle Channel,
        TPCANBaudrate Btr0Btr1,
        TPCANType HwType = 0,
        DWORD IOPort = 0,
        WORD Interrupt = 0
);

Wobei die letzten drei Parameter optional sind und bei USB nicht verwendet werden.

Delphi:

Code:

class function Initialize(
    Channel: TPCANHandle;
    Btr0Btr1: TPCANBaudrate
    ): TPCANStatus; overload; static;

Dabei erscheint am Ausgangs-Fehler-Cluster immer der Fehelercode x5ED bzw. d1517. Ich verwende die Standart WinAPi-Aufrufkonvention. Wenn ich die Fehlerprüfung der dll ausschalte stürtzt mir LabView ab. Prof. Google konnte mir zu diesem Fehlercode auch nicht viel sagen, außer dass es möglicherweise irgendwie mit der WinAPI zusammen hängt



Kann mir bitte jemand sagen wie dieser Fehler zu stande kommt und wie ich ihn vermeiden kann? Vielen Dank.

schöne Grüße
Stefan

Standard C kennt KEINE optionalen Funktionsparameter und das DLL Interface folgt Standard C Konventionen und nicht C++ oder Delphi Konventionen wo Parameter mit Defaultwerten deklariert werden können. Das bedeutet dass Du doch echt alle 5 Parameter konfigurieren musst und den "optionelen" Parametern exlplizit den Defaultwert zuweisen musst.

Der Umstand dass die Funktion stdcall ist macht eine variable Anzahl Parameter sowieso vollkommen unmöglich, da der Aufrufer die Parameter auf den Stack schiebt, aber die Funktion den Stack anschliessend korrigiert.

Inwiefern die Datentypen korrekt sind kann ich nicht sagen, da die Deklaration von TPCANStatus, TPCANHandle usw. nirgends aus Deinem Post ersichtlich ist.

Hallo RolfK,

Vielen Dank für die Antwort. Das war wohl der Fehler. Hab die zusätzlichen eingänge alle auf 0 gesetzt und siehe da, der Fehler ist verschwunden. Und wieder was gelernt dabei.

(14.11.2012 22:36 )rolfk schrieb:  Standard C kennt KEINE optionalen Funktionsparameter und das DLL Interface folgt Standard C Konventionen und nicht C++ oder Delphi Konventionen wo Parameter mit Defaultwerten deklariert werden können. Das bedeutet dass Du doch echt alle 5 Parameter konfigurieren musst und den "optionelen" Parametern exlplizit den Defaultwert zuweisen musst.

Der Umstand dass die Funktion stdcall ist macht eine variable Anzahl Parameter sowieso vollkommen unmöglich, da der Aufrufer die Parameter auf den Stack schiebt, aber die Funktion den Stack anschliessend korrigiert.

Das wusste ich bis jetzt noch nicht. In der API-Dokumentation sind auch nur Einbindungen für objektorientierte Sprachen, wie C++, C#, Delphi, VBasic und Python aufgeführt aber keine in ANSI-C.

Zitat:Inwiefern die Datentypen korrekt sind kann ich nicht sagen, da die Deklaration von TPCANStatus, TPCANHandle usw. nirgends aus Deinem Post ersichtlich ist.

TPCANStatus ist ein BYTE-enum und und TPCANHandle ein DWORD-enum. Die Initialisierung des USB-Kanals schien aber bereits korrekt funktioniert zu haben, wie die PCANStatus-Ausgabe "PCAN_ERROR_OK" im Bild zeigt.

viele Grüße
Stefan

(15.11.2012 12:31 )SchwindelInside schrieb:  TPCANStatus ist ein BYTE-enum und und TPCANHandle ein DWORD-enum. Die Initialisierung des USB-Kanals schien aber bereits korrekt funktioniert zu haben, wie die PCANStatus-Ausgabe "PCAN_ERROR_OK" im Bild zeigt.

Nun diese Erklärung ist aber in schrillem Gegensatz zum Diagramm in Deinem ersten Post. Dort hast Du den Rückgabewert als U32 konfiguriert und das Handle als U8. Ein Byte-Enum ist aber ein U8 und ein DWORD ein U32. Also doch noch mal schauen?

Auch noch schauen ob TPCANBaudrate echt ein 16 Bit Integer ist!

Ich hab von denen VIs bekommen, die besagte dll aufrufen ... da war alles schon fertig - mit Beispielen (die waren sogar fast OK).
Vielleicht einfach mal nachfragen.

Beste Grüße

Hallöle,

Hab da nur beim Tippen was durcheinander verwechselt.

(15.11.2012 15:14 )rolfk schrieb:  

(15.11.2012 12:31 )SchwindelInside schrieb:  TPCANStatus ist ein BYTE-enum und und TPCANHandle ein DWORD-enum. Die Initialisierung des USB-Kanals schien aber bereits korrekt funktioniert zu haben, wie die PCANStatus-Ausgabe "PCAN_ERROR_OK" im Bild zeigt.

Nun diese Erklärung ist aber in schrillem Gegensatz zum Diagramm in Deinem ersten Post. Dort hast Du den Rückgabewert als U32 konfiguriert und das Handle als U8. Ein Byte-Enum ist aber ein U8 und ein DWORD ein U32. Also doch noch mal schauen?

Auch noch schauen ob TPCANBaudrate echt ein 16 Bit Integer ist!

TPCANStatus ist ein DWORD-Ring, TPCANHandle ein BYTE-Ring und TPCANBaudrate tatsächlich ein WORD-Ring. In der API-Doku werden sie als enums bezeichnet, da es unter anderm in den .Net-Sprachen die Unterscheidung zwischen Enum und Ring wie in Labview anscheinend nicht gibt. Die DLL-Einbindung war aber wohl korrekt.
Ein 16-Bit-Int finde ich eigentlich zeimlich angemessen um Baudraten in kBit/s bis max 1MBit/s anzugeben. Was würdes Du denn dafür nehmen?

Grüße
SI

Anzeige

(16.11.2012 14:55 )SchwindelInside schrieb:  Hallöle,

Hab da nur beim Tippen was durcheinander verwechselt.

(15.11.2012 15:14 )rolfk schrieb:  

(15.11.2012 12:31 )SchwindelInside schrieb:  TPCANStatus ist ein BYTE-enum und und TPCANHandle ein DWORD-enum. Die Initialisierung des USB-Kanals schien aber bereits korrekt funktioniert zu haben, wie die PCANStatus-Ausgabe "PCAN_ERROR_OK" im Bild zeigt.

Nun diese Erklärung ist aber in schrillem Gegensatz zum Diagramm in Deinem ersten Post. Dort hast Du den Rückgabewert als U32 konfiguriert und das Handle als U8. Ein Byte-Enum ist aber ein U8 und ein DWORD ein U32. Also doch noch mal schauen?

Auch noch schauen ob TPCANBaudrate echt ein 16 Bit Integer ist!

TPCANStatus ist ein DWORD-Ring, TPCANHandle ein BYTE-Ring und TPCANBaudrate tatsächlich ein WORD-Ring. In der API-Doku werden sie als enums bezeichnet, da es unter anderm in den .Net-Sprachen die Unterscheidung zwischen Enum und Ring wie in Labview anscheinend nicht gibt. Die DLL-Einbindung war aber wohl korrekt.
Ein 16-Bit-Int finde ich eigentlich zeimlich angemessen um Baudraten in kBit/s bis max 1MBit/s anzugeben. Was würdes Du denn dafür nehmen?

Grüße
SI

Also einmal is TPCANStatus ein Byte-enum und dann ist's ein DWORD-Ring. Irgendwie musst Du Dich entscheiden! :-)
16 Bit is zwar genügend für Baudrate aber es spart überhaupt nichts ob man jetzt ein 16 bit oder ein 32 bit Integer nimmt. Zudem ersceint mir die Verwendung eines Enums hier eher unsinnig es sei den man definiert ihn so dass er nur die diskret möglichen Werte enumeriert aber dann würde ein 8bit Wert auch noch lange genügen.
Persönlich tendiere ich dazu um bei eigenen APIs meist 32 bit Integerparameter zu vewenden, da alle Parameter eh immer als 32 Bit Werte über den Stack übergeben werden.