Vielleicht mal eine kleine Warnung in die Runde was die Interfaces von Uhlenbrock angeht:
ich helfe einem Kollegen aus, seine im Bau befindliche Modelleisenbahn mittels PC Steuerung zu automatisieren.
Dabei kommen vorwiegend Produkte von Uhlenbrock zum Einsatz, welche sich bisher als zuverlässig und problemlos im Betrieb erwiesen haben (ich selber fahre LDT und ESU, soll hier aber nichts zur Sache tun).
Leider musste ich eine Entdeckung machen, die vielleicht früher oder später auch anderen passieren könnte.
Die Konstellation ist dabei folgende: Auf Grund der geplanten Grösse der Anlage, wird bereits zu Beginn die Steuerung auf mehrere Zentralen verteilt:
- Eine Intellibox II zur Steuerung der Züge
- Eine IB-COM zum Schalten der Weichen über eigene Booster
- Eine weitere IB-COM rein nur für die Rückmeldungen
diese drei Zentralen sind per USB mit einem Rechner verbunden, was leider anscheinend nicht ganz ohne weitere Probleme möglich ist.
Zum Einsatz kommt aktuell Windows XP SP3, die restliche Konfiguration dürfte keinen direkten Einfluss nehmen.
Folgendes konnte beobachtet werden: Solange zwei Geräte am PC eingesteckt sind, funktioniert alles einwandfrei. Wird ein drittes Gerät eingesteckt, so meldet der Hardwaremanager von Windows, das zuerst angemeldete Gerät sei nicht mehr angeschlossen und vergibt dessen COM-Port nun an das dritte Gerät. Dieser Vorgang kann "im Kreis rum" beliebig fortgesetzt werden, das zuletzt angeschlossene Gerät scheint immer dem am längsten angeschlossenen Gerät die Schnittstelle "zu klauen".
Ein Betrieb dreier Geräte ist somit nicht möglich. Natürlich wurde hier zunächst die Ursache auf der Seite des Benutzers gesucht, der Effekt trat aber selbst nach intensiver Fehlersuche dauernd auf, getestet wurde mit den Treibern:
- 4.40 (mitgeliefert auf der Uhlenbrock CD)
- 6.3a von der Uhlenbrock Homepage
- 6.5 direkt von Silicon Labs (in den Intelliboxen und neueren Interfacen steckt ein CP2102 USB-Serial Wandler von der Firma, die sind anscheinend für vermurkste Treiber berüchtigt).
langsam etwas ratlos (und leicht entnervt) habe ich mir die Gerätedaten angeschaut und war leichters erstaunt festzustellen, dass sämtliche Silicon Labs CP2102 in den Uhlenbrock Geräten die selbe (!) Seriennummer (nämlich 0001) besitzen und anscheinend somit ab zwei Geräten nicht mehr vom Treiber unterschieden werden können.
Warum SL dies nicht im Treiber damit löst, dass das Gerät an die Port ID des USB Hubs gebunden wird ist mir leider auch ein Rätsel.
Ich habe nun eine Abhilfe gefunden, die vielleicht auch anderen Nutzern in solch einer Situation helfen könnte: Von Silicon Labs gibt es ein Tool, welches auf der SL Homepage unter der Bezeichnung "an144sw.zip" verfügbar ist und per USB eine Änderung der Seriennummer zulässt. Ich habe diese bei den beiden IB-Com Geräten auf 0002 bzw. 0003 geändert und seither funktioniert alles einwandfrei.
Vielleicht wäre es auch eine Lösung, wenn die SL Chips ab Werk eine aufsteigende Seriennummer hätten, so könnte das Problem grundlegend behoben werden, dürfte aber anscheinend eine Preisfrage sein.
Die Geräte werden nun mit dem Treiber 6.5 betrieben und laufen wie erwähnt wie gewünscht, einzig das IB Util reklamiert ab dem 6.x Treiber, es sei keine Schnittstelle gefunden worden, wird diese jedoch von Hand eingegeben funktioniert alles wie gewünscht.
Vielleicht hilft das irgendwem mal, wenn er eine ähnliche Konstellation antrifft.
Ich habe dies übrigens an Uhlenbrock so weitergegeben, das Problem ist dort bekannt ! Mein Vorschlag war diesen Hinweis falls zutreffend doch bitte irgendwo zu vermerken... zwar kam wie gesagt umgehend die Antwort das Problem sei vorhanden und man danke mir für die Problemlösung(!) seither ist aber nichts mehr geschehen.
Was die Resets der IB I angehen: Da habe ich mich schon stundenlang damit beschäftigt, auch mit der Sache mit externen Einflüssen, Ringkernen etc. das Gerät hat defintivi zwei Probleme:
- Es ist massiv anfällig auf Störeinflüsse von aussen, nicht nur irgendwelche eingeschleppten Sachen auf der seriellen Schnittstelle, nein: Auch irgendwas am Gesamtlayout macht das Gerät anfällig (Transformatoren, besonders Schaltnetzteile, DECT Telefone, anscheinend auch Mobiltelefone).
- Der Stack der seriellen Schnittstelle scheint einen wunden Punkt zu haben, an dem er zum Überlaufen neigt. Dies dürfte entweder einen Watchdog im Stack selbst oder sonstwo im Speichermanagement oder dem Prozessor selbst auslösen und somit den Neustart erwirken.
Ich kann mich in dem Punkt den vielen Zurufen nur anschliessen: Es konnte bisher keine Lösung rein mit der IB I präsentiert werden, die zu 100% funktioniert.