Support für Hersteller
Userkonfiguration
Beispielcode
Analysewerkzeuge
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.
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.
Kürzel | Name | Bedeutung | Typ |
---|---|---|---|
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 Wert0x01 "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.
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>
Kürzel | Name | Bedeutung | Typ |
---|---|---|---|
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 ""