BiDiB, ein universelles Steuerprotokoll für Modellbahnen

BiDiB - Bidirektionaler Bus - Logo

Inhaltsverzeichnis

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:

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.

1.4. Revisionsstand

Dieses Dokument beschreibt Revision 1.26 von BiDiB, Stand 15.08.2016.

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.

Revisionsgeschichte
1.262016-08-15 hinzu: BIDIB_PCFG_IS_PAIRED, BIDIB_ACCESSORY_PARA_STARTUP, BIDIB_ACCESSORY_PARA_OPMODE. Generelle Überarbeitung, Detaillierung, Übersetzung verbessert.
 2016-02-25 Änderung in der Zubehöransteuerung, hinzu MSG_LC_PORT_QUERY_ALL, Protokollversion 0.6⇒0.7
1.252015-11-28 Änderung der Byte-Reihenfolge von Portadressen im flachen Modell
1.242015-03-22 hinzu MSG_LC_CONFIGX_GET_ALL, flaches Portmodell (siehe Zubehöransteuerung), Protokollversion 0.5⇒0.6
1.232014-12-04 hinzu FLAG_QUERY0, Erläuterungen zu Accessory- und Lokadresse
 2014-11-11 Neue Konfigurationsnachrichten für Ports (CONFIGX*)
 2014-08-14 ergänzende Definitionen für POM (Gleisausgabe)
 2014-07-25 ergänzende Klarstellungen bei der Lizenz
V1.222014-06-26 hinzu: BIDIB_MSYS_SERVOMOVE_QUERY, längere Antworten bei Versionsabfragen
V1.222014-02-07 hinzu: MSG_ACCESSORY_NOTIFY, MSG_BM_DYN_STATE, MSG_CS_PROG, MSG_CS_PROG_STATE
V1.212013-12-16 hinzu: MSG_STRING_GET, _SET, MSG_STRING, FEATURE_STRING_SIZE
V1.202013-11-18 hinzu: Erläuterungen für Drehscheiben; Erläuterung für BIDIB_CS_STATE_GO_IGN_WD
V1.202013-10-29 hinzu: MSG_SYS_GET_UNIQUE_ID verpflichtend für Bootloader, die direkt angesprochen werden
V1.19.12013-10-21 Die Übersetzung Speed – DCC28 – DCC14 (in der Gleisausgabe) wurde auf verpflichtend geändert und eine Formel hierfür festgelegt
V1.192013-10-04 Erweiterung MSG_LC_OUTPUT_QUERY und features FEATURE_RELEVANT_PID_BITS, FEATURE_CTRL_PORT_QUERY_AVAILABLE
new: BIDIB_MSYS_ACC_OKAY_QIN1, BIDIB_MSYS_ACC_OKAY_QIN0, BIDIB_MSYS_ACC_OKAY_NF
V1.182013-07-18 Erweiterung bei SYS_MAGIC (Support für kleine Bootloader). Einführung SecureSwitch – Quittungen bei Weichenfehlern bzw. Handverstellung (Accessory)
 2013-06-29 BIDIB_ERR_OVERRUN als Fehlermeldungen hinzu.
 2013-06-29 Ergänzungen und Klarstellungen bei den Lizenzbedingungen
V1.172013-06-18 Einführung eines Watchdogs für DCC-Erzeugung, FEATURE_GEN_WATCHDOG neu dazu
V1.162013-06-02 Erläuterungen bei MSG_SYS_RESET, FEATURE_CTRL_STRETCH_DIMM neu dazu
V1.152013-04-20 Übermittlung von Fehlercodes bei Accessory
V1.142013-04-02 Einheitliche Definition von Accessory Schaltzeit
V1.132013-03-25 MSG_LOGON_REJECTED neu dazu; für Fehlerbehandlung bei zu vielen Teilnehmern
V1.122013-02-23 MSG_BOOST_CURRENT wird durch MSG_BOOST_DIAGNOSTIC ersetzt.
V1.112013-01-30 MSG_BOOST_ON bzw. _OFF mit einem Parameter ergänzt
V1.102013-01-23 MSG_CS_BIN_STATE ergänzt
V1.092013-01-17 FEATURE_BST_INHIBIT_AUTOSTART ergänzt
V1.092012-12-21 Erläuterungen bei MSG_CS_DRIVE_ACK; MSG_BOOST_QUERY ergänzt
V1.082012-11-13 Erläuterungen und finale Kodierung bei MSG_BM_SPEED, FEATURE_BM_ISTSPEED_INTERVAL
V1.072012-10-12 Ergänzung mit der Class Accessory, Parameter bei MSG_STALL; Erläuterungen bei MSG_CS_DRIVE
V1.062012-09-26 Class Zubehör: MSG_LC_WAIT dazu, Rechtschreibkorrekturen.
V1.052012-09-24 Class Belegtmeldung: Zusätzliche Befehle MSG_BM_GET_CONFIDENCE und MSG_BM_CONFIDENCE.
V1.042012-07-25 Zusätzliche Erläuterungen bei MSG_VENDOR*. MSG_SYS_PING / MSG_SYS_PONG haben einen Parameter erhalten
Ergänzungen bei Class Schalten: BIDIB_MACRO_RESTORE, BIDIB_MSYS_DELAY_RANDOM, MACRO_PARA jetzt 32 Bit.
V1.032012-07-25 Zusätzliche Erläuterungen bei MSG_VENDOR*.
V1.022012-06-06 Erläuterung bei MSG_NODE_LOST korrigiert.
V1.012012-03-19 MSG_FEATURE_GETALL, MSG_FEATURE_GETNEXT, MSG_NODETAB_GETALL, MSG_NODETAB_GETNEXT, Übertragungsverfahren für Features und Nodes erläutert.
V0.132012-02-21 MSG_BM_ADDRESS mit der Möglichkeit, mehrfache Belegung zu melden. Hinweis bei MSG_BM_SPEED.
V0.122011-07-20 Lokale Befehle für PING und PONG neu dazu; MSG_BM_MIRROR_OCC und _FREE neu dazu.
V0.112011-07-20 Neue feature-Parameter für Booster, Systemzeit, MSG_BOOST_STAT Meldungen erweitert. Stromeinstellung für Booster dazu.
V0.102011-04-02 Vorschläge für Dekoderanmeldung ergänzt, neue Message MSG_BM_BLOCK_CV für das blockweise Lesen von CVs.
V0.092011-02-24 Änderungen bei der NODE_TAB (falls keine Unterknoten), weitere Fehlercodes hinzu.
MSG_SYS_GET_ERROR dazu.
V0.082010-12-20 Boosterklasse ergänzt.
V0.072010-12-07 Erläuterungen bei Vendor config, V_VALUE dazu; Fehlermeldung erweitert; MSG_SYS_MAGIC mit index 0; Enable /Disable mit auto-forward auf Unterknoten. BM_MSG für Accessory dazu.
MSG_SYS_IDENTIFY_STATE dazu.
V0.062010-12-06 Erläuterungen bei NODE_CHANGE dazu
V0.052010-12-01 UniqueID erläutert, PKT_CAPACITY neu dazu, ClassID dazu
V0.042010-11-29 Paketaufbau für Routing optimiert, Feinabgleich.
neu dazu: MSG_BM_SET_SIZE, MSG_BM_GET_SIZE
V0.032010-11-25 Erweiterung für Hubs und Sub-Knoten.
V0.022010-11-17 Erweiterung für heterogene Rückmeldermodule, Individualisierung des Featuresets auf einzelne Module
V0.012010-11-03 Initiales Dokument

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:

BiDiB: Der Protokollstandard, also die Art und Weise, wie Nachrichten kodiert sind.
BiDiBus: Eine mögliche physikalische Implementierung einer Busebene, speziell für die Verbindung innerhalb einer Modellbahn geeignet. BiDiBus basiert auf RS485 und verwendet RJ45 Kabel.
Bussystem: Der gesamte Aufbau, bestehend aus Interface und Knoten (z. B. Meldern) und evtl. notwendiger interner Verbindungen, auch mehrere Ebenen umfassend.
Class: Knoten sind hinsichtlich Ihrer prinzipiellen Eigenschaften in Klassen eingeteilt. Es gibt z. B. Belegtmelder, DCC-Erzeuger, Schaltausgabe, Bedienpulte.
Feature: Eine bestimmte Eigenschaft eines Knotens (wie z. B. 'Melder kann Lokrichtung erkennen'). Ein Feature kann individuell je Knoten abgefragt oder konfiguriert werden.
Host: Der steuernde Computer, i. d. R. ein PC mit entsprechender Software. Aus Sicht des BiDiB-System diejenige Instanz, von welcher das erste Interface seine Befehle erhält.
Hub: Ein Knoten auf einer Busebene, welcher zugleich Interface für eine nachgeordnete Ebene ist.
Interface: Die Stelle in einer Ebene (Struktur) des Bussystems, welche mit dem Host oder dem übergeordnetem Knoten kommuniziert.
Knoten: Ein Teilnehmer im Bussystem, also die (fallweise verteilte) Hardware. Ein Teilnehmer auf einer Ebene kann auch Interface für die nächsttiefere Ebene sein (Hub-Funktion).
Logon: Der Versuch eines Teilnehmers, eine logische Verbindung zu einen Interface aufzunehmen. Die Verbindung wird bestätigt und der Host über diesen neuen Knoten benachrichtigt.
Melder: Ein Knoten des BiDiB-Systems, welcher die Gleisbelegung erfasst und BiDi-Rückmeldung auswertet.
Node-Adresse: Die von Interface nach der automatischen Anmeldung vergebene Nummer (byte), unter welcher der Knoten (auf dieser Ebene) in dieser Sitzung angesprochen wird. (NODE_ADDR)
Magic: (System-ID) Eine (an sich bedeutungslose) Nummer, die bei Starten des Interfaces von Host abgefragt werden muss und anhand der z. B. die richtige Baudeinstellung erkannt werden kann.
Unique-ID: Die von Hersteller in den Melder fest programmierte, eineindeutige Kennung, bestehend aus 16 Bit Class-IDs, 8 Bit Herstellerkennung und 32 Bit herstellerspezifischer Nummer (z. B. Produktindex und Seriennummer).

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 (Unique-ID) einprogrammiert. 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 PC-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 Hardware erfolgt also letztendlich über die Unique-ID und ist damit nicht von der aktuellen Adressvergabe abhängig.

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 in der Lage sein, Nachrichten mit einer Mindestgröß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 x8 + x5 + x4 + 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:

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.

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:

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

Ä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. UniqueID

Jeder Knoten hat eine herstellerseitig einprogrammierte eindeutige Nummer, die UniqueID. Die UniqueID besteht aus 7 Bytes:

Aufbau der Unique-ID
1. Byte ClassID

Hierbei handelt es sich um ein Bitfeld, welches die prinzipielle Klassenzugehörigkeit eines Knotens angibt. Dieses Bitfeld dient dem Host zur schnellen Orientierung, welche Funktionen auf auf diesem Knoten zu finden sind. Wenn ein Knoten Befehle einer bestimmten Klasse implementiert hat, so muss er auch das entsprechende Class-Bit gesetzt haben. Ein Knoten darf auch mehreren Klassen zugleich angehören.

Bit 71: Knoten enthält Sub-Knoten (ist also selbst ein Interface)
Bit 61: Knoten enthält Besetztmelderfunktionen
Bit 5reserviert (1: Knoten enthält Bedienfunktionen, MMI)
Bit 41: Knoten enthält DCC-Signalerzeugung für Fahren, Schalten
Bit 31: Knoten enthält DCC-Signalerzeugung für Programmieren
Bit 21: Knoten enthält Accessory-Stellfunktionen
Bit 11: Knoten enthält Booster-Funktionen
Bit 01: Knoten enthält Zubehör-Schaltfunktionen, wie z. B. Lichtanimation

Reservierte Bits sind als 0 zu kodieren.

2. Byte ClassID-Erweiterung; dieses Byte ist reserviert und mit 0 zu kodieren.
3. Byte Vendor-ID: Hier wird die gleiche Kodierung wie bei DCC verwendet, siehe NMRA Manufacturer ID Numbers.
4.-7. Byte Produktkennung, bestehend aus 4 Bytes

Diese 4 Byte = 32 Bit unterteilen sich in Produkttyp-Kennung und eine Seriennummer, damit Hostprogramme und Analysewerkzeuge die jeweiligen Knoten leichter identifizieren können. Die Aufteilung, wie viel Bits Produkttyp kodieren und wie viele Bits die Seriennummer kodieren, liegt im Ermessen des Herstellers und wird über das Feature FEATURE_RELEVANT_PID_BITS festlegt. Eine Aufteilung 16Bits/16Bits wird empfohlen. Die Produkttyp-Kennung beginnt immer bei ersten Byte, Bit 0 (BiDiB ist immer little-endian (low-byte first) kodiert).

Fehlt das Feature FEATURE_RELEVANT_PID_BITS, so erfolgt die Aufteilung 16 Bit / 16 Bit.

Die ClassID dient zum schnellen Auffinden von Teilfunktionalitäten, ein Hostprogramm muss nur die Features derjenigen Knoten ansehen, welche das entsprechende Klassenbit gesetzt haben. Ein Knoten muss die entsprechenden Befehle der gemeldeten Klassen kennen und korrekt beantworten, auch wenn z. B. aufgrund aktueller Benutzerkonfiguration kein Objekt in dieser Klasse vorhanden ist.

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, Unique 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 64 Byte nicht übersteigt.
  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 UniqueID 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.
Klasse Occupancy:
Der Knoten enthält Belegtmelder.
Klasse DCC-Generator:
Der Knoten stellt DCC-Fahr- und Schaltbefehle bereit.
Klasse DCC-Programmieren:
Der Knoten stellt DCC-Servicemode-Befehle bereit.
Klasse Accessory Control:
Der Knoten hat Stellfunktionen für Fahrwegzubehör.
Klasse Booster:
Ein Booster verstärkt das DCC-Signal für Fahrzeuge und DCC-Dekoder, er hat keine eigene DCC-Erzeugung.
Klasse Schaltfunktionen:
Der Knoten stellt Zubehör- und Licht-Ansteuerung sowie -Animation bereit.

4. Nachrichten

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

System Abfrage der Software- und Hardwareversion und der Produktkennung, Systemstart und -stop, Verbindungseinstellungen, Abfrage und Einstellen der Node-Adressen.
Feature Abfrage und Einstellen der Eigenschaften des Knotens (Features)
User-Config offene Nachrichten zur herstellerspezifischen, erweiterten Konfiguration
Nachrichten für Firmwareupdates Upload neuer Knotensoftware.
Nachrichten für Melder Belegtmeldungen und Dekoder-Rückmeldung
Nachrichten für Booster Kontrolle und Überwachung von Boostern
Nachrichten für Gleisausgaben DCC Fahr- und Schaltbefehle
Nachrichten für Schaltaufgaben Weichen, Signale, Fahrwegzubehör
Nachrichten für Konfiguration und direkten Portzugriff Beleuchtung, Animationen, Sound, Zubehör

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.

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

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:

Systemnachrichten für die Anlagenverwaltung

(Hinweis zur Implementierung: diese Nachrichten sind mandatory)

4.1.2. Uplink: System-Nachrichten

Allgemeine Systemnachrichten

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).

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.

Aufstellung der allgemeinen Features
NummerNameBedeutung
252 FEATURE_STRING_SIZE Maximale Stringlänge für Stringvariablen. Wertebereich: 0; 8…24
(Fehlt das Feature FEATURE_STRING_SIZE, so kann der Knoten keine Stringnachrichten verarbeiten.)
253 FEATURE_RELEVANT_PID_BITS Anzahl der relevanten Bits für die Produktkennung in der Unique-ID. Wertebereich: 0…31.
Default 16. (Fehlt das Feature FEATURE_RELEVANT_PID_BITS, so erfolgt die Aufteilung 16 Bit / 16 Bit.)
4.2.1. Downlink: Nachrichten für das Abfragen oder Setzen von Feature-Einstellungen

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:

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 und -inhalt ist 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

V_NAME und V_VALUE sind ASCII-Folgen. Wenn die Folge mit einer Ziffer 0…9 beginnt, so handelt es sich um einen numerischen Wert. V_NAME sollen in der Regel mit einem Buchstaben beginnen. Mit numerischen Werten für V_NAME wird die klassische CV-Programmierung emuliert, der Adressbereich wird (wie in Dekoderbeschreibungen üblich) bei 1 beginnend gezählt. Damit kann direkt eine Usereingabe an den Knoten weitergereicht werden. V_NAME = "0" ist unzulässig.

Beispiele für MSG_VENDOR*:
MSG_VENDOR_GET 0x01 0x38 (=1 '8'): Es wird die CV 8 (bei üblichen Dekodern = Herstellerkennung) gelesen: 1 ist hier die Länge des Strings, welcher nur aus dem ASCII-Zeichen für 8 besteht.
MSG_VENDOR_SET 8 'S'C'H'W'E'L'L'E' 3 '2'5'5': Die Nachricht beginnt mit der Kennung MSG_VENDOR_SET, dann kommt die Längenangabe von 8, gefolgt vom Parameternamen 'Schwelle'. Es folgt wieder eine Längenangabe (3), dann der Parameterwert (hier 255). Das Prinzip ist vergleichbar mit den Einträgen in einer Ini-Datei.
4.3.2. Uplink: Nachrichten für Userconfig

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

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
Aufstellung der Features für Firmware-Update
NummerNameBedeutung
254 FEATURE_FW_UPDATE_MODE 0: kein FW-Update möglich
1: FW-Update im Intel-Hex-Verfahren möglich. Die maximale Zeilenlänge beträgt 16 Daten-Bytes (d.h. die Intelhex-Zeile beginnt mit ':10' oder kleiner).

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:

name_version.ddd.hex
PlatzhalterVerwendung
name_version Name der Firmware, diese soll erkennbar Hersteller und Produkt kennzeichnen sowie eine Versionsbezeichnung haben. Alle Datei für verschiedene Zielbereiche müssen den gleichen String für name_version verwenden.
ddd Zielspeicherbereich, 3-stellig, mit führenden 0 aufgefüllt.
hex Dateierweiterung, hier wird fest die Erweiterung .hex verwendet.
Beispiel:
xyz_occupancydetector_v1_23f.000.hex
xyz_occupancydetector_v1_23f.001.hex

000 und 001 wäre hier dann die jeweilige Nummer des Ziel-Speicherbereichs. Es wird empfohlen, den Bereich 000 für den Hauptprogrammspeicher zu verwenden und 001 für den Konfigurationsspeicher (EEPROM).

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.)

4.4.4. Uplink: Nachrichten für FW-Update

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.

Allgemeiner Hinweis: Dieser Abschnitt 'Zentrale' ist noch in der Testphase. Sicherlich wird man für die Ansteuerung von Loks noch das eine oder andere brauchen – z. B. Adresse neu zuweisen, Ansteuerformat festlegen, Loknamen verwalten (wer verwaltet das – die Ausgabeeinheit?) usw.

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

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

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

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

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

Sofortige Quittung: Befehl konnte nicht angenommmen werden.

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

1 0

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

2 0

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

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

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

3 1

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

4 2

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

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

5 2

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

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.

Objekte haben 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.

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 im Knoten ein Fehler auf, schickt der Knoten 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:

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.

Aufwändige Objekte mit einem komplexen Zustandsraum können auch aus mehreren Accessorys zusammengesetzt sein, sie verfügen dann über mehrere Begriffe. Die Zusammenstellung erfolgt frei in der Hostsoftware.

Ein Spezialfall darunter ist der Betriebsmodus von Objekten. Hier – und nur 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 mit dem Betriebsmodus zwei oder mehr Begriffe, die wie folgt definiert sind:

Die Nachrichten an die verschiedenen Accessorys bleiben dabei unabhängig voneinander. 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
4.6.4. Uplink: Nachrichten für Accessory-Funktionen
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:

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.

Typorientiertes Portmodell Flaches Portmodell
Definition Jeder Ausgang und Eingang (Port) ist fest einem Porttyp zugeordnet. Jeder Porttyp hat einen eigenen Nummernbereich, welcher jeweils für sich von 0 an beginnend gezählt wird. Die Funktion (z. B. Servoausgang, Schaltausgang) ist damit direkt in der Adresse kodiert. Alle Ausgänge und Eingänge (Ports) benutzen einen gemeinsamen Nummernbereich, die Adressen werden linear für alle Ports vergeben. Der Porttyp (Funktion) ist einzig über die Konfiguration des jeweiligen Ports bestimmt. Im flachen Portmodell besteht damit die Möglichkeit, dass sich der Typ eines Ports durch eine Konfigurationsnachricht verändern lässt.
Aktivierung Das typorientierte Portmodell ist an einem Knoten aktiv, wenn FEATURE_CTRL_PORT_FLAT_MODEL und FEATURE_CTRL_PORT_FLAT_MODEL_EXTENDED nicht vorhanden sind oder den Wert 0 haben.
Die Anzahl der verfügbaren Ports wird vom Knoten je Typ über FEATURE_CTRL_*_COUNT bekanntgegeben.
Das flache Portmodell ist an einem Knoten aktiv, wenn FEATURE_CTRL_PORT_FLAT_MODEL und/oder FEATURE_CTRL_PORT_FLAT_MODEL_EXTENDED einen Wert > 0 hat. In diesem Fall geben diese Features auch gleich die Gesamtzahl aller Ports an, sie berechnet sich als die Summe PORT_FLAT_MODEL_EXTENDED*256+PORT_FLAT_MODEL.
Die FEATURE_CTRL_*_COUNT geben, falls vorhanden, die maximal mögliche Anzahl der auf den jeweiligen Typ konfigurierbaren Ports an.
Dieses Modell ist ab Protokollversion 0.6 verfügbar.
PORT0 PTYPE Ausgangstyp. PORTADDRESS Ausgangsnummer pro Knoten; diese wird ab 0 gezählt. Sie wird als 16-bit little-endian Integer kodiert, dessen 4 MSB reserviert und mit 0 zu belegen sind. Wertebereich 0…4095
PORT1 PORTNUM Ausgangsnummer pro Typ; diese wird ab 0 gezählt. Wertebereich 0…127, Bit 7 ist reserviert (0).
Kodierung der Porttypen
WertNameBedeutungOperationenKonfigurationsmöglichkeiten
0 SWITCH Schaltausgang (früher: SPORT) aus/ein keine
1 LIGHT Lichtausgang (früher: LPORT) aus/ein/blinken/dimmen Helligkeit, Dimmgeschwindigkeit
2 SERVO Servoausgang positionieren Endpositionen, Umlaufgeschwindigkeit
3 SOUND Tonausgang play/pause/stop Lautstärke, Tonquelle
4 MOTOR Motorausgang Drehen/Geschwindigkeit Regelung
5 ANALOGOUT allgemeine Ansteuerung Spannung Maximalwerte
6 BACKLIGHT Lichtausgang Helligkeit direkt Dimmgeschwindigkeit, Kanal-Mapping
7…14 reserviert
15 INPUT Kontakteingang, z. B. Taster oder Endschalter offen/geschlossen keine
16…254 reserviert
255 reserviert (interner Gebrauch in Knoten oder PC-Programmen)
4.6.6. Features für Schaltfunktionen

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

Aufstellung der Features für die Schaltfunktions-Klasse
NummerNameBedeutung
50 FEATURE_CTRL_INPUT_COUNT Anzahl der Eingänge (z. B. für Taster)
Wertebereich: 0…128.
51 FEATURE_CTRL_INPUT_NOTIFY Spontan-Meldung von Taster-Eingängen erlaubt. Der Knoten liefert Änderungen des Tasterzustand von selbst an den Host.
Wertebereich: 0…1.
52 FEATURE_CTRL_SWITCH_COUNT Anzahl der Standard-Ausgänge
Hier wird die Anzahl der Schaltausgänge abgefragt. Wertebereich: 0…128.
53 FEATURE_CTRL_LIGHT_COUNT Anzahl der Licht-Ausgänge
Lichtausgänge haben erweiterte Eigenschaften, wie z. B. Blinken, Dimmen, usw.
Hier wird die Anzahl der Lichtausgänge abgefragt. Wertebereich: 0…128.
54 FEATURE_CTRL_SERVO_COUNT Anzahl der Servoausgänge
Hier wird die Anzahl der Servoausgänge abgefragt. Wertebereich: 0…128.
55 FEATURE_CTRL_SOUND_COUNT Anzahl der abspielbaren Sounds
Hier wird die Anzahl der Sounds abgefragt. Wertebereich: 0…128.
56 FEATURE_CTRL_MOTOR_COUNT Anzahl der Motorausgänge
Gemeint sind hier Motorausgänge für Zubehörartikel (z. B. Karusselldrehzahl)
Wertebereich: 0…128.
57 FEATURE_CTRL_ANALOGOUT_COUNT Anzahl der Analogausgänge
Hier wird die Anzahl der Analogausgänge abgefragt. Wertebereich: 0…128.
58 FEATURE_CTRL_STRETCH_DIMM Verlangsamung von Helligkeitsübergängen bei Lichtausgängen. Helligkeitsübergänge werden zusätzlich um diesen Faktor verlangsamt. Wertebereich 1…250.
59 FEATURE_CTRL_BACKLIGHT_COUNT Anzahl der Lichtausgänge (dimmbar, für Raumlicht)
Gemeint sind hier Lichtausgänge, deren Helligkeit dann im Stellbefehl einstellt wird.
Wertebereich: 0…128.
70 FEATURE_CTRL_PORT_FLAT_MODEL Unterstützung des flachen Portmodells, unteres Byte der Anzahl der darin ansprechbaren Ports. Zahl der insgesamt am Knoten vorhandenen Ein- und Ausgänge.
Wertebereich: 0…255.
71 FEATURE_CTRL_PORT_FLAT_MODEL_EXTENDED Unterstützung des flachen Portmodells, oberes Byte der Anzahl der darin ansprechbaren Ports. Zahl der insgesamt am Knoten vorhandenen Ein- und Ausgänge.
Wertebereich: 0…16.
66 FEATURE_CTRL_PORT_QUERY_AVAILABLE Abfragen von Portzuständen möglich
0 = Ausgangszustände sind nicht abfragbar. (default)
1 = Ausgangszustände sind abfragbar, es erfolgt eine Antwort auf MSG_LC_PORT_QUERY(_ALL).
67 FEATURE_SWITCH_CONFIG_AVAILABLE (veraltet, ab Protokollversion 0.6 ist MSG_LC_CONFIGX zur Portkonfiguration zu verwenden)
Konfiguration von Ports möglich
0 = Schaltport sind nur einfach schaltbar. (default)
Bit 1 = Schaltports bieten eine erweiterte Konfiguration und können zu INPUTs werden.
4.6.7. Downlink: Nachrichten für Schaltfunktionen
4.6.8. Uplink: Nachrichten für Zubehör / Schaltfunktionen
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.

Beispiel für ein Makro:

Dieses Beispiel zeigt eine Verkehrsampel, ein Makro A soll diese auf den Signalisierungsbegriff 'STOP' schalten, ein weiteres Makro B soll die Ampel auf 'FAHRT' schalten.

Makro A (Ampel schaltet von grün nach rot)
DelayAktion
0Ausgang für 'GELB' einschalten.
0Ausgang für 'GRÜN' ausschalten.
10Ausgang für 'ROT' einschalten.
0Ausgang für 'GELB' ausschalten.

Erklärung: beim Start des Makros wird ohne Verzögerung GELB ein- und GRÜN ausgeschaltet (die Ampel springt also auf GELB). Die nächste Aktion hat eine Wartezeit von 10, nach dieser Wartezeit geht ROT an und ohne weitere Verzögerung geht GELB aus.

Makro B (Ampel schaltet von rot über rot-gelb nach grün)
DelayAktion
0Ausgang für 'GELB' einschalten.
10Ausgang für 'ROT' ausschalten.
0Ausgang für 'GELB' ausschalten.
0Ausgang für 'GRÜN' einschalten.

Bei diesem Makro wird zuerst GELB zugeschaltet, dann nach einer Verzögerung ROT zusammen mit GELB abgeschaltet und zugleich grün eingeschaltet.

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:

Aufstellung der Features für Makro-Unterstützung
NummerNameBedeutung
60 FEATURE_CTRL_MAC_LEVEL Unterstützter Makro-Level
0 = keine Makrofähigkeit
1 = Makros des Level 1 (einfache Aktionslisten)
2 = Makros des Level 2 (Aktionslisten, mit Abfragen, Start, Stop, Zufall)
61 FEATURE_CTRL_MAC_SAVE Permanente Speicherung von Makros möglich
0 = keine Speicherfähigkeit;
1…n = Anzahl der Speicherplätze für permanente Speicherung
62 FEATURE_CTRL_MAC_COUNT Zahl möglicher Makros
0 = keine Makrofähigkeit
1…n = Anzahl der möglichen Makros des angegebenen Levels
63 FEATURE_CTRL_MAC_SIZE Länge lokaler Makrolisten
0 = keine Makrofähigkeit;
1…n = Anzahl der Einträge je Makroliste
64 FEATURE_CTRL_MAC_START_MAN Start von Makros durch lokale Eingänge
0 = Makros können nicht durch lokale Eingänge gestartet werden.
1 = Makros können durch lokale Eingänge gestartet werden. Dabei gilt eine feste Zuordnung: Eingang 0 startet Makro 0, Eingang 1 startet Makro 1, usw.
65 FEATURE_CTRL_MAC_START_DCC Start von Makros durch DCC
0 = Makros können nicht durch DCC gestartet werden.
1 = Makros können durch DCC-Befehle gestartet werden. Die Programmierung der DCC-Adresse erfolgt mit den jeweils üblichen Mitteln (z. B. per Progtaster oder CV-Programmierung. Zubehörbefehl 0 startet Makro 0, usw.
4.6.11. Downlink: Nachrichten für lokale Makros

Es gibt folgende Befehle zum Erstellen und Verwalten von Makros:

4.6.12. Uplink: Nachrichten für lokale Makros

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 Belegtmeldungen
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 die den 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
Aufstellung der Features für die Belegtmelder-Klasse
NummerNameBedeutung
0 FEATURE_BM_SIZE Anzahl der Belegtmeldungen. Hier werden die Anzahl der Melderbits eines Knotens abgefragt. Für Melder mit unbekannter Anzahl am Eingängen (z. B. Interface zu einem S88-Bus) kann diese Variable auch geschrieben werden. Wertebereich: 0…128.
1 FEATURE_BM_ON 0: Der Knoten liefert keine Belegtmeldung.
1: Der Knoten liefert Belegtmeldungen (Spontan). Dies erfolgt automatisch bei einer Änderung des Zustandes.
2 FEATURE_BM_SECACK_AVAILABLE 0: keine Quittungen
1: Der Melder beherscht das Secure-ACK-Quittungsverfahren für Belegtmeldungen
3 FEATURE_BM_SECACK_ON Wenn dieses Feature ungleich 0 ist, dann ist Secure-ACK-Quittungsverfahren enabled. Der Wert gibt das Retransmitintervall in Einheiten von 10ms an. Empfohlen ist eine Einstellung von 20 entsprechend 200ms.
4 FEATURE_BM_CURMEAS_AVAILABLE 0: keine Strommessdaten
1: Der Melder kann Strommessdaten (eines Abschnittes) liefern
5 FEATURE_BM_CURMEAS_INTERVAL Wenn dieses Feature ungleich 0 ist, dann ist Strommessung enabled.
Der Wert gibt das Abtastintervall der Strommessung in Einheiten von 10ms an. Empfohlen ist eine Einstellung von 200 entsprechend 2s.
6 FEATURE_BM_DC_MEAS_AVAILABLE 0: keine Ersatzmessung verfügbar. (siehe hierzu auch MSG_BM_CONFIDENCE)
1: Ersatzmessung: Der Melder kann Belegtmeldungen auch bei abgeschaltetem Fahrstrom liefern
7 FEATURE_BM_DC_MEAS_ON 1: Der Melder liefert Belegtmeldungen auch bei abgeschaltetem Fahrstrom
8 FEATURE_BM_ADDR_DETECT_AVAILABLE 1: Der Melder kann erkannte Lok-Adressdaten liefern (sofern im Lokdekoder aktiviert)
9 FEATURE_BM_ADDR_DETECT_ON 1: Der Melder liefert die Adressdaten
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 die ü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.

Anmerkungen zu den BM_MIRROR_* Befehlen:
Bei der Quittierung von Belegtmeldungen sollte die Quittung mit der gleichen Befehlsart wie die Belegtmeldung erfolgen: erfolgte die Belegtmeldung byteweise, sollte auch die Quittung byteweise erfolgen. Ebenso für Einzelmeldungen. Der Grund hierfür liegt im Echtzeitverhalten: Angenommen, der Belegtmelder meldet mehrere Bits sehr schnell hintereinander mittels MSG_BM_OCC / MSG_BM_FREE. Wenn jetzt der Host die erste Meldung quittiert und hier ein Byte zurückschickt, in dem nur ein Teil der Belegtmelderbits korrekt ist, dann bekommt er vom Belegtmelder-Knoten postwendend eine MSG_BM_MULTIPLE-Nachricht, welche ihm den richtigen Vektor anzeigt. Das passiert ebenso für alle folgenden MSG_BM_*-Nachrichten, welche noch in der Pipeline sind.
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:

4.7.5. Features für BiDi-Detektoren

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

Aufstellung der Features für Bidi-Detektoren
NummerNameBedeutung
10 FEATURE_BM_ADDR_AND_DIR 1: Der Detektor hat Richtungserkennung, d.h. die prinzipielle Fähigkeit dazu.
11 FEATURE_BM_ISTSPEED_AVAILABLE 0: Der Detektor versteht keine Speedmeldungen
1: Der Detektor kann Speedmeldungen vom Dekoder weiterleiten
12 FEATURE_BM_ISTSPEED_INTERVAL Wenn dieses Feature ungleich 0 ist, dann werden Speedmeldungen weitergeleitet. Der Wert gibt das Intervall der Speedmeldungen in Einheiten von 10ms an. Empfohlen ist eine Einstellung von 50 entsprechend 500ms
13 FEATURE_BM_CV_AVAILABLE 0: Der Detektor versteht keine CV-Antworten
1: Der Detektor kann CV-Antworten von Dekodern einlesen und weiterleiten
14 FEATURE_BM_CV_ON 0: Der Detektor leitet CV-Antworten des Dekoders nicht weiter
1: Der Detektor leitet CV-Antworten des Dekoders weiter
28 FEATURE_BM_DYN_STATE_INTERVAL 0: Der Detektor leitet DYN-Antworten des Dekoders nicht weiter
1…255: Der Detektor leitet DYN-Antworten des Dekoders weiter; Interval in Einheiten von 100ms
29 FEATURE_BM_RCPLUS_AVAILABLE 0: Der Detektor versteht keine RailcomPlus-Antworten
1: Der Detektor kann RailcomPlus-Antworten von Dekodern melderabschnittsbezogen weiterleiten
2: Der Detektor kann RailcomPlus-Antworten von Dekodern global weiterleiten (MNUM=255)
4.7.6. 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:

Kodierung der Adressmeldung
WertBedeutung
0 keine Adresse erkannt.
1…10239 Lok- bzw. Zubehöradresse; Zur Unterscheidung werden die beiden MSB verwendet.
Bit 15,14Bits 13…0
00Lokadresse, Orientierung (Aufgleisrichtung) nach vorne
10Lokadresse, Orientierung nach hinten
01Accessory-Adresse
11Extended Accessory Adresse
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.
Ein gesetztes Richtungsbit bedeutet, dass die Lok mit Ihrer linken Seite (bei Blickrichtung in Fahrtrichtung vorwärts, Führerstand 1) mit der Gleisseite verbunden ist, in welcher der Detektor installiert ist. An der linken Seite ist bei Verdrahtung mit NEM-Farben der Radschleiferanschluss in schwarz (rechte Seite ist rot).

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

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.

Aufstellung der Features für die Booster-Klasse
NummerNameBedeutung
15 FEATURE_BST_VOLT_ADJUSTABLE Ausgangsspannung einstellbar
Wenn dieses Feature ungleich 0 ist, dann kann die Ausgangsspannung des Boosters konfiguriert werden.
16 FEATURE_BST_VOLT Die Ausgangsspannung ist der hier angegebene Wert in Volt.
17 FEATURE_BST_CUTOUT_AVAIALABLE Cutout verfügbar. 1 = Der Booster kann eine Austastlücke erzeugen
18 FEATURE_BST_CUTOUT_ON Cutout eingeschaltet. 1 = Der Booster erzeugt die Austastlücke
19 FEATURE_BST_TURNOFF_TIME Abschaltzeit normal
Zeitdauer, welche nach einem Kurzschluss bis zum Abschalten benötigt wird. Booster, welche das nicht variabel haben, sollen den eingestellten Wert zurückliefern. Der Wert ist in der Einheit 1ms angegeben.
20 FEATURE_BST_INRUSH_TURNOFF_TIME Abschaltzeit Inrush (optional)
Zeitdauer, während welcher ein Kurzschluss sofort nach dem Einschalten (bedingt durch Einschaltstrom-Spitze) toleriert wird. Der Wert in der Einheit 1ms angegeben.
21 FEATURE_BST_AMPERE_ADJUSTABLE Ausgangsstrom ist einstellbar
Wenn dieses Feature ungleich 0 ist, dann kann der maximale Ausgangsstrom des Boosters konfiguriert werden.
22 FEATURE_BST_AMPERE maximaler Ausgangsstrom
max. Ausgangsstrom. Dieses Feature ist so kodiert wie die Strommessung (siehe MSG_BOOST_DIAGNOSTIC). Es kann sein, dass der gewünschte Wert nicht einstellbar ist, der Knoten stellt dann den nächstkleineren Strom und sofern dieser 0 ist, den minimal möglichen Strom ein. Der eingestellte Wert kann dann wieder abgefragt werden.
Beispielwerte
0x52 = 820.5A (496mA)
0x71 = 1131A (992mA)
0x83 = 1311.5A (1472mA)
0x8B = 1392A (1984mA)
0x93 = 1472.5A (2496mA)
0x9B = 1553A (3008mA)
0xAA = 1704A (3968mA)
0xBA = 1865A (4992mA)
23 FEATURE_BST_CURMEAS_INTERVAL Diagnoseintervall
Der Booster kann Diagnosewerte (z. B. Strommessdaten, Temperatur, Spannungen) liefern, wenn dieses Feature ungleich 0 ist, dann ist Strommessung enabled.
Der Wert gibt das Abtastintervall der Strommessung in Einheiten von 10ms an. Empfohlen ist eine Einstellung von 200 entsprechend 2s.
Der Knoten soll ein Intervall von 100ms nicht unterschreiten.
26 FEATURE_BST_INHIBIT_AUTOSTART Normalerweise startet ein Booster automatisch, wenn DCC an seinem Eingang eingeschaltet wird. Wenn dieses Feature auf 1 gestellt ist, dann wird dieser Start unterbunden und der Booster muss explizit mit einer MSG_BOOST_ON eingeschaltet werden. Es ist damit z. B. möglich, gezielt Anlagenbereiche dauerhaft stromlos zu schalten.
27 FEATURE_BST_INHIBIT_LOCAL_ONOFF Sollte ein Booster über lokale Taster für Stop und Go verfügen, so kann mit diesem Feature entschieden werden, ob diese Taster wirken. Wenn dieses Feature auf 1 gestellt ist, dann wird der Tastendruck nicht direkt ausgewertet, sondern an den Host (als Boosterstatus) gemeldet. Der Host kann das weitere Vorgehen entscheiden (Anwendung: dezentrale Nothalttaster)
4.8.3. Downlink: Nachrichten für Booster
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.

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

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