MBCAN-LOGO

Hintergründe

In der Zeit der µC, PCs, Tablets und Smartphones ist alles digital. Dies gilt auch für die Schaltungstechnik. Analoge Bauteile werden nur noch eingesetzt, wenn es um die Bereitstellung elektrischer Leistung über Verstärker oder um das Einhalten des Abtasttheorems bei der Digitalisierung über Filter geht. Ansonsten werkeln fast nur noch digitale Bauteile.

Der Vorteil digitaler Bauteile, insbesondere der Einsatz von Microcontrollern mit Speicher, liegt dabei auf der Hand. Ein einmal erstelltes Layout mit Ein- und Ausgängen kann über Software beliebige Funktionen ausführen. Diese Funktionen lassen auch Parametrierungen zu, z.B. die Adresse eines Decoders, Reaktionszeiten, Wegediagramme von Servos usw.

Auch meine Module benötigen eine Software. Nicht nur als Arbeitsprogramm im µC sondern auch auf dem PC für die Decoderparameter. Nachfolgend finden Sie ein paar Infos zu den von mir erstellten Softwaretools von MBCAN.

Artikel auf dieser Seite
Artikel Das Datenmodell von MBCAN
Artikel Der Befehlssatz von MBCAN
Artikel Der Post-Code von MBCAN
Artikel Das Parametriercenter von MBCAN
Artikel MBCAN mit Rocrail® verbinden

Das Datenmodell von MBCAN

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

Um die mbc-Module verwalten zu können bedarf es eines Datenmodells. Nur so ist gewährleitet, dass Daten zwischen der Parametriersoftware auf dem PC und dem Programm auf den mbc-Modulen ausgestauscht und verifiziert werden können.

Ich habe mich für ein 8 Bit breites System-Array mit einer variablen Gesamtlänge entschieden. Jede 8-Bit-Speicherzelle des Arrays steht für eine spezielle Date und kann über den CAN-Bus angesprochen, gelesen und geschrieben werden.

Das System-Array ist in zwei Teile unterteilt, dem allgemeinen Teil mit zwei Sektionen und dem modulspezifischen Teil:

Allgemeiner Teil

Infos des Moduls - ist für die Identifikation des Moduls notwendig und entspricht dem ROM- oder Firmware-Bereich eines Computersystems. Änderungen sind nur durch eine neue Firmware möglich. Er ist bei allen Modulen von der Definition her gleich.

Zustand des Moduls - ist für die Bewegungsdaten des Moduls vorgesehen wie Name, Versorgungsspannung, Temperatur aber auch die GUiD in der Märklin-Nomenklatur. Dieser Bereich ist zum Teil wie ein EEPROM, zum Teil wie ein RAM angelegt, je nach Funktion der Speicherzelle. Er ist bei allen Modulen von der Definition her gleich.

Modulspezifischer Teil

Parameter des Moduls - ist für die modul- und funktionsspezifischen Parameter vorgesehen. Dieser Bereich ist wie ein EEPROM angelegt und bei allen Modulen von der Definition her unterschiedlich.

Nachfolgend die Definition des System-Arrays in C für den µC mit dem modulspezifischen Teil für den Servo-Decoder mbc-84:

//================================================================= //= System-Array = //================================================================= // MBC_ARRAY_START Start des belegten Systemarrays #define MBC_ARRAY_START 1 //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ //+ Allgemeiner Teil + //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // MBC_ALLG_START Start des Allgemeinblocks #define MBC_ALLG_START MBC_ARRAY_START //***************************************************************** //* Infos des Moduls * //***************************************************************** // MBC_INFO_START Start des Neuanmeldeblocks #define MBC_INFO_START MBC_ARRAY_START // MBC_L_SNR Laenge der Seriennummer // MBC_S_SNR Index Start Seriennummer // MBC_SNR Seriennummer #define MBC_L_SNR 8 #define MBC_S_SNR MBC_ARRAY_START #define MBC_SNR sys_array[MBC_S_SNR] // MBC_L_ART Laenge der Artikelnummer // MBC_S_ART Index Start Artikelnummer // MBC_ART_1 Artikelnummer Byte 4 // MBC_ART_2 Artikelnummer Byte 3 // MBC_ART_3 Artikelnummer Byte 2 // MBC_ART_4 Artikelnummer Byte 1 #define MBC_L_ART 4 #define MBC_S_ART (MBC_L_SNR + MBC_S_SNR) #define MBC_ART_1 sys_array[MBC_S_ART] #define MBC_ART_2 sys_array[MBC_S_ART + 1] #define MBC_ART_3 sys_array[MBC_S_ART + 2] #define MBC_ART_4 sys_array[MBC_S_ART + 3] // MBC_L_SW Laenge Softwareversion // MBC_S_SW Index Start Softwareversion // MBC_SW_1 Softwareversion Byte 3 // MBC_SW_2 Softwareversion Byte 2 // MBC_SW_3 Softwareversion Byte 1 #define MBC_L_SW 3 #define MBC_S_SW (MBC_L_ART + MBC_S_ART) #define MBC_SW_1 sys_array[MBC_S_SW] #define MBC_SW_2 sys_array[MBC_S_SW + 1] #define MBC_SW_3 sys_array[MBC_S_SW + 2] // MBC_L_HW Laenge Hardwareversion // MBC_S_HW Index Start Hardwareversion // MBC_HW_1 Hardwareversion Byte 6 // MBC_HW_2 Hardwareversion Byte 5 // MBC_HW_3 Hardwareversion Byte 4 // MBC_HW_4 Hardwareversion Byte 3 // MBC_HW_5 Hardwareversion Byte 2 // MBC_HW_6 Hardwareversion Byte 1 #define MBC_L_HW 6 #define MBC_S_HW (MBC_L_SW + MBC_S_SW) #define MBC_HW_1 sys_array[MBC_S_HW] #define MBC_HW_2 sys_array[MBC_S_HW + 1] #define MBC_HW_3 sys_array[MBC_S_HW + 2] #define MBC_HW_4 sys_array[MBC_S_HW + 3] #define MBC_HW_5 sys_array[MBC_S_HW + 4] #define MBC_HW_6 sys_array[MBC_S_HW + 5] // MBC_L_NAMEBLOCK Laenge des Modulnamens // MBC_S_NAMEBLOCK Index Start Modulname // MBC_NAME Name des Moduls #define MBC_L_NAMEBLOCK 20 #define MBC_S_NAMEBLOCK (MBC_L_HW + MBC_S_HW) #define MBC_NAME sys_array[MBC_S_NAMEBLOCK] // MBC_INFO_ENDE Ende des Neuanmeldeblocks #define MBC_INFO_ENDE (MBC_L_NAMEBLOCK + MBC_S_NAMEBLOCK) //***************************************************************** //* Zustand des Moduls * //***************************************************************** // MBC_STATE_START Start des Neuanmeldeblocks #define MBC_STATE_START MBC_ARRAY_STATE // MBC_L_GUID Laenge der GuiD // MBC_S_GUID Index Start GUiD // MBC_UiD_1 GUiD Byte 4 // MBC_UiD_2 GUiD Byte 3 // MBC_UiD_3 GUiD Byte 2 // MBC_UiD_4 GUiD Byte 1 #define MBC_L_GUID 4 #define MBC_S_GUID (MBC_L_NAMEBLOCK + MBC_S_NAMEBLOCK) #define MBC_UiD_1 sys_array[MBC_S_GUID] #define MBC_UiD_2 sys_array[MBC_S_GUID + 1] #define MBC_UiD_3 sys_array[MBC_S_GUID + 2] #define MBC_UiD_4 sys_array[MBC_S_GUID + 3] // MBC_L_DB Laenge der Datenbankversion // MBC_S_DB Index Start Datenbankversion // MBC_DB Datenbanknummer des PC #define MBC_L_DB 12 #define MBC_S_DB (MBC_L_GUID + MBC_S_GUID) #define MBC_DB sys_array[MBC_S_DB] // MBC_L_KN Laenge CS2-Geraetekennung // MBC_S_KN Index Start CS2-Geraetekennung // MBC_KN_H CS2-Geraetekennung HIGH // MBC_KN_L CS2-Geraetekennung LOW // MBC_AK_H CS2-Autokennung HIGH // MBC_AK_L CS2-Autokennung LOW // MBC_CS2_GER CS2-Geraetegruppe #define MBC_L_KN 5 #define MBC_S_KN (MBC_L_DB + MBC_S_DB) #define MBC_KN_H sys_array[MBC_S_KN] #define MBC_KN_L sys_array[MBC_S_KN + 1] #define MBC_AK_H sys_array[MBC_S_KN + 2] #define MBC_AK_L sys_array[MBC_S_KN + 3] #define MBC_CS2_GER sys_array[MBC_S_KN + 4] // MBC_L_PARA Laenge Parametersatz // MBC_S_PARA Index Start Parametersatz // MBC_PLUGGED Steckernetzteil gesteckt // MBC_SPG_1 Spannung 10er Digit // MBC_SPG_2 Spannung 1er Digit // MBC_SPG_3 Spannung 0.1er Digit // MBC_TMP_1 Temperatur 10er Digit // MBC_TMP_2 Temperatur 1er Digit // MBC_TMP_3 Temperatur 0.1er Digit #define MBC_L_PARA 7 #define MBC_S_PARA (MBC_L_KN + MBC_S_KN) #define MBC_PLUGGED sys_array[MBC_S_PARA] #define MBC_SPG_1 sys_array[MBC_S_PARA + 1] #define MBC_SPG_2 sys_array[MBC_S_PARA + 2] #define MBC_SPG_3 sys_array[MBC_S_PARA + 3] #define MBC_TMP_1 sys_array[MBC_S_PARA + 4] #define MBC_TMP_2 sys_array[MBC_S_PARA + 5] #define MBC_TMP_3 sys_array[MBC_S_PARA + 6] // MBC_ALLG_ENDE Ende des Allgemeinblocks #define MBC_ALLG_ENDE (MBC_L_PARA + MBC_S_PARA) // MBC_L_GENPURP Laenge des General Purpose Arrays // MBC_S_GENPURP Index Start des General-Purpose-Arrays // MBC_ARRAY_MAX Laenge des Systemarrays #define MBC_L_GENPURP 2048 #define MBC_S_GENPURP (MBC_L_PARA + MBC_S_PARA) #define MBC_ARRAY_MAX (MBC_L_GENPURP + MBC_S_GENPURP) // MBC_ARRAY_ENDE Ende des Systemarrays #define MBC_ARRAY_ENDE (MBC_ARRAY_MAX - 1) //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ //+ Modulspezifischer Teil fuer das Modul mbc-84 + //+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ // Laenge modulspezifische Parameter // Index Start modulspezifische Parameter // MMAddr HIGH // MMAddr LOW // Stellung der Aktoren #define MBC_84_L_MM 3 #define MBC_84_S_MM MBC_S_GENPURP #define MBC_84_MM_H sys_array[MBC_84_S_MM] #define MBC_84_MM_L sys_array[MBC_84_S_MM + 1] #define MBC_84_MM sys_array[MBC_84_S_MM + 2] // Laenge Maximalwerte Servos, Schrittweite und Center // Index Start Maximalwerte Servos, Schrittweite und Center // Servoanschlaege (Lx,Rx,Center,VZx) #define MBC_84_L_SVMAX 13 #define MBC_84_S_SVMAX (MBC_84_L_MM + MBC_84_S_MM) #define MBC_84_SVMAX sys_array[MBC_84_S_SVMAX] // Laenge Servowege 120 Steps pro Servo // Index Start Servowege // Servowege #define MBC_84_L_SVWEG 960 #define MBC_84_S_SVWEG (MBC_84_L_SVMAX + MBC_84_S_SVMAX) #define MBC_84_SVWEG sys_array[MBC_84_S_SVWEG]

Listing 1: Datenmodell der MBCAN-Module

Soweit meine Idee zu einem Datenmodell. Es funktioniert bislang sehr gut. Insbesondere die Unterscheidung in einen allgemeinen Definitionsteil, welcher für alle mbc-Module gleich ist, und einen modulspezifischen Teil hat sich bewährt und macht nachträgliche Erweiterungen und Anpassungen im Quellcode einfacher.

zurück zum Anfang

Der Befehlssatz von MBCAN

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

Um die Module des MBCAN-Projektes auf dem CAN-Bus ansprechen und parametrieren zu können, bedarf es neben der Geräte-UiD auch einen adäquaten Befehlssatz. Der Befehlssatz von Märklin® setzt sich aus Kommandos zusammen, die im CAN-Header integriert sind. Da dieser Header sehr sensibel auf Fehler reagiert, fällt er für eigene Befehlsübertragungen aus.

Märklin® hat aber eine Möglichkeit geschaffen, dass Privatpersonen, Vereine o.ä. freie Adressräume in der Loc-ID (Local ID, nicht Lokomotiv-ID ;-) ) nutzen können. Diese liegen im Adressraum 0x00001800 bis 0x00001BFF (Datenbytes 1 bis 4 der CAN-Nachricht) und sind u.a. über das Schaltkommando 0x0B (= 0x16 im CAN-Header) verfügbar.

Mein Befehlssatz baut auf diesem Adressraum und das Schaltkommando auf. Anders als bei Märklin® üblich, generiere ich aber nur uni-direktionale Befehle. D.h., das Response-Bit im CAN-Header bei den Märklin®-Kommandos nutze ich nicht. Bislang hat die CS2/3® noch nicht gemeckert. Sollte das irgendwann mal so sein, werde auch ich die Befehle bi-direktional aufbauen.

//===================================================================== //= CAN-Befehlsnummern PC-Kommunikation initialisieren = //= Dieser ist der zweite Teil in der Addr der CAN-Nachricht 0x18xx = //===================================================================== // PC_DB_H PC - Datenbanknummer HIGH // PC_DB_M PC - Datenbanknummer MID // PC_DB_L PC - Datenbanknummer LOW // PC_KENNER PC - Geraetekenner und Identifier // PC_NEU PC - Neuanmeldungsanforderung des PC // PC_NEU_DATA PC - Neuanmeldungskanal des PC // MD_NEU_DATA MD - Neuanmeldungskanal des Moduls // PC_RESET PC - Reset durch PC // PC_MD_DEL PC - Modul wurde aus Datenbank geloescht // PC_ALIVE PC - Alivemeldung durch PC angefordert // MD_ALIVE MD - Acknowledge des Moduls auf PC_ALIVE // PC_ARRAY PC - Anfordern, auf das Systemarray des Moduls // zuzugreifen // MD_ARRAY MD - Acknowledge des Moduls auf PC_ARRAY // PC_ARRAY_DATA PC - Schreiben/Lesen und ggf. Wert und Systemarray- // index uebergeben // MD_ARRAY_DATA MD - Ack des Moduls auf PC_ARRAY_DATA und Wert aus // dem Systemarray uebergeben // PC_UPGRADE PC - Anfordern, auf das Systemarray des Moduls // zuzugreifen // MD_UPGRADE MD - Acknowledge des Moduls auf PC_UPGRADE // PC_UPGRADE_DATA PC - Schreiben/Lesen und ggf. Wert und Systemarray- // index uebergeben // MD_UPGRADE_DATA MD - Ack des Moduls auf PC_UPGRADE_DATA und Wert // aus dem Systemarray uebergeben // PC_BOOT PC - Modul mit neuer Firmware starten // MD_S88 MD - S88-Stellungsmeldung #define PC_DB_H 0x00 #define PC_DB_M 0x01 #define PC_DB_L 0x02 #define PC_KENNER 0x03 #define PC_NEU 0x04 #define PC_NEU_DATA 0x05 #define MD_NEU_DATA 0x06 #define PC_RESET 0x07 #define PC_MD_DEL 0x08 #define PC_ALIVE 0x09 #define MD_ALIVE 0x0A #define PC_ARRAY 0x0B #define MD_ARRAY 0x0C #define PC_ARRAY_DATA 0x0D #define MD_ARRAY_DATA 0x0E #define PC_UPGRADE 0x0F #define MD_UPGRADE 0x10 #define PC_UPGRADE_DATA 0x11 #define MD_UPGRADE_DATA 0x12 #define PC_BOOT 0x13 #define MD_S88 0x14

Listing 1: Befehlssatz der MBCAN-Module

Die Nachrichten auf dem MBCAN-Bus entsprechen wie beschrieben der Märklin®-Konvention mit einer Datenlänge von 8 Byte:

Beispiel: 00 16 5F 38 08 00 00 18 09 6D 38 34 01

Übersetzung:

PRIO: 0x00 = Normale Priorität der Nachricht

KOMMANDO: 0x16 = Schaltkommando

HASH: 0x5F38 = HASH aus der GUiD gemäß Märklin®

DLC: 0x08 = Länge der Nachricht

Adresse: 0x00001809 = ALIVE-Anfrage

GUiD: 0x6D383401 = Anfrage an mbc-84 #1

Weitere Informationen zu den CAN-Nachrichten gemäß Märklin®-Konvention siehe Quellenangabe unten. Eine vollständige Beschreibung mit Beispielen befindet sich jeweils in den Bedienungsanleitungen zu den Modulen.

Nachfolgend sind die Befehle und ihre Funktionen aufgeführt:

Befehl Sender Loc-ID Funktion
PC_DB_H
PC_DB_M
PC_DB_L
PC 0x00001800
0x00001801
0x00001802
Übertragung des Datenbanknamens

Bytes 1 bis 6 stellen das Datum, Bytes 7 bis 12 die Uhrzeit dar. Beispiel: 070917235340 = am 07.09.2017 um 23:53:40 wurde die Datenbank erstellt. Dieser Name findet sich auch im Dateinamen der exportierten Datenbank aus dem Parametriercenter.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001800 – 0x00001802
D4 – D7: Datumsangaben Byteweise

Nachrichten:

PC_DB_H
00 16 5F 38 08 00 00 18 00 30 37 30 39

PC_DB_M
00 16 5F 38 08 00 00 18 01 31 37 32 33

PC_DB_L
00 16 5F 38 08 00 00 18 02 35 33 34 30

Antwort der Module:

-/-

PC_KENNER PC 0x00001803 Kenner und Identifier für die Module

Die Kennung der MBCAN-Module folgt strikt dem Format der Geräte-UiD von Märklin. In der GUiD stellt die erste Stelle die Kennung dar. Zur Zeit verwendet MBCAN die Kennung "m" (0x6D). Im Parametriercenter kann die Kennung angepasst werden, falls Märklin den Kenner "m" für seine eigene Module reklamiert. Darüber hinaus bekommt jedes Modul noch einen Identifier, mit dem es sich an der GUiD der CS2/3 als „Sonstige Geräte“ anmelden kann. Zur Zeit ist dies „AAAA“ (0xAAAA). Im Parametriercenter kann die Kennung angepasst werden, falls Märklin den Identifier "m" für seine eigene Module reklamiert. Ausgenommen sind die Module mbc-80 (Identifier 0x0040) und mbc-82 (Identifier 0x0000) die von Märklin fest vorgegeben sind. Diese Identifier sind in der Firmware der Module bereits fest integriert

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001803
D5 – D6: Identifier
D7: Kenner

Nachrichten:

00 16 5F 38 08 00 00 18 03 00 AA AA 6D

Antwort der Module:

-/-

PC_NEU PC 0x00001804 Neuanmeldeaufforderung

Zyklische Aufforderung an neu am MBCAN-Bus angeschlossene und noch nicht angemeldete Module, sich am Parametriercenter anzumelden. Dies gilt auch für Module, die über das Parametriercenter zurückgesetzt wurden.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001804

Nachrichten:

00 16 5F 38 08 00 00 18 04 00 00 00 00

Antwort der Module:

MD_NEU_DATA

PC_NEU_DATA PC 0x00001805 Rückmeldung des PC an das Modul während des Neuanmeldeprozesses

Der PC sendet das empfangene Seriennummer-Byte auf den MBCAN-Bus zurück als Quittierung. Das entsprechende Modul antwortet dann mit dem nächsten Byte, alle anderen Module schalten in den Listen-Modus und reagieren erst nach einer weiteren PC_NEU-Nachricht, falls sie noch nicht erfolgreich angemeldet waren.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001805
D7: n-tes Byte der Seriennummer

Nachrichten:

Seriennummernbyte 0x04 wird vom PC bestätigt

00 16 5F 38 08 00 00 18 05 00 00 00 04

Antwort der Module:

MD_NEU_DATA

MD_NEU_DATA Modul 0x00001806 Meldung des Moduls während des Neuanmeldeprozesses

Wenn das Modul noch nicht am Parametriercenter angemeldet war, reagiert es mit dieser Nachricht an den PC. Es sendet sein erstes Byte seiner Seriennummer an den PC. Reagiert der PC mit der Nachricht PC_NEU_DATA mit exakt dem gleichen Byte, sendet es weitere Bytes seiner Seriennummer, bis entweder alle Bytes übertragen wurden (erfolgreiche Anmeldung) oder der PC gerade ein anderes Modul initiiert. Stimmt das Byte nicht überein, geht es in den Listen-Modus und wartet auf eine weitere PC_NEU-Nachricht.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001806
D7: n-tes Byte der Seriennummer

Nachrichten:

Seriennummernbyte 0x04 wird vom Modul gesendet

00 16 2B 17 08 00 00 18 06 00 00 00 04

Antwort des PC:

PC_NEU_DATA

PC_RESET PC 0x00001807 Durchführen eines Hardware-Resets auf dem Modul

Über das Parametriercenter können Module gezielt einem RESET unterzogen werden. Die Identifizierung der Module geschieht über ihre GUiD.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001807
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 5F 38 08 00 00 18 07 6D 38 34 01

Antwort der Module:

-/-

PC_MD_DEL PC 0x00001808 Modul aus Datenbank entfernen

Das Modul wurde aus der Datenbank entfernt und kann sich an dieser Datenbank auch nicht mehr neu anmelden. Wird in der Regel nur bei Modulen verwendet, die sich in der Datenbank befinden aber nicht mehr am Bus angeschlossen werden sollen. Wird nur einmal gesendet, wenn das Modul im Parametriercenter gelöscht wird. Ist das Modul nicht am Bus und wird nach einem Neustart der Software wieder am Bus angeschlossen, meldet es sich nicht mehr neu an, es sei denn, die Datenbank wird neu erstellt.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001808
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 5F 38 08 00 00 18 08 6D 38 34 01

Antwort der Module:

-/-

PC_ALIVE PC 0x00001809 ALIVE-Abfrage

Zyklische Abfrage über die GUiD, ob das betreffende Modul sich noch am MBCAN-Bus befindet. Es antwortet mit der Nachricht MD_ALIVE.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001809
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 5F 38 08 00 00 18 09 6D 38 34 01

Antwort der Module:

MD_ALIVE

MD_ALIVE Modul 0x0000180A Antwort ALIVE-Anfrage

Antwort des Moduls auf eine ALIVE-Abfrage durch den PC.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x0000180A
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 2B 17 08 00 00 18 0A 6D 38 34 01

Antwort des PC:

-/-

PC_ARRAY PC 0x0000180B Zugriff Systemarray anfragen

Der PC fragt über die GUiD an, ob er auf das Systemarray des Moduls zugreifen darf.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x0000180B
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 5F 38 08 00 00 18 0B 6D 38 34 01

Antwort der Module:

MD_ARRAY

MD_ARRAY Modul 0x0000180C Zugriff Systemarray freigegeben

Antwort des durch die GUiD im Befehl PC_ARRAY adressierten Moduls mit Freigabe des Zugriffs. Das Modul geht dann in die Wartestellung, alle anderen Module werten die folgenden Anfragen des PC nicht mehr aus. Ausgenommen sind Anfragen des PC außerhalb des Befehls PC_ARRAY_DATA.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x0000180C
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 2B 17 08 00 00 18 0C 6D 38 34 01

Antwort des PC:

-/-

PC_ARRAY_DATA PC 0x0000180D Schreiben/Lesen auf Array

Der PC stellt die Zugriffsanfrage. Dies kann entweder ein Lese- oder ein Schreibzugriff sein. Außerdem ist der Systemarray-Index enthalten, der gelesen oder beschrieben werden soll. Beispiel: D4 = 0 -> Lesen, 1 -> Schreiben; D5 + D6 = Systemarray-Index; D7 = zu schreibender Wert, bei lesendem Zugriff irrelevant. Über den Index des Systemarrays wird außerdem das Ende einer Datenübertragung angezeigt. Liegt der Index über der Maximallänge des Systemarrays und entspricht es einem bestimmten Wert, wird die Wartestellung des Modus für weitere Datenübertragungen aufgehoben und alle anderen Module können wieder auf einen PC_ARRAY-Zugriff angesprochen werden.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x0000180D
D4: 0 -> Lesen, 1 -> Schreiben
D5 – D6: Systemarray-Index
D7: zu schreibender Wert, beim Lesen n.c.

Nachrichten:

Schreibe den Wert 0x0A an die Stelle 0x0001 im Systemarray

00 16 5F 38 08 00 00 18 0D 01 00 01 0A

Antwort der Module:

MD_ARRAY_DATA

MD_ARRAY_DATA Modul 0x0000180E Antwort des Moduls auf Systemarray-Zugriff

Bei einem lesenden Zugriff übergibt das Modul auf D7 den Inhalt des Systemarrays, bei einem schreibenden Zugriff ist D7 irrelevant. Die anderen Datenbytes der Nachricht (D4 ... D6) sind identisch mit der Nachricht des PC.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x0000180E
D4: 0 -> Lesen, 1 -> Schreiben
D5 – D6: Systemarray-Index
D7: gelesener Inhalt des Systemarrays, beim Schreiben n.c.

Nachrichten:

Gelesener Wert 0x07 aus der Stelle 0x0108 im Systemarray

00 16 2B 17 08 00 00 18 0E 00 01 08 07

Antwort des PC:

-/-

PC_UPGRADE PC 0x0000180F Firmware-Upgrade

Der PC fragt über die GUiD an, ob er die Firmware des Moduls upgraden darf. Ist nur aktiv bei Modulen der 3. Generation und nicht gültig für die Module des Typs mbc-91.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x0000180F
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 5F 38 08 00 00 18 0F 6D 38 34 01

Antwort der Module:

MD_UPGRADE

MD_UPGRADE Modul 0x00001810 Firmware-Upgrade freigeben

Antwort des durch die GUiD im Befehl PC_UPGRADE adressierten Moduls mit Freigabe des Zugriffs. Das Modul geht dann in die Wartestellung, alle anderen Module werten die folgenden Anfragen des PC nicht mehr aus. Ausgenommen sind Anfragen des PC außerhalb des Befehls PC_UPGRADE_DATA.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001810
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 2B 17 08 00 00 18 10 6D 38 34 01

Antwort des PC:

-/-

PC_UPGRADE_DATA PC 0x00001811 Schreiben Firmware

Der PC übermittelt die Upgrade-Daten. Das Modul speichert diese in das externe EEPROM zur Vorbereitung der Neuprogrammierung. Die Daten werden PAGE-weise (je 64 Byte) vom Parametriercenter übertragen, so dass der BOOTLOADER hinterher die Daten aus dem externen EEPROM auch korrekt auslesen kann.

Genutzte Datenbytes:

HASH: Laufende Nummer in der jeweiligen PAGE
D0 – D3: Loc-ID 0x00001811
D4 – D7: 4 zu schreibende Bytes

Nachrichten:

Schreibe im laufenden Index 2 die Werte 0x01, 0x00, 0x01 und 0x0A fortlaufend in das externe EEPROM

00 16 03 02 08 00 00 18 11 01 00 01 0A

Antwort der Module:

MD_UPGRADE_DATA

MD_UPGRADE_DATA Modul 0x00001812 Antwort des Moduls auf Schreiben Firmware

Das Modul antwortet mit der exakten Datenstruktur der gesendeten Nachricht und signalisiert damit, dass es die Upgrade-Daten im externen EEPROM gespeichert hat.

Genutzte Datenbytes:

HASH: Laufende Nummer in der jeweiligen PAGE
D0 – D3: Loc-ID 0x00001812
D4 – D7: 4 zu schreibende Bytes

Nachrichten:

Schreibe im laufenden Index 2 die Werte 0x01, 0x00, 0x01 und 0x0A fortlaufend in das externe EEPROM

00 16 03 02 08 00 00 18 12 01 00 01 0A

Antwort des PC:

-/-

PC_BOOT PC 0x00001813 Schreiben Firmware

Der PC übermittelt die Upgrade-Daten. Das Modul speichert diese in das externe EEPROM zur Vorbereitung der Neuprogrammierung. Die Daten werden PAGE-weise (je 64 Byte) vom Parametriercenter übertragen, so dass der BOOTLOADER hinterher die Daten aus dem externen EEPROM auch korrekt auslesen kann.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001813
D4 – D7: GUiD des Moduls

Nachrichten:

GUiD mbc-84 #1 = 6D 38 34 01

00 16 5F 38 08 00 00 18 13 6D 38 34 01

Antwort der Module:

-/-

MD_S88 Modul 0x00001814 Stellungsmeldung mbc-88 / mbc-90

Sendet bei Statusänderung eines PINs die Stellung auf den MBCAN-Bus, so dass sowohl des Parametriercenter als auch andere Module diese ggf. weiterverarbeiten können. Ist ein Relikt aus den ersten beiden Generationen der MBCAN-Modulreihe und sollte bei Eigenentwicklungen durch Auswertung der 0x23-CAN-Kommandos von Märklin® ersetzt werden.

Genutzte Datenbytes:

D0 – D3: Loc-ID 0x00001814
D4 – D5: Modulnummer (BUS 1 1…31, BUS 2 32…62, BUS 3 63…93)
D6: Kontaktnummer (1...16)
D7: Stellung

Nachrichten:

Modul 16 Kontakt 2 hat Stellung 1

00 16 2B 17 08 00 00 18 14 00 10 02 01

Antwort der Module:

-/-

Soweit die von mir definierte Kommunikation zwischen den Modulen und dem PC. Erweiterungen sind jederzeit möglich, Adressraum ist ja noch reichlich vorhanden.

Den Befehlssatz finden Sie als pdf-Datei unter Download.

Quellen:
• "Kommunikationsprotokoll CAN transportierbar über Ethernet", Märklin, 2012

zurück zum Anfang

Der Post-Code von MBCAN

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

Jedes Modul besitzt eine Dreifarb-LED zur Anzeige des Betriebsstatus. Dies ist notwendig, da die Module ansonsten ohne Bus-Verbindungen keine Möglichkeiten haben zu sagen "wie es ihnen gerade geht".

Ähnlich dem Post-Code bei den PC, wo über Töne beim Booten die einzelnen Schritte bestätigt oder Fehler akustisch ausgegeben wurden, habe ich mir einen Licht-Code für die Dreifarb-LED einfallen lassen.

Die LED-Anzeige wird mit 500 ms getaktet und ist je Botschaft 7 s lang; d.h., dass im Grundsatz 6 Blinkschematas zu je einer der drei Farben ROT, ORANGE und GRÜN möglich sind, Mischungen mal ausgenommen.

Die Farbe der LED sind drei Klassen von Botschaften resp. Stati zugeordnet:

ROT: Fehler im Modul
ORANGE: Konfiguration des Moduls
GRÜN: Bestätigung von Prozessen

Stand heute sind folgende Post-Codes implemetiert:

Normalbetrieb
Neuanmeldung PC erfolgreich
Neuanmeldung CS2 erfolgreich
Modulupdate erfolgreich
BT-Schreiben erfolgreich
FW-Upgrade erfolgreich
MCP-CAN-Baustein defekt oder nicht vorhanden
Versorgungsspannung zu niedrig
Firmware-Upgrade abgebrochen, da Fehler beim Parsen des neuen Programms. Das im Controller gespeicherte Programm wird wieder ausgeführt.
Firmware-Upgrade hat einen allgemeinen Systemfehler erzeugt. Das Modul muss über die ISP-Schnittstelle komplett neu aufgesetzt werden.
Interne Firmware wird gestartet (nur bei Modulen mit Upgrade-Funktion)
Firmware-Upgrade - Probedurchlauf wird durchgeführt
Firmware-Upgrade - Programmierung des internen EEPROM wird durchgeführt
Modul konfiguriert die interne Hardware

Unregelmäßiges Aufflackern der orangenen LED-Farbe bei ansonsten grüner LED zeigt Datentraffic auf dem CAN-Bus an. Damit ist erkennbar, ob der auf dem Modul implementierte CAN-Baustein Nachrichten verarbeitet.

Unregelmäßiges Aufflackern der grünen LED-Farbe bei ansonsten dunkler LED beim Hochfahren der Module signalisiert einen Programmiervorgang nach erfolgreichem Überspielen einer neuen Firmware in das externe EEPROM.

zurück zum Anfang

Das Parametriercenter von MBCAN

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

Zur Parametrierung meiner mbc-Module habe ich mir ein Software in Visual Basic programmiert. Das entsprechende SDK bietet Microsoft für private Anwendungen mittlerweile kostenlos an.

Bild 1
Bild 1: Startbildschirm MBCAN-Parametriercenter

Nach dem erfolgreichen Start zeigt sich eine aufgeräumte Benutzeroberfläche. Im linken Teil befindet sich ein Objektbaum in welchem die angeschlossenen mbc-Module gelistet sind. Im rechten Teil sind die entsprechenden Parameter des jeweiligen Moduls zu sehen.

Bild 2
Bild 2: Benutzeroberfläche

Als Beispiel ist nachfolgend die Parametriermöglichkeit eines einzelnen Servos gezeigt. So macht das Modellieren von Bewegungsabläufen Spaß.

Bild 3
Bild 3: Einstellmöglichkeiten für ein Servo

Der Clou: Jedes mbc-Modul hat eine Seriennummer ähnlich einer MAC-ID. Mit dieser meldet es sich über den CAN-Bus und der RS232-, BT- oder WLAN- Schnittstelle des mbc-80-Moduls resp. über das LAN/WLAN-Netzwerk der CS2/3® am Parametriercenter an und kann so von anderen Modulen unterschieden werden.

Bild 4
Bild 4: Kommunikationswege zu den MBCAN-Modulen

Im Parametriercenter kann darüber hinaus der Datentraffic auf dem CAN-Bus mitgelesen werden. Diese Funktion war besonders bei der Softwareentwicklung von enormer Hilfe. Aber auch beim Mitlesen und Entschlüsseln von CAN-Commands, die Märklin® noch nicht dokumentiert hat, tut diese Funktion ihre Pflicht.

Bild 5
Bild 5: CAN-Bus-Monitor

Zu guter Letzt schreibt das Parametriercenter den Datentraffic in eine Datei weg die im Nachgang in Ruhe ausgewertet werden kann.

Bild 6
Bild 6: Logfile einer TCP/IP-Verbindung

Die Bedienungsanleitung und das Installationspaket finden Sie unter Download.

Quellen:
• "Einstieg in Visual Basic 2010", Thomas Theis, Galileo Computing

zurück zum Anfang

MBCAN mit Rocrail® verbinden

Eingestellt: 06.12.2021 --- letzte Änderung: 25.02.2023 --- (c) Dr.-Ing. Thomas Wiesner

Lange habe ich nur mit den Oberflächen der CS2/3® und der MS2® gespielt. Aber irgendwann kommt auch der Wunsch auf, ggf. über den PC die Anlage zu steuern. Auf der Suche nach einem PC-Programm bin ich auf das spendenbasierte Rocrail®-Projekt gestoßen. Rocrail® ist eine "eierlegende Wollmilchsau" was die Verbindung und die Verarbeitung von und zu Zentralen unterschiedlicher Hersteller und Protokolle betrifft. Um so faszinierter war ich, dass mit dem "MBUS"-Modul auch eine UDP resp. TCP-Schnittstelle zu den Märklin®-Zentralen bereits integriert war.

Leider bietet Rocrail® keine RS232- oder BT- Verbindung, die im Sinne von MBCAN das ASCII-Frame-Format eines UDP-Frames versteht. Aber die TCP-Verbindung (MBUS) spricht dieses Frame entsprechend der Märklin®-Konvention. Also anstelle der RS232- und BT-Schnittstelle einen ESP8266-01 als Schnittstelle auf dem mbc-80 integrieren, das Protokoll mappen und schon funktioniert es.

Rocrail® muss ein wenig parametriert werden um an MBCAN zu funktionieren. Zunächst ist die Zentrale einzurichten. Dazu werden die Rocrail-Eigenschaften aufgerufen und der Reiter "Zentrale" ausgewählt.

Bild 1
Bild 1: Einstellungen zur Zentrale

Anstelle der Standard-Schnittstelle wurde hier eine neue Zentrale mit dem Namen mbc-80 erzeugt. Dies geschieht über die Option "NEU" und dort über die Schnittstellenfunktion "MBUS". Die vorhandene virtuelle Schnittstelle kann gelöscht werden. Wird die Zentrale ausgewählt, kann über "Eigenschaften" ein Teil der Konfiguration vorgenommen werden.

Bild 2
Bild 2: Protokoll und Schnittstellenauswahl für die Zentrale

"Typ" der Verbindung ist TCP, als "Hostname" wird die IP-Adresse des mbc-80 eingetragen. Der "Port" ist 15731, also der Standard-Port von Märklin®.

Bild 3
Bild 3: Optionen zur Schnittstellenauswahl für die Zentrale

Bei den Optionen zur Schnittstelle sind alle Optionen bis auf die Schaltverzögerung auszuschalten. Somit arbeitet Rocrail® als Slave was völlig ausreichend für die Funktion ist.

Damit sowohl Ereignisse von den Märklin®-Zentralen als auch umgekehrt von Rocrail® verarbeitet werden können, sind auf der Registerkarte "Automatik" zwei Häckchen zu setzen. Zum einen ist die Option "Signal-Ereignisse" als auch die Option "Signal-Ereignisse verarbeiten" zu aktivieren. Dann werden die Gleisbild-Symbole jeweils wechselseitig bei den Signalen aktualisiert. Bei den Weichen braucht es keine weiteren Einstellungen.

Bild 4
Bild 4: Signal-Ereignisse verarbeiten

Danach können sowohl Signale als auch Weichen über die jeweilige PORT-Adresse angesprochen werden.

Bild 5
Bild 5: Signal-Einstellungen

Bild 6
Bild 6: Weichen-Einstellungen

Mit diesen einfachen Einstellungen lässt sich MBCAN ganz einfach auch über Rocrail® steuern.

Bild 7
Bild 7: Beispiel-Gleisbild mit Verbindung zu MBCAN

zurück zum Anfang