Zitat

---

Also Bernd, verzeih mir bitte, wenn ich damit behaupte, dass die mangelnde Anhaltepräzision nicht einen Zusammenhang mit der IB hat.

---

Hier muss ich aus eigener Erfahrung Bern recht geben. Die Performance der IB ist nicht das gelbe vom Ei. Dieses liegt primär an der Anzahl der Wiederholungen eines Befehls, welche bei der IB gigantisch ist. auch sind die Pausen zwisch den einzelnen Befehlen länger als nötig...

Der Vorschlag die Wiederholungen eines Befehls durch den Benutzer je Lok einstellbar zu machen wurde von den Entwicklern bis heute auf die lange Bank geschoben.

Besonders schlecht sieht es aus, wenn die IB mehrere Protokolle fährt hier bricht die Performance gänzlich ein. Deshalb habe ich mir auch nur Motorola Schonkost verordnet

Die Anhaltegenauigkeit, die daraus resultiert ist von der gewählten Lösung und der Intelligenz der Software abhängig. Wer trotz Digital mit stromlosen Abschnitten anhält, hat sicher kein Problem mit mehr als 20 Zügen. Was die Software anbelangt hier ein Beispiel. Das von mir verwendetet Railroad & Co. verwendet intern über 1000 Fahrstufen. Die werden in die 14 Motorola Fahrstufen umgerechnet. Wenn man es sich einfach macht, werden während des Abbremsens viele Fahrstufen mehrfach generiert. Hr. Freiwald, der Entwickler von RR&Co. hat mit seiner Software darauf reagiert und sichergestellt, das diese redundanten Befehle nicht gesendet werden. Seitdem gibt es bei meinem Layout keine Performance Problem mehr. Aber mehr als 4-5 Züge fahren auch nicht gleichzeitig...

Was die Resets anbelangt habe ich übrigens als ein IB User der ersten Stunden nicht einen bisher erlebt.

Was aus meiner Sicht heute gegen die IB spricht, ist dass die Beseitigung von Fehlern ziemlich lange dauert. Die Beseitigung des von mir gemeldeten gemeldeten und dokumentierten Fahrtrichtungs Bug hat sich fast 2 Jahre hingezogen und wurde auch erst in Angriff genommen, als ich recht massiv auf diesem Punkt in den einschlägigen Foren rumgeritten bin

Was für die IB spricht: die meisten Bugs sollten raus sein - soweit müssen andere Systeme erstmal reifen.

Viele Grüße

Holger

Hallo Holger,

Sorry, aber da muss ich einfach nur sagen, dass wir eine Anhaltepräzision erreichen, die bei weniger als 5cm (In der Regel sind es vielleicht 2 höchstens 3cm) Anhaltepräzision haben auf unserer Anlage und ich bin schon der Meinung, dass dies ein hervorragender Wert ist . azu auch folgendes:

Unsere Anlage besitzt keine stromlosen Abschnitte. Obige Werte erzielen wir mit Windigipet mit über 20 Zügen auf der Anlage mit Automatik Betrieb mit Anforderungskontakten und 120 Rückmeldestrecken die ebenfalls über die IB geführt werden (ALSO KEIN!! HSI welcher über eine seperate Schnittstelle an den PC geführt werden)

Unsere Bremsstrecken sind etwa 60cm lang. Die Bremsung übernehmen noch grössten Teils die Decoder selber, haben aber letzte Woche mit Windigipet 9.0 die ersten Versuche gemacht mit Bremsverzögerung weg vom Decoder zur Softwarelösung. Die ersten Test's zeigen kaum schlechtere Werte.

Hingegen gab es noch einen kleinen Bug bei der 9.0er Version welche die IB-PC Verbindung auf nur 2400Bd laufen lies. Da gab es tatsächlich ein Überfahren des Zielkontaktes! Eine Kurrektur mittels eines Bugfixes war dieses Problem schlagartig wieder weg.

Bei Automatikbetrienb mit Anforderungskontakten waren bei uns schon des Öfteren sicher bis zu 10 Zügen (oft auch sehr lange Züge dessen Wagen voll beleuchttet sind und nahe an die Lastgrenzen der Loks kommen) gleichzeitig unterwegs.

Wie's Herr Peterlin genau macht mit der Umrechnung der internen Fahrstufen auf die Decoderrelevanten Fahrstufen ist mir auch nicht bekannt, aber Performanceprobleme durch Ausgabe von mehreren Befehlen mit der gleichen Fahsrtufe scheint hier nicht der Fall zu sein. Jedenfalls erkenne ich hier keine Probleme.

Die Erfahrung die ich mit der ganzen Sache mache ist die, dass man mit den falschen Einstellungen aller Glieder in der Kette (sei es beim PC die Schnittstelle oder bei Windigipet mit den Systemeinstellungen oder der SO bei der IB) so verschiedenes kaputt machen kann und dann die Gesammtperformance leidet.

Deshalb bleibe ich fest mit meiner Meinung, dass es eher an der Einstellung liegt und nicht an der IB selber. Allerdings habe ich mit Multiprotokoll (noch) keine Erfahrung gemacht.

Hallo Martin

Es geht nicht um 20 Züge fahren , das schafft die IB ohne Probleme . Es geht darum bei 20 fahrenden Zügen gleichzeitig 5 oder mehr Züge ab zu bremsen oder zu beschleunigen, das heißt es sehr viele Daten werden gesendet. Nun kannst du bei jedem hinzu kommenden , abremsenden Zug die Verlängerung des Bremsweges merken.
Außerdem sind auf meiner Anlage 5cm ein sehr langer Weg. Ein zug Muß beim Erreichen des Stoppmelders auch stehen und nicht erst 5 cm weiter.

Gruß

Bernd

Moin zusammen..

diese Auseinandersetzung hier ist schon mehrere Jahre alt.

Es ist mittlerweile längst bewiesen, daß die IB Probleme hat, wenn mehrere Loks gleichzeitig abgebremst/beschleunigt werden. Die Geschwindigkeit IB <-> PC ist dabei genauso irrelevant wie die verwendete Software.

Das Problem tritt dann auf, wenn der interne Ringspeicher der IB (Dieser Speicher enthält die Loks, die zyklisch refresht werden) voll ist und eine neue Lok hinzukommt. Die IB schickt dann teilweise bis zu 30x das gleiche Kommando an die gleiche Lok. Somit bekommen andere Loks ihre Befehle erst viel später und somit verlängert sich der Bremsweg.

Das gleiche tritt auch bei der Beschleunigung auf, allerdings fällt es hier nicht so sehr ins Gewicht.

Also nochmal: Nur wenn 5 oder mehr Loks gleichzeitig beschleunigt oder abgebremst werden, tritt dieses Problem auf.

Martin, du hast dieses Problem nicht gehabt, weil Du über den Decoder gebremst hast. Hier wird nur EIN Kommando gesendet. Das bekommt die IB natürlich fehlerfrei hin.

Wenn Du jetzt über die Software bremst, wirst Du sehr schnell merken, wovon wir hier reden.

Auch ich war von dem Problem betroffen, ein Umstieg auf die MobaSbS hat mich davon erlöst.

Viel Erfolg

Michael

Hallo Zusammen,

Zitat von Michael Mertner

---

...diese Auseinandersetzung hier ist schon mehrere Jahre alt.

Es ist mittlerweile längst bewiesen, daß die IB Probleme hat, wenn mehrere Loks gleichzeitig abgebremst/beschleunigt werden. Die Geschwindigkeit IB <-> PC ist dabei genauso irrelevant wie die verwendete Software.

Das Problem tritt dann auf, wenn der interne Ringspeicher der IB (Dieser Speicher enthält die Loks, die zyklisch refresht werden) voll ist und eine neue Lok hinzukommt. Die IB schickt dann teilweise bis zu 30x das gleiche Kommando an die gleiche Lok. Somit bekommen andere Loks ihre Befehle erst viel später und somit verlängert sich der Bremsweg.

Das gleiche tritt auch bei der Beschleunigung auf, allerdings fällt es hier nicht so sehr ins Gewicht.

Also nochmal: Nur wenn 5 oder mehr Loks gleichzeitig beschleunigt oder abgebremst werden, tritt dieses Problem auf...

---

Und das ganze gilt auch nur dann, wenn im reinen Motorola-Protokoll gefahren wird. Wird die IB ausschließlich als DCC-Zentrale verwendet, tritt das von Michael geschilderte Problem nicht auf.

Im (englischen) IB-Yahoo-Forum wurde dies vor geraumer Zeit von einigen Mitgliedern ausführlichst gemessen und dokumentiert.

Herzliche Grüße und gute Nacht

Hallo Bernd,

Zitat

---

Außerdem sind auf meiner Anlage 5cm ein sehr langer Weg. Ein zug Muß beim Erreichen des Stoppmelders auch stehen und nicht erst 5 cm weiter.

---

Oh, jetzt fange ich an zu verstehen. Offenbar löst du ein Sofort Stop ein wenn der Zug den Stop Kontakt erreicht. Da reichen natürlich 5cm nicht, das ist mir schon klar. Wir verlangsamen den Zug bereits einen Kontakt früher und stoppenm ihn dann am Stop Kontakt sanft. Ziel sollte da auch sein, dass die Züge möglichst vorbildnah sehr sanft und langsam in den Bahnhof einfaheren und Kontakt um Kontakt ihre Geschwindigkeit verringern bis er steht. So haben wir halt auch etwa 5 bis 6 Kontaktstrecken auf einem Bahnhofsgleis.

Bisher haben wir die Philosophie bvertreten, dass wir die Verzögerung dem Decoder überlassen mit zwei Effekten: der eine ist wegen der niedrigen Anzahl Fahrstufen bei Motorola. Damit man die Fahrstufen sanfter ausgleichen kann. Zweiter Punkt ist natürlich den Datenverkehr so geriing wie möglich zu halten.

Jetzt hat Herr Peterlin so viele schöne features in die Lokdatenbank eingebaut, dass wir im Moment am Umdenken sind und diese Features möglichst nutzen möchten. Daher wollen wir Zug um Zug umstellen und es entsprechend testen.

Jetzt bin ich selber gespannt iwe das mit der Performance der IB so spielt. Jedenfalls konnte ich bis jetzt keine grossen Unterschiede feststellen in Bezug auf viel oder wenig Datenverkehr. Wenn ich von 10 gleichzeitig fahrenden Zügen sporeche, dann meine ich natürlich, dass diese nie mit konstanter Geschwindigkeit über die Anlage donnern. Die Fahrstrassen sind natürlich mit verschiedenen Fahrstufen pro Rückmeldeabschnitt belegt, wobei eine Fahrstrasse sicherlich minimal 3 Rückmeldeabschnitte betrifft und maximal sagen wir bis zu 10 Abschnitte. Da ist wirklich intensiver Datenverkehr angesagt und auch mit vielen Fahrstufenwechsel.

Ich bin jetzt schon gespannt darauf wie es sein wird, wenn die Software mehr übernehmen muss.

Hallo miteinander,

Vielleicht noch ein weiterer Aspekt oder besser gesagt eine Frage:

Wisst ihr eigentlich, welche Firmware die IB besass als die Performanceprobleme aufgetaucht sind?

Wir haben die aktuellste Version 1.5xx drauf. Das ist die die mit der IRIS eigeführt wurde.

Nun stelle ich mir schon die Frage, ob da nicht nur die IRIS integriert wurde, sondern auch einige andere Sachen.

Vielleicht liegt da der Hase begraben.

Zitat von Martin Lutz

---

Wisst ihr eigentlich, welche Firmware die IB besass als die Performanceprobleme aufgetaucht sind?

---

Hallo Martin,

das Problem ist so alt, wie die IB selbst. Wie ich bereits geschrieben hatte, bin ich ein IB Nutzer der ersten Stunde. Meine IB hat die Seriennummer 1000002997 seinerzeit mit der FW Version 1.001. Ich hatte direkt von 6021/6051 auf die IB umgestellt.

Bei meinem Layout gab es mit der 6021/6051 keine Performance Probleme, da ich aber einen Kopfbahnhof hatte war das Nichtvorhandensein einer absoluten Fahrtrichtungsvorgabe bei PC Steuerung der Haupgrund was anderes zu verwenden.

Mit der IB kammen sofort die Performanceprobleme. Durch meinen Kontakt zu Herrn Freiwald wurde dann die Ansteuerung der IB so verändert das Fahrstufenbefehle an die IB nur gesendet werden, wenn diese voneinader verschieden sind. Das brachte bei mir dann eine akzeptable Performance in Verbindung mit Railroad & Co.

Der wesentlich Lösungsansatz die Anzahl der Wiederholungen die die IB bei EINEM Fahrbefehl generiert drastisch zu verringern, ist bis heute nicht verwirklicht worden. Wie ein Vorredner schon schrieb: das senden EINES Fahrbefehls an die IB führt dazu, dass der Fahrbefehl viele viele mal am Gleis generiert wird. Deutlich häufiger als das z.B. eine 6021 macht. Durch die Wiederholung will man sicherstellen, dass die Lok den Fahrbefehl auf jeden Fall mitbekommt - auch wenn vieleich gerade mal eine kurze Störung (Kontaktproblem etc.) vorlag. Nur da macht die IB einfach zuviel des guten...

Richtig schlimm wird es, wenn noch die Pausen zwischen verschiedenen Protokollen im Multiprotokollbetrieb dazu kommen.

Aber nochmals: für viele Anwendungsprofile ist die IB keine schlecht Lösung. Nur Verbesserungswürdig ist nach wie vor einiges. Für meine Anwendungsprofil würde ich mir jedoch auch heute wieder eine IB zu legen.

Viele Grüße

Holger

Guten Morgen Holger,

Zitat

---

das Problem ist so alt, wie die IB selbst. Wie ich bereits geschrieben hatte, bin ich ein IB Nutzer der ersten Stunde. Meine IB hat die Seriennummer 1000002997 seinerzeit mit der FW Version 1.001. Ich hatte direkt von 6021/6051 auf die IB umgestellt.

---

Aha, da haben wirs. Ist dir bewusst, dass seit der ersten Stunde sich so einiges getan hat? Da gab es einige Versionen der Firmware, die man selbst runterladen konnte und immer noch kann. Woher willst du wissen, dass diese Punkte nicht schon längst überarbeitet wurde?

Mittlerweile ist die Version 1.501 aktiv und diese haben wir drauf. Diese ist aktiv seit Anfang 2004!

Nun, ich bin mal gespannt wie's dann bei uns aussieht, wenn wir der IB noch mehr Arbeit zumuten.

Zitat

---

Der wesentlich Lösungsansatz die Anzahl der Wiederholungen die die IB bei EINEM Fahrbefehl generiert drastisch zu verringern, ist bis heute nicht verwirklicht worden.

---

Gestatte mir da nochmals die Frage: um welche Firmware handelt es sich da? Was heisst, bis heute?


Seltsam auch, dass dieses Problem im Windigipet Forum praktisch noch nie zur Debatte kam, obwohl da sehr viele mit der IB fahren. Zusammen mit Windigipet allerdings.

Zitat von Martin Lutz

---

Guten Morgen Holger,

Gestatte mir da nochmals die Frage: um welche Firmware handelt es sich da? Was heisst, bis heute?

---

Hallo Martin,

natürlich bin ich nicht bei der 1.001 stehen geblieben, sondern habe immer die aktuelle Version drauf. Aber an den unsäglichen Wiederholungen hat man bisher (leider) nichts geändert.

Das Problem ist, dass sich die Positionierung der IB über die Jahre geändert hat. Am Anfang wurde die IB als Ersatz der 6021 vermarktet. Mittlerweile vermarktet man die IB mehr als DCC Zentrale, die auch noch Motorola (und Selctrix) kann. Entsprechend sind die Prioritäten bei Weiterentwicklungen gesetzt...

Viele Grüße

Holger

Hallo zusammen,

ich finde Eure Beiträge allesamt sehr interessant, helfen Sie doch mit ein Problem einzukreisen. Dieses ist bei uns auch vorhanden gewesen, die Ursache war allerdings nicht klar einzugrenzen.

Wir haben dann letztendlich die IB mit einem TITAN 80VA Trafo versorgt. Die Probleme, vor allem mit dem Reset wurden geringer. Möglicherweise sind die anderen Trafos (viel preiswerter) bei Volllast zu früh in die Knie gegangen?

Wir haben in einem Falle die Intellibox mit dem HSI 88 von den Besetztmeldungen befreit. Damit konnten wir eine Verbesserung erreichen in Bezug auf Genauigkeit der Loksteuerung.

Ganz besonders positiv hat es sich ausgewirkt als wir das Schalten und Melden komplett ausgelagert haben. In unserem zweiten Falle in ein Rautenhaus Selectrix System. Danach musste die IB nur noch die Loks steuern, was sie fortan ganz gleichmäßig und korrekt erledigt hat. Auf dieser Anlage fahren bis max 9 Züge gleichzeitig.

In unseren IB's werkelt die Software 1.501 Unsere Steuerungssoftware ist RAILWARE.

Zitat von Michael Mertner

---

Das Problem tritt dann auf, wenn der interne Ringspeicher der IB (Dieser Speicher enthält die Loks, die zyklisch refresht werden) voll ist und eine neue Lok hinzukommt. Die IB schickt dann teilweise bis zu 30x das gleiche Kommando an die gleiche Lok. Somit bekommen andere Loks ihre Befehle erst viel später und somit verlängert sich der Bremsweg.

---

Hallo alle miteinander,

ich habe die IB zwar noch nicht so lange, daß mir dieses Problem bisher aufgefallen wäre, aber gibt es nicht genau dafür die beiden Sonderfunktionen 27 und 28 zum Purging (to purge = entschlacken)???

Zitat

---

Sonderoption Nr. 27
Gibt an, wieviel Zeit nach dem letzten Befehl vergehen soll, bis eine
Lokadresse aus dem Refresh-Zyklus gelöscht wird (= Purging).
0 = kein Purging
1 - 240 = Zeit in Minuten zwischen letztem Befehl und Purging
(Werkseinstellung = 2 Minuten).

Sonderoption Nr. 28
Setzt die Bedingungen für&#146;s Purging
= 0 Lokgeschwindigkeit = 0 (Werkseinstellung)
= 1 Lokgeschwindigkeit =/ 0

---

oder ist das was ganz anderes : : :

Hallo Michael,

Zitat

---

Also nochmal: Nur wenn 5 oder mehr Loks gleichzeitig beschleunigt oder abgebremst werden, tritt dieses Problem auf.

Martin, du hast dieses Problem nicht gehabt, weil Du über den Decoder gebremst hast. Hier wird nur EIN Kommando gesendet. Das bekommt die IB natürlich fehlerfrei hin.

Wenn Du jetzt über die Software bremst, wirst Du sehr schnell merken, wovon wir hier reden.

---

Obwohl ich nicht betroffen bin (fahre seit Anfang 2005 Rautenhaus-Selectrix, vorher IB, vor der IB Selectrix) wurde am letzten Train-Controller Stammtisch nähe München über dieses Problem gesprochen. Gemäss Angaben von Herr Freiwald und einem Betatester können mit der IB tatsächlich nicht mehr als 5 Loks gleichzeitig von einer Software beschleunigt und abgebremst werden. Davon ist nur die IB betroffen und es fällt auch nicht immer auf (wenn z. B. der Decoder diese Funktion übernimmt) da in vielen Fällen diese Gleichzeitigkeit nicht eintritt. Uhlenbrock hat noch vieles zu tun und ich hoffe für die vielen IB-Nutzer, dass da bald etwas geschieht - auch in Sachen Reset's. Auf die "Neuheit" des eingebauten IR-Empfängers hätte UB aber zugunsten der wirklichen Probleme verzichten können!

mit freundlichen Grüssen aus Zürich

Gian


(n.B.: Gestern abend war das Forum kurze Zeit nicht zugänglich und heute fehlen die Smiles - ist das nur bei mir oder liegt da ein Forum-Problem vor?)

Hallo Torsten

Zitat von Torsten Piorr-Marx

---

... aber gibt es nicht genau dafür die beiden Sonderfunktionen 27 und 28 zum Purging (to purge = entschlacken)???
...oder ist das was ganz anderes

---

Klare Antwort: Ja und nein !

Das Purging wird aktiv, um Loks aus dem Ringspeicher zu löschen, die sowieso schon lange nicht mehr "angefasst" wurden. Aber das Grundproblem der IB ist eben, dass der Ringspeicher an sich zu klein ist. Nach meinem Kenntnisstand fasst er genau 4 Loks incl. deren Funktionszustände. Darauf kann mich jetzt niemand festnageln.

Daher das Problem, wenn eine 5. Lok ins Spiel kommt. Jetzt muss dauernd "gepurged" werden, nämlich dann, wenn alle 5 Loks gleichzeitig Befehle bekommen.

Aber, und genau hier liegt der Hund begraben, ist auch dies eigentlich kein Problem.
Die IB verhält sich jetzt falsch und beginnt, in Verbindung mit dem Purging zu viele Wiederholungen eines Kommandos für eine einzige Lok. Soviel ich weiss, jedesmal für die letzte, die in den Ringspeicher gekommen ist. Aber auch das ist ohne Gewähr. Dadurch bedingt kommt es zu den Zeitverzögerungen bei allen Loks, auch bei der letzten, denn wenn ein Befehl bis zu 30 mal wiederholt wird, dann kostet das in Verbindung mit dem Purging kostbare Zeit. Und dies bemerkt man dann bei einer Verlängerung des Bremsweges.

Witzigerweise tritt das Problem mit der Märklin 6051 nämlich nicht auf. Die bekommt erst später bei 8-9 Loks "dicke Backen", weil dann die 2400 Baud einfach nicht mehr reichen.

Das Problem betrifft NUR das Motorola II Protokoll. Wenn gleichzeitig auch noch DCC Loks im Spiel sind, wirds noch schlimmer, weil hier intern auch noch umgeschaltet werden muss und schlimmstenfalls auch die DCC-Loks längere Bremswege bekommen, weil die IB mal wieder damit beschäftigt ist, 5 Loks unter Motorola zu "bedienen" und das nicht auf die Reihe bekommt.

Wie schon gesagt, wenn über den Decoder gebremst wird, tritt das Problem nicht auf, da hier nur sehr wenige, wenn nicht gar nur ein Befehl gesendet werden muss. Den Rest erledigt der Decoder in der Lok.

Das Problem ist bei Uhlenbrock seit langer Zeit bekannt. Mindestens jedoch seit zwei Jahren und hat auch nix mit dem Softwarerelease zu tun. Ich habe jetzt die 1.501 drinne und nachwievor dieses Problem - wenn ich denn mit der IB steuere, was ich aber nur zu Testzwecken mache.

Gefahren wird mit der MobaSbS, die zum einen einen grösseren Ringspeicher hat (ich glaube, 16 Loks) und zum anderen auch nicht unnötig viele Wiederholungen an die Loks schickt. Daher ist dieses Problem hier unbekannt.

So, genug gepinnt. Der nächste bitte

Gruss Michael

Hallo miteinander,

Zu diesem Problem bin ich nun gespannt auf unsere Versuche, mit der IB mehr zu belasten.

Nun hat aber Uhlenbrock aber eine neue IB im Tender. Nach Angaben der Uhlenbrock Webseite soll diese ja schon ausgeliefert sein.

Ist da vielleich jemand, der diese neue IB schon hat? Sind da diese Probleme auch noch vorhanden?

Hat da schon jemand Erfahrung?

Da ich im Moment zu Hause noch eine 6021 besitze und nur in unserem Moba Raum eine fest eingebaute IB, habe ich schon lange im Kopf mal für mich eine IB anzuschaffen. Einfach wegen der Nutzung des erweiterten Adressbereiches und die Programmiermöglichkeinfür Nicht Märklin Decoder (CV Byteweise)

Da Märklin wieder eine Insellösung generiert und nicht einmal die CV's kompatibel zu den anderen macht, so kann mir die CS den "Buckel runterrutschen"