Benutzer-Werkzeuge

Webseiten-Werkzeuge


railcom

Dies ist eine alte Version des Dokuments!


RailCom®

Bis vor ein paar Jahren war die Kommunikation auf einer digitalen Modellbahn eine Einbahnstraße gewesen, das bedeutete dass die gesendeten Informationen von der Zentrale zu den Decodern geschickt wurden und vom Decoder kam nichts zurück! Die DCC-Befehle wurden zur Lok geschickt in der leisen Hoffnung, es möge schon am Ziel ankommen. Man spricht hier von unidirektionaler Kommunikation, benutzt wird als Protokoll z.B. DCC, das es erlaubt, über 2 Drähte (die beiden Schienen) Information und Strom für den Fahrbetrieb gleichzeitig zu übertragen. Mit steigendem Funktionsumfang der Loks und besser werdender Technik, entstand der Wunsch nach einer bidirektionaler Kommunikation und Absicherung der Datenübertragung. Durchgesetzt hat sich hierbei eine Technik mit Zeitmultiplex genannt RailCom® (das ist der entsprechende Markenname der Fa. Lenz). In der NMRA wird diese Technik als DCC-BiDi bezeichnet.

RailCom® ist ein bidirektionales Kommunikationssystem, genau wie bei MFX kann hier der Lok-Decoder nicht nur Befehle empfangen, sondern auch senden (Bidirektional = in 2 Richtungen). Es handelt sich dabei nicht um ein generelles neues Protokoll, sondern man kann es als DCC-Erweiterung betrachten. Deshalb können auch DCC-Lokdecoder ohne der RailCom®-Funktion mit einer RailCom®-fähigen Zentrale fahren und umgekehrt. Um jedoch Daten vom Decoder zu empfangen, sind entsprechende RailCom® fähige Decoder, Zentralen und Booster notwendig.


Was bringt RailCom®

Komfort und Sicherheit:

Eine Lok wird aufgegleist und man erkennt die Lok sofort im Gleisstellpult des Computers, mit dem richtigen Namen an der richtigen Stelle im Gleisbild. Es wird die richtige Lokrichtung der Lok korrekt angezeigt! Dadurch, dass eine Lok immer lokalisierbar ist, kann ein PC-Programm „Falschfahrten“ erkennen und eine Geisterfahrt (z.B. wegen einer nicht oder nicht richtig gestellten Weiche) stoppen.

Genaueres Halten und bequemes Programmieren:

Vom Decoder werden empfangene Befehle quittiert, müssen nicht mehr von der Zentrale auf Verdacht wiederholt werden und somit können neue Befehle schneller ans Gleis transportiert werden. Die verfügbare Bandbreite von DCC, wird mit RailCom® besser ausgenutzt. Die Decoder melden auch die gefahrene Ist-Geschwindigkeit zurück an das PC-System, dadurch kann die Berechnung des Aufenthaltsortes der Lok genauer bestimmt werden.

Von den Lokdecodern können an jeder Stelle der Anlage Parameter ausgelesen und übertragen werden. Alle CV-Werte eines Decoders lassen sich binnen 2s auslesen, dadurch wird eine Optimierung der Fahreigenschaften wesentlich vereinfacht. Das Verstellen von Motorparameter während des Fahrbetriebes auf der Anlage, ermöglicht ein sofortiges Erkennen der Veränderung.

Vereinfachte Wartung und gezielte Reinigung:

Der Decoder kann Fehlerzustände an das System melden. Mit Hilfe dieser Information kann eine erhöhte Stromaufnahme des Motors oder die Überschreitung bestimmter Grenzwerte (Betriebsdauer) auf eine fällige Wartung hinweisen.

Die Lok kann einen Zustandsbericht über das Gleis senden, wie oft es zu kurzzeitigen Stromausfällen durch die verschmutzten Gleise oder Räder gekommen ist. Eine entsprechende Auswertung entscheidet, ob die Meldung immer an der gleichen Stelle vorkommt (dann wird ein Reinigungszug auf diesen Gleisabschnitt geschickt) oder immer die gleiche Lok den Fehler bringt (Radkontakte bzw. Räder kontrollieren).

Mehr Spielwert:

RailCom® ermöglicht auch, dass eine Lok realistischer betrieben werden kann. Es wird virtuell Kohle und Wasser nachgefüllt, diese Vorräte gehen nach und nach zu Neige und die Lok meldet die aktuellen Füllstände an das System. Der Anwender muss somit rechtzeitig an das „Wasserfassen“ denken.


Wie funktioniert RailCom®

Bei RailCom® werden abwechseln Daten zur Lok und von der Lok übertragen, man spricht hier von Zeitmultiplex. In den normalerweise kontinuierlichen Datenstrom von der Zentrale zur Lok werden winzige Unterbrechungen eingebaut. Diese Unterbrechungen nennt man „cutout“ und diese sind so kurz, dass das Fahrverhalten der Lokomotiven nicht beeinflusst wird.

In der Unterbrechungspause darf (und soll!) der Lokdecoder Daten an die Zentrale zurücksenden.

Als „Datenleitung“ für die Übertragung der Railcom-Nachrichten werden die Schienen verwendet. Das passiert aus Sicht des Anwenders also quasi parallel zu den digitalen Steuer- und Schaltbefehle und erspart somit einen zusätzlichen Verkabelungsaufwand.

Die Unterbrechungspause ist selbst wieder in zwei Abschnitte gegliedert, diese werden mit Channel 1 und Channel 2 bezeichnet. Im Channel 1 ist ein ständiges Senden (=Broadcast) der eigenen DCC-Adresse der Lok vorgesehen. Im Channel 2 ist eine gezielte Antwort des aktuell im vorangehenden DCC-Befehl angesprochenen Decoders vorgesehen. Nur dieser Decoder darf (und muss!) antworten.

In der CV28 wird (einheitlich bei allen Decodern) festgelegt, ob der Decoder im Channel 1 oder 2 oder in beiden Channel sendet.

Bit 0 bedeutet: Senden in Channel 1

Bit 1 bedeutet: Senden im Channel 2

Diese Rückübertragung muss mit einem sogenannten Detektor ausgewertet werden, das kann an verschiedenen Stellen erfolgen:

  • Ein globaler Detektor sitzt an einer zentralen Stelle (typischerweise in der Zentrale).
  • Lokale Detektoren sind verteilt und sind den jeweiligen Gleisabschnitten zugeordnet.

Ein globaler Detektor erkennt naturgemäß keine Ortsinformation, er kann nicht auswerten, wo auf der Anlage die Lok gerade steht, deren Nachricht er gerade detektiert. Lokale Detektoren sind da im Vorteil. Sie wissen, dass die Lok gerade bei Ihnen sein muss und können die Ortsinformation zusammen mit der Loknachricht weiter geben.

Damit entsteht eine neue Qualität der Belegtmeldung. Nicht nur „hier ist belegt“, sondern „hier fährt Lok 123“.

Diese lokalen Detektoren verfügt der GBM16T auf jedem seiner 16 Gleisbelegtmelder und ermöglicht das Erkennen von bis zu vier DCC-Decodern auf einem Gleisabschnitt!


RailCom® sicher einsetzen

Der Channel 1 ist bei mehreren Loks in einem Abschnitt problematisch und sollte bei funktionierenden Channel 2, vollständig deaktiviert werden. Der Channel 2 ist der sichere Weg für eine fehlerfreie Kommunikation, wenn das von jedem Hersteller auch gesendet werden würde!

Durch die Mitwirkung vieler OpenDCC Anwendern, entstand eine Übersicht, welcher Hersteller sich wie gut an die Railcom-Norm hält und stellt dessen technische Kompatibilität dar:

http://www.opendcc.de/info/railcom/railcom_decoder_overview.html

Nur Updatefähige Decoder einsetzen und auch mal überprüfen, ob der Hersteller nicht nur Updatefähigkeit verspricht, sondern das auch lebt! Hier ist z.B. eine Überprüfung anzuraten, ob der Hersteller auch seine bisherigen Decoder pflegt und wann er zum letzten Mal eine neue Version bereitgestellt hat. Die beiden Herstellern Zimo und D&H, agieren hier vorbildlich!

Beim Anlagenbau einen Gleisbesetzmelder verwenden der lokale Detektoren besitzt (z.B. den GBM16T von OpenDCC / Fichtelbahn). Diese Belegtmelder möglichst in gleicher Technik und alle Gleisabschnitte über Belegtmelder führen. Auch Weichenstraßen sollten für eine lückenlose Überwachung an das System angeschlossen werden.

Bei Einsatz mehrerer Booster darauf achten, dass diese gleichartig laufen, sowohl was Spannung als auch genaues Timing der Cutout betrifft. Hier bietet sich an, dass man den gleichen Boostertyp vom gleichen Hersteller verwendet und keinen Mischbetrieb auf der Anlage verbaut.


Hinweis:

RailCom® und RailComPlus® sind eingetragene Warenzeichen der Firma Lenz Elektronik GmbH in Hüttenbergstrasse 29, D-35398 Giessen und der ESU electronic solutions ulm GmbH & Co. KG in Edisonallee 29, D-89231 Ulm. Zur Erhöhung der Lesbarkeit des Textes haben wir darauf verzichtet, bei jeder Verwendung des Begriffes darauf zu verweisen.

railcom.1397812745.txt.gz · Zuletzt geändert: 2016/07/05 10:48 (Externe Bearbeitung)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki