IO-Warrior x64 Library & C#: Programme funktionieren nicht

[Palmm130]

Hallo,
ich programmiere derzeit mit dem IO-Warrior24, welchen wir in der Schule zusammenlöten.
Ich entwickele Programme auf meinem Notebook (Windows 7 x86), welche tadellos mit dem Warrior funktionieren.
Wenn ich die Programme mit meinem PC (Windows 7 x64) kompilliere und ausführe funktionieren sie nicht zuverlässig, natürlich mit installierter (system32 / syswow64) x64.dll. Dieses Phänomen konnte ich schon bei mehreren Mitschülern beobachten.
Es passieren manchmal zufällige Laufzeitfehler oder auch Fehlfunktionen beim lesen/schreiben.
Darüberhinaus wird die .dll nicht gefunden, nur wenn sie im Programmverzeichnis ist.

Ist das bekannt oder gibt es eine unsererseits falsche vorgehensweise?

Wir entwickeln mit der Microsoft Visual Studio Express Edition 2008/2010 für C#.

Edit: wer eine Umgehung des Problems sucht, mein letzter Beitrag enthält eine pdf-Anleitung zum 32-Bit kompillieren.

[Christoph Jung]

Wie wird denn die iowkit.dll in das C#-Projekt eingebunden? Wird eine spezielle DLL genutzt oder wird ein eigener Wrapper eingebunden?
Wo genau tritt der Fehler auf und ist dieser irgendwie reproduzierbar?

[Palmm130]

die .dll wird wie im C#-Codebeispiel eingebunden, über

Code: Select all

[DllImport("iowkit.dll")]
public static extern IntPtr IowKitOpenDevice();

wobei OpenDevice(); und das auslesen der Warrior-Informationen stets zu funktionieren scheint.
Jedoch scheint das lesen und setzen der Pins manchmal gar nicht ausgeführt zu werden.
Wenn ein Ausgang auf Output geschaltet wird, leuchten die entsprechenden LEDs beispielsweise gar nicht auf, obwohl der selbe Code mit dem gleichen Warrior an einer 32-Bit Maschine funktioniert hat - vorher und nachher wieder!

Dazu werfen manche Projekte "es wurde versucht, eine Date mit einem falschen Format zu laden. (HRESULT: 0x8007000B)", obwohl die richtige Library geladen wurde.
Ich persönlich benutze die Librarys aus der Download-Sektion für den IO-Warrior (vor ca. 2 Wochen geladen).

Dazu kommt noch, dass die Library unter 32-Bit im Ordner system32 gefunden wird, unter 64-Bit jedoch nicht, da muss sich stets die 64-Bit-DLL mit im .\bin\Debug\ Ordner befinden. (ebenso wenig unter syswow64)

[Christoph Jung]

Wird denn ein 64-Bit Projekt erstellt und dazu auch eine 64-Bit Version der DLL genutzt? Mischen darf man nämlich nicht.
Eigentlich macht ein 64-Bit Programm für den IO-Warrior auch keinen großen Sinn. Das 32-Bit Programm sollte Problemlos auf einem 64-Bit System laufen.
Wichtig ist bei .Net auch, welche Version genommen wird. Da kann man ja zwischen 1.5 bis hin zu 4.0 wählen. Diese Einstellung findet sich in den Projekteigenschaften irgendwo.

Bei einem 64-Bit Windows muss eine 32-Bit DLL in den sysWOW64 Ordner und eine 64Bit in den System32 Ordner hinterlegt werden.
Liegt an der unfähigkeit der Namensgebung bei Microsoft :(.
Ansonsten ist es schon richtig, dass die DLL im selben Ordner wie die Anwendung liegen sollte, zwecks Updates der DLL.

Läuft denn das 32-Bit Programm ohne Fehler auf der 64-Bit Maschiene?

Die Frage ist, wenn etwas geschrieben wird, kommt das auch beim IO-Warrior an? am besten mit dem SimpleHIDWrite Tool überprüfen ob das auch wirklich angekommen ist. Das Tool ist im SDK enthalten.

[towaibw]

Wenn ich das hier lese, kommt mir wieder mein Wunsch, eine 64bit iowkit.dll zu haben, in den Sinn. Über meine Probleme zu diesme Thema hatte ich hier im Forum berichtet.

Eigentlich macht ein 64-Bit Programm für den IO-Warrior auch keinen großen Sinn. Das 32-Bit Programm sollte Problemlos auf einem 64-Bit System laufen.

Obiger Kommentar von Herrn Jung ist einfach zu kurz gedacht. Mein Problem damals war (wenn ich mich recht erinnere), das ein 64bit Java nichts mit einer 32bit dll anfangen kann, und der Einsatz eines 64bit Java war nicht verhandelbar. Deshalb wäre der Hinweis, dass auf 64bit Systemen auch ein 32bit Java läuft in keinster Weise zielführend.

Mein Wunsch:
CodeMercs stellt eine 64bit Version ihrer dll für die IO-Warriors bereit. Aus meiner Sicht kann sich das nur positiv auf die Einsatzmöglichkeiten der IO-Warrior und deren Absatz auswirken.

Danke!

Thomas

[Christoph Jung]

So nochmal zum mitschreiben:
Wir liefern die Sourcecodes der DLL, diese sind Open Source und man kann somit eigene Änderungen vornehmen oder es nach 64Bit Kompilieren.
Desweiteren ist im großen SDK sowie im Windows SDK ein Ordner enthalten, in dem die 64Bit Version für Windows fertig kompiliert ist. Mehr können wir auch nicht machen als es anbieten. Falls die CDs nicht aktuell waren, bitte ich um Entschuldigung deswegen.

Also bitte die Anschuldigungen, "es gäbe keine möglichkeit eine 64Bit DLL zu nehmen" oder "es gibt keine 64Bit DLL zum Download" unterlassen, denn dies entspricht einfach nicht der Wahrheit.

@towaibw:
Was Java angeht tut es mir leid, dass ich nicht helfen konnte, aber ich kann leider nicht alle Programmiersprachen unterstützen und aus dem FF ein Programm oder eine Lösung dazu bieten. Java ist ein Thema, wo wir nur wenig resonanz bekommen.

[towaibw]

Sorry, ist bei mir leider noch nicht angekommen, dass es bereits eine 64bit Version der dll gibt.
Ich nehme somit alles zurück und behaupte das Gegenteil ;-).

