Hallo miteinander,

Nun, mache ich halt ein neues Thema auf und beziehe mich auf die IB Diskussion unter " CS kommt für mich nicht mehr in Frage!":

Zitat von Christian Lütgens

---

Praxisfremd...? Meine Software macht das ständig, weil konzeptbedingt die Anfahr- und Bremsverzögerung der Loks möglichst weitgehend ignoriert wird. Von den ~20 Loks, die meine Anlage bisher verkraftete, waren durchaus schon 15 gleichzeitig in Betrieb (d.h. es werden praktisch ständig Befehle gesendet). Wenn die Anhaltegenauigkeit eine Schienenlänge betragen würde, dann würde ich mich ärgern.

---

Praxisfremd, deshalb:
Wenn im Automatikbetrieb 15 bis 20 Züge mit der IB kontrolliert werden müssen, so wird trotzdem kaum einmal der Fall sein, dass zwei Züge oder mehr absolut synchron etwas tun (Fahrstufe verändern oder sonst irgend etwas) Ausser man hat Doppeltraktionen im Einsatz. Aber auch hier sind es vielleicht zwei Loks.

Wenn man das bei der IB kritiisiert so sollte man das eben auch im Vergleich zu anderen Produklten machen. Dieser Vergleich vermisse ich.

Tatsache ist auch, dass wir schon deutlich mehr als 20 Züge über die Automatik von Windigipet gefahren sind. Mir ist KEINE Zugfahrt bekannt die uns zuweit gefahren ist und eindeutig dem angeblichen Verhalten der IB zugeordnet werden kann.

Zitat

---

Soweit ich verstanden habe, wird die Mehrfachtraktion hier nur genutzt, um das Problem manuell zu simulieren. Mit der PC-Steuerung kann auch die 6021 in die Verlegenheit kommen, mehrere Loks gleichzeitig steuern zu müssen - da hat sie dann den Vorteil der Dummheit, sprich: die 6021 überläßt es dem Programm, ihr die Befehle mundgerecht zu servieren. Mehr dazu später.

---

Die Mehrfachtraktion taugt nicht für die Simulation eines Automatikbetriebs. Grund: siehe oben, weil es in der Praxis kaum vorkommt, dass zwei Loks genau zum selben Zeitpunkt Befehle erhalten.

Zitat

---

Da zeigt sich dann die Intelligenz der Zentrale: Die Zentrale muß den normalen Refresh-Zyklus unterbrechen, für alle Beteiligten der Mehrfachtraktion die neuen Befehle senden und dann den Refresh-Zyklus wieder aufnehmen. Tut sie das nicht, hat man ein Problem.

---

Aha, jetzt kommen wir zum Punkt:
Die Intellibox hat hier die Möglichkeit deisen Refresh Zyklus mit den Sonderoptionen zu verstellen. Es sind deren drei.


Aus den inoffiziellen Liste der Sonder Optionen:

Zitat

---

27 Refresh cycle 1..240 Minimum time in minutes between the last command to a loc and the moment it may be
removed from the refresh cycle.
2* Default: two minutes.
0 Never remove a loc from refresh cycle once it is activated.


28 Refresh cycle
0* Remove loc from refresh cycle only when its speed is currently zero.
1 May remove loc from refresh cycle even when its current speed is not zero.

29 Refresh cycle
0 Do not remove loc from refresh cycle when 'in-use'.
1* May remove loc from refresh cycle even when 'inuse'.

---

Leider sind nur die SO 27 und 28 im Handbuch dokumentiert. Die Zahlen mit den Sternchen bedeuten Standarteinstellungen. Wir haben die SO27 auf 0 gestellt. Diese Liste ist gültig für die Firmware Version 1.500

Ich denke, gerade mit der SO 27 = 0 werden die Loks gleich wieder aus dem Refresh Zyklus gekippt, wenn sie ihren Befehl erhalten haben. Warum sie hier Standartmässig auf 2Minuten gesetzt wurde, keine Ahnung.

Hallo.

Zitat

---

Die Mehrfachtraktion taugt nicht für die Simulation eines Automatikbetriebs. Grund: siehe oben, weil es in der Praxis kaum vorkommt, dass zwei Loks genau zum selben Zeitpunkt Befehle erhalten.

---

Wie ich schon schrieb: Bei mir ständig. Der Befehlspuffer (im PC) ist durchaus mal mit 4-5 Befehlen gefüllt, die der Rechner gerne zeitgleich ans 6050 senden möchte, aber es aus gutem Grund sein läßt. Das hängt sicher von den Streckengegebenheiten und von der verwendeten Software ab, praxisfremd ist es keineswegs.

Und selbst wenn es nur im Ausnahmefall vorkommt: Wenn es bei dieser Situation zu Problemen kommt, ist das ganz klar ein Softwarefehler der Zentrale. Es kommt ja auch niemand auf die Idee, den Absturz der 6021 im MM1- / MM2-Mischbetrieb, gleichzeitiger Aktivierung von Funktionen und Änderung der Geschwindigkeit als "kein Problem, weil praxisfremd" abzuhaken.

Zitat

---

Die Intellibox hat hier die Möglichkeit deisen Refresh Zyklus mit den Sonderoptionen zu verstellen. Es sind deren drei.

---

Das beschriebene Fehlverhalten darf nichts mit den genannten Sonderoptionen zu tun haben. Die sind nur dann interessant, wenn das Signal auf der Schiene auf Übertragungsfehler optimiert werden soll. Bei Eintreffen neuer Befehle muß der Zyklus unterbrochen werden, egal wie viel im Refresh-Buffer ist, und die Befehle müssen schnellstmöglich ans Gleis gesendet werden, egal wie viele es sind.

Zitat

---

Ich denke, gerade mit der SO 27 = 0 werden die Loks gleich wieder aus dem Refresh Zyklus gekippt, wenn sie ihren Befehl erhalten haben. Warum sie hier Standartmässig auf 2Minuten gesetzt wurde, keine Ahnung.

---

Umpf, wirklich nicht? Jetzt bin ich aber enttäuscht.

Die Grundeinstellungen der IB scheinen mir durchaus sinnvoll zu sein: So lange eine Lok fahren soll, bekommt sie kontinuierlich ihre Befehle. Falls die Lok ihr Gedächtnis verliert, oder falls eine Fahrstufenänderung oder Funktionsauslösung wegen Kontaktproblemen nicht übertragen wird, dann bekommt sie es wenigstens etwas verspätet beim Refresh.

Je mehr Loks im Refresh-Zyklus drin sind, desto länger dauert es, bis die Zentrale einmal komplett alles durchgeackert hat. Wenn der Refresh-Zyklus bei neuen Befehlen unterbrochen wird und die Lok den Befehl gerade korrekt empfängt - kein Problem. Sonst kann es aber sein, daß die Änderung erst deutlich später bei Lok ankommt als mit einem kleinen Refresh-Zyklus. Und darum ist Purging bei vielen Loks, von denen nicht alle fahren, eine gute Sache.

Eine Lok, die seit zwei Minuten steht, aus dem Refresh-Zyklus wieder zu entfernen, erscheint mir durchaus sinnvoll. Alzheimer dürfte bei Stillstand wohl kein allzu großes Problem sein, und während der Fahrt lindert ein kurzer Zyklus viele Übertragungsprobleme deutlich.

Und mit SO27=0 wird die Lok nicht sofort aus dem Refresh wieder rausgenommen, sondern gar nicht, zumindest wenn Deine zitierte Dokumentation korrekt ist. Ich würd's bei den zwei Minuten für "inaktive" Loks belassen, das klingt nach einem wirklich vernünftigen Wert.


Bye,
Christian

Hallo Christian

Zitat von Christian Lütgens

---

Und mit SO27=0 wird die Lok nicht sofort aus dem Refresh wieder rausgenommen, sondern gar nicht, zumindest wenn Deine zitierte Dokumentation korrekt ist. Ich würd's bei den zwei Minuten für "inaktive" Loks belassen, das klingt nach einem wirklich vernünftigen Wert.


Bye,
Christian

---

Oh, da habe ichs tatsächlich falsch interpretiert. Es heisst, dass kein Purging passiert bei der Einstellung 0. Ich ging davon aus, dass 0 sek gemeint sind.

Trotzdem bleibt die Tatsache, dass wir so oder so (mit beiden Einstellungen von SO27) in der Praxis noch nie Probleme hatten bezüglich Anhaltegenauigkeit wenn wir auch mehr als 20 Züge im Automatikbetrieb hatten und zwar mit Windigipet.

Übrigens noch etwas zur Baudrate:

Wir wechselten erst vor kurzem von Windigipet 8.5 auf die Version 9.0. Wir hatten die Baudrate immer auf 19200Bd eingestellt. Und hatten nie Probleme damit. Als ich unmittelbar nach der 9.0er Installation den selben Automatikbetrieb laufen liess, so fuhren die Züge konstant übers Ziel hinaus.

Warum? Ein kleiner Bug auf der 9.0er Version liess nur eine Baudrate von 2400Bd zu. Auch mit der IB. Durch ein Bugfixes konnte man die Baudrate wieder verstellen. So stellten wir diese wieder auf die 19200 ein und alles lief wieder in der gewohnten Anhaltegenauigkeit.

Hallo.

Zitat

---

Trotzdem bleibt die Tatsache, dass wir so oder so (mit beiden Einstellungen von SO27) in der Praxis noch nie Probleme hatten bezüglich Anhaltegenauigkeit wenn wir auch mehr als 20 Züge im Automatikbetrieb hatten und zwar mit Windigipet.

---

Das glaube ich Dir natürlich gerne und freue mich, daß es so ist. Die Diskussionen zeigen jedoch, daß andere Nutzer andere Erfahrungen gemacht haben, und das sollte man meiner Meinung nach nicht mit einem einfachen "bei mir nicht, basta" vom Tisch wischen.

Zitat

---

Übrigens noch etwas zur Baudrate:

Wir wechselten erst vor kurzem von Windigipet 8.5 auf die Version 9.0. Wir hatten die Baudrate immer auf 19200Bd eingestellt. Und hatten nie Probleme damit. Als ich unmittelbar nach der 9.0er Installation den selben Automatikbetrieb laufen liess, so fuhren die Züge konstant übers Ziel hinaus.

Warum? Ein kleiner Bug auf der 9.0er Version liess nur eine Baudrate von 2400Bd zu. Auch mit der IB. Durch ein Bugfixes konnte man die Baudrate wieder verstellen. So stellten wir diese wieder auf die 19200 ein und alles lief wieder in der gewohnten Anhaltegenauigkeit.

---

Schau Dir mal die Protokollbeschreibung der IB an. Ich hatte mir die mal von der Uhlenbrock-Homepage runtergeladen, war ein ganzes Buch. Und dann vergleiche sie mit den zwei DIN A4-Zetteln, auf denen das Protokoll der 6050 komplett beschrieben ist. Dann weißt Du, warum für die IB (wenn sie nicht im reinen 6050-Modus betrieben wird) 2400 bps wirklich nicht ausreichen.

Auch hier hilft der Märklin-Technik ihre Dummheit: Es werden einfach nicht so viele Daten übertragen, weil deutlich weniger Daten vorhanden sind, die es zu übertragen gilt und weil die Zentrale von sich aus gar nichts macht. 2400 bps ist für die 6021 einfach ausreichend, sofern der Programmierer sein Handwerk versteht und nicht davon ausgeht, daß er die Daten nur möglichst schnell loswerden muß und sich schon irgendwer drum kümmert, daß damit was passiert.

Hattet Ihr denn die IB während des Fehlers auch auf 2k4 eingestellt, oder lief womöglich der PC auf 2k4 und die IB noch auf 19k2? Das wäre noch eine besondere Hürde, die die Datenübertragung zur Glückssache macht.


Bye,
Christian

Hallo Christian,

Zitat

---

Hattet Ihr denn die IB während des Fehlers auch auf 2k4 eingestellt, oder lief womöglich der PC auf 2k4 und die IB noch auf 19k2? Das wäre noch eine besondere Hürde, die die Datenübertragung zur Glückssache macht.

---

Jetzt hast du ein Eigentor gemacht.

Meine Erfahrung mit der RS232 Schnittstelle ist die, wenn die beiden Datengeräte, die mit einander über RS232 kommunizieren sollten, unterschiedliche Baudrate eingestellt habe, läuft gar nix. Ausser das eine Gerät wird so eingestellt, dass sie sich selber synchronisiert. So ist letztlich an beiden Geräten die selbe Baudrate vorhanden.

So hätte ich mit unterschiedlichen Baudraten wohl kaum einen Zug in Bewegung setzen können.

Aber so hatte ich zwar einen korrekten Automatikbetrieb, ausser eben, dass die Züge zu weit fuhren. Eben eine Folge der langsameren Datenkommunikation.

Aber du hast natürlich Recht, wenn mehr Daten übermittelt werden, dann dauerts länger.

Zitat

---

Das glaube ich Dir natürlich gerne und freue mich, daß es so ist. Die Diskussionen zeigen jedoch, daß andere Nutzer andere Erfahrungen gemacht haben, und das sollte man meiner Meinung nach nicht mit einem einfachen "bei mir nicht, basta" vom Tisch wischen.

---

Ich kann natürlich nur aus der Sicht Windigipet/IB berichten. Über andere SOftware kenne ich mich nicht aus. Kann natürlich schon sein, dass Herr Peterlin seine Software auf die IB optimiert hat. Auf jeden Fall sind sehr viele WDP Fahrer mit der IB unterwegs. Wenn das derart grosse Probleme geben würde, dann würde man auch in dessen Forum mehr darüber lesen.

Ich möchte natürlich nocheinmal darauf hinweisen, dass in der Praxis beim Automatikbetrieb es sozusagen nicht vorkommt, dass zwei unterschiedliche Züge gleichzeitig einen Befehl erhalten. Da spielt der Zufall und die Reihenfolge der Kontaktabfrage die entscheidende Rolle. Wenn natürlich ein Zug auf der Strecke mit einer kleinen Verzögerung die Fahrt etwas verringert, so fälltz das auch nicht auf. Wenn man auf der Stopstelle natürlich eine Toleranz nicht auch einbezieht, so ist klar, dass es Probleme gibt. Auf der Windigipet Seite wird im Workshop sehr ausführlich über die Rückmeldekontakte informiert. Man muss sich schon bei der Auslegung der Anlage gewisse Toleranzen einkalkulieren wie:

- Datenstau (Sowohl Fahrbefehle, als auch RMK Einleseverzögerung, Betriebssystem Rechner, Schnittstelle, Auslastung der PC CPU usw...)
- Toleranzen der Loks (Motor, Getriebe usw.)
- Betriebsspannung (starke Spannungsschwankungen sind mit Modellbahtrafos ebenfalls unvermeidlich)


Ich behaupte jetzt, dass man hier diese Probleme locker in den Griff kriegt mit der richtigen Auslegung seiner Anlage.

WDP hat auch ein gutes Betatest Team, das aus der Praxis kommt. Es sind auch einige Insider dabei.

Zitat von Christian Lütgens

---

Hallo.
Wie ich schon schrieb: Bei mir ständig. Der Befehlspuffer (im PC) ist durchaus mal mit 4-5 Befehlen gefüllt, die der Rechner gerne zeitgleich ans 6050 senden möchte, aber es aus gutem Grund sein läßt. Das hängt sicher von den Streckengegebenheiten und von der verwendeten Software ab, praxisfremd ist es keineswegs.

---

Hallo Christian,
worann sieht man das der Puffer des PC gefüllt ist :

Hallo.

Zitat

---

Jetzt hast du ein Eigentor gemacht.

---

Neinnein, ich weiß schon, was ich schreibe.

Zitat

---

So hätte ich mit unterschiedlichen Baudraten wohl kaum einen Zug in Bewegung setzen können.

---

Da sieht meine Erfahrung anders aus. Die Wahrscheinlichkeit ist groß, daß gar nichts geht, und die Wahrscheinlichkeit ist sehr groß, daß alles äußerst unzuverlässig ist. Aber mit etwas Glück geht trotzdem noch was... nur halt sehr langsam (mit Fehlerkorrektur) oder sehr fehlerbehaftet (ohne). Da kommt's drauf an, was WDP wann wie an die IB sendet - dazu kann ich natürlich nichts sagen.

Zitat

---

Da spielt der Zufall und die Reihenfolge der Kontaktabfrage die entscheidende Rolle.

---

Was meinst Du mit "Reihenfolge der Kontaktabfrage"? Der s88-Bus wird innerhalb weniger Millisekunden abgefragt, da merkt man wirklich (fast) keine Verzögerung. Beim Poll-Betrieb schickt das Interface dann den Inhalt sämtlicher Kontakte an den PC, die IB bietet außerdem die Möglichkeit, von sich aus die veränderten Kontakte zu senden, und zwar in dem Moment, in dem sie verändert sind.

In beiden Fällen liegen die Informationen innerhalb maximal ~330ms beim PC vor, für alle Kontakte.

Muß man bei WDP eigentlich immer noch angeben, wie oft gepollt werden soll? Kam mir damals, als ich es mir angeschaut habe, schon sehr rückständig vor. Meine Software pollt immer, wenn sie gerade Zeit hat, und durch die Verzögerung der 6021 nach jedem Befehl (es sind tatsächlich 100ms, nicht 10 wie ich vorhin irgendwann schrieb) ist das recht oft der Fall.

Zitat

---

Ich behaupte jetzt, dass man hier diese Probleme locker in den Griff kriegt mit der richtigen Auslegung seiner Anlage.

---

Z.B. Nothalt-Strecken an jedem Signal... Ernsthaft: Nach der Beschreibung des Fehlers zu urteilen, über den wir hier mehr lang als breit diskutieren, ist der durch die Auslegung der Anlage nur schwer in den Griff zu bekommen. Dann schon eher durch die Auslegung der Software.

Zitat

---

worann sieht man das der Puffer des PC gefüllt ist

---

In meinem Fall an der Länge des Striches in der rechten oberen Bildschirmecke. Das ist der Vorteil einer selbstgestrickten Software: Man kann selbst festlegen, was sie macht.


Bye,
Christian

Hallo Christian,

Zitat

---

Da sieht meine Erfahrung anders aus. Die Wahrscheinlichkeit ist groß, daß gar nichts geht, und die Wahrscheinlichkeit ist sehr groß, daß alles äußerst unzuverlässig ist. Aber mit etwas Glück geht trotzdem noch was... nur halt sehr langsam (mit Fehlerkorrektur) oder sehr fehlerbehaftet (ohne). Da kommt's drauf an, was WDP wann wie an die IB sendet - dazu kann ich natürlich nichts sagen.

---

Ich habe mich schon relaitiv viel mich mit RS 232 Schnittstellen rumschlagen müssen. Ich habe aber beim besten Willen noch nie erlebt, dass zwei unterschiedlich eingestellte Baudraten nur einen Hauch von vernünftigen Daten übermittelt wurden.

Zitat

---

Was meinst Du mit "Reihenfolge der Kontaktabfrage"? Der s88-Bus wird innerhalb weniger Millisekunden abgefragt, da merkt man wirklich (fast) keine Verzögerung. Beim Poll-Betrieb schickt das Interface dann den Inhalt sämtlicher Kontakte an den PC, die IB bietet außerdem die Möglichkeit, von sich aus die veränderten Kontakte zu senden, und zwar in dem Moment, in dem sie verändert sind.

---

Da meine ich weniger die Abfrage zwischen s88 und der IB bzw PC sondern wie das Programm arbeitet. Im Windigipet gibt es der sogenannte Automatikbetrieb nach Anforderungskontakten. Da scannt dann die Software vorher eingegebene Kontakte durch und sucht dabei eine Möglichkeit bei einem freien Anforderungskontakt nach einer freien Fahrstrasse. Für diese Abfrage gibt es noch einen Zufallsalgorythmus. Dieses Spiel muss natürlich dann mit der IB zusammenarbeiten. Wohl erwähnt, dass dies nur eine Möglichkeit ist, Züge im WDP fahren zu lassen.

Jede fahrstrasse besteht nicht nur aus einer Rückmeldestrecke sondern aus beiebig vielen im Minimalfall aus drei. So kann man in jeder Fahrstrasse (oder im Fahrplan auch Lokwesie) bereits vordefinieren wie ein Zug beispielsweise auf dem Bahnhofsgleis abbremst. So haben wir beispielsweise ein Bahnhofsgleis in 6 Rückmeldeabschnitte eingeteilt und können so sehr sanfte Zugseinfahrten definieren.

So, jetzt ist es doch ein Zufallspiel, denn die Lok kommt doch zu einem bestimmten Zeitpunkt auf einen Kontakt, ganz sicher nicht synchron mit dem Ablauf der s88 Abfrage der IB. Dazu kommt noch das Einlesen in den PC und schliesslich wann die Software bereit ist genau diesen Kontakt abzufragen.

Trotzdem halten die Züge in einer Genauigkeit von nur wenigen cm an. Und genau diese wenigen (vielleicht höchstens 3cm) halte ich für erstaunlich genau. Wer es noch genauer brucht, sorry, der macht in meinen Augen einen Denkfehler. Letztlich kann er auch beim besten Motor und Decoder nicht erwarten, dass keine Toleranzen vorhanden sind.

