Wie ist BiDiB entstanden?

Bidirektionale Datenübertragung war seitens der Industrie schon seit 2004 angekündigt und wurde sukzessive auch in Dekodern implementiert. Erste Rückmeldersysteme kamen 2009 auf den Markt, diese waren aber noch nicht für eine anlagenweite Installation gedacht.

Mit Erscheinen von 16-fach Rückmeldern in 2010 (Fa. Blücher, OpenDCC) entstand der Bedarf nach einem möglichst gemeinsamen Rückmelderbus. Nachdem das Produkt RC-Talk von Tams bereits im Markt verfügbar war, wurde ausgehend von RC-Talk in längeren Diskussionsrunden ein leistungsfähiger und zukunftssicherer Nachfolger entworfen.

Dieser Entwurf beinhaltet Konzepte und Strukturen, welche auch die Lösung für die sonstigen Busprobleme an der Modellbahn sind. Der ursprüngliche als Rückmeldebus gedachte Entwurf hatte also das Potential, ein universeller Modellbahnbus zu werden. Deshalb wurde und wird dieser Entwurf sukzessive erweitert, um auch Zentralen, Booster, Zubehör und Stellpulte zu umfassen.

Nachdem wir von Konzept überzeugt waren und sich der Bus in der Simulation bewährte, wurde Ende 2010 beschlossen, einen Testaufbau aus Interface, verschiedenartigen und mehreren Knoten aufzubauen und zu erproben.

An dieser Stelle gilt mein Dank den Diskussionspartnern Hrn. Tams, Hrn. Blücher und Hrn. Herzog für den konstruktiven Disput sowie Hrn. Fischer für die Übersetzung.

BiDiB-Historie

HeuteAktive Diskussion über Ergänzungen und Verbesserungen des Protokolls
März 2015Erweiterung und Optimierung der Ansteuerung von Zubehörknoten, BiDiB Protokollversion 0.6 (siehe unten).
2014Weiterer Ausbau der Unterstützung von Railcom und POM
Dezember 2013Erfolgreicher Ausstellungsbetrieb einer Großanlage mit über 20 Boostern und 600 Meldeabschnitten.
August 2012Zubehörknoten entstehen und mit Ihnen auch mehrere Hostprogramme wie z. B. Wizard oder Monitor
Juni 2012Erste Serie von Gleisbesetztmeldern / Boostern.
Februar 2012Funktionierender Testaufbau eines BiDiBus-Systems mit mehreren Knoten und automatischem Anmelden.
Juli 2011Erste funktionierende Verbindung PC mit einem BiDiB-System
Dezember 2010Erste Veröffentlichung auf www.bidib.org; Definition von BiDiB (speziell Rückmelder) und BiDiBus, Liste der Unterstützer

Siehe hierzu auch die Revisionsgeschichte der Spezifikation.

Zusammenfassung der Änderungen von V0.5 ⇒ V0.6

Im Wesentlichen umfassen diese Änderungen die Ansteuerung und Konfiguration von Zubehörknoten. Im Bereich Konfiguration unterscheidet sich V0.5 und V0.6, alle anderen Bereiche (Portansteuerung, Melder, Fahren, Accessory) sind identisch oder kompatibel.

  • Neue Befehle für die Konfiguration von Ports: CONFIGX_*, die bisherigen CONFIG-Befehle sind nicht mehr zu verwenden.
  • Innerhalb des CONFIGX-Systems sind weitere Konfigurationsmöglichkeiten hinzugekommen: z. B. BIDIB_PCFG_IO_CTRL, BIDIB_PCFG_TICKS
  • MSG_CONFIGX_GET_ALL zum schnellen Einlesen der Konfiguration eines Knotens
  • Einführung eines flachen Portmodells als Alternative zum bisherigen typorientierten Portmodell, erkennbar an FEATURE_CTRL_PORT_FLAT_MODEL. Beide Portmodelle benutzen ein (generalisiertes) Bytepaar PTYPE/PNUM zum Adressieren des Ports.
  • Das flache Portmodell unterstützt Typ-Umstellung von Ports durch eine CONFIGX-Nachricht (BIDIB_PCFG_RECONFIG)
  • MSG_LC_NA hat einen optionalen Parameter ERRCAUSE bekommen
  • Überarbeitung der Ports: Neuer Porttyp INPUT, OUTTYPEs wurden in PORTTYPEs umbenannt, SPORT, LPORT und ANALOG in SWITCH, LIGHT, und ANALOGOUT; zugehörige Features entsprechend angepasst.

Zusammenfassung der Änderungen von V0.6 ⇒ V0.7

Weiter verbessert wurde die direkte Ansteuerung und Konfiguration von Zubehörports:

  • MSG_LC_PORT_STAT liefert jetzt auch Input-Zustände, MSG_LC_PORT_QUERY (zuvor MSG_LC_OUTPUT_QUERY) fragt auch diese ab. Die bisherigen MSG_LC_KEY*-Nachrichten sind nicht mehr zu verwenden.
  • MSG_LC_PORT_QUERY_ALL zum schnellen Einlesen der Portzustände eines Knotens

Generell ist nun vorgeschrieben, dass unbekannte optionale Parameter einfach ignoriert werden, d.h. "zu lange" Nachrichten sind verpflichtend zu unterstützen. Dies sichert die Vorwärts-/Rückwärts-Kompatibilität bei Erweiterungen des Protokolls in zukünftigen Revisionen.

Darüberhinaus sind einige Verfeinerung aufgenommen worden:

  • MSG_ACCESSORY_PARA meldet im Fehlerfall den unbekannten Parameter.
  • BIDIB_ACCESSORY_PARA_STARTUP konfiguriert das Einschaltverhalten von Accessorys.
  • BIDIB_ACCESSORY_PARA_OPMODE verleiht Accessorys einen Betriebsmodus und erlaubt damit (auch lokalen) Nothalt, etwa für Drehscheiben.
  • BIDIB_PCFG_IS_PAIRED schützt gegeneinander treibende Ports vor Überlastung.
  • Motorports lassen sich jetzt ansteuern (MSG_LC_OUTPUT).
  • Hauptgleisprogrammierung unterstützt nun die Befehlsmodi XPOM und Short Form.
  •