BiDiB, ein universelles Steuerprotokoll für Modellbahnen

Nachrichten für Fahrwegzubehör

BiDiB - Bidirektionaler Bus - Logo

Inhaltsverzeichnis

Allgemeines

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

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

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

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

Revisionsstand

Dieses Dokument beschreibt Revision 1.27 von BiDiB, Stand 07.04.2017.

Die Revisionsgeschichte ist dem allgemeinen Teil zu entnehmen.

4.6. Accessory und Zubehör/Schaltfunktionen

Übersicht Zubehöransteuerung in BiDiB
1. Accessory 2. Schaltanwendungen 3. Makro
für Objekte mit einem Zustand, Einsatz 'am Gleis', also für Weichen und Signale. für Dinge 'neben' dem Gleis, also Beleuchtung, Animation, Sound, Bedienfelder, usw. für die Zusammenfassung von Schaltbefehlen zu lokalen Abläufen.

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.

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.

Beispiel 1: Angenommen, es gibt 12 Abgänge, dann sind die Abgänge 0 und 6, 1 und 7, 2 und 8, usw. jeweils gegenüberliegend.

Beispiel 2: Ein Wenden auf der Drehscheibe kann dadurch erreicht werden, dass man aus dem aktuellen Begriff mittels new = (current + total / 2) % total den neuen Begriff errechnet.

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.

Beispiel: Ein Lichthauptsignal mit Geschwindigkeitsanzeiger wird mit zwei Accessorys repräsentiert, eines für den Signalbegriff und eines für die Geschwindigkeitskennziffer. Ein darüberhinaus installierter Geschwindigkeitsvoranzeiger würde über ein drittes Accessory dargestellt. Dies ist einfacher als alle möglichen Kombinationen der Signalbilder in einem Accessoryzustand zu vereinen.

Auch wenn das Zusatzsignal implizit erlischt sobald Hp 0 gezeigt wird, ändert sich beim Schalten des Signalbegriffs nicht der Aspect auf "keine Geschwindigkeit anzeigen", eine Abfrage liefert weiter den eingestellten Wert. Die Begriffskombination "Hp 0"+"Ziffer 3" führt zum selben Signalbild wie "Hp 0"+"keine Ziffer", ohne dass der Host dies gesondert berücksichtigen muss.

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.

Aufstellung der Features für die Accessory-Control-Klasse
NummerNameBedeutung
40 FEATURE_ACCESSORY_COUNT Anzahl der Weichen / Signale auf diesem Knoten
Hier wird die Anzahl der steuerbaren Objekte abgefragt. Wertebereich: 0…128.
41 FEATURE_ACCESSORY_SURVEILLED Lage-Überwachung
0: Knoten meldet keine Verstellung
1: Knoten meldet bei Verstellung den neuen Zustand mit einer MSG_ACCESSORY_NOTIFY Nachricht.
42 FEATURE_ACCESSORY_MACROMAPPED Abbildung von Begriffen auf Macros
0: Knoten hat keine Abbildungsfunktion
1…n: Knoten bildet Begriffe bei Accessory auf Macros ab. Diese Zahl gibt auch an, wie viele Begriffe maximal auf ein Accessoryobjekt abgebildet werden könnten, d.h. wie viele verschiedene Begriffe max. konfiguriert werden können (nicht müssen). Die Anzahl tatsächlicher Begriffe des jeweiligen Accessory wird bei MSG_ACCESSORY_STATE übermittelt.

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
    ParameterBeschreibung
    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_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
    ParameterBeschreibung
    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
    WertNameBedeutung
    1-249   –   Reserviert.
    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.
    BitBedeutung
    7 Grundeinheit:
    0: 100ms (d.h. Wertebereich 0…12,7s)
    1: 1s (d.h. Wertebereich 0…127s)
    6…0Schaltzeit, 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
    ParameterBeschreibung
    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 7Bedeutung
    0 normale Operation
    BitBedeutung
    00: Zielzustand erreicht. WAIT ist 0.
    1: Zielzustand noch nicht erreicht. WAIT gibt die angenommene Restdauer an.
    10: Zielzustand wird durch Rückmeldung (z. B. Schaltkontakt) verifiziert.
    1: keine Kontrolle des Zielzustandes vorhanden.
    6…2reserviert, mit 0 zu belegen
    1 Fehler aufgetreten (z. B. Ausfall Spule / Handverstellung); WAIT gibt in diesem Fall die Ursache gemäß railcom-Spec an.
    BitBedeutung
    6…0reserviert, 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:
    BitBedeutung
    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:
    BitBedeutung
    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
    0x00Kein Fehler (mehr). Bei gesetztem Bit 6 ist das Ende der Fehlerliste erreicht, mit der nächsten Nachricht wird wieder von vorn begonnen.
    0x01unbekanntes 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.
    0x02Stromaufnahme des Antriebs zu hoch.
    0x03Versorgungsspannung zu gering, die Funktion ist nicht sichergestellt.
    0x04Sicherung defekt.
    0x05Temperatur zu hoch.
    0x06Rückmeldefehler (z. B. ungewollte Verstellung festgestellt, Schaltvorgang nicht erfolgreich). Der Fehlercode wird gegebenenfalls zusammen mit einem neuen Aspect, häufig 255 ("unbekannt"), übertragen.
    0x07Lokale Verstellung durch Anwender (z. B. per Taster am Decoder). Der Fehlercode wird gegebenenfalls zusammen mit dem neuen Aspect übertragen.
    0x10Weichenlaterne oder Signallaterne defekt
    0x20Servo defekt
    0x3FInterner 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
    NameCodeWerttypBedeutung
    BIDIB_ACC_DETAIL_CURR_ANGLE1DEG5 0x01 uint8 Aktueller Positionswinkel (etwa einer Drehscheibe) in Einheiten von 1,5 Grad, Wertebereich 0…239
    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 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.
    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.