BiDiB, ein universelles Steuerprotokoll für Modellbahnen

Inhaltsverzeichnis

• 1. Allgemeines
  • 1.1. Zielsetzung, besondere Eigenschaften
  • 1.2. Ursprung, Geschichte
  • 1.3. Rechtliches, Lizenz
  • 1.4. Revisionsstand
  • 1.5. Design-Grundlagen
  • 1.6. Glossar
  • 1.7. Prinzipien der Knotenzuordnung, Adressierung
• 2. Physikalische Implementierung
• 3. Protokollbeschreibung
  • 3.1. Prinzipieller Nachrichtenaufbau
  • 3.2. Routing
  • 3.3. Unique-ID
  • 3.4. Typischer Protokollstart
  • 3.5. Klassen
  • 3.6. Systemzeit
• 4. Nachrichten
  • 4.1. System-Nachrichten
    • 4.1.1. Downlink: System-Nachrichten
    • 4.1.2. Uplink: System-Nachrichten
  • 4.2. Abfragen oder Setzen von Feature-Einstellungen
    • 4.2.1. Downlink: Nachrichten für das Abfragen oder Setzen von Feature-Einstellungen
    • 4.2.2. Uplink: Nachrichten für Featuremitteilungen
  • 4.3. Nachrichten zur Userkonfiguration
    • 4.3.1. Downlink: Nachrichten zur Userkonfiguration
    • 4.3.2. Uplink: Nachrichten für Userconfig
  • 4.4. Firmware-Updates
    • 4.4.1. Ablauf eines Firmware-Updates
    • 4.4.2. Features für FW-Update
    • 4.4.3. Downlink: Nachrichten für FW-Update
    • 4.4.4. Uplink: Nachrichten für FW-Update
  • 4.5. Gleisausgabe-Geräte
    • 4.5.1. Ansteuerung Gleisausgabe
    • 4.5.2. Features für Gleisausgabe
    • 4.5.3. Downlink: Nachrichten für Gleisausgabe
    • 4.5.4. Uplink: Nachrichten für Gleisausgabe
  • 4.6. Accessory und Zubehör/Schaltfunktionen
    • 4.6.1. Ansteuerung Fahrwegzubehör
    • 4.6.2. Features für Accessory-Funktionen
    • 4.6.3. Downlink: Nachrichten für Accessory-Funktionen
    • 4.6.4. Uplink: Nachrichten für Accessory-Funktionen
    • 4.6.5. Ansteuerung Zubehör / Schaltfunktionen
    • 4.6.6. Features für Schaltfunktionen
    • 4.6.7. Downlink: Nachrichten für Schaltfunktionen
    • 4.6.8. Uplink: Nachrichten für Zubehör / Schaltfunktionen
    • 4.6.9. Lokale Makros
    • 4.6.10. Features für lokale Makros
    • 4.6.11. Downlink: Nachrichten für lokale Makros
    • 4.6.12. Uplink: Nachrichten für lokale Makros
  • 4.7. Belegtmeldung
    • 4.7.1. Erfassung und Absicherung
    • 4.7.2. Features für Belegtmelder
    • 4.7.3. Downlink: Nachrichten für Belegtmelder
    • 4.7.4. Uplink: Nachrichten für Belegtmelder
    • 4.7.5. Features für BiDi-Detektoren
    • 4.7.6. Downlink: Nachrichten für BiDi-Detektoren
    • 4.7.7. Uplink: Nachrichten für BiDi-Detektoren
  • 4.8. Booster
    • 4.8.1. Ansteuerung von Boostern
    • 4.8.2. Features für Booster
    • 4.8.3. Downlink: Nachrichten für Booster
    • 4.8.4. Uplink: Nachrichten für Booster
  • 4.9. Verteilte Steuerung
    • 4.9.1. Kommunikation mit anderen Bediengeräten
    • 4.9.2. Kontrolle und Adressierung
    • 4.9.3. Request: Nachrichten von Gästen an Gastgeber
    • 4.9.4. Response: Nachrichten von Gastgebern an Gäste

1. Allgemeines

1.1. Zielsetzung, besondere Eigenschaften

Das Protokoll BiDiB dient zur Steuerung einer Modellbahn. Es ermöglicht die Kontrolle und Ansteuerung von Loks, Weichen und Zubehör sowie die sichere Übertragung von Rückmelderinformationen aus der Modellbahnanlage an den steuernden Rechner. BiDiB steht für BiDirektionaler Bus und bietet folgende Vorteile:

• Automatische Hardwarezuordnung, keine Programmierung erforderlich (Plug&Play). Dadurch lassen sich bei modular und/oder veränderlich aufgebauten Anlagen Adresskonflikte sicher vermeiden. Stellwerksdateien sind einfach kopierbar.
• Weitgehend freie Anordnung von Baugruppen (z. B. Melder, Booster oder Ausgabebausteine), auch kein Verschieben von Melderadressen durch neu hinzugekommene Melderbausteine.
• Einfache Skalierbarkeit und Erweiterbarkeit durch die vom Protokoll vorgesehene Möglichkeit, Hub-Bausteine zu unterstützen.
• Extrem schnelle Datenübertragung, durch CRC abgesichert.
• Überwachung der gesamten Übertragungskette und auch der Rückmeldebausteine selbst durch die zuschaltbare Secure-ACK-Technik. Das garantiert für eine störungsfreie Rückmeldung.
• Volle Unterstützung BiDi-fähiger Rückmelder durch Übertragung von Adressen, CV-Nachrichten und der Istgeschwindigkeit der Dekoder.
• Meldung mehrerer Loks in einem Abschnitt.
• Mischbetrieb normaler und BiDi-fähiger Rückmelder problemlos möglich: man kann damit an wichtigen Stellen (z. B. Eingleiser) BiDi-Melder verbauen, in der sonstigen Anlage jedoch einfachere, normale Melder.
• Flexibles, offenes Protokoll, zukunftssicher.

Die Graphik illustriert eine typische Anordnung. Das Protokoll ist für verschiedenste Modellbahnsteuerungssysteme von der einfachen Heimanlage bis zur großen Austellungsanlage gleichermaßen geeignet und kann problemlos an die Aufgabenstellung angepasst werden. Hierzu gibt es einen verpflichtenden Satz an Abfrage- und Einstellparametern, die jedes System enthalten muss. Die im folgende verwendeten Bezeichnungen sind im Glossar erläuternd zusammengefasst.

1.2. Ursprung, Geschichte

In 2009 stellten die Firmen Lenz und Tams Rückmeldersysteme für BiDi vor, damit war die Auswertung der bidirektionalen Datenübertragung zwischen DCC-Dekodern und Steuereinheiten theoretisch möglich. Entsprechende Rückmeldersysteme waren zwar angekündigt, aber bis Ende 2010 war nur das einfache Tams RC-Talk im Markt verfügbar. Aus der Diskussion über einen zukunftsfähigen Nachfolger ist dieses Protokoll entstanden. Auf Grund der Leistungsfähigkeit und des stabilen Betriebes wurde dieser wurde dann die Grundlage für einen erweiterten Entwurf, welcher auch Zentralen, Zubehör und Bediengeräte (z. B. externe Stellpulte) umfasst.

An dieser Stelle gilt mein Dank den Diskussionspartnern Hrn. Tams, Hrn. Bluecher und Hrn. Herzog für den konstruktiven Disput.

1.3. Rechtliches, Lizenz

BiDiB® wird von einem Arbeitskreis betreut und (fort-)entwickelt (BiDiB-Implement-Group), diesem gehören neben weiteren Mitgliedern maßgebend die Herren Kersten Tams, Markus Herzog und Wolfgang Kufer an.

Rechtliches: Diese Spezifikation wird bereitgestellt 'wie sie ist', es gibt keine Zusicherung irgendeiner Eignung für irgend einen Anwendungsfall. Damit gibt es auch keine Gewähr oder Zusicherung irgendeiner Funktion oder wirtschaftlichen Verwertbarkeit, jegliche Garantie wird ausgeschlossen. Der Anwender übernimmt die volle Verantwortung bei Verwendung dieser Spezifikation. In keinem Fall kann irgendein Mitglied der BiDiB-Implement-Group für irgendwelche direkten oder indirekten Schäden haftbar gemacht werden. Neben der Möglichkeit des Lizenzentzugs entstehen für den Lizenzgeber keine Haftungsansprüche gegenüber dem Lizenznehmer.

Das Protokoll BiDiB ist für die Verwendung zusammen mit Modellbahnsteuerungssoftware vorgesehen und kann ohne Lizenzkosten sowohl auf der PC-Seite als auch auf der Hardwareseite implementiert werden. Zur Sicherstellung der Kompatibilität sind jedoch folgende Lizenz-Bedingungen einzuhalten.

• Vor jeder Veröffentlichung oder erstmals geplanten Implementierung in einem neuen Produkt muss der Arbeitskreis BiDiB bzw. Herr Kufer informiert werden. Diese Information wird bis zur Veröffentlichung des Produkts vertraulich behandelt.
• Der im folgenden beschriebene Funktionsumfang (sofern nicht als optional gekennzeichnet) muss vollständig implementiert sein. Es muss klar angegeben sein, welche Features und Klassen unterstützt werden. (Beispiel: Unterstützung BiDiB Protokollversion x.xx, Belegtmeldung inkl. Adressmeldung und Richtung)
  PC-Programme können Teilfunktionen bei der Implementierung auslassen (Beispiel: die Funktionalität 'Firmwareupdate' kann in Steuerungsprogrammen entfallen). Wenn jedoch eine bestimmte Funktionalität implementiert wird, ist diese allgemeingültig und spezifikationskonform zu implementieren. Ziel muss eine einheitliche Behandlung von BiDiB-Systemen sein.
• Die verwendeten Herstellerkennungen und Produktkennungen sind zusammen mit einer Kurzbeschreibung des Produkts, der unterstützten Klassen und einem Link auf die Beschreibung des Produktes (Handbuch/Datenblatt) auf bidib.org zu veröffentlichen.
• Jegliche Erweiterung des Protokollumfangs ist vorher einvernehmlich mit dem Arbeitskreis BiDiB abzusprechen und muss vom Protokoll und von der Referenzimplementierung her offengelegt werden. Diese Einschränkung dient primär der Sicherstellung von Kompatibilität und Eindeutigkeit, nicht zum Blocken von Wettbewerbern oder Verhindern neuer Funktionen.
• Die Kodierung von Daten, welche über BiDiB übertragen werden, muss offengelegt und frei nutzbar sein. Ausnahmen hiervon sind nur in begündeten Ausnahmefällen zugelassen (z. B. Firmware-Update). Diese Einschränkung dient wie oben primär der Sicherstellung von Kompatibilität und Eindeutigkeit, nicht zum Blocken von Wettbewerbern oder Verhindern neuer Funktionen.
• Jede Implementierung muss auf den originären Ursprung des Dokuments (-> BiDiB.org) verweisen. Dieser Verweis muss sowohl im Produktprospekt / Datenblatt als auch im Handbuch erfolgen (unabhängig vom Informationsträger).
• Jede Veröffentlichung an anderer Stelle (auch auszugsweise) bedarf der vorherigen schriftlichen Zustimmung und muss auf den originären Ursprung des Dokuments (-> BiDiB.org) verweisen.
• Geräte, die BiDiB verwenden, sind mit dem Logo zu kennzeichnen. Dies gilt insbesondere für Schnittstellenbuchsen, auf denen BiDiB implementiert ist. Das Logo und der Begriff BiDiB darf nur nach vorheriger expliziter Zustimmung des Arbeitskreises BiDiB verwendet werden. Auch diese Einschränkung dient nur der Sicherstellung von Kompatibilität, nicht zum Blocken von Wettbewerbern.
• Geräte und/oder Software, die BiDiB implementieren, sind zur Kompatibilitätsprüfung dem Arbeitskreis auf Verlangen kostenfrei zur Verfügung zu stellen.
• Der Lizenznehmer verpflichtet sich, die notwendigen Tests zur Interoperabilität seiner Komponenten (sowohl Hardware als auch Software) mit der gebotenen Sorgfalt durchzuführen.
  Im Falle von Kompatibilitätsproblemen sind die entsprechenden Komponenten nachzubessern und alle notwendigen Informationen und Materialien zu durchgeführten Tests und zur Lokalisierung des Problems kostenfrei bereit zu stellen.
  Der Lizenznehmer verpflichtet sich, binnen 2 Monaten die Inkompatibilität zu beheben. Diese Frist kann bei reinen Softwarekomponenten bis zur nächsten Version verlängert werden. Erfolgt keine Fehlerbehebung, so kann die Lizenz für dieses Produkt widerrufen werden.
• Im Falle von Inkompatibilitäten ist häufig das Zusammenspiel mehrerer Komponenten betroffen. Die beteiligten Parteien sind im ersten Schritt dazu aufgefordert und verpflichtet, miteinander das Problem zu untersuchen und zu klären, warum diese Komponenten nicht miteinander funktionieren.
  Wird dabei keine Einigkeit über die Ursache erzielt, so ist das Problem dem Arbeitskreis BiDiB vorzulegen, der über das weitere Vorgehen entscheidet.
• Bewusste Verstöße gegen die Lizenzbedingungen haben den Entzug der Lizenz für alle Produkte des Lizenznehmers zur Folge.

1.4. Revisionsstand

Dieses Dokument beschreibt Revision 1.29 von BiDiB, Stand 21.07.2023.

In diesem Dokument ist der grundlegenden Nachrichtenaufbau und die Struktur beschrieben. Nachrichten, welche speziell einem Anwendungsfall (also z. B. Schalten, Melden, Fahren, ...) zugeordnet sind, sind in weiteren Dokumenten bzw. Kapiteln beschrieben.

1.5. Design-Grundlagen

BiDiB ist als zustandsloses Protokoll angelegt. Für Nachrichtenverluste existieren diverse Sicherungsmechanismen.

Die wichtigste Eigenschaft, um eine hohe Fehlertoleranz zu erreichen, ist die Idempotenz der Nachrichten. Im Allgemeinen übertragen Nachrichten nur Zustände, keine Kommandos oder Befehle. Ihr Empfang wird vom Knoten üblicherweise mit einer Nachricht selben Inhalts quittiert. Damit kann im Fehlerfall die Übertragung einfach wiederholt werden, ohne bei Mehrfachempfang ungewollte Aktionen auszulösen. Dies gilt insbesondere für die kritischen Modellbahn-Anwendungen Fahren, Schalten und Melden. Auch wird etwa bei sequentieller Übertragung in mehreren Nachrichten stets ein Identifier verwendet, mit dem eine verlorene Information erneut angefordert werden kann.

Kommunikationsfehler hingegen werden nur einfach gemeldet und nicht wiederholt, um die Implementierung zu vereinfachen. Ein Verlust einer Fehlermeldung ist mit dem Ausbleiben der erwarteten Antwort gleichzusetzen. Treten mehrere Fehler zugleich auf, können diese in einer Liste zum Abholen bereit gestellt werden, müssen aber nicht wiederholt werden. Bleibt ein Fehler erhalten, wird er beim nächsten Versuch das Objekt zu benutzen nochmals gemeldet. Die Behebung eines Fehlers wird in der Regel nicht gemeldet. Ausnahmen hiervon bilden Objekte, bei denen Störungen/Fehlerzustände intrinsisch sind (z. B. Booster und Accessorys), für diese kann Speicherung oder Wiederholung vorgeschrieben sein.

Ebenso verfahren wird bei spontanen Ereignissen, die nicht betriebsrelevant sind. Ein Verlust solcher Nachrichten kann nur durch die Überprüfung der Sequenznummern erkannt werden, es existiert aber keine vorgeschriebene Fehlerbehandlung und keine Wiederholmöglichkeit. Für betriebskritische Ereignisse (Belegtmeldungen, Accessory) gibt es mit Secure-ACK und Secure-Switch auch Quittungsverfahren zur Absicherung.

Die Fortentwicklung von BiDiB ist im Protokoll fest verankert. Bei neuen Revisionen der Spezifikation wird streng auf Rückwärtskompatibilität geachtet. Erweiterungen des Funktionsumfangs sind meist leicht möglich, da diese üblicherweise optional sind und ignoriert werden können. Bei nicht rückwärtskompatiblen Änderungen wird die Protokollversion angehoben, welche von jedem Knoten abgefragt werden kann. Dies erlaubt die Unterstützung veralteter Implementierungen und gewährleistet in gewissem Maße auch die Kompatibilität mit noch unbekannten Funktionen.

1.6. Glossar

In diesem Dokument werden folgende Bezeichnungen für die einzelnen Protokollteilnehmer oder Eigenschaften verwendet:

1.7. Prinzipien der Knotenzuordnung, Adressierung

Ein mit BiDiB angesprochenes System ist baumartig organisiert: Der Host sieht ein Interface, mit dem er eine Kommunikationsverbindung aufbaut. Das Interface ermöglicht ihm Zugang zu einer (flachen) Anordnung aus Knoten. Jeder dieser Knoten ist in der Regel ein Baustein, der eine oder mehrere bestimmte Funktionen beinhaltet (z. B. ein Melder mit Rückmeldekontakten). Es ist aber auch möglich, dass dieser Baustein selbst auch nur ein Interface ist, hinter dem sich eine weitere Struktur befindet (so wie ein Unterordner). Dadurch erreicht man eine große Flexibilität sowohl in den Verdrahtungsmöglichkeiten als auch in der möglichen Heterogenität der angeschlossenen Busknoten.

BiDiB verfügt über eine automatische Adressvergabe der Knoten. Hierbei ist jedem Knoten herstellerseitig eine eindeutige Nummer einprogrammiert, die Teil der Unique-ID ist. Beim Einschalten des BiDiB-Systems werden vom Interface innerhalb seiner Struktur die vorhandenen Knoten gesucht und ihnen eine lokale Adresse zugewiesen, diese lokale Adresse ist ein Byte lang. Das Interface erstellt dabei eine Liste aus verfügbaren Knoten, ihrer Unique-ID und ihrer lokalen Adresse. Knoten selbst können wieder Interfaces sein, so dass insgesamt eine Baumstruktur entsteht. Jeweils eine Verzweigung hat Kenntnis über die Knoten direkt nach der Verzweigungsstelle. Die maximale Adresslänge innerhalb des Baumes ist 4 Byte.

Diese Zuordnungstabelle ist bei jedem Start unterschiedlich und wird auch automatisch erweitert, wenn ein neuer Knoten auf den Bus aufgesteckt wird. Das Interface schickt in diesem Fall eine entsprechende Nachricht an den Host. Wenn ein Interface aus dem System entfernt wird (z. B. Abstecken eines Hubs), so sind implizit auch alle Knoten hinter diesem Interface nicht mehr erreichbar.

Host-intern sind die Knoten (neben den programm-internen Dingen wie z. B. Bildschirmposition und Knotenname) auch mit ihrer jeweiligen Unique-ID abgelegt. Der Host holt sich nun beim Systemstart die Zuordnungstabelle vom Interface und bekommt daraus die für diese Sitzung gültigen lokalen Adressen, die zu diesen Unique-IDs gehören. Die Zuordnung vom Objekt auf der Bedienoberfläche zur Modellbahn-Hardware erfolgt also letztendlich über die Knotenidentität und ist damit nicht von der aktuellen Adressvergabe abhängig.

Um den Austausch eines Knotens zu ermöglichen, soll in Hostprogrammen darauf geachtet werden, dass die einem Knotenobjekt zugewiesene Unique-ID leicht durch eine andere ersetzt werden kann. Da die Unique-ID einer Baugruppe nicht vom Anwender eingestellt werden kann, kann er den Ersatzknoten nicht auf die "alte Adresse" programmieren um die im Programm konfigurierte Zuordnung weiterzuverwenden; stattdessen ist es erforderlich die Änderung in der Hostsoftware vorzunehmen. Der Tausch der Unique-ID wird etwa nötig beim Ersetzen defekter Baugruppen durch baugleiche Hardware, bei der Erweiterung um mehr Ausgänge durch Verwendung eines überlegenen Produkts, oder beim Aufspielen einer anderen Produktfirmware die mehr Funktionen anbietet.

Wie funktioniert die erstmalige Eingabe bzw. Zuordnung der Knoten?

Wenn der Host beim Einlesen der Zuordnungstabelle einen (oder mehrere) Knoten findet, die noch nicht in seinem Gleisbild enthalten sind, so kann er diese in einem Topf 'neu verfügbare Melder / Zentralen / Booster usw.' darstellen. Man kann dann z. B. auf der Knotenhardware durch Tastendruck ein Blinken der Belegtmeldung (bzw. Identify) auslösen und kann das so leicht im PC auf den richtigen Gleisabschnitt zuordnen.

Was passiert, wenn z. B. ein Knoten mit Besetztmeldefunktion ausfällt oder getauscht wurde?

Wenn der PC beim Einlesen der Zuordnungstabelle für einen bereits konfigurierten Besetztmelder die Unique-ID nicht findet, so kann er eine Fehlermeldung ausgeben. Sollte parallel ein neuer Melder erscheinen, könnte das Programm auch gleich nachfragen, ob dieser neue Melder den alten ersetzt.

2. Physikalische Implementierung

Das Protokoll BiDiB ist als Protokoll für verschiedene Übertragungsmedien wie z. B. Serielle Verbindung, USB, RS485, Ethernet oder Wireless geeignet (mit dann jeweils angepasstem Framing). Entsprechende Spezifikationen sind den jeweiligen Dokumenten zu entnehmen.

Die jeweilige Übertragungsschicht sorgt für das korrekte Framing und den byteweisen, transparenten Transport von BiDiB-Nachrichtenpaketen. Generell muss die Übertragungsschicht den Transport der Daten mit einer CRC absichern. Die Übertragungsschicht muss mindestens in der Lage sein, Nachrichten mit einer Größe von 64 Bytes zu transportieren.

CRC bezeichnet ein Prüfsummenverfahren. Bei einigen physikalischen Implementierungen wird CRC8 verwendet: Auf der Senderseite wird das gemäß Polynom x⁸ + x⁵ + x⁴ + 1 über das Paket gebildet, beginnend beim ersten Byte des Paketes, Init=0, nicht invertiert. Empfängerseitig wird die CRC mit dem gleichen Polynom über das gesamte Paket inkl. CRC gebildet, das Ergebnis muss 0 sein.

3. Protokollbeschreibung

3.1. Prinzipieller Nachrichtenaufbau

Eine MESSAGE hat folgenden Aufbau:

MESSAGE ::= MSG_LENGTH  MSG_ADDR  MSG_NUM  MSG_TYPE  DATA
MSG_LENGTH ::= 0x00 | … | 0x7f
MSG_ADDR ::= MSG_ADDR_STACK  0x00
MSG_ADDR_STACK ::= ε | NODE_ADDR  MSG_ADDR_STACK
NODE_ADDR ::= 0x01 | … | 0xff
MSG_NUM ::= 0x00 | … | 0xff
MSG_TYPE ::= 0x00 | … | 0xff
DATA ::= ε | ANY_BYTE  DATA
ANY_BYTE ::= 0x00 | … | 0xff

Ein Nachricht besteht als aus der Länge, einer Adressenangabe, einer (fortlaufenden) Nachrichtennummer, einer Typangabe und optionale Parameter. Diese Felder sind nachfolgend erläutert:

• MSG_LENGTH besteht aus einem Byte und gibt die Nachrichtengröße in Bytes an. Hierbei wird die Länge ab erstem Byte der MSG_ADDR bis zum Ende des DATA-Feldes angegeben. Ein Nachricht, die nur aus Adresse 0, MSG_NUM und MSG_TYPE besteht, hat also die Länge 3. Wertebereich 0…127, MSB ist reserviert.
  Anmerkung: sollte bei einer zukünftigen Erweiterung eine Vergrößerung der Nachrichten erforderlich werden, so kann über das reservierte MSB eine Erweiterung vorgenommen werden, z. B. gemäß folgender Regel: Ist das erste Byte im MSG_LENGTH-Feld kleiner 128, dann besteht das MSG_LENGTH-Feld nur aus einem Byte. Ist das MSB im ersten Byte des MSG_LENGTH-Feldes gesetzt, so errechnet sich die Länge zu: (Erstes Byte & 0x7F) * 128 + (zweites Byte & 0x7F); Im 2. Byte darf das MSB nicht gesetzt sein.
• MSG_ADDR bezeichnet die zugewiesene Ziel- oder Quelladresse dieser Nachricht. MSG_ADDR besteht aus 1 bis 5 Bytes, jedes Byte definiert die lokale Adresse (NODE_ADDR) auf einer Ebene. Das letzte Byte von MSG_ADDR ist immer 0. Es sind damit max. 4 Adressbytes von 0 verschieden.
  Wenn die MSG_ADDR gleich 0 (also der MSG_ADDR_STACK leer) ist, dann adressiert die Nachricht direkt das Interface bzw. den Knoten. Wenn die MSG_ADDR ungleich 0 ist, dann wird derjenige Knoten hinter dem Interface adressiert, dessen lokale Adresse der ersten NODE_ADDR entspricht. In diesem Fall schickt ein Interface die Nachricht entsprechend weiter, dabei wird der MSG_ADDR_STACK vorn um ein Byte gekürzt. Umgekehrt wird bei Nachrichten, welche von einem weiter unten liegenden Knoten erhalten wurden, dessen lokale Adresse vom Interface vorne angefügt.
• MSG_NUM bezeichnet einen durchlaufenden Nachrichtenindex, der bei jeder Nachricht um eins hochgezählt wird. Die 0 wird dabei übersprungen (1,2,...,255,1,2,...). Der Empfänger kann die MSG_NUM prüfen und kann so feststellen, ob ihm eine Nachricht verloren gegangen ist. Für den Fall des Nachrichtenverlustes liegt es im Ermessen des Empfängers, wie er reagiert. Der Wiederanlauf erfolgt mit den Befehlen des Protokolls, ein Retransmit/Rewind einzelner Nachrichten ist nicht vorgesehen.
  Beispiel: In der Regel wird der Empfänger alle Belegtzustände erneut anfordern bzw. bei aktivierter Secure-ACK-Technik erfolgt die Wiederholung automatisch.
  Wenn die MSG_NUM mit Wert 0 übertragen wird, so erfolgt keine Überprüfung der Sequenz, eine entsprechende Fehlermeldung darf nicht erfolgen. Die 0 setzt auch gleichzeitig die Sequenz im Empfänger zurück, nach der 0 kann dann mit dem durchlaufenden Nachrichtenindex bei 1 begonnen werden.
  Bei Broadcast-Nachrichten und bei lokalen Nachrichten (MSG_LOCAL_*) wird die MSG_NUM komplett ignoriert, sie ist mit 0 zu belegen.
• MSG_TYPE: Ein Byte, welches den Nachrichten-Typ kodiert und damit prinzipiell festlegt, welche Art von Nachricht hier vorliegt und wie die Richtung ist.
  Zur schnelleren Dekodierung sind die Nachrichtentypen in Gruppen zusammengefasst:

  0x00	Offset für Downlink Nachrichten
  0x80	Offset für Uplink Nachrichten
  0x00	Offset für System Nachrichten
  0x10	Offset für Feature und User Nachrichten
  0x20	Offset für Rückmelder Nachrichten
  0x30	Offset für Booster Nachrichten
  0x38	Offset für Accessory, Switch, Makro Nachrichten
  0x60	Offset für DCC-Generator Nachrichten
  0x70	Offset für lokale Nachrichten (mit besonderen Regeln, s.u.)

  Die exakten Kodierungen der Nachrichten sind der Datei bidib_messages.h zu entnehmen, welche allen Lizenznehmern zur Verfügung steht.
• DATA: je nach MSG_TYPE folgen hier die weiteren Parameter der Nachricht. Als DATA sind alle Bytes 0…255 zugelassen.

Die Sicherung der Daten gegen Übertragungsfehler ist Sache des jeweiligen Transportmediums (wie z. B. CRC im Fall der seriellen Übertragung). Das Protokoll selber sieht keinen Message-Retransmit vor, kritische Nachrichten werden auf höherer Ebene abgesichert (z. B. mit Secure-ACK oder entsprechender Antwort des Knotens).

Die Nachrichtenlänge (MSG_LENGTH) dient nicht nur der Begrenzung der Nachricht bei mehreren aufeinanderfolgenden, sondern gibt auch an wie viele DATA-Bytes tatsächlich in der Nachricht als Parameter zur Verfügung stehen. Dies können durchaus mehr oder weniger Bytes sein als der Nachrichtentyp vermuten lassen würde. Hiermit lassen sich optionale Parameter realisieren, die bei Nichtvorhandensein mit Vorgabewerten belegt werden. Werden weniger Parameter als nötig gesendet, antwortet der Knoten mit einer Fehlermeldung. Werden mehr Parameter als erwartet gesendet, so werden die überschüssigen Bytes ignoriert; dies garantiert Vorwärtskompatibilität.

Eine Nachricht kann bis zu 64 Bytes lang sein (MSG_LENGTH=63), alle Transportschichten müssen dies unterstützen. Längere Nachrichten im Downstream können, sofern von der jeweiligen Transportschicht und dem Knoten unterstützt, pro Knoten mittels der Nachricht MSG_PKT_CAPACITY erlaubt werden. Um eine lange Nachricht an einen Knoten zu senden, müssen auch alle Interfaces im Transportpfad dies unterstützen. Längere Nachrichten im Upstream sollen sich an der im Downstream verwendeten Länge orientieren.

3.2. Routing

BiDiB ermöglicht es, Teilnetze zu verdrahten und diese (ähnlich wie bei USB) über Hubs baumförmig aufzubauen. Dies erlaubt die Skalierbarkeit für größere Modellanlagen, für kleinere Anlagen wird man nur ein Netz aufbauen und kann daher die Ausführungen in diesem Kapitel erst mal überspringen. Wie sich die Teilnetze über die lokale Adresszuordnung einigen, wird in einem weiteren Dokument beschrieben – für die Protokollbeschreibung hier sind nur die Ergebnisse dieses Vorgangs relevant.

Zugelassen sind max. 4 kaskadierten Netze. (Diese Beschränkung soll vor allem Hostimplementierungen erleichtern, dadurch ist die jeweilige aktuelle lokale Adresse eines Endknotens auf 32 Bit beschränkt.)

Hierbei gelten folgende Regeln für das Routing der Nachrichten:

• Downstream: Ein Knoten, der eine MESSAGE empfängt, prüft die Zieladresse der Nachricht: diese enthält seine lokale NODE_ADDR in der aktuellen Struktur, evtl. gefolgt von weiteren Subadressen. Ist das nächste Byte ungleich 0 (noch zu MSG_ADDR_STACK gehörend), so stellt es eine Subaddresse dar, und der Knoten schickt die MESSAGE an den untergeordneten Knoten weiter, jedoch um das erste Byte (nämlich seine eigene NODE_ADDR) verkürzt.
  Ist das nächste Byte hingegen gleich 0 und der MSG_ADDR_STACK leer, so ist der Knoten selbst adressiert.
  Bei Broadcast-Nachrichten ist der MSG_ADDR_STACK immer leer.
• Upstream: Ein Knoten, welcher von einem Unterknoten eine MESSAGE empfängt, fügt zur Nachricht die lokale Adresse (NODE_ADDR) des Unterknotens hinzu, und reicht diese dann an sein Interface weiter.

Damit der überordnete Knoten respektive der Host diese Struktur erfassen kann, gibt es entsprechende Befehle:

• MSG_NODETAB_GETALL, MSG_NODETAB_GETNEXT: Mit diesen Befehlen werden die einem Knoten zugeordnetem Unterknoten abgefragt.
  Der Knoten beantwortet diese Abfrage mit einer MSG_NODETAB_COUNT (gibt die Größe der Tabelle an), die einzelnen Tabelleneinträge werden mit einer MSG_NODETAB_GETNEXT angefordert, was jeweils mit einer Nachricht MSG_NODETAB beantwortet wird. Hat der Knoten keine Unterknoten, so ist die Länge der Knotentabelle 1 und der einzige enthaltene Eintrag ist der Knoten selbst.
  Nach dem Power-Up gesendet, wenn die Buszuteilung in der Unterknotenstruktur noch nicht abgeschlossen ist, wird die Abfrage mit MSG_NODETAB_COUNT = 0 beantwortet. Erst wenn die Unterknotenstruktur stabil geworden ist, soll die Anfrage nach der Knotentabelle beantwortet werden. Damit werden häufige Nachrichten über Zustandsänderung zu Beginn vermieden.

Ändert sich die Zuordnungstabelle im laufenden Betrieb (z. B. durch an- oder abstecken), so sendet das Interface von sich aus eine MSG_NODE_LOST oder MSG_NODE_NEW Nachricht. Diese Message muss mit MSG_NODE_CHANGED_ACK quittiert werden (oder die Knotentabelle wird komplett abgefragt). Sowohl die Nachrichten für MSG_NODE_LOST, MSG_NODE_NEW und MSG_NODE_CHANGED_ACK haben als Parameter die (durchlaufende) Versionsnummer (der Tabelle). Damit wird sichergestellt, dass keine Änderungen der Busstruktur übersehen werden.

Veränderungen der Knotentabelle während der Übertragung soll das Interface vermeiden (z. B. keine Logon-Aufforderung aussenden). Erfolgt doch eine Veränderung der Knotentabelle, während diese mit MSG_NODETAB_GETNEXT abgefragt und übertragen wird, so soll das Interface einfach die Übertragung wieder von vorne mit einer neuen MSG_NODETAB_COUNT (aber mit einer um eins inkrementierten Versionsnummer) beginnen.

3.3. Unique-ID

Jeder Knoten hat eine eindeutige Nummer, die Unique-ID. Die Unique-ID besteht aus 7 Bytes:

Die Eindeutigkeit der Produktkennung (und damit der Unique-ID) wird vom jeweiligen Hersteller über die fest einprogrammierten Seriennummern garantiert. Weder Unique-ID noch Produktkennung stellen dabei allerdings eine feste Hardwarekennung dar, ein und dieselbe Baugruppe kann mit verschiedenen Firmwares bespielt werden zwischen denen sich die Klassen oder gar die Produkttypen unterscheiden können. Nur die Seriennummer bleibt dabei in der Regel gleich, alleine ist diese aber nicht nötigerweise eindeutig.

Darstellung der Unique-ID in Hostprogrammen / Aufklebern / Tools:

Damit die Anwender Baugruppen im Ernstfall leichter zuordnen können, wird eine einheitlich Darstellung der Unique-ID empfohlen. Diese soll Vendor-ID abkoppeln und das 4. bis 7. Byte (in dieser Reihenfolge) als Hex darstellen.

Beispiele:

• VID 0D PID 0278456B
• Vendor: Public Domain & Do-It-Yourself Decoders, Product ID 0x0278456B

Zusätzlich kann es in den Knoten die Möglichkeit geben, einen benutzerspezifischen Knoten-Kurznamen (siehe MSG_STRING) zu hinterlegen. Dieser kann alternativ für die Darstellung verwendet werden und ermöglicht dem Endanwender einen leichtere Migration von Konfigurationsprogrammen zu Fahrprogrammen.

3.4. Typischer Protokollstart

Beim Verbindungsaufbau mit einen BiDiB-System kann man gemäß folgender Liste vorgehen:

1. Verbindungsaufbau mit dem ersten Knoten (i. d. R. das Interface).
   Beispielsweise bei einem seriellen Interface schickt der Host zwei MAGIC-Zeichen, gefolgt von einer MSG_SYS_GET_MAGIC Nachricht. Dies probiert man auf den möglichen Baudraten und testet, ob eine fehlerfrei Antwort kommt. Als timeout reichen hier 200ms.
2. Anhalten des BiDiB-Systems.
   Durch Senden von MSG_SYS_DISABLE wird das spontane Übermitteln von Nachrichten unterbunden. Dieses Anhalten dient primär dazu, dass man bei der folgenden Auslesephase nicht von Spontanmeldungen unterbrochen wird.
   Alternativ kann man das System auch mit einer MSG_SYS_RESET zu einem erneuten Start und kompletten Neuanmelden der Knoten veranlassen.
3. Jetzt liest man die Eigenschaften des ersten Knotens ein.
   Wesentlich sind hierbei die Antworten auf MSG_GET_SYS_MAGIC, MSG_SYS_GET_P_VERSION und die Class-Bits der Unique-ID, diese geben an, welche prinzipiellen Eigenschaften der Knoten hat und welche Nachrichten er unterstützt.
   Sollte es sich beim Knoten um ein Interface handeln, lässt man sich die Knotenliste (MSG_NODETAB_GETALL) geben. Des weiteren kann man sich von diesem Knoten alle Features (MSG_FEATURE_GETALL) und alle sonstigen Informationen geben lassen.
   Dabei ist zu beachten, dass man je Knoten nur so viele Abfragen 'auf Vorrat' zugleich schicken darf, dass die zu erwartende Antwortgröße 48 Byte nicht übersteigt.
   Unterstützt ein Knoten Konfigurations-Fingerprinting, kann man mit der Antwort auf MSG_SYS_GET_UNIQUE_ID auch schnell überprüfen ob die Knoteneinstellungen noch den bereits bekannten entsprechen.
4. Weitere Knoten.
   Wenn weitere Knoten gemeldet wurden, so wiederholt man den Schritt 3 für alle Knoten, welche man in der Knotenliste erhalten hat. Sollte bei diesen Knoten wieder ein Interface enthalten sein, so wird auch dieses Interface nach seiner Knotenliste befragt.
   Dabei kann man durchaus mehrere Knoten parallel bearbeiten und z. B. für jede MSG_FEATURE gleich ein MSG_FEATURE_GETNEXT absenden. Als timeout reichen hier 500ms.
5. Freigabe.
   Wenn alle Daten eingelesen sind, dann schaltet man mit der Nachricht MSG_SYS_ENABLE das System für Spontanmeldungen frei.

3.5. Klassen

Knoten melden mit Ihrer Unique-ID Klassen an, z. B. Belegtmelder, Interface, Booster, usw. Wie umfangreich die Klasse implementiert ist, wird durch Features bekanntgegeben.

Innerhalb einer Klasse gibt es verpflichtende Nachrichten, die ein Knoten unbedingt implementieren muss sowie optionale Nachrichten, die nur bei bestimmten Features implementiert sind.

Klasse Interface:

Ein Interface (Hub) transportiert Nachrichten von und zu weiteren Knoten in einem Subnetz.

• Verpflichtend:
  • Alle Systemnachrichten
  • alle Nachrichten zur Node-Verwaltung (NEW, LOST, usw.)
  • Überlastsicher: Ein Interface darf keine Nachrichten verlieren, entsprechende Puffer sind vorzuhalten.
• Optional:
  • User Konfiguration
  • Firmware-Update

Klasse Occupancy:

Der Knoten enthält Belegtmelder.

• Verpflichtend:
  • Alle Systemnachrichten
  • FEATURE_BM_SIZE, FEATURE_BM_ON
  • Nachrichten für Belegtmeldung (GET_RANGE, GET_CONFIDENCE, FREE, OCC, MULTIPLE, CONFIDENCE)
• Optional:
  • SECACK, Features und MIRROR-Nachrichten
  • Strommessung
  • Adressmeldung, Features und Nachrichten (ADDR_GET_RANGE, ADDRESS)
  • BiDi-Detektion, Features und Nachrichten
  • User Konfiguration
  • Firmware-Update

Klasse DCC-Generator:

Der Knoten stellt DCC-Fahr- und Schaltbefehle bereit.

• Verpflichtend:
  • Alle Systemnachrichten
  • FEATURE_GEN_WATCHDOG, FEATURE_GEN_POM_REPEAT, FEATURE_GEN_DRIVE_BUS
  • Nachrichten für Gleisausgabe (MSG_CS_SET_STATE, MSG_CS_DRIVE, MSG_CS_ACCESSORY, MSG_CS_BIN_STATE, MSG_CS_POM)
• Optional:
  • lokale Bedienung, Features und Nachrichten
  • Erweiterte Quittung, Auswertung der ACK-Leitung
  • RailcomPlus, Feature und Nachrichten
  • User Konfiguration
  • Firmware-Update

Klasse DCC-Programmieren:

Der Knoten stellt DCC-Servicemode-Befehle bereit.

• Verpflichtend:
  • Klasse DCC-Generator
  • Programmiermodus (BIDIB_CS_STATE_PROG)
  • Programmiernachrichten (MSG_CS_PROG, MSG_CS_PROG_STATE)

Klasse Accessory Control:

Der Knoten hat Stellfunktionen für Fahrwegzubehör.

• Verpflichtend:
  • Alle Systemnachrichten
  • FEATURE_ACCESSORY_COUNT
  • Nachrichten zur Accessoryansteuerung (MSG_ACCESSORY_SET, MSG_ACCESSORY_GET)
  • SecureSwitch (MSG_ACCESSORY_STATE)
• Optional:
  • Überwachung und Spontanmeldung (MSG_ACCESSORY_NOTIFY)
  • User Konfiguration
  • Firmware-Update

Klasse Booster:

Ein Booster verstärkt das DCC-Signal für Fahrzeuge und DCC-Dekoder, er hat keine eigene DCC-Erzeugung.

• Verpflichtend:
  • Alle Systemnachrichten
  • FEATURE_BST_INHIBIT_AUTOSTART
  • Nachrichten für Booster
• Optional:
  • Diagnostik, FEATURE_BST_CURMEAS_INTERVAL und MSG_BOOST_DIAGNOSTIC
  • BiDi-Detektion, Features und Nachrichten
  • User Konfiguration
  • Firmware-Update

Klasse Schaltfunktionen:

Der Knoten stellt Zubehör- und Licht-Ansteuerung sowie -Animation bereit.

• Verpflichtend:
  • Alle Systemnachrichten
  • FEATURE_CTRL_*_COUNT oder FEATURE_CTRL_PORT_FLAT_MODEL
  • Nachrichten zur Portansteuerung und -konfiguration
• Optional:
  • FEATURE_CTRL_PORT_QUERY_AVAILABLE und Nachrichten zur Portabfrage
  • FEATURE_CTRL_INPUT_NOTIFY und Spontanmeldung von Eingängen
  • FEATURE_CTRL_MAC_LEVEL und Nachrichten zur Makroansteuerung
  • User Konfiguration
  • Firmware-Update

Klasse Gast:

Der Knoten stellt ein Bediengerät dar, dies kann sowohl eine Benutzerschnittstelle (MMI) oder eine Maschinenschnittstelle (M2M) sein.

• Verpflichtend:
  • Alle Systemnachrichten
  • Nachrichten zur verteilten Bedienung (als Gast)
  • String-Nachrichten zur Identifikation
• Optional:
  • User Konfiguration
  • Firmware-Update

Klasse Gastzugang:

Der Knoten enthält eine Schnittstelle zu einem BiDiB-System, er stellt einen Gastgeber-Dienst zur Interaktion mit diesem bereit.

• Verpflichtend:
  • Alle Systemnachrichten
  • Nachrichten zur verteilten Bedienung (als Gastgeber)
  • String-Nachrichten zur Identifikation
• Optional:
  • User Konfiguration
  • Firmware-Update

3.6. Systemzeit

Ein BiDiB-System verfügt über eine globale Systemzeit, um bei zeitbasierten Messungen eine höhere Genauigkeit zu erreichen. Verschiedene Nachrichten können Zeitstempel für das jeweilige Ereignis enthalten, dadurch sind genaue Ergebnisse bei Fahrzeugverfolgung und -kalibrierung ("Einmessen") möglich. Die Unsicherheit bei der Latenz der Datenübertragung wird so eliminiert.

Die BiDiB-Systemzeit hat eine Auflösung von 1 Millisekunde und wird als 16-Bit Integer mit zyklischem Überlauf repräsentiert. Es wird ein Fehler von ±5 ms zwischen den Uhren aller Knoten im System angestrebt.

Um eine Zeitmessung über verschieden Knoten hinweg zu ermöglichen, müssen die Uhren der Knoten aufeinander synchronisiert werden. Diese Synchronisation erfolgt auf jeder Busebene abhängig von der Transportschicht und wird vom jeweiligen Interface übernommen. Ob ein Interface/Hub dies unterstützt oder nicht muss in der Produktbeschreibung angegeben sein.

Die Synchronisation erfolgt typischerweise über eine periodisch ausgesendete Broadcastnachricht mit einem Zeitstempel. Beim Empfang dieser Nachricht wird die lokale Knotenuhr auf die Systemzeit eingestellt. Verzögerungen auf dem Übertragungsweg oder intern beim Senden und Empfangen sind dabei zu berücksichtigen und durch entsprechende Offsets zu korrigieren, die entstehende Unsicherheit soll maximal ±1ms pro Busebene sein. Im Moment der Justage kann es mit diesem Verfahren zu einem (kleinen) Sprung der Zeitfolge kommen, ein Host muss dies berücksichtigen.

Bleibt die Synchronisation aus, muss ein Knoten auf die Verwendung von Zeitstempeln verzichten sobald die enstehende Unsicherheit größer als ±3 ms wird. Beispiel: hat ein Prozessortakt eine Abweichung von bis zu 10ppm (0,01 ‰), dann soll er etwa 100 s nach der letzten Synchronisation seine lokale Uhrzeit nicht mehr verwenden.

Ein Interface soll sich mit der darüberliegenden Struktur synchronisieren, bevor es seine untergeordneten Knoten mit der Systemzeit versorgt. Hat es bis zum SYS_ENABLE (oder einem angemessenen Timeout) keine Synchronisationsnachricht erhalten, so soll es autark seine lokale Uhrzeit benutzen und damit die Synchronisation der Unterknoten durchführen.

4. Nachrichten

Die Nachrichten, welche auf dem BiDiB-System benutzt werden, lassen sich in folgende Bereiche gliedern:

Mit Downlink wird die Richtung Host ⇒ BiDiB-System bezeichnet, mit Uplink die Richtung zum Host.

Generell erfolgen Meldungen im Uplink spontan (nach erfolgter Freigabe im Interface). Bestimmte Meldungsarten können mittels Feature-Einstellung ein- oder ausgeschaltet werden.

Lokale Nachrichten

Für die lokale Kommunikation innerhalb einer Busebene können zusätzliche Nachrichten verwendet werden, um Verbindungszustände zu erfassen, An- und Abmelden zu organisieren oder Zeitsynchronisation herzustellen. Je nach Bustopologie und verwendeter Busphysik kann ein unterschiedlicher Umfang an lokalen Nachrichten nötig sein, näheres regeln die Spezifikationen der jeweiligen Verbindungstechnik.

Für lokale Nachrichten sind die Bereiche 0x70 bis 0x7F (Downstream) und 0xF0 bis 0xFF (Upstream) reserviert. Dies ermöglicht die Abtrennung und separate Behandlung dieser Nachrichten auf Linkebene.

Lokale Nachrichten sind grundsätzlich von der Sequenznummerierng ausgenommen, um Index-Folge der übergeordneten Verbindung Host-Zielknoten nicht stören. Sie werden mit Nachrichten-Index = 0 übertragen, welcher beim Empfang auch nicht ausgewertet wird oder den Indexzähler verändert.

4.1. System-Nachrichten

Die Systemnachrichten sind verpflichtend für alle BiDiB-Knoten mit der Ausnahme von 'Bootloader'-Knoten, siehe hierzu MSG_SYS_MAGIC für detaillierte Angaben.

4.1.1. Downlink: System-Nachrichten

Allgemeine Systemnachrichten

• MSG_SYS_GET_MAGIC:

  Der adressierte BiDiB-Knoten soll die Systemkennung übermitteln. Es folgen keine weiteren Daten. Diese Nachricht soll als erste Nachricht vor jeden anderen Nachricht gesendet werden.

  Der Knoten antwortet mit der SYS_MAGIC, welche auch das prinzipielle Verhalten des Knotens beschreibt.

• MSG_SYS_GET_P_VERSION:

  Abfrage der unterstützten Protokollversion von BiDiB. Es folgen keine weiteren Daten.

  Der entsprechende Knoten antwortet mit der von seiner Software unterstützten Version des Protokoll.

• MSG_SYS_ENABLE:

  Es folgen 0 oder 2 Byte Daten. Der Knoten wird freigegeben, ab diesen Zeitpunkt sind spontane Meldungen (z. B. aufgrund von Änderungen von Belegungszuständen oder wegen neu gefundener Hardware) möglich. Die Nachricht gilt rekursiv für alle Unterknoten.

  MSG_SYS_ENABLE Parameter

  Parameter	Beschreibung
  CLASS_ENABLEL	Class-Bits der Klassen, für deren zugehörige Nachrichten die spontane Aussendung erlaubt wird. Spontane Systemnachrichten werden erlaubt, sobald irgendeines der Bits gesetzt ist.
  CLASS_ENABLEH

  Hubs reichen die Nachricht automatisch an alle Unterknoten weiter, es genügt daher im Host nur den Knoten 0 zu adressieren. Es erfolgt keine Quittung.

  Der optionale Parameter CLASS_ENABLE ist seit Protokollversion 0.9 verfügbar. Fehlt er, so wird 0xDF 0x00 als Wert angenommen, d.h. Bedienfunktionen sind ausgenommen.

  Hinweise:

  MSG_SYS_ENABLE steuert nur die Freigabe spontaner Nachrichten, man kann ohne SYS_ENABLE mit dem Knoten normal kommunizieren und dessen Funktionen benutzen.

  Wenn nach einen MSG_SYS_ENABLE ein weiterer Knoten hinzukommen, so hat dieser von der Vererbung nichts mitbekommen. Dieser Knoten muss nach dem NODETAB_CHANGE_ACK mit dem aktuellen Zustand von SYS_ENABLE versorgt werden.

  Bei der Initialisierung wird empfohlen, zuerst Knotentabelle und Features komplett einzulesen und als Abschluss der Initialisierung MSG_SYS_ENABLE zu senden.

• MSG_SYS_DISABLE:

  Es folgen 0 oder 2 Byte Daten. Das BiDiB-System wird blockiert, ab diesen Zeitpunkt erfolgen keine spontanen Meldungen mehr. Ereignisse, welche im Zustand SYS_DISABLE passieren, werden nicht für später zwischengespeichert, Knotenzustände lassen sich aber gezielt abfragen. Die Nachricht gilt rekursiv für alle Unterknoten.

  MSG_SYS_DISABLE Parameter

  Parameter	Beschreibung
  CLASS_DISABLEL	Class-Bits der Klassen, für deren zugehörige Nachrichten die spontane Aussendung abgeschalten wird. Spontane Systemnachrichten bleiben solange erlaubt, sobald irgendeines der Bits gesetzt ist.
  CLASS_DISABLEH

  Hubs reichen die Nachricht automatisch an alle Unterknoten weiter, es genügt daher im Host nur den Knoten 0 zu adressieren. Es erfolgt keine Quittung.

  Der optionale Parameter CLASS_DISABLE ist seit Protokollversion 0.9 verfügbar. Fehlt er, so wird 0xFF 0xFF als Wert angenommen, d.h. sämtliche Spontannachrichten werden blockiert.

• MSG_SYS_GET_UNIQUE_ID:

  Abfrage der Unique-ID und des Konfigurations-Fingerprints des Knotens. Es folgen keine weiteren Daten.

  Der entsprechende Knoten antwortet mit MSG_SYS_UNIQUE_ID.

  (Die Unique-ID eines Knotens ist auch in der Knotentabelle seines Interfaces hinterlegt).

• MSG_SYS_GET_SW_VERSION:

  Abfrage der installierten Softwareversion(en) des Knotens. Es folgen keine weiteren Daten. Der Knoten antwortet mit einer MSG_SYS_SW_VERSION.

• MSG_SYS_PING:

  Es folgt ein Byte.

  Der entsprechende Knoten im BiDiB-System wird veranlasst, eine quasi leere Nachricht (MSG_SYS_PONG) zurück zu senden. Diese Antwort muss binnen 250ms eintreffen, ansonsten hat der Host den entsprechenden Knoten als ausgefallen anzusehen. Das als Parameter übergebene Byte wird bei MSG_SYS_PONG zurückgesendet.

• MSG_LOCAL_PING:

  Diese Nachricht wird nur auf lokaler Ebene verwendet, um die Ausfallprüfung (keep-alive) der Transportschicht (z. B. serielle Schnittstelle) zu unterstützen.

  Es folgen keine weiteren Daten.

  Der entsprechende Knoten im BiDiB-System wird veranlasst, eine Nachricht des Typs MSG_LOCAL_PONG zurück zu senden. Diese Antwort muss binnen 250ms eintreffen, ansonsten betrachtet das Interface den entsprechenden Knoten als ausgefallen und meldet diesen Ausfall mittels einer MSG_NODE_LOST an den Host.

  (Im Falle des BiDiBus übernimmt der Token und die Antwort auf den Token diese Ausfallüberprüfung.)

• MSG_SYS_IDENTIFY:

  Es folgt ein weiteres Byte. 0: Identify wird abgeschaltet, 1: Identify wird eingeschaltet.

  Der entsprechende Knoten im BiDiB-System wird veranlasst, lokal eine Anzeige für Identify anzuzeigen (z. B. eine blinkende LED). Der Knoten antwortet mit einer MSG_SYS_IDENTIFY_STATE Nachricht.

• MSG_SYS_GET_ERROR:

  Die letzte aufgetretene (und nicht bereits per Spontanmeldung abgesendete) Fehlermeldung wird ausgelesen. Der Fehlerspeicher wird durch das Lesen gelöscht. Sollte kein Fehler vorliegen, so wird eine leere Fehlermeldung (also Fehlernummer 0) zurückgeliefert.

• MSG_LOCAL_SYNC:

  Diese Nachricht wird nur auf lokaler Ebene verwendet, um die Systemzeit in der Transportschicht zu synchronisieren.

  Es folgen zwei Bytes (TIME_L, TIME_H) mit der BiDiB-Systemzeit, TIME gibt dabei den Zeitpunkt des letzten Framemarkers vor der Nachricht an. Der Knoten stellt seine lokale Uhr auf den empfangenen Zeitstempel, eventuelle Datenlaufzeiten sind dabei durch entsprechende Offsets zu kompensieren. Die Nachricht wird nicht beantwortet.

  Beispiel: Ein Knoten empfängt MSG_LOCAL_SYNC 3. Die Zeit vom Framesignal bis zur Bearbeitung der Nachricht beträgt 2 ms. Die interne Uhr wird also auf 5 gestellt.

Systemnachrichten für die Busverwaltung

(Hinweis zur Implementierung: diese Nachrichten sind mandatory, aber diese Nachrichten beinhalten nur bei Interface-Knoten variable Daten, einfache Endknoten haben konstante Daten. D.h. die Antworten auf MSG_NODETAB_GET* usw. sind als Konstanten ablegbar und damit auch auf sehr kleinen Microcontrollern implementierbar). BiDiB verfügt über eine automatische Zuordnung der Knoten (z. B. Melder, Booster usw.). Diese Zuordnung ist im Interface hinterlegt und kann dort abgeholt werden. Hierfür sind folgende Nachrichten vorgesehen:

• MSG_SYS_RESET:

  Das BiDiB-System wird hinsichtlich der Hostschnittstelle zurückgesetzt und die Zuordnung aller Knoten wird erneut durchgeführt. Die bisherige Zuordnungstabelle verliert ihre Gültigkeit.

  Wenn diese Nachricht an einen Knoten gerichtet wird, so soll sich dieser Knoten aus dem Bus ausloggen (durch eine Wartezeit von 1s) und anschließend erneut einloggen. Interne Zustände des Knotens können dabei verloren gehen.

  Achtung: Durch ein MSG_SYS_RESET gehen alle noch nicht ausgelieferten Nachrichten sowohl im Uplink als auch im Downlink verloren, auch geht das BiDiB-System in den Zustand SYS_DISABLE, es ist also nach einem Reset die Konsistenz der Daten zu prüfen und die Informationen vom BiDiB-System neu einzulesen.

  Achtung: Durch ein MSG_SYS_RESET wird eine Busstruktur zurückgesetzt, im Falles des BiDiBus (RS485) bedeutet das eine Pause von einer Sekunde auf dem Bus, damit alle Unterknoten in den Zustand Disconnected wechseln. Erst nach dieser Zeit wird der Bus neu aufgebaut und die Knotentabelle wird wieder gültig. In dieser Zeit wird MSG_NODETAB_GETALL mit 0 beantwortet.

  Achtung: Erst wenn der Knotentabelle wieder gültig geworden ist, dann können auch wieder Zugriffe auf Knoten und die Weiterleitungen von Nachrichten erfolgen, insbesondere auch von Broadcast-Nachrichten wie z. B. MSG_SYS_ENABLE oder MSG_SYS_CLOCK.

  Ein Knoten kann von sich aus einen Reset anfordern: Dies geschieht durch Senden einer Fehlermeldung mit dem Fehlercode BIDIB_ERR_RESET_REQUIRED.

• MSG_NODETAB_GETALL:

  Mit diesem Befehl wird das Interface veranlasst, die aktuelle Zurordnungstabelle von Unique-ID und lokaler Adresse auszugeben. Diese Ausgabe erfolgt als Reihe von Nachrichten, es wird mit einer MSG_NODETAB_COUNT begonnen, gefolgt von MSG_NODETAB, welche jeweils durch eine MSG_NODETAB_GETNEXT ausgelöst wird.

  Während die Ausgabe läuft, führen weitere Anfragen mit MSG_NODETAB_GETALL zu einem Abbruch und Neustart der Übertragung.

  Sollte eine solche Tabelle noch nicht vorliegen, antwortet das Interface mit einer Nachricht MSG_NODETAB_COUNT = 0. In diesem Fall muss der Host nach ein paar ms erneut nachfragen.

  Liegt die Tabelle vor, antwortet das Interface mit MSG_NODETAB_COUNT = 'Tabellenlänge'.

  Hinweis:

  Diese Nachricht findet nur auf Knoten Verwendung, welche in ihrer Unique-ID einen Hub angemeldet haben. Knoten, welche keine Substruktur beinhalten, beantworten diese Anfrage trotzdem, in diesem Fall ist die Knotentabelle nur einen Eintrag lang, lokale Adresse ist 0.

• MSG_NODETAB_GETNEXT:

  Mit diesem Befehl wird das Interface veranlasst, die nächste Zeile der Knotentabelle zu senden. Es folgen keine Parameter.

  Der Knoten antwortet mit einer MSG_NODETAB Nachricht. Liegt keine Zeile (mehr) vor, antwortet er mit MSG_NODE_NA 255. Hat sich die Knotentabelle seit der letzen Übertragung von MSG_NODETAB_COUNT verändert, antwortet er mit MSG_NODETAB_COUNT und beginnt bei den MSG_NODETAB-Nachrichten von vorn (mit der inkrementierten Versionsnummer).

• MSG_GET_PKT_CAPACITY:

  Mit diesem Befehl kann man aus einem Knoten auslesen, welche maximale Nachrichtenlänge er verarbeiten kann. Dies entspricht der maximalen Länge einer Nachrichtensequenz, wenn diese nur aus der einen Nachricht besteht, und damit der maximalen Anzahl an Bytes in einem Paket (zwischen zwei Frame-Markierungen).

  Der Knoten antwortet mit einer MSG_PKT_CAPACITY Nachricht. Antwortet der Knoten nicht oder mit einem Wert unter 64, gilt die standardmäßige Beschränkung auf 64.

• MSG_NODE_CHANGED_ACK:

  Es folgt ein Byte mit der Sequenznummer (Versionsnummer der Knotentabelle) der NODE_NEW- bzw. NODE_LOST-Nachricht, welche bestätigt wird. Diese Nachricht sendet der Host innerhalb von 250ms an ein Interface, wenn es von diesem eine Mitteilung über einen verlorenen oder neu hinzugekommenen Knoten erhalten hat. Wenn das Interface die gleiche Versionsnummer der Knotentabelle bestätigt bekommen hat, die es bei der letzten Änderungsmitteilung gesandt hat, so wird diese und alle vorangegangenen Änderungen als quittiert angesehen.

• MSG_LOCAL_LOGON_ACK (vormals MSG_LOGON_ACK):

  Diese Nachricht wird nur auf lokaler Ebene verwendet, um die Adressvergabe der Transportschicht (z. B. BiDiBus) zu regeln.

  Es folgt ein Byte mit der lokalen Adresse (NODE_ADDR) und 7 Bytes mit der Unique-ID. Nur wenn der Knoten die empfangene Unique-ID identisch zu seiner internen Unique-ID geprüft hat, darf er seine lokale Adresse auf empfangene NODE_ADDR einstellen.

  Die Nachricht wird als Broadcast und mit der MSG_NUM = 0 gesendet. Sie wird immer interpretiert, selbst wenn (noch) kein Logonversuch unternommen wurde. Es ist damit auch möglich, einem Knoten eine lokale Adresse vor dem allgemeinen Logon zuzuteilen.

• MSG_LOCAL_LOGON_REJECTED (vormals MSG_LOGON_RECJECTED):

  Diese Nachricht wird nur auf lokaler Ebene verwendet, um die Adressvergabe der Transportschicht (z. B. BiDiBus) zu regeln.

  Es folgen 7 Bytes mit der Unique-ID. Die Anmeldeversuche eines angesprochenen Knoten werden damit abgewiesen.

  Mögliche Ursache für das Abweisen des Logons können sein:

  • Die Interfacetabelle ist voll, die max. mögliche Zahl an Teilnehmern ist erreicht.
  • Es wurde eine doppelte Unique-ID auf dem Bus erkannt

  Zugleich mit der MSG_LOCAL_LOGON_REJECTED schickt das Interface eine Fehlermeldung mit BIDIB_ERR_BUS an den Host ab.

Systemnachrichten für die Anlagenverwaltung

(Hinweis zur Implementierung: diese Nachrichten sind mandatory)

• MSG_SYS_CLOCK:

  Mit diesem Befehl wird eine Anlagen-Modelluhrzeit übertragen. Diese Anlagenuhr läuft typischerweise beschleunigt gegenüber der Echtzeit. Es folgen vier Bytes (TCODE₀, TCODE₁, TCODE₂, TCODE₃) mit der Angabe der Uhrzeit. Die Kodierung dieser Bytes stimmt mit der Kodierung des entsprechenden DCC-Befehls überein.

  Aufbau Modellzeit

  Feld	Kodierung	Bedeutung
  TCODE0	00mmmmmm	mmmmmm = Angabe der Minute, Wertebereich 0…59.
  TCODE1	100HHHHH	HHHHH = Angabe der Stunde, Wertebereich 0…23.
  TCODE2	01000www	www = Wochentag, 0=Montag, 1=Dienstag, ... 6=Sonntag.
  TCODE3	11ffffff	ffffff = Uhrbeschleunigungsfaktor, ffffff=0 heißt Uhr angehalten.

  Die Daten bestehen jeweils aus einem 2 Bit Feld (Typ) und 6 Bit Wert. Der Host sendet das komplette Zeitpaket jede Modellbahn-Minute.

  Wenn die Anlage angehalten wird, soll der Uhrbeschleunigungsfaktor 0 gesendet werden.

  Auf Busimplementationen soll diese Nachricht bevorzugt als Broadcast gesendet werden.

4.1.2. Uplink: System-Nachrichten

Allgemeine Systemnachrichten

• MSG_SYS_MAGIC:

  Übertragung der Systemkennung: Diese Variable dient zum Identifizieren und zur Kontrolle der Übertragung. Es folgen zwei Datenbytes, MAGIC_L, MAGIC_H, welche die Systemkennung darstellen. Die Systemkennung wird mit laufendem Nachrichtenindex 0 übertragen, damit kann die Nachrichtenfolge hostseitig einsynchronisiert werden.

  Kodierung der Systemkennung

  MAGICL	MAGICH	Bedeutung
  0xFE	0xAF	BIDIB_SYS_MAGIC = Standard BiDiB-Knoten
  0x0D	0xB0	BIDIB_BOOT_MAGIC = Nur reduzierter Bootloader
  …	…	reserviert

  Wenn ein Knoten bei der Abfrage der SYS_MAGIC mit BIDIB_BOOT_MAGIC = 0xB00D antwortet, so handelt es sich um einen in seiner Funktionalität stark reduzierten Knoten, welcher nur den Bootloader aktiviert hat. Dieser Knoten beherrscht nur einen kleinen Teil der BiDiB-Nachrichten (siehe Tabelle), er kennt keine Featureabfragen, hat jedoch das Feature FEATURE_FW_UPDATE_MODE (254) = 1 gesetzt (obwohl es nicht abfragbar ist). Auch die Fehlererkennung und -behandlung in diesem Knoten ist reduziert, die Prüfung der Integrität der Datenübertragung (CRC) ist jedoch verpflichtend. Dieser Knoten hat keine ClassID-Bits gesetzt.

  Nachrichten eines Knotens mit BIDIB_BOOT_MAGIC

  Downstream	Upstream
  MSG_SYS_GET_MAGIC	MSG_SYS_MAGIC
  MSG_SYS_GET_P_VERSION	MSG_SYS_P_VERSION
  MSG_SYS_GET_SW_VERSION	MSG_SYS_SW_VERSION
  MSG_SYS_IDENTIFY	MSG_SYS_IDENTIFY_STATE
  MSG_FW_UPDATE_OP	MSG_FW_UPDATE_STAT
  MSG_SYS_RESET
  MSG_LOCAL_LOGON_ACK	MSG_LOCAL_LOGON
  MSG_SYS_GET_UNIQUE_ID	MSG_SYS_UNIQUE_ID

  Hinweise:

  Ziel dieses reduzierten Befehlsumfanges ist die Möglichkeit, einen kleinen Bootloader zu realisieren, welcher in den Bootbereich-Speicher kleinerer Prozessoren passt (<4k).

  MSG_SYS_GET_UNIQUE_ID ist nur verpflichtend für Knoten, bei denen die Unique-ID nicht durch die Abfrage der Knotentabelle des übergeordneten Interfaces ermittelt werden kann. (Grund: das Hostprogramm braucht die Unique-ID, um eine zugehörige Firmware zu ermitteln).

  Sofern es die Speichergröße erlaubt, soll der Bootloader mit normaler BiDiB-Funktionalität realisiert werden.

• MSG_SYS_PONG:

  Es folgt ein Byte. Diese Nachricht erfolgt als Antwort auf eine MSG_SYS_PING Anfrage, dabei wird das bei PING übergebene Byte wieder zurückgesendet.

• MSG_LOCAL_PONG:

  Diese Nachricht wird nur auf lokaler Ebene verwendet, um die Ausfallprüfung der Transportschicht (z. B. serielle Schnittstelle) zu unterstützen.

  Leere Nachricht, es folgen keine weiteren Daten. Diese Nachricht ist die Antwort zu MSG_LOCAL_PING.

• MSG_SYS_P_VERSION:

  Übertragung der unterstützten Protokollversion. Es folgen zwei Datenbytes, welche die Protokollversion von BiDiB kodieren.

  MSG_SYS_P_VERSION Parameter

  Parameter	Beschreibung
  P_VERSIONL	Nebenversionsnummer
  P_VERSIONH	Hauptversionsnummer

• MSG_SYS_UNIQUE_ID:

  Der Knoten sendet seine eindeutige Kennung. Es folgen 7 Bytes mit der Unique-ID und optional 4 Bytes mit einem Konfigurations-Fingerprint.

  Der Fingerprint ist eine 32-bittige Prüfsumme über sämtliche Einstellungen des Knotens. Dazu gehören:

  • Features (MSG_FEATURE)
  • Userkonfiguration (MSG_VENDOR und MSG_STRING)
  • Accessorykonfiguration (MSG_ACCESSORY_PARA)
  • Portkonfiguration (MSG_LC_CONFIGX)
  • Makrokonfiguration (MSG_LC_MACRO und MSG_LC_MACRO_PARA)

  Explizit ausgenommen sind sämtliche Bus- und Betriebszustände (auch solche die über Neustarts hinweg persistiert werden), unterstützte Protokollversionen und Firmwarestände (solange sich nichts anderes ändert).

  Der Fingerprint wird vom Knoten mittels einer guten (gleichverteilten, chaotischen, effizienten) aber nicht notwendigerweise kryptographischen Hashfunktion errechnet. Ändert sich ein Konfigurationswert, ändert sich auch der Fingerprint.

  Hinweise:

  Fingerprinting ist optional für Knoten. Wird es nicht unterstützt, wird nur die Unique-ID übertragen.

  Die Hashfunktion muss bei jeder Anfrage den aktuellen Wert liefern, es genügt nicht sie nur einmal beim Knotenstart zu berechnen. Zur Steigerung der Effizienz ist es auch möglich, einen inkrementellen Algorithmus zu wählen der jede Änderung einer Einstellung einzeln mit ins Ergebnis einbezieht.

  Der Fingerprint dient dem schnellen Laden von Knotenkonfigurationen beim Sitzungsstart. Ein Host kann sich die einmal abgefragten oder geschriebenen Konfigurationswerte für einen Knoten zusammen mit dem dazugehörigen Fingerprint lokal speichern. Trifft er das nächste Mal auf den Knoten, kann er sie anhand der Unique-ID und des Fingerprints im Speicher identifizieren und direkt laden ohne den Knoten abfragen zu müssen.

• MSG_SYS_SW_VERSION:

  Übertragung der Softwareversion: Es folgen 1 bis 16 Tripel (je 3 Bytes), diese kodieren den Softwarestand des Knotens und evtl. assoziierter knoteninterner Subsysteme. Der Wertebereich ist herstellerspezifisch. In jedem Tripel wird der Subänderungsindex als erstes, der Hauptänderungsindex als letztes übertragen. Eine jeweils neuere Version hat einen numerisch größeren Änderungsindex.

  Das erste Tripel beschreibt die Softwareversion des Knotens selbst, weitere Tripel können für fest dem Knoten zugeordnete Untersysteme (Coprozessoren, Boardversionen u.ä.) verwendet werden.

  Anmerkung: bis zur Spezifikationsrevision 1.21 war nur ein Triple als Antwort erlaubt.

• MSG_SYS_IDENTIFY_STATE:

  Es folgt ein Byte mit dem Zustand des Identify: 0: abgeschaltet, 1: eingeschaltet.

  Diese Nachricht wird gesendet, wenn entweder per Hostbefehl (MSG_SYS_IDENTIFY) oder lokal per Taster die Identifizierung des Knotens ausgelöst oder abgeschaltet wurde.

  Empfehlung: Sollte der Taster für Identify mehrfach belegt sein (z. B. wenn ein Dekoder auch per DCC Adresse-Lernen programmiert werden kann), so soll ein kurzer Tastendruck Identify auslösen, ein langer Tastendruck das DCC-Lernen. Mit dieser Empfehlung soll gleiches Verhalten über verschiedene Baugruppen hinweg realisiert werden.

• MSG_SYS_ERROR:

  Fehlermeldung eines Knotens. Die Fehlermeldungen erfolgen entweder nach einer Abfrage (per MSG_SYS_GET_ERROR), spontan (sofern der Knoten enabled ist), oder anstatt der Antwort (bei Verwerfen der Nachricht). Es folgt ein Byte mit der Fehlerart sowie fallweise weitere Parameter. Je nach Fehlerart wird die Verarbeitung der Daten nicht mehr möglich sein.

  Kodierung der Fehlerart

  Wert	Name	Bedeutung
  0x00	BIDIB_ERR_NONE	Der Knoten hat keinen Fehler (mehr) im Fehlerspeicher.
  0x01	BIDIB_ERR_TXT	Der Knoten sendet eine Textfehlermeldung: es folgt ein Byte mit Angabe der Länge, gefolgt von ASCII-Zeichen der Fehlermeldung.
  0x02	BIDIB_ERR_CRC	Die empfangene Nachricht (bzw. das Nachrichtenpaket) hatte einen CRC-Fehler, es folgt ein Byte mit der MSG_NUM der fehlerhaften Nachricht. Der Knoten verwirft das empfangene Nachrichtenpaket. Hinweis: diese Nachricht ist nur sinnvoll bei Punkt-zu-Punkt Verbindungen, bei physikalischen Strukturen mit gleichzeitigem Empfang mehrerer Teilnehmer erfolgt keine Fehlermeldung.
  0x03	BIDIB_ERR_SIZE	Die empfangene Nachricht weist eine zu geringe Länge auf (zu wenig Parameter). Es folgt ein Byte mit der MSG_NUM. Der Knoten verwirft die empfangene Nachricht.
  0x04	BIDIB_ERR_SEQUENCE	Die empfangene Nachrichtenfolge weist einen Sequenzfehler auf, es sind Nachrichten verloren gegangen. Es folgt ein Byte mit der MSG_NUM der aktuell erwarteten Nachricht (bei korrekter Sequenz) sowie optional ein Byte mit der MSG_NUM der aktuellen Nachricht, also der ersten wieder richtig empfangenen Nachricht. Der Knoten bearbeitet jedoch die empfangenen Nachrichten und übernimmt die aktuelle Sequenznummer als neuen Startpunkt.
  0x05	BIDIB_ERR_PARAMETER	Die empfangene Nachrichten weist einen Parameterfehler auf. es folgt ein Byte mit der MSG_NUM der Nachricht, welche den Fehler enthielt. Die Nachricht wird nicht bearbeitet.
  0x10	BIDIB_ERR_BUS	Die diesem Knoten zugeordnete Unterstruktur hat einen Busfehler. Es folgt ein Byte mit der Fehlernummer: 0 Kurzschluss 1 Bus unterbrochen, fehlende Abschlusswiderstände 2 zu viele Abschlusswiderstände 3 Anmeldefehler, Inkonsistenzen in der Knotentabelle. 4 Anmeldefehler, zu viele Knoten in dieser Ebene. 5 Busfehler, Overrun am Busmaster aufgetreten (normalerweise Folge eines Programmierfehlers). 6 Busfehler, Token am Busmaster aufgetreten.
  0x11	BIDIB_ERR_ADDRSTACK	Eine Nachricht von einem Unterknoten enthält 3 lokale Adressen, d.h. der verfügbare Adressstack ist bereits erschöpft (weil da zu viele Ebenen hintereinander liegen) und die Nachricht kann nicht mehr geroutet werden. Es folgen 4 Bytes: NODE ADDR_STACK NODE: der Knoten, welche die zu lange Adresse eingereicht hat. ADDR_STACK: die restlichen Bytes dieser zu langen Adresse. Damit kann der Host die Ebene identifizieren, in welcher die Adressverletzung auftrat.
  0x12	BIDIB_ERR_IDDOUBLE	Es versucht sich ein Knoten anzumelden, welcher bereits angemeldet ist oder der dieselbe ID hat wie ein bereits in der Knotentabelle enthaltener. Es folgen optional 7 Bytes mit der Unique-ID des Knotens.
  0x13	BIDIB_ERR_SUBCRC	Eine Nachricht von einem Unterknoten konnte wegen eines CRC-Fehlers nicht empfangen werden. Es folgt 1 Byte: NODE NODE: Lokale Adresse des gerade adressierten Knotens.
  0x14	BIDIB_ERR_SUBTIME	Eine Nachricht von einem Unterknoten konnte nicht komplett empfangen werden, timeout. Es folgt 1 Byte. NODE NODE: Lokale Adresse des gerade adressierten Knotens.
  0x15	BIDIB_ERR_SUBPAKET	Ein Paket mit einer Nachricht von einem Unterknoten hatte eine Konsistenzfehler in der Size-Angabe. Es folgt 1 Byte mit der NODE-Adresse und optional weitere Bytes mit dem Inhalt des Pakets. NODE: Lokale Adresse des gerade adressierten Knotens.
  0x16	BIDIB_ERR_OVERRUN	Ein Interface konnte die übermittelten Nachrichten nicht mehr auf seiner nachgeordneten Struktur weitersenden, es sind Nachrichten verlorengegangen.
  0x20	BIDIB_ERR_HW	Der Knoten hat einen internen Fehler festgestellt. Es folgt ein Byte mit der Fehlernummer (Herstellerspezifisch)
  0x21	BIDIB_ERR_RESET_REQUIRED	Der Knoten ist (z. B. durch Umkonfiguration von CVs) in einem Zustand, welcher einen Reset erfordert.
  0x30	BIDIB_ERR_NO_SECACK_BY_HOST	Die Maximalzahl an Wiederholungen von Belegtmeldungsnachrichten wurde erreicht ohne dass der Host den Zustand quittiert hat.

Systemnachrichten für die Busverwaltung

(Anmerkung zur Implementierung: diese Nachrichten sind nur bei Interface-Knoten mit variablen Daten, einfache Endknoten haben konstante Daten, entsprechende Antworten können also statisch im Flashspeicher des Prozessors abgelegt werden).

• MSG_NODETAB_COUNT:

  Diese Nachricht wird vor der Übertragung einzelner MSG_NODETAB gesendet, wenn der Host mit MSG_NODETAB_GETALL angefragt hat. Es folgt ein Byte mit der Länge der Knotentabelle. Diese Tabelle wird anschließend mit einer entsprechenden Anzahl an MSG_NODETAB_GETNEXT-Abfragen abgeholt.

• MSG_NODETAB:

  Es folgen 9 Bytes mit einem Eintrag der Zuordnungstabelle:

  MSG_NODETAB Parameter

  Parameter	Beschreibung
  NODETAB_VERSION	Aktuelle Version der Tabelle, wird bei jeder Änderung inkrementiert, Überlauf: 255→1
  NODE_ADDR	Zugewiesene lokale Adresse des Knotens (Wertebereich 0…127) Adresse 0 steht für den Knoten selbst.
  UNIQUE_ID[7]	Die Unique-ID des Knotens, diese besteht aus 7 Bytes

  Wenn ein Knoten keine Unterknoten hat (also auch kein Class-Bit 'Hub' in der Unique-ID gesetzt hat), so ist die Knotentabelle nur einen Eintrag lang, und enthält den Knoten selbst.

  Die Übertragung der Knotentabelle erfolgt mit einer oder mehreren MSG_NODETAB-Nachrichten. Während die Übertragung läuft, sollen keine Knoten der Tabelle hinzugefügt oder entnommen werden. Erfolgt dennoch eine Änderung, beginnt das Interface wieder von vorn mit MSG_NODETAB_COUNT.

• MSG_PKT_CAPACITY:

  Mit dieser Nachricht teilt ein Knoten dem Host mit, welche maximale Nachrichtenlänge er lokal verarbeiten kann. Dies ist in der Regel begrenzt durch die Größe des Empfangspuffers für Pakete der jeweiligen Transportschicht (welche ansonsten transparent für den Host ist). Die Länge entspricht bei paketbasierter Übertragung von Nachrichtensequenzen der maximalen Anzahl von Bytes für den Paketinhalt (als eine Sequenz mit nur einer Nachricht), z. B. 64 beim BiDiBus.

  Es folgt eine Längenangabe, bestehend aus einem Byte, Wertebereich 64…127. Der Minimalwert ist 64, kleinere Werte sind reserviert und zu ignorieren. (MSB ist reserviert für length-extension)

• MSG_NODE_NA:

  Es folgt ein Byte mit der (lokalen) Nummer des angesprochenen Knotens. Die Meldung wird vom Interface zurückgesendet, wenn der Host versucht, einen Knoten anzusprechen, welcher nicht (oder nicht mehr) in der Liste ist.

  Diese Nachricht (mit Knoten 255) wird auch gesendet, wenn bei der Übertragung mittels MSG_NODETAB_GETNEXT bereits alle Knoten übertragen wurden.

• MSG_NODE_LOST:

  Es folgt die aktuelle Versionsnummer der Knotentabelle, und der Tabelleneintrag des verlorenen Knotens (siehe MSG_NODETAB), bestehend aus lokaler Adresse (1 Byte) und Unique-ID (7-Bytes).

  Ein bereits angemeldeter Knoten antwortet nicht mehr.

  Wenn es sich bei dem verlorenen Knoten z. B. um einen Melder handelt, so kann (und soll) der Host geeignete Maßnahmen einleiten (partieller oder allgemeiner Nothalt, Verkehrslenkung). Die MSG_NODE_LOST des Interfaces muss vom Host bestätigt werden. Sollte sie innerhalb von 250ms nicht bestätigt werden, so wird sie von Interface max. 16 Mal wiederholt.

  Wenn es sich bei dem verlorenen Knoten um einen Hub handelt, so sind implizit auch alle Knoten hinter diesem Hub verloren.

• MSG_NODE_NEW:

  Es wurde ein neuer, bisher nicht vorhandener Knoten erkannt und der Knoten-Liste hinzugefügt. Es folgt die aktuelle Versionsnummer der Knotentabelle, und der Tabelleneintrag dieses neuen Knotens (siehe MSG_NODETAB), bestehend aus lokaler Adresse (1 Byte) und Unique-ID (7-Bytes).

  Die Nachrichten für MSG_NODE_LOST und MSG_NODE_NEW werden erst nach dem erstmaligen Einlesen der Knotentabelle gesendet und nur dann, wenn das (Spontan-)Enable des Interfaces gesetzt ist. MSG_NODE_NEW muss ebenso wie MSG_NODE_LOST vom Host bestätigt werden (mittels MSG_NODE_CHANGED_ACK oder einer Komplettabfrage beginnend mit MSG_NODETAB_GETALL), ansonsten erfolgen bis zu 16 Wiederholungen.

  Wenn mehrere Änderungen hintereinander auftreten, so wird jedes Mal die Versionsnummer inkrementiert und eine Nachricht erzeugt, wiederholt wird aber nur die letzte Änderung.

• MSG_STALL:

  Es folgt ein Byte, welches den Zustand kennzeichnet.

  0:

  Der Knoten arbeitet normal

  1:

  Ein Knoten sendet diese Nachricht, wenn er feststellt, dass sein Ausgangsdatenpuffer voll zu werden droht und deswegen die aktuelle Downstream-Nachricht nicht mehr bearbeitet werden kann. Ein solche Situation kann eintreten, wenn der Host den Knoten mit Anfragen 'zuschüttet'. Sie kann auch eintreten, wenn z. B. eine Zwischenebene des BiDiB-Baumes eine geringere Transportbandbreite hat: das entsprechende Interface schafft es nicht mehr, die vom Host übergebenen Daten auf seiner Unterstruktur weiterzugeben. Bei MSG_STALL eines Interfaces darf daher der Host auch keine Nachrichten mehr an Subknoten des Interfaces schicken.

  Ein MSG_STALL 1 wird vom Knoten mit einem MSG_STALL 0 wieder aufgehoben.

  Hinweis:

  Es ist in BiDiB gewünscht und zulässig, dass der Host Nachrichten an einen Knoten zusammenfasst und gemeinsam überträgt. Dabei darf es allerdings nicht zu einer Überlastung des Knotens kommen. Diese tritt z. B. bei einer BiDiBus-Struktur dann ein, wenn die in einem Paket übertragenen Nachrichten mehr als 48 Bytes in Summe an Antworten generieren.

  D.h. man kann ohne weiteres einen Block aus MSG_GET_SW_VERSION, MSG_GET_P_VERSION, MSG_FEATURE_GETALL, MSG_FEATURE_GETNEXT, MSG_FEATURE_GETNEXT, MSG_FEATURE_GETNEXT schicken, um die Daten des Knotens einzulesen.

• MSG_LOCAL_LOGON (vormals MSG_LOGON):

  Diese Nachricht wird nur auf lokaler Ebene verwendet, um die Adressvergabe der Transportschicht (z. B. BiDiBus) zu regeln.

  Es folgen 7 Bytes mit der Unique-ID. Der Knoten versucht sich anzumelden. Diese Nachricht wird beim Systemstart verwendet, um die lokale Buszuteilung abzuklären.

4.2. Abfragen oder Setzen von Feature-Einstellungen

Vorbemerkung: Es gibt unterschiedliche Implementierung und auch Anforderungen an ein BiDiB-System, welche auch teilweise anlagenspezifisch sind. Zudem können auf einer Anlage Knoten mit unterschiedlichen Eigenschaften installiert sein.

Beispiele:

In einer mit Mittelleiter installieren Modellanlage ist die Richtungsauswertung ungültig; der Anwender wird diese Eigenschaft hier im Belegtmelder abwählen (müssen).

der Belegtmelder der Firma xyz kann Strommessung, die Software der Firma abc kann diese aber nicht auswerten. Also wird die Software der Fa. abc die Übertragung von Strommesswerten abwählen.

Aus diesem Grund gibt es im Protokoll die Möglichkeit, Eigenschaften des Knotens abzufragen und den Knoten zu konfigurieren, d.h. diese Eigenschaft freizugeben. Dies geschieht über die Feature-Einstellungen. Wenn ein Knoten eine bestimmte Eigenschaft nicht unterstützt, so kann die entsprechende Feature-Einstellung nicht umgestellt werden. Der Host kann dies durch Prüflesen der vorgenommenen Einstellung kontrollieren.

Vom Knoten selbst dürfen Features nur beim Power-Up verändert werden. Der PC liest Features einmalig ein und geht dann davon aus, dass die Hardware diese gemeldeten Eigenschaften hat.

Das Beantworten von Featurenachrichten ist für Knoten verpflichtend, Features selbst jedoch nicht. Die ID's für bestimmte Featureeinstellung sind verpflichtend. Nicht vergebene Feature-IDs sind reserviert. Erweiterungen der Features (neue ID's) sind zuvor beim Arbeitskreis BiDiB zu beantragen.

Ein vollständige Liste aller Feature-IDs ist in der Datei bidib_messages.h enthalten.

4.2.1. Downlink: Nachrichten für das Abfragen oder Setzen von Feature-Einstellungen

• MSG_FEATURE_GETALL:

  Mit dieser Nachricht beginnt die Abfrage aller Featurewerte. Es folgt optional ein Byte, welches dem Knoten signalisiert, dass der Host das Streaming der Featurewerte wünscht. Der Knoten setzt intern den Zähler für die MSG_FEATURE_GETNEXT-Abfragen zurück und antwortet mit der Nachricht MSG_FEATURE_COUNT, welche die Anzahl der vorhandene Features angibt. Ist diese Anzahl 0, hat der Knoten keine Features.

  Hat der optionale Parameter den Wert 1, signalisiert dies dem Knoten dass er selbständig mit dem Senden der Feature-Nachrichten beginnen soll ohne auf MSG_FEATURE_GETNEXT-Abfragen zu warten. Der optionale Parameter mit dem Wert 0 signalisiert, dass der Host das Streaming der Featurewerte nicht wünscht. Die Werte 2..255 sind reserviert.
  Die Unterstützung dieser Funktionalität ist optional, wird aber für Knoten ab ausgewiesener Protokollversion 0.8 empfohlen.

• MSG_FEATURE_GETNEXT:

  Mit dieser Nachricht wird ein Featurewert abgefragt. Es folgt kein Byte. Die Antwort besteht entweder aus einer MSG_FEATURE (wobei der Knoten selbst das jeweils nächste FEATURE auswählt und sendet) oder aus einer MSG_FEATURE_NA Nachricht (mit feature_num = 255), wenn bereits alle Features übermittelt wurden.

• MSG_FEATURE_GET:

  ein einzelnes Feature abfragen. Es folgt ein Byte mit der Featurenummer, welche abgefragt wird.

  Der Knoten antwortet mit einer MSG_FEATURE.

• MSG_FEATURE_SET:

  ein einzelnes Feature einstellen. Es folgen zwei Bytes: Featurenummer, Wert.

  Der Knoten antwortet mit einer MSG_FEATURE als Bestätigung. Sollte ein Wert übermittelt worden sein, welcher nicht einstellbar war, wird der tatsächlich eingestellte Wert zurückgesendet.

Die Kodierung der Feature-Sets für die jeweiligen Klassen ist den Dokumentationen der einzelnen Klassen zu entnehmen.

Wenn ein Knoten mit einer Feature-ID angesprochen wird, und dieses Feature am Knoten nicht bekannt ist, so wird eine MSG_FEATURE_NA (=feature not available) zurückgesendet.

4.2.2. Uplink: Nachrichten für Featuremitteilungen

Für die Antwort einer Featureabfrage werden folgende Nachrichtentypen verwendet:

• MSG_FEATURE:

  es folgt eine Byte mit der Feature-Nummer und ein Byte mit dem Wert. Logische Features sind bei 1 aktiviert, bei 0 deaktiviert.

• MSG_FEATURE_NA:

  Diese Nachricht wird gesendet, wenn ein Feature angefragt wurde, das auf diesem Knoten nicht verfügbar ist. Es folgt ein Byte mit der (nicht implementierten) Feature-Nummer.

  Ebenso wird diese Nachricht (mit Feature-Nummer 255) gesendet, wenn bei einer Reihenabfrage mit MSG_FEATURE_GETNEXT bereits alles übermittelt wurde.

• MSG_FEATURE_COUNT:

  Diese Nachricht wird vor der Übertragung gesendet, wenn der Host mit MSG_FEATURE_GETALL angefragt hat. Es folgt ein Byte mit der Anzahl der vorhandenen Features und optional ein Byte zur Ankündigung des Übertragungsmodus.

  Das Modus-Byte wird mit dem Wert 1 übertragen, wenn der Host Streaming angefordert hat und es vom Knoten unterstützt wird. Der Knoten beginnt selbständig mit dem Senden der MSG_FEATURE, wobei er selbst für die Datenflusskontrolle verantwortlich ist und auch während einer laufenden Übertragung voll abfragbar bleibt. Mit der Anzahl kann der Host kontrollieren, ob alle Feature-Nachrichten eingetroffen sind.

  Andernfalls werden die Feature-Werte einzeln mit einer Reihe von MSG_FEATURE_GETNEXT abgeholt. Mit der Anzahl kann der Host eine entsprechende Anzahl von Anfragen stellen.

4.3. Nachrichten zur Userkonfiguration

Es gibt fallweise herstellerspezifische Parameter, welche über die normale Konfiguration hinausgehen. Für diese wird seitens des Protokoll nur die Übertragungstechnik definiert, Parameterbezeichnung, -inhalt und -bedeutung sind Sache des Herstellers.

Vendor-spezifische Datenübertragungen dürfen nicht für Steuer-, Rückmelde- und sonstige Befehle verwendet werden, für die es im normalen Protokoll ein Pendant gibt.

Bevor diese Parameter übertragen werden, muss der entsprechende Knoten mit seiner UNIQUE-ID aktiviert werden. Zwischen VENDOR_ENABLE und VENDOR_DISABLE sind keine anderen Nachrichten außer VENDOR_** zulässig. Erst nachdem der Knoten MSG_VENDOR_DISABLE bestätigt hat, sind Zugriffe auf diesen Knoten wieder erlaubt.

4.3.1. Downlink: Nachrichten zur Userkonfiguration

• MSG_VENDOR_ENABLE:

  Es folgen 7 Bytes der zuvor ausgelesenen UNIQUE-ID. Der Knoten antwortet mit MSG_VENDOR_ACK.

• MSG_VENDOR_DISABLE:

  Es folgen keine weiteren Daten; der Knoten ist wieder deaktiviert. Der Knoten antwortet mit MSG_VENDOR_ACK.

• MSG_VENDOR_SET:

  Es folgen Daten, die wie folgt aufgebaut sind:

  VENDOR_DATA ::= V_NAME  V_VALUE
  V_NAME ::= LENGTH  V_NAME_STR
  V_NAME_STR ::= V_NAME_CHAR | V_NAME_CHAR  V_NAME_STR
  V_VALUE ::= LENGTH  V_VALUE_STR
  V_VALUE_STR ::= ε | V_VALUE_CHAR V_VALUE_STR

  Der Knoten speichert den Parameterwert in seiner Konfiguration, sofern ihm der Schlüssel (V_NAME) bekannt ist. Er antwortet mit einer MSG_VENDOR Nachricht, diese enthält denselben V_NAME und den gespeicherten Wert. Tritt bei der Verabeitung ein Fehler auf, kann der gespeicherte Wert von dem in MSG_VENDOR_SET übertragenen Wert abweichen, in der Regel wird dann der vorherige Wert beibehalten.

• MSG_VENDOR_GET:

  Es folgen Daten, die wie folgt aufgebaut sind:

  V_NAME ::= LENGTH  V_NAME_STR
  V_NAME_STR ::= V_NAME_CHAR | V_NAME_CHAR  V_NAME_STR

  Der Knoten antworten mit einer MSG_VENDOR Nachricht, diese enthält denselben V_NAME und den gespeicherten Wert dieses Parameters. Ist der Schlüssel (V_NAME) dem Knoten nicht bekannt, so antwortet der Knoten mit dem leeren Wert (V_VALUE = 0x00 "").

Die Knotenkonfiguration wird wie ein assoziatives Feld (Schlüssel-Wert-Paare) behandelt. V_NAME und V_VALUE sind ASCII-Folgen, damit kann eine Nutzereingabe direkt an den Knoten weitergereicht werden. Wenn die Folge aus Ziffern 0…9 besteht, so handelt es sich um einen numerischen Wert. Die Schlüssel (V_NAME) sollen in der Regel mit einem Buchstaben beginnen. Das Prinzip ist vergleichbar mit den Einträgen in einer Ini-Datei.

Es wird empfohlen, sprechende Namen für die Parameter und ihre Werte zu verwenden, sich dabei aber auf etwa 32 Bytes Gesamtlänge zu beschränken. Ein hartes Limit ist durch die Paketgröße gegeben, bei maximaler Nachrichtenlänge von 64 Bytes bleiben 55 Bytes für die beiden Strings V_NAME_STR und V_VALUE_STR.

Mit numerischen Werten für V_NAME und V_VALUE wird die klassische CV-Programmierung emuliert, der Adressbereich wird (wie in Dekoderbeschreibungen üblich) bei 1 beginnend gezählt. V_NAME = 0x01 "0" ist unzulässig.

• MSG_STRING_SET:

  Senden eines Strings an den Knoten. Es folgen weitere Bytes, welche den angesprochenen Namensraum, den angesprochenen Identifier (zu setzende Variable, Kanal) und den String selbst angeben.

  Diese Funktion ist im Knoten nur verfügbar wenn vom entsprechenden Feature angekündigt.

  MSG_STRING_SET Parameter

  Parameter	Beschreibung
  NAME_SPACE	bezeichnet den Namensraum innerhalb des Knotens, Wertebereich 0…255 0: String-Variablen im Knoten allgemein 1: Debug-Streams 2: Textausgabe für Accessories, über Aspect anwählbar wo BIDIB_ACCESSORY_PARA_USES_STRINGS = 1 3…255: reserviert
  STRING_ID	bezeichnet den angesprochenen String innerhalb des Namensraumes. Namensraum 0: STRING_ID = 0: Produktname, readonly, vom Hersteller vorgegeben. STRING_ID = 1: Knotenname, read/write, vom Anwender einstellbar (daher auch "Username"). STRING_ID = 2…255: reserviert Namensraum 1 (im Downstream, MSG_STRING_SET): STRING_ID = 0: Standard Input eines Textterminal. STRING_ID = 1…255: reserviert Namensraum 1 (im Upstream, MSG_STRING): STRING_ID = 0: Standard Output, als Reaktion auf Stdin-Eingaben. STRING ID = 1: Standard Error, als Reaktion auf Stdin-Eingaben. Unabhängig vom Terminal auftretende Fehler werden normal als Knotenfehler mit MSG_SYS_ERROR gemeldet. STRING ID = 2: Logmeldungen mit Warning-Level STRING ID = 3: Logmeldungen mit Info-Level STRING ID = 4: Logmeldungen mit Debug-Level STRING ID = 5: Logmeldungen mit Trace-Level STRING_ID = 6…255: reserviert Namensraum 2: STRING_ID = 0: Default-Anzeige (zum Beispiel leerer String) STRING_ID = 1…N: weitere Texte, die als Accessory-Aspekt zur Anzeige auswählbar sind (siehe BIDIB_ACCESSORY_PARA_USES_STRINGS) STRING_ID = 255: kommaseparierte Liste, beginnend mit Anzahl verfügbarer Einträge (max. 128) und maximaler Länge pro String jeweils als Dezimalstring kodiert; weitere Parameter können folgen. Der String ist typischerweise nicht schreibbar.
  SIZE	bezeichnet die Stringlänge. 0: String nicht existent. 1…127: Anzahl der Zeichen.
  CHARS	String, kodiert im Zeichensatz ISO 8859-1 (reiner 8-Bitcode). Das Byte 0x00 darf im String nicht vorkommen.

  Der Knoten antwortet (bei Namensraum 0 und 2) mit MSG_STRING und dem neu gespeicherten Wert. Ist der geschriebene String länger als zulässig, wird er vom Knoten gekürzt oder die Nachricht wird mit BIDIB_ERR_PARAMETER abgelehnt. Wenn die Antwort für einen String die Size 0 ergibt, so existiert der String nicht.

  Hinweise zum Namensraum 0:

  Das FEATURE_STRING_SIZE legt fest, wie lang die Zeichenfolgen im Knoten max. sein können. Aus Rücksicht auf die Darstellung in Hostprogrammen ist das auf eine max. Länge von 8 bis 24 Zeichen beschränkt. Existiert das FEATURE_STRING_SIZE nicht (oder hat den Wert 0), so kann der Knoten nicht mit Strings umgehen.

  Der Knoten antwortet jeweils mit MSG_STRING und dem neu gespeicherten Wert. Wenn die Antwort auf einen String die Size 0 ergibt, so existiert der String nicht.

  Vom Anwender veränderliche Strings (z. B. Knotenname) sind bei Auslieferung mit ' ' (= Leerzeichen) und einer Länge 1 vorzubelegen. Damit sind Hostprogramme in der Lage, leicht zwischen Auslieferungszustand und 'bereits benutzerkonfiguriert' zu unterscheiden.

  Der STRING 1 ist ein Kurzname für den Knoten, welcher der Anwender vergibt, z. B.: HBF-links-Signale.

  Hinweise zum Namensraum 1:

  Das FEATURE_STRING_DEBUG legt fest, wie der Namensraum 1 benutzt wird. Hat es den Wert 1, kann der Knoten ein einfaches Textterminal bereitstellen und MSG_STRING-Nachrichten für Debugausgaben auf verschiedenen Kanälen verwenden. Existiert das Feature nicht oder hat den Wert 0, sind Debugausgaben abgeschaltet.

  Jeder Kanal stellt einen Textstream aus UTF8-Bytes dar, die übertragenen Zeichen aus jeder Nachricht werden aneinandergehängt. Beispiel: Eine Folge von MSG_STRING 1 0 3 "abc", MSG_STRING 1 0 3 "def" wird also genauso interpretiert wie eine MSG_STRING 1 0 6 "abcdef".
  Als Trennzeichen wird der Zeilenumbruch \n verwendet. So lassen sich auch lange Ein- und Ausgaben transportieren, die Darstellung mehrerer Kanäle kann zeilenweise erfolgen. Ein Sequenzfehler in der Übertragung soll wie ein Zeilenumbruch behandelt werden.

  Der Sender soll dabei die maximal sinnvolle Nachrichtenlänge ausnutzen, um Overhead zu vermeiden. Auf MSG_STRING_SET oder MSG_STRING_GET wird keine Antwort erwartet, es kann aber Knoten geben die mit einem leeren String antworten. Die Ausgaben per MSG_STRING werden als Spontannachrichten behandelt. Für die Pufferung ist der Knoten verantwortlich, eine Flut von Lognachrichten soll andere Upstreamnachrichten nicht blockieren. Mit der eingeschränkt verfügbaren Bandbreite soll verantwortungsvoll umgegangen werden.

  Die Befehlsyntax auf dem Terminal ist frei wählbar, Eingaben dürfen vom Knoten beliebig ignoriert werden. Die Auswahl der Logausgaben kann hartkodiert werden (z.B. beim Debugging während des Entwicklungsprozesses) oder dynamisch über die Eingabe erfolgen.

  Für die Übertragung von Binärdaten dient das Update-Protokoll.

  Hinweise zu Namensraum 2:

  Das Bit 2 des FEATURE_STRING_NAMESPACES_AVAILABLE legt fest, ob der Namensraum 2 verfügbar ist und insbesondere dessen STRING_ID 255.

  Um mit MSG_STRING_SET dynamisch den Text je Accessory setzen zu können, sollte es mindestens so viele Texteinträge geben wie Accessories, damit man jedem Accessory einen festen Index zuordnen und den entsprechenden Begriff zuweisen kann.

  Die Speicherung erfolgt flüchtig im RAM, die beim Knotenstart verfügbaren Werte können jedoch konfigurierbar sein.

• MSG_STRING_GET:

  Abfragen einer Stringvariable im Knoten. Es folgen weitere Bytes, welche den angesprochenen Namensraum und den angesprochenen Identifier angeben.

  Diese Funktion ist im Knoten nur verfügbar wenn vom entsprechenden Feature (FEATURE_STRING_SIZE, FEATURE_STRING_NAMESPACES_AVAILABLE) angekündigt.

  Der Knoten antwortet mit einer MSG_STRING die den abgefragten String enthält. Sofern ein String nicht existiert, wird SIZE = 0 zurückgegeben.

4.3.2. Uplink: Nachrichten für Userconfig

Für die Antwort einer Userconfig wird folgender Nachrichtentyp verwendet:

• MSG_VENDOR:

  Es folgen Daten, die wie folgt aufgebaut sind:

  VENDOR_DATA ::= V_NAME  V_VALUE
  V_NAME ::= LENGTH  V_NAME_STR
  V_NAME_STR ::= V_NAME_CHAR | V_NAME_CHAR  V_NAME_STR
  V_VALUE ::= LENGTH  V_VALUE_STR
  V_VALUE_STR ::= ε | V_VALUE_CHAR  V_VALUE_STR

• MSG_VENDOR_ACK:

  Es folgt ein Datum: 0: kein Userconfig-Mode, 1: Bestätigung, dass der Knoten im Userconfig-Mode ist.

• MSG_STRING:

  Diese Nachricht ist die Antwort auf eine MSG_STRING_SET oder MSG_STRING_GET. Im Namensraum 1 kann die Nachricht auch spontan gesendet werden, wenn dies freigegeben ist.

  Es folgen weitere Bytes, welche den angesprochenen Namensraum, den angesprochenen Identifier, die Stringlänge und den String selbst angeben. Reihenfolge und Format der Parameter entsprechen MSG_STRING_SET, zur Bedeutung siehe dort.

4.4. Firmware-Updates

Ein Modul kann nach einen Firmwareupdate seine Unique-ID wechseln, es sind auch Module möglich, welche zu Beginn nur Firmware-Update beherrschen. In diesem Fall melden sie sich normal an, es sind jedoch alle Class-Bits auf Null gesetzt.

4.4.1. Ablauf eines Firmware-Updates

Für eine Fehlerbehebung oder das Nachrüsten neuer Funktionen ist es wünschenswert, dass Knoten die Fähigkeit zum Update ihrer Software haben. Ob und wie die Software eines Knotens aktualisiert werden kann, wird durch ein Feature festgelegt.

Im folgenden ist der Ablauf für FEATURE_FW_UPDATE_MODE = 1 exemplarisch dargestellt:

1. Der Host sendet an den Node die Nachricht, dass ein Firmware-Update erfolgen soll. (MSG_FW_UPDATE_OP, Parameter BIDIB_MSG_FW_UPDATE_OP_ENTER) Diese Nachricht enthält zur Sicherheit die Unique-ID des Nodes. Ab diesem Zeitpunkt sind keinerlei sonstigen Befehle mehr erlaubt, der Node geht in einen eingeschränkten Mode, im dem nur Firmware-Update-Befehle ausgewertet werden.
2. Der Node sendet eine 'Ready'-Nachricht, mit der er anzeigt, dass er bereit zum Empfang der Firmware ist.
3. Der Host sendet eine Nachricht, welche den Typ bzw. Zielspeicher der folgenden Firmware angibt – z. B. Inhalt des Flash-Speichers.
4. Der Node quittiert den Empfang und zeigt an, dass er die Datensätze erwartet.
5. Der Host liest die Intel-Hex-Datei (wird vom Hersteller des Nodes bereitgestellt) ein und sendet diese Zeile für Zeile an den Node. Die Übertragung erfolgt direkt im ASCII-Format. Beim Erzeugen der Hex-Datei ist die max. Nachrichtenlänge zu beachten, die Hex-Records sind z. B. in Größe 16 Bytes je Zeile zu formatieren.
6. Der Node quittiert den Empfang jeder Zeile und zeigt damit an, dass er bereit für weitere Datensätze ist. Erst nach der Quittung darf der Host die nächste Zeile senden.
7. Als letztes sendet der Host eine Nachricht, dass die letzte Zeile übertragen wurde und eventuelle Fragmente noch in den Speicher geschrieben werden sollen.
8. Der Node sendet eine 'Ready'-Nachricht und ist wieder bereit, ein weiteres Firmware-Paket entgegen zu nehmen.

Am Ende des Firmwareupdates sendet der Host ein Kommando zum Reboot bzw. Exit. Der Node quittiert diese Nachricht, wartet dann 1s (damit meldet ihn das Interface ab), startet dann neu und wird automatisch neu angemeldet. Es wird empfohlen, durch Maßnahmen innerhalb der Firmware (z. B. CRC-Prüfung beim Start), die vollständige und korrekte Übertragung der Firmware zu prüfen.

Da sich der Knoten nach dem FW-Update neu anmeldet, hat er keine Kenntnis über den Systemzustand (ob Spontanmeldungen erlaubt sind oder nicht) und sendet keine Spontanmeldungen. Fallweise muss man (wie auch bei jedem anderen neuen Knoten) eine entsprechende MSG_SYS_ENABLE an den neuen Knoten senden.

4.4.2. Features für FW-Update

Zielspeicherbereiche:

Je nach Implementierung des Nodes können dort unterschiedliche Zielspeicherbereiche vorhanden sein: z. B. Flash, EEPROM, usw. Für jeden dieser Zielspeicherbereiche gibt es ein Updatefile vom Hersteller.

Für Updatefiles ist ein einheitliches Namensschema festgelegt:

xyz_occupancydetector_v1_23f.000.hex
xyz_occupancydetector_v1_23f.001.hex

4.4.3. Downlink: Nachrichten für FW-Update

Während eines Firmware-Updates wird der Node in einen Zustand mit eingeschränkter Funktionaltät versetzt (=Update-Mode). Im Update-Mode wird die normale Funktion eingestellt (z. B. keine Gleisausgabe, keine Erkennung, keine Interface-Funktion), es dürfen im Update-Mode keine anderen Befehle mehr an den Node gesendet werden.

Auch gilt ein strenges Quittungsverfahren: jede Nachricht des Hosts muss von Node quittiert werden, erneute Nachrichten dürfen nur gesendet werden, wenn die Quittung der vorherigen Nachricht vorliegt. (Grund hierfür sind fallweise Speicherzeiten, in denen der Node den Programmspeicher beschreibt und daher nicht in der Lage ist, normalen Programmcode auszuführen.)

• MSG_FW_UPDATE_OP:

  Es folgen ein weiteres Byte, welche die durchzuführende Operation angibt. Abhängig von diesem Byte können weitere Parameter folgen.

  Der Node antwortet jeweils mit einer MSG_FW_UPDATE_STAT.

  Kodierung des Firmwareupdate-Operationstyps

  Wert	Name	Bedeutung
  0x00	BIDIB_MSG_FW_UPDATE_OP_ENTER	Node soll in den Update-Modus wechseln. Es folgen 7 Byte mit der Unique-ID des Nodes. Nur wenn die Unique-ID mit der des Nodes übereinstimmt, darf der Node in den Update-Mode wechseln. Der Node antwortet mit einer MSG_FW_UPDATE_STAT(BIDIB_MSG_FW_UPDATE_STAT_READY), falls er im Bootloader ist, bzw. mit einer MSG_FW_UPDATE_STAT(BIDIB_MSG_FW_UPDATE_STAT_EXIT), falls er nicht in den Bootloader wechseln konnte.
  0x01	BIDIB_MSG_FW_UPDATE_OP_EXIT	Node soll den Update-Modus verlassen.
  0x02	BIDIB_MSG_FW_UPDATE_OP_SETDEST	Auswahl Zielspeicher. Mit diesem Befehl wird der Zielbereich festgelegt, in welchem die folgenden Daten gespeichert werden sollen. Es folgt ein Byte mit der Nummer des Zielbereiches. Der Knoten antwortet mit einer MSG_FW_UPDATE_STAT(BIDIB_MSG_FW_UPDATE_STAT_DATA). 0: Flash (Applikation) 1: EEPROM
  0x03	BIDIB_MSG_FW_UPDATE_OP_DATA	Daten: Für den aktuell gewählten Zielspeicher wird eine Dateneinheit gesendet. Die Daten werden als Zeile einer Intel-Hex-Datei übertragen. 'White'-Charakters (also 0x20, 0x09, 0x0D und 0x0a) werden dabei nicht mit übertragen.
  0x04	BIDIB_MSG_FW_UPDATE_OP_DONE	Für den aktuell gewählten Zielspeicher sind keine weiteren Daten mehr vorhanden, Node soll den Update des Zielspeichers durchführen. Der Node antwortet mit einer MSG_FW_UPDATE_STAT(BIDIB_MSG_FW_UPDATE_STAT_READY).

4.4.4. Uplink: Nachrichten für FW-Update

• MSG_FW_UPDATE_STAT:

  Nach einem MSG_FW_UPDATE_OP Befehl wird immer eine Statusnachricht gesendet. Es folgen zwei Bytes:

  MSG_FW_UPDATE_STAT Parameter

  Parameter	Beschreibung
  STATUS	Prozess-Status Kodierung des Firmwareupdate-Operationsstatus Wert Name Bedeutung 0x00 BIDIB_MSG_FW_UPDATE_STAT_READY Node ist im Update-Modus, betriebsbereit. 0x01 BIDIB_MSG_FW_UPDATE_STAT_EXIT Node verlässt den Update-Modus. Der Node bestätigt diese Nachricht und meldet sich von seiner übergeordnete Struktur ab (z. B. durch eine hinreichend lange Wartezeit am BiDiBus). Anschließend führt er einen Reset durch und meldet sich neu an. 0x02 BIDIB_MSG_FW_UPDATE_STAT_DATA Node erwartet (weitere) Daten. 0x255 BIDIB_MSG_FW_UPDATE_STAT_ERROR Node hat einen Fehler festgestellt und den aktuellen Vorgang abgebrochen. Er verbleibt im vorherigen Zustand.
  TIMEOUT bzw. ERROR	Nach erfolgreicher Ausführung gibt das Byte die vom Host mindestens einzuhaltende Zeit an, bis das nächste Paket gesendet werden darf: Wert Bedeutung 0 Die nächste Nachricht an den Node darf sofort versendet werden. 1…255 Die nächste Nachricht an den Node soll erst nach einer Pause gesendet werden. Der Wert gibt deren Länge in Einheiten von 10ms an. Im Fehlerfall (STAT_ERROR) gibt das Byte einen Fehlercode an: Wert Name Bedeutung 1 BIDIB_FW_UPDATE_ERROR_NO_DEST Zielspeicherbereich nicht vorhanden. 2 BIDIB_FW_UPDATE_ERROR_RECORD Fehler im Record (z. B. ungültige Zeichen). 3 BIDIB_FW_UPDATE_ERROR_ADDR Record außerhalb des Speichers. 4 BIDIB_FW_UPDATE_ERROR_CHECKSUM Prüfsummenfehler im Hex-Record. 5 BIDIB_FW_UPDATE_ERROR_SIZE Record zu groß. 6 BIDIB_FW_UPDATE_ERROR_APPCRC CRC Fehler auf Applikation, Firmware nicht gestartet.

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

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

  Wert	Name	Bedeutung
  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

  Parameter	Beschreibung
  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 Bit Bedeutung 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…4 reserviert
  DATA1	Bitfeld Ausgabe Aktiv Für Formate DCC14, DCC28, DCC128 Bit Bedeutung 0 0: keine Geschwindigkeit ausgeben 1: Geschwindigkeit ausgeben 1 0: F0,F1…F4 nicht ausgeben 1: F0,F1…F4 ausgeben 2 0: F5…F8 nicht ausgeben 1: F5…F8 ausgeben 3 0: F9…F12 nicht ausgeben 1: F9…F12 ausgeben 4 0: F13…F20 nicht ausgeben 1: F13…F20 ausgeben 5 0: F21…F28 nicht ausgeben 1: F21…F28 ausgeben 7…6 reserviert 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: ADDR_L, ADDR_H, DATA, TIME

  Der Zubehördekoder mit der Adresse [ADDR_H*256+ADDR_L] 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

  Parameter	Beschreibung
  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. Bit Bedeutung 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, ADDR_L, ADDR_H.

  MSG_LOCAL_ACCESSORY Parameter

  Parameter	Beschreibung
  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

  Parameter	Beschreibung
  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 Wert Name Bedeutung 0x00 BIDIB_CS_POM_RD_BLOCK PoM (standard CV 0…1023) 4-Byte-Block lesen (Railcom 1.2) 0x01 BIDIB_CS_POM_RD_BYTE PoM (standard CV 0…1023) Byte lesen 0x02 BIDIB_CS_POM_WR_BIT PoM (standard CV 0…1023) Bit schreiben 0x03 BIDIB_CS_POM_WR_BYTE PoM (standard CV 0…1023) Byte schreiben 0x43 BIDIB_CS_XWR_BYTE1 Short Form CV Access 1 Byte schreiben 0x47 BIDIB_CS_XWR_BYTE2 Short Form CV Access 2 Byte schreiben 0x80 BIDIB_CS_xPOM_reserved XPoM (extended CV 24-Bit) reserviert 0x81 BIDIB_CS_xPOM_RD_BLOCK XPoM (extended CV 24-Bit) 4-Byte-Block lesen 0x82 BIDIB_CS_xPOM_WR_BIT XPoM (extended CV 24-Bit) Bit schreiben 0x83 BIDIB_CS_xPOM_WR_BYTE1 XPoM (extended CV 24-Bit) ein Byte schreiben 0x87 BIDIB_CS_xPOM_WR_BYTE2 XPoM (extended CV 24-Bit) zwei Bytes schreiben 0x8B BIDIB_CS_xPOM_WR_BYTE3 XPoM (extended CV 24-Bit) drei Bytes schreiben 0x8F BIDIB_CS_xPOM_WR_BYTE4 XPoM (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: Opcode Wert Bedeutung XWR_BYTE1 0b0010 Beschleunigungsanpassung, CV23:=DATA0 XWR_BYTE1 0b0011 Verzögerungsanpassung, CV24:=DATA0 XWR_BYTE1 0b1001 Service Mode Decoder Lock XWR_BYTE2 0b0100 lange Adresse, CV17:=DATA0, CV18:=DATA1, CV29.5=1 XWR_BYTE2 0b0101 Indexregister, 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 DID₄,DID₃,DID₂,DID₁,DID₀

• 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: ADDR_L, ADDR_H, STATE_L, STATE_H, DATA. Dabei kennzeichnet STATE die auszugebende DCC Nachricht.

  MSG_CS_BIN_STATE Parameter

  Parameter	Beschreibung
  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[, ADDR_L, ADDR_H].

  MSG_CS_QUERY Parameter

  Parameter	Beschreibung
  QUERY	ENUM der abgefragten Information und Abfragemodus: Bit Bedeutung 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

  Parameter	Beschreibung
  OPCODE	Byte, definiert die auszuführende Operation Wert Name Bedeutung 0x00 BIDIB_CS_PROG_BREAK Abbruch der laufenden Aktion 0x01 BIDIB_CS_PROG_QUERY Anfrage der Restzeit der laufenden Aktion 0x02 BIDIB_CS_PROG_RD_BYTE Byte Lesen 0x03 BIDIB_CS_PROG_RDWR_BIT Bit Abfragen/Schreiben 0x04 BIDIB_CS_PROG_WR_BYTE Byte 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

  Name	Bedeutung
  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,14 Bits 13…0 00 Lok-Adresse (kurzes Format bis einschließlich 127, lang ab 128; Wertebereich 1…59391) 10 (reserviert) 01 Accessory-Adresse (Wertebereich 0, 4, 8…2044) 11 Extended-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:

0. Quittung Ebene 0: Der Gleisausgabeknoten hat die Nachricht empfangen.
1. Quittung Ebene 1: Der Befehl wurde aufs Gleis ausgegeben.
2. 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.

• 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

  Parameter	Beschreibung
  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

  Parameter	Beschreibung
  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

  Parameter	Beschreibung
  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

  Parameter	Beschreibung
  ADDRL	Adresse, untere 8 Bits
  ADDRH	Adresse, obere 6 Bits
  DATA0	Bitfeld, Format
  DATA1	Bitfeld Ausgabe Aktiv
  DATA2	Geschwindigkeit
  DATA3	3*reserved, FL (Licht), F4, F3, F2, F1
  DATA4	F12 – F5
  DATA5	F20 – F13
  DATA6	F28 – F21

• MSG_CS_DRIVE_EVENT:

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

  MSG_CS_DRIVE_EVENT Parameter

  Parameter	Beschreibung
  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: Wert Bedeutung 0 kein Event vorliegend 1 LOST: 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

  Parameter	Beschreibung
  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 / normal Accessory: 0=normal, 1=extended 6 0: reserviert 5 Activate: 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

  Parameter	Beschreibung
  OPCODE	ENUM der abgefragten Information und Abfragemode: Bit Bedeutung 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

  Parameter	Beschreibung
  STATE	Ergebnis Wert Name Bedeutung 0x00 BIDIB_CS_PROG_START Dieser Status wird nach Erhalt des Programmierbefehls zurückgesendet. 0x01 BIDIB_CS_PROG_RUNNING Status während der Ausführung. RUNNING bei länger dauernden Vorgängen als Zwischenmeldung auf eine QUERY-Abfrage gesendet. 0x80 BIDIB_CS_PROG_OKAY Programmiervorgang erfolgreich. 0xC0 BIDIB_CS_PROG_STOPPED Der Programmiervorgang wurde abgebrochen, Ergebnis ist ungültig. 0xC1 BIDIB_CS_PROG_NO_LOCO Programmiervorgang beendet, es wurde kein Verbraucher am Gleis erkannt. 0xC2 BIDIB_CS_PROG_NO_ANSWER Programmiervorgang beendet, Programmierung wurde von Lok nicht bestätigt bzw. beim Lesen keine Reaktion der Lok. 0xC3 BIDIB_CS_PROG_SHORT Programmiervorgang beendet, Kurzschluss erkannt. 0xC4 BIDIB_CS_PROG_VERIFY_FAILED Programmiervorgang 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

  Parameter	Beschreibung
  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

  Wert		Bedeutung
  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

4.6. Accessory und Zubehör/Schaltfunktionen

BiDiB unterscheidet bei der Ansteuerung von stationären Modellbahnobjekten zwischen Funktionen der Klasse Accessory und Funktionen der Klasse Schaltanwendungen. Nur erstere werden für den sicheren Zugbetrieb eingesetzt, sie verfügen über die Möglichkeiten der Begriffsvorgabe, Lagerückmeldung und Fehlerbehandlung.

Für sekundäre Effekte und zur Konfiguration der Accessorys gibt es die einfachen Schaltfunktionen und Makros, welche die Ausgänge der Baugruppen direkt kontrollieren können.

4.6.1. Ansteuerung Fahrwegzubehör

Knoten können in der Lage sein, Weichen, Drehscheiben, Signale, Bahnübergänge und vieles mehr abzubilden, im Allgemeinen wird hier von 'Objekten' gesprochen. Knoten mit Ansteuerung solcher für den Fahrweg relevanten Objekte haben das Class-ID-Flag 'Accessory' gesetzt.

Accessory-Objekte haben jeweils einen 'Begriff' (=Aspect), den sie darstellen oder auf den sie schalten können. Typische Weichen haben z. B. 'Gerade' und 'Abzweig', aber im Sinne dieser Norm fallen auch Mehrwegweichen, Drehscheiben und Schiebebühnen unter diese Definition. Bei einer Drehscheibe ist der 'Begriff' dann der jeweilige Abgang. Der Zustand des Objektes wird allein vom Host kontrolliert und kann nicht durch fremde Einflüsse gestört werden kann. Von sich aus kann das Accessory nur in einen Fehlerzustand wechseln.

Wird ein neuer Begriff angewählt, nimmt das Objekt den entsprechenden Zustand ein. Dieser Schaltvorgang kann Zeit in Anspruch nehmen, ein Knoten meldet diese Stellzeit als Befehlsbestätigung und schickt eine weitere Zustandsmeldung nach Ende der Aktion. Tritt ein Problem auf, schickt der Knoten selbsttätig eine Fehlernachricht.

Es besteht die Möglichkeit, dass eine unvorhergesehene Zustandsänderung z. B. durch eine Handverstellung erfolgt. In diesem Fall sendet der Knoten spontan eine MSG_ACCESSORY_NOTIFY-Nachricht. Dieses spontane Senden muss sowohl durch 'SYS_ENABLE' als auch durch eine entsprechende Feature-Einstellung freigegeben sein.

MSG_ACCESSORY_NOTIFY wird auch zur Übermittlung von Zwischenberichten während der Ausführung verwendet. Diese können neben der zu erwartenden Restlaufzeit auch zusätzliche Information wie Drehwinkel enthalten.

Die Konfiguration des zu schaltenden Objektes hängt von dessen Ansteuerung ab, die Umsetzung obliegt dem Hersteller und kann je nach Baugruppe und Anwendungsfall (z. B. Magnetantrieb, Servo, Stepper, Lichtsignal, Formsignal, etc.) verschieden sein. Zur Verfügung stehen allgemein gehaltene Parameter, siehe MSG_ACCESSORY_PARA_SET, sowie die generischen Nachrichten zur Userkonfiguration. Darüberhinaus lassen sich Accessory-Operation auch auf Portbefehle (Schaltfunktionen) abbilden, wodurch sich die umfangreichen Möglichkeiten für die Konfiguration einzelner Ports nutzen lassen, siehe MSG_LC_CONFIGX_SET.

Ein Knoten teilt dem Host nur die Anzahl der Begriffe eines Accessorys mit, nicht um welche Art von Objekt es sich handelt. Diese Zuordnung ist Aufgabe des Steuerungsprogramms, eine Systematisierung würde den Rahmen des Protokolls sprengen und könnte keine Vollständigkeit erlangen.

Allerdings sind bei der Anordnung der Begriffe einige Vorgaben zu beachten. Der Begriff 0 soll immer die Ruhelage abbilden, bei Weichen also üblicherweise das Stammgleis. Bei Signalen muss der Begriff 0 auf die Stellung Halt abgebildet werden. Bei Drehscheiben, Schiebebühnen, Segmentscheiben usw. sind zwei unterschiedliche Geometrien zu beachten:

• Lineare Anordnungen (wie z. B. Segmentscheiben): Hier wird jeder anfahrbare Abgang der Reihe nach einem Begriff des Accessoryobjekts zugeordnet.
• Rotationssymmetrische Anordnungen (wie z. B. klassische Drehscheibe): Hier wird jeder anfahrbare Abgang einem Begriff des Accessoryobjekts zugeordnet, wobei die Begriffe von oben betrachtet im Uhrzeigersinn steigend angeordnet werden. Mit Position wird immer die gleiche Seite der Drehbühne (mit Häuschen) bezeichnet.
  Ein Abgang kann zwar anfahrbar, aber nicht benutzbar sein, das ist z. B. der Fall, wenn die Bühne so steht, dass das Häuschen gegenüber einem benutzbaren Abgang liegt. Eine solche Position ist 'passiv', wird aber ebenso in die Begriffliste aufgenommen. In welcher Position die Bühne wie befahren werden kann ist in der Hostsoftware festzulegen.
  Die Zahl der Begriffe ist zwingend gerade und jeweils zwei Begriffe liegen sich um 180° gegenüber.

Umfangreiche Objekte können auch über mehrere Accessorys angesteuert werden, ihr "mehrdimensionaler" Zustandsraum setzt sich aus den Begriffen der einzelnen Accessorys zusammen. Der Knoten bildet dann jedes Tupel aus der Produktmenge der Accessoryzustände auf seine Ausgänge ab. Alle Kombinationen sind möglich und anwählbar – es gibt keine ungültigen –, manche mögen sich aber dieselbe Bedeutung und Wirkung teilen. Die Zusammenstellung des Objekts aus den Accessorys erfolgt frei in der Hostsoftware.

Die Nachrichten an die verschiedenen Accessorys bleiben weiterhin unabhängig voneinander, ein Schalten eines Accessorys darf keine Seiteneffekte auf die anderen Begriffe haben. Der Einfachkeit halber kann ein Steuerungsprogramm immer die gesamte Begriffskombination senden. Es müssen dabei die Umlaufzeiten und Fehlerzustände aller Accessorys berücksichtigt werden.

Ein Spezialfall der kombinierten Ansteuerung von Objekten ist der Betriebsmodus. Hier wirkt sich der Zustand eines Accessorys auf die Bedeutung eines anderen Accessory-Zustandes aus. Diese Abhängigkeit ist mittels des BIDIB_ACCESSORY_PARA_OPMODE erkennbar. Dabei hat das Accessory für den Betriebsmodus zwei oder mehr Begriffe, die wie folgt definiert sind:

• Begriff 0 – "(Not)Halt": Das gesamte Objekt ist angehalten. Die Begriffe aller anderen Accessorys dieses Kompositums sind in diesem Modus irrelevant für den Gesamtzustand.
• Begriff 1 – "Normalbetrieb": Das Objekt ist im Einsatz und folgt den Begriffen der anderen Accessorys, ihr Zustand ist gültig. Nur in diesem Modus darf das Objekt durch die Steuerungssoftware befahren werden.
• Weitere Begriffe gelten jeweils als irregulärer Modus und sind so zu behandeln wie Begriff 0, d.h. der Zustand der anderen Accessorys ist ungültig und das Objekt darf nicht eingesetzt werden.
  Beispiele: Im Kalibrierungsmodus gleicht eine Schiebebühne ihre Bühnenposition mit einem Nulllagesensor ab, im Einstellungsmodus kann eine Drehscheibe von Hand verfahren werden.

Auch während ihr Zustand keine Auswirkungen auf das Objekt hat, können Accessorys weiter normal betätigt werden. Typischerweise wird das Objekt erst beim Wechsel in den Einsatzmodus die gewählten Begriffe annehmen. Bei einem Wechsel des Betriebsmodus muss daher wie üblich die Umlaufzeit beachtet werden.

4.6.2. Features für Accessory-Funktionen

Die Eigenschaften des Knotens sind mittels Feature-Abfragen feststellbar. Generell gilt: Feature Werte außerhalb des angegebene Wertebereichs sind reserviert.

Wenn per Feature eine bestimmte Zahl an Accessorys gemeldet werden, dann müssen diese auch implementiert und ansprechbar sein.

4.6.3. Downlink: Nachrichten für Accessory-Funktionen

• MSG_ACCESSORY_SET:

  Stellen eines Modellbahnzubehörs, es folgen 2 Bytes: ANUM, ASPECT. Diese beiden Bytes definieren das steuerbare Objekt und den darzustellenden Begriff.

  MSG_ACCESSORY_SET Parameter

  Parameter	Beschreibung
  ANUM	bezeichnet das Objekt innerhalb des Knotens, Wertebereich 0…127
  ASPECT	Dieses Byte beschreibt den Zustand des Objekts, 0 soll dabei den Ruhezustand darstellen. 254 versetzt das Modell in einen sicheren Zustand ("Nothalt"). Wertebereich 0…127, 254

  Der Knoten antwortet mit einer MSG_ACCESSORY_STATE. Sollte die Aktion länger als 100ms dauern, so wird sofort mit einer MSG_ACCESSORY_STATE geantwortet und dabei die prognostizierte Stellzeit übermittelt. Am Ende des Stellvorgangs erfolgt automatisch eine weitere MSG_ACCESSORY_STATE als Zeichen, dass der Stellvorgang abgeschlossen ist.

  SecureSwitch:

  Die Quittung des Knotens mittels MSG_ACCESSORY_STATE ist verpflichtend. Sie kann die Ausführungsbestätigung enthalten, eine Ankündigung einer Wartezeit oder eine Fehlermeldung. Bleibt sie aus, wird das Steuerungsprogramm das Accessory nicht benutzen und den Ausführungszustand nochmals explizit abfragen. Fallweise kann auch der MSG_ACCESSORY_SET-Befehl wiederholt werden.

  Wenn mit ANUM ein Objekt angesprochen wird, welches am Knoten nicht existiert, dann antwortet der Knoten mit einer MSG_ACCESSORY_STATE, Objektnummer 255, Aspect 255, Fehlercode 0x01. Die Zahl der möglichen Objekte kann mit einer Feature-Anfrage erfragt werden.

  Wenn mit ASPECT ein Begriff außerhalb des Bereiches dieses Objekts angesprochen wird, dann antwortet der Knoten mit einer MSG_ACCESSORY_STATE, Aspect = 255, Fehlercode 0x01.

• MSG_ACCESSORY_GET:

  Mit diesem Befehl wird der Zustand des Objektes abgefragt. Es folgt ein Byte: ANUM.

  Der Knoten antwortet mit MSG_ACCESSORY_STATE.

• MSG_ACCESSORY_GETALL:

  Mit diesem Befehl wird der Zustand aller Accessory-Objekte des Knoten abgefragt. Es folgen keine Parameter.

  Der Knoten antwortet mit einer MSG_ACCESSORY_STATE pro Objekt. Die Zahl der zu erwartenden Antworten entspricht dem FEATURE_ACCESSORY_COUNT.

  Der Knoten ist bei den Antwortnachrichten selbst für die Datenflusskontrolle verantwortlich und bleibt auch während einer laufenden ACCESSORY_GETALL-Übertragung voll abfragbar.

  Der Befehl ist ab ausgewiesener Protokollversion 0.8 verfügbar.

• MSG_ACCESSORY_PARA_SET:

  (optional)

  Mit diesem Befehl werden die Konfigurations-Parameter eines Accessory-Objektes eingestellt.

  Es folgen zwei oder mehr Bytes:

  MSG_ACCESSORY_PARA_SET Parameter

  Parameter	Beschreibung
  ANUM	bezeichnet das Objekt innerhalb des Knotens, Wertebereich 0…127
  PARA_NUM	Nummer des einzustellenden Parameters
  DATA[0…]	zu setzende Werte, abhängig vom Parameter

  Der Knoten antwortet mit MSG_ACCESSORY_PARA. Sollte der PARA_NUM am Objekt unbekannt sein, antwortet der Knoten mit einer PARA_NUM = BIDIB_ACCESSORY_PARA_NOTEXIST (=255) und dem unkannten Parameter.

  Kodierung der Accessorykonfigurations-Parameter

  Wert	Name	Bedeutung
  1-248	–	Reserviert.
  249	BIDIB_ACCESSORY_PARA_USES_STRINGS	Das Accessory ist für die Auswahl eines Strings zur Textanzeige auf einem Display zuständig, die Begriffe 0 bis TOTAL-1 entsprechen den Strings aus Namensraum 2 (Index 0 bis TOTAL-1). Es folgt ein weiteres Byte mit dem Wert 1. Der String-Namensraum 2 hat mindestens die Länge von TOTAL. Dieser Parameter ermöglicht es, für die betroffenen Accessorys ein entsprechendes Begriffsauswahlfeld anzubieten. Er ist typischerweise nicht schreibbar.
  250	BIDIB_ACCESSORY_PARA_HAS_ESTOP	Das Accessory unterstützt den Nothalt-Begriff. Es folgt ein weiteres Byte mit dem Wert 1. Ist der Parameter nicht vorhanden oder folgt ein anderer Wert, hat das Accessory keinen Nothalt implementiert und wird nur mit einer Fehlermeldung auf Nutzungsversuche reagieren. Der Parameter ist typischerweise nicht schreibbar.
  251	BIDIB_ACCESSORY_PARA_OPMODE	Das Accessory ist Teil eines zusammengesetzen Objektes mit einem Betriebsmodus. Es folgt ein weiteres Byte ANUM mit der Nummer des Accessoryobjektes, das den Betriebsmodus repräsentiert, Wertebereich 0…127. Der Parameter ist typischerweise nicht schreibbar. Der Wertebereich enthält keine Möglichkeit zur Trennung der Abhängigkeit, wo keine Abhängigkeit wirkt ist der gesamte Parameter nicht vorhanden.
  252	BIDIB_ACCESSORY_PARA_STARTUP	Verhalten des Accessorys während des Knoten(neu)starts. Es folgt 1 weiteres Byte mit folgender Bedeutung: 0…127: Der angegebene Aspect wird beim Knotenstart eingenommen. 254: Der Knoten stellt beim Start den letzten gesetzten Begriff wieder her. 255: Der Knoten unternimmt beim Start nichts. Falls eine Überwachung (Lagerückmeldung) vorhanden ist, soll der vorliegende Begriff angenommen werden, ansonsten "unbekannt" (255). Knoten, an denen der Parameter nicht vorhanden ist, sollen sich verhalten wie beim Wert 255. Falls eine Überwachung (Lagerückmeldung) vorhanden ist, kann bei Übereinstimmung mit dem Zielzustand (bei 0…127, 254) der Schaltvorgang entfallen. Ein Knoten darf (und sollte) anfallende Schaltvorgänge zeitlich strecken bzw. dynamisch verzögern, um Überlastungen beim Einschalten zu verhindern. Beantwortet er in dieser Zeit schon MSG_ACCESSORY_GET-Nachrichten, muss er jedoch eine Restzeit bis zum Einlaufen des Zustandes melden.
  253	BIDIB_ACCESSORY_PARA_MACROMAP	Zuordnung von Begriffen zu Makros. Jedem Begriff des Accessoryobjekts wird ein Makro zugeordnet. Es folgen weitere Daten, welche die Zuordnung definieren. DATA0: Nummer des Makros, welches bei Begriff 0 ausgeführt wird. DATA1: Nummer des Makros, welches bei Begriff 1 ausgeführt wird. DATA2: Nummer des Makros, welches bei Begriff 2 ausgeführt wird. usw. Die Liste darf max. 16 Einträge lang sein und nur gültige Macronummern enthalten. Die Liste wird mit einem Eintrag 255 beendet. Der Knoten übernimmt diese Liste bis zur max. Zahl von Begriffen. (siehe auch FEATURE_ACCESSORY_MACROMAPPED)
  254	BIDIB_ACCESSORY_SWITCH_TIME	Definition der Schaltzeit analog zur Spezifikation von railcom. Bit Bedeutung 7 Grundeinheit: 0: 100ms (d.h. Wertebereich 0…12,7s) 1: 1s (d.h. Wertebereich 0…127s) 6…0 Schaltzeit, Wertebereich 0…127
  255	BIDIB_ACCESSORY_PARA_NOTEXIST	(nur im Uplink) Der angefragte PARA_NUM ist am Knoten unbekannt oder existiert für dieses Accessory nicht. Ab Protokollversion 0.7 folgt ein Byte mit der Nummer des angefragten Parameters.

• MSG_ACCESSORY_PARA_GET:

  (optional)

  Mit diesem Befehl werden die Konfigurations-Parameter eines Accessory-Objektes abgefragt. Es folgen zwei Bytes: ANUM, PARA_NUM Der Knoten antwortet mit MSG_ACCESSORY_PARA.

4.6.4. Uplink: Nachrichten für Accessory-Funktionen

• MSG_ACCESSORY_STATE:

  Dieser Befehl teilt dem Host den Zustand des Accessory-Objektes mit. Diese Antwort wird gesendet nach einer Abfrage (MSG_ACCESSORY_GET), nach einem Stellbefehl (MSG_ACCESSORY_SET) oder spontan bei Erreichen des Zielzustandes.

  Es folgen 5 oder mehr Bytes:

  MSG_ACCESSORY_STATE Parameter

  Parameter	Beschreibung
  ANUM	bezeichnet das Objekt innerhalb des Knotens, Wertebereich 0…127. Bei ANUM=255 existiert das angefragte Objekt nicht.
  ASPECT	Dieses Byte beschreibt den aktuellen (bzw. während eines Wechsels: den geplanten) Zustand des Objekts, Wertebereich 0…127. Bei ASPECT=254 befindet sich das Objekt im Nothalt, sämtliche Bewegungen sind angehalten um Schäden an Modellen zu vermeiden. Bei ASPECT=255 ist der Zustand unbekannt. Dies entspricht normalerweise dem gesetzten Zustand, solange kein Fehler vorliegt.
  TOTAL	Dieses Byte gibt an, wie viele mögliche Zustände (=ASPECT) das Objekt hat. Begriffe werden immer bei 0 beginnend (ohne Lücke) angesprochen. Wertebereich 0…128. Beispiele: Standardweiche: 2 Zustände: 0 und 1 Signal mit Hp 0, Hp 1, Hp 2: 3 Zustände: 0, 1 und 2 Unterstützt ein Objekt den Nothalt-Zustand, muss dies im Parameter HAS_ESTOP angegeben werden. Anmerkung: wenn ein Accessory den Wert TOTAL mit 0 zurückliefert, dann sind da keine Begriffe vorhanden und es kann nichts geschaltet werden. Das kann z. B. bei Macro-basierten Accessory der Fall sein, wenn keine Macros zu Begriffen hinterlegt sind.
  EXECUTE	Dieses Byte gibt an, wie der aktuelle Stand der Ausführung ist, also ob die Aktion schon beendet ist, ob sie überwacht wird und ob evtl. ein Fehler aufgetreten ist: Bitfeld: Bit 7 Bedeutung 0 normale Operation Bit Bedeutung 0 0: Zielzustand erreicht. WAIT ist 0. 1: Zielzustand noch nicht erreicht. WAIT gibt die angenommene Restdauer an. 1 0: Zielzustand wird durch Rückmeldung (z. B. Schaltkontakt) verifiziert. 1: keine Kontrolle des Zielzustandes vorhanden. 6…2 reserviert, mit 0 zu belegen 1 Fehler aufgetreten (z. B. Ausfall Spule / Handverstellung); WAIT gibt in diesem Fall die Ursache gemäß railcom-Spec an. Bit Bedeutung 6…0 reserviert, mit 0 zu belegen Falls ein Fehler aufgetreten ist, bleibt der zuletzt gemeldete Ausführungsstatus (Ziel erreicht bzw. im Umlaufen begriffen) fortbestehen.
  WAIT	normale Operation: Wenn der Zielzustand eingelaufen ist, wird hier 0 gemeldet. Wenn der Zielzustand noch nicht eingelaufen ist, wird hier die angenommene Restzeit wird gemäß Railcom-Spec angegeben: Bit Bedeutung 7 Grundeinheit: 0: 100ms (d.h. Wertebereich 0…12,7s) 1: 1s (d.h. Wertebereich 0…127s) 6…0 Schaltzeit, Wertebereich 0…127 bei Fehlermeldung: Es wird die Fehlerursache übermittelt: Bit Bedeutung 7 reserviert, mit 0 zu belegen 6 0: Es liegt nur der in den folgenden 6 Bits angegebene Fehler vor. 1: Es liegen neben dem angegebenen noch weitere Fehler vor, die in folgenden Nachrichten gemeldet werden. 5…0 0x00 Kein Fehler (mehr). Bei gesetztem Bit 6 ist das Ende der Fehlerliste erreicht, mit der nächsten Nachricht wird wieder von vorn begonnen. 0x01 unbekanntes Objekt/ungültiger Aspect. Der empfangene Befehl konnte nicht ausgeführt werden und wird ignoriert. Der Fehlercode wird immer mit Aspect=255 übertragen, der vorherige Fehlerfall und Aspect bleiben aber bestehen. 0x02 Stromaufnahme des Antriebs zu hoch. 0x03 Versorgungsspannung zu gering, die Funktion ist nicht sichergestellt. 0x04 Sicherung defekt. 0x05 Temperatur zu hoch. 0x06 Rückmeldefehler (z. B. ungewollte Verstellung festgestellt, Schaltvorgang nicht erfolgreich). Der Fehlercode wird gegebenenfalls zusammen mit einem neuen Aspect, häufig 255 ("unbekannt"), übertragen. 0x07 Lokale Verstellung durch Anwender (z. B. per Taster am Decoder). Der Fehlercode wird gegebenenfalls zusammen mit dem neuen Aspect übertragen. 0x10 Weichenlaterne oder Signallaterne defekt 0x20 Servo defekt 0x3F Interner Decoderfehler, z. B. Selbsttest Prozessor Prüfsumme fehlerhaft. Ein Fehlerzustand, der mit einer Verstellung einhergeht (Ursachen 0x06 und 0x07), kann durch MSG_ACCESSORY_SET aufgehoben werden.
  DETAILS[0…40]	Optionale ergänzende Details zum aktuellen Stand der Accessory-Operation. Sie dienen der präziseren Verfolgung und Darstellung eines Accessories, sind aber nicht betrieblich relevant. Der Knoten entscheidet, welche Informationen er wann anfügt, sie lassen sich nicht gezielt abfragen. Übertragen werden sie als Liste aus bis zu 8 Schlüssel-Wert-Paaren, bestehend jeweils aus Parametertyp und -wert. DETAILS_LIST ::= ε | DETAIL_PAIR DETAILS_LIST DETAIL_PAIR ::= D_ENUM1 D_VALUE | D_ENUM2 D_VALUE[2] D_ENUM1 = 0x00 | … | 0x3F D_ENUM2 = 0x40 | … | 0x7F

  Kodierung der Zustandsdetail-Parameter

  Name	Code	Werttyp	Bedeutung
  BIDIB_ACC_DETAIL_CURR_ANGLE1DEG5	0x01	uint8	Aktueller Positionswinkel (etwa einer Drehscheibe) in Einheiten von 1,5 Grad, Wertebereich 0…239. Objekte mit einem einstellbaren Min/Max-Bereich (z.B. Schiebebühnen) melden die (Zwischen-)Position ebenfalls auf den Bereich 0…239 skaliert.
  BIDIB_ACC_DETAIL_TARGET_ANGLE1DEG5	0x02	uint8	Angezielter Positionswinkel am Ende der Bewegung, in Einheiten von 1,5 Grad, Wertebereich 0…239
  BIDIB_ACC_DETAIL_TIMESTAMP	0x40	uint16	Systemzeitstempel vom Moment der Lageerfassung

  Die spontane Meldung bei Abschluss des Stellvorgangs sendet der Knoten nur ab, wenn SYS_ENABLE gesetzt ist. Sie wird auch nicht vom Host quittiert. Der Zustand kann aber jederzeit (auch während des Stellvorgangs) per MSG_ACCESSORY_GET abgefragt werden, ein regelmäßiges Einlesen ist denkbar.

  Spontane Ereignisse außerhalb eines Stellvorgangs und Begriffswechsel werden mit MSG_ACCESSORY_NOTIFY gemeldet.

• MSG_ACCESSORY_NOTIFY:

  Dieser Befehl meldet dem Host den Zustand eines Accessory-Objektes. Die Nachricht wird bei einem spontanen Ereignis (z. B. Detailzustandsänderung, Handverstellung, Fehler) gesendet. Voraussetzung ist, dass sowohl SYS_ENABLE gesetzt ist und das Feature FEATURE_ACCESSORY_SURVEILLED auf 1 steht.

  Es folgen 5 oder mehr Bytes, diese sind identisch zu MSG_ACCESSORY_STATE kodiert.

  SecureSwitch:

  Der Empfang einer MSG_ACCESSORY_NOTIFY (mit WAIT=0) muss vom Hostprogramm mit einer Abfrage (MSG_ACCESSORY_GET) oder einem Befehl (MSG_ACCESSORY_SET) quittiert werden. Erfolgt dies nicht, darf der Knoten die Nachricht max. achtmal in einem zeitlichen Abstand von 500ms wiederholen.
  Ein Nachricht MSG_ACCESSORY_NOTIFY mit WAIT!=0 ist ein Zwischenbericht und braucht nicht quittiert zu werden.

  Im Falle einer Änderung des ASPECT kann dabei entweder der übermittelte "neue" Begriff übernommen werden oder versucht werden den bisherigen Begriff erneut zu aktivieren.

  Ist das Bit 6 im Feld WAIT gesetzt (d.h. es liegen noch weitere Fehler vor), dann sind diese Fehler mit einer weiteren (oder mehreren) MSG_ACCESSORY_GET Nachricht abzuholen bis Fehlercode 0x00 erreicht ist.

• MSG_ACCESSORY_PARA:

  (optional)

  Diese Nachricht wird als Antwort auf eine Abfrage oder Setzen von Konfigurations-Parametern gesendet.

  Es folgen zwei oder mehr Bytes: ANUM, PARA_NUM [Daten], diese sind wie beim Befehl MSG_ACCESSORY_PARA_SET kodiert.

4.6.5. Ansteuerung Zubehör / Schaltfunktionen

Knoten mit Schaltfunktionen können z. B. Lichtsteuerungen, Animationen (mit Bewegung) o.ä. sein. Auch Bedienpulte sind möglich, Knoten dürfen auch Tastereingaben haben. Knoten mit Schaltfunktion haben das Class-ID-Flag 'Schalten' gesetzt.

Knoten mit Schaltfunktionen haben einen oder mehrere Ein- und Ausgänge. Diese werden als 'Ports' angesprochen, jeder Port lässt sich individuell konfigurieren, abfragen und schalten.

Schaltfunktionen unterscheiden sich erheblich, je nach Art des Ausgangs: Hier gibt es reine Schaltausgänge, Lichtausgänge mit Dimm- oder Blinkfunktionen, Servos (mit Positionierung), Sounds, Analogspannungen usw. Für Ausgänge gibt es daher einen 'Ausführbefehl', mit dem eine Veränderung des Ausgangs angesteuert wird und einen Konfigurationsbefehl, mit welchem die Eigenschaften festgelegt werden.

Knoten können auch über die Fähigkeit verfügen, Ports in ihrer Funktion zu verändern. So kann beispielsweise ein Ausgang zu einem Eingang umkonfiguriert werden. Dies soll während der Konfigurationsphase des Knotens, nicht im operativen Einsatz geschehen. Die Umkonfiguration des Typs soll keine Auswirkungen auf die restlichen Konfigurationsparameter des Ports haben.

Ein Knoten kann überdies Makros unterstützen, diese optionale Fähigkeit bringt weitere Befehle und Konfigurationsmöglichkeiten mit:

• Zusammenfassen von Schaltfunktionen zu lokalen Makroabläufen
• Konfiguration dieser Makroabläufe (Ablaufgeschwindigkeit, Startbedingung)
• Konfiguration dieser Makroabläufe hinsichtlich der Ansteuerquelle (per Schaltbefehl, per Uhrzeit)

Für das Ansprechen von Ports gibt es ab Protokollversion 0.6 zwei verschiedene Adressierungsmodelle. Beide verwenden 2 Bytes, unterscheiden sich jedoch in der Anordnung der verfügbaren Ports im Adressraum.

Im typorientierten Portmodell finden nur Porttypen mit Breite 1 Verwendung. Andere Breiten kommen nur im flachen Portmodell zur Anwendung, wo je nach Typkonfiguration verschieden viele Ports zur Verfügung stehen können. Im typorientierten Modell können zwei Ausgänge mit exklusiver Ansteuerung auch als ein SWITCH-Port abgebildet werden.

4.6.6. Features für Schaltfunktionen

Die Eigenschaften der Knoten (wie z. B. die Anzahl der jeweiligen Ausgangsarten) sind mittels Feature-Abfragen feststellbar:

4.6.7. Downlink: Nachrichten für Schaltfunktionen

• MSG_LC_OUTPUT:

  Direkte Ausgangsoperation, es folgen 3 Bytes: PORT₀, PORT₁, PORTSTAT. Diese drei Bytes definieren den Ausgang und die Operation, welche auf diesem erfolgt.

  MSG_LC_OUTPUT Parameter

  Parameter	Beschreibung
  PORT[2]	Diese Bytes adressieren den Port
  PORTSTAT	Dieses Byte beschreibt den Zustand des Ports, die Bedeutung ist abhängig vom Typ des angesprochenen Ausgangs. Ausgangstyp Kodierung der Schaltbefehle 0 (=BIDIB_PORTTYPE_SWITCH) Normaler Schaltausgang, es gibt folgende Operationen: Wert Name Operation 0 BIDIB_PORT_TURN_OFF Ausgang AUS schalten 1 BIDIB_PORT_TURN_ON Ausgang EIN schalten 2-255 - reserviert 1 (=BIDIB_PORTTYPE_LIGHT) Schaltausgang für Lichtsteuerung, es gibt folgende Operationen: Wert Name Operation 0 BIDIB_PORT_TURN_OFF Ausgang direkt in die Helligkeit AUS schalten 1 BIDIB_PORT_TURN_ON Ausgang direkt in die Helligkeit EIN schalten 2 BIDIB_PORT_DIMM_OFF Ausgang in die Helligkeit AUS dimmen 3 BIDIB_PORT_DIMM_ON Ausgang in die Helligkeit EIN dimmen 4 BIDIB_PORT_TURN_ON_NEON Ausgang in die Helligkeit EIN mit Neonflackern einschalten 5 BIDIB_PORT_BLINK_A Ausgang blinkt mit etwa 1Hz, das blinken beginnt mit der Ein-Phase. Ein konfiguriertes Dimmen ist dabei aktiv. 6 BIDIB_PORT_BLINK_B Ausgang blinkt mit etwa 1Hz, das blinken beginnt mit der Aus-Phase. Ein konfiguriertes Dimmen ist dabei aktiv. 7 BIDIB_PORT_FLASH_A Ausgang blinkt mit etwa 3Hz, das blinken beginnt mit der Ein-Phase. 8 BIDIB_PORT_FLASH_B Ausgang blinkt mit etwa 3Hz, das blinken beginnt mit der Aus-Phase. 9 BIDIB_PORT_DOUBLE_FLASH Ausgang macht Doppelblitze, wiederholend (Einsatzfahrzeuge) Die Modi 5 und 6 sind für Bahnübergänge gedacht, die Modi 7 und 8 für Warnblinker. 2 (=BIDIB_PORTTYPE_SERVO) Servoausgang, PORTSTAT ist in diesem Fall die Zielposition des Servos. Dabei entspricht ein PORTSTAT von 0 dem unteren Anschlag, 255 dem oberen. Optional lassen sich die Anschläge konfigurieren (siehe unten), der maximale Einstellbereich soll eine Servopulsbreite von 0.5ms bis 2.5ms umfassen. Die Anschlagwerte sind hier weiter gefasst als die normierten 1ms bis 2ms, da sich Servos in der Realität oft über diesen Bereich hinaus ansteuern lassen. 3 (= BIDIB_PORTTYPE_SOUND) Soundfunktion, es gibt folgende Operationen: Wert Name Operation 0 BIDIB_PORT_TURN_OFF Abspielen beenden 1 BIDIB_PORT_TURN_ON Geräusch abspielen 2-255 - reserviert Mit BIDIB_PCFG_TICKS lassen sich Dauer-/Wiederholmodus und Momentaktivierung unterscheiden. 4 (= BIDIB_PORTTYPE_MOTOR) Motorfunktion, PORTSTAT gibt die Geschwindigkeit an. Die Kodierung entspricht DCC128: Das MSB kodiert die Drehrichtung: 1 = vorwärts, 0 = rückwärts Die LSBs (Bit 6…0) kodieren die 126-stufige Geschwindigkeit, wobei 0 = Halt und 1 = Nothalt bedeutet. 5 (= BIDIB_PORTTYPE_ANALOGOUT) Analogfunktion (genauere Definition folgt) 6 (= BIDIB_PORTTYPE_BACKLIGHT) Lichtfunktion, direkt dimmbar. PORTSTAT gibt die Helligkeit an, Bereich 0…255. 7 (=BIDIB_PORTTYPE_SWITCHPAIR) Abwechselnde Aktivierung von zwei Schaltausgängen, z. B. für Spulenantriebe. Es gibt folgende Operationen: Wert Name Operation 0 BIDIB_PORT_TO_0 Ersten Ausgang einschalten und zweiten aus. 1 BIDIB_PORT_TO_1 Ersten Ausgang ausschalten und zweiten ein. 2-255 - reserviert Vergleiche RCN 213, Beschreibung des R-Bits im Format für einfache Zubehörbefehle. Bei Standardanwendungen bedeutet PORTSTAT = 0 Weiche auf Abzweig oder Fahrtrichtung links bzw. Signal auf Halt ("rot") und PORTSTAT = 1 Weiche gerade oder Fahrtrichtung rechts bzw. Signal auf Fahrt ("grün"). 8…15 reserviert

  Auf eine Schaltanforderung antwortet ein Knoten mit MSG_LC_STAT. Sollte ein Port außerhalb der vorhandenen Ports angesteuert werden, oder ein Schaltzustand angesteuert werden, der nicht unterstützt wird, so antwortet der Knoten mit MSG_LC_NA. Sollte ein Knoten einen bestimmten Zustandsübergang nicht beherrschen, so soll er den nächstmöglichen Übergang durchführen: also z. B. Neon-Einschaltflackern sei nicht vorhanden, es wird normal eingeschaltet.

• MSG_LC_PORT_QUERY:

  (bis einschließlich Protokollversion 0.6 unter dem Namen MSG_LC_OUTPUT_QUERY, nur für Ausgänge)

  Abfrage des Status eines Ausgangs oder Eingangs, es folgen 2 Bytes zur Adressierung des Ports. Auf eine Abfrage antwortet ein Knoten mit MSG_LC_STAT oder fallweise MSG_LC_NA.

  Hinweise:

  Dieser Befehl ist optional für Ausgänge. Ob der Knoten diesen Befehl beantwortet, wird im Feature FEATURE_CTRL_PORT_QUERY_AVAILABLE festgelegt. Fehlt dieses Feature oder ist es 0, dann kann die Antwort auf MSG_LC_PORT_QUERY ausbleiben. Hat der Knoten Eingänge, so müssen diese immer abfragbar sein.

  Dieser Befehl soll dem Host ermöglichen, eine Ausgangsstellung zurückzulesen um z. B. die richtige Darstellung am Schirm durchführen zu können.

  Ausgangszustände sind als knotenintern zu behandeln, sie können jederzeit durch Accessory-Stelloperationen, Makroausführungen, als Reaktion auf Eingänge, wegen Zeitabhängigkeiten oder Anderem wechseln. Änderungen an ihnen werden nicht automatisch dem Host mitgeteilt. Wo dies nötig ist, sind Accessorys zu verwenden, für welche entsprechende Absicherungsnachrichten im Protokoll vorgesehen sind.

• MSG_LC_KEY_QUERY:

  (veraltet, ab ausgewiesener Protokollversion 0.7 ist der Befehl MSG_LC_PORT_QUERY zu verwenden)

  Mit dieser Nachricht kann der Zustand eines lokalen Tasters eines Knotens abgefragt werden. Ob der Knoten Taster hat (und wie viele) ist durch eine Feature-Abfrage zu klären. Es folgt ein Byte: PORT.

  MSG_LC_KEY_QUERY Parameter

  Parameter	Beschreibung
  PORT	Nummer des Tasteneingangs. Entspricht PORT0 im flachen Portmodell und PORTNUM im typorientierten (bei PTYPE=15).

  Der Knoten antwortet mit einer MSG_LC_KEY Nachricht, welche den Zustand des Tasters enthält, oder fallweise mit MSG_LC_NA.

• MSG_LC_PORT_QUERY_ALL:

  Abfrage des Status aller oder mehrerer Ports. Es folgen 0, 2 oder 6 Bytes. Sofern Parameter folgen, geben diese die abzufragenden Typen sowie den Bereich an.

  MSG_LC_PORT_QUERY_ALL Parameter

  Parameter	Beschreibung
  SELECT[2]	Diese Bytes bilden eine 16 Bit lange Bitmap, mit der sich die abzufragenden Ports nach Typ filtern lassen. Bit 0 von SELECT0 entspricht SWITCH, Bit 1 LIGHT usw. Ist das entsprechende Bit nicht gesetzt, so wird der Port übersprungen.
  START[2]	Diese Bytes adressieren den ersten zu übertragenden Port.
  END[2]	Diese Bytes adressieren den ersten nicht mehr zu übertragenden Port.

  Sind die Parameter nicht vorhanden, so wird für SELECT der Wert 0xFFFF, für START der Wert 0 und für END der Wert 0xFFFF angenommen. Es muss START <= END gelten.

  Der Knoten antwortet mit mehreren MSG_LC_STAT Nachrichten, für jeden am Knoten vorhandenen Port welcher im von START und END angegebenen Bereich liegt und für welchen das seinem Typ entsprechende Bit in SELECT gesetzt ist. Die Reihenfolge der Ports ist dabei zu befolgen, die Antworten sind aufsteigend nach Portnummer zu senden.

  Am Ende der Übertragung sendet der Knoten MSG_LC_NA mit der Portadresse 0xFFFF.

  Hinweise:

  Die schnelle Abfrage mehrerer Ports eines Knoten ist ab ausgewiesener Protokollversion 0.7 verfügbar.

  Unterstützt der Knoten keine Abfrage von Ausgangszuständen (FEATURE_CTRL_PORT_QUERY_AVAILABLE), so werden diese Ports ignoriert (SELECT &= 0xFF00).

  Dieser Befehl dient zum schnellen Einlesen der Port-Zustände eines Knotens. Das Senden geschieht unter Ausnutzung der Blocktransferfähigkeit des Protokolls und unter selbständiger Beachtung der Transportkapazität seitens des Knotens, der Host muss keine besonderen Vorkehrungen zur Datenflusskontrolle (vgl. MSG_STALL) treffen. Der Knoten muss während der Abarbeitung des Befehls weiterhin andere Nachrichten empfangen und beantworten können.

  MSG_LC_PORT_QUERY_ALL wird nicht gepuffert. Wenn während einer laufenden Übertragung eine weitere MSG_LC_PORT_QUERY_ALL-Nachricht an den Knoten geschickt wird, so wird die aktive Sequenz abgebrochen und eine neue Übertragung gestartet. Durch Abfragen eines leeren Bereichs kann eine Übertragung damit auch beendet werden.

  Die MSG_LC_NA-Nachricht dient als Markierung, um das Ende der Übertragung auch ohne Kenntnis der vorhandenen Ports und ihrer Typen sicher erkennen zu können.

  Beispiele:

  Eine Abfrage MSG_LC_PORT_QUERY_ALL 0xFF 0xFF, 0x00 0x00, 0xFF 0xFF liefert die Zustände aller Ports des Knotens (wie auch die Abfrage ohne Parameter).

  Eine Abfrage MSG_LC_PORT_QUERY_ALL 0x00 0xFF, 0x00, 0x00, 0x08, 0x00 auf einem Knoten mit dem typorientierten Portmodell liefert nur MSG_LC_NA 0xFF 0xFF, da der Filter nur Eingänge und der Bereich nur Ausgänge selektiert.

  Eine Abfrage MSG_LC_PORT_QUERY_ALL 0x06 0x00, 0x01 0x00, 0xFF 0xFF liefert die Zustände aller Licht- und Servoausgänge ab der Portadresse 16.

• MSG_LC_CONFIGX_SET:

  Konfiguration eines Ports. Es folgen n Parameter:

  MSG_LC_CONFIGX_SET Parameter

  Parameter	Beschreibung
  PORT[2]	Diese Bytes adressieren den Port
  DATA[2…41]	Liste aus 1 bis 8 Schlüssel-Wert-Paaren, bestehend jeweils aus Parametertyp und -wert. P_LIST ::= P_PAIR | P_PAIR P_LIST P_PAIR ::= P_ENUM P_VALUE

  Der Knoten speichert diese Parameter ab und antwortet mit einer Nachricht MSG_LC_CONFIGX, dabei werden die neu eingestellten Werte übermittelt sowie etwaige Parameter-Fehler mittels BIDIB_PCFG_NONE gemeldet. Existiert der angesprochene Port am Knoten nicht, wird stattdessen mit MSG_LC_NA geantwortet.

  Kodierung der Portkonfigurations-Parameter

  Name	Code	Werttyp	Bedeutung
  BIDIB_PCFG_NONE	0x00	uint8	0: keine Parameter für diesen Port verfügbar 1…n: Fehlerhafter Parameter (unbekannter oder an diesem Port nicht unterstützter Typ, ungültiger Wert). Das Byte gibt dabei den Code des Parameters an. Bei ungültigen Werten wird der alte Wert beibehalten und mitgesendet.
  BIDIB_PCFG_LEVEL_PORT_ON	0x01	uint8	Analogwert der Helligkeit für den Zustand EIN, Wertebereich 0…255; (1)
  BIDIB_PCFG_LEVEL_PORT_OFF	0x02	uint8	Analogwert der Helligkeit für den Zustand AUS, Wertebereich 0…255 (1)
  BIDIB_PCFG_DIMM_UP	0x03	uint8	Dimmgeschwindigkeit in Richtung EIN, als Schrittweite pro 10ms (2), Wertebereich 1…255
  BIDIB_PCFG_DIMM_DOWN	0x04	uint8	Dimmgeschwindigkeit in Richtung AUS, als Schrittweite pro 10ms (2), Wertebereich 1…255
  BIDIB_PCFG_OUTPUT_MAP	0x06	uint8	Zuordnung zu Ausgabekanal (wie bei DMX) (3)
  BIDIB_PCFG_SERVO_ADJ_L	0x07	uint8	Unterer Justierwert für Servos (4)
  BIDIB_PCFG_SERVO_ADJ_H	0x08	uint8	Obererer Justierwert für Servos (4)
  BIDIB_PCFG_SERVO_SPEED	0x09	uint8	Servo Speed (Umlaufzeit)
  BIDIB_PCFG_SERVO_EXTRA	0x0a	uint8	Besondere Einstellungen für Servos, Bitfeld Bit 0: Spannung abschalten. Wenn dieses Bit gesetzt ist, wird die Servospannung nach Bewegung abgeschaltet. Das spart Strom und reduziert mögliche kleine Bewegungen in der Ziellage.
  BIDIB_PCFG_TICKS	0x0b	uint8	Einschaltzeit eines Ausgangs, in Einheiten von 10ms. Nach der angegebenen Zeit schaltet der Ausgang selbsttätig ab, um eine Überlastung zu verhindern. Durch wiederholte Schaltbefehle lässt sich das Ausschalten hinauszögern. Der Wert 0 steht für einen Dauerausgang.
  BIDIB_PCFG_SWITCH_CTRL	0x0d	uint8	Elektrisches Verhalten eines SWITCH-Ports. Im oberen Nibble ist das Verhalten für den ON-Zustand kodiert, im unteren das für den OFF-Zustand. Jedes der beiden Nibble verfügt über folgenden Wertebereich: 0: LOW (gegen GND geschaltet) 1: HIGH (gegen VCC geschaltet) 2: Z (hochohmig) 3: WEAK_LOW (mit Widerstand auf GND gezogen, nicht belastbar) 4: WEAK_HIGH (mit Widerstand auf VCC gezogen, nicht belastbar) Werden WEAK_LOW oder WEAK_HIGH nicht unterstützt, so sind sie vom Knoten wie Z zu behandeln.
  BIDIB_PCFG_INPUT_CTRL	0x0e	uint8	Elektrisches Verhalten eines INPUT-Ports. Wertebereich: 0: ACTIVE_LOW (der Eingang ist aktiv wenn er mit GND verbunden wird) 1: ACTIVE_HIGH (der Eingang ist aktiv wenn er an VCC gelegt wird) 2: ACTIVE_LOW + PULLUP (der Eingang wird mittels hohem Widerstand auf VCC gezogen, für definierten Ruhezustand) 3: ACTIVE_HIGH + PULLDOWN (der Eingang wird mittels hohem Widerstand auf GND gezogen, für definierten Ruhezustand) Wird PULLUP bzw. PULLDOWN nicht unterstützt, so hat der Knoten nur das LSB zu respektieren.
  BIDIB_PCFG_LOAD_TYPE	0x0f	uint8	Lasttyp eines OUTPUT-Ports. Wertebereich: 0: allgemein (nur Schalten, alle Fehlerbilder ignorieren) 1: ohmsche Last 2: Magnetspule ohne Endabschaltung 3: Magnetspule mit Endabschaltung Wird für keine Last eine Lageüberwachung unterstützt, entfällt der Parameter.
  BIDIB_PCFG_MOVE_TYPE	0x10	uint8	Servobewegungsmuster, Umlaufkurve (5) Der Wert besteht aus 2 Nibble zu je 4 Bit. Jedes Nibble wählt eine Bewegungsart aus, wobei das niederwertige Nibble (4 LSBs) für Bewegungen gilt, bei denen der Zielwert größer als der Startwert ist. Das höherwertige Nibble (4 MSBs) gilt für Bewegungen, bei denen der Zielwert kleiner als der Startwert ist. Wertebereich: 0=Lineare Bewegung 1=Weiches Anlaufen, weiches Auslaufen (Smooth start, smooth end) 2=Weiches Anlaufen, Auslaufen mit Nachwippen. 3=Weiches Anlaufen, Auslaufen mit Rückprellen. 4-15=reserved 14=Reserviert für vollständig benutzerdefinierte Kurve 1 15=Reserviert für vollständig benutzerdefinierte Kurve 2 Wenn der Knoten einen BIDIB_PCFG_MOVE_TYPE nicht unterstützt, wird der Defaultwert 0=Lineare Bewegung gesetzt.
  BIDIB_PCFG_DIMM_UP_8_8	0x43	uint16	Dimmgeschwindigkeit in Richtung EIN, Schrittweite pro 10ms (2), Wertebereich 1…65535 (6)
  BIDIB_PCFG_DIMM_DOWN_8_8	0x44	uint16	Dimmgeschwindigkeit in Richtung AUS, Schrittweite pro 10ms (2), Wertebereich 1…65535 (6)
  BIDIB_PCFG_TRANSITION_TIME	0x46	uint16	Zeit für den sanften Wechsel zwischen Portzuständen, etwa Überblenden von Farben oder Dimmen der Helligkeit. Einheit 10ms, Wertebereich 0…65535
  BIDIB_PCFG_RGB	0x80	uint24	RGB-Wert zur Farbwahl eines Lichtausgangs: erstes Byte Rot, zweites Grün, drittes Blau
  BIDIB_PCFG_RECONFIG	0x81	uint24	Port Reconfiguration (7)
  BIDIB_PCFG_CONTINUE	0xFF	none	Eine zusätzliche Nachricht mit weiteren Wertepaaren folgt

  (1)

  Sollte die Lichtsteuerung eine andere interne Auflösung besitzen, so werden die Werte von der Lichtsteuerung selbst auf ihre eigene Auflösung umgerechnet. Ein evtl. notwendige Gammakorrektur soll der Knoten selbst berechnen.

  (2)

  Die Dimmgeschwindigkeit wird als Schrittweite angegeben, d.h. der Maximalwert 'durchschreitet' den Helligkeitsbereich in einem Schritt (also keine Zwischenstufen), eine Schrittweite von 1 steuert alle möglichen Zwischenstufen an. Die Zeit für einen Dimmschritt ist 10ms, so lassen sich Zeiten bis zu 2,5s erzielen, was für typisches Verhalten von Signalen geeignet ist.

  (3)

  Kanalmapping: Durch Angabe einer Zuordnungsnummer lassen sich unterschiedliche LIGHT- oder BACKLIGHT-Ports auf eine gemeinsame Ausgabe abbilden. Dadurch können z. B. unterschiedlich schnelle Dimmvorgänge oder Farbe auf der gleichen Lampe konfiguriert werden. (virtuelle Ports)

  (4)

  Die Werte sind immer im Bereich 0…255 angegeben und werden vom Knoten auf den Servopulsbreitenbereich von 0.5ms bis 2.5ms abgebildet.

  (5)

  Die Umlaufkurven werden mit den Justierwerten des Servos (BIDIB_PCFG_SERVO_ADJ_L und BIDIB_PCFG_SERVO_ADJ_H) linear skaliert sowie fallweise zeitlich gestreckt, dabei liegt der Start- und der Endpunkt innerhalb des gesamten Stellbereiches, um etwas Reserve z.B. für geplante Überschwinger beim Nachwippen zu haben. Genauere Infos zu den Weg-Zeitverläufen siehe Supportseiten.

  (6)

  Bietet ein Knoten Dimmzeiten als 16-Bit Werte an, so kann er entsprechend langsamere Dimmvorgänge fahren – von 10ms bis 10min. Das ist insbesondere für die Anlagenbeleuchtung zur Tag/Nacht-Simulation interessant. Ein Knoten kann entweder DIMM-Werte im 8-Bit Bereich oder im 16-Bit Bereich parametrieren.

  (7)

  Typkonfiguration: Der Parameter beschreibt, welche Typen in einer variablen Konfigurationsumgebung am angesprochenen Port verfügbar sind, und welcher Porttyp aktuell gesetzt ist. Der Wert besteht aus 3 Bytes: ACT_TYPE, PORTMAP₀, PORTMAP₁. ACT_TYPE gibt den eingestellten bzw. einzustellenden Porttyp an. PORTMAP gibt als 16 Bit lange Bitmap über die gesetzten Bits an, welche Typen an diesem Port einstellbar sind; Bit 0 von PORTMAP₀ entspricht SWITCH, Bit 1 LIGHT usw. Die PORTMAP wird beim Setzen des Parameters ignoriert.

  Hinweise:

  Der Befehl löst die CONFIG_SET-Nachricht ab. Die Konfiguration eines Ports mit 'CONFIGX…'-Nachrichten ist ab ausgewiesener Protokollversion 0.6 verfügbar und zu verwenden.

  Das P_ENUM BIDIB_PCFG_NONE wird nur im Upstream benötigt.

  Wenn ein Port mehr als 8 Konfigurationsparameter hat, dann wird nach dem letztem Parameter der ersten Nachricht ein P_ENUM BIDIB_PCFG_CONTINUE angefügt; es wird dann auch nur eine Antwort des Knotens (mit mehreren Nachrichten) erwartet.

  Wenn ein Knoten die gespeicherten Parameterwerte nicht sofort zur Anwendung bringen kann, soll er den betroffenen Port deaktivieren; d.h. Schalt- oder Abfrage-Nachrichten werden per MSG_LC_NA mit der Ursache BIDIB_ERR_LC_PORT_INACTIVE abgelehnt bis die Konfiguration wirksam ist. Zusätzlich kann per MSG_SYS_ERROR der genaue Grund signalisiert werden, etwa die Erfordernis eines Neustarts.

  Ein Hostprogramm darf nur diejenigen P_ENUMs an einen Knoten und Port senden, die der Knoten zuvor bei einer Abfrage als 'am Knoten bekannt' mitgeteilt hat. Damit wird sichergestellt, dass der Knoten keine ihm unbekannten P_ENUMs (v.a. unbekannter Größe) auswerten muss.

• MSG_LC_CONFIGX_GET:

  Abfrage der Konfiguration eines Ports. Es folgen 2 Parameter:

  MSG_LC_CONFIGX_GET Parameter

  Parameter	Beschreibung
  PORT[2]	Diese Bytes adressieren den Port

  Die Nachricht MSG_LC_CONFIGX_GET wird mit einer Nachricht MSG_LC_CONFIGX beantwortet, dabei werden alle eingestellten Werte übermittelt. Existiert der angesprochene Port am Knoten nicht, wird stattdessen mit MSG_LC_NA geantwortet.

  Hinweise:

  Der Befehl löst die CONFIG_GET-Nachricht ab. Die Konfiguration eines Ports mit 'CONFIGX…'-Nachrichten ist ab ausgewiesener Protokollversion 0.6 verfügbar und zu verwenden.

  Die Anwortlänge auf MSG_LC_CONFIGX_GET kann bis zu 45 Byte sein, dies ist entsprechend in der Datenflusskontrolle (vgl. MSG_STALL) zu berücksichtigen. Typischerweise muss man die Antwort auf MSG_LC_CONFIGX_GET abwarten, bevor man neue Abfragen an den Knoten schicken kann. Die Nachricht MSG_CONFIGX_GET_ALL hat diese Einschränkung nicht.

• MSG_LC_CONFIGX_GET_ALL:

  Abfrage der Konfigurationen aller oder mehrerer Ports. Es folgen 0 oder 4 Bytes. Sofern Parameter folgen, definieren diese den Bereich.

  MSG_LC_CONFIGX_GET_ALL Parameter

  Parameter	Beschreibung
  START[2]	Diese Bytes adressieren den ersten zu übertragenden Port.
  END[2]	Diese Bytes adressieren den ersten nicht mehr zu übertragenden Port.

  Sind die Parameter nicht vorhanden, so wird für START der Wert 0 und für END der Wert 0xFFFF angenommen. Es muss START <= END gelten.

  Der Knoten antwortet mit mehreren MSG_LC_CONFIGX Nachrichten, für jeden am Knoten vorhandenen Port welcher im von START und END angegebenen Bereich liegt. Die Reihenfolge der Ports ist dabei zu befolgen, die Antworten sind aufsteigend nach Portnummer zu ordnen.

  Hinweise:

  Die Konfiguration eines Ports mit 'CONFIGX…'-Nachrichten ist ab ausgewiesener Protokollversion 0.6 verfügbar und zu verwenden.

  Dieser Befehl dient zum schnellen Einlesen der Port-Konfiguration eines Knotens. Das Senden geschieht unter Ausnutzung der Blocktransferfähigkeit des Protokolls und unter selbständiger Beachtung der Transportkapazität seitens des Knotens, der Host muss keine besonderen Vorkehrungen zur Datenflusskontrolle (vgl. MSG_STALL) treffen. Der Knoten muss während der Abarbeitung des Befehls weiterhin andere Nachrichten empfangen und beantworten können.

  Die Anzahl der zu erwartenden Antwortnachrichten kann durch entsprechende Featureabfragen vorab bestimmt werden.

  MSG_LC_CONFIGX_GET_ALL wird nicht gepuffert. Wenn während einer laufenden Übertragung eine weitere MSG_LC_CONFIGX_GET_ALL-Nachricht an den Knoten geschickt wird, so wird die aktive Sequenz abgebrochen und eine neue Übertragung gestartet.

  Beispiele:

  Eine Abfrage MSG_LC_CONFIGX_GET_ALL 0, 0, 0xFF, 0xFF liefert alle Ports des Knotens (wie auch die Abfrage ohne Parameter).

  Bei Verwendung des typorientierten Portmodells liefert eine Abfrage MSG_LC_CONFIGX_GET_ALL BIDIB_PORTTYPE_SERVO, 0, BIDIB_PORTTYPE_SERVO+1, 0 alle Servoports des Knotens.
  Zum selben Ergebnis führt MSG_LC_CONFIGX_GET_ALL BIDIB_PORTTYPE_SERVO, 0, BIDIB_PORTTYPE_SERVO, $SERVO_COUNT (mit der eingelesenen Anzahl von Servos)

• MSG_LC_CONFIG_SET:

  (veraltet, ab ausgewiesener Protokollversion 0.6 ist der Befehl MSG_LC_CONFIGX_SET zu verwenden)

  Konfiguration eines Ports hinsichtlich seiner Parameter. Es folgen 6 Bytes:

  MSG_LC_CONFIG_SET Parameter

  Parameter	Beschreibung
  PORT[2]	Diese Bytes adressieren den Port im typorientierten Portmodell
  DATA[4]	Konfigurationswerte

  Die Konfigurationswerte sind immer als uint8 (im Bereich 0…255) angegeben. Ihre Bedeutung ist abhängig vom Ausgangstyp und entspricht jeweils einem CONFIGX-Wertepaar:

  Typ (PORT0)	DATA0	DATA1	DATA2	DATA3
  Schaltausgang 0 (=BIDIB_PORTTYPE_SWITCH)	Hier ist im Normalfall keine Konfiguration vorgesehen. Für Sonderanwendungen (z. B. Kontrolle weiterer Baugruppen) gibt es die Möglichkeit der Konfiguration. Ob der Knoten diese Konfiguration anbietet, ist dem Feature FEATURE_SWITCH_CONFIG_AVAILABLE zu entnehmen. Fehlt dieses Feature, gibt es keine Konfiguration und Schaltports können nur geschaltet werden.
  	IO-Setup (1)	BIDIB_PCFG_TICKS	reserviert	reserviert
  Lichtausgang 1 (=BIDIB_PORTTYPE_LIGHT)	Bei Lichtausgängen ist die min. und und max. Helligkeit, Geschwindigkeit des Dimmens konfigurierbar. Mittels des Features FEATURE_CTRL_STRETCH_DIMM (sofern vorhanden) kann der Übergang bis zum Faktor 250 zusätzlich verlangsamt werden, damit dauert ein Helligkeitsübergang bis zu 10min und ist damit für die Tag-Nacht-Simulation einer Anlage geeignet.
  	BIDIB_PCFG_LEVEL_PORT_OFF	BIDIB_PCFG_LEVEL_PORT_ON	BIDIB_PCFG_DIMM_DOWN	BIDIB_PCFG_DIMM_UP
  Servoausgang 2 (=BIDIB_PORTTYPE_SERVO)	Bei Servoausgängen lässt sich der untere und obere Anschlag justieren sowie die Umlaufgeschwindigkeit festlegen.
  	BIDIB_PCFG_SERVO_ADJ_L	BIDIB_PCFG_SERVO_ADJ_H	BIDIB_PCFG_SERVO_SPEED	reserviert
  Lichtausgang 6 (=BIDIB_OUTTYPE_BACKLIGHT)	Bei Lichtausgängen mit direkt steuerbarer Helligkeit ist eine eventuelle Abbildung auf die echte Hardware und Geschwindigkeit des Dimmens konfigurierbar.
  	BIDIB_PCFG_DIMM_DOWN	BIDIB_PCFG_DIMM_UP	BIDIB_PCFG_OUTPUT_MAP	reserviert
  3, 4, 5, …	Genauere Definition für Sound, Motor- und Analogspannungsausgänge folgt.

  Reservierte Werte sind mit 0 zu belegen.

  (1)

  IO-Setup:

  • 0=output (direkt schaltend)
  • 1=High Puls (wenn auf 1 geschaltet wird, kehrt der Ausgang nach der Zeit S auf 0 zurück)
  • 2=Low Puls
  • 3=tristate (d.h. der PORT ist inaktiv)
  • 4=pullup (d.h. der PORT kann nicht mehr geschaltet werden, er agiert als Input)
  • 5=pulldown (d.h. der PORT kann nicht mehr geschaltet werden, er agiert als Input)

  Der Knoten speichert diese Parameter ab und antwortet mit einer MSG_LC_CONFIG Nachricht. Sollte ein Port außerhalb der vorhandenen Ports angesteuert werden, so antwortet der Knoten mit MSG_LC_NA.

• MSG_LC_CONFIG_GET:

  (veraltet) Abfrage eines Ports hinsichtlich seiner Parameter. Es folgen 2 Parameter:

  MSG_LC_CONFIG_GET Parameter

  Parameter	Beschreibung
  PORT[2]	Diese Bytes adressieren den Port

  Sollte ein Port außerhalb der vorhandenen Ports angesteuert werden, so antwortet der Knoten mit MSG_LC_NA. Ansonsten erfolgt eine Antwort mit MSG_LC_CONFIG.

4.6.8. Uplink: Nachrichten für Zubehör / Schaltfunktionen

• MSG_LC_NA:

  Diese Nachricht wird gesendet, wenn eine Ausnahme an einem Port aufgetreten ist. Dabei kann es sich um einen Fehler beim Schalten oder Konfigurieren eines Ausgangs handeln oder auch das Ende einer Übertragung bei QUERY_ALL. Es folgen zwei oder drei Bytes mit Angaben zu Port und Fehlerursache.

  MSG_LC_NA Parameter

  Parameter	Beschreibung
  PORT[2]	Diese Bytes geben den angesprochenen Port an. Port 0xFFFF signalisiert den Abschluss einer Übertragung von mehreren Ports.
  ERRCAUSE[0…1]	Optionaler Parameter, kodiert die Fehlerursache.

  Kodierung der Fehlerursache

  Wert	Name	Bedeutung
  0	reserviert	(interner Gebrauch in Knoten oder PC-Programmen)
  1	BIDIB_ERR_LC_PORT_GENERAL	(oder Parameter ERRCAUSE nicht vorhanden) Fehlerursache nicht näher spezifiziert
  2	BIDIB_ERR_LC_PORT_UNKNOWN	Port ist unbekannt, nicht aktivierbar: Der angesprochene Port bzw. Typ existiert an dem Knoten nicht. Dieser Fehler ist auch durch eine Konfigurationsänderung nicht heilbar. Beispiel: Ein Knoten meldet per Feature nur 16 Ports, es wurde aber eine Nachricht für Port 20 gesendet.
  3	BIDIB_ERR_LC_PORT_INACTIVE	Port ist aufgrund der Knotenkonfiguration zurzeit nicht nutzbar. Er ist deaktiviert. Dieser Fehler kann durch eine Umkonfiguration geheilt werden. Beispiel 1: Angenommen flaches Portmodell, Port 0 lässt sich als SWITCH und SWITCHPAIR konfigurieren, blockiert in zweiterem Fall aber Port 1. Dieser beantwortet Schaltbefehle dann mit BIDIB_ERR_LC_PORT_INACTIVE. Beispiel 2: Ein Port wurde mit zueinander inkompatiblen (aber für sich validen) Parametern konfiguriert, oder eine Parameteränderung ist vor einem Neustart noch nicht wirksam. Er lehnt währenddessen Schaltbefehle ab.
  4	BIDIB_ERR_LC_PORT_EXEC	Ausführen der Portoperation nicht möglich. Beispiele: Ein SWITCH-Port erhält einen Befehl mit PORTSTAT 5. Oder ein Ausgang im flachen Portmodell wird mit MSG_LC_KEY_QUERY abgefragt.
  5…254		reserviert
  255	BIDIB_ERR_LC_PORT_BROKEN	Hardwarefehler liegt vor. Diese Meldung betrifft genau den gemeldeten Port, genauere Ursachen (interner Knotenfehler, Stromversorgung, usw.) werden fallweise über die allgemeinen Knotenfehler berichtet.

  Hinweise:

  Ein Steuerprogramm soll bei vorhandenem ERRCAUSE die Ursache anzeigen. Bei unbekannter Ursachennummer soll die Fehlernummer angezeigt werden.

• MSG_LC_STAT:

  Diese Nachricht überträgt den momentanen Zustand eines Ports. Es folgen drei Bytes: PORT₀, PORT₁, PORTSTAT.

  Für Ausgänge wird sie als Antwort auf eine Abfrage gesendet oder als Quittung für einen Operationsbefehl, sobald der Ausgang seinen gewünschten Zustand erreicht hat. Sollte es sich um einen Ausgang mit mehr als 100ms Schaltzeit handeln, so wird sofort nach dem Erhalt der MSG_LC_OUTPUT eine Nachricht MSG_LC_WAIT zurückgesendet.

  Für Eingänge wird sie als Antwort auf eine Abfrage gesendet oder auch spontan, wenn sich der Portzustand ändert und der Knoten enabled ist sowie FEATURE_CTRL_INPUT_NOTIFY gesetzt ist.

  MSG_LC_STAT Parameter

  Parameter	Beschreibung
  PORT[2]	angesprochener Port
  PORTSTAT	Je nach Porttyp: Zustand des Ausgangs, identisch zu MSG_LC_OUTPUT kodiert, oder Zustand des Eingangs: 0: inaktiv (offen). 1: aktiv (geschlossen). (Üblicherweise werden Schalter/Taster gegen Masse eingesetzt, diese ziehen den Prozessoreingang auf Low, wenn der Taster geschlossen/gedrückt ist (=Active Low). Dies kann mittels PCFG_INPUT_CTRL, sofern verfügbar, auch anders konfiguriert werden.)

  Hinweis:

  Diese Nachricht soll dem Host ermöglichen, an knoteninterne Portzustände zu gelangen um diese z. B. passend anzeigen zu können. Die Übertragung erfolgt jedoch ohne gesonderte Absicherung mit Quittung oder Wiederholung. Wo dies erforderlich ist, sollen Accessorys oder Melder verwendet werden.

• MSG_LC_WAIT:

  Diese Nachricht wird als sofortige Empfangsbestätigung gesendet, wenn der Ausgang seinen angeforderten Zustand erst nach einer Zeit von 100ms oder mehr erreicht.

  Es folgen drei Bytes: PORT₀, PORT₁, TIME.

  MSG_LC_WAIT Parameter

  Parameter	Beschreibung
  PORT[2]	angesprochener Port
  TIME	Prognostizierte Umlaufzeit. Diese Umlaufzeit wird analog zur Railcom-Spezifikation wie folgt kodiert: Die 7 niederwertigen Bits der Restlaufzeit kennzeichnen die Laufzeit bis zum Erreichen des Ende-Zustand der angeforderten Schaltaktion (prognostizierte Umlaufzeit). Die Zeit wird abhängig vom MSB in Einheiten von 1/10 Sekunden (MSB = 0) oder 1 Sekunde (MSB = 1) angegeben. Eine Zeit von 0 bedeutet keine Schaltzeit ermittelbar. Damit ergibt sich ein Wertebereich 0…12,7 Sekunden bzw. 0…127 Sekunden.

• MSG_LC_KEY:

  (veraltet, ab ausgewiesener Protokollversion 0.7 wird nur MSG_LC_STAT verwendet)

  Diese Nachricht wird gesendet, wenn der Knoten lokale Taster enthält und diese betätigt wurden oder wenn eine explizite Abfrage erfolgte. Diese Nachricht erfolgt spontan (MSG_SYS_ENABLE und das entsprechende feature muss hierfür gesetzt sein) und wird nicht wiederholt. Es folgen zwei Bytes: PORT, KSTATE.

  MSG_LC_KEY Parameter

  Parameter	Beschreibung
  PORT	Nummer des Tasteneingangs. Entspricht PORT0 im flachen Portmodell und PORTNUM im typorientierten (bei PTYPE=15).
  KSTATE	Zustand des Tasters: 0: nicht gedrückt. 1: gedrückt.

• MSG_LC_CONFIGX:

  Nachricht eines Ports hinsichtlich seiner Parameter. Es folgen 4 bis max. 43 Bytes Parameter.

  MSG_LC_CONFIGX Parameter

  Parameter	Beschreibung
  PORT[2]	Diese Bytes geben den angesprochenen Port an.
  DATA[2…42]	Liste aus 1 bis 8 Schlüssel-Wert-Paaren, bestehend jeweils aus Parametertyp und -wert. Die Kodierung entspricht der Nachricht MSG_LC_CONFIGX_SET.

  Hinweise:

  Die Meldung löst die CONFIG-Nachricht ab. Die Konfiguration eines Ports mit 'CONFIGX…'-Nachrichten ist ab ausgewiesener Protokollversion 0.6 verfügbar und zu verwenden.

  Wenn ein Port mehr als 8 Konfigurationsparameter hat, dann wird nach dem letztem Parameter der ersten Nachricht ein P_ENUM BIDIB_PCFG_CONTINUE angefügt, das zeigt dem Hostprogramm an, dass automatisch eine weitere Nachricht MSG_LC_CONFIGX übermittelt wird.

  Das P_ENUM BIDIB_PCFG_RECONFIG wird nur bei Verwendung des flachen Portmodells benötigt. Es ist dann im Upstream verpflichtend mitzusenden, um dem Host den Typ des Ports bekanntzugeben – auch wenn der Knoten keine Umkonfiguration unterstützt und der aktuelle Typ der einzig verfügbare ist.

• MSG_LC_CONFIG:

  (veraltet.) Diese Nachricht wird nach einer Konfiguration oder nach einer Abfrage mittels MSG_LC_CONFIG_GET gesendet. Sie beschreibt die Einstellung eines einzelnen PORTs.

  Es folgen 6 Parameter, Reihenfolge und Kodierung wie bei MSG_LC_CONFIG_SET.

4.6.9. Lokale Makros

Zubehörsteuerungen können die Fähigkeit zu Makros haben, diese Fähigkeit kann unterschiedlich gut ausgeprägt sein und wird durch einen Level definiert. Ob Makros unterstützt werden und welcher Level der Makrofähigkeit unterstützt wird, kann durch eine Feature-Abfrage geklärt werden.

Ebenso sind Anzahl und mögliche Länge der Makrokanäle durch Featureabfragen zu klären.

Makros des Level 1 bestehen aus einer linearen Liste an Schaltpunkten, zu denen bestimmte Aktionen ausgeführt werden. Ein Schaltpunkt ist definiert durch den zeitlichen Abstand zum vorherigen Schaltpunkt, durch den geschalteten Ausgang und durch den Befehlswert. Jede dieser Aktionen entspricht einem MSG_LC_OUTPUT-Kommando. Zusätzlich hat ein Makro noch generelle Parameter wie z. B. die Schrittgeschwindigkeit, mit der es ausgeführt wird.

(Anmerkung: Intern im Knoten kann durch geschickte Programmierung der MSG_LC_OUTPUT-Befehl auf 2 Bytes verkürzt werden, damit ist dann bei einer Verwendung innerhalb Makros auch bei knappen Speicher eine große Zahl an Schaltpunkten möglich.)

Makros des Level 2 bestehen ebenso aus einer linearen Liste an Schaltpunkten (entsprechend Level 1), zusätzlich gibt es Schaltpunkte, welche das Starten und Anhalten weiterer Makros sowie das Synchronisieren verschiedener Makroläufe und die Abfrage von Eingängen (z. B. Endschalter oder Bedientaster) ermöglichen. Damit lassen sich dann bereits kleine lokale Ablaufsteuerungen realisieren, wie sie für animierte Szenen auf der Modellbahn gebraucht werden.

Ein Makro ist also eine Schrittkette von Aktionen auf einem Knoten, welche in einem bestimmten Raster ausgeführt wird. Das Raster für die Ausführung wird durch MACRO_TICK definiert. MACRO_TICK ergibt sich durch BIDIB_MACRO_PARA_SLOWDOWN (s.u.), multipliziert mit der Grundeinheit von 20ms.

Beispiel: stellt man BIDIB_MACRO_PARA_SLOWDOWN auf 50, so ergibt sich MACRO_TICK zu 50 * 20ms = 1s. Das Makro wird also jede Sekunde um einen TICK weitergeschaltet.

Makros sind selbständig. Makros lassen sich individuell laden, verändern und starten. Eine bestimmte Aktion oder ein bestimmter Ausgang darf in mehreren Makros vorkommen. Es dürfen so viele Makros gleichzeitig gestartet werden, wie der Dekoder anbietet. Auch kann es möglich sein, aus Makros Accessory-Objekte zusammenzustellen.

Makros sind Konfigurationshilfsmittel für Knoten, die Fähigkeit zum Anzeigen und Erstellen von Makros ist für PC-Programme optional.

4.6.10. Features für lokale Makros

Die Makrounterstützung und das Level der Makrofähigkeit sind mittels Feature-Abfragen feststellbar:

4.6.11. Downlink: Nachrichten für lokale Makros

Es gibt folgende Befehle zum Erstellen und Verwalten von Makros:

• MSG_LC_MACRO_HANDLE:

  Es folgen zwei Bytes: Makroindex, Operations-Code. Die jeweilige Operation wird mit einer MSG_LC_MACRO_STATE beantwortet.

  Kodierung des Makro-Operations-Codes

  Wert	Name	Bedeutung
  0	BIDIB_MACRO_OFF	Makro soll abgebrochen werden.
  1	BIDIB_MACRO_START	Makro soll gestartet werden.
  2…0xFB		reserviert.
  0xFC (=252)	BIDIB_MACRO_RESTORE	Wiederherstellen. Das angegebene Makro wird aus dem Permanentspeicher (sofern vorhanden, dies kann durch eine Abfrage des Features überprüft werden) übertragen und überschreibt damit das aktuell geladene Makro. Sollte kein Permanentspeicher vorhanden sein, so wird das angegebene Makro gelöscht (wie BIDIB_MACRO_DELETE).
  0xFD (=253)	BIDIB_MACRO_SAVE	Sichern. Das angegebene Makro wird in den Permanentspeicher (sofern vorhanden, kann durch eine Abfrage des Features überprüft werden) übertragen und steht nach dem erneuten Start des System wieder zur Verfügung.
  0xFE (=254)	BIDIB_MACRO_DELETE	Löschen des Makros. Der Inhalt des angegebene Makros wird gelöscht (im Arbeitsspeicher). Diese Operation ist identisch zum Setzen aller(!) Schaltzustände auf 255, 255 (END_OF_MACRO). Durch anschließendes BIDIB_MACRO_SAVE wird auch eine ev. Kopie im Permanentspeicher gelöscht.

  Hinweis:

  Das Sichern eines Makros kann im Knoten einige Zeit beanspruchen. Je nach Implementierung des Knotens kann dieser fallweise in dieser Zeit keine Anfragen beantworten. Es ist daher die Antwort auf diesen Befehl abzuwarten, bevor weitere Befehle gesendet werden.

• MSG_LC_MACRO_SET:

  Setzen eines Makroschaltpunktes, damit wird ein einzelner Makropunkt definiert. Es folgen 6 Parameter:

  MSG_LC_MACRO_SET Parameter

  Parameter	Beschreibung
  DATA0	Index des Makros
  DATA1	Index des Punktes innerhalb des Makros
  DATA2	DELAY: Verzögerungszeit zum Vorgängerpunkt. Wertebereich 0…250	SYS_TYPE: unverzögerter Aufruf einer Systemfunktion. Wertebereich 251…255
  DATA3	PORT[2]: Diese Bytes geben den angesprochenen Port an.	SYS_CMD: Systemfunktion, z. B. das Ende des Macros.
  DATA4		SYS_ARG[2]: Argumente der Systemfunktion. Von der jeweiligen Funktion nicht verwendete Bytes sind mit 0 zu belegen, sie werden zwar mitübertragen, jedoch nicht ausgewertet.
  DATA5	PORTSTAT: Schaltzustand gemäß der Tabelle bei MSG_LC_OUTPUT

  Das Setzen eines Makroschaltpunktes wird mit einer MSG_LC_MACRO Nachricht beantwortet. Sollte ein Port außerhalb der vorhandenen Ports konfiguriert werden, so wird das Makro bei Ausführung an dieser Stelle beendet.

  Das Ende eines Makro wird mit dem Setzen aller Parameter auf 255 signalisiert, bzw. wenn der für Makro verfügbare Speicherplatz zu Ende ist.

  DELAY, Verzögerungszeit: Die hier angegebene Zahl bezeichnet die Zeit bezogen auf den vorhergehende Makropunkt. Eine Zeit von 0 bedeutet keine zeitliche Lücke zwischen den Aktionen (wiewohl sie doch aus physikalischen Gründen i. d. R. knapp nacheinander ausgeführt werden). Die hier angegebene Zeit bedeutet die Zahl der MAKRO_TICKs, welche bis zur Ausführung der Schaltaktion vergehen. Der gültige Bereich beträgt 0…250.

  Die tatsächliche Wartezeit ergibt sich, wenn man diese Zahl mit der Geschwindigkeit der Makroausführung multipliziert. Damit lassen sich Zeiten von 20ms bis über 20min realisieren.

  Für Makros des Level 2 sind bei DELAY = 255 weitere Systemfunktionen gemäß folgender Tabelle definiert:

  Kodierung der Systemfunktionen bei DELAY=255 (Makro Level 2)

  Wert	Name	Funktion
  255	BIDIB_MSYS_END_OF_MACRO	Das Makro wird beendet.
  254	BIDIB_MSYS_START_MACRO	Das in SYS_ARG0 angegebene Makro wird gestartet. Dies kann auch das aktuelle Makro sein, es beginnt dann wieder von vorn.
  253	BIDIB_MSYS_STOP_MACRO	Das in SYS_ARG0 angegebene Makro wird gestoppt. Stop bedeutet hierbei Abbruch, nicht Pause. Sollte sich das Zielmakro in einem kritischen Abschnitt befinden, so wird die Stopanforderung nach dem kritischen Abschnitt ausgeführt.
  252	BIDIB_MSYS_BEGIN_CRITCAL	Das Makro wird nicht durch eine Stopanforderung angehalten, der momentane Ablauf soll fertiggestellt werden (bis END_CRITICAL). Beispiel: die Bewegung eines mechanisches Objekts soll nicht 'auf halber Strecke' abbrechbar sein.
  251	BIDIB_MSYS_END_CRITCAL	Das Makro darf durch eine Stopanforderung angehalten werden (default)
  250	BIDIB_MSYS_FLAG_QUERY1	Das in SYS_ARG0 angegebene Flag wird auf Zustand 1 abgefragt. Sofern es nicht gesetzt ist, wird die Makroausführung pausiert, bis das Flag (z. B. durch ein anderes Makro) gesetzt ist.
  249	BIDIB_MSYS_FLAG_SET	Das in SYS_ARG0 angegebene Flag wird gesetzt. Wertebereich: 0…15
  248	BIDIB_MSYS_FLAG_CLEAR	Das in SYS_ARG0 angegebene Flag wird gelöscht. Wertebereich: 0…15
  247	BIDIB_MSYS_INPUT_QUERY1	Der in SYS_ARG angegebene Eingang bzw. Schalter wird abgefragt. Im flachen Portmodell wird hier die Portadresse angegeben, im typorientierten wird nur die PORTNUM in SYS_ARG0 kodiert (mit PTYPE=15). Sofern der Schalter offen ist (PORTSTATE=0), wird die Makroausführung pausiert. Wenn der Schalter geschlossen ist (PORTSTATE=1), wird die Makroausführung fortgesetzt.
  246	BIDIB_MSYS_INPUT_QUERY0	Der in SYS_ARG angegebene Eingang / Schalter wird abgefragt. Im flachen Portmodell wird hier die Portadresse angegeben, im typorientierten wird nur die PORTNUM in SYS_ARG0 kodiert (mit PTYPE=15). Sofern der Schalter geschlossen ist (PORTSTATE=1), wird die Makroausführung pausiert. Wenn der Schalter offen ist (PORTSTATE=0), wird die Makroausführung fortgesetzt.
  245	BIDIB_MSYS_DELAY_RANDOM	Die Makroausführung wird um eine zufällige Zeit verzögert. Die Zeitspanne wird als Zufallswert aus einem Zeitraum von 0…SYS_ARG0 MACRO_TICKS bei jedem Aufruf neu berechnet. Damit lassen sich z. B. bei Beleuchtungen von Häusern realistische Abläufe erzielen.
  244	BIDIB_MSYS_DELAY_FIXED	Die Makroausführung wird um eine feste Zeit von 0…255 MACRO_TICKS verzögert. Die Zeit ist in SYS_ARG0 angegeben.
  243	BIDIB_MSYS_ACC_OKAY_QIN1	Der in SYS_ARG angegebene Eingang / Schalter wird abgefragt. Im flachen Portmodell wird hier die Portadresse angegeben, im typorientierten wird nur die PORTNUM in SYS_ARG0 kodiert (mit PTYPE=15). Sofern der Schalter geschlossen ist (PORTSTATE=1), wird an das Accessory, welches dieses Makro gestartet hat, eine erfolgreiche Ausführung gemeldet. Wenn der Schalter offen ist (PORTSTATE=0), wird ein Rückmeldefehler gemeldet.
  242	BIDIB_MSYS_ACC_OKAY_QIN0	Der in SYS_ARG angegebene Eingang / Schalter wird abgefragt. Im flachen Portmodell wird hier die Portadresse angegeben, im typorientierten wird nur die PORTNUM in SYS_ARG0 kodiert (mit PTYPE=15). Sofern der Schalter offen ist (PORTSTATE=0), wird an das Accessory, welches dieses Makro gestartet hat, eine erfolgreiche Ausführung gemeldet. Wenn der Schalter geschlossen ist (PORTSTATE=1), wird ein Rückmeldefehler gemeldet.
  241	BIDIB_MSYS_ACC_OKAY_NF	An das Accessory, welches dieses Makro gestartet hat, wird eine erfolgreiche Ausführung gemeldet (mit der Zusatzinfo: No Feedback available).
  240	BIDIB_MSYS_SERVOMOVE_QUERY	Das in SYS_ARG angegebene Servo wird abgefragt. Im flachen Portmodell wird hier die Portadresse angegeben, im typorientierten wird nur die PORTNUM in SYS_ARG0 kodiert (mit PTYPE=2). Sofern die Bewegung des Servos noch nicht beendet ist, wird die Makroausführung pausiert. Wenn die Bewegung beendet ist, wird die Makroausführung fortgesetzt.
  239	BIDIB_MSYS_FLAG_QUERY0	Das in SYS_ARG0 angegebene Flag wird auf Zustand 0 abgefragt. Sofern es gesetzt ist, wird die Makroausführung pausiert, bis das Flag (z. B. durch ein anderes Makro) rückgesetzt ist.

• MSG_LC_MACRO_GET:

  Abfrage eines Makropunktes, es folgen zwei Bytes mit Makroindex und Schaltpunktindex. Die Abfrage wird mit einer MSG_LC_MACRO beantwortet.

  MSG_LC_MACRO_GET Parameter

  Parameter	Beschreibung
  DATA0	Index des Makros, in dem der Schaltpunkt abgefragt wird.
  DATA1	Index des Schaltpunktes innerhalb des Makros

  Die Indizes werden beginnend ab 0 gezählt.

• MSG_LC_MACRO_PARA_SET:

  Setzen eines allgemeinen Parameters für ein Macro, damit werden die Ausführungsparameter des Makros festgelegt: Makrogeschwindigkeit, Ausführungsmode (z. B. repetierend), Startbedingung usw. Es folgen 6 Parameter:

  MSG_LC_MACRO_SET_PARA Parameter

  Parameter	Beschreibung
  DATA0	Index des Makros
  DATA1	Index des Parameters
  DATA2	Wert des Parameters (LSB)
  DATA3	Wert des Parameters
  DATA4	Wert des Parameters
  DATA5	Wert des Parameters (MSB)

  Das Setzen eines Makroparameters wird mit einer MSG_LC_MACRO_PARA Nachricht beantwortet.

  Indexwerte der Parameter:

  Kodierung der Makrokonfigurations-Parameter

  Wert	Name	Bedeutung
  1	BIDIB_MACRO_PARA_SLOWDOWN	Laufgeschwindigkeit des Macros. Mit diesem Wert wird die Abarbeitungsgeschwindigkeit angegeben. Die Grundeinheit ist 20ms. Wertebereich: 1…250 Voreinstellung 1. Beispiel: bei einer Einstellung von 5 schaltet das Macro alle 100ms um einen Macro-Tick weiter. Wenn also in der Makroliste etwa 2 angegeben ist, dann bedeutet das in Summe einen zeitlichen Abstand von 200ms zwischen den Aktionen.
  2	BIDIB_MACRO_PARA_REPEAT	Wiederholungen des Makros. Das Makro wird so oft wiederholt, wie hier angegeben. Wenn hier 0 angegeben wird, dann wird das Makro endlos wiederholt. Wertebereich: 0…250 Voreinstellung: 1, d.h. das Makro wird genau einmal ausgeführt.
  3	BIDIB_MACRO_PARA_START_CLK	Macrostart per Systemuhr freigegeben. DATA2 bis DATA5 enthalten den Zeitpunkt als TCODE (siehe hierzu die Erläuterungen beim Befehl MSG_SYS_CLOCK) Ergänzend zum Start zu einer bestimmten Modell-Uhrzeit besteht auch den Möglichkeit, Macro-Starts wiederholend festzulegen, also z. B. jede Stunde. oder jeden Tag zur gleichen Stunde. Dies wird durch Angabe eines TCODEs erreicht, welcher nicht in einer normalen Zeitnachricht enthalten sein kann. Solche TCODEs sind also Triggerbedingungen, welche ähnlich einem 'wildcard' bei mehreren Zeitpunkt erfüllt werden: TCODEx Bedeutung 00mmmmmm mmmmmm = Angabe der Minute: 0…59: definierte Startzeit 60: Start jede Minute 61: Start jede halbe Stunde (d.h. bei 0,30) 62: Start jede Viertelstunde (d.h. bei 0,15,30,45) 100HHHHH HHHHH = Angabe der Stunde 0…23: definierte Startzeit 24: Start zu jeder Stunde 25: Start zu jeder Stunde, 8:00 bis 17:00 (nur tagsüber) 01000www www = Wochentag, 0=Montag, 1=Dienstag,…6=Sonntag. 7: Start an jedem Tag 110fffff fffff = Uhrbeschleunigungsfaktor (für Macro irrelevant). Ein Makro startet immer dann, wenn der Knoten eine Übereinstimmung bei Minute, Stunde und Tag erkennt. Soll das Starten via TCODE unterbunden werden, sind alle Triggerbedingungen auf void zu stellen, d.h. für min/hr/day ist jeweils 0x3F als Datenwert anzugeben. Wenn also die Triggerung ganz abgeschaltet werden soll, so ist 0x3f, 0xbf, 0x7f, 0xff zu senden. Voreinstellung: 0x3f, 0xbf, 0x7f, 0xff (=abgeschaltet) Beispiele: TCODE = (0x00 + 15), (0x80 + 24), (0x40 + 7): Hier erfolgt ein Start jeden Tag, jede Stunde, immer zur Minute 15. TCODE = (0x00 + 00), (0x80 + 18), (0x40 + 7): Hier erfolgt ein Start jeden Tag, 18:00
  tbd.	tbd.	Macrostart per DCC-Schaltbefehl freigegeben.
  tbd.	tbd.	Macrostart per externen Eingang freigegeben.

  Wenn ein Knoten in der Lage ist, Makros permanent zu speichern, dann müssen die Makroparameter bei diesem Vorgang auch mit abgespeichert werden.

• MSG_LC_MACRO_PARA_GET:

  Abfrage eines Makroparameters, es folgen zwei Bytes mit Makroindex und Parameterindex. Die Abfrage wird mit einer MSG_LC_MACRO_PARA beantwortet.

4.6.12. Uplink: Nachrichten für lokale Makros

• MSG_LC_MACRO_STATE:

  Die Nachricht wird als Quittung nach der Zustandsänderung (Operation) eines Makros gesendet. es folgen zwei Bytes mit Makroindex und Zustand.

  Kodierung des Makrozustands

  Wert	Name	Bedeutung
  0	BIDIB_MACRO_OFF	Makro ist angehalten
  1	BIDIB_MACRO_START	Makro wird gestartet
  2	BIDIB_MACRO_RUNNING	Makro wird bereits ausgeführt
  252	BIDIB_MACRO_RESTORE	Makro wurde wiederhergestellt
  253	BIDIB_MACRO_SAVE	Makro wurde gesichert
  254	BIDIB_MACRO_DELETE	Makro wurde gelöscht
  255	BIDIB_MACRO_NOTEXIST	Makro existiert nicht (Makroindex beim Aufruf zu groß)

• MSG_LC_MACRO:

  Übermittlung eines abgefragten Makropunktes, es folgen 6 Bytes mit Makroindex und Schaltpunktindex sowie dem Inhalt dieses Punktes. Die Kodierung ist identisch zu MSG_LC_MACRO_SET.

• MSG_LC_MACRO_PARA:

  Übermittlung eines abgefragten Makroparameters, es folgen 6 Bytes mit Makroindex, Parameterindex und Parameterwert (Data). Wenn der Parameter im Knoten nicht existiert, dann wird der Wert 0xFF für alle Datenbytes zurückgeliefert.

  MSG_LC_MACRO_PARA Parameter

  Parameter	Beschreibung
  DATA0	Index des Makros
  DATA1	Index des Parameters
  DATA2	Wert des Parameters (LSB)
  DATA3	Wert des Parameters
  DATA4	Wert des Parameters
  DATA5	Wert des Parameters (MSB)

4.7. Belegtmeldung

4.7.1. Erfassung und Absicherung

Belegtmeldung dient dazu, den Aufenthaltsort von Fahrzeugen zu melden. Dieser wird i. d. R. durch eine Stromverbrauchsmessung detektiert. Parallel dazu können Belegtmelder in der Lage sein, bidirektionale Nachrichten (railcom) der Fahrzeuge auszuwerten.

Melder haben das Bit 'Melderfunktion' in der ClassID gesetzt. Melder dienen nur zur Anzeige von Belegtzuständen, nicht zum Melden sonstiger Ereignisse wie z. B. ein Tastendruck oder eine Eingabe aus der Anlage (z. B. von einem Stellpult). Hierfür ist die Klasse 'Zubehör' vorgesehen.

Eine verloren gegangene Belegtmeldung kann im Rechnerbetrieb dramatische Auswirkungen haben: wenn die Belegtmeldung eines Haltabschnittes nicht eingeht, wird ein Zug nicht rechtzeitig angehalten und es kann zu einem Unfall mit materiellen Schäden und Betriebsunterbrechung kommen.

Deshalb ist zum einen die Übertragung in BiDiB mit CRC abgesichert und die Nachrichtenfolge sequentiell durchnummeriert, so dass Übertragungsfehler erkannt werden. Darüber hinaus bietet BiDiB für Belegtmelder noch weitere Sicherungsmethoden:

Secure-ACK-Quittungsverfahren für Belegt- und Positionsmeldungen

Secure-ACK ist ein erweitertes, automatisiertes Quittungverfahren, welches das korrekte Einlesen des Rückmelderinformation auch bei evtl. vorhandenen Übertragungsfehlern garantiert.
Bei aktiviertem Secure-ACK-Quittungsverfahren sendet der Host alle erhaltenen Belegtmeldungen an das Rückmeldersystem zurück. Das Rückmeldesystem vergleicht nun den echten Rückmelderzustand mit dem quittiertem Zustand. Stellt es dabei eine Differenz fest, so werden die fehlerhaften Rückmelderbits erneut übertragen. Wenn die Rückübertragung des Hosts nicht innerhalb der festgelegten Zeit eintrifft, versucht der Melder selbständig, die Meldung erneut abzusenden.
Es ist sowohl bei der Rückmeldebaugruppe als auch beim Hostprogramm klar anzugeben, ob das Secure-ACK-Quittungsverfahren unterstützt wird.

'Vertrauens'-Kontrolle

Ein Melder kann dem Host mitteilen, wie gut die Erfassung ist, also ob die gemeldeten Belegungen auch glaubhaft sind.
Es kann z. B. der Fall eintreten, dass bedingt durch einen Kurzschluss am Gleis nur noch 'eingefrorene' Belegtmeldungen existieren oder gar die Belegtmeldung unmöglich ist. In diesem Fall kann der Melder dies dem Host mitteilen und so evtl. eine durch fehlerhafte Belegtmeldung verursachte Programmreaktion verhindern.

'Alive'-Kontrolle

Das Interface kontrolliert die Verbindung zu seinen Meldern (Knoten) und sendet dem Host eine Änderungsmitteilung, wenn ein Melder verlorengegangen ist oder ein neuer hinzugekommen ist. Darüber hinaus kann der Host periodisch eine PING Nachricht an einen Melder absenden, diese wird dort innerhalb einer festgelegten Zeit entweder mit einer normalen Nachricht oder mit einer PONG-Nachricht (das ist einfach eine leere Nachricht) beantwortet.

Ein weiterer beachtenswerter Punkt ist der verwendete Adressraum. DCC kennt eigentlich zwei Adressräume: kurze und lange Adresse. Es ist jedoch allgemeine Praxis, dass in Steuergeräten diese beiden Adressräume zu einem Adressraum vereint werden. Immer dann, wenn eine Adresse mittels kurzer Adresse darstellbar ist, dann wird kurze Adresse verwendet.

BiDiB behandelt alle DCC Adressen als eindeutig (nach RCN 211), die Unterscheidung kurz-lang existiert im Protokoll nicht.

4.7.2. Features für Belegtmelder

4.7.3. Downlink: Nachrichten für Belegtmelder

Vorbemerkung: Die Anzahl der Melder eines Knotens wird mit den Befehlen MSG_FEATURE... abgefragt bzw. verändert. Man kann über die Featureeinstellung auch die Zahl der Melder konfigurieren. Diese Möglichkeit dient speziell zum Support von Interfaces auf bisherige Meldersysteme: z. B. ein S88-System hat erst mal eine unbekannte Länge und muss daher erst in der Größe definiert werden. Die Zahl der Melder je Knoten ist auf 128 beschränkt.

• MSG_BM_GET_RANGE:

  Mit diesem Befehl werden die Zustände aller Belegtmelder in einem bestimmten Bereich abgefragt. Es folgen 2 Bytes: START, ENDE, welche die zu übertragenden Melderbits bezeichnen.

  Das Rückmeldersystem antwortet mit einer MSG_BM_MULTIPLE Nachricht, die alle Belegtmeldungen von START bis (exklusiv) ENDE enthält.

  Hinweise:

  START- und ENDE-Werte, die nicht auf Bytegrenzen passen, sollen ab- bzw. aufgerundet werden.

  Wenn START außerhalb des Bereiches der verfügbaren Melder liegt, erfolgt eine Fehlermeldung. Wenn ENDE außerhalb liegt, wird die Angabe bei der Antwort auf die verfügbaren Melder beschränkt.

  Bis einschließlich Spezifikationsrevision 1.27 war verpflichtend, dass START und ENDE je durch 8 teilbar sind. Hostprogramme sollen dies weiterhin garantieren.

• MSG_BM_MIRROR_OCC:

  Mit diesem Befehl wird eine einzelne Belegtmeldung zurück an den Melder übertragen. Bei aktiviertem Secure-ACK-Quittungsverfahren (FEATURE_BM_SECACK_ON) wird diese einzelne Belegtmeldung vom Melder nochmal übertragen, falls der Zustand im Melder nicht mit der Mirrormeldung übereinstimmt.

  Wenn Secure-ACK nicht aktiviert ist, muss der Melder diese Nachricht ignorieren.

  Es folgt ein Byte mit der lokalen Melderadresse (MNUM) wie bei MSG_BM_OCC.

• MSG_BM_MIRROR_FREE:

  Mit diesem Befehl wird eine einzelne Freimeldung zurück an den Melder übertragen. Bei aktiviertem Secure-ACK-Quittungsverfahren (FEATURE_BM_SECACK_ON) wird diese einzelne Freimeldung vom Melder nochmal übertragen, falls der Zustand im Melder nicht mit der Mirrormeldung übereinstimmt.

  Wenn Secure-ACK nicht aktiviert ist, muss der Melder diese Nachricht ignorieren.

  Es folgt ein Byte mit der lokalen Melderadresse (MNUM) wie bei MSG_BM_FREE.

• MSG_BM_MIRROR_MULTIPLE:

  Mit diesem Befehl werden die eingelesenen Zustände byteweise zurück an den Melder übertragen. Bei aktiviertem Secure-ACK-Quittungsverfahren (FEATURE_BM_SECACK_ON) werden nicht mit dem Zustand im Melder übereinstimmende Belegtmeldungen vom Melder nochmal übertragen.

  Wenn Secure-ACK nicht aktiviert ist, muss der Melder diese Nachricht ignorieren, bei aktiviertem Secure-ACK erfolgt die Antwort umgehend (mit MSG_BM_MULTIPLE).

  Es folgen Angaben zur Basisadresse dieses Abschnittes und Länge der Meldung sowie die Belegtmeldungsdaten, kodiert wie bei MSG_BM_MULTIPLE.

  Anmerkung:

  Die Quittierung soll nur dann byteweise erfolgen, wenn auch die Belegtmeldung byteweise übertragen wurde. Der Grund hierfür liegt im Echtzeitverhalten: Angenommen, der Belegtmelder meldet mehrere Bits sehr schnell hintereinander als Einzelmeldungen MSG_BM_OCC / MSG_BM_FREE. Würde der Host die erste Meldung mit einem ganzen Byte quittieren, in dem dann jedoch nur ein Teil der Belegtmelderbits korrekt ist, bekäme er vom Belegtmelder-Knoten postwendend noch eine MSG_BM_MULTIPLE-Nachricht mit dem richtigen Vektor. Dasselbe geschähe für alle folgenden Einzelnachrichten, welche noch in der Pipeline sind.

• MSG_BM_GET_CONFIDENCE:

  Es folgen keine Parameter.

  Die aktuelle 'Qualität' der Belegtmeldung wird angefragt, der Knoten antwortet mit einer MSG_BM_CONFIDENCE.

4.7.4. Uplink: Nachrichten für Belegtmelder

Vorbemerkung: Generell erfolgen Meldungen im Uplink spontan (nach erfolgter Freigabe im Interface). Bestimmte Meldungsarten können mittels Feature-Einstellung ein- oder ausgeschaltet werden.

Für Belegtmeldung werden 3 verschiedene Nachrichtentypen verwendet:

• MSG_BM_OCC:

  eine einzelne Belegtmeldung (als Änderungsmeldung); es folgen ein Byte mit der lokalen Melderadresse (MNUM) und optional zwei Bytes mit einem BiDiB-Systemzeitstempel (TIME_L, TIME_H).

  Ist das FEATURE_BM_TIMESTAMP_ON aktiviert und liegt dem Melder eine gültige Systemzeit vor, liefert er einen Zeitstempel für den Zeitpunkt der Melderauslösung mit. Ist dieser nicht genau bestimmbar, soll der Zeitstempel weggelassen werden.

  Hinweis: Die Systemzeit wird auf dem BiDiBus mittels MSG_LOCAL_SYNC-Nachrichten in Abständen von bis zu 32 s synchronisiert. Ein Melder muss eine Clock-Genauigkeit besser als 30ppm haben, um innerhalb dieser Zeitspanne maximal 1 ms wegzudriften. Hat der Melder eine höhere Ungenauigkeit (z. B. mit RC-Oszillator), darf er dieses Feature nicht verwenden.

  Ist das FEATURE_BM_SECACK_ON aktiviert, muss der Host sofort eine MSG_BM_MIRROR_OCC für dieselbe MNUM an den Detektor zurücksenden. Bis diese Quittung eingetroffen ist, wird die Nachricht im eingestellten Intervall mehrfach wiederholt. Der Ereignis-Zeitstempel kann dabei weggelassen werden, wenn er nicht mehr vorliegt. Um keine Meldungsflut zu verursachen, ist die Zahl der Wiederholungen zu begrenzen; längere Ausfälle werden vom Businterface behandelt. Liegt die Quittung danach immer noch nicht vor, wird eine Fehlermeldung mit dem Code BIDIB_ERR_NO_SECACK_BY_HOST gesendet.

  Es soll auch solange keine Freimeldung für den Abschnitt gegeben werden, bis die Belegtmeldung bestätigt worden ist; dies ist insbesondere für Punktmelder mit kurzen Auslösezeiten wichtig.

• MSG_BM_FREE:

  eine einzelne Freimeldung (als Änderungsmeldung); es folgen ein Byte mit der lokalen Melderadresse (MNUM). Wenn durch eine Belegtmeldung ein Abschnitt als frei gemeldet wird, so ist implizit auch eine evtl. gemeldete Lok auf diesem Abschnitt verschwunden.

  Ist das FEATURE_BM_SECACK_ON aktiviert, muss der Host sofort eine MSG_BM_MIRROR_FREE für dieselbe MNUM an den Detektor zurücksenden. Bis diese Quittung eingetroffen ist, wird die Nachricht im eingestellten Intervall mehrfach wiederholt. Um keine Meldungsflut zu verursachen, ist die Zahl der Wiederholungen zu begrenzen; längere Ausfälle werden vom Businterface behandelt. Liegt die Quittung danach immer noch nicht vor, wird eine Fehlermeldung mit dem Code BIDIB_ERR_NO_SECACK_BY_HOST gesendet.

• MSG_BM_MULTIPLE:

  Diese Nachricht übermittelt Belegt/Freimeldungen eines ganzen, zusammenhängenden Bereiches an Melderadressen. Es folgen Angaben zur Basisadresse dieses Bereiches und Anzahl der der Meldungen sowie die Belegtmeldungsdaten selbst.

  MSG_BM_MULTIPLE Parameter

  Parameter	Beschreibung
  MNUM	Basisadresse des gemeldeten Abschnittes (wie bei MSG_BM_OCC), diese muss hier aber ein ganzzahliges Vielfaches von 8 sein.
  SIZE	Anzahl der gemeldeten Bits, Wertebereich 8… 128. Size kann ebenfalls nur vielfache Werte von 8 annehmen.
  DATA[1…16]	Melderdaten. Das LSB des ersten Bytes entspricht der Basisadresse, das MSB des ersten Bytes der Basisadresse + 7. Das LSB des zweiten Bytes entspricht Basisadresse + 8 usw. Ein gesetztes Bit steht für einen belegten Abschnitt, ein nicht gesetztes für einen freigemeldeten. Bei einer Melderanzahl (FEATURE_BM_SIZE), die kein Vielfaches von 8 ist, wird am Ende mit 0-Bits aufgefüllt.

  Diese Nachricht ist speziell in der Initialisierungsphase bzw. nach einem Protokollfehler zum schnellen Einlesen der Belegtmeldung gedacht.

  Ist das FEATURE_BM_SECACK_ON aktiviert, muss der Host sofort eine MSG_BM_MIRROR_MULTIPLE für denselben Bereich an den Detektor zurücksenden. Bis diese Quittung eingetroffen ist, wird die Nachricht im eingestellten Intervall mehrfach wiederholt. Um keine Meldungsflut zu verursachen, ist die Zahl der Wiederholungen zu begrenzen; längere Ausfälle werden vom Businterface behandelt. Liegt die Quittung danach immer noch nicht vor, wird eine Fehlermeldung mit dem Code BIDIB_ERR_NO_SECACK_BY_HOST gesendet.

• MSG_BM_CONFIDENCE:

  Diese Nachricht übermittelt eine Information über die 'Vertrauenswürdigkeit' der aktuellen Belegtmeldung. Es folgen 3 Bytes, welche den Zustand bezeichnen. Je nach Zustand des Gleissignals kann die Erfassung der Belegtmeldung beeinträchtigt sein: so ist z. B. bei einem Kurzschluss des Gleissignals je nach internem Aufbau des Belegtmelders nur eine 'eingefrorene' oder gar keine gültige Meldung möglich.

  Bei Ausfall der Gleisstromversorgung oder des Erfassungsystems muss die entsprechende CONFIDENCE-Meldung zeitlich vor den Änderungen der Belegt- oder Adressmeldungen eingehen. Damit hat das Hostprogramm die Möglichkeit, nachfolgende Belegt- oder Adressmeldungen im richtigen Kontext zu sehen.

  Nach einem Wechsel des Vertrauenszustands sind die Nachrichten zur Lokgeschwindigkeit und eine evtl. davon abgeleitete Ortsbestimmung fallweise veraltet.

  MSG_BM_CONFIDENCE Parameter

  Parameter	Beschreibung
  VOID	0: die Belegtmeldung leitet sich aus der tatsächlichen Situation am Gleis ab. <>0: die gemeldete Belegung ist ungültig, eine Erfassung zurzeit nicht möglich.
  FREEZE	0: die Belegtmeldung wurde mit dem Eingangssignal oder einer Ersatzmethode des Melders ermittelt. <>0: die Belegtmeldung ist nicht aktuell, sondern der gespeicherte Zustand einer früheren Situation.
  NOSIGNAL	0: die Belegtmeldung wurde mit gültigem Eingangssignal ermittelt (d.h. es liegt ein Gleissignal an). <>0: es fehlt ein gültiges Eingangssignal vom Booster.

  Es handelt sich bei diesen Bytes also um 'Warnstufen':

  • ¬VOID ∧ ¬FREEZE ∧ ¬NOSIGNAL: das Meldeergebnis ist komplett okay.
  • ¬VOID ∧ ¬FREEZE ∧ NOSIGNAL: es handelt es sich um eine Ersatzmessung (mit geringerer Fehlerfreiheit, insbesondere im Kurzschlussfall) und das Gleissignal ist ausgefallen.
  • ¬VOID ∧ FREEZE ∧ NOSIGNAL: es handelt sich um einen eingefrorenen Zustand vom letzten Zeitpunkt bevor das Gleissignal ausgefallen ist. Der Belegtmelder schickt in diesem Zustand keine Spontanmeldungen mehr, Abfragen sind aber möglich.
  • VOID ∧ ¬FREEZE ∧ NOSIGNAL: Es liegen (noch) keine Ergebnisse einer Erfassung vor (z. B. beim Start), es liegt kein Gleissignal an. Der Belegtmelder schickt in diesem Zustand keine Spontanmeldungen mehr, Abfragen sind sinnlos.

  Anmerkung: Mittels dieser Nachricht lässt sich auch ohne Boosterüberwachung ein Boosterausfall erkennen, welcher z. B. durch Kurzschluss, Nothalt oder einen Hardware-Defekt ausgelöst werden kann.

  Es ist zulässig, dass der Melderbaustein bis zu 8 Erfassungsbereiche hat, in diesem Fall soll je Erfassungsbereich das entsprechende Bit in VOID, FREEZE und NOSIGNAL gesetzt werden. Wenn nur ein Erfassungbereich vorhanden ist, wird jeweils das LSB gesetzt, bei 2 Erfassungsberreichen die beiden unteren Bits, usw. Eine Hostsoftware muss die Bereiche nicht zwingend getrennt betrachten, sondern kann die Meldung auch einfach für den gesamten Knoten gelten lassen.

  Wenn spontane Belegtmeldung aktiviert ist, dann erfolgt auch eine spontane Meldung bei Änderung des Vertrauenszustandes des Melders. Sollte ein Melder mehrere Erfassungsbereiche besitzen (welche evtl. zugleich den Zustand wechseln), soll die Zusammenfassung zeitlich dicht aufeinanderfolgender Zustandsänderungen zu einer einzigen Meldung bereits im Knoten erfolgen.

• MSG_BM_CURRENT:

  Strom-Meldung, es folgen zwei Bytes: MNUM, CURRENT

  MSG_BM_CURRENT Parameter

  Parameter	Beschreibung
  MNUM	lokale Adresse des Melders
  CURRENT	Stromverbrauch Kodierung des Stromwertes Wert Bedeutung 0 kein Stromverbrauch, Gleis ist frei. 1…15 Stromverbrauch, in mA. Möglicher Bereich: 1…15mA 16…63 Stromverbrauch, Wert ist (Datum - 12) * 4mA. Möglicher Bereich: 16…204mA 64…127 Stromverbrauch, Wert ist (Datum - 51) * 16mA. Möglicher Bereich: 208…1216mA 128…191 Stromverbrauch, Wert ist (Datum - 108) * 64mA. Möglicher Bereich: 1280…5312mA 192…250 Stromverbrauch, Wert ist (Datum - 171) * 256mA. Möglicher Bereich: 5376…20224mA 251…253 reserviert. 254 Overcurrent aufgetreten. 0xFF Nur Belegtmeldung, kein exakter Verbrauch bekannt.

  MSG_BM_CURRENT wird nur spontan gemeldet und kann nicht abgefragt werden. Durch Setzen oder Löschen des FEATURE_BM_CURMEAS_INTERVAL kann die Übertragung zu- oder abgeschaltet werden.

4.7.5. Features für BiDi-Detektoren

Bidirektionale Nachrichten der Fahrzeuge (Railcom nach RCN 217) können in verschiedenen Knoten wie Belegtmeldern und Boostern ausgewertet werden. Dazu können diese die folgenden Features anmelden:

(1)

Adressdaten sind verfügbar, wenn Railcom im Lokdekoder aktiviert ist (CV 28).

(2)

Lokale Detektoren haben typischerweise bessere Erkennungsergebnisse für Fahrzeugmeldungen und sollten bevorzugt verwendet werden. Globale Detektoren bieten sich für Booster an, die nur ein einziges Gleis (ohne extra Belegtmelder) oder nur stationäre Dekoder versorgen.

4.7.6. Downlink: Nachrichten für BiDi-Detektoren

• MSG_BM_ADDR_GET_RANGE:

  Es folgen 2 Bytes: START, ENDE.

  Mit diesem Befehl werden die vom Detektor erfassten Lok-Adressen erneut übertragen und zwar für die Abschnitte von Index START bis Index ENDE-1. Es erfolgt eine Reihe von (Einzel-)Adressmeldungen (MSG_BM_ADDRESS). Wenn ein Abschnitt keine Lokadresse enthält, wird dieser Abschnitt mit Adresse 0 übertragen. Wenn ein Abschnitt am Detektor nicht existiert, wird nichts übertragen. Ein globaler Detektor kann mit START=255 und optional ENDE=0 abgefragt werden.

  Die Nachricht ist nur verfügbar, wenn das FEATURE_BM_ADDR_DETECT_ON gesetzt ist.

• MSG_BM_MIRROR_POSITION:

  Mit diesem Befehl wird eine Positionsmeldung eines Dekoders zurück an den Detektor übertragen. Bei aktiviertem Secure-ACK-Quittungsverfahren (FEATURE_BM_POSITION_SECACK) wird die letzte Positionsmeldung vom Detektor nochmal übertragen, falls der dem Detektor bekannte Ort für den Dekoder nicht mit der Mirrormeldung übereinstimmt.

  Liegen dem Detektor keine Ortsinformationen zu dem Dekoder vor oder ist Secure-ACK nicht aktiviert, ignoriert der Detektor diese Nachricht.

  Es folgen fünf Bytes mit der Adresse des Dekoders und der ID der Ortsmarke, kodiert wie bei MSG_BM_POSITION.

4.7.7. Uplink: Nachrichten für BiDi-Detektoren

Sowohl in Belegtmeldern als auch in anderen Knoten, wie etwa Boostern, können bidirektionale Nachrichten (railcom) der Fahrzeug- bzw. Stationärdekoder ausgewertet werden. Globale Detektoren, die nicht zwischen mehreren Meldeabschnitten unterscheiden, setzen das MNUM-Feld auf 255.

Bei der Meldung einer Dekoderadresse wird folgendes Schema verwendet:

Hinweise zur Fahrzeugorientierung:

Die Richtungsangabe im MSB ist nur gültig, wenn auch die entsprechende Einstellung (FEATURE_BM_ADDR_AND_DIR) die Übertragung der Aufgleisrichtung vorsieht. Falls dieses Feature abgewählt ist, soll das Richtungsbit mit 0 übertragen werden und darf nicht ausgewertet werden.

Das Richtungsbit kodiert die (fahrtrichtungsunabhängige) Aufgleisrichtung, es ist gesetzt wenn die mit dem Detektor verbundene Schiene rechts liegt. Links/rechts bezieht sich dabei auf die Lok, bei Blickrichtung nach vorn (Vorwärtsfahrt, zur Rauchkammertür bzw. Führerstand 1). Auf der linken Seite ist bei Verdrahtung mit Farben nach NEM 650 der Radschleiferanschluss in schwarz ausgeführt, auf der rechten Seite in rot.

An welcher Gleisseite der Detektor installiert ist, kann von Abschnitt zu Abschnitt verschieden sein. Es wird aber empfohlen, konsistent DCC1 (positive Polarität, gekennzeichnet auch als +, P oder A) als gemeinsamen Pol vom Booster zur Schiene durchzuverbinden und Detektoren sowie Belegtmelder in DCC2 (negative Polarität, gekennzeichnet auch als -, N oder B) einzuschleifen.

In Knoten, die BiDi unterstützen, dienen die folgenden BiDiB-Nachrichten zur Weiterleitung der entsprechenden Rückmeldungen:

• MSG_BM_ADDRESS:

  Mit dieser Meldung wird das Auftreten einer Lok in einem bestimmten Abschnitt angezeigt.

  Es folgen drei oder mehrere Bytes: MNUM, ADDR_L, ADDR_H, [ADDR_L, ADDR_H], ...

  Ist nur ein Dekoder im Abschnitt, so erfolgt eine 3 Byte Meldung. Sind mehrere Dekoder im Abschnitt, so werden die Adressen der Dekoder in folgenden Bytepaaren ADDR_L, ADDR_H übertragen. Es können maximal 16 Adressen in einem Abschnitt gemeldet werden. Dies gilt auch für globale Detektoren. Adressmeldung ist dort nur für kleine Aufbauten (z.B. Programmiergleis) vorgesehen.

  MSG_BM_ADDRESS Parameter

  Parameter	Beschreibung
  MNUM	Lokale Nummer des Belegtmelders, Wertebereich 0…127; 255
  ADDR[2][1…16]	Adressen der Lok- bzw. Zubehördekoder. Wertebereich entsprechend dem DCC-Wertebereich, kodiert wie oben beschrieben

  Hinweise zum Verhalten des Knotens:

  Wenn eine Adressmeldung erfolgt war und kein Dekoder mehr in diesem Abschnitt detektiert werden kann, dann meldet der Knoten dies mit einer MSG_BM_ADDRESS mit Adresse 0.

  Wenn bei mehreren Dekodern einer in diesem Abschnitt nicht mehr detektiert werden kann, dann meldet der Knoten eine MSG_BM_ADDRESS mit den noch vorhandenen Adressen.

  Wenn keine Belegung auf einem Abschnitt gemeldet wird (z. B. via MSG_BM_FREE), sind implizit auch alle Adressmeldungen aufgehoben.

• MSG_BM_ACCESSORY:

  (noch genauer zu spezifizieren)

  Mit dieser Meldung wird die Rückmeldung eines Accessory Dekoders angezeigt.

• MSG_BM_CV:

  CV-Meldung, es folgen fünf Bytes: ADDR_L, ADDR_H, CV_L, CV_H, DAT

  MSG_BM_CV Parameter

  Parameter	Beschreibung
  ADDR[2]	Adresse des meldenden Dekoders, kodiert wie oben beschrieben
  CV[2]	CV, Wertebereich 0…1023; 0 entspricht der CV1
  DAT	Das gelesene Datum.

  Hinweise:

  Ein Rückmeldebaustein soll kurz hintereinander eintreffende, mehrfache POM-Antworten zur gleichen CV auf einer Lok filtern und nur eine Nachricht an den Host schicken. Trotzdem ist es möglich, dass zu einem POM-Befehl mehrere Antworten eingehen (wenn z. B. eine Lok zwei verschiedene Rückmelder überbrückt).

  POM-Nachrichten können auch durch andere Befehlsgeräte (z. B. Handregler) verursacht werden, ein Hostprogramm muss das berücksichtigen.

  Sollte das Detektorsystem nicht in der Lage sein, die Lokadresse zu bestimmen, so ist das Adressfeld für die Lokadresse mit 0xFFFF zu übertragen. Ebenso wird mit der CV-Adresse verfahren. Hier wird 0xFFFF statt der richtigen CV-Adresse übertragen. (Das ist nur ein Notbehelf, um extrem einfach gebaute PoM-Detektoren zu unterstützen und nicht empfohlen!)

• MSG_BM_XPOM:

  CV-Meldung einer POM-Operation. Es folgen 10 bis 13 Bytes: ADDR_L/DID₀, ADDR_H/DID₁, 0/DID₂, 0/DID₃, 0/VID, OPCODE, CV_L, CV_H, CV_X, DATA[1…4]

  Alle Parameter sind wie bei MSG_CS_POM kodiert, eine Lokadresse enthält jedoch zusätzlich die Aufgleisrichtung wie oben beschrieben.

  Hinweis:

  XPOM-Block-Leseoperationen sind seitens der Zentrale mit einer Sequence-ID ausgerüstet. Das Detektorsystem muss die Rückmeldeantwort des Dekoders mittels dieser Sequence-ID dem DCC-Befehl zuordnen und die Felder für Decoder-ID bzw. Adresse und CV passend zuweisen.

• MSG_BM_SPEED:

  Geschwindigkeits-Meldung, es folgen vier Bytes: ADDR_L, ADDR_H, SPEED_L, SPEED_H

  MSG_BM_SPEED Parameter

  Parameter	Beschreibung
  ADDR[2]	Adresse des meldenden Dekoders, kodiert wie oben beschrieben
  SPEED[2]	Geschwindigkeit in km/h, Lowbyte wird zuerst übertragen

  FEATURE_BM_ISTSPEED_INTERVAL legt fest, wie oft die Übertragung erfolgt. Empfohlen ist eine Einstellung von mind. 200ms. Der Detektor soll Speednachrichten mitteln, wenn diese vom Dekoder häufiger als die eingestellte Übertragungsrate eintreffen. Sollte keine Änderung der Geschwindigkeit erfolgen, soll der Detektor nichts übermitteln, dies gilt insbesondere bei der Geschwindigkeit 0.

  Die MSG_BM_SPEED soll nur einmal je (Lok-)Dekoder erfolgen, auch wenn dieser Dekoder aktuell verschiedene Abschnitte überbrückt und daher in diesen Abschnitten zugleich erfasst wird.

  MSG_BM_SPEED wird nur spontan gemeldet und kann nicht abgefragt werden. Durch Setzen oder Löschen des FEATURE_BM_ISTSPEED_INTERVAL kann die Übertragung zu- oder abgeschaltet werden.

  MSG_BM_SPEED Nachrichten mit Adressfeld = extended Accessory werden von stationären Messanlagen gesendet.

• MSG_BM_DYN_STATE:

  Zustands-Meldung eines Dekoders, es folgen fünf oder mehr Bytes beginnend mit MNUM, ADDR_L, ADDR_H, DYN_NUM.

  MSG_BM_DYN_STATE Parameter

  Parameter	Beschreibung
  MNUM	Lokale Nummer des Belegtmelders, Wertebereich 0…127; 255
  ADDR[2]	Adresse des meldenden Dekoders, kodiert wie oben beschrieben
  DYN_NUM	Kennzeichnung des übertragenen Zustand. 0: reserviert 1: Signalqualität 2: Temperatur 3: Behälter 1 4: Behälter 2 5: Behälter 3 6: Distanz 7-255: reserviert
  VALUE[1…N]	Zustandswert, ein Byte sofern nicht anders angegeben. Dyn-Num Kodierung des Zustandswertes 0: reserviert 1: Signalqualität, Wertebereich 0…100 Übertragen wird das Verhältnis fehlerhaft empfangener Pakete zu Gesamtpaketen in Prozent. Ein Wert von 0 bedeutet fehlerfreien Empfang (seitens des Dekoders). 2: Temperatur (signed char). Wert Bedeutung 0…127 Temperatur in der Einheit Grad Celsius. 128…225 reserviert. 226…255 negative Temperatur (-30°C…-1°C). 3: (Betriebs-) Energievorrat, Wertebereich 0…100 Angabe des Füllstandes des Behälters 1; Antriebsenergie (z. B. Akkustand) 4: Behälter 2 5: Behälter 3 6: Distanz, bestehend aus 4 Byte: DISTANCEL, DISTANCEH, TIMEL, TIMEH. DISTANCE kodiert die gemessene, zurückgelegte Wegstrecke eines Fahrzeuges in mm. Die Wegstrecke wird dabei als zyklisch durchlaufender 16-Bit Wert erfasst (Überlauf 65535-0). Der Zähler inkrementiert, wenn das Fahrzeug vorwärts fährt (in Richtung Führerstand 1). TIME ist ein Systemzeitstempel für den Zeitpunkt des Empfangs der Nachricht vom Dekoder. 7-255: reserviert

  FEATURE_BM_DYN_STATE_INTERVAL legt fest (in Einheiten von 100ms), wie oft die Übertragung erfolgt. Empfohlen ist eine Einstellung von mind. 1s. FEATURE_BM_DYN_STATE_INTERVAL = 0 schaltet die Übertragung ab. Der Detektor soll Zustandmeldungen der Lok nicht übermitteln, wenn diese vor Ablauf von eines FEATURE_BM_DYN_STATE_INTERVAL vom Lokdekoder eintreffen.

  Die MSG_BM_DYN_STATE soll nur einmal je (Lok-)Dekoder erfolgen, auch wenn dieser Dekoder aktuell verschiedene Abschnitte überbrückt und daher zugleich in mehreren Abschnitten erfasst wird.

  MSG_BM_DYN_STATE wird nur spontan gemeldet und kann nicht abgefragt werden. Durch Setzen oder Löschen des Features FEATURE_BM_DYN_STATE_INTERVAL kann die Übertragung zu- oder abgeschaltet werden.

  Hintergrund-Information zur DYN_NUM = 1: Entsprechende Lokdekoder vorausgesetzt (diese müssen railcom ID7, Sub-ID7 bedienen) kann damit eine Art Quality-of-Service Anzeige realisiert werden. Der Lokdekoder führt eine Statistik über alle empfangenen DCC-Pakete (Zahl fehlerhafter Pakete / Gesamtzahl). Diese Statistik wird an den Detektor übertragen und von BiDiB weitergeleitet. Das Hostprogramm entscheidet dann über die Auswertung: korreliert der Fehler mit der Lok, kann ein Hinweis über verschmutzte Radkontakte ausgegeben werden, korreliert der Fehler mit dem Gleisabschnitt, kann auf verschmutztes Gleis geschlossen werden.

  Hintergrund-Information zur DYN_NUM = 6: Diese Meldung dient zum genauen Rangieren bzw. zum genauen Vermessen einer Modellanlage. Die Daten werden aus der Rückmeldung des Dekoders gewonnen (Railcom ID07, DV22 und DV23). Die Informationen unterliegen einer Streuung hinsichtlich des Erfassungszeitpunktes abhängig von der DCC-Wiederholrate. Für die Auswertung relevant sind daher sowohl die Belegtmeldungen des Abschnitts als auch die DISTANCE-Meldungen des Dekoders. Beide sind daher - bei gesetztem FEATURE_BM_TIMESTAMP_ON - mit millisekundengenauen BiDiB-Systemzeitstempeln gekennzeichnet, womit ein sehr guter Näherungswert für die exakte Fahrzeugposition durch Interpolation errechnet werden kann.

• MSG_BM_RCPLUS:

  Meldung eines Dekoders im RailcomPlus-Anmeldeprozess. Ein BiDi-Detektor sendet diese Nachricht ab, wenn im Anmeldevorgang eine entsprechende Rückmeldung eines oder mehrerer Dekoder im Abschnitt erkannt wurde.

  Es folgen zwei oder mehr Bytes: MNUM OPCODE DECVID DECUID[4]

  MSG_BM_RCPLUS Parameter

  Parameter	Beschreibung
  MNUM	Lokale Nummer des Belegtmelders, Wertebereich 0…127; 255
  OPCODE	Klassifizierung der Antwort, s.u.
  DEC_MUN[4]	Seriennummer des Dekoders. Diese 4 Bytes (Manufacturer Unique Number) bilden zusammen mit der DEC_MID die Unique-ID des Dekoders (DID).
  DEC_MID	Herstellerkennung des Dekoders (Manufacturer IDentifier, wie DCC Vendor ID)

  Kodierung des Opcode für RailcomPlus Erkennung

  Wert				Bedeutung
  	T	C	P
  RC_PONG	LOCO	OKAY	0	Auf den Gleisausgabebefehl PING oder FIND hat genau ein Dekoder geantwortet. T gibt an, ob ein Lok- oder Accessory-Dekoder geantwortet hat. C gibt an, ob der Dekoder die CID dieses Systems bereits kennt; wenn nicht dann sind weitere Abfragen erforderlich, insbesondere eine Kontrolle der Adresse. P gibt die Orientierung des Dekoders an. Es folgen 5 Bytes mit der DID des antwortenden Dekoders.
  			1
  		NEW	0
  			1
  	ACCESSORY	OKAY	0
  			1
  		NEW	0
  			1
  RC_PING_COLLISION			0	Auf den Gleisausgabebefehl PING haben mehrere Dekoder gleichzeitig geantwortet. Die Antwort am Gleis ist nicht kollisionsfrei und fehlerhaft.
  			1
  RC_FIND_COLLISION			0	Auf den Gleisausgabebefehl FIND haben mehrere Dekoder gleichzeitig geantwortet. Die Antwort am Gleis ist nicht kollisionsfrei und fehlerhaft. Es folgen 5 Bytes mit der DID des Suchbefehls, auf den geantwortet wurde.
  			1
  RC_BIND_ACCEPTED	LOCO			Auf den Gleisausgabebefehl BIND ist eine Bestätigung des Dekoders erfolgt. Der Dekoder ist unter der zugewiesenen Adresse ansprechbar. Es folgen 7 Bytes mit der DID des quittierenden Dekoders sowie der befohlenen Adresse, kodiert wie oben beschrieben, um den Aufbau einer Zuordnungstabelle im Host zu erleichtern.
  	ACCESSORY

  Hinweise:

  BIND, FIND bzw. PING-Nachrichten werden von der Gleisausgabe mehrfach 'back-to-back' wiederholt. Ein Detektorsystem darf dabei nur eine entsprechende Quittungs-Nachricht je Abschnitt erzeugen.

  PING-Nachrichten werden von der Gleisausgabe zyklisch wiederholt (z. B. im Abstand von 1…2s). Ein Detektorsystem darf dabei nur dann eine entsprechende BM_RCPLUS-Nachricht erzeugen, wenn sich der Inhalt des PONGs gegenüber der vorherigen Nachricht verändert hat.

  Bei FIND-Nachrichten der Gleisausgabe muss das Detektorsystem eine BM_RCPLUS-Nachricht erzeugen, wenn sich der Inhalt der FIND-Nachricht verändert hat (neuer Suchbereich) oder wenn sich die Antwort(en) der Dekoder (PONG) gegenüber den vorherigen Nachrichten verändert hat.

• MSG_BM_POSITION:

  Positionsmeldung. Es folgen fünf Bytes: ADDR_L, ADDR_H, TYPE, LOCATION_L, LOCATION_H

  MSG_BM_POSITION Parameter

  Parameter	Beschreibung
  ADDR[2]	Adresse des meldenden Dekoders, kodiert wie oben beschrieben.
  TYPE	Art der Ortsangabe: 0: Ortsmarke mit vom Anwender vergebener 16-Bit-Kennung 1: Funkzelle mit logischer Kennung (vgl. FEATURE_CELL_NUMBER) 2…255: reserviert
  LOCATION[2]	Ortsangabe des Dekoders, Lowbyte wird zuerst übertragen.

  Positionsmeldungen werden gesendet, wenn ein Fahrzeugdekoder über bidirektionale Nachrichten seine Position bekanntgibt. Diese bestimmt er üblicherweise aus Ortsmarken, die ihre Kennnung (ID, auch: Adresse) per Infrarot oder Ähnlichem direkt an das Fahrzeug übertragen. Auch beim Wechsel zwischen Funkzellen kann der Dekoder den Host über die neue Verbindung informieren. Im Gegensatz zu Belegtmeldungen, bei denen die Fahrzeuge von einem fest installierten Sensor detektiert werden und je Meldeabschnitt (MNUM) ein oder mehrere Dekoderadressen vorliegen können, wird hier jeder Dekoderadresse eine Ortskennung pro Typ zugeordnet.

  MSG_BM_POSITION wird nur spontan gemeldet und kann nicht abgefragt werden. Durch Setzen oder Löschen des FEATURE_BM_POSITION_ON kann die Übertragung zu- oder abgeschaltet werden.

  Ist das FEATURE_BM_POSITION_SECACK aktiviert, muss der Host sofort eine MSG_BM_MIRROR_POSITION mit demselben Inhalt an den Detektor zurücksenden. Bis diese Quittung eingetroffen ist, wird die Nachricht im eingestellten Intervall mehrfach wiederholt. Um keine Meldungsflut zu verursachen, ist die Zahl der Wiederholungen zu begrenzen; längere Ausfälle werden vom Businterface behandelt. Liegt die Quittung danach immer noch nicht vor, wird eine Fehlermeldung mit dem Code BIDIB_ERR_NO_SECACK_BY_HOST gesendet.

  Es soll darauf geachtet werden, je Dekoder erst dann eine neue Position zu melden, wenn die vorherige bestätigt worden ist.

  MSG_BM_POSITION-Nachrichten mit Adressfeld = extended Accessory werden von stationären Empfängern gesendet, die zur Identifikation von Ortsmarken dienen.

4.8. Booster

4.8.1. Ansteuerung von Boostern

Booster dienen zum Verstärken und Aufbereiten des Gleissignals, je nach Größe der Modellanlage können diese mehrfach vorhanden sein.

Booster verstärken das Gleissignal und stellen es an ihrem Ausgang zur Verfügung. Hierzu verwenden sie ein eigenes Netzteil. Wenn als Busmedium BiDiBus verwendet wird, so wird über den Bus auch das DCC-Signal (mit RS485-Pegeln) übertragen.

Booster haben fallweise Diagnosemöglichkeiten (Ausgangsstrom und -spannung messen, Kurzschlusserkennung), Bedienmöglichkeiten (An- und Abschalten), und können einen globalen Detektor für railcom enthalten. In diesem Fall ist der Booster in der Lage, entsprechende Nachrichten zu senden (siehe auch Klasse Belegtmelder). Er verwendet den Wert 255 für das MNUM-Feld.

Kontrolle von Boostern:

Prinzipiell wird zwischen dem Zustand der Gleisausgabe (GO, SOFTSTOP, STOP) und dem Zustand der Booster unterschieden, d.h. auch wenn die Gleisausgabe auf STOP geht, bleiben die Booster in Betrieb. Erst wenn die Gleisausgabe komplett abgeschaltet wird, schalten auch die Booster ab. Dies ist notwendig, um ein versehentliches Losfahren der Lokomotiven bedingt durch die Analogerkennung in den Dekodern zu verhindern.

Es kann der Fall eintreten, dass Booster am Ausgang gegenseitig verbunden sind (z. B. durch ein Fahrzeug, welches gerade eine Versorgungsgrenze überbrückt). BiDiB trägt dem Rechnung und legt fest, dass Boosternachrichten i. d. R. als Broadcast zu verteilen sind. Der Host schickt daher eine Änderung des Boosterzustand (ON, OFF) nur an das Interface, dieses sendet die Nachricht als Broadcast an alle angeschlossenen Booster.

Es ist auch möglich, einzelne Booster gezielt an- oder abzuschalten (durch direkte Adressierung). Egal ob ein Booster über Broadcast oder individuell umgeschaltet wurde, er meldet immer seinen Statuswechsel an den Host. Das bedeutet z. B. wenn man ein System mit 10 Boostern hat und sendet an das Interface MSG_BOOST_ON (Broadcast), so entstehen 10 MSG_BOOST_STAT-Nachrichten.

Mehrere Gleisausgabeknoten und Booster:

Es ist denkbar, dass nicht nur das Interface eine Gleissignalerzeugung meldet, sondern auch weitere Knoten (z. B. separate DCC-Schaltansteuerung). Diese Knoten sind dann vom Host mit separatem BOOST_ON bzw. BOOST_OFF anzusteuern. Sollte einem solchen Knoten eine Unterstruktur mit weiteren Boostern zugeordnet sein, dann gelten die Broadcast nur für diesen Teilast, vom Hauptverteiler ist das abgekoppelt.

4.8.2. Features für Booster

Enthält der Booster einen globalen Detektor für BiDi-Nachrichten von Dekodern, so muss er zusätzlich die entsprechenden Features (siehe BiDi-Detektoren) unterstützen.

4.8.3. Downlink: Nachrichten für Booster

• MSG_BOOST_ON:

  Mit diesem Befehl wird die Gleisspannung eingeschaltet. Es folgt ein Byte (UNICAST), welches definiert, ob die Nachricht als Broadcast weiterverteilt werden soll oder nicht. Der Knoten antwortet mit MSG_BOOST_STAT.

  Kodierung von Unicast

  Wert	Bedeutung
  0	Ein Interface muss diese Nachricht als Broadcast an alle angeschlossenen Knoten verteilen, damit das Einschalten der Booster möglichst synchron erfolgt. Die Einschaltnachricht gilt für den Interfaceknoten sowie alle dem Interface nachgelagerten Knoten, die das Gleissignal aus dem Bus entnehmen.
  1	Die Einschaltnachricht gilt nur für diesen Knoten

  Es ist zu beachten, dass Booster auch über einen Statuswechsel der DCC-Erzeugung eingeschaltet werden können, sofern dies nicht durch ein gesetztes Feature FEATURE_BST_INHIBIT_AUTOSTART blockiert ist.

  Wenn im Moment des Einschaltens kein DCC vorhanden ist, dann schaltet der Booster nicht ein. Daraus ergeben sich je nach Einschaltreihenfolge unterschiedliches Verhalten:

  • Zuerst DCC der Gleisausgabe einschalten, dann MSG_BOOST_ON(0): alle Booster schalten ein (keine Ausnahme)
  • Zuerst MSG_BOOST_ON(0), dann DCC der Gleisausgabe einschalten: alle Booster schalten ein, ausgenommen diejenigen Booster, bei denen FEATURE_BST_INHIBIT_AUTOSTART gesetzt ist.
• MSG_BOOST_OFF:

  Mit diesem Befehl wird die Gleisspannung ausgeschaltet. Es folgt ein Byte (UNICAST), welches definiert, ob die Nachricht als Broadcast weiterverteilt werden soll oder nicht. Der Knoten antwortet mit MSG_BOOST_STAT.

  Kodierung von Unicast

  Wert	Bedeutung
  0	Ein Interface muss diese Nachricht als Broadcast an alle angeschlossenen Knoten verteilen. Die Nachricht gilt für den Interfaceknoten sowie alle dem Interface nachgelagerten Knoten, die das Gleissignal aus dem Bus entnehmen.
  1	Die Nachricht gilt nur für diesen Knoten.

• MSG_BOOST_QUERY:

  Es folgen keine weiteren Daten. Mit diesem Befehl wird der Status des Boosters abgefragt. Sofern Spannungs- oder Strommessung verfügbar ist, wird auch diese mit übermittelt.

  Der Knoten antwortet mit einer MSG_BOOST_STAT und optional MSG_BOOST_DIAGNOSTIC.

4.8.4. Uplink: Nachrichten für Booster

Booster können neben ihrem Status auch Stromverbrauch und Bidi-Ergebnisse melden. Falls dies unterstützt wird, werden dazu die Bidi-Detektor-Nachrichten verwendet. Bei der Gleisausgabe können bei Boostern sowohl behebbare als auch permanente Fehler auftreten. Mögliche Fehler sind z. B. Übertemperatur, Fremdspeisung, Kurzschluss, ...

Noch in Diskussion: Soll man diese mit einer eigenen Nachricht übermitteln oder besser in Status kodieren.

• MSG_BOOST_STAT:

  Nach einer Statusänderung des Boosters wird diese Nachricht abgesendet. Diese Statusänderung kann durch einen Hostbefehl oder durch Hardwarebedingungen hervorgerufen sein. Es folgt ein Byte mit dem Status, generell kodiert dabei das MSB den Einschaltzustand, das nächste Bit die Zuordnung des Booster zur Busstruktur (DCC-Eingang), weitere Bits kennzeichnen darüber hinausgehende Zustände:

  Kodierung des Booster-Status

  Bit	Bedeutung
  7	Betriebszustand 0 Booster ist abgeschaltet. 1 Booster ist eingeschaltet.
  6	Buszugehörigkeit (für DCC-Signal) 0 Booster ist dieser Busstruktur zugeordnet (default). 1 Booster ist anderem Bus zugeordnet (Sonderfall, z.B. für DCC-Domainübergang).
  5…0	Zusätzliche Information zum Boosterzustand.

  Kodierung des Booster-Status

  Wert	Name	Bedeutung
  0x00	BIDIB_BST_STATE_OFF	Booster ist abgeschaltet (allgemein, z. B. aufgrund Host-Befehl).
  0x01	BIDIB_BST_STATE_OFF_SHORT	Booster ist abgeschaltet (wegen Kurzschluss).
  0x02	BIDIB_BST_STATE_OFF_HOT	Booster ist abgeschaltet (wegen Übertemperatur).
  0x03	BIDIB_BST_STATE_OFF_NOPOWER	Booster ist abgeschaltet (wegen fehlender Netzspannung).
  0x04	BIDIB_BST_STATE_OFF_GO_REQ	Booster ist abgeschaltet und es liegt eine Einschalt-Anforderung vor.
  0x05	BIDIB_BST_STATE_OFF_HERE	Booster ist abgeschaltet (aufgrund lokalen Tastendrucks).
  0x06	BIDIB_BST_STATE_OFF_NO_DCC	Booster ist abgeschaltet (wegen fehlendem Eingangssignal).
  0x80	BIDIB_BST_STATE_ON	Booster ist eingeschaltet.
  0x81	BIDIB_BST_STATE_ON_LIMIT	Booster ist eingeschaltet und läuft in der Strombegrenzung.
  0x82	BIDIB_BST_STATE_ON_HOT	Booster ist eingeschaltet und ist im kritischen Temperaturbereich.
  0x83	BIDIB_BST_STATE_ON_STOP_REQ	Booster ist eingeschaltet und es liegt eine Stop-Anforderung vor.
  0x84	BIDIB_BST_STATE_ON_HERE	Booster ist eingeschaltet (aufgrund lokalen Tastendrucks).

  Hinweis: GO- oder STOP-Anforderungen können fallweise dezentral anfallen (z. B. durch auf der Anlage verteilte Notaustaster), das Feature FEATURE_BST_INHIBIT_LOCAL_ONOFF entscheidet in diesem Fall über das Verhalten:

  • Fehlt dieses Feature oder ist der Wert = 0, dann wird mit dem Nothalttastern das komplette Gleisausgabesystem angehalten, d.h. ein Tastendruck löst einen Low-Puls auf der ACK-Leitung im BiDiBus aus und führt so zu einem Stop der Gleisausgabe im Master. Als Folge schalten alle Booster wegen fehlendem DCC ab.
    Derjenige Booster, welcher den ACK-Puls ausgelöst hat, meldet seinen Zustandswechsel mit BIDIB_BST_STATE_OFF_HERE, alle anderen melden ihren Zustandswechsel mit BIDIB_BST_STATE_OFF. Der Host kann so feststellen, von welchem Anlagenteil aus der Nothalt ausgelöst wurde.
  • Ist der Wert des Features = 1, so wird bei Tastendruck kein ACK-Puls ausgelöst, sondern der entsprechende Knoten meldet diesen Tastendruck mit einer BIDIB_BST_STATE_ON_STOP_REQ, d.h. er bleibt an und sendet die Stop-Anforderung an den Host. Es liegt nun im Ermessen des Hostprogrammes, ob es Softstop, Nothalt oder bestimmte Anlagenteile abschaltet.
• MSG_BOOST_DIAGNOSTIC:

  Diagnose-Meldung eines Booster als Liste, diese umfasst z. B. Strom-Meldung, Spannung, Temperatur.

  Die Meldewerte sind jeweils Paare, bestehend aus einer Kennung der Meldungsart und dem Meldewert.

  DIAG_LIST ::= DIAG_PAIR | DIAG_PAIR DIAG_LIST
  DIAG_PAIR ::= DIAG_ENUM DIAG_VALUE

  Kodierung der Booster-Diagnostik

  Name	Code	Bedeutung
  BIDIB_BST_DIAG_I	0x00	Stromwert. Wert Bedeutung 0 kein Stromverbrauch, Gleis ist frei. 1…15 Stromverbrauch, in mA. Möglicher Bereich: 1…15mA 16…63 Stromverbrauch, Wert ist (Datum - 12) * 4mA. Möglicher Bereich: 16…204mA 64…127 Stromverbrauch, Wert ist (Datum - 51) * 16mA. Möglicher Bereich: 208…1216mA 128…191 Stromverbrauch, Wert ist (Datum - 108) * 64mA. Möglicher Bereich: 1280…5312mA 192…250 Stromverbrauch, Wert ist (Datum - 171) * 256mA. Möglicher Bereich: 5376…20224mA 251…253 reserviert. 254 Overcurrent aufgetreten. 255 kein exakter Verbrauch bekannt.
  BIDIB_BST_DIAG_V	0x01	Spannungswert. Wert Bedeutung 0…250 Spannung in der Einheit 100mV. 251…254 reserviert. 255 kein exakter Spannungswert bekannt.
  BIDIB_BST_DIAG_TEMP	0x02	Temperatur (signed char). Wert Bedeutung 0…127 Temperatur in der Einheit Grad Celsius. 128 … 225 reserviert. 226 … 255 negative Temperatur.

  Hinweise:

  Diese Nachricht ersetzt die bisherige MSG_BOOST_CURRENT

  Der Stromwert ist kodiert wie beim Belegtmelder.

  Die übermittelten Felder sind optional. Wenn ein Knoten ein bestimmte Messung nicht verfügbar hat, dann darf er den entsprechenden Feldtyp weglassen. Die Nachricht muss jedoch mindestens ein Feld enthalten.

  Die Häufigkeit der Diagnose-Meldung wird mit dem Feature FEATURE_BST_CURMEAS_INTERVAL eingestellt.

4.9. Verteilte Steuerung

4.9.1. Kommunikation mit anderen Bediengeräten

Eine Modelleisenbahnsteuerung besteht fallweise aus mehreren mehr oder minder autonomen Komponenten. Der Anwender trifft Eingaben durch sie oder möchte Rückmeldung durch Statusanzeigen und -meldungen bekommen. All diese Systeme müssen in die Steuerung und Absicherung einbezogen werden und benötigen dazu Zugriff auf das BiDiB-System in verschiedener Tiefe. Zu ihnen gehören unter anderem:

• Handregler für Fahrzeuge
• Stellpulte für Fahrwege
• Besetztmeldungsanzeigen und Zugnummernfelder
• Nothalttaster
• Schalttafeln für Zubehör und Licht
• Monitoring-Anwendungen
• Steuerungsprogramme
• Konfigurationsprogramme

Auf technischer Seite werden auch Anwendungen ermöglicht wie:

• Bus-Logger
• Netzbrücken
• Bus-Umschalter
• Verteilerdienste

Das Konzept eines zentralen Hosts, der alleine für den sicheren Betrieb verantwortlich ist und die volle Kontrolle über sein BiDiB-Netz ausübt, wird dabei nicht aufgegeben. Er sitzt an der Wurzel des Adressbaumes, empfängt alle Upstream-Nachrichten von den ihm untergebenen Knoten und sendet alle Downstream-Nachrichten.

Ein Host kann als Gastgeber einen Gastzugang bereitstellen, auf dem er verschiedene Dienste zum Zugriff auf sein Netz anbietet. Andere Bediengeräte können sich als Gast mit diesem Gastgeber verbinden und verschiedene Anfragen (Requests) schicken.

Ein Host ist nicht verpflichtet, irgendwelche Dienste bereitzustellen. Spontannachrichten mit Anfragen von Gästen kann er durch MSG_SYS_DISABLE unterbinden. Ein Gastgeber ist jederzeit dazu berechtigt, Anfragen abzuweisen.

Empfängt ein Gastgeber eine Anfrage oder will er von sich aus etwas mitteilen, kann er dem Gast auf dem jeweiligen Weg eine Antwort (Response) zukommen lassen.

Gast-Knoten können unterschiedlich ausgeprägt sein: Es kann sich um eine in Hardware ausgeführte Baugruppe handeln, die eine physische Benutzerschnittstelle enthält. Der Knoten kann aber auch rein der Kommunikation zwischen autonomen Geräten dienen und etwa als Programmierschnittstelle (API) oder Netzwerkschnittstelle ausgeführt sein. Eine solche Software-Instanz zeichnet sich unter anderem dadurch aus, dass sie eine zufällig erzeugte Unique-ID verwenden kann (vgl. netBiDiB). Zum Ausgleich dafür sind die MSG_STRING_*-Nachrichten für Produktname und Username verpflichtend, der Username soll auch direkt beim Start oder in den Einstellungen der Software vergeben werden können.

4.9.2. Kontrolle und Adressierung

Ein Gast, der die Kontrolle über einen Teil des BiDiB-System übernehmen möchte, kommuniziert ausschließlich mit dem Gastgeber, der seinerseits die volle Verantwortung über das System hat. Für den Zugriff auf Knoten kapselt der Gast die üblichen BiDiB-Downstream-Nachrichten (konkret deren Typ und Datenteil) in REQ_SEND-Nachrichten ein und sendet das Gesamtpaket an den Gastgeber. Der Gastgeber dient dabei als Stellvertreter des Zielknotens (Proxy) und leitet die eingekapselten Nachrichten nach erfolgreicher Prüfung der Zugriffsrechte an den vom Gast adressierten Knoten weiter. In Gegenrichtung werden Antworten sowie die abonnierte Kommunikation mit dem Zielknoten vom Gastgeber in RESP_NOTIFY-Nachrichten eingekapselt und an den Gast gesendet.

Ein Gast-Knoten erfährt per MSG_SYS_ENABLE, ob der Host Gast-Nachrichten unterstützt. Er darf nicht einfach spontan Nachrichten senden (ohne je eine Antwort zu bekommen). Bekommt er eine MSG_SYS_ENABLE ohne dass Gast-Nachrichten erlaubt werden, soll er eine Fehlermeldung zeigen.

Um Anfragen zu den von ihm kontrollierten Knoten entsprechend beantworten zu können, verwaltet ein Gastgeber eine Struktur in der gespeichert ist, welche Nachrichtenarten von welchen Knoten an welche Gäste weitergeleitet werden sollen. Bekommt er eine Anfrage eines Gastes, an einen bestimmten Knoten eine bestimmte Nachrichten zu senden, und lässt er dies zu (führt das Senden des Downstream-Befehls aus), so trägt er die erwarteten Antwortmöglichkeiten ein um beim Eintreffen der Upstream-Antwort diese an den Gast weiterleiten zu können.

Sämtliche Anfragen und Antworten beziehen sich auf einen bestimmten Knoten im System des Gastgebers. Dabei kann es sich sowohl um physische Baugruppen handeln, die über ein Bussystem an den Gastgeber angeschlossen sind, als auch um virtuelle Knoten (typischerweise mit VID=0), die vom Gastgeber simuliert werden. Der Gastgeber kann so auch beliebige interne Objekte abbilden (etwa Fahrstraßen, Blöcke, Berechtigungen, Fahrtaufträge, Zubehörabläufe etc) oder Legacy-Systeme ohne BiDiB-Unterstützung in das System integrieren. Der Gastgeber kann für diese Knoten ausgesuchte Nachrichtentypen implementieren und dem Gast so die Ausführung bestimmter Befehle ermöglichen, nicht implementierte Nachrichtentypen werden einfach immer abgelehnt.

Ein Knoten kann vom Gast auf verschiedene Weisen adressiert werden, die Zielangabe besteht aus einem Byte mit dem Modus und davon abhängigen weiteren Parametern. Der Gastgeber löst die Zielangabe in der Nachricht zu einer Knotenreferenz auf und diese weiter zu einer Session-Adresse. Mit dem TARGET_MODE wird die Art der gewünschten Zieladressierung beschrieben:

Das Format der Zielangabe TARGET in vom Gast gesendeten Nachrichten ist dabei durch den TARGET_MODE wie folgt unterteilt:

Ein Gastgeber muss nicht alle Arten der Zieladressierung unterstützen. Er muss jedoch die verschiedenen Formate verstehen und alle Nachrichten mit TARGET_MODE ≤ 0x10 beantworten, bei Nichtunterstützung mit RESULT=0xFF.

4.9.3. Request: Nachrichten von Gästen an Gastgeber

• MSG_GUEST_REQ_SUBSCRIBE:

  Der Gast bittet den Gastgeber, bestimmte Nachrichten an und von dem ausgewählten Knoten an den Gast weiterzumelden. Der Gastgeber merkt sich diese Abonnements, kann sie aber auch jederzeit auslaufen lassen.

  Der Gastgeber speichert dazu jede Gast-Zielknoten-Kombination. Ein Bitfeld zur groben Filterung, über welche Nachrichten von welchen Knoten der Gast informiert werden will, reicht dazu aus.

  Unterschieden wird zwischen Upstream und Downstream sowie dem Bereich, zu welchem der Nachrichtentyp gehört.

  Die definierten Nachrichtentypen im SUBSCRIPTION sind unabhängig vom verwendeten TARGET_MODE in der REQ_(UN)SUBSCRIBE Nachricht.

  REQ_(UN)SUBSCRIBE Parameter

  Parameter	Beschreibung
  TARGET[1;6]	Bestimmung des Zielknotens, bestehend aus TARGET_MODE und dessen Parametern — beim BIDIB_TARGET_MODE_UID folgen 5 Byte.
  SUBSCRIPTION[2]	Bitfeld mit der Auswahl, welche Nachrichen abonniert werden sollen: Bit Bedeutung 0 Downstream ⋮ Systemnachrichten (inkl. Hubnachrichten) 1 Feature- und Usernachrichten 2 Rückmeldernachrichten 3 Boosternachrichten 4 Port- und Makronachrichten 5 Gast- & Hubnachrichten 6 Gleissignalnachrichten (inkl. Prog) 7 Accessorynachrichten 8…15 Upstream Jeweils wie Downstream (8: System etc.) Ein Wert von 0xFFFF abonniert alle Nachrichten.

  Der Gastgeber antwortet mit RESP_SUBSCRIPTION_COUNT und beginnt danach automatisch mit dem Versand von RESP_SUBSCRIPTION für jeden aufgelösten Knoten.

  Hinweise:

  Falls das Ziel des Abonnements der anfragende Knoten selbst oder einer seiner Unterknoten ist, sollte das Abonnement mit entsprechendem RESULT-Code abgelehnt werden.

  Der Gastgeber akzeptiert auch Abonnements für Zielknoten, die (noch) nicht mit dem System verbunden sind, um reibungsloses Plug-and-Play zu ermöglichen. Der Gast wird vom Gastgeber über Änderungen des Verbindungsstatus mit einer Nachricht RESP_NOTIFY[TARGET=…, SUB_MSG_NUM=0, SUB_MSG_TYPE=MSG_LOCAL_LOGON/LOGOFF] unterrichtet.

  Verschiedene Targetmodes (insbesondere 0x08…0x0F) können zum selben Knoten aufgelöst werden. Dies ist an der TARGET_UID in der Antwort erkennbar.

  Mehrere verschiedene REQ_SUBSCRIBE auf den gleichen Knoten erweitern bestehende Abonnements.

  Zum Löschen von bestimmten Abonnements ist REQ_UNSUBSCRIBE zu verwenden.

  Abonnements mit BIDIB_TARGET_MODE_SWITCH, BIDIB_TARGET_MODE_BOOSTER, BIDIB_TARGET_MODE_ACCESSORY, BIDIB_TARGET_MODE_DDCGEN sowie BIDIB_TARGET_MODE_HUB werden auf alle betreffenden Knoten anhand ihrer Classbits aufgelöst.
  Der Gastgeber antwortet mit RESP_SUBSCRIPTION pro aufgelösten Knoten.

  Das Abonnement mit dem BIDIB_TARGET_MODE_ALL wird auf alle aktuell verbundenen Knoten außer dem Gastknoten selbst und seiner Unterknoten aufgelöst.
  Der Gastgeber antwortet mit RESP_SUBSCRIPTION pro aufgelösten Knoten.

  SUBSCRIPTION Bit 5 ist bevorzugt zu verwenden, wenn der Gast lediglich an Veränderungen der Baumstruktur (NODE_NEW/NODE_LOST) interessiert ist.

  MSG_SYS_ERROR Nachrichten eines Knotens werden immer an den Gast weitergeleitet, sobald eine Gast-Zielknoten-Kombination - unabhängig vom Abonnementumfang - besteht.

  Mit der Abmeldung des Gastes vom System (MSG_NODE_LOST) verfallen alle Abonnements. Ebenso sollte der Gastgeber bei Reinitialisierung (MSG_SYS_GET_MAGIC, MSG_SYS_DISABLE) oder Neustart (MSG_SYS_RESET) des Gastknotens alle bestehenden Abonnements löschen und dies dem Gast mittels RESP_SUBSCRIPTION[TARGET=…, RESULT=0x80, SUBSCRIPTION=0x0000] mitteilen.

  Dem Gastgeber steht es frei virtuelle Knoten zu implementieren die mehrere Knoten für einen TARGET zusammenfassen. Dem Gast gegenüber erscheint so die Einrichtung des Abonnements auf einen einzigen Knoten.

• MSG_GUEST_REQ_UNSUBSCRIBE:

  Der Gast bittet den Gastgeber, das Weiterleiten bestimmter Nachrichten an und von dem ausgewählten Knoten an den Gast zu beenden.

  Der Gastgeber antwortet mit RESP_SUBSCRIPTION_COUNT und beginnt danach automatisch mit dem Versand von RESP_SUBSCRIPTION für jeden aufgelösten Knoten, welcher den aktuellen Stand der ggf. weiterhin bestehenden Abonnements beinhaltet.

  Es werden die gleichen Parameter wie für REQ_SUBSCRIBE verwendet.

• MSG_GUEST_REQ_SEND:

  Der Gast fordert den Gastgeber auf, die verpackte Nachricht an den ausgewählten Knoten zu senden.

  REQ_SEND Parameter

  Parameter	Beschreibung
  TARGET[1;6]	Bestimmung des Zielknotens, bestehend aus TARGET_MODE und dessen Parametern — beim BIDIB_TARGET_MODE_UID folgen 5 Byte.
  REQ_MSG_TYPE	Nachrichtentyp der zu sendenden Nachricht
  REQ_DATA[0…N]	Weitere Parameter der zu sendenden Nachricht

  Der Gastgeber prüft, ob die Nachricht gesendet werden kann, und schickt sie fallweise an den Zielknoten. Die Sequenznummer (MSG_NUM) wird dazu vom Gastgeber generiert. Er antwortet in jedem Fall mit RESP_SENT als Empfangsbestätigung der Anfrage (solange TARGET_MODE ≤ 0x10).

  Hinweise:

  Erhält der Gastgeber die Antwort auf die gesendete Nachricht vom Zielknoten, leitet er sie per RESP_NOTIFY an den Gast weiter, sofern dieser zuvor ein Abonnement für den entsprechenden Nachrichtentyp eingerichtet hat.

  Bei Nachrichten zur Abfrage des Knotens, dessen Ergebnisse bereits lokal im Gastgeber vorliegen, darf und soll der Gastgeber das Senden überspringen und direkt die entsprechende Antwort generieren. Dies gilt insbesondere für Systemnachrichten zur Busverwaltung (Knotentabelle), Feature-Einstellungen und String-Variablen, Zustände von Gleisausgaben oder Boostern, Belegtmeldungen und Accessory-Zustände.

4.9.4. Response: Nachrichten von Gastgebern an Gäste

Unabhängig vom Targetmode folgt in den Antworten vom Gastgeber an den Gast auf TARGET_MODE (1 Byte) immer TARGET_UID (5 Byte).

• MSG_GUEST_RESP_NOTIFY:

  Der Gastgeber benachrichtigt den Gast über eine abonnierte Nachricht.

  RESP_NOTIFY Parameter

  Parameter	Beschreibung
  TARGET_MODE	Der TARGET_MODE des Abonnements. Der aktuelle Wert ist immer BIDIB_TARGET_MODE_UID.
  TARGET_UID[5]	Bestimmung des Knotens, der die Upstream-Nachricht gesendet hat bzw. an den die Downstream-Nachricht addressiert ist. Bestehend aus 5 Bytes mit der VID und PID, also der Unique-ID ohne die Klassenbits.
  SUB_MSG_NUM	Nachrichtennummer der vom Gastgeber empfangenen bzw. gesendeten Nachricht, oder 0 wenn die Nachricht lokal vom Gastgeber erzeugt wurde.
  SUB_MSG_TYPE	Nachrichtentyp der vom Gastgeber empfangenen bzw. gesendeten Nachricht. Das MSB des Typs kodiert, ob es eine Nachricht vom Gastgeber an das Ziel oder eine Nachricht vom Ziel an den Gastgeber ist.
  SUB_DATA[0…N]	Weitere Parameter der vom Gastgeber empfangenen bzw. gesendeten Nachricht

  Hinweise:

  Voraussetzung für jegliche RESP_NOTIFY Nachrichten ist in jedem Fall ein bestehendes Abonnement für den entsprechenden Nachrichtentyp und die Richtung.

  Der Gastgeber sendet RESP_NOTIFY, wenn er vom Zielknoten eine Nachricht empfängt oder wenn er selbst eine Nachricht an den Zielknoten sendet.
  Dies kann insbesondere die Reaktion auf REQ_SEND mit einer Zustandsabfrage sein, wenn der Gastgeber die angefragte Information lokal vorrätig hat.

  RESP_NOTIFY wird maximal einmal pro Nachricht gesendet, auch wenn der Gast sowohl ein globales als auch ein knotenspezifisches Abonnement eingerichtet hat.

  Der Host sorgt wie üblich für Quittungen (NODE_CHANGED_ACK, SecureACK, SecureSwitch) gegenüber dem Zielknoten. Der Gast sollte ebenso Quittungen via REQ_SEND senden, es ist empfohlen (aber nicht verpflichtend) dass der Host die Quittungen pro Gast überprüft (zum Beispiel wenn ein Gast die Bestätigung sendet aber ein zweiter Gast nicht).

• MSG_GUEST_RESP_SENT:

  Der Gastgeber bestätigt dem Gast, dass er eine REQ_SEND-Nachricht bekommen hat und was damit geschehen ist.

  RESP_SENT Parameter

  Parameter	Beschreibung
  TARGET_MODE	Der TARGET_MODE aus der REQ_SEND-Nachricht.
  TARGET_UID[5]	Bestimmung des Zielknotens, zu dem das TARGET der REQ_SEND-Nachricht aufgelöst wurde. Bestehend aus 5 Bytes mit der VID und PID, also der Unique-ID ohne die Klassenbits. Mit dieser UID werden später eventuelle Antworten des Zielknotens via RESP_NOTIFY übertragen.
  ACK_SEQ	Die Sequence-Number der bestätigten bzw. abgelehnten REQ_SEND-Nachricht.
  RESULT	Bestätigung, dass die angeforderte Nachricht gesendet wurde (MSB=0), oder warum dies nicht geschah (MSB=1). Bit 7 Bit 6…0 Bedeutung 0 OK 0 Der Anfrage des Gastes wurde entsprochen. In den DETAILS folgt ein Byte, welches die Zuordnung von Host-Nachrichten zu Gast-Wünschen erlaubt. Die Antwort des Zielknotens wird noch erwartet und dann über RESP_NOTIFY gemeldet. 1 Der Gastgeber konnte der Anfrage des Gasts entsprechen, die Antwort vom Zielknoten ist bereits eingetroffen oder lag lokal vor. Sie wird dem Gast direkt im Anschluss über RESP_NOTIFY mitgeteilt. Es folgen keine Daten in den DETAILS. Der Gastgeber kann den Request auch "akzeptieren" während die Antwort vom Zielknoten noch aussteht, und einfach die zu erwartende Antwort liefern (mit SUB_MSG_NUM=0). Der Gastgeber kümmert sich dann um die Umsetzung der Anfrage inklusive Fehlerbehandlung und Nachrichtenwiederholung. 2 Der Gastgeber konnte der Anfrage des Gasts entsprechen, die Antwort wird noch erwartet. In den DETAILS folgen drei Byte, eine SEQ_NUM welche die Zuordnung von Host-Nachrichten zu Gast-Wünschen erlaubt sowie ein Bitfeld zur Beschreibung des aktuell gültigen Filters (wie bei RESP_SUBSCRIPTION). Der Gastgeber ist nicht für eine Wiederholung der Nachricht zuständig 1 Grund für die Ablehnung. Der Anfrage des Gastes konnte nicht entsprochen werden. 125 Der Zielknoten konnte nicht eindeutig aufgelöst werden. 126 Der als Ziel angegebene Knoten ist nicht mit dem System verbunden. Äquivalent zu NODE_NA auf TARGET_MODE-Ebene 127 Der angefragte TARGET_MODE wird nicht unterstüzt. Der TARGET_UID-Parameter wird als 0 übertragen.
  DETAILS[0…N]	Abhängig von RESULT werden hier verschiedene Daten übertragen. Im Gutfall wird die Sequence-Number der vom Host an den Zielknoten gesendeten Nachricht angegeben, sofern die Antwort nicht bereits im Host vorlag. Im Falle einer Ablehnung (0x80) wird optional ein Präfix der zu sendenden Nachricht angegeben, für welche die Einschränkung gilt. Kein Präfix bedeutet, dass sämtliche Nachrichten mit diesem Grund abgelehnt werden. Ein Präfix von einem Byte bedeutet, dass nur dieser Nachrichtentyp abgelehnt wurde. Ein Präfix von mehreren Byte bedeutet, dass nur dieser Nachrichtentyp bezogen auf den bestimmten Teil des Knotens abgelehnt wurde. Beispiel: RESULT=0x80, DETAILS=[MSG_CS_DRIVE, 15, 0] bedeutet, dass das Fahrzeug mit der Adresse 15 nicht vom Gast gesteuert werden darf. Für andere Adressen oder Nachrichtentypen liegt möglicherweise keine Einschränkung vor.

• MSG_GUEST_RESP_SUBSCRIPTION_COUNT

  Diese Nachricht wird zu Beginn der Übertragung gesendet, wenn der Gast mit MSG_GUEST_REQ_SUBSCRIBE/UNSUBSCRIBE angefragt hat.

  RESP_SUBSCRIPTION_COUNT Parameter

  Parameter	Beschreibung
  TARGET_MODE	Der TARGET_MODE aus der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht.
  TARGET_UID[5]	Bestimmung des Zielknotens, zu dem das TARGET der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht aufgelöst wurde. Bestehend aus 5 Bytes mit der VID und PID, also der Unique-ID ohne die Klassenbits. Die abonnierten Nachrichten später mit dieser UID in RESP_NOTIFY übertragen.
  ACK_SEQ	Die Sequence-Number der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht.
  RESULT	Quittung Wert Bedeutung 0 OK, Abonnement eingerichtet 0x80 Abonnements werden (für den Zielknoten) nicht unterstützt 0x81 Abonnement konnte nicht eingerichtet werden: das Ziel ist der Abonnent selbst oder ein Unterknoten. 0xFE Abonnement konnte nicht eingerichtet werden, weil der Nachrichtentyp vom Knoten nicht unterstützt wird 0xFF Der verwendete TARGET_MODE wird nicht unterstüzt, vgl. RESP_SENT.
  COUNT[2]	Zwei Bytes mit der Anzahl der entsprechend des TARGET aufgelösten Knoten.

• MSG_GUEST_RESP_SUBSCRIPTION:

  Der Gastgeber bestätigt ein Nachrichtenabonnement des Gasts oder teilt eine Änderung mit.

  RESP_SUBSCRIPTION Parameter

  Parameter	Beschreibung
  TARGET_MODE	Der TARGET_MODE aus der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht.
  TARGET_UID[5]	Bestimmung des Zielknotens, zu dem das TARGET der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht aufgelöst wurde. Bestehend aus 5 Bytes mit der VID und PID, also der Unique-ID ohne die Klassenbits. Die abonnierten Nachrichten später mit dieser UID in RESP_NOTIFY übertragen.
  ACK_SEQ	Die Sequence-Number der REQ_SUBSCRIBE/REQ_UNSUBSCRIBE-Nachricht.
  RESULT	Quittung Wert Bedeutung 0 OK, Abonnement eingerichtet 0x80 Abonnements werden (für den Zielknoten) nicht unterstützt 0x81 Abonnement konnte nicht eingerichtet werden: das Ziel ist der Abonnent selbst oder ein Unterknoten. 0xFE Abonnement konnte nicht eingerichtet werden, weil der Nachrichtentyp vom Knoten nicht unterstützt wird 0xFF Der verwendete TARGET_MODE wird nicht unterstüzt, vgl. RESP_SENT.
  SUBSCRIPTION[2]	Aktive Nachrichtenauswahl, als Bitfeld wie bei REQ_SUBSCRIBE/REQ_UNSUBSCRIBE

© Wolfgang Kufer 28.10.2010, update 17.03.2024, (www.bidib.org)

('RailCom' ist ein eingetragenes Warenzeichen der Lenz GmbH, Giessen)