LabVIEW
tchar nicht definiert bei DLL Einbindung
Meine Kristallkugel ist leider noch immer defekt!! Ich habe absolut keine Idee, wie diese Funktion aussieht und noch viel weniger eine Beschreibung dazu gelesen. Minimal den Prototypen müsste man halt schon kennen und meist ist das nur eingeschränkt genügend, und muss man auch eine Beschreibung der Funktion von dem Programmierer haben. Der C Prototyp teilt einem oft bei weitem nicht genug mit.
Dieser Header ist zwar schon etwas aber grundsätzlich nicht genügend um ihn in welcher Form dann auch (ja auch von einem C Programm aus) ohne viel Trial und Error anzusprechen. Und damit meine ich Trial and Error das im Error Fall meist brutal crasht.
Ein paar Beispiele:
- Der TCHAR Typ wie schon eher erwähnt ist völlig undefiniert. Nirgends ist ersichtlich dass er von den Windows API Headern importiert wird noch mit welchen Define er evaluiert werden sollte.
- Der int Rückgabewert der Funktionen ist nirgends dargelegt. Ist das eine Zahl die 0 ist im Erfolgsfall und alles andere ist ein Errorcode, oder ist es gerade so dass ungleich 0 Erfolg angibt und 0 einen Fehler oder ist es noch irgendwas anderes?
- Es gibt auch noch etliche andere Dinge die zwar für jemanden mit Erfahrung in diesem Bereich mit etwas Vermuten ziemlich sicher herzuleiten sind, aber ohne Erfahrung ganz schön in die Hosen gehen kann.
Mir scheint es dass hier ein Hardwarehersteller (Testo) gerne einen LabVIEW Treiber für ihr Gerät mit DLL Treiber haben möchte aber es unsinnig erachtet um da jemanden mit Verstand von LabVIEW UND C drauf anzusetzen. Das Resultat solcher Treiber ist grundsätzlich immer dasselbe: Macht sich gut im Verkaufskatalog des Gerätes aber der Kunde der das Gerät unter anderem wegen diesem Treiber kauft wird wahrscheinlich niemals mehr ein Gerät bei diesem Hersteller kaufen und eventuel in verschiedenen Foren um Support fragen weil der Treiber manchmal/oft/immer komische Dinge tut, wie abstürzen und dann auch noch laut verkünden dass sowohl LabVIEW als auch der entsprechende Gerätetreiber nur Müll sind.
Nun wenn Du ein bestehendes Programm hast das einmal zuverlässig läuft ist es grundsätlich so dass das immer laufen msollte. Aber:
LabVIEW VIs sind dazu da um selber Programme zu schreiben. Und auch der erfahrenste Programmierer kann nicht alle möglichen Anwendungsfälle von späteren Benützern antizipieren und testen. Bei gebastelten Treibern führt das aber schnell mal dazu dass es dann plötzlich doch crasht da bestimmte Funktionen mit Parametern aufgerufen werden die unsinnig sind. Bei einem sauber programmierten Treiber hingegen sind solche Dinge abgefangen und verursachen eine (hoffentlich) sinnvolle Laufzeitfehlermeldung (in LabVIEW typischerweise in einem Errorcluster) die dem Benützer einen Hinweis gibt über den aufgetretenen Fehler, aber ohne das LabVIEW Programm ins Land der Exceptions (crash) zu beförderen.
Dieser Treiber ist vom Interface an sich noch einer der einfacheren (obwohl ich mal davon ausgehe dass das Komplizierte eigentlich noch kommen muss, nämlich welche Datenbytes mit Read und Write übertragen werden) aber die ganze Headersammlung in Deinem Post macht das Ganze schon extrem kompliziert. Scheinbar hat dieses Gerät mindestens 3 verschiedene Interfaces die alle verschiedenen APIs haben und Du hast Dich hier auf das USB Interface beschränkt. Ist es vorgesehen um die anderen Interfaces auch noch anzusprechen?
Was ist überhaupt das Ziel dieses Projekts? Muss das ein schneller Job sein für die Verwendung innerhalb des Betriebes, etwa zum Erstellen eines Testprogramms in der Fertigung, oder soll das ein Treiber werden für Benützung durch Kunden?
Im ersten Fall kann man mit Gebastel auskommen, da ja der Testingenieur innerhalb des Betriebes ist und nur er sich die Haare ausraufen muss, wenn das Ganze wieder mal crasht, aber im zweiten Fall ist gar kein Treiber besser als ein gebastelter!
@Fabi_testo wrote:
Ja das wurde mir anfangs auch gesagt, dass es höchstwahrscheinlich komplizierter sein wird. Und das ist nun der Fall.
Im Prinzip beinhaltet dieses TESTOEMUSB alle Header Files. Das heißt alle werden angesprochen.
Im Endeffekt sollte es so aussehen, dass im Hintergrund folgendes abgespielt wird während der Benutzer auf Start drückt:
1. Anzahl der angeschlossenen Geräte erkennen
2. Serialnumber erhalten
3. Aus dieser Serialnumber eine DeviceID erhalten (DeviceID ist für alle weiteren Vorgänge unabdingbar)
Das alles sollte im Hintergrund stattfinden, so dass der Benutzder nur auf Start drückt, und letztendlich die Messdaten vor sich sehen kann.
Das ganze Projekt ist für den Kunden gedacht, da eine hohe Anfrage kam ob es nicht möglich wäre, dieses Gerät mit LabVIEW auszulesen.
Grüße
Fabian
Das was Du in Punk 1 - 3 beschreibst ist grundsätzlich nicht so schwierig zu machen aber ohne etwas C Kenntnisse dürfte es doch sehr mühsam werden. Der nicht nummerierte Punkt 4 ist aber da wo ohnehin noch sehr viel Arbeit reingesteckt werden muss auch wenn das mit einem funktionierenden Treiber für die DLL vollständig in LabVIEW gemacht werden kann. Punkt 1 - 3 könnte ich tun aber der Rest ist nicht sinnvoll realisierbar da das nur mit verfügbarer Hardware und entsprechender Dokumentation der Protokolldaten machbar ist die mit der Read und Write Funktion übertragen werden.
Ein echter LabVIEW Treiber der alle USB Funktionen der DLL verfügbar macht würde mich vielleicht einen Tag Arbeit kosten. Danach kannst Du aber je nach Komplexität der Bytestruktur für die Datenübertragung nochmals etliche Tage investieren um die eigentlich Protokollimplementation zu realisieren.
