Liebe Gemeinde
Feuer frei....

Hallo Werner,

da wurde schon genug geschrieben. Einfach nachlesen, da hast du alle Infos, die du brauchst.:

http://www.opendcc.de/info/railcom/railcom.html
http://www.digital-plus.de/digitalplus-railcom.php
http://www.digital-bahn.de/info_rm/rm_bidi.htm

und weitere 475.000 Ergebnisse in Google.

Gruss

Stephan

Zitat von supermoee

---

Hallo Werner,

da wurde schon genug geschrieben. Einfach nachlesen, da hast du alle Infos, die du brauchst.:

http://www.opendcc.de/info/railcom/railcom.html
http://www.digital-plus.de/digitalplus-railcom.php
http://www.digital-bahn.de/info_rm/rm_bidi.htm

und weitere 475.000 Ergebnisse in Google.

Gruss

Stephan

---

Hallo Stephan
mit Google war von mir so nicht gefragt, wollte Erfahrungen von Modellbahnern habe.

Zitat von werner1952

---

... wollte Erfahrungen von Modellbahnern habe.

---

Bitte schön:
Meine ESU 4 (XL) Loksound und LOPI Decoder melden sich via Railcom Plus an der ECoS II innerhalb von 3 Sekunden an. Probleme mit dieser Anmeldung hatte ich bislang noch nie ....

Viele Grüße,

Kalle

Moin Kalle

3 Sekunden.
Bei stehender Lok oder auch bei fahrender (Stichwort Zugverfolgung)
Ist das schnell genug für Zugverfolgung, oder geht die Erkennung schneller, wenn die Lok erst mal angemeldet ist und und im ICE3 Tempo von Rückmeldeblock zu Rückmeldeblock rauscht?

Zitat von Heinzi

---

Moin Kalle

3 Sekunden.
Bei stehender Lok oder auch bei fahrender (Stichwort Zugverfolgung)
Ist das schnell genug für Zugverfolgung, oder geht die Erkennung schneller, wenn die Lok erst mal angemeldet ist und und im ICE3 Tempo von Rückmeldeblock zu Rückmeldeblock rauscht?

---

Funkioniert RailCom® nur mit einem ICE3?

Zitat von Heinzi

---

Moin Kalle

3 Sekunden.
Bei stehender Lok oder auch bei fahrender (Stichwort Zugverfolgung)
Ist das schnell genug für Zugverfolgung, oder geht die Erkennung schneller, wenn die Lok erst mal angemeldet ist und und im ICE3 Tempo von Rückmeldeblock zu Rückmeldeblock rauscht?

---

3 Sekunden - das ist die Zeit für die erstmalige Anmeldung an der Zentrale. Also ähnlich MFX.

Mit Zugverfolgung meinst Du wohl das "Erkennen" der Lok über die entsprechenden Railcom Detectoren? Nun, ich habe die ECoS Detectoren im Einsatz. Von den 16 Eingängen sind 4 Railcom fähig. Wer's denn braucht? Ist wohl ein nettes Feature für automatischen Betrieb. So kann man einem PC Programm rückmelden, dass da auch wirklich der ICE 3 am Eingang 9 des Rückmeldebausteins vorbeihuscht und kein anderes Schienenfahrzeug.

Aber wirklich brauchen tue ich das eigentlich nicht. Das PC Programm weiss auch so, wo sich wann welche Lok befindet, bzw. zu befinden hat! Wenn da was nicht stimmt, dann hilft auch die Identifizierung der Lok via Railcom wenig ... dann hat man "Durcheinander" ...

Meine 2 ct zu dem Thema.

Viele Grüße,

Kalle

Hallo Werner,

Da deine Frage "was kann Railcom?" Und nicht "eure Erfahrungen mit Railcom" hiess, habe ich dich missverstanden. Ich bitte um Entschuldigung.

Es gibt Railcom und Railcom+. Bitte beachten.

Gruss

Stephan

Hallo zusammen.

