Digitalsysteme .... eine Gegenüberstellung: Unterschied zwischen den Versionen

Aus RailRoad&Co.-Wiki
Zur Navigation springenZur Suche springen
Zeile 7: Zeile 7:
>>>>> im Aufbau begriffen; Zwischenspeicherung !!! <<<<<<<<<<
>>>>> im Aufbau begriffen; Zwischenspeicherung !!! <<<<<<<<<<


===1. Vorwort===
==Vorwort==


Aus den vielen Anfragen und Beiträgen aus dem Forum: Railroad & Co, Freiwald Software (Egmating)
Aus den vielen Anfragen und Beiträgen aus dem Forum: Railroad & Co, Freiwald Software (Egmating)
Zeile 23: Zeile 23:




===2. Betrachtete Digitalsysteme===
==Betrachtete Digitalsysteme==


Am Markt werden eine Reihe von digitalen Systemen angeboten.
Am Markt werden eine Reihe von digitalen Systemen angeboten.
Zeile 36: Zeile 36:




===3. Digitalsystem - Architekturen===
==Digitalsystem - Architekturen==


====3.1 Historie====
===Historie===


* allgemeine Betrachtung
* allgemeine Betrachtung
Zeile 62: Zeile 62:




* spezifische Entwicklungshintergründe und ihre Auswirkungen
* spezifische Entwicklungshintergründe


Märklin mit seinen Systemen als auch DCC wurden auf dem Hintergrund der "Spielzeugindustrie" entwickelt.
Märklin mit seinen Systemen als auch DCC wurden auf dem Hintergrund der "Spielzeugindustrie" entwickelt.
Zeile 80: Zeile 80:
Selectrix fällt damit in die Kategorie: "dezentrale oder verteilte Systeme" .
Selectrix fällt damit in die Kategorie: "dezentrale oder verteilte Systeme" .


*  ... und ihre Auswirkungen


Letztendlich ist es unter Berücksichtigung des vorgenannten nicht verwunderlich, daß sich ganz unterschiedliche Kommunikationsstrukturen entwickelten, sowohl auf der Hardware-Seite als auch auf der Software-Seite in Form der Protokolle.
Letztendlich ist es unter Berücksichtigung des vorgenannten nicht verwunderlich, daß sich ganz unterschiedliche Kommunikationsstrukturen entwickelten, sowohl auf der Hardware-Seite als auch auf der Software-Seite in Form der Protokolle.


Während Selectrix
Während Selectrix mit einem Bussystem und einem Protokolltyp für Fahren, Schalten und Melden auskommt, werden bei DCC und Märklin jeweils 2 Bussysteme und Protokolltypen benötigt; eines für Fahren und Schalten und eines für Melden.




====3.2 System- und Kommunikations- Strukturen====
===System- und Kommunikations- Strukturen===


 
====zentralistische Systeme====
====3.3 zentralistische Systeme====


* Fahren
* Fahren
* Schalten
* Schalten
Bei diesen Systemen sind sowohl die Lok-Dekoder als auch alle anderen Dekoder zum Schalten (Anzeigen) über eine 2 adrige Verbindung -- z.B. Schiene / Gleis -- mit der Zentrale verbunden.
Von der Zentrale werden alle Einstellbefehle codiert über diesen Bus übermittelt.
Die jeweilge Spannung und ihre digitale Codierung ist zwischen den beiden Systemen DCC und Märklin sehr unterschiedlich.
Nähere techn. Informationen über die Busse und ihre Protokolle können über die Links (unten) abgerufen werden.
Die Zentrale verwaltet auch alle Zeiten, die zwischen zwei Aktionen, die eine funktionelle Einheit bilden, liegen (z.B. schalten von Weichen, Signalen).
* Melden
* Melden
Diese Funktion wurde erst mit der Erweiterung der "PC-Steuerung" notwendig.
Sie ist quasi das "Auge des Modellbahn-Steuerungsprogramms, hier von TrainController (TC).
Das Prinzip des Meldens ist die Erkennung eines Stromflusses, ausgelöst durch ein Fahrzeug, welches sich in einem Überwachungsbereich (Gleisabschnitt) befindet.
-- DCC
  Die Besetztmeldung / Erkennung basiert bei DCC auf der sog. "Strommessung".
  Hier wird der gesamte Strom eines Abschnittes über einen Bestztmelder (Dekoder) geführt.
  Fließt ein Strom weil sich ein Verbraucher (Lok oder Wagen mit Beleuchtung oder
  "Widerstandsachsen") befindet, dann wird dies erkannt und über einen eigenen Meldebus mit
  eigenem Protokoll an die Zentrale gemeldet.
-- Märklin
  Die Besetztmeldung / Erkennung basiert bei Märklin aus der "Masse-Kontaktgabe".
 
* Identifikation von Lok-/Fahrzeug- Adressen
* Identifikation von Lok-/Fahrzeug- Adressen