Zitat

---

Muß man bei WDP eigentlich immer noch angeben, wie oft gepollt werden soll? Kam mir damals, als ich es mir angeschaut habe, schon sehr rückständig vor. Meine Software pollt immer, wenn sie gerade Zeit hat, und durch die Verzögerung der 6021 nach jedem Befehl (es sind tatsächlich 100ms, nicht 10 wie ich vorhin irgendwann schrieb) ist das recht oft der Fall.

---

Wieso rückständig? Was erwartest du? Welche Version meinst du?

Rückständig oder nicht. Ich weiss nicht. Es soll einfach so sein, dass man es in der Praxis brauchen kann und das tut es. Kein Zweifel. In der aktuellen Version von WDP kann man das Intervall der RM Kontaktabfrage einstellen von 50ms bis 1sek in 10ms Schritten. Nun, in der Praxis funktioniert das. Wie du erkennen kannst bei uns zumindest gibt es da keine Probleme.

Es ist schon klar, dass man mit den Einstellungen den sauberen Fahrbetrieb ruinieren kann. Insofern kann man die zuviele Möglichkeiten schon kritisieren. Aber es gibt natürlich so viele Anlagevarianten und Kombinationen wie es Nutzer gibt. Ich will daher nicht von Rückständig sprechen.

Hallo.

Zitat

---

Ich habe aber beim besten Willen noch nie erlebt, dass zwei unterschiedlich eingestellte Baudraten nur einen Hauch von vernünftigen Daten übermittelt wurden.

---

Ich schon. Spaß macht das nicht, soviel ist sicher.

Zitat

---

So, jetzt ist es doch ein Zufallspiel, denn die Lok kommt doch zu einem bestimmten Zeitpunkt auf einen Kontakt, ganz sicher nicht synchron mit dem Ablauf der s88 Abfrage der IB. Dazu kommt noch das Einlesen in den PC und schliesslich wann die Software bereit ist genau diesen Kontakt abzufragen.

---

Der s88-Bus funktioniert als Schieberegister, die Module werden der Reihe nach abgefragt und alle liefern ihre Daten ab. Beim 6050 (-> dumm) erfolgt die Abfrage immer dann, wenn der PC sie startet, und die Daten werden direkt aus den Modulen an den PC geliefert. Bei der IB (-> klug) erfolgt die Abfrage kontinuierlich, die IB schiebt die Daten in einen Buffer. (Darum auch die Einstellmöglichkeit an der IB, wie viele s88-Module angeschlossen sind.) Wenn der PC die Abfrage startet, liest die IB nur noch aus dem Buffer aus, was deutlich schneller geht. Alternativ kann die IB von sich aus den PC informieren, wenn's was neues gibt, was u.U. noch schneller geht.

Zitat

---

Trotzdem halten die Züge in einer Genauigkeit von nur wenigen cm an. Und genau diese wenigen (vielleicht höchstens 3cm) halte ich für erstaunlich genau. Wer es noch genauer brucht, sorry, der macht in meinen Augen einen Denkfehler. Letztlich kann er auch beim besten Motor und Decoder nicht erwarten, dass keine Toleranzen vorhanden sind.

---

5cm finde ich auch noch OK, alles darüber akzeptiere ich nur bei "unkontrollierbaren" Loks (die ich dann tunlichst irgendwie kontrollierbar mache) oder während der Einmeßphase (bei meiner Software).

Laut einer anderen Nachricht im Modellbahntreff stellt die IB bei schnell aufeinanderfolgenden Lokbefehlen die s88-Verarbeitung zurück, und das ist dann das Problem. Ich habe keine IB, daher kann ich nur ins Blaue spekulieren, was damit wieder gemeint sein könnte: Entweder die IB fragt dann nicht mehr regelmäßig den s88-Bus ab, oder im "intelligenten" Betrieb werden die Veränderungen erst dann an den PC signalisiert, wenn wieder Platz auf der Leitung ist. In letzterem Fall wäre eine Software, die 6050-artig die Daten pollt, womöglich nicht von dem Problem betroffen, weil da nicht die IB entscheidet, was wann zu tun ist.

Ich sehe schon, ich muß mir doch mal so ein Ding kaufen. Ist einfach viel zu interessant, um es nur aus der Ferne zu betrachten.

Zitat

---

Wieso rückständig? Was erwartest du? Welche Version meinst du?

---

Das sind ja gleich drei Fragen auf einmal.

Rückständig, weil es meiner Meinung nach bessere Möglichkeiten für den Poll-Zyklus gibt (sprich: immer dann, wenn's paßt) oder weil - bei der IB - die aktive "Benachrichtigung" der elegantere Weg ist.

Was ich erwarte: Bei Auswahl von "6050" wird in jeder freien Minute der s88-Bus abgefragt, bei Auswahl von "IB" werden die Möglichkeiten der intelligenten Zentrale genutzt, um die Daten möglichst schnell in die Software zu bekommen.

Welche Version: Keine Ahnung, ist wohl so drei oder vier Jahre her. Ich habe dann - aus anderen Gründen - mit meiner eigenen Software angefangen und mich um den Markt nicht mehr gekümmert.

Zitat

---

Ich will daher nicht von Rückständig sprechen.

---

Ich meinte auch nur dieses eine klitzekleine Detail. Insgesamt ist WDP sicher nicht rückständig, auch wenn es damals nicht mein Fall war.


Bye,
Christian

Hallo,

nur zur Erinnerung. Ich habe den "praxisfremden" Test im Handbetrieb gefahren. Die IB war nicht mal mit dem Computer verbunden. Also kann es nichts mit Software (ausser der von der IB), Schnittstellen oder Baudraten zu tun haben.
Wenn ich mich recht an eine Diskussion im Railroadforum erinnere, schickt die IB die Fahrbefehle nicht wie üblich 2 mal, sondern xxmal an das Gleis. Durch diese unkontrollierte Datenflut kann es dann zu den verzögerten Befehlen kommen.
Ganz praxisfremd ist der Test nun auch nicht. Als Amifan fahre ich gelegentlich Mehrfachtraktion. Bei grösseren Anlagen kommt es wahrscheinlich doch vor, dass mehrere Befehle gleichzeitig kommen. Vor allem bei Computersteuerung.

Gruss Kurt

Hallo Kurt,

Auch zur Erinnerung:

Die Ausgangssituation ist folgender Satz:

Zitat

---

Ich war Ende letzten Monats auf einem Seminar für
Modellbahnsteuerungen. Dort wurde ganz eindeutig gesagt, daß die IB
sich, bei der Steuerung von 4 Motorola Loks gleichzeitig aufhängt,
bzw. so lange Zeit benötigt, daß die Züge nicht mehr rechtzeitig zum
Halten kommen.

---

Als erstes:
Die IB hängt sich ganz bestimmt nicht auf.

Zweitens:
In der Praxis fährt man vielleicht zwei Loks in Doppeltraktion. Und ausser PC Steuerung schaffst du es sonst sowieso nicht von Hand mehrere Loks (nicht in Doppeltraktion!!) absolut synchron zu steuern. Deshalb ist dein Test schon etwas weit hergeholt.

Wie dem auch sei:
Mit Automatikbetrieb per PC ist es davon abhängig wann di eZüge über die Kontakte fahren, die dann den Befehl erteilen etwas zu tun. So zeigt es meine Erfahrung, dass es ganz gut funktioniert.

Wenn du deine Anlage von Hand steuerst ist dein Test sogar noch Praxisfremder. Es sein denn, du bedienst tatsächlich 4 Loks in Mehrfachtraktion. Letztlich hast du nur zwei Hände und zwei Regler auf der IB.

Hallo.

Zitat

---

In der Praxis fährt man vielleicht zwei Loks in Doppeltraktion. Und ausser PC Steuerung schaffst du es sonst sowieso nicht von Hand mehrere Loks (nicht in Doppeltraktion!!) absolut synchron zu steuern. Deshalb ist dein Test schon etwas weit hergeholt.

---

Das kommt natürlich immer darauf an, wie viele Leute die Anlage bedienen.


Bye,
Christian

Hallo Martin,

ich gebe ja zu, dass ich etwas praxisfremd war. Wer hat schon einen Prüfstand, auf den er 4 Loks stellen kann? Bei mir kommt das aber trotzdem vor, z.B. nach Warungsarbeiten.

Mehrfachtraktion muss nicht Doppeltraktion heissen. Wenn ich auf die neueren US-Loks stehen würde, wäre eine 3, 4 oder 5fach Traktion durchaus möglich. Und dann mit 2 Fahrreglern eine Parallelausfahrt aus einem Bahnhof.

Gruss Kurt