THEMA: Railcom-fähige Rückmeldebussysteme

Hallo Werner,

schau mal hier:

http://www.digital-plus.de/digitalplus-railcom.php

Gruß
Karl

Hallo Karl,

danke für den Hinweis. Ich habe den Eindruck, dass Lenz dort nicht wirklich weiter gemacht hat. Z.B. dieser LRC135 ist scheinbar nie auf den Markt gebracht worden. Und der der LCR135 sollte seine Informationen per USB dem Computer respektive der Steuersoftware weiterreichen.

Grüße - Werner P

Seien wir froh, dass der "Vater von DCC" auf seine alten Tag' lieber mit der Eisenbahn (Lenz Spur 0) spielt als sich neue Patente auszudenken

Grüße, Peter W.

Hallo Peter,

da magst du recht haben.. Ich war bei der Intermodellbau in Dortmund auf deren Stand. Der neue Handregler, nun ja ich sage mal LH90 Version 2.0!
Und die drahtlose Variante, die sie sich ausgedacht haben, braucht mehr Drähte als eine kabelgebundener Handregler.
Ich bin von den Neuheiten von Lenz, was die digitale Steuerung anbetrifft, enttäuscht.

Grüße - Werner P

Hallo Werner,

du kannst dir auch Bidib anschauen ( https://www.fichtelbahn.de/ oder https://www.opendcc.de/bidib/overview/overview.html ).
Mir gefällt das ganz gut. Man muss sich eine Weile einarbeiten (ob das bei anderen Herstellen weniger Arbeit ist weiß ich nicht) und auch mal was basteln. Aber es funktioniert gut und im Forum bekommt man auch gute Unterstützung von den Leuten, die das entwickeln. Leider hat der Bus es bisher nur zu wenigen Herstellern geschafft. Es gibt auch einen S88 Adapter, falls du da schon was haben solltest.

Grüße,
Moritz

Hallo Moritz,

auf bidib-System bin ich durch einen Freund auch aufmerksam geworden. Irgendwie empfinde ich das als zu sehr computerlastig (Bauchgefühl). Aber es ist meine potentielle B-Variante.

Grüße - Werner P

Hallo Frank,

danke für den Link. Tams macht es ebenso, wie von Herrn Lenz mal geplant, sprich die Informationen werden direkt dem PC und damit dem Steuerprogramm, zugeführt.

Grüße - Werner P

Hallo Werner,

ja Bidib ist sehr computerlastig. Aber wie möchtest du mit Railcom ohne einen Computer arbeiten? Sicherlich, du kannst Anzeigen für die Lokadresse in einem Rückmeldeabschnitt irgendwo einbauen, aber sonst?
Vielleicht erzählst du ein bisschen genauer, was du dir von der Steuerung erwartest.

Grüße,
Moritz

Hallo Moritz,

klar will ich den Computer zur Steuerung nutzen.

Meine Frage zielte auf grundsätzliche Möglichkeiten, die von den industriellen Produkten genutzt werden.

Wenn ich das richtig interpretiere, so gibt es grundsätzlich wohl zwei Möglichkeiten. Einmal so wie es Lenz, Tran usw. machen, nicht über die Zentrale sondern über den Computer.
Das bidib-System verknüpft die Zentrale in der alles zusammenläuft mit dem Computer.
Roco (Z21) und Digikeijs DR5000 nutzen den LocoNet-Bus und führen die Informationen dann dem Computer zu.

Habe ich das richtig verstanden?

Grüße - Werner P

Hallo Werner,

mit Lenz und kenne ich mich nicht so genau aus. Aber ich nehme mal an, dass man da auch nicht viele USB-Kabel zum Computer legt und die Komponenten einzeln anschließt?

Bei Bidib werden die einzelnen Componenten mit Ethernetkabeln untereinander verkabelt, der Master (die "Zentrale") verwaltet die Kommunikation auf diesen Kabeln und zum Computer. Also irgendwie läuft schon alles dort zusammen, aber verwaltet wird das nicht vom Master. Z.B. über Belegtmeldungen auf anderen Komponenten am Bus führt der nicht Buch, er leitet nur die Daten weiter an den Computer und zurück. Der Computer selbst muss die Belegtmeldungen verwalten. Dadurch wird das einfach erweiterbar, weil der Master eben nicht wissen muss, was wo genau angeschlossen ist und welchen Effekt das haben soll - das muss man am Computer festlegen.

Unabhängig von dieser Aufgabe ist der Master auch ein Booster, erzeugt also ein DCC Signal, dass dann (natürlich nicht über die Ethernet-Kabel) an andere Komponenten weitergegeben wird. Das ist aber - vermute ich - einfach so entstanden, weil es keinen Sinn macht, eine extra Komponente für die Kommunikation zum Computer zu haben. Die selbe Hardware kann man auch als zusätzlichen Booster einsetzen. Konfigurieren kann man das alles aber nur über den Computer (Konfigurations-CVs des Boosters aber auch z.B. Servopositionen beim Bidib-Servodekoder). Du kannst aber auch bestehende Zubehördekoder ans DCC Signal anschließen (das wird dann wie gehabt programmiert), die haben dann natürlich nicht die  Möglichenkeit der Bidib-Kommunikation.

Vielleicht hilft dir das ein bisschen bei der Entscheidung.

Grüße,
Moritz

Hallo Werner,
nein, hast du nicht.

Grundsätzlich ist es so: Die von den Loks ausgesandten Railcom-Meldungen werden im jeweiligen Abschnitt über den Belegtmelder gesammelt und über den Bus zur Zentrale transportiert. Hier besteht schon die erste Hürde, die bisherigen Bus-Systeme sind für eine solche Last nicht ausgelegt und schaffen fast nur Adressrückmeldung. Wenn du die Möglichkeiten von Railcom wirklich nutzen und dich nicht nur auf das Auslesen der Adresse beschränken willst, wirst du um BiDiB kaum herum kommen.

Wenn die Meldungen in der Zentrale angekommen sind, müssen sie irgendwie ausgewertet werden. Das man prinzipiell in der Zentrale machen, sofern diese ein Display und Gleisbild etc. hat, wenn man einen Rechner mit Steuerungssoftware nutzt, dann sind diese Daten dort aber in jedem Fall sinnvoller aufgehoben. Dabei spielt es keine Rolle, ob man Lenz, OpenDCC oder sonstwas nutzt. Wenn du Railcom nutzen willst, müssen die Daten zur Steuerungssoftware kommen.


Hier besteht keinerlei Unterschied zwischen den Zentralen, lediglich der Bus ist anders. Wie ich oben schon schrieb ist das LocoNet für Railcom nicht die erste Wahl, weil zu beschränkt. Der Weg der Railcommeldungen ist im Prinzip also gleich:
Lok -> Gleis -> Belegtmelder -> Bus -> Zentrale -> USB / Netzwerk,... -> PC


Viele Grüße
Carsten

Hallo Carsten,

danke dir für die Richtigstellung, auch für die Information bzgl. des LocoNet-Bussystems.

Grüße - Werner P

Hallo Werner,

ich weiß nicht, wie groß deine Anlage ist. Vielleicht legst du dir einfach mal einen Master und zwei Rückmelder zu (mit 32 Abschnitten kann man ja schon was machen) und probierst aus, wie du damit klar kommst. Preislich ist das glaube ich bei um 250 Euro. Wenn es dir dann nicht gefällt, findest du bestimmt jemanden, der dir das abnimmt.
Ich habe das ähnlich gemacht und werde demnächst erweitern (aber bei mir reichen die 32 Abschnitte schon für einen sinnvollen Fahrbetrieb aus, deshalb war das mit der Erweiterung nicht so eilig). Vielleicht kennst du auch jemanden, der in der Nähe wohnt und wo du dir das einmal anschauen kannst.

Grüße,
Moritz

Folks!
Es gibt bei RailCom zwei unterschiedliche Signalquellen: die local detectors an den Besetztmeldern und den globalen am Booster/Zentrale. Wenn man von etwa 80 DCC Befehlen pro Sekunde ausgeht können nach jedem DCC Befehl durch die mehrbytigen Antworten der Decoder große Mengen Daten entstehen. Jeder Decdoer broadcastet seine Adresse und zusätzlich können die Decoder im Kanal 2 auf zuvor gestellte Fragen antworten. Die klassischen MoBa Busse funktionieren immer noch mit etwa 9600-16000Baud. Da bekommt man die Datenmengen einfach nicht durch. Daher hat man auch lange Zeit versucht RailCom aufzuhalten weil die Digitalhersteller keinen Bus haben durch den man die RailCom Antworten durchleiten kann.

Der Ansatz von Lenz abermals einen weiteren Bus zu machen, oder jeden Besetztmelder an USB anzuschließen was wohl nicht der Weisheit letzter Schluss. Man braucht schnellere Bussysteme und vor allem auch Besetztmelder die redundante Daten verdichten. Also ein Besetztmelder der schon gemeldet hat daß der Decoder 4711 in seinem Bereich ist muß das nicht 80 mal pro Sekunde widerholen. Das Entlastet die Bussysteme. Nur solche gescheitere Besetztmelder sind noch rar. BiDiB und die diversen CAN Bus Varianten sind derzeit die einzig brauchbaren, weil ausreichend schnellen Bussysteme im Rennen.

BiDiB will zusätzlich die verschiedenen Hersteller miteinander verbinden und das will keiner außer die Gruppe rund um Kufer / Fichtelbahn. Die großen Hersteller befürchten einfach ein Support Chaos wenn man Regler/Bestetztmelder/Zentrale/Booster/PCInterface von unterschiedlichen Herstellern zusammen spannt. Mein Eindruck ist, die Vielfalt der Geräte würde dann die Sache zu komplex werden lassen. Daher macht ESU Roco und ZIMO jeweils ihr eigenes Ding. Beide sind da aber eher langsam unterwegs, wobei ESU verfügbare Produkte hat und ZIMO seit etwa 10 Jahren "in kürze" fertig ist. Roco scheint da mit der Z21 viel zu bewegen, der ZIMO CAN Bus in dem Ding ist sicher auch von Vorteil.

Gelangen die Daten zur Zentrale oder zum PC Interface dann muß die PC SW auch noch was damit anfangen können. Da ist bisher auch kaum etwas passiert. Mein Eindruck ist daß man bisher nur an Adressmeldungen denkt. Das ist schade weil das gibt es seit den frühen 1980'ern dafür hätte man RailCom nicht erfinden müssen  - schlag nach bei Digitrax mit seinem Transponding oder ZIMO mit den Zugnummernimpulsen.

Man kann mit RailCom noch andere Dinge tun wie zum Beispiel einen Tacho anzeigen der die tatsächliche Geschwindigkeit zeigt, statt der derzeit angezeigten Simulation die lediglich den Geschwindigkeitsregler in eine Tachonadel wandelt. Wenn man mit ABC einen Zug stoppt sollte der Tacho schon auf 0 wechseln. Das passiert aber heutzutage AFAIK nur bei ZIMO. Es gibt noch weitere Anwendungen die keinen Stellpult PC nötig machen. Virtuelle Verbrauchsgüter ist so etwas, Kohle, Wasser, Diesel. Oder die ost/west Richtungsanzeige damit könnte man feststellen ob man im Kopfbahnhof an den Prellbock oder hinaus auf's Gleis steuert. Das ist ein wesentlicher Unterschied gegenüber vor/zurück. Man hat hier ähnliches wie in der Analog Welt wider zur Verfügung unabhängig wie die Lok aufgegleist ist. Automatische Vergabe von Lokadressen (Anmelden der Lok), Bilden von Mehrfachtraktionen, dunkeltasten von Lichtern, das alles und noch mehr lässt sich mit RailCom Info machen.

Nur dazu braucht es auch die Infrastruktur. Insofern meine ich wird man am ehesten etwas von den großen Digitalherstellern zu sehen bekommen, m.a.W. ESU, ZIMO, Roco. Die haben die Infrastruktur an Zentrale, Rückmelder mit RC Leser und Decoder. Da hat es ein unabhängiges System wie BiDiB schwerer voran zu kommen, weil anfangs vermutlich einiges davon proprietär sein wird und erst nach und nach genormt werden wird.

Derzeit sollte man Infrastruktur kaufen die Aussicht auf längerfristige Verwendung hat. Also Decoder die RC können und Updatebar sind. Besetztmelder gibt's derzeit mit gutem Bussystem nur die Dinger von ESU und das neue Ding von Roco. Das StEin Modul von ZIMO wir auch "in kürze" verfügbar sein ... Mehr kann oder will man derzeit uns Modellbahnern nicht anbieten.
-AH-

Hallo Werner,

für mich ist BiDiB auch das z.Z. leistungsfähigste System und außerdem ist es günstig. Z.B. kann die Lok die Gleisverschmutzung per Railcom melden. Das geht zumindest z.Z. nur mit BiDiB.
Mit Tams gibt es einen zweiten Hersteller.

Wenn Du Dir mal die Möglichkeiten der Zubehör-Decoder anschaust, so etwas bekommst Du sonst nirgends.

Grüße
Stephan

Servus,



Nein, das Gegenteil ist der Fall.

Wie es an vielen anderen Stellen in der technischen Entwicklung die Vergangenheit gezeigt hat, fördert eine gemeinsame, sauber definierte Basis die Entwicklung und Verbreitung.
Die Entwicklungen beispielsweise auf dem PC Markt zeigen das deutlich.

Zudem spart es massiv Geld, weil man die wichtige Arbeit nur einmal macht.

So heterogen wie die digitale Landschaft bei den Zentralen aussieht, ist das Chaos pur und zudem alles andere als Zukunftssicher.

Hallo Arnold


Warum sollte das so sein? Dass es anders geht beweisen S88, LocoNet, XpressNet und selbst der SX-Bus. Voraussetzung dafür ist natürlich, dass die Herren ihren proprietären Quark sein lassen und die Spezifikationen einhalten.

Hallo Frank


Was verstehst du unter breitbandiger?

Viele Grüße
Carsten

Das hat BiDiB nix damit zu tun das ist ein reines Decoder feature geht somit mit jeder RailCom Infrastruktur, wenn der verwendete Decoder die Daten liefert.

@17 schön daß Du anderer Meinung bist. Frag irgend einen der großen Hersteller weshalb sie nicht so agieren wie Du es gerne hättest. Wobei mir offene Standards auch lieber wären nur dann hätten wir vermutlich wesentlich weniger als jetzt. Ich beschäftige mich schon sehr lange mit Normung und da hab' ich eben andere Erfahrungen gemacht als das was ich gerne hätte.

@18 Selektrix wie es derzeit implementiert ist, ist aber für die Ansprüche von RailCom um Größenordnungen zu langsam. Die Architektur könnte auch mit schnelleren Bussystemen, nur damit stirbt ein Kern der Selektrix Architektur, glaube nicht daß das gewollt wäre. Auch die anderen genannten Bussysteme sind für heutige Ansprüche zu langsam. Da werden tote Pferde geritten...

Es ist völlig klar daß Anwender mit vorhandener Infrastruktur die zu langsam für heutige Entwicklungen wie RailCom udglm ist nach Auswegen suchen möglichst wenig ändern zu müssen. Wenn man in Zukunft die Neuerungen benutzen will sind halt die besonders uralten Techniken wie S88, R-Bus, Selektrix, LocoNet, XpressNet halt nicht geeignet. Das heißt nicht daß die schlecht wären nur halt für die zu erwartenden neuen Entwicklungen nicht mehr passend. Aber auch die schnellen Bussystemen wir RS485 oder CAN sind ja nix neues das Zeug gibt's seit den 1960'er bzw 1970'er Jahren. Es gab schon vor 30 Jahren keinen finanziellen Grund die nicht zu verwenden, es hat vermutlich nur keiner der Entwickler daran gedacht. Daher sind wir heutzutage noch immer mit technisch besonders simpler HW konfrontiert. Heutzutage ist es sogar billiger einen Prozessor mit CAN Bus Infrastruktur zu verwenden als mühsam selbst die HW für die MoBa Klassiker bereitzustellen. Von der nötigen SW dazu red' ich gar nicht. Faktisch alle Prozessoren mit CAN interfache haben ISO Layer 1-6 fertig implementiert. Da braucht kein Anwender (Entwickler) mehr was dafür zu tun geht einfach.
-AH-

Ja und nein, der Bus muss in der Lage sein, die Datenmenge zu transportieren und es sind die entsprechenden Kommandos nötig. Das ist bisher nur bei BiDiB vorhanden.

Grüße
Stephan

Sorry falsch!
Der Decoder muß in der Lage sein Signal Qualität zurück zu melden, das ist ein RC Feature des Decoders. Das können inzwischen viele ESU, ZIMO und andere. Der BiDiB hat damit nicht einmal garix zu tun außer eben der Aufgabe die vom Decoder erzeugten Daten weiter zu transportieren, aber das ist auch ident für alle Bussysteme die RailCom tauglich sind (also CAN oder BiDiB). Jeder RailCom Detector kann die Qualitätsdaten empfangen und weitergeben wirklich jeder weil das absolut keinen technischen Unterschied zu anderen RC Infos hat. Man braucht dann auch jemanden der die Daten versteht, aber auch dazu hat der Bus keinerlei helfende oder hindernde Eigenschaften.
-AH-

Hallo Arnold,

ich denke, wir reden aneinander vorbei.
Ob andere System die Railcom-Daten auf den Bus legen weiß ich nicht. Für mein Verständnis müssten auch die entsprechenden Kommandos im Bus-Protokoll definiert sein.
Vielleicht einigen wir uns, dass die Daten bisher nur im BiDiB-System nutzbar sind
Sollte das nicht mehr der aktuelle Stand sein, dann bitte ich um Hinweise, wo ich diese Infos finden kann.
Bei den Decodern sind mir nur D&H und Zimo bekannt, dass Sie QoS senden können. ESU wäre mir neu. Wenn Du da die entsprechenden Infos hast, dann wäre ich Dir dankbar, wenn Du sie mir mitteilen könntest.

Grüße
Stephan

Hello Stefan!
Der Bus über den die Geräte verbunden sind hat da gar nichts am Hut. BiDiB ist halt einer von vielen der ausreichend schnell ist. Die anderen Firmen mit CAN Bus können das alle auch. Es wäre sogar sehr unvorsichtig würde man RailCom Datagrammen extra im Bus nachprogrammieren müssen. Die Aufgabe des Busses zb BiDiB ist nur die Infos zu transportieren. Da ist BiDiB nicht besser oder schlechter als die anderen. Große Unterschiede gibt es natürlich zu den Uraltbussen wie LocoNet, X-PressNet udglm. die sind dafür ungeeignet.
NEIN: genau das ist eine Falschaussage! Die Empfangsqualität Meldung und andere Dinge mehr kannst auch mit der ECoS oder MX31ZL, oder MX10 nutzen.
Ob ESU die QOS Meldung jetzt in den Decodern auch schon macht weiß ich nicht, nur wie schon mehrfach geschrieben ist das keine Sache des Transportbusses sondern eine Decoder Eigenschaft.
-AH-

Hallo Arnold,

könntest Du mir bitte Links schicken, wo das beschrieben ist. Die einzige Info, dass das genutzt werden kann finde ich hier:
http://wiki.rocrail.net/doku.php?id=sensor-statistic-en
Da steht nur BiDiB und ich denke, dass Rob das schnell einbauen würde, wenn die Daten auch bei anderen Systemen verfügbar wären. Deshalb bitte ich Dich um Infos, wo ich das nachlesen kann, dass es auch funktioniert und ggf. auch gleich Rob infirmieren.
Grüße
Stephan

Hallo Frank,

bist Du sicher, dass der DR4088RB-CS Railcom-Daten erkennen kann oder verstehe ich Dich falsch?
Ich denke eher, dass Digikeys jetzt die Kommandos eingebaut hat, die Railcom-Daten über Xpressnet ermöglichen und nicht, dass der DR4088RB-CS das kann. Die Kommandos sind im Xpressnet-Standard nicht vorhanden.
Wahrscheinlich sind es diese:
https://www.opendcc.de/info/xpressnet/xpressnet_bidi_e.html

Der angekündigte DR5088RC kann aber auch nicht mehr als die Lok-Adresse in Kanal 1 zu erkennen: https://www.digikeijs.com/dr5088rc-digidetect.html
Mehr gibt Loconet an Kommandos und auch Geschwindigkeit nicht her. Für mich ist das dann nur rudimentäres Railcom.

Wenn Du andere Infos hast, bitte mitteilen.

Grüße
Stephan

Im LocoNet hat Digitrax eben ein Kommando für die Lokadresse (in deren Sprache heisst das "Transponding") definiert. Mehr brauchen sie selber ja nicht. Bis jetzt sind mir noch keine anderen LocoNet Kommandos für andere RailCom-Informationen untergekommen, aber es sollte doch kein Problem sein solche zu definieren. Wenn dann nicht Digitrax mit dem erhobenen Finger "Nanana" sagt.

Bevor ihr übrigends "zu langsam" sagt, dann lasst mal hören welche Geschwindigkeit ist denn vonnöten und was ist vorhanden?

Gruß,
Harald.

Hallo Frank,

Du verwirrst mich. Was für ein Rückmeldesignal von der Lok sollte der DR4088RB-CS an die Zentrale durchlassen. Kann der Railcom? Falls nein, dann kann er nur melden, dass da eine Lok steht. Falls doch, wo ist diese Info zu finden?

Grüße
Stephan

Hi!
Zur Frage QOS Meldung: JEDER RC Detector muß diese Daten lesen. Wenn er die dann an den Bus weiter geben kann oder tut ist das nicht vom Bus abhängig. Egal ob das in irgendwelchen tertiär Quellen anders steht.
Zur Bandbreite: DCC schafft etwa 80 DCC Kommandos pro Sekunde (kommt drauf an welche Befehle versendet werden). Das bedeutet es können etwa 10 Bytes RC Daten entstehen. Damit haben wir 800 Bytes Rohdaten. Da kommen noch Header udglm dazu runden wir großzügig ab um eine runde Zahl zu haben haben wir 1000 Bytes die zu transportieren sind, ofrt mehr als 10.000Bits pro Sekunde nur RC Daten!!!!!!. Wobei ich hier noch weglasse, daß jeder LocalDetector gleichzeitig die 2 Kanal 1 Bytes absetzen will, die Lage ist also weit schlimmer als in der hier beschriebenen Abschätzung! Das alleine verstopft schon Loconet oder XPRessnet die üblicherweise andere Aufgaben auch noch haben. Die einzige Lösung ist bereits im RC Detector zu filtern. Einzige Alternative zum Filtern wäre mehrere zusätzliche RailCom Busse auf Basis LocoNet oder X-PressNet über die Anlage zu verkabeln nur damit man bei seinem alten geliebten Bus bleiben kann, das kann aber nicht das Ziel sein oder? Daher ist BiDiB ja durchaus zu begrüßen, nur ist es eben nicht das Einzige Bussystem sondern nur eines und es gibt etliche andere die das sogar schneller können.
Hier dürfte auch die Ursache für die Missverständnisse in diesen Thread herkommen. RC Leser die mit den langsamen Bussen leben müssen schmeißen gezwungener Maßen den Großteil der empfangenen RC Daten weg. Wenn man diese Erfahrung hat meint man das wäre halt so, nur das ist halt nicht das was ESU, ZIMO anbieten, die können's ja!

Zu den Alten Bussen: man versucht die Kunden mit dem alten Zeug bei Laune zu halten, verschweigt daß ein solche RC Infrastruktur natürlich weit entfernt von dem ist was sich Lenz einmal ausgedacht hat. Der hat nämlich einen eigenen schnellen RC-Bus machen wollen. Den gibt's aber nicht, wurde nicht fertig. Meiner Beobachtung nach wird diesbezüglich von Lenz wohl nicht mehr viel zu erwarten sein.

Bei RailCom wird oft nur das Rückmelden der Adressen und das Auslesen von CVs betrachtet. RC ist aber noch viel mehr. Also das Mappen von RC Adressen auf das Transponding von DigiTrax ist nur ein kleiner Anfang.
-AH-

@ Harald
Nach meinem Stand hat Loconet ca. 19kBaud, Xpressnet 64k, CAN 125k und BiDiB 500k Brutto-Datenrate. Da geht dann immer noch Protokoll-Overhead weg.

@ Frank
Vielen Dank für die Info.
Laut den Infos im Screenshot würde ich interpretieren, dass das die Konfiguration der Xpressnet-Schnittstelle und nicht eines DR4088RB. Falls ja, dann könnte das die Option sein um die Befehle aus meinem Link oben weiter zu geben. Blücher unterstützt z.B. diese Befehle bei seinem Xpressnet-Interface. Das wurde mal für die OpenDCC Z1 entwickelt. Bei der Z21 geht das, glaube ich auch, aber nur die Lokadresse.
Ansonsten bin ich verwirrt.
Hast Du einen Decoder mit Railcom? Kannst Du irgendwo sehen, dass da eine Loknummer übertragen wird?

Grüße
Stephan

Excuses for reacting in English, I can read German, but writing is something completely different..

This option is needed to enable loco info to be transferred through USB and LAN, and is incorporated for Windigipet users only (Dutch manual). For additional info see https://www.windigipet.de/foren/index.php?topic=74628.0

Greetings

Rinus Vos
Niederlande

Edit: typo & link

@ 36 ELNA

Strange. It works here.

Greetings,

Rinus Vos
Niederlande

@36 ELNA5


"Dutch Manuals don't help if only german / english
speaking people are the users of the stuff."

Two remarks:

1st. Don't kill the Messenger (hi, hi). I do not own the system, and I do not work for Digikeijs. I am still looking for the system that meets my needs.

2nd. In the Netherlands there is a growing fanbase for this system, because it offers a great bang per buck.

I do agree that a German manual is needed!

Greetings

Rinus Vos
Niederlande

Hallo
Ich hatte auch lange Mühe in dem digitalen Durcheinander den Durchblick zu kriegen. Insofern fand ich die Ursprungsfrage von Werner P spannend und hoffte, dass hier eine vernünftige Marktübersicht entsteht. Leider ist das nicht passiert, aber ich versuche hier eine Zusammenfassung der Lage.
Als Anfänger muss man zuerst mal Begreifen, dass Railcom-fähig nicht unbedingt vollständige Railcom Unterstützung heisst. Das heisst: Nur weil das Railcom Logo auf der Decoderschachtel prangt, kann der der Decoder vielleicht doch nur POM und seine Adresse melden. Weitere mögliche Informationen wären QoS, Speed, etc. Gut sind z.B. die (neueren) Decoder von Zimo oder D&H. Aber auch andere Hersteller ziehen nach. Wichtig ist, dass man sich dem Umstand bewusst ist und genau aufpasst, was man kauft.
Das nächste sind die Railcom Detektoren. Diese sind typischerweise lokal in den Belegtmeldern der Gleisabschnitte verbaut. Sie erfassen die Railcom Nachrichten der Decoder, die diese in der Austastlücke des DCC Signals senden. Als Beispiel: Der BiDiB GMB16T hat 16 Gleisanschlüsse, an jedem davon können die Railcom Nachrichten von 4 Railcom Decodern empfangen und auf den BiDiBus gelegt werden.
Jetzt sind wir also beim Bus. Der Bus ist das Kommunikationsmittel der Bausteine wie Zentrale, Belegtmelder aber auch anderen Komponenten zur Licht- oder Weichensteuerung. Der Bus muss nicht nur ein "Rückmelde"-bus sein, sondern kann eben auch BiDirektionaler Bus sein. Der Platz im DCC Signal ist sehr knapp. Darum macht es Sinn, möglichst wenig Kommunikation im teuren DCC Signal ausser den Lokbefehlen zu haben. Weil die alten Busse wie Loconet und Xpressnet eben nur für Kommunikation in eine Richtung ausgelegt wurden sind sie aber zu schwach für umfangreichere bidirektionale Kommunikation, auch wenn in jüngerer Zeit damit begonnen wurde deren Befehlssätze zu ergänzen, damit sie Railcom Nachrichten transportieren können. Für mein Verständnis sind sie damit aber auch nur Railcom-fähig und unterstützen nicht zu 100% Railcom.
Moderne Busse basieren auf Industriebussen wie CAN oder RS485 (darauf basiert BiDiB). Diese Busse sind zwar auch alt, aber eben von Anfang an für Aufgaben entwickelt wie sie sich heute in der Modellbahn stellen. Weshalb der BiDiBus auf RS485 und nicht auf CAN basiert ist hier http://www.bidib.org/bidibus/xtra_info.html nachzulesen.
Leider ist mir kein System bekannt, dass auf CAN basiert und aktuell bei der Modellbahn (ausser Märklin) eine wirkliche Rolle spielt und Railcom gut unterstützt. Leider wurde hier bis jetzt auch keines konkret genannt.

Beste Grüsse
Markus

Hallo zusammen,

auch ich hatte gehofft mal eine Zusammenstellung von Railcom fähigen Rückmeldern zu bekommen.
Bisher sehe ich aber nur BiDiBus und die GMB16T aber die benötigen immer einen GBMBoost um mit dem Bus verbunden zu werden und mit dem Gleissignal gespeist zu werden. Sie können wenn ich es richtig verstanden nicht mit z.B. einer Z21 und dessen Gleissignal gespeist werden.

Damit scheiden sie für mich aus, bei meiner  Anlage benötige ich keinen zusätzlichen Booster, ich habe aber sehr viele Rückmelder um auch auf kleinem Raum einen gewissen Betrieb zu ermöglichen. Bisher nutze ich acht (8) Uhlenbrock 63320 Rückmeldebausteine und würde sie in Zukunft gerne durch Railcom fähige Melder ersetzen.

Ein zusätzlicher Bus zum PC wäre kein Problem aber weitere Netzteile mit Boostern, deren Spannung ich nicht einstellen kann schon.

Gruß
Rainer

Hallo Rainer,

Du kannst BiDiB natürlich auch mit einer anderen Zentrale betreiben. Es gibt 3 Konfigurationsmöglichkeiten. Die Links findest Du auf dieser Seite:
https://www.fichtelbahn.de/gbmboost_index.html
als Rückmeldesystem
als Rückmeldesystem mit Booster
als Interface/Zentrale mit Booster und Rückmeldesystem

Es gibt diese Jahr auch noch den GBM16TS, der keinen GBMBoost benötigt und direkt am Bus angeschlossen wird:
https://shop.fichtelbahn.de/GBM16TS_1

Von Tams gibt es bald den 8-fach Rückmelder HERMES. Ist noch nicht auf der Webseite aber im Katalog auf Seite 25 zu finden.

Grüße
Stephan

Hallo Rainer
Neu gibts das BiDiB-IF2 https://www.fichtelbahn.de/if2_index.html. Damit kannst du einen BiDiBus eröffnen. Und bald kommt ein GBM16TS https://shop.fichtelbahn.de/GBM16TS_1 . Das ist ein GBM der direkt an den Bus abgeschlossen werden kann. Ideal für Umsteiger oder Module. Beide sind vollständig bestückt und keine Bausätze.
Gruss Markus

Hallo Stefan #42
Der Hinweis auf den Tams Katalog ist sehr hilfreich. Sehr erfreulich, dass ein Hersteller wie Tams den BiDiBus bei Neuentwicklungen berücksichtigt. Das zeigt, dass BiDiB als offenen und leistungsfähigen Bus in der Branche erkannt wird und sich vielleicht auch andere Hersteller anschliessen.
Gruss Markus

Moin allerseits,

@Markus #40: bzgl. CAN-Bus möchte ich nur mal kurz anmerken, dass von ESU ECoSlink auf CAN basiert und deren ECoS Zentrale wohl Railcom und Railcom-Plus mit allerlei Funktionen unterstützt ...
http://www.esu.eu/produkte/digitale-steuerung/e...rweiterungsoptionen/

Grüße,
Arndt

Vielen Dank Arndt,
für deinen wertvollen konkreten Beitrag.
Beste Grüsse
Markus

Hallo zusammen,

danke an Markus und Stefan, der GBM16TS scheint wirklich sehr interessant in Zusammenhang mit dem IF2.

Auch Hermes scheint mir sehr interessant, es tut sich also etwas.

Gruß
Rainer

@48 Das Leistungsangebot des Rückmelders ist aber stark unterschiedlich. Am RS Bus mach das Ding nur Besetztmeldungen. RailCom Daten liefert das Ding nur am CAN Bus in der Version Roco/ZIMO


Alle 3 CAN Systeme die derzeit in Europa Verbreitung haben können und nutzen das Märklin(bedingt), ESU und Roco/ZIMO. Übrigens habe ich das schon in Beitrag n32 genannt.
-AH-

Hallo Frank,

bitte aufpassen, der RS-Bus (Lenz) und R-Bus (Roco) sind was ganz unterschiedliches.

Grüße
Stephan

@49
Danke für die Präzisierung bezüglich Beitrag 32. Nur leider finde ich in dem Beitrag das Wort CAN nicht und habe darum nicht realisiert, dass die genannten Systeme auf CAN basieren. 'Tschuldigung.

@48
Es ist ja zu begrüssen, dass Roco auch neue Railcom-fähige Rückmelder bringt. Nur die Dokumentation ist sehr dürftig, wenn nicht irreführend. (zumindest was unter dem genannten Link zu finden ist). Wie AH schon ausführte: Darauf dass das Leistungsangebot unterschiedlich ist, muss man als Laie erst mal kommen. Und wie gut die Railcom Detektoren am CAN Bus dann sind wissen wir immer noch nicht. Kann der auch 4 Decoder pro Abschnitt?

Gruss
Markus

Folks,

auch der BiDiB ist ein CAN-Bus.

Jens

Hallo Jens



Hast du eine Quelle für deine Aussage? Ich bin kein Pro in Signaltechnik. Aber nach allem was ich bis jetzt gelesen habe, verstehe ich RS485 und CAN als unterschiedliche Systeme.

Danke und Gruss
Markus

Das ist definitiv falsch.

Grüße
Stephan

Servus,



=>

http://www.bidib.org/bidibus/xtra_info.html ->


Grüßle

MiScha

Folks!
Das Roco Ding ist ganz neu und noch kaum erhältlich. Die Frage zur X-PressNet Melderei ist alleine aus von mir bereits mehrfach beschriebenen technischen Gründen klar, steht aber auch in der Roco Doku klar drin. Wenn jemand in den vergangenen 10 Jahren sich für eines der veralteten Bussysteme entschieden hat war das ja nie Zufall sondern Absicht und Vorsatz neue Dinge wie RailCom eben nicht verwenden zu wollen, alternative Bussysteme oft auch billiger gibt's ja schon lange. Die Fakten sind seit 20-30 Jahren klar. Durch einen dünnen Gartenschlauch passt auch nicht genug Wasser um eine Großstadt zu versorgen.
Die Beschränkung der RC Adressen ist soweit ich die Entwickler verstanden habe hier weggelassen worden weil es unnötigen zusätzlichen Aufwand bedeuten würde. Das Problem an der Sache (hier meine ich RC Daten im Kanal1) ist aber wie teilt man einem Decoder mit nicht zu senden um Kollisionen zu vermeiden. Das muß auf höherer Ebene passieren, zB durch das PC Programm.

Hintergrund: im Kanal1 sendet jeder Decoder seine Adresse nach dem Empfang einer DCC Nachricht. Wenn da jetzt mehr als ein Decoder ist, zerstören sich die Decoder die Nachricht gegenseitig, da diese gleichzeitig senden. Somit sind die Zentralen mit ihren globalen Detektoren einmal draußen. Lokale Detektoren können nun einen Abschnitt isoliert betrachten. Wenn da aber nun >=2 Decoder drin sind muß man eine Runde nachdenken. In der Regel wir der ersten Lok gesagt einige Zeit keine Broadcasts zu senden, damit hat man die Möglichkeit die nächste im Abschnitt zu lesen. Das geht natürlich nur wenn der Zug da hineinfährt. Wenn der Wurm schon drin ist, zB beim Anlagenstart wird's eher schwer werden da mehrere Loks zu lesen. Deshalb gibt's noch weitere Verfahren die im Kanal2 auf Fragen antworten oder mittels ZACK Impulse die Sache beschleunigen.
-AH-

@Arnold
Gibt es den Roco-Rückmelder schon? Auf der Web-Seite ist er noch als nicht lieferbar gekennzeichnet. Eine Doku finde ich auch nicht, deshalb war mir auch nicht klar, ob er Railcom-Daten vielleicht doch über den R-Bus sendet.

Mehrere Loks auf einem Abschnitt, die in Kanal 1 senden stören sich. Es wurde mal eine Funktion spezifiziert, die das verhindern soll. Das wurde aber wieder entfernt.
Der Decoder soll einfach das Senden auf Kanal 1 einstellen, sobald er mehrmals über seine Adresse angesprochen wurde. Wenn er dann länger Zeit nicht mehr angesprochen wurden, dann soll er wieder auf Kanal 1 senden.
Das wird trotzdem mittlerweile von D&H und Tams unterstützt. Wer diese Funktion nützlich findet sollte beim Hersteller seines Vertrauens nachfragen.

Grüße
Stephan

Hallo Frank,

man muss unterscheiden zwischen reiner Gleisbelegtmeldung oder Loknummernrückmeldung (Selectrix, Zimo, Digitrax, Lenz). Ohne Adressrückmeldung gibt es kein "Transponding" - egal über welchen Datenbus das an die Zentrale zurück läuft.

Ein "Transponding via LocoNet" gibt es nicht. Da transpondet nichts. Die LN Busteilnehmer brabbeln ihre Änderungsdaten von sich aus in Echtzeit auf dem Netzwerk (vereinfacht dargestellt). Railcom ist nicht mehr proprietär, es darf jedermann nachbauen (es gibt auch eine NMRA RP dazu).

Vergleich: LocoNet ist ein Mutli-Point Netzwerk (peer-to-peer), der SX-Bus ist ein bidirektionaler Master-Slave Bus und der RS-Bus (vermutlich auch der R-Bus) ein unidirektionaler Master-Slave Bus.

Grüße, Peter W.

Hallo Frank,

Loconet ist leider nicht offen. Als kommerzieller Hersteller benötigst Du eine kostenpflichtige Lizenz. Für Hobbyanwendungen gibt es eine kostenlose Lizenz, in der sind aber nicht alle Befehle enthalten.

Transponding ist genauso lizenzbehaftet und außer Digitrax wird es von keinem anderen Hersteller unterstützt. Transponding wurde nicht weiter entwickelt, so wie das bei Railcom der Fall ist. Es gibt wohl nur einen Rückmelder, der das unterstützt. Hatte vor Jahren mal gelesen, dass das auch nicht so besonders zuverlässig läuft. Die für das Transponding nötigen Befehle im Loconet werden jetzt auch für Railcom genutzt.

Da es kaum noch Komponenten gibt, die Railcom nicht unterstützen, ist für mich Railcom die sinnvollere Lösung.

Grüße
Stephan

Hi Frank!
LocoNet ist ein besonders hartnäckig verteidigtes geschlossenes System. Es war eine weise Entscheidung des Ehepaars Ireland den Bus teilweise für Bastler zu öffnen, so kam's ja auch zur Verwendung beim FREMO. Offene Technologie ist es aber nicht.
Das Transponding funktioniert mäßig, Digitrax promotet es nicht und es gibt auch kaum HW dafür.

RailCom ist ein Konzept von Lenz, das dann mit anderen Firmen weiterentwickelt wurde, das waren/sind TAMS, ZIMO, Kühn. ESU kam später dazu und ZIMO wurde hinausgedrängt weil sie vor Lenz Decoder und Zentrale hatten und sich nicht an Vorgaben halten wollten. Anfangs hat LENZ mit Patent und Lizenzen Kontrolle auszuüben versucht. Das hat dazu geführt daß die Sach' eingeschalfen ist. Seit einiger Zeit ist RailCom aber Lizenzfrei, jeder darf es verwenden, die technischen Specs legt derzeit aber Lenz fest. Ein Übertragen der "Ordnungsstelle" an eine andere Institution scheint nicht unmöglich.

Zurück zu den Bussen: derzeit gibt's BiDiB, und die 3 CAN Bussysteme die genügend Duchsatz für RailCom haben. Die klassischen Bussysteme sind um Größenordnungen zu langsam. Eventuell können Teilfunktionen  gemappt werden wie Adressmeldung in LocoNet indem man Transpondig Nachrichten sendet.
-AH-

Ihr wisst aber schon, dass es seit langer Zeit einen Railcom-Rückmelder auch für die z21 gibt ?
Der Blücher GBM16XT wird per Xpreessnet angeschlossen und funktioniert tadellos. Ich habe das Teil seit einem Jahr im Einsatz, und keine Probleme damit (im Gegensatz zu den Digikeijs-Teilen am R-Bus)

Hallo Frank,

vielleicht solltest Du die Beträge so lesen, wie sie geschrieben sind und sie nicht interpretieren.

Niemand hat geschrieben, dass Railcom-Daten nicht auch auf Loconet und Xpressnet übertragen werden können. Es wurde geschrieben, dass die alten Bussystem zu langsam sind um alle bereits jetzt möglichen Railcom-Daten und mögliche zukünftige Daten auch bei größeren Anlage zeitnah zu übertragen.

Ein kleiner Ausflug für Dich um Dich auf den Stand zu bringen.
Bei Loconet gibt es das Transponding schon ca. 15 Jahre. Also kann eine Lokadresse schon mindestens so lange per Loconet übertragen werden. Diese Kommandos werden jetzt eben von railcom-fähigen Rückmelder mit benutzt.
Bei Xpressnet wurden die nötigen Kommandos von Wolfgang Kufer für die OpenDCC Z1 definiert (siehe Link weiter oben) und in einen Rückmelder eingebaut: https://www.opendcc.de/s88/gbm_bidi/gbm_bidi.html
Auf meine Initiative wurden diese Xpressnet-Kommandos dann sogar in Rocrail eingebunden.
Blücher kann sowohl über Loconet als auch über Xpressnet die Lokadresse ausgeben, aber eben _nur_ die Lokadresse, kein Speed, QoS usw.
Im Zuge der Entwicklung des oben genannte Rückmelders hat Wolfgang Kufer festgestellt, dass Xpressnet einfach zu langsam ist für zukünftige Aufgaben. Dann hat hauptsächlich er BiDiB am Anfang aufgebaut.

Railcom ist eben nicht gleich Railcom. Es muss einfach nachgeschaut werden, was bei einem Produkt Railcom bedeutet. Nur rudimentär die Lokadresse oder vielleicht doch mehr. Das gilt für Decoder genau so wie für Rückmelder.

Vielleicht wird es Dir jetzt klar.

Zum Rocorückmelder.
Woher weist Du, dass der Rückmelder Railcom (laut Beschreibung auf Web-Seite nur Lokadresse) über den R-Bus kann?
Arnold hat weiter oben beschreiben, dass er das nicht könnte, aber leider keine weiteren Infos dazu geliefert, wo das nachgelesen werden kann.

Grüße
Stephan

Hi Stephan!
Zum 8 fach Roco Melder, kann leider nicht immer alles schreiben von dem ich weiß.

Zu Railcom: es gibt keine Varianten. Lt Definition muß alles transparent sein. Wird gefiltert ist das halt kein RailCom - so einfach ist das.

Es ist nicht weiter schlimm von den Decodern nur die Adressmeldungen zu verwenden. Es muß nur klar sein daß das dann nix mehr mit RailCom zu tun hat. MaW man braucht einen schnellen Bus.
-AH-

Bei Railcom gibt es schon diverse Varianten und Abstufungen auf Lokdecoderseite. Was der Railcomdecoder daraus macht und was er auf den Bus bringt ist wieder eine ganz andere Art Bier.

So ganz ehrlich: mir persönlich reicht vollkommen, wenn Lokadresse und Aufgleisrichtung gemeldet werden. Die dadurch produzierte Datenmenge ist dann ja auch marginal. Mir geht es weniger darum aus meiner Anlage ein Computernetzwerk zu machen.

Bisher wird selbst das was vorhanden ist softwareseits eh nur rudimentär unterstützt. Rocrail kann nicht mal die Aufgleisrichtung richtig verarbeiten.

Hallo Zusammen,

nochmals vielen Dank an alle die hier ihr Wissen und ihre Erfahrung eingebracht haben.

Ich habe viel dazugelernt und ebensoviel Neues erfahren. Letztlich habe mich nach reiflicher Überlegung für das BiDiB-System entschieden. Ausschlaggebend waren neben dem verwendeten Bussystem, die Kombination aus Einspeisung und Rückmeldung.

Grüße - Werner P

Hallo Werner
Schön dass du dich hier nochmals meldest und uns deine Wahl mitteilst.
Viel Spass und Erfolg!
Herzliche Grüsse
Markus

Hallo Alle,

ich habe jetzt versucht alles zu lesen und verstehen (mit meiner Deutsch). Und ich habe die folgende Frage - bin ich richtig, dass als Railcom-fähiger Rückmelder fuer ein DCC Lenz Zentrale System das hier:

https://www.opendcc.de/s88/gbm_bidi/gbm_bidi_e.html

bauen kann? Die Verbindung wäre dann mit Xpressnet?

Ich mochte die Railcom Möglichkeit fuer mein Schattenbahnof nutzen.

Vielen Dank

Gruss Ivan

Hallo Ivan,
nein, BiDiB / GBMBoost ist ein eigenes System und passt nicht zu Lenz.

Viele Grüße
Carsten

Folks!
Für alle die RailCom nachrüsten möchten auf der Anlage, ganz unabhängig von spezifischen Produkten folgende grundlegende Info:

Bei RailCom entstehen nach jedem DCC Datenpaket in der Pause dazwischen zwei Informationssätze die von der HW gelesen werden sollen und dann je nach Intelligenz der Leseeinrichtung weitergeleitet werden müssen. Wenn man etwa 80-100 DCC Befehle in der Sekunde annimmt und dann je nach übertragenen Befehlen noch im Mittel 6 Bytes Rückmeldung hat man am Rückmeldebus einiges an Datenverkehr den die Primitivsysteme nicht schaffen können.

Es läuft daraus hinaus daß für vernünftige RailCom Nutzung BiDiB oder CAN Bus nötig sein wird - also das was derzeit kaufbare Zentralen bieten. X-Press Net LocoNet sind einfach um Größenordnungen zu langsam. Da kann man lediglich verdichtete gefilterte Daten einspeisen. S88 ist ohnehin draußen weil hier nur Besetztmeldungen weitergeleitet werden, mehr ist da nicht möglich.
-AH-

Carsten, Arnold,

klar. Dann folgt;

wenn ich jetzt Railcom nutzen will hesist es:

- Lenz wegschmeißen etwas anderes kaufen? Was dann?
- Oder 2 Zentralen (Lenz (weichen, licht,…….+ ???(Züge+ Ruckmeldung)) und mit PC Programm (muss sowieso sein) zusammen steuern?

Sorry, ich kann nicht (als nicht-expert auch mit Google) eine eindeutige Antwort finden (wenn so was gibt).

Gruss Ivan

Hello Ivan!
Mit der Lenz Ausrüstung kommt man nicht recht weit. Lenz hat technisch immer nur das minimalste gemacht und seine Reputation aus der Grundentwicklung DCC bezogen - Erfinder von DCC. Alleine die Idee mehrere Bussysteme über die Anlage ziehen zu wollen ist Unfug.

RailCom HW wurde von ZIMO in den Decodern bereits etwa 2001/2 eingebaut. Als dann dei Sach' seitens Lenz ausgegoren war hat ZIMO einen SW Update für die Decoder angeboten und so tausende RC fähige Decoder im Markt gehabt was Lenz superextrem verärgert hat. Getoppt wurde das vom MX31ZL das war die erste kommerzielel Zentrale mit RailCom HW. Da ZIMO sich nicht von Lenz einbremsen lassen wolte kam es dann zum bekannten Streit und Bruch. ZIMO hatte da überall leichtes Spiel weil man immer eher großzügig gedacht hat. Also schnelle CPUs, schneller Bus, Reserven beim Speicher, das kostest alles faktisch kein Geld und schützt vor unnötigen frühen Grenzen beim Ausbauen.

Um es konkret zu formulieren sehe ich derzeit wenn man RailCom Interesse hat nur ESU, Märklin/Trix, Roco/Fleischmann und ZIMO gut aufgestellt. Gegebenenfalls auch noch Tams mit den Fichtelbahn Modulen nur da ist man schon etwas in die Bastelabteilung gerutscht. Bei allen Anbietern ist aber die Rücklese Besetztmelder HW noch relativ aufwändig. Bezahlbar und durchgängig ausgeführt ist die Geschichte mit der schwarzen Z21 und den neuen 8-Fachbesetztmelder. Märklin und ESU sind da zögerlich zB Bei ESU nur ein Teil der Besetztmelderausgänge kann RC. ZIMO hat den Roco Besetztmelder gemacht der ist preislich attraktiv kann auch zum MX10 benutzt werden wobei die dann möglichen 20A für N wohl unnötig sind, daher die Empfehlung für die Roco/Fleischmann Geschichte. Bei ZIMO gibts dann nich das StEin Modul für alle die zu viel Geld haben.
-AH-

Hallo Ivan,
leider ist es entgegen verschiedener Beiträge so, dass Du RailCom eben nicht vollumfänglich einfach so auf Bussystemen wie LocoNet oder XPressNet nutzen kannst.

Beispiel Beitrag #27: XPressNet - wenn man sich den Inhalt auf OpenDCC tatsächlich auch mal durchliest, statt nur drauf zu verlinken, dann sieht an, dass es sich um eine OpenDCC-spezifische Erweiterung des Befehlssatzes handelt. Sprich: Ja, der Bus kann (mit Einschränkungen bzgl. des Datendurchsatzes) grundsätzlich die Information transportieren, es ist aber nicht spezifiziert wie, weil im Standard nicht vorgesehen. Ein OpenDCC RailCom Melder mit XPressNet wird also an einer anderen als einer OpenDCC-Zentrale eher nicht funktionieren, es sei denn, diese reicht ihr unbekannte Pakete 1:1 an den PC weiter. XPressNet 3.0 soll wohl RailCom können, allerdings habe ich dazu die Spec. nicht gefunden, kann das also nicht verifizieren.

Für LocoNet gibt es von Blücher RailCom Melder. Ich habe mir vor längerer Zeit auch dazu mal die Details angeschaut, da werden einige RailCom Informationen auch an Stellen ins Protokoll "reingefrickelt", wo eigentlich andere Daten erwartet werden (aus meiner Erinnerung war es wohl die Aufgleisrichtung, für die es beim DigiTrax-proprietären Transponding keine Entsprechung gibt). Eine komplexe Zentrale, die die Daten selbst verwaltet (also typischerweise solche mit Display, Stellpult, Fahrstraßen-Steuerung etc.) wird damit also voraussichtlich nur eingeschränkt etwas anfangen können oder ist schlimmstenfalls sogar verwirrt durch die an unerwarteter Stelle "geparkten" Informationen.

Damit dürfte auch klar werden, warum dann z. B. ein OpenDCC Melder mit XPressNet-Interface an einer Lenz Zentrale eben nicht funktionieren wird.

Was gehen kann (wenn Du Deine Lenz Zentrale weiter verwenden willst und diese wenigstens die RailCom-Lücke erzeugt) ist, dass Du an den Booster der Zentrale einen RailCom-Detector anschließt, den Du dann ohne Hilfe der Zentrale direkt mit der PC-Software verwaltest. Das müsste z. B. mit einem OpenDCC BiDiB Knoten (wegen der USB-Schnittstelle) und einem Melder durchaus funktionieren. Wesentlich günstiger als die volle Lösung ist das aber auch nicht.

M. W. haben auch die Blücher Melder ein hauseigenes Interface und können dann an verschiedene Busse adaptiert werden. Da musst Du selbst mal nachshauen, ob es auch einen direkten Weg an den PC gibt.

Viele Grüße,
Torsten

Hallo,

"RailCom-fähig" ist kein exakter Begriff. Ein Booster kann bereits dann als RailCom-fähig bezeichnet werden, wenn er die Lücke (Cutout) erzeugt. Da ist noch keine Rede von der Verarbeitung irgendwelcher Daten.

Es gibt verschiedene Arten der Anwendung beim Empfänger:

Wenn es um die Erkennung von Lokadressen im Belegtmelder geht, dann geht das auch per LocoNet und dank einer inoffziellen Erweiterung im XpressNet-Protokoll sogar am X-BUS (zB Blücher GBM16XN und z21, je nach FW-Version). Am R-BUS geht da aber gar nichts: der Belegtstatus wird hier jeweils nur mit einem Bit übertragen, fertig. (Theoretisch kann aber auch das R-BUS Protokoll erweitert werden).

Eine weitere für den Endbenutzer sehr nützliche RailCom-Anwendung ist sicher das CV-Lesen über POM, wo der CV-Wert im RailCom-Kanal 2 an die Zentrale geschickt wird. Das funktioniert normalerweise nur, wenn die Lok am Hauptgleis der Zentrale (="Global RailCom-Detector") steht. Das kann aber auch der Roco Belegtmelder 10808 (nützlich wenn er zB vom LightBooster 10805 versorgt wird), das werden aber auch die neuen "großen" Booster 10806 und 10807 können - wenn sie per CAN (ZCAN20-Protokoll) mit der Zentrale verbunden sind. Am R-BUS geht das nicht, und schon gar nicht am B-BUS. Die Booster 10806 und 10807 senden den ganzen RailCom Kanal-2 per CAN an die Zentrale. Es stimmt schon dass das richtig viel Daten werden können, aber Kanal-2 besteht überwiegend aus Wiederholungen der selben Daten (am Gleis sinnvoll wegen der eher schlechten Verbindung, am CAN lässt sich da aber viel komprimieren). Am Belegtmelder 10808 lässt sich diese Weiterleitung ebenfalls jetzt schon aktivieren, das Teil komprimiert die Daten aber nicht, also nicht unbedingt empfehlenswert.

Was wäre zur Zeit noch interessant am Kanal 2: aktuelle Geschwindigkeit, das beherrschen aber noch nicht so viele Decoder. Und selbst da hängt es oft auch stark von der FW-Version im Decoder ab, wie gut das funktioniert. Es muss auch oft erst ein brauchbarer Umrechnungsfaktor im Decoder eingestellt werden, damit überhaupt ein halbwegs sinnvoller Wert gemeldet wird. Ich bin mir nicht so sicher ob damit jeder Endverbraucher klar kommt. Seit den letzten FW-Versionen könnte die z21/Z21 auch die Railom-Geschwindigkeit an den PC/Handregler melden, aber es wird soweit ich weiss  noch nirgends ausgewertet. Vermutlich würde es Beschwerden hageln weil "geht mit meinem XY-Decoder nicht" bis "unplausible Werte werden angezeigt".

Eine weitere eventuell nützliche RailCom-Anwendung betrifft die Weichendecoder, wo die Stellung bzw verbleibende Restzeit der Bewegung an die Zentrale gemeldet wird (RailCom STAT1 und TIME), aber nur wenige Weichendecoder können das überhaupt. Die z21/Z21 wertet das noch nicht aus. Eine ältere ESU-ECoS, die ich mir mal genauer angeschaut habe, pollt dagegen den Weichendecoder, indem sie CV33 des Decoders per POM ausliest.

Weitere RailCom-Anwendungen wie "Füllstand" sind meiner Meinung nach Zukunftsmusik, es bleibt aber interessant. Dass es nicht viel schneller vorangeht liegt aber auch daran, dass man zwar hochdetailliert die elektrischen Eigenschaften von RailCom definiert hat, bei der Festlegung der Dateninhalte aber eher lustlos und teilweise auch ziellos agiert hat. Kanal 1 ist wenig durchdacht und wegen dem Durcheinanderquatschen der Decoder praktisch unbrauchbar, beim Erkennen der Lokadressen müssen gute Detectoren auch den Kanal 2 analysieren (der 10808 kann tatsächlich auch mehrere Decoder im Gleisabschnitt erkennen, Stichwort Doppeltraktion). Beim ACK und NACK ist man mal beim RailCom-Spezifizieren über die Leserichtung von 0x0F bzw 0xF0 gestrauchelt. Der tatsächliche implementierte Funktionsumfang in den Decodern und Zentralen hat zurzeit auch nur eine recht kleine gemeinsame Schnittmenge: POM Lesen, und selbst das können nicht immer nicht alle Decoder.

Mit dem Thema "Railcom-fähige Rückmeldebussysteme" sehe ich es so: Lokadresse melden sind auch am LocoNet und eingeschränkt am X-BUS möglich. R-BUS und B-BUS sind völlig ungeeignet. Am CAN (ZCAN20, ESU) geht schon viel mehr. Während das ZCAN20-Protokoll aber veröffentlicht und noch am wachsen ist, hält ESU sein Protokoll geheim. BiDiB ist theoretisch hochinteressant, nur was hätte eigentlich einer der großen Hersteller praktisch davon, außer dass er dann noch den Test und den undankbaren Support für Fremdgeräte übernehmen darf?


vg
Gerhard

Noch mal Danke auf Alle für die Antworten. Ich muss sagen, dass, ich jetzt noch weniger als früher verstehe . (das selbst als Dr., Dip. Ing in Bahn Stromversorgung).
Wenn ich noch mal ein paar Fragen darf:
Das Schattenbahnhof sollte zusammen 48 "Gleisen" haben wo ich mir wünsche, dass die Zentrale die Loko Adresse ablesen kann.  Man weiß was da steht.
Geht das überhaupt und dann mit Railcom? Ja/Nein? Ja/Nein?
Wenn Ja:
Kann man die Lenz Zentrale anwenden? Ja/ Nein?
Wenn Ja:
Was braucht man noch dafuer?
Wenn Nein:
Was braucht man anstatt? Und kann man die Lenz Zentrale weiter für etwas nutzen (ich habe auch den Booster usw. und andere Sachen von Lenz).
Es geht jetzt um die Planung. Wen das alles nicht läuft muss ich etwas anderes planen und kaufen bevor ich mit dem Bau los gehe.
Danke

MfG Ivan

PS- bitte wenns es geht nur die Ja/Nei Antworten nutzen

Hallo Ivan,

ja, es ist mit Railcom möglich, Loks auf allen Gleisen im Schattenbahnhof zu erkennen.

Wenn die Lenz-Zentrale und die Booster den Railcom-Cutout erzeugen kann, dann ja, da das Rückmeldesystem von der Lenz-Zentrale unabhängig wäre.

Du musst ein Rückmeldesystem wählen. Bei der genannten Größe halte ich BiDiB für das geeignetste System, sowohl was die Leistungsfähigkeit, als auch den Preis angeht.
Die Lenz-Zentrale könnte für die DCC-Erzeugung verwendet werden:
https://www.fichtelbahn.de/gbmboost_rm.html

Allerdings würde ich beim BiDiB-System die DCC-Zentrale verwenden, die im GBMBoost schon eingebaut ist, also diese Variante:
https://www.fichtelbahn.de/gbmboost_interface.html

Die Lenz-Komponenten könntest Du verkaufen und damit einen Teil der neuen Komponenten finanzieren oder die Zentrale z.B. für schon vorhandene Zubehör-Decoder und/oder das Programmiergleis verwenden.

Bei weiteren Fragen kannst Du Dich gerne im OpenDCC-Forum melden:
https://forum.opendcc.de/

Grüße
Stephan

Hallo Stephan,
warum machst Du für ein Forum Reklame, bei dem ich mich allein wegen meiner Email-Adresse nicht anmelden kann? Einem Forum, bei dem die in solch einem Fall angeblich helfen könnenden Administratoren nicht zugänglich sind?
Ich glaube, dass die technischen Fragen besser hier diskutiert werden sollten als in einem elitären Forum.
Gruß
Loddel

Elitär wohl kaum. Was für eine Email-Adresse (Domain) ist es denn? Das z.B. wegwerf-Emails nicht akzeptiert werden ist bei vielen Foren aus guten Gründen der Fall. Sicherlich ist es schade das ohne Anmeldung nichtmals ein Lesezugriff existiert.

Klar können die Fragen auch hier gestellt und diskutiert werden, aber die Anzahl der Beteiligten ist halt ggf. deutlich geringer als im Forum der Macher... die soweit ich weiß alle keine N-Bahner sind.

Zum Bastelstatus:
es ist wohl angedacht in der nächsten Zeit auch vermehrt Fertigkomponenten anzubieten, wo dann nichtmals mehr Stiftleisten eingelötet werden müssen.

@Gerhard/75:
DCC ist auch ein Standard geworden den viele umsetzen und einhalten. PCs sind nur deshalb zu dem geworden was sie heute sind, weil offene Schnittstellen existieren und von verschiedensten Firmen genutzt werden können. Ja, da kommt es ggf. auch mal dazu das man die Komponente eines anderen debugged. Umgekehrt ist aber auch die eigene Komponente nie fehlerfrei und der andere wird mal deine Fehler suchen. Das gleiche Spiel hat man aber bei DCC, Railcom, etc. doch auch schon. Oft genug liest man z.B. im OpenDCC-Forum auch von Decodern die das System aus dem Tritt bringen. Manchmal weil ein Fehler bei der BiDiB-Komponente vorliegt, oft genug aber auch weil ein Decoder Fehler macht (die teils bereits mit neuerer Firmware behoben sind).
Aber ja, es gibt wohl auch z.B. Software-Hersteller, die zwar BiDiB sprechen wollten, aber nur mit von ihnen ausgewählten Komponenten... und alle anderen ausschließen. Denen wurde dann halt die Lizenz verwehrt. Zu Recht wie ich finde, ich will auch nicht nur Decoder von einer Firma auf meiner Anlage fahren können, nur weil der Hersteller der Zentrale mit den anderen Unstimmigkeiten beim DCC befürchtet.

Gruß,
  Daniel

Hallo Loddel,

da stellst Du eine recht steile Behauptung auf.
Wie schon Daniel geschieben hat, elitär ist da gar nichts.
Bisher wurden alle technischen Probleme gelöst, das wird sicher auch bzgl. Deiner Anmeldung so sein.
Du kannst mir eine PN schicken, dann könnte ich mich darum kümmern.


Für mich ist das ein System der Kundenbindung. Bei Loconet funktioniert es auch mit mehreren Herstellern.

Grüße
Stephan

Hallo Stephan,
elitär heißt : ausgelesen, erlesen. Wegen meiner Email-Domain wird der Anmeldevorgang abgebrochen. Das ist doch: ausgewählt. Außerdem halte ich Eliten nicht für grundsätzlich schlecht, höchstens dann, wenn ich nicht dazugehören darf.
Ja, ich versuche Dir eine PN zu schicken, es wäre aber bestimmt auch gut, wenn der Administrator auf dem dort auf der Internetseite angegeben Link erreichbar wäre.
Grüße
Lothar

JA
JA aber der Äerger wird extrem groß

Besetztmelder die über einen geeigneten Bus rückmelden.

Mit RailCom soll nicht nur die Adresse gemeldet werden es sind da noch viel mehr Dinge möglich. Beispiele sind automatisches Anmelden von neuen Fahrzeugen, das Bestätigen von Befehlen, die durch die Bestätigung danach seltener ausgesendet werden das schafft freie Bandbreite für Neues. Vereinfachung von Programmierung und Konfiguration der Fahrzeuge, neue Dinge wie virtueller Zugbus, also Kommunikation von Fahrzeugteilen miteinander so als wäre da ein Kabel dazwischen. Alle diese Neuerungen gehen nur wenn die Komponenten zusammen Arbeiten. Nur die Adressen rückmelden ist nur ein winzig kleiner Teil. Selbst wenn man nur das machen will hat man das Problem zu einem Steuernden PC dann mehrfache Verbindung von der Anlage zum PC bauen zu müssen. Viele Steuerungsprogrammen können damit aber nicht umgehen. Da die Zentrale oder Booster ohnehin kaum Geld kosten im Vergleich zur restlichen Infrastruktur rate ich die alten Lenz Komponenten in der Bucht zu entsorgen und eine Lösung zu suchen die den Weg in die Zukunft nicht verbaut.
-AH-

Was spricht eigentlich dagegen unter jedes Modul/Segment/Anlagenteil einen USB-Hub zu pappen und dann von jedem Rückmelder alles über USB zum Steuercomputer zu schicken? Der Steuercomputer kann dann alles zwischen 19" Rackserver, Raspi oder eingebaut in die Zentrale sein. Was kann der BiDiBus was USB nicht kann, besonders im Hinblick auf Rückmeldemitteilungen?

Grüße,
Harald.

Kann man machen wenn man nur simple Dinge machen will, also RailCom eigentlich gar nicht verwenden will sondern nur eine Zugnummernanzeige.
-AH-

Welche nicht-simplen Sachen würden denn mit USB nicht gehen meist?

Grüße,
Harald.

USB hat z.B. keinerlei Prioritäten, da quakt dich hinterher die Windmühle voll mit "habe mich gedreht", dafür darf der Rückmelder der dir die Zugkollision ankündigt schweigen. Weiteres Thema ist störanfälligkeit, die bei USB keine besondere Rolle spielt. Buslängen können auch ein Thema werden. Und nebenbei verteuert es manche Sache auch noch, denn wo bei BiDiB ein kleiner 8-Bitter reicht brauchts für USB schon min. spezielle 8-Bitter oder gleich ÄRMe etc.

Gruß,
  Daniel

Bei 280Mbit/sec brauch ich doch keine Prioritäten. Da bring ich 10kBit/sec RailCom und noch etwas mehr unter. Die Telefonleute haben auch immer behauptet dass Ethernet unbrauchbar wär weil es keine Prioritäten hat.

Störanfälligkeit: Löst man auf dem nächsten Protokollniveau. Wenn das nicht zu lösen ginge dann wär kein jpeg das über USB kommt ohne Bitfehler und beim Tippen mit meinem Keyboard würden Zeichen verschwinden.

Kosten: Was kostet ne USB-Hub aus nem Container aus Fernost?

Software: Als USB-HID anmelden und dann brauchts wahrscheinlich nicht mal spezielle Driver.

Grüße,
Harald.

280 MBit? Wo hast du die denn in der USB-Spec gefunden? Und was bringt dich auf den Trichter das ein Amok laufender Knoten keine 480MBit auf den Bus bringen könnte?
Ethernet selbst kann auch keine Telefonie. Das geht erst mit höheren Schichten, und die kennen wiederum auch Priorisierung. Ansonsten viel Spaß beim Telefonieren wenn ein Dateitransfer läuft.
Störanfälligkeit: schön. Geht alles auf deine Bandbreite und vor allem Latenzzeiten. Kommt die Belegtmeldung halt erst beim 20. Versuch an, nach jedesmal entsprechender Wartezeit beim Retransmit.
Kosten: wen interessiert der Hub? Wir reden von jedem einzelnen Melder etc. Davon mal ab wäre die Antwort: zuviel. Zumindest wenn ich mir anschaue was für einen #### an USB-Hubs ich bisher aus solchen Containern erhalten habe.
Software: wahrscheinlich? Ahja

Aber es hindert dich natürlich keiner dran dein eigenes System auf Basis von USB auf den Markt zu bringen. Die bisherigen Anbieter haben sich halt unter anderem aus den genannten Punkten nicht dafür entschieden.

Gruß,
  Daniel

Hallo Harald

Wieso den unbedingt USB.  Ethernet kostet auch nicht viel mehr. Heutzutage sind Ethernet Switches sehr günstig zu haben. Mit Ethernet kannst du dann auch mehrere Zentralen oder PC haben.
Gute Protokolle sind sowieso unabhängig von der Übertragungsschicht. Lösungen für die Monate gibt es auch schon.
In der Industrie wurden die RS485 basierenden Feldbusse durch Ethernetbasierte Lösungen ersetzt.

Gruss Matthias

zB das Quittieren von empfangenen Befehlen, Anmelden von neuen Loks... siehe auch Posting 83 von mir.

Zu der Frage weshalb USB vorgeschlagen wurde und nicht Ethernet: von Blücher und anderen gibt es RailCom fähige Besetztmelder die vie USB ihre Info abgeben können. Sinn der Sache ist den RailCom Traffic los zu werden wenn der Anwender ein Primitiv Bussystem an der Anlage hat das das Verkehrsvolumen nicht schafft - X-Press, R-Bus, LocoNet oder gar S88.  Ich kenne noch keine kaufbaren Besetztmelder die das über Ethernet anbieten. Da haben die Herstelelr wohl berechtigte Angst daß der Supportaufwand bei der Konfiguration von netzwerkfähigen Meldern nicht zu beherrschen sein wird. Roco zwingt die Anwender die voreingestellten Adressen zu verwenden, wenn man da was verstellt gibt's keinen Support - warum wohl?

Die Stellwerksprogramme haben derzet aber alle das Konzept ein "System" oder "Anlage" steuern zu wollen. Da steht der Gedanke _durch_ eine Zentrale die den Computeranschluss herstellt zugreifen zu können. EInige Programme können mehrere "Anlagen" gleichzeitig aber das Konzept "n mal Besetztmelder" direkt an den PC zu hängen unterstützt derzeit keiner.

Mit der USB Geschichte handelt man sich auch gerne ein Masseschleifenproblem ein. Ich habe Kunden die auf diese Weise USB Kabel zerschmolzen haben. Sicher ein Extremfall aber nicht ganz unlustig. Es gibt USB Brücken die galvanish trennen, wer erklärt das einem DAU? Falls man das hinbekommt erfindet schnell jemand einen noch dümmeren DAU und alle Arbeit war vergebens
-AH-

Hallo Arnold,

Vielen Dank fuer die Antworten.  Es hilft!. Und ich mache weiter mit Lenz. Es wird sowieso noch 10 Jahren dauern bis es zu dem Stand kommt, dass man meine Anlage ordentlich betrieben kann. In diese Zeit sollte das Lenz System ausreichend sein. Und so lange man die Verdrahtung hat und alle Zubehör Decoders weiter nutzen kann (also ueber DCC)  sollte der Umbau nicht so schlimm sein.

Nochmal Danke

Gruss Ivan

Es gibt demnächst ein System dass RailCom-fähige Rückmelder über S88 und Ethernet anbietet. Dafür wurde das S88-Protokoll kompatibel zu bestehenden S88-Meldern erweitert. Die ersten Prototypen laufen bereits in Anlagen.

Das System hat die folgenden Eigenschaften:
- Ein Modul hat 8 Kanäle, die sich in 8 Belegtmelder und 8 Kurzschlussmelder aufteilen
- Kurzschlussstrom und Belegtmeldeschwelle sind einstellbar
- Es werden kurze oder lange Lokadressen mit bis zu 4 Loks pro Kanal gemeldet
- Die Rückmeldung von PGM-Befehlen funktioniert genauso wie das Auslesen von CVs
- Die Lokaufstellrichtung wird erkannt

Schau mal unter http://www.lokstoredigital.de