THEMA: CAN Bus an der Moba

Hallo,

wo hat Roco einen CAN Bus? Loconet ist leider schrecklich langsam.

Zimo hat einen und Märklin - mit inkompatiblem Protokoll.

CAN ist leider nur ein elektrischer Standard, aber was genau drauf läuft ist genau so inkompatibel wie Mercedes zu Opel.

Grüße, Peter W

Hallo Peter, vielleicht lieg ich da falsch aber zumindest der Roco Z21 Detector und booster werden mit CAN Anschluss beworben und ich geh davon aus, dass die Datenverbindung zu einer Z21 dann über diesen Bus laufen würde ?
LG
Heinz

PS .. Und ich möchte ja nicht zu viel über die automobilen CANs philosophieren, aber nachdem Opel und Mercedes zT Bosch Steuergeräte verwenden, kriegt man mit einem CAN Logger auch aus beiden zumindest ein paar Signale raus

Hallo Peter,

Siehe hier:

https://www.z21.eu/de/z21-system/system-1

Gruß Jens

Ich habe die schwarze Z21 seit 2 Jahren in Betrieb mit 4 Roco Detectoren über CAN Bus und sehr schnelle Rückmeldung zB. Railcom ohne Probleme.

Hallo nied2001
Das ist sicher eine technisch sehr gute, aber auch sehr teure Lösung. Ich hätte mir von einer Verbreitung des CAN Bus in der Moba ( und in vielen Bereichen ist er lange techn Standard) auch eine Senkung der Bausteinkosten versprochen. Und ich geb Peter vollkommen recht - die Datengeschwindigkeit von Loconet ( verbunden mit einer allfälligen Beschränkung der Teilnehmerzahl ) ist nicht mehr zeitgemäß
LG
Heinz

Hi!
Wenn man sich mit primitiv Technik aus den 1960'er-1970'er Jahren begnügt kann man S88/LocoNet udglm. nutzen. Aufpassen nicht nur simpel veraltet sondern auch für damalige verhältnisse Schnecken langsam! Der CAN ist halt viel schneller und vor allen viiiiiel billiger, weil die CAN Bus HW durch die Verbreitung in Autos in allen Embedded Plattformen fix im Chip zur Verfügung steht. Vor allem die Pegel Anpassung und er ist ein Differenzial-Signal. Meist wird mit 12-24V Signal Pegel gefahren das macht das Zeugs extrem störsicher.

Zur Z21 gibt's diverse Melder die sind recht gut und sehr preiswert wenn man die Funktionalität nutzt. Will man nur Freimelder, dann ist man da falsch.
-AH-

Hallo,


Welche genau gibt es noch neben dem Roco eigenen?

Grüße, Peter W

Hallo zusammen,

aus meiner Sicht würde ich Ethernet und TCP/IP dem CAN-Bus vorziehen. Differentiell ist das Signal auch, alles durchstandardisiert bis zum Stecker. Geschwindigkeiten bis in den Gigabit-Bereich, wer's braucht. Ethernet ist allgegenwärtig, das senkt die Preise. Auch gibt es mittlerweile etliche Microcontroller, die schon die wesentlichen Interface-Komponenten auf dem Chip haben. Aber noch ist niemand so richtig auf den Zug aufgesprungen. Einzig für die Steuerung über PC/Mobiltelefon/Tablet wird es zur Zeit genutzt.

Klaus

Hallo,

mal eine "doofe Frage" (falls es so etwas gibt). Woran merke ich im praktischen Betrieb, dass Loco net  langsam ist?


Viele Grüße
Christian

Hallo Christian
Ich bin absolut kein Bus Experte, habe an meiner DR5000 13 loconet Teilnehmer hängen (und da sagt man, das sei etwa die max mögliche Zahl,  warum auch immer) und stelle halt fest, dass beim Vielzugbetrieb( also ca 8 gleichzeitig) und bei meinen rel kurzen Sensorabschnitten, viel Botschaften laufen und da mal eine Belegtmeldung verloren geht - oder schlimmer noch , die Bus Verbindung zum Steuer Laptop verloren geht. Ob das mit der hohen Buslast und der langsamen Geschwindigkeit zu tun hat - keine Ahnung. Bei zB 4 Zügen gleichzeitig ist mir das noch nie passiert
Und ich würd mich auch gerne an Peter Ws Frage an Arnold anhängen- Welche anderen CAN Komponenten ausser den erwähnten gibt es denn ? Und was würde neben Belegt info und Railcom noch transportiert werden?

Beste Grüße
Heinz

Hallo Heinz,
Ich würde bei Dir nicht auf zu viel Buslast tippen. Digikeijs hat leider ab ca. 2020 extrem schlechte (billige) Bauteile mit größeren Toleranzen verwendet. Das führt dazu das, dass Loconet-Signal verschlechtert wird und so bleiben Meldungen auf der Strecke.

Nur mal so zum Alter der Netzwerke.
Loconet 1996
Can Bus 1986

@Christian
Du wirst keine Antwort bekommen, wann das Loconet überlastet wird. Und was dazu führt, dass es überlastet wird.
Diese ganzen Zahlen mit 16k/s Loconet oder bis zu 1 Mbit/s bei Can Bus sind eher theoretisch und bei der Modellbahn eher zu vernachlässigen. Die Modellbahn ist eher keine Echtzeitanwendung, die im uS Bereich Daten übertragen muss.
Meine persönliche Erfahrung ist, dass auch Netzwerke bestehend aus 20 Teilnehmern auch mit Railcom ohne Probleme funktioniert. Digitrax empfiehlt bei mehr, als 20 Teilnehmern einen Repeater einzusetzen.

Das richtig große Problem ist bei Can Bus, das zwar einige Hersteller damit arbeiten, aber es gibt schlicht und einfache keine Norm, die bei allen gültig ist. Jeder kocht hier fleißig seine eigene Suppe. Das geht sogar, so weit, dass entweder eigene Stecker verwendet werden oder wenn es RJ45 Stecker sind, ist die Belegung bei jedem Hersteller anders.

Loconet ist in den Augen von machen Leuten veraltet, aber es ist genormt, die Belegung der Stecker ist gleich und für kleines Geld lassen sich Kabel selber machen da die RJ12 Stecker einfach zu haben sind.

Gruß Stefan

Danke Stefan

wirklich interessante Argumentation und Fakten !!!

beste Grüße

heinz

Hallo,

leider nicht nur Fakten, sondern auch Mist. Wenn da z.B. behauptet wurde, dass Daten "verlorengingen": Wie wurde das festgestellt? Die genaue Ursache, warum etwas nicht übermittelt wird, kann durchaus unterschiedlich sein. So kann z.B. ein Rückmelder grenzwertig angeschlossen sein: Zu lange Strippe zum Meldeabschnitt, Störungen etc. Dann geht erst gar kein Datenpaket auf die Reise. Bevor man so etwas behauptet, muss man erst einmal Ursachenforschung betreiben.

Ganz hanebüchen die Behauptung, dass Loconet zu einer gestörten Übertragung zwischen Zentrale und PC führte. Nein, PCs haben keine Loconetschnittstelle. Sie kommunizieren mit der Zentrale fast immer über das Netzwerk oder über USB. Ein Problem auf dieser Ebene hat mit Loconet nicht im entferntesten etwas zu tun.

Die Diskussion über die Geschwindigkeit ist Theorie. Loconet ist in den meisten Fällen __schnell__genug__. Ja, es gibt auch andere Systeme. Bei CAN hat man die Schwierigkeit, dass nichts genormt ist und BiDiB ist eher eine Nischenlösung. Wenn man so etwas schreibt, gibt es von den Jüngern meist wütende Proteste, aber es ist so. Bei solchen Diskussionen stellt man häufig fest, dass Diskussionsteilnehmer eine Art emotionale Beziehung zu einem Hersteller, Produkt, etc. hergestellt haben.

Ich behaupte nicht, dass Loconet das Nonplusultra ist. Es ist jedoch in den meisten Fällen völlig ausreichend.

Grüße
Zwengelmann

hallo Zwengelmann

nun das sind ein paar starke Behauptungen , aber seis drum - wir kennen uns im Forum lange genug. Also ich verwende auf zwei Anlagen unterschiedliche Hersteller, beide mit Loconet BUS , habe zu keinem irgendeinen näheren Bezug und möchte einfach nur analytisch verstehen. Die erste Anlage ist eine kleinere mit Z21 und Uhlenbrock, Digikeijs Rückmeldern, die zweite größere mit DR 5000 und ebenfalls Uhlenbrock und Digikeijs Rückmeldern, daneben ESU, Littfinski Schaltdecoder usw. Die erste Anlage läuft einwandfrei - bei der zweiten größeren habe ich die beschriebenen Probleme - es ist nicht EIN Melder ,der ab und zu spinnt,  es ist auch nicht EINE zu lange Leitung , es sind ganz verschiedene  Melder , die mal die Botschaft verlieren und immer nur bei Vielzugbetrieb ( wie ich oben geschrieben habe), nie bei wenigen Zügen.
Du wirst es nicht glauben, aber ich habe tatsächlich realisiert, dass es  keine Loconet Verbindung zum laptop gibt !!!
Als nicht Bus Fachmann ( aber mit Beispielen aus der Automobilindustrie) kann ich mir aber vorstellen, dass eine Verbindung ( sicherheitshalber)  unterbrochen wird, wenn der Bus durcheinanderkommt ( aber vielleicht irre ich , deshalb ja auch dieser Thread).
Die Erklärung von Stefan mit den minderwertigen Komponenten, ja das leuchtet ein - auch das Argument , dass die Moba Anwendung im Prinzip kein Echtzeit Problem hat - möglicherweise ist aber der Bus mit der Gleichzeitigkeit von Botschaften überfordert ???
Aber vielleicht hast Du ja auch noch eine Erklärung ?
mit bestem Dank und herzlichem Gruß

Heinz

Bei Problemen auf dem Loconet ist das wichtigste Tool zum Fehler suchen ein Computerinterface das eine kollisions LED hat. Weil beim Loconet ist es wichtig dass wenn zwei Teilnehmer versuchen gleichzeitig zu senden beide das entdecken und verschieden lang Pause machen um es dann nochmal zu versuchen. Wenn das nicht funktioniert ist die LED gefühlt  immer an. Auch kann jmri die loconetpakete aufzeichnen und man kann sehen ob ein Busteilnehmer den Bus zumüllt.

Da normal bei Belegtmeldungen im Durchschnitt mehr als Zehntelsekunden zwischen den Meldungen vergehen reicht die Bandbreite eigentlich. Man vergleiche mit thinwire Ethernet. Das ist die gleiche Technologie.

Grüße,
Harald.

@Heinz
Das Problem bei den betroffenen Rückmeldern ist, das man das nicht an einem bestimmten Bauteil fest machen kann.
Was meistens schlechte Werte hat, ist die zDiode D1. Liegt hier eine Spannung von weniger als 2,75V an, ist die Diode nicht die Beste. Werte um 2,6V sind die Grenze nach meinen Erfahrungen. Ich kann Dir aber nicht garantieren, ob das der einzige Fehler ist. Es kam schon vor, dass andere Bauteile einfach schlecht verlötet waren.
Man kann übrigens an der blauen LED der DR5000 sehen, ob das Loconet "abstürzt". Leuchtet die blaue LED ständig erfolgt keine oder zu viel Kommunikation. Aber dann würden überhaupt keine Befehle mehr ankommen. Man kann auch im Log der DR5000 sehen, ob es zu den erwähnten Kollisionen kommt. Im Log würde dann L.Col mehrmals hintereinanderstehen. Normalerweise sollte das aber kein Problem sein. Da ich aber nicht weiß, ob da Digikeijs noch in den letzten Firmwareversionen herumgeschraubt hat, ist das unter Vorbehalt mit der Firmware 1.5.5.

Gruß Stefan



Die von Flitt zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hi!
Deine Frage ist alles andere als "doof". Es gibt mangels Wissen oft Fehlberatungen, sehr häufig auch vorsätzlich, um die eigene geliebte Plattform am Leben zu erhalten. Bestes Beispiel aus einem anderen Bereich ist SX. Nun zur Frage warum ist LocoNet schon seit der Einführung und besonders heute zu langsam für die gestellte Aufgabe:

Es gibt 2 "Stellen" nämlich die Latenz, wie zeitlich genau kann ein Ereignis gemeldet werden und die Bandbreite, also die Menge der Daten die von den Außengeräten Richtung Zentrale und gegebenenfalls PC und oder Bediener gemeldet werden.

Bereits mit der Meldegeschwindigkeit bekommen viele auch schon moderat kleine Anlagen gewaltige Probleme. Wenn man per Automatik Züge steuern will sind Verzögerungen ärgerlich. Das betrifft sowohl Zentralen basierende Automatiken und noch viel mehr PC Steuerungen. Viele PC Interfaces sind noch immer der Idee von V24/RS232 verhaftet. Selbst wenn man das scheinbar über USB abwickelt ist das über Konverter gelöst. Hier hat mann das LocoNet und zusätzlich die veraltete serielle Verbindung. Wenn nun am Systembus Befehle zu den Fahrzeugen (Qualle Handregler oder PC) zeitlich mit den Meldungen der Freimelder in Konflikt sind kommt es zu zeitlichen Ungenauigkeiten. Symptom: Anlage läuft mit einem fahrenden Zug gut oder perfekt. Betreibt man das aber mit mehreren Zügen und rangiert parallel dazu händisch noch bleiben die Modelle "falsch" stehen. Bei kleineren Anlagen ist das noch einigermaßen tolerabel aber bei größeren Layouts führt das schnell zu gewaltigen Betriebsschwierigkeiten. Bestes Beispiel dafür sind FREMO Layouts. Da werden die Bediener gebeten wenig am FRED zu drehen um genau da Zeit für die anderen frei zu lassen.

Zweites Thema Bandbreite, also Volumen der Daten. Man kann im Datenformat DCC so etwa 80-100 Befehle pro Sekunde auf's Gleis legen, kommt auf die Länge des Befehls an. Nach jedem Befehl gibt es RailCom Rückmeldungen. Es gibt aber auch noch das Transponding oder die ZAK Quittierungen. DigiTrax kann schon nicht mehr korrekt alle Transponding Daten übertragen sondern muß viele Daten im Lesegerät wegschmeißen, hoffentlich nur Doppelmeldungen. Mit RailCom geht das gar nicht mehr durch. Man möchte ja nicht nur Decoder Adressen lesen, sondern auch Infos wie Qualität des Gleises, Zusatzdaten wie Stromverbrauch, Zuggruppen, das Anmelden von Modellen die grad' auf's Gleis gestellt werden und vieles mehr. Die Freimelder die die Daten lesen wissen ja nicht was an solchen Infos "entsorgt" werden kann, weil das die Steuerung eeh schon weiß. Das muß über den System Bus weitergeleitet werden. Daher muss da alles irgendwo hin wo ein "gescheites" Ding sitzt und die Auswertung macht. Bedenke die Geschwindigkeit am Beispiel RailCom ist 250kBaud, also grob 25x schneller als die langsamen Busse aus den 1960/70'ern. Da diese Daten aber nur nach den eher langsamen DCC Befehlen kommen, ist dazwischen einiges an Zeit diese Infos über den Bus los zu werden, das ist aber noch immer um Größenordnungen zu langsam.

Neuere Infos wie Decoder meldet seine Tastenzuordnung dem System, man sieht dann im Fahrpult oder in der APP am Hendl welche Funktionstaste was macht brauchten halt Bandbreite sonst geht das nicht. Das mühsame Einrichten der Fahrpulte kann so einfach entfallen. Interessant wenn man von einer Anlage auf eine andere wandert. Solche Dinge werden von Herstellern ohne schnellem Bus klein geredet.

Es gibt noch viele weitere Dinge die man nicht erkennt wenn man gezwungener Maßen überhaupt nicht an die Infos die heutige Modellbahnen können nutzt, weil das der Systembus nicht kann. Daher nochmals die Frage wie merkt man daß mir eigentlich was fehlt kommt nur wenn man sich von >40 Jahre Technik löst und schaut ob es nicht während dieser Zeit Fortschritte gegeben hat. In den 1970'ern benutzen viele noch Telefone mit Wählscheibe, da ist einiges passiert inzwischen. Zugegebenermaßen nicht immer von Vorteil. Aber man kann ja selbst wählen ob man sich von einem Streichelphone "quälen" lässt. Detto auf der Modellbahn, Viele Ärgerlichkeiten die dieses Forum ständig beschäftigt sind technisch stark gemildert oder komplett bequem gelöst durch die aktuelle Technik. Lies nach wie oft das Umbelegen von Funktionstasten hier behandelt wird. Nicht alles Neuere macht die Dinge sorgenfrei, aber das Gegenteil aktuelle Technik völlig zu ignorieren und so wie früher bei Rolls Royce dem Kunden einzureden ABS braucht man nicht wer so ein Auto hat fährt so, daß man das nicht braucht - ist auch nicht die Lösung. Das passiert aber grad' in der MoBa.
-AH-

vielen Dank für diese wirklich hochinteressanten Infos !
@haba # 15 - vielen Dank aber das übersteigt leider meine ekeltronischen Fähigkeiten um ein Vielfaches
@ Stefan #16
also das mit der Z Diode ist mir zu heikel - ich bin kein Elektroniker - aber der Hinweis mit der blauen LED  bzw dem Log Protokoll, dem geh ich in jedem Fall nach - vielen Dank - Digitalhersteller bietet ja ein upgrade der DR 5000 auf eine xyz an, aber ich denke das betrifft nur das WLAN Modul und nicht die Bauteile , die Du beschreibst ??

Ansonsten war mir schon klar , dass ich für mein Problem ( das ja nur sporadisch auftritt) wahrscheinlich keine Lösung bekommen werde. Meine Frage zielte eher darauf ab, wenn ich nochmals eine neue Anlage plane und auch nochmals bereit wäre, Geld in eine neue Steuerung zu investieren, wohin würde man da den Schwerpunkt legen - und so bin ich auf CAN gekommen ? ( aber auch das scheint nicht soo einfach zu sein) von der Logik scheint mir der BiDiB schon der richtige Ansatz , allerdings bleibt er leider auch solitär.

beste Grüße und Danke nochmals für die wirklich interessanten insights

Heinz  

Hi,



na so ganz solitär ist BIDIB ja nun nicht, Für die Hardware gibt es ja mit TAMS einen größeren und schon länger am Markt sich befindenen Hersteller und Fichtelbahn ist ja nun auch schon über 10 Jahre in Sachen BIDIB unterwegs. Und mit opendcc (W.K. et all) gibt es dazu auch noch einen privaten Entwickler, dessen Ideen bei den beiden kommerziellen Anbietern einfliessen.

VG wassi

PS: https://bidib.org/vendors.html  

Hallo Arnold,

welche heutige (!) Bussysteme von welchen Herstellern sind Deiner Meinung nach empfehlenswert ? (Bitte konkrete Namen). Und falls es mehrere Hersteller sind, sind die untereinander kompatibel ?

Viele Grüße, Joni

PS: Vielleicht hast Du es schon geschrieben, dann hätte ich es vor lauter Kritik an den andern Systemen übersehen.

@Heinz  
Nein das Upgrade kann das Problem mit den Rückmeldemodulen von Digikeijs nicht lösen. Das Problem liegt ja nicht in der Zentrale sondern in den Modulen selbst. Das Problem kann genauso bei allen anderen Zentralen mit Loconet auftreten.

Gruß Stefan

Hi!
Technisch sinnvoll sind nur Bussysteme die technisch ein solcher sind und keine überbordende IT Infrastruktur bauchen, die man kompliziert managen muß. Daher sind klassische Netzwerke wie Ethernet oder W-LAN keine gute Idee. Die Modellbahner kennen sich da auch nicht ausreichend aus. Daher konnte das auch kein Hersteller in den markt drücken trotz vieler gescheiterter Versuche.

Sinnvoll und das schon seit Jahrzehnten sind elektrisch sichere Bussysteme wie RS485 oder CAN Bus.

RS485 hast beim BiDib Fichtelbahn, Tams
CAN Bus ZIMO, ESU, Märklin, Roco und einige kleinere Firmen mehr

Die Busse sind was die elektrische betrifft HW gut dokumentiert. Das Protokoll darin wird leider möglichst von jeder Firma getrennt definiert. Einzige Ausnahme der ZIMO CAN Bus 2, der mit dem MX10 kam, wird auch von Roco benutzt. Zusätzlich gibts mehrere kleine Anbieter und Selbstbauprojekte da die CAN Bus HW bereits in den Chips drinnen ist.

Vorteil der beiden Busfamilien ist daß man bereits mit einem simplen 8-Bitter als Prozessor auskommt bei der Implementierung. Einfache CPUs machen aber nicht alle ESU und Märklin haben ja einen Pinguin in der Kiste hocken. Aber auch ohne Guano-Zeugs kann man die Sache langsam machen wie das ZIMO beim MX10 zeigt. Hingegen Roco bei der Z21 startet innerhalb von wenigen Sekunden.

Das soll die anderen Busse nicht schlecht machen nur für höhere Aufgeben sind die halt zu lahm.
-AH-

Vielen Dank, Arnold !!

Hallo

Das heißt, man ist i.d.R. auf Gedeih und Verderb auf einen Hersteller angewiesen.
Diesen Aspekt finde ich einen großen Rückschritt.

Oder sind bei den CAN Bus-Systemen Übersetzer in Aussicht, mit denen man Produkte des einen Herstellers an eine Zentrale eines anderen Herstellers anschließen kann ? Oder sind Anlagenkomponenten in Aussicht, die bezüglich CAN "multiprotokollfähig" sind ?
Ansonsten wäre das nicht einladend für CAN Busse.

Viele Grüße, Joni

Hallo Joni,
so lange die Protokolle nicht offengelegt werden bedeutet es genau das, man wird in der jeweiligen Welt bleiben müssen. Das Problem wie denn die Hardwarebelegung aussieht bleibt auch noch.

Ein kommerzieller Hersteller hat mit Sicherheit nicht die Zeit, das mittels Reverse Engineering herauszufinden. ;) Man müsste ja Mätrix, ESU, Roco und Zimo auswerten. Also den universal Übersetzer kann man sich abschminken denke ich. Und ob dann die kommerzielle Verwendung ohne Freigabe vom jeweiligen Protokollbesitzer rechtlich i.O. wäre, steht auf einem ganz anderen Blatt.

Gruß Stefan

Hi!
Der ZIMO / Roco CAN Bus ist hier definiert:
https://www.zimo.at/web2010/documents/ZIMO_CAN_Protokoll_4.28_Public.pdf da ist nix geheimes dran!
-AH-

Also Arnold würdest Du auf Grundlage eines internen Dokuments mit diesen Einschränkungen eine Entwicklung starten?

kilobit wenn schon, kilobit ist die Übertragungsgeschwindigkeit. BAUD ist die Schrittrate - was was anderes ist!

Sorry, aber das hat sich leider ab Ende der 1980er Jahre leider so eingebürgert in diversen Anleitungen!

Und die V24/RS232 kann auch 230 und 460 kbit schnell (das ging schon 1994!) sein, mit entsprechenden Bausteinen, wollte bloß keiner in der Modellbahn ..............

Daher Rs 422/485 oder gleich CAN Bus!

Gruß, Micha

Yep sorry wegen meinem Fehler Bit/Byte bei der RC Geschwindigkeit.

Busübersetzer ist sinnlos so wie bisher - wer kann LocoNet durch einen S88 durchleiten? Die LocoNet auf Xpress sind auch mühsam. Gegebenenfalls Fahrpult Traffic konvertieren auf Primitiv Art. Das will vermutlich kein Hersteller. Man will ja mehr Funktionalität anbieten wie Funktionstasten, Piktogramme, Tacho, udglm.
-AH-

Hallo,

als Drittanbieter kannst mit so einem Klopapier nichts anfangen. Und das wird beim Mitbewerb nicht viel besser sei.
Solange sich innerhalb der RCN keine Norm ergibt, kann man keine kompatiblen CAN Produkte herstellen, egal zu was.

Grüße, Peter W

Hallo Arnold,

bei Busübersetzer dachte ich an CAN des einen Hersteller zu CAN des anderen Herstellers. Nicht LocoNet, S88 oder Xpress untereinander (die sind kein CAN, oder ?). Ok, verzeihe, aber mit den Bussen kenne ich mich sehr wenig aus ... .

Vielleicht wären Busübersetzer auch der falsche Weg - falls dabei viel Funktionalität verloren geht. Aber wäre es möglich, z.B. Rückmeldebausteine herzustellen, die mehrere CAN-Busse verstehen ? Wäre doch ein Verkaufsargument, oder ? Aber da müssten wohl die Hersteller miteinander reden und kooperieren - schlechte Aussichten !???!

Viele Grüße, Joni

Es tut mir Leid, aber ich finde das alles andere als ausgereift, zukunftssicher oder fortschrittlich, wenn da jeder sein eigenes Süppchen kocht.
Oder muss ich damit leben, dass alle paar Jahre was neues auf den Markt kommt - wie eben im Computer-Bereich. Folge: Entweder springe ich jeweils auf die neuen Züge auf und kann das Alte in die Tonne treten - oder ich entscheide mich bei meinem System zu bleiben und bin dann halt in ein paar Jahren "für den Rest meines Lebens" veraltet ?? (Sofern ich dann noch Komponenten dafür bekomme ...).

Es gibt ja den NMRA LLC. Der ist sogar auf CAN basiert. Nur warum anwenden wir jetzt nicht alle LLC? Nicht mal in der großen USA?

Tja, weil es eben som eine unheimlicher Krampf ist irgend ein Paketorientiertes Protokoll über CAN zu realisieren. Da muss man von der Adresse bis zum Framing alles selber machen. Schon die Beispiele lehren eienm das Grausen. So nein, kein auf CAN basiertes Protokoll wird das Rennen als das neue "offene" Protokoll der Zukunft machen sagt meine Glaskugel.

Das mit dem Bussübersetzer ist jede Menge Arbeit für genau welchen Ruhm? Ich hab schon Software für vier Bus Protokolle geschrieben (LocoNet, WiThrottle, DCCEX, SRCP) und Übersetzer sind gar nicht so leicht weil bei der Frage "Was ist eine Lokaddresse" fängt es schon an (DCC kurz, DCC lang, SX, MM, MFX) und wenn dann auch noch dispatch und consist unterstützt werden sollen wird es etwass haarig.

Ich denke immer noch irgendwas über IP/UDP wird das Rennen machen, weit ich träum zwar von BLE aber das ist ja noch schlimmer als CAN.

Grüße,
Harald.

Seitens der RailCommunity wird es meiner Ansicht nach nie eine Norm bezüglich Bus geben. Das nennt sich zwar "Community", ist aber in Wahrheit nur Geplänkel.

Die einzige Chance ein System durchzuboxen wäre die Markthoheit eines einzigen Herstellers.

Da das hab' ich eeh so verstanden verstanden hab' das mit der Antwort nur etwas überzeichnet. Aber die Konzepte der Hersteller sind ja unterschiedlich. Beispiel: wie sollte die Piktogramme der Tastenzuordnung konvertiert werden? Alleine schon die Adresse des Fahrzeugs kennen einige Busse nicht sondern da wird mit Tabellen und Indexen darin gearbeitet. Also schon bei so was Grundlegendem wird es sehr aufwändig.


Das ist ein Hirngespinst ohne Abgleich mit den Herstellern. Ähnliches hat der MOROP vor Jahren als NEM Norm für Tastenanordnung versucht. Kein einziger der Hersteller hat nur ansatzweise überlegt sowas umzusetzen, so kann man ein Anwenderanliegen schon im Vorfeld töten. Da war faktisch vorsätzlich zur Verhinderung der Idee.


Korrekt, weil es ESU, ZIMO udglm gibt die bereit sind in Entwicklung und neue Dinge zu investieren dafür viel Geld in die Hand nehmen und andere die sich mit Händen und Füßen dagegen wehren Neuerungen zu entwickeln, oder noch schlimmer vom Mittbewerb was zu übernehmen. Eben weil das Aufwand ist. Es fehlt überall an Manpower das ist das große Problem, Geld natürlich auch noch...
Sehr ärgerlich sind vor allem wenn's schon Normen gibt daß jedes mal einzelne rausgrasen - ohne Ausnahme macht das jede Firma - und wegen einer Winzigkeit die Sache nochmals komplizierter machen. Derzeit grad' zu befürchten beim Melden der Funktionstasten bei der automatischen Lokanmeldung, nur als Beispiel. Dadurch wird dann die Sache "kaputt" gemacht um Gemeinsames machen zu können
-AH-

Hallo Miteinander,

Wenn ich diesen Faden so betrachte, dann bekomme ich den Eindruck, es gibt die Wahl zwischen:

(Ur-)Alte Bussysteme mit begrenzter Funktion, wie Loconet, Sx (ist von Anfang an bidirektional) oder … . Dafür mit Unterstützung durch mehrere Anbieter.

Oder neuere Bussysteme mit zusätzlichen Funktionen (z.B. Railcom), wie BiDiB-Fichtelbahn oder CAN. Aber dafür meist nur von einem Hersteller. Und wenn der den Bach runtergeht oder sein Produkt ändert, haste Pech gehabt.

Für mich stellt sich die Frage, ob es überhaupt einen "zukunftsfähigen" Bus geben kann (wie von Heinz, dem Eröffner des Fadens gefragt und gewünscht). Wenn ich so die Halbwertszeit in der Computerei betrachte - von vielleicht 5 Jahren - dann sehe ich eigentlich nur zwei Möglichkeiten:

Entweder zum Tag X kaufen, auf diesem Stand bleiben und hoffen, dass in späteren Jahren noch kompatiple Hard- und Software gibt.

Oder alle paar Jahre Hard- und Software durch neue ersetzen. Aber wer würde wirklich bei einer aufgebauten Modellbahn die Anlagendecoder erneuern, nur weil es jetzt andere gibt ? Bei einem Neubau ist das was anderes.

Und so langsam bin ich auch dabei, die Hoffnung auf einen genormten, neuen Bus zu begraben:

Es müssten einerseits die Hersteller sich auf eine Norm einigen bzw. eine anderweitig getroffene Norm 1:1 übernehmen.
Und andererseits kann in eine einmal gefundene Bus-Norm Neuerungen so eingebunden werden, dass die älteren Busteilnehmer weiterhin ihren Dienst verrichten können ?

Viele Grüße, Joni

PS: Und das Ganze noch bezahlbar !? Und für die Hersteller wirtschaftlich.

Digitalelektronik ist so billig geworden, man könnte da einen Einplatinencomputer mit LAN für jedes Rückmeldemodul nehmen. Und dann nen Webserver auf jedes Teil

Hallo,

zumindest unter den Informatikern gibt es ein sehr beliebten Comic, der die Situation auf den Punkt bringt:

https://xkcd.com/927/

Die Chancen, daß ein neuer Standard die alten entbehrlich macht, sinkt mit jedem neuen Standard. Insbesonders, wenn, wie hier schon mehrfach ausgedrückt, die Hersteller nicht an einem Strang ziehen.

Klaus

wirklich spannende Fakten, Einsichten und Meinungen - ich hab wieder sehr viel gelernt - vielen herzlichen Dank für eure tollen Beiträge , auch wenn ich das Fazit so nicht ganz mittrage. In der Automobilindustrie haben wir es auch geschafft uns auf neue Bus Systeme und neue Standards zu einigen ( zumindest im Groben)
Warum - da waren zum einen die Zulieferer, die sich auf Standards geeinigt haben ( weil sie einfach nicht jeder Marke eigens zugeschnittene Komponenten liefern konnten und wollten ) und weil der Gesetzgeber mache Funktionen vorschreibt , die zB hohe Verarbeitungsgeschwindigkeiten bedingen.
Würde sich die EU statt mit der Krümmung von Bananen, mit verbindlichen Standards für Moba beschäftigen ( was auch nicht weniger wertschöpfend wäre) - ihr würdet gucken, wie schnell wird dann einheitliche Standards hätten

meint Euer

heinz  

Hallo,

für die Krümmung von Bananenwagen brauchen wir gar nicht die EU das bringt die Modellbahn Industrie auch ohne Norm hin.

Grüße, Peter W

Hallo zusammen,

von wegen "Digital - und zwei Kabel", scheint eher eine Großbaustelle zu sein in der digitalen Modellbahnwelt.

Gruß
Chris

.... und wenn man keine Ahnung hat, dann einfach mal die F..... halten!

Sorry das ich das jetzt so schreibe, aber so langsam geht es mir auf den Keks wenn Analogies ohne Ahnung von Digital immer wieder so einen sch.... posten.

Gruß Alex