Der CAN Bus dient als Kommunikationsnetz der Steuergeräte bei Märklin Systems. Ziel ist, allen Geräten zur Steuerung einer Modellbahnanlage ein einheitliches Kommunikationsmedium zur Verfügung zu stellen.

Mittels CAN Meldungen werden Steueraufgaben übermittelt.

Mittels CAN Streams werden Updates und Konfigurationsdaten übertragen.

Die Datenrate ist 250 KBit/s, die maximale Buslänge ist 100m.

Das CAN Protokoll schreibt vor, dass Meldungen mit einer 29 Bit Meldungskennung, 4 Bit Meldungslänge sowie bis zu 8 Datenbyte bestehen. Die Meldungskennung wird aufgeteilt in die Unterbereiche Priorität (Prio), Kommando (Command), Response und Hash.

Die Kommunikation basiert auf folgendem Datenformat:

Priorität (Prio)

Bestimmt die Priorisierung der Meldung auf dem CAN Bus:

• Prio 1: Stopp / Go / Kurzschluss-Meldung
• Prio 2: Rückmeldungen
• Prio 3: Lok anhalten (?)
• Prio 4: Lok / Zubehörbefehle
• Rest Frei

Die Priorisierung wird von den Teilnehmern nicht als Teil der Meldung verstanden, sondern dient zum Priorisieren der Meldung auf dem CAN Bus.

Kommando

Bestimmt das vom Endgerät auszuführende, bzw. das ausgeführte Kommando. Kommandowerte sind eindeutig definiert.

Response

Gibt an, ob die CAN Meldung eine Anforderung oder eine Antwort auf eine vorhergehende Anforderung ist. Grundsätzlich wird eine Anforderung ohne gesetztes Response Bit gesendet. Sobald eine Anforderung ausgeführt wurde, wird sie mit gesetztem Response Bit sowie dem ursprünglichen Meldungsinhalt beantwortet. Die Antwort kann dabei zusätzlich angefragte Werte enthalten. Jeder Teilnehmer am Bus, der die Anforderung ausgeführt hat, bestätigt sie.

Hash

Der Hash erfüllt eine Doppelfunktion. Primär dient er zur Kollisionsauflösung der Meldungen und zur Sicherstellung der Kollisionsfreiheit zum CS1 Protokoll. Sekundär kann er die Folgenummer einer Datenübertragung beinhalten.

Kollisionsfreiheit zum CS1 Protokoll:

Im CAN Protokoll der CS1 wird der Wert 6 für den "com-Bereich der ID", dies sind die Bits 7..9, d.h. Highest Bit im Lowest-Byte (0b0xxxxxxx) und die beiden Bits darüber (0bxxxxxx11), nicht benutzt. Diese Bitkombination wird daher zur Unterscheidung fest im Hash verwendet.

Kollisionsauflösung:

Der Hash dient dazu, die CAN Meldungen mit hoher Wahrscheinlichkeit kollisionsfrei zu halten. Dieser 16 Bit Wert wird aus der UID des Gerätes berechnet. Rechenvorschrift: 16 Bit High UID XOR 16 Bit Low der UID. Danach werden die Bits entsprechend zur CS1-Unterscheidung gesetzt.

Jeder Teilnehmer am Bus hat den Hash empfangener CAN-Meldungen auf Kollisionsfreiheit (zum eigenen Hash) zu prüfen. Wird der eigene Hash empfangen, so ist ein neuer zu wählen. Dieser darf mit keinem weiteren bereits empfangenen übereinstimmen.

Folgenummer einer Datenübertragung:

Wird der Hash zur Kennzeichnung der Paketnummer verwendet, so werden diese Bits bei der Berechnung der Paketnummer ausgeblendet. D.H. bei der 16 Bit Zahl werden die Bits 7 bis 9 ausgeblendet, die obersten 3 Bits sind 0. Der Wertebereich verringert sich entsprechend auf 8192.

Meldungsbestätigung

Wer Anforderungen verschickt muss selbst Sorge dafür tragen, zu erfahren ob die gewünschte Aktion tatsächlich ausgeführt wurde. Die Meldungen werden nicht gesichert über den CAN-Bus übertragen. Der Empfang einer Meldung wird nicht bestätigt. Erst die Ausführung eines Kommandos wird bestätigt, bzw durch das Senden der Bestätigungsmeldung quittiert. Fehlt diese Quittierung, ist davon auszugehen, dass die Aktion nicht ausgeführt wurde.

Sonstiges

• Bei der Kommunikation werden keine Sender + Empfänger Adresse verwendet.
• In der Kommunikation werden keine Remoteframes (=CAN-ID anfragen statt mit Daten senden) verwendet. Im allgemeinen sind die Teilnehmer so konfiguriert dass sie Remoteframes ignorieren
• Byte-Order in den Meldungen ist immer Motorola Big Endian

Auf der CS2 kann - über das Setup / IP - Einstellungen - das Can-UDP-Gateway gestartet werden. Dort kann eine IP-Adresse (Einzel-Adresse oder Broadcast-Adresse) als Ziel-Adresse spezifiziert werden, an die das Gateway sendet. Die Portnummern sind über die Oberfläche nicht einstellbar und sind fest auf 15731 und 15730 gesetzt.

Funktionsweise:

Wenn gestartet, lauscht das Gateway auf dem Ethernet Empfangsport 15731. Es verwirft alle UDP-Pakete, die eine Länge ungleich 13 haben. Pakete der Länge 13 werden als Can-Bus-Pakete interpretiert: 4 Byte Can-Bus-Id (BigEndian oder Network-Order), 1 Byte Länge und 8 Byte Daten, die ggf. mit Nullbytes aufzufüllen sind. Dieses Paket wird dann als Can-Bus-Botschaft auf den Can-Bus gegeben. Nicht abbildbare Bits oder Bytes auf dem CAN-Bus werden nicht beachtet und sollten auf "0" gesetzt werden.

Umgekehrt liest das Gateway alle Can-Bus-Botschaften, wandelt sie in analoger Weise in UDP-Pakete der Länge 13 um und verschickt diese an die spezifizierte IP-Adresse und den Sendeport (15730).

Beispielkonfiguration im lokalen Netz mit dem Netzwerksegment 192.168.2.0

CS2: (192.168.2.20) empfängt auf Port 15731 und sendet an die Broadcast-Adresse 192.168.2.255:15730.
PC1: (192.168.2.10) empfängt auf Port 15730 und sendet an die CS2 (192.168.2.20:15731)
PC2: (192.168.2.11) empfängt auf Port 15730 und sendet an die CS2 (192.168.2.20:15731)

Im Ethernet werden immer Pakete mit 13 Bytes übertragen, unabhängig von der CAN - Datagramgröße, da das CAN - Ethernet - Gateway Pakete anderer Länge verwirft.

Die Bytes in der CAN- Botschaft werden folgendermaßen in dem UDP-Paket eingepackt:

Bytes 1 bis 4 sind die Meldungskennung.
Byte 5 entspricht dem DLC der CAN-Meldung.
Bytes 6 - 13 sind die entsprechenden Nutzdaten. Dabei nicht benötigte Bytes sind mit 00 zu füllen.

Adressen im System

Der gesamte Adressraum hat 2^32 Adressen (0x0000 0000 - 0xFFFF FFFF), dies sind rund 4 Milliarden Adressen. Diese werden auch als UID (Universal Identifyer) bezeichnet. Je nach eingesetztem Protokoll hat jedoch eine UID eine andere Bedeutung.

Definition der Teilnehmerkennungen

Im System besitzt jeder adressierbare Teilnehmer eine eindeutige 32 Bit Adresse. Dabei werden folgende UID unterschieden:

Geräte UID

Eindeutig vergebene Universal ID

Local-ID

(=Local ID, nicht Locomotive ID) Aus dem Protokoll und der Adresse berechnete Lokale ID

mfx UID

mfx Universal UID

Bestimmte Geräte - UID besitzen eine besondere Bedeutung:

Die UID 0x00000000 ist die Broadcastadresse. Signalisiert, dass mehrere Teilnehmer denselben Befehl abarbeiten sollen.
Die UID 0xFFFFFFFF ist ungültig und steht für eine nicht initialisierte UID des Endgerätes.

Einbindung bestehender Gleisprotokolle, Local-ID

Der Adressraum hat rund 4 Milliarden verfügbare Adressen. Von diesem Adressraum wird ein Teil (Adresse 0 - 65536) für die Einbindung bestehender Protokolle verwendet: In diesem reservierten Bereich werden die bestehenden Digitalprotokolle eingebettet, repräsentiert durch die Local-ID. Durch Ihre Lage ergibt sich das Protokoll. Aufgeführt sind die unteren 2 Byte der Local-ID bei diesen Protokollen, die oberen sind = 0x0000.
So ergibt sich folgendes Adressschema:

Beispiele in (Hex):

Märklin Motorola mit Adresse 2 = Basis (00 00 00 00) + Adresse (02) ==> (00 00 00 02)

MM2 Zubehör mit Adresse 3 = Basis (00 00 30 00) + Adresse (3) ==> (00 00 30 03)

Bildung von Automatik-UID und Rückmelde-UID

Im Gesamtsystem können sich mehrere Geräte mit der Fähigkeit einer Automatisierung oder einer Rückmeldemöglichkeit befinden.

Für eine Möglichkeit, diese Ressourcen Systemweit nutzen zu können, muss diese Fähigkeit angesprochen werden können. Dabei wird die Möglichkeit der Rückmeldung und der Automatisierung in einem gemeinsamen Adressraum zusammengefasst.

Diese Kennungen bestehen aus zwei 16Bit Teilkennungen: Einer zugeordneten Gerätekennung und einer Kennung für die Automatik/Rückmeldekennung in diesem Gerät. Somit können 65K Geräte mit jeweils 65K Funktionen zusammengeschaltet werden. Die Kontaktadresse sowie die Automatisierungsadresse wird somit über eine Kombination von 16 Bit Gerätekenner und 16Bit Kontakt- / Automatikkennung gebildet. Über diese Adressierung werden im System alle Kontakte und Automatikfunktionen angesprochen.

Durch diese Kennungen ist es möglich, Ressourcen von einem Gerät zur Steuerung in einem anderen Gerät zu verwenden.

Gerätekennungen

Ressourcen in Systeme, die einen S88 Bus / Rückmeldebus besitzen oder eine Automatisierungsfunktionen realisieren, bekommen eine 16Bit Gerätekenner zugewiesen.

Die Master - Zentrale weist den Endgeräten die Kennung beim Systemstart jeweils zu. Eine Resetfeste Speicherung findet in den Geräten nicht statt.

Über diese zentrale Verwaltung der Gerätekennungen wird erreicht, dass eine ausgefallenes Gerät im System ersetzt werden kann. Die gespeicherte und verwendete Adressierung in Automatikfunktionen kann somit unverändert übernommen werden.

Der Master – Zentrale speichert eine Liste mit allen bekannten Geräten im System, sowie deren NickNames als .cs2 Konfigurationsdatei. Der Name/Kenner kann sinnvoll vorbelegt werden, ist aber vom Anwender änderbar.

Rückmeldekennungen und Automatikkennungen

Über diese Kennung wird sowohl eine Rückmeldung wie auch eine Automatisierungsfunktion angesprochen. Beide Funktionalitäten werden in einem gemeinsamen Adressraum zusammengefasst.

S88:

Rückmeldekennungen beginnen im Highbyte bei 0 bis maximal 63, Lowbyte im Bereich jeweils von 0 - 255. Somit sind maximal 16.384 Rückmeldekontakte pro Gerät möglich.

SX1:

Der Wert 64 ist reserviert für SX1 Rückmelder.

Automatikfunktionen:

Automatikfunktionen beginnen im Highbyte bei 65 der ASCII Darstellung von „A". Im Lowbyte beginnen per Konvention zur Zeit die Werte bei ASCII "1", dezimal 49 (0x31). (Dies ist die ASCII Darstellung „A1“ – somit die erste memory Funktion). Die Lücke zwischen SX1 Rückmelder und Automatikfunktionen ist reserviert.

Dabei werden die jetzt schon vorhandenen Automatikfunktionen mit der schon vergebenen Bezeichnung A1 – z8 adressiert. Neue Kennungen können zur Realisation neuer Automatisierungsfunktionen benutzt werden.

Tabelle der sich daraus ergebenden Adressierung.

Automatisierungsadressen / Rückmeldeadressen

Diese Adressen werden zusammengesetzt aus der Gerätekennung und der entsprechenden Rückmeldekennung bzw Automatikkennung. Die Gerätekennung bildet dabei den höherwertigen Teil.

Geschwindigkeiten:

Geschwindigkeiten im gesamten System werden als 10-Bit Werte behandelt. Dieser Wert ist unabhängig vom real zur Lok (über das Gleis) gesendeten Wert. Der verwendete Wertebereich sollte von 0 bis 1000 gehen, 0 entspricht einer stehenden Lok,1 einer gerade losfahrenden Lok, 1000 der maximalen Geschwindigkeit einer Lok. Werte oberhalb 1000 (bis 1023) dürfen/können vorkommen und sollten keinen Empfänger stören. Die Fahrgeschwindigkeit entspricht hierbei dem Maximum.

Die Umrechnung in reale Decoder-Fahrstufen ist anhand folgender Rechenvorschriften möglich:

Systemfahrstufe = 1 + (Gleisfahrstufe - 1) * Schrittweite

Die Decoderfahrstufe 1 ist immer auch Systemfahrstufe 1. Decoderfahrstufe 11 ist somit bei:

14 Fahrstufen ==> Systemfahrstufe 771
27 Fahrstufen ==> Systemfahrstufe 381
28 Fahrstufen ==> Systemfahrstufe 371
31 Fahrstufen ==> Systemfahrstufe 331
126 Fahrstufen ==> Systemfahrstufe 81

Zum Senden einer gezielten Fahrstufe sind nur die errechneten Werte zulässig. Der Gfp realisiert eine Umrechnung, so dass diese errechneten Werte exakt in der Mitte eines Bereiches sind.

Einige Befehle des Gleis Format Prozessor sind als Sonderbefehle / Programmierbefehle realisiert, welche sequenziell abgearbeitet werden. Nur jeweils ein Programmierbefehl kann in Abarbeitung sein. Um sicherzustellen, dass diese Programmierbefehle auch abgearbeitet wurden, muss auf die Bestätigung des Gleis Format Prozessor gewartet werden.

Ein Programmierbefehl wird im Gleis Format Prozessor zwischengespeichert und zur Abarbeitung übergeben. Bei Stopp kann diese Abarbeitung nicht stattfinden, da keine Gleistelegramme gesendet werden können. Die Abarbeitung des Programmierbefehls steht in diesem Zustand aus. Weitere Programmierbefehle werden dann verworfen. Einige Programmierbefehle sind nicht auf die Abarbeitung von Gleistelegrammen angewiesen. Bei diesen kann auch eine Abarbeitung bei Stopp stattfinden. Im Einzelnen handelt es sich um folgende Befehle: