Tagebuch vom Bau einer Modelleisenbahn

Neue Bootloader geflasht

Heute wurden einige Änderungen am CAN-Bus-Protokoll eingeführt. Die Broadcast-ID und die Gateway-ID wurden ausgetauscht. Dadurch haben Antworten der CAN-Knoten höhere Priorität auf dem Bus als alle anderen CAN-Meldungen. Gleichzeitig wurde die Antwortmeldung um zwei Bytes gekürzt. Diese Änderung machte das Umflashen der sämtlicher Bootlader und neue Gateway-Firmware notwendig.

Das war eine typische Unter-Tisch-Arbeit mit viel Kletterei. Wie es bei Murfy so ist, hat es nicht auf Anhieb geklappt. Die Ursache habe ich zwei Stunden später herausgefunden: Ich habe beim Flashen einen CAN-Knoten übersehen. Da er noch das alte Protokoll sprach, hat er den Flashvorgang der neuen Firmware gestört.

Zum guten Schluss hat alles geklappt und die neuen Bootlader erfüllen wieder ihren Zweck. Ein paar kleinere Probleme in der Steuerungs-Software waren schnell gefunden und behoben. Hier zeigt sich der Vorteil des automatischen Testens. Diese Tests sind fehlgeschlagen, weil über hart verdrahtete Indizes in der Antwortmeldung zugegriffen wurde. So konnte der Fehler vor Inbetriebnahme gefunden werden.

Kommandoverarbeitung wird modellbasiert generiert

Die Kommandoverarbeitung in der Firmware der CAN-Knoten war ein unschönes Stück Spaghetti-Code. Es dient trotzdem als Referenzimplementierung für die modellbasierte Firmware-Entwicklung. Zuerst wurde ein Zustandsdiagramm gefertigt, das die Betriebszustände enthält. Die eingehenden Kommandos sind die Zustandsübergänge enthalten. Aus diesem Diagramm wird mit Hilfe von openArchitectureWare der Code für die Kommandoauswertung generiert. Der Code enthält relativ viele Callbacks und switch/case-Anweisungen und bläht den Binärcode um ca. 1,5 KByte auf. Das ist aber nicht weiter schlimm, da jetzt noch Platz für ca. 18 KByte im Flash des ATmega32 vorhanden ist.

Formsignale funktionieren auch

Heute habe ich einen üblen Fehler in der Firmware der Microcontroller gefunden. Diese haben die Konfiguration der Formsignale zerschossen und dadurch die Ansteuerung unbrauchbar gemacht. Hier zeigt sich die Stärke, den Microcontrollern einen CAN-Bootloader zu verpassen. So können alle 14 verbauten Controller in einem Rutsch mit fehlerfreier Firmware geflasht werden.

Behebung der Restprobleme

Die problembehafteten BRAWA-Signale sind nun auch in Ordnung gebracht. Ein Blocksignal scheint eine durchgebrannte Glühbirne zu haben. Diese kann aus einen Einfahrsignal mit unnützerweise zwei roten Glühbirnchen repariert werden. Auch ein Weichenantrieb scheint nicht durchzuschalten. Dieser muss vermutlich neu gekauft werden, denn die Ansteuerung des Schattenbahnhofs gelingt so nur von einer Seite.

Es sind noch einige andere Restarbeiten zu erledigen. Jetzt ist unter Eisenbahnanlage richtig Platz, so dass mal richtig gesaugt werden kann. Die Kabel der Weichen und Signale wurden nicht gekürzt. Sie werden zu Schleifen gebunden und mit dem Elektrotacker fixiert. Einige wenige Anschlüsse müssen noch beschriftet werden. 90 Prozent dieser Arbeit wurde schon vor der Verkabelung erledigt. Dies hat sich während der Verkabelung als sehr nützlich erwiesen, so dass die Konfiguration der Microcontroller sehr einfach von statten ging.

Prototypen für Magnetartikel-Module fertiggestellt

Ähnlich einfach, wie die Entwicklung der Lichtsignal-Module gestaltete sich heute der Prototyp für die Weichenschaltung. Nachdem auf dem Steckbrett eine funktionierende Schaltung zusammengesteckt war, wurde ein Prototyp gelötet. Einige Anpassungen in der CAN-Knoten-Firmware waren notwendig, damit die Weichen oder Signale geschaltet werden können. Typische Modellweichen werden über Magnetspulen angetrieben. Diese haben heutzutage eine Endabschaltung, um das Durchbrennen der Magnetspulen durch Fehlbedienung zu verhindern. Diese Endabschaltung lässt sich dazu ausnutzen, um die Lage der Weiche festzustellen. So lassen sich manuelle Schaltvorgänge feststellen und es lässt sich ein automatischer Schaltvorgang beschleunigen. Denn während eine Weiche ohne Endabschaltung für eine gesicherte Zeit unter Strom gesetzt werden muss (hier etwa eine Sekunde), kann der Strom bei einer endabgeschalteten Weiche abgeschaltet werden und der nächste Schaltvorgang in Angriff genommen werden. Auch lässt sich so feststellen, ob überhaupt ein Schaltvorgang nötig ist. Zeigt eine Weiche auf den linken Abzweig, muss ein Auftrag, die Weiche nach links zu schalten nicht mehr durchgeführt werden.

Prototypen für Lichtsignal-Module fertiggestellt

Heute wurden die Prototypen für die Module der Lichtsignale fertig gelötet. Die Module werden über ein 10-poliges Kabel kaskadiert mit einem Mikrocontroller verbunden. Darüber laufen Spannungsversorgung und die Datenleitung. Auf den Modulen sind Schieberegister (74HC595) samt Leistungstreiber (ULN 2803) für die Lichtsignale vorhanden. Es können bis zu vier Module kaskadiert werden. Die Controller sind in der Lage, die korrekten Signalbilder der Deutschen Bahn anzuzeigen. Es wird also nur das Kommando gegeben, dass z.B. das Signal P3 auf Hp2 geschaltet werden soll. Es werden Vorsignale, Blocksignale, Einfahrsignale, Ausfahrsignale und Gleissperrsignale auseinandergehelten. Dabei könnten in Zukunft noch weitere Signale - wie z.B. die neuen Ks-Signale - der Controller-Firmware hinzugefügt werden, denn es ist ein In-System-Programming der Firmware über CAN-Bus möglich.

Schaltung für Steuerung über CAN-Bus steht

Seit letztem Donnerstag entwickeln mein Kollege Marc Habiger und ich die Stellwerkssteuerung für die Modellbahn. Heute haben wir den CAN-Protokollumfang in den Griff bekommen. Dazu zählt natürlich der Austausch von CAN-Frames, sowie die vernünftige Filterung der Frames am Controller. Dadurch können gleich die unwichtigen Pakete rausgefiltert werden, ohne dass der Mikrocontroller mit Rechenzeit belastet wird. Auch das Versenden von Standard Data Frames sowie Extended Data Frames funktioniert problemlos.

Derzeit arbeiten wir an der Kopplung der Kommunikation mit dem PC. Diese soll über die schon altbackene RS232-Schnittstelle geschehen. Diese hat aber bis heute jeder PC und somit muss keine neue Steckkarte oder andere Erweiterung für den PC gekauft werden. Ein CAN-RS232-Gateway setzt die CAN-Frames vom PC über RS232-Schnittstelle auf den CAN-Bus um.

Ich werde häufig gefragt, warum das Ganze über CAN-Bus läuft. Schließlich gibt es genug ausgereifte Digitalmodule für die Modellbahn. Es ist so, dass der CAN-Bus viele gute Eigenschaften hat. Der CAN-Bus wurde von Bosch für den Automotive-Umfeld entwickelt. Ziel war es, durch Einsparung von Verkabelung Aufwand und Gewicht einzusparen. Inzwischen sind 20 Jahre vergangen und der CAN-Bus steckt in nahezu jedem Neuwagen. Die mechanische Belastung auch im Auto sind teilweise enorm, so dass mit dem CAN-Bus ein robuster 2-Draht-Bus (mit der Karosserie als Masse) geschaffen wurde. Bei der Modellbahn sind einige dieser Aspekte auch von Bedeutung. Ziel ist es, Verkabelung einzusparen. Nicht aus Gewichtsgründen, sondern aus rein ergonomischen Gründen, da die Drähte über Kopf montiert werden müssen. Auch die Robustheit spielt dabei eine Rolle. Es gibt auch auf einer Modellbahn viele Störeinflüsse gerade durch Antriebsspulen.

Zum guten Schluss zählt doch eins: Man hat etwas eigenes entwickelt um es zu verstehen. Obendrein ist es auch erheblich kostengünstiger, als die käuflich zu erwerbenden Digitalmodule. Letztlich ist es einfach nur cool, wenn man der Modellbahnanlage ein Firmware-Update spendiert ;-)