Hallo AXL,
Zitat
Strom an
Digitalsystem wartet bis die Weiche genug Zeit zum stellen hatte (einige Sekunden)
Strom wieder aus
Richtig und toller Satz . Würde der PC wirklich warten (in dem Sinn, das er zwischenzeitlich nichts anderes tut), hätte man garantiert meterlange Bremswege und Crashes. Schönes noch triviales Beispiel, das eine gute SW fürs PC fahren eigentlich wichtiger ist wie ein gutes Digitalsystem. Aber unrealistisch: Solche Monster-Bugs würdest Du allenfalls bei Share- oder SchenkWare finden, vorwiegend bei Programmierern , die noch nicht mal eine MoBa haben.
Zitat
Und während diesem Warten ist das Digitalsystem BLOCKIERT!
Es kann keine Befehl gesendet werden, z.B. auch keine Lok abgebremst werden. Das Digitalsystem ist so lange schlichtweg tot (einige Sekunden!!). Diese Eigenschaft hängt wie gesagt dem Motorola-Protokoll an, d.h. 6021, IB usw. verhalten sich hier völlig identisch.
Und wenn ich mich nicht täusche schalten auch die CS1 und CS2 die Weichen so, oder geht das inzwischen über mfx?
Das halte ich nun wirklich als Leser für üble Nachrede. So einfach ist es nicht. Ein MM Befehl brauch vielleicht 5 ms, seine 8 fache Ausfertigung (MM üblich) max 40 ms. Alles andere wäre eine Bug in der Software (die allenfalls mit einmaligen Umschalt oder zweimaligen Ein- wie Ausbefehl an der Com Schnittstelle belastet wird) oder des Decoders! Von einem Weichen-Decoder sollte man letztendlich erwarten, das er bereits eine einmalig erhaltenen Befehl(sfolge) auch erfolgreich umsetzt. Tut er das nicht, bedingungslos zurückgeben (wir leben im 21. Jahrhundert) oder ab in die Tonne.
Alle mir bekannten Digitalsysteme senden nach einem Schaltbefehl sofort weiter mit Lokbefehlen. Keine mir bekannte Zentrale wartet bis die Weiche geschaltet ist . Das wäre ein Killerkriterium, das auch die 6021 nicht hatte. Die Märklin-Motorola Geräte haben eine beschränkte PC-Tauglichkeit zum PC-Fahren , allein zum Schalten sind sie gar nicht so schlecht, wenn der Decoder taugt.
Zitat
Das ist auch der Grund warum z.B. im MiWuLand die Digitalsystem Fahren und Schalten getrennt sind. Die hatten ja früher 6021 und mussten die Anlage deshalb so auslegen. Hätten die Fahren und Schalten zusammen gelassen, könnte es bei Bremsvorgängen ohne Stoppmelder locker flockig mal Abweichungen von 100cm geben!
Der Grund für die Trennung ist eigentlich ein anderer:
Es entstehen im realen Betrieb immer wieder Störungen (Funken o.ä.) im Datenstrom des Gleises. Es werden von den meisten modernen Digitalsystemen die Lokbefehle öfter und die Weichenbefehle seltener oder nur einmal versendet. Wenn ein Funken einen Lokbefehl erwischt, wurde der Lokbefehl halt nochmal gesendet. Erwischt er einen Weichenbefehl, fährt der Zug ins Nirvana. Deswegen sollte man bei grossen Boosterbereichen mit resultierend hoher Funken-Wahrscheinlichkeit die Weichen besser an einen eigenen Booster anschliessen, damit ein Lokfunken nicht den einzigen Weichenbefehl killt.
Zitat
Inzwischen wird im MiWuLand ja Lenz verwendet.
Aha, interessant, ich hatte bisher immer den Eindruck, die fahren mit LDT .
Zitat
Die Auftrennung Fahren/Schalten wäre also nicht mehr nötig, wurde aber beibehalten, um die Anlagentechnik weitgehend identisch zwischen alten und neuen Anlagenteilen zu halten.
Die funktionale Aufteilung auf mehrere Digitalsysteme hat einen entscheidenden Nachteil : Nur noch Computer können als universelle Steuergeräte fungieren. Die Optionen mit entsprechenden Handreglern oder Konsolen alternativ oder auch nur auf Teilen der Anlage mit einem Gerät alle Funktionen (Loks, Weichen, RM lesen) nutzen zu können entfällt.
Zitat
Ähnliche Überlegungen kann man auch bei der Rückmeldung anstellen. Da gibt es auch Dinge, da stehen mir die Haare zu Berge.
Die Haare stehen mir bereits zu Berge, wenn ein Weichendecoder eine Weiche nicht zuverlässig schaltet. Das führt dann nur allzu oft zu esotherischen Übertragungen auf Steuerungssoftware, Protokolle bis hin zu aufwendigen wie unnötigen Sicherheitsmassnahmen a la Servoantrieb oder Stromlosabschnitten als Notbremse falsch fahrender Züge von Anlagenbauern, die sich dabei für „Digitalexperten“ halten, ohne die Ursachen zu erkennen. Manche beschwören dann sogar die tausendfache Befehlswiederholung.
Zitat
Ich kann mich Peter nur anschließen: es gibt sehr wenige Digitalsysteme, die WIRKLICH für die Computersteuerung (einer großen Anlage) geeignet sind. Und die neuen Touch-Screen Zentralen gehören IMHO sicherlich nicht hierzu.
Also am Touchscreen selbst liegt es bestimmt nicht. Ich glaube Railware hat die Unterstützung der CS1 für ihre Art des Fahrens wohl auf Grund mangelnden Befehlsdurchsatzes mal abgelehnt. Ich mag zwar kein Railware, aber ich respektiere und befürworte, das hier ein Softwarehersteller mal gesagt hat, so geht es mit unserer Software nicht, anstatt nicht zu haltende Funktionsversprechen zu machen.
Soweit ich das überhaupt überblicken kann, hat die CS2 hier einen anderen Architektur-Ansatz. Sie stellt erst mal ein „konventionelles“ Digitalsystem in ihren Gleisformatprozessoren zu Verfügung. Die Konsole selbst fungiert hier (hoffeentlich) als ein autonomes Steuergerät – ähnlich einem PC - am Märklinbus, und somit an der eigentlich Steuerung aus GFPs (Mikro-Controller). Zumindest wenn hier weiter regelmässig (aber erfolgreich) gewartet wird, dürfte die CS2 eine höheres Potential zum PC-Steuern erreichen können, als man das gemeinhin von eine „Software-Zentrale“ erwartet. Ich könnte mir sogar vorstellen, das es Märklin wie Kunden weiterbringen würde, Märklin würde auch eine günstige CS2 „BlackBox“ im Booster-Case anbieten, das die Verwendung von ausschliesslich MSen samt PC ermöglichen würde.
Hallo Uhu, Karlheinz,
Zitat von Uhu
Zitat von JSteam
Es muss der Aspekt des Digitalsystems am Gleis betrachtet werden. Selbst einer unbegrenzt schnell arbeitenden Zentrale sind da Grenzen gesetzt, da nicht unendlich viele Befehle ans Gleis gesendet werden können. Anderenfalls könnten die Decoder diese nämlich nicht mehr verstehen.
Richtig, darum nochmals, auch da ist SX nicht überfordert.
Zitat von JSteam
Und da bringt auch die Aufteilung Schalten/Melden/Fahren nichts mehr, denn die paar MA Befehle im Vergleich zu den Lokbefehlen machen den Kohl auch nicht mehr fett.
Ebenfalls einverstanden, darum gibt es bei SX nur einen synchronen BUS, der als SX0 für Fahren (112 Loks) allein, SX1 zum Melden und Schalten (bis 896 Weichen/Melder) eingesetzt wird. Reicht das nicht, können weitere SX-Busse (entsprechende Interfaces nur zum Melden und Schalten) eingesetzt werden, alles ohne Geschwindigkeitseinbusse (von mir für einen Hersteller erfolgreich getestet).
Ok, die alte DCC vs. SX Leier.
SX ist praktisch nicht schneller. Keine Trafo kann 896 Weichen in 80 ms schalten, und DCC kann jedes Licht 10 mal schneller umschalten als SX Ich könnte das hier so fortsetzen bis zum St. Nimmerleinstag , dann würde ich den gleichen Fehler machen, wie viele SX Anbieter, die zwar nicht in der Lage sind, einen SX-Prozessor auf die Beine zu stellen, aber sich gerne an den endlosen Wiederholungen nichtssagender Zahlen festhalten.
SX ist eine sehr gutes und mehrwertiges System (konfektionierte Kabel verhindert Verkablungsfehler, speziell Mehrwerte im Protokoll , "Clockgebend", "logisch patchbar", die tw. veraltet sind, und tw. noch ungenutzt sind. Die oft beschwörten Übertragungsraten von SX wirken auf die Loko nur im praktisch nicht existenen idealen verlustfreien Gleissystem und vepuffen sofort im Nichts, oder vekehren sich ins Gegenteil, wenn man SX mit einem anderen Protokoll mischt.
Die geringe Menge von Anbietern, und die ursprünglich noch nicht als "PIC" - und somit nur mit entsprechendem Aufwand Know-How und Kosten realisierbaren Decodern - haben zu einer ursprünglich überdurchschnittlichen Qualität der Komponenten verglichen mit "Möchtegern-DCC-Anbietern" geführt. Dabei war die Qualität aber nicht durch das SX-Protokoll selbst gegeben (aus meiner Sicht eher umgekehrt, da DCC als einziges System eine normierte Qualitätsanforderung bzgl. der Übertragungsqualität kennt, dren Einhaltung leider freiwilli ist) und es gibt mindest genauso viele DCC-Anbieter mit hoher Qualität. Prinzipiell ist die bereitgestellte Funktionalität von DCC erheblich höher, und die Performance im wesentlich ein Merkmal der Steuergerätes, dem bei DCC auf Grund der vielfältigeren Einflussnahme eine wesentlich höhere Verantwortung zukommt. Für den User heisst das praktisch, das beim DCC die "Marke" des Systems und der gewählten Komponenten eine erheblich grössere Rolle spielt.
Insofern verstehe ich nicht die Rufe nach einem "auch noch DCC" in der CS2, und fürchte, das der Druck auf Märklin hier zu eine zweitklssigen Implementierungen kommen wird. Fordert noch SX, und ihr gebt der CS womöglich den Todesstoss au dem Weg zum PC.
Viele Grüße
Frank