Hintergründe

Der Eigenbau von Decodern und Funktionsmodulen für Märklin Digital® ist seit der Einführung der CS2® und der Veröffentlichung des CAN-Protokolls für einen versierten Hard- und Softwareentwickler kein Buch mit sieben Siegeln mehr.

Es gibt bereits eine Unmenge von Anbietern von Zubehör für dieses System - nicht nur Märklin®. Dennoch hat mir die Herausforderung gefallen, nach jahrelanger Abstinenz von Modellbahn und Elektronikentwicklung den Schritt zur Eigenentwicklung einer nach meinem Gusto funktionell gestalteten Produktlinie zu wagen. So ist MBCAN entstanden.

Meine Produktlinie zeichnet sich durch folgende Randbedingungen aus:

- Aufbau eines nicht-kommerziellen Projekts für den Hobby-Bereich
- Nutzen des von Märklin® veröffentlichten CAN-Protokolls
- Liefern von Denkanstößen und Ideen für andere interessierte Modellbahnern
- Erfüllen meiner eigenen Anforderungen an Modellbahn-Zubehör

MBCAN ist dabei nicht zwingend kompatibel zu anderen CAN-Projekten aus der Modellbahnwelt. Das ist aber auch nicht meine Intention. Es soll Denkanstöße und Ideen für andere interessierte Modellbahnern liefern. Wenn mir das gelingt, habe ich mein Ziel erreicht.

Artikel auf dieser Seite
	Anforderungen an MBCAN
	Adaption von Digitalzentralen mit dem MBCAN-Projekt
	Die Systemarchitektur des MBCAN-Projekts
	Das Dilemma mit den Gleisformaten
	Die Pinbelegung des MBCAN-Steckers
	Vom Gleissignal zum CAN-Kommando Schaltbefehlinterpretation durch einen µC
	Module auf dem MBCAN-Bus anhand einer Seriennummer und einer GUiD identifizieren
	Module auf dem MBCAN-Bus über die CAN-Schnittstelle upgraden

Anforderungen an MBCAN

Eingestellt: 01.01.2007 --- letzte Änderung: 21.10.2021 --- (c) Dr.-Ing. Thomas Wiesner

Als ich 2007 begann, eine Produktlinie für die Steuerung einer Modelleisenbahn aufzusetzen, habe ich mir zunächst Gedanken gemacht, was meine Anforderungen an eine solche Steuerung sind. Diese Checkliste hat sich in den Jahren ein wenig gewandelt. Die nachfolgend aufgeführte Übersicht ist die heute für mich gültige:

1:1-Ersatz von vorhandenen k83®-, k84®- und s88®-Modulen
MM®-Adresse und s88®-Moduladresse per Software
Fernparametrierbarkeit der Decoder und Module nach dem Einbau in die Anlage
Decodertypen für Switchboard, Servo, mfx®-Ertüchtigung des Boosters 6017® und Ertüchtigung der Märklin® Digital® Geräte der 1. Generation
Rückmeldung direkt an die Zentrale über den CAN-Bus mit eigenem Link® S88®-Derivat
Einsatz für C®- und K®-Gleise
Anbindung der Module über CAN-Bus an die CS2®/ CS3®/ MS2®
Anbindung der Module an die Märklin® Digital® Geräte der 1. Generation
Nutzung von Cat.5e-Patch-Kabel zwischen den Modulen
Stromversorgung der Module über das CAN-Netzwerkkabel und / oder Steckernetzteil
Einhalten der CAN-Bus-Spezifika hinsichtlich Busstruktur und Terminierung

zurück zum Anfang

Adaption von Digitalzentralen mit dem MBCAN-Projekt

Eingestellt: 01.01.2007 --- letzte Änderung: 20.04.2022 --- (c) Dr.-Ing. Thomas Wiesner

Das MBCAN-Projekt arbeitet grundsätzlich mit jeder Digitalzentrale zusammen, die Magnetartikel im MM2®-Protokoll schaltet. Verschiedene Verbindungsarten, auch gemischt, sind möglich.

Nicht nur CS2/3® oder die MS2®-Gleisbox kommen als Zentralen in Frage. Am einfachsten kann eine MM2®-Zentrale über den TRACK-Sniffer-Eingang mit MBCAN kommunizieren. Dieser Weg ist allerdings unidirektional, d.h. nur Kommandos von der Zentrale zu MBCAN sind möglich. Dies gilt sowohl für Lok- als auch Magnetartikelbefehle. Beide Befehlsarten werden in das CAN-Protokoll übersetzt und können so auch vom PC über das mbc-80 empfangen und ausgewertet werden.

Komfortabler wird es, wenn es sich bei der Zentrale um eine 6021® handelt. Die Verbindung wird dabei über den I2C®-Bus hergestellt. Dieser Weg ist bi-direktional, d.h. alle Kommandos von der Zentrale zu MBCAN und umgekehrt sind möglich. Dies gilt sowohl für Lok- als auch Magnetartikelbefehle. Das mbc-89 ersetzt dabei bei Nichtvorhandsein einer CS2/3® oder MS2® ein Interface 6051®, ausgenommen der s88-Schnittstellenfunktion. Diese kann durch entsprechende mbc-88/90 ersetzt werden. Es ist jedoch darauf hinzuweisen, dass die Steuerungssoftware, die formals das Interface 6051® bedient hat, jetzt über WLAN und das mbc-80 im CAN-Protokoll-Format interagieren muss. Das RS232-Format des Interfaces 6051® wird nicht unterstützt.

Richtig komfortabel wird es, wenn es sich bei der Zentrale um eine 6021® handelt und sich eine CS2/3® am MBCAN-Bus befindet. Dann agiert das mbc-89 als Connect6021® und bietet ein Adressmapping von MM2®-Adressen 1...80 auf mfx®/DCC®-Loks an. Magnetartikelbefehle des 6040® oder 6043® können ebenfalls blockweise (je vier Adressen fortlaufend) wahlweise als MM2® oder DCC® gemappt werden. Eine Rücksynchronisierung bei Schaltanfoderungen seitens der CS2/3® erfolgt. Bei der MS2® gilt das gleiche, außer dass eine Mapping bei den Loks nicht funktionert, da die GUI hierzu fehlt. Ein Steuern von 80 Loks mit MM2®-Adresse ist aber auch hier möglich.

zurück zum Anfang

Die Systemarchitektur von MBCAN

Eingestellt: 29.01.2018 --- letzte Änderung: 20.04.2022 --- (c) Dr.-Ing. Thomas Wiesner

Das MBCAN-Projekt basiert auf einem CAN-Bus. Dieser Feldbus zeichnet sich durch eine Linienstruktur aus. D.h., dass alle Module parallel an den Signalleitungen angeschlossen sind.

Im nachfolgenden Bild sehen Sie die Übersicht zu den bei MBCAN verfügbaren Modulen und deren Anwendung.

Die eingesetzten CAN-Bus-Receiver erlauben eine maximale Modulzahl von 100 Stück am Bus. D.h., jeder mbc-80 kann an seinen MBCAN-Bussen jeweils in Summe 100 Module ansteuern.

In Richtung CS2/3® und MS2® gelten die Empfehlungen von Märklin®, da die Bussysteme Märklinbus® und MBCAN-Bus hardwaremäßig getrennt sind.

Sollte diese Zahl bei einem mbc-80 erreicht werden, kann ein zweiter an den Märklinbus® angeschlossen werden. Die Kommunikation über den Märklinbus® zwischen allen Komponenten ist gewährleistet.

Was auf der einen Seite wie ein Fluch wirkt kann auf der anderen Seite aber auch wertstiftend genutzt werden.

Jeder der mbc-80 meldet sich als LinkS88®-Derivat an der CS2/3® an und erhält so einen Kenner unter dem er als LinkS88® ansprechbar ist.

Die angeschlossenen mbc-88/90 reagieren nur auf Anfragen an den jeweiligen mbc-80 und antworten mit dessen Kennung an die GUI der CS2/3®. Derzeit werden somit maximal 255 x 16 (mbc-90) + 255 x 8 (mbc-88) = 6120 Rückmeldekontakte am MBCAN-Bus unterstützt. Bei maximal 50 Modulen je mbc-80 würden minimal 12 x mbc-80 benötigt.

Im Vergleich empfiehlt Märklin® maximal 10 s88®-Module je Bus an seinem LinkS88®, was inkl. Bus 0 31 Modulen a 16 Kontakte = 496 Kontakten entspricht. Es würden also minimal 13 LinkS88® unter Einhaltung der Spezifika notwendig sein. MBCAN steht Märklin® damit in Sachen Performance in nichts nach.

