Hallo allerseits,

ich möchte mit diesem Beitrag auf die Nutzung von BiDiB mit der Tams MC2 näher eingehen. Vorab sei gesagt, dass ich für diesen Bericht zwei BiDIB-Bausteine ausgeliehen bekommen habe, die ich nach dem Test wieder zurückgebe. Die MC2 selber gehört mir.

Ein kleiner Überblick über BiDiB

BiDiB steht für BiDirektionaler Bus, über den die Steuerung verschiedener Aufgaben bei der Modellbahn erfolgen kann. Bidirektional deshalb, da nicht nur Kommandos von der BiDiB-Zentrale an die BiDiB-Module gesendet werden können, es können auch BiDiB-Module Daten an die Zentrale senden. Weiterhin erlaubt BiDiB auch die Konfiguration bzw. den Firmware-Update von BiDiB-Modulen.

Die Verbindung zwischen PC und BiDIB-Zantrale kann entweder über USB oder Netzwerk erfolgen. Letzters wird mit netBiDiB bezeichnet. Die MC2 unterstützt netBiDiB.

Testaufbau

Zunächst ein Übersichtsbild mit allen Komponenten und der MC2.



Im Detail sind das von links nach rechts:

- Trafo für die Stromversorgung des Tams WD-34.BiDIB Weichendecoder
- Tams s88-3 Rückmeldemodul für den s88-Bus
- Weichenantrieb Modellbau Glöckner Bestellnummer GLÖZ/002BS
- Tams WD-34.BiDIB Weichendecoder
- Tams BiDiB-Rückmeldemodul Hermes
- C-Gleis angeschlossen an Tams Hermes



Eigentlich verwendet man für BiDiB grüne und für s88 blaue Patch-Kabel. Für meinen Test habe ich für BiDiB aber graue und für s88 rote Patch-Kabel verwendet. Bitte nicht verwirren lassen.

Tams MC2 und BiDiB

Die MC2 wird über einen Web-Browser konfiguriert. Die Web-Oberfläche der MC2 nennt sich MC2 Toolbox. Im Bereich Betrieb -> BiDiB listet die MC2 Toolbox alle angeschlossenen Komponenten, die bei BiDiB mit Knoten bezeichnet werden, auf. Die MC2 selber ist auch ein BiDiB-Knoten. Jeweils rechts stehen dann die Details zum Knoten, der im Knotenbaum markiert ist.







Hier zeigt sich auch gleich eine spezielle Fähigkeit der MC2. s88-Module, die am s88-Bus angeschlossen sind, werden von der MC2 virtuell in BiDiB eingebunden. D.h. man kann s88-Module via BiDiB ansprechen.





iTrain

Der Markt bietet verschiedene Programme zur Modellbahnsteuerung. Stellvertretend für Programme, die die MC2 mit netBiDiB ansteuern können, zeige ich iTrain. Zunächst eine Übersicht, die das Gleisbild von iTrain zeigt mit einer Weiche, einem Rückmeldekontakt, einer Anzeige des MC2-internen Boosters und dem iTrain-Rückmeldemonitor.



Ähnlich wie in der MC2-Toolbox, bietet auch iTrain eine Übersicht aller an die MC2 angeschlossenen BiDiB-Knoten.



Hier ein Beispiel, wie man eine Weiche in iTrain definiert, die über BiDiB angesprochen wird.



Und hier ein Beispiel, wir ein Rüclmeldekontakt in iTrain unter Nutzung von BiDiB definiert wird.



Sonderfall TrainController

TrainController unterstützt in der aktuellen Version TC 10 B1 BiDiB nicht. Es gibt eine Laborversion von TC, die BiDiB in eingeschränkter Form anbietet. Eingeschränkt deshalb, weil man damit keine Lokomotiven steuern kann und weil nur Zentralen unterstützt werden, die über USB mit dem PC verbunden werden. netBiDiB wird von TC nicht unterstützt. Weiterhin ist wichtig zu nennen, dass die TC-Laborversion keine offiziell unterstützte Version von TC ist. Funktionen wie BiDiB, die in einer Laborversion enthalten sind, könnten bei der nächsten offiziellen Version von TC entfallen.

Wie können BiDiB-Module, die an der MC2 angeschlossen sind, dennoch von TC aus genutzt werden, denn TC unterstützt kein netBiDiB und die MC2 hat keine USB-Schnittstelle.

Die MC2 unterstützt ein weiteres Protokoll für die Kommunikation zum PC, nämlich p50x. p50x über Netzwerk wird offiziell von TC 10 B1 +Hardware unterstützt. Es bedarf dazu keiner TC-Laborversion.

So wie die MC2 s88-Module virtuell in BiDiB einbinden kann (siehe oben), so kann sie anders herum auch BiDiB-Module in das Protokoll p50x einbinden. Und damit auch mit TC nutzbar machen. Um diese Funktionalität nutzen zu können, muss man BiDiB-Zubehör-Decoder mehrere DCC-Weichenadressen und den BiDiB-Rückmeldemodulen einen s88-Kontaktnummernbereich in der MC2 Toolbox zuordnen. Und das geht wie folgt.

In der MC2 Toolbox geht man nach System -> Zubehör. Unten sieht man alle angeschlossenen BiDiB-Zubehörmodule. Hier das Tams WD-34.BiDiB.



Nun klickt man das Modul an und rechts öffnet sich eine Liste. Das WD-34.BiDiB kann bis zu vier Weichen schalten, so dass man in der Liste für jede Weiche eine separate DCC Weichenadresse definieren kann. Die Adressen können beliebig vergeben werden und müssen nicht fortlaufend sein. "xxx" steht für noch nicht definiert.



Nach Abschluss der Eingabe klickt man erneut das Modul an und die Liste der Adressen verschwindet wieder.



Das gleiche Vorgehen gibt es auch für die Rückmeldung. In der MC2 Toolbox wechselt man nach System -> Rückmelder und sieht unten ebenfalls eine Liste alles BiDiB-Rückmeldemodule. Hier das Tams Hermes.



Nun klickt man auf ein Modul und rechts öffnet sich die Eingabe für "Beginn Bereich". Hier ist nun folgendes zu beachten. Die Eingabe gibt die Anzahl an Kontakten an, ab der das BiDiB-Rückmeldemodul über s88 ansprechbar sein soll. Dieser Bereich muss nach den am s88-Bus angeschlossenen s88-Modulen liegen.



Konkret: Ich habe an der MC2 ein s88-Modul angeschlossen. Das hat 16 Eingänge. Die MC2 beginnt immer bei Kontakt 0. Somit sind Kontakt 0-15 für das s88-Modul am s88-Bus reserviert. Das BiDiB-Rückmeldemodul muss danach folgen und hat selber 8 Eingänge, also Kontakte 16-23. Aus diesem Grund wird "Beginn Bereich" auf 16 gesetzt.

In TC und im MC2 Toolbox Rückmeldemonitor spricht man die Rückmeldekontakte aber immer über die s88-Namenskonvention an; also in 16er Modul-Einheiten. Das bedeutet für unser Beispiel. Das s88-Modul wird angesprochen über Modul 1 Kontakt 1-16 und das BiDiB-Modul über Modul 2 Kontakt 1-8. Im Grunde nicht schwierig, wenn man einmal verstanden hat, wie alles gemeint ist. Und so sieht es dann aus, wenn am BiDiB-Rückmeldemodul Kontakt 8 belegt ist. Anzeige in der MC2 Toolbox:



Und in TC:



Für die Einbindung von BiDiB-Module in das p50x-Protokoll ist unbedingt wichtig, dass die MC2 die neueste FW 1.7.3 und die neueste Toolbox 1.8.5 installiert hat. Infos dazu auch hier: RE: Neue Zentrale Tams MC2 (10)

Ich hoffe, dass ich Euch einen Überblick über BiDiB mit der Tams MC2 geben konnte.

Viele Grüße Dirk

Hallo,

Nicht so lang und detailliert aber ich habe auch so etwas in französische auf meine Website geschrieben: http://www.digi-train.ch/modelisme/eclairage_maquette.html

Hallo Dirk!

Ein interessanter Bericht!

Zitat von nakott im Beitrag #1

---

oder Netzwerk erfolgen. Letzters wird mit netBiDiB bezeichnet. Die MC2 unterstützt netBiDiB.

---

Zitat von nakott im Beitrag #1

---

Stellvertretend für Programme, die die MC2 mit netBiDiB ansteuern können, zeige ich iTrain.

---

Hallo Dirk,

Zitat von nakott im Beitrag #1

---

Stellvertretend für Programme, die die MC2 mit netBiDiB ansteuern können, zeige ich...

---

Hallo!

Zitat von vikr im Beitrag #4

---

Hallo Dirk,

Zitat von nakott im Beitrag #1

---

Stellvertretend für Programme, die die MC2 mit netBiDiB ansteuern können, zeige ich...

---

wurrde von TAMS nicht auch die Z21APP als Anzeige- und Bedienprogramm in Aussicht gestellt?

MfG

vik

---

Hallo Eckhart,

Zitat von Eckhart im Beitrag #5

---

Wenn sich die Z21 (und die zugehörige App) auch in Richtung (net?)BiDiB Kompatobilität bewegen würden, dann könnte ich mir das gut vorstellen. Wenn nicht, dann verstehe ich deine Anmerkung zum Thema BiDiB nicht!?!?

---

Hallo Eckhart,

Zitat von Eckhart im Beitrag #3

---

Kann man Zubehördecoder und Rückmelder über netBiDiB direkt an die MC2 hängen?

---

Zitat von Eckhart im Beitrag #3

---

Kann man Zubehördecoder und Rückmelder über netBiDiB ...... direkt an iTrain hängen?

---

Eine hoffentlich hilfreiche Erklärung zu BiDiB und netBiDiB von einem, der eine große Anlage mit mehreren dutzend BiDiB-Modulen betreibt:
Der BiDiBus ist ein klassischer Feldbus ( kommt ursprünglich daher, weil man damit die Daten von Messsensoren im Feld sprich über viele m² verteilt eingesammelt hat. )
Der BiDiBus sorgt für die sichere Kommunikation aller Module mit dem Bus-IF und verteilt gleichzeitig das DCC-Signal für die Booster.
Die BiDiB-Architektur ist dezentral, d.h. die Steuer- oder Sensormodule sitzen dort, wo man sie braucht, die Weichendecoder direkt an den Weichen, die Belegtmelder in der Nähe der Gleisabschnitte.
Im Idealfall werden nur Stromversorung und das BiDiBus-Kabel über die Anlage gezogen.
Das BUS-IF wird normalerweise per USB an den PC angeschlossen.
U.a deshalb, weil es immer wieder Ärger mit USB-Treibern gibt, wurde NetBiDiB entworfen. Damit wird die Verbindung von PC zum BiDiBus über Ethernet hergestellt.
Ein Interface, das das kann, ist die mc². Es gibt derzeit keine Module, die über NetBiDiB angeschlossen werden, ich sehe darin auch keinen Vorteil bei stationären Modulen ( s.u.)
Wenn man jetzt einen Schritt weitergeht, könnte man statt des BiDiBus auch alle Module direkt an ein LAN anschliessen.
Dagegen sprechen eine ganze Menge Fakten:
1. statt eines simplen seriellen Bussystems mit durchlaufender Verkabelung hätte man dutzende von einzelen Netzwerkkabeln, die über NW Switches zusammengefasst werden müssten.
2. Der Verwaltungsaufwand in Sachen Netzwerkadressen und DNS Service wäre sehr hoch und erfordert entsprechende Performance der NW-Server
3. Ein LAN-IF pro Modul ist sehr viel teurer als ein serielles IF
4. Der mögliche Datendurchsatz über LAN ist für eine MoBa Steuerung völlig übertrieben, der serielle Bus ist selbst bei 100 Modulen weit entfernt von Vollauslastung
5. DCC muss ich trotzdem an die Booster bekommen

Für WLAN sieht das Ganze noch schlechter aus, der Verwaltungsaufwand ist noch höher als beim kabelgebundenen LAN und die Betriebssicherheit ist wesentlich geringer, alleine schon deshalb,
weil man typischerweise jede Menge fremde Sender aus der Nachbarschaft als Störer hat.
WLAN in der klassischen Form ist nicht Echtzeit geeignet, daher keine gute Lösung.
Man sieht das daran, wenn das Smartfone zum Steuern in der gegenüberliegenden Raumecke kurz das WLAN verliert, dann wird der Lokführer sehr nervös ........
Und die mc² ist ein sehr gutes BiDiB-IF insbesondere dann, wenn man nicht nicht BiDiB, sondern auch andere Schnittstellen braucht.
Gruß Thomas

Hallo,

Zitat von tomholzwurm im Beitrag #8

---

die mc² ist ein sehr gutes BiDiB-IF insbesondere dann, wenn man nicht nicht BiDiB, sondern auch andere Schnittstellen braucht.

---

Darf ich mich da mit einer Frage reinhängen?

Auf der Seite https://tams-online.de/epages/642f1858-c...e/Digital/BiDiB wird BiDiB mit seinen Bausteinen von Tams erklärt.
Nachdem die Redbox nicht mehr erhältlich ist, ist diese Grafik eigentlich veraltet.

Aber ich versteh sie trotzdem nicht.

Einerseits ist Zeus mit einem BiDiBus (sic!) an den PC angeschlossen und speist dann den BiDiBus.

Andererseits ist die Redbox mittels "Digitale Fahrbefehle" (sic!) an den PC angeschlossen und gibt diese an den 1. BiDiB-Booster weiter, der dann via BiDiBus an den zweiten die "digitalen Fahrbefehle" weitergibt...

Im BiDiBus sind die Leitungen 7+8 das "stinknormale" DCC-Signal (unverstärkt).

Und lt. Beschreibung kriegen die Booster nur die Fahrbefehle und Zeus nur die Schaltbefehle und macht die Rückmeldung.

Weiters las ich, dass ich, dass die Booster entweder über BiDiB ODER über den DCC-Eingang erhalten dürfen, sonst kanns blitzen.

Meine Fragen dazu:
1) Wie ist Zeus wirklich mit dem PC verbunden? (Darstellung falsch?)
2) wie ist die Redbox wirklich mit dem PC verbunden?
3) fehlt da zwischen dem PC und Zeus bzw. Redbox noch etwas?
4) Die Lokbefehle und die Schsltbefehle sind doch alle im DCC Signal vereint.
Wenn die aufgetrennt werden, müssten doch eigentlich 2 getrennte BiDiBus-Stränge zu Schalt/Rückmeldebausteinen und zu den Boostern sein.
Warum sind die verbunden

Vielen Dank

Jakob

Hi Jakob,

eine Erklärung zum Bild, so wie ich denke:

ZEUS und RedBox (RB) sind jeweils per USB mit dem PC verbunden. Schalten und Rückmelden geht über BiDiB. Fahren über die RB. Die BiDiB Booster bekommen das unverstärkte Gleis-Signal von der RB, denn das kann ZEUS nicht erzeugen. Die BiDiB-Booster melden den Status von Strom, Spannung und Temperatur über BiDiB und ZEUS an den PC. Auf dem PC benötigt es dann z.B. iTrain.

Die MC2 vereint dann quasi alles in einer Box + LAN Anbindung zum PC statt USB.

Viele Grüße Dirk

Hallo Jakob,

Zitat von scientific im Beitrag #10

---

1) Wie ist Zeus wirklich mit dem PC verbunden? (Darstellung falsch?)
2) wie ist die Redbox wirklich mit dem PC verbunden?
3) fehlt da zwischen dem PC und Zeus bzw. Redbox noch etwas?
4) Die Lokbefehle und die Schsltbefehle sind doch alle im DCC Signal vereint.

---

Also Zeus und Redbox werden am Seriellen COM-Port angeschlossen?

Das erklärt aber immer noch nicht die doppelte Einspeisung des DCC-Signals in den BiDiBus.

Hallo,

Zitat von scientific im Beitrag #13

---

Das erklärt aber immer noch nicht die doppelte Einspeisung des DCC-Signals in den BiDiBus.

---

Dass das Schema veraltet ist, denk ich mir.

Gibts ein aktuelles auch auf der Website?

Aber erklär mir bitte, was es dann bedeuten soll, dass Fahrbefehle und Schaltbefehle getrennt sein sollen?
Das müssten dann ja 2 unabhängige BiDiB-Busse sein.

Wo gibts eine aktuelle Zeichnung und Erklärung dazu?

DCC-Befehle (Fahren, Schalten) gehen über die Redbox (graue Linie), BiDiB-Schaltbefehle und Rückmeldungen gehen über den Zeus (grüne und blaue Linen).
Zusätzlich werden die DCC-Daten in das BiDiB-Kabel über den Booster rechts eingespeißt, da BiDiB auch Fahrbefehle übertragen kann, wie schon geschrieben, der Zeus kann aber kein DCC erzeugen.

Mit der mc2 wird der Zeus ersetzt und die Redbox und die graue Line entfernt, da die mc2 DCC erzeugen kann.

Grüße
Stephan

Hallo zusammen,

noch eine kleine Anmerkungen. Im Bild sind alle Decoder für Schalten am BiDiB Bus. D.h. in diesem Beispiel erzeugt die RB nur das Gleissignal für Fahren. Das macht großen Sinn, denn so kann man die eh relativ geringe Bandbreite am Gleis nicht auch noch mit Schltebefehlen weiter reduzieren und es bleibt maximal viel für Fahren.

Viele Grüße Dirk

Hallo Dirk,

Zitat von nakott im Beitrag #17

---

in diesem Beispiel erzeugt die RB nur das Gleissignal für Fahren.

---

Hallo vik,

das Bild zeigt den BiDiB Schaltdecoder WD-34.BiDiB. Er wird direkt über BiDiB und ZEUS vom PC gesteuert.

Beispiel iTrain: In iTrain würde man zwei Digitalsysteme anlegen. a) ZEUS und b) RedBox. In iTrain legt man bei der Definition der Weichen etc. fest, über welches Digitalsystem der Schaltbefehl gesendet wird. In diesem Fall über ZEUS. Nur die Loks wären dem Digitalsystem RB in iTrain zugeordnet.

Es würde auch gemischt gehen. Dann würde die RB nur die Schaltbefehle erzeugen, für die sie den Befehl dazu von iTrain bekommt.

Viele Grüße Dirk

Hallo vik,

Nachtrag: Schau mal diesen Screenshot



Dort wo MC2 steht würde ZEUS stehen. Der Weichendecoder wird über BiDIB mit dem Schaltbefehl versorgt.

Zum Vergleiche eine Weiche, die von iTrain über die RB gesteuert wird. Hier gibt man, wie Du es kennst, auch die DCC/MM Weichenadresse ein.



Viele Grüße Dirk

Zitat von scientific im Beitrag #15

---

Wo gibts eine aktuelle Zeichnung und Erklärung dazu?

---

Ich hab mir jetzt das nochmal durchgelesen:
https://bidib.org/transport/bidibus.html#T21
Demnach sind die Leitungen 7+8 das stinknormale DCC Signal (unverstärkt) und nur das Booster-Signal, also die Fahrbefehle für die Loks und die Schaltbefehle für Fahrzeuge (Licht, Sound...)

Die Schaltbefehke für Magnetartikel, Anlagenbeleuchtung, Servos und die Rückmeldeinfos (Railcom auch?) der Gleisbesetztmelder dürften dann über die Leitungen 4+5 (DATA) gehen.

Damit speist die RB die Leitungen 7+8 und Zeus die Leitungen 4+5.

So macht die Zeichnung dann wieder Sinn für mich.

Was ich noch immer nicht herausgefunden habe:
Wie wird Zeus bzw die Redbox an einen Computer angeschlossen?
USB? Seriell (COM-Port)?

Die mc² wird ja glaub ich per Ethernet/öLAN-Kabel angehängt.

Lg

Hallo,

Zitat von scientific im Beitrag #22

---

Was ich noch immer nicht herausgefunden habe:
Wie wird Zeus bzw die Redbox an einen Computer angeschlossen?
USB? Seriell (COM-Port)?

---

Zitat von nakott im Beitrag #11

---

ZEUS und RedBox (RB) sind jeweils per USB mit dem PC verbunden.
Die MC2 vereint dann quasi alles in einer Box + LAN Anbindung zum PC statt USB.

---

Die eine Antwort ist mir tatsächlich durchgerutscht.

Und wie lautet die Antwort auf die Adernbelegung und die darüber transportierten Daten?

Lg

Zitat von scientific im Beitrag #22

---

Demnach sind die Leitungen 7+8 das stinknormale DCC Signal (unverstärkt) und nur das Booster-Signal, also die Fahrbefehle für die Loks und die Schaltbefehle für Fahrzeuge (Licht, Sound...)

Die Schaltbefehke für Magnetartikel, Anlagenbeleuchtung, Servos und die Rückmeldeinfos (Railcom auch?) der Gleisbesetztmelder dürften dann über die Leitungen 4+5 (DATA) gehen.

Damit speist die RB die Leitungen 7+8 und Zeus die Leitungen 4+5.

---