| System | Busmedium / Topologie | Datenrate / Baudrate | Max. Nutzdaten pro Frame | Max. Nodes pro Segment | Erweiterung / Repeater | Protokollart | Bidirektional / Rückmeldung | Bemerkungen |
|---|
| Loconet1) (Digitrax) | TTL, seriell, Daisy Chain / Stern | ~16,6 kBit/s | Wenige Bytes | 128 (theoretisch bis 255) | Segmentierung möglich, Kabelqualität beachten | Multi-Masterr | Ja, alle Geräte können senden | Einfach, robust, weit verbreitet; Peer-to-Peer erlaubt große Anlagen |
| BiDiB2) | RS‑485, 2-Draht, differenziell | 500 kBit/s | Variabel, mehrere Bytes | 32 | Repeater möglich → 127–255 | Master-Slave (Master = Steuerrechner) | Ja, Slaves antworten auf Master-Anfrage | Spezialisierte Architektur für digitale Anlagen; flexible Adressierung |
| VLCB, CBUS3) (MERG, CAN) | CAN-Bus, 2-Draht differenziell | 125 kBit/s | 8 Byte (klassisches CAN) | 32 | Repeater / Segmentierung möglich → bis 255 | Multi-Master (CAN mit ACK) | Ja, ACK & Fehler | Robust, standardisiert; Segmentierung für große Anlagen nötig |
| XPressNet4) (Lenz) | RS‑485, 2-Draht differenziell | 62,5 kBit/s | Variabel, typischerweise 2–4 Byte | 32 | Repeater möglich → bis 256 | Master-Slave | Ja | RS‑485 Limit 32 Nodes pro Segment; Repeater für größere Anlagen üblich |
| ESU CAN (z. B. ECoS) | CAN-Bus, 2-Draht differenziell | 125–500 kBit/s | 8 Byte (klassisches CAN) | 32 | Segmentierung möglich | Master-Slave / Producer-Consumer je nach System | Ja | Klassischer CAN physikalisch; Segmentierung notwendig für viele Geräte |
| DCC (Digital Command Control) | Gleis als Bus (Stromkreis) | ~8 kBit/s über Gleis | Variabel, typischerweise 2–8 Byte | Abhängig von Gleislänge / Stromversorgung | Booster / Trennabschnitte möglich | Master-Broadcast über Gleis; Rückmeldungen optional via RailCom | RailCom5) mit dazu fähigen Dekodern. | Kein festes Node-Limit; physikalische Beschränkung durch Strombelastung |
Bei einem Master-Slave Bus werden die am Bus angeschlossenen Module zyklisch abgefragt (Polling). Dies passiert in der Regel durch die Digitalzentrale oder einer Steuerungssoftware. Die Antwortzeit steigt mit der Anzahl der Module, weil diese alle einzeln abgefragt werden. Das passiert unabhängig davon, ob sich ein Zustand an einem Modul geändert hat.
Bei einem Peer-to-Peer Bus können sich die Teilnehmer untereinander "unterhalten", es ist kein Polling erforderlich. Ein Peer-to-Peer Bus ist auch ein Multi-Master Bus.
Beim Multi-Master, auch Producer/Consumer Bus genannt, gibt es "Produzenten" und "Verbraucher". Bei diesem Bus werden nur Ereignisse (Events) gemeldet. Es ist kein Polling erforderlich. Ändert sich an einem Modul ein Zustand, z.B. weil ein Schalter betätigt wurde oder ein Besetztmelder seinen Status ändert, wird dies über ein Ereignis auf dem Bus mitgeteilt. Alle Module, für die das Ereignis interessant ist, werden darauf reagieren.
Peer-to-Peer und Producer/Consumer können auch mit Polling abgefragt werden, beim Master-Slave Bus gibt es nur Polling. DCC mit Railcom ist eine Besonderheit, es werden im DCC Signal in einer Austastlücke Daten vom Dekoder zur Zentrale übertragen. Der Bus ist nicht ohne weiteres für Rückmelder, Schalter usw. verwendbar.
Der größte Nachteil bei einem Master-Slave Bus ist, das es immer eine zentrale Steuereinheit geben muss, die den Bus kontrolliert und die Busteilnehmer abfragt, auch wenn diese gar nichts zu sagen haben. Möchte man keine zentrale Steuereinheit, dann ist der Multi-Master Bus ideal. In diesem Falle gibt es bei der Modellbahnsteuerung zwei unterschiedliche Verfahren. Daten werden mit einer Adresse an einen anderen Teilnehmer gesandt (das kennen wir von TCP/IP Netzwerker wie das Internet) oder es werden Ereignisse auf den Bus gegeben, die von anderen Teilnehmern verarbeitet werden (CAN).