DCC-Mapping

Beim Betrieb ohne Steuerungsprogramm als Host soll eine Steuerung von BiDiB-Knoten sowie DCC-Fahrzeugen und -Zubehör mit Handreglern o.ä. ermöglicht werden, die nur Befehle nach RCN 212 bzw. RCN 213 unterstützen.

Dazu müssen die vom Handregler empfangenen DCC-Adressen und -Aspekte auf die Aspekte und Accessorys eines BiDiB-Knoten für Zubehör (Aspect-Mapping) bzw. auf einen BiDiB-DCC-Generator-Knoten (Generator-Mapping) abgebildet werden.

Die dafür notwendigen Daten werden mithilfe der textbasierten Vendor-Nachrichten (siehe Kapitel Nachrichten zur Userkonfiguration) übertragen.

Aspekt-Mapping

Mit dem Aspekt-Mapping können DCC-Adressen und -Aspekte auf die Accessorys der BiDiB-Knoten für Zubehör und deren Aspekte abgebildet werden. Es handelt sich um eine N:M-Abbildung, die Zuordnung ist beliebig und Mehrfachzuordnungen sind möglich. Eine Zeile in der Speichertabelle entspricht daher einer Zuordnung eines DCC-Aspects zu einem BiDiB-Aspect. Die folgende Konvention beschreibt die Verwendung bestimmter Vendor-Nachrichten zur Übertragung einer solchen Tabelle vom Host zu einem Adapter-Knoten (typischerweise der Klasse Handregler oder Hub) und ermöglicht das Auflisten, Hinzufügen und Löschen von Zeilen.

Beispiel-Szenario:

Das Aspekt-Mapping wird vom Anwender als Teil der Anlagenkonfiguration erstellt und als AspectMapping-Tabelle in einem (oder mehreren) als DCC-Adapter fungierenden Knoten hinterlegt. Im Betrieb nimmt die Adapter-Applikation die DCC-Befehle vom Handregler entgegen, wandelt sie in das BiDiB-Format für Accessorys um und versendet sie gemäß der AspectMapping-Tabelle an die entsprechenden BiDiB-Knoten.

Format

Die Nachrichten folgen der Schlüssel/Wert-Vorgabe der allgemeinen BiDiB-Spezifikation: ASCII-Strings mit vorangestelltem Längen-Byte.

Der Schlüssel zur Identifikation eines Eintrags enthält neben einem Präfix (AME) die komplette Zuordnung, die einzelnen Teile sind durch jeweils ein Leerzeichen getrennt:

<VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>

Durch den Wert wird angegeben, ob die Zuordnung in der Tabelle existiert oder nicht (via 0x1 "1" bzw. 0x00 ""), was sowohl zum Schreiben als auch beim Lesen verwendet wird.

Verwendete Abkürzungen
KürzelNameBedeutungTyp
AME AspectMappingEntry Operation für einen Eintrag (entry) Konstante
AMR AspectMappingRange Operation für einen Bereich (range) Konstante
<VID><PID1><PID2><PID3><PID4> Knoten-ID Vendor- und Produkt-ID-Bytes des Knotens Hexadezimalstring (je zwei Zeichen pro Byte)
<ACC-Nr> Accessory BiDiB-Accessory-Nummer Dezimalzahl
<ASP-Nr> Aspekt Aspekt des BiDiB-Accessorys Dezimalzahl
<DCC-Addr> DCC-Adresse Accessory lt. RCN 213 Dezimalzahl
<DCC-Aspect> DCC-Adresse Aspekt lt. RCN 213 Konstante "R" oder "G"
0xnn Länge variable Länge des Schlüssels bzw. Wertes Rohbyte
"1" Wert der Mapping-Eintrag existiert Konstante
"" Leerer Wert der Mapping-Eintrag existiert nicht Konstante
<offset> Versatz Dezimalzahl
<limit> Limit Dezimalzahl
<count> Anzahl Dezimalzahl

Operationen

  • AME - Entry Write:

    Mit dieser Nachricht wird die angegebene AspectMapping-Tabellenzeile im Knoten erstellt, symbolisiert durch den Wert 0x01 "1". Besteht die Zeile bereits, bleibt sie erhalten.

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_SET 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x01 "1"

    Die erfolgreiche Ausführung der Operation wird mit der „gespiegelten“ Nachricht inkl. Wert „1“ quittiert. Konnte die Operation nicht ausgeführt werden, enthält die Quittung den alten Wert (leer) für den Tabelleneintrag. Zusätzlich kann eine Fehlermeldung mit dem Grund versandt werden.

    Antwort - OK (input-value gespiegelt):

    MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x01 "1"

    Antwort - NOK (alter Wert):

    MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x00 ""

    Antwort - NOK (am Beispiel Out of Memory):

    MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x00 ""
    + MSG_SYS_ERROR BIDIB_ERR_TXT "out of memory"
  • AME - Entry Delete:

    Mit dieser Nachricht wird die angegebene AspectMapping-Tabellenzeile im Knotens gelöscht, symbolisiert durch den leeren Wert (0x00 ""). Existierte die Zeile gar nicht, bleibt sie weiter abwesend.

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_SET 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x00 ""

    Die Antwort besteht aus der „gespiegelten“ Anfrage mit dem Wert. Eine gelöschte Zuordnung wird mit dem leeren Wert (0x00 "") quittiert. Konnte eine Zuordnung nicht gelöscht werden und existiert weiterhin, wird dies mit dem Wert 0x01 "1" gemeldet, sowie optional einer Fehlermeldung mit dem Grund.

    Antwort - OK (Wert gespiegelt):

    MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x00 ""

    Antwort - NOK (alter Wert):

    MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x01 "1"
  • AME - Entry Read:

    Mit dieser Nachricht wird das Vorhandensein einer Zuordnung vom Knotens gelesen.

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_GET 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>"

    Sowohl ein vorliegender wie ein fehlender Eintrag für diese Zuordnung werden mit einer Nachricht mit „gespiegelten“ Schlüssel quittiert:

    Antwort - (Eintrag gefunden, existiert):

    MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x01 "1"

    Antwort - (Eintrag fehlt, existiert nicht):

    MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x00 ""
  • AMR - Range Delete All:

    Mit dieser Nachricht werden alle Zuordnungen aus der Tabelle des Knotens gelöscht, symbolisiert durch den leeren Wert (0x00 "").

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_SET 0x05 "AMR *" 0x00 ""

    Die Quittung besteht aus der „gespiegelten“ Anfrage. Konnten nicht alle Zuordnungen gelöscht werden, enthält der Wert die Anzahl der verbliebenen Zuordungen.

    Antwort - OK:

    MSG_VENDOR 0x05 "AMR *" 0x00 ""

    Antwort - NOK:

    MSG_VENDOR 0x05 "AMR *" 0xnn "<count>"
  • AMR - Range Read All (Stream):

    Mit dieser Nachricht werden alle Zuordnungen in der Tabelle vom Knoten gelesen.

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_GET 0x05 "AMR *"

    Die Antwort besteht aus zwei Teilen:

    Die erste Nachricht enthält neben dem „gespiegelten“ Anfrage-Schlüssel als Wert die Anzahl der im Anschluss gelieferten Zuordnungen. Sind keine Zuordnungen vorhanden ist der Wert 0x01 "0". (Zur Unterscheidung von Knoten, die gar kein Aspekt-Mapping unterstützen, dort ist der Wert leer.)

    Im Anschluss daran liefert der Knoten selbstständig eine Nachricht pro gespeicherter Zuordnung. Der Knoten ist dabei selbst für die Datenflusskontrolle und Reihenfolge zuständig. Die gelieferten Zuordnungen entsprechen dem Format der Entry-Read/Write-Antworten.

    Antwort(en) - OK:

    MSG_VENDOR 0x05 "AMR *" 0xnn "<count>"
    + MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x01 "1"
    + …

    Antwort - NOK (Aspekt-Mapping nicht unterstützt):

    MSG_VENDOR 0x05 "AMR *" 0x00 ""
  • AMR - Range Read (Stream):

    Mit dieser Nachricht werden die Zuordnungen im angegebenen Bereich der Tabelle vom Knoten gelesen.

    Der „Offset“ bezieht sich auf den Startindex (in der vom Knoten verwendeten Reihenfolge) der zu liefernden Zuordnungen, das „Limit“ bezeichnet die maximale Anzahl der zu liefernden Zuordnungen. Die Angabe des „Offsets“ soll die Wiederholbarkeit bei Nachrichtenverlust ermöglichen.

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_GET 0xnn "AMR <offset> <limit>"

    Die Antwort besteht aus zwei Teilen:

    Die erste Nachricht enthält neben dem „gespiegelten“ Anfrage-Schlüssel als Wert die Anzahl der im Anschluss gelieferten Zuordnungen. Sind keine Zuordnungen vorhanden ist der Wert 0x01 "0". (Zur Unterscheidung von Knoten, die gar kein Aspekt-Mapping unterstützen, dort ist der Wert leer.)

    Im Anschluss daran liefert der Knoten selbstständig eine Nachricht pro gespeicherter Zuordnung. Der Knoten ist dabei selbst für die Datenflusskontrolle und Reihenfolge zuständig. Die gelieferten Zuordnungen entsprechen dem Format der Entry-Read/Write-Antworten.

    Antwort(en) - OK:

    MSG_VENDOR 0xnn "AMR <offset> <limit>" 0xnn "<count>"
    + MSG_VENDOR 0xnn "AME <VID><PID1><PID2><PID3><PID4> <ACC-Nr> <ASP-Nr> <DCC-Addr> <DCC-Aspect>" 0x01 "1"
    + …

    Antwort - NOK (Aspekt-Mapping nicht unterstützt):

    MSG_VENDOR 0xnn "AMR <offset> <limit>" 0x00 ""
Beispiel AME - Entry Write:

Schreibe einen AspectMapping-Eintrag für die Zuordnung von Accessory 18, Aspekt 2 im Knoten mit der Node-ID 0DEA00D62E auf DCC-Accessory 12 und DCC-Aspekt 1:

MSG_VENDOR_SET   24   'A'M'E' '0'D'E'A'0'0'D'6'2'E' '1'8' '2' '1'2' '0'   1   '1'

Die Nachricht beginnt mit der Kennung MSG_VENDOR_SET, dann kommt die Längenangabe von 24, gefolgt vom Schlüssel 'AME 0DEA00D62E 18 2 12 0'. Es folgt wieder eine Längenangabe (1), dann der Parameterwert (hier '1').
Die Nachricht wird an einen Adapter-Knoten für einen DCC-Handregler geschickt.

Die Antwort des Adapter-Knotens nach erfolgreicher Verarbeitung der Nachricht:

MSG_VENDOR   24   'A'M'E' '0'D'E'A'0'0'D'6'2'E' '1'8' '2' '1'2' '0'   1   '1'

Die Nachricht beginnt mit der Kennung MSG_VENDOR, dann kommt die exakt gespiegelte Anfrage mit Längenangabe von 24 und Schlüssel 'AME 0DEA00D62E 18 2 12 0'. Es folgt wieder eine Längenangabe (1), dann der Parameterwert (hier '1').

Bei erfolgloser Verarbeitung durch den Adapter-Knoten:

MSG_VENDOR   24   'A'M'E' '0'D'E'A'0'0'D'6'2'E' '1'8' '2' '1'2' '0'   0

Die Nachricht beginnt mit der Kennung MSG_VENDOR, dann kommt die Längenangabe von 24, gefolgt vom gespiegelten Schlüssel 'AME 0DEA00D62E 18 2 12 0'. Jetzt folgt wieder eine Längenangabe (0) aber ohne Wert.
Im Bedarfsfall kann eine zusätzliche Fehlermeldung versendet werden, z.B.:

MSG_SYS_ERROR   BIDIB_ERR_TXT   'o'u't' 'o'f' 'm'e'm'o'r'y'
Beispiel AMR - Range Read All (Stream):

Lies alle AspectMapping-Einträge aus einem Adapter-Knoten:

MSG_VENDOR_GET   5   'A'M'R' '*'

Die Nachricht beginnt mit der Kennung MSG_VENDOR_GET, dann kommen nur noch die Längenangabe von 5, gefolgt vom Schlüssel 'AMR *'.
Die Nachricht wird an einen Adapter-Knoten für einen DCC-Handregler geschickt.

Der Adapter-Knoten antwortet mit der Anzahl AspectMapping-Einträge (im Beispiel 4) gefolgt von den Einträgen selbst:

MSG_VENDOR    5   'A'M'R' '*'   1   '4'
MSG_VENDOR   24   'A'M'E' '0'D'E'A'0'0'D'6'2'E' '1'8' '1' '1'2' '0'   1   '1'
MSG_VENDOR   24   'A'M'E' '0'D'E'A'0'0'D'6'2'E' '1'8' '2' '1'2' '1'   1   '1'
MSG_VENDOR   24   'A'M'E' '0'D'E'A'0'0'D'E'E'E' '1'0' '1' '1'1' '0'   1   '1'
MSG_VENDOR   24   'A'M'E' '0'D'E'A'0'0'D'E'E'E' '1'0' '2' '1'1' '1'   1   '1'

Die Nachricht beginnt mit der Kennung MSG_VENDOR, dann kommt die exakt gespiegelte Anfrage mit Längenangabe von 5 und dem Schlüssel 'AME *'. Es folgt wieder eine Längenangabe (1), dann der Parameterwert (hier '4').
Jetzt folgen die angegebenen AspectMapping-Einträge, im Beispiel mit einer Zuordnung für zwei verschiedene BiDiB-Knoten:

  • Knoten 0DEA00D62E mit BiDiB-Accessory=18/Aspect=1 auf DCC-Addr=12/Asp=0 sowie BiDiB-Accessory=18/Aspect=2 auf DCC-Addr=12/Asp=1
  • Knoten 0DEA00DEEE mit BiDiB-Accessory=10/Aspect=1 auf DCC-Addr=11/Asp=0 sowie BiDiB-Accessory=10/Aspect=2 auf DCC-Addr=11/Asp=1

Das Format der AspectMapping-Einträge ist genau so wie das der Antworten auf ein erfolgreiches Schreiben bzw. das Lesen eines einzelnen Eintrags.

Generator-Mapping

Beim Generator-Mapping werden die DCC-Adressen für Fahrzeuge und Zubehör auf die Knoten-IDs der BiDiB-DCC-Generator-Knoten abgebildet über welchen sie angesprochen werden sollen.

Beispiel-Szenario:

Das Generator-Mapping wird vom Anwender als Teil der Anlagenkonfiguration erstellt und als GeneratorMapping-Tabelle in einem (oder mehreren) als DCC-Adapter fungierenden Knoten hinterlegt. Im Betrieb nimmt die Adapter-Applikation die DCC-Befehle vom Handregler entgegen, wandelt sie in das BiDiB-Format für Fahrzeuge bzw. DCC-Accessorys um und versendet sie gemäß GeneratorMapping-Tabelle via BiDiB an den entsprechenden Generator-Knoten.

Format

Das Format für Fahrzeuge und Zubehör unterscheidet sich nur durch das Präfix des Schlüssels - GML… für Fahrzeuge (Lokomotiven) und GMA… für DCC-Zubehör (Accessory).

Die Nachrichten folgen der Schlüssel/Wert-Vorgabe der allgemeinen BiDiB-Spezifikation: ASCII-Strings mit vorangestelltem Längen-Byte.

Der Schlüssel enthält neben dem Präfix (GMLE, GMAE, GMLR und GMAR) entweder die DCC-Adresse oder einen Stern (*) für den gesamten Bereich.

Der Wert enthält die Knoten-ID des gewünschten Generator-Knotens (Unique-ID ohne Klassenbits):

<VID><PID1><PID2><PID3><PID4>
Verwendete Abkürzungen
KürzelNameBedeutungTyp
GMLE GneratorMappingLocoEntry Operation für ein Fahrzeug (loco) Konstante
GMAE GneratorMappingAccessoryEntry Operation für ein Zubehörartikel (accessory) Konstante
GMLR GneratorMappingLocoRange Operation für mehrere Fahrzeuge Konstante
GMAR GneratorMappingAccessoryRange Operation für mehrere Zubehörartikel Konstante
<VID><PID1><PID2><PID3><PID4> Knoten-ID Vendor- und Produkt-ID-Bytes des Knotens Hexadezimalstring (je zwei Zeichen pro Byte)
<DCC-Addr> DCC-Adresse Fahrzeug- bzw. Zubehöradresse lt. RCN 212 bzw. RCN 213 Dezimalzahl
0xnn Länge variable Länge des Schlüssels bzw. Wertes Rohbyte
"" leerer Wert kein Generator hinterlegt Konstante

Operationen

  • GMLE - Entry Loco Write
    GMAE - Entry Accessory Write:

    Mit dieser Nachricht wird einer DCC-Adresse ein Generator-Knoten zugeordnet. Eine zuvor bestehende Zuordnung wird überschrieben.

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_SET 0xnn "GMLE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"
    MSG_VENDOR_SET 0xnn "GMAE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"

    Die erfolgreiche Ausführung der Operation wird mit der „gespiegelten“ Nachricht quittiert. Konnte die Operation nicht ausgeführt werden, enthält die Quittung den alten Tabelleneintrag. Zusätzlich kann eine Fehlermeldung für den Grund versandt werden.

    Antwort - OK (input-value gespiegelt):

    MSG_VENDOR 0xnn "GMLE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"
    MSG_VENDOR 0xnn "GMAE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"

    Antwort - NOK (wenn kein Wert gespeichert):

    MSG_VENDOR 0xnn "GMLE <DCC-Addr>" 0x00 ""
    MSG_VENDOR 0xnn "GMAE <DCC-Addr>" 0x00 ""

    Antwort - NOK (am Beispiel Out of Memory für Fahrzeuge):

    MSG_VENDOR 0xnn "GMLE <DCC-Addr>" 0x00 ""
    + MSG_SYS_ERROR BIDIB_ERR_TXT "out of memory"
  • GMLE - Loco Entry Delete
    GMAE - Accessory Entry Delete:

    Mit dieser Nachricht wird die Zuordnung der angegebenen DCC-Adresse auf einen Generator-Knoten gelöscht, symbolisiert durch den leeren Wert (0x00 "").

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_SET 0xnn "GMLE <DCC-Addr>" 0x00 ""
    MSG_VENDOR_SET 0xnn "GMAE <DCC-Addr>" 0x00 ""

    Die erfolgreiche Ausführung der Operation wird mit der „gespiegelten“ Nachricht quittiert. Konnte die Operation nicht ausgeführt werden, enthält die Quittung den alten Tabelleneintrag.

    Antwort - OK (input-value gespiegelt):

    MSG_VENDOR 0xnn "GMLE <DCC-Addr>" 0x00 ""
    MSG_VENDOR 0xnn "GMAE <DCC-Addr>" 0x00 ""

    Antwort - NOK (alter Wert):

    MSG_VENDOR 0xnn "GMLE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"
    MSG_VENDOR 0xnn "GMAE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"
  • GMLE - Loco Entry Read
    GMAE - Accessory Entry Read:

    Mit dieser Nachricht wird gelesen, welcher Generator-Knoten der angegebenen DCC-Adresse zugeordnet ist.

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_GET 0xnn "GMLE <DCC-Addr>"
    MSG_VENDOR_GET 0xnn "GMAE <DCC-Addr>"

    Eine existierende Zuordnung wird mit der Knoten-ID des Generator-Knotens beantwortet. Bei nicht vorhandener Zuordnung bleibt der Wert leer (0x00 "").

    Antwort - (existiert):

    MSG_VENDOR 0xnn "GMLE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"
    MSG_VENDOR 0xnn "GMAE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"

    Antwort - (existiert nicht):

    MSG_VENDOR 0xnn "GMLE <DCC-Addr>" 0x00 ""
    MSG_VENDOR 0xnn "GMAE <DCC-Addr>" 0x00 ""
  • GMLR - Loco Range Delete All
    GMAR - Accessory Range Delete All:

    Mit dieser Nachricht werden die Generator-Zuordnungen aller Fahrzeug- bzw. aller Zubehör-DCC-Addressen gelöscht, symbolisiert durch den leeren Wert (0x00 "").

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_SET 0x06 "GMLR *" 0x00 ""
    MSG_VENDOR_SET 0x06 "GMAR *" 0x00 ""

    Die Quittung besteht aus der „gespiegelten“ Anfrage. Konnten nicht alle Zuordnungen gelöscht werden, enthält der Wert die Anzahl der verbliebenen Zuordungen.

    Antwort - OK:

    MSG_VENDOR 0x06 "GMLR *" 0x00 ""
    MSG_VENDOR 0x06 "GMAR *" 0x00 ""

    Antwort - NOK:

    MSG_VENDOR 0x06 "GMLR *" 0xnn "<count>"
    MSG_VENDOR 0x06 "GMAR *" 0xnn "<count>"
  • GMLR - Loco Range Read All (Stream)
    GMAR - Accessory Range Read All (Stream):

    Mit dieser Nachricht werden alle Generator-Zuordnungen zu Fahrzeug- bzw. Zubehör-DCC-Adressen gelesen.

    Die Vendor-Nachricht ist wie folgt aufgebaut:

    MSG_VENDOR_GET 0x06 "GMLR *"
    MSG_VENDOR_GET 0x06 "GMAR *"

    Die Antwort besteht aus zwei Teilen:

    Die erste Nachricht enthält neben dem „gespiegelten“ Anfrage-Schlüssel als Wert die Anzahl der im Anschluss gelieferten Zuordnungen. Sind keine Zuordnungen vorhanden ist der Wert 0x01 "0". (Zur Unterscheidung von Knoten, die gar kein Generator-Mapping unterstützen, dort ist der Wert leer.)

    Im Anschluss daran liefert der Knoten selbstständig eine Nachricht pro gespeicherter Zuordnung. Der Knoten ist dabei selbst für die Datenflusskontrolle und Reihenfolge zuständig. Die gelieferten Zuordnungen entsprechen dem Format der Entry-Read/Write-Antworten.

    Antwort(en):

    MSG_VENDOR 0x06 "GMLR *" 0xnn "<count>"
    + MSG_VENDOR 0xnn "GMLE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"
    + …
    MSG_VENDOR 0x06 "GMAR *" 0xnn "<count>"
    + MSG_VENDOR 0xnn "GMAE <DCC-Addr>" 0x0A "<VID><PID1><PID2><PID3><PID4>"
    + …

    Antwort - NOK (Generator-Mapping nicht unterstützt):

    MSG_VENDOR 0x06 "GMLR *" 0x00 ""
    MSG_VENDOR 0x06 "GMAR *" 0x00 ""