CAN Anschluss


Allgemeines

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.

CAN Grundformat

Das CAN Protokoll schreibt vor, dass Meldungen aus 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), Antwortbit (Response) und Hash. Die Kommunikation basiert dabei auf folgendem Datenformat:

Meldungskennung DLC Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7
Prio Command Resp. Hash DLC D-Byte 0 D-Byte 1 D-Byte 2 D-Byte 3 D-Byte 4 D-Byte 5 D-Byte 6 D-Byte 7
2+2 Bit 8 Bit 1 Bit 16 Bit 4 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit 8 Bit
XX + XX XXXXXXX X XXXXXXXXXXXXXXX XXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
Message Prio Kommando Kennzeichnung CMD/ Resp. Kollisions-auflösung Anzahl Daten-bytes Daten ....





Grundbeschreibung der Felder

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 nur 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.

Kennwertbereiche für die Kommandowerte:

Bereich Anzahl Start Ende
Systembefehle 1 0x00 0x00
Verwaltung 8 0x01 0x0A
Zubehör 2 0x0B 0x0D
Rückmeldungen 3 0x10 0x12
Software Update / Konfig 6 0x18 0x1C
GUI Informationsübertragung 3 0x80

Response

Bestimmt, ob die CAN Meldung eine Anforderung oder eine Antwort auf eine vorhergehende Anforderung ist. Grundsätzlich wird eine Anforderung ohne ein gesetztes Response Bit gesendet. Sobald ein Kommando ausgeführt wurde, wird es mit gesetztem Response Bitzurückgesendet. Dabei wird der ursprünglichen Meldungsinhalt in der Antwort um eventuell angefragte Werte ergänzt. Jeder Teilnehmer am Bus der die Meldung ausgeführt hat bestätigt das Kommando.

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.

Dastellung Hash Systematik

Kollisionsauflösung:

Der Hash dient dazu, die CAN Meldungen mit hoher Wahrscheinlichkeit kollisionsfrei zu gestalten. Dieser 16 Bit Wert wird gebildet aus der UID Hash. Berechnung: 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 zu pr�fen. Wird der eigene Hash empfangen, so ist ein neuer zu w�hlen. Dieser darf mit keinem weiteren 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

Eine Initiator eine Meldung muss Sorge daf�r tragen, dass die gew�nschte Aktion tats�chlich ausgef�hrt wird. Die Meldungen werden nicht gesichert �ber den CAN-Bus �bertragen. Der Empfang einer Meldung wird nicht best�tigt. Die Ausf�hrung eines Kommandos wird best�tigt, bzw nur durch das Senden der Best�tigungsmeldung quittiert. Fehlt diese Quittierung, ist davon auszugehen, dass die Aktion nicht ausgef�hrt wurde.

Sonstiges

In 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 diese nicht empfangen werden.

Byte-Order in den Meldungen ist immer Motorola Big Endian.


�bertragung der CAN Kommandos via Ethernet

Auf der CS2 kann - �ber das Setup / IP - Einstellungen - das Can-UDP-Gateway gestartet werden. Dort kann eine IP-Adresse (auch Broadcast) spezifiziert werden, an die das Gateway sendet. Die Portadressen sind �ber die Oberfl�che nicht einstellbar und werden fest auf die Ports 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, sendet an die Broadcast-Adresse 192.168.2.255:15730.
PC1: (192.168.2.10) empf�ngt auf Port 15730 sendet an CS2 (192.168.2.20:15731)
PC2: (192.168.2.11) empf�ngt auf Port 15730 sendet an 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.

Allgemeines

Adressen im System

Der gesamte Adressraum hat 2**32 Adressen (0x0000 0000 - 0xFFFF FFFF), dieses 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.
Loc 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, Loc-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 Loc-ID. Durch Ihre Lage ergibt sich das Protokoll. Aufgef�hrt sind die unteren 2 Byte der Loc-ID bei diesen Protokollen, die oberen sind = 0x0000.
So ergibt sich folgendes Adressschema:

Start
Adresse
End
Adresse
Protokoll
0x0000 0x03FF MM1,2 Loks und Funktionsdecoder
(20 & 40 kHz, 80 & 255 Adressen)
0x0400 0x07FF Reserviert
0x0800 0x0BFF SX1 (Erweiterung)
0x0C00 0x0FFF Reserviert
0x1000 0x13FF Res. f�r MM1,2 Funktionsdecoder F1 - F4 (40 kHz, 80 & 255 Adressen)
0x1400 0x17FF Reserviert
0x1800 0x1BFF Frei f�r Privatanwender / Clubs
0x1C00 0x1FFF Reserviert
0x2000 0x23FF Reserviert f�r MM1,2 Lokdecoder (20 kHz, 80 & 256 Adressen)
0x2400 0x27FF Reserviert
0x2800 0x2BFF SX1-Zubeh�rartikel (Erweiterung)
0x2C00 0x2FFF Reserviert f�r Traktionen (interne GUI Kennungen)
0x3000 0x33FF MM1,2 Zubeh�rartikeldecoder
(40 kHz, 320 & 1024 Adressen)
0x3400 0x37FF Reserviert
0x3800 0x3BFF DCC-Zubeh�rartikel
0x3C00 0x3FFF DCC-Zubeh�rartikel



0x4000 0x7FFF MFX
0x8000 0xBFFF SX2
0xC000 0xFFFF DCC


Beispiel (Hex):

M�rklin Motorola mit Adresse 2: Basis: 00 00 00 00 Plus Adresse: 00 00 00 02
MM2 Zubeh�r mit Adresse 3 Basis: 00 00 30 00 Plus Adresse: 00 00 30 03

Zugeordnete Ger�tekennungen f�r R�ckmelder und Automatikfunktionen

Systeme mit einem S88 Bus oder welche Automatisierungsfunktionen unterst�tzen, werden �ber einen 16Bit Ger�tekenner adressiert.
Die Kontaktkennung und die Automatisierungsfunktion wird somit �ber eine Kombination von 16 Bit Ger�tekenner und 16Bit Kontakt/Automatikkennung gebildet. �ber diese Adressierung werden alle Kontakte und Automatikfunktionen angesprochen.
Die Master - Zentrale weist den Endger�ten die Kennung beim Systemstart jeweis zu. Eine Resetfeste Speicherung findet in den Ger�ten nicht statt.
�ber diese 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 sich eine Liste mit allen bekannten Ger�ten im System, sowie deren NickNames als .cs2 Konfigurationsdatei. Der Name kann sinnvoll vorbelegt werden, muss aber vom Anwender ge�ndert werden k�nnen.

Nummernkreis / Adressen der R�ckmeldekennungen und Automatikfunktionen

R�ckmeldekennungen beginnen im Highbyte bei 0 bis maximal 63 Lowbyte im Bereich jeweils von 0 - 255.
Somit maximal 16.384 R�ckmeldekontakte pro Ger�t m�glich.
Der Wert 64 ist reserviert f�r SX1 R�ckmelder.
Automatikfunktionen beginnen im Highbyte bei "A" = 65. Im Lowbyte beginnen per Konvention zur Zeit die Werte bei "1", dezimal 49 (0x31).
Abildung der Automatikfunktionen wie derzeitiges Memory: A1 = Erste memory Funktion.
Adresssystematik erm�glicht Ger�te mit R�ckmeldung und Automatikfunktionen (Wie die CS2).

Automatisierungsadressen / R�ckmeldeadressen

Diese Adressen werden zusammengesetzt aus der Ger�tekennung (H�her wertig) und der entsprechenden R�ckmeldekennung bzw Automatikkennung.

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, 1000 der maximalen Geschwindigkeit einer Lok.
Werte oberhalb 1000 (bis 1023)  d�rfen vorkommen und sollten keinen Empf�nger st�ren. Die Fahrgeschwindigkeit entspricht hierbei dem Maximum.
Die Umrechnung in reale m�glich Fahrstufen ist anhand folgender Rechenvorschriften m�glich:

Systemfahrstufe = 1 + (Gleisfahrstufe - 1) * Schrittweite

Fahrstufen

Anzahl Schrittweite
14 77
27 38
28 37
31 33
126 8


Gleisfahrstufe 1 ist somit immer auch Systemfahrstufe 1.
Gleisfahrstufe 11 ist bei:

14 Fahrstufen: 771
27 Fahrstufen: 381
28 Fahrstufen: 371
31 Fahrstufen: 331
126 Fahrstufen: 81

Sequenzielle Programmierbefehle

Einige Befehle des Gleis Format Prozessor sind als Sonderbefehle / Programmierbefehle realisiert, welche sequenziell abgearbeitet werden. Nur 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 Programmierbefehl steht in diesem Zustand aus. Weitere Programmierbefehle werden 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:

Befehl Abarbeitung bei Stopp
Lok Discovery Nein
MFX Bind Nein
MFX Verify Nein
Read Config Nein
Write Config Nein
Read Config Data Ja
Statusdaten Konfiguration Ja