Die Unterstützung für BiDiB in JMRI wird von Eckart gemacht.

Siehe Forums-Thread.

Derzeit unterstützt JMRI die Verbindung über USB, BiDiB über TCP, und es gibt einen BiDiB-Simulator, der durch eine XML-Datei konfiguriert wird.

Öffnen Sie die Registerkarte Verbindungen, wählen Sie „BiDiB“ aus dem Auswahlfeld Systemhersteller und wählen Sie aus den folgenden Setups. Der Systembuchstabe für BiDiB-Verbindungen ist „B“.

BiDiB unterstützt Hotplugging auf dem BiDiBus, dies wird auch in JMRI-BiDiB unterstützt. Geht ein Knoten verloren, werden alle Objekte, die darauf verweisen als ungültig markiert aber nicht entfernt. Wenn ein neuer Knoten gefunden wurde, werden alle ungültigen Objekte überprüft, ob sie wieder aktiviert werden können.

Um eine neue Verbindung zu erstellen, kann entweder der Portname (z. B. ttyUSB0 unter Linux oder COM1 unter Windows) ausgewählt oder die UID des Root-Knotens direkt eingegeben werden. Da UIDs weltweit eindeutig sind und sich für eine bestimmte Hardware nie ändern, kann der passende Port automatisch gefunden werden, indem alle verwendbaren Ports gescannt werden. Unter Windows werden alle Ports COMx gescannt, unter Linux und macOS kann ein Namensfilter verwendet werden (Standard ist „ttyUSB*“). Beim Herstellen der Verbindung durch Auswahl eines Ports aus der Liste der verfügbaren Ports wird die vom Gerät ausgelesene UID angezeigt und gespeichert - sofern es sich bei dem Gerät um einen BiDiB-Knoten handelt. Dazu kann eine Checkbox (Autoscan) aktiviert werden - wenn JMRI neu gestartet wird, kann der Port durch Scannen der verfügbaren Ports gefunden werden. Wenn also mehr als eine BiDiB-Verbindung verwendet wird, ist die Port-Bezeichnung des USB-Geräts nicht relevant.

In diesem Fall ist die Hardware nicht direkt mit JMRI verbunden, sondern JMRI verbindet sich mit einem TCP-Server, der sich wiederum mit der Hardware verbindet. Dies kann nützlich sein, wenn ein anderes Programm als Hauptsteuerprogramm verwendet wird und JMRI nur als CV-Programmierer (Decoder Pro). Die Parameter sind die IP-Adresse und die Portnummer des Servers, zu dem eine Verbindung hergestellt werden soll. Die Standardportnummer ist 62875.

Es steht ein BiDiB-Simulator zur Verfügung. Dieser Verbindungstyp hat ein Feld für eine XML-Datei mit der simulierten Konfiguration. Der Speicherort für diese Datei ist das Profilverzeichnis.

