Benutzer-Werkzeuge

Webseiten-Werkzeuge


railcom

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. Bei aktiven Channel 1 sendet ständig und unkontrolliert der Decoder seine Adresse auf das Gleis. Das hat zur Folge, dass der Detektor bei mehr als einer sendenden Lok im Channel 1 nichts mehr verstehen kann und evtl. auch falsche DCC-Adressen an das System meldet. Die Lok-Erkennung über Channel 2 ist eine feine Sache und bietet das Potenzial der Zukunft. Es antwortet nur die angesprochene Lok, es gibt keine Kollision von Nachrichten bei mehreren Loks, die Übertragung ist somit sauber und sicher. Leider wurde eine Antwort im Channel 2, in der Anfangszeit von Railcom von vielen Decoder Herstellern ignoriert. Selbst heute liefern manche Hersteller noch Decoder aus, die nicht laut Norm eine verpflichtende Antwort im Channel 2 senden. 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

In zahlreichen älteren Loks die noch mit Glühbirnen beleuchtet werden, ist diese Lampe oft einseitig direkt gegen die Schiene geschaltet.

Das zerstört die RailCom®-Nachrichten auf einer Polungsseite.

Für dieses Problem gibt es eine Abhilfe. Der Verbraucher (Glühbirne) muss mit dem „gemeinsamen Plus“ des Decoders verbunden werden. Im Notfall kann man diese Birnchen auch isolieren.

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 Hersteller 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 diesen Belegtmelder führen. Auch Weichenstraßen sollten für eine lückenlose Überwachung an das System angeschlossen werden. Die Daten im Rückkanal suchen sich nur dann den richtigen Weg über den korrekten Detektoren, wenn keine „verlockenderen“ Seitenpfade vorhanden sind. Diese können neben den schon erwähnten einseitigen Glühbirnen in der Lok auch detektorlose Pfade (z.B. Abschnitte ohne Melder) oder Pfade mit einem anderen Spannungsabfall sein. Wichtig ist, dass die ganze Gleisanlage gleichartig angeschlossen ist: gleichartige Belegtmelder, lückenlose Überwachung und immer die gleiche Betriebsspannung.

Werden Booster mit Nachrichtenlücke (Railcom-Booster) und alte Booster ohne BiDi auf der Anlage gemischt, ergibt sich ein Kurzschluss, wenn während der Cutout-Phase diese beiden Booster über ein Fahrzeug verbunden werden. Das bedeutet: man muss seine komplette Anlage (genauer gesagt alle Booster, welche Gleise versorgen) mit Railcom-tauglichen Boostern ausstatten. Das Timing für die Cutout-Lücke ist in der Railcom-Spezifikation nicht im Hinblick auf den Betrieb mehrerer Booster und sekundärseitigen Kurzschluss zweier Booster durch ein Fahrzeug über der Trennstelle genormt. Das hat zur Folge, wenn mehrere Booster von unterschiedlichen Herstellern zusammen verbaut werden und der Ausgang zweier Booster über einer Trennstelle verbunden werden, dass ein Booster noch Signal erzeugt, während der andere Booster schon sein cutout erzeugt! Das führt zum Kommunikationsverlust und Kurzschlüssen. Es empfiehlt sich daher, den gesamten Fahrbetrieb mit Boostern gleicher Bauart und mit gleicher Betriebsspannung auszurüsten.


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.txt · Zuletzt geändert: 2016/07/05 10:52 von 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki