THEMA: Welches Bussystem ist zu empfehlen?

Hallo Dalmi,
kommt drauf an, was du machen willst. Für die herkömmliche Rückmeldung von Belegtabschnitten sind alle Busse hinreichend schnell. Will man aber Railcom einsetzen, wird die Luft schnell dünner. Ausreichend schnell sind dann eigentlich nur noch die CAN-Varianten, beispielsweise bei Zimo, oder der extra mit Blick auf Railcom entwickelte BiDiBus. Beim CAN bist du allerdings mehr oder weniger auf den Hersteller der jeweiligen Zentrale angewiesen, Dritthersteller gibts da kaum bis gar nicht. BiDiB ist zwar ein offenes System, hat aber (bisher?) noch keine breite Unterstützung, soweit ich weiß, baut lediglich Tams als Dritthersteller Komponenten dafür.

Ansonsten unterstützen die Bus-Systeme Railcom bestenfalls teilweise - Wie gesagt muss das kein Manko sein, wenn man das eh nicht einsetzen will. Weit verbreitet sind S88 und LocoNet, für beide gibts auch viele Drittanbieter. S88 ist allerdings technisch doch etwas überholt... Außerdem gäbe es noch XpressNet, das wird hauptsächlich für Handregler verwendet, Roco nimmt aber ein Derivat davon als R-Bus für seine weißen und schwarzen Z21. Auch da gibts Drittanbieter. Bliebe letztlich noch der SX-Bus, der allerdings mehr in der Selectrix-Welt verhaftet ist. Alles andere läuft dann so ziemlich als "unter ferner liefen".

Viele Grüße
Carsten

Hallo,

im Hinblick auf Technologien wie RailCom sollte das Bussystem möglichst leistungsfähig sein. Das wären dann z.B. Märklin und Esu (basieren auf CAN) und BiDiB von Fichtelbahn (Selbstbauprojekt, bei dem ein großer Teil vorgefertigt ist.)
Wenn die Nutzung von RailCom (vielfältige Rückmeldung der Dekoder und z.B. automatische Anmeldung von neu aufs Gleis gestellten Loks) nichtgewünscht ist, kommen je nach bevorzugtem Anbieter: SX-Bus, S88, Loconet, XPressNet...

Jens

Hello!
Soll der Bus nur Rückmeldungen transportieren oder auch Fahrpultbefehle und Konfigurationsdaten? Da landet man dann bei Bussen die möglichst simpel gestaltet sind und dementsprechend das Ziel haben möglichst keinerlei Funktionalität, oder nur eine und die möglichst schlecht, zu bieten wie S88. S88 ist einfach kann nur Besetztmeldungen und bietet viel Spielspaß weil man ständig Einstreuungsprobleme bekämpfen muß. Am anderen Ende sind komplexere Lösungen wie die CAN Bus Varianten oder BiDiB die meist sehr Herstellernahe sind. Niemand will beim "Nachbarn" mitmachen daher gibt's da nichts Herstellerübergreifendes.

In den Normungsgremien läuft das seit den frühen 1990'ern auf 2 Extreme hinaus: 1. Das ist mir viiiel zu primitiv da kann ich meine Funktionen nicht abdecken. 2. Das ist viel zu komplex das kann ich bei mir nicht einbauen habe keine Ressourcen dazu.
Daher gibt's nichts herstellerübergreifendes, sondern eben die einzelnen Lösungen. CAN Bus von MäTrix, ESU oder ZIMO, alle zueinander inkompatibel, und den BiDiB. Primitivlösungen wie S88, LocoNet X-Press Net haben etwas mehr Vielfalt bei den Anbietern können halt nix wenn man moderne Technologien wie RailCom anschaut.
-AH-

Hallo Dalmi,

wie bei den ersten Antworten bereits deutlich wird, gibt es sehr viele Möglichkeiten.

Was für Anforderungen stellst du an deine Anlage?
Wie groß wird deinen Anlage?
Wird die Anlage über einen PC gesteuert?
Hast du evtl Bekannte oder einen Club in deiner Nähe, wo du dir digital gesteuert Anlage vor Ort ansehen kannst?

Meine Spur N-Anlage betreibe ich mit der RMX-USB Zentrale und dem RMX-Bus von Rautenhaus. Gesteuert wird die Anlage mittels PX mit der Software von Freiwald (Silber 8). Gefahren wird aber überwiegend DCC. Meine Anlage ist ca. 14 m² groß, und es fahren immer zwischen 8 und 10 Züge gleichzeitig. Probleme gibts eigentlich nur, wenn eine Weiche mal nicht richtig schaltet. Das liegt aber dann nicht am Schalt-und Meldebus, sondern an der Weiche selbst.

Zustätzlich baue ich mir aber noch eine Modulanlage in H0 auf. Bei dieser Anlage verwende ich die z21 weiß von Roco in Verbindung mit dem R-Bus. Zu dem R-Bus kann ich aber noch nicht wirklich viel sagen, da sich diese Anlage im Bau befindet und noch nicht alle Rückmelde- und Schaltmodule angeschlossen sind.

Viele Grüße
Andreas

Grüße
Andreas

Hallo,
Danke schön für die Rückmeldungen.
Die Anlage wird ca. 8 qm haben und auch zwei (optional drei) Schattenbahnhöfe bekommen.
Angedacht war vom reinen Handbetrieb ein langsamer Ausbau, der später automatische Abläufe ermöglicht mit der Möglichkeit, trotzdem noch ein / zwei Züge parallel dazu von Hand zu fahren/rangieren. Somit wird wohl es unumgänglich werden, ein Programm zu kaufen (tendiere da zu Freiwald) und dann auch über den PC zu fahren.
Ich dachte da zunächst, dass der LocoNet-Bus da dann die Lösung wäre, immerhin ist der ja weitverbreitet (Fremo nutzt den ja auch), aber oben schreibt ja AH, das dieser Bus zu den primitiven gehört. Schon ist man da ein wenig geschockt.
Beste Grüße
Dalmi

Hallo Dalmi,

was spricht gegen den LocoNet-Bus? Wenn LocoNet wirklich so primitiv ist, warum kann man damit trotzdem Anlagen störungsfrei betreiben? Solange RailCom nicht Herstellerübergreifend einheitlich ist, sehe ich RailCom nicht als Fortschritt. Es gibt evtl einige "Dinge" die RailCom kann, aber ich frage mich, wie oft man diese "Dinge" beim Betrieb einer Anlage wirklich braucht. Wichtiger ist in meinen Augen, daß man sich nicht an einen Hersteller bindet. Welche Zentrale hast du bereits ins Auge geschlossen? Mit der Software von Freiwald hast du ja schon eine gute Wahl getroffen. Auch wenn die Software nicht ganz günstig ist, kann man damit als nicht "Programmierer" sehr gut damit arbeiten.

Ich brauche kein RailCom, zumindest nicht in der jetztigen Form. Es gibt ja nicht nur RailCom sondern auch RailCom plus. Beide scheinen aber noch erhebliche Schwächen zu haben. Man kann sehen, daß es wahrscheinlich nie einen einheitlichen "RailCom-Bus" geben wird. Außerdem müssen die Lokdecoder und die Meldedecoder ebenfalls RailCom unterstützen.

Grüße
Andreas

Servus,

vielleicht muss man das relativieren. Als "Primitiv" würde ich zunächst mal den S88 einstufen weil das Protokoll wirklich nur dumm unidirektional Belegtzustände weitergibt und sonst nichts kann. Und in der originalen Version ist der auch noch extrem Störanfällig, insbesondere wenn die Leitungen länger werden. Die S88N (für Netzwerk) ist da wohl besser. Wegen der Verbreitung durch Märklin gibt es auch sehr viele Anbieter. Aber es ist heute einfach nicht mehr State-of-the-Art.

Loconet erlaubt da schon weit mehr und kann auch als Steuerbus dienen. Bekannteste Anwendung ist der Fred(i) beispielsweise. Auch eine Boosterverkabelung kann man damit realisieren da das DCC Signal (optional) mit auf dem Bus liegen kann.

Neben der bekannten Hersteller Uhlenbrock, Digitrax, Roco (Z21) gibt es auch eine Reihe weniger bekannter Anwendungen, u.a. auch auf RailCom basierend. Und mit Digikeijs gibt es ja auch einen neuen Spieler im Loconet-Feld mit einigen frischen Ideen.

Wenn man noch mehr Daten übertragen will kommt man sicherlich auch irgendwann an Grenzen, aber für die üblichen Anwendungen der heimischen Modellbahn ist das mehr als ausreichend. Ich würde da im Moment immer noch drauf setzen.

Grüßle
Elvis

P.S.: Nachtrag: Das man für echtes RailCom usw. auf was anderes setzen muss wurde oben ja genannt. Ich selbst habe da noch keinen Bedarf

Hallo Dalmi,

das schon erwähnt BiDiB ist für mich das z.Z. leistungsfähigste System.
Bei einer so großen Anlage wäre der Einsatz von einem Railcom-fähigen System sicher sinnvoll.
Z.B. die Gleisverschmutzungsanzeige ist sehr praktisch und einige weitere Dinge sind in Vorbereitung.
Traincontroller geht dann allerdings nicht.
Du kannst ja mal Dein Projekt im OpenDCC-Forum vorstellen https://forum.opendcc.de/


RailcomPlus ist einer Erweiterung von Railcom um die automatische Anmeldung wie bei MFX. Welche Schwächen soll Railcom 'scheinbar' haben?
Einen Railcom-Bus muss es auch nicht geben, genauso wie es keinen einheilichen Bus gibt, der Railcom-Daten nicht übertragen kann. Der Bus muss nur vorbereitet sein, entsprechende Daten zu übertragen.

Grüße
Stephan

Auch wenn Arnold kein Freund von LocoNet ist, so ist es doch der einzige bidirektionale Bus wo viele Hersteller interoperable Komponenten anbieten. Dann reicht die Geschwindigkeit nicht für volles RailCom (für Belegmeldungen mit ID aber schon), doch dafür gibt es bis jetzt nur Herstellerspezifische Lösugen.

Im Jahr 2020 hat eigentlich dann alles WiFi außer die Moba?

Grüße,
Harald

Hallo,

intressant, wie hier Argumente falsch zugeordnet werden , insbesondere zum Thema Railcom :

Loconet ist das Übertragungsmedium für Railcom und schränkt nicht ein

Der Fragesteller möchte später TC als PC Software einsetzen, diese unterstützt nur Railcom Kanal1 = Lokadresse senden bei Einfahrt in den Melder.

grösste Schwachstelle sind aber bei Railcom die Lokdecoderhersteller die nur wenig vernünftige Daten senden

Ausserdem ist bei Einsatz von PC Software Railcom völlig überbewertet, denn die SW weiss eh wohin die Loks fahren. da reichen einfache und nicht so teure Belegtmelder.

Mein Moba Beginn war mit LENZ und XPRESSNET , die heute noch Rückmelden und Schalten .
Zum Fahren setze ich DIGIKEIJS ein mit LOCONET,
hier geht ein sehr gute Boosterüberwachung mit Meldungen an TC
Eine Drehscheibensteuerung die viele DS unterstützt
Die Zugverfolgung auch bei manuellen Fahren
und ein WLAN Handregler oder die Z21 App von Roco

gruss Hartmut

Servus,

die aktuellen Steuersoftware Lösungen sind hier halt generell besser geworden. Auch iTrain unterstützt das manuelle fahren sehr gut und führt den Zug in den Blöcken entsprechend nach.

RailCom würde da vielleicht noch mehr Infos beisteuern, aber für die Edge-Cases sind die Melder insgesamt halt doch kostspieliger. Bei kleinen Anlagen egal, bei größeren eine Frage der Prioritäten.

Fun fact: Blücher hat die Railcom Version GBM16XN inzwischen abverkauft und nimmt das Produkt aus dem Sortiment. Der ältere ohne Railcom wurde nochmal aufgelegt. Hatte ich auch noch net mitgeschnitten...
https://www.bluecher-elektronik.de/

Grüßle
Elvis

Hello!

RailCom hat das Konzept die Daten von den Decodern lokal einzusammeln und dann über einen Systembus weiter zu transportieren. Das haben die wenigsten Anwender verstanden. RailCom Plus hat vor allem den Namen gemeinsam hat aber nichts mit RailCom zu tun, könnte man auch mit anderen Mechanismen realisieren, zb mfx mit dem die Technik verwandt ist. Derzeit ist es halt so, daß die Anmelderei von ESU so realisiert worden ist. Man hat aber entschieden das nicht zu Normen, bzw kaufmännische Hürden einzubauen. Es ist auch recht langsam weshalb manche Hersteller die Lösung nicht wollen. Daher ist das eine Insellösung. Derzeit wird in der Railcommunity (leider ein sehr verwechslungsbringender Name hat nix mit RailCom zu tun) versucht die Lokanmelderei und Vergabe von Adressen zu normen. Das passiert jetzt gerade daher ist da auch noch nix fix. RailCom wird man naheliegender weise dabei verwenden. Das ist einer der Gründe weshalb DCC empfohlen wird und die anderen Gleisformate eine Sackgasse sind, insbesondere weil dadurch ein Mischbetrieb zb SX und RailCom nicht geht.

RailCom ist der Mechanismus um vom Decoder über das Gleis "an Land" zu kommen. Für einen Systembus ist es nicht geplant und eignet sich auch nicht dazu. Man braucht aber irgend etwas um die RailCom Daten abzutransportieren.

Da man, um einigermaßen RailCom Verkehr zu bewältigen, >100kBaud Busbandbriete braucht sind die klassischen Bussysteme wie X-Press Net oder LocoNet völlig ungeeignet. Das ist kein Vorwurf an diese Bussysteme, in den 1970'ern als die Grundlagen dafür konstruiert worden sind war man froh im Weitverkehr mit 75/110 Baud einen Fernschreiber zu haben. So waren die knapp über 10kBaud dieser Busse sehr weitsichtig bzw. schnell. Leider gibt es viele "Pferdeliebhaber" die diese schon seit Jahrzehnten zu schmalen Bussysteme noch immer reiten wollen, obwohl das Pferd schon seit Jahrzehnten lahmt. Jeder der meint mit einem LocoNet Lesegerät irgend etwas sinnvolles mit RailCom zu machen hat entweder nicht verstanden worum es dabei geht (eher die Anwender), oder er will absichtlich die Kunden hinter's Licht führen um, bevor das zu viele Leute bemerken, diese nochmals mit der Technik ordentlich abzukassieren. Meiner Meinung nach ist das unseriös. Hab' keine Einwände zu sagen: hier ist ein Besetztmelder der auch Zugnummern über LocoNet mit großen Verzögerungen weitergeben kann - hier fehlt aber noch viel RailCom Funktionalität. Aber zu behaupten das ist ein Local Detector und via LocoNet meldet der weiter, das ist unseriös, weil der 90% der Daten alleine schon aus Bandbreitengründen weggeworfen werden müssen. Nur das wird da nicht dazugesagt. Das "Verbing" ist da: ja es gibt Funktionen die wir nicht brauchen (gemeint ist da natürlich KÖNNEN) daher funktioniert das auch oder so ähnliche Ausreden.

Zurück zum UP: Ich würde mir überlegen ob einer der CAN Bus Anbieter in Frage kommt, also MäTrix, ESU oder Roco/ZIMO. Wenn's ums Basteln geht dann gegebenenfalls auch noch BiDiB mit Fichtelbahn und TAMS. Was davon wirklich zielführend ist weiß keiner. Bei MäTrix ESU und Roco hat man relativ große Firmen die viele Kunden haben. Ob die aber das auch weiter bringen weiß man nicht. ZIMO ist immer sehr innovativ, man weiß aber nie ob die Ankündigung in 10 Jahren kommt oder inzwischen 3x überholt worden ist von neueren. Einzig Roco ist da stabilisierend, weil die einfach drauf bestehen daß die Dinge benutzbar bleiben. Insofern ein kleiner Vorteil für Roco/ZIMO. BiDiB mit Fichtelbahn hat sehr gutes Zeugs ist halt eine Minifirma. Tams ist mit an Bord, was da aber an kaufbaren Produkten längerfristig bestehen bleibt ist offen. LocoNet und Co. würde ich für ein neues Projekt ausschließen das war schon vor 15 Jahren veraltet.
-AH-

Hallo,
Danke für die Infos, obwohl ich ehrlicherweise sagen muss, das das Licht im Dickicht noch nicht sehr viel heller geworden ist. Tendierte doch alles bisher zu LocoNet (Danke an Elvis, sehr gut erklärt), Schrecken mich doch andere Aussagen, das dieses System vor 15 Jahren schon veraltet war, wieder ab.
Aussagen, das man auf die großen Hersteller vertrauen soll, kann ich nicht nachvollziehen. Denn wie oft standen Roco oder Mätrix schon mit dem Rücken an der Wand?
Beste Grüße
Dalmi

Hi Dalmi!
Du musst Dir überlegen was Du haben willst. Reicht eine reine Besetztmelderei aus, dann kannst auch S88 nehmen. Dann ist aber klar mehr als: da ist irgendwas aber keine Ahnung was das ist bekommst Du da nicht raus.
Willst JETZT was bauen, und nicht bald drüber sinnieren warum moderne Mechanismen nicht geht dann wird's schwierig. LocoNet ist für RailCom Sachen zu langsam, was anderes weit verbreitetes gibt's nicht. Mit MäTrix und Roco/Fleischmann hat man halt die breite Anwenderbasis und darf hoffen, daß es 3rd Party Anbieter gibt weil die durch die weite Verbreitung Geschäft erhoffen.
-AH-

Hallo Dalmi,
man könnte es auch aus einer anderen Perspektive sehen: LocoNet gibts seit Jahrzehnten und genausolange tut es zuverlässig seinen Dienst. Die Möglichkeiten für die Zukunft, eben speziell auf Railcom bezogen, sind aber begrenzt. Dafür kann man auf eine breite Anwenderbasis und vor allem eine breite Anbieterbasis zurückgreifen. Das Mitverfolgen der Züge macht letztlich die Software auch ohne Railcom-Daten, man müsste aber ggf. auf automatische Anmeldung der Loks etc. verzichten.

Wenn du das nicht willst, bleiben nur die oben genannten Möglichkeiten, die aber eben mehr oder weniger Insellösungen sind und im Fall von BiDiB der Hersteller ein sehr kleiner ist. Du musst jetzt nur auswählen, ob die z.B. im Fall von LocoNet der Ist-Stand der Technik ausreicht oder ob du lieber auf einen schnelleren Bus mit mehr Möglichkeiten setzt, der aber an einem einzigen Hersteller hängt.

Viele Grüße
Carsten

Hallo,
Sinnigerweise macht es später schon Sinn, dass man weiß, welche Lok sich gerade im SBf befindet und nicht blind fährt nach dem Motto: Da ist was drin und irgendwas kommt wieder heraus.
Sicher ist auch, dass ich mich nicht auf eine Insellösung einlassen will und auch ein sehr kleines Herstellerangebot. Ganz schnell sitzt man dann auf dem Trockenen, wenn dann ein Hersteller ausfällt (Insolvenz, Firmenaufgabe und kein Nachfolger usw.).
Viele Grüße
Dalmi

Hallo Dalmi,
wie gesagt, die Verfolgung macht die Software. Blind bist du dann nicht.

Viele Grüße
Carsten

Hallo haba,

deine Aussage stimmt so nicht: der SX-Bus ist -soweit mir bekannt ist - älter und konnte von Anfang an (!!!!!!) Daten senden und empfangen. Darüber hinaus kann es z.B. Mit den Belegtmeldern von MTTM auch schon sehr lange die Dekoderadresse zurückmelden - da hat noch niemand an RailCom gesacht. Mit RailCom wäre aber noch sehr viel mehr möglich und das kann der alte SX-Bus nicht leisten.

Da mich die langsame Entwicklung aber mitlerweile echt ankäst, bin ich am Übetlegen, ob Mfx nicht eine Möglichkeit wäre.

Jens

@18
Die Geschichte mit der Lokadresse Rückmelden gibt's seit den 1970'ern, damals hatte noch niemand einen Gedanken an SX verloren. Da gibt's viele Lösungen, leider jeweils Insellösungen ZIMO, Digitrax.

mfx von Märklin ist das klassische Beispiel wie man solche Dinge nicht angehen darf. Das Gleisprotokoll ist im Vergleich zu anderen Lösungen langsam, das Datenformat wird nur ausgesuchten Herstellern und da nur zu einem Teil veröffentlicht. Es hätte das Potential gehabt DCC zu ersetzen, das hat man mit mMn hohen Anstrengungen verhindert - schade. Inzwischen ist denen DCC rechts und links um die Ohren gefahren. Da können die "kleinen Hersteller" wesentlich mehr als es die große Tante Mä den Kunden zumutet / zutraut. Solche Politik hat in der Wirtschaft noch nie funktioniert.
Zu mfx selbst die Idee für das RDS einen Quarz wegen Genauigkeit zu erfordern sorgt dafür daß es lange kein mfx in N gegeben hat.
-AH-

Hallo zusammen,

vielleicht wäre für Dalmi noch interessant zu wissen was man später bei der Verkabelung der einzelnen Rückmeldemodule beachten sollte und welche Protokolle mehr oder wenig empfindlich (parallele Leitungsführung) sind.

Dies hatte mich damals dazu bewogen trotz modernerer Systeme auf SX für den BUS zusetzen.
Eine Decoderrückmeldung/-anmeldung via RailCom benötige ich nicht. Auch gibt es hier genügend OEM-Anbieter, bei denen man entsprechende Melder, Ein-und Ausgabemodule, Signal und Weichendecoder fertig aufgebaut oder als Bausätze erwerben kann. Meine im Bau befindliche Anlage wird ca. 50 8-fach Belegmelder, über 50 Weichendecoder (ca. 150 Weichen) sowie Lichtsignaldecoder und 800 Meter Gleis umfassen. Bis dato 250 Meter Gleis und 15 Belegmelder verbaut und trotz paralleler Leitungsführung über alle 6 Segmente (12 Meter Länge / 14,5 qm) keine Störungen oder Verzögerungen in den Meldungen.

Das Thema fahren ob nun DCC oder SX oder SX2 ist mit den Multiprotokolllokdecodern oder Multizentralen (RMX) sowieso keiner Diskussion mehr würdig.

Abhängig von der Größe der Anlage und speziell in meinem Fall würde ich neben SX heute nur noch BiDiB ins Auge fassen. Was die Verfügbarkeit von Komponenten angeht, kann es auch bei heutigen namhaften Herstellern sehr schnell (Alter oder Finanzsituation) zu Ende sein.

Grüße
Christian

Hallo Andreas!

Wenn Du TrainController nutzen willst, mußt Du Dir wirklich die Frage stellen, was RailCom im Betrieb noch für Vorteile bringt. Ich habe eine Zeitlang die Kombination von TrainController mit Adreßrückmeldung (MÜT) genutzt. Das Ergebnis war eher ernüchternd. Es kam vor, daß die Adreßrückmeldung eine Lok falsch erkannte. Daraus schloß TrainController, daß eine falsche Lok in den für eine andere Lok reservierten Block fuhr, und stoppte augenblicklich die Zugfahrt, obwohl ja in Wirklichkeit alles richtig war. Ich habe die Zugerkennung dann ausgeschaltet. So funktioniert es reibungslos.

Möglicherweise funktioniert die Adreßerkennung bei heutigen Meldern zuverlässiger. Aber genau genommen fehlt mir nichts.

Herzliche Grüße
Elmar

Hallo zusammen,

da in diesem Thread einige Einwürfe zum SX-Bus kamen möchte ich hier speziell in Verbindung mit der Thematik RailCom einige Hinweise und Anmerkungen beifügen.

Was der SX-Bus in Verbindung mit RailCom leistet, kann der Interessierte grundsätzlich schon aus der (z. Zt. noch vorläufigen) Beschreibung zum neuen Rückmelder auf der D&H Homepage entnehmen. Siehe: https://doehler-haass.de/cms/media/pdf2/RM_Bedienungsanleitung.pdf

Da ich bereits einen entsprechenden Rückmelder besitze konnte ich schon einige Tests durchführen und Erfahrungen sammeln. Getestet habe ich den Rückmelder, der über den SX-Bus an ein beliebiges Gerät angeschlossen werden kann, welches einen SX-Bus bereitstellt (z.B. eine entsprechende Zentrale oder auch ein Bus-Interface) in Verbindung mit der D&H FCC und auch in Kombination mit der Roco/Fleischmann z21 start. Dazu weiter unten mehr.

Die D&H FCC kann bekanntlich einen normkonformen RailCom Cutout am Gleis ausgeben und die über den PX-Bus angeschlossen Booster entsprechend ansteuern. Diese können dann automatisch einen absolut synchronen Cutout generieren, so dass auch in über Booster versorgten Abschitten RailCom Meldungen von den Fahrzeugen ausgegeben werden können.

Der Rückmelder lieferte in meinem ersten Anwendungsfall seine Daten über den SX-Bus an die FCC und diese wiederum die Daten an den PC auf dem die D&H Future Control Software zur Präsentation/Interaktion genutzt wurde. Getestet wurde der Gleisanschluss direkt am Gleisausgang der FCC und zusätzlch an einem Booster in diesem Fall einem TRIX Power Pack PP 2000 (#66807).

In dieser Konstellation war es in Verbindung mit D&H Lok/Sound Decodern und einem PIKO/Uhlenbrock Decoder möglich folgende RailCom Daten/Funktionen zu nutzen:
- Nutzung von Channel 1 (address broadcast) und Channel 2 Daten
- Auswertung von bis zu 4 kurzen bzw. langen Lokadressen pro Gleisabschnitt
- Auswertung der Verbundadresse (consist address)
- POM-Lesen in jedem Gleisabschnitt auch dann, wenn mehre Loks im Abschnitt
  Hinweis: Die D&H Software erlaubt in Verbindung mit der FCC ein sequentielles Lesen aller CV´s in einem Durchgang
- Fahrzeuggeschwindigkeit (Voraussetzung hier: Nur ein Fahrzeug im Gleisabschnitt)
- Gleissignalqualität (Voraussetzung hier: Nur ein Fahrzeug im Gleisabschnitt)

Die Rückmeldungen von einzelnen Paramatern erfolgten ohne merkliche Verzögerung. Da der SX-Bus einen festen Frame hat und damit lastunabhängig ist, kann diese Beobachtung dahingehend erweitert werden, dass dies auch dann weiterhin der Fall ist, wenn nicht nur einige wenige Abschnitte überwacht/beobachtet werden, sondern zahlreiche (~ 200 pro SX-Bus).

Zusätzlich habe ich den Rückmelder, wie von D&H beworben im Zusammenspiel mit einem "Fremd-" System getestet. In meinem Fall mit der z21 (start).

Der Aufbau war hier gegenüber der Variante mit der FCC alleine nur insofern modifiziert, als dass das Gleissignal nun direkt von der z21 bereitgestellt wurde und der Rückmelder nun dieses Signal auswertete. Die Weiterleitung/Verarbeitung erfolgte auch hier wieder über den SX-Bus zur FCC und von dort über deren USB-Anschluss zum PC, wo erneut die D&H Future Control Software zur Anwendung kam.

Die Ansteuerung der z21 erfolgte über die z21 App und eine Roco Multimaus. Auch in dieser Konstellation waren soweit getestet die o.g. RailCom Funktionalitäten gegeben.

Die Parametrierung des Rückmelders und die Abfrage seiner Versionierung erfolgt ebenfalls über den SX-Bus. Hierzu werden die SX-Adressen/Kanäle 0 und 1 verwendet. Über den SX-Bus können auf den Rückmelder auch potentiell notwendige Updates aufgespielt werden. Da dies Update von einem PC aus erfolgt, sind hier allerdings zusätzliche Anforderungen zu berücksichtigen. Soweit ich dies beurteilen kann wird hierfür eine FCC oder ein Programmer von D&H benötigt.

Beste Grüße
Werner

Hallo Werner,

meine FCC ist schon etwas älter. Geht das mit aktualisierter Firmware auch mit der?

Oder gar mit der MiniFCC ( die ja nicht von D&H ist )?

Jens

Hallo Jens,

möchte den Bus Thread nicht kapern. Deshalb nur kurz.

Ih sehe keinen Grund warum das mit deiner FCC auch ohne Aktualisierung auf die neuste Firmware nicht funktionieren sollte. Allerdings würde ich dir eine Aktualisierung der Firmware empfehlen, da dort sicher einige Features enthalten sind (z.B. bis zu 32 Fkt., etc.), die deine Version noch nicht aufweist. Ich denke auch, dass das für ein problemloses Update der neusten Geräte sinnvoll oder gar notwendig ist.

Auch die MiniFCC sollte in Verbindung mit dem Rückmelder funktionieren. Sie hat ja 2 SX-Busse, unterstützt DCC und stellt den RailCom CutOut an ihrem Gleisausgang und am PX-Bus bereit.
Zudem sollte auch ihr USB-Interface hinreichend schnell sein alle Daten zügig an ein PC-Programm weiterzugeben.

Beste Grüße
Werner

Hallo Arnold,

die Wurzeln von Selectrix richen in die 70er Jahre zurück. Damals hat noch niemand an dcc gedacht - so rum war‘s. Wie man die Loknummernrückmeldung ohne Digitalsystem lösen will als ‚alten Hut‘ und ‚Insellösung‘ erschließt sich mir nicht. Natürlich hat man schon zu analogen Zeitendavon geträumt und sicher gab es dazu auch die eine oder andere Lösung. Das hat aber nichts mit Digital zu tun.

Überraschen tut mich das SX-Protokoll nun aber doch, wenn teilweise RailCom auf dem SX-Bus möglich wird.

Man mag einwenden, dass dies nicht die volle RailCom-Funktionalität ist, aber es ist mehr, als nur die Loknummer. Da scheint mir die praktische Anwendung von RailCom und dessen Komfortsteigerung doch in praktische Reichweite zu rücken.

Bin ich mit meiner FCC und SX doch nicht ganz so hinter dem Mond?

Jens

Hallo,
Da ich jetzt am Anfang mit der schwarzen Z21 händisch fahren will (sogar muss mangels "Masse"), stehen mir mit der Zentrale ja alle Optionen offen bzgl. des Bussystems. Aber da dann später ein PC mitspielen will, was muss ich bezüglich Trennstellen etc. beim Bau jetzt gleich beachten? (Die Trennstellen werden natürlich für den Handbetrieb überbrückt)?
Beste Grüsse
Dalmi

Hallo Dalmi,

mit der Z21 schwarz hast ja eine Zentrale die sehr viele Möglichkeiten bietet. Den TrainController kannst ja auch mit der Z21 verwenden.
Das mit den Trennstellen habe ich bei meiner ersten Anlage auch so gemacht. Ich habe mir alle paar Monate einen Besetztmelder gekauft und verbaut. Bei der H0 Modulanlage mache ich es auch wieder so.

Grüße
Andreas

@25 Hi Jens!
Historisch gesehen gibt's bei den Mehrzugssteuerungen die mit zu heute gebräuchlichem Digitalbetrieb vergleichbar sind einiges aus den 1970'ern. Davor gab's Tonfrequenzsteuerungen die haben aber wenig mit der Digitaltechnik zu tun, waren aber auch Mehrzugsteuerungen.

Tatsächlich kaufbar war das erste System in den 1970'ern von ZIMO gefolgt von Lenz in den frühen 1980'ern vermarktet über Arnold und Märklin. Die Anfänge dieser Lösungen waren natürlich noch früher.
Meiner Erinnerung nach, da bin ich mir aber nicht sicher über den zeitlichen Ablauf, war SX erst in den 1990'ern verfügbar weil es davor noch viel teurer war ASICs fertigen zu lassen. Das wollten auch Lenz und Ziegler machen wurde aber aus Kostengründen verworfen. Ziegler hat in den späten 1990'ern einen Chip für den MX62 machen lassen. Da war der Prozessor mit einiger Peripherie auf einem Keramikplättchen gebondet. Superextrem guter Decoder mit traumhaften Fahreigenschaften für die damalige Zeit, doch zu der Zeit kamen kleine PICs raus die die direkt gebondeten PICs auf dem Keramikplättchen unnötig gemacht haben. bereits die Nachfolgeneneration des MX62 hatte wider einen PIC mit Gehäuse.

Zurück zu den Bussystemen: Aus meiner Sicht braucht man insbesondere für PC gesteuerte Anlagen bei denen die Latenz der Meldungen extrem entscheidend ist einen Systembus mit >100kBaud Bandbreite. Langsamere Busse können zwar Meldungen konzentrieren, Doubletten filtern und damit etwas helfen. Alle PC Steuerungen die Zeit/Weg Rechnungen machen haben damit ein massives Problem. Daher kann ich nur den Rat geben die Uralt Zöpfe abzuschneiden. Bei einem neuen Anlagenprojekt gleich auf Technik setzen die Zukunftspotential hat. Wobei ich da leider kein kommerzielles Produkt ohne Einschränkung empfehlen kann. Dringend aber die Empfehlung das alte Zeugs keinesfalls für einen Neuanfang zu nehmen.
-AH-

Hallo Arnold!

Kurze Anmerkung zur Chronologie: Auf zwei Internet-Seiten wird ausgeführt, Selectrix habe ab 1982 zur Verfügung gestanden. In meinem Trix-Katalog 1982/83 wird es noch nicht angeboten. Im nächsten Katalog, den ich besitze (1985/86) ist es im Katalog enthalten. Die beiden Kataloge dazwischen besitze ich leider nicht. Daher kann ich es jetzt nicht präzise aufs Jahr genau feststellen. Aber auf jeden Fall ist es in der ersten Hälfte der 80er-Jahre erschienen.

Herzliche Grüße
Elmar

Hallo,



Bei meiner Anlage mit ca 14m² (im Normalbetrieb immer zwischen 8 bis 10 Züge gleichzeitig in Betrieb, zum Test auch mal bis zu 14 Züge) in Verbindung mit der RMX-USB Zentrale und dem RMX/SX Bus, gibt es in Verbindung mit dem TrainController bezüglich der Zeit/Weg Rechnung keinerlei Probleme. Dabei nutze ich nur einen Melder pro Block. Das natürlich alles ohne RailCom. Ob RailCom bei der RMX-USB Zentrale schon möglich ist, oder ob es irgendwann kommt, kann ich leider nicht sagen.

Bei D&H soll ja jetzt schon teilweise RailCom funktionieren. So wie ich die Leute bei D&H einschätze, wird noch so einiges mit dem SX-Bus gehen.
Als ich ca. 2002/2003 in die digitale Welt der Modelleisenbahn einstieg, wurde SX schon als "Tot" dargestellt. Wenn ich mir aber diesen Thread so durchlese, bin ich froh, dass ich damals ich mit dem SX-Bus angefangen habe.

Grüße
Andreas

Hello!
Mein Bruder, der ist Automechanikermeister, lehnt es kategorisch ab Frostschutz in seinen Autos einzufüllen. So vermeidet er auch alle damit zusammenhängende Probleme. Man muß nur die Erwartungen niedrig genug ansetzen dann kann man nicht endtäuscht werden, Sein Fuhrpark eignet sich auch dazu siehe u.a. https://dlv.co.at
-AH-

#31 Arnold,

ich freue mich bei jeden Fahrbetrieb über einen funktionierenden und störungsfreien Betrieb, und das alles mit einem "veralteten" Bus in deinen Augen. Ich weiß ja nicht, ob du schon einmal eine größer Anlage mit der RMX-USB Zentrale und den RMX-Bus bzw. eine Anlage mit der FCC und den SX-Bus im Betrieb in Verbindung mit dem TrainController gesehen hast. Vielleicht würdest du dann deine Meinung ändern. Therorie und Praxis sind wie im Leben ein sehr großer Unterschied.

Ich wünsche den Threadsteller Dalmi viel Spaß mit seiner Z21 schwarz, und bin mir sicher, daß er auch einen funktionierenden und störungsfreien Betrieb an seiner künftigen Anlage herstellen wird, selbst wenn er nur den LocoNet-Bus verwendet (der ja in deinen Augen auch nichts ist).

Grüße
Andreas