IOWarrior 56 - USB EMIs unter Linux

Dies ist das deutsche Forum für alle Themen um den IO-Warrior. Beiträge bitte nur in Deutsch.

Moderator: Guido Körber

Post Reply
carstenkaemmerer
Posts: 2
Joined: Thu Jul 23, 2015 10:00 pm

IOWarrior 56 - USB EMIs unter Linux

Post by carstenkaemmerer »

Ich habe einen IOWarrior 56 an meinem Steuer-PC angeschlossen.
Ich möchte damit für meine Home-Automatisierung einen ganzen Schwung Inputs
und ein paar Outputs realisieren, die bislang noch via Parallelport-Karte
angeschlossen sind.

Basierend auf dem Testprogramm habe ich mir ein kleines C-Programm geschrieben,
das mittels einer Endlosschleife und via ReadNonBlocking
für jede Input-Port-Änderung eine Zeile ausgibt.

Ich bin dabei über ein Problem mit EMIs auf dem USB-Port gestolpert,
welches hier im Forum auch schon mal beschrieben wurde
(viewtopic.php?f=2&t=1746).
Bei mir passiert öfters ein:

Code: Select all

... port 1 disabled by hub (EMI?), re-enabling...
... USB disconnect, device number 2
... iowarrior 2-1:1.0: I/O-Warror #0 now disconnected
... iowarrior 2-1:1.1: I/O-Warror #1 now disconnected
... [...]
... iowarrior 2-1:1.0: IOWarrior product=0x1503, serial=000016F7 interface=0 now attached to iowarrior0
... iowarrior 2-1:1.1: IOWarrior product=0x1503, serial=000016F7 interface=1 now attached to iowarrior1
Meine Frage hier geht jetzt aber nicht um die Hardware. Ich weiß,
wer den EMI auslöst (eine Gembird SIS-PM, eine via USB steuerbare
schaltbare Steckdosenleiste, beim Ausschalten einer Steckdose).
Durch Umstecken auf einen anderen Port kann ich diese EMIs von "oft"
auf "selten" reduzieren.

Das Problem ist, dass mein kleines Programm nichts davon mitbekommt, dass
der IOWarrior disconnected und neu verbunden wurde.
Es liest munter weiter, bekommt aber keine Input-Port-Änderungen mehr mit.
Ich vermute, dass es immer noch die alten, gar nicht mehr gültigen
USB-Devices offen hat und dort lauscht.

Das Programm läuft einfach weiter
und verhält sich ganz normal - ich kann überhaupt nicht erkennen,
dass es schon lange nicht mehr mit dem IOWarrior verbunden ist.

Erst, wenn ich das Programm stoppe und neu starte, verbindet er sich mit
den neuen Devices und liest dann wieder die Input-Änderungen.

Das Verhalten macht diese Lösung für Überwachungsaufgaben praktisch
unnutzbar. Selbst, wenn ich die Quelle für die vielen EMIs abstelle,
kann ich doch nie ausschließen, dass so ein Ereignis (ein Disconnect und Reconnect) irgendwann mal
passiert. Und ab da bekomme ich dann keine Änderungen mehr mitgeteilt.

Meine Frage ist jetzt: Gibt es eine Möglichkeit, diesen Disconnect
im Programm zu erkennen? Dann könnte ich ja die Devices schließen
und neu öffnen. Anahnd der errno konnte ich nix erkennen.

Meine einzige Lösung bislang war, in der Endlosschleife nicht nur das
Read zu machen, sondern jedes mal das Device auf und hinterher wieder zu.
Aber das sieht für mich "selten-C-Pogrammierer" irgendwie nach einer
ineffektiven Holzhammer-Methode aus...

Das Problem müsste doch eigentlich weit verbreitet sein und die Lösung
damit ganz naheliegend?!

Wenn es hilft, kann ich gerne noch weitere Details beisteuern!

fr_a_nk
Posts: 5
Joined: Tue Jul 15, 2014 6:54 pm

Re: IOWarrior 56 - USB EMIs unter Linux

Post by fr_a_nk »

Hallo,

ich habe eine Excel Anwendung programmiert mit der ich über einen Windows Timer im Sekundentakt Daten über den I2C Bus des IOW schicke. Um festzustellen ob jemand den USB Stecker am PC abgezogen hat, was ja dasselbe wie ein Disconnect sein sollte, rufe ich bei jedem Timer Durchlauf die Funktion IowKitOpenDevice auf und prüfe ob die einen Wert ungleich 0 zurückgibt. Ist der Wert 0 gibt mein Programm eine Fehlermeldung raus und versucht laufend den IOW zu öffnen bis er wieder mit dem PC verbunden ist oder das Programm manuell beendet wird. Ob dieses Verfahren mit dem Timing in einer Endlosschleife funktioniert muß man halt ausprobieren.
Viel Erfolg.

Gruß
Frank

carstenkaemmerer
Posts: 2
Joined: Thu Jul 23, 2015 10:00 pm

Re: IOWarrior 56 - USB EMIs unter Linux

Post by carstenkaemmerer »

Hallo Frank!

Vielen Dank für Deine Antwort! Das hat bei meinen ersten Tests ebenfalls gut funktioniert.

Ich probiere jetzt noch ein wenig weiter. Außerdem versuche ich mir noch darüber klar zu werden, was dieser Hinweis in der API-Doku zu IowKitOpenDevice für mich bedeutet:

Calling this function several times is possible, but not advisable. The devices get reenumerated and therefore the position in the list for a specific device may change.

Momentan kann mein Programm mehrere IOWarrior bedienen. Ich öffne alle und schreibe die Handles in ein Array. Wenn ich den Hinweis richtig interpretiere, dann kann ich mich jetzt nicht mehr drauf verlassen, dass die Reiehnfolge der IOWarriors nach jedem Öffnen immer die gleiche ist. Da muss ich den Zugriff dann wohl über die ausgelesene Seriennr machen.

fr_a_nk
Posts: 5
Joined: Tue Jul 15, 2014 6:54 pm

Re: IOWarrior 56 - USB EMIs unter Linux

Post by fr_a_nk »

Hallo,

mit mehr als einem IOW wird das natürlich interessanter. Wenn bei mir die Situation auftritt das IowKitOpenDevice den Wert 0 zurückgibt rufe ich anschließend IowKitCloseDevice auf damit das Handle vom Betriebsystem wieder freigegeben wird. Das geht mit mehr als einem IOW natürlich nicht weil IowKitCloseDevice alle IOWs schließt. Ich habe mir die Handlenummern vor dem disconnecten und nach den reconnecten mal anzeigen lassen und die waren, solange die Anwendung aktiv und nicht zwischendurch geschlossen und wieder geöffnet wurde, immer identisch. Aber der Gedanke das über die Seriennummer auszuwerten klingt logisch denn die sollte ja einzigartig sein.
Viel Erfolg noch.

Viele Grüße.
Frank

Guido Körber
Site Admin
Posts: 2740
Joined: Tue Nov 25, 2003 10:25 pm
Location: Germany/Berlin
Contact:

Re: IOWarrior 56 - USB EMIs unter Linux

Post by Guido Körber »

Grundsätzlich ist es natürlich nicht falsch sich darum zu kümmern Fehlerfälle abzufangen, aber die IO-Warrior sind ohne Probleme in der Lage beliebig lange ohne solche Fehler zu laufen. So lange niemand im Betrieb den Stecker zieht, oder eine externe Störung dazu kommt sollte der Chip beliebig lange geradeaus laufen.

Wenn also Komponenten Störungen erzeugen, dann sollte man sich um die Störquelle kümmern und nicht primär darum mit diesem Fehlerzustand zu leben.

Mit der Steckdosenleiste wäre als erstes zu klären wie die Störung an den IO-Warrior kommt. Eventuell hilft es einen self-powered Hub dazwischen zu schalten.

Post Reply