Hallo.

Die Firmen Lenz, Tams, Kühn, Zimo, Roco/Fleischmann und Viessmann haben so viel ich weiss Gespräche gehabt und zusammen der
Standardisierung der Rückmeldung auf Basis des DCC-Protokolls mit Railcom sich vereinbart.

Rutger Friberg (früher Technical Board der NMRA) hat sich bereit erklärt, unter dem Dach der beiden Modellbahn-verbände MOBA und BDEF
eine neue Normung der Digitalsysteme DCC - Railcom für Europa in deutscher Sprache zu organisieren und zu moderieren.

Die Gespräche haben an den Messen in Köln und Nürnberg stattgefunden und es wird erwartet dass die Hammer in Dortmund geschlagen wird.

Jetzt läuft vielleicht die Entwicklung von RailCom schneller.

Zitat von Tom Blikstad

---

...und es wird erwartet dass die Hammer in Dortmund geschlagen wird.

---

Wo auch sonst?

Zitat

---

Rutger Friberg (früher Technical Board der NMRA) hat sich bereit erklärt, unter dem Dach der beiden Modellbahn-verbände MOBA und BDEF
eine neue Normung der Digitalsysteme DCC - Railcom für Europa in deutscher Sprache zu organisieren und zu moderieren.

---

Hallo Tom,

dann kann eigentlich nicht mehr viel schiefgehen, wenn nicht irgendein Hersteller durchknallt.

Gibt`s da irgendwo ein Communiqué oder sonst was Anklickbares?

Danke und Gruss,
Manfred

Hallo Manfred.

Ja, gibt es: Link

Hallo Manfred, Hallo zusammen,

Zitat

---

Gibt`s da irgendwo ein Communiqué oder sonst was Anklickbares?

---

einiges zum neuen RailCombus kann man hier schon erfahren.

Viele Grüße
Frank

Hallo Tom,

merkwürdig, da gab`s doch Unkenrufe, dass ESU teilweise vorgeprescht sein soll, insbesondere beim Weichendecoder.
Wie soll das aber geschehen sein, wenn die von Lenz lizenziert worden waren und Lenz wirklich so darauf schaut, dass die heiklen Standards tatsächlich auch eingehalten werden?

Na ja, wenigstens scheint nun die zweite Stufe gezündet zu werden - mit Roco/Fleischmann, ESU und Viessmann an Bord - sicher keine schlechten Aussichten, wenn auch geographisch nicht so breit abgestützt wie das wünschbar wäre.

Je mehr über das Gleis geht, desto unabhängiger ist man von den meist proprietären Bus-Protokollen.

Gruss,
Manfred

Hallo Manfred,

Zitat

---

Je mehr über das Gleis geht, desto unabhängiger ist man von den meist proprietären Bus-Protokollen.

---

Wer sagt denn, das der RailComBus properitär ist? Er verbindet sich ja mit USB, XPressNet und Commander. Mal sehen was nocht kommt. Als Hardware reicht ne USB-Buchse und Standard-RJ45-Kabel. Eigentlich erübrigen sich so eher die "properitären" Booster.

Viele Grüße
Frank

Hallo Frank,
ich dachte gar nicht an den RailCombus, sondern an alle die andern, von ESU über ZIMO über LocoNet, usw.

Hatte Dein Posting mit dem Link zum RailCombus noch gar nicht gelesen.

Gruss,
Manfred

Zitat

---

Je mehr über das Gleis geht,.......

---

........je mehr probleme kann es geben.
........je mehr wird emv zum thema.


mal ehrlich
ich frage mich nur wie diese entwicklungskosten wieder eingefahren werden. wo der wirkliche mehrnutzen ist? (gegenüber eienr pc basierten zugverfolgung)
man rechne nur all die zusatzkosten....... da hat man vermutlich bald einen pc inkl sw und 21" bildschirm zusammen.

nein ehrlich:
eine lok erkennung im schattenbahnhof liesse ich mir auch was kosten.

Hi Heinzi,

die kosten holt man sich so wieder rein: rückmeldedecoder für 4 railcom abschnitte 185 euro.. siehe ESU thread auf der nürnberger messe

da bin ich noch gespannt was da kommt... bei den preise nicht viel... und wie du schon sagst wird ein PC für großbahner ein echtes schnäppchen...

Mahlzeit,

Zitat

---

rückmeldedecoder für 4 railcom abschnitte 185 euro..

---

Tams verlangt fuer einen Rueckmeldedetektor 25 EUR, also fuer vier Abschnitte 100 EUR.
Der Tams-RS485 wird vermutlich auch kompatibel zum RailCom-Bus sein/werden, bzw, es wird sicher Schnittstellen geben.

Was mir bei dem ESU-Dings fehlt, ist eine Angabe zur Zuordenbarkeit der Belegtmeldeabschnitte zu den RailCom-Lokaldetektoren.

Auf 16 Belegtmeldeabschnitte kommen 4 Detektoren.

Im Übrigen dachte ich, dass auch an einer Lösung mit lokalen Sendern gearbeitet wird, die ihren Abschnitts-Code an die Decoder melden und diese wiederum ihre Adresse und den empfangenen Abschnittscode an den Globaldetektor?

Gruss,
Manfred

Hi Manfred,

Zitat

---

Im Übrigen dachte ich, dass auch an einer Lösung mit lokalen Sendern gearbeitet wird, die ihren Abschnitts-Code an die Decoder melden und diese wiederum ihre Adresse und den empfangenen Abschnittscode an den Globaldetektor?

---

Das duerfte der "Kilometerstein" von Zimo sein.

Hi Thomas,

Für uns gut für Railcom weniger gut.. wenn bereits jetzt der Preiskrieg zwischen dem Lowcost Anbieter TAMs und den anderen Railcommitgliedern anfängt dann werden wohl einige dort wieder aussteigen weil sie die kosten nicht einspielen können... das schafft nur frust und keine lust.

Nun weisst du warum in den USA sich die hersteller um eigene protokolle kümmern und lancieren.. weil sie dann halt die preise selbst bestimmen und geld verdienen können.

bin gespannt ob herr tams dann bei den sitzungen noch willkommen ist wenn seine produkte um 40% weniger kosten als die von ESU oder ROCO und doch das gleiche können...falls sie das können.

uns als user ist das kurzfristig egal.. langfristig kann es uns aber nicht egal sein...

Hallo,

das Detektoren teuere sind als herkömmlich Gleisbesetztmelder war ja zu erwarten.
Allerdings muss man seine Anlage ja auch nicht flächendeckend mit Railcom Detektoren zupflastern. Das Hauptproblem, der Steuerungen die auf Zugverfolgung basieren, ist ja das man der Software den Initialzustand mitteilen muss. Und da kann jetzt Railcom die Brücke zwischen überwachtem und nicht überwachtem Teil der Anlage schlagen, indem alle in den Bereich einfahrenden Züge der Software gemeldet werden.
Ich könnte mir durchaus vorstellen, das z.B. die Ecos irgendwann eine darauf basierende Schattenbahnhofssteuerung bietet. Dafür scheint das Modul gut ausgelegt zu sein: SBF an doppelgleisiger Strecke, je ein Detektor in jedem Zufahrtsgleis und dann noch 12 weitere Rückmeldekontakte, die man im SBF verbauen kann.

Was jetzt die Preisdiskussion Tams / ESU angeht, so darf man nicht nur die Detektoren betrachten sondern den gesamten Baustein:
Tams:
- 4 Detektorean á 25€ = 100€
- 12 Gleisbesetzmeldemodule: 3xGBM-1 (31,90€ + S88-3 (32,90€ = 128,60€

ESU:
- komplett 185€

Da ist keinen Preisvorteil bei den Tams Modulen, zumal ich da jetzt noch nicht mal die Gehäuse für die Tams Module noch extra aufgezählt habe. Das man mit Bausätzen Geld sparen kann ist doch schön aber diese Preise darf man bei einem ehrlichen Vergleich nicht heranziehen. Das es für den einzelnen je nach Anwendungsfall günstiger sein dürfte sich für die einzelnen Module zu entscheiden, da er z.B. die GBMs nicht benötigt steht auf einem ganz anderen Blatt.

Gruß
Michael

Max,

Zitat

---

Für uns gut für Railcom weniger gut.. wenn bereits jetzt der Preiskrieg zwischen dem Lowcost Anbieter TAMs und den anderen Railcommitgliedern anfängt dann werden wohl einige dort wieder aussteigen weil sie die kosten nicht einspielen können... das schafft nur frust und keine lust.

---

Das ist Kaese. Bei RailCom tut sich was und ich habe als Kunde die Wahl. Lege ich auf bestimmte Eigenschaften wert muss ich entsprechend bezahlen, benoetige ich nur bestimmte Eigenschaften reicht mir vielleicht die preiswerte Loesung. Fuer die breite Akzeptanz ist das gut und genau das ist das, was z.B. Maerklin mit mfx fehlt.

Beispiel: Brauche ich Rueckmelder und Detektoren in Kombination, dann nehme ich die Loesung von ESU. Brauche ich nur Detektoren, dann greife ich zu Tams oder Lenz. Brauche ich einen Booster mit integriertem global Detektor, dann kann ich zu Lenz(?), Zimo oder ESU greifen, reicht mir die Austastluecke, dann kann ich im guenstigsten Fall meinen alten Booster mit einem Umbaukit, was lt. einem der Messeberichte von Tams kommen soll, fuer wenig Geld RailCom-faehig machen.

Es ist eine Auswahl da und das ist gut so.

Zitat

---

Nun weisst du warum in den USA sich die hersteller um eigene protokolle kümmern und lancieren.. weil sie dann halt die preise selbst bestimmen und geld verdienen können.

---

Welche US-Hersteller lancieren eigene Protokolle?

Gruss,
Manfred

Hallo zuammen,

Zitat von Manfred

---

Welche US-Hersteller lancieren eigene Protokolle?

---

Digitrax positioniert Transponding.

Eine Loko sendet ihre Adresse an die "Belegtmelder", die nun Abschnittsnummer, Belegtzustand und Lok-ID ins LocoNet einspeisen.

So ähnlich kann man sich auch den neuen RailComBus vorstellen.

Als ein vollwertiger Rückmeldebus, der aber nicht nur Belegtzustand und Lok-Adresse, sondern auch noch Lokdaten (Geschwindigkeit, Stromverbrauch, ? ) auf den Rückmeldebus legt.

Sicher wird es stark vom Preis der "RailCom-Belegtmelder" abhängen, inwieweit und wie schnell der RailComBus sich als "qualifizierte" Alternative zum traditionellen Rückmeldebus (RS, S8 oder als AddOn zum vorhandenen Systembus positioneren kann.

Bei Bedarf kann man den sowohl direkt in eine zentralen Steuerung (via USB z.B. PC, Commander, ?), oder mittels einen properitärem Systembus-Gateway (XPressNet, wer ist der nächste ?) potentiell in Systembusse sonstiger bestehender DCC Anbieter einspeisen.

Ich hoffe wegen der Ringarchitektur, das beliebig viele Geräte (Interfaces, lokale Steuer- und Anzeigegeräte) die Infos mittels "einschleifen" verwerten können, so das der Bus letztendlich sowohl lokales als auch als globales RailCom bereitstellen kann.

Viele Grüße
Frank

Hallo Thomas,

Zitat von Muenchner Kindl

---

Bei RailCom tut sich was und ich habe als Kunde die Wahl. Lege ich auf bestimmte Eigenschaften wert muss ich entsprechend bezahlen, benoetige ich nur bestimmte Eigenschaften reicht mir vielleicht die preiswerte Loesung. Fuer die breite Akzeptanz ist das gut und genau das ist das, was z.B. Maerklin mit mfx fehlt.

Beispiel: Brauche ich Rueckmelder und Detektoren in Kombination, dann nehme ich die Loesung von ESU. Brauche ich nur Detektoren, dann greife ich zu Tams oder Lenz. Brauche ich einen Booster mit integriertem global Detektor, dann kann ich zu Lenz(?), Zimo oder ESU greifen, reicht mir die Austastluecke, dann kann ich im guenstigsten Fall meinen alten Booster mit einem Umbaukit, was lt. einem der Messeberichte von Tams kommen soll, fuer wenig Geld RailCom-faehig machen.

Es ist eine Auswahl da und das ist gut so.

---

woher weiß ich denn, was ich brauche? Was leisten denn die verschiedenen Varianten in der Zukunft? Kann ich denn Rückmelder und Detektoren frei wählen oder müssen die nicht auf Bussysteme und somit auf bestimmte Zentralen abgestimmt sein?
Wettbewerb und Auswahl sind sicherlich gut, aber dazu braucht es Informationen darüber, was geht. Das ist bei Produkten oder hier besser Systemen, die erst am Anfang ihrer Entwicklung stehen, nur schwer absehbar. Für die Produzenten schon und für die Kunden erst recht.
Der Thread hatte ja den Ursprung, freudig ein gemeinsames Vorgehen der wichtigsten Anbieter publik zu machen. Ich stimme Dir in der Stoßrichtung zu, dass es gut ist, wenn die jetzt aktiv werden, aber ich glaube, dass trotzdem die Vorstellung, was daraus werden soll, möglichst eng gemeinsam entworfen und weiterentwickelt werden muss. Sonst droht das übliche Wettbewerbschaos. Wenn heute jemand sagen würde, "ist doch gut, dass es MM (mfx), DCC und SX gibt, dann hat jeder die Wahl, genau das zu kaufen, was er genau braucht" dann würde man über solchen Unfug genauso lächeln wie wenn er sagen würde "ist doch gut, dass es verschiedene Kupplungstypen gibt, dann kann jeder genau das wählen, was er braucht." Der Wettbewerb mag für den Anschub ganz gut sein, tatsächlich fließt dann anschließend jahrzehnte-lang alle Energie in Bemühungen, die unterschiedlichen Systeme nachträglich wieder zusammen zu führen, wobei vieles überhaupt nicht mehr geht (wie wir an den "Märklin vs. Rest der Welt"-Debatten leidvoll erleben).

Gruß Dietmar

Hallo,

Zitat

---

woher weiß ich denn, was ich brauche?

---

Hier ist normalerweise der Fachhandel gefragt, allerdings duerfte es einfacher sein, mfx zu verkaufen.

Zitat

---

Was leisten denn die verschiedenen Varianten in der Zukunft?

---

Zitat

---

Kann ich denn Rückmelder und Detektoren frei wählen oder müssen die nicht auf Bussysteme und somit auf bestimmte Zentralen abgestimmt sein?

---

Tja... da ist tatsaechlich nicht alles im Reinen. Genormt ist die Kommunikation zwischen Decoder und Detektor, der Weg zur Zentrale oder Applikation ist nicht genormt. Ich gehe hier davon aus, dass sich der RailCom-Bus von Lenz durchsetzen wird, der Tams-RS485 wird dazu kompatibel sein, evtl. ueber Schnittstellen. Was Zimo macht weis ich nicht, die haben allerdings meines Wissens nach keine lokalen Komponenten, Kuehn hat nur Decoder, Viessmann ist wohl erst eingestiegen und ESU wird vermutlich eine eigene Suppe ueber CAN kochen.

Generell ist es aber so, dass man einfach schauen muss, was man denn braucht. Reicht es mir, meinen Schattenbahnhof zu ueberwachen oder will ich die Ist-Geschwindigkeit auf dem Display der Zentrale sehen. Will ich, abhaengig von der Lokadresse, eine Aktion ausloesen oder soll RailCom nur als Programmierhilfe (Auslesen von CV auf Hauptgleis) verwendet werden.

Ja, nicht jedes System kann alles, nicht jeder Decoder besitzt alle moeglichen Eigenschaften, nicht jede Zentrale kann alles anzeigen... hier sehe ich Potential fuer die Fachhaendler... viel Potential! Vermutlich wird es bei ein paar "Beratern" (nicht Alix ) , den Herstellern selbst oder eben Foren bleiben.

Zitat

---

woher weiß ich denn, was ich brauche? Was leisten denn die verschiedenen Varianten in der Zukunft? Kann ich denn Rückmelder und Detektoren frei wählen oder müssen die nicht auf Bussysteme und somit auf bestimmte Zentralen abgestimmt sein?

---

Das sind m. E. *die* Fragen.

Für den "stand alone" Betrieb des RailCom-Busses von Lenz soll es ein "LRC 140 XpressNet-Gateway" geben, das ist aber noch nicht mal grob beschrieben.

Wie binden andere Hersteller den RailCom Bus in ihre stand alone Lösungen ein, wenn der zum Standard werden sollte?

Abgesehen davon: Wird das nicht selbst für die überzeugtesten Lenz-Anwender langsam etwas unbequem: Gerätebus, Rückmeldebus und nun noch ein RailCom-Bus?

Sollten da andere mittun, die bislang alles über ein Kabel leiten konnten?
Zimo? Die LocoNet-Leute (so sie sich denn mal dazu herablassen würden)?
ESU? Viessmann? Märklin? Trix? Hornby?

Wieso sollten sie?

Und dann dafür die Ankettung des Users an die oben erwähnten proprietären Busse?

Warum nicht der angedachte "Kilometerstein" ohne Busanbindung, der auch konventionelle Besetztmeldungen zuhanden des Globaldetektors der jeweiligen Booster-Sektion absetzen könnte?

Gruss,
Manfred

Hallo alle zusammen,

ich gebe zu, ich habe mich noch nicht mit Railcom beschäftigt, aber das prädestiniert mich doch auch als "Beratungsversuchskaninchen".

Bisher verstehe ich nämlich noch nicht so recht, was nun eigentlich genormt ist.
- Die Hardware (Bussystem)?
- Die übertragenen Inhalte?
- Das Datenprotokoll?

Kann man damit nun Komponenten verschiedenster Hersteller miteinander kombinieren oder bin ich doch auf die Komponenten eines Herstellers angewiesen, weil die am besten zusammenarbeiten?
Einiges Proprietäres lese ich doch schon aus den vorherigen Postings heraus... Das ist doch Käse!

Und was ist, wenn ich verschiedene Komponenten miteinander mische und irgendwas nicht geht? An wen wende ich mich dann?

Vielfalt ist ja schön und gut (wie bei Lokdecodern), aber eine Garantie, dass es alles funktioniert, sehe ich noch nicht.

Oder sehe ich das völlig falsch? Nur zu, macht mich schlau...

Zitat

---

Bisher verstehe ich nämlich noch nicht so recht, was nun eigentlich genormt ist.
- Die Hardware (Bussystem)?
- Die übertragenen Inhalte?
- Das Datenprotokoll?

---

Wenn ich das richtig mitgekriegt habe allenfalls das Datenprotokoll (und ein bisschen Inhalt).

Zitat

---

Kann man damit nun Komponenten verschiedenster Hersteller miteinander kombinieren oder bin ich doch auf die Komponenten eines Herstellers angewiesen, weil die am besten zusammenarbeiten?
Einiges Proprietäres lese ich doch schon aus den vorherigen Postings heraus... Das ist doch Käse!

---

Sollte schon gehen, solange sie nicht an einen der proprietären Busse angebunden werden müssen.

Aus Schaden klug geworden: Lenz soll die Lizenzen nur noch vergeben, wenn die Dinger tatsächlich RailCom-konform arbeiten, da die Sache sehr viel heikler sein soll als das DCC-Protokoll.

Wer hat den Schaden angerichtet? Die NMRA mit ihrer Laxheit insbesondere den amerikanischen Herstellern gegenüber.
Obschon es Test-Software gibt, foutieren sich viele Hersteller darum und reden von DCC-Kompatibilität (ausser Lenz hat auch kaum je ein europäischer Hersteller ein NMRA Conformance Seal, vulgo "Football" beantragt).
Meistens geht das auch leidlich gut, aber halt beileibe nicht immer. Und sowieso ist die Normung der tatsächlichen
Entwicklung gegenüber meist hinterdrein. Das bezieht sich auf DCC, nicht auf RailCom.

Wenn was nicht klappt, sollten die beteiligten Hersteller die Adressaten sein, denn es liegt in ihrem eigenen Interesse, dass sich ihre Investitionen zukünftig auszahlen werden. Das gelingt nicht mit Schwarzpeter-Politik und Murks.

Gruss,
Manfred

Hallo Manfred,

Zitat

---

Abgesehen davon: Wird das nicht selbst für die überzeugtesten Lenz-Anwender langsam etwas unbequem: Gerätebus, Rückmeldebus und nun noch ein RailCom-Bus?

---

Der RailComBus kann den Rückmeldebus (via USB an PC oder via GateWay zum XPressNet) ersetzen .

Das die Tams auch XPressNet Anschlüsse hat, sollte beides auch für den Betrieb mit der Tams gelten.

So verstehe ich zumindest die Ankündigungen, habe aber selbst noch keine technische Protokollbeschreibung, deren Veröffentlichung jedoch bereits angekündigt wurde.

Da konfektioniertes Kabel (RJ45) verwendet werden, dürfte diese Lösung einen Tick bequemer sein als das Verlegen eines 2-adrigen RS-Bus oder eines 6 adrigen s88.

Der wesentliche Vorteil des RailComBus für Leute mit bestehender DCC-Anlage dürfte allerdings die prinzipielle Nachrüstbarkeit Ihres Systems sein oder werden.

Viele Grüße
Frank

Hi Udo,

genormt ist das:
- Die übertragenen Inhalte?
- Das Datenprotokoll?

Es gibt ein paar Minimalanforderungen, diese sind dann bei allen Herstellern gleich.

So muss z.B. RailCom ueber die CV29 ein/aus geschalten werden koennen, ueber CV28 wird gesteuert, was uebertragen werden darf.
Ein RailCom-Decoder muss in der Lage sein, seine Adresse stets zu senden, ebenso muss er auf Anfrage den Inhalt einer CV ausgeben.
Ein Detektor muss die gesendete Adresse oder CV lesen koennen.

Was danach passiert oder was zusaetzlich ueber den gleichen Kanal uebertragen wird ist herstellerspezifisch.

Ich z.B. nutze RailCom dazu, anzuzeigen, welcher Zug auf welchem Gleis steht und als Programmierhilfe beim Hauptgleisprogrammieren. Dabei spielt es keine Rolle, ob da ein Tams, ein Lenz oder ein Zimo-Decoder drinsteckt, die minimalfunktionen gehen immer.

Zimo z.B. zeigt die Ist-Geschwindigkeit der Lok im Display der Zentrale an, das wird vermutlich mit einem Tams-Decoder nicht funktionieren. Von Lenz habe ich so eine exakte Positionsangabe (gefahrene mm) im Hinterkopf, das duerfte auch nur mit Lenz gehen.

Fuer meinen Fall koennte ich auch Lenz-Detektoren und Anzeigen einsetzen, oder Lenz-Booster.

Bei mir sieht das uebrigens so aus:

aktuell sind drei Gleise ueberwacht, ich sehe hier die vierstelligen Adressen der Loks, die auf dem jeweiligen Gleis stehen (ist eine Betatest-Konstellation, deshalb zusaetzlich die 7-Segment-Anzeigen)
Funktioniert mit allen Decodern zuverlaessig.