====3.4 dezentrale Systeme====
====dezentrale Systeme====


* Fahren
* Fahren
Zeile 105: Zeile 133:




====3.5 Lok-/Fahrzeug - (Multiprotokoll-)Dekoder====
===Lok-/Fahrzeug - (Multiprotokoll-)Dekoder===








===4. Einsatz auf Modellbahn-Anlagen===
==Einsatz auf Modellbahn-Anlagen==


====4.1 Labor v.s. Anlage====
===Labor v.s. Anlage===


====4.2 Beispiel >> Schalten====
===Beispiel >> Schalten===


* Aufgabe
* Aufgabe
Zeile 123: Zeile 151:




====4.3 Beispiel >> Fahren / Multiprotokolle====
===Beispiel >> Fahren / Multiprotokolle===






====4.4 Zusammenwirken mit dem Software Programm  TrainController (TC)====
===Zusammenwirken mit dem Software Programm  TrainController (TC)===






===5. Produktanbieter / Quellen===
==Produktanbieter / Quellen==





Version vom 18. Juli 2011, 18:11 Uhr

Modellbahn Digitalsysteme ... eine Gegenüberstellung; aber keine Vergleiche und Bewertungen


Digitalsysteme ... eine Gegenüberstellung

>>>>> im Aufbau begriffen; Zwischenspeicherung !!! <<<<<<<<<<

Vorwort

Aus den vielen Anfragen und Beiträgen aus dem Forum: Railroad & Co, Freiwald Software (Egmating) habe ich entnommen, daß viele Modellbahner, die neu in das digitale Zeitalter eintreten oder eine Umstellung / Erweiterung vor haben, unsicher sind, welches digitale System und welche Komponenten denn nun "die richtigen" seien.

Ferner habe ich den Eindruck gewonnen, daß bei bestimmten Betriebssituationen Probleme auftauchen, die sinnvoll nur unter Berücksichtigung der Kenntnisse der / des digitalen Systems(e) gelöst werden können.

Bei all dem wurde und werde ich an meine eigene Zeit erinnert, als ich vom analogen System auf das digitale umgestiegen bin.

Diese Gegenüberstellung soll die reinen technischen Daten und Fakten, wie sie von den Herstellern in ihren Datenblättern bzw. in den Normen definiert sind ergänzen.

Ich betone ausdrücklich, daß dieser Beitrag kein Vergleich über "für und wider" darstellen und auch kein System bewerten soll.

Der Leser soll diese Informationen mit aufnehmen und hoffentlich erfolgreich in seine Lösungsfindung einbeziehen.


Betrachtete Digitalsysteme

Am Markt werden eine Reihe von digitalen Systemen angeboten. Ich will hier nur die betrachten, die am häufigsten im oben erwähnten Forum vertreten sind; hierzu zählen ...

  • DCC
  • Märklin mit seinen Varianten
  • Selectrix (SX)

In dieser Abhandlung wird der Stand der Systeme betrachtet, wie er im Juli 2011 vorlag. Spätere Entwicklungen müssen jeweils nachgetragen werden.


Digitalsystem - Architekturen

Historie

  • allgemeine Betrachtung

Meines Wissens und meiner Erinnerung nach brachte die Fa. Märklin als erstes ein "komplettes" Digitalsystem auf den Markt, welches als "Motorola I" bekannt wurde. Es folgten über die Jahre die Nachfolger "Motorola II" und "mfx".

Märklin führte sein digitales System unter dem Marketingaspekt ein: Zwei Drähte genügen zum Betreiben der Anlage. Kein "Drahtverhau" mehr, wie bei analogen Anlagen. Als Drähte fungierten weitestgehends die Schienen als Verbindung zwischen Zentrale und jeweiligen Dekodern. Für die Rückmeldung (Besetztmeldung) wurde eine separate Kommunikationsstrecke eingeführt, der "s88 - Bus".

Die technischen Details des Märklinsystems wurden ofiziell nie offengelegt. Technisch interessierte Nutzer ermittelten "rückwärts" die Protokolle für "Motorola I / II" und konnten somit Selbsbauprodukte aufbauen. Für "mfx" liegen, auch aus Patentschutzgründen keine Detail-Informationen vor.

Man kann unter diesen Randbedingungen die Märklinsysteme als "geschlossene Systeme" einstufen.


Aufgrund dieser "Abschottung" entwickelte die Zubehörindustrie, wohl im Zusammenwirken mit anderen Modellbahnherstellern", das digitale System "DCC", welches genormt wurde und bei dem alle technischen Daten "offen liegen" und kostenlos einzusehen sind.


Die Fa. Trix, seinerzeit noch juristisch eigenständig, entwickelte zusammen mit industrieller Unterstützung das digitale System "Selectrix". Dieses System ist ebenfalls genormt und alle Informationen / Daten liegen offen vor.


  • spezifische Entwicklungshintergründe

Märklin mit seinen Systemen als auch DCC wurden auf dem Hintergrund der "Spielzeugindustrie" entwickelt. Dies bedeutet, alle bisherigen Tasten, Schalter, Trafo - Funktionen sollten in eine Zentrale integriert werden. Die Peripherie, d.h. die Dekoder sollten so einfach und damit so preiswert als irgend möglich sein.

Die Anbindung an einen PC kam eigentlich erst später hinzu und stand nicht im Fokus der ersten Entwicklungen.

Somit lassen sich diese beiden Systeme als "zentralistische Systeme" definieren.


Bei der Entwicklung von Selectrix wurde, wohl durch die industriellen Erfahrungen mit verteilten Systemen, ein gänzlich anderer Ansatz gewählt. Im Selectrix-Verbund sollten auch die peripheren Komponenten soviel "Intelligenz" als irgend möglich besitzen um ein "verteiltes System" aufbauen zu können. Dieser Ansatz erforderte auch ein komplett anderes Kommunikationssystem (Bussystem). Bei Selectrix kann jeder Busteilnehmer mit jedem anderen Daten / Informationen austauschen.

Dies ist bei den beiden vorgenannten Systemen nicht möglich, dort gibt es nur eine Richtung von der Zentrale zu den Dekodern (Peripherie);(ausgenommen das im Moment auf den Markt kommende RailCom Verfahren bei DCC > siehe weiter unten; als auch mfx hier gibt es eine Gegenrichtung Lokdekoder -> Zentrale).

Selectrix fällt damit in die Kategorie: "dezentrale oder verteilte Systeme" .


  • ... und ihre Auswirkungen

Letztendlich ist es unter Berücksichtigung des vorgenannten nicht verwunderlich, daß sich ganz unterschiedliche Kommunikationsstrukturen entwickelten, sowohl auf der Hardware-Seite als auch auf der Software-Seite in Form der Protokolle.

Während Selectrix mit einem Bussystem und einem Protokolltyp für Fahren, Schalten und Melden auskommt, werden bei DCC und Märklin jeweils 2 Bussysteme und Protokolltypen benötigt; eines für Fahren und Schalten und eines für Melden.


System- und Kommunikations- Strukturen

zentralistische Systeme

  • Fahren
  • Schalten

Bei diesen Systemen sind sowohl die Lok-Dekoder als auch alle anderen Dekoder zum Schalten (Anzeigen) über eine 2 adrige Verbindung -- z.B. Schiene / Gleis -- mit der Zentrale verbunden.

Von der Zentrale werden alle Einstellbefehle codiert über diesen Bus übermittelt.

Die jeweilge Spannung und ihre digitale Codierung ist zwischen den beiden Systemen DCC und Märklin sehr unterschiedlich. Nähere techn. Informationen über die Busse und ihre Protokolle können über die Links (unten) abgerufen werden.

Die Zentrale verwaltet auch alle Zeiten, die zwischen zwei Aktionen, die eine funktionelle Einheit bilden, liegen (z.B. schalten von Weichen, Signalen).


  • Melden

Diese Funktion wurde erst mit der Erweiterung der "PC-Steuerung" notwendig. Sie ist quasi das "Auge des Modellbahn-Steuerungsprogramms, hier von TrainController (TC).

Das Prinzip des Meldens ist die Erkennung eines Stromflusses, ausgelöst durch ein Fahrzeug, welches sich in einem Überwachungsbereich (Gleisabschnitt) befindet.

-- DCC

  Die Besetztmeldung / Erkennung basiert bei DCC auf der sog. "Strommessung".
  Hier wird der gesamte Strom eines Abschnittes über einen Bestztmelder (Dekoder) geführt.
  Fließt ein Strom weil sich ein Verbraucher (Lok oder Wagen mit Beleuchtung oder
  "Widerstandsachsen") befindet, dann wird dies erkannt und über einen eigenen Meldebus mit
  eigenem Protokoll an die Zentrale gemeldet.

-- Märklin

  Die Besetztmeldung / Erkennung basiert bei Märklin aus der "Masse-Kontaktgabe".
  
  • Identifikation von Lok-/Fahrzeug- Adressen


dezentrale Systeme

  • Fahren
  • Schalten
  • Melden
  • Identifikation von Lok-/Fahrzeug- Adressen


Lok-/Fahrzeug - (Multiprotokoll-)Dekoder

Einsatz auf Modellbahn-Anlagen

Labor v.s. Anlage

Beispiel >> Schalten

  • Aufgabe
  • Lösung: Märklin / DCC
  • Lösung: Selectrix


Beispiel >> Fahren / Multiprotokolle

Zusammenwirken mit dem Software Programm TrainController (TC)

Produktanbieter / Quellen

--Jens Mohr; 82275 Emmering (bei München); www.jens-mohr.com 09:40, 17. Jul. 2011 (UTC)