BiDiB, ein universelles Steuerprotokoll für Modellbahnen

BiDiB - Bidirektionaler Bus - Logo

Inhaltsverzeichnis

Allgemeines

Das Protokoll BiDiB dient zur Kontrolle einer Modellbahnanlage. Es ermöglicht die Ansteuerung von Loks, Zubehör und sichere Übertragung von Rückmelderinformationen aus der Modellbahnanlage an den steuernden Rechner.

BiDiB kann über verschiedene Übertragungsmedien transportiert werden, dabei wird das Framing und die Sicherung der Nachrichten gewährleistet.

Eine Erläuterung der hier verwendeten Begriffe und der Protokollgrundzüge findet sich im allgemeinen Teil der Protokollbeschreibung, gleiches gilt auch für die Hinweise zur Benutzung und zur Lizenz.

Dieser Abschnitt der Protokollbeschreibung erläutert nur einen Teil der Nachrichten.

Revisionsstand

Dieses Dokument beschreibt Revision 1.29 von BiDiB, Stand 21.07.2023.

Die Revisionsgeschichte ist dem allgemeinen Teil zu entnehmen.

4.5. Gleisausgabe-Geräte

4.5.1. Ansteuerung Gleisausgabe

Gleisausgabe-Geräte sind Knoten, die in der Lage sind, ein DCC-Signal zu erzeugen. Dieses DCC-Signal ist a-priori nur dem Knoten selbst und allen direkt angeschlossenen Geräten bekannt. Der Knoten kann durch Systemnachrichten freigeschaltet werden, dass er die zentrale Verteilung des DCC-Signals (über das entsprechende Leitungspaar im BiDiBus) ansteuern darf. BiDiB enthält also die Möglichkeit, verschiedene DCC-Systeme parallel zu betreiben. Mögliche Anwendungen hierfür sind z. B. ein separates Programmiergleis, welches unabhängig von Hauptgleis betrieben werden kann oder ein separater DCC-Signalzweig, welcher nur für das Schalten verwendet wird.

Ein Problem auf Ausstellungsanlagen sind 'hängende' Fahrzeuge, welche bedingt z. B. durch Kontaktschwierigkeiten Fahrbefehle nicht mehr empfangen und dadurch den Betrieb stören. Im BiDiBus ist eine schnelle Durchleitung der Information vorgesehen, ob eine railcom-Quittung von der Lok empfangen wurde. Diese Information kann von der Gleisausgabeeinheit empfangen werden und zu einer Aussage zusammengefasst werden, ob die entsprechende Lok noch in Verbindung mit der Zentrale ist. Stellt die Zentrale einen Verlust der Lok fest, so sendet sie ein Nachricht an den Host.

Im Regelbetrieb wird das Gleisausgabe-Gerät vom Host angesprochen. Es besteht jedoch der Wunsch, dass DCC-Generatoren sowohl vom Host als auch dezentral angesprochen werden können. Hierbei entsteht neben dem Zielkonflikt über die Kontrolle ('wer kontrolliert die Lok, wer sichert den Fahrweg') auch ein Konflikt, welche Stelle eine Quittierung über den Befehl und die erfolgte Ausgabe auf dem Gleis erhält. In BiDiB ist es vorgesehen, dass im Regelbetrieb lokale Kontrollgeräte (verteilte Handregler und Stellpulte) ihre Stellanforderungen an den Host senden, dieser prüft und filtert das fallweise (z. B. kein Stellen einer Weiche in einer reservierten Fahrstraße) und erteilt dann den entsprechenden Befehl an das Gleisausgabegerät. Das Gleisausgabegerät quittiert dies im Regelbetrieb gegenüber dem Host.

Havarie- und Testbetrieb: Darüber hinaus gibt es Situationen, in denen der Host nicht in der Lage ist, die gewünschten Befehle zu erteilen, z. B. weil die Betriebssituation nicht vorgesehen ist, das PC-Programm abgestürzt ist oder der PC schlicht nicht angeschlossen ist. Für diesen Havarie- und Testbetrieb ist direkte lokale Kontrolle vorgesehen.

Für diesen Notbetrieb dürfen daher DCC-Generatoren die lokale Busstruktur (z. B. BiDiBus) auf Befehle zur Zugsteuerung abhören und diese Befehle (quittungsfrei) ausführen. Diese Fähigkeit wird über ein Feature eingestellt. Wenn das Feature aktiviert ist, werden Handreglerbefehle (die eigentlich an den Host gesendet werden) von der Gleisausgabeeinheit sozusagen im 'Spionage-Mode' mitgelesen und ausgeführt. Damit hier jedoch der Zielkonflikt (wer kontrolliert) eindeutig gelöst werden kann, hat der Host über den Befehl MSG_CS_ALLOCATE die Möglichkeit, diese Spionage zu unterbinden und die Handregler damit quasi 'auszusperren'. Dieses 'Aussperren' der Handregler über den Befehl MSG_CS_ALLOCATE ist aber immer nur für eine beschränkte Zeit gültig, MSG_CS_ALLOCATE muss also permanent wiederholt werden. Damit ist ein nahtloser Übergang der Steuerung vom PC auf Handregler möglich, auch Fahren ohne PC ist ohne weitere Maßnahmen möglich.

Watchdog: Um im Falle eines unerwarteten Verbindungsabbruches zwischen Hostprogramm und Gleisausgabe nicht Züge ohne Kontrolle unterwegs zu haben, ist die Gleisausgabe mit einer Verbindungsüberwachung ausgerüstet. Hierbei muss das Hostprogramm in regelmäßigen Abständen mittels MSG_CS_SET_STATE (BIDIB_CS_STATE_GO) den ON-Zustand der Zentrale erneuern, dabei legt das Feature FEATURE_GEN_WATCHDOG das Intervall fest, in dem die Erneuerung mindestens erfolgen muss.

Erfolgt diese Erneuerung nicht, dann werden von der Gleisausgabeeinheit alle Loks angehalten, welche unter Kontrolle des Hosts stehen. Dieses Anhalten erfolgt permanent (d.h. die geladene Geschwindigkeit der Loks wird auf bleibend 0 gesetzt).

Ein Hostprogramm muss also vor Beginn der Lokkontrolle das Feature FEATURE_GEN_WATCHDOG auslesen und entsprechend häufig den ON-Zustand erneuern.

Auskunftsfunktion: Wenn ein Steuer- oder Anzeigeprogramm auf eine bereits laufende Gleisausgabe trifft und sie nicht zurücksetzt, sind Auskünfte über die zur Zeit aktiven Fahrzeuge nötig. Die Nachricht MSG_CS_QUERY und die zugehörige Antwort MSG_CS_DRIVE_STATE ermöglichen diese Abfrage der Adressen, Formate und Zustände.

4.5.2. Features für Gleisausgabe
Aufstellung der Features für die Gleissignal-Klasse
NummerNameBedeutung
100 FEATURE_GEN_SPYMODE Spymode
Hier wird eingestellt, ob lokale Kontrolle (Mithören von Handreglernachrichten) erlaubt ist oder nicht.
0: Mithören nicht erlaubt.
1: Mithören prinzipiell erlaubt, kann aber durch MSG_CS_ALLOCATE unterbunden sein.
101 FEATURE_GEN_WATCHDOG Hostüberwachung
0: Keine Überwachung (=keine Watchdogfunktion).
1…100: Hostprogramm muss periodisch den MSG_CS_SET_STATE(GO) wiederholen. Wiederholung muss innerhalb des Intervalls FEATURE_GEN_WATCHDOG * 100ms erfolgen. default = 20, entsprechend 2s.
102 FEATURE_GEN_DRIVE_ACK Quittungen für Fahr- und Programmierbefehle – Bitfeld:
Bit 0 aktiviert zusätzlich Ebene 1 (Gleisausgabe)
103 FEATURE_GEN_SWITCH_ACK Quittungen für Schaltbefehle – Bitfeld:
Bit 0 aktiviert zusätzlich Ebene 1 (Gleisausgabe)
106 FEATURE_GEN_POM_REPEAT Anzahl von POM-DCC-Nachrichten, welche die Zentrale je POM-Befehl sendet
2: Standard gemäß railcom-Spezifikation (default).
3…8: Höhere Anzahl an DCC-Nachrichten, um unwillige Dekoder zu korrektem Antworten zu bewegen.
107 FEATURE_GEN_DRIVE_BUS Kontrolle des DCC-Busses (innerhalb BiDiBus)
0: Knoten empfängt DCC vom BiDiBus
1: Knoten treibt DCC auf dem BiDiBus
108 FEATURE_GEN_LOK_LOST_DETECT Gleisausgabe erkennt und meldet 'verlorene' Lokomotiven
0: Verlorene Lokomotiven werden nicht erkannt bzw. gemeldet.
1: Verlorene Lokomotiven werden gemeldet.
109 FEATURE_GEN_NOTIFY_DRIVE_MANUAL Die Gleisausgabe kann fallweise lokale Bedienelemente aufweisen.
BitBedeutung
0 0: Lokal bediente Lokomotiven werden nicht gemeldet.
1: Lokal bediente Lokomotiven werden gemeldet. (default)
1 0: Lokal bediente Accessory werden nicht gemeldet.
1: Lokal bediente Accessory werden gemeldet. (default)
2…7reserviert
110 FEATURE_GEN_START_STATE Zustand der Gleisausgabe nach Power-Up.
0: DCC ist abgeschaltet.
1: DCC ist eingeschaltet.
111 FEATURE_GEN_EXT_AVAILABLE Zusätzliche (Protokoll-)Eigenschaften der Gleisausgabe, die Erweiterung ist verfügbar wenn das jeweilige Bit gesetzt ist.
BitBedeutung
0 Die Gleisausgabe unterstützt Nachrichten für RailcomPlus (MSG_CS_RCPLUS und MSG_CS_RCPLUS_ACK)
1 Die Gleisausgabe unterstützt Nachrichten für M4 (MSG_CS_M4 und MSG_CS_M4_ACK)
2 Die Gleisausgabe unterstützt Nachrichten für DCCA nach RCN218 (MSG_CS_DCCA und MSG_CS_DCCA_ACK)
3 Die Gleisausgabe unterstützt zusätzliche Nachrichten für DCC (SDF, Funktionen bis F68, Analogfunktionen)
4 Die Gleisausgabe unterstützt Nachrichten für MM (Motorola)
5…6reserviert
7 Die Gleisausgabe unterstützt die Auskunftsfunktion für den Wiederholspeicher mittels MSG_CS_QUERY.
4.5.3. Downlink: Nachrichten für Gleisausgabe
  • MSG_CS_ALLOCATE:

    Es folgt ein Byte mit Inhalt 0. (= lokale Busaddresse des Hosts)

    Der Gleisausgabeknoten nimmt keine Befehle von sonstigen lokalen Adressen an. Diese Sperre ist für 2s gültig und verfällt dann von selbst.

  • MSG_CS_SET_STATE:

    Mit diesem Befehl wird der Zustand der Gleisausgabe eingestellt oder abgefragt. Es folgt ein Byte, das den neuen Zustand kodiert. Der Knoten antwortet immer mit einer MSG_CS_STATE.

    Vor dem erstmaligen Aufschalten der Ausgabe sollte der Befehls-Zustand der Lokomotiven kontrolliert werden bzw. alle Lokomotiven aus dem Ausgabespeicher entfernt werden. Damit wird vermieden, dass eventuell noch alte Fahrstufen bei Lokomotiven geladen sind.

    Der Startzustand nach dem Einschalten kann durch das FEATURE_GEN_START_STATE eingestellt werden.

    Kodierung der Zustände von Gleisausgabegeräten
    WertNameBedeutung
    0x0 BIDIB_CS_STATE_OFF Die Gleisausgabe wird abgeschaltet. Als Folge werden auch angeschlossene Booster abschalten.
    0x1 BIDIB_CS_STATE_STOP Alle Loks werden mittels Nothalt angehalten, jedoch Weichen können nach wie vor geschaltet werden. Wenn Stop von der Zentrale nicht unterstützt wird, so wird OFF ausgeführt.
    0x2 BIDIB_CS_STATE_SOFTSTOP Alle Loks werden mit Fahrstufe 0 (also mit ihrer eigenen Verzögerung) angehalten, Weichen können weiterhin geschaltet werden. Wenn Soft-Stop von der Zentrale nicht unterstützt wird, so wird STOP ausgeführt.
    Die Gleisausgabe führt den Soft-Stop durch und steht anschließend im Zustand STOP.
    0x3 BIDIB_CS_STATE_GO Wiederaufnahme des Betriebes, Loks und Weichen können geschaltet werden. Bei aktiviertem Watchdog muss dieser Befehl permanent wiederholt werden.
    0x4 BIDIB_CS_STATE_GO_IGN_WD Wiederaufnahme des Betriebes, Loks und Weichen können geschaltet werden. Ein evtl. vorhandener Watchdog wird dabei außer Betrieb gesetzt (=ignore Watchdog)
    0x8 BIDIB_CS_STATE_PROG Programmiermode; Die Zentrale hat in den Programmiermode umgeschaltet und ist zur Ausführung von Programmierbefehlen (auf den Programmiergleis) bereit. Der normale Betrieb sowie ein evtl. Watchdog ruht.
    0x9 BIDIB_CS_STATE_PROGBUSY Programmiermode; diese Meldung zeigt an, dass aktuell ein Programmiervorgang auf dem Programmiergleis durchgeführt wird. (nur bei Abfrage).
    0xD BIDIB_CS_STATE_BUSY Die Gleisausgabe ist nicht mehr aufnahmefähig für neue Befehle, z. B. weil entsprechende Ausgabe-Fifos voll sind. (Nachricht nur bei Abfrage)
    0xFF BIDIB_CS_STATE_QUERY Der Zustand wird abgefragt. (nur für MSG_CS_SET_STATE).
  • MSG_CS_DRIVE:

    Mit diesem Befehl werden Fahrbefehle ausgegeben. Es folgen weitere Parameter, welche Format und auszugebende Funktionen kennzeichnen. Wenn eine Lok keine höheren Funktionen angelegt hat, sollen die entsprechenden Gruppen der Funktionsbefehle als inaktiv gekennzeichnet werden. Das schont speziell die knappe Ressource Bandbreite am Gleis.

    MSG_CS_DRIVE Befehle werden von einer oder mehreren MSG_CS_DRIVE_ACK Nachrichten quittiert. Die verschiedenen Quittungsstufen können per FEATURE_GEN_DRIVE_ACK im Ausgabeknoten zugeschaltet werden. Wenn mehrere Fahrbefehle für die gleiche DCC-Adresse erteilt werden, so ist es den Ausgabegerät erlaubt, bei Engpässen in der Bandbreite diese zusammenzufassen. In diesem Fall können zwischenliegende Quittungen entfallen.

    Fahrbefehle werden immer mit einer Fahrstufenanzahl von 127 + Richtungsbits übergeben, erst die Gleisausgabeeinheit konvertiert diesen Fahrbefehl entsprechend dem gewählten Format auf die entsprechende Fahrstufenzahl am Gleis.

    MSG_CS_DRIVE Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits.
    ADDRH Adresse, obere 6 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt. Die Adresse 0 ist keiner echten Lok zugeordnet und hat eine Sonderfunktion. (3) (4)
    DATA0 Bitfeld
    BitBedeutung
    3…0 Format (5):
    0000: DCC14 (14 Fahrstufen)
    0001: DCC SDF (126 Fahrstufen)
    0010: DCC28 (28 Fahrstufen)
    0011: DCC128 (126 Fahrstufen)
    0100: MM14
    0101: MM27a (27 Fahrstufen mittels alternierender 14 Fahrstufenbefehle)
    0110: MM27b (28 Fahrstufen mittels Licht)
    0111: M4/MFX (126 Fahrstufen)
    1000…1111: reserviert
    7…4reserviert
    DATA1 Bitfeld Ausgabe Aktiv
    Für Formate DCC14, DCC28, DCC128
    BitBedeutung
    00: keine Geschwindigkeit ausgeben
    1: Geschwindigkeit ausgeben
    10: F0,F1…F4 nicht ausgeben
    1: F0,F1…F4 ausgeben
    20: F5…F8 nicht ausgeben
    1: F5…F8 ausgeben
    30: F9…F12 nicht ausgeben
    1: F9…F12 ausgeben
    40: F13…F20 nicht ausgeben
    1: F13…F20 ausgeben
    50: F21…F28 nicht ausgeben
    1: F21…F28 ausgeben
    7…6reserviert
    Diese Bits bezeichnen die jeweils gültigen Datenfelder in den nachfolgenden Byte. Nur diejenigen Datenfelder, deren Bits gesetzt sind, werden von Ausgabeeinheit übernommen.
    Wenn alle Bits = 0 gesetzt sind, so wird die Lok in der Ausgabeeinheit aus dem Wiederholspeicher entfernt (2), dies wird mit ACK=1 quittiert.
    DATA2 Geschwindigkeit, bestehend aus Richtung (MSB) und Speed (7 LSBs) (1)
    DATA3 FL, F4 – F1; 3 MSBs sind reserviert.
    Die Bitorder der Funktionsbits ist: 3*reserved, FL (Licht), F4, F3, F2, F1
    DATA4 F12 – F5
    DATA5 F20 – F13
    DATA6 F28 – F21
    (1)
    Geschwindigkeit ist analog zum DCC128-Geschwindigkeitsbefehl kodiert, unabhängig von gewählten Lokformat.
    • Das MSB kodiert die Fahrtrichtung: 1 = vorwärts, 0 = rückwärts
    • Die LSBs (Bit 6…0) kodieren die Geschwindigkeit (Speed), wobei 0 = Halt und 1 = Nothalt bedeutet.
    Werte von 2…127 bezeichnen die Fahrstufen. Erst die Gleisausgabeeinheit konvertiert in das jeweilige Format, hierbei ist die Umsetzung gemäß folgender Regel vorzunehmen:
    • DCC128: Fahrstufe (1…126) = Speed - 2 + 1 = (Speed-1)
    • DCC28: Fahrstufe (1…28) = GANZZAHL((Speed - 2) * 2 / 9) + 1 = ((Speed-1) * 2 + 7) / 9
    • DCC14: Fahrstufe (1…14) = GANZZAHL((Speed - 2) / 9) + 1 = ((Speed-1) + 8) / 9
    Siehe hierzu auch: Erläuterungen zur Geschwindigkeitskodierung.
    (2)
    Eine unbenutzte Lokomotive sollte aus der Ausgabeeinheit abgemeldet werden, um die geringe Bandbreite am Gleis nicht durch unnötige Refresh-Ausgaben für diese Lok zu belasten.
    (3)
    Wenn die Lok 0 aus der Ausgabeeinheit abgemeldet wird, so werden alle Lokomotiven aus dem Wiederholspeicher entfernt (Init).
    (4)
    In DCC gibt es zwei Adressierungsarten: kurze und lange Adresse. Theoretisch handelt es sich dabei um zwei komplett getrennte Adressräume. Es ist jedoch allgemeine Praxis, dass in Steuergeräten diese beiden Adressräume zu einem Adressraum vereint werden. Auch in BiDiB werden alle Lokadressen generell in einem 16 Bit Adressraum abgebildet (unabhängig von Format und Adressierung).
    Nach RCN 211 werden DCC-Dekoder mit Adressen bis einschließlich 127 automatisch über kurze Adressen, ab 128 über lange Adresse angesprochen. Der Adressraum ist bei DCC nominell auf 1 bis 10239 (einschließlich) beschränkt. Die Ausgabeeinheit prüft das nicht ab, es kann bei Verwendung größerer Adressen also mehrfach zu gleichen Adressen am Gleis kommen.
    Hinweis: Durch verodern der Adresse mit 0xC000 kann man lange Adressierung erzwingen. Es ist aber darauf zu achten dass diese Adresse nicht zugleich als kurze Adresse verwendet wird. (Bei der Rückmeldung wird nicht unterschieden)
    (5)
    Wird ein Format (Gleisprotokoll) von der Ausgabeeinheit nicht unterstützt, so sendet sie MSG_CS_DRIVE_ACK mit ACK=0.
  • MSG_CS_ACCESSORY:

    Mit diesem Befehl werden Zubehörobjekte über die Gleisausgabe (DCC) angesteuert. Es folgen 4 Bytes: ADDRL, ADDRH, DATA, TIME

    Der Zubehördekoder mit der Adresse [ADDRH*256+ADDRL] wird mit dem Begriff in DATA angesteuert. DATA ist eine Bitstruktur, bestehend aus CONFIG (Bit 7,6) ACTIVATE (Bit 5) und ASPECT (Bit 4 – Bit 0).

    MSG_CS_ACCESSORY Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits.
    ADDRH Adresse, obere 3 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-) Adresse und wird bei 0 beginnend gezählt.
    DATA Bitfeld
    Bit Bedeutung
    7 Extended / Basic Accessory: 0=basic, 1=extended
    6 Timing Kontrolle: 0 = konventionell Ansteuerung per coil-on/coil-off, 1 = Ausgabeeinheit macht Timing (siehe Hinweis)
    5 Activate: 0=coil-off / 1=coil-on
    Wenn ACTIVATE gesetzt ist, erzeugt die Gleisausgabe den entsprechenden Einschaltbefehl für den Spulenausgang, bei rückgesetztem ACTIVATE den Ausschaltbefehl.
    4…0 ASPECT
    Zweibegriffige Zubehördekoder werden mit (ASPECT 0 = red) und (ASPECT 1 = green) angesteuert.
    TIME Definition der Schaltzeit analog zur Spezifikation von railcom.
    BitBedeutung
    7 Grundeinheit:
    0: 100ms (d.h. Wertebereich 0…12,7s)
    1: 1s (d.h. Wertebereich 0…127s)
    6…0 Schaltzeit, Wertebereich 0…127
    Damit lassen sich Zeiten von 100ms bis 127s einstellen.
    Hinweise:
    Timingkontrolle an die Ausgabeeinheit übertragen:
    • Nur möglich bei normalen Accessory (Bit 7 = 0)
    • Begriff (Aspect) ist auf 0 und 1 reduziert (nur zweibegriffige Accessory)
    • Die beiden Begriffe eines Accessory sind auf Ebene der Gleisausgabeeinheit nicht gegenseitig verriegelt.
    • Die Anzahl der zugleich aktiven Accessory-Befehle kann durch die Gleisausgabeeinheit beschränkt sein, in diesem Fall wird ein Stellbefehl als 'nicht ausgeführt' quittiert. Er muss dann zu einem späteren Zeitpunkt wiederholt werden.
    Adressierungsschema:
    BiDiB transportiert die Adresse des DCC-Befehls 'as is', es erfolgt keine Umsetzung der Adressen. Bei DCC Basic Accessory sind Einschränkungen des Adressbereichs durch die DCC-Norm vorgegeben: Dekoderadresse 0 wird nicht benutzt (und daraus folgend werden die Adressen 0…3 nicht benutzt) und Adresse 2047 mit Begriff 0 bedeutet Notaus.

    Auch für Accessory-Befehle gibt es ein mehrstufiges Quittungsverfahren, dessen Stufen per FEATURE_GEN_SWITCH_ACK im Ausgabeknoten zugeschaltet werden kann. Der Knoten sendet entsprechende MSG_CS_ACCESSORY_ACK-Nachrichten.

    Anmerkung: Dieser Befehl deckt Zubehördekoder über DCC ab. Es gibt auch noch direkt über BiDiB angesteuertes Zubehör (mit erweiterten Eigenschaften), hierzu dienen die Befehle der Klasse Accessory.

  • MSG_LOCAL_ACCESSORY:

    Diese Nachricht wird nur auf lokaler Ebene verwendet und ist optional.

    Mit diesem Befehl werden (legacy) DCC-Accessory-Befehle als Broadcast verteilt, die Nachricht ist nicht an einzelne Knoten adressiert und wird nicht quittiert. Hubs müssen die Nachricht als Broadcast weiterverteilen. Die Auswertung ist nur für Sonderfälle vorgesehen, wie z. B.:

    • Havariebetrieb: Von einen lokalen Handregler (z. B. Multimaus) sind keine direkten Adressierungen anderer Knoten möglich. Hier kann optional über diesen Befehl ein Notbetrieb von Weichen ermöglicht werden.
    • Legacy Mode: Sollte ein BiDiB-System mit einen veralteten Steuersystem verbunden sein (z. B. über einen entsprechenden Protokollumsetzer), so können die traditionellen Weichenschaltbefehle über diesen Weg verteilt werden.

    Es folgen drei Parameter, STAT_FLAG, ADDRL, ADDRH.

    MSG_LOCAL_ACCESSORY Parameter
    ParameterBeschreibung
    STAT_FLAG Statusflag, zeigt den Zustand der Hostansteuerung und definiert die Auswertbarkeit.
    0: Auswertung freigegeben (z. B. keine gültige Hostverbindung oder Legacy-Mode)
    1…n: reserviert.
    ADDRL Adresse, untere 8 Bits der DCC-Spulenadresse.
    ADDRH Adresse, obere 4 Bits der DCC-Spulenadresse. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Hinweise:
    Es wird nur der 'Coil-On'-Befehl übertragen.
    Eine Adressprogrammierung in den Knoten soll mittels 'Weichenadresse' erfolgen, das ist Spulenadresse / 2.
    Die Adressprogrammierung in den Knoten erfolgt linear, es wird eine Basisadresse und ein abgedeckter Bereich spezifiziert.
  • MSG_CS_POM:

    Mit diesem Befehl werden Programmierbefehle für das Hauptgleis (Program on Mains) ausgegeben. Es folgen weitere Parameter, welche Adresse, angesprochene CV, Daten und durchzuführende Operation bezeichnen. Programmierbefehle werden von einer oder mehreren MSG_CS_POM_ACK Nachrichten quittiert. Die verschiedenen Quittungsstufen können per FEATURE_GEN_DRIVE_ACK im Ausgabeknoten zugeschaltet werden. Sofern eine Gleisausgabeeinheit einen Befehl nicht ausgeben kann (z. B. weil die Operation nicht implementiert ist), liefert sie trotzdem einen MSG_CS_POM_ACK mit ACK=0.

    Sofern ein Railcom-fähiger Dekoder den POM-Befehl beantwortet, erzeugt der zuständige Bidi-Detektorknoten eine MSG_BM_CV oder MSG_BM_XPOM Nachricht.

    POM Befehle gibt es in mehreren Varianten, es gibt folgende wesentliche Unterscheidungsmerkmale:

    • Adressierung des Zieldekoders erfolgt entweder über die DCC-Adresse (normales Verfahren) oder über die Dekoderkennung. Dekoderkennung ist eine 40-Bit Zahl, bestehend aus Herstellerkennung und eineindeutige ID. Beim BiDiB-Befehl wird anhand der MID (Herstellerkennung) unterschieden, ob via Lokadresse oder via DID adressiert wird.
    • Der Zieldekoder kann ein Fahrzeugdekoder oder ein Zubehördekoder sein, bei letzteren wird weiter zwischen Accessory und Extended Accessory unterschieden. Die Unterscheidung wird anhand der beiden MSBs der Adresse getroffen, ähnlich wie bei BiDi-Detektoren kodiert.
    • Adressierung der Ziel-CV innerhalb des Dekoders: Hier gibt es die klassische Variante (POM), hierbei werden 1024 CVs adressiert und der zu lesende/schreibene Inhalt ist ein oder vier Byte. Mit der Einführung von Railcom entstand eine weitere Variante, welche die CV-Adresse auf 24 Bit erweitert und dann jeweils 32 Bit überträgt (XPOM). Beim BiDiB-Befehl wird das durch den OPCODE definiert.

    Die Parameter des MSG_CS_POM-Befehls werden immer mit der maximalen Feldgröße kodiert, auch wenn z. B. nur kurze CV-Adresse angesprochen werden soll. Das Adressfeld ist also immer 8+32 Bit, das CV-Adressfeld 24 Bit und das Datenfeld 32 Bit breit. Wie bei BiDiB üblich wird generell das LSB zuerst übertragen (Little-Endian).

    MSG_CS_POM Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits (DID0 bei Dekoderadressierung).
    ADDRH Adresse, obere 8 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt. (DID1 bei Dekoderadressierung);
    Die Unterscheidung, ob Accessory oder Fahrzeugdekoder adressiert wird, ist in Bit 14 und 15 kodiert:
    • Bit 15,14 = 00: Fahrzeugdekoder
    • Bit 15,14 = 10: (reserviert)
    • Bit 15,14 = 01: Standard Zubehördekoder
    • Bit 15,14 = 11: Extended Zubehördekoder
    ADDRXL 0 bei Lokadressierung, DID2 bei Dekoderadressierung
    ADDRXH 0 bei Lokadressierung, DID3 bei Dekoderadressierung
    MID 0: Adressierung über die Lokadresse
    1…255: Adressierung über Dekoderkennung, dieses Feld ist dann die Herstellerkennung (=DID4)
    OPCODE Byte, definiert die auszuführende Operation
    WertNameBedeutung
    0x00BIDIB_CS_POM_RD_BLOCKPoM (standard CV 0…1023) 4-Byte-Block lesen (Railcom 1.2)
    0x01BIDIB_CS_POM_RD_BYTEPoM (standard CV 0…1023) Byte lesen
    0x02BIDIB_CS_POM_WR_BITPoM (standard CV 0…1023) Bit schreiben
    0x03BIDIB_CS_POM_WR_BYTEPoM (standard CV 0…1023) Byte schreiben
    0x43BIDIB_CS_XWR_BYTE1Short Form CV Access 1 Byte schreiben
    0x47BIDIB_CS_XWR_BYTE2Short Form CV Access 2 Byte schreiben
    0x80BIDIB_CS_xPOM_reservedXPoM (extended CV 24-Bit) reserviert
    0x81BIDIB_CS_xPOM_RD_BLOCKXPoM (extended CV 24-Bit) 4-Byte-Block lesen
    0x82BIDIB_CS_xPOM_WR_BITXPoM (extended CV 24-Bit) Bit schreiben
    0x83BIDIB_CS_xPOM_WR_BYTE1XPoM (extended CV 24-Bit) ein Byte schreiben
    0x87BIDIB_CS_xPOM_WR_BYTE2XPoM (extended CV 24-Bit) zwei Bytes schreiben
    0x8BBIDIB_CS_xPOM_WR_BYTE3XPoM (extended CV 24-Bit) drei Bytes schreiben
    0x8FBIDIB_CS_xPOM_WR_BYTE4XPoM (extended CV 24-Bit) vier Bytes schreiben
    Hinweise:
    Bit 0,1: entspricht den DCC CC-Bits
    Bit 2,3: gibt beim XPOM-Schreiben die Anzahl Bytes - 1 an.
    Bit 6,7: Unterscheidet PoM/short form/XPOM
    CVL, CVH, CVX CV-Adresse, Low Byte zuerst. CVX ist nur bei XPOM erforderlich und wird bei klassischem POM mit 0 übertragen. CV wird beginnend bei 0 gezählt (wie auch der Gleisbefehl). Die CV-Benennungen von Decodern beginnen bei CV1 (CV1 wird mit 0 kodiert).
    Bei Short Form CV Access wird hier direkt der 4-bittige Instruction Type gesetzt, mit folgenden Werten:
    OpcodeWertBedeutung
    XWR_BYTE10b0010Beschleunigungsanpassung, CV23:=DATA0
    XWR_BYTE10b0011Verzögerungsanpassung, CV24:=DATA0
    XWR_BYTE10b1001Service Mode Decoder Lock
    XWR_BYTE20b0100lange Adresse, CV17:=DATA0, CV18:=DATA1, CV29.5=1
    XWR_BYTE20b0101Indexregister, CV31:=DATA0, CV32:=DATA1
    DATA[1…4] CV-Werte.
    Bei Standard-POM ist nur ein Datum erforderlich, bei XPOM-Write sind je nach Zahl der zu schreibenden Bytes bis zu 4 DATA-Bytes erforderlich. Die Angabe erfolgt little endian, d.h. DATA0 kommt an die CV-Adresse, DATA1 an CV-Adresse+1, usw.
    Hinweise:
    Beim Bit Schreiben wird das zuschreibende Bit mittels DATA bestimmt: DATA = 1111DBBB, wobei BBB die Bitposition angibt und D den Wert des Bits. (identisch zur DCC Definition)
    Das Feature FEATURE_GEN_POM_REPEAT legt die Zahl der Wiederholung dieses Befehls auf dem Gleis fest.
    Bei XPOM wird für jeden Zugriff seitens der Gleisausgabe eine Sequence-ID (modulo 4) erzeugt. Diese wird zusammen mit dem Befehl ausgegeben. Die Gleisausgabe muss 'in_order' zu den Befehlen erfolgen.
    Um die Implementierung von Detektoren zu erleichtern, soll die Gleisausgabe anstatt eigener Sequenzen für jeden Dekoder nur eine globale generieren.
    DekoderID, CV-Adresse wie Daten-Bytes sind mit little endian kodiert. Die DCC-Übertragung hingegen verwendet big endian, sendet also in umgekehrter Reihenfolge; z. B. bei der Dekoder-ID dann DID4,DID3,DID2,DID1,DID0
  • MSG_CS_BIN_STATE:

    Mit diesem Befehl werden einzelne Aktionen bei einem Fahrzeugdekoder ausgelöst, z. B. die Kupplung betätigt oder eine (nicht permanente) Funktion ausgelöst. Des weiteren sind einzelne DCC-Nachrichten wie ein Analogfunktionskommando möglich. Es folgen 5 Bytes: ADDRL, ADDRH, STATEL, STATEH, DATA. Dabei kennzeichnet STATE die auszugebende DCC Nachricht.

    MSG_CS_BIN_STATE Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits.
    ADDRH Adresse, obere 6 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt. Die Adresse 0 ist dabei reserviert.
    STATEL Binary State Nummer, untere 8 Bits Funktionssteuerung mit Gruppenbefehlen (RCN 212 2.3.1-4)
    0: reserviert.
    1: Funktionen F1…F4, F0.
    2: Funktionen F5…F8.
    3: Funktionen F9…F12.
    4: Funktionen F13…F20.
    5: Funktionen F21…F28.
    6: Funktionen F29…F36.
    7: Funktionen F37…F44.
    8: Funktionen F45…F52.
    9: Funktionen F53…F60.
    10: Funktionen F61…F68.    		 Analogkanal (RCN 212 2.3.8), Wertebereich 0…255
    STATEH Binary State Nummer, obere 7 Bits. MSB ist zu 0 gesetzt. 0x80 (Opcode 0, MSB ist zu 1 gesetzt). 0x81 (Opcode 1, MSB ist zu 1 gesetzt).
    DATA Binary State Zustand. Wertebereich 0,1 Bitvektor der Funktionsbits gemäß obiger Tabelle, mit der zuerst genannten Funktion als LSB. Wertebereich 0…255 Analoger Datenwert. Wertebereich 0…255

    DCC Binary States umfassen 32767 mögliche Ausgänge, diese werden auf Gleisebene zusammen mit den Datum D in 2 Bytes ausgegeben: DCC kodiert das als DLLLLLLL HHHHHHHH. Die Binary State Nummer 0 bedeutet Adressierung aller Binary States im Dekoder.

    Funktionen und Analogwerte werden einmal mit der normgerechten Wiederholzahl am Gleis ausgegeben, jedoch nicht in den Kommando-Wiederholspeicher übernommen. Sollte eine Funktion aufgrund eines vorangegangen MSG_CS_DRIVE bereits im Wiederholspeicher sein, so wird sie dort aktualisiert.

    Die Fähigkeit zur Ausgabe von Analogfunktionen und Funktionsgruppen bis F68 ist im FEATURE_GEN_EXT_AVAILABLE angekündigt.

    MSG_CS_BIN_STATE-Befehle werden wie Fahrbefehle mit einem MSG_CS_DRIVE_ACK quittiert.

  • MSG_CS_QUERY:

    Mit diesem Befehl wird eine Abfrage aktiver Fahrzeuge durchgeführt. Es folgen 1 oder mehrere Bytes, welche die Abfrage kodieren: QUERY[, ADDRL, ADDRH].

    MSG_CS_QUERY Parameter
    ParameterBeschreibung
    QUERY ENUM der abgefragten Information und Abfragemodus:
    BitBedeutung
    7 Abfragemode:
    • 0: Einzelabfrage des durch ADDRL und ADDRH definierten Objektes
      Der Knoten antwortet mit einer MSG_CS_DRIVE_STATE.
    • 1: Abfrage alle Objekte dieses Typs
      Der Knoten sendet selbstständig eine MSG_CS_DRIVE_STATE für jede im Wiederholspeicher bekannte Adresse unter Beachtung der Transportkapazität seitens des Knotens. Der Knoten muss während der Abarbeitung des Befehls weiterhin andere Nachrichten empfangen und beantworten können. Ist kein Objekt vorhanden, antwortet er mit einer MSG_CS_DRIVE_STATE mit Adresse 0.
    6…4 Reserviert, mit 0 vorzubelegen
    3…0 Objekttyp:
    1: Lokadresse
    ADDRL Adresse, untere 8 Bits.
    ADDRH Adresse, obere 6 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt. Die Adresse 0 ist dabei reserviert.

    Die Unterstützung der Gleisausgabe für diesen Befehl ist im FEATURE_GEN_EXT_AVAILABLE festgelegt.

  • MSG_CS_PROG:

    Mit diesem Befehl werden Programmierbefehle (Programmiergleis) ausgegeben. Diese Gleis-Befehle werden von einer Ausgabeeinheit nur unterstützt, wenn das Classbit 3 gesetzt ist.

    Es folgen weitere Parameter, welche angesprochene CV, Daten und durchzuführende Operation bezeichnen. MSG_CS_PROG Befehle werden von einer oder mehreren MSG_CS_PROG_STATE Nachrichten quittiert.

    Programmierbefehle gibt es (historisch bedingt) in mehreren Varianten, es gibt folgende wesentliche Unterscheidungsmerkmale:

    • Adressprogrammierung: einfache, direkte Programmierung der Adresse, keine CV Auswahl möglich. Wird von BiDiB nicht mehr unterstützt.
    • Registerprogrammierung (Paged): Auswahl einer CV aus dem Bereich 1…8, weitere CVs werden mittels Setzen einer Pageadresse erreicht. Wird von BiDiB nicht mehr unterstützt.
    • CV-Programmierung, Bytemode: In einem Bereich von 1-1024 können CVs byteweise abgefragt werden.
    • CV-Programmierung, Bitmode: Innerhalb einer CV kann ein einzelnes Bit verifiziert oder gesetzt werden.

    Der Zieldekoder kann ein Fahrzeugdekoder oder ein Zubehördekoder (Standard oder Accessory) sein. Bei der Programmierung am Programmiergleis spielt diese Unterscheidung keine Rolle.

    Adressierung der Ziel-CV innerhalb des Dekoders: Mit den Programmiergleisbefehlen können 1024 CVs adressiert werden. Darüber hinausgehende Adressen sind hostseitig durch entsprechende vorherige Einstellungen der Indexregister (CV 31 und CV 32) durchzuführen.

    MSG_CS_PROG Parameter
    ParameterBeschreibung
    OPCODE Byte, definiert die auszuführende Operation
    WertNameBedeutung
    0x00BIDIB_CS_PROG_BREAKAbbruch der laufenden Aktion
    0x01BIDIB_CS_PROG_QUERYAnfrage der Restzeit der laufenden Aktion
    0x02BIDIB_CS_PROG_RD_BYTEByte Lesen
    0x03BIDIB_CS_PROG_RDWR_BITBit Abfragen/Schreiben
    0x04BIDIB_CS_PROG_WR_BYTEByte Schreiben
    CVL, CVH CV-Adresse, Low Byte zuerst. CV wird beginnend bei 0 gezählt (wie auch der Gleisbefehl). Die CV-Benennungen von Decodern beginnen bei CV1 (CV1 wird mit 0 kodiert).
    DATA[0…1] CV-Daten. Im Falle des Byte-Lesens wird DATA nicht benötigt, kann aber trotzdem im Befehl enthalten sein.
    Hinweise:
    Beim Bitbefehl wird das zu verifizierende bzw. zu schreibende Bit mittels DATA bestimmt: DATA = 111KDBBB, wobei BBB die Bitposition angibt und D den Wert des Bits. K ist die Operation (1=write, 0=verify) (identisch zur DCC Definition). Die Gleisausgabe reicht das so direkt an den Dekoder weiter.
    Die Antwort eines Bitbefehles ist entweder OKAY oder FAILED (z. B. mit Timeout). Wird z. B. ein gesetztes Bit in einer CV mit 'verify,D=1' abgefragt, so ist die Antwort OKAY. Wird dieses Bit mit 'verify,D=0' abgefragt, so ist die Antwort TIMEOUT, da der Dekoder keine Antwort sendet.
    Der Knoten antwortet sofort mit einer MSG_CS_PROG_STATE und nach Abschluss der Operation mit einer weiteren MSG_CS_PROG_STATE. [Diskussion: sollen wir kontinuierliche STATE Nachrichten vorschreiben – Fortschrittsbalken?]
    MSG_CS_PROG ist sequentiell, d.h. es kann nur eine Programmieraktion zu einer Zeit aktiv sein. Ein Programmiervorgang muss beendet sein, bevor eine neuer Vorgang gestartet werden darf.
    Programmiermode: Bevor Programmierbefehle ausgeführt werden können, muss die Ausgabeeinheit durch eine Statusumsschaltung auf BIDIB_CS_STATE_PROG in den Programmiermode gebracht werden. Solange eine Programmieraktion läuft, sind keine normalen Gleisbefehle möglich. Nach Ende des Programmiervorgangs muss die Ausgabeeinheit wieder in den normalen Betriebsmode geschaltet werden.
    Programmieren im Programmiermode ist eine globale und adresslose Methode, um CVs in den Lokdekodern zu verändern und birgt die Gefahr, dass der Anwender versehentlich alle Loks und fest angeschlossenen Zubehördekoder auf der Anlage umprogrammiert. Ein Hostprogramm soll daher vor Aktivierung des Programmiermodes auf diesen Umstand hinweisen (z. B. mit einer Warnbox), sowie möglichst alle abhängigen Booster abschalten und nur den Booster des Knotens mit dem Programmiermode aktiv halten.
  • MSG_CS_RCPLUS:

    (optional, ob ein Knoten diesen Befehl unterstützt ist im FEATURE_GEN_RCPLUS_AVAILABLE festgelegt)

    Mit diesem Befehl wird die Railcom-Plus Ausgabe der Zentrale gesteuert. Es folgt mindestens ein Byte (OPCODE), abhängig vom Inhalt von Opcode folgen optional weitere Bytes.

    Jede MSG_CS_RCPLUS wird mit einer oder mehreren MSG_CS_RCPLUS_ACK mit dem entsprechenden OPCODE beantwortet.

    Kodierung des Opcode für RailcomPlus Befehl
    NameBedeutung
    RC_GET_TID Die Gleisausgabeeinheit liefert die aktuelle TID zurück.
    RC_SET_TID Setzen der TID. Es folgen 6 Bytes: CID0, CID1, CID2, CID3, CID4, SID
    RC_PING Permanentes Aussenden der RailcomPlus-Kennung (TID).
    Es folgt ein Parameter INTERVAL, dieser gibt den zeitlichen Abstand der Aussendungen in der Einheit 100ms an. Ein Wert von 0 schaltet die Aussendung ab.
    RC_PING_ONCE_P0 Einmaliges Aussenden der RailcomPlus-Kennung (TID).
    RC_PING_ONCE_P1
    RC_BIND Zuweisen der Dekoderadresse. Es folgen 7 Byte:
    DEC_MUN0,DEC_MUN1,DEC_MUN2,DEC_MUN3, DEC_MID, NEW_ADDRL, NEW_ADDRH. Die neue Adresse ist wie folgt kodiert:
    Bit 15,14Bits 13…0
    00Lok-Adresse (kurzes Format bis einschließlich 127, lang ab 128; Wertebereich 1…59391)
    10(reserviert)
    01Accessory-Adresse (Wertebereich 0, 4, 8…2044)
    11Extended-Accessory-Adresse (Wertebereich 0…2046)
    Mit der Adresse 0 kann ein Dekoder abgemeldet werden, mit DID 0 gar alle gleichzeitig. Dabei muss auch die SID inkrementiert werden.
    RC_FIND_P0 Der Gleisausgabebefehl FIND wird mit gelöschtem bzw. gesetztem P-Bit erzeugt. Es folgen 5 Byte:
    DEC_MUN0,DEC_MUN1,DEC_MUN2,DEC_MUN3, DEC_MID
    RC_FIND_P1
    Hinweise:
    Das permanente Aussenden der TID ist nach jedem Start des Knotens inaktiv (INTERVAL = 0), ebenso bei Resets.
    Beim permanenten Aussenden der TID werden beide Phasenlagen angesprochen. Das Intervall gibt den maximalen zeitlichen Abstand zwischen zwei Aussendungen mit derselben Phasenlage an.
    Um sicherzugehen, dass jeder Decoder die Nachrichten empfängt, werden die Pakete mehrfach am Gleis ausgegeben. Die Anzahl der Wiederholungen lässt sich über das Feature FEATURE_GEN_POM_REPEAT festlegen.
4.5.4. Uplink: Nachrichten für Gleisausgabe

Für Fahr-, Schalt- und Programmier-Nachrichten an die Gleisausgabe existiert ein mehrstufiges Quittungsverfahren:

  1. Quittung Ebene 0: Der Gleisausgabeknoten hat die Nachricht empfangen.
  2. Quittung Ebene 1: Der Befehl wurde aufs Gleis ausgegeben.
  3. Quittung Ebene 2: Der Dekoder hat den Befehl per ACK (via BiDi) bestätigt.

Während Ebene 0 immer verplichtend ist, lassen sich die höheren Ebenen optional per Feature zuschalten. Deren Quittungen werden zusätzlich gesendet.

Kodierung der Werte für ACK-Parameter
WertEbeneBedeutung
0 0

Sofortige Quittung: Befehl konnte nicht angenommmen werden.

Dies tritt auf, wenn die entsprechenden Puffer voll sind oder die Gleisausgabe abgeschaltet ist. Ebenfalls wird mit 0 quittiert, wenn die Ausgabeeinheit den angeforderten Befehl nicht unterstützt (z. B. XPOM Opcode, DRIVE Gleisformat).

1 0

Sofortige Quittung: Befehl wurde angenommen und wird demnächst auf das Gleis ausgegeben.

2 0

Sofortige Quittung: Befehl wurde angenommen und wird mit Verzögerung auf das Gleis ausgegeben.

Diese Quittung ist ein Hinweis an den Host, dass aktuell ein gewisser Engpass in der Gleisausgabe vorliegt und eine Drosselung in der Anzahl der Befehle seitens der Ausgabeeinheit angeraten wird.

Die Gleisausgabeeinheit muss nach einer Quittung mit 2 noch in der Lage sein, mindestens einen weiteren Befehl anzunehmen.

3 1

Spontane Quittung: Der Befehl für diese Adresse wurde jetzt aufs Gleis ausgegeben.

4 2

Spontane Quittung: Nach der Gleisausgabe des Befehls wurde der Empfang von keinem Dekoder bestätigt.

Dies dient dem schnellen Auffinden von Lücken mittels FIND im RailComPlus-Vereinzelungsprozess.

5 2

Spontane Quittung: Nach der Gleisausgabe des Befehls wurde der Empfang wurde von mindestens einem Dekoder bestätigt.
  • MSG_CS_STATE:

    Mit dieser Nachricht wird der aktuelle Zustand der Ausgabe mitgeteilt. Es folgt ein Byte, das den aktuellen Zustand kodiert. Der Zustand ist hierbei ebenso wie bei MSG_CS_SET_STATE kodiert.

  • MSG_CS_DRIVE_ACK:

    Mit diesem Befehl werden Fahrbefehle quittiert. Es folgen weitere Parameter:

    MSG_CS_DRIVE_ACK Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits.
    ADDRH Adresse, obere 6 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt.
    ACK Quittung, diese ist kodiert wie oben beschrieben.
  • MSG_CS_ACCESSORY_ACK:

    Mit diesem Befehl werden Schaltbefehle quittiert. Es folgen weitere Parameter:

    MSG_CS_ACCESSORY_ACK Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits
    ADDRH Adresse, obere 3 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt.
    ACK Quittung, diese ist kodiert wie oben beschrieben.
  • MSG_CS_POM_ACK:

    Mit diesem Befehl werden POM Befehle quittiert. Es folgen weitere Parameter, Adresse und Quittung. Adresse ist identisch zum MSG_CS_POM-Befehl kodiert und wird im Knoten einfach 'durchgereicht'.

    MSG_CS_POM_ACK Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits (DID0 bei Dekoderadressierung).
    ADDRH Adresse, obere 8 Bits. (DID1 bei Dekoderadressierung);
    Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL. Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt.
    Die Unterscheidung, ob Accessory oder Fahrzeugdekoder adressiert wird, ist in Bit 14 und 15 kodiert:
    • Bit 15,14 = 00: Fahrzeugdekoder
    • Bit 15,14 = 10: (reserviert)
    • Bit 15,14 = 01: Standard Zubehördekoder
    • Bit 15,14 = 11: Extended Zubehördekoder
    ADDRXL 0 bei Lokadressierung, DID2 bei Dekoderadressierung
    ADDRXH 0 bei Lokadressierung, DID3 bei Dekoderadressierung
    MID 0: Adressierung über die Lokadresse
    1…255: Adressierung über Dekoderkennung, dieses Feld ist dann die Herstellerkennung (=DID4)
    ACK Quittung, diese ist kodiert wie oben beschrieben.
  • MSG_CS_DRIVE_MANUAL:

    Mit diesem Befehl werden Handbedienungen einer Lokomotive gemeldet. Hierzu muss jedoch das FEATURE_GEN_NOTIFY_DRIVE_MANUAL auf 1 gesetzt sein. Es folgen weitere Parameter, deren Struktur wie bei MSG_CS_DRIVE angelegt ist:

    MSG_CS_DRIVE_MANUAL Parameter
    ParameterBeschreibung
    ADDRLAdresse, untere 8 Bits
    ADDRHAdresse, obere 6 Bits
    DATA0Bitfeld, Format
    DATA1Bitfeld Ausgabe Aktiv
    DATA2Geschwindigkeit
    DATA33*reserved, FL (Licht), F4, F3, F2, F1
    DATA4F12 – F5
    DATA5F20 – F13
    DATA6F28 – F21
  • MSG_CS_DRIVE_EVENT:

    Mit diesem Befehl werden Ereignisse bei einer Lokomotive gemeldet. Es folgen weitere Parameter:

    MSG_CS_DRIVE_EVENT Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits
    ADDRH Adresse, obere 6 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt.
    EVENT Event, dieses ist wie folgt kodiert:
    WertBedeutung
    0kein Event vorliegend
    1LOST: die Lok antwortet nicht mehr auf Befehle. Die Überwachung lässt sich via FEATURE_GEN_LOK_LOST_DETECT aktivieren.
    Anmerkungen zu LOST:

    Eine häufige Störursache beim Fahrbetrieb sind 'hängende' Lokomotiven, welche z. B. durch Kontaktschwierigkeiten keine Fahrbefehle mehr erhalten. Sofern eine Modellbahnanlage flächendeckend mit railcom-Meldern ausgerüstet ist, kann die Gleisausgabeeinheit den Verbindungsverlust zu einer Lokomotive bemerken und melden.

    Die Gleisausgabeeinheit überwacht hierzu die ACK-Leitung auf dem BiDiBus und schaltet für eine Fahrzeug-Dekoder Adresse den Überwacher scharf, sofern ACK-Bestätigungen für diesen Dekoder eingehen. Nach 10 Lokbefehlen ohne ACK-Bestätigung soll das MSG_CS_DRIVE_EVENT erzeugt werden. Dies kann natürlich nur dann funktionieren, wenn die Modellanlage flächendeckend mit railcom-Meldern ausgerüstet ist, ansonsten kommt es bereits beim Befahren von nicht railcom-überwachten Abschnitten zu einer 'LOST'-Meldung.

    Auf die Möglichkeit der präventiven Gleisüberwachung mittels MSG_BM_DYN_STATE sei hier ergänzend hingewiesen.

  • MSG_CS_ACCESSORY_MANUAL:

    Mit diesem Befehl werden Handverstellungen bei einem DCC-Accessory gemeldet. Es folgen weitere Parameter:

    MSG_CS_ACCESSORY_MANUAL Parameter
    ParameterBeschreibung
    ADDRL Adresse, untere 8 Bits.
    ADDRH Adresse, obere 3 Bits. Die gesamte Adresse ergibt sich zu ADDRH*256+ADDRL.
    Die Adresse bezeichnet die echte (DCC-)Adresse und wird bei 0 beginnend gezählt.
    DATA Bitfeld
    BitBedeutung
    7Extended / normal Accessory: 0=normal, 1=extended
    60: reserviert
    5Activate: 0=coil-off / 1=coil-on
    4…0 ASPECT
    Zweibegriffige Zubehördekoder werden mit (ASPECT 0 = red) und (ASPECT 1 = green) angesteuert.
  • MSG_CS_DRIVE_STATE:

    Mit diesem Befehl werden Abfragen zu MSG_CS_QUERY beantwortet. Es folgt ein Parameter, welcher die Art der Antwort kodiert. Die weiteren Befehlsparameter sind identisch zu MSG_CS_DRIVE_MANUAL kodiert. Im Falle der Abfrage einer nicht existierenden Lok wird diese Lok mit allen Datenfeldern = 0 gemeldet.

    MSG_CS_DRIVE_STATE Parameter
    ParameterBeschreibung
    OPCODE ENUM der abgefragten Information und Abfragemode:
    BitBedeutung
    7 Abfragemode:
    0: Nachricht ist die Reaktion auf eine Einzalabfrage
    1: Nachricht ist Teil eines Datenstroms
    6 Ende:
    0: es folgen weitere Nachrichten
    1: letzte Nachricht dieser Abfrage (ist auch bei Einzelantworten gesetzt)
    6…4 Reserviert, mit 0 vorzubelegen
    3…0 Objekttyp:
    1: Lokadresse
    ADDR[2] Identisch zu MSG_CS_DRIVE_MANUAL kodiert
    DATA[7]
  • MSG_CS_PROG_STATE:

    Mit diesem Befehl werden Ergebnisse bei einem Programmiervorgang im Service-Mode gemeldet. Es folgen weitere Parameter:

    MSG_CS_PROG_STATE Parameter
    ParameterBeschreibung
    STATE Ergebnis
    WertNameBedeutung
    0x00BIDIB_CS_PROG_STARTDieser Status wird nach Erhalt des Programmierbefehls zurückgesendet.
    0x01BIDIB_CS_PROG_RUNNINGStatus während der Ausführung. RUNNING bei länger dauernden Vorgängen als Zwischenmeldung auf eine QUERY-Abfrage gesendet.
    0x80BIDIB_CS_PROG_OKAYProgrammiervorgang erfolgreich.
    0xC0BIDIB_CS_PROG_STOPPEDDer Programmiervorgang wurde abgebrochen, Ergebnis ist ungültig.
    0xC1BIDIB_CS_PROG_NO_LOCOProgrammiervorgang beendet, es wurde kein Verbraucher am Gleis erkannt.
    0xC2BIDIB_CS_PROG_NO_ANSWERProgrammiervorgang beendet, Programmierung wurde von Lok nicht bestätigt bzw. beim Lesen keine Reaktion der Lok.
    0xC3BIDIB_CS_PROG_SHORTProgrammiervorgang beendet, Kurzschluss erkannt.
    0xC4BIDIB_CS_PROG_VERIFY_FAILEDProgrammiervorgang beendet, Kontrollvorgang fehlerhaft (siehe Hinweis).
    TIME prognostizierte Restdauer in Einheiten von 100ms.
    Die Restdauer kann technisch bedingt nur schwer abgeschätzt werden, insbesondere bei Dekodern, welche Bitmode nicht unterstützen, ist die Aussage stark schwankend.
    Der Knoten probiert hier einfach Daten der Reihe nach durch und ist bei 'Treffer' fertig.
    CVL, CVH CV-Adresse, Low Byte zuerst. CV wird beginnend bei 0 gezählt (wie auch der Gleisbefehl). Die CV-Benennungen von Decodern beginnen bei CV1 (CV1 wird mit 0 kodiert). Wertebereich 0…1023
    DATA[0…1] CV-Daten. Im Falle des Byte-Schreibens oder einer Fehlermeldung wird DATA nicht benötigt, kann aber trotzdem im Befehl enthalten sein.
    Hinweise:
    bei STATE kodiert das MSB den Zustand laufend / beendet und das Bit 6 'Fehler aufgetreten'.
    Wenn ein STATE 'beendet' gemeldet wird, ist das Feld TIME zwar vorhanden, aber ungültig und mit 0 zu kodieren.
    BIDIB_CS_PROG_VERIFY_FAILED kann z. B. auftreten, wenn zwei Dekoder am Gleisausgang sind: beim bitweisen Lesen des CV-Inhaltes überlagern sich Antworten, bei der abschließenden Kontrolle wird das Leseergebnis jedoch nicht bestätigt.
  • MSG_CS_RCPLUS_ACK:

    (optional, ob ein Knoten diese Nachricht unterstützt ist im FEATURE_GEN_RCPLUS_AVAILABLE festgelegt)

    Mit dieser Nachricht werden Railcom-Plus-Befehle von der Zentrale quittiert. Es folgt mindestens ein Byte (OPCODE), abhängig vom Inhalt von Opcode folgen ein oder mehrere Bytes.

    MSG_CS_RCPLUS_ACK Parameter
    ParameterBeschreibung
    OPCODE Klassifizierung der Antwort, s.u.
    ACK (bei BIND, PING_ONCE und FIND) Quittung, diese ist kodiert wie oben beschrieben.
    Zusätzlich zur Ebene-0-Empfangsquittung als direkte Antwort auf MSG_CS_RCPLUS kann das Digitalsystem Quittungen höherer Ebenen versenden, die Unterstützung dafür ist in FEATURE_GEN_DRIVE_ACK kodiert. Das regelmäßige Aussenden der TID im per RC_PING festgelegten Intervall wird dabei mit OPCODE = RC_PING_ONCE_P0/P1 gemeldet.
    Kodierung des Opcode für RailcomPlus Quittierung
    WertBedeutung
    RC_TID Meldet die angefragte bzw. gesetzte TID. Es folgen 6 Bytes: CID0, CID1, CID2, CID3, CID4, SID
    RC_PING Meldet den zeitlichen Abstand des Aussendens der RailcomPlus-Kennung (TID).
    Es folgt ein Byte INTERVAL (Einheit 100ms, der Wert 0 entspricht "inaktiv")
    RC_BIND Zuweisung der Dekoderadresse. Es folgen 6 Byte:
    ACK, DEC_MUN0,DEC_MUN1,DEC_MUN2,DEC_MUN3, DEC_MID
    RC_PING_ONCE P0 Aussendung der RailcomPlus-Kennung (TID). Es folgt 1 Byte mit der Quittung.
    P1
    RC_FIND P0 Suche nach Dekodern. Es folgen 6 Byte:
    ACK, DEC_MUN0,DEC_MUN1,DEC_MUN2,DEC_MUN3, DEC_MID
    P1