Inhaltsverzeichnis
Werbung
BETRIEBSANLEITUNG BASISGERÄTE MX10, MX10EC
Schienensignal, Rückmeldungen, Datenbank
6.
DCC und MOTOROLA (MM) bilden die Grundausstattung des MX10. Hardware und Software sind je-
doch offen für die Erweiterung mit anderen Protokolle, insbesondere mfx (mit RDS-Rückmeldung) und
Selectrix, falls ein solcher Bedarf besteht. Denkbar wäre auch eine Erweiterung in Richtung neuer, effi-
zienterer Methoden (als es die existierenden Formate sind) der Datenkommunikation auf der Schiene.
HINWEIS: Motorola (MM) in aktueller Software (auf der diese Betriebsanleitung basiert) noch
NICHT implementiert.
RailCom
und ZIMO Zugnummernerkennung:
®
Die „bi-directional communication" nach „RailCom
MX10 / MX32 / StEin) ein Bestandteil aller relevanten Komponenten.
Das MX10 ist mit zwei „RailCom
-Präzisions-Global-Detektoren" ausgestattet; d.h. für jeden der bei-
®
den Schienenausgänge ist ein getrennter Detektor eingebaut.
„Global" ist ein Begriff aus der RailCom
-Norm (bereits aus NMRA-Zeiten) und bedeutet, dass es sich
®
um den Empfang jener RailCom
-Nachrichten handelt, die unabhängig von der aktuellen Position (=
®
dem Gleisabschnitt) des Fahrzeugs sind, also beispielsweise Rückmeldungen der Geschwindigkeit, des
Stromverbrauchs, von Alarmen, Weichenstellungen, CV Auslesewerten, usw. *).
„Präzision" deutet darauf hin, dass Empfang und Auswertung der RailCom
standardisierten Schwellwerten einfacher Detektoren erfolgt, sondern dass das RailCom
nächst digitalisiert wird und nachher analysiert wird, um auch stark abgeschwächte und verstümmelte
Meldungen zu entziffern und damit möglichst unempfindlich gegenüber Einflüssen zu sein, wie sie in der
praktischen Anwendung auf einer großen Anlage auftreten, beispielsweise durch das Abziehen großer
Teile des RailCom
-Rückmeldestroms durch beleuchtete Wagen.
®
„lokale Detektoren" hingegen befassen sich mit der Identifizierung der in einzelnen Gleisabschnitten vorhandenen
*)
Fahrzeugen; diese Aufgabe wird im Rahmen des ZIMO Systems von den „StEin"-Modulen (= Stationär-Einrichtungs-
Modulen) wahrgenommen; diese arbeiten allerdings nicht als einfachen Lokaldetektoren, sondern lesen auch globale
Nachrichten (und leiten diese an die Zentrale MX10 weiter), weil die Empfangsqualität im Falle von großen Anlagen im
einzelnen Gleisabschnitt besser sein kann als am Standort der Zentrale.
Das ZIMO Basisgerät MX10 liest auch die „Zugnummernimpulse" der ZIMO Decoder mit, welche ne-
ben RailCom
als Quittung für den Empfang von DCC-Paketen verwendet werden, auch von Deco-
®
dern aus der Zeit vor dem Jahr 2005, als RaiCom
Zugnummernerkennung als Rückmeldung aus den Decodern.
ACHTUNG: Während der Abarbeitung von Programmier- und Auslesebefehlen in SERV PROG
(Schiene-2 als Programmiergleis) werden KEINE RailCom
Schiene-1 noch Schiene-2). Das betrifft aber NICHT die Zeit, in der ein Fahrpult im „SERV
PROG" ist, sondern nur die kurze Zeitspanne des Quittungsempfanges.
RailCom® ist ein eingetragenes Warenzeichen der Firma Lenz Elektronik GmbH
" ist innerhalb des ZIMO Systems (der Generation
®
-Meldungen nicht nach den
®
®
-Signal zu-
noch nicht existierte, sondern eben nur diese ZIMO
®
-Meldungen empfangen (weder auf
®
Seite 21
Die Organisation der Datenaussendung über das Schienensignal (DCC oder MM)
(in vielen Unterlagen als „Aussendezyklus" bezeichnet):
Neben der Versorgung der Anlage mit Fahrstrom muss eine Digitalzentrale vor allem die für Fahr-
zeuge und Zubehör-Artikel bestimmten Informationen aus den Eingabegeräten (Fahrpulte, Computer,
...) übernehmen und auf effiziente Weise, d.h. mit möglichst geringer Zeitverzögerung und mit mög-
lichst hoher Sicherheit, zu den Decodern übermitteln.
Dabei muss immer die Störungsanfälligkeit des Datenkanals berücksichtigt werden, wie er in der Mo-
dellbahnwelt wegen der Kontaktunterbrechungen zwischen Schiene und Fahrzeugen existiert.
Daher wird ein ausgeklügeltes Prioritäten-Schema eingesetzt, das bestimmt, wie die verfügbare Aus-
sendezeit auf die unterschiedlichen aktuellen Datenpakete aufgeteilt wird. Es werden die folgenden
Prioritätsstufen unterschieden; höhere Priorität (Reihenfolge 0, 1, 2..) bedeutet häufigere
Aussendung:
0. Protokoll-Erfordernisse (Request-for-Service-Slots, Zeit-Sync für Decoder, u.a.)
1. Änderung des Dateninhalts (neue Geschwindigkeit, Funktionen, ..) durch Fahrpult, Computer,
u.a.
2. Daten für Adressen im Vordergrund eines der Fahrpulte,
3. Daten für Adresse von „Nebenobjekten" der Vordergrund-Adressen, z.B. in Doppeltraktionen,
4. Daten für Adressen von Computer-Fahrpulten (ESTWGJ, STP, TrainController, usw.),
5. Daten für Adressen im RüF eines der Fahrpulte oder Favoriten-Liste im Computer
6. Daten für Adressen im der System-Datenbank (die nicht in eine der höheren Prioritäten fallen),
7. Scan-Zyklus, um nicht gemeldete Adressen zu finden.
Platz blank, Platz für weitere Beschreibung.
Werbung
Inhaltsverzeichnis