JMRI-Systemnamen bestehen im Allgemeinen aus einem Systemverbindungspräfix Xn, wobei X der Systemverbindungsbuchstabe ist und n entweder leer oder bei Mehrfachverbindungen eine Zahl ist, gefolgt von dem Typbuchstaben („T“ für Weichen, „L“ für Lampen, „S“ für Detektoren und „R“ für Melder (Lokadressenrückmeldung, Reporter) und die Systemadresse.

Für BiDiB ist der Systemverbindungsbuchstabe „B“, die Systemadresse ist ein String mit der BiDiB-Adresse.

Die BiDiB-Adresse hat generell die Form:

Knoten:Adresse

Ein Knoten auf dem BiDiBus wird entweder durch seine weltweit eindeutige Kennung (UID) identifiziert, die eine 40-Bit-Hexadezimalzahl ist, oder durch einen im Knoten konfigurierten Benutzernamen (mit dem BiDiBWizard). Die hexadezimale UID muss mit einem „X“ beginnen, Benutzernamen müssen mit einem Buchstaben beginnen (besser nicht mit „X“) und dürfen nur andere Buchstaben, Zahlen, Unterstriche („_“) oder Bindestriche („-“) enthalten. Dies ist eine Einschränkung von JMRI für BiDiB, nicht für BiDiB selbst. Die Knotenspezifikation ist unabhängig von Groß- und Kleinschreibung.

Der Knotenteil der Adresse kann weggelassen werden (einschließlich Doppelpunkt), in diesem Fall wird automatisch das Interface (Root Node, d. h. der direkt mit JMRI verbundene BiDiB-Knoten) verwendet.

Der Adresse auf dem Knoten kann ein Adresstyp als Buchstabe vorangestellt werden, und – nur für Portadressen – kann ein Porttyp als Buchstabe folgen. Die Nummer ist erforderlich und die beiden Buchstaben sind optional. Werden sie weggelassen, werden geeignete Standardeinstellungen in Abhängigkeit von den Fähigkeiten des Knotens ausgewählt: Nur eine Zentrale hat DCC-Adressen, Weichen sind bevorzugt Accessories und Lichter sind bevorzugt Ports (digitale Pins des Geräts). Die allgemeine Form einer Adresse auf einem Knoten ist also:

xny

wobei x der optionaler Adresstyp ist, n die numerische Adresse und y der optionale BiDiB-Porttyp.

In JMRI werden in deutscher Sprache Belegtmelder als Detektoren (engl. Sensors) bezeichnet, Railcom Rückmelder als „Melder“.

Die Bezeichnung „Weichen“ (engl. Turnouts) in JMRI bezieht sich nicht unbedingt auf tatsächliche Weichen, sondern eher auf ein einen generellen I/O-Port der Hardware, der die beiden Zustände An und Aus einnehmen kann. In BiDiB sollten Weichen aber nicht direkt über die Ports gesteuert werden, sondern als Accessories angesprochen werden. Diese Auswahl geschieht über den Addresstyp-Buchstaben.

Liste der Adresstypen:

Liste der BiDiB Porttypen:

Beispiele (das Interface (Rootnode) wird als Zentrale angenommen und hat die UID 0d68001234 und „MeinKnoten“ ist der Nutzername):

BiDiB Belegtmelder und Eingangsports werden Detektoren zugeordnet.

BiDiB-Accessories sind das Äquivalent zu Weichen. Sowohl Signallampen als auch tatsächliche Weichen können sich auf JMRI-Weichen beziehen. Signale sollen aber über „Signalmasten“ bedient werden (siehe weiter unten).

BiDiB-Ports werden normalerweise Lampen (Lichter, Lights) zugeordnet. BiDiB-Ports unterstützen entweder ein flaches Adressierungsmodell oder ein typbasiertes Adressierungsmodell. Das Adressierungsmodell wird durch die Firmware des Knotens bestimmt. Beim flachen Adressierungsmodell werden alle verfügbaren Ports einfach von 0 bis zur Anzahl der Ports minus 1 nummeriert. Jeder Port muss im Knoten (z. B. mit dem BiDiBWizard) als einer der oben genannten Porttypen konfiguriert werden, der von der Hardware selbst unterstützt wird. In diesem Fall ist der Buchstabe des Porttyps in der JMRI-Systemadresse nicht erforderlich, da der Typ vom Knoten gelesen wird.

Wenn der Knoten das typbasierte Adressierungsmodell verwendet, sind Porttypen in der Firmware fest kodiert und können nicht geändert werden. Jeder Porttyp hat einen eigenen Adressbereich beginnend bei 0 bis zur Anzahl der Ports für diesen Typ minus 1. In diesem Fall ist der Porttyp Teil der Portadresse und der Porttypbuchstabe wird in der BiDiB-Adresse benötigt. Siehe die Beispiele oben.

Es wird ein Signalmasttyp für BiDiB-Accessories bereitgestellt, bei dem ein JMRI-Aspekt direkt einem BiDiB-Accessories-Aspekt zugeordnet werden kann. Die Signalbilder können programmiert werden in den BiDiB-Knoten mit Makros über den BiDiB-Wizard. Andere Signalmasttypen (z. B. der Matrix-Typ) können „Weichen“ zugeordnet werden.

Belegtmelder, die die Rückmeldung von Lokadressen unterstützen, melden diese Adresse an einen JMRI-Melder. Jede Melderadresse hat eine Belegtmelderadresse mit der gleichen Nummer.

Wenn JMRI über dieses System mit einer Anlage verbunden ist, wird ein BiDiB-Menü wird angezeigt:

• Traffic Monitor
• Start/Stopp BiDiB über TCP Server
  Der Server hört auf Port 62875 auf eingehende Clients, leitet alle Nachrichten des Clients an die Systemverbindung weiter und sendet alle von der Verbindung eingehenden Antwortnachrichten an alle verbundenen Clients. Das ist so etwas wie das Gegenteil der oben erwähnten „BiDiB over TCP“-Systemverbindung.

BiDiB-Hardware kann normalerweise in vielen Aspekten konfiguriert werden, einschließlich der Definition von Makros. Dies ist nicht im Umfang von JMRI. Stattdessen gibt es den BiDiB-Wizard. Der BiDiB-Wizard ist ein externes Tool - ebenfalls in Java geschrieben - und verwendet die gleiche zugrunde liegende BiDiB-Bibliothek (jbidibc).

Mit diesem Tool werden alle Knotenparameter konfiguriert, z.B: der Knoten-Nutzername, die Portkonfigurationen und viele andere Parameter. Daher ist kein weiteres Konfigurationstool in JMRI integriert. Der BiDiB-Wizard kann mit dem oben genannten BiDiB-über-TCP-Server verbunden werden.

Anfangs gab (und gibt) es in JMRI dafür Signal-Heads, dort definiert man einzelne Lampen, die ihrerseits „Turnouts“ steuern, denen dann BiDiB-Ports zugeordnet werden können.

In BiDiB sind für Signale allerdings Accessories vorgesehen, die nicht nur Ein und Aus können, sondern die eine Anzahl von „Aspects“ haben und über Macros eingestellt werden kann, welche Lampen bei welchen Aspect leuchten sollen. Nebenbei wird bei Accessories auch die Übertragung zur Hardware mittels Bestätigungs-Meldungen gesichert. Die Programmierung solcher Accessories und Macros geht mit dem BiDiBWizard, bitte die Doku dazu dort lesen.

In JMRI wurden dann „Signal Masts“ erfunden, die ein eigenes Objekt darstellen, der Systemname wird von JMRI allerdings vorgegeben, enthält aber in Klammern eine Connection-spezifische Adresse (ein Connection ist das Bindeglied zur jeweiligen Hardware, man könnte auch „Treiber“ sagen). Man sieht schon, hier muss es eine explizite Unterstützung für BiDiB geben. Das ist auch der Fall, es gibt ein extra SignalMast Objekt „BiDiB Accessory Aspect“, das eben ein BiDiB-Accessory unterstützt.

Wie legt man also ein Signal Mast an? Man öffnet die Tabelle „Signal Masts“ unter Tools→Tables und klickt „Add“ rechts unten.

Der folgende Dialog erscheint:

User Name ist frei wählbar, als Signal System muss „DB HV 1969“ ausgewählt werden, denn damit werden die Aspekts des Signals definiert. In Mast Type ist dadurch eine Liste erstellt, die die Signaltypen im HV-System darstellt. JMRI kennt also das deutsche HV-System. In diesem Fall ein Ausfahrtsignal mit Vorsignal. Als Mast Driver muss natürlich „BiDiB Accessory Aspect“ gewählt werden, die Connection ist BiDiB und unter Accessory Address wird die BiDiB-Adresse des Accessories eingestellt, wie man sie von den anderen Objekten kennt, in diesem Fall ist es ein BiDiB-Knoten mit dem Username „N210“ und dort Accessory 3 (man kann auch explizit „N210:a3“ schreiben, aber bei Knoten, die Accessories haben, ist „a“ default).

Die folgenden Felder geben die möglichen Aspekts eines solchen Signals an, es ist die Aspekt-Nummer einzutragen, die man mit dem BiDiBWizard in der Hardware definiert hat. Im Beispiel wurden die Aspects einfach von oben nach unten durchnummeriert, nur HP00 sollte immer Aspekt 0 haben.

Der Button „Create“ erzeugt das Signal und die Tabelle enthält einen neuen Eintrag:

Man sieht den etwas kruden Systemname und kann in der Spalte „Aspekt“ gleich mal die verschiedenen Aspekts des Signal ausprobieren. Dieser Signal Mast kann nun in den Panels verwendet werden.

Gültige Systemnamen sehen folgendermassen aus:

BF$bsm:DB-HV-1969:exit_distant_short(N210:3)

wobei die einzelnen Felder bedeuten:

• B - Der Systemverbindungsbuchstabe
• F - Zeigt einen Signalmast an
• $bsm - Zeigt einen BiDiB Signalmast an
• DB-HV-1969 - Signal System, das deutsche DB HV 1969 System in diesem Fall
• exit_distant_short - Signaltyp, kombiniertes Ausfahrtsignal mit Vorsignal in diesem Fall
• N210:3 - BiDiB Accessory Adresse, Accessory 3 des BiDiB Knotens N210 in diesem Fall