(08.05.2012 09:41 )hawk72 schrieb: Danke erstmal für die Antwort,
ich habe gestern die Sache nochmal durchgetestet, untestützt durch einen C++ Spezi.
Leider sind wir zu keinem Ergebniss gekommen da die
"DeviceInfo" struktur als array[16] zwingend angelegt werden muss und nun hat es eher dort "geklemmt".
Die DeviceData Struktur greift dann auf das in der DeviceInfo Struktur hinterlegte Gerät zu.
"Die Deklaration der Datenstruktur/des Datenarrays für die max. 16 zu verwaltenden Geräte sieht folgendermaßen aus.
t_DeviceInfo myDeviceInfo[16];
Diese muss vom aufrufenden Programm intern angelegt werden. Der Zeiger auf diese Datenstruktur bzw. das Datenarray wird jeweils übergeben."
Wir haben nun verschiedenste Möglichkeiten durchgetestet um die
Deviceinfo - Struktur in LV abzubilden aber ohne Erfolg
DWORD idx; // USB-Geraete-Index
int open; // Zustand -> Open=1 / Close=0
char vid_pid[256]; // VID/PID-String
char dev_info[256]; // GeraeteInfo-String
char sn_info[256]; // S/N-String
int hw_info; // HW-Info (5xxx)
unsigned char hw_var; // HW-Variante
int fw_vers; // FW-Version
Angefangen haben wir mit einem Array mit Cluster (int32,int32,(String array[256],String array[256],String array[256],String array[256]),int32,U8,Int32))
Wobei der C-Spezi sich bei der DWORD und Char Sache nicht ganz sicher war.
Müßten es nicht 3 dummy filler chars sein beim U8 der DeviceData Struktur und auch hier?
Sind wir auf dem richtigen Weg oder müßten wir die String-Array eventuell als Stringcluster umsetzen?
Grüße Norbert
Also DWORD ist ein unsigned long was unter Windwos immer ein unsigned 32 Bit integer ist.
Ob dort drei Fillerbytes kommen oder nicht ist nicht sicher zu sagen ohne die komplete Header Datei zu sehen, und eventuel sogar das Makefile.
Microsoft Visual C benützt default 8 Byte Alignment was heissen würde, dass das letzte int tatsächlich auf 4 Byte aligned würde, aber das kann man mit #pragma pack(x) Preprocessordirektiven im Code ändern und das Defaultalignment lässt sich auch als Commandlineparameter zum C Compiler abänderen, was dann im Makefile oder Projekt sichtbar wäre.
Zu guter letzt Dein C Spezialist sollte wissen, dass fixed-size Arrays innerhalb einer Struktur inlined sind und absolut nicht dasselbe als ein Arraypointer. Und LabVIEW kennt keine entsprechenden fixed-size Arrays (nun es kennt sie schon aber nur für die FPGA Umgebung) also kann man nicht einfach einen LabVIEW String in einen Cluster setzen und hoffen dass das schon gut geht. Das ginge nicht einmal wenn die Struktur dort einen Stringpointer erwartet, denn LabVIEW String ist nicht gleich C String Pointer.
Anstelle davon muss man den fixed-size Array (String) durch einen Cluster mit entsprechender Anzahl kompatibler Elemente nachbilden, also in diesem Fall je 256 U8 Integern.
Persönliche erachte ich es einfacher um auszurechnen wieviele Bytes diese Struktur belegt (alignment Fillerbytes nicht vergessen), dann mit der Anzahl der Strukturelemente im Array multiplizieren und dies dann als Bytearray anzulegen und so an die Funktion zu übergeben. Nach dem Aufruf kann man dann die Daten aus dem Array herausklauben. Mühselig ja, und die beste Variante ist dann auch, um eine Wrapper DLL in C zu schreiben die das Ganze von diesen C Strukturen in LabVIEW freundlichere Datentypen umsetzt. Vorausgesezt dass man genug C kennt, um eine solche Wrapper DLL zu machen ist das die einfachste und auf lange Frist am besten unterhaltbare Variante. Und wenn man nicht genug C Kenntnisse hat um eine solche Wrapper DLL zu machen ist man eigentlich schon zum vorneherein zum Scheitern verurteilt um das auch ohne Wrapper DLL ganz im LabVIEW Diagramm zu machen.