PS: In meinem Beitrag kann ich keine Anschuldigungen erkennen. Auch erwarte ich Bereich Java keine Unterstützung. Also bitte wieder beruhigen...(ist besser für die Gesundheit).

[Palmm130]

Bei den Express-Editionen von Visual Studio kann man nicht auswählen, ob ein Programm für x86 oder x64 kompiliert wird, scheinbar entscheidet es das selbst anhand des Betriebssystems. Hier "funktioniert" auch nur ein x64-Programm nur dann, wenn die x64-lib im Verzeichnis ist, bei der x86-dll wird der Fehler ausgegeben: "Es wurde versucht, eine Datei im falschen Format zu laden", was ja auch stimmt.
Das mit den dlls an den Orten System32 und SysWOW64 war ein netter Hinweis, hat jedoch nicht zum Erfolg geführt.

Soll ich ein fertig kompilliertes Programm einmal hochladen?

Für welches .NET-Framework sind die dlls denn optimiert? es liegen auf dem Testsystem alle vor (2-4) und in 3.5 wird gearbeitet.

[Christoph Jung]

Ich glaube man musste die Option, für wieviel Bit das Programm Kompiliert werden soll erstellen. Müsste ich mal hier bei mir schaun.
Das Komplette Projekt einfach an jung@codemercs.com schicken. Zip, Rar oder 7Zip.

Die DLLs sind in keiner Weise für .NET optimiert. Die DLLs sind reines C, daher auch dieser Wrapper in unserem Beispiel.
Es gibt eine spezielle .NET DLL von einem hier aus der Community. Die können wir aber nicht in unser SDK packen, weil das externe Software ist.

[Christoph Jung]

Also ich hab das Programm jetzt mal grob überblickt und finde keine Fehler. Ich kanns hier auch als x64 Version kompilieren und ausführen (Als Standard ist "Any CPU" eingetragen, hab dort mal ein neues Profil erstellt, welches explizit x64 nutzt. Leider kenn ich den Aufbau der Platine nicht und kann so schlecht das mit den LEDs testen. An welchen Ports sind diese denn angeschlossen?

Ansonsten läuft das Programm ohne Fehlermeldungen. MIt dem SimpleHIDWrite konnte ich auch den Datenverkehr sehen. Wenn ich die Beiden dunklen Buttons betätige schreibt er irgendwelche Daten.

[Palmm130]

Danke für die Mühe,
im Sourcecode-Ordner befindet sich eine Textdatei mit der Pinbelegung.
Es ist schon auffällig, dass mehrere Probleme damit haben, hilft ein Scan des Schaltplans?

[Christoph Jung]

So hab den Fehler (hoffentlich) ausgemerzt. In der USB.IOWarrior Klasse habe ich einige Variablendeklerationen geändert. Jetzt funktioniert es unter x86 und x64 Windows 7. Ich werde es im SDK austauschen.

[Palmm130]

Nun da der x64 Support scheinbar klammheimlich aufgegeben wurde, anbei noch eine Anleitung im pdf-Format zum 32-Bit Kompillieren unter Windows x64 (Betrifft nur Express Editionen von Visual Studio).

[Christoph Jung]

Öhm nein es sollte nach meiner Änderung alles funktionieren. Und da keine weiteren Fragen mehr aukamen war das Thema für mich erledigt. Was klappt denn nicht?

EDIT: Ach es geht um Grundlagen der Benutzung einer Entwicklungsumgeben. Ich bin davon ausgegenagen, dass man so etwas wissen müsste, wenn man Programmieren will.

[Palmm130]

Prinzipiell wollte ich x64-Anwendungen schreiben, im sdk befindet sich nun keine x64-dll mehr. Wenn ich die dll im 64-Bit Modus lade, wir mir der Fehler "Versuch, eine dll im falschen Format zu laden" angezeigt, also der fehlerhafte Versuch, eine 32-Bit dll aus einer 64-Bit Anwendung zu laden.
Daher wollte ich für jeden, der hier drüber stolpert die Alternative anbieten, sie im 32-Bit Modus zu kompillieren. Das diese Funktion in den Express-Editionen so unnötig versteckt sein muss, konnte keiner vorher ahnen, dies ist eine der häufigsten Fragen zum Thema VS:E