THEMA: Bus-Systeme

Hallo Helmut,
du kannst nur das/die Bussystem(e) verwenden, welche von deiner Zentrale unterstützt werden.
gruß
hajo

https://www.heel-verlag.de/Praxishandbuch+Digitale+Modellbahn.htm

https://www.themt.de/el-1400-dgt-49.html

https://www.buecher.de/shop/modellbahn/digitali...brgiubotpclj0uimmec/

https://bahnbuch.de/einfuehrung-in-die-digitale-modellbahn

und Dr. Google :)

Gruß
Jürgen

Hallo,

es fehlt BiDiB. Railcom ist kein Bus, sondern ein Variante des DCC-Signals. Bei CAN ist zu beachten, dass die Fraktionen Märklin/Trix/ESU inkompatibel zu Fleischmann/Roco/Zimo sind. Das wären also zwei verschiedene Systeme und somit Punkte in der Liste.

Welcher Bus der geeignetste ist, wird zu einem Glaubenskrieg führen. Gibst Du eine Empfehlung ab, wirst Du sofort von jemanden aus einem der anderen Lager als Depp hingestellt.

Tipp: Mach' eine Umfrage, das ist gerade ein heißes Thema.

Grüße
Zwengelmann

Um den Krieg zu eröffnen:
- Der SX-Bus ist zu vermeiden, sterbendes System.
- BiDiB, wenn Du von einem Hersteller abhängig sein willst und Traincontroller von vornherein ausschließen kannst
- Loconet ist weit verbreitet und bewährt

Servus Helmut,

wenn du die z21 (weiße Version, ggfs. mit WLAN Freischaltung) weiter nutzen willst spricht das eigentlich für den R-Bus für die Rückmeldung. Module dafür gibt es von Fleischmann/Roco selbst sowie Digikeijs.

Für Eingabegeräte gibt es den X-Bus (XPressnet) und einen Satz dafür geeignete Geräte. Und natürlich die WLAN-Maus.

https://www.z21.eu/de/produkte/z21start/anschluesse-z21#53-1289

Wenn die Frage der Zentrale offen ist gibt es natürlich auch alle Möglichkeiten. Aber ehrlich gesagt wüsste ich nicht warum. Die z21 kann erst mal alles was man braucht.

Eine kleine Einschränkung sind bestimmte Decoder die etwas heikel auf Spannung reagieren und das große Netzteil ist da etwas knapp dran, für unsere Spur ist ein Netzteil mit 15V DC völlig ausreichend.

Grüßle
Elvis

R-Bus, nicht RS-Bus.


Warum so martialisch.
Es geht auch anders, mal schauen.


Zwei Hersteller, Fichtelbahn und Tams.
Vorteile: schnell, Protokoll offen, beste Railcom-Unterstützung, sehr gutes Preis-/Leistungsverhältnis.
Wird die automatischen Decoder-Anmeldung unterstützen.

Grüße
Stephan

Servus,

jo, auch grad bemerkt... und korrigiert

LDT hat nur die Erweiterung für den 10787, das ist dann mit dem 10819 etwas überholt. Darum wieder rausgeworfen aus der Liste...

Und den GBM16XN gibts ja auch nicht mehr ab Hersteller. Schade drum...

Grüßle
Elvis

Hallo Helmut,

ich würde mir an deiner Stelle eine Aufstellung der benötigten Decoder machen und dann schauen, was der Markt pro BUS anbietet.

Belegmelder
Weichendecoder
Signaldecoder
Drehscheibendecoder
Booster

Oft hilft auch die Suche im www, um ggf. auf Themen wie parallel liegende Leitungen (Übersprechen) oder verdrillen der Litzen bzw. den Aufbau des Busses hinsichtlich der Reihung von Komponenten (auch die Anzahl der Decoder pro Strang) sich ein Bild zu machen. Das ganze ist dann auch noch davon abhängig, wie groß deine Anlage, also die Anzahl zu integrierender Decoder, ist.
Eine Empfehlung verkneife ich mir dabei mal.

Grüße
Christian

Hallo zusammen,
ich verstehe die Priorisierung des Themas "Bus" in dieser Breite nicht.
DCC Signal an Zubehör, ggf. extra Booster dafür, ggf. Rückmeldung über Railcom, gut ist.

Wer einen richtigen Bus hierfür nutzen will, sollte Kosten/Nutzen/Zukunftssicherheit abwägen.
BIDIB ist sicher intelligent gemacht. Mich hat persönlich die Software (erster Eindruck, nur Windows) abgehalten.

Relevant wird das Thema Bus doch sonst nur bei Rückmeldung und ggf. Handreglern.

Das müssen nicht mal die gleichen Busse sein, je nach Zentrale.

Ich denke also ...überbewertet.

Gruß Michael

Als Konfigurations-Tools gibt es den Wizard (Java) und den Monitor (nur Windows).
Steuerung-Software, die BiDiB unterstützen sind Rocrail, iTrain, Windigipet und ModellSTW wobei die beiden letzten nur unter Windows laufen.
An Windows kommt man wohl kaum vorbei, wenn man Hersteller-Tools nutzen möchte.


So unterschiedlich sind die Meinungen.
Warum nicht einfach einen Bus der alles kann?
Ist doch z.B. viel einfacher und komfortabler die Zubehör-Decoder über den Bus zu programmieren.

Grüße
Stephan

Für mich ist der Umstieg auf Digital ja vor allem deswegen interessant, weil ich damit so grosse Anlagen steuern kann, die schon wieder zu gross für mich alleine sind. Wenn ich also Kollege Computer mitspielen lassen will, brauche ich Rückmelder damit der "sieht" wo was ist.

Ich will nicht nur einen "Bus" der alles kann, sondern ein ganzes System, was "alles" kann. Fahren, Schalten, Steuern (auch selbständig/automatisch) und einfach zu verkabeln ist und funktioniert. Und günstig ist. Gibts leider nicht (aus einer Hand) :(

Viele Grüsse

Michael

Hallo Namensvetter,
so ein System wäre toll, müsste für mich jedoch auch standardisiert sein und von vielen Anbietern unterstützt werden.
Eine Moba ist halt eine langlebige Investition, auch mit viel Lebenszeit und Herzblut - bei einem kleinen Markt für Elektronikhersteller. Das passt halt nicht zusammen.
Deshalb mein eher pragmatischer Ansatz, bei dem im worst case auch mal ein paar Kästchen und Büs-chen ausgetauscht werden könnten.
VG Michael

Noch eine Frage zum Thema Bus/Rückmeldung:
Wie verhält es sich denn mit s88?
Muss ich mich da von Anfang an bei der Planung dafür oder dagegen entscheiden und festlegen oder wovon hängt der Einsatz ab?
Und in Verbindung mit welchen Zentralen bzw. welchem PC-Steuerungsprogramm?
Schöne Ostern!

Hallo Helmut,

S88 ist ein altbackenes System, sozusagen der Pionier. Über S88 bekommst Du nur die einfache Belegtmeldung, d.h. irgendwelche Railcom-Rückmeldungen funktionieren damit nicht. Ist aber nicht schlimm, jede Software kommt damit klar.

S88 hat ein kleines Problem: Es ist im Grund eine Kette von Rückmeldern. Wenn nachträglich irgendwo etwas eingefügt werden muss, verschieben sich sämtliche nachfolgenden Adressen. Natürlich gibt es auch dafür Lösungsmöglichkeiten, aber im Prinzip ist eine nachträgliche Einfügung nicht vorgesehen.

Du solltest auf S88N achten. S88N ist im Gegensatz zu S88 sauber definiert und erlaubt größere Buslängen bzw. ist weniger störanfällig.

Eine Lösung der genannten Problematik ist, dass man einen anderen Bus als Hauptbus nutzt und nur auf lokaler Ebene S88N-Melder einfügt. Für Loconet und BiDiB gibt es Schnittstellen, bei den anderen Bussystemen weiß ich es nicht. S88 lässt sich also grundsätzlich mit allen Bussystemen nutzen, die entsprechende Schnittstellen haben, sowie mit Zentralen, die den direkten Anschluß vorsehen. Da fehlt mir der Überblick.

Grüße
Zwengelmann

Ich würde ganz pragmatisch vorgehen:

Erstelle eine Rangliste zu folgenden Punkten

Welche Handregler gefallen dir? Oder brauchst du gar keinen Handregler?
Welche PC Steuerungsprogramme gefallen dir?
Hast du vor ein Gleiststellbild zu verwenden?
Brauchst du eine Spezialsteuerung? z.B Drehscheibe.
Bist du in einem Klub oder Kennst du Leute die ein bestimmtes System verwenden. Auch Spurübergreifend. Habt ihr den selben Bus kann sogar der Handregler des Gartenbahners verwendet werden.
Wie viele Ruckmelder, Weichen, Signale etc hast du.
Kommt Selbstbau in Frage?

Dann kannst einen (oder mehrere) Bus suchen, je nach Anforderungen fallen einige raus.

Ich würde die Rückmeldungen wie auch die Schaltbefehle für Weichen und Signale über den Bus nehmen. Einige Systeme können nur Rückmelden. Ich persönlich finde es eleganter wenn ein Weichenbaustein auch gerade die Istlage zurückmelden kann.

Viele Grüsse
Matthias

Hallo Zwengelmann,

der Blödsinn war jetzt wieder nötig:



Wieso ist etwas, was einfach funktioniert, für Dich ein ,sterbendes System‘? Du klingst genauso, wie die Unzahl von Windows-Usern, die gegen Apple wettern, in Wahrheit jedoch nicht den Hauch einer Ahnung haben, wovon sie reden.
In diesem Fall stellt sich die Frage gar nicht, da der Weg seitens der vorhandenen Zentrale vorgegeben ist. Aber es muss halt immer jemand auf die Kacke hauen.

D&H entwickeln an dem ‚sterbenden System‘ fleißig weiter. Schon komisch.

Jens

Mit den neuen Zentralen von Tams und einem Kooperationspartner kommt BIDIB als meiner Meinung nach einziger technisch zeitgemäßer Bus in ein ganz neues Licht.
Hätte mich vor einem Jahr evtl. anders entscheiden lassen.
VG Michael

https://tams-online.de/epages/642f1858-c39b-4b7...ital/EasyControl/mc2

Ich frage deshalb so "dumm" weil ich alleine z.B. bei Digikeijs verschiedene Rückmeldedecoder sehe:
S 88, s88n, LocoNet, Opto, R-Bus, ....
Bei den anderen Anbietern ist es ähnlich.
Dies verwirrt mich etwas und ich weis nicht, was ich wozu verwenden soll und warum.
Ich bin noch in der Planungsphase und möchte das momentan beste System verwenden und nicht auf das "falsche Pferd" setzen.
VG Helmut

Hallo Helmut,

du könntest den Gaul so aufzäumen: Was hast du für eine Zentrale? Willst du dabei bleiben?

Ja, dann gibt Dir diese die Möglichkeiten vor.

Nein: Was muss eine Zentrale können? Diese gibt dann in weitem Rahmen den Bus vor.

Ich persönlich arbeite mit dem ‚sterbenden System‘ und bin sehr zufrieden damit.


Jens

Schönen Abend,

arbeiten die BidiB-fähigen Komponenten von Fichtelbahn und die von Tams (mc2) eigentlich problemlos zusammen oder gibt es da noch zu wenig Praxiserfahrung?

Und hat Littfinski mit dem Infinity-Cube neulich nicht auch irgendwas BidiB-kompatibles ausgegraben?

Vielleicht kommt ja nun doch mehr Schwung rein, wenn BidiB nun dank Out-Of-The-Box-Produkten auch von weniger lötfreudigen Hobbygenossen genutzt werden kann.

VG Andreas

Hallo Helmut....
mir geht es da genau so!!
viele Anbieter viele Meinungen.
Gruß Frank

Grüße Euch,
meiner Kenntnis nach ist das die zu Tams baugleiche Zentrale von LS Digital.
https://www.lsdigital-shop.de/produkt/infinitycube/
Wurde gemeinsam entwickelt.

Kompatibilität vermute ich bei den Komponenten, weil es ja eine Spezifikation von Herrn Kufer gibt. Erfahrung damit habe ich keine.

Bei mir geht die Rückmeldung von Railcom über Loconet, was aber glaube ich eine Sonderlösung von Digikeijs ist. Wie gesagt, wenn das mal zum sterbenden System wird (um den Kollegen zu zitieren) tausche ich das System, darauf bin ich baulich vorbereitet.

VG Michael

@ Helmut_k

S88 und S88_N ist praktisch dasselbe, S88N verwendet normale Netzwerkkabel und ist daher unempfindlicher gegen Störung.
Genaugenommen ist S88 kein Bus sondern ein Schieberegister. S88 kannst nur Melden aber keine Schaltbefehle abgeben.

OPTO heisst es ist eine galvanische Trennung mittels Optokoppler vorhanden.

Den Railcomrückmelder gibt es bei digikejs nur für Loconet.
S88 und S88N kannst du an Loconet oder RBus Rückmelder anschliessen.

Loconet ist weit verbreitet und wird von allen gängigen Steuerungsprogrammen unterstützt. Auch viel Vereine und Modulanlagen wie FREMO oder NTRAK verwenden Loconet. dazu gibt es alle möglichen Bausteine von verschiedenen Hersteller und auch viele gute Bausätze und Unterstützung für Arduino und Raspberry. Im Englischsprachigen Bereich ist Loconet de facto der Standard.


Als ich mir Gedanken gemacht habe, waren Selectrix und Loconet in der Endauscheidung. Ich kannte aber persönlich niemand der SX verwendet hat, so wurde es Loconet.

Viele Grüsse
Matthias

Hallo Helmut,

ich finde die Frage alles andere als dumm. Während hier über die Gleissignale ausgiebig Diskurs geführt wird, werden die Busse fast gar nicht betrachtet. Ich vermute, dass sich nicht wenige Modellbahnfreunde anhand des Gleissignals eine Zentrale aussuchen, zunächst nur fahren und später Schalten und Rückmelden ergänzen und dabei die Busse verwenden, die die Zentrale eben mitgebracht hat.

Die Busse erfüllen verschiedene Funktionen z.B. Schalten (Weichen, Signale), Rückmelden (Belegmelder), Verbindung zum Handregler und Verbindung zum Rechner (heute meist USB direkt an der Zentrale). Nicht alle Busse erfüllen alle Funktionen, DCC-Schalten schaltet eben nur, S88 ist ein reines Rückmeldesystem.

Viele Grüße
Martin

Hallo Helmut,

ich gebe Dir vollkommen Recht. Und das ist eben auch einer der Gründe, die mich seinerzeit zu SX gebracht haben: Dieses System war das erste und lange Zeit das einzige, das alles in einem Aufwasch gemacht hat. Der SX-Bus war von Anfang an Bestandteil des Systems. Über ihn wurde geschaltet und gemeldet. Es war alles einheitlich. Ich musste mir keinen Gedanken um ein Bussystem machen, es war einfach dabei und es war eines der zuverlässigsten und leistungsfähigsten Systeme. Macher dcc-Fahrer hat doch tatsächlich dn SX-Bus zum Schalten und Melden eingesetzt.

Heute gibt es viele, die behaupten SX sei ein sterbendes System. Komisch, denn die neue FCC ist in der Lage RailCom auszuwerten. Auch die neuen SX-Bus-omponenten werden RailCom können. Vermutlich ist es anders herum: Das totgesagte SX wird vermutlich als erstes System RailCom vollumfänglich nutzen.

Einen Bonus gibt es in meinen Augen obendrauf: Mir ist es völlig Wurscht, was für ein Decoder in einer gebraucht gekauftenLok drin ist, sie fährt bei mir immer (von Steinzeit-dcc-Decodern abgesehen...)

Jens

Meinem Verständnis nach sind die "beiden Drähte", die man an Weichendecoder und Gleise anschließt bereits ein Bus, der liefert Energie und Daten.
Das Ganze "Gleissignal" zu nennen ist vermutlich ein Marketingbegriff, den mal irgend jemand platziert hat, der sein spezifisches Zeug verkaufen will, der der Sache jedoch nicht gerecht wird.
Gruß Michael

Hallo Michael,

es macht schon einen Unterschied. Die ‚beiden Drähte‘ liefern zunächst Strom und Signal für die Dekoder. Früher hat man Weichendekoder an den Schienen angeschlossen und man konnte tatsächlich seine Anlage mit zwei Drähten digital betreiben. Damit warb man bei mm und dcc. Man konnte Loks fahren und Weichen stellen, aber kein Gerät konnte sagen, ich bin gerade so und so eingestellt. Rückmeldung hat es also nicht gegeben.

SX widerum hat das von Anfang an anders gemacht. Die Schalt und Meldebausteine wurden über eine separate Leitung mit DIN-Steckern betrieben. Das standardisierte Signal beinhaltete sowohl die Schaltbefehle als auch die Rückmeldungen von Meldebausteinen. Somit war das System in der Lage, die Position der Züge auf der Anlage zu bestimmen und programmgesteuert darauf zu reagieren -automatisch.

Bei dcc waren dafür separate Lösungen notwendig, die in den heutigen Busdschungel mündeten, weil jeder einen Grund brauchte, damit man nur sein System kaufte. Das war bei SX anders.

Wer nur digital seine Lok steuern will und vielleicht Weichen schalten will, für den tut es dcc. Wer mehr will, etwa Teil- oder Vollautomatik, der muss sich um ein entsprechend leistungsfähiges Bussystem Gedanken machen. Über RailCom erreicht man erstmals eine Rückmeldung der Züge, etwa wie schnell sie in welche Richtung fahren, welche Adresse sie haben, wie Gut das Signal ist, das sie erhalten u.s.w. . Das sind eine Menge Informationen und je mehr Loks auf der Anlage stehen, desto mehr werden es. Viele Busse können das nicht leisten oder nur teilweise.

Der Standard SX-Bus kann das auch nicht. Allerdings wird daran, wie bereits erwähnt, entwickelt.

Was letztlich daran Marketing ist, hängt von Deinen Anforderungen ab.

Jens

Wie kommst Du zu der Aussage?

Grüße
Stephan

Hallo Stephan,

beachte das Wörtchen "vermutlich". Damit lässt sich alles begründen. Die erste Modellbahn in der geplanten Raumstation auf dem Mond wird vermutlich auch mit SX gesteuert. Isch schwör!

Rocrail "vollumfänglich" ginge heute mit Loconet (wenn die Anlage nicht groß ist) und BiDiB. Ginge, wenn eine entsprechende Software verfügbar wäre. Die Software ist der Knackpunkt bei "vollumfänglich".

Grüße
Zwengelmann

Hello!
Wenn Du anfängst kannst Du jetzt die Entscheidung treffen ob Du jetzt sparst und später sehr hohe Kosten hast. Alternativ jetzt etwas mehr Geld ausgeben und eine leistungsfähige Plattform kaufen die zwar etwas mehr Geld kostet aber später keine Limitationen verursacht.

Die uralt Bussysteme wie S88, SX, X-Press Net, und LocoNet würde ich auf keinen Fall mehr in einem neuen Projekt an wesentlicher Stelle einbauen. Eventuell noch LocoNet und X-Press Net für ganz simple Fahrregler, sofern man hier auf Rückmeldungen von der Anlage verzichten will. Finanziell ist das kein Gewinn so man einen schnellen guten Bus ohnehin auf der Anlage hat.

BiDiB hat derzeit nur Tams und Fichtelbahn als Anbieter. Beide sind eher kleine Unternehmen, wobei hinter Fichtelbahn der sehr engagierte Entwickler des BiDiB steht.

CAN Bus gibt es derzeit 4 miteinander inkompatible Implementierungen, das nur als Info daß CAN Bus nicht zwingend miteinander kompatibel ist. Vorteil ist er ist überaus leicht zu bauen (für die Hersteller), da durch die Verwendung in KFZ die Bauteile extrem billig sind. Weiters für Modellbahner nur unter gröbster Mißachtung von Empfehlungen zu stören, maW extrem betriebssicher!
Es gibt ESU, Märklin und ZIMO als CAN Implementierungen in der Modellbahn Welt. ZIMO hat 2 Varianten wobei die neuere für Dich interessant sein kann. Diese wird auch von Roco benutzt. Dadurch gibt es gute Versorgung mit durchaus günstigen Modulen und Zentralen Z21 (schwarz). Wenn man's komplexer haben will kann man ZIMO Baugruppen einstreuen - leider sind die Preisschildchen bei ZIMO immer etwas prohibitiv hoch. Weiters will ZIMO oft längere Zeit nix liefern - warum auch immer.

Bei einem Neubau heutzutage unbedingt DCC vorsehen als Gleissignal, das ist ohnehin unwidersprochen. Weiters so bauen, daß man RailCom als Rückweg von den Fahrzeugen zum Steuerbereich nicht künstlich verhindert. Das bedeutet es gibt daher nur BiDiB und die ZIMO/Roco/Fleischmann CAN-Bus Variante. Nur die beiden Bussysteme sind offen, also sowohl die Elektrik als auch das Protokoll für andere Entwickler einsichtig und benutzbar. Märklin/Trix hat viele Beschränkungen, ESU ist auch gut, hat ein fertiges System mit allen nötigen Baugruppen. ESU ist aber teurer und hat Bussystem nicht offen gelegt und auch einiges im Bereich RailCom nur proprietäre Lösungen wie RailCom+.

RailCom+ dient zur Anmeldung von Decodern am System. Die Normung ist gerade im Laufen, es gibt da im Wesentlichen 3 Methoden von ESU/Lenz, Kufer (Fichtelbahn) und ZIMO. Ich erwarte daß die genormte Version keine der 3 sein wird.
-AH-

Wenn ich den Faden hier verfolge, kann man sich heute auf eine der Inseln setzen und hoffen, daß die bei der "Klimaerwärmung" alias Marktbereinigung nicht untergeht.

Würde ich mich heute für ein Digitalsystem mit entsprechender Not zur Auswahl von Komponenten entscheiden müßen, wäre ich aber arg verunsichert. Das alles hat ja gute Chancen, daß die Entscheidung, wie sie auch immer fällt, die falsche sein wird. Möglicherweise überlebt ja auch keines der Systeme, weil dann am Ende doch der "technische Fortschritt" weitere Varianten ins Spiel bringt.

Schade, daß der ganze Markt von den Herstellern und nicht durch die Kunden getrieben ist.

Gruß
Klaus

Hallo Klaus,
ich sehe das Thema eher aufgebauscht.

Es geht doch bei der Diskussion um zukünftig verbreitete und unverbreitete, den üblichen ewig untoten und weitere Busse primär um Rückmeldung und vielleicht noch Handregleranschluss. Also vor allem Rückmeldung. Im schlimmsten Falle müsste ma diese erneuern. Sicher teuer, Wahrscheinlichkeit gering, auf keinen Fall Weltuntergang.

Weichen und Loks zappeln weiter lustig über DCC und melden sich sogar über Railcom an bzw. ihre Stellung (Weichen) zurück.

Gruß Michael

Ja genau! Wieso hat man einen Bus, der nicht von Haus aus in beide Richtungen funktioniert? Die Idee, vergleichsweise kompliziert DCC in den Strom einzukoppeln und am Dekoder wieder raus, erscheint mir völlig falsch. Kann ich auch gleich den Dekoder mit "normalem" Strom betreiben und ein "ordentliches" Bussystem nutzen. Ohnehin erscheint es mir unpraktisch, das viele der "Busse" nur in eine Richtung funktionieren und zudem auch noch einen "zentralen Master" haben. Komponenten die untereinander Kommunizieren sind scheinbar unüblich. Warum... Egal, das führt zu weit.

Von der Leitungsphysik ist CAN sicherlich gut, aber das Protokollwirrwarr erscheint mir wirklich unzeitgemäß. Warum normt da nicht mal einer? Klar, jeder Hersteller kann tun und lassen, was er mag. Aber auch wir, könnten uns mal erdreisten, "einfach" mal die Systemanforderungen zu definieren und eine Norm etablieren. Es muß ja nicht immer der Hersteller sein, der seine Claims absteckt. Aus meiner Sicht ist es längst Zeit, daß der Kunde mal tätig wird, denn die Summe der nicht kompatiblen "Nicht-System" Komponenten kann am Ende ja nicht hilfreich sein, zumindest, wenn man die Lebensdauer über die von Smartphones heben will

Gruß
Klaus

Hallo,

in ein paar Jahren werden wir über die lächerlichen Bussysteme lachen, auch CAN wird in der Automobilindustrie vermutlich bald abgelöst weil er teuer und sperrig ist - an Lösungen wird seitens der Chip Hersteller gearbeitet.

Der einzige Netzwerk ähnliche Bus von den bestehenden am Markt ist Loconet.

Grüße, Peter

Auch die Amis haben mit LCC (Layout Command Control®) auch unter OpenLCB ein CAN System am Start. Wurde von der NMRA verabschiedet und sollte Herstellerübergreifend sein. Das ganze dümpelt aber auch schon seit einigen Jahren rum, ohne Unterstützung der grossen Hersteller.

In der Industrie sind CAN und RS485 Lösungen schon massiv im Hintertreffen. Ethernetbasierte Lösungen sind viel Leistungsfähiger und kosten genau gleich viel wie die seriellen Busse.

Sofern hat Peter wahrscheinlich recht. Ich verstehe nicht wieso man jetzt noch auf neue serielle Busse setzt wenn man ein schönes System mit PoE (Power over Ethernet) oder WiFi bauen könnte dass dann wirklich Leistungsfähig und Zukunftssicher ist.

Viele Grüsse
Matthias

Abwarten und Tee trinken.
Für die Modellbahn werden in den nächsten Jahren bestimmt noch ein paar neue Bussysteme als der ultimative Standard auf den Markt kommen. Je nach Marktanteil des Erfinders haben sie dann eine Chance oder auch nicht. Und während neue Systeme kommen und gehen, bleibt S88 (N) wahrscheinlich sogar weiter bestehen...

Grüße

Michael

Das ist jetzt aber eine Wahrnehmungsstörung Auch Ethernet ist seriell

Und PoE über die dünnen Leitungen einer Cat 5/6/7 Leitung sind für Moba Anwendungen ungeeignet. Ein Servodekoder zieht ja mehrere Ampere, wenn die Servos arbeiten. Ich bleib dabei: Bus- und Stromversorgung haben nichts miteinander zu tun und das sollte so bleiben.



Na ja... die Physik bleibt unbestechlich. 100MBit gehen halt nicht über mehrere Kilometer über normale Cat 5/6/7 Verdrahtung. CAN ganz locker, aber dann eben auch nur noch mit ein paar Kilobit. Also Äpfel mit Birnen zu vergleichen hilft in dem Fall nicht.

Die Leistungsfähigkeit meint hier wohl das Datenübertragungsvolumen... ist das aktuell in irgendeiner Moba-Anwendung ein Thema? Glaub ich nicht!

Zudem sind die Gesamtkosten bei Ethernet noch deutlich höher, wenn wirklich nennenswert mehr Daten rüber kommen sollen. Denn dann brauchts auch einen schnellen Controller mit mehr Speicher usw, der auch den komplexen Protokollstack abfahren kann und trotzdem Echtzeitanwendungen machen kann. Entsprechend sind auch die Anforderungen an die Software entsprechend. Mit dickerem Controller, den üblicherweise externen Leitungstreibern usw. plus Stecker und Leitungen ist Ethernet immer noch ein vielfaches teurer als als CAN oder noch mehr RS485. Natürlich kann man auch Ethernet auf Mini-Controllern fahren mit externem Ethernet Chip. Nur dann kommt da gar nichts mehr an Leistung an, jedenfalls eher weniger, als bei chip-interner CAN-Schnittstelle. Nicht zu vergessen: Ethernet in gestörter Umgebung bräuchte dann auch voll galvanische Trennung. Das sparen sich so manche Leitungstreiber derzeit aber.

Aber das ist ja alles nur die Definition der physikalischen Schnittstelle. Nach meiner Auffassung bräuchte es erst mal ein brauchbares Datenmodell für die Moba. Wie die dann über welchen Draht übertragen werden, ist doch letztlich egal! Auch entsprechende Bus-Brücken könnte man ja bauen, von S88 nach CAN nach Ethernet oder wie auch immer.



Was bringt mir das, außer Störungen? Die Idee mit NFC auf Basis von Bluetooth kann ich mir vorstellen, ist aber teuer, allein der Lizenzkosten wegen. Aber jeden Weichendekoder mit 'ner Wifi Karte zu versorgen... ich glaub, das wird nichts Abgesehen vom Stromverbrauch, der nicht eingesparten Leitung für die Stromversorgung und all der anderen Unwägbarkeiten.

Wie auch immer, solange jeder sein Süppchen kocht, wird da kein Brei fertig.

Gruß
Klaus

Hallo Klaus

Ich habe es durchgerechnet für SPS und Leitsysteme. Die Ethernetbasierte Lösung ist mittlerweile günstiger. Bei einem mehreren Kilometerlangen CAN Bus müsstest du auch galvanisch trennen etc. Bei Ethernet nimmt man einfach Glasfaser. Für Spur N werden aber Kupferleitungen Problemlos ausreichen.



Ein ESP32 Entwicklungsboard mit WiFi mit mehr als genug Rechenpower für eine DCC Zentrale plus den ganzen TCP/IP Stack kostet eine Handvoll Euro. ein CAN Fähiges Board ist auch nicht günstiger. die Zeiten der 8Bit Controller sind langsam vorbei.



Beim Gleissignal aller Digitalsysteme sind Strom und Datenübertragung miteinander verbandelt und nicht immer auf eine elegante Art und Weise.

Bei Spur N ist es noch ein Problem der Grösse aber ab HO könnte man die LokDecoder auch mit BT oder Zigbee ausrüsten und aufs Gleis einfach Gleichspannung zur Stromversorgung geben.



Die gibt es schon. Da reicht dann aber S88 und Loconet zu Ethernet und das gibt es bereits.

Gruss
Matthias

Hallo,

nix CAT5/6/7. 2-Draht 10 MBit Ethernet (half duplex) ist angesagt. Da braucht man auch keine Hubs und Switches.

Grüße, Peter W

Hi,

Ethernet ist nicht echtzeitfähig und deshalb für Steuerungsanwendungen nicht geeignet. Es gibt zwar Varianten, die isochrone Datenübertragung ermöglicht, aber das ist dann mit dem herkömmlichen Ethernet nicht kompatibel, das wäre ein weiteres System im Zoo.

Grüße
Zwengelmann

Can auch nicht... auch hier ist keine Arbitrierung garantiert. Methoden zur Round-Robin Arbitrierung fehlen vollständig usw. Allein die Priorisierung von Nachrichten ist keine zeitliche Zusage.

Fragt sich indes, was bei 10MBit, wie oben vorgeschlagen, auf Ethernet alles gesendet werden müßte, damit man modellbahnspezifische Zeitlimits überschreiten kann. Ethernet hat allerdings den ganz erheblichen Nachteil, daß schon bei nur leicht steigender Last die Zahl der verworfenen Pakete stark ansteigt und man daher im Halbduplex nicht mal näherungsweise an die theoretische Datenmenge entsprechend der Bitrate kommt.

Echtzeit meint ja nicht schnell, sondern ein garantiertes Zeitverhalten.

Nach diesen Kriterien wäre USB beinahe genial, den genau dafür hat man garantierte Zeitzuordnungen auf dem Bus vorgesehen die garantiert kollisionsfrei genutzt werden können und sich auch mehrere Sender nicht gegenseitig die Butter vom Brot klauen.

Gruß
Klaus

Hallo,

.
Was heißt denn bei Dir echtzeitfähig! Und welche der Zentralen ist es?

Gruß

Hallo ulus,

die Diskussion geht mittlerweile um ein zukünftiges System. Da braucht man keine Zentrale mehr. Bereits heute gibt es Systeme, bei denen Funktionen teilweise in die Rechnersoftware verlegt werden, Beispiel DCC++.

Grüße
Zwengelmann

Hallo Zwengelmann,

das habe ich verstanden, beantwortet aber meine Frage nicht.

Gruß

P.S.: Baue gerade an meiner Bahn, die mit BiDiB betrieben werden wird.

Au weia!

Da muss ich aber schon mal reingrätschen. Richtig ist: Die Gleisprotokolle sind alle unidirektional. Hier soll RailCom Abhilfe schaffen. Hat man ei Blockhestütztes System mit Rückmeldern, müssen diese in der Lage sein, die von der Lok kommenden Informationen Ungekürzt weiterzuleiten. Dafür braucht es einen leistungsfähigen Bus.

Braucht man das nicht, reichen heutige Bussysteme aus.

Und weil jemand gesagt hat, die Bussysteme wären unidirektional: Stimmt nicht! BiDiB trägt das im Namen: Bi Direktionaler Bus. SX war schon immer bidirektional.

Aber SX ist ja ‚sterbend‘....

Jens

...würde eher sagen "Der untote Missionar", der hier regelmäßig erscheint

Ist trotzdem falsch und völlig missverständlich.
Was soll der Themen-Starter damit anfangen?

Grüße
Stephan

Machen CAN, Loconet und SX.
Xpressnet und BiDiB haben einen Busmaster.


=> BiDiB, von Modellbahner für Modellbahner, schnell, Spezifikation frei verfügbar, für zukünftige Erweiterung offen, nicht an ein Medium gebunden.

Grüße
Stephan

Wäre mir neu, wo ist diese Info zu finden?

So ein System ist mir nur von Railware mit dem 'USB DCC-Generator' bekannt.

Grüße
Stephan

Hallo Stephan

Die neuste Version von DCC++ ist das Arduino basierte DCC EX.

https://dcc-ex.com/index.html

Hallo Stephan,



Das bezog sich auf die anfängliche Äußerung eines gewissen Zwengelmann,  Wie gesagt: Die Neue FCC kann nicht  nur die RC-Austastlücke erzeugen, sie kann auch RC-Informationen empfangen und an die Steuersoftware weiterleiten. Auch die neuen Belegtmelder werden dies können.

Was also ist da nicht zeitgemäß?

Unter diesen Aspekten ist die FCC eine unbedingte Empfehlung - mit SX-Bus.

Jens

Folks!
Zu den Bussystemen irgendwelche Empfehlungen zur Technik aus den 1960ern bis1970ern ist keine gute Idee. Somit alles mit den langsamen Geschwindigkeiten wie LocoNet udglm kann nicht gehen.

Ethernet und Funk udglm sind oft angedacht und auch implementiert worden. Der Beweis der Dysfunktionalität ist mehrfach erbracht worden. Zumindest derzeit ist das Zeugs zu groß und zu empfindlich.

RailCom ist die bisher einzige Methode die funktioniert um von Fahrzeugen Daten über das Gleis zurück zu senden. mfx hat Märklin/ESU entwickelt, ist aber wesentlich komplizierter, vor allem größer und kann weniger und vor allem langsam. In N AFAIK kaum zu implementieren - zumindest derzeit.

Die Normung von Bussystemen hat einen Konflikt: es gibt Hersteller die wollen viel Funktionalität. Kann man benutzen muß man aber nicht. Das verursacht auch einiges an Aufwand Beispiele ESU und ZIMO, auch mit dem BiDiB Ansatz hätte man einen guten Bus. Der hängt aber Funktional gegenüber ESU und ZIMO bereits zurück, nicht von der Technik her sondern auf der Definitionsseite. Es gibt andere Hersteller die wollen möglichst keine Funktionalität geben sich mit dem simplesten Ansatz zufrieden der schon am Schreibtisch nicht ordentlich geht. Das bietet meist nur Minimalistisches und greift immer zu kurz. Die beiden Extrempole finden nicht zusammen, daas wird aber von den Anwendergruppen wie MOROP oder NMRA kategorisch ignoriert. Das Hauptproblem ist, daß Anwender erwarten wenn man verschiedene Hersteller mischt daß das funktioniert. Da gibt's immer Ärger, vor allem wer macht dann Support? Dieses Forum ist voll von solchen Fragen. Daher sind die Ansätze zur Busnormung bisher ohne gewünschtem Ergebnis.

Zur Ursprungsfrage zurück: Einer der CAN Busse oder BidiB.

Die uralt Klamotten (SX, X-Press, LocoNet) sind einfach um Faktor 100 zu langsam, S88 kann nur besetztmelden. Heutzutage jemanden in historischer Liebe zu irgend einer alten Plattform (da haben vor allem die SX Leute ein Problem) dort hin zu schicken ist grob böswillig falsch!
-AH-

Hier ist das vergleichsweise neutral und sehr reflektiert beschrieben auch in Bezug zum Standardablauf in solchen Threads wie auch diesem hier wieder...

https://doehler-haass.de/cms/pages/haeufige-fragen.php#a11

Gruß
Eglod

Hi!

Wo geht dieses Q&A auf die Frage des UP ein? Es gab im Thread ein paar Abschweifungen zu Digitalformaten, das kann man ja zur Erklärung von Gedanken machen.

Kern der Frage ist wenn man neu anfängt welcher Bus, da hat D&H den SX Bus der wohl in keinsterweise zukunftsorientiert ist. War Super zur Zeit als er entworfen wurde für die damaligen Anforderungen.
-AH-

In der Antwort auf die letzte Frage unten, die im Link auch schon geöffnet ist, gibt es Informationen zu Bus-Fragen.

Und wenn ich nicht ganz falsch liege, zielte der allererste Punkt der Ursprungsfrage genau auf den dort behandelten Thmenkreis.

Gruß
Eglod

Auch heute kann man bedenkenlos eine Anlage mit SX oder Loconet bauen.
Traincontroller unterstützt Bidib noch nicht. Und Handregler werden bei Bidib über Xpressnet abgeschlossen. Also auch über einen Uraltbus. Bei den Regler hat sich WLAN schon durchgesetzt. Auch bei Modultreffen war es kein Problem solange das WLAN ausschliesslich für die Modellbahn benutzt wird.

Wenn schon CAN dann Märklin,Trix und kompatible wie CanDigitalbahn. Da hat man dann auch Handregler eine riesige Auswahl an Hard und Software inklusive Handregler.
Der Rest steckt einfach zu fest in der Nische.
Gruss Matthias

Es wäre für mich persönlich kein Argument, dass eine einzelne SW BidiB nicht unterstützt, dann nutz doch iTrain oder Rocrail oder ....

So wird man halt nie auf einen grünen Zweig kommen. Es wird immer Gründe dafür und dagegen geben.

Solange es keinen "Mainstream Standard" wie DCC gibt, führt die Diskussion in die Unendlichkeit.

Dass man bei der HW zumindest auf etwas aus diesem Jahrhundert setzten sollte, auch wenn ich das selber mit Loconet wohl nicht getan habe, leuchtet mir allerdings ein.

VG Michael

Hallo zusammen,
komischerweise wurde mir das schon vor 20 Jahren immer wieder von irgendwelchen Leute prophezeit.

Seitdem ist das Angebot für den SX-Datenbus unglaublich gewachsen und war wohl noch nie so groß, wie heute. Ich betreibe damit eine Großanlage mit über 100 Weichen, einer Vielzahl von komplexen, mehrbegriffigen Signalen und über 100 Blockstrecken.

Gesteuert wird mit modernen Funkhandreglern über Bluetooth, die über Tasten- und Drehreglersteuerung verfügen.

Viele Grüße,
Mathias

Hallo -AH-,

es ist schon unterhaltsam, wie die dcc-Propheten ihre Scheuklappen einstellen, weil nicht sein kann, was nicht sein darf. Du redest von Uralthardware?

Anders herum wird ein Schuh draus: mit der neuen FCC kann man RailCom nutzen! Und mit den neuen Besetztmeldern ebenso. Und es ist alles abwärtskompatibel. Klar, dass alte Module kein RC können, aber die neuen können es.

Also: dcc, fahren, sx2 fahren und SX1 fahren, schalten über SX-Bus und RailCom nutzen - was sagst du jetzt?

Jens

Tut mir leid wenn ich da auf dem Thema drauf bleibe das ist leider wirklich verblendet falsch! Beide sind um Größenordnungen zu langsam!

Wenn man bei DCC 80 Kommandos pro Sekunde annimmt, eher sind das sogar mehr. Dann entstehen mit RC 5 netto Bytes Daten die durch die Decoder weggesendet werden. Mit Overhead (Framing udglm) sind das um einfach rechnen zu können 10 Bytes also 100 x 80 Bits die ständig am Bus Datenverkehr erzeugen. Wie soll das neben den ohnehin schon zu schmalen Bandbreiten in den alten Bussen transportiert werden? Wenn man gute "local detectoren" hat kommt durch jede weitere Lok auf der Anlage nochmals etwa 40 Bits Daten hinzu die muß man mal transportieren können!!! Diese Datenmengen fallen JEDE SEKUNDE neuerlich an. Das ist das was an RailCom Daten auf der Anlage weggesendet wird! Da sind noch keine Fahrpulte, Besetztmelder, Weichen oder was auch immer berücksichtigt. Deren Daten sollen ja auch noch transportiert werden.

Vor 20 Jahren waren die Möglichkeiten mit den langsamen Bussen schon belächelt. Damals schon wurden höhere Funktionen als nicht nötig bezeichnet um die mangelnde Bandbreite wegzudiskutieren. Heutzutage ist das noch viel schlimmer! Wobei man leicht voraussehen kann daß noch mehr als Infos transportiert werden müssen.

Selbstverständlich kann man MoBa mit den alten Sachen machen, die vielen Anlagen beweisen das. Dann gibt's aber keine Lokanmeldung, keine Tacho, keine Statusmeldungen, keine Zugnummern und noch vieles andere.
-AH-

Hallo,

der SX-Bus ist vielleicht nicht mehr der neueste aber immerhin ein "Standard" in der SX-Welt, bei DCC gibt es ein Mix aus diversen-Bussystemen diverser Hersteller und es ist keinerlei Verständigung auf ein System in Sicht (daher muss ich immer schmunzeln wenn davon gesprochen wird das DCC der Standard sein soll). Daher gibt es auch Firmen die innovative SX-Produkte nicht für DCC weiter entwickeln da es eben auch nach 25 Jahren bei DCC noch immer keinen Standardbus gibt:

https://www.1zu160.net/scripte/forum/forum_show...e%20digital#x1224960

Ich bin froh nicht mit DCC Schalten und Melden zu müssen da man sich hier auf ein Anbieter (bzw. auf ein Bus) festlegen muss. Wenn dann der Anbieter dann irgendwann nicht mehr existiert dann steht man da. Das Schalten und Melden war damals (Mitte der neunziger Jahre) ein Grund warum ich mit SX begonnen haben da Schalten und Melden schon damals ein ungeliebtes Kind in der DCC-Welt war. Bei SX kann ich seit 1997 Bus-Teilnehmer kaufen und verbauen. Und mit SX kann ich eine raumfüllende Anlage in Spur N steuern. Wenn jemand mein er benötigt dazu unbedingt den neusten DCC-Bus weil SX nicht zukunftsorientiert wäre dann kann ich da ebenfalls nur schmunzeln. Vielleicht liegt es auch daran dass sowas ausgerechnet ein Händler schreibt der nur DCC-Artilkel im Sortiment hat

Es gibt übrigens auch Märklin-Bahner die mit SX ihre Anlagen schalten und melden und nur noch mit Märklin fahren. Rautenhaus bietet hierfür auch SX Wechselstrom-Gleisbelegtmelder an.

Grüße
Markus

Hallo Arnold

Das DCC Gleissignal wird nicht dem eigentlichen Loconet hinzugefügt. Dazu gibt es im Loconetkabel die Railsync Leiter die genau das DCC Signal verbreiten.

Loconet generiert Events. Wenn die Lok 1234 in den Abschnitt 4711 einfährt gibt es genau ein Event.  Natürlich gibt es mehr Daten zwischen Decoder und Localdetector aber dies belasted Loconet nicht. Und sonst teilt man es einfach auf. Ist immer noch günstiger als andere Lösungen.

Wäre wirklich schön wenn es ein einheitlichen Bus für DCC gäbe. Ich dachte mal openLCB jetzt LCC wird es aber mittlerweile denke ich dass das nichts wird.
Auch Bidib ist eine technische Tolle Lösung. Lange Zeit gab es nur Bausätze von Fichtelbahn, jetzt endlich auch Komponenten von Tams.
Und statt sich beim CAN zu einigen, gibt es schon einen ganzen Zoo an CAN Bussen für die Moba. Dadurch gibt es kleine Stückzahlen und hohe Preise aber jeder Hersteller meint dich mit dem eigenen Bus vor der Konkurrenz zu schützen.
Und so setze ich lieber auf eine weit verbreitete Lösung, bei der ich auch noch in zehn Jahren Komponenten bekomme.

Viele Grüsse Matthias

Hi Matthias!

Ja klar ich weiß wie LocoNet funktioniert aber mit den 16kBaud kann man auch kein RailCom machen in dem Sinne wie's konzipiert ist. Mein zuvor gepostetes Beispiel würde den Bus mehr als die Hälfte beriets befüllen nur mit den Rückmeldedaten. Selbstverständlich kann man 95% der Daten wegschmeißen um einen winzigen Bruchteil der Funktionalität dann doch irgendwie zu melden. Was hat man: nur Besetztmeldung und Decoder Adresse und das nur sehr selten. Daher ist ja auch das große Unverständnis rund um moderne Systeme.

Klassisches Beispiel mit der RC Daten Filterei bei LocoNet. Lok fährt in den Abschnitt, Besetztmelder schickt die Nachricht mit der Decoder Adresse. Wenn 2. Decoder rein kommt oder wenn die Lok getauscht wird sendet er nicht mehr weil sich ja die Besetzmeldung nicht geändert hat. Auch das Problem kann man erkennen und reagieren, dann gibts weiteren Ärger damit am Schluß gelangt man zum Konzept viel zu senden und das kann der langsame Bus nicht.

Einen einheitlichen Systembus wird es nicht geben in absehbarer Zeit sonst bleibt man bei den Primitivmechanismen wie man es derzeit hat. Weil man sich bei einer Einigung auf den kleinsten gemeinsamen Nenner einigt. Vielen reicht es aus, sie haben Freude mit der Modellbahn und das ist schön. Ich will da keinen davon abbringen. Ja ich weiß wir hätten das alle gerne anders möglichst alles zusammenstoppeln zu können. Die 4 derzeit benutzen CAN Bus Protokolle, da kann der CAN Bus nichts dafür sondern die Hersteller haben mit voller Absicht die Definition der Busse nicht veröffentlicht, bzw Dinge eingebaut die für andere die Definition unbrauchbar gemacht haben. Voll dokumentiert ist einzig die 2. Protokolldefinition von ZIMO. Aber auch diese ist keine public Norm sondern unter der "Hoheit" von ZIMO.

Es gibt so grundsätzliche Fragen beim Design eines Anlagenkonzepts wie: Meldet ein Gerät autark wenn es neue Info hat, oder muß es von einer Zentrale ständig abgefragt werden. Simple konzeptionelle Unterschiede aber führt zu extrem unterschiedlichen Strukturen.

Anderes Grundsatzbeispiel sind Adressräume. Früher hat man angenommen ein Bus mit 32 Teilnehmern ist großzügig konzipiert. Ich betreue Modellbahnanlagen da gibts 100 Fahrpulte die herumliegen, zusätzlich noch einiges an Computer, die benutzen alle eben auch diesen Adressraum für ein Fahrpult.

Die von mir geschätzte Firma ZIMO hat ein Konzept bei den MX9 für 1000 Abschnitte, dann ist der Adressraum aus. Eine Anlage die ich betreue hat etwa 9000 Abschnitte, daran hat vor 40 Jahren niemand gedacht daß man so große Modellbahnanlagen bauen wird. Daher ist es so immens wichtig die Konzepte offen zu lassen, viel Reserven einzubauen, man soll nicht Grenzen einbauen die man absehbar schnell erreicht. Die alten Bussysteme fahren mit 9600-16.000Baud. Das ist etwa die Modemgeschwindigkeit die man Mitte der 1980'er Jahre hatte. Das nur zur Bedeutung wie grottenlangsam das ist und das wird mit Zähnen und Klauen als innovativ und gut verteidigt. Die Schnelleren Systeme sind auch nur Faktor 10-100 schneller so viiiiiiel mehr ist das ja auch nicht aber immerhin deutlich schneller.
-AH-

Ich kann gerade nicht folgen. Das ganze hängt doch von der Zahl der Meldeabschnitte ab und wie diese dynamisch ihren Zustand ändern. Bei einer Moba, bei der nur ein Zug fährt, wird ja nur alle paar Sekunden ein neuer Abschnitt als Belegt gemeldet und ein anderer wieder frei. Kannst Du uns mal kurz auf die Grundlagen Deiner Berechnung bringen? Ich hab den Anschluß verloren.

Nehmen wir den völlig übertriebenen Fall an, 50 Züge Fahren mit 200km/h und die Abschnitte sind alle nur so lang wie eine Weiche ( 10cm ), dann komm ich auf 170 Meldungen pro Sekunde. Nun kommts drauf an, wieviel Byte so eine Meldung auf einem Bus erzeugt. Bei 3 Byte Adresse und 1 Byte Meldung 4 Byte.

Sind dann rund 700 Byte pro Sekunde und damit weit weg von 16kBaud.

Aber vielleicht bin ich schlicht auf dem falschen Dampfer!

Danke

Hallo Arnold

Deine extremen Beispiele und nicht das, was der durchschnittliche Modellbahner so macht. Bei dieser Grösse sind dann auch mehrere Steuer PCs nötig und auch bei CAN oder  Bidib mehrere Busse.
Bei dem was Zimo für die Zentrale und den Stein abruft kann ich ganz viel Loconet oder SX Hardware kaufen, da liegt dann auch das eine oder andere zusätzliche Interface drin.

Viele Grüsse
Matthias

Na ja, will man über eine zukunftssichere Hardware diskutieren, kommt man nicht umhin sich Grenzfälle zu erdenken. Bei verteilter Logik braucht es auch nicht gleich mehrere PCs. Will man z.B. richtige Stellwerkslogik bauen, dann muß man die Daten zumindest in der richtigen Reihenfolge auswerten, um z.B. die automatische Auflösung von Fahrstraßenabschnitten vorbildgerecht zu machen. Da reicht es nicht schnell zu sein.

Ohnehin konnte ich den Werten von Arnold noch nicht folgen, siehe Frage oben.

Verteilt man Logik, hat man auch mehrere Sender, die sich einen Bus teilen müssen, ggf. mit zusätzlichem Verwaltungsaufwand, der dann auch Bandbreite futtert.

Gruß
Klaus

Hallo Arnold,
das ist übrigens ein Punkt, den ich auch am LocoNet sehr kritisiere. Öffentlich verfügbar ist einzig die LocoNet PE in Version 1.0 und eine Ergänzung für die SV Programmierung. Ohne Lizenz darfst Du nichts öffentlich anbieten. Ich laufe DiGiTrax schon seit Jahren hinterher, allerdings haben die keine Lust mit mir zu reden.

Für meine FREDI-Implementation kann mir das noch egal sein, da der Verein einen speziellen Deal mit DiGiTrax hat und daher das Problem dafür irrelevant ist. Für andere Basteleien ist die fehlende Lizenz aber der Todesstoß.

Und nach allem, was ich bisher gehört habe, bekommen selbst Lizenznehmer keine vollumfängliche Dokumentation...

Gruß,
Torsten

Hi

Unterm Strich, kann man eine 10m lange Anlage, mit bis zu 20 Zügen, 100 Weichen, 200 Meldeabschnitte und 25 (Ausfahrt)signale mit einem Twincenter und LDT s88N vernünftig steuern?

LG ChristiaN

Ja keine Frage! Wenn man die modernen Mechanismen wie RailCom nutzen will ist S88 hinderlich.

Der UP dieses Threads wollte aber Bussysteme diskutieren.

Zu den Postings zuvor wegen der großen Mengen die ich präsentiert habe, fürchte ich habe Euch verwirrt. Das soll nur zeigen daß man vieles beim Design berücksichtigen muß.
-AH-

In der Tat. Ich würde mich freuen wenn Du Deiner Betrachtung einfach nochmal Deine Ausgangsdaten zufügst, so daß ich ungefähr nachvollziehen kann, wie Du auf Deine Werte kommst. Bisher kann ich die nicht nachvollziehen. Sorry!

Danke
Klaus

Hi Arnold

Danke dir!

Und Ihr, AH und andere Experts, solltet auch unbedingt weiter alle Möglichkeiten Ausdiskutieren, das ist früher oder später sehr wichtig für uns alle, aber vergisst auch nicht #19 Helmut, der längst schreiend das Hobby aufgab und davon lief!!

LG ChristiaN

Hallo zusammen,

ich habe zu den BUS System auch einige Fragen und vielleicht kann man mir diese mit beantworten.

1. Gibt es bei den modernen BUS Systemen immer noch das Thema des Übersprechens bei paralleler Verlegung der Rückmeldelitzen?

2. Muss ich bei den modernen BUS Systemen weiterhin die Litzen verdrillen, um Störungen auszuschließen?

3. Welche Funktionen benötigt man bei RailCom wirklich, wenn man die Anlage sowieso über eine Software am PC steuert?

4. Wieviele Hersteller bieten für den gleichen modernen BUS auch Komponenten an (um ggf. auf einen anderen Hersteller ausweichen zu können)?

Danke und Grüße
Christian

Hallo zusammen,
ich denke, die Diskussion geht an den Bedürfnissen und Erfordernissen von 99% der "normalen" Modellbahner vollständig vorbei.

Meine Anlage ist schon sehr groß, hat viele Lokomotiven, Steuerwagen, Weichen, Signale, Rückmelder und ich nutze trotzdem wohl nicht 5% der Möglichkeiten des SX-Datenbus.

Die SX1-Loknummernrückmeldung ist ein nettes Gimmick aber in der Praxis eher nebensächlich, weil ich ein PC Stellwerk nutze.

Viele Grüße,
Mathias

Hallo Arnold,

schade, dass du beim Lesen nicht mal die Scheuklappen abnehmen kannst. Deine technische Beschreibung und die Extrembeispiele kann ich nachvollziehen. Ebenso kann ich nachvollziehen und zustimmen, dass den Daten auf dem SX-Bus nur sehr begrenzt Informationen hinzugefügt werden können.

Wie es technisch gelöst wird, kann ich Dir momentan nicht sagen. Ich kann aber meine Phantasie mal spielen lassen. Dazu bemühe ich mal die Telekom. Wieviel MBit jagen die heute maximal durch zwei Drähte? Hat man das vor 35 Jahren für möglich gehalten? Um mal Deine stoisch Haltung zu bemühen, würdest du vermutlich heute noch behaupten, DSL sei ein sterbendes System. Bis zur Abschaltung der analogen Leitungen und der ISDN-Übertragung hat alles wunderbar miteinander funktioniert. Meinst du nicht, dass man solch bekannten Ideen nicht auch bei der Moba sinnvoll anwenden könnte?
Der SX-Bus bleibt wie er ist und trotzdem werden wesentlich mehr Daten drüber geschickt. Aber nochmal: Es kann offensichtlich nicht sein, was nach Deiner Meinung nicht sein darf.

Im übrigen ist dcc auch eine uralte Geschichte, die auf den Markt kam, als sie noch nicht zu ende gedacht war. Ich frage mich immer wieder, wieso sich jemand mit so einem verkorksten Gleisprotokoll wie dcc herumschlagen soll, nur um hier nach einem brauchbaren Bussystem zu fragen. Bei SX - so blöd du es auch finden magst - gab es dieses Problem von Anfang an nicht - bis heute. Aber es ist ja ein sterbendes System....

Jens

Das kann schon  die bisherige FCC mit den neuen railcom-fähigen Rückmelder sein 2019.
Würde trotzdem nicht mit SX neu anfangen.

Übrigens belegt der neue Rückmelder für die Railcom-Daten eine zusätzliche Adresse. Diese Daten müssen dann interpretiert werden.


Danke, das kenne ich bereits. Mir fehlt die Info zu meiner Frage.
Da ist bisher noch nichts gekommen.

Grüße
Stephan

Hallo Arnold,

Womit begründest Du diese Aussage bzgl. BiDiB.

Grüße
Stephan

Ja, ist  physikalisch bedingt, je höher die Datenrate, desto besser muss die Abschirmung sein.


Railcom ist ein Bonus, ein Upgrade an Möglichkeiten. Wer das will soll es machen, wer meint darauf verzichten zu können, soll verzichten.


- Märklin und CanDigitalBahn (Zentrale für Loks nur von Märklin), ein paar Selbstbaukomponenten (Stummi-Forum, Canguru)
- Zimo und Roco. Welche Funktionen gegenseitig genutzt werden können kann ich Dir nicht sagen.
- BiDiB: Fichtelbahn, Tams

Wenn was fehlt bitte ergänzen.

Grüße
Stephan

Falscher Vergleich. Die unterschiedlichen DSL-Varianten haben außer dem Teil 'DSL' im Namen nichts gemeinsam. Das ist wie SX und SX2 und dann weiter SX3 ....


Es werden nicht mehr Daten übertragen, sondern immer wieder die gleichen

Grüße
Stephan

Hello Jens!
Mein Anliegen ist bei Neuprojekten nicht Technik von Übervorgestern zu verwenden. Die Anlagen sollen doch nach Möglichkeit Jahrzehnte benutzbar bleiben.

DCC war simpel als man es genormt hat. Das Wesentliche im Gegensatz zu ZIMO Datenformat, FMZ, MM, SX oder all den anderen war daß man die Erfahrung der damals vergangenen Jahrzehnte genutzt hat und das so gemacht hat daß man ausbauen und erweitern konnte. Das ist dann auch sehr oft passiert. Leider ist es dadurch mehr und mehr kompliziert geworden. Die Alternative es am Niveau der Entwicklungszeit zu halten meine ich ist ein falscher Weg. Das ist es was ich an SX nicht gut finde, es hat im Design keine Erweiterungsmöglichkeit. Klar ist es ausgebaut worden, nur wo ist man da hingelangt im Vergleich zu DCC. Selbiges gilt für Bussysteme. Egal welcher nur nicht so simpel daß es morgen schon zu klein ist. Das ist der Gedanke.
-AH-

Hallo Arnold,

dein Anliegen in allen Ehren, aber dann dürftest du genau genommen auch keines der anderen Systeme empfehlen! Denn egal, wo man hinschaut: das Bedienkonzept ist finsterste Steinzeit und zwar bei ALLEN Systemen!

Lokadressen vergeben und merken, wenn man Fahren will, Adresse eingeben. Hat man eine Lok, die mehr kann, sei es Sound oder Kupplungssteuerung, muss man wissen, welcher Sound hinter welcher Funktion liegt. Das müsste ALLES situationsbezogen automatisch gehen. Lok aufs Gleis und sie erscheint in einer Auswahlliste am Regler.Ich entscheide nur noch, ob ich selbst fahren will oder ob das System sie automatisch fahren soll, ob mit Licht oder ohne und ob mit Lärm oder ohne. DAS wäre zeitgemäß. Statt dessen gibt es zwei URALT-Systeme bei denen gegenseitig behauptet wird, dass sie zu alt sind.

Egal, wie du es drehst und wendest: Anwender von SX-Systemen haben immer einen stabilen, funktionierenden Bus dabei und können JEDE Lok fahren. Bei dcc kommt - wie in diesem Faden - immer irgendwann die Frage auf, welchen Bus soll man nehmen, und da gibt es einige! Und gefahren werden kann nur dcc. Ganz ehrlich: Wo ist der Fortschritt da? Mit RailCom rückt das oben beschriebene Bedienkonzept in greifbare Nähe. Und mit vernünftigen Bedienkonzepten spielt es keine Rolle, was für eine Technik unten drunter ist, solange sie zuverlässig funktioniert. Und unter diesem Aspekt macht ein vielseitiges System ebenfalls Sinn.

Aber mach weiter auf ‚edler Ritter‘ für eine ‚moderne‘ Modellbahnsteuerung. So werden die Fäden wenigstens unterhaltsam.

Jens

MFX und Railcom+ ist bekannt?
Möglich, dass sich diese Funktionalität mit DCCA bald im DCC-Bereich weiter verbreitet.

Mich wundert Deine Diskussionsführung.
Du stellst Behauptungen auf. Wenn man sie Dir wiederlegt oder konkret nachfragt, dann gibt es keine Reaktion.
Du stellst Vergleiche an, die nicht haltbar sind, da anscheinend das Wissen dazu fehlt. Reaktion keine.
Offensichtlich gibt es auch noch einige Informationslücken.
Du unterstellst anderen Scheuklappen, ließt aber nicht was geschrieben wird, sondern interpetierst.
Und ganz zum Schluss wird es persönlich.
Ich bin auch nicht immer der Meinung von Arnold, aber er bleibt immer sachlich.

Ich bin der Meinung, Du solltest an Deiner Diskussionskultur arbeiten.

Grüße
Stephan

Hallo Stefan,

kurze Frage: was soll DCCA sein? Das sagt mir (und Google) nichts.

Klaus

Glaskugel: Wegen der Verbreitung wird als Applikationsprotokoll weiter LocoNet verwendet werden. Aber nicht auf 16kBaud sondern neu verpackt. IP gibts ja schon.

Grüße,
Harald.

Hallo Miteinander,

wenn ich das so lese, finde ich es traurig wie es in der MoBa-Welt zugeht. Jeder (oder zumindest viele) pochen auf das System das sie verwenden (sowohl Hersteller, Händler als auch Modellbahner). So viele verschiedene Busse, die nicht miteinander reden können für einen im Vergleich z.B. zur IT-Branche mit recht kleinem Markt.

Ist die Forderung etwas "modernes", was mit dem Stand der Technik Schritt hält und auf jahrzehnte zukunftsfähig ist, nicht ein Widerspruch in sich ? Zumindest im IT-Bereich ? Ist da nicht etwas was heute "modern" ist in 10 oder 20 Jahre "Steinzeit" ? Muss ich da nicht die Entscheidung treffen: Entweder immer dem Stand der Technik folgen und alle vielleicht 10 Jahre meine Digitalkompomenten ersetzen oder einmal eine Entscheidung treffen und dieser bis zum Ende treu bleiben ?

Als ich vor etwa 25 Jahren mit der Computerei anfing war der parallele und der serielle RS 232 "Bus" häufig anzutreffen. Beides ist inzwischen nahezu ausgstorben. Dann kamen (u.a. ?) der USB-Bus oder LAN oder WiFi dazu. Trotz des riesigen IT-Marktes kann ich ein USB-Gerät an jeden USB-Bus anschließen (oder täusche ich mich da ?) - allenfalls beachten musss ich welcher Stecker (USB A, B, Mini, ...) - obwohl, da gibt es auch schon wieder USB 1.0, 1.1, 2.0, 3.0 und bald ? Das einzige (?) was ich bei jedem neuen Gerät brauche, ist der passende Treiber.

Aber in der IT-Brache haben sich die Firmen doch immer wieder auf ein Bussystem einigen bzw. normen können oder es hat sich zumindest ein Standard durchgesetzt. Warum muss in der Modellbahn (fast) jeder Hersteller sein eigenes Süppchen kochen ???????????

Fragt, verwundert oder manchmal ärgert sich
mit vielen Grüße Joni

PS: Beim Beispiel USB: Ich kann immerhin ein 3.0 Gerät an einen 2.0 Bus anschließen und umgekehrt - dann halt jeweils zu 2.0 Bedingungen.

Hallo Miteinander,

ein Nachtrag:

Machen wir es nicht z.T. genau so wie die Hersteller ? "Jeder" (oder zumindest viele) pochen auf "ihr" System, "ihren" Bus und lassen mitunter andere Standpunkte und Meinungen nicht oder nur ungern stehen.

Ich will es positiv sehen: Aus der bisherigen Diskussion habe ich viel gelernt. Es kamen viele Pros und Contras zu den einzelnen Systemen und Busse. Über manchen Tonfall lese ich einfach hinweg. Herzlichen Dank für die Informationen die ich erhalten habe !!! Aus den vielen verschiedenen und z.T. widersprüchlichen Meinungen lese ich heraus: Den einen (!) "idealen" Bus gibt es nicht (oder vielleicht noch nicht ???) Kann es einen "idealen" Bus überhaupt geben ? Meine unten stehenden Wünsche halte ich z.T. für widersprüchlich bzw. gegenseitig ausschließend. Für mich heißt das: Ich sehe keinen Grund "meinen" Bus zu wechseln. Und wenn ich einen Neueinsteigen beraten sollte, wüsste ich nicht was ich empfehlen soll.

Nochmals herzlichen Dank für Eure Infos.

Viele Grüße, Joni

PS: Unter "ideal" würde ich z.B. verstehen: Gute technische Eigenschaften, ausgereift, bewährt, zukunftsicher, langlebig, von vielen unterstützt, akzeptable Kosten, einfach anwendbar, ... . (Reihenfolge zufällig, ohne Gewichtung).

PS: Beim Beispiel USB: Ich kann immerhin ein 3.0 Gerät an einen 2.0 Bus anschließen und umgekehrt - dann halt jeweils zu 2.0 Bedingungen.

PPS: Meine persönliche Meinung: Es könnte viel helfen, wenn wir alle (Anwender, Händler, Hersteller) nicht uns gegenseitig als Hauptkonkurrenten sehen würden (oder Spur N gegen H0, ...), sondern wenn Konkurrenten, dann andere Hobbys wie PC-Spiele, Motorräder, ... .

@Joni

Das ist die Problematik der versunken Kosten. Jeder Hersteller hat viel Geld und Zeit in seine Produkte investiert. Deshalb investiert er jetzt noch mehr um das ganze am Leben zu erhalten.
Bei den Anwendern ist es ähnlich.
Das Resultat ist ein zerstückelter Markt mit sehr kleinen Stückzahlen. Was das Hobby teuer macht und Leute davon abhält.

Gruss Matthias

Hallo zusammen,
ich denke halt, dass ein zukünftiger Schritt "gut genug" sein muss, um die von Arnold angesprochenen Daten zu transportieren. So eine technische Iteration passiert ja nur alle paar Jahrzehnte, wenn überhaupt noch einmal. Vielleicht genügt BidiB dafür.

Usability sehe ich genauso als Thema. Das ist jedoch im Bereich Fahrzeuge und Komponenten mit Railcom+ und Co. auch adressierbar.

Man kann noch lamentieren, dass  frühere Systeme / Busse die Rückmeldung meist nicht berücksichtigt haben, aber das ist doch eine Sicht in die Vergangenheit, die nichts bringt. Da war man mit Sx sicherlich weitsichtiger, das ist jedoch kein Argument, den alten Gaul immer noch als Zukunftsmodell verkaufen zu wollen.

Wie langsam alles tickt, sieht man auch an den "Railcom-Verweigerern" und den immer noch "Digital-Verweigerern" (50%?). Es ist also wirtschaftlich nicht gerade hoch verlockend, hier tollste Dinge zu entwickeln.

Kurzum: Die Evolution wird weiter langsam verlaufen. Ich denke, dass die richtigen Entwicklungen bereits unterwegs sind.

VG Michael

Hallo Michael,
dahinter steht das Thema, dass unser Hobby eben "Modellbahn" und nicht "Digitaltechnik" heißt. Die große Zahl an Analogbahnern dürfte u.a. darin begründet sein, dass es bestehende, funktionierende Anlagen und analoges Know-How gibt, während man keine Lust hat, sich mit dem ganzen digitalen Krams zu beschäftigen.

Ich habe früher eine Selectrix Lok in 3 Minuten programmiert; heute dauert das Auslesen der 150 SX-Parameter schon 3 Minuten.... Ich habe mich da mittlerweile durch viel Lesen und sammeln von Erfahrung reingefuchst und behaupte, dass viele andere dazu einfach keine Lust haben, weil sie eben "Modellbahner" sind.

Die Selectrix Loknummernerkennung ist ein Protokoll zur Fahrzeugerkennung im Rahmen der Gleisbesetztmeldung. Railcom dürfte etwas ähnliches sein.

Aber: benötigen viele Modellbahner das überhaupt? Bei kleinen Anlagen oder über den Computer gesteuerten Anlagen eher uninteressant.

Ich fürchte, dass locker 90% der Modellbahner nicht ansatzweise die heute schon gegebenen Möglichkeiten der Digitaltechnik nutzen, weil die Nutzung wenig intuitiv ist und oftmals den Anwender schlichtweg auch nicht interessieren.

Viele Grüße,
Mathias

Schönen Tag,

mein wohl etwas praxisferner Wunschtraum:

Entwicklung von digitaler Moba-Technik auf möglichst internationaler Open-Source-Ebene. Wie z. B. BidiB. Wobei ich weitere Opensource Projekte nicht kenne und somit auch nicht weiß, wie ähnlich/entfernt die mit/von einander sind,.

Ihre Brötchen sollen sich die Hersteller dann mit kompatiblen Zentralen, Decodern, Komponenten und Steuerungssoftware machen, die dann je Hersteller eine längere Zeit kompatibel mit den bisherigen Produkten der Hersteller sind.   -    Nur so können ausreichend viele User in adäquater Zeit zum Umstieg bzw. Zustieg bewogen werden.

Noch so eine naive Idee:

Können Gleisplansoftware und Steuerungssoftware nicht zusammenwachsen?

Es sollte IMHO technisch machbar sein, einen bestehenden Gleisplan automatisiert in eine komprimierte Übersicht zu verwandeln, wie man sie von Steuerungssoftware kennt bzw. sollten naheliegende Trennungen, Schaltungen, Kehrschleifen etc. auf Basis eines Userprofils gleich softwareseitig vorgeschlagen werden. Oder gibt es das schon?

VG Andreas
Andreas

Hallo Mathias,
Arnold hatte Railcom weiter oben gut beschrieben, es geht weit über Nummern- und Richtungserkennung hinaus.
Was Du schreibst sehe ich absolut ähnlich, gerade nach "Kunstpausen"😉 muss ich mich jedesmal erneut reindenken, obwohl die Steuerung nur "Beiwerk" ist.

VG Michael

Diesen Gedanken habe ich vor 2 Jahrzehnten bei Nokia kennengelernt - hamma ned / brauch' ma ned, und die Deppen die das trotzdem machen werden aus der Firma entfernt. Was macht Nokia heutzutage im Consumerbereich?
-AH-

"Ja...aber" - der Schlüssel war die Bedienbarkeit, ein Tsunami, der bis in Industriemaschinen wirkt.
Sonst wird sich keiner außer den Nerds den Möglichkeiten annehmen (können).
VG Michael

Ich würde die Moba eher mit Industrieautomation als mit Desktop Consumer Anwendung vergleichen. Und da haben wir auch noch Modbus (*) RS485 in Betrieb und dazugekommen ist Modbus TCP/IP. Und http(s) und und und.

Bedienbarkeit ist superwichtig und auch nicht leicht weil hier sollen ja nicht nur ausgebildete Fachkräfte (wie Industrieautomation) sondern auch alle anderen die Möglichkeit haben mitzuspielen. Bedienbarkeit ist nicht auf die leichte Schulter zu nehmen. Vergleiche ein Googleprodukt mit dem Produkt der Konkurrenz.

Grüße,
Harald.

(*) Nur ein Beispiel von 17 oder so Standards.

Wir sind doch inzwischen bei so gut wie jedem technischen Gerät auf einem Stand, dass die meisten Anwender irgendwo zwischen 10 und 90% der angeboten Funktionen gar nicht nutzen/brauchen.
Früher (war alles besser) habe ich mich mit jedem Gerät, z.B. einem Autoradio, so lang befasst, bis ich alle Funktionen beherrscht habe. Das war machbar. Aber wehe, eine Funktion klappte nicht so, wie man es sich dachte.
Heute habe ich Menüpunkte im Autoradio, die ich noch nie gesehen, oder auch nur von gehört hätte.
Selbst unsere Küchenmaschine kann Sachen, die wir noch nie abgerufen haben.
Wenn nun jemand kommt und sagt, das Radio oder der Mixer ist veraltet und er würde davon abraten, weil er dies und das nicht kann ...
Wen störts ausser ein paar Nerds, die sonst im Leben keine Freu(n)de haben

Jürgen H.

Hallo ste111,



Ah ja, das spielt in unserem Maßstab jetzt DIE Rolle. Aber gut, dass du fragst: Ja, die sind bekannt. RailCom und auch die Lenz-Weiterentwicklung sind beides Systeme mit Potential. Seit ich vor über 20 Jahren davon gehört habe, wird immer nur davon gesprochen. Standardmäßig eingesetzt wird es nirgendwo. Der Modellbahner KANN es einsetzen, wenn er will und die - entsprechend - teureren Komponenten kaufen. Ein System, dass einfach von Hause aus die Möglichkeiten nutzt existiert bis heute nicht. MFX wiederum ist nach meinem wissen nicht in N verbreitet, obwohl mich das ein wenig wundert.

Was das Thema Diskusionskultur betrifft, so gibt es da wohl sicher verschiedene Sichtweisen. Wo Arnold objektiv ist, wenn er bei SX von einem ‚sterbenden System‘ spricht und dabei jegliche Weiterentwicklung ausblendet, erschließt sich mir nicht. Es ist SEINE Meinung, daran ist nichts objektives.

Jeder soll nehmen, was ihn glücklich macht, ob nun dcc oder SX. Dcc ist ein Fahr- und Schaltprotokoll, mehr nicht. SX ist darüber hinaus ein vollwertiges Meldesystem und das war es von Anfang an. Klar ist der Anspruch an die übertragenen Daten heute ein Vielfaches höher. Bei der Vielfalt an verschiedenen Bussystemen genügt die Mehrheit heutigen Ansprüchen nicht mehr. Punkt. Auch der SX-Bus kann das nicht leisten. Und jetzt kommt‘s: Es wird jedoch daran entwickelt, sogar bei dem verteufelten SX (aber das darf scheinbar nicht sein). Über die Berechtigung eines ‘althergebrachten‘ Systemes mag jeder selbst entscheiden, wenn er mal seine älteste Lok in die Hand nimmt....

Objektiv darf kein System als ‚sterbend‘ deklariert werden. Und wie ich bereits sagte: mit einer entsprechenden Benutzeroberfläche würden wir nicht mehr über Protokolle, Bussysteme und was weiß ich sprechen, weil es egal ist, solange es das macht, was es soll.

Ich habe ein SX-System im Einsatz und es funktioniert hervorragend. Ich wehre mich jedoch dagegen, dass sich ein selbsternannter dcc-Pabst anmaßt, das alleinige Wissen darüber zu haben, was Menschen kaufen dürfen und was nicht. Wenn SX so schlecht wäre, wie immer wieder behauptet, gäbe es SX schon lange nicht mehr! Das Gegenteil scheint eher der Fall zu sein.

Punkt.

Jens

Modbus ist ein gutes Beispiel.
Modbus hatte einen zweiten Frühling. Nicht weil das Protokoll so viel besser ist als z.B.: Profibus/Profinet sondern weil es vom Hersteller zur freien Verfügung freigegeben wurde. Und so kam es dass fast alle SPS und alle möglichen Geräte Modbus verstehen, weil es verbreitet ist und nichts kostet. Und in den allermeisten Fällen ist Modbus völlig genügend.
Und mit Modbus TCP ist auch der Übertragungsweg egal. Ob Kupfer, Glasfaser, Funk VPN Tunnel alles geht und muss vom SPS Programmierer nicht beachtet werden.
Für SX und Loconet gibt es schon Projekte für eine IP Kommunikation. Es ist doch überhaupt kein Problem alle Informationen des SX Bus in ein IP Telegramm zu packen und 13 mal die Sekunde zu verschicken. Da langweilt sich jedes Netzwerk. Ein einfacher Webserver auf dem Netzwerkknoten und ich kann komfortabel alle Daten des alten SX auf SX/IP zuweisen.

Wenn man Komfort will nimmt man die Produkte von Märklin/Trix mfx ist Bidirektional von Anfang an. Und von der Startpackung bis zur Grossanlage gibt es abgestufte Ausbaumöglichkeiten.

Die DCC Herren haben teilweise ein falsches Spiel betrieben. Einen Teil offengelegt um es als Standard durchzusetzen, einen andere Teil ohne Standardisierung nur in die eigenen Produkte eingebaut und bewusst Inkompatibilitäten geschaffen. Weder Bremsen mit Bremsdioden noch irgendwelches Railcom wurde vorgängig standardisiert. Die Folgedavon ist, dass es bis heute Decoder gibt, die damit nicht zurecht kommen. Vor allem US Loks können es nicht aber auch einige Kato Modelle nach europäischen Vorbild.

Und wenn ich meine Loks nochmals öffnen sollte um einen neuen Decoder auszurüsten muss es definitiv was besseres sein als DCC mit irgendeiner aufgesetzten Railcom Version. Während die DCC Herren ihr Spiel betrieben haben, wurden mehrere tolle Steuerprogramme geschaffen die wunderbar ohne Railcom auskommen.

Gruss
Matthias

Faszinierend, das wieder einmal geschrieben wird, ohne wenigstens den Faden vorher zu lesen. Da sind die nun wieder hingeworfenen Punkte doch erklärt.
Wer lesen kann...

Interessant, dass Steuerungsprogramme somit die Qualität der Signalübertragung detektieren können und so vieles mehr. Ist doch Ersatz für Railcom, oder?

Und die hingeworfene Verallgemeinerung der Inkompatibilität von Railcom ist unfundierte Panikmache nahe am aktuellen "Qualitätsjournalismus".

Ich fand die Diskussion dennoch interessant und habe auch etwas gelernt. Danke dafür.

VG Michael

Hallo zusammen,

wollte hier eigentlich nichts schreiben.
Ups, jetzt habe ich es doch getan! 😀

Schönes Wochenende allen!
Daniel