Hallo zusammen,
ich habe einen IO-Warrior 100 bestellt und wollte diesen in Betrieb nehmen.
mAirlist erkennt das Device auch mit mehreren Varianten.
Egal welche ich auswähle; es kommt der Log-Eintrag: Kann IO-Warrior Modell nicht identifizieren: 07C0 / 1506
Hat jemand eine Idee, oder den 100er ans Laufen bekommen? Danke
Nachtrag: Tastendrücke werden offenbar erkannt, aber mit folgender Meldung quittiert:
HID read Error: hid_read_timeout. Das Gerät ist nicht angeschlossen.
Erfolgt bei jedem Drücken und Loslassen eines Pins.
@Torben ist der IO100 Eurerseits überhaupt integriert und unterstützt?
Es werden nämlich nur 55 Eingänge angezeigt und mich irritieren diese vier Auswahlmöglichkeiten.
Habe jetzt auch schon andere Rechner mit mAirList verwendet, um einen Hardwarefehler auszuschließen. Ebenso eine alte Version 3 rausgekramt. Diese erkennt den IO-Warrior nicht, was für mich ein Indiz ist, dass hier einfach eine Library o.ä. fehlen könnte.
Nein, bisher nicht. Und mir war dieses (neue) Modell auch bislang nicht bekannt.
Ich habe gerade Snapshot 5222 hochgeladen. Schau mal, ob er jetzt funktioniert.
Welchen der vier Device-Einträge hast du ausgewählt? Richtig wäre m.E. der “SimpleIO”.
@Torben den hatte ich auch im Verdacht, habe aber mehrfach alle vier getestet.
Bei dem “Simple IO” kommt die Meldung: "HID read Error: hid_read_timeout Das Gerät ist nicht angeschlossen.
Seit dem Neustart des Rechners erhalte ich jetzt beim ersten Mal einen “Range Check Error”, danach nicht mehr.
Habe den Bugreport unter Angabe des Tickets an die Support-Email-Adresse geschickt.
Wir nähern uns der Lösung. Jetzt bitte mal Build 5223 testen.
@torben Habe wieder alle vier Devices getestet. Keine Reaktion, keine Fehlermeldung.
Es werden aber schon 81 GPI in der Liste angezeigt.
Ich habe dir per Mail einen Link zu einer Debug-Version geschickt.
Diese schreibt alle empfangenen und gesendeten Pakete in das Systemprotokoll - dazu musst du dort unter “Filter” den Haken bei “Debug” setzen.
Mich würde interessieren was dort erscheint.
82, um genau zu sein. Die interne Zählung beginnt bei 0.
@Torben Immerhin kommt überall etwas und die Hex-Werte unterscheiden sich.
Port 01
| 18.01.2023 15:14:59 | Debug | IO-Warrior receive: FF FF FF FF FF FF FF FF FB FF FF FF |
|---|---|---|
| 18.01.2023 15:14:59 | Debug | IO-Warrior receive: FF FF FF FF FF FF FF FF FF FF FF FF |
Port02
| 18.01.2023 15:15:09 | Debug | IO-Warrior receive: FF FF FF FF FF FF FF FF F7 FF FF FF |
|---|---|---|
| 18.01.2023 15:15:09 | Debug | IO-Warrior receive: FF FF FF FF FF FF FF FF FF FF FF FF |
Port03
| 18.01.2023 15:15:16 | Debug | IO-Warrior receive: FF FF FF FF FF FF FF FF EF FF FF FF |
|---|---|---|
| 18.01.2023 15:15:17 | Debug | IO-Warrior receive: FF FF FF FF FF FF FF FF FF FF FF FF |
Port04
| 18.01.2023 15:15:18 | Debug | IO-Warrior receive: FF FF FF FF FF FF FF FF DF FF FF FF |
|---|---|---|
| 18.01.2023 15:15:19 | Debug | IO-Warrior receive: FF FF FF FF FF FF FF FF FF FF FF FF |
Offenbar stimmt die Beschriftung der Ports auf dem Board nicht mit den internen Portnummern überein.
Wenn ich richtig gezählt habe, ist:
Port 1 auf dem Board = Port 69 in mAirList
Port 2 auf dem Board = Port 68 in mAirList
Port 3 auf dem Board = Port 67 in mAirList
usw.
Port 70 auf dem Board = Port 0 in mAirList
(Was dann mit Port 80-82 ist, weiß ich nicht.)
Probier das mal.
Ja, die sind auch ganz merkwürdig angeordnet…
Port 77 (oben links) lässt das Device abstürzen und es kommen nur noch Fehlermeldungen, dass das Gerät nicht erkannt wird.
Habe mal einen Draht angelötet und bin von oben links aus alle Ports durchgegangen.
In der Fernsteuerung war an verschiedenen Ports der Next-Befehl für die Automation hinterlegt.
Keine Reaktion.
So richtig schlau werde ich daraus noch nicht.
Die Bezeichnung scheint wirklich Grütze zu sein.
Einen Hinweis findet man in den beiden Dokumenten:
Seite 3
Seite 5
Demnach ist es wie folgt aufgeteilt:
P0.0…P0.7
First I/O port of the chip. These pins correspond
with the lowest 8 bits of the input or output reports
(bits 0…7, first data byte).
Die Grafik scheint fehlerhaft zu sein, aber von der Zuordnung müsste es so sein:
P0.0 PIN23
P0.1 PIN24
…
P.07 PIN32
Das passt dann auch mit der HEX-Zahl, wenn man diese umrechnet.
Schließt man PIN23 auf der Platine mit GROUND, so wird der Befehl 0 in mAirList ausgeführt.
PIN24 korrespondiert mit der 1
Ich werde morgen alles in Ruhe auflisten und hier dokumentieren.
Das ist ja völliges Chaos.
Ok, dann gab es also ein Missverständnis zwischen Port und Pin. Ich habe jetzt diverse Datenblätter studiert und kann es folgendermaßen aufklären:
Die verschiedenen IO-Warrior-Modelle stellen jeweils eine bestimmte Menge von Ports zur Verfügung, die ihrerseits jeweils (bis zu) 8 IO-Pins besitzen.
Die Notation ist dabei jeweils P<Port>.<IO-Pin>, also z.B. P3.2 (Port 3, Pin 2).
Jeder Port entspricht dabei übrigens genau einem Datenbyte aus dem HID-Report, und jedes Bit davon jeweils einem I/O-Pin.
mAirList arbeitet grundsätzlich immer mit diesen Ports und IO-Pins - wobei bislang verwirrenderweise diese IO-Pins einfach von 0 an durchnummeriert und als “Port” bezeichnet wurden wurden. Also P3.2 entspricht in der mAirList-GUI dann dem “Port 26” (3*8 + 2).
Das ist etwas, das ich jetzt zunächst einmal geradeziehen werde (und dabei noch alte unbenutzt Tabs entferne). So sieht das dann zukünftig aus:
Weiterhin muss ich die Tabelle noch um einige Zeilen ergänzen. Denn der IOW100 hat tatsächlich 82 I/O-Pins, allerdings sind diese nicht fortlaufend auf die Ports verteilt, sondern es fehlen mittendrin welche. Zum Beispiel hat Port 1 nur drei Pins (0 bis 2) statt acht:
Da die Tabelle im Konfigurationsprogramm sich automatisch aus den maximal möglichen Werten generiert, kann ich die Zeilen leider nicht automatisch ausblenden. Aber ich werde zumindest dafür sorgen, dass alle verfügbaren I/O-Pins konfigurierbar sind (P11.2 ist der letzte).
Nun kommt das große Missverständnis:
Diese Pin-Nummern des Boards sind nicht zu verwechseln mit den Pin-Nummern des ICs bzw. der Platine! Hier musst du tatsächlich immer nach dem Datenblatt gehen und ablesen, welcher IC-Pin welchem IO-Pin entspricht.
Ich melde mich, sobald ich das oben genannte in einen Snapshot eingebaut habe.
Update: Bitte Build 5224 testen.
Unter Build 5224 scheint alles zu funktionieren. Tausend Dank!
Noch ein Wunsch für zukünftig. Ich fände es ganz cool, wenn man eine Entprellzeit aktivieren könnte.
Gerade ältere Leuchtdrucktaster (Lumitas, RAFI) neigen zum Prellen.
Da schafft aber auch Abhilfe, den Befehl unter “Aus”, also bei sinkender Flanke einzutragen.
Finde ich auch eine gute Idee!
