ChRB (Christoph-Röbi-Bahn) - dritte Anlage

Zitat von egos

Wie schaffst du das, dass kein "Stottern" beim Langsamfahren entsteht?

Oski, es kann auch bei uns vorkommen, besonders wenn wir nur einen Pantographen oben haben. Wie du vielleicht gesehen hast, hat die Lok im Video beide Pantos oben. Beim Fahrbetrieb sind wir immer in einem Dilemma: Beide Pantos oben -> sieht nicht realistisch aus, ein Panto oben -> Kann gelegentlich zum Stottern führen.

Ich habe im Sinn, mit der Zeit unsere Loks mit einem Stütz-Kondensator auszurüsten. Damit kann man denen das Stottern gründlich abgewöhnen. Details dazu kann ich dir ja am 1. November erzählen.

So, das bisschen Software im Amorocuino ist erstellt. Dieses kommuniziert nun mit dem Steuerungs-Computer (Amorocos) über USB und sendet diesem jedesmal eine Meldung, wenn der Status einer Lichtschranke geändert hat. Eine solche Meldung enthält folgende Information:

- Nummer des Amorocuino (es wird bei der ChRB III ja einige davon geben, die alle am Amorocos angeschlossen sind)

- Nummer des Amorocuino-Pins, an dem die aktuelle Lichtschranke angeschlossen ist

- Status (ob die Lichtschranke ein Object erkannt hat oder nicht)

Dieser Mini-Franz-Carl-Weber-Schaufenster-Setup hat zwar keine praktische Bedeutung, aber er zeigt auf, dass der Steuerungs-Computer (Amorocos) über den Status der Lichtschranken informiert wird, und dann jeweils die Fahrrichtung der Lok ändern kann, sodass die Lok immer innerhalb der zwei Lichtschranken bleibt.

Zwar fängt jetzt die Arbeit (Software-Erstellung im Amorocos) erst an. Eine sehr genaue Erfassung der Zugs-Positionen ist nun möglich. Demnächst werde ich zeigen, wie ein Zug aus 80 km/h mit regelmässiger Verzögerung einen millimetergenauen Halt am Ende eines Blocks (Ziellandung ) ausführen kann.

We are really excited at ChRB!

Die Verkabelung zwischen den Arduinos und den Infrarot Lichtschranken wie ich's im Beitrag 381 und im Beitrag 398 gezeigt habe, hat sich nicht bewährt. Ich hatte einen Kurzschluss und die Signale von drei Lichtschranken sind beim Arduino gar nicht angekommen.

Die indirekte Verkabelung über das Breadboard war kompliziert und die Platzverhältnisse um etwas umzustecken, waren zu eng.

Jetzt habe ich es geändert. Die Signal-Kabel zu den Arduino-Eingängen sind nun direkt angeschlossen. Die Anschlüsse für die Speisung erfolgen über die Speisungs-Leisten des Breadboards.

Nun funktioniert es bestens. Von jeder Lichtschranke, wenn sie durch einen Zug unterbrochen wird, geht das entsprechende Signal an den Arduino und von dort als Meldung ans Java Steuerungs-Programm auf dem Mac.

So sieht die neue Verkabelung aus. Die Speise-Kabel (rot-schwarz) gehen auf die beiden Speise-Leisten des Breadboard (links) und die Signal-Leitungen (weiss) gehen direkt zu den Arduino-Pins. Jetzt mache ich dann noch eine Kabel-Führung mit Zug-Entlastung, Dann wird es (hoffentlich) auch etwas schöner aussehen.

Heute hatten wir unseren traditionellen Jahresend-Aufräum- und Putztag bei der ChRB. Es sieht jetzt zwar wieder ordentlich aus, aber es hallt beim Sprechen wieder im Raum (fast wie vor einem Jahr , als wir angefangen hatten). Zudem werden wir jetzt erfahrungsgemäss während ein paar Wochen nichts mehr auf Anhieb finden.

Es es jetzt dringend nötig - und damit werde ich schon heute Abend anfangen - wieder die gewohnte und vertraute Unordnung zu veranstalten.

Nichts ist so beständig wie der Wandel

Ich habe jetzt lange nichts mehr geschrieben über den Bau bei der ChRB III. Das heisst aber nicht, dass ich in der Zwischenzeit nichts gemacht hätte.

Im Gegenteil: Ich habe sehr viel Zeit für die ChRB aufgewendet. Dabei habe ich aber auch meine Meinung über gewisse Lösungs-Ansätze und -Konzepte mehrmals geändert, vieles über den Haufen geworfen, neu begonnen, wieder verworfen und wieder neu begonnen. Jetzt endlich glaube ich, auf dem richtigen Weg zu sein.

Alles, was ich jetzt angetönt habe, betrifft nicht den mechanischen Aufbau der Anlage, sondern die Steuerung und deren Konzepte. Vor rund einem Jahr, als wir mit der ChRB III begonnen, war es klar, dass wir mit Selectrix (*) fahren, schalten und melden, wie wir das auch schon bei der ChRB I und II gemacht haben.

(*) Eigentlich haben wir schon lange keine original Selectrix-Komponenten mehr, sondern fast ausschliesslich Selectrix-kompatible Komponenten von ESU, Döhler & Haas, Rautenhaus und Stärz. Aber nichtsdestotrotz funktioniert das alles nach dem Selectrix-System.

Ich hatte (aus Platzgründen) geplant, die Rautenhaus-Komponenten in selbstgedruckte Racks einzubauen.

Aber vieles kam anders:

Bei der Rückmeldung mit Bestztmeldern (statt Reed-Kontakten wie bei der ChRB II), traten Schwierigkeiten auf. Es sind uns ein Fahrstrom-Booster und zwei Lok-Decoder abgeraucht, als wir versuchten den einen Pool des Speisungs-Trafos mit der einen der beiden Schienen (der elektrisch durchgehenden) zu verbinden (was man ja muss, damit die Besetztmeldung überhaupt funktioniert).

Dass wir mit unseren Rautenhaus-Lichtsignal-Decodern immer wieder Probleme hatten (plötzlich gesetzte Parameter verloren), ist eine Tatsache und ein für uns ungelöstes Problem.

Der Selectrix-Bus für Schalten/Melden übermittelt seine Informationen 13 mal pro Sekunde. Das bedeutet, dass die Dauer vom Auftreten eines Ereignisses bis zum Ankommen der Meldung am Steuerungs-Computer variabel lang ist und bis zu 77 ms betragen kann (für mich eher etwas zu lang).

Das alles und die Tatsache, dass ich angefangen habe, mich für die Arduinos zu begeistern, haben mich bewogen, für das Schalten, sowie für das Melden vom Selectrix-System Abschied zu nehmen und etwas Eigenes zu entwickeln.

Die Abkehr vom Selectrix gilt wie oben geschrieben nur für das Schalten und das Melden. Für das Fahren werden wir das Selectrix weiterhin verwenden, obwohl ein Ersatz desselben früher oder später auch ein Thema werden kann.

Nun, der Ersatz des Selectrix für das Schalten / Melden, also das Ablösen der Rautenhaus-Weichen-Decoder, -Lichtsignal-Decoder, und -Rückmelde-Encoder durch eine Eigenentwicklung bildet für mich im Moment mein Haupt-Interesse und darüber werde ich gerne in den nächsten Beiträgen im Detail berichten.

Abkehr vom Selectrix-System für das Schalten und das Melden

Wie im letzten Beitrag geschrieben, habe ich angefangen, ein eigenes Digital-System für die Rückmeldungen an den Steuerungs-Computer, sowie für das Schalten der Weichenantriebe und der Lichtsignale zu entwickeln.

Dass die einzelnen Komponenten auf Arduinos aufbauen sollen, war für mich bald einmal klar. Auch dass das Amorocos (unser Steuerungs-System) mit diesen Arduinos auf irgendeine Art und Weise kommunizieren können muss, liegt auf der Hand. Aber wie?

Ich habe mich dann ziemlich ausgiebig mit Kommunikations-Möglichkeiten zwischen Arduinos auseinandergesetzt und Verschiedenes ausprobiert, bis ich dann schliesslich auf ein Bus-System basierend auf RS-485 gekommen bin. RS-485 ist ein Industrie-Standard für eine asynchrone, serielle Datenübertragung. Im Gegensatz zum sehr verbreiteten RS-232, welches Kommunikation zwischen genau zwei Systemen unterstützt, können mit RS-485 viele Systeme über eine Datenleitung miteinander kommunizieren, also genau was ich brauche.

Nur, das Ganze ist nicht ganz so einfach, wie ich mir das erst vorgestellt habe. Das RS-485 soll im Halb-Duplex-Mode betrieben werden, weil Full-Duplex in dieser Konstellation keinen Sinn macht. Das bedeutet aber, dass jedes Gerät, das an der RS-485-Leitung angeschlossen ist, sowohl senden und empfangen kann. Man stelle sich nun aber das Chaos vor, das entsteht, wenn jedes Gerät wild Daten sendet und nebenbei noch etwas versucht mitzubekommen, was die anderen Geräte gesendet haben ----- no go!

Das kann nur funktionieren, wenn klare Regeln für die Kommunikation aufgestellt sind und sich jedes angeschlossene Gerät strikte an diese Regeln hält. In der Informatik nennt man das ein Protokoll. Wenn mehrere Geräte über die gleiche Leitung kommunizieren, wie das dann bei uns der Fall sein wird, gibt es dafür auch einen Fachbegriff: Das ist dann ein Bus. Wir brauchen also ein Bus-Protokoll, und zwar eines für einen Bus, der auf RS-485 basiert. Bei der Suche nach solchen Bus-Protokollen bin ich auf zwei gestossen, die in der Industrie sehr verbreitet sind. Das eine ist das Modbus-Protokoll, das hauptsächlich im angelsächsischen Raum verbreitet ist. Das andere ist das Profibus-Protokoll von Siemens, welches vorwiegend im EU-Raum und vor Allem in Deutschland angewendet wird.

Beide erwähnten Bus-Protokolle sind aber für wesentlich umfangreichere Anwendungen, als die unsrige und sind entsprechend schwerfällig und kompliziert. Für uns also klar ein Overkill. Was tun? Logo: Es braucht ein weiteres, massgeschneidertes, auf RS-485 basierendes Bus-Protokoll. Uns so ist in den letzten Wochen das Sturzibus-Protokoll entstanden.

Im nächsten Beitrag werde ich (ohne allzu tief ins Detail zu gehen) das Sturzibus-Protokoll vorstellen.

Der Sturzibus

Das folgende Diagramm zeigt den Layout der Steuerungs-Systeme bei der ChRB III. Die beiden vertikalen Anordnungen der Module (links und rechts) reflektieren die beiden "Sammelplätze" für diese.

Zuoberst ist das Steuerungs-Programm Amorocos, das bezüglich seiner Stellung in der Hierarchie etwa mit einem Train-Controller verglichen werden kann. Das Amorocos kommuniziert über USB mit zwei Systemen, dem Selectrix (allerdings nur noch für das Fahren) und mit dem Sturzibus-System (zum Schalten und Melden).

Das Sturzibus-System funktioniert nach dem Master-Slave-Konzept. Heutzutage ist die in der Kommunikations-Technologie bisher sehr gebräuchliche Terminologie "Master-Slave", wie auch der Begriff "Mohrenkopf", die scheinbar an Rassismus erinnern sollen, verpönt. Ich halte nichts davon, sondern ärgere mich eher etwas darüber. Trotzdem - ich will ja nicht provozieren - verwende ich beim Sturzibus die Begriffe "Gateway" statt Master und "Modul" statt Slave.

Also, der Gateway ist beim Sturzibus der Chef. Er kommuniziert mit dem (übergeordneten) Chef, dem Amorocos und er hält bei der Sturzibus-Kommunikation die Fäden in der Hand. Ausschliesslich der Gateway ist befugt, eine Kommunikation zu starten. Alle Module dürfen (und müssen) am Bus "hören", haben aber alles sofort wieder zu vergessen, was sie nichts angeht. Wenn ein Modul aber vom Gateway adressiert, d.h. angesprochen wird, hat es umgehend zu antworten und dann wieder "ruhig" zu sein und nur noch zu "hören". Mit diesem Konzept herrscht Zucht und Ordnung in der Kommunikation.

Für die Entgegennahme von Instruktionen vom Amorocos und für die Weiterleitung von Rückmeldungen der Module ans Amorocos ist ausschliesslich der Gateway zuständig. Die Module wissen nicht einmal, dass oberhalb des Gateways noch eine Hierarchie-Stufe existiert.

In den nächsten Beiträgen werde ich etwas mehr ins Detail gehen, wie das funktioniert und werde auch zeigen, was schon realisiert ist.

Zitat von Bueti

und zwei Direktoren (Christoph und Röbi).

... und einen Verwaltungsrat (Martin).

Zitat von Cebu Pacific

damals machte er seinem Namen noch alle Ehre und stürzte öfters Mal ab.

Das ist richtig. Bei so einer Datenübertragung kann es gelegentlich mal vorkommen, dass - wegen Störeinflüssen von aussen - das eine oder andere Bit unterwegs umfällt. Die Software muss das (z.B. durch ein Prüfsummenverfahren) feststellen können, um nicht plötzlich mit verfälschten Daten zu arbeiten. Das ist der Punkt, wo es definitiv aufhört, einfach zu sein, und bei solchen Fehl-Übertragungen ist der Sturzibus öfters mal abgestürzt, oder genauer gesagt, eingefroren. Der Gateway hat dann auf eine Antwort eines Moduls gewartet und die Module müssen eh die Schnauze halten, weil sie nur etwas sagen dürfen, wenn sie vom Gateway dazu aufgefordert werden. Also eine klassische Dead-Lock-Situation.

Diese Probleme sind jetzt durch zwei zusätzliche Massnahmen gelöst.

1. Wenn ein Modul eine Meldung erhält, bei der etwas nicht stimmt (weil unterwegs damit etwas passiert ist), muss es diese verstümmelte Meldung ignorieren und sofort wieder auf Empfang gehen.

2. Der Gateway benötigt eine Time-Out-Überwachung. Also wenn er innerhalb der zu erwartenden Zeit von einem Modul keine Antwort erhalten hat, muss er den Befehl an's Modul wiederholen.

Sturzibus - Ein Anfang ist gemacht

Auf dem folgenden Bild erkennt man, wie die Sturzibus-Komponenten etwa aussehen werden.

Die vorderste Komponente (im schwarzen Gehäuse) ist der Gateway. Im Gateway agiert ein Arduino-Mega, in dem ein USB-Kabel für die Kommunikation mit dem Amorocos steckt (sieht man stirnseitig). Für den Gateway hätte es auch ein Arduino Uno getan und damit hätte auch ein kleineres Gehäuse gereicht. Aber erstens geht es ja nicht, dass der Chef kleiner ist als seine "Arbeiter" und zweitens wollte ich für alle Sturzibus-Komponenten ein Einheits-Gehäuse mit einem Einheits-Arduino verwenden und das ist bei mir der Mega. Deshalb sieht es auf der oberen Platine etwas leer aus. Was man aber auf der Platine erkennt (in der näheren Ecke) ist ein Transceiver MAX485. Daran wird der physische RS-485 Bus angeschlossen. Intern gibt es Verbindungen zu Ein- und Ausgängen am Arduino.

Was hinter dem Gateway angeordnet ist, sind die Module des Stellplatzes H (linke Kolonne im Organigramm Beitrag 411), wobei die Farben der Gehäuse mit den Kästchen im Organigramm übereinstimmen.

Unmittelbar hinter dem Gateway befindet sich das erste fertige IR-Rückmelde-Modul (gelb). An den 42 dreipoligen Schraubklemmen sind die Infrarot-Lichtschranken angeschlossen. Intern sind diese mit Ground, DCC (5V), sowie je mit einem Arduino-Eingang verbunden. Die Aufgabe des IR-Rückmelde-Moduls ist, auf Aufforderung des Gateway, den Status aller 42 Lichtschranken-Anschlüsse in einem 10 Byte umfassenden Telegramm an den Gateway zurückzumelden, welcher es seinerseits ans Amorocos weiterleitet.

Auch das IR-Rückmelde-Modul besitzt (wie der Gateway und alle anderen Module) einen MAX485 Transceiver für den Anschluss des RS-485-Busses. Auf dem Bild sieht man vom Transceiver des Gateway ein senkrecht nach unten führendes Kabel, das durch ein Loch in der Tischlatte verschwindet. Das ist der Teil des Busses, der über eine Distanz von gut 5 Metern zum Stellplatz K führt. Wegen der hohen Geschwindigkeit des Sturzibus (ich möchte ihn mit einer Geschwindigkeit von mindestens 500'000 Bit pro Sekunde betreiben), muss hier ein abgeschirmtes und paarweise verdrilltes Kabel verwendet werden, für welches ich ein hochwertiges USB-Kabel missbraucht habe. Vom gleichen Transceiver führt auch ein dreiadriges Kabel zum Transceiver des nächsten Moduls. Wegen der kurzen Distanz geht hier auch ein gewöhnliches Kabel, das nicht abgeschirmt sein muss.

Auf dem folgenden Bild sieht man der Gateway und das erste IR-Rückmelde-Modul etwas genauer.

Beim IR-Rückmelde-Modul sind noch längst nicht alle Schraubklemmen angeschlossen. Die sind für die zweite (noch nicht realisierte) Hälfte des Schattenbahnhofs reserviert. Die herumliegenden USB-Kabel sind nur für das Laden von Software vorgesehen. Im Betrieb besteht keine Verbindung zu einem übergeordneten System, ausser über den Sturzibus zum Gateway.

Auch die Speisung mit 5V DC für die Arduinos erkennt man hier gut (bei der Haupt-Platine rechts oben mit dem angeschlossenen rot/schwarzen Kabel).

Und hier sieht man die andere Seite (den Stellplatz K). Dies entspricht der rechten Kolonne im Organigramm (Beitrag 411).

Auch hier ist erst ein IR-Rückmelde-Modul ausgerüstet. Beim zugehörigen Transceiver ist das Kabel angeschlossen, das vom Stellplatz H her kommt. Ganz vorne sieht man den Gleichrichter für die Speisung der Weichen-Module, die im Moment in Fertigung sind. Für die Weichen-Antriebe würden die 5V des Arduino nicht ausreichen. Deshalb werden die Weichen-Module zusätzlich mit ca. 20 VDC gespeist.

Adressierung der Sturzibus-Module

Mit dem erwähnten Konzept, dass jede Kommunikation vom Gateway initiiert wird und sich an ein bestimmtes Modul richtet, wird klar, dass jedes Modul eine eindeutige Adresse braucht. Eine Modul-Adresse ist eine Zahl im Bereich 0 ... 127. Der Bereich ist so gewählt, dass die Adresse in jedem Fall in sieben Bit gespeichert werden kann.

Interessant ist, dass der Gateway keine Adresse hat (und braucht). Da der Gateway jede Kommunikation mit einem bestimmten Modul initiiert, muss er im vorhandenen Adress-Feld des Telegramms die Adresse des Ziel-Moduls angeben. Wenn das angesprochene Modul eine Antwort an den Gateway schickt, verwendet es im Adress-Feld seine eigene Adresse, damit der Gateway weiss, ob das richtige Modul geantwortet hat.

Adressierung:

• Die IR-Rückmelde-Module haben die Adressen 0, 1 und 2. Jedes Modul ist für den Anschluss von 42 IR-Lichtschranken vorgesehen.
• Die Besetztmelde-Module haben die Adressen 10, 11, ..., 17. Jedes Modul wird für 16 Besetztmelde-Strecken gebaut. Hier steht die Anzahl Module noch nicht ganz fest, aber es dürften um die acht sein.
• Die Weichen-Module haben die Adressen 30, 31, 32 und 33. Vier Weichen-Module müsste gerade reichen. Jedes Modul kann 20 Weichen-Antriebe bedienen und davon haben wir etwa 75.
• Die Lichtsignal-Module haben die Adressen 40, 41, 42 und 43. Voraussichtlich wird ein Modul für sieben oder acht Lichtsignale mit bis zu 7 LED ausreichen.

Die Adresse des aktuellen Moduls wird im (in jedem Arduino vorhandenen) EEPROM gespeichert. Das ist ein nicht-flüchtiger Speicherbereich. Wenn die Adresse einmal geschrieben ist, ist sie somit dem jeweiligen (physischen) Arduino fest zugeordnet. Das Arduino-Programm hingegen, das die Funktionalität der Module bestimmt, soll für alle Module gleich sein. Das Programm soll also in jede Rolle schlüpfen können, sei es IR-Rückmeldung, Weichenantrieb, Lichtsignal, ... . Aus der Adresse kann das Programm ermitteln, von welchem Typ das Modul ist und dann die entsprechende funktionale Rolle einnehmen.

Das Sturzibus-IR-Rückmelde-Modul

Diesem sind wir im vorletzten Beitrag schon begegnet. Hier werden sie noch etwas mehr im Detail gezeigt. Zwei davon sind bereits fertig und betriebsbereit. Jedes dieser Module ist für bis zu 42 Infrarot-Lichtschranken gebaut. Die Anzahl der Lichtschranken im Endausbau liegt zwischen 84 und 126. Also brauchen wir noch ein drittes, das ich demnächst anfertigen werde.

Hier sieht man ins Innenleben des IR-Rückmelde-Moduls. Unten sieht man den Arduino Mega mit einem aufgesteckten Proto-Shield. Die grünen Kabel im Inneren stellen die Verbindung zwischen den Schraubklemmen und den Arduino-Eingängen auf dem Proto-Shield her.

Die nächsten beiden Bilder zeigen den Arduino mit dem Proto-Shield im Huckepack, sowie die beiden einzelnen Komponenten. Am Arduino selber wird nichts verlötet. Dieser kann jederzeit vom Huckepack abgetrennt und (falls nötig) durch einen anderen ausgetauscht werden.

Danke, Oski. Deine Komplimente bringen mich wieder mal in Verlegenheit. Dabei mache ich ja nur, was mich jeweils grad "packt".

Ich freue mich auch auf deinen nächsten Besuch.