Railcom kann in Verbindung mit der ECoS noch viel mehr.
Im Schattenbahnhof zeigt er dir natürlich die Loks mit Klarnamen auf dem Display an, sofern due Detectoren dort verbaust.
Aber für einen Automatikbetrieb gibt es die Möglichkeit über Lokkategorien die Fahrstraßen automatisch bzw. bevorzugt zu schalten.
Beispielsweise hat ein ICE natürlich Priorität bei der Ein und Ausfahrt im Bahnhof.
Durch die Erkennung der Lok kann die ECoS die Fahrwege entsprechend den Lokkategorien schalten.

Desweiteren hat natürlich Railcom den Vorteil die Dekoder auf dem Hauptgleis gezielt auszulesen und zu programmieren.
Ein Programmiergleis ist somit nicht mehr zwingend erforderlich.

Hallo
mich würde die Erfahrungen anderer Modellbahner interessieren.

Giulio

Hallo Leute!
Dem DCC-System wird ja manchmal nachgesagt, daß Befehle an die Lokdecoder umso schleppender ausgegeben werden,
je höher die Anzahl der gleichzeitig betriebenen Loks auf der Anlage ist. Man sagt, daß ab ca. 60 Zügen die Loks
von herkömmlichen DCC-Zentralen nicht mehr punktgenau zum Halten gebracht werden. Das ist sogar
nachvollziehbar, wenn man bedenkt, daß alle Lokbefehle im DCC-Datenstrom ständig wiederholt werden müssen, weil die
Zentrale ja nicht weiß, ob der angesprochene Decoder auch tatsächlich den für ihn bestimmten Befehl empfangen hat.
Man stelle sich nur mal eine Anlage vor, bei der im Schattenbahnhof 40 Züge halten und auf den sichtbaren Gleisen
vielleicht noch 15 Loks fahren. Das bedeutet ja, daß in jeder Befehlssequenz schon 40 mal der Befehl Fahrstufe 0
und 15 mal diverse Fahrstufen gesendet werden müssen. Jetzt kommen noch die Schaltbefehle für Zugbeleuchtung,
Sounddecoder, Weichen und Signale hinzu, dann ist man ganz schnell bei mehr als 64 Befehlen in der DCC-Befehlsschlange. Hiermit macht
Railcom jetzt Schluß, indem die Lokdecoder den Empfang eines jeden Befehls an die Zentrale zurückmelden. Das
geschieht bei Railcom als sogenannte ACK-Meldung auf Kanal 2. Da die Zentrale jetzt weiß, welche Befehle von den Decodern
schon empfangen wurden, müssen diese bestätigten Befehle nicht mehr wiederholt werden, was die Länge der
DCC-Sequenzen entscheidend verkürzt. Die Befehlsübertragung zu den Decodern wird also insgesamt viel schneller
als bisher möglich. Dazu kommt dann noch, daß man über POM-Read jederzeit die Werte von CVs von Loks auf dem
Hauptgleis auslesen kann. Mit diesem Feature hat man die Geschwindigkeitskurven von neuen oder unbekannten
Loksdecodern in Rekordzeit programmiert. Seit ich meinen GBM-Boost als Zentrale habe, möchte ich diese Möglichkeiten
nicht mehr missen.
Viele Grüße
Heinz

Hallo Heinz
welche Zentralen außer der ECOS können das?

Zitat von werner1952

---

welche Zentralen außer der ECOS können das?

---

bin zwar nicht Heinz, aber: so einige
z.B. OpenDCC, Ecos, Lenz, Viessmann, Roco Z21
eigentlich sollte das wohl jede Railcom Zentrale können, ist aber nicht immer implementiert

Hallo Werner!
Soweit ich weiß, wertet im Moment nur die BiDiB-Zentrale GBMBoost von Fichtelbahn/OpenDCC diese Befehlsempfangsbestätigung aus.
Ich benutze den GBMBoost zusammen mit Rocrail und bin äußerst zufrieden.
Gruß
Heinz

@ Werner
Wenn sich Deiner Frage auf die Befehlsoptimierung mit dem ACK bezieht, mir ist auch nur bekannt, dass das BiDiB-System das kann. Der Bus ist darauf ausgelegt, es gibt sogar dafür eine Leitung dafür:
http://bidib.org/bidibus/xtra_info.html (ganz unten "Warum ist der ACK eine separate Leitung?")

Ob mit CAN-Bus oder anderen überhaupt der Ack so schnell an die Zentrale weiter gegeben werden kann, dass eine Optimierung erfolgen kann, ist mir nicht bekannt.

@ Ulf
Beziehst Du Deine Antwort auch auf den ACK. Falls ja, hast Du andere Infos als ich?

Hier noch ein paar Infos was Railcom z.Z im BiDiB-System kann:
http://wiki.fichtelbahn.de/doku.php?id=railcom

Grüße
Stephan

Zitat von stephan_bauer

---

@ Ulf
Beziehst Du Deine Antwort auch auf den ACK. Falls ja, hast Du andere Infos als ich?

---

nein, die bezog sich nur auf Railcom+POM

Zitat von kaeselok

---

Zitat von Heinzi

---

Moin Kalle

3 Sekunden.
Bei stehender Lok oder auch bei fahrender (Stichwort Zugverfolgung)
Ist das schnell genug für Zugverfolgung, oder geht die Erkennung schneller, wenn die Lok erst mal angemeldet ist und und im ICE3 Tempo von Rückmeldeblock zu Rückmeldeblock rauscht?

---

3 Sekunden - das ist die Zeit für die erstmalige Anmeldung an der Zentrale. Also ähnlich MFX.

Mit Zugverfolgung meinst Du wohl das "Erkennen" der Lok über die entsprechenden Railcom Detectoren? Nun, ich habe die ECoS Detectoren im Einsatz. Von den 16 Eingängen sind 4 Railcom fähig. Wer's denn braucht? Ist wohl ein nettes Feature für automatischen Betrieb. So kann man einem PC Programm rückmelden, dass da auch wirklich der ICE 3 am Eingang 9 des Rückmeldebausteins vorbeihuscht und kein anderes Schienenfahrzeug.

Aber wirklich brauchen tue ich das eigentlich nicht. Das PC Programm weiss auch so, wo sich wann welche Lok befindet, bzw. zu befinden hat! Wenn da was nicht stimmt, dann hilft auch die Identifizierung der Lok via Railcom wenig ... dann hat man "Durcheinander" ...

Meine 2 ct zu dem Thema.

Viele Grüße,

Kalle

---

Ich she das eigentlich genau umgekehrt. Erst die intelligente Rückmeldung macht Railcom sinnvoll. Also wo einer Automatic während des Betriebs laufend mitgeteilt wird, welche Lok sich gerade wo befindet. Das automatische Anmelden, gerade wenn man eine Lok neu auf die Anlage stell empfinde ich als nettes Features aber nicht für den Fahrbetrieb nicht relevant. Denn ich stelle nicht dauernd Fahrzeuge auf die Anlage und nehm sie gleich wieder weg.

Nach meiner Erfahrung funktioniert die nicht intelligente Zugverfolgung für die allermeisten Fälle als ausreichend, sofern alles zuverlässig funktioniert. Das kenne ich aus eigener Erfahrung mit Windigipet. Stürzt Windigipet (extrem selten) oder PC generell ab, dann "vergisst" das Programm gerade die laufende Anlagesituation unmittelbar vor dem Problem. Man muss dann alle Züge kontrollieren, ob sie an dem Ort stehen, wo sie das Programm gerade noch in Erinnerung hatte. Da wäre natürlich schon, wenn der PC nach dem reboot wieder mitgeteilt bekäme, welcher Zug sich gerade wo befindet.

Genau die selbe Situation ist, wenn man mal fahren will ohne PC, dann hat der PC einen bestimmten Stand abgespeichert. Dieser Stand wird aber verändert, wenn man händisch fährt (ohne eingeschalteten PC). So stimmt beim nächsten Start des PCs die Situation Wahrheit mit dem PC nicht überein. Auch da wäre es toll, wenn eine Intelligenz dem System genau mitteilt welcher Zug sich gerade wo auf der Anlage befindet.

Hierzu wären durchaus mal Erfahrungsberichte interessant.

Ansonsten ist die heute weit verbreitete passive Rückmeldeart mehr als ausreichend.

Das ganze Railcom System für eine intelliente Positionsrückmeldung ist ja letztlich auch nur dann zu 100% nutzbar, wenn man alle Decoderfahrzeuge mit Railcomdecodr ausgestattet hat, was ja auch selten der Fall sein wird. Wenn ich den Fahrzeugpark auf unserer Anlage so betrachte, dann gibt es in den Modellen Decoder aus mindestens einem Jahrzeht Decodergeschichte über mehrere Hersteller hinweg. Das geht von dem 6090er von Märklin, viele 60902 von Märklin, dann Decoder von Lenz, Zimo, ESU, Uhlenbrock bis hin zu den aktuellen mfx Decoder von Märklin und nicht zuletzt welche von Tams. Bei weitem nicht alle sind Railcomtauglich. Aber sie fahren alle zusammen auf einer Anlage über die selbe Zentrale.

moin,
RailCom-fähig bekommt man jeden Zug mit wenig Aufwand und Kosten und man hat auch noch einen Funktionsdecoder dabei
http://www.tams-online.de/htmls/produkte...ukte_fd_r2.html
Gruß Kersten Tams

Zitat von ktams

---

moin,
RailCom-fähig bekommt man jeden Zug mit wenig Aufwand und Kosten und man hat auch noch einen Funktionsdecoder dabei
http://www.tams-online.de/htmls/produkte...ukte_fd_r2.html
Gruß Kersten Tams

---

Klar bekommt man das bei jedem Zug auf die Reihe, keine Frage. Ist halt für den User (je nach Stand seines Fahrzeugparks und Alter der Decoderflotte) mit mehr oder weniger Kosten verbunden. Ist aus Ihrer Sicht Hr. Tams verständlicherweise ein Geschäft in dem Sie Geld verdienen und so auch weiter existieren können, was ja auch ihr gutes Recht ist.

Bleibt die Frage, ob das schon jemand hat und hier über die Erfahrung berichten kann?

Entscheidend dabei ist natürlich die Einlesegeschwindigkeit. Beträgt sie wie bei der Lokeinlesung ebenfalls 3sek ist das für diesen Zweck ja wohl untauglich. Auch eine Modelllok legt in dieser Zeit schon einiges Strecke zurück.

Und wenn ich an unsere Anlage denke bei Vollbetrieb, wäre die Datenmenge schon recht gross, die da laufend zurückgelesen wird. Wenn also eine Lok in die Stopstrecke (RM Kontakt, der für die Halteposition zuständig ist) einfährt und es würde von da an 3sek dauern, bis das Computerprogramm erkennt, dass die Lok jetzt zum Stehen gebracht werden muss, wäre die Lok bereits drüber hinweg, wenn sie zum Stehen kommt bei sanfter Bremsweise.

Zitat von Martin Lutz

---

Wenn also eine Lok in die Stopstrecke (RM Kontakt, der für die Halteposition zuständig ist) einfährt und es würde von da an 3sek dauern, bis das Computerprogramm erkennt, dass die Lok jetzt zum Stehen gebracht werden muss, wäre die Lok bereits drüber hinweg, wenn sie zum Stehen kommt bei sanfter Bremsweise.

---

Dann hast Du das Wechselspiel zwischen sofortiger Meldung und latentem Identifizieren nicht verstanden. Das Programm weiß bereits vor der Einfahrt in den Meldeabschnitt, welcher Decoder den Bereich wechselt, denn das sich bewegende Fahrzeug identifiziert sich permanent auf der Anlage.

Und wenn Du (zum Beispiel aus Kostengründen) nur wenige Abschnitte mit Identifizierung verbauen willst, so legst Du diese in die Blöcke vor die Halteabschnitte.

Hallo,

ich kann bei den Meldezeiten nur von BiDiB sprechen.
Wie oben schon geschrieben, werden die Adressen ja permanent gemeldet.
Diese Adress-Meldungen der jeweiligen Decoder, sind quasi in Echtzeit in RocRail, WDP oder iTrain zu sehen.
Bei BiDiB vor allem "Flächendeckend". Also auf allen Belegtmeldeabschnitten.
Die RailCom-Detektoren sind dort Bestandteile der Belegtmelder.

Daneben kann BiDiB auch noch weitere Information vom Decoder an das Hostprogramm weiter geben.
- Geschwindigkeit
- Aufgleichsrichtung (bei Zweileiter)
- Temperatur
- Signalqualität (lässt dann auf verschmutzte Gleisabschnitte oder Räder schließen)

Das müssen die Decoder aber auch können und per RailCom liefern.
Gerade Signalqualität melden im Moment (leider) nur wenige.
Meines Wissens zur Zeit nur die Decoder von Doehler & Haass und die neuen Decoder von Tams (jeweils mit aktueller FW) .
Hier sind einige Decoder auf RailCom-Fähigkeiten getestet http://www.opendcc.de/info/railcom/railc...r_overview.html

Anlagen, die BiDiB verwenden, werden hier im Forum ja einige vorgestellt:

viewtopic.php?f=64&t=84209&start=50
viewtopic.php?f=64&t=98111&hilit=bidib#p1062964
http://www.cs2.stummiforum.de/viewtopic....872&hilit=bidib

Hallo,

ich würde diesen Thread gerne um "Was Railcom NICHT kann" erweitern. Ich vermisse eine Rückmeldung der Parameter "tatsächliche Geschwindigkeit" und "prozentuale Stromaufnahme". Beide Parameter wären nötig, um eine Modellbahnlokomotive vorbildgetreuer steuern zu können. Leider erlaubt die reale Modellbahntechnik ausschliesslich Spielzeugartigen Betrieb.

Wenn diese Parameter vorliegen würden, könnte man z.B. eine Lok kurz beschleunigen und dann ohne Gas langsam ausrollen zu lassen, eben wie eine reale Lok -- oder z.b. auch ein Auto -- gefahren wird.

Schade, das ist eine verschenkte Chance, die z.B. die Steuerung in Oli4's Kultthread ausgiebig nutzt.

Kersten, wie sieht's aus?

Michael

Hi Michael,

deine gewünschten Features scheitern laut ESU dran, das man sich (NMRA, also außerhalb Deutschlands) nicht einigen kann, welche Funktionen wie übertragen werden, sprich eine einheitliche Norm erstellt wird. Dann und erst dann können diese Funktionen auch in der Zentrale mit (entsprechender Software) abgerufen werden. Das ist auch der Grund, weshalb die Daten des ESU-Messwagens nicht auf der Ecos (noch nicht)angezeigt werden können.
Genauer kann ich es nicht erklären, sondern eben nur widergeben, was mir gesagt wurde.

Robert

Moin zusammen

Zitat

---

Ich vermisse eine Rückmeldung der Parameter "tatsächliche Geschwindigkeit" und "prozentuale Stromaufnahme

---

Ich erlaube mir an dieser Stelle (Mangels verständniss) dann mal die Frage was genau man sich davon für Vorteile erschaft.
Bei lastgeregelten Decodern mit linearerer Geschwindigkeitskennlinie ist die Sollgeschwindigkeit (von der Zentrale vorgegeben) doch bereits recht genau mit der ist Geschwindigkeit übereinstimmend. (Jedenfalls bei mir mit einigen wenigen Ausnahmen und logo im stabilen Zusand).
Prozentuale Stromaufnahme: Was ist denn 100% und was ist der Bezug zum Vorbild und was macht man mit dieser Angabe?