Railcom - "Bi-Directional Communication" Für Dcc; Kurz Zusammengefasst Können Die "Railcom" - Aufgaben So Gegliedert Werden; Ständige Weiterentwicklung Der Railcom-Nutzung - ZIMO MS440C Bedienungsanleitung

MS-SOUND-Decoder MS440 bis MS990
4
RailCom - „Bi-directional communication" für DCC
"Bi-directional" bedeutet, dass im Rahmen des DCC Protokolls ein Informationsfluss nicht nur in Richtung zu den De-
codern stattfindet, sondern auch in die umgekehrte Richtung; also nicht nur Fahrbefehle, Funktionsbefehle, Stellbe-
fehle, usw. an die Decoder, sondern auch Rückmeldungen wie Empfangs-Quittungen, Geschwindigkeitsmessun-
gen, sonstige Zustandsinformation und CV-Auslesen aus den Decodern zur Digitalzentrale oder „lokalen Detektoren".
ZIMO Decoder aller Typen (sowie Digitalzentralen und Gleis-Rückmelder als Empfangsgeräte) waren schon seit den
1990er Jahren (lange vor RailCom) mit einer proprietären Form der „bi-directional communication" ausgestattet - der
„ZIMO Zugnummernerkennung". Dies war damals ein wesentlicher Unterschied zu Produkten des Mitbewerbs. In
Anlagen mit den bis 2010 gebauten MX9 Gleisabschnitts-Modulen wird weiterhin die ZIMO Zugnummernerkennung
verwendet, da MX9-Module NICHT mit „RailCom" arbeiten (die nachfolgenden „StEin"-Module hingegen schon).
Seit dem Jahr 2005 (kurz nach der Einführung durch die Fa. Lenz) sind alle ZIMO Decoder ausgestattet
für das in der Zwischenzeit genormte Rückmeldeprotokoll „RailCom" (RCN-217 bei Railcommunity -
VHDM - und S-9.3.2 bei NMRA). RailCom ersetzt auch die oben erwähnte ZIMO Zugnummernkennung.
Die grundsätzliche Funktionsweise von RailCom beruht darauf, dass der ansonsten kontinuierliche Energie- und Da-
tenstrom, also das DCC - Schienensignal, welches von der Digitalzentrale auf die Schiene gelegt wird, von kurzen
potenzial-freien Lücken (die "RailCom-Cutouts", max. 500 microsec) unterbrochen wird; in diesen Lücken können die
Decoder weitgehend ungestört Rückmelde-Informationen (als „RailCom-Nachrichten", insgesamt - beide Channels
zusammen - bis zu 48 bit lang) aussenden, welche von „lokalen Detektoren" (einzelnen isolierten Gleisabschnitten
zugeordnet) oder vom „globalen Detektor" in der Digitalzentrale selbst empfangen und ausgewertet werden.
Für die grundsätzliche RailCom Konfiguration relevante CVs:
CV Bezeichnung Bereich
0, 1, 2, 3,
#28 RailCom Konfiguration
65, 66, 67
Hochstrom
also Bit 3 = 1
eingeschal-
Grundeinstellungen
#29 0 - 63
Configuration data
(28 oder 128
Fahrstufen,
Einstellung der
Geschwindigkeits-
#136
Rückmeldung
0 - 255
oder km/h – Regelungs-
kontrollzahl bei Eichfahrt
In ZIMO Decodern (mittlerweile auch in den meisten Fremdprodukten) sind die RailCom-Funktionen
standardmäßig eingeschaltet; wenn dies nicht der Fall sein sollte, wird es also aktiviert durch
CV #29, Bit 3 = 1 CV #28 = 3
UND
falls die Geschwindigkeits-Rückmeldung (Tacho) nicht funktionieren sollte:
Default Beschreibung
3 Bit 0 - RailCom Channel 1 (Aussenden eigene Adresse)
Bit 1 - RailCom Channel 2 (Daten der eigenen Adresse)
bzw.
jeweils = 0: aus- = 1: eingeschaltet
67
Bit 6 - Hochstrom-RailCom (nur Großbahn-Decoder)
mit Bit 6,
= 0: aus = 1: Hochstrom (wenn Großbahn)
Bit 0 - Richtungsverhalten
14 =
0 = normal, 1 = umgekehrt
Bit 1 - Fahrstufensystem (Anzahl Fahrstufen)
1
0000 110
0 = 14, 1 = 28 Fahrstufen
Bit 2 - Automatische Umschaltung auf Analogbetrieb
(„RailCom"
0 = aus, 1 = eingeschaltet
Bit 3 - RailCom („bi-directional communication")
tet),
0 = ausgeschaltet 1 = eingeschaltet
und
Bit 4 - Auswahl der Geschwindigkeitskennlinie
Bits 1,2 = 1
0 = Dreipunkt-Kl. nach CV #2, #5, #6
1 = freie Kennlinie nach CV #67 ... #94
Bit 5 - Auswahl der Fahrzeugadresse (DCC)
und autom.
0 = „Kleine" Adresse laut CV #1
Analogbet
1 = „Große" Adresse laut CVs #17+#18
Korrekturfaktor für die Geschwindigkeits-Rückmeldung
über RailCom.
128
oder (siehe Kapitel 5.8)
Nach Eichfahrt kann hier ein Wert der internen Ge-
schwindigkeitsberechnung ausgelesen werden.
(oder = 67, wenn Großbahn-Decoder),
CV #158, Bit 2 = 1
oder ausnahmsweise (falls MX31ZL als Zentrale):
In den ersten Jahren nach Einführung von RailCom wurde dessen Potenzial nur für zwei Möglichkei-
ten intensiv genutzt: zur Adress-Meldung für isolierte Gleisabschnitte (das, was zuvor die ZIMO Zug-
nummernerkennung geleistet hat), sowie zum
(auch „Programming-on-the-Main" = „PoM" genannt). Dies hat sich - in etwa seit dem Jahr 2015 - ge-
ändert: DCC-Decoder ohne RailCom sind kaum noch vorstellbar.
Kurz zusammengefasst können die „RailCom" - Aufgaben so gegliedert werden:

Durch sämtliche RailCom-Antworten (zunächst unabhängig vom Inhalt der Nachricht selbst) wird
der Empfang der jeweils vorangehenden
die "Bandbreite" der gesamten DCC-Steuerung erhöht. Letzteres ist der Fall, weil quittierte DCC-
Befehle nicht wiederholt werden müssen.
 „RailCom Channel 2" (der jeweils zweite - mit 36 bit größere Teil - jeder RailCom-Gesamtnach-
richt): Darüber werden, jeweils als Antwort auf einen DCC-Befehl an die eigene Decoder-Adresse,
aktuelle Daten aus dem Fahrzeug zum „globalen Detektor" der Digitalzentrale gemeldet; dazu ge-
hören beispielsweise (je nach Auslegung) die "echte" (gemessene) Geschwindigkeit, Routing- und
Positions-Codes, simulierte "Treibstoffvorräte", aktuelle Werte der CVs auf Anfrage (CV-Program-
mieren und -Lesen im Operational Mode oder „Programming-on-the-Main" – PoM)
 „RailCom Channel 1" (der jeweils erste - kleinere Teil mit 12 bit): Darüber wird (normalerweise
nichts anderes als) die eigene Decoder-Adresse gemeldet, und zwar als Antwort auf sämtliche
DCC-Befehle (also vor allem auf diejenigen, die NICHT das eigene Fahrzeug adressieren, daher
bis zu 100 Mal / sec). Da somit alle Decoder gleichzeitig Channel 1 - Daten aussenden, sind diese
nur auf isolierten Gleisabschnitten durch „lokale Detektoren" lesbar, wenn sich dort gerade nur ein
einziges Fahrzeug mit RailCom-aktiviertem Decoder befindet.
Im „globalen Detektor" des Basisgerätes überlagern sich hingegen die gleichzeitigen Channel 1 - Daten der ver-
schiedenen Decoder und sind daher nicht lesbar, was aber sowieso keinen Sinn hätte, da die Adressen nur lokal
(auf den einzelnen isolierten Gleisabschnitten) von Interesse sind.
Die obige „Kurzbeschreibung" der RailCom-Technik bezieht sich nur auf die „normalen" Vorgänge; es gibt in der
Praxis (auch in den Normen selbst) zahlreiche Abweichungen und Ausnahmen in den Channel-Zuteilungen, u.a.
Ständige Weiterentwicklung der RailCom-Nutzung:
Da laufend neue RailCom-Anwendungen geschaffen und in Decodern und Digitalgeräten implemen-
tiert werden, wobei ZIMO häufig eine Vorreiter-Rolle einnimmt, können Betriebsanleitungen diesbe-
züglich nicht immer aktuell gehalten werden.
Daher gibt es hier nur eine kurze Auflistung von Anwendungen und ins Auge gefassten Anwendungen,
die entweder schon realisiert wurden (je nachdem, wann dieser Text gelesen wird), gerade in Arbeit
sind, oder vielleicht in näherer Zukunft realisiert werden (in ZIMO Decodern und Systemen):
Klassische Anwendungen:
Adress-Meldung (Anzeige auf Ziffernanzeigen oder Computer-Stellwerk), CV-Programmieren und
-Lesen, Geschwindigkeits-Meldung (zur Anzeige auf Tacho am Bediengerät), Richtungszustands-Mel-
dung (zur Anzeige Vor-/Rückwärts sowie Ost-West am Bediengerät und autom. Steuerungseingriffe).
Erweitere Meldungen aus den Fahrzeugen:
HLU&ABC-Meldungen (zur Anzeige am Bediengerät und autom, Steuerungseingriffe), Zielentfernung
und Zielgeschwindigkeit (zur Anzeige auf „Echt"-Führerständen), zurückgelegte Wegstrecken, Stei-
gungen, Gefälle, Kurven (Decoder mit Sensoren), Höhendifferenzen, Drehwinkel, Streckenprofile, ak-
tuelle Position, Decoder-bezogene Daten (Motorstrom, Temperatur, ...).
Erweiterte betriebliche Anwendungen:
ZIMO Aufgleissuche, Adressanmeldung und -zuordnung für neue Fahrzeuge (nach RCN-218), GUI
(Graphical-User-Interface) aus dem Fahrzeug zu den Bediengeräten), Übermittlung größerer Daten-
mengen aus den Fahrzeugen und Zügen (z.B. Streckenprofil oder Vorbild-Gewichte und -Masse der
Wagen eines Zuges), Übermittlung von Textnachrichten aus dem Zug zur Anzeige am Bediengerät.
= 0
„RailCom" ist ein eingetragenes Warenzeichen der Lenz Elektronik GmbH.
Seite 41
CV-Programmieren und -Lesen im Operational Mode
DCC-Befehle bestätigt, was die Betriebssicherheit und