|
von Märklin
auf
Selectrix
Copyright 2022
Jens Mohr
83224 Grassau
(Chiemsee/Achental) |
Digitalsysteme ... eine Gegenüberstellung
Vorwort
Die Idee zum Schreiben dieser Gegenüberstellung kam mir im Laufe
der Zeit, in der ich das TrainController (TC)* - Forum (von
Freiwald Software, Egmating) verfolgt und mit Kommentaren begleitet
habe.
In dem "TC-WIKI", welches das TrainController (TC)* - Forum
ergänzt, habe ich dann diese Gegenüberstellung im August 2011
eingestellt.
Diese
Gegenüberstellung soll die reinen technischen Daten und Fakten,
wie sie von den Herstellern in ihren Datenblättern bzw. in den
Normen definiert sind, ergänzen.
Der hiesige Leser
soll durchaus hier auch zusätzliche Informationen über andere
digitale Systeme finden, mit aufnehmen und hoffentlich erfolgreich
in seine Lösungsfindung einbeziehen.
Modellbahn Digitalsysteme ... eine
Gegenüberstellung
(aber keine Vergleiche und Bewertungen)
Einführung
Aus den vielen Anfragen und Beiträgen aus dem Forum: Railroad &
Co, Freiwald Software (Egmating) habe ich entnommen, daß viele
Modellbahner, die neu in das digitale Zeitalter eintreten oder
eine Umstellung / Erweiterung planen, unsicher sind, welches
digitale System und welche Komponenten denn nun "die richtigen"
seien.
Ferner habe ich den Eindruck gewonnen, daß bei bestimmten
Betriebssituationen Probleme auftauchen, die sinnvoll nur unter
Berücksichtigung der Kenntnisse der / des digitalen Systems(e)
gelöst werden können.
Bei all dem wurde und werde ich an meine eigene Zeit erinnert, als
ich vom analogen System auf das digitale umgestiegen bin.
Diese Gegenüberstellung soll die reinen technischen Daten und
Fakten, wie sie von den Herstellern in ihren Datenblättern bzw. in
den Normen definiert sind, ergänzen.
Ich betone ausdrücklich, daß dieser Beitrag kein Vergleich über
"für und wider" darstellen und auch kein System bewerten soll.
Der Leser soll diese Informationen mit aufnehmen und hoffentlich
erfolgreich in seine Lösungsfindung einbeziehen.
Betrachtete Digitalsysteme
Am Markt werden eine Reihe von digitalen Systemen angeboten.
Ich will hier nur die betrachten, die am häufigsten im oben
erwähnten Forum vertreten sind;
hierzu zählen ...
* DCC
* Märklin mit seinen Varianten
* Selectrix (SX)
In dieser Abhandlung wird der Stand der Systeme betrachtet, wie er
(bei mir) im August 2011 vorlag. Spätere Entwicklungen müssen
jeweils nachgetragen werden.
Digitalsystem - Architekturen
Historie
* allgemeine Betrachtung
Meines Wissens und meiner Erinnerung nach brachte die Fa.
Märklin als erstes ein "komplettes" Digitalsystem für
Modellbahnanlagen auf den Markt, welches als "Motorola I"
bekannt wurde.
Es folgten über die Jahre die Nachfolger "Motorola II" und
"mfx".
Märklin führte sein digitales System unter dem Marketingaspekt
ein: Zwei Drähte genügen zum Betreiben der Anlage. Kein
"Drahtverhau" mehr, wie bei analogen Anlagen.
Als Drähte fungierten weitestgehend die Schienen, sie sind die
Verbindung zwischen Zentrale und jeweiligen Decodern (Zentrale
>> Lok- / Schalt- Decoder).
Für die Rückmeldung (Besetztmeldung), die später mit dem
PC-Anschluß hinzu kam, wurde eine zusätzliche separate
Kommunikationsstrecke eingeführt, der "s88 - Bus" (Melde-Decoder
>> Zentrale).
Die technischen Details des Märklinsystems wurden offiziell nie
offengelegt.
Technisch interessierte Nutzer ermittelten "rückwärts"
(re-engineering) die Protokolle für "Motorola I / II und mfx"
und konnten somit Selbstbauprodukte realisieren.
Die Fa. ESU, Ulm, welche wohl maßgeblich an der
Entwicklung von "mfx" mitgewirkt hat, vertreibt mit der Zentrale
"ECOS" ein Produkt, welches auch das Protokoll "mfx" ausführen
kann; dort wird dieses aber aus Schutzgründen "M4" Protokoll
genannt.
Man kann unter diesen Randbedingungen die Märklinsysteme als
"geschlossene Systeme" einstufen.
Aufgrund dieser "Abschottung" entwickelte die Zubehörindustrie
(Fa. Lenz), wohl im Zusammenwirken mit anderen
Modellbahnherstellern", das digitale System "DCC", welches
genormt wurde und bei dem alle technischen Daten "offenliegen"
und kostenlos einzusehen sind.
Die Fa. Trix, seinerzeit noch juristisch eigenständig,
entwickelte zusammen mit industrieller Unterstützung das
digitale System "Selectrix".
Dieses System ist ebenfalls genormt und alle Informationen /
Daten liegen offen vor.
Zwischenzeitlich wurde das System in punkto zusätzlicher
Lok-Adressen / Funktionen weiterentwickelt.
Dieses neue Selectrix-System ist mit dem Vorgänger "aufwärts
kompatibel" und wird als Selectrix "SX II" (SX2
*) bezeichnet.
Im weiteren Verlauf wird das "ursprüngliche" Selectrix - System
nur als Selectrix (SX) bezeichnet. Heute findet man z.T. zur
Unterscheidung auch "SX I" (SX1 *) in der Literatur.
DCC und Selectrix lassen sich als "offene Systeme" bezeichnen,
da - wie bereits erwähnt - alle Systemdaten offengelegt sind.
* spezifische Entwicklungshintergründe
Märklin mit seinen Systemen als auch DCC wurden auf dem
Hintergrund der "Spielzeugindustrie" entwickelt.
Dies bedeutet, alle bisherigen Tasten, Schalter, Trafo-Funktionen sollten in eine Zentrale integriert werden. Die
Peripherie, d.h. die Decoder sollten so einfach und damit so
preiswert als irgend möglich sein.
Die Anbindung an einen PC kam eigentlich erst später hinzu und
stand nicht im Fokus der ersten Entwicklungen.
Somit lassen sich diese beiden Systeme als "zentralistische
Systeme" definieren.
Bei der Entwicklung von Selectrix wurde, wohl durch die
industriellen Erfahrungen mit verteilten Systemen, ein gänzlich
anderer Ansatz gewählt.
Im Selectrix-Verbund sollten auch die peripheren Komponenten
soviel "Intelligenz" als irgend möglich besitzen, um ein
"verteiltes System" aufbauen zu können.
Dieser Ansatz erforderte auch ein komplett anderes
Kommunikationssystem (Bussystem). Bei Selectrix kann jeder
Busteilnehmer mit jedem anderen Daten / Informationen
austauschen; eine Einschränkung ist hier nur bei den
Lok-Decodern (beim Fahren) gegeben.
Dies ist bei den beiden vorgenannten Systemen (Märklin, DCC)
nicht möglich, dort gibt es nur eine Richtung von der Zentrale
zu den Decodern (Peripherie); (ausgenommen das im Moment auf den
Markt kommende RailCom Verfahren bei DCC > siehe weiter unten;
als auch "mfx" hier gibt es eine Gegenrichtung
Lokdecoder ->
Zentrale).
Bei diesen beiden Merkmalen ist die Gegenrichtung der
Kommunikation aber nur auf den Lok-Decoder begrenzt und eben
nicht allgemein gültig wie bei Selectrix (>> ein großer und
wesentlicher technischer Systemunterschied).
Selectrix fällt damit in die Kategorie: "dezentrale oder
verteilte Systeme" .
* ... und ihre Auswirkungen
Letztendlich ist es unter Berücksichtigung des
Vorgenannten
nicht verwunderlich, daß sich ganz unterschiedliche
Kommunikationsstrukturen entwickelten, sowohl auf der Hardware-
als auch auf der Software-Seite in Form der Protokolle.
Während Selectrix mit einem Bussystem und einem Protokolltyp für
Fahren, Schalten und Melden auskommt, werden bei DCC und Märklin
jeweils 2 Bussysteme und Protokolltypen benötigt; eines für
Fahren und Schalten und eines für Melden.
Selectrix * wurde 2010 / 2011 zu dem sog. SX 2* System
erweitert (das bisherige wird demzufolge SX 1* bezeichnet.
Im SX 2* System wurde der Funktionsumfang des Lok-Decoders erweitert,
mit der Folge, das mehr Adressen zum Ansprechen dieser
Funktionen benötigt werden als bisher. Dies wiederum hatte zur
Folge, daß in Bezug auf die Kommunikation mit dem Lok-Decoder ein
erweiterter Protokolltyp eingeführt werden mußte.
Die Kommunikation mit
allen anderen Decodern ist geblieben.
Im SX 2* System gibt es folglich zwei
Protokolltypen, eines zur Steuerung der Lok / Fahrzeug - Dekoder
und eines für alle anderen Dekoder.
Werden bzw. sollen noch Handregler zur Steuerung der Anlage mit
eingebunden werden, dann benötigt man bei Märklin bzw. DCC in
aller Regel ein drittes Bus- und Protokoll- System; Selectrix
hingegen benötigt kein weiteres Bussystem.
Mit SX2 kommen, wegen der unterschiedlichen Realisierungen
durch die einzelnen Hersteller, in den Zentralen u.U. auch
zusätzliche Schnittstellen und / oder Geräte auf den Markt, so
daß die Handregler / Bedieneingaben auch das SX2 Protokoll
bedienen können.
Hinweis: ein Selectrix-Handregler kann immer nur zu einem
Zeitpunkt auf einen der SX-Busse der Anlage zugreifen. Sollen
andere SX Busse bedient werden, dann muß der Handregler
umgesteckt oder mittels eines elektronischen Schalters
umgeschaltet werden
* ... und die unterschiedliche, offen gelegten Bus-Systeme /
Protokolle
--DCC
Dieses Protokoll (ohne RailCom) ist so gestaltet, daß man von
einem "Standard-Anteil" und einem "offenen Anteil
(Erweiterungen)" sprechen kann.
Durch diesen gewählten Aufbau lassen von den einzelnen
Modellbahn - Herstellern relativ einfach spezifische Produktergänzungen in
das System einfügen.
Im Ergebnis ergibt dies unterschiedlich lange Protokolle und
damit unterschiedlich lange Übertragungszeiten.
--Selectrix
Das Selectrix (SX 1) * Protokoll, bestehend aus einem
"Adress-Byte" und einem "Funktions-Byte", hat einen starren,
festen Rahmen.
Aus diesem Grunde ist auch jede Übertragungszeit gleich lang und
es läßt sich daraus ableiten, wie oft innerhalb eines Busses
jeder Busteilnehmer innerhalb einer definierten Zeitperiode
angesprochen wird.
Die Flexibilität bei diesem Bussystem liegt darin, daß das
Busprotokoll (einzelne Bit) selbst keiner Decoder-Funktion
zugeordnet ist.
Die Funktion des einzelnen Bits ergibt sich aus dessen logischer
Zuordnung zu der / Decoder Funktion bzw. Funktionen.
So kann das gleiche Bit bei einem Decoder als Ausgang "S"
schalten und bei einem anderen als Meldereingang "M" gesetzt interpretiert werden
> die Zentrale wertet dies dann aus.
Wiederum kann das gleiche Bit ein Teil einer Bitkombination
sein, die eine bestimmte Meldung übermittelt; z.B. Fahrstufe;
etc.
Mit Einführung von SX 2 * kommt ein zweites Protokoll zur
Ansteuerung (im Moment nur) der Lok- Decoder hinzu.
Ziel von SX 2 * ist es, den Adress- und den Funktions-Bereich
(Zusatzfunktionen) für Loks / Fahrzeuge zu erweitern.
Da die neuen Lok-Decoder aus dem Hause Doehler & Haas, München
so programmiert (konfiguriert) werden können, daß sie entweder
als Selectrix 1* oder Selectrix 2 *, DCC bzw. Märklin - Decoder
operieren, wird eine Präambel benötigt, die vor jedem neuen
Protokoll dem Decoder mitteilt, für welchen Operationsmode und
damit "Lok-Decoder-Typ" die folgende Information gedacht ist.
Der Präambel folgen dann 5 weitere Bytes, welche die Adresse und
alle Funktionen zum Inhalt haben.
Diese zeitlich verlängerte Übertragungsdauer, im Vergleich zu SX
1 *, hat zur Folge, daß die bisherigen Zeiten für ein "refreshen"
keine Gültigkeit mehr besitzen.
Ferner kommt die Herausforderung hinzu, daß nicht alle
theoretisch möglichen Lokadressen ständig aktualisiert werden
können.
Von Seiten des Decoderherstellers Doehler & Haas, München, ist es
deshalb vorgesehen (und vorgeschlagen), daß für die
Kommunikation mit den Loks folgendes gilt ...
- es können wie bisher 103 Loks / Fahrzeuge, die mit einem SX
1 * Decoder ausgestattet sind, auf der Anlage betrieben werden.
In Bezug auf das Protokoll gibt es keinen Unterschied. Auch
wurde das Raster beibehalten.
- für SX 2 * Lokdecoder war eine Protokollerweiterung
notwendig. Diese zusätzlichen Informationen werden in das
Raster von SX 1 * integriert.
Im Ergebnis stellt sich pro Erweiterung eine zeitliche
Verlängerung im Zeitraster (Wiederholung) ein.
Als Kompromiß wurden deshalb Protokollerweiterungen für max.
32 SX 2* Lokdecoder definiert und in das Zeitverhalten
eingebaut.
Somit wird in einem SX 2 * Refresh-Rahmen mit allen 103
SX 1 *
Fahrzeugen und mit 32 SX 2 * Fahrzeugen
kommuniziert.
Da sich auf der Anlage, aufgrund des neuen Adressraums bei SX
2 * wesentlich mehr SX 2 * Lokdecoder und damit Fahrzeuge befinden
können, wird eine flexible Zuordnung der Lok-Decoderadresse zu
einem der SX 2 * Refresh-Rahmen benötigt.
Es zeichnet sich ab, daß jeder Hersteller einer Zentrale hier
seine eigenen Wege in der Realisierung geht. Diese bedeutet auch
eine unterschiedliche Anzahl von gleichzeitig steuerbaren Loks
auf einer Anlage.
Im Jahr 2011 gibt ein Hersteller an, daß bei ihm max. 16 SX 2*
Loks neben den 103 SX 1*-Loks betrieben werden können. Ein
weiterer ermöglicht den gleichzeitigen Betrieb von 32 SX 2* Loks.
Wiederum ein anderer verwendet auf dem Gleis ein ganz eigenes, an
SX angelehntes Gleissignal - SMX * genannt -- und ermöglicht den
gemischten Betrieb von SX 1* und SX 2* - Loks, wobei die max.
Anzahl von Loks weiterhin bei 103 liegt.
Ein weiterer Ansatz ist, daß aus der 4-stelligen
Lok-Decoder-Nummer immer nur die Einer / Zehner/ Hunderter
Stelle fest verwendet wird und letztlich die Loks dann weiterhin
im SX 1 * - Betrieb, also 103 Loks zeitlich parallel zu betreiben
sind.
Es wird sich zeigen, welche Varianten am Markt angenommen werden
und welche noch hinzu kommen.
In Bezug auf die Lokdecoder-Adressermittlung
gibt es nunmehr Unterschiede; s. weiter unten.
Alles Vorgenannte gilt für den sog. SX0-Bus einer Zentrale, an
dem das Gleis und damit die Lok-Decoder angeschlossen sind.
An dem SX1-Bus, an den keine Lokdecoder anschaltbar sind, haben
sich beim SX 2 System auch keine Änderungen ergeben.
Bisher wurden der SX0 und der SX1 Bus einer Zentrale immer
vom Takt und Protokoll her gleich betrieben.
Je nach obiger Hersteller-Lösung ist das künftig wohl nicht mehr
in jedem Fall so.
Der Nutzer sollte sich daher VOR einem Einsatz von SX2 auch
Gedanken über die Anschaltung / Funktion aller anderen Decoder /
Handsteuergeräte, etc. an den anderen SX-Bussen machen und bei
den Anbietern nachfragen.
--Märklin
Da es keine offiziellen Daten / techn. Informationen über die
Märklin - Protokolle gibt, beziehe ich dieses System hier nicht
weiter in die Protokoll-Betrachtungen ein. Leser können sich
evtl. über die angebotenen Links weiter informieren.
System- und Kommunikations-Strukturen
zentralistische Systeme
* Fahren
* Schalten
Bei diesen (hier betrachteten) Systemen sind sowohl die
Lok-Decoder als auch alle anderen Decoder zum Schalten
(Anzeigen) über eine 2adrige Verbindung (Bus) -- z.B. Schiene
/ Gleis oder Drähte / Kabel -- mit der Zentrale verbunden.
Von der Zentrale werden alle Einstellbefehle codiert über
diesen Bus übermittelt.
Die jeweilige Spannung und ihre digitale Codierung ist zwischen
den beiden Systemen DCC und Märklin sehr unterschiedlich.
Selbst zwischen Motorola I / II und mfx (M4) gibt es große
Unterschiede.
Nähere techn. Informationen über die Busse und ihre Protokolle
können über die Links (unten) abgerufen werden.
Da die mir am Markt bekannten Decoder zum Schalten / Anzeigen
relativ einfach aufgebaut sind, muß zum Schalten eines Ausgangs
ein Befehl ausgegeben werden > Ausgang "ein" und nach einer
Zeit t der Befehl > Ausgang "aus".
Die Zeit t wird in der Zentrale verwaltet.
Daraus folgt, jedes Schalten eines Magnetartikels erfordert 2
Busübertragungen plus einer Zeitverarbeitung in der Zentrale.
* Melden
Diese Funktion wurde erst mit der Erweiterung der
"PC-Steuerung" notwendig. Sie ist quasi das "Auge des
Modellbahn-Steuerungsprogramms", hier von TrainController (TC).
Das Prinzip des Meldens ist die Erkennung eines Stromflusses,
ausgelöst durch ein Fahrzeug, welches sich in einem
Überwachungsbereich (Gleisabschnitt) befindet.
-- DCC
Die Besetztmeldung / Erkennung basiert bei DCC auf der sog.
"Strommessung". Hier wird der gesamte Strom eines Abschnittes
über einen Besetztmelder (Decoder) geführt. Fließt ein Strom,
weil sich ein Verbraucher (Lok oder Wagen mit Beleuchtung oder
"Widerstandsachsen") auf dem Gleisabschnitt befindet, dann
wird dies erkannt und über einen eigenen Meldebus mit eigenem
Protokoll an die Zentrale gemeldet.
Anmerkung:
Die "Widerstandsachsen" sind elektr. parallel
geschaltete
Widerstände, deren Gesamtwiderstand sich wesentlich reduziert,
was zu einem höheren Strom führt.
Dies ist bei der Auslegung / Konfiguration der Anlage zu
berücksichtigen.
-- Märklin
Die Besetztmeldung / Erkennung basiert bei Märklin aus der
"Masse-Kontaktgabe". Diese historische Bezeichnung ist
geblieben, obwohl man bei einem digitalen System nicht mehr
von "Masse" sprechen
kann.
Der Mittelleiter ist an einen der beiden Ausgänge von der Zentrale bzw.
des Boosters angeschlossen. Der andere Ausgang wird mit einem
der beiden
Außengleise (Schienen) verbunden.
Steht ein Märklin (oder 3 Leiter-Fahrzeug) auf dem Gleis, dann
verbinden die elektr. leitenden Achsen das an der
"Zentrale / Booster" angeschlossene Gleis (Schiene) mit dem
anderen "Melde - Gleis" (Schiene). Diese Schiene ist an einen Melde-Decoder-Eingang angeschlossen.
Somit liegt am Meldereingang das gleiche Potential wie bei der
Zentrale / Booster an. Über einen im Meldedecoder hochohmigen
Widerstand kommt jetzt ein kleiner Stromfluß (mA) zustande,
denn der Meldedecoder muß einen Anschluß besitzen, auf dem sich
das Mittelleiter- Potential des Gleisabschnitts befindet; also
es muß eine Verbindung zur Zentrale oder Booster bestehen.
Letztendlich wird auch hier ein Stromfluß ausgewertet; im
Gegensatz zu DCC ist dieser allerdings kleiner
(geringerer Wert).
Die beiden unterschiedlichen Ansätze brachten am Markt auch
unterschiedliche Decodertypen hervor.
Diese sind jeweils über unterschiedliche Bussysteme mit der
Zentrale verbunden.
Während bei Märklin der "S88" Bus sein muß, hängt es bei DCC
davon ab, was die jeweilige Zentrale für einen Melde-Bus zur
Verfügung stellt.
S88 Kurzbeschreibung
Da dieses System bei den Modellbahnern sehr verbreitet ist
und es in den Internet-Foren auch immer wieder als "kritisch"
betrachtet wird, soll hier eine Kurzbeschreibung eine
Hilfestellung geben --- und gleichzeitig den Unterschied zum
SX - System verdeutlichen.
Am Markt werden baulich
unterschiedliche Varianten angeboten, deshalb wird hier nur
das Prinzip erläutert, nicht eine spezifische Realisierung.
Aufbau
Das S88 System besteht aus
einer Reihe von Besetztmeldern, die über einen "Bus" (Kabel)
miteinander in Serie geschaltet und mit einer Zentrale bzw.
eigenem Computer-Interface verbunden sind.
Die Zentrale bzw. das Computer-Interface bildet immer die
Steuer- und Auswerteeinheit.
Von der Zentrale bzw. dem Computer-Interface wird dann die
Besetzt / Frei - Information an das
Modellbahnsteuerungsprogramm geleitet.
Damit eine eindeutige Zuordnung
der Informationen zum realen Gleisanschluß möglich ist, muß
jeder Gleisanschluß, d.h. Besetztmeldereingang eine Adresse
erhalten.
Diese wird aus Sicht der Zentrale bzw. des Computer-Interfaces
dadurch vergeben, daß der erste in der Kette liegende Modul
die Nummer 1 erhält und die jeweils 8 bzw. 16 Gleisanschlüsse
dann 1 / 1 ... 1 / 16; usw.
Werden Besetztmelder mit 8 und 16 Gleisanschlüssen in einer
Kette gemischt, dann muß man aufpassen, wie die Zentrale bzw.
das Computer-Interface die Numerierung vornimmt (diese ist
recht starr angelegt).
Muß man später in die Kette neue Besetztmelder einfügen, dann
verschieben sich alle nachfolgend bereits vergebenen Adressen
-- es muß in der Modellbahnsoftware umadressiert werden.
Struktur und Ablauf
Ein Besetztmelder besteht
intern aus drei Funktionen ..
- der Erkennung einer Spannung
und damit eines Stromflusses (auch bei einem
"Masse-Anschluß") am vom Gleis zum Melder führenden Draht.
In der Regel können an einen Besetztmelder 8 bzw. 16 Gleise
angeschlossen werden. Wird ein Stromfluß erkannt, dann wird
ein "Latch - Ausgang" z.B. High (1) gesetzt; ansonsten Low
(0).
- Übernahme dieser 8 bzw. 16
Informationen per Takt-Kommando von der Zentrale in ein
Dekoder internes Schieberegister.
- Mit diesem Takt wird ferner
die Bitweise Weiterleitung
dieser 8 bzw. 16 Bits aus einem Schieberegister über eine gemeinsame Datenleitung in
Richtung Zentrale bzw. Computer-Interface ausgeführt.
Mit Einschalten der Zentrale
bzw. des Computer-Interfaces erhalten alle Besetztmelder
zeitgleich das Signal, daß die Gleiszustände in die
Schieberegister zu übernehmen sind.
Danach werden über die
Taktleitung Impulse gesendet, welche die Schieberegister dazu
veranlassen ...
- zuerst mit jedem Takt-Impuls
ihre eigenen Bit-Informationen auf die Datenleitung zu legen
- und dann vom nachfolgenden
Besetztmelder dessen Bit-Informationen auf der Datenleitung
"durchzureichen".
Die Zentrale bzw. das
Computer-Interface muß die Takte mitzählen, damit es die
Dateninformation dann auch einer Adresse zuordnen kann.
Die max. Anzahl der Takte
ergibt sich aus der Summenbildung Anzahl Besetztmelder X
Anzahl Gleisanschlüsse.
Wurde die max. Anzahl der Takte
erreicht, also alles abgefragt und zugeordnet, dann werden
über eine Leitung alle Schieberegister gelöscht.
Anschließend beginnt das ganze
Spiel von neuem.
Systemanfälligkeit
Werden auf die Adern des
"Busses" Impulse induziert, so hat das Ganze, je nachdem
welche Leitung betroffen ist, unterschiedliche negative
Auswirkungen. In jedem Fall ist der gesamte Zyklus gestört !!
Da die Besetztmelder und der "Bus" keinerlei
Sicherungsmaßnahmen besitzen, können und werden Störungen
nicht erkannt !!
Auch die Zentrale bzw. das Computer-Interface kann solche
Störungen nicht erkennen und ausblenden; es kommt zu
Fehlfunktionen in der Modellbahn-Steuerungssoftware.
Es ist daher dringend angeraten, NUR mit geschirmten Kabeln zu
arbeiten und mit solchen Moduln, die auf eine solche Schirmung
auch elektrisch ausgelegt sind.
Auslastungsproblematik
Erfolgt die Steuerung und
Auswertung des S88 Meldesystems über eine Zentrale, so ist das
ein weiterer Faktor, der bei der Auslastung der Zentrale,
neben Fahren und Schalten, zu berücksichtigen ist.
Aus diesem Grunde ist in jedem Falle der Einsatz eines eigenen
Computer-Interfaces in Betracht zu ziehen.
* Identifikation von Lok-/Fahrzeug- Adressen
--DCC
Mit dem genormten Systemteil RailCom bringt die DCC Gemeinde
derzeit ein Rückmeldesystem auf den Markt, was nicht nur die
Lok-Decoder-Adresse melden soll, sondern noch umfangreichere
sonstige
Informationen liefern kann (Zukunft).
Unter OpenDCC findet der Leser hierzu eine umfangreiche
Abhandlung.
Im Prinzip basiert die Lösung auf folgendem Verfahren:
Die Gleisspannung wird derzeit in regelmäßigen sehr kurzen
Abständen umgeschaltet, so daß die "Rechteckspannung"
entsteht. In diesen Umschaltmoment wird eine kurze Verzögerung
eingefügt, damit ist das Gleis für eine kurze Zeit von der
Zentrale / Booster abgeschaltet > spannungslos.
Innerhalb dieser Zeitspanne kann jetzt ein Lokdecoder eine
Meldung über die Gleise schicken, die dann von der Zentrale
aufgenommen und ausgewertet werden muß.
Der Lokdecoder muß zur Spannungspeicherung einen größeren
Kondensator besitzen, der in dieser Zeitspanne das Senden
ermöglicht.
Anmerkung:
Liegt nach der kurzen Verzögerung wieder die Gleisspannung an,
dann lädt sich der Kondensator wieder auf.
Die Kondensatoren aller auf der Anlage befindlichen Loks sind
elektr. gesehen parallel geschaltet, so daß sich ein
wesentlich höheres Gesamt "C" (Ladung) ergibt.
Elektr. gesehen beeinflußt ein Kondensator die Anstiegszeit
der Spannung; hier also auch indirekt der "Code-Bits".
DCC als "zentrales System" im Verbund mit dem
DCC-Meldeverfahren RailCom könnte dazu neigen, daß auf
mittelgroßen Anlagen die zeitliche Auslastung für die
Steuerung mittels PC-Modellbahn-Steuerungsprogrammen zu
Problemen führt.
Es bleibt abzuwarten, wie sich dieses Verfahren und die damit
verbundenen Komponenten im Modellbahn-Alltag bei
mittelgroßen Anlagen bewährt.
--Märklin
Mit mfx (M4) hat Märklin ein Meldesystem eingeführt. Dieses
hat allerdings eine ganz andere Funktion als das unter DCC
vorgestellt und das noch unter Selectrix vorzustellende
Verfahren.
Bei Märklin melden sich die Loks mit ihrer Lokdecoder-Adresse
beim Aufsetzen automatisch bei der Zentrale an. Die Zentrale
ordnet dieser Lokdecoder-Adresse eine "Modellbahn-Lok-Adresse"
zu.
Es findet also keine Identifikation über den Standort des
Fahrzeuges (Lok) auf der Anlage statt.
Anmerkung:
Jeder Lokdecoder hat eine eigene, fest vom Werk vergebene
Adresse. Die Adressen wiederholen sich nicht, lt. Märklin.
dezentrale Systeme
In diesem Beitrag wird in diesem Abschnitt nur das
Selectrix-System betrachtet.
Grundsätzlich wird das Gleis über zwei Leitungen an die Zentrale
oder einen Booster angeschlossen.
Über diese Leitungen erfolgt, wie bei den beiden anderen
Systemen auch, die elektrische Versorgung des Lokdecoders und
des Lok-Motors als auch die Protokollübermittlung.
Wie bei DCC wird auch hier die Polarität in sehr kurzen
Zeitspannen zur Erzeugung einer "Rechteckspannung" umgeschaltet.
Das Protokoll ist allerdings unterschiedlich zu DCC, als auch
gegenüber Märklin.
Booster werden über den sog. PX-Bus mit der Zentrale verbunden.
Über diesen Bus wird das Übertragungssignal von der Zentrale an
die Booster übermittelt. Die Booster prägen es dann innerhalb
ihres Versorgungsbereichs der Gleisspannung auf.
* Fahren
* Schalten
* Melden
Hinweis:
Im Jahr 2010 / 2011 wurde bei Selectrix die Adressenerweiterung
für Lokdecoder bzw. auch die Erweiterung des Funktionsumfanges
eines Lokdecoders eingefügt.
Dieses "neue System" wird als SX 2 tituliert; das frühere
erhielt (nachträglich) zur Unterscheidung die Bezeichnung SX
1.
Alle folgenden Angaben basieren vom Grundsatz her auf SX 1 und
nur die Erweiterungen werden speziell mit SX 2 angegeben.
Der Grund, die meisten Funktionalitäten stehen gleichermaßen
unter SX 1 als auch SX 2 zur Verfügung.
Aus Sicht der Zentrale ist das Gleis ein Teil des SX 0 -
Busses. Und nur an einem SX 0 Bus kann ein Lok-Decoder (Fahren)
angeschaltet werden !!
Alle anderen SX - Decoder (Schalten, Melden) können wahlfrei
über einen der beiden Busse, SX 0 oder SX 1, mit der Zentrale
verbunden sein. Beide Busse sind bei Einsatz des SX 1 Systems
vollkommen identisch aufgebaut; beim SX 2 System wird der SX 0
Bus, d.h. das Gleis unterschiedlich zum SX 1 Bus betrieben (s.
oben).
Da auf dem SX 0 Bus nach wie vor das SX 1 Protokoll
"gefahren" wird, können auch die bisherigen anderen
Decoder
dort angeschlossen sein.
Wegen der für SX 2 eingefügten Protokoll-Rahmen (s. oben)
kommt es dann allerdings für diese Decoder auch zu einer
"Verzögerung" beim Refreshen.
Es steht zu erwarten, das die Hersteller hier künftig
unterschiedliche Lösungen anbieten, z.B. mittels eines dritten
SX Busses, der dann analog zu dem SX1 Bus betrieben wird.
Über diese Busse werden auch die logischen Schaltkreise der
Decoder versorgt !!, während Spannungen zum Schalten, etc.
separat dem Decoder zuzuführen sind.
Beim Schalten zeigt sich -- im Gegensatz zu DCC und
Märklin -- ein großer Unterschied. Soll bei SX z.B. eine
Weiche geschaltet werden, dann setzt die Zentrale an den
Decoder nur eine Meldung ab, mit dem Inhalt > Weiche schalten
und die Weichenstellung.
Der Decoder übernimmt das Einschalten des Magnetartikels
(Spule) und beachtet die Einschaltdauer (Stromflußdauer) und
schaltet dann den Magnetartikel wieder aus.
Aus Sicht der Zentrale ist dies pro Schaltvorgang eine 50%
Busentlastung gegenüber DCC und Märklin und eine starke
Entlastung bei der Zeitverfolgung (Einschaltdauer des
Magnetartikels).
Das Prinzip des Meldens ist das gleiche wie bei DCC,
also eine ''Messung des Gesamtstroms'' im Meldeabschnitt.
Wobei der Meldedecoder hier an einen der SX-Busse
angeschlossen und mit der Zentrale verbunden ist.
Wollen Märklinisten allerdings, wie ich selbst, SX
verwenden, dann steht ihnen aufgrund des 3 Leiter-Gleises
auch die "Märklin-Variante" zusätzlich zur Verfügung.
Wie unter Märklin dargestellt, kann vom "Melde-Gleis
(Schiene)" eine Verbindung zum SX-Melder-Eingang geführt
werden. In diese Verbindung muß der Nutzer allerdings selbst
einen z.B. 10 k Ohm Widerstand einfügen. Damit funktioniert
eine "Masse-Kontakt" Meldung wie zuvor beschrieben.
--Konfigurierungshinweis für SX-Besetztmelder
Anmerkung:
Soweit sich die folgende Beschreibung auf das "Prinzip der
Strommessung" bezieht, haben die Hinweise auch Gültigkeit für
DCC.
Anschaltung am Gleis:
Die Besetztmelder müssen mit einem Anschluß an den / einen
Booster bzw. Zentrale angeschlossen werden und mit einem der
(meist) 8 Meldeeingänge an den zu überwachenden
Gleisabschnitt.
Meldeeingänge müssen sich immer auf den
Versorgungskreis eines Boosters (einer Zentrale) beziehen.
Wird dies nicht beachtet, so kommt es zu elektr. Problemen und
fehlerhaften Ergebnissen.
Anschaltung am SX-Bus:
Bei der Anschaltung eines Besetztmelders an einen der SX -
Busse einer Zentrale ist folgendes zu beachten:
- ältere Besetztmelder müssen an die Zentrale
angeschlossen werden, von der auch das Gleis versorgt wird.
Sie müssen taktsynchron zum Gleistakt betrieben werden
- neuere Besetztmelder sind intern anders aufgebaut, so
daß diese Anforderung nicht mehr besteht. Sie können an
einer zweiten Zentrale mit dem SX-Bus angeschlossen werden,
während die Meldeeingänge am Takt des Gleises hängen, also
an der ersten Zentrale.
- Besetztmelder '''OHNE''' Opto-Koppler, die das
Gleispotential vom Potential des Besetztmelders trennen,
''müssen'' an EINER Zentrale angeschlossen werden, d.h. eine
Verteilung auf mehrere Zentralen führt zu Problemen !!
- Besetztmelder '''MIT''' Opto-Koppler, die das
Gleispotential vom Potential des Besetztmelders trennen,
können auch auf mehrere Zentralen verteilt angeschlossen
werden.
Siehe hierzu auch die Informationen im Register
SX-System-Aufbau.
Unterscheidungsmerkmale zum
S88 Meldesystem (s. weiter oben)
Das SX-Meldesystem kann aus
beliebig vielen Besetztmeldern bestehen, die an einen der
verfügbaren SX - Busse einer Zentrale angeschlossen sind. Im
Extremfall (wegen der max. Adressen pro SX-Bus) müssen mehrere
Zentralen eingesetzt werden.
Jeder Besetztmelder ist frei
adressierbar, d.h. nachträglich hinzukommende Melder erfordern
keine Umadressierung der bestehenden.
Ein weiterer, sehr großer
Unterschied besteht in der Konfigurierbarkeit der
Besetztmelder für jeden Gleisanschluß, inkl. der Auswertung in
Hinblick auf eine Veränderung der Gleissituation (des
Indikators).
Damit erhält der Nutzer eine hohe Flexibilität.
Der Datenverkehr ist im
Vergleich zu S88 gut abgesichert, so daß die Störanfälligkeit
des SX-Busses sehr, sehr gering ist.
Fazit:
Das SX-Meldesystem ist flexibel und sicher !! Dies kommt auch
indirekt dadurch zum Ausdruck, daß in den Internet Foren kaum
etwas über dieses System zu lesen ist -- die Nutzer haben
demnach keine Probleme damit.
>> Selectrix II (SX 2) ---
und die neue Lok-Adressierung <<
Mit Einführung von SX 2 wurde das bisherige "Manko" von "nur
103 Lokadressen" aufgehoben.
Es lassen sich jetzt 9.999 Adressen für Lok-Decoder
vergeben; mehr als genug.
Ferner wurden zusätzliche Ausgänge auf dem Lok-Decoder zum
Schalten von Lok-Funktionen bereitgestellt.
Aber wie kann dann das alte Prinzip mit annähernd gleichen
Zyklen in der Decoderkommunikation eingehalten werden ??
Genau genommen gar nicht, denn eine Protokollübertragung
dauert wesentlich länger als bei SX1 (s. oben).
Wie bereits zuvor dargestellt, können nur max. 32
Lokdecoder in einem Zyklus angesprochen werden.
Die jeweilige max. Anzahl von "aktiven" Loks hat dabei zwei
gegengerichtete Auswirkungen. Ist ihre Anzahl gering, dann ist
zwar der gesamte refresh-Zyklus kürzer (mehr Wiederholungen
z.B. pro sek oder min.). Hingegen steigt die Häufigkeit der
Umgruppierungen und damit der Aufwand im Handling bzw. in der
"zeitlichen Wartezeit". Bei höherer Anzahl, ist dieses
Verhalten invers.
Eine weitere Betrachtung gilt der höheren Anzahl von zu
übertragenden Bytes, verglichen mit SX1.
Die höhere Anzahl bedingt typischerweise auch eine höhere
Fehlerrate in der Übertragung, damit wird wieder eher eine
schnelle Wiederholung wünschenswert.
Daraus läßt sich aber sofort ableiten, daß es einer
Strategie bedarf, nach der Loks und damit Lokdecoder in diesen
Zyklus eingebunden ("aktiv") oder wieder ausgestellt
("passiv") werden.
Desweiteren ist jeweils zu definieren, wie sich der
"passiv" - Zustand für den Nutzer auf der Anlage bemerkbar
macht.
Die Fa. Doehler & Haas hat dies so definiert, wenn der
Lokdecoder sich in der Fahrstufe 0 befindet UND ALLE sonstigen
Funktionen ausgeschaltet (off) sind, dann befindet sich der
Decoder im "passiven" Zustand und kann aus dem Zyklus
herausgenommen werden.
Auswirkungen auf den Betrieb (Beispiel)
Dies bedeutet, daß der Nutzer -- gleich ob im manuellen
Betrieb oder via PC -- diese Konstellation herbeiführen muß.
Ist die "Gleichzeitigkeitsgrenze" erreicht, bedeutet dies, daß
z.B. eine Lok dunkel geschaltet werden muß, während sie im
Bahnhof wartet, damit eine andere fahren kann.
Mir erscheint die Definition von passiv zu streng zu
sein, es wird sich zeigen, welche Änderungen aus der Praxis
einfließen werden.
Eine weitere Folge dieser "Erweiterung" ist, daß die
Schnittstelle Zentrale <> PC je nach Hersteller
unterschiedlich erweitert werden muß, damit der erweiterte
Adress- und Funktions-Raum auch genutzt werden kann.
* Identifikation von Lok-/Fahrzeug- Adressen im Selectrix -
System
''Diese Identifikations-Methode ist etwas "tricki".''
Wie bei DCC wechselt auch bei SX das Gleispotential an den
Schienen. Hierbei entsteht eine kleine Spannungslücke --
während diese bei DCC sehr viel größer sein muß !!
In dieser kurzen Phase entlädt sich ein kleiner Kondensator,
der sich auf dem Lok-Decoder befindet, über die Schienen und
den an der Schiene angeschlossenen Meldereingang und von dort
zum Booster / Zentrale und wieder zurück zum Gleis / Schiene >
Lok.
Der hierbei entstehende kleine Stromfluß (bei SX I ca. 1-2 mA;
bei SX 2 ca. 5 mA) wird vom Melder erkannt und ausgewertet.
Wie erfolgt nun die Zuordnung zur Lok-Decoder-Adresse ??
Die Kondensatorentladung erfolgt während der Übertragung der
Informationen an die Lok xyz.
Der "intelligente" SX-Melder registriert (merkt sich) die
jeweils gesendete Lok-Adresse. Folgt jetzt unmittelbar in
seinem Beobachtungs (Melde-) Abschnitt eine
Kondensatorentladung, dann kann er die Lokadresse diesem
Abschnitt zuordnen, was z.B. bei TC (TrainController) einem
Block entspricht.
Dadurch, das im SX 1 System alle 103 Adressen kontinuierlich
angesprochen werden, wird auch beim Aufgleisen die Lok UND der
Standort erkannt.
Im Vergleich mit DCC fällt auf, daß das DCC Meldesystem
sehr viel weiter ausgebaut ist als das von SX.
Hinweis:
Soll die SX-Identifikation eingesetzt werden, dann müssen nach
SX-Angabe alle in Lok und Wagen vorhandenen Birnchen / LEDs
auf einer Seite über eine schnell schaltende Silizium-Diode
verbunden werden.
Diese Diode verhindert "Querströme", die bei der
Kondensatorentladung auftreten würden und dann könnte keine
saubere Erkennung erfolgen.
Wenn Märklinisten SX und seine Melder einsetzen (s. oben),
dann muß aus solchen Gründen auch eine Diode in Serie zum
Widerstand geschaltet werden.
Achtung:
Das vorgenannte gilt für SX 1 Lok-Decoder.
Die Lok-Decoder, die im SX 2 Modus arbeiten, verhalten sich
zwar grundsätzlich ebenso,
ABER ...
wenn diese nicht als "aktiv" erfaßt sind, werden sie auch
nicht angesprochen und damit im heutigen Verfahren nicht
erkannt.
Dies gilt auch für das Aufsetzen von neuen Loks, die sind ja
auch noch nicht "aktiv" ohne eine explizite Anmeldung, d.h.
Auswahl mittels Zentrale, Handregler oder Steuerungsprogramm.
Welche Lösung seitens der Selectrix Lieferanten
angeboten werden wird, muß abgewartet werden (Stand 2011).
Allgemeines:
Die heutigen, modernen PC-Modellbahn-Steuerungsprogramme, wie
TC, benötigen keine solche Identifikation für den laufenden
Betrieb der Anlage.
Allerdings können solche Systeme hilfreich sein, wenn in
schwer einsehbaren Bereichen (z.B. Schattenbahnhöfen) manuell
- ohne PC-Programm - Zugbewegungen vorgenommen werden müssen.
Multiprotokoll-Zentrale und Decoder
Auf dem Markt werden zunehmend mehr Multiprotokoll- Decoder und
Zentralen angeboten.
Dies ist wohl primär als Marketing-Instrument der Hersteller
zu sehen, als auch ein Instrument beim "Verteilungskampf" von
Marktanteilen.
In den wenigsten Fällen werden private Modellbahner (außer
Clubs) eine Vielzahl und Vielfalt von Modellbahnen (Loks)
besitzen.
Auch wenn dies hier und da der Fall sein sollte, dann wäre ein
Decoder-Umbau auch eine gute Alternative zu einer
"Multiprotokoll-Anlage".
Mit mehreren Systemen (Protokollen) auf einer Anlage zu
arbeiten, ist nicht unproblematisch und bedarf vom Nutzer immer
ein "Mehrfach-Wissen" beim Aufbau, Betrieb und Pflege seiner
Anlage.
Aus technischer Sicht ist anzumerken, daß es immer zu
zeitlichen Verzögerungen beim "Umschalten" der Protokolle
kommt -- gegenüber einem Reinrassigen-System.
Es müssen von der Zentrale / Decoder die Umstellung in der
Gleisversorgung (Takt, Codierung) vorgenommen bzw. erkannt
werden.
Bei "zentralistischen Systemen" sind von solchen zeitlichen
Belangen nicht nur die Lok-Decoder betroffen, sondern
zusätzlich ALLE an dem Bus (Zentrale) angeschlossenen
Schaltdecoder.
Wenngleich sich die einzelnen Zeiten nur im µs / ms - Bereich
bewegen mögen, so können sich diese addieren. Hier ist ein
wesentlicher Faktor auch der Mix der Loks und ihre jeweils
aktuelle Nutzung.
Hinweis:
Die gegenwärtig von Doehler & Haas angebotenen Lokdecoder
werden bei der Erstinbetriebnahme auf eines der möglichen
Gleisformate (DCC, Märklin, Selectrix (1/2), je nach
verwendeter Zentrale, eingestellt.
Auf der Anlage arbeiten sie im Betrieb dann ausschließlich in
diesem Operationsmodus.
Einsatz auf Modellbahn-Anlagen
Labor v.s. Anlage
Es wird keinen Zweifel geben, daß diese
Multiprotokoll-Systeme in den Labors der einzelnen
Hersteller einwandfrei arbeiten.
Auf den unterschiedlichen Anlagen, insbesondere auf
mittelgroßen und dies im Zusammenwirken mit
PC-Anlagen-Steuerungsprogrammen, wie TC, kann es zu
zeitlichen Problemen bei der Abarbeitung der Steuerbefehle /
Melderabfragen kommen.
Dies insbesondere dann, wenn zentralistische Systeme wie DCC
und Märklin mit komplett unterschiedlichen Gleis-Signalen /
Busprotokollen zusammen als Multiprotokoll-System
betrieben werden.
In den verschiedenen Foren kann man solches immer wieder aus
den Fragestellungen herauslesen.
Beispiel >> Schalten
* Aufgabe
Schalten einer Weiche von TC heraus.
* Lösung: Märklin / DCC
TC sendet über den Bus PC <> Zentrale eine Meldung zum
Schalten der Weiche x in Stellung r.
Die Zentrale muß diese Meldung aufnehmen und in drei
Aktionen zerlegen ..
1) Meldung an zugehörigen Weichendekoder senden mit dem
Inhalt Ausgang (= Weiche x) einzuschalten (Stromfluß >
Magnetartikel Spule)
2) Zeit für Dauer der Einschaltung der Spule setzen und
abfragen, wann diese abgelaufen ist
3) Meldung an zugehörigen Weichendekoder senden mit dem
Inhalt Ausgang (= Weiche x) auszuschalten (kein Stromfluß
> Magnetartikel Spule)
TC sollte in dieser Zeitspanne KEINE weiteren z.B.
Weichenbefehle an die Zentrale senden. D.h. in TC ist eine
entsprechende "Wartezeit" einzutragen, diese sollte größer
sein als die unter 2) eingestellte Zeitdauer plus Reserve.
Diese Reserve wird in der Praxis benötigt, da davon
auszugehen ist, daß eine Busübertragung wegen Störungen
auch wiederholt werden muß.
Es können auch sonstige Aktivitäten "dazwischen kommen".
Anstelle von TC kann jedes andere
Steuerprogramm gedanklich gesetzt werden.
* Lösung: Selectrix
TC sendet über den Bus PC <> Zentrale eine Meldung zum
Schalten der Weiche x in Stellung r.
Die Zentrale muß diese Meldung aufnehmen und in
Aktionen zerlegen ..
1) Meldung an zugehörigen Weichendekoder senden mit dem
Inhalt Ausgang (= Weiche x) auf Stellung r zu schalten.
Der SX-Weichendecoder nimmt diese Meldung auf und zerlegt
diese in die Aktionen ....
1) Ausgang (= Weiche x) einschalten (Stromfluß >
Magnetartikel Spule)
2) Zeit für Dauer der Einschaltung der Spule setzen und
abfragen, wann diese abgelaufen ist
3) Ausgang (= Weiche x) ausschalten (kein Stromfluß >
Magnetartikel Spule)
TC sollte in der Zeit, in der die Zentrale beschäftigt
ist, keine weiteren Weichenbefehle senden.
Im Vergleich zum vorangegangenen Systemansatz ist diese
Belegung aber wesentlich kürzer.
Somit steht in TC auch nur eine sehr kurze "Wartezeit".
TC kann also in einer wesentlich höheren Sequenz
Aktionen (z.B. Weichen schalten) ausführen, da sowohl die
Auslastung der Zentrale als auch der Anlagenbusse pro
Aktion sehr viel geringer ist.
Anstelle von TC kann jedes andere
Steuerprogramm gedanklich gesetzt werden.
Anzahl Fahrstufen im Lok-Decoder >> Systembelastung
Dieses Beispiel gilt gleichermaßen für alle 3
betrachteten Systeme und betrachtet die Problematik nur
qualitativ.
* Aufgabe:
Es soll eine Lok aus der Fahrgeschwindigkeit Vg
innerhalb eines Bremsbereichs von z.B. L = 30 cm auf die
Kriechgeschwindigkeit Vk abgebremst werden, so daß mit
Erreichen des Haltebereichs die Lok sofort anhalten
(stoppen) kann.
* Gegeben:
Lok A mit 128 Fahrstufen
Lok B mit 31 Fahrstufen
Computersteuerprogramm - TrainController (TC)
Zentrale des jeweiligen Systems, angeschlossen über eine
serielle Schnittstelle an den PC
* Darstellung für Lok A:
TC berechnet nach Erkennen des Erreichens des
Bremsbereichs anhand von Vg und der Länge L sowie der
Zielgeschwindigkeit Vk und der Anzahl der Lok-Fahrstufen,
wie oft eine Fahrstufenreduzierung an die Zentrale zu
senden ist. Aus dieser Betrachtung ergibt sich auch die
optimale zeitliche Verteilung.
In dieser Betrachtung gehen wir mal von 100 zu schaltenden
Fahrstufen aus.
TC setzt also 100 Meldungen an die Zentrale ab und diese
"übersetzt" diese Information in das
entsprechende
Datenformat / Protokoll und schickt ebenfalls min. 100
Meldungen an den Lokdecoder.
Bei einer schlechten Gleisverbindung sind es in der Regel
mehr.
* Darstellung für Lok B:
Der erste Absatz von Lok A trifft genau so für Lok B
zu.
Allerdings gehen wir hier mal von 25 zu schaltenden
Fahrstufen aus.
Der dritte Absatz von Lok A trifft auch wieder für Lok B
zu; allerdings werden min. nur 25 Meldungen gesendet.
* Ergebnis der "gedanklichen Spielerei"
-- und das gilt sowohl für das Bremsen als auch
Beschleunigen --
Für Lok A werden 4 mal mehr Befehlsübertragungen benötigt
als für Lok B.
Das System ist also wesentlich stärker belastet.
Ob das menschliche Auge im "normalen"
Anlagen-Betriebsalltag einen wesentlichen Unterschied
feststellen kann ??, das muß jeder für sich herausfinden.
Allerdings ist davon auszugehen, daß zeitliche Engpässe
aufgrund des obigen Effekts sehr wohl bemerkbar sind, wenn
viele Zugbewegungen zeitlich parallel stattfinden.
Beispiel >> Fahren / Multiprotokolle
Wird mit unterschiedlichen Protokollen gefahren, das
geschieht bei Märklin bereits, wenn Motorola I / II und mfx
(M4) eingesetzt wird, dann muß die Zentrale jeweils komplett
die Gleistakte ändern als auch das Protokoll.
Das alles kostet Zeit. Bei manuellem Betrieb von zwei Loks
sicher kein Problem, jedoch mit z.B. TC und 15 Loks kann es
zu welchen kommen (wobei die Zahlen nur die Unterschiede
verdeutlichen sollen und keine absoluten Werte darstellen).
Entsprechendes gilt, wenn der Lok-Decoder mit mehreren
Protokollen betrieben werden kann. Dann muß der die
entsprechende "Vorauswahl" treffen. Auch das kostet Zeit.
In all diesen Fällen, kann es -- wie die vielen Anfragen im
TC-Forum zeigen -- unter den unterschiedlichsten
Randbedingungen zu Problemen kommen; sie müssen aber nicht
auftreten und vor allem sich nicht immer permanent äußern .
Auch der Betrieb mit SX2 wirkt sich, neben der längeren
Übertragungszeit des Protokolls, auch durch die
Lok-Verwaltung (Loks aktiv / passiv setzen) zeitlich recht
ungünstig aus.
Betreiber von SX2 Anlagen sollten dies bei größeren Anlagen
und vielen Wechseln entsprechend berücksichtigen.
Modellbahn Digitalsysteme ...
hier sollten ALLE genau hinschauen und nachfragen
Quellen für weitergehende Informationen
Die
hier aufgeführten Links sollen dem Leser die Möglichkeit
geben, sich weiter in diese Thematik einzuarbeiten.
Hinweise für "Beginner"
Viele Modellbahner starten mit "Startsets"
aus der "analogen Zeit" oder mit neuen "digitalen",
die der Händler "um die Ecke" anbietet.
In der Regel sind damit eine Zentrale und
ein paar Schaltdekoder vorhanden.
Erst im "zweiten Schritt" kommt dann die PC-
Steuerungssoftware, wie z.B. TC*, hinzu.
Benötigt werden jetzt erstmals Melde-Dekoder.
Und dies ist der Zeitpunkt, wo sich der
Nutzer genau informieren sollte und nicht zu schnell einem System
(Bus und Melde-Dekoder) den Zuschlag geben.
Denn wenn diese Produkte nicht dauerhaft störungsfrei arbeiten,
dann kostet das richtig Geld und Nerven !!! -- diese Erfahrung
mußten leider schon viele Modellbahner machen.
Da in aller Regel dann auch noch weitere
Schaltdekoder / Signaldekoder, etc. folgen, sollte man diese Dinge
wegen des auszuwählenden Bussystems mit in die Überlegungen
einbeziehen.
Wenn Sie hier eine Unterstützung
wünschen, dann melden Sie sich bitte per eMail.
HINWEISE zu mit
* markierten Worten
Alle Firmenbezeichnungen /
Firmennamen; Produktbezeichnungen / Produktnamen stellen keine
Werbung oder Empfehlung dar, sondern beschreiben nur die in diesem
Projekt individuell und subjektiv ausgewählten Produkt -
Hersteller bzw. Lieferanten als auch deren verwendeten Produkte
zur Anschauung, Darstellung und Beschreibung des eigentlichen Projekt
- Inhalts.
Analoges gilt auch für die eingetragenen
Links (s. hierzu Distanzierung auf der Link-Seite).
Der Leser soll selbst auf dem Markt
recherchieren und für seine Bedürfnisse selbst entscheiden, welches
Produkt er einsetzen will und wo er sich dieses beschaffen möchte.
In dieser Veröffentlichung verwendete
Produktnamen / Produktbezeichnungen sind von / durch den einzelnen
Hersteller(n) geschützt. Ihre Nutzung dient lediglich zur
Kennzeichnung / Beschreibung des Produktes selbst.
Analoges gilt für die erwähnten
Firmenbezeichnungen / Firmennamen.
|