zurück zum Anfang

Das Dilemma mit den Gleisformaten

Eingestellt: 15.05.2022 --- letzte Änderung: 18.05.2022 --- (c) Dr.-Ing. Thomas Wiesner

Seit der Einführung der Digitaltechnik bei der Modellbahn hat sich einiges getan. Es gibt drei etablierte Gleisformate MM®, DCC® und mfx®, die mehr oder weniger ab- bzw. aufwärtskompatibel sind und vor allem von Märklin® immer noch durch die Zentralen CS2/3® und MS2® unterstützt werden. Zubehördecoder sprechen zumindest zwei dieser Protokolle. Dies gilt auch für Drittanbieterprodukte.

Will man an den über die Jahre beschafften Digital-Komponenten festhalten, gibt es diverse Konnektoren wie z.B. das Connect6021®, um diese auf den CAN-Bus zu implementieren und weiternutzen zu können. Das funktioniert auch soweit - mit ein paar Einschränkungen. Das Connect6021® übersetzt die Schaltkommandos in CAN-Nachrichten mit einer Loc-ID im MM2®-Adressbereich (Loc-ID 0x3000-0x313f) und sendet sie an die Zentrale. Die Zentrale wiederum zeigt die Schaltzustände in der GUI an, worüber wiederum Schaltkommandos ausgeführt werden können die auf den Keyboards 6040® am Connect6021® synchronisiert angezeigt werden. Aber leider nur für 16 Keyboards und damit im MM2®-Adressbereich von 1 bis 256. Das MM2®-Format kann aber grundsätzlich 320 Adressen verwalten, wie es die GUI der CS2/3® und MS2® zeigt. Der Differenzadressbereich zwischen 256 und 320 kann so nicht angesprochen werden.

Auszug CAN-Dokumentation Märklin® 07.02.2012, Seite 8

Des Weiteren hat Märklin® in seinem CAN-Protokoll 1024 mögliche MM2®-Zubehöradressen (Loc-ID 0x3000-0x33ff) vorgesehen. Diese sind aber weder durch die GUI der CS2/3® und MS2® oder das Connect6021® in Gänze ansprechbar. Grund für die Einschränkung auf 320 Adressen ist, dass der Gleisformatprozessor historisch bedingt die Schaltkommandos in Gleissignale übersetzt, und da ist halt bei 320 Adressen Schluss. Aber warum den Differenzadressbereich bis 1024 nicht nutzen? MBCAN tut genau dass, d.h. die Schaltdecoder mbc-83, mbc-84 und mbc-87 können auf den gesamten MM2®-Adressraum von 1 bis 1024 parametriert werden. Halt mit dem Hemmnis, dass nur bis zur Adresse 320 die GUI der CS2/3® und MS2® verwendbar ist. PC-Programme sollten damit zurecht kommen, da sie in der Regel das CAN-Frameformat nutzen und somit alle Loc-IDs verarbeiten können sollten.

Was aber tun, wenn man über die Keyboards 6040® auch den Differenzadressbereich von 256 bis 1024 ansprechen will? Ein zweites Connect6021® hilft nicht, da es die Schaltadressen nicht mappen kann. Für diesen Fall gibt es den mbc-89, bei welchem die Basisadresse der Keyboards entsprechend parametriert wird. Maximal vier mbc-89 und jeweils 16 Keyboards sind notwendig, und schon können nicht nur alle 320 MM2®-Adressen über die Keyboards 6040® adressiert und in der GUI nutzbar gemacht, sondern auch alle anderen Adressen mit den MBCAN-Komponenten synchronisiert werden - quasi als GUI-Ersatz für die CS2/3® und MS2®. Ob sich der Aufwand lohnt, 64 Keyboards 6040® zu beschaffen, überlasse ich jedem selbst. Möglich aber ist es auf jeden Fall.

Jetzt könnten Nutzer sagen: "Dann nimm doch gleich DCC®, da sind bereits Adressen > 256 nutz- und in der GUI der CS2/3® und MS2® anzeigbar". Richtig, aber dann müssen ggf. verbaute Decoder die nur MM2® sprechen, ausgetauscht werden. Und dies soll durch den mbc-89 vermieden werden - und die Keyboards 6040® sind auch in Zukunft kein Fall für das alte Eisen.

Aber auch den DCC®-Usern kann der mbc-89 helfen. Entgegen dem Connect6021® übersetzt der mbc-89 die Schaltkommandos auf Anforderung auch in den DCC®-Adressraum (Loc-ID 0x3800-0x3bff). Je nach Parametrierung des Moduls kann pro Stellpult (4 Adressen) vorgegeben werden, ob es sich um MM2®- oder DCC®-Schaltkommandos handeln soll. Somit können die Keyboards 6040® und das Memory 6043® auch DCC® sprechen.

zurück zum Anfang

Die Pinbelegung des MBCAN-Steckers

Eingestellt: 01.01.2007 --- letzte Änderung: 06.09.2022 --- (c) Dr.-Ing. Thomas Wiesner

Die Verbindung zwischen den Modulen von MBCAN erfolgt, wie mittlerweile bei fast allen Modellbahn-Produkten in der Peripherie, über vorkonfektionierte Netzwerkkabel.

Bei der Auswahl der Pinbelegung habe ich mich ein wenig um Internet umgeschaut. Dabei ist mir die Seite von ESU aufgefallen. ESU® verwendet zwischen ihren Modulen auch Netzwerkkabel. Deren Pinbelegung war auf dem ersten Blick genau das, was ich mir vorgestellt habe.

Bild 1: Pinbelegung des MBCAN-Steckers

Genauso wie bei ESU® haben auch meine Module eine RJ-45-Eingangs- und eine Ausgangsbuchse. Darüber steuere ich unter anderem die automatische Terminierung des CAN-Busses. Dieses wird nämlich leider bei anderen CAN-Produkten aus dem Hobby-Bereich gerne vergessen. Der CAN-Bus ist kein sternförmig aufgebauter Bus sondern wird im offenen Ring betrieben mit Abschlusswiderständen an beiden Enden des Busses. Macht man das nicht, so kann dies zu einer Herabsetzung der maximalen Datenrate auf dem Bus führen. Im ungünstigen Fall kommt es zur Kommunikationsunterbrechung. Dieses Problem habe ich durch die Schaltungstechnik auf dem folgenden Bild behoben.

Bild 2: Auto-Terminierung des CAN-Bus

Auf dem Bus führe ich außerdem eine Spannungsversorgung für die einzelnen Module. Somit erspare ich mir eine separate Versorgung jedes einzelnen Moduls. Eine weitere Einspeisung bei Unterschreitung der zulässigen Versorgungsspannung von 18 V (wird an den betroffenen Modulen durch Blinken der LED in Rot angezeigt und ist auch über die Parametriersoftware anzeigbar) kann über jedes Modul egal wo im MBCAN-Bus vorgenommen werden.

Bild 3: Spannungsversorgung über das MBCAN-Verbindungskabel

Seien Sie bitte vorsichtig bei der Verwendung von ESU®-Produkten an meinem MBCAN-Bus. Ich übernehme keine Garantie, dass ESU®-Produkte an meinem Bus funktionieren. Insbesondere dann, wenn Sie die Fremdeinspeisung des Gleissignals verwenden. Es könnte zu ungewollten Kurzschlüssen kommen. In diesem Fall beachten Sie bitte mein Impressum. Ich übernehme dafür keine Haftung.

Quellen:
• "http://www.esu.eu/produkte/digitale-steuerung/ecoslink-terminal/", ESU
• "https://www.sps-wagner.de/moba/index.html", Familie Wagner

zurück zum Anfang

Vom Gleissignal zum CAN-Kommando Schaltbefehlinterpretation durch einen µC

Eingestellt: 01.01.2007 --- letzte Änderung: 24.01.2018 --- (c) Dr.-Ing. Thomas Wiesner

Die Grundidee von Märklin® zu seinem Digitalsystem beruht auf den Motorola-ICs MC145026 (Sender) und MC 145027/9 (Empfänger), einem Fernsteuerungssystem zur Datenübertragung via 1-Wire, Opto oder Funk. Daten und Takt werden kombiniert übertragen; eine Trennung erfolgt im Empfängerbaustein.

Die Schaltbefehle bei Märklin® werden mit einer Taktfrequenz von ca. 38,4 kHz von der Zentrale versendet. Ein Datenbit im trinären Datenformat ist acht Takte lang, dies entspricht rund 208 µs.

Bild 1: MÄRKLIN® MM-Datenformat

In den Jahren seit der Veröffentlichung des Märklin®-Digital-Systems sind zahlreiche Protokoll-Erweiterungen hinzugekommen. Auch gibt es andere Protokolle, die eine weite Verbreitung erfahren haben, wie z.B. DCC (offener Standard aus dem Gleichstrombereich) oder das mfx®-Protokoll von Märklin®. Alle drei Protokolle werden im Mix von den neuen Digitalzentralen auf einem Gleis versendet. Sie vertragen sich, da Kollisionen, d.h. gleiche Bitmuster oder Taktfrequenzen, vermieden werden. Man kann sich trotzdem vorstellen, was für ein Datenwust auf dem Gleis anzutreffen ist und die Decoder allerhand zu tun haben um die für sie bestimmten Datenpakete fehlerfrei identifizieren zu können.

Selbstbaudecoder für das Märklin®-Digital-System gibt es viele. Diese verwenden entweder die Motorola-ICs und deren Nachfolger oder nutzen Microcontroller. Letztere bieten etwas mehr Flexibilität und haben schließlich dazu geführt, dass auch der vierte Zustand eines Datentrits genutzt wird ohne dass ältere Decoder Fehlfunktionen zeigen.

Ein Entwickler von Selbstbaudecodern auf Basis von Microcontrollern muss sich überlegen, wie er mit geringem Aufwand und ggf. geringer Performance seines Controllers eine funktionierende Einheit herstellen kann. Dazu schaut er sich das Protokoll an und versucht dies auf bekannte, von Hardware und Software bereits unterstützte Grundmuster zurückzuführen.

Genauso klappt das auch beim Märklin®-Motorola-Protokoll:

Wenn man die Trits des Datenpakets invertiert und betrachtet, erkennt der geübte Entwickler die vertraute Silhouette einer UART-Datenübertragung mit einem Startbit, sechs Datenbits und einem Stoppbit ins Auge (Bild 2).

Bild 2: UART-Datenübertragung mit einem Startbit, sechs Datenbits und einem Stoppbit

Die Datenrate ist doppelt so hoch wie beim Schaltbefehl im Motorola®-Format und beträgt 76800 Bd. Dies ist eine Baudrate die dem UART-Standard gängiger Microcontroller, PC o.ä. entspricht. Einer Auswertung über die UART-Schnittstelle eines Microcontrollers steht also nichts im Wege.

Schaltbefehle im Märklin®-Motorola®-Format (Bild 3) bestehen aus vier Gruppen von Trits (Datenpaket). Die ersten vier Trits beinhalten die Adresse des Schaltdecoders. Dabei werden durch eine Adresse grundsätzlich immer vier Schaltausgänge mit je zwei Richtungen (Rot/Grün) angesprochen. Danach folgt regelmäßig ein Trit mit dem Wert '0' als Zeichen für einen Schaltbefehl. Die drei anschließenden Trits adressieren einen der vier möglichen Schaltausgänge inkl. Richtung. Das letzte Trit gibt an, ob der Ausgang eingeschaltet (Strom ein) oder ausgeschaltet (Strom aus) werden soll.

Bild 3: Schaltbefehle im Märklin®-Motorola®-Format

Ein gültiger Schaltbefehl im Märklin®-Motorola®-Format besteht aus zwei Datenpaketen zu je 9 Trits - dies ergibt 18 Trits die es gilt aus dem Datenstrom herauszufiltern. Es sei angemerkt, dass neuere Zentralen auch bei Schaltbefehlen mehr als einmal dieses Doppelkommando auf das Gleis legen um sicherzugehen, dass in der Datenflut unterschiedlichster Protokolle eine gesicherte Datenübertragung gewährleistet werden kann. Bei der CS2® habe ich vier Doppelkommandos beobachten können.

Im Bild 4 ist das Flussdiagramm zur Auswertung der ersten 9 Trits / 18 Bits eines Datenpakets im Märklin®-Motorola®-Format dargestellt. Als Datenquelle wird die UART-Schnittstelle mit 6N1 (ein Startbit, sechs Datenbits, kein Paritybit, ein Stoppbit) initialisiert. Der Bitzähler und das Befehlsregister (18 Bit lang) werden zurückgesetzt.

Wird ein gültiges Zeichen von der UART empfangen wird getestet, ob der Bitzähler Null ist. Wenn ja, wird die Befehlslängenmessung gestartet. Danach wird geprüft, ob eine "0" oder "63" empfangen wurde. Erst dann ist ein gültiges Zeichen für einen Schaltbefehl empfangen worden. Da auch andere Protokolle auf dem Gleis sind kann es sein, dass auch andere Zeichen gültig sein könnten. Wird ein solches empfangen wird die Befehlserfassung gestoppt und die Prozedur wird neu gestartet.

Nach 18 gültigen Bits wird getestet, ob insgesamt max. 1,87 ms vergangen sind. Dies entspricht den genannten 208 µs x 9 Trits.

Bild 4: Flussdiagramm zur Auswertung der ersten 9 Trits / 18 Bits eines Datenpakets

Ist der Test positiv liegt der erste Teil eines Doppelkommandos für einen Schaltbefehl vor. Die Prozedur muss zweimal durchlaufen werden. Sind beide dekodierten Befehle identisch liegt ein gültiger Schaltbefehl vor und kann weiterverarbeitet werden.

Im MBCAN-Projekt nutze ich diese Prozedur, um im Falle einer Kopplung zwischen dem Modul mbc-89 und einer Digitalzentrale ohne Märklin®-CAN-Bus die CAN-Schaltbefehle im Märklin-Format gemäß CAN-Protokollbeschreibung generieren zu können. Dies macht das MBCAN-System flexibel bei der Wahl der Digitalzentrale ohne von zukünftigen Entwicklungen in diesem Bereich ausgeschlossen zu werden.

Auch einer Anwendung für Eigenentwicklungen direkt am "offenen Gleis", z.B. mit einem Atmel-Tiny-Prozessor steht nichts im Weg.

Quellen:
• "Einstieg in Märklin Digital", Märklin-Sachbuch 0308
• "Digitale Modellbahnsteuerung mit einem PC", http://home.snafu.de/mgrafe/Programme/Signalerzeugung - Froitzheim.pdf

zurück zum Anfang

Module auf dem MBCAN-Bus anhand einer Seriennummer und einer GUiD identifizieren

Eingestellt: 21.02.2018 --- letzte Änderung: 04.09.2022 --- (c) Dr.-Ing. Thomas Wiesner

Der CAN-Bus ist ein Multimastersystem. Um Nachrichten zielgerichtet zwischen Modulen auszutauschen, Parameter zu setzen oder aber die Firmware zu aktualisieren müssen die Module gezielt angesprochen werden können.

In den LAN-Netzwerken geschieht dies in der Regel über die MAC-ID. Sie ist eineindeutig, im Netzwerkadapter implementiert und macht diesen Netzwerkport damit von überall her in den angeschlossenen Netzwerken ansprechbar.

Um im CAN-Bus nach einem PowerUp die Module unter der vorher gewählten Adresse wiederzufinden, muss also eine der MAC-ID vergleichbare eineindeutige Kennung in den Modulen implementiert werden. Wenn davon ausgegangen wird, dass neue Module nicht eines nach den anderen angeschlossen und parametriert werden, sondern auch mehrere, neue Module gleichzeitig am CAN-Bus nach einem PowerUp angeschlossen sind, muss die Kennung bereits bei der Produktion der Module quasi eingepflanzt werden.

Eine Möglichkeit, dies umzusetzen, ist die Integration der Kennung in die Firmware der Module. Dies bedeutet allerdings, dass die Firmware in der Regel je Modul neu kompiliert werden muss was aufwändig ist.

Besser ist eine Hardwarelösung. Auch hier gibt es mehrere Möglichkeiten der Umsetzung:

1. DIP-Schalter o.ä. über die eine Adresse vorgegeben wird. Diese Option schränkt die Anzahl der Module aber ein auf die maximal möglichen Schalterstellungen.

2. Nutzung von Peripheriebausteinen mit bei der Produktion eingeprägter Seriennummer. Diese ist in der Regel bei 1-Wire-Bausteinen der Firma Dallas® zu finden.

Ich habe mich für Lösung 2 mit einem Dallas®-Baustein entschieden.

Bild 1: Seriennummer eines Moduls vom Typ mbc-84

Der Baustein DS1820®, ein Temperatursensor, liefert eine 8 Byte lange Seriennummer. Diese Seriennummer nutze ich als Identifier und MAC-ID-Ersatz für meine Module. Außerdem erhalte ich nebenbei noch die Modulgehäuse-Innentemperatur und habe damit quasi dieselben Kennwerte neben der Spannung wie sie auch andere Komponenten von Märklin® (u.a. Gleissignalprozessoren oder die CS2® selbst) liefern. Nach der Erstanmeldung des Moduls sind Name und Seriennummer zunächst identisch, der Name kann über das Parametriercenter angepasst werden.

Die Anmeldung des Moduls und damit die Freischaltung der Funktionalität gegenüber einer Modellbahn-Zentrale erfolgt über einen PC und das Parametriercenter sowie den Terminaladapter mbc-80. Jedes Modul sendet nach dem initialien PowerUp und nach Aufforderung durch den PC das erste Byte seiner Seriennummer über den CAN-Bus. Der PC sendet als Antwort das zuerst empfangene Byte zurück (vgl. Befehlssatz in der Rubrik "Verwalten"). Stimmt die Antwort mit dem gesendeten Byte überein, sendet das betreffende Modul das zweite Byte. Alle anderen Module gehen in den Wartemodus. Dieser Automatismus wird bis zum 8 Byte wiederholt. Da die Seriennummer des DS1820® eineindeutig ist, gehen alle sich anmeldende Module bis auf eines in den Wartemodus.

Nach der Identifikation des Moduls über die Seriennummer fragt der PC noch die Stammdaten des Moduls, also den Modultyp, die Softwareversion der Firmware und die Hardwareversion ab. Anhand des Modultyps setzt das Parametriercenter dann die GUiD zusammen und übergibt diese an das Modul. Damit ist die Anmeldung abgeschlossen und der PC fordert das nächste Modul auf sich anzumelden. Die Einstellungen des Parametriercenters werden in einer PC-Datenbank gespeichert, deren Name zyklisch auf dem CAN-Bus ausgegeben wird solange das Parametriercenter geöffnet ist.

Die GUiD des Moduls bleibt permanent im Modul gespeichert. Sollte das Modul an einer anderen Zentrale angeschlossen werden ändert sich am gespeicherten Verhalten des Moduls zunächst nichts. Erst wenn über das Parametriercenter ein anderer Datenbankname übertragen wird, beginnt der Anmeldeprozess von Neuem. Die Parameter des Moduls, außer der GUiD, ändern sich dadurch jedoch nicht.

Die GUiD der Module entspricht dem Format der GUiD, welche Märklin für Peripherie wie Gleisformatsprozessor, Decoder o.ä. verwendet (Geräte-UID = eindeutig vergebene Universal ID). Diese besteht aus einem Kennbuchstaben und einer fortlaufenden Nummer. Insgesamt entspricht dies einer 32-Bit-Adresse. Das Parametriercenter baut die GUiD anhand der Stammdaten und der bereits registrierten Module desselben Modultyps zusammen:

Byte 1 = "m" (0x6D)
Byte 2 und 3 = Modultyp, z.B. "84" für das Modul mbc-84 (0x38 und 0x34)
Byte 4 = lfd. Nummer des Modultyps (0x00 bis 0xff)

Zusammen ergibt sich z.B. 0x6D383400 als GUiD für das 1. Modul vom Modultyp mbc-84.

Bild 2: GUiD eines Moduls vom Typ mbc-84

Die Anzahl der Module je Modultyp ist auf 256 begrenzt. Die bis dahin ausschöpfbaren Möglichkeiten (z.B. 256 x 4 Servos beim Modultyp mbc-84) entsprechen dem maximalen Adressraum beim MM2®-Format; für private Anlagen in der Regel mehr als ausreichend.

Bild 3: Das angemeldete Modul vom Typ mbc-84

Die GUiD des Moduls wird durch die CS2/3® akzeptiert - nach der Anmeldung am Parametriercenter meldet sich das Modul nachfolgend bei einer ggf. vorhandenen CS2/3® an. Dort sind die Infos zum Modul nach erfolgreicher Anmeldung abrufbar. Genauso verhält es sich beim Automatikkenner des mbc-80.

Am Beispiel der CS2® und des mbc-80 werden nachfolgend die verfügbaren Informationen der Module gezeigt:

In der Registerkarte "Konfiguration->Info" der GUI der CS2® werden neben dem Modultyp MBCAN mbc-80 und der lfd. Nummer #1 auch die Artikelnummer MBC8001, die Firmwareversion 1.0, die Seriennummer 0xF5000802BFBCD910 und die GUiD #m-80-0x01 (entspricht Parametriercenterformatierung 0x6D383001) angezeigt.

Bild 4: Das angemeldete Modul vom Typ mbc-80 in der GUI der CS2®

Die Registerkarte "Info" zeigt die Modulversorgungsspannung und die Modulgehäuse-Innentemperatur an.

Bild 5: Die Infos des angemeldeten Moduls vom Typ mbc-80 in der GUI der CS2®

Ein Modul vom Typ mbc-80 erzeugt außerdem in der Registerkarte
"Konfiguration->Geräte" einen Eintrag sowie den zugeordneten Automatikkenner.

Bild 6: Ein Automatik-Gerät des Typs mbc-80 als simulierter LinkS88® mit der Kennung 256

Dies sind die bislang implementierten Funktionen des Parametriercenters und der CS2/3® bezüglich der Modulidentifikation. Denkbar ist eine Erweiterung der Parametrierung einzelner Modul-Parameter. Dies wird ggf. später erfolgen. Weitere Infos zur PC-Software siehe hier.

Quellen:
• "Datenblatt DS1820", Dallas Semiconductor
• "Kommunikationsprotokoll CAN transportierbar über Ethernet", Märklin, 2012

zurück zum Anfang

Module auf dem MBCAN-Bus über die CAN-Schnittstelle upgraden

Eingestellt: 03.04.2018 --- letzte Änderung: 07.12.2019 --- (c) Dr.-Ing. Thomas Wiesner

Wie bereits im Artikel zur Seriennummer beschrieben, ist der CAN-Bus ein Multimastersystem. Um Nachrichten zielgerichtet zwischen Modulen auszutauschen, Parameter zu setzen oder aber die Firmware zu aktualisieren müssen die Module gezielt angesprochen werden können.

Ist das entsprechende Modul am CAN-Bus identifizierbar spricht nichts dagegen, die Firmware auf den Modulen anstelle über die ISP-Schnittstelle über den CAN-Bus zu aktualisieren.

Hierzu bieten die Atmel®-Controller einen Bootloader-Bereich, der nach Hardware-Reset oder gezielt durch einen Andressaufruf ausgeführt wird.

Problem ist, dass dieser Bootloader-Bereich in seiner Größe beschränkt ist. Leider passt die CAN-Ansteuerung und die Seriennummerbestimmung inkl. des benötigten Parser für eine neue Firmware von der Größe her nicht in den verfügbaren Bootloader. Wie sowas im Grundsatz geht findet sich auf http://www.mikrocontroller.net. Nun scheint guter Rat teuer.

Es geht also darum, sowohl das Modul am CAN-Bus eindeutig ansprechen und gleichzeitig die Firmware in das Modul zu schreiben zu können OHNE auf Speichergrenzen zu treffen. Die Lösung liegt in einem externen EEPROM als Zwischenspeicher für eine neue Firmware. Das interne EEPROM ist nämlich auch dafür zu klein und bereits durch Modulparameter (z.B. den Servowegen) weitestgehend ausgenutzt.

Bild 1: Externes EEPROM als Firmware-Zwischenspeicher

Wenn das Modul am MBCAN-Bus betrieben wird, kann über die entsprechenden Befehle des MBCAN-Befehlssatzes die neue Firmware Seite für Seite in das externe EEPROM geschrieben werden. Ist dies erfolgreich geschehen, wird das Modul neu gestartet und der Bootloader aufgerufen. Dieser prüft ob eine neue Firmware vorliegt indem er im externen EEPROM nach einem entsprechenden Tag sucht. Ist dieser vorhanden, wird die neue Firmware geprüft; ist sie ohne Fehler, wird das Modul neu programmiert und danach gestartet. Die neue Firmware wird nun ausgeführt.

Um genau dieses dem Controller beim Start auch mitzuteilen, braucht es besondere Einstellungen in den sogenannten Fuses. Diese sorgen für die richtigen Startvektoren beim Anlegen der Spannungsversorgung. Die entsprechenden Einstellungen sind Bild 2 zu entnehmen.

Bild 2: FUSES-Einstellungen für den Upgrade-Modus

Die Programmierung der Module kann nicht nur durch die Atmel®-Tools erfolgen. Ein User, welcher die Module nachgebaut hat, verwendete die Tools von Arduino® zur Programmierung. Bei Interesse leite ich gerne seine Beschreibung weiter.

Quellen:
• "http://www.mikrocontroller.net", Internet, 2018

zurück zum Anfang