LabVIEWForum.de

Hallo,

würde gerne eine CAN Karte von Vector Informatik verwenden und diese unter LabVIEW 8.0 anpsrechen. Dazu kann man sich enteder eine ("teure") Freischaltung kaufen, oder man nutzt den XL Treiber (siehe http://www.vector-worldwide.com/downloads/...rs/xl_lib64.zip ) in Form einer DLL Datei. Ein paar Aufrufe bekomem ich mittels des Call Library Function Node auch hin (siehe Screenshot), bei anderen scheitere ich aber hoffnungslos. Dies ist u.a. bei allen Aufrufen die structs (z.B. xlGetDriverConfig) erwarten und dynamische Rückgabegrößen haben der Fall.
Hier im Forum habe ich bereits Beispiele für ältere Versionen (mit ncdXXXX Aufrufen) gefunden, für die habe ich jedoch keine Beschreibung der API und weiß nicht was als Parameter erwartet wird u.ä.
Hat sich evtl. schon mal jemand an einer neuen Version probiert? Bräuchte erstmal "nur" Kommunikation via CAN. Beispiele zu structs und/oder Platzhaltern für Rückgabewerte würden mir auch schon weiterhelfen.
Falls da noch jemand etwas probiert: evtl. kann man ja mal ein Beispiel gemeinsam erarbeiten.

Gruß und danke,

Robert

Für solche Sachen soll es auf jeden Fall eine Dokumentation von Vector geben, such mal danach, ansonsten wäre diese Lib unbrauchbar.

eg

' schrieb:Für solche Sachen soll es auf jeden Fall eine Dokumentation von Vector geben, such mal danach, ansonsten wäre diese Lib unbrauchbar.

eg

Hi,

???
Für "meine" Version habe ich eine Dokumentation, passend zur DLL Datei, bzw. die stellt Vector zur Verfügung. Ihre eigenen VIs wollen sie aber (verständlicherweise) verkaufen, insofern gibt es "nur" eine DLL mit Doku die die Funktionen beschreibt (siehe Link im ersten Posting). Dort ist jede Funktion mit Parametern und Rückgabewerten beschrieben. Zu den Versionen die hier im Forum sind, fehlt mir die. Dort habe ich dann eine "nackte" DLL und entsprechende VIs die aus der DLL einige (also längst nicht alle) Funktionen aufrufen. Sicher, einiges bekomme ich über die Namen raus und kann ich mir denken...
Problem: die Beispiele hier aus dem Forum laufen bei mir X Minuten stabil durch, aber nicht 24h (über Nacht). Dann stehen die Programme, bzw. die CAN Nachrichten werden nicht mehr von LV empfangen (CAN läuft weiter). Deshalb würde ich gerne die aktuelle DLL verwenden, um Fehler in irgend einer alten Version auszuschließen.
Das hier http://www.LabVIEWforum.de/index.php?act=a...st&id=32365 hat mich aber auch schon weitergebracht, werde das mal anders probieren...

Robert

' schrieb:Hi,

???
Für "meine" Version habe ich eine Dokumentation, passend zur DLL Datei, bzw. die stellt Vector zur Verfügung. Ihre eigenen VIs wollen sie aber (verständlicherweise) verkaufen, insofern gibt es "nur" eine DLL mit Doku die die Funktionen beschreibt (siehe Link im ersten Posting). Dort ist jede Funktion mit Parametern und Rückgabewerten beschrieben. Zu den Versionen die hier im Forum sind, fehlt mir die. Dort habe ich dann eine "nackte" DLL und entsprechende VIs die aus der DLL einige (also längst nicht alle) Funktionen aufrufen. Sicher, einiges bekomme ich über die Namen raus und kann ich mir denken...
Problem: die Beispiele hier aus dem Forum laufen bei mir X Minuten stabil durch, aber nicht 24h (über Nacht). Dann stehen die Programme, bzw. die CAN Nachrichten werden nicht mehr von LV empfangen (CAN läuft weiter). Deshalb würde ich gerne die aktuelle DLL verwenden, um Fehler in irgend einer alten Version auszuschließen.
Das hier http://www.LabVIEWforum.de/index.php?act=a...st&id=32365 hat mich aber auch schon weitergebracht, werde das mal anders probieren...

Robert

Wieviel Geld will denn Vektor sehen und wieviel Geld ist eine Programmierstunde von Dir wert? Wenn ich so sehe mit was für Problemen Du kämpfst und das wahrscheinlich nachdem Du das DLL Tutorial von IchSelbst schon gelesen hast, denke ich mal dass die Library von Vektor eigentlich in jedem Fall ein Schnäppchen sein müsste.

Rolf Kalbermatter

' schrieb:Wieviel Geld will denn Vektor sehen und wieviel Geld ist eine Programmierstunde von Dir wert? Wenn ich so sehe mit was für Problemen Du kämpfst und das wahrscheinlich nachdem Du das DLL Tutorial von IchSelbst schon gelesen hast, denke ich mal dass die Library von Vektor eigentlich in jedem Fall ein Schnäppchen sein müsste.

Rolf Kalbermatter

Hallo Rolf,

Kostenpunkt liegt bei ca. 600€, sofern die Vector Lösung verwendet wird. Meine Programmierstunden kosten "nichts", da das ganze nebenbei läuft und als "Pausenfüller" dient...
Das DLL Tutorial hat mir sehr zur Einführung geholfen, es geht jedoch (meiner Meinung nach) zu wenig auf reale Bedingungen ein. Der Aufruf und Übergabe von "einfachen" Datentypen, Strings und Pointern ist ja kein Problem und läuft einwandfrei, auch bei unterschiedlichsten Datentypen und Mischung Pointer/Wert (ist ja letztendlich nur die Auswahl eines anderen Feldes/Kästchens in LabVIEW). In der realen Welt werden aber nunmal gerne structs verwendet (das bekomme ich auch noch hin), oder "gemeinerweise" halt auch gerne Zeiger auf structs (die wiederrum structs enthalten) und structs mit unterschiedlichsten Datentypen...
Ein Beispiel mit Rückgabe eines Zeigers auf ein struct mit unterschiedlichen Datentypen fehlt in dem Tutorial halt völlig. Dort wird unter 4.5.2 einfach davon ausgegangen, dass alles ein Datentyp ist und somit ein Array verwendet werden kann. Das dieser Trick funktioniert ist mir soweit auch klar (und warum er funktioniert). Praxis sieht nur leider anders aus...

Gruß,

Robert

P.S. Der Anhang lässt LV komplett abstürzen (wird natürlich erst nachdem der Treiber erfolgreich geladen wurde ausgeführt)

erledigt

Hatte eine "falsche" DLL verwendet (ältere Version), da ich ständig welche umkopiert und ausprobiert hatte. ARGH....

' schrieb:oder "gemeinerweise" halt auch gerne Zeiger auf structs (die wiederrum structs enthalten) und structs mit unterschiedlichsten Datentypen...

Haste mal ein Muster?

' schrieb:Haste mal ein Muster?

Moin,

genaue Konvention verbirgt sich in einem PDF das in obigem Link enthalten ist. Ein Beispiel daraus wäre z.B.

XLstatus xlGetDriverConfig(XLdriverConfig *pDriverConfig)

typedef struct s_xl_driver_config {
unsigned int dllVersion;
unsigned int channelCount;
unsigned int reserved[10];
XLchannelConfig channel[XL_CONFIG_MAX_CHANNELS];
} XLdriverConfig;


typedef struct s_xl_channel_config {
char name [XL_MAX_LENGTH + 1];
unsigned char hwType;
unsigned char hwIndex;
unsigned char hwChannel;
unsigned short transceiverType;
unsigned int transceiverState;
unsigned char channelIndex;
User manual
XLuint64 channelMask;
unsigned int channelCapabilities;
unsigned int channelBusCapabilities;
unsigned char isOnBus;
unsigned int connectedBusType;
XLbusParams busParams;
unsigned int driverVersion;
unsigned int interfaceVersion;
unsigned int raw_data[10];
unsigned int serialNumber;
unsigned int articleNumber;
char transceiverName [XL_MAX_LENGTH + 1];
unsigned int specialCabFlags;
unsigned int dominantTimeout;
unsigned int reserved[8];
}
XLchannelConfig;

typedef struct {
unsigned int busType;
union {
struct {
unsigned int bitRate;
unsigned char sjw;
unsigned char tseg1;
unsigned char tseg2;
unsigned char sam;
unsigned char outputMode;
}
can;
unsigned char raw[32];
}
data;
}
XLbusParams;

Da man aber die Gesamtanzahl an Bytes kennt, hole ich mir nun ein Byte Array (vgl. letztes Bild) und fummel dann z.B. jeweils 4Bytes zu einem int zusammen. Diese Datentypen verpacke ich dann in einem Cluster und gebe sie zurück.
Das obige Beispiel geht auch noch tiefer verschachtelt und mit Pointer dazwischen ;=) Da muss ich aber erst mal schauen ob das noch mit LV geht...

Gruß,

Robert

' schrieb:Da man aber die Gesamtanzahl an Bytes kennt, hole ich mir nun ein Byte Array (vgl. letztes Bild) und fummel dann z.B. jeweils 4Bytes zu einem int zusammen.

Im Prinzip genau so.

Zitat:und mit Pointer dazwischen ;=) Da muss ich aber erst mal schauen ob das noch mit LV geht...

Eigentlich nicht. Es sei denn so: Aus 4 Bytes den Pointer machen. Der Pointer wird dem MoveBlock-VI, das hier auch irgendwo angesprochen wurde, übergeben. Dieses VI holt den Zielspeicher wieder per Array, das dann wieder umgefummelt werden muss. Usw.

[*guck*]

Union-Strukt. Hmm. Auch das geht. Macht aus einem Array drei Cluster.

Schau mer mal, ob ich das übernehmen kann.

' schrieb:Eigentlich nicht. Es sei denn so: Aus 4 Bytes den Pointer machen. Der Pointer wird dem MoveBlock-VI, das hier auch irgendwo angesprochen wurde, übergeben. Dieses VI holt den Zielspeicher wieder per Array, das dann wieder umgefummelt werden muss. Usw.

Wieso nicht? Genauso habe ich es vor. Die Adresse liefert mir die DLL zurück. Für die 32-Bit Versionen ist die halt 32 Bit lang, für 64 Bit dementsprechend. Aber das könnte man auch hardcodieren. Solange ich weiß wieviele Bytes ich ab der Adresse lesen soll/muss, gebe ich die Anzahl an Bytes und die Adresse an dei Move Funktion und die besorgt mir dann den Inhalt. Sollte (von der Theorie zumindest) ohne Probleme machbar sein. Gibt jetzt (leider) erst mal was anderes zu tun, war gerade so schön dabei...

Für dein Tutorial: mach in die DLL ein Struct mit diversen Datentypen, evtl. auch struct im struct (oder noch mit einem union gewürzt) und mach aus den einzelnen Bytes halt wieder die Datentypen, verpack die in einen Cluster und gut ist. Eigentlich simpel (wenn man weiß wie) ;=)

Gruß,

Robert

P.S. kleines Problem habe ich noch bei anderen Stucts: Strings dürfen dort bis zu 200 Zeichen lang sein, aber auch entsprechend kürzer. Dumm nur, wenn man über Array Subset 200 Bytes abschneidet und die dann mit Byte Array to String umwandelt... Aber da sollte man auch die "Nullterminierung" des Strings im Bytearray vorher finden können.