THEMA: Lenz und RailCom

Hallo,

weil die auch lieber Eisenbahn spielen (mit Spur 0). Ich kann es ihnen nicht einmal verübeln

Grüße, Peter W.

Lenz hat such mt den anderen Mitgliedern der Railcom Gruppe zerstritten und daraufhin mit ESU Railcomplus herausgebracht. Von den grossen Herstellern hat nun niemand mehr Lust auf Railcom, zumal es noch diverse Technische Probleme gibt.Lenz hat ja nicht einmal eine Raul vom tauglichen Rückmeldebus.
Das beste Produkt für Railcom kommt von Fichtelbahn. Nicht von Lenz, Esu, Tams oder Zimo.
Das sagt schon vieles.

Viele Grüsse
Matthias

Hallo Boris,

von Lenz ist in nächster Zeit wohl nichts zu erwarten.

@Matthias
Zwischen Lenz und Zimo hatte es gekracht, bei Tams und Kühn ist mir nichts bekannt. Railcomplus ist eine reine ESU-Entwicklung, die dann zusammen mit Lenz veröffentlicht wurde.

Grüße
Stephan

Danke für Eure Antworten!

Ich habe eine LZV100. Ich bin schon sehr zufrieden, läuft alles stabil.

Wenn ich jetzt aber RailCom gerne nutzen möchte, müsste das die LZV100 erst einmal können. Sie soll es nach einem Update auch können, aber selbst das Update steht in den Sternen.

Habe ich aus Eurer Sicht irgendwie eine Chance, RailCom heute zu nutzen, auch wenn ich bei meiner LZV100 bleibe?

VG,
Boris.

Hallo Boris,

die LZV100 kann den Railcom-Cutout erzeugen.Damit können Decoder ihre Daten senden. Sonst würde auch nicht die RailCom Adressanzeige LRC120 funktionieren.

Wenn Du die Railcom-Daten an die Steuerungs-Software weiterleiten möchtest, dann benötigst Du Rückmelder und einen Bus, der da kann.

Mir sind folgende bekannt:
Tams RC-Link
Blücher GBM + Loconet-Interface
OpenDCC GBMBoost + GBM16T - Der kann auch als Booster und Bus mit einer LZV100 als Zentrale arbeiten. Ist aber nur für spezielle Fälle sinnvoll, da die Zentrale im GBMBoost-Master besser ist.

Welche Software nutzt Du?

Grüße
Stephan

Hallo Stephan,

danke für die Antwort.
Ich nutze den Traincontroller.

VG,
Boris.

Guten Morgen,

ich würde das Thema gerne wieder einmal aufgreifen.
Weiß jemand von Euch etwas Neues? Wird Lenz jemals mit den "neuen" Produkten fertig.

Zudem die weitere Frage, da ich nicht mehr auf dem Laufenden bin:
Was ist aktuell die gängigste Lösung, um BiDi zu verwirklichen?

Viele Grüße,
schönes Wochenende,
Boris.

Hallo Boris,
nach wie vor: OpenDCC GBMBoost (vertrieben über Fichtelbahn). Von Lenz erwarte ich persönlich schon lange nichts mehr, da herrscht wohl ewiger Stillstand.

Viele Grüße
Carsten

Folks!
Meiner Einschätzung nach wird von Lenz in absehbarer Zeit nichts kommen. Selbst das 0-Spur Steuergerät fehlt seit Jahren. Insofern schenken Lenz und ZIMO sich da nichts gegeneinander in Sachen Kundenvergrämung, obwohl sie sonst wenig gemeinsam haben.

RailCom Plus war eigentlich von Anbeginn an mit angedacht. Durch das Vorpreschen von ZIMO dem Lenz technisch nicht folgen konnte hat man dann eine rechtliche Hürde aufgebaut, um ZIMO zu stoppen. So wie auch in anderen Industriezweigen wendet sich so etwas sehr verlässlich gegen den Hürden Errichter. ZIMO hat, obwohl als erster mit RC Decodern und einer RC Zentrale (MX31ZL) am Markt, auch keinerlei Vorteile ziehen können. Die kündigen auch seit 10 Jahren das MX10 an welches in einer sehr rudimentären fehlerhaften Version seit kurzem verkauft wird. Das MX10 kann RC um darauf aufsetzend mehr Qualität in die MoBa Welt zu bringen.

Ein Produkt wurde in dem Thread noch nicht genannt, das soll nachgetragen werden. Zumal es endlich zur verbreiteten Nutzung beitragen kann. Die Z21 von Roco kann RailCom. Die Zentrale ist sehr weit verbreitet, es gibt viele Programme die die unterstützen. Damit wäre einmal das Thema Global Detector abzuhaken. Für Anwender von X-Press Net Anlagen wie Lenz ist da auch ein Umstieg leicht möglich, ohne all zu viel von der existierenden HW entsorgen zu müssen.

Für diesen Herbst hat Roco einen neuen Besetztmelder angekündigt. Dieser soll RailCom Melder für jeden Ausgang drauf haben. Roco hat glücklicherweise beim Z21 Design kapiert daß man einen leistungsfähigen Bus braucht. Vor allem aus Kostengründen hat man den CAN Bus gewählt, alles anderen wäre viel teurer. Die Automobilindustrie hat die CAN Bus Komponenten extrem billig gemacht. Hier ist das große Problem der "alten" Zentralen. Das ist das Hauptproblem bei Lenz, der hat keinen brauchbaren Bus dafür. Die RailCom Daten haben ein großes Volumen das bringt man durch die alten Bussysteme die mit 9600 Baud oder 16000Baud arbeiten einfach nicht durch. Selbst wenn man redundante Daten bereits in den Besetztmeldern filtern würde. Die Z21 nutzt den CAN Bus. Das Bus Protokoll ist keine Neuerfindung sondern man hat sich da an ZIMO angelehnt. Das ist im wesentlichen deshalb passiert weil die andern CAN Bus Zentralenhersteller das jeweilige hauseigene Protokoll nicht veröffentlicht haben. Die Z21 ist übrigens kein ZIMO Design sondern stammt von hke - es wird oft vermutet die Z21 käme von ZIMO wegen dem "Z" im Namen, das ist aber nicht der Fall.

Mit dieser Infrastruktur kann Roco dann weiter machen. Das selbstständige Anmelden von Loks (bekannt von mfx von Märklin) ist eines dieser Killerfeatures für den Spielbereich. Bin neugierig von Lenz/ESU hier den bisherigen Fehler verlängern wird und Roco Steine in den Weg zu legen. Falls das weiter so ist wird Roco wohl was Neues machen müssen - bin überzeugt daß ZIMO da freudig mithelfen wird - nur das wäre wohl das schlechteste was passieren kann. Dann würde es 3 Lokanmeldesysteme geben (neben mfx und RailCom+) und das kann nicht Sinn der Sache sein. Durch das hohe Volumen an Z21 und Lokmodellen hätte Roco wohl gute Karten da einen neuen Standard zu etablieren.

Zurück zum UP: mit dem neuen Roco Besetztmelder kann man wenn man einen Booster hat der die RC cutouts machen kann durchaus etwas anfangen. Die Frage ist dann wie bekommt man die gelesenen Daten vom Besetztmelder weg. Bisher gibt's da den CAN Bus, ob es weitere Schnittstellen geben wird weiß man noch nicht. Technisch gesehen ist das das Entscheidende. Aus Kostengründen, von Besetztmeldern braucht man doch mehrere auf einer Anlage, erwarte ich eigentlich nur eine Schnittstelle und damit müsste man sich was überlegen wie man den CAN Bus mit seinen Infos an einen PC anschließt - so man kein Z21 (die schwarze) oder MX10 als Zentrale hat. Es gibt Peak die machen solche Schnittstellen nur der Preis ist dann auch in der Größenordnung einer Z21 womit das wohl kommerziell keinen Sinn macht. Zumal die PC SW dann die Peak Module kennen muss.

-AH-

Vielen Dank für Eure Antworten, vor allem an Arnold!!

Hallo Arnold,

RS485 ist meistens wohl günstiger als CAN. Mir wäre es lieber gewesen, wenn Roco BiDiB als Bus genommen hätte. Wie Du schreibst, ist das Protokoll angelehnt an Zimo, also wieder was "spezielles", mit dem sich ein Hersteller abschottet. Bin mal gespannt, ob der GBM mehr als die Lokidentifikation auf dem Bus geben kann.
Prinzipiell begrüße ich natürlich jede Railcom-fähige Komponente.

@Boris
Ansonsten bin ich auch der Meinung, dass von Lenz bzgl. Railcom nichts mehr kommt.
Außer Roco, wie von Arnold geschrieben, hat sich zu meinem letzten Beitrag nichts bzgl. Railcom geändert.
Zur Info, mittlerweile können D&H-, Tams- und Zimo-Decoder die Gleisverschmutzung erkennen und per Railcom melden.

Grüße
Stephan

Hallo ste111,

ich meine gelesen zu haben, das BiDiB auch ein CAN- Bus ist. Deshalb ist der Bus aber noch lange nicht kompatibel zu anderen CAN-Systemen. Der Bus ist die Hardware - hinzu kommt noch das Protokoll. Ist das scheiße, nutzt die beste Hardware nichts. Märklin und ESU Geräte verstehen sich - trotz CAN meines Wissens auch nicht.

Jens

Hallo Jens,

definitiv nein. Hier steht auch warum CAN nicht verwendet wurde:
http://bidib.org/bidibus/xtra_info.html

Grüße
Stephan

Hallo Jens,



Zumindest die Märklin MS1 versteht sich mit den ESU-Ecos Zentralen (die ist nämlich von ESU entwickelt worden).

Gruß
Thomas

@11
Die HW Kosten für einen CAN Bus sind durch nichts zu unterbieten V24/RS232, RS485 und andere Derivaten sind um vielfaches teurer abgesehen von niedrigeren Geschwindigkeiten und weniger Störsicherheit. Es gibt viele Prozessoren wo bereits CAN HW drin ist die über 1000V Spannungsfestigkeit garantieren. Da gibt's ARM 0/3 Dinger um 1-3 Euronen die alles drin haben! Da gibt's kein gebastle mit Filtern oder Widerständen und Supressordioden mehr...

Der ZIMO CAN Bus Variante 2 ist offengelegt, damit großer Unterschied zu Märklin und ESU

@12
BiDiB definiert vor allem ein Protokoll, könnte auch via CAN Bus betrieben werden. Es gibt aber eine eigene Busversion auf Basis 485. AFAIK sind die aktuellen CAN Bus Specs im MHz Bereich, da braucht man mit 485 gar nicht dran denken. Wobei aber die CAN Busse in der MoBa nur die älteren Standards nutzen und nicht über 500kHz kommen oder wie bei ZIMO Variante 1 grad' um die 100kHz fahren.

@14
ESU, ZIMO und Märklin haben unterschiedliche Protokolle. Die unteren Layers sind natürlich gleich. Man könnte auch einem Märklin Gerät die ESU Sprache beibringen so man das möchte.
ZIMO hat 2 miteinander inkompatible Protokolle. Früher aus der MX1 Welt und ein neueres das das MX10 und MX32 spricht. Wobei diese Geräte auch das alte Protokoll können. Diese Version 2 benutzt auch Roco. So kann man ein MX32 an eine Z21 anhängen und damit arbeiten.

Das hilft aber alles dem UP nicht wirklich weiter... Helfen kann da mit der Z21 weiter zu machen und die vorhandene XPress HW wie Handregler udglm zu benutzen.
-AH-

Servus,

der RS485 ist blliger umzusetzen als CAN - serielle Bausteine hast Du praktisch in jedem µC drin, CAN muß meistens mit externen Bausteinen umgesetzt werden.

Die Geschwindigkeit des CAN Busses ist vor allem von der nötigen Leitungslänge abhängig. Im Automobilsektor sind im allgemeinen CAN Bussysteme mit bis zu 500 kbit/s üblich. Das größte Manko dieses Busses ist, daß er nicht echtzeitfähig ist.

Meiner Meinung nach hätte man BiDiB bei der Verwendung von CAN anders designen müssen, da hier die Adressierung nach Funktion und nicht nach Baugruppe geschieht und zudem die Priorisierung der Nachrichten über die Message ID macht.

Grüßle

MiScha

Das ist nicht so! Ich kenne keine Prozessoren die nach außen mehr als 3V oder 5V serielle Anschlüsse bieten. Mit dem Logikpegel Ausgang des Prozessors kann man keinen Bus über eine MoBa Anlage bauen. Man muss Treiber und Pegelwandler vorsehen und das wird teuer. Bipolar mit ESD Ableitung und höheren Busspannungen 12, 24 oder 48V wegen Betriebssicherheit ist gefragt. Es gibt aber viele Prozessoren die das für den CAN Bus im Gehäuse drin haben. Daher ist das Zeugs unschlagbar attraktiv aus finanzieller Sicht. Solche Prozessoren sind häufig und billig.

Völlig richtig, nur das sind alle anderen Busse auch nicht zumal sie um Zehnerpotenzen langsamer sind.

Im Industrieanlagenbau, aus der Ecke kommt der CAN Bus ursprünglich, baut man ähnlich wie in der Netzwerktechnik Konzentratoren udglm um größere Längen oder mehr Durchsatz zu bekommen. Beides wird für die MoBa vorerst irrelevant sein.
Für die MoBa von Interesse ist die einfache Implementation. Im Grunde macht der CAN Chip alle ISO Layer bis rauf zur Applikationsschicht. Man muß das Zeugs nur einmal einstellen und dann kann man das als Programmierer einfach als erledigt abhaken.

Das hat aber alles nix mit RailCom zu tun, wonach der UP gefragt hat. Entscheidend für RC Nutzung ist ausreichende Bandbreite um die Meldungen übertragen zu können. Da gibt's in der MoBa Welt derzeit nur 2 Lösungen BiDiB und CAN, letzterer in 3 zueinander inkompatiblem Varianten. Wobei Gateways zwischen BiDiB und einer CAN Implementation durchaus denkbar sind.
-AH-

Servus,

Du brauchst in der Regel auch für Controller mit eingebautem CAN einen Treiberbaustein für den physikalischen Anschluß also die Verkabelung.


Der CAN Bus wurde Anfang der 80er von Bosch für die Vernetzung von Steuergeräten im Automobil entwickelt. Spezifiziert sind hier maximal 1Mbit/s für eine maximal Leitungslänge von 40m ...

Einfach ist die Implementierung nicht - da man hier das gesamte System planen muß, weil das entscheidende Auswirkung auf die Buslast und die Weiterleitung der priorisierten und vor allem auch nicht priorisierten Nachrichten hat.

Grüßle MiScha

Eben genau diese Dinge sind im Prozessorgehäuse bereits integriert, das ist das Geniale an diesen Prozessoren.
-AH-

Noch mal vielen herzlichen Dank für eine zahlreichen und umfassenden Antworten!!

Hallo
Was meint  Ihr über Layout Command Control (LCC) http://www.dccwiki.com/Layout_Command_Control. ( Text is Englisch)

Kan das RailCom Konkurrenz bieten?

Gruß,
Björn

Hallo Arnold

BiDiB ist mit max. 13V spezifiziert und die verwendeten Bustreiber benötigen keine weiteren Bauteile.

Hier bin ich mir nicht sicher, auf was Du Dich beziehst. BiDiB verwendet wegen der Leitungslänge 500kBaud. RS485 könnte noch mehr.
Der Vorteil von RS485 ist noch, dass auch bei hoher Busbelastung der volle Durchsatz genutzt werden kann, anders wie beim kollisionsbehafteten CAN.

@Björn
LCC scheint ein Bus zu sein. Das hat mit Railcom dirkt nichts zu tun. Per Railcom sendet der Decoder Daten. Diese Daten könnten über einen Bus übertragen werden. Prinzipiell könntet das jeder Bus, wenn die Befehle dafür definiert wären.

Grüße
Stephan

Wo hast Du denn diesen Unsinn her? Gerade die Kollisionsfreiheit ist ja der Witz bei CAN. Andere kollisionsbehaftete Protokolle wie Ethernet (und um mal ein Modellbahn-Beispiel zu nennen LocoNet - hier spricht man in der Spec ja explizit davon, sich in dieser Beziehung an Ethernet anzulehnen) gehen ab ca. 50% Buslast in die Knie. CAN kannst Du mit 100% Buslast nutzen, durch die Priorisierung der Messages können dann natürlich niederpriore Messages "feststecken". Genau hier muss man sich beim Design der darüberliegenden Protokolle halt ein paar Gedanken machen.

Gerade die ganzen altbackenen UART-basierten Lösungen (RS-422, RS-485, RS-232) sind auf Hardwareebene erstmal in keiner Weise kollisionsfrei.

Gruß,
Torsten

Es gibt auch noch RailCom-Empfänger fürs LocoNet.
Was ist der Tams RC-Link für ein Bus?

Wieviel Bandbreite muss es denn sein?

Gruß,
Harald.

Hello!

DCC "kann" etwa 80 Befehle pro Sekunde senden. Nach jedem Packet sendet jeder RC Decdoer seine Adresse aus und kann in einem 2. Zeitbereich eine Frage der Zentrale beantworten. Dieser Datenstrom passt nicht durchs LocoNet zumal das eigentlich für anderen Aufgaben wie Handregler odglm konzipiert ist. Klar kann man im Besetztmelder redundante Daten filtern, aber sehr große Anlagen verkraftet der Bus nicht im RC Daten zu melden.

Tams verwendet den BiDiB

Bandbreiten Abschätzungen sind schwer weil es unterschiedlichste Anwendungen gibt. Filtert ein Besetztmelder redundante Infos oder schickt der alles weiter? Ganz grob ein worst case scenario: 80 DCC Befehle pro Sekunde 2 Bytes Spontanmeldung und 6 Bytes im 2. Kanal. somit 80 * (2 + 6) => 640 Bytes. Das sind 6400 Bit nur RailCom Daten. Da gibt's noch keine Fahrbefehle, Besetztmeldungen oder Weichen / Signale. Alles sehr theoretisch und in der Praxis sicher weniger durch sinnvolles Filtern. Die klassischen Busse haben 10 bis 16kBaud Geschwindigkeit. Das geht sich theoretisch aus wenn man die Busse nicht auch noch für anderes brauchen würde.
-AH-

Servus,

mal ein Frage dazu:

In einer größeren Anlage mit mehreren Boostern - wird da dann das DCC Signal für die entsprechende Lok nur auf dem Booster Abschnitt gesendet, auf dem sich die Lok befindet?

Grüßle

MiScha

Hallo Mischa,
nein, normalerweise überall. Woher soll die Zentrale / der Booster auch wissen wo welche Lok steht? Außerdem muss das Signal überall gleich sein, sonst gibts an den Trennstellen Probleme, wenn da grad ein Zug drüberfährt.

Viele Grüße
Carsten

Hi Mischa

Booster sind eigentlich reine Leistungserhöher. Beispiel: Zentrale hat 3 Ampere, jede Lok im Schnitt 300mA (Hallo ERNST - das ist ein  B e i s p i e l !  Ich weiß, dass nicht jede N-Lok 300...), also kannst du 10 Loks fahren lassen. Willst Du mehr (Loks), brauchst Du Booster.

Zentrale versorgt nur Innenkreis mit 3 A, Booster nur Aussenkreis mit 3 A - also kannst Du jetzt 2 x 10 = 20 Loks fahren lassen. Desahlb braucht auch jeder Booster einen eigenen Trafo (= 230 V-Anschluss).

Gleisverbindung zwischen Innen- und Aussenkreis muss dann zwingend beidseitig getrennt werden.

Alle Loks sind aber nur in der Zentrale "gespeichert". Zentrale spricht per "Digital-Signal" mit Lok übers Gleis. Da der Aussenkreis aber beidseitig getrennt ist, kann dieses Signal nicht weiter und "bleibt im Innenkreis".

Jetzt kommt Booster: Zentrale schickt nur "Digital-Signal" via Kabel zum Booster, der leitet dieses Signal weiter an die Loks im Aussenkreis. Strom fürs Aussen-Gleis kommt ja vom zweiten Trafo.

Vorteil: Falls Kurzschluss, steht nicht die ganze Anlage, sondern nur der Bereich, in dem der Kurze auftritt. Im Beispiel also entweder Innen oder Aussen. Besonders sinnvoll im Ausstellungsbetrieb

verstärkende Grüße
HaWeO

Ps,. Entschuldigt bitte die kurze Abschweifung vom Hauptthema Railcom - nur: auch dieses Rückmelde-Signal müsste bei Abschnittstrennungen über die Booster laufen.

OK, Kollisionen werden wohl vermieden, dafür gibt es das von Dir schon erwähnte Problem des Aussperrens von Teilnehmern.
https://de.wikipedia.org/wiki/Carrier_Sense_Multiple_Access/Collision_Resolution


Bei einem Master-Slave-System wie bei BiDiB erschließt sich mir das nicht. Aber vielleicht können wir das privat weiter besprechen.
Wie immer hat jedes System seine Vor- und Nachteile.

@Harald
Blücher hat was für Loconet. Allerdings gibt es bei Loconet nur die Kommandos für die Lokadresse und wohl für das CV-Auslesen. Sonst reicht, wie von Arnold schon beschrieben, die Bandbreite nicht.

Bgzl. RC-Link kennst Du Dich eigentlich aus
http://www.1zu160.net/scripte/forum/forum_show.php?id=573091#aw29

Grüße
Stephan

Servus,



Also grundsätzlich: ja, ok - danke an Euch für die Antwort

Bei BiDiB Systemen mit Railcom könnte ich mir durchaus vorstellen, daß das handlebar ist, da ja der GBM Node über die angeschlossenen  GBM 16Ts via Railcom eigentlich wissen kann, welche Lok gerade in seinem Bereich fährt - und das weiß ja die Zentrale auch, bzw. die Steuerungssoftware ...

Hallo Mischa,
mit Railcom würde das gehen, ja. Die Booster wären dann aber keine reinen Booster (Verstärker) mehr, sondern selbst Zentrale, weil sie ein komplett anderes Gleissignal erzeugen müssen. Bei GBMBoost wär das nichtmal so sehr schwierig, weil Node und Master die gleiche Hardware haben. Es macht aber wenig Sinn das so zu handhaben, da man sich wie gesagt Probleme an den Trennstellen einhandelt. Durch die verschiedenen Signale können dort dann Kurzschlüsse entstehen. Deshalb wird z.B. im Miniatur-Wunderland in HH (wo mehrere Zentralen eingesetzt werden) mit Übergabeabschnitten gearbeitet. Bei der Fahrt eines Zuges von Bereich A zu B wird die Übergabe von Zentrale A versorgt. Wenn der Zug komplett eingefahren ist, wird der Abschnitt dann umgeschaltet zu Zentrale B und die Fahrt kann weitergehen. Da zuhause kaum einer eine derart große Anlage bauen wird, dass die Übertragungskapazität am Gleis knapp wird und eine zweite Zentrale her muss (speziell mit Railcom, wo die Wiederholungen entfallen oder zumindest stark reduziert werden können), braucht man sich diesen Aufwand nicht machen. Ein Gleissignal auf der gesamten Anlage - fertig.

Viele Grüße
Carsten