Anzeige:
THEMA: Bussysteme/Steuerung die zweite
THEMA: Bussysteme/Steuerung die zweite
helmut_k - 09.04.21 18:43
Vielen Dank für die überaus vielen Beiträge zu meiner Frage.
Unterm Strich stellt sich für mich heraus, dass es auf eine bidirektionale Steuerung/Rückmeldung hinausläuft, also z.B. Railcom.
Ich möchte auch mit einer PC-Steuerung fahren. Mit mehr als 30 Zuggarnituren bin ich von Hand sicher überfordert. Hierzu liebäugle ich momentan mit dem TrainController, lese aber es gibt da wohl Probleme im Zusammenspiel mit Railcom.
Was tun? AlternativeLösung?
Viele grüße
Helmut
Link zu erstem Thread:
https://www.1zu160.net/scripte/forum/forum_show.php?id=1230778&start=1
Unterm Strich stellt sich für mich heraus, dass es auf eine bidirektionale Steuerung/Rückmeldung hinausläuft, also z.B. Railcom.
Ich möchte auch mit einer PC-Steuerung fahren. Mit mehr als 30 Zuggarnituren bin ich von Hand sicher überfordert. Hierzu liebäugle ich momentan mit dem TrainController, lese aber es gibt da wohl Probleme im Zusammenspiel mit Railcom.
Was tun? AlternativeLösung?
Viele grüße
Helmut
Link zu erstem Thread:
https://www.1zu160.net/scripte/forum/forum_show.php?id=1230778&start=1
Die Rückmeldung der Belegtabschnitte und der Weichen kannst du auch ohne Railcom haben.
Aber der Hersteller von Traincontroller sperrt sich gegen Railcom und auch den Bidib Bus.
Beides zusammen geht leider nicht. Ist dir Railcom wichtiger oder Traincontroller?
Es gibt es auch andere Steuerungsprogramme als Traincontroller. Rocrail unterstützt fast jeden Bus. Auch bei iTrain geht vieles. Beide unterstützen Bidib.
Ohne Ausprobieren wirst du nicht weiter kommen.
Ich würde nur Sachen kaufen die jetzt schon funktionieren. Zu hoffen dass irgendein Hersteller irgendwann etwas implementiert kann lange dauern.
Gruss Matthias
Aber der Hersteller von Traincontroller sperrt sich gegen Railcom und auch den Bidib Bus.
Beides zusammen geht leider nicht. Ist dir Railcom wichtiger oder Traincontroller?
Es gibt es auch andere Steuerungsprogramme als Traincontroller. Rocrail unterstützt fast jeden Bus. Auch bei iTrain geht vieles. Beide unterstützen Bidib.
Ohne Ausprobieren wirst du nicht weiter kommen.
Ich würde nur Sachen kaufen die jetzt schon funktionieren. Zu hoffen dass irgendein Hersteller irgendwann etwas implementiert kann lange dauern.
Gruss Matthias
Hallo,
unterstützen die dann auch Railcom-Funktionen?
fragt sich
Günter
Zitat - Antwort-Nr.: | Name:
Rocrail unterstützt fast jeden Bus. Auch bei iTrain geht vieles. Beide unterstützen Bidib.
unterstützen die dann auch Railcom-Funktionen?
fragt sich
Günter
kochender-Eisenbahne - 09.04.21 21:18
Moin Günter,
als begeisteter Anwender von BiDiB kann ich Dir sagen das sowohl ITrain wie auch Rocrail den BiDiB-Bus und damit Railcom hervorragend unterstützen. Dieses trifft auf alle Fälle aber auch auf Win-digipet zu.
Neben der Lokerkennung incl. Fahrtrichtung und auch der Analyse von dreckigen Gleisabschnitten begeistert mich immer wieder das der BiDiB Melder bis zu 4 Loks in einem Meldeabschnitt erkennt.
Mit ITrain kann man sogar bis zu 4 Loks automatisch in einem Meldeabschnitt automatisch parken. 3 Loks habe ich selber getestet weil ich es nicht glauben wollte.
Wozu ist das nützlich? Z.B. für automatischen Lokwechsel, Vorspann-Betrieb oder Mehrfachtraktion oder einfach nur auf Abstellgleisen oder BW´s bis zu 4 Loks pro Melder zu parken.
Dann ist das CV-Auslesen per POM auch noch eine feine Sache.
Gruß aus Hamburg
Thorsten
als begeisteter Anwender von BiDiB kann ich Dir sagen das sowohl ITrain wie auch Rocrail den BiDiB-Bus und damit Railcom hervorragend unterstützen. Dieses trifft auf alle Fälle aber auch auf Win-digipet zu.
Neben der Lokerkennung incl. Fahrtrichtung und auch der Analyse von dreckigen Gleisabschnitten begeistert mich immer wieder das der BiDiB Melder bis zu 4 Loks in einem Meldeabschnitt erkennt.
Mit ITrain kann man sogar bis zu 4 Loks automatisch in einem Meldeabschnitt automatisch parken. 3 Loks habe ich selber getestet weil ich es nicht glauben wollte.
Wozu ist das nützlich? Z.B. für automatischen Lokwechsel, Vorspann-Betrieb oder Mehrfachtraktion oder einfach nur auf Abstellgleisen oder BW´s bis zu 4 Loks pro Melder zu parken.
Dann ist das CV-Auslesen per POM auch noch eine feine Sache.
Gruß aus Hamburg
Thorsten
Hallo Thorsten,
wenn das Parken von 4 Lokomotiven in einem einzigen Meldeabschnitt so genau funktioniert (habe dazu an anderer Stelle von ca. 1 cm Genauigkeit gelesen), müsste ITrain doch auch, vorausgesetzt, es gibt genügend Sicherheitsabstand dazwischen, 4 Garnituren zugleich in einem Meldeabschnitt fahren lassen können?
VG Andreas
wenn das Parken von 4 Lokomotiven in einem einzigen Meldeabschnitt so genau funktioniert (habe dazu an anderer Stelle von ca. 1 cm Genauigkeit gelesen), müsste ITrain doch auch, vorausgesetzt, es gibt genügend Sicherheitsabstand dazwischen, 4 Garnituren zugleich in einem Meldeabschnitt fahren lassen können?
VG Andreas
Hallo,
@Thorsten #3:
danke für deine Erklärung/Hinweise! Das kannte ich so nicht und ist sicherlich für neue Einsteiger interessant.
Ich hatte bislang immer im Hinterkopf, dass die Railcom-Lücke bei manchen Decodern Probleme bereitet.
Für mich kommt ein Umstieg nicht in Frage, da ich bereits sehr viele Rückmelder (s88N) und TrainController(Gold) besitze.
Mit TC-Gold habe ich sehr gute Erfahrung bezüglich der Verfolgung der Loks/Züge gemacht.
4 Loks in einem Block zu parken habe ich (noch) nicht versucht, versuchen werde ich das irgendwann.
LG
Günter
@Thorsten #3:
danke für deine Erklärung/Hinweise! Das kannte ich so nicht und ist sicherlich für neue Einsteiger interessant.
Ich hatte bislang immer im Hinterkopf, dass die Railcom-Lücke bei manchen Decodern Probleme bereitet.
Für mich kommt ein Umstieg nicht in Frage, da ich bereits sehr viele Rückmelder (s88N) und TrainController(Gold) besitze.
Mit TC-Gold habe ich sehr gute Erfahrung bezüglich der Verfolgung der Loks/Züge gemacht.
4 Loks in einem Block zu parken habe ich (noch) nicht versucht, versuchen werde ich das irgendwann.
LG
Günter
Hallo Günter,
mehrere Loks / Züge in einem Block abstellen, soll auch mit TC gehen - allerdings nur wenn die Ausfahrt in die gleiche Richtung geht wie die Einfahrt, also kein Stumpfgleis (Handbuch Seite 276 - 279). Das habe ich aber noch nicht ausprobiert.
Viele Grüße, Joni
PS: Helmut, könntest Du noch in Dein Startbeitrag des zweiten Fadens einen Link zum ersten Faden setzen - wenn jemand von Anfang an lesen möchte - Danke.
mehrere Loks / Züge in einem Block abstellen, soll auch mit TC gehen - allerdings nur wenn die Ausfahrt in die gleiche Richtung geht wie die Einfahrt, also kein Stumpfgleis (Handbuch Seite 276 - 279). Das habe ich aber noch nicht ausprobiert.
Viele Grüße, Joni
PS: Helmut, könntest Du noch in Dein Startbeitrag des zweiten Fadens einen Link zum ersten Faden setzen - wenn jemand von Anfang an lesen möchte - Danke.
zwengelmann - 10.04.21 09:47
Hallo Helmut,
hier hängt nun alles an der Softwarefrage. Wenn Traincontroller gesetzt ist, braucht man über BiDiB nicht mehr zu diskutieren.
TC funktioniert mit minimaler Rückmeldung. D.h., es funktioniert auch mit S88-Rückmeldern. TC muss nur wissen, welche Abschnitte besetzt sind. Anhand des Streckenplans und der Weichenstellung kann TC dann sehr gut selbst errechnen, welches Fahrzeug gerade in einen Abschnitt einfährt, welches Fahrzeug wo ist.
Ich sehe auch wieder diesen Irrtum: Railcom ist KEIN Bus. Mit Railcom sendet die Lok ein paar Daten, aber sie hat keine Ahnung, wo ist ist und kann demzufolge auch keine Positionsinformation für irgendeine Software liefern. Um die zu bekommen, muss die Anlage in Abschnitte aufgeteilt und diese mit Railcom-fähigen Rückmeldern ausgestattet werden, die ihre jeweilige Information über einen Bus (und hier scheidet z.B. S88 aus) weiterleiten. Selbst mehr als ein Railcom-Fahrzeug in einem Abschnitt geht schief, denn die Fahrzeuge werfen einfach nur ihre Daten aus. Wenn zwei gleichzeitig sprechen, versteht man keinen. Deshalb braucht man Abschnitte.
Helmut, irgendwo musst Du anfangen. Setzt Du auf z.B. BiDiB als Bus, scheiden manche Softwareprodukte aus. Setzt Du auf ein bestimmtes Softwareprodukt, scheiden wiederum gewisse Bussysteme aus. Wenn Du hier keine Anfangsentscheidung triffst, wirst Du Dich permanent im Kreis drehen.
Wenn Du zukunftssicher sein willst, baust Du halt eine Railcom-fähige Infrastruktur, selbst wenn Traincontroller diese Daten ignoriert. Vielleicht kommt's ja irgendwann. Auf der anderen Seite: Warum, wenn es auch ohne geht? Aber vielleicht wechselst Du in ein paar Jahren die Software und ärgerst Dich dann. Hier kann Dir niemand helfen, das ist eine Entscheidung, die getroffen werden muss.
Grüße
Zwengelmann
hier hängt nun alles an der Softwarefrage. Wenn Traincontroller gesetzt ist, braucht man über BiDiB nicht mehr zu diskutieren.
TC funktioniert mit minimaler Rückmeldung. D.h., es funktioniert auch mit S88-Rückmeldern. TC muss nur wissen, welche Abschnitte besetzt sind. Anhand des Streckenplans und der Weichenstellung kann TC dann sehr gut selbst errechnen, welches Fahrzeug gerade in einen Abschnitt einfährt, welches Fahrzeug wo ist.
Ich sehe auch wieder diesen Irrtum: Railcom ist KEIN Bus. Mit Railcom sendet die Lok ein paar Daten, aber sie hat keine Ahnung, wo ist ist und kann demzufolge auch keine Positionsinformation für irgendeine Software liefern. Um die zu bekommen, muss die Anlage in Abschnitte aufgeteilt und diese mit Railcom-fähigen Rückmeldern ausgestattet werden, die ihre jeweilige Information über einen Bus (und hier scheidet z.B. S88 aus) weiterleiten. Selbst mehr als ein Railcom-Fahrzeug in einem Abschnitt geht schief, denn die Fahrzeuge werfen einfach nur ihre Daten aus. Wenn zwei gleichzeitig sprechen, versteht man keinen. Deshalb braucht man Abschnitte.
Helmut, irgendwo musst Du anfangen. Setzt Du auf z.B. BiDiB als Bus, scheiden manche Softwareprodukte aus. Setzt Du auf ein bestimmtes Softwareprodukt, scheiden wiederum gewisse Bussysteme aus. Wenn Du hier keine Anfangsentscheidung triffst, wirst Du Dich permanent im Kreis drehen.
Wenn Du zukunftssicher sein willst, baust Du halt eine Railcom-fähige Infrastruktur, selbst wenn Traincontroller diese Daten ignoriert. Vielleicht kommt's ja irgendwann. Auf der anderen Seite: Warum, wenn es auch ohne geht? Aber vielleicht wechselst Du in ein paar Jahren die Software und ärgerst Dich dann. Hier kann Dir niemand helfen, das ist eine Entscheidung, die getroffen werden muss.
Grüße
Zwengelmann
Hallo Helmut,
der aktuelle Train Controller 9 unterstützt kein Railcom. Ob z. B. der TC 10 Railcom unterstützt kann im Moment noch niemand sagen.
Ob Railcom ja oder nein hängt vielleicht auch von deinem aktuellen Fuhrpark ab. Wenn du hier viele Fahrzeuge hast welche kein Railcom beherrschen (ich denke da an ältere Trix Loks mit Onbord-Sound?) und du die Loks nicht umbauen willst/ kannst dann würde ich eher auf Railcom verzichten. Mit dem TC kannst du auch ohne Railcom eine Anlage mit 30 Zügen (und auch mit deutlich mehr Zügen) steuern. Mit dem TC spielt es beispielsweise auch keine Rolle ob du mit dem S88N oder mit dem SX-Bus arbeitest.
Diese Entscheidungen musst du alleine treffen. Und wie sich Railcom entwickeln wird weiß auch niemand. Vielleicht ist es in fünf Jahren der Standard oder es verschwindet wegen mangelnder Akzeptanz langsam wieder vom Markt.
Grüße
Markus
der aktuelle Train Controller 9 unterstützt kein Railcom. Ob z. B. der TC 10 Railcom unterstützt kann im Moment noch niemand sagen.
Ob Railcom ja oder nein hängt vielleicht auch von deinem aktuellen Fuhrpark ab. Wenn du hier viele Fahrzeuge hast welche kein Railcom beherrschen (ich denke da an ältere Trix Loks mit Onbord-Sound?) und du die Loks nicht umbauen willst/ kannst dann würde ich eher auf Railcom verzichten. Mit dem TC kannst du auch ohne Railcom eine Anlage mit 30 Zügen (und auch mit deutlich mehr Zügen) steuern. Mit dem TC spielt es beispielsweise auch keine Rolle ob du mit dem S88N oder mit dem SX-Bus arbeitest.
Diese Entscheidungen musst du alleine treffen. Und wie sich Railcom entwickeln wird weiß auch niemand. Vielleicht ist es in fünf Jahren der Standard oder es verschwindet wegen mangelnder Akzeptanz langsam wieder vom Markt.
Grüße
Markus
Michael S. - 10.04.21 10:56
Ich vermute es ist wie bei der Elektromobilität: Kann keiner sagen, wo das hinführt, vielleicht verschwindet sie wegen fehlender Akzeptanz wieder vom Markt.
Also weiß ich nicht. Ich werfe es einfach mal in den Raum. Ich hoffe jetzt sind alle verunsichert, die sich ein Elektroauto kaufen wollen.
Zur SW: Ich war auch immer auch auf TC fixiert, da es wirklich viele nutzen und es sicher ein gutes Programm ist. Die Zeiten, wo man "hoffen" muss, dass jemand etwas implementiert sind jedoch vorbei. Man muss einfach mal klar sagen, dass es genügend andere ausgezeichnete Software gibt, iTrain läuft dazu auch auf Mac und Linux.
VG Michael
Also weiß ich nicht. Ich werfe es einfach mal in den Raum. Ich hoffe jetzt sind alle verunsichert, die sich ein Elektroauto kaufen wollen.
Zur SW: Ich war auch immer auch auf TC fixiert, da es wirklich viele nutzen und es sicher ein gutes Programm ist. Die Zeiten, wo man "hoffen" muss, dass jemand etwas implementiert sind jedoch vorbei. Man muss einfach mal klar sagen, dass es genügend andere ausgezeichnete Software gibt, iTrain läuft dazu auch auf Mac und Linux.
VG Michael
Zitat - Antwort-Nr.: 7 | Name: Zwengelmann
Selbst mehr als ein Railcom-Fahrzeug in einem Abschnitt geht schief, denn die Fahrzeuge werfen einfach nur ihre Daten aus. Wenn zwei gleichzeitig sprechen, versteht man keinen. Deshalb braucht man Abschnitte.
Das ist nicht korrekt, nur im Kanal 1 melden alle Decoder ihre Adresse in jeder Railcom-Lücke, Daten im Kanal 2 (CVs lesen, Geschwindigkeit usw.) werden nur vom Decoder gesendet, der per DCC-Adresse angesprochen wurde.
Hier gibt es dann keinen Datensalat.
Grüße
Stephan
Das ist eine automatische Adressvergabe wie Railcom+ nur von der Railcommunity als offener Standard.
In der nächsten DiMo ist ein Bericht angekündigt. (https://www.vgbahn.shop/dimo-digitale-modellbahn/).
Grüße
Stephan
teppichbahner - 10.04.21 16:46
Zitat
Das ist nicht korrekt, nur im Kanal 1 melden alle Decoder ihre Adresse in jeder Railcom-Lücke, Daten im Kanal 2 (CVs lesen, Geschwindigkeit usw.) werden nur vom Decoder gesendet, der per DCC-Adresse angesprochen wurde.
Da diese "Ansprache" aber aus der Zentrale und nicht vom Belegtmelder kommt, kann jeweils nur ein Dekoder in Melden, alle anderen Belegtmelder bekommen also keine fahrzeugspezifischen Informationen, richtig?
Damit ist doch die ursprünglich mal geäußerte Ansicht, aufgrund zu vieler gleichzeitiger Fahrzeuginformationen wären gängige Bussysteme "überfordert".
Stellt sich mir nun die Frage, wie viele Fahrzeuge können denn in einer Sekunde im "Kanal 2" addressiert und abgefragt werden?
und
kann auf Kanal 2 auch die Fahrzeugadresse gelesen werden? Wenn nein, dann müßte man ja indirekt auf das Fahrzeug schließen und einen anderen Wert auf "Kanal 2" erwarten und nur dort ist dann das vorher angesprochene Fahrzeug.
Gruß
Klaus
Hallo Klaus
Es dürften etwa 180 DCC Befehle pro Sekunde sein. Oder weniger, kommt auf den Befehl an. Zudem dauert die Übertragung von "0" länger als von "1".
Gruss Matthias
Es dürften etwa 180 DCC Befehle pro Sekunde sein. Oder weniger, kommt auf den Befehl an. Zudem dauert die Übertragung von "0" länger als von "1".
Gruss Matthias
Arnold_Huebsch - 11.04.21 10:02
Hello!
TC hat sich eine gewisse Dominanz erworben, basiert auf dem Gedanken die schlechtest denkbare Zentrale als Maß aller Dinge zu nehmen und darauf aufzubauen. Man benutzt also einen Großteil der Möglichkeiten moderner Zentralen grundsätzlich nciht. Das rächt sich immer mehr weil die Funktionen die viele Modellbahner benutzen wollen darüber weit hinaus geht. Alleine die ZeitWeg Rechnung wäre viel präziser würde man RailCom Infos übernehmen.
Kanal 2 von RailCom ist reserviert für Antworten von Decodern auf eine Frage die die Zentrale zuvor ausgesendet hat. Das bedeutet theoretisch so viele Pakete wie mögliche Fragen. Das ist natürlich Unsinn, weil man ja nicht ausschließlich Fragen sendet. Meiner Einschätzung sich pro Sekunde ohnehin kaum mehr als 80 DCC Pakete möglich, daher sinkt die Zahl der Kanal2 Antworten noch viel weiter. Es gibt aber Überlegungen auch auf Kanal2 Spontanmeldungen zu senden, nachdem der Decoder seine eigene Adresse empfangen hat. Das geht natürlich nur wenn man viele lokale Detektoren hat. Diese braucht man ohnehin um Kanal1 Nachrichten lesen zu können wenn es mehr als einen Decoder auf der Anlage gibt. Daher die Notwendigkeit einen Bus zu haben der das transportieren kann. RailCom ist eben viiiiiiiiel mehr als nur die Decoder Adresse melden.
-AH-
TC hat sich eine gewisse Dominanz erworben, basiert auf dem Gedanken die schlechtest denkbare Zentrale als Maß aller Dinge zu nehmen und darauf aufzubauen. Man benutzt also einen Großteil der Möglichkeiten moderner Zentralen grundsätzlich nciht. Das rächt sich immer mehr weil die Funktionen die viele Modellbahner benutzen wollen darüber weit hinaus geht. Alleine die ZeitWeg Rechnung wäre viel präziser würde man RailCom Infos übernehmen.
Kanal 2 von RailCom ist reserviert für Antworten von Decodern auf eine Frage die die Zentrale zuvor ausgesendet hat. Das bedeutet theoretisch so viele Pakete wie mögliche Fragen. Das ist natürlich Unsinn, weil man ja nicht ausschließlich Fragen sendet. Meiner Einschätzung sich pro Sekunde ohnehin kaum mehr als 80 DCC Pakete möglich, daher sinkt die Zahl der Kanal2 Antworten noch viel weiter. Es gibt aber Überlegungen auch auf Kanal2 Spontanmeldungen zu senden, nachdem der Decoder seine eigene Adresse empfangen hat. Das geht natürlich nur wenn man viele lokale Detektoren hat. Diese braucht man ohnehin um Kanal1 Nachrichten lesen zu können wenn es mehr als einen Decoder auf der Anlage gibt. Daher die Notwendigkeit einen Bus zu haben der das transportieren kann. RailCom ist eben viiiiiiiiel mehr als nur die Decoder Adresse melden.
-AH-
Zitat
TC hat sich eine gewisse Dominanz erworben, basiert auf dem Gedanken die schlechtest denkbare Zentrale als Maß aller Dinge zu nehmen und darauf aufzubauen.
.png){kind=small}
teppichbahner - 11.04.21 11:38
Zitat
Daher die Notwendigkeit einen Bus zu haben der das transportieren kann.
Aber wenn Du schreibst, daß es deutlich weniger als 80 Pakete pro Sekunde sind, weil nicht nur Fragen gesendet werden, dann ist das eine sehr überschaubare Zahl von Meldungen, die man locker auf Bussen mit 5 oder 10kBit transportieren kann.
Das ist ja genau meine Frage: Was soll ein ach so gigantischer Bus im 10MBit Bereich, wenn dann alle paar Millisekunden mal ein Paketchen raustropft.
Ich denke, der Faden hat mir die Augen geöffnet
1.) Es gibt keinen Standard, sondern gaaaanz viele verschiedene, die sich im Protokoll und der Hardware vollständig unterscheiden.
2.) Es gibt keinerlei Software derzeit, die auch nur näherungsweise "alle" diese "Standards" benutzen könnte.
3.) Viele der "Standards" gelten als veraltet und können ( wahrscheinlich ) in näherer Zukunft abgeschafft werden.
4.) Es gibt derzeit nichts und niemanden, der versucht EINEN neuen Standard zu schaffen, auf den sich eine breite Zahl von Herstellern einigen würde und der Nutzer etwas davon hätte.
5.) Die blödesten, primitivsten, einfachsten und sinnlosesten Dinge sind mit zwar vermutlich nutzlosen, aber dennoch extrem behindernden Patenten zugemüllt, was der Schaffung EINES Standards absolut entgegen steht.
6.) Die Dokumentation der Hersteller ist faktisch nur selten vorhanden, viele der Standards sind im "dunklen" und bleiben auch dort. Eigene Erweiterung oder Nutzung auch deshalb ausgeschlossen, wenn nicht schon die Patentlage eine sinnvolle Nutzung verhindert.
Gestern hab ich im EM gelesen, daß Märklin die Selectrix Unterstützung aufgibt und Dekoder nur noch im eigenen Hause entwickeln will. Die Qualität dieser Bastel-Produkte kennen wir ja nun schon hinreichend, eine lange Liste Reklamationen habe ich selber schon hinter mir.
Kurzum:
Ich bleib bei analog! Diesen ganzen Quatsch tuhe ich mir echt nicht an...
Und nochmal zurück zum EM:
Da stehen so sinnreiche Bemerkungen wie:
Zitat
... auch der Wiederverkaufswert von professionell digitalisierten und mit Sound bestückten Lokomotiven ist auf jeden Fall höher als jener klassischer Analogfahrzeuge
Wenn ich diesen Faden sehe, wo sich ja schon abzeichnet, daß es immer wieder neuere Protokolle, auch auf dem Gleis, geben wird, dann ist ein Dekoder ja schneller vom Wertverlust betroffen, als das Modell, in dem dieser steckt. Von BiDiB, ABC Bremse, Railcom usw... tausende Schweine und kein Dorf
Und nun noch Selectrix weg. Was mag wohl der Wert einer Selectrix-Sound-Lok in 10 Jahren sein Lustig, was alles so in den Zeitungen steht. Vielleicht ja auch alles nur ein Aprilscherz...Digitalisierung: Wie im echten Leben eine riesige Geldverschwendung. Beim Vorbild das selbe Drama: Alte Stellwerke haben locker ein Jahrhundert gehalten und selbst die Relaisstellwerke aus den 60er Jahren, die einen Sicherheitsstandard und Bedienkomfort und Leistungsfähigkeit haben, die derzeit noch über denen der digitalisierten Anlagen steht, leben immer noch, selbst in größten Bahnhöfen wie Köln oder Düsseldorf. Ein ESTW ist nach 15, spätestens nach 20 Jahren weg vom Fenster, da keine Ersatzteile mehr verfügbar sind. Die selben Gründe also, die auch dort die Wertvernichtung treiben.
Danke für den sehr aufschlußreichen Faden!
Gruß
Klaus
Ich denke eher nicht, denn du hast den wichtigsten Punkt 7 nicht genannt, vielleicht, weil du ihn gar nicht kennst.
7.) Es gibt sehr viele Mobahner, die teils seit Jahrzehnten mit ihrem gewählten Digitalsystem hochzufrieden sind und gar keine "Verbesserung" brauchen.
Jürgen H.
teppichbahner - 11.04.21 12:27
@17:
Jein...
Wenn Du sagst, der technische Stand als auch die Summe an Material, die ich bereits gekauft habe, reicht mir aus und Ersatzteile brauch ich nicht.
Wenn ich aber auch weitere Modelle kaufen will und stelle plötzlich fest, es wird sie nicht mehr geben ( siehe Selectrix-Ende, falls das stimmt ), dann hab ich doch ein valides Problem, oder? Komm ich nicht dann irgendwann an den Punkt meinen Fuhrpark komplett zu erneuern? Egal ob durch Dekodertausch oder Neukauf?
Also ich weiß nicht... bei den Werten die da so im Raume stehen... autsch!
Gruß
Klaus
Jein...
Wenn Du sagst, der technische Stand als auch die Summe an Material, die ich bereits gekauft habe, reicht mir aus und Ersatzteile brauch ich nicht.
Wenn ich aber auch weitere Modelle kaufen will und stelle plötzlich fest, es wird sie nicht mehr geben ( siehe Selectrix-Ende, falls das stimmt ), dann hab ich doch ein valides Problem, oder? Komm ich nicht dann irgendwann an den Punkt meinen Fuhrpark komplett zu erneuern? Egal ob durch Dekodertausch oder Neukauf?
Also ich weiß nicht... bei den Werten die da so im Raume stehen... autsch!
Gruß
Klaus
@18: Das ist Quatsch.
Bereits meine erste Zentrale, 1999 gekauft, war eine Multiprotokollzentrale, die SX und DCC fahren konnte.
Es gibt heute dafür noch Upgrade Chips zum einfachen Selbsteinbau für kleines Geld, so ich es wollte.
Mich tangiert es also gar nicht, falls DCC, oder SX als Gleisprotokoll oder Rollmaterial nicht mehr erhältlich wäre.
Anders sieht es bei Analogbahnern aus, die sich mit einem sog. Zwangsdecoder und dessen möglicherweise unbefriedigenden Analogeigenschaften abfinden müssen, oder auf gewissen Loks verzichten.
Jürgen H.
Bereits meine erste Zentrale, 1999 gekauft, war eine Multiprotokollzentrale, die SX und DCC fahren konnte.
Es gibt heute dafür noch Upgrade Chips zum einfachen Selbsteinbau für kleines Geld, so ich es wollte.
Mich tangiert es also gar nicht, falls DCC, oder SX als Gleisprotokoll oder Rollmaterial nicht mehr erhältlich wäre.
Anders sieht es bei Analogbahnern aus, die sich mit einem sog. Zwangsdecoder und dessen möglicherweise unbefriedigenden Analogeigenschaften abfinden müssen, oder auf gewissen Loks verzichten.
Jürgen H.
teppichbahner - 11.04.21 12:48
... oder Zwangsdekoder zur Not mit der Fräse entfernen und ein paar Fädeldrähte drüber löten.
Ja, hatten wir schon einige male...
Gruß
Klaus
Ja, hatten wir schon einige male...
Gruß
Klaus
Zitat - Antwort-Nr.: | Name:
Wenn ich aber auch weitere Modelle kaufen will und stelle plötzlich fest, es wird sie nicht mehr geben ( siehe Selectrix-Ende, falls das stimmt ), dann hab ich doch ein valides Problem, oder?
Zitat - Antwort-Nr.: | Name:
... oder Zwangsdekoder zur Not mit der Fräse entfernen und ein paar Fädeldrähte drüber löten.
Aha, Decoder entfernen ist also kein Problem, aber Decoder gegen andere tauschen nennt man "Fuhrpark komplett erneuern".
Alles klar.
Jürgen H.
teppichbahner - 11.04.21 13:51
Zitat
Egal ob durch Dekodertausch oder Neukauf?
Hab ich geschrieben! Erst Lesen dann meckern!
Zitat - Antwort-Nr.: 16 | Name: teppichbahner
1.) Es gibt keinen Standard, sondern gaaaanz viele verschiedene, die sich im Protokoll und der Hardware vollständig unterscheiden.
Das war schon von Anfang an so, sollte also keine neue Erkenntnis sein.
Zitat - Antwort-Nr.: 16 | Name: teppichbahner
2.) Es gibt keinerlei Software derzeit, die auch nur näherungsweise "alle" diese "Standards" benutzen könnte.
Verscheidene Programme unterstützen nicht alle die gleichen Systeme, was ist da neu?
Zitat - Antwort-Nr.: 16 | Name: teppichbahner
3.) Viele der "Standards" gelten als veraltet und können ( wahrscheinlich ) in näherer Zukunft abgeschafft werden.
Möglich, eher unwahrscheinlich dass das zu Lebzeiten der bisherigen Nutzer passiert.
Das Thema hatte damit begonnen, was aktuell sinnvoll wäre, wenn ich mich richtig erinnere.
Zitat - Antwort-Nr.: 16 | Name: teppichbahner
4.) Es gibt derzeit nichts und niemanden, der versucht EINEN neuen Standard zu schaffen, auf den sich eine breite Zahl von Herstellern einigen würde und der Nutzer etwas davon hätte.
Es gibt nichts und niemanden, der EIN Auto für alle schaffen möchte.
Zitat - Antwort-Nr.: 16 | Name: teppichbahner
5.) Die blödesten, primitivsten, einfachsten und sinnlosesten Dinge sind mit zwar vermutlich nutzlosen, aber dennoch extrem behindernden Patenten zugemüllt, was der Schaffung EINES Standards absolut entgegen steht.
Blödsinn.
Zitat - Antwort-Nr.: 16 | Name: teppichbahner
6.) Die Dokumentation der Hersteller ist faktisch nur selten vorhanden, viele der Standards sind im "dunklen" und bleiben auch dort. Eigene Erweiterung oder Nutzung auch deshalb ausgeschlossen, wenn nicht schon die Patentlage eine sinnvolle Nutzung verhindert.
Behauptung, Beweise?
Ansonsten Blödsinn.
Grüße
Stephan
Hallo miteinander
Zu RailCom:
Wäre schön, wenn die automatische Anmeldung nicht nur bei Loks und Schalt-/Meldeartikel funktionieren würde, sondern auch bei Wagen. Dann könnte ich einfach die Lok und acht verschiedene Reisezugwagen auf die Schienen stellen und die Software weiss sofort, wie lange der Zug ist (gleiches bei Güterwagen). Ist nur so ein Gedanke (jep, Decoder kosten und bei schlechtem Radkontakt...).
@teppichbahner
Zwangsdecoder sind für einige Leute ein Ärgernis, egal ob Analog- oder Digitalfahrer. Vor allem dann, wenn sie fest auf die Platine gelötet wurden.
Zu Selectrix: Märklin baut keine Selectrixfähigen Decoder mehr ein. Das betrifft in Spur N, so wie ich das sehe, nur Minitrix und ist seit ca. einem Jahr bekannt. Und wenn diese Decoder auch noch fest eingelötet werden, dann siehe Absatz oben. Andere Hersteller bieten neben den eigenen DCC Decoder immer noch eine Schnittstelle an. Da kann ein Selectrixfähiger Decoder eingesteckt werden.
Und wenn nicht, dann hilft, wie schon mehrfach geschrieben, eine Multiprotokollzentrale. Hier mal eine Auswahl von solchen, welche SX1+DCC bieten:
Occasionen:
D&H: Future-Central-Control
ESU: Central Station Reloaded
ESU: ECoS
ESU: ECoS 2
Fleischmann: TWIN-Center (6802)
Rautenhaus Digital: RMX950
Rautenhaus Digital: SLX850
Rautenhaus Digital: SLX850AD
Stärz: ZS2
Trix: Central Control 2000
Uhlenbrock: Intellibox
Uhlenbrock: Intellibox IR
Erhältlich:
ESU: ECoS 2.1
KM1 System Control 7 (eher für grosse Spuren gedacht)
Müt Digirail: Multi Control 2004 (neuste News allerdings ist aus dem Jahre 2019, die ich gefunden habe)
Raptor Digital: Raptor Zentrale (kann sogar noch FMZ)
Rautenhaus Digital: RMX950USB
Stärz: ZS1
Stärz: ZS2+
Uhlenbrock: Intellibox II
Noch nicht erhältlich:
D&H: Future-Central-Control X
Nicht alle hier aufgezählten Zentralen bieten auch z.b. für Schalt-/Lichtdecoder oder Belegtmelder einen separaten SX-Bus. Aber auch da gibt es Lösungen, sicher dann, wenn z.B. die Belegtmelder galvanisch getrennt sind und die ganze Sache über ein Computerprogramm läuft.
Und bei reinen DCC-Zentralen sieht es Bus-seitig ähnlich aus. Einige sind nicht nur auf einen Schalt-/Meldebus beschränkt, sondern bieten gleich zwei oder mehr an. Selbst wenn die "alte" Zentrale nicht mehr repariert werden kann, ein Ersatz (occasion oder neu) vom gleichen oder einem anderen Hersteller ist meistens vorhanden.
Geht im bei Analog ein Loksteuerregler hops, wird dieser entweder auch repariert oder ersetzt. Bei Digital ist das nicht anders. Was mehr kostet, sei mal ausser acht gelassen, denn...
... Analog- und Digitalfahren haben etwas gemeinsames: Willst Du mehr, bezahlst Du mehr. Und bei beidem musst Du meiner Meinung nach egoistisch denken: Was willst Du? Und dann holst Du Dir aus deinem gewähltem System raus (egal ob analog oder digital), was Du möchtest oder brauchst (mehr Relais, mehr Dioden, mehr Decoder usw.).
Griessli
Tipsi
Zu RailCom:
Wäre schön, wenn die automatische Anmeldung nicht nur bei Loks und Schalt-/Meldeartikel funktionieren würde, sondern auch bei Wagen. Dann könnte ich einfach die Lok und acht verschiedene Reisezugwagen auf die Schienen stellen und die Software weiss sofort, wie lange der Zug ist (gleiches bei Güterwagen). Ist nur so ein Gedanke (jep, Decoder kosten und bei schlechtem Radkontakt...).
@teppichbahner
Zwangsdecoder sind für einige Leute ein Ärgernis, egal ob Analog- oder Digitalfahrer. Vor allem dann, wenn sie fest auf die Platine gelötet wurden.
Zu Selectrix: Märklin baut keine Selectrixfähigen Decoder mehr ein. Das betrifft in Spur N, so wie ich das sehe, nur Minitrix und ist seit ca. einem Jahr bekannt. Und wenn diese Decoder auch noch fest eingelötet werden, dann siehe Absatz oben. Andere Hersteller bieten neben den eigenen DCC Decoder immer noch eine Schnittstelle an. Da kann ein Selectrixfähiger Decoder eingesteckt werden.
Und wenn nicht, dann hilft, wie schon mehrfach geschrieben, eine Multiprotokollzentrale. Hier mal eine Auswahl von solchen, welche SX1+DCC bieten:
Occasionen:
D&H: Future-Central-Control
ESU: Central Station Reloaded
ESU: ECoS
ESU: ECoS 2
Fleischmann: TWIN-Center (6802)
Rautenhaus Digital: RMX950
Rautenhaus Digital: SLX850
Rautenhaus Digital: SLX850AD
Stärz: ZS2
Trix: Central Control 2000
Uhlenbrock: Intellibox
Uhlenbrock: Intellibox IR
Erhältlich:
ESU: ECoS 2.1
KM1 System Control 7 (eher für grosse Spuren gedacht)
Müt Digirail: Multi Control 2004 (neuste News allerdings ist aus dem Jahre 2019, die ich gefunden habe)
Raptor Digital: Raptor Zentrale (kann sogar noch FMZ)
Rautenhaus Digital: RMX950USB
Stärz: ZS1
Stärz: ZS2+
Uhlenbrock: Intellibox II
Noch nicht erhältlich:
D&H: Future-Central-Control X
Nicht alle hier aufgezählten Zentralen bieten auch z.b. für Schalt-/Lichtdecoder oder Belegtmelder einen separaten SX-Bus. Aber auch da gibt es Lösungen, sicher dann, wenn z.B. die Belegtmelder galvanisch getrennt sind und die ganze Sache über ein Computerprogramm läuft.
Und bei reinen DCC-Zentralen sieht es Bus-seitig ähnlich aus. Einige sind nicht nur auf einen Schalt-/Meldebus beschränkt, sondern bieten gleich zwei oder mehr an. Selbst wenn die "alte" Zentrale nicht mehr repariert werden kann, ein Ersatz (occasion oder neu) vom gleichen oder einem anderen Hersteller ist meistens vorhanden.
Geht im bei Analog ein Loksteuerregler hops, wird dieser entweder auch repariert oder ersetzt. Bei Digital ist das nicht anders. Was mehr kostet, sei mal ausser acht gelassen, denn...
... Analog- und Digitalfahren haben etwas gemeinsames: Willst Du mehr, bezahlst Du mehr. Und bei beidem musst Du meiner Meinung nach egoistisch denken: Was willst Du? Und dann holst Du Dir aus deinem gewähltem System raus (egal ob analog oder digital), was Du möchtest oder brauchst (mehr Relais, mehr Dioden, mehr Decoder usw.).
Griessli
Tipsi
Zitat - Antwort-Nr.: | Name: maylander
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.
Hast Du dafür Belege?
Zitat - Antwort-Nr.: | Name: maylander
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.
Railcom war von Anfang an standartisiert, nur man benötigte eine Lizenz von Lenz. Die konnte man aber nicht unbedingt leicht bekommen (was ich blöd fand).
Schon länger ist Railcom lizenzfrei, seit 2016 von der Railcommunity öffentlich spezifiziert:
http://normen.railcommunity.de/RCN-217.pdf
Mit Diodenbremsen meinst Du wohl Lenz ABC. Das hat nichts mit DCC zu tun.
Erfunden hatte es Umelec, Lenz hatte noch die Langsamfahrt hinzugefügt und diese Funktion mit einer Lizenz verbunden (was ich blöd fand), was aber schon länger nicht mehr gilt.
Spezifiziert sind die ABC-Bits in CV27 schon im NMRA-Dokument von 2012. Wann die CV hinzugefügt wurde kann ich nicht finden.
Wie vor allem vom Arnold schon öfters erwähnt ist Railcom absolut DCC-kompatibel. Decoder, die die kurze Unterbrechung nicht verkraften sind NICHT DCC-kompatibel.
Interessant wäre noch, ob die Problem-Decoder mit einem Pufferkondensator funktionieren.
Zitat - Antwort-Nr.: | Name: maylander
Während die DCC Herren ihr Spiel betrieben haben, wurden mehrere tolle Steuerprogramme geschaffen die wunderbar ohne Railcom auskommen.
Steuerungsprogramme gab es schon vor der Veröffentlichung von Railcom.
Grüße
Stephan
Zitat - Antwort-Nr.: | Name: xenayoo
Ah ja, das spielt in unserem Maßstab jetzt DIE Rolle. Aber gut, dass du fragst: Ja, die sind bekannt.
So wie Du es geschrieben hattest, klang es für mich so, dass es das nicht gibt.
Zitat - Antwort-Nr.: | Name: xenayoo
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.
Verstehe ich nicht. Mir fallen fast keine (relevanten) Anbieter außer Märklin ein, die Railcom nicht unterstützen.
Je nach Anbieter gibt es natürlich preisliche Unterschiede, zum Teil deutliche Aufpreise, aber gerade im Vergleich zu SX-Komponenten sehe ich die nicht gegeben. (jetzt bitte kein Vergleich teuerstes gegen billigestes).
Mehr Technik kostet meistens eben mehr Geld.
Zitat - Antwort-Nr.: | Name: xenayoo
MFX wiederum ist nach meinem wissen nicht in N verbreitet, obwohl mich das ein wenig wundert.
MFX wäre wegen der Decoder-Größe bisher nicht möglich, mit den neuen Decoder schon.
Zitat - Antwort-Nr.: | Name: xenayoo
Es wird jedoch daran entwickelt, sogar bei dem verteufelten SX (aber das darf scheinbar nicht sein).
Das hat niemand geschrieben, vor allem Arnold nicht.
Das ist nur Deine Interpreation, nicht die Aussage.
Zitat - Antwort-Nr.: | Name: xenayoo
Ich habe ein SX-System im Einsatz und es funktioniert hervorragend.
Das ist doch schön. Kann keine gegenteilige Behauptung finden.
Zitat - Antwort-Nr.: | Name: xenayoo
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.
Arnold ist kein 'selbsternannter dcc-Pabst', er kennst sich nur gut aus, ist lange dabei und auch in der Railcommunity aktiv.
Auch steht nirgends, 'was Menschen kaufen dürfen und was nicht'.
Ist Deine Interpretation, nicht die Aussage.
Zitat - Antwort-Nr.: | Name: xenayoo
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.
Es behauptet niemand, dass SX schlecht ist, nur nicht mehr zeitgemäß oder andere Begriffe.
Das ist ein großer Unterschied.
Das erste iPhone ist doch nicht schlecht, nur nicht mehr zeitgemäß.
Grüße
Stephan
Zitat - Antwort-Nr.: 25 | Name:
Decoder, die die kurze Unterbrechung nicht verkraften sind NICHT DCC-kompatibel.
Ich mach jede Wette dass die Digitraxdecoder die ich hab und die bei RailCom verwirrt werden einen DCC-kompatibel Stempel besitzen. Warum sie "aussteigen" weiss ich nicht. Wenn ich aber mal so eine Woche Zeit übrig hab könnte ich eine Testserie anlegen wo man Sachen ausprobiert. Z.B. Präambel nochmal extra verlängern oder den Decodern extra Puffer "draufpappen".
Zitat - Antwort-Nr.: 26 | Name:
Mir fallen fast keine (relevanten) Anbieter außer Märklin ein, die Railcom nicht unterstützen.
Digitrax ist als einer der größten Hersteller weltweit sehr relevant.
Ach, wir bei DCC++EX haben noch keine RailCom Lücke in der Release Software, aber das liegt mehr daran dass die verbreitete "Open Source HW" (also Motorshields zum Arduino) meistens die Spezifikation zum Spannungsabfall sowieso nicht erfüllt. Ich hab keine Lust "kann RailCom" zu sagen und dann wird HW genommen wo das nicht funktioniert und dann sind wir die Dummen.
Grüße,
Harald.
Hallo Zusammen,
Funktioniert Railcom mit dieser Kombination?
SW: ITrain
z21 mit Belegtmelder Digikeijs DR4088RB über R-Bus angebunden, jedoch die weiteren nachgeschalteten Digikeijs Module via S88N?
Gruß,
Robert
Funktioniert Railcom mit dieser Kombination?
SW: ITrain
z21 mit Belegtmelder Digikeijs DR4088RB über R-Bus angebunden, jedoch die weiteren nachgeschalteten Digikeijs Module via S88N?
Gruß,
Robert
hallo AH, Ste111,
das ist es, was ich nicht verstehe:
Auf der Einen Seite wird immer wieder gebetsmühlenartig wiederholt, wie veraltet SX sei und deshalb könne es niemandem mehr empfohlen werden. Was an dcc moderner sein soll, erschließt sich mir nicht.
Nochmal:
Dcc kann nur steuern und schalten
SX kann steuern, schalten UND melden.
Zum Melden benötigt man bei dcc einen ZUSÄTZLICHEN Bus, von den es VIELE gibt. Punkt.
SX-Systeme können problemlos mit mehreren Formaten umgehen, so dass es - mir zumindest - völig egal ist, was für ein Dekoder darin werkelt, solange er lastgeregelt ist. SX-Systeme werden weiterentwickelt und kommen such mit RailCom klar.
Wirklich gute Handregler, die RailCom nutzen (können) gibt es meines Wissens bei keinem Anbieter, da alle in dem Punkt auf Software und Tablets setzen.
Im übrigen sehe ich einen Unterschied bei nutzen können und wirklich nutzen. Es gibt heute, nach über 20 Jahren RailCom-Gerede kein einziges Digitalsystem, welches ‚out-of-the-box‘ RailCom mit allem möglichen Komfort einsetzt.
Können tun’s angeblich fast alle....
Schönen Sonntag mit der MoBa
Jens
das ist es, was ich nicht verstehe:
Auf der Einen Seite wird immer wieder gebetsmühlenartig wiederholt, wie veraltet SX sei und deshalb könne es niemandem mehr empfohlen werden. Was an dcc moderner sein soll, erschließt sich mir nicht.
Nochmal:
Dcc kann nur steuern und schalten
SX kann steuern, schalten UND melden.
Zum Melden benötigt man bei dcc einen ZUSÄTZLICHEN Bus, von den es VIELE gibt. Punkt.
SX-Systeme können problemlos mit mehreren Formaten umgehen, so dass es - mir zumindest - völig egal ist, was für ein Dekoder darin werkelt, solange er lastgeregelt ist. SX-Systeme werden weiterentwickelt und kommen such mit RailCom klar.
Wirklich gute Handregler, die RailCom nutzen (können) gibt es meines Wissens bei keinem Anbieter, da alle in dem Punkt auf Software und Tablets setzen.
Im übrigen sehe ich einen Unterschied bei nutzen können und wirklich nutzen. Es gibt heute, nach über 20 Jahren RailCom-Gerede kein einziges Digitalsystem, welches ‚out-of-the-box‘ RailCom mit allem möglichen Komfort einsetzt.
Können tun’s angeblich fast alle....
Schönen Sonntag mit der MoBa
Jens
Zitat - Antwort-Nr.: 28 | Name: Robby2020
Funktioniert Railcom mit dieser Kombination?
SW: ITrain
z21 mit Belegtmelder Digikeijs DR4088RB über R-Bus angebunden, jedoch die weiteren nachgeschalteten Digikeijs Module via S88N?
iTrain kann das, S88-oder Roco-R-Bus-Melder können das nicht.
Grüße
Stephan
Hallo Stephan,
Welche Melder und Bus ginge ansonsten mit der z21?
Gruß,
Robert
Welche Melder und Bus ginge ansonsten mit der z21?
Gruß,
Robert
Westerland - 11.04.21 19:38
Zitat - Antwort-Nr.: | Name:
Es behauptet niemand, dass SX schlecht ist, nur nicht mehr zeitgemäß oder andere Begriffe.
Hallo Stephan,
als vor einigen Jahren die Firma Märklin/Trix das System Selectrix freigegen hat, wurde gebetsmühlenartig behauptet, das System sei am Ende.
Nur ist das Angebot seitdem geradezu explosionsartig gewachsen. Ein großer Teil der Lokdecoder versteht Selectrix und gerade hat ESU sein Angebot an Selectrix fähigen Komponenten erweitert.
Von daher ist es schon ein wenig rätselhaft, warum nun ausgerechnet die DCC Bahner seit Jahren behaupten, dann System sei tot. Na ja, ich glaube nicht, dass die diversen Firmen, die Selectrix Komponenten anbieten, das tun, weil das System tot ist.....
.png){kind=small}
Viele Grüße,
Mathias
teppichbahner - 11.04.21 19:43
Den Grabenkrieg zwischen DCC und SX kann ja führen wer will. Aber hat der erklärte Ausstieg von Märklin bei SX kein Gewicht bei der zu erwartenden Lebensfähigkeit von SX? Ist Märklin nicht der größte Hersteller ( gewesen )? Gab es überhaupt andere Hersteller, die Dekoder mit SX von Haus aus in Fahrzeuge verbaut haben?
Ob tot oder nicht, kann ja jeder sehen wie er will, aber wenn ein großer abspringt, hat das doch auch eine Aussage.
Oder bin ich auf dem falschen Dampfer? Kann ja sein, bin ja "nur Analogi".
Gruß
Klaus
Ob tot oder nicht, kann ja jeder sehen wie er will, aber wenn ein großer abspringt, hat das doch auch eine Aussage.
Oder bin ich auf dem falschen Dampfer? Kann ja sein, bin ja "nur Analogi".
Gruß
Klaus
@Stephan
Habe mal recherchiert.
Der Roco Melder 10808 kann wohl CAN und R-Bus.
Nachtrag: Ralicom soll laut Roco damit nur mit CAN Bus gehen, also nur mit der schwarzen Z21
Gruß,
Robert
Habe mal recherchiert.
Der Roco Melder 10808 kann wohl CAN und R-Bus.
Nachtrag: Ralicom soll laut Roco damit nur mit CAN Bus gehen, also nur mit der schwarzen Z21
Gruß,
Robert
Beitrag editiert am 11. 04. 2021 19:54.
Zitat - Antwort-Nr.: | Name:
Aber hat der erklärte Ausstieg von Märklin bei SX kein Gewicht bei der zu erwartenden Lebensfähigkeit von SX?
Nein, denn es gibt (fast?) gar keine SX-Zentrale, die nicht auch DCC fahren könnte.
Schalt- und Meldekomponenten hat ohnehin kaum ein SXler bei Trix gekauft, sondern bei anderen Anbietern, die es immer noch gibt.
Welchen Einfluss soll also Märklin auf SX haben nur weil sie aus Loks, die seit Jahrzehnten schon SX und DCC konnten nun das SX streichen?
Ja.
Jürgen H.
Hallo Klaus,
Nein, Trix hatte leider von Anfang an Große Fehler bei der Vermarktung gemacht. Seit Märklin am Ruder ist, war klar, dass der Ausstieg erfolgen würde und das haben sie auch gesagt. Bei SX gibt Märklin seit gefühlt 20 Jahren nicht mehr den Ton an.
Märklin mag der Größte sein, heißt aber nicht der Beste. SX war eine gewisse Zeit Exklusiv bei Trix. Andere Anbieter haben sich deshalb nicht für SX interessiert.
Faktisch ist der Große vor vielen Jahren bereits abgesprungen. Die Wiederholung dieser alten und bekannten Aussage hat heute Null praktische Auswirkungen.
Was Märklin betrifft, bist du zum Glück auf dem falschen Dampfer.
Jens
Zitat - Antwort-Nr.: | Name:
Den Grabenkrieg zwischen DCC und SX kann ja führen wer will. Aber hat der erklärte Ausstieg von Märklin bei SX kein Gewicht bei der zu erwartenden Lebensfähigkeit von SX?
Nein, Trix hatte leider von Anfang an Große Fehler bei der Vermarktung gemacht. Seit Märklin am Ruder ist, war klar, dass der Ausstieg erfolgen würde und das haben sie auch gesagt. Bei SX gibt Märklin seit gefühlt 20 Jahren nicht mehr den Ton an.
Zitat - Antwort-Nr.: | Name:
Ist Märklin nicht der größte Hersteller ( gewesen )? Gab es überhaupt andere Hersteller, die Dekoder mit SX von Haus aus in Fahrzeuge verbaut haben?
Märklin mag der Größte sein, heißt aber nicht der Beste. SX war eine gewisse Zeit Exklusiv bei Trix. Andere Anbieter haben sich deshalb nicht für SX interessiert.
Zitat - Antwort-Nr.: | Name:
Ob tot oder nicht, kann ja jeder sehen wie er will, aber wenn ein großer abspringt, hat das doch auch eine Aussage.
Faktisch ist der Große vor vielen Jahren bereits abgesprungen. Die Wiederholung dieser alten und bekannten Aussage hat heute Null praktische Auswirkungen.
Zitat - Antwort-Nr.: | Name:
Oder bin ich auf dem falschen Dampfer? Kann ja sein, bin ja "nur Analogi".
Was Märklin betrifft, bist du zum Glück auf dem falschen Dampfer.
Jens
@Robby
Schau dir den DR5088rc von Digikeijs an.
Den Kannst du mittels USB an den PC anschliessen und dient auch als Loconet interface.
ACHTUNG unbedingt Anleitung und WIKI lesen. Benutze bitte einen USB Optoloppler oder USB Isolator.
https://support.digikeijs.com/hc/de/articles/36...l;cher-und-Downloads
https://www.digikeijs-wiki.com/doku.php?id=dr5088rc
Oder du gönnst die die grosse Z21 die kann Loconet und CAN
Viele Grüsse Matthias
Schau dir den DR5088rc von Digikeijs an.
Den Kannst du mittels USB an den PC anschliessen und dient auch als Loconet interface.
ACHTUNG unbedingt Anleitung und WIKI lesen. Benutze bitte einen USB Optoloppler oder USB Isolator.
https://support.digikeijs.com/hc/de/articles/36...l;cher-und-Downloads
https://www.digikeijs-wiki.com/doku.php?id=dr5088rc
Oder du gönnst die die grosse Z21 die kann Loconet und CAN
Viele Grüsse Matthias
@Ste111
Berichte über Reibereien gab es genüge. In der Mobapresse, in Foren und auch auf den Herstellerwebseiten. In Sachen Rückmeldung gab es zwischen Digitrax und Lenz, sowie Zimo und Lenz Nettigkeiten.
Statt miteneander zu reden haben sie es für alle schwieriger gemacht.
Digitraxdecoder vertragen kein Railcom. Digitrax hat sein Transponding aber auch verpatentiert und nicht freigegeben. Durch die Verbreitung von Digitrax wird sich Railcom in Nordamerika nicht durchsetzen können.
Die Railcommunity ist auch lustig. Der einzige genormte Rückmeldebus ist der
Trommelwirbel
Tadaaaaaaaaaaaaaa....
S88-N datiert von 2020
https://railcommunity.de/index.php?option=com_c...;id=49&Itemid=61
RCD-688 s88-N Rückmeldebus 06.12.2020 385 Kb
Wieso wird dort kein railcomfähiger Bus spezifiziert? Lenz hat ja nichts brauchbares. Kann man sich wirklich nicht zusammenraufen? Märklin kann daswas Railcom kann schon seit Ewigkeiten.
Bei MOROP ist Selectrix als Gleissignal und Bus genormt. Beim Amerikanischen Gegenstück NMRA DCC als Gleissignal und der CAN basierte LCC als Steuer und Rückmeldebus.
Gruss
Matthias
Berichte über Reibereien gab es genüge. In der Mobapresse, in Foren und auch auf den Herstellerwebseiten. In Sachen Rückmeldung gab es zwischen Digitrax und Lenz, sowie Zimo und Lenz Nettigkeiten.
Statt miteneander zu reden haben sie es für alle schwieriger gemacht.
Digitraxdecoder vertragen kein Railcom. Digitrax hat sein Transponding aber auch verpatentiert und nicht freigegeben. Durch die Verbreitung von Digitrax wird sich Railcom in Nordamerika nicht durchsetzen können.
Die Railcommunity ist auch lustig. Der einzige genormte Rückmeldebus ist der
Trommelwirbel
Tadaaaaaaaaaaaaaa....
S88-N datiert von 2020
https://railcommunity.de/index.php?option=com_c...;id=49&Itemid=61
RCD-688 s88-N Rückmeldebus 06.12.2020 385 Kb
Wieso wird dort kein railcomfähiger Bus spezifiziert? Lenz hat ja nichts brauchbares. Kann man sich wirklich nicht zusammenraufen? Märklin kann daswas Railcom kann schon seit Ewigkeiten.
Bei MOROP ist Selectrix als Gleissignal und Bus genormt. Beim Amerikanischen Gegenstück NMRA DCC als Gleissignal und der CAN basierte LCC als Steuer und Rückmeldebus.
Gruss
Matthias
@Matthias,
Ich bin ja aktuell von Analog auf Digital umgestiegen und baue derzeit eine neue Anlage (Digital).
Die weiße z21 reicht erstmal, genauso wie die Digikeijs DR4088RB Melder, die ich schon besitze. Bezüglich Software werde ich zu iTrain greifen, und später mal auf die schwarze Z21 umsteigen.
Die Melder werden dann halt ausgewechselt (benötige nicht so viele).
Gruß,
Robert
Ich bin ja aktuell von Analog auf Digital umgestiegen und baue derzeit eine neue Anlage (Digital).
Die weiße z21 reicht erstmal, genauso wie die Digikeijs DR4088RB Melder, die ich schon besitze. Bezüglich Software werde ich zu iTrain greifen, und später mal auf die schwarze Z21 umsteigen.
Die Melder werden dann halt ausgewechselt (benötige nicht so viele).
Gruß,
Robert
Servus,
Nee Klaus, rein bildlich gesprochen hat das nicht mal Dampf. Das ist mehr so ne römische Galeere und der Typ vorne macht bumm, bumm, bumm, bumm....
Manchmal hab ich dir das Gefühl du versuchst dir und uns recht krampfhaft einzureden das digital ja nicht funktionieren kann und wir das alles völlig falsch machen. Komisch nur das die Hummel doch fliegt!
on-topic...
Moderne Software kann auch mit mehreren Systemen am PC arbeiten, also ist die Bus-Frage doch letztlich auch nur eine Festlegung unter vielen. So ne Modellbahn ist ja keine Veranstaltung für die Ewigkeit...
Man kann sich heut natürlich auch massiv einen Kopf machen was morgen so sein wird. Oder man arbeitet mit dem was so verfügbar ist. Rückmelder kann man tauschen, Zentralen auch. Ich hab von letzteren inzwischen mehrere rumliegen die sich über die 25 Jahre digital angesammelt haben, und die meisten kommen immer mal wieder zum Zug. Ok, die alte IB1 hat dann langsam hinter sich
Derzeit komm ich noch ganz gut ohne Railcom oder BiDiB aus. Aber das muss nicht so bleiben, und wenn ich morgen Bock drauf hab dann bau ich das halt um und neue Melder dafür ein. Werden ja auch eher günstiger als teurer. Und wenn man dafür paar Uralt-Decoder rauswerfen muss ist das kein Drama und meist finden sich auch noch andere Gründe dafür.
So what?
Grüßle
Elvis
Nee Klaus, rein bildlich gesprochen hat das nicht mal Dampf. Das ist mehr so ne römische Galeere und der Typ vorne macht bumm, bumm, bumm, bumm....
Manchmal hab ich dir das Gefühl du versuchst dir und uns recht krampfhaft einzureden das digital ja nicht funktionieren kann und wir das alles völlig falsch machen. Komisch nur das die Hummel doch fliegt!
on-topic...
Moderne Software kann auch mit mehreren Systemen am PC arbeiten, also ist die Bus-Frage doch letztlich auch nur eine Festlegung unter vielen. So ne Modellbahn ist ja keine Veranstaltung für die Ewigkeit...
Man kann sich heut natürlich auch massiv einen Kopf machen was morgen so sein wird. Oder man arbeitet mit dem was so verfügbar ist. Rückmelder kann man tauschen, Zentralen auch. Ich hab von letzteren inzwischen mehrere rumliegen die sich über die 25 Jahre digital angesammelt haben, und die meisten kommen immer mal wieder zum Zug. Ok, die alte IB1 hat dann langsam hinter sich
Derzeit komm ich noch ganz gut ohne Railcom oder BiDiB aus. Aber das muss nicht so bleiben, und wenn ich morgen Bock drauf hab dann bau ich das halt um und neue Melder dafür ein. Werden ja auch eher günstiger als teurer. Und wenn man dafür paar Uralt-Decoder rauswerfen muss ist das kein Drama und meist finden sich auch noch andere Gründe dafür.
So what?
Grüßle
Elvis
Beitrag editiert am 11. 04. 2021 21:33.
Zitat - Antwort-Nr.: 33 | Name: Teppichbahner
Gab es überhaupt andere Hersteller, die Dekoder mit SX von Haus aus in Fahrzeuge verbaut haben?
Hallo Klaus,
ist zwar OT aber du hattest ja gefragt: Da fällt mir nur Brawa ein welche Digitalfahrzeuge anbieten welche neben DCC auch SX beherrschen:
https://www.brawa.de/produkte/n/lokomotiven/die...28-diesellok-232-dr/
Das größte Hindernis für die Verbreitung von SX war meiner Meinung nach der gewählte Name des Auftraggebers - Selectrix. Oder auf Deutsch übersetzt "wähle Trix". Diesen Namen hätte Firmen wie Fleischmann, Roco, Arnold, Roco, Märklin oder japanische oder amerikanische Hersteller nie und nimmer akzeptiert. Da klingt DCC schon ein wenig neutraler
Grüße
Markus
Zitat - Antwort-Nr.: 29 | Name: xenayoo
Auf der Einen Seite wird immer wieder gebetsmühlenartig wiederholt, wie veraltet SX sei und deshalb könne es niemandem mehr empfohlen werden. Was an dcc moderner sein soll, erschließt sich mir nicht.
DCC ist flexibler, da paket-orientiert, nicht wie SX1 das einen festen Rahmen hat.
Hast Du Dir mal SX2 angeschaut? Das ist vom Prinzip wie DCC paket-orientiert, wohl nicht ohne Grund.
Zitat - Antwort-Nr.: 29 | Name: xenayoo
Dcc kann nur steuern und schalten
SX kann steuern, schalten UND melden.
Zum Melden benötigt man bei dcc einen ZUSÄTZLICHEN Bus, von den es VIELE gibt. Punkt.
Das ist für mich die falsche Denkweise. Man benötigt EINEN Bus.
Für die Rückmeldung benötigt man einen Bus, egal bei welchem Protokoll.
Wenn Du SX auf das Gleis gibst, dann bekommst Du genauso wenig eine Rückmeldung wie bei jedem anderen Protokoll. Man benötigt einen Rückmelde-Bus.
SX war mal ein System von Trix. Das System hatte ein Gleisprotokoll und einen System-Bus.
Das hatte auch Lenz, DCC als Gleisprotokoll, RS-Bus für die Rückmeldung.
Erstmal kein Unterschied.
Erst viel später, als Märklin SX fallen gelassen hat haben andere Hersteller Komponenten für den SX-Systembus hergestellt, aber auch nicht alle, die SX unterstützen. Z.B. unterstützt Uhlenbrock und ESU SX als Gleisprotokoll aber nicht den Systembus.
Dein Argument kann man genauso auf Loconet anwenden. Jeder Hersteller, der Loconet unterstützt hat einen Systembus. Punkt, um es mit Deinen Worten zu sagen.
Zitat - Antwort-Nr.: 29 | Name: xenayoo
SX-Systeme können problemlos mit mehreren Formaten umgehen, so dass es - mir zumindest - völig egal ist, was für ein Dekoder darin werkelt, solange er lastgeregelt ist. SX-Systeme werden weiterentwickelt und kommen such mit RailCom klar.
Ist doch super, keiner sagt was anderes.
Zitat - Antwort-Nr.: 29 | Name: xenayoo
Wirklich gute Handregler, die RailCom nutzen (können) gibt es meines Wissens bei keinem Anbieter, da alle in dem Punkt auf Software und Tablets setzen.
Ich denke, das ESU Mobile Control II ist so ein Gerät.
Ansonsten ist das bisher etwas mau.
Zitat - Antwort-Nr.: 29 | Name: xenayoo
Im übrigen sehe ich einen Unterschied bei nutzen können und wirklich nutzen. Es gibt heute, nach über 20 Jahren RailCom-Gerede kein einziges Digitalsystem, welches ‚out-of-the-box‘ RailCom mit allem möglichen Komfort einsetzt.
Definitionssache, was ist 'mit allem möglichen Komfort'.
ESU kann viel, BiDiB hat alles bis auf einen Handregler, Roco funktioniert wohl auch gut, Zimo kann viel. So schlecht sieht das meiner Meinung nach nicht aus.
Grüße
Stephan
Zitat - Antwort-Nr.: 32 | Name: Westerland
Nur ist das Angebot seitdem geradezu explosionsartig gewachsen. Ein großer Teil der Lokdecoder versteht Selectrix und gerade hat ESU sein Angebot an Selectrix fähigen Komponenten erweitert.
Na ja, 'explosionsartig' ordne ich mal Deinen übliche Übertreibungen zu.
Ich sehe bei keinem System einen explosionsartigen Zuwachst, höchsten bei Arduino-Projekten.
Ich denke, der Anteil von SX sinkt, konnte man auch den den Umfragen hier im Forum sehen.
Grüße
Stephan
Zitat - Antwort-Nr.: 27 | Name: haba
Ich mach jede Wette dass die Digitraxdecoder die ich hab und die bei RailCom verwirrt werden einen DCC-kompatibel Stempel besitzen.
Warum sie "aussteigen" weiss ich nicht. Wenn ich aber mal so eine Woche Zeit übrig hab könnte ich eine Testserie anlegen wo man Sachen ausprobiert. Z.B. Präambel nochmal extra verlängern oder den Decodern extra Puffer "draufpappen".
Wäre super, wenn Du das prüfen könntest.
Grüße
Stephan
Zitat - Antwort-Nr.: 38 | Name: maylander
Berichte über Reibereien gab es genüge. In der Mobapresse, in Foren und auch auf den Herstellerwebseiten. In Sachen Rückmeldung gab es zwischen Digitrax und Lenz, sowie Zimo und Lenz Nettigkeiten.
Statt miteneander zu reden haben sie es für alle schwieriger gemacht.
Lange her, war totaler Mist, hat die Verbreitung von Railcom lange blockiert.
Lenz musste auch 'freundlich' darauf hingewiesen werden, dass das Patent nichtig ist, wenn man es prüfen lässt.
Meine Frage bezog sich auf
Zitat - Antwort-Nr.: | Name: maylander
Einen Teil offengelegt um es als Standard durchzusetzen, einen andere Teil ohne Standardisierung nur in die eigenen Produkte eingebaut und bewusst Inkompatibilitäten geschaffen.
Dazu ist mir nichts bekannt.
Zitat - Antwort-Nr.: 38 | Name: maylander
Digitraxdecoder vertragen kein Railcom. Digitrax hat sein Transponding aber auch verpatentiert und nicht freigegeben. Durch die Verbreitung von Digitrax wird sich Railcom in Nordamerika nicht durchsetzen können.
Die Amis hatte ich nicht auf dem Schirm, man möge mir verzeihen.
Zitat - Antwort-Nr.: 38 | Name: maylander
Die Railcommunity ist auch lustig. Der einzige genormte Rückmeldebus ist der
S88-N datiert von 2020
Wurde auch langsam Zeit
Die schon seit vielen Jahren bestehende 'Norm' (http://www.s88-n.eu/) wurde eben offiziell gemacht, mehr nicht.
Das war eine eher leichte Aufgabe.
Zitat - Antwort-Nr.: 38 | Name: maylander
Wieso wird dort kein railcomfähiger Bus spezifiziert? Lenz hat ja nichts brauchbares. Kann man sich wirklich nicht zusammenraufen? Märklin kann daswas Railcom kann schon seit Ewigkeiten.
Um ein Protokoll o.ä. in der Railcommunity zu spezifizieren muss das selbige natürlich frei nutzbar sein. Märklin gibt es nicht frei, wie andere auch.
Hast Du schon mal versucht eine Gruppe mit unterschiedlichen Meinungen und Vorstellungen auf etwas gemeinsames zu vereinigen.
Wenn ja, dann wirst Du bei der Railcommunitiy sicher mit offenen Armen empfangen.
Falls nein, stell es Dir lieber nicht vor, wie das den Alterungsprozess beschleunigt.
Grüße
Stephan
Zitat - Antwort-Nr.: 33 | Name: Teppichbahner
Den Grabenkrieg zwischen DCC und SX kann ja führen wer will. Aber hat der erklärte Ausstieg von Märklin bei SX kein Gewicht bei der zu erwartenden Lebensfähigkeit von SX? Ist Märklin nicht der größte Hersteller ( gewesen )?
In dem Fall wurde SX befreit.
Der Ausstieg war ja schon vor über 20 Jahren.
Dass die neuen Minitrox-Decoder kein SX mehr können halte ich für eine schlechte Entscheidung.
Gab es überhaupt andere Hersteller, die Dekoder mit SX von Haus aus in Fahrzeuge verbaut haben?
Ob tot oder nicht, kann ja jeder sehen wie er will, aber wenn ein großer abspringt, hat das doch auch eine Aussage.
Zitat - Antwort-Nr.: 33 | Name: Teppichbahner
Oder bin ich auf dem falschen Dampfer? Kann ja sein, bin ja "nur Analogi".
Ja, bist Du.
Grüße
Stephan
Moin ste111,
lustig, dass gerade du so eine Aussage machst....
Was passiert denn hier gerade? Wenn ich von SX schreibe, meine ich SX-Systeme mit ihrer heutigen Funktionalität. Das schließt dcc und SX2 mit ein. Die Parallelen zwischen SX2 und dcc sind mir ebenfalls hinreichend bekannt.
Ich spreche hier für mich. In meinen Augen sind heutige SX-Systeme mit die beste Basis, da sie nahezu mit allem umgehen können. Die neue FCCx setzt da sogar noch einen drauf. Was die Grundfunktionalität Fahren, Steuern und Melden angeht, ist es völlig egal, welche SX-Komponenten ich einsetze - es funktioniert.
Das trifft auf die allermeisten dcc-Produkte nicht zu und wird gerne verschwiegen. Da muss man schon genau hinsehen, ob sich die Bus-Module überhaupt einsetzen lassen. Das Problem gibt es bei SX nicht. Alt oder nicht, davon ist dcc Dank vieler konkurrierender Hersteller weit entfernt.
Ich würde Neueinsteigern durchaus zu SX raten, weil es einfach ist, weil es gut funktioniert und weil es eine sehr große Auswahl gibt. Zu sagen, es sei alt, ist ein armes Argument. Es sagt lediglich aus, dass es seit langem nichts Vergleichbares gibt, das einfach funktioniert.
Damit ist nicht gesagt, dass man mit dcc keine Modellbahn steuern kann, das funktioniert zweifelsohne. Jedoch wie man an diesem Faden sehen kann, stellt sich SX-System-Anwendern nicht die unnötige Frage nach einem Bussystem - und das seit mehr als 30 Jahren.
Jens
lustig, dass gerade du so eine Aussage machst....
Zitat - Antwort-Nr.: | Name:
Hast Du schon mal versucht eine Gruppe mit unterschiedlichen Meinungen und Vorstellungen auf etwas gemeinsames zu vereinigen.
Was passiert denn hier gerade? Wenn ich von SX schreibe, meine ich SX-Systeme mit ihrer heutigen Funktionalität. Das schließt dcc und SX2 mit ein. Die Parallelen zwischen SX2 und dcc sind mir ebenfalls hinreichend bekannt.
Ich spreche hier für mich. In meinen Augen sind heutige SX-Systeme mit die beste Basis, da sie nahezu mit allem umgehen können. Die neue FCCx setzt da sogar noch einen drauf. Was die Grundfunktionalität Fahren, Steuern und Melden angeht, ist es völlig egal, welche SX-Komponenten ich einsetze - es funktioniert.
Das trifft auf die allermeisten dcc-Produkte nicht zu und wird gerne verschwiegen. Da muss man schon genau hinsehen, ob sich die Bus-Module überhaupt einsetzen lassen. Das Problem gibt es bei SX nicht. Alt oder nicht, davon ist dcc Dank vieler konkurrierender Hersteller weit entfernt.
Ich würde Neueinsteigern durchaus zu SX raten, weil es einfach ist, weil es gut funktioniert und weil es eine sehr große Auswahl gibt. Zu sagen, es sei alt, ist ein armes Argument. Es sagt lediglich aus, dass es seit langem nichts Vergleichbares gibt, das einfach funktioniert.
Damit ist nicht gesagt, dass man mit dcc keine Modellbahn steuern kann, das funktioniert zweifelsohne. Jedoch wie man an diesem Faden sehen kann, stellt sich SX-System-Anwendern nicht die unnötige Frage nach einem Bussystem - und das seit mehr als 30 Jahren.
Jens
Michael S. - 12.04.21 08:15
Das ist ein wirklich skurriler Vergleich und läuft immer auf die gleiche eingeschränkte Grundannahme hin: ich nehme mein von der Verbreitung her Minisystem und erzürne mich über die Vielfalt und Uneinheitlichkeit der Alternativen.
Was bringt das???
Ich habe hier einen einzigen Beitrag zu einem aktuellen System aus der Praxis gelesen: Das war BidiB mit iTrain und dem Beispiel der drei bzw. vier Triebfahrzeuge in einem Abschnitt.
VG Michael
Was bringt das???
Ich habe hier einen einzigen Beitrag zu einem aktuellen System aus der Praxis gelesen: Das war BidiB mit iTrain und dem Beispiel der drei bzw. vier Triebfahrzeuge in einem Abschnitt.
VG Michael
Westerland - 12.04.21 09:03
Zitat - Antwort-Nr.: | Name:
Na ja, 'explosionsartig' ordne ich mal Deinen übliche Übertreibungen zu.
Ich sehe bei keinem System einen explosionsartigen Zuwachst, höchsten bei Arduino-Projekten.
Ich denke, der Anteil von SX sinkt, konnte man auch den den Umfragen hier im Forum sehen.
Hallo Stephan,
seit der Freigabe von Selectrix durch Märklin/Trix ist das Angebot mindestens um den Faktor 10 gewachsen.
Heute bekomme ich zu jeder Fragestellung ein Angebot von mehreren Anbietern und es ist endlich der Wettbewerb entstanden, den Trix vorher verhindert hat.
Ich steuere meine Züge heute über Funkhandregler mit beleuchtetem Display und habe dabei die Möglichkeit über Taste UND Drehregler zu steuern. Meine Lichtsignale steuere ich über Funktionsdecoder, die ALLE erdenklichen Kominationen darstellen können, das vorbildgerechte Überblenden zwischen den Signalbildern realisieren und sogar die korrekte Dunkeltastung des Vorsignals ermöglichen.
Bei den Lokdecodern kann ich, je nach Anforderung, zwischen verschiedenen Herstellern wählen und die Adressrückmeldung ist über Belegtmelder bei SX längst realisiert.
Natürlich ist es nervig, dass man eine SX-Lok heute nicht mehr in drei Minuten programmieren kann. Im Gegenzug habe ich aber eine Vielzahl schaltbarer Funktionen und kann das Spitzenlicht vorbildgerecht schalten und dimmen!
Zitat - Antwort-Nr.: | Name:
Ich würde Neueinsteigern durchaus zu SX raten, weil es einfach ist, weil es gut funktioniert und weil es eine sehr große Auswahl gibt. Zu sagen, es sei alt, ist ein armes Argument. Es sagt lediglich aus, dass es seit langem nichts Vergleichbares gibt, das einfach funktioniert.
Damit ist nicht gesagt, dass man mit dcc keine Modellbahn steuern kann, das funktioniert zweifelsohne. Jedoch wie man an diesem Faden sehen kann, stellt sich SX-System-Anwendern nicht die unnötige Frage nach einem Bussystem - und das seit mehr als 30 Jahren.
Ich habe in den letzten 20 Jahren eine Vielzahl von SX Digitalsystemen implementiert und glaube sagen zu können, dass alle Anwender bis heute zufrieden sind.
Da bei uns im Nordwesten nahezu alle mir bekannten Modellbahner mit SX unterwegs sind, implementiere ich auch heute noch SX-Datenbusse. Mittlerweile allerdings mit Multiprotokollzentrale, damit auch Gastloks anderer Formate mitfahren können und die erweiterten SX-Parameter wählbar sind.
Viele Grüße,
Mathias
Arnold_Huebsch - 12.04.21 11:19
Folks ein paar Antworten auf das zuvor geschriebene:
mfx in N geht derzeit nicht weil man für die Rückmeldung genaues Timing braucht, OK das könnte man hinbekommen, aber woher soll die Energie für das Senden der RDS Daten kommen. Die Kondensatoren dafür sind einfach zu groß. Trix hat ja explizit verhindert auf der MTC14 Puffer C's anschließen zu können, warum man auch immer zu so einer Entscheidung gelangt ist.
Zur Frage warum man von Mechanischen, Elektromechanischen zu Relais und schließlich zu Computerbasierenden Stellwerken gelangt ist? Ganz simpel die heute gefahrenen Zugfolgen schafft man mit vielen autarken Stellwerken, auf denen jeweils ein Bediener sitzt, nicht. Man ist daher gezwungen weite Strecken, ganze Netze, zentral steuern zu können um diese Leistung zu erreichen. Ohne Zweifel so wie eine Dampflok die 150 Jahre alt ist noch gewartet werden kann, ein ähnlich altes Stellwerk noch immer betrieben wird, wird die heutige Technik für beide Bereiche wohl nicht laufen in einigen Jahren bereits.
Bandbreite der Bussysteme: Ja in Kanal 1 von RailCom hat man 2 Nutzbytes und in Kanal 2 3Bytes. Jede Lok produziert die ersten beiden Bytes auf der Anlage das erhöht die Daten gewaltig. Zusätzlich braucht man zum Übertragen der 5 Bytes wohl etwa die Zeit von 10 Bytes weil man Abstände einhalten muß Frames braucht und Fehlerkorrektur. Kein Hersteller hat es geschafft mit einem der alten Busse RailCom zu implementieren, lediglich seltenes Melden von Decoder Adressen was ja wohl nicht ernst gemeint sein kann als RC Support.
Nein haben keinen Confirmation Test geschafft, schon in den 90'ern nicht als von RC keine Rede war, und das hat die Irelands auch extrem verärgert, weshalb sie zu einer Blockadehaltung übergegangen sind.
SX oder DCC keine Frage beides gute Systeme. Die entscheidende Frage ist haben die Hersteller Vertrauen in ihr eigenes Produkt und entwickeln es weiter. Nein in der SX Welt tun sie es nicht, es wird nur weiter gewurstelt ohne Aussicht auf wirklich Neues. Die Antwort der Anbieter sagt alles über die Zukunftsaussichten. Das im Sinne eines Neuanfangs, also jemand der eine Anlage ohne vorhandenem Material startet. Wo war neues Erweiterungen, abgesehen von Produktwartungen?
Bestandsanlagen zu ändern oder gar abzureißen um einen Systemwechsel zu machen SX --> DCC das ist meiner Einschätzung schlecht beraten. Da empfehle ich dringend bei SX zu bleiben außer es drückt der Schuh gewaltig. Dann ist das aber eine kostspielige Änderung, daher meine Zurückhaltung. Ein Mischbetrieb kostet Ärger in beiden Welten sollte kurz gehalten werden so man sich das überhaupt antun will.
RailCom in der Roco Welt: das geht nur mit einer CAN Bus Infrastruktur, das bedeutet nur mit der schwarzen Z21. Also alle mit z21 sind da nicht dabei.
-AH-
mfx in N geht derzeit nicht weil man für die Rückmeldung genaues Timing braucht, OK das könnte man hinbekommen, aber woher soll die Energie für das Senden der RDS Daten kommen. Die Kondensatoren dafür sind einfach zu groß. Trix hat ja explizit verhindert auf der MTC14 Puffer C's anschließen zu können, warum man auch immer zu so einer Entscheidung gelangt ist.
Zur Frage warum man von Mechanischen, Elektromechanischen zu Relais und schließlich zu Computerbasierenden Stellwerken gelangt ist? Ganz simpel die heute gefahrenen Zugfolgen schafft man mit vielen autarken Stellwerken, auf denen jeweils ein Bediener sitzt, nicht. Man ist daher gezwungen weite Strecken, ganze Netze, zentral steuern zu können um diese Leistung zu erreichen. Ohne Zweifel so wie eine Dampflok die 150 Jahre alt ist noch gewartet werden kann, ein ähnlich altes Stellwerk noch immer betrieben wird, wird die heutige Technik für beide Bereiche wohl nicht laufen in einigen Jahren bereits.
Bandbreite der Bussysteme: Ja in Kanal 1 von RailCom hat man 2 Nutzbytes und in Kanal 2 3Bytes. Jede Lok produziert die ersten beiden Bytes auf der Anlage das erhöht die Daten gewaltig. Zusätzlich braucht man zum Übertragen der 5 Bytes wohl etwa die Zeit von 10 Bytes weil man Abstände einhalten muß Frames braucht und Fehlerkorrektur. Kein Hersteller hat es geschafft mit einem der alten Busse RailCom zu implementieren, lediglich seltenes Melden von Decoder Adressen was ja wohl nicht ernst gemeint sein kann als RC Support.
Zitat - Antwort-Nr.: | Name:
Ich mach jede Wette dass die Digitraxdecoder die ich hab und die bei RailCom verwirrt werden einen DCC-kompatibel Stempel besitzen.
Nein haben keinen Confirmation Test geschafft, schon in den 90'ern nicht als von RC keine Rede war, und das hat die Irelands auch extrem verärgert, weshalb sie zu einer Blockadehaltung übergegangen sind.
SX oder DCC keine Frage beides gute Systeme. Die entscheidende Frage ist haben die Hersteller Vertrauen in ihr eigenes Produkt und entwickeln es weiter. Nein in der SX Welt tun sie es nicht, es wird nur weiter gewurstelt ohne Aussicht auf wirklich Neues. Die Antwort der Anbieter sagt alles über die Zukunftsaussichten. Das im Sinne eines Neuanfangs, also jemand der eine Anlage ohne vorhandenem Material startet. Wo war neues Erweiterungen, abgesehen von Produktwartungen?
Bestandsanlagen zu ändern oder gar abzureißen um einen Systemwechsel zu machen SX --> DCC das ist meiner Einschätzung schlecht beraten. Da empfehle ich dringend bei SX zu bleiben außer es drückt der Schuh gewaltig. Dann ist das aber eine kostspielige Änderung, daher meine Zurückhaltung. Ein Mischbetrieb kostet Ärger in beiden Welten sollte kurz gehalten werden so man sich das überhaupt antun will.
RailCom in der Roco Welt: das geht nur mit einer CAN Bus Infrastruktur, das bedeutet nur mit der schwarzen Z21. Also alle mit z21 sind da nicht dabei.
-AH-
Hallo Arnold,
Das ist so nur für den Schritt Mechanisches Stellwerl zu Relaisstellwerk korrekt. Ein Elektronisches Stellwerk (Computerbasiert) ist nicht schneller (in der Regel eher langsamer) als ein Relaisstellwerk. Die Prozesszeiten mit mehrfacher Validierung mehrerer Rechner dauert in der Regel länger als das Schalten der Relais.
Viele Grüße
Dirk
Zitat - Antwort-Nr.: | Name:
Zur Frage warum man von Mechanischen, Elektromechanischen zu Relais und schließlich zu Computerbasierenden Stellwerken gelangt ist? Ganz simpel die heute gefahrenen Zugfolgen schafft man mit vielen autarken Stellwerken, auf denen jeweils ein Bediener sitzt, nicht.
Das ist so nur für den Schritt Mechanisches Stellwerl zu Relaisstellwerk korrekt. Ein Elektronisches Stellwerk (Computerbasiert) ist nicht schneller (in der Regel eher langsamer) als ein Relaisstellwerk. Die Prozesszeiten mit mehrfacher Validierung mehrerer Rechner dauert in der Regel länger als das Schalten der Relais.
Viele Grüße
Dirk
teppichbahner - 12.04.21 13:00
Zitat
Ganz simpel die heute gefahrenen Zugfolgen schafft man mit vielen autarken Stellwerken, auf denen jeweils ein Bediener sitzt, nicht.
Das ist faktisch schlicht falsch! Die Fahrstraßeneinstellzeiten sind bei Relaisstellwerken deutlich! schneller als bei den "modernen" ESTWs. In Kombination mit Zuglenkung, egal mit Zugnummer oder Lenkziffer, hat man einen Automatisierungsgrad, der der eines ESTWs in nichts nachsteht! Zudem lassen sich auch rechnerbasierte ZL Anlagen auf Relaisstellwerken aufsetzen und zwar ohne jedes Problem, denn der Zuglenkungsteil ist nicht sicherheitsrelevant und kann daher von einem einfachen PC aus erfolgen. Ebenso ist Fernsteuerung bei Relaisstellwerken absolut üblich, Fernsteuerung aus der BZ inklusive!
Übrigens ist das SpDrS600 das schnellste Stellwerk, was je gebaut wurde. Als Nachfolger zum SpDrS60 ist es die letzte Relaisstellwerksbaureihe von Siemens. Die komplette Fahrwegprüfung, Festlegung und Freigabe zur Signalfahrtstellung erfolgt in EINEM Arbeitstakt von 25ms! Ein ESTW braucht da, wenn alle Weichen schon richtig liegen, rund 3 bis 8 Sekunden, je nach Zwischenebenen ( ESTW-A & Co ). Ist Streckenblock involviert, kann es mehrere Minuten dauern! Kein Witz!
Zudem sollte man wissen, daß ein Relaisstellwerk in wenigen Sekunden nach dem Einschalten volle Betriebsbereitschaft hat. Zudem können Teile der Anlage modifiziert werden, während der Rest der Anlage ungestört weiter arbeitet, was für die Nutzung bei Bauzuständen wesentlich ist. Bei ESTW dauert das Neueinspielen einer Anlagenkonfiguration inklusive Distribution der Fahrwegdaten auf die gesteuerten Anlagenteile Stunden! Mal eben eine Weiche "rausnehmen" geht als beim ESTW gar nicht. Daher gibt es heute auch keine Bahnhofsumbauten mehr unter "rollendem Rad". Bei Relaisstellwerken völlig problemlos. Spurkabel abziehen, fertig!
Des weiteren sollte man die Gesamtnutzungsdauer sehen. Relaisstellwerke halten "ewig", entsprechende Wartung vorausgesetzt. Natürlich müssen Ralaiskontakte von Zeit zu Zeit erneuert werden, aber da sprechen wir von Jahrzehnten. Bei einem ESTW ist spätestens nach 20 Jahren Ende. Dann muß die Anlage komplett ersetzt werden! Typischer Weise erreichen ESTW diese Nutzungsdauer aber nicht, weil im Zuge von Umbauten der Außenanlage keine neuen Anlagen-Konfigurationen mehr erstellt werden können und/oder keine neuen Baugruppen für die Anlage mehr verfügbar sind. So wird, nur zum Beispiel, gerade im Bereich Bochum ein ESTW komplett erneuert, weil 2 Weichen für einen neue Gleisverbindung hinzugefügt werden. Bei einem Relaisstellwerk würden die Arbeiten im Stellwerk in wenigen Stunden erfolgt sein. Wäre keine besondere Konfiguration im Stellwerk erforderlich ( Fahrstraßen- und Signalwahl ) würde das zusätzliche Einbauen von 2 Weichen keine 30 Minuten dauern! ( Tischfelder stecken, Leitungen auf Tischverteiler auflegen, Leitung Tischverteiler auf Gestellrahmen auflegen, Gruppen stecken, Spurkabel stecken, 2 * 4 Drähte zu den Weichen anklemmen, prüfen, fertig ).
Nee, Digitaltechnik bringt keinen Vorteil für die Bahn, treibt die Kosten ganz erheblich und führt zu den unglaublich vielen komplett stillgelegten Bahnhöfen bei den Umbauten )
Gruß
Klaus
Beitrag editiert am 12. 04. 2021 13:18.
Servus,
Ich finde ja immer etwas befremdlich warum man die FCC immer noch als SX-Zentrale betrachtet. Da sie ja u.a. MM und DCC kann ist das doch somit auch eine Multiprotokollzentrale, oder?
XpressNet und RailCom (und L-net, meint wohl dann Loconet?) sind originär nicht der SX-Welt entsprungen. Es ist aus meiner Sicht schön das man da mit der FCCx den eingeschlagenen Weg weiter geht, aber das als Begründung für die Weiterentwicklung die Integration von SX-fremden Protocollen anzuführen ist dann irgendwie albern. Sorry.
Generell hab ich den Eindruck das sich D&H schon länger sehr viel breiter aufgestellt hat als es die SX-Kunden so wahrnehmen wollen. Hat der Hersteller ja mit die besten DCC-Decoder am Markt und mittlerweile einen festen Fuß in der Tür bei vielen DCC-Fahrern...
Grüßle
Elvis
Ich finde ja immer etwas befremdlich warum man die FCC immer noch als SX-Zentrale betrachtet. Da sie ja u.a. MM und DCC kann ist das doch somit auch eine Multiprotokollzentrale, oder?
XpressNet und RailCom (und L-net, meint wohl dann Loconet?) sind originär nicht der SX-Welt entsprungen. Es ist aus meiner Sicht schön das man da mit der FCCx den eingeschlagenen Weg weiter geht, aber das als Begründung für die Weiterentwicklung die Integration von SX-fremden Protocollen anzuführen ist dann irgendwie albern. Sorry.
Generell hab ich den Eindruck das sich D&H schon länger sehr viel breiter aufgestellt hat als es die SX-Kunden so wahrnehmen wollen. Hat der Hersteller ja mit die besten DCC-Decoder am Markt und mittlerweile einen festen Fuß in der Tür bei vielen DCC-Fahrern...
Grüßle
Elvis
Beitrag editiert am 12. 04. 2021 13:38.
Naja Elvis,
Das mag man jetzt sehen, wie man will. Die FCC von Doehler&Haass ist zunächst die Erweiterung des SX-Systems. Man kann damit zwar mm, SX2 und dcc ZUSÄTZLICH zu SX1 fahren, aber das Schalten und Melden erfolgt mach wie vor über den SX-Bus.
Die eingehandelten Probleme bei Multiprotokoll, die immer wieder gerne zitiert werden, kann ich nicht nachvollziehen.
Reine SX-Systeme sind nur noch gebraucht erhältlich. Deshalb sind, wenn von SX gesprochen wird, eben jene heute erhältlichen Multiprotokollsysteme gemeint. Im Kern ist die FCC nach wie vor eine SX-Zentrale, die in ihrer neuesten Version um einen zusätzlichen Bus erweitert wurde und auch RailCom kann. Im übrigen kann die FCC per Einstellung zum reinrassigen SX1-System werden. Wenn man von dcc spricht, meint man ja auch heutige Systeme und nicht das Ur-Lenz-System oder Arnold Digital....
Und deshalb ist es - ich muss echt langsam lachen über diesen Ausdruck - nach Meinung der erfahrenen dcc-Propheten , ein ‚sterbendes System‘.
Jens
Das mag man jetzt sehen, wie man will. Die FCC von Doehler&Haass ist zunächst die Erweiterung des SX-Systems. Man kann damit zwar mm, SX2 und dcc ZUSÄTZLICH zu SX1 fahren, aber das Schalten und Melden erfolgt mach wie vor über den SX-Bus.
Die eingehandelten Probleme bei Multiprotokoll, die immer wieder gerne zitiert werden, kann ich nicht nachvollziehen.
Reine SX-Systeme sind nur noch gebraucht erhältlich. Deshalb sind, wenn von SX gesprochen wird, eben jene heute erhältlichen Multiprotokollsysteme gemeint. Im Kern ist die FCC nach wie vor eine SX-Zentrale, die in ihrer neuesten Version um einen zusätzlichen Bus erweitert wurde und auch RailCom kann. Im übrigen kann die FCC per Einstellung zum reinrassigen SX1-System werden. Wenn man von dcc spricht, meint man ja auch heutige Systeme und nicht das Ur-Lenz-System oder Arnold Digital....
Und deshalb ist es - ich muss echt langsam lachen über diesen Ausdruck - nach Meinung der erfahrenen dcc-Propheten , ein ‚sterbendes System‘.
Jens
Hallo zusammen,
Engagierte Diskussion hier. Vielleicht interessiert jemanden, warum jemand sich 2019 für DCC entschieden hat. Folgende Fragen waren zu beantworten:
1. Marktverbreitung, Anbieterzahl, Produktauswahl
2. System-Unterstützung großer Anbieter
3. Situation außerhalb D/EU - hier insbesondere Nordamerika, wo viele Impulse herkommen und Umsätze (und Marktmacht) geschaffen werden
Wer genau liest, wird feststellen, dass technische Festlegungen keine Rolle spielen, sie sind schlichtweg irrelevant im heutigen Umfeld.
Nach über 35jähriger Beschäftigung mit elektronischen Produkten ist (mir) längst klar geworden, dass nicht unbedingt das technisch bessere Produkt sich durchsetzt. Ich lege mehr und mehr Wert auf nichttechnische Entscheidungsfaktoren, siehe oben.
Was nützt mir ein tolles System, welches kaum mehr unterstützt wird. Die Älteren werden noch die VHS - Betamax - System2000 Diskussionen kennen. Wie ist es ausgegangen?
Wieviele Nicht-IBM-PC-Rechnerarchitekturen im PC-Bereich gab es 1982-1990? Wer hat "gewonnen" bzw. den Markt seitdem quasi konkurrenzlos beherrscht?
Ist DCC oder Selectrix besser? Keine Ahnung, ist auch nicht relevant, da keine entscheidenden Unterschiede in der Nutzungsmöglichkeit bestehen.
Dann sind wir wieder bei den Punkten 1-3, und da steht SX einfach nicht mehr gut da.
Darum gab es eine DCC-Startpackung. Eine SX-Startpackung wäre sehr viel schwieriger zu bekommen gewesen, ich hätte damals von keiner gewusst.
VG Mark
Engagierte Diskussion hier. Vielleicht interessiert jemanden, warum jemand sich 2019 für DCC entschieden hat. Folgende Fragen waren zu beantworten:
1. Marktverbreitung, Anbieterzahl, Produktauswahl
2. System-Unterstützung großer Anbieter
3. Situation außerhalb D/EU - hier insbesondere Nordamerika, wo viele Impulse herkommen und Umsätze (und Marktmacht) geschaffen werden
Wer genau liest, wird feststellen, dass technische Festlegungen keine Rolle spielen, sie sind schlichtweg irrelevant im heutigen Umfeld.
Nach über 35jähriger Beschäftigung mit elektronischen Produkten ist (mir) längst klar geworden, dass nicht unbedingt das technisch bessere Produkt sich durchsetzt. Ich lege mehr und mehr Wert auf nichttechnische Entscheidungsfaktoren, siehe oben.
Was nützt mir ein tolles System, welches kaum mehr unterstützt wird. Die Älteren werden noch die VHS - Betamax - System2000 Diskussionen kennen. Wie ist es ausgegangen?
Wieviele Nicht-IBM-PC-Rechnerarchitekturen im PC-Bereich gab es 1982-1990? Wer hat "gewonnen" bzw. den Markt seitdem quasi konkurrenzlos beherrscht?
Ist DCC oder Selectrix besser? Keine Ahnung, ist auch nicht relevant, da keine entscheidenden Unterschiede in der Nutzungsmöglichkeit bestehen.
Dann sind wir wieder bei den Punkten 1-3, und da steht SX einfach nicht mehr gut da.
Darum gab es eine DCC-Startpackung. Eine SX-Startpackung wäre sehr viel schwieriger zu bekommen gewesen, ich hätte damals von keiner gewusst.
VG Mark
Kann mir mal ein Nutzer von Railcom dem praktischen Anwendungsfall erläutern?
Wo sehe ich, dass das Gleis verschmutzt ist und um welche Stelle auf der Anlage es sich handelt?
Welche Dimensionen sind da angegeben?
Wie funktioniert die Positionierung von mehreren Loks/Zügen auf einem Belegtmeldeabschnitt?
Wie erfahre ich, wo sich welche Lok befindet?
Das sind Dinge, die mich viel mehr interessieren, als der Kleinkrieg um Bits und Bytes.
Jürgen H.
Wo sehe ich, dass das Gleis verschmutzt ist und um welche Stelle auf der Anlage es sich handelt?
Welche Dimensionen sind da angegeben?
Wie funktioniert die Positionierung von mehreren Loks/Zügen auf einem Belegtmeldeabschnitt?
Wie erfahre ich, wo sich welche Lok befindet?
Das sind Dinge, die mich viel mehr interessieren, als der Kleinkrieg um Bits und Bytes.
Jürgen H.
Servus Jens,
Genau. Und schon schaut die Welt nicht mehr so schwarz/weiß aus
Soweit ich das sehe kannst du als Gleissignal doch eh nutzen was du willst. Es geht nur um die Rückmeldung und deren Weiterleitung. Und als Bussystem fallen einige der alten Systeme stumpf irgendwann raus bzw. unterstützen halt nur rudimentäre Funktionen. Das mag noch eine Weile reichen, aber die Propheten haben das Land schon lange verlassen. Der neue, heiße Scheiß spielt sich woanders ab.
Grüßle
Elvis
Zitat - Antwort-Nr.: | Name:
Reine SX-Systeme sind nur noch gebraucht erhältlich. Deshalb sind, wenn von SX gesprochen wird, eben jene heute erhältlichen Multiprotokollsysteme gemeint
Genau. Und schon schaut die Welt nicht mehr so schwarz/weiß aus
Soweit ich das sehe kannst du als Gleissignal doch eh nutzen was du willst. Es geht nur um die Rückmeldung und deren Weiterleitung. Und als Bussystem fallen einige der alten Systeme stumpf irgendwann raus bzw. unterstützen halt nur rudimentäre Funktionen. Das mag noch eine Weile reichen, aber die Propheten haben das Land schon lange verlassen. Der neue, heiße Scheiß spielt sich woanders ab.
Grüßle
Elvis
Westerland - 12.04.21 15:16
Zitat - Antwort-Nr.: | Name:
Dann sind wir wieder bei den Punkten 1-3, und da steht SX einfach nicht mehr gut da.
Hallo Mark,
wie kommst Du zu dieser Erkenntnis? Ich habe bei SX ein viel breiteres Angebot als für so manchen DCC-Datenbus.
Das Gleisprotokoll ist mittlerweile wurscht; da hat DCC den Vorsprung von SX lange aufgeholt. Was aber ist mit den vielen Datenbussen bei DCC? Empfinde das Angebot für so manchem davon keineswegs als ausreichend!
Für den SX-Datenbus gibt es aber nun wirklich ausreichend Material von verschiedenen Anbietern.
Viele Grüße,
Mathias
Mathias,
außerhalb Europas, wenn nicht gar nur Deutschlands spielt SX quasi keine Rolle. In sofern hat Jürgen recht.
Nur anders als im Videobereich sind die Modellbahnmärkte oft nur lokal. Hier interessieren sich nur wenige für beispielsweise japanische Eloks oder US-Amerikanische Zugkompsitionen. Deshalb ist es schlicht egal, ob in den USA dcc den Ton angibt oder nicht - es hat keinen Einfluss auf unseren Binnenmarkt. Das jührt Jürgens Argumente ad Absurdum.
Jeder darf seine eigene Sichtweise haben, und wenn Jürgens Digitalkomponenten auf dem Internationalen Markt erhältlich sein müssen, fällt SX eben raus - und nicht nur SX sondern auch fast alle localen dcc-Angebote. Das aber nur am Rande...😉
Jens
außerhalb Europas, wenn nicht gar nur Deutschlands spielt SX quasi keine Rolle. In sofern hat Jürgen recht.
Nur anders als im Videobereich sind die Modellbahnmärkte oft nur lokal. Hier interessieren sich nur wenige für beispielsweise japanische Eloks oder US-Amerikanische Zugkompsitionen. Deshalb ist es schlicht egal, ob in den USA dcc den Ton angibt oder nicht - es hat keinen Einfluss auf unseren Binnenmarkt. Das jührt Jürgens Argumente ad Absurdum.
Jeder darf seine eigene Sichtweise haben, und wenn Jürgens Digitalkomponenten auf dem Internationalen Markt erhältlich sein müssen, fällt SX eben raus - und nicht nur SX sondern auch fast alle localen dcc-Angebote. Das aber nur am Rande...😉
Jens
@Jürgen,
Als Corona Wiedereinsteiger, bin ich gerade selbst dabei meine MoBa rundum zu digitalisieren.
Auf Deine Frage zu Railcom kann ich Dir aus meiner Laienhaften Sicht sagen, dass Du bei Railcom die Möglichkeit hast die Parameter-Daten der Lok Bidirektional auszutauschen.
Beispiel:
Du hast eine Pendelstrecke, normal würde Dir ein Melder sagen: nun ist eine Lok irgendwo im Abschnitt XY.
Bei Railcom sagt die Lok zudem selbst welche es ist, wo dort, wie schnell Sie ist, welchen Bremsweg Sie hat.
Die Steuerungssoftware muss daher nur die Informationen verarbeiten um die Lok platzgenau zu Bremsen.
Das geht auch ohne Railcom, dann müssen aber über die Steuer-SW Messungen mit Messfahrten gemacht werden etc. Manchmal verschätzt sich diese Berechnung.
Gruß,
Robert
Als Corona Wiedereinsteiger, bin ich gerade selbst dabei meine MoBa rundum zu digitalisieren.
Auf Deine Frage zu Railcom kann ich Dir aus meiner Laienhaften Sicht sagen, dass Du bei Railcom die Möglichkeit hast die Parameter-Daten der Lok Bidirektional auszutauschen.
Beispiel:
Du hast eine Pendelstrecke, normal würde Dir ein Melder sagen: nun ist eine Lok irgendwo im Abschnitt XY.
Bei Railcom sagt die Lok zudem selbst welche es ist, wo dort, wie schnell Sie ist, welchen Bremsweg Sie hat.
Die Steuerungssoftware muss daher nur die Informationen verarbeiten um die Lok platzgenau zu Bremsen.
Das geht auch ohne Railcom, dann müssen aber über die Steuer-SW Messungen mit Messfahrten gemacht werden etc. Manchmal verschätzt sich diese Berechnung.
Gruß,
Robert
Servus Mathias,
was genau ist ein DCC-Datenbus?
Zwar gibt es Zentralen die DCC (Gleissignal) und einen anderen Bus (Rückmeldung/Handregler) zusammen bringen, aber das macht das eine nicht zum anderen. Wenn jetzt das FCCx XPressNet oder Loconet (immer noch ?) implementiert wird da ja auch nicht automatisch ein SX-Bus daraus, oder?
Oder etwa doch?
Grüßle
Elvis
was genau ist ein DCC-Datenbus?
Zwar gibt es Zentralen die DCC (Gleissignal) und einen anderen Bus (Rückmeldung/Handregler) zusammen bringen, aber das macht das eine nicht zum anderen. Wenn jetzt das FCCx XPressNet oder Loconet (immer noch ?) implementiert wird da ja auch nicht automatisch ein SX-Bus daraus, oder?
Oder etwa doch?
Grüßle
Elvis
Beitrag editiert am 12. 04. 2021 16:41.
LaNgsambahNer - 12.04.21 15:47
Moin,
Ich denke mal das das die US-Bahner hierzulande (und in Europa) gaaanz anders sehen.... und das sind nicht wenige.
Gruß Kai☕
Zitat - Antwort-Nr.: | Name:
Deshalb ist es schlicht egal, ob in den USA dcc den Ton angibt oder nicht - es hat keinen Einfluss auf unseren Binnenmarkt. Das jührt Jürgens Argumente ad Absurdum.
Ich denke mal das das die US-Bahner hierzulande (und in Europa) gaaanz anders sehen.... und das sind nicht wenige.
Gruß Kai☕
Hallo,
wenn man wollte, könnte man das SX-System auch mal weiter entwickeln.
Spezifikation von:
- Alternativen zum DIN Stecker
- SX-over-IP
- Nutz- und Steuerdaten (Protokollimplementation)
- Handreglersteuerung (Adresse, Protokoll, Fahrstufen)
- Lokdecoder-Programmierung (SX1, SX2-Parameter, DCC-CV, DCC-PoM)
- Zentralendaten (Gleisspannung, Stromverbrauch, Temperatur)
- Lokdaten wie Lokname, Funktionstasten-Symbol/Beschreibung, Fahrstufe (Soll/Ist), Motorstrom, Temperatur
- Spezifikation eines Rahmens für zusätzliche Datenübertragungen (Auxiliary Payload), ähnlich wie die Multiprotokoll-Erweiterungen beim Gleissignal
Das ist bislang alles in den oberen Kanälen irgendwie hingeschustert und nicht öffentlich dokumentiert oder genormt.
Die Handregleranbindung sollte besser über USB oder LAN und/oder WLAN erfolgen, statt dem ganzen proprietärem Bus- und Steckergedöns (SX, RMX, PX, MX, ...).
Ich weiß das kostet alles, aber wenn ein System überleben kann, dann in einem Qualitätssegment. Der Massenmarkt wird sowieso von den großen Herstellern bedient.
Grüße, Peter W.
wenn man wollte, könnte man das SX-System auch mal weiter entwickeln.
Spezifikation von:
- Alternativen zum DIN Stecker
- SX-over-IP
- Nutz- und Steuerdaten (Protokollimplementation)
- Handreglersteuerung (Adresse, Protokoll, Fahrstufen)
- Lokdecoder-Programmierung (SX1, SX2-Parameter, DCC-CV, DCC-PoM)
- Zentralendaten (Gleisspannung, Stromverbrauch, Temperatur)
- Lokdaten wie Lokname, Funktionstasten-Symbol/Beschreibung, Fahrstufe (Soll/Ist), Motorstrom, Temperatur
- Spezifikation eines Rahmens für zusätzliche Datenübertragungen (Auxiliary Payload), ähnlich wie die Multiprotokoll-Erweiterungen beim Gleissignal
Das ist bislang alles in den oberen Kanälen irgendwie hingeschustert und nicht öffentlich dokumentiert oder genormt.
Die Handregleranbindung sollte besser über USB oder LAN und/oder WLAN erfolgen, statt dem ganzen proprietärem Bus- und Steckergedöns (SX, RMX, PX, MX, ...).
Ich weiß das kostet alles, aber wenn ein System überleben kann, dann in einem Qualitätssegment. Der Massenmarkt wird sowieso von den großen Herstellern bedient.
Grüße, Peter W.
Michael S. - 12.04.21 16:26
Das ist ja gruseliger, als ich dachte.
Na dann, zurück in die Zukunft! Natürlich per Bus!
VG Michael
Na dann, zurück in die Zukunft! Natürlich per Bus!
VG Michael
Christian69 - 12.04.21 16:44
Hallo Peter,
für die Besitzer der Rautenhaus RMX950(7)USB und PC-Zentrale (Software) wird es dieses Jahr noch ein Update geben.
- Einbindung der WlanMaus von Fleischmann als Handregler
- Komplette Übernahme der vorhandenen Loks aus der PC-Zentrale, egal welches Protokoll
- Erweiterte Funktionstasten F1-F28
Ich baue zur Zeit an einer großen Anlage und betreibe diese mit dem SX-BUS unter Verwendung von TC und möchte schon bezüglich der Verdrahtung und den speziellen Anforderungen bei DCC nicht auf einen anderen BUS wechseln.
164 Weichen
30x 2-fach Weichendecoder
15x 8-fach Weichendecoder (inkl. 14 Servos für Schuppentorantriebe)
64x 8-fach Belegmelder
3 Kehrschleifenmodule mit Sensorgleis
2x Dual Frog Juicer (für die zwei Hosenträger)
14x 16-fach Lichtsignaldecoder mit Zusatzplatinen
1x Drehscheibensteuerung (-umbausatz)
9 Booster
Grüße
Christian
für die Besitzer der Rautenhaus RMX950(7)USB und PC-Zentrale (Software) wird es dieses Jahr noch ein Update geben.
- Einbindung der WlanMaus von Fleischmann als Handregler
- Komplette Übernahme der vorhandenen Loks aus der PC-Zentrale, egal welches Protokoll
- Erweiterte Funktionstasten F1-F28
Ich baue zur Zeit an einer großen Anlage und betreibe diese mit dem SX-BUS unter Verwendung von TC und möchte schon bezüglich der Verdrahtung und den speziellen Anforderungen bei DCC nicht auf einen anderen BUS wechseln.
164 Weichen
30x 2-fach Weichendecoder
15x 8-fach Weichendecoder (inkl. 14 Servos für Schuppentorantriebe)
64x 8-fach Belegmelder
3 Kehrschleifenmodule mit Sensorgleis
2x Dual Frog Juicer (für die zwei Hosenträger)
14x 16-fach Lichtsignaldecoder mit Zusatzplatinen
1x Drehscheibensteuerung (-umbausatz)
9 Booster
Grüße
Christian
Zitat - Antwort-Nr.: 59 | Name:
War wohl weniger Jürgen, als ich
Du schaffst es aber auch wirklich, die Argumentation ins absurde umzudrehen
Schon mal was von Versorgungssicherheit gehört? Ein international verbreiteter Standard gibt mir als Kunden die Sicherheit auch bei Ausfall lokaler Lieferanten weiter das System unterhalten zu können.
Nebeneffekte können bessere Preise durch höhere Stückzahlen sein.
Im übrigen bin ich ganz froh, dass es Zimo, Roco, Peco, usw. gibt, sonst würde meine Anlage ganz anders aussehen. Soviel zum Thema ich wäre hier Nationalist.
Aber klar, man kann Argumente natürlich auch absichtlich Missverstehen wollen.
VG Mark
LaNgsambahNer - 12.04.21 17:20
Moin Mark,
nicht aufregen....😎 Hier wird sich regelmäßig zerfleischt wenn es um SX vs. DCC geht.
Und es sind immer dieselben Protagonisten.
Also, keep cool und trink ´n 🍺
Gruß Kai😁🍺
nicht aufregen....😎 Hier wird sich regelmäßig zerfleischt wenn es um SX vs. DCC geht.
Und es sind immer dieselben Protagonisten.
Also, keep cool und trink ´n 🍺
Gruß Kai😁🍺
Zitat - Antwort-Nr.: 58 | Name:
Hallo Mathias,
Das bestreite ich gar nicht bzw. habe ich auch festgestellt. Es ist aber doch natürlich, dass für ein derartig lange existierendes System selbst für ungewöhnliche Probleme Lösungen existieren.
Aber das finde ich eine gewisse Stärke von DCC: es können unterschiedliche Bus-Systeme entwickelt werden, alle mit unterschiedlichen Stärken und Schwächen. Der PC hat wahrscheinlich nur wegen solcher Flexibilität seit über 30 Jahren überlebt.
Wenn die Nachfrage nach bestimmten Komponenten groß genug ist, wird jemand ein entsprechendes Angebot entwickeln. Oder der Kunde kann doch auf SX ausweichen - oder?
Immerhin scheinen ja die SX-Hersteller mittlerweile selbst DCC-Busse zu integrieren - siehe FCCx. Bei D&H als SX-Erfinder scheint man viel pragmatischer zu sein als so mancher hier im Forum.
VG Mark
Zitat - Antwort-Nr.: 67 | Name:
Hallo Kai,
Danke, bin ganz entspannt - ein Bierchen geht natürlich immer ☺️🍻
Ich bin aber ein Freund der Tatsache, den anderen in Diskussionen nicht grundsätzlich Missverstehen zu wollen.
In diesem Sinne - Prosit 😊
Zitat - Antwort-Nr.: 63 | Name: Peter W.
wenn man wollte, könnte man das SX-System auch mal weiter entwickeln.
Zitat - Antwort-Nr.: 63 | Name: Peter W.
Das ist bislang alles in den oberen Kanälen irgendwie hingeschustert und nicht öffentlich dokumentiert oder genormt.
Hallo Peter,
du bist etwas voreilig mit deinen Schlussfolgerungen, die öfters schon korrigiert werden mußten.
Warum informierst du dich nicht zu einem Thema, wenn du den Oberlehrer spielen möchtest.
Das was du in deinem Post in deiner Aufstellung aufzählst ist doch bei D&H dokumentiert.
Link: https://doehler-haass.de/cms/pages/system-spezifikation.php
Hast du überhaupt Erfahrung theoretisch oder praktisch mit SX (System/Bus)???
Du favorisierst DCC als Allrounder - kannst du bitte erläutern, wieviel Komponenten bei verschiedenen DCC-Herstellern miteinander kompatibel sind???
Das Forum ist doch voll von Hilferufen zu den Inkompatibilitäten bei DCC und der Busstruktur.
Was möchtest du den SX-Nutzern eigentlich mitteilen? Und wieso stagniert es im SX-Sektor.
Bluetooth Handregler, Android-Fahrregler für Smartphone, WLAN Funkhandregler und als Steckergedöns gibt es die RJ45 Busverkabelung.
Anmerkungen
hajo
Hallo,
Ich fahre mit Rocrail und dort gibt es eine Infoausgabe als Log. Da steht sinngemäß für jeden befahrenen Abschnitt:
Abschnit xyz, DCC-Adresse 45, Signal Quality 8
Ist die Zahl zu hoch, sollte da mal sauber gemacht werden. Was fehlt (und schön wäre), wäre eine entsprechende optische Aufbereitung auf dem Gleisplan bzw. eine Tabelle mit absteigender Qualität, so dass die "dreckigsten" Gleise oben stehen. Die Daten wären nach einer Weile Laufzeit da, lediglich die Aufbereitung fehlt hier. Durch beobachten des Logs geht das aber auch so.
Die Auflösung der Meldung ist effektiv ein Belegtmelder-Abschnitt. Sind dort mehrere Loks vorhanden, so werden im BiDiB-Monitor entsprechend mehrere Adressen angezeigt - ob das auch in Rocrail der Fall wäre, weiß ich nicht, da ich den UseCase bei mir nicht habe.
Stelle ich eine Lok auf ein Gleis, so wird mir angezeigt, welche das ist (sofern RR eine entsprechende Lok registriert hat). Der BiDiB-Monitor zeigt mir alternativ direkt die Adresse an, was ganz praktisch ist bei neuen/unbekannten Loks
Grüße Micha
Zitat - Antwort-Nr.: 56 | Name:
Kann mir mal ein Nutzer von Railcom dem praktischen Anwendungsfall erläutern?
Wo sehe ich, dass das Gleis verschmutzt ist und um welche Stelle auf der Anlage es sich handelt?
Welche Dimensionen sind da angegeben?
Wie funktioniert die Positionierung von mehreren Loks/Zügen auf einem Belegtmeldeabschnitt?
Wie erfahre ich, wo sich welche Lok befindet?
Das sind Dinge, die mich viel mehr interessieren, als der Kleinkrieg um Bits und Bytes.
Ich fahre mit Rocrail und dort gibt es eine Infoausgabe als Log. Da steht sinngemäß für jeden befahrenen Abschnitt:
Abschnit xyz, DCC-Adresse 45, Signal Quality 8
Ist die Zahl zu hoch, sollte da mal sauber gemacht werden. Was fehlt (und schön wäre), wäre eine entsprechende optische Aufbereitung auf dem Gleisplan bzw. eine Tabelle mit absteigender Qualität, so dass die "dreckigsten" Gleise oben stehen. Die Daten wären nach einer Weile Laufzeit da, lediglich die Aufbereitung fehlt hier. Durch beobachten des Logs geht das aber auch so.
Die Auflösung der Meldung ist effektiv ein Belegtmelder-Abschnitt. Sind dort mehrere Loks vorhanden, so werden im BiDiB-Monitor entsprechend mehrere Adressen angezeigt - ob das auch in Rocrail der Fall wäre, weiß ich nicht, da ich den UseCase bei mir nicht habe.
Stelle ich eine Lok auf ein Gleis, so wird mir angezeigt, welche das ist (sofern RR eine entsprechende Lok registriert hat). Der BiDiB-Monitor zeigt mir alternativ direkt die Adresse an, was ganz praktisch ist bei neuen/unbekannten Loks
Grüße Micha
Das sollte mit Weg-Zeit Berechnung noch feiner gehen. Wenn man einen Gleisplan im CAD hat sollte man dann sogar mit den Daten die Dreckstellen "einfärben" können.
Grüße,
Harald.
Hallo,
@Robert#60:
Das mit dem Einmessen ist so, keine Frage.
Aber was wird wo verschätzt? Dafür hätte ich gerne Belege!
Unter TrainController funktioniert das einwandfrei.
LG
Günter
@Robert#60:
Zitat - Antwort-Nr.: | Name:
dann müssen aber über die Steuer-SW Messungen mit Messfahrten gemacht werden etc. Manchmal verschätzt sich diese Berechnung.
Das mit dem Einmessen ist so, keine Frage.
Aber was wird wo verschätzt? Dafür hätte ich gerne Belege!
Unter TrainController funktioniert das einwandfrei.
LG
Günter
Hallo miteinander
@Micha
Verwendest Du auch die Info über die Ist-Geschwindigkeit? Und ist damit die Fahrstufe gemeint oder die tatsächliche Geschwindigkeit des Modells?
@xenayoo
Es gibt noch eine reine SX Zentrale neu zu kaufen: Stärz ZS1.
@Arfman
XpressNet-Adapter gibt es schon seit Mitte 2012. Das ist nichts neues mehr im Selectrix-Bereich.
Griessli
Tipsi
@Micha
Verwendest Du auch die Info über die Ist-Geschwindigkeit? Und ist damit die Fahrstufe gemeint oder die tatsächliche Geschwindigkeit des Modells?
@xenayoo
Es gibt noch eine reine SX Zentrale neu zu kaufen: Stärz ZS1.
@Arfman
XpressNet-Adapter gibt es schon seit Mitte 2012. Das ist nichts neues mehr im Selectrix-Bereich.
Griessli
Tipsi
Hallo Hajo,
zum den Specs möchte ich nur anmerken, dass ich mit SX-ern in Kontakt bin und mit Herstellern. Ich weiß schon, dass da auch nicht immer alles miteinander kann, vor allem wenn der eine oder andere Hersteller mal einen Vorstoß in eine nicht akkordierte Erweiterung macht, z.B. bei der Anzahl der Funktionstasten. Hier gab es wohl Missverständnisse.
Mir persönlich bekannte SXer lehnen RJ45 als SX-Bus strikt ab, wegen der Verwechslungsgefahr. Wenn ich dann hin so manche Zentrale hinein schaue (für einen Anbieter habe ich mal die Schaltung zur Q/A reverse engineered) dann graut es mir beim Gedanken dass ein DAU vielleicht mal ein Ethernet - womöglich mit aktivem PoE - an den SX Bus (genauso wie auch RJ45-S88N) anschließt. Dann knallt und raucht es. Das ist genau so wie die häufigen Warnungen vor der Verwechslungsgefahr zwischen den "Telefonkabel" basierten Xpressnet und Loconet Bussen. Das muss man nicht nochmals nachmachen.
Eine Garantie für die Richtigkeit und Gültigkeit der verlinkten Spezifikationen wird von DH selbst ausgeschlossen. Steht so auf der genannten Seite. Was habe ich als Entwickler dann davon, wenn der Hersteller mit seine Daten nicht garantiert und ich das nachfragen muss? In Tests hat sich gezeigt, dass sich DH in der Tat selbst nicht immer an diese Spezifikationen gehalten hat. Unterschiedliche Zentralen wie auch unterschiedlich ASIC Versionen haben unterschiedliches Timing und rein softwarebasierte Decoder ebenso. Und da spreche ich jetzt nur von Fahrzeugdecodern, da ich mich ich mich mit Zubehörgeräten noch gar nicht richtig auseinander gesetzt habe.
Und ja, ich favorisiere für mich und meine Tätigkeit - privat, non-profit und business - immer DCC (why not?), bin aber für jede Art von heterogenen Systemen offen. Gekocht wird immer nur mit Wasser, es besteht im allgemeinen aus H2O, auch wenn mancher vielleicht Goldquelle drauf schreibt.
BT-Handregler & Co: Wenn man etwas am Leben halten will muss man es promoten und supporten. Es nützt nichts wenn es theoretisch etwas gibt, aber niemand kennt es? DH kann ich mitlerweile in jedem besseren Moba Laden kaufen, zumindest auf Bestellung,. Die anderen Produkte habe ich schon lange nicht mehr aktiv beworben gesehen. Aus den Augen, aus dem Sinn - also sorry falls ich etwas zu sehr auf die Tube gedrückt habe, es soll ein Diskussions- und Denkanstoss sein!
Grüße, Peter W:
zum den Specs möchte ich nur anmerken, dass ich mit SX-ern in Kontakt bin und mit Herstellern. Ich weiß schon, dass da auch nicht immer alles miteinander kann, vor allem wenn der eine oder andere Hersteller mal einen Vorstoß in eine nicht akkordierte Erweiterung macht, z.B. bei der Anzahl der Funktionstasten. Hier gab es wohl Missverständnisse.
Mir persönlich bekannte SXer lehnen RJ45 als SX-Bus strikt ab, wegen der Verwechslungsgefahr. Wenn ich dann hin so manche Zentrale hinein schaue (für einen Anbieter habe ich mal die Schaltung zur Q/A reverse engineered) dann graut es mir beim Gedanken dass ein DAU vielleicht mal ein Ethernet - womöglich mit aktivem PoE - an den SX Bus (genauso wie auch RJ45-S88N) anschließt. Dann knallt und raucht es. Das ist genau so wie die häufigen Warnungen vor der Verwechslungsgefahr zwischen den "Telefonkabel" basierten Xpressnet und Loconet Bussen. Das muss man nicht nochmals nachmachen.
Eine Garantie für die Richtigkeit und Gültigkeit der verlinkten Spezifikationen wird von DH selbst ausgeschlossen. Steht so auf der genannten Seite. Was habe ich als Entwickler dann davon, wenn der Hersteller mit seine Daten nicht garantiert und ich das nachfragen muss? In Tests hat sich gezeigt, dass sich DH in der Tat selbst nicht immer an diese Spezifikationen gehalten hat. Unterschiedliche Zentralen wie auch unterschiedlich ASIC Versionen haben unterschiedliches Timing und rein softwarebasierte Decoder ebenso. Und da spreche ich jetzt nur von Fahrzeugdecodern, da ich mich ich mich mit Zubehörgeräten noch gar nicht richtig auseinander gesetzt habe.
Und ja, ich favorisiere für mich und meine Tätigkeit - privat, non-profit und business - immer DCC (why not?), bin aber für jede Art von heterogenen Systemen offen. Gekocht wird immer nur mit Wasser, es besteht im allgemeinen aus H2O, auch wenn mancher vielleicht Goldquelle drauf schreibt.
BT-Handregler & Co: Wenn man etwas am Leben halten will muss man es promoten und supporten. Es nützt nichts wenn es theoretisch etwas gibt, aber niemand kennt es? DH kann ich mitlerweile in jedem besseren Moba Laden kaufen, zumindest auf Bestellung,. Die anderen Produkte habe ich schon lange nicht mehr aktiv beworben gesehen. Aus den Augen, aus dem Sinn - also sorry falls ich etwas zu sehr auf die Tube gedrückt habe, es soll ein Diskussions- und Denkanstoss sein!
Grüße, Peter W:
@Günter
Das liegt auf der Hand.
Änderst Du den Bremsweg an der Lok ohne Railcom, bekommt das eine SW wie TC ohne erneute Messfahrten nicht mit. Wie bekommt es TC mit, wenn Haftreifen nach Verschleiß nicht mehr gut greifen? Oder die Differenz bei verschmutzen und sauberen Gleisen?
Das liegt auf der Hand.
Änderst Du den Bremsweg an der Lok ohne Railcom, bekommt das eine SW wie TC ohne erneute Messfahrten nicht mit. Wie bekommt es TC mit, wenn Haftreifen nach Verschleiß nicht mehr gut greifen? Oder die Differenz bei verschmutzen und sauberen Gleisen?
Westerland - 13.04.21 08:23
Hallo Peter,
entschuldige, aber so das Satire sein? Mir persönlich bekannte SXler nutzen den RJ45, weil weltweit genormt, günstig verfügbar und gut. Ich nutze den auch und würde mir wünschen, dass ALLE Komponenten damit ausgerüstet werden!
Zitat - Antwort-Nr.: | Name:
BT-Handregler & Co: Wenn man etwas am Leben halten will muss man es promoten und supporten. Es nützt nichts wenn es theoretisch etwas gibt, aber niemand kennt es?
Wer DCC nutzt, kennt es nicht. Wer mit Selectrix unterwegs ist, schon. Bei unserem Bremer Stammtisch sind die Produkte sogar im Einsatz...
Besonders hervorheben möchte ich an dieser Stelle den Service von Anbietern wie Stärz Modellbahnelektronik, Rautenhaus oder Doehler & Haass sowie die Selectrix Gemeinde im Osten Deutschlands.
Bei mir blieb da nie eine Frage unbeantwortet.
Viele Grüße,
Mathias
Zitat - Antwort-Nr.: | Name:
Änderst Du den Bremsweg an der Lok ohne Railcom, bekommt das eine SW wie TC ohne erneute Messfahrten nicht mit. Wie bekommt es TC mit, wenn Haftreifen nach Verschleiß nicht mehr gut greifen? Oder die Differenz bei verschmutzen und sauberen Gleisen?
Der Bremsweg einer Lok wird in TC ganz bequem mit einem Schieberegler geändert, nicht im Decoder.
Wie bekommt Railcom mit, wenn es Schlupf am Gleis gibt?
Bei verschmutzten Gleisen geht es digital zu, entweder Lok fährt, oder Lok steht.
Da bei TC mit jeder Meldestelle die Weg-Zeit Berechnung neu beginnt, interessiert Schlupf oder Schmutz im Block vorher nicht.
Die genaue Position ist überhaupt nur interessant, wenn angehalten werden soll. Dann wird üblicherweise gebremst und Schlupf tritt gar nicht auf.
Ich nutze nun schon seit Beginn der Wegberechnung, also der virtuellen Melder, TC und habe eine Genauigkeit von einem cm, auch mit Loks ohne Haftreifen. Mir würde Railcom o.ä. gar keinen Vorteil bringen.
Jürgen H.
Hallo,
wir sind ‚ein wenig‘ abgekommen, von der Frage nach dem richtigen Bus-System. Lag auch an mir.
Nun zeigt sich aber deutlich, dass sehr viele gar nicht wissen, wofür RailCom eigentlich da ist. Der Beitrag zuvor vo Jürgen zeigt das ganz deutlich. Alle reden seit mehr als 20 Jahren davon, aber keiner weiß wirklich, was es kann - auch ich nicht.
Klar, dass die heutige Software sich mit ihren Algorithmen sich auf die Steuerung ohne RC spezialisiert hat. Welche Gründe die Ablehnung von RC bei Freiwald genau hat, liegt im Bereich der Spekulation.
Was sich für mich bisher herauskristallisiert hat: RC ist zunächst ganz banal die aktive Rückmeldung eines Dekoders - und das Protokollunabhängig. Das heißt, RailCom ist kein dcc-Feature. Damit kann man Protokollunabhängig Dekoder leichter Programmieren. Eine Zentrale muss dann nicht mer AK-Impulse interpretieren. Weiter kann ein System damit feststellen, welche Lok in welcher Richtung wo steht. Wenn ich den Faden mal weiterspinne und z.B. Weichen mit einem stellungsabhängigen Schalter ausgestattet sind, würde das System sogar manuell umgestellte Weichen bemerken.
Wie gesagt. Ich weiß auch nicht alles über RC. Nur dass es eine Menge Möglichkeiten für mehr Komfort bietet und jede Menge Dinge, an die ich noch gar nicht gedacht habe. Vielleicht sollten wir einen Faden aufmachen, wo wir mal Möglichkeiten von RC, Wünsche und Lösungen erarbeiten.
Jens
wir sind ‚ein wenig‘ abgekommen, von der Frage nach dem richtigen Bus-System. Lag auch an mir.
Nun zeigt sich aber deutlich, dass sehr viele gar nicht wissen, wofür RailCom eigentlich da ist. Der Beitrag zuvor vo Jürgen zeigt das ganz deutlich. Alle reden seit mehr als 20 Jahren davon, aber keiner weiß wirklich, was es kann - auch ich nicht.
Klar, dass die heutige Software sich mit ihren Algorithmen sich auf die Steuerung ohne RC spezialisiert hat. Welche Gründe die Ablehnung von RC bei Freiwald genau hat, liegt im Bereich der Spekulation.
Was sich für mich bisher herauskristallisiert hat: RC ist zunächst ganz banal die aktive Rückmeldung eines Dekoders - und das Protokollunabhängig. Das heißt, RailCom ist kein dcc-Feature. Damit kann man Protokollunabhängig Dekoder leichter Programmieren. Eine Zentrale muss dann nicht mer AK-Impulse interpretieren. Weiter kann ein System damit feststellen, welche Lok in welcher Richtung wo steht. Wenn ich den Faden mal weiterspinne und z.B. Weichen mit einem stellungsabhängigen Schalter ausgestattet sind, würde das System sogar manuell umgestellte Weichen bemerken.
Wie gesagt. Ich weiß auch nicht alles über RC. Nur dass es eine Menge Möglichkeiten für mehr Komfort bietet und jede Menge Dinge, an die ich noch gar nicht gedacht habe. Vielleicht sollten wir einen Faden aufmachen, wo wir mal Möglichkeiten von RC, Wünsche und Lösungen erarbeiten.
Jens
Zitat - Antwort-Nr.: | Name:
...Weichen mit einem stellungsabhängigen Schalter ausgestattet sind, würde das System sogar manuell umgestellte Weichen bemerken.
Manuell umstellen bei Servoantrieb, oder am Magnetantriebshebelchen bei Unterflurmontage ist schon schwierig.
Wenn man mit manuell meint, an einem Stellpult, oder Eingabegerät des Digitalsystems, so ist das bei SX schon immer rückgemeldet und TC verarbeitet das auch, sprich zeigt mir die Weichenstellung an.
Das ist nicht bei allen Systemen so (bin aber nicht auf dem neuesten Stand) und vielleicht auch nicht bei allen Steuerprogrammen.
Eine Anmeldung einer Lok, wie bei Mfx, hört sich auch zunächst ganz gut an. Der Aufwand, diese Lok in der Software einzurichten bleibt aber, nach derzeitgem Stand, gleich.
Ist eine Lok einmal in der Datenbank und einem Block erfasst, brauche ich keine Anmeldung und auch keine Fahrtrichtungsmeldung mehr.
Vorstellbar wäre, Falschfahrten anhand der gemeldeten Lok-ID schneller zu erkennen und einen Nothalt auszuführen, wenn die Lok unerwartet in einem anderen Block auftaucht.
Das ist aber dann etwas, was Herr Freiwald wohl so kommentieren würde : Einen Hardwarefehler (falsch gestellte Weiche) mit Software kompensieren wollen.
Ich will hier aber auch den Fortschritt nicht dadurch bremsen, dass ich meine vollkommene Zufriedenheit und damit Bedürfnislosigkeit hervorhebe.
Wer genau heute vor der Wahl steht, ein System anzuschaffen, kann lieber noch ein bis zwei Jahrzehnte warten, bis es etwas besseres gibt, als das tote SX mit seinem Bus.
Jürgen H.
Jürgen,
Meinst du deinen letzten Satz mit Zwinkersmiley oder provokant?
Ich meinte genau den Fall, wo man manuell am Stellhebel der Weiche eingreift. Das geht zwar auch ohne RailCom, indem man tatsächlich einen Stellungsabhängigen Schalter mit Encoder einsetzt. Theoretisch müsste dies auch mit Endabgeschalteten Magnetantrieben von Arnold, Fleischmann und Trix gehen, aber den Schaltern traue ich nicht.
Dabei fällt mir ein, dass sich motorische Weichenantriebe meist nicht manuell stellen lassen... Alles nicht so ganz einfach.
Jens
Meinst du deinen letzten Satz mit Zwinkersmiley oder provokant?
Ich meinte genau den Fall, wo man manuell am Stellhebel der Weiche eingreift. Das geht zwar auch ohne RailCom, indem man tatsächlich einen Stellungsabhängigen Schalter mit Encoder einsetzt. Theoretisch müsste dies auch mit Endabgeschalteten Magnetantrieben von Arnold, Fleischmann und Trix gehen, aber den Schaltern traue ich nicht.
Dabei fällt mir ein, dass sich motorische Weichenantriebe meist nicht manuell stellen lassen... Alles nicht so ganz einfach.
Jens
Zitat - Antwort-Nr.: | Name:
Jürgen,
Meinst du deinen letzten Satz mit Zwinkersmiley oder provokant?
Die Interpretation überlasse ich ganz dir
Es gab (gibt noch?) Weichendecoder, die die Stellung des Eisenankers in der Spule auswerten können.
Das ist dann kontaktlos und zuverlässig.
Jürgen H.
Michael S. - 13.04.21 14:27
Natürlich gibt es ganz normale Weichen, die man von Hand umstellen kann, z.B. bei mir im Schattenbahnhof, z.B. mit Magnetantrieb.
Und natürlich gibt es Hardwarefehler. Schön, wenn eine Software dann überwachend eingreift.
Und natürlich gibt es Begründungen für alles, speziell, wenn es um eigene Nachteile geht.
VG Michael
Und natürlich gibt es Hardwarefehler. Schön, wenn eine Software dann überwachend eingreift.
Und natürlich gibt es Begründungen für alles, speziell, wenn es um eigene Nachteile geht.
VG Michael
Westerland - 13.04.21 14:52
Zitat - Antwort-Nr.: | Name:
Natürlich gibt es ganz normale Weichen, die man von Hand umstellen kann, z.B. bei mir im Schattenbahnhof, z.B. mit Magnetantrieb.
Hallo Michael,
natürlich ist das theoretisch denkbar aber wer stellt seine Weichen im Schattenbahnhof (!) mit der Hand um? Findest Du das nicht ein wenig konstruiert?
Bei Selectrix gibt es dafür die Encoder. Aber nutzt die jemand? Braucht man so etwas? Ich meine eher praxisfremd.
Viele Grüße,
Mathias
Moin,
Also ich habe bei mir schon Situationen, wo ich zumindest nicht die Software hochfahren. Für Tests, zum Reinigen, für Fotos. Da stelle ich Weichen über die IB direkt. Wenn ich nun die Software starte, würde sie das nicht bemerken. Es gibt natürlich Steuerungen, wo sich vorher mal alle Weichen stellen lassen, aber eine Rückmeldung wäre ja noch besser.
Viele Grüße
Dirk
Zitat - Antwort-Nr.: | Name:
Hallo Michael,
natürlich ist das theoretisch denkbar aber wer stellt seine Weichen im Schattenbahnhof (!) mit der Hand um? Findest Du das nicht ein wenig konstruiert?
Also ich habe bei mir schon Situationen, wo ich zumindest nicht die Software hochfahren. Für Tests, zum Reinigen, für Fotos. Da stelle ich Weichen über die IB direkt. Wenn ich nun die Software starte, würde sie das nicht bemerken. Es gibt natürlich Steuerungen, wo sich vorher mal alle Weichen stellen lassen, aber eine Rückmeldung wäre ja noch besser.
Viele Grüße
Dirk
Michael S. - 13.04.21 15:45
Hallo Mathias,
ja, ich habe auch an das manuelle Eingreifen und gar nicht den Normalbetrieb gedacht. Bei mir ist das besonders heikel, weil es eine mehrgleisige Kehrschleife betrifft und ich diese passend zu mehreren Weichen per digital gesteuertem Relais polarisiere (es gibt weitergehende Gründe gegen ein Kehrschleifenmodul).
VG Michael
ja, ich habe auch an das manuelle Eingreifen und gar nicht den Normalbetrieb gedacht. Bei mir ist das besonders heikel, weil es eine mehrgleisige Kehrschleife betrifft und ich diese passend zu mehreren Weichen per digital gesteuertem Relais polarisiere (es gibt weitergehende Gründe gegen ein Kehrschleifenmodul).
VG Michael
Hallo
Für das Schalten und Melden braucht man kein Railcom ein Bus reicht aus.
Ich habe einige Digitrax DS64. Die Melden zurück wenn ein Schaltbefehl ausgeführt wird und wenn esentsprechend konfiguriert und verkabelt die Ist-Lage der Weiche. Das ist manchmal schon nützlich. Vor allem wenn die Hand Gottes am rangieren ist.
Ein Weichendecoder mit Railcom wäre toll zum Einbau in Kato Weichen und ähnliche. Dann hätte man eine echte Rückmeldung ohne zusätzliche Busverkabelung.
Auf der Anlage habe ich aber lieber ein Schienensignal und ein getrennter Bus zum Schalten und Melden.
Gruss Matthias
Für das Schalten und Melden braucht man kein Railcom ein Bus reicht aus.
Ich habe einige Digitrax DS64. Die Melden zurück wenn ein Schaltbefehl ausgeführt wird und wenn esentsprechend konfiguriert und verkabelt die Ist-Lage der Weiche. Das ist manchmal schon nützlich. Vor allem wenn die Hand Gottes am rangieren ist.
Ein Weichendecoder mit Railcom wäre toll zum Einbau in Kato Weichen und ähnliche. Dann hätte man eine echte Rückmeldung ohne zusätzliche Busverkabelung.
Auf der Anlage habe ich aber lieber ein Schienensignal und ein getrennter Bus zum Schalten und Melden.
Gruss Matthias
Michael S. - 13.04.21 17:41
Hallo Matthias,
Weichendecoder mit Railcom sind ja schon mehrere Jahre Stand der Technik, bei Kato weiss ich nicht, ob der Kühn das kann.
Gleis- und Schaltsignal lässt sich bei beiden Systemen getrennt führen, bei DCC habe ich für das Schalten einfach einen separaten Booster.
Melden ist bei mir der einzige Bus. Wenn der stirbt, nehme ich einfach den nächsten😁😁😁
VG Michael
Weichendecoder mit Railcom sind ja schon mehrere Jahre Stand der Technik, bei Kato weiss ich nicht, ob der Kühn das kann.
Gleis- und Schaltsignal lässt sich bei beiden Systemen getrennt führen, bei DCC habe ich für das Schalten einfach einen separaten Booster.
Melden ist bei mir der einzige Bus. Wenn der stirbt, nehme ich einfach den nächsten😁😁😁
VG Michael
Hallo Michael
Welchen Decoder meinst du von Kühn?
Ich habe keinen gesehen,den man in eine Katoweiche einbauen könnte.
Gruss Matthias
Welchen Decoder meinst du von Kühn?
Ich habe keinen gesehen,den man in eine Katoweiche einbauen könnte.
Gruss Matthias
Roland Herzog - 13.04.21 18:35
Hallo Mathias,
im Club (mec-luthe) werden Encoder für die beiden Stellpulte an der Anlage eingesetzt. Dadurch kann man auch mit und ohne PC Fahrbetrieb machen. Darum setzte ich die Encoder auch zu Hause ein. Es kommt nicht jeder Besucher mit der Software gleich zurecht, mit dem Stellpult klappt das sofort.
Gruß, Roland
Zitat - Antwort-Nr.: 84 | Name:
Bei Selectrix gibt es dafür die Encoder. Aber nutzt die jemand? Braucht man so etwas? Ich meine eher praxisfremd.
im Club (mec-luthe) werden Encoder für die beiden Stellpulte an der Anlage eingesetzt. Dadurch kann man auch mit und ohne PC Fahrbetrieb machen. Darum setzte ich die Encoder auch zu Hause ein. Es kommt nicht jeder Besucher mit der Software gleich zurecht, mit dem Stellpult klappt das sofort.
Gruß, Roland
Hallo Mathias,
bei mir waren Encoder A und Encoder B bei meiner alten Anlage für das Gleisbildstellwerk im Einsatz. Hat damals prima mit 1-2 Zügen gleichzeitig in Betrieb (und vor allem ohne PC) funktioniert. Bei der neuen Anlage kommt aber ein PC zum Einsatz da im Schattenbahnhof ca. 100 Belegtmelderabschnitte vorhanden sind und ein Zugspeicher damit automatisch gesteuert werden soll. Aber eben ohne Hardware-Gleisbildstellwerk und natürlich wieder mit SX-Bus
Grüße
Markus
bei mir waren Encoder A und Encoder B bei meiner alten Anlage für das Gleisbildstellwerk im Einsatz. Hat damals prima mit 1-2 Zügen gleichzeitig in Betrieb (und vor allem ohne PC) funktioniert. Bei der neuen Anlage kommt aber ein PC zum Einsatz da im Schattenbahnhof ca. 100 Belegtmelderabschnitte vorhanden sind und ein Zugspeicher damit automatisch gesteuert werden soll. Aber eben ohne Hardware-Gleisbildstellwerk und natürlich wieder mit SX-Bus
Grüße
Markus
Michael S. - 13.04.21 19:16
Hi Matthias,
das ist der WD-10, man benötigt noch den Motoradapter MA-10.
Der WD-10 macht zwar Railcom, aber leider keine Rückmeldung der Weichenstellung.
https://kuehn-digital.de/wd10--schaltdecoder.html
https://kuehn-digital.de/ma10--adapter-fuer-4-motorische-weichen.html
VG Michael
das ist der WD-10, man benötigt noch den Motoradapter MA-10.
Der WD-10 macht zwar Railcom, aber leider keine Rückmeldung der Weichenstellung.
https://kuehn-digital.de/wd10--schaltdecoder.html
https://kuehn-digital.de/ma10--adapter-fuer-4-motorische-weichen.html
VG Michael
Hallo,
und was macht der auf Railcom?
interessiert sich
Günter
Zitat - Antwort-Nr.: | Name:
Der WD-10 macht zwar Railcom, aber leider keine Rückmeldung der Weichenstellung.
und was macht der auf Railcom?
interessiert sich
Günter
Westerland - 14.04.21 12:56
Zitat - Antwort-Nr.: | Name:
Bei mir waren Encoder A und Encoder B bei meiner alten Anlage für das Gleisbildstellwerk im Einsatz. Hat damals prima mit 1-2 Zügen gleichzeitig in Betrieb (und vor allem ohne PC) funktioniert. Bei der neuen Anlage kommt aber ein PC zum Einsatz da im Schattenbahnhof ca. 100 Belegtmelderabschnitte vorhanden sind und ein Zugspeicher damit automatisch gesteuert werden soll. Aber eben ohne Hardware-Gleisbildstellwerk und natürlich wieder mit SX-Bus
Hallo Markus,
ich kenne sicher mehr als 25 Modellbahnanlagen, die mit Selectrix gesteuert werden und habe selbst bei vielen davon an der Systemimplementierung mitgewirkt.
Aber ich habe tatsächlich noch nie einen Encoder A oder Encoder B live gesehen....
Liebe Grüße,
Mathias
Hallo Markus #91
Schön, dass der Betrieb von 1 Zug gleichzeitig funktioniert hat. Sonst wär´s ja ein Diorama und keine MoBa gewesen.
VG Andreas
Zitat
Hat damals prima mit 1-2 Zügen gleichzeitig in Betrieb ... funktioniert
Schön, dass der Betrieb von 1 Zug gleichzeitig funktioniert hat. Sonst wär´s ja ein Diorama und keine MoBa gewesen.
VG Andreas
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;