Hallo Udo,

Zitat

---

Bisher verstehe ich nämlich noch nicht so recht, was nun eigentlich genormt ist.

---

Zitat

---

- Die Hardware (Bussystem)?

---

die genormte Hardware ist erstmal das seit vielen Jahren "genormte" Verfahren zur Übertragung von Bits und Bytes durch Gleis. Dem kommt bei Railcom eine besondere Bedeutung zu, da RailCom kein aus anderen Anwendungen übernommenes Verfahren ist, sondern ein speziell auf die Belange der DCC-MoBa hin entwickelte Technik.

Der RailComBus ist ein genormetes Bussystem zur Übertragung von Belegtmeldung und RailCom-Daten. seine Verwendung ist nicht Bestandteil von RailCom selbst , so das RailCom natürlich auch anderweitig übertragen werden kann. (z.B. auch global direkt in einen Detector des Boosters (z.B. ESU,Zimo).

Zitat

---

- Die übertragenen Inhalte?

---

Die werden wohl vom Hersteller des Decoders festgelegt werden dürfen.
Ich könnte mir vorstellen, das es auf ein Lösung hinausläuft, ber der bestimmte Inhalte z.B. Adresse "verpflichtend" sind, und andere optional.
Vermutlcih kommt irgendwann mal eine Art Funktion-Mapping für RailCom, bei dem man sich aussuchen kann, was man aus dem Daten-Angebot des Decoder-Herstellers denn übertragen haben möchte.

Der sich so langsam herauskristallisierende Konsens scheint aus : Adresse, abgefragten CV-Inhalte, Geschwindigkeit und Stromverbrauch zu bestehen.

Zitat

---

- Das Datenprotokoll?

---

Ja, das für Gleis, wie das für den RailComBus.

Zum Begriff genormt: Bisher hat die NMRA alles was zu DCC gehört genormt. Da wohl RailCom betreffend eine unterschiedlcihe Interessenslage in der NMRA zwischen amerikanischen Anbietern (Digitrax/Loconet) und europäischen Herstellern besteht, sieht es so aus, als könnte sich bzgl. des Normungsgremiums für RailCom hier was ändern. Bzgl. RailCom normt Lenz deswegen selber, und vergibt Lizenzen.
Akzeptieren tun das bisher : ESU, Lenz, Kühn , Tams, Viessmann, Zimo.

Viele Grüße
Frank

p.S. Ich finde es übrigens sehr Schade, wenn die NMRA nicht mehr DCC Tutto Kompletti normt. Sie hat das früher aus meiner Sicht sehr gut gemacht (wenigstens die Dokumenation, die Prüfung wahr ja freiwillig, und der haben sich kaum Hersteller gestellt). Zur Zeit munkelt man, das auch ehemalige NMRA - Normer zu eurpäischen normenden Verbänden wechseln, so das RailCom und DCC (auch) in Europa "genormt" werden.

Für das linzensierende Vorgehen der Fa Lenz habe ich allerdings vollstes Verständnis. Zuviele Produkte wurden in der Vergangenheit unter der DCC Logo verkauft, die nicht die freiwillige NMRA Prüfung überstanden hätten, und auch in der betrieblichen Praxis unserer grossen Anlage entsprechend Probleme machten. Das betraf meit Multi-Prot-Produkte oder Schaltungen die zum Vetrieb unter mehreren Protokollen gleichzeit entworfen worden sind. Hier stammt meine prinzipielle Skepsis gegen Multi-Prot her.

Guten Morgen,

Zitat

---

Bisher verstehe ich nämlich noch nicht so recht, was nun eigentlich genormt ist.

---

Vielleicht kann man RailCom ein wenig mit TCP/IP vergleichen. Beim Netzwerkprotokoll ist festgelegt, wie die Datenpakete aussehen und wie die Hard/Software, mindestens bis einschliesslich Transportlayer (Layer 4 im OSI-Modell), spaetestens bis zum Applikationslayer (im OSI-Modell Layer 7) zu funktionieren hat.

Was danach oder davor kommt, und welche Daten letzendlich in den Paketen verschickt werden legt die jeweilige Applikation fest. Zumeinst sind es Standardpakete wie html, FTP usw.
Als "Gegenbeispiel" nehmen wir mal die aktuellen New-Age-Zentralen wie CS und Ecos. Diese besitzen eine Netzwerkkarte und grundsaetzlich TCP/IP. Was die Ecos an Datenpaketen auswertet und verarbeitet bzw. zuruecksendet, was die zum Steuern einer Anlage benoetigt, hat mit TCP/IP nichts mehr zu tun.

Bei RailCom sieht das aehnlich aus. Genormt sind die Datenpakete und die Beschaffenheit des Transportweges vom Decoder zum Detektor. Was der Decoder neben der Mininalanforderung (Adresse, angeforderte CV) sendet und was der Detektor damit macht ist Sache des Herstellers.

Nun, und hier sind wir wieder beim Fachhaendler und dessen Chance, sich als Fachberater zu etablieren:

Ich gehe in einen Laden und sage sowas wie "Hey, ich habe da was von RailCom gelesen, was ist das und was kann ich damit machen?"
Dann sollte mir der Fachhaendler die Moeglichkeiten und Spezialitaeten erklaeren koennen und je nachdem was ich fuer mich gebrauchen und nutzen kann, kann ich mir ueberlegen, ob ich z.B. auf das umfangreiche Zimo-Konzept wechsle oder ob mir zur Ueberwachung meines 5-Gleisigen Schattenbahnhofs auch die preiswerten Tams-Komponenten reichen.
Dabei muss einem bewusst sein, dass wenn ich z.B. das breite Funktionsspektrum von Zimo nutzen will, ich mich auch ausschliesslich auf Zimo beschraenken muss. Ein Tams-Decoder bietet mir hier zwar die Grundeigenschaften, Features wie Ist-Geschwindigkeit oder aktuelle Stromaufnahme wird damit wohl nicht funktionieren.

Fazit: Mindeststandard koennen alle, die das RailCom-Logo fuehren und von daher von Lenz die Lizenz dazu haben, Spezialitaeten sind vom Hersteller abhaengig.

@Thomas & Frank,

danke für die ausführlichen Erklärungen.

Die Quintessenz, die ich daraus ziehe, ist, dass man sich bei der Wahl für die Produkte eines Herstellers der "Anlageninfrastruktur" auch irgendwie an diesen bindet.

Bei den Lokdecodern mag das anders sein, aber mit der vielfach gepriesenen Wahlfreiheit ist es bei DCC für die Anlageninfrastruktur hinsichtlich RailCom dann doch nicht so weit her...

Hinzu kommt, dass man sich bei einem Hersteller dann doch eher darauf verlassen kann, dass alles aus dessen Haus miteinander "spielt".

Hallo Udo,

Zitat

---

dass man sich bei der Wahl für die Produkte eines Herstellers der "Anlageninfrastruktur" auch irgendwie an diesen bindet.

---

Je nach Anforderung ja. Minimalanforderungen werden durch alle gedeckt, die die Lizenz haben, wer auf herstellerspezifische Besonderheiten wert legt, muss sich natuerlich gewissermassen binden.
Das ist aber keine Eigenart von RailCom sondern begegnet uns ueberall im taeglichen Leben und natuerlich bei der Modelleisenbahn.

Zitat

---

mit der vielfach gepriesenen Wahlfreiheit ist es bei DCC für die Anlageninfrastruktur hinsichtlich RailCom dann doch nicht so weit her...

---

Warum? Ich habe doch die Wahl, ob, wie und in welchem Umfang ich den Uebertragungsweg RailCom nutzen will. Je mehr ich mich auf grundlegendes beschraenken kann, desto groesser ist die Wahlmoeglichkeit. So kann ich fuer meinen Zweck jeden Decoder einsetzen, der grundsaetzlich RailCom kann.

Zitat

---

Hinzu kommt, dass man sich bei einem Hersteller dann doch eher darauf verlassen kann, dass alles aus dessen Haus miteinander "spielt".

---

Auch diese Annahme begegnet uns ueberall auf der Welt, oft trifft sie auch zu und liegt auch gewissermassen in der Natur der Sache. Ich kann mir nicht vorstellen, dass wenn z.B. Lenz einen Decoder baut, er dessen Tauglichkeit auch an einer Tams-, Zimo-, Commander-, sonstwas-Zentrale und dessen Komponenten testet.

hi thomas,

ich glaube die aussage des vorschreibers war in die richtung das es mit der kompatibilität auch bei DCC so seine hürden gibt... das dies woanders auch der fall ist steht außer zweifeln...es kocht jeder nur mit wasser..

Max,

Zitat

---

das es mit der kompatibilität auch bei DCC so seine hürden gibt

---

Bei den Komponenten, die hierzulande in der Regel angeboten werden, sind mir keine nennenswerten Huerden bekannt.
Was in Amerika und deren Produkten ist interessiert mich hier nicht.

Zitat

---

Auch diese Annahme begegnet uns ueberall auf der Welt, oft trifft sie auch zu und liegt auch gewissermassen in der Natur der Sache. Ich kann mir nicht vorstellen, dass wenn z.B. Lenz einen Decoder baut, er dessen Tauglichkeit auch an einer Tams-, Zimo-, Commander-, sonstwas-Zentrale und dessen Komponenten testet.

---

Die Standardisierung ernst genommen, sollte das auch gar nicht nötig sein, denn die Handwerker handeln die Länge z.B. eines Meters auch nicht auf jeder Baustelle separat aus, sondern haben alle die gleiche Referenz, den Urmeter von Sèvre.

Sind so wenige Hersteller an einer Sache wie RailCom beteiligt - dazu noch aus dem gleichen Sprachraum und in vergleichsweise naher geographischer Umgebung - steigt hoffentlich die Chance auf problemfreie Interoperabilität der von den jeweiligen Herstellern gelieferten Komponenten.
Bislang scheint`s jedenfalls nicht schlecht auszusehen.
Wenn der Herr Friberg nun noch moderierend mitmischen sollte, braucht wohl niemandem bange zu sein.

Gruss,
Manfred

hi,

leider kann man DCC nicht so ganz von der NMRA abkoppeln.. und mir geht es hier nicht um die USA... beim bus merkt man schon unterschiede (der eine loconet, der andere CAN der dritte weiss noch nicht recht...

klar kann man sich nur auf das mindeste beschränken aber auch das ist schon eine einschränkung wenn man gerade die interoperabilität hervorhebt. ich hoffe wie manfred, das es die teilnehmer gelernt haben diese fehler nicht zu wiederholen.. aber anderseits: wann hat der mensch schon mal aus seinen fehlern gelernt

die hoffung stirbt zu letzt...

Hallo zusammen,

Zitat

---

Hinzu kommt, dass man sich bei einem Hersteller dann doch eher darauf verlassen kann, dass alles aus dessen Haus miteinander "spielt".

---

Das mag im Einzelfall stimmen, manche Hersteller sehen das sogar als Vorteil im Sinne von technischer Markenbindung an , aber genau darum geht es bei Normung und DCC wie RailCom nicht . Ziel der ganzen Bemühungen ist es , das die Produkte verschiedener Hersteller garantiert zusammenarbeiten

Zitat

---

leider kann man DCC nicht so ganz von der NMRA abkoppeln.. und mir geht es hier nicht um die USA... beim bus merkt man schon unterschiede (der eine loconet, der andere CAN der dritte weiss noch nicht recht...

---

Die Austauschbarkeit der Komponenten findet auf Grund der Vielfalt bei Systembussen (LocoNet, XpressNet, CanBus, ECosLink, EasyNet, ...), RM-Bussen (S88, RSBus, SX,...) schnell ein Ende.

Oft wünscht man sich als DCC-Bahner vergeblich, das es nur einen Systembus gäbe, so wie es nur ein Internet gibt. Der öffentlich zu normende RailComBus soll wohl ein Angebot sein, wenigstens einen genormten RailCom-fähigen Rückmeldebus anzubieten. Dabei bleibt der RailComBus keine Vorraussetzung für RailCom , da RailCom Daten natürlich auch über vorhandene Systembusse übertragbar sein könn(t)en.

Viele Grüße
Frank

Hallo und Guten Morgen,

bitte versteht RailCom als Fundament fuer die Uebertragung von Daten.

Zitat

---

denn die Handwerker handeln die Länge z.B. eines Meters auch nicht auf jeder Baustelle separat aus, sondern haben alle die gleiche Referenz, den Urmeter von Sèvre.

---

RailCom ist in diesem Vergleich der Urmeter, ob der Handwerker auf dessen Basis eine Betonwand, eine Ziegelwand oder eine aus Holz baut ist die andere Sache und kommt auf den Kunden an. Wenn ich ein Holzhaus will gehe ich nicht zum Maurer.

RailCom ist die Basis und die Hersteller koennen darauf aufbauen. Je nachdem was ich benoetige waehle ich aus, wie in allen anderen Bereichen auch.

Wichtig und essentiell ist, dass die Geraete auf der Basisseite sauber zusammenarbeiten und das tun sie zumindest in meiner Umgebung.

hi thomas,

vorneweg.. ich freue mich das es mit railcom weitergeht... und bin positivist.. ich mag aber auch keine wissen was ich kaufe...

nach genauem lesen ist railcom ein proprietäres system der firma lenz sowie es proprietäre systeme von märklin oder digitraxx oder mth gibt... es ist vergleichbar mit windows: microsoft definiert was windows ist, entwickelt es weiter und schreibt interfaces..

lenz wacht über die einhaltung "seiner" railcom norm in dem sie lizenzen vergibt... vermutlich erstmal kostenfrei.. im gegenzug prüft lenz ob die produkte unter den lizenzen die norm einhalten, denn würden sie das nicht machen ist es wie derzeit bei DCC ein ziemliches chaos... (recommended practices werden nciht eingehalten, specs stimmen nicht usw. aber jeder sagt er sei DCC kompatibel)

ob lenz auch in zukunft dieses gratis machen wird weiss keiner.. auch nicht ob lenz jeden anbieter eine lizenz geben wird.. auch nicht ob irgendwann DCC durch die NMRA um einen RAILCOM norm erweitert wird die abweichend von der LENZ norm ist.. die hoffnungen sind das dies alles nicht passiert.

somit ist der zeit der unterschied zwischen RAILCOM und MFX nur:

Railcom von der Firma Lenz vergibt lizenzen und lädt andere zum mitmachen unter ihren bedingungen ein und märklin a la ESU mit MFX macht das nicht!

daher wird railcom sich in der deutschen DCC welt erstmal sicherlich schnell ausbreiten sofern die kosten überschaubar bleiben... was mit teilnehmenden firmen wie TAMS sicherlich der fall sein wird.

ich danke für die ausführungen.

PS apropos der grundlegende unterschied zwischen Railcom und TCP/IP aus der sicht dieser diskussion ist, das TCP/IP niemanden gehört aber voll dokumentiert ist.

Zitat

---

ob lenz auch in zukunft dieses gratis machen wird weiss keiner.. auch nicht ob lenz jeden anbieter eine lizenz geben wird.. auch nicht ob irgendwann DCC durch die NMRA um einen RAILCOM norm erweitert wird die abweichend von der LENZ norm ist.. die hoffnungen sind das dies alles nicht passiert.

---

Möglicherweise ist Lenz nicht der Alleininhaber der Railcom betreffenden Patente. IIRC, ist auch Stan Ames, dessen Frau, Debbie Ames, die Lenz Agency of North America führt, beteiligt.

Je mehr Firmen an der Entwicklung von RailCom teilhaben, desto stärker
wird die "normative Kraft des Faktischen" wirken - hoffentlich.

Und wenn die NMRA endlich den Pranger - um den geht es letztlich - aufstellen würde und klar sagte, dass soundsoviele Produkte soundsovieler Hersteller Murks sind, dann würde wohl die NMRA auch die Lizenz erhalten.

Gruss,
Manfred

Aufjedenfall bin ich auch kurz davor auf den Railcom-Zug aufzuspringen.

Einiege railcom-fahige Decoder hab ich ja schon.

Weiss man, ob es für ESU Lopi´s 3 Updates für Railcom geben wird?

Hi Torsten,

Zitat

---

Weiss man, ob es für ESU Lopi´s 3 Updates für Railcom geben wird?

---

Gibt es doch. Zumindest habe ich einen Lopi3, der RailCom kann.