Benutzer-Werkzeuge

Webseiten-Werkzeuge


railcom

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
railcom [2014/04/18 11:02] – [Was bringt RailCom®] fichtelbahnrailcom [2016/07/05 10:52] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 24: Zeile 24:
 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. 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.
  
-{{ :monitor:bidib-monitor_melder.jpg?600 |}}+{{ :monitor:monitor_railcommelder.jpg |}}
  
 **Vereinfachte Wartung und gezielte Reinigung:**  **Vereinfachte Wartung und gezielte Reinigung:** 
Zeile 32: Zeile 32:
 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). 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).
  
-{{ :allgemein:gleisreinigung_reinigungszug.jpg?500 |}}+{{ :allgemein:gleisreinigung_reinigungszug.jpg?600 |}}
  
 **Mehr Spielwert:**  **Mehr Spielwert:** 
Zeile 74: Zeile 74:
 Nicht nur **"hier ist belegt"**, sondern **"hier fährt Lok 123"**. 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 somit das Erkennen von bis zu vier DCC-Decodern auf einem Gleisabschnitt!+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!
  
  
 ---- ----
-===== Wie kann ich RailCom® sicher einsetzen=====+===== 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+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...
  
 <WRAP center round tip 80%> <WRAP center round tip 80%>
Zeile 88: Zeile 88:
 </WRAP> </WRAP>
  
 +{{:allgemein:lok_analog_nach_digital.gif |}}
  
-{{ :allgemein:mxulfa_zimoupdate.gif?200|}} +In zahlreichen älteren Loks die noch mit Glühbirnen beleuchtet werden, ist diese Lampe oft einseitig direkt gegen die Schiene geschaltet
-Nur Updatefähige Decoder einsetzen und auch mal überprüfenob 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. Bei 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 angeschlossen werden.+**Das zerstört die RailCom®-Nachrichten auf einer Polungsseite.** 
  
-Bei Einsatz mehrerer Booster darauf achten, dass diese gleichartig laufensowohl was Spannung als auch genaues Timing der Cutout betrifftHier bietet sich an, dass man den gleichen Boostertyp vom gleichen Hersteller verwendet und keinen Mischbetrieb verbaut.+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. 
 + 
 + 
 +{{ :allgemein:mxulfa_zimoupdate.gif?250|}} 
 +Nur Updatefähige Decoder einsetzen und auch mal überprüfenob 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. 
 + 
 +{{ :gbm:gbm16t_schattenbahnhof.jpg?700 |}} 
 + 
 +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.
  
 ---- ----
railcom.1397811739.txt.gz · Zuletzt geändert: 2016/07/05 10:48 (Externe Bearbeitung)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki