Überblick
Das FREMO Stellwerk oder Elekdra ist keine Modellbahnsteuerung im klassischen Sinnen sondern versucht die Abläufe der aus dem Vorbild nachzubilden. Dabei wird ein Schwerpunkt auf die Unterstützung dieser Abläufe gelegt, mit dem Ziel, in einem Modul-Arrangement im FREMO, den Betrieb nach Fahrplan und mit Zugnummern unter Berücksichtigung von Blocksicherungen (Streckenblock) zu ermöglichen.
Elekdra stammt mehrheitlich aus der Feder von Thomas Kurz und später Stefan Bormann und wird mit einigen anderen FREMO-Mitgliedern weiterentwickelt. Es handelt sich um ein Open-Source-Project, dass in Java als Programiersprache implementiert wird. Damit ist eine weitgehende Unabhängigkeit von einer Hardwareplattform gegeben. Es läuft derzeit unter Windows und Linux.
Auf der Webseite "FREMO Interlocking" schreibt Thomas Kurz:
Was ist Elekdra?
Elekdra MB: Elektronisches Stellwerk für Modelleisenbahnen
Elekdra MB ist ein elektronisches Stellwerk (ESTW), das speziell auf die Anforderungen im Modellbahnbereich konzeptioniert ist. Dabei ist auch auf die besonderen Gegebenheiten des Modulbaues eingegangen worden.
Elekdra soll die logische Komponente in der Bahnhofsteuerung sein. Das heißt, dass hier alle Bedingungen, die einen "sicheren" Betrieb auch im Modellbahnbereich sicher sollen, überprüft werden. Elekdra stellt neben der sicheren Bedienung der einzelnen Komponenten wie Weichen auch eine Bedienung des Bahnhofes mit Hilfe einer Fahrstrassenlogik zur Verfügung. Dabei soll bei jeder Handlung, die der Bediener setzt, eine Überprüfung erfolgen, ob diese Handlung nicht gegen betriebliche und sicherheitstechnische Regeln verstösst.
Da Elekdra keine eigene Schnittstelle zum Benutzer hat, ist sie universell für die verschiedensten Arten von Schnittstellen einsetzbar. Elekdra stellt eine universelle Schittstelle zur Bedienung zur Verfügung. Auf dieser Schnittstelle können Anschließend andere Benutzerinterfaces aufsetzen. Dies eröffnet die Möglichkeit, dass Elekdra sowohl mit einem herkömlichen Drucktastenstellpult bedient werden kann, aber auch mittels Bedienoberflächen am PC. Diese Schnittstelle eröffnet aber auch die Möglichkeit, einen Bahnhof, der mit Elekdra ausgestattet ist, fernzusteuern.
Durch den Einsatz von LotusNet ermöglicht Elekdra den Einsatz kommerzieller Element-Decoder und Rückmeldemodule.
Um den Einsatz im Modulbau zu gewährleisten wird Elekdra so allgemein definiert, dass eine Anpassung an andere Gegebenheiten leichtgewichtig und schnell durchführbar sind.
Elekdra besteht aus den folgenden Hauptbestandteilen, die miteinander kommunizieren:
- Dem Stellwerks-Kern oder auch Logik-Modul (Elekdra)
- Der Schnittstelle zur Hardware
- Dem Bediener-Interface (Elui, Etis60, StDrs60, ...)
- Den weiteren Schnittstellen
Mit Elekdra werden nur Weichen, Signale, Fahrstrassen beeinflusst und Rückmeldungen vom Gleis entgegengenommen, der Streckenblock gesichert und Zugnummern dargestellt. Es werden keine Triebfahrzeuge beeinflusst! Es handelt sich also um eine reine Stellwerkssoftware.
Falls Sie etwas anderes zur Modellbahnsteuerung gesucht haben, schauen Sie doch z.B. bei anderen OpenSource Projekten wie z.B. Rocrail oder JMRI rein. Alternativ gibt es auch viele kommerzielle Anbieter.
Es ist nicht ausgeschlossen, das hier später auch über die Verwendung von Rocrail im FREMO berichtet wird!
Die grundlegende Architektur des FREMO STW sieht wie folgt aus:
Schaut man sich das Bild oben an, stellt man fest, dass nicht wirkliche viele Grundbausteine notwendig sind. Wir werden aber später sehen, dass deren Definition, die Logik dahinter und die Abhängigkeiten bisweilen eine unterhaltsame Denksportaufgabe sind.
Digitale Steuerung im FREMO
Der FREMO unterscheidet bei der Digitaltechnik zwischen Fahren und der Sicherungstechnik
Gefahren wird mit dem DCC Standard. Alle relevanten Informationen findet man auf fremo-net unter https://www.fremo-net.eu/digital.html
Mit dem DCC Standard werden die Triebfahrzeuge bzw. deren Decoder gesteuert. Dazu werden die FRED’s verwendet – FREMOS einfache Drehregler. Damit kann der Triebfahrzeugführer immer neben dem Zug hergehen und befindet sich auf der Höhe des Geschehens.
Sicherungstechnik ist Sache des Betriebsstellenbesitzers, unterliegt aber gewissen Regeln, damit ein realistischer Fahrbetrieb möglich ist. Die Informationen findet man ebenfalls auf fremo-net unter
https://www.fremo-net.eu/signale.html
Grundlage ist eine DCC Zentrale (im weiteren „Betriebszentrale“ genannt) und ein Bussystem (LocoNet + RailSync)
· Eine einzige Betriebszentrale steuert die gesamte Fahrzeugbeeinflussung
· Jedes Fahrzeug hat eine fixe Adresse (lange DCC Adresse)
· Jede Adresse ist einem Regler (Fred) zugeordnet
· Aus Leistungsgründen ist ein Arrangement unterteilt und jedes «Bezirk» bekommt einen Booster, der ebenfalls am Bus (LocoNet) hängt.
Nur so ist ein Fahrbetrieb mit vielen Teilnehmern auf dem Arrangement möglich. Das folgende Bild zeigt schematisch, wie ein Arrangement aus zwei Bahnhöfen aufgebaut sein kann.
Betriebssysteme und Anforderungen
Hardwareseitig sind keine besonderen Anforderungen zu erfüllen, damit Elekdra funktioniert. Ein 5 Jähriger PC- oder Laptop-Oldtimer mit 1GB Speicher, ein wenig Platz auf der Festplatte (ca. 400MB), einer halbwegs passablen Grafikkarte und Monitor (1028 x 1024 Auflösung) und Netzwerk/WiFi sollten reichen. Wichtig wäre noch der USB 2.0 Anschluss, damit die Verbindung zur LocoNet-Hardware (LocoBuffer-USB, Zentrale) funktioniert.
Windows XP, Windows Vista, Windows 7 oder 8.1 sollten problemlos funktionieren. Wenn also Programme wie OpenOffice oder Microsoft Office problemlos starten, ist genug Leistung vorhanden.
Auf Linux und Mac gehen wir gesondert ein. Linux wegen dem RaspberryPi und Mac, weil mir keiner zur Verfügung steht… .
Ein PC wie oben beschrieben bekommt man Gebraucht für 200-300 Euro bzw. CHF. Toll wäre es, wenn der PC dann exklusiv für die Steuerung und Modellbahn zur Verfügung steht. Die Konfiguration von Firewall und Virenscanner wird später kurz beschrieben.
Elekdra ist in JAVA Programmiert. Damit ist das sogenannte Java Runtime Environment ein notwendiger Bestandteil. Java kann man kostenfrei beziehen.
Digitalzentralen, LocoBuffer-USB & Decoder
Loconet ist das Verbindungsprotokoll, was verwendet wird, damit die Software (Elekdra) ihre Befehle an die Hardware (Decoder) übertragen kann. Wer sich vertieft mit Loconet auseinandersetzen will, möge bitte im Anhang die Links zu Loconet und Digitrax anschauen.
Man kann hier zwei Arten unterscheiden:
- Loconet über eine Zentrale gesteuert
- Standalone Loconet über einen PC gesteuert
Schaut man sich den ersten Fall an, stellt man fest, dass man mit einer modernen Zentrale eine Art Computer zur Automation erworben hat.
Mit der Zentrale kann man natürlich alle relevanten Aspekte abdecken.
- Fahren (Zugbeeinflussung)
- Schalten (Weichen, Signale)
- Fahrstrasse (Logik & Abhängigkeiten)
- Rückmelden (Zustand von Weichen/Signalen, Gleisbesetztmeldung)
- Booster Steuerung
ABER – Wie wir oben schon gelernt haben, wird im FREMO der Betrieb von der Sicherungstechnik getrennt. Also müssten wird das Bild der Zentrale nochmals neu Zeichnen.
Die Betriebszentrale ist für die Zugbeeinflussung Zuständig.
Eine oder mehrere Weitere Zentralen oder LocoBuffer-USB sind auf der Betriebsstelle für die Sicherungstechnik zuständig.
Auf dem Bild unten erkennt man die beiden separaten „Zentralen“ als Laptop mit LocoBuffer-USB.
Die Betriebszentrale verwendet LocoNet als Protokoll, um Booster einzubinden und um mit den Fredi’s die Triebfahrzeuge zu steuern. Dieses LocoNet hat KEINE Verbindung zu den Betriebsstellen – ausser zu den Boostern der Betriebsstelle.
Da LocoNet so ein praktisches Protokoll ist, kann Elekdra via Loconet kommunizieren. Im Gegensatz zum Loconet der Betriebszentrale ist das isolierte Betriebsstellen Loconet etwas erweitert worden und wird daher im FREMO Lotusnetz genannt. Technisch ist es beides auf dem Digitrax LocoNet Protokoll aufgebaut.
Installation
Comming soon...
Die eigene Betriebsstelle
Bevor wir nun eine eigene Betriebsstelle definieren, versuche ich mal mit einem Fluss-Diagramm darzustellen, was notwendig ist, eine Betriebsstelle zu definieren und welche Informationen wir dazu benötigen.
Aufbau der Konfiguration
Grundsätzlich ist es so, dass Elekdra alle XML Dateien liest, die durch das Start-Verzeichnis im Startup-Script vorgegeben werden. Das bedeutet zweierlei:
- Es können beliebig viele XML Dateien vorliegen oder es kann alles in einer einzigen XML Datei vorliegen
- Eine oder alle XML Dateien werden vollständig gelesen und überprüft
XML Dateien:
XML Dateien sind aus sogenannten “TAG’s” aufgebaut. Diese separieren die einzelnen Elemente und haben einen “Start-” und eine “End-Tag”. Diese müssen immer “richtig geformt“ sein. Also jedes Start-Tag muss auch ein End-Tag haben. Tags können auch geschachtelt werden, allerdings muss dann die richtige Sequenz beachtet werden.
Hier mal ein Beispiel für eine Tag-Sequenz, die eine Weiche definiert:
<elekdra.turnout>
<name>W1</name>
<hastrafflock>true</hastrafflock>
<selflocking>false</selflocking>
<loconet>
<lnaddress>151</lnaddress>
<protocol>sw_req1</protocol>
<inverted>false</inverted>
<resend_sec>30</resend_sec>
</loconet>
</elekdra.turnout>
Das erste Start-Tag lautet:
<elekdra.turnout>
Das zugehörtige End-Tag lautet:
</ elekdra.turnout>
Dazwischen gibt es einen Loconet-Block sowie drei Tags, die den “Tournout” beschreiben.
Was heisst den nun „richtig geformt“?
<elekdra.turnout> ... </elekdra.turnout>
Zwischen den spitzen Klammern <> steht das Schlüssel-Wort „elekdra“. Dieses Schlüssel-Word ist um ein weiteres Schlüssel-Word „turnout“ ergänztz worden. Getrennt durch einen Punkt „.“ Jetzt können weitere Tags die Weiche (turnout) noch genauer beschreiben. Abgeschlossen wird die Beschreibung dieser einen Weiche mit dem gleichen Tag, aber – und das ist das wichtige geschlossen mit eine „/“ ! Es muss also immer ein solches „Pärchen“ geben.
Mit Hilfe von diesen Strukturen in den XML Dateien, teilen wir Elekdra und Elui sowie den anderen Softwarebausteinen mit, was unsere Betriebsstelle auszeichnet und auf was es zu Achten gibt. Hier definieren wir unsere Lego-Bausteine selber!
Eine gute Einführung in Sachen XML findet man bei selfhtml.org unter:
wiki.selfhtml.org/wiki/XML
Das WICHTIGSTE aus Selfhtml nochmals in Kürze:
Als Markup bezeichnet man alle Zeichengruppen, welche eine Struktur in XML definiere
Start-Tags, z.B.
<startTag>
End-Tags, z.B.
</endTag>
Leerelemente, z.B.
<Leerelement />
Entitätsreferenzen, z.B.
&
Zeichenreferenzen, z.B.
&x0f;
Kommentare, z.B.
<!-- Kommentar -->
Hilfreich ist sicherlich ein guter Editor. Es gibt viele Gute Editoren. Ich persönlich kann für den Einsatz unter Windows den Editor Notepad++ empfehlen: notepad-plus-plus.org Der behherscht auch XML Syntax Highlighting.
XML-Dateien:
Diese kleine Beispiel zeigt, warum es nicht sinnvoll ist, alles in eine einzige Datei hinein zuschreiben. Die XML-Datei würde sehr lang und schnell sehr unübersichtlich werden. Daher habe ich für mich folgende Struktur definiert (die Präfixe aus Nummern sorgen dafür, dass die Reinfolge richtig ist):
100_Bahnhofsname_Configuration.xml
Beinhaltet alle Elekdra-Konfigurationen wie Weichen, Gleise, Fahrziele, Signale, Blocksignale und Sensoren ohne eine konkrete Anordnung auf der Grafischen Ebene. Hier geht es nur um die Definition der Grundbausteine unseres Bahnhofs.
200_Bahnhofsname_Graphics.xml
Beinhaltet alle Elui-Konfigurationen, die Grundbausteine aus der 100er Datei sowie deren Anordnung und Ausrichtung in der Elui-Grafik.
300_Bahnhofsname_Baseroutes.xml
Beinhaltet alle Basis-Fahrstrassen aus den Grundbausteinen aus der 100er Datei sowie deren Grundstellung und Schutzstellungen, aus denen sich die Logik (Verschlussplan) des Bahnhofs ergibt.
400_Bahnhofsname_Routes.xml
Beinhaltet alle Rangier- oder Verschub-Fahrstrassen aus den Grundbausteinen aus der 300er Datei sowie deren Grundstellung und Schutzstellungen, aus denen sich die Logik (Verschlussplan) des Bahnhofs ergibt.
500_Bahnhofsname_ZNA.xml
Konfiguration des Zugnummern-Systems.
600_Bahnhofsname_TCP_TCP_Block.xml
Konfiguration des Streckenblocks von und nach anderen Bahnhöfen.
Bevor wir jetzt anfangen die Dateien für einen Bahnhof zu schreiben, wäre es gut zu wissen, welche Komponenten denn in etwa beteiligt sind und wie diese Angeordnet und nummeriert oder benannt sind.
Komponenten in Elekdra
Hier mal ein simples Beispiel von einem Streckenblock, der alle Komponenten beinhaltet:
Es sind auf dem Bild zwei Bahnhöfe “A” und “B” zu erkennen. Je eine Weiche und Signale. Dazu kommt noch ein Gleiskontakt je Bahnhof sowie die Bahnhofsgleise 1 und 2 (von unten gezählt) sowie das Streckengleis (Block) zwischen “A” und “B”. Nicht sichtbar sind die logischen Elemente wie die Fahrstrassen. Folgende Zugfahrten sind denkbar:
- Von “A” Gleis 1 nach “B” Gleis 1
- Von “A” Gleis 1 nach “B” Gleis 2
- Von “A” Gleis 2 nach “B” Gleis 1
- Von “A” Gleis 2 nach “B” Gleis 2
- Von “B” Gleis 1 nach “A” Gleis 1
- Von “B” Gleis 1 nach “A” Gleis 2
- Von “B” Gleis 2 nach “A” Gleis 1
- Von “B” Gleis 2 nach “A” Gleis 2
Jede Weiche hat eine Grundstellung (Grade oder Abgelenkt) und je nach Zugfahrt müssen die Weichen anders gestellt werden. Ausserdem gibt es noch den Sicherheitsaspekt. Es darf nur ein Zug auf der Strecke sein. Wenn also ein Zug aus “A” nach “B” unterwegs ist, darf keines der Ausfahrt Signale in “B” auf Fahrt gehen. Der Bahnhof “A” verschliesst mit dem Block “AB” die Ausfahrt von “B”. Und natürlich umgekehrt.
Genau auf die Bereitstellung der Komponenten zur Lösung des scheinbar kleinen Bahnhofs mit Strecke zielt die Struktur von Elekdra ab!
Neben der Hardware im Rechner und dem Zusammenspiel mit der Modelbahnhardware stellt Elekdra folgende Elemente zur Verfügung (in Klammern die Englischen Begriffe):
- Weichen (Turnout)
- Gleis (Track)
- Signale (Signal)
- Gleiskontakte (Sensor)
- Logische Ebenen = Fahrstrassen (Route)
- Logische Ebenen = Block (Block)
Ein Block kann aus einem oder mehreren Weichen, Gleisen und Signalen bestehen. Gleiches gilt für die Fahrstrasse. Block ist die freie Strecke zwischen “A” und “B” plus die “Schutzstrecke”. Eine Fahrstrasse kann z.B. auch zum Rangieren aus “A” Gleis 1 auf die freie Strecke notwendig sein. Damit ist dann auch einleuchtend, warum es wichtig ist, die Grundpositionen der Elemente zu kennen, die aktuelle Stellung zu wissen und die logischen Abhängigkeiten voneinander zu definieren.
Beispiel “Wagenübergabestelle Bennewitz & Wichern”
Um ein Beispiel zu zeigen, welches sich im Aufbau befindet, habe ich meine eigene Betriebsstelle „B&W – WÜST“ hier als Beispiel verwendet. Die Daten habe ich immer zu Hand und kann sie entsprechend Darstellen.
Schaut man sich die Symbol-Skizze der WÜst von B&W an, habe ich mal alle Gleise durchnummeriert.
Gleis „G114 / G115“ ist eigentlich das Streckengleis. Bei mir nach den Vorgaben der SBB und einer fiktiven Kilometrierung benannt (Km 114, Km115).
Von Oben nach Unten geht es dann wie folgt weiter:
· Weiche „W1“ – Einfahrtsweiche
· Weiche „W2“ – Schutzweiche zu G11
· Gleis „G11“ – Schutzgleis für Fehlfahrten und zum Umsetzen
· Weiche „W3“ - Weiche zu G3 und via W4 zu G1 und G2
· Weiche „W4“ - Weiche G1 und G2
· Gleis „G1“ – Umfahrgleis
· Gleis „G2“ – Bereitstellgleis
· Gleis „G3“ – Einfahrtgleis
· Weiche „W7“ – Weiche zu G4 und G5 via W6
· Weiche „W6“ – Weiche zu G4 und G5
· Weiche „W5“ – Weiche von G1 und G2
· Weiche „W9“ – Weiche von G3 und G1 und G2
· Gleis 53 geht dann nachher in den Industrieanschluss, der aber im Moment noch nicht betrachtet wird.
Dazu kommen noch die Signale in der SBB Notation:
· Vorsignale: 14P* und 14R*
· Hauptsignale: 14P und 14R
· Zwerge: 1A, 1D, 2B, 2C
· Ausfahrsignal: A
· Rangiersignal: R1, R2
· Sperrsignal: S1
Es ist wie beim spielen mit Lego – man lernt nach und nach die Bausteine kennen und kann sie dann irgendwann sinnvoll kombinieren. Zum Erstellen des eigenen Bahnhofs habe ich festgestellt, dass sich die Dateien faktisch nur “zusammen” entwickeln lassen und man sich vorher auf Papier (ist wohl das einfachste) folgendes klar machen muss:
· Wie heissen die Weichen?
· Wie heissen die einzelnen Gleisabschnitte bzw. Gleise
· Wie heissen die Ziele (Targets) der einzelnen Fahrstrassen und wo liegen die?
· Wie heissen die Signale (auch wenn sie nur virtuell da sind) und wo liegen sie?
· Wie heissen die Signale an den Blockstellen oder Bahnhöfen, die mit im Segment vor oder hinter uns liegen?
· Welche Sensoren für Weichen und Gleisbesetztmeldung gibt es?
· Welche Fahrstrassen-Segmente (Base Route) gibt es von wo nach wo?
· Welche Fahrstrassen (aus Base Route‘s) gibt es von wo nach wo?
Also ohne eine Art Bahnhofsdatenblatt geht hier schnell mal eben nichts mehr. Machen wir uns nichts vor – wir bilden hier die Anlagenautomation eines Bahnhofs in Annäherung an das Original nach.
Jetzt möchte ich aufzeigen, wie sich das ganze Entwickeln lässt. Dazu zeige ich auf, wie meine Betriebsstelle von Ihren Dateien aufgebaut ist.
Verschiedene Program-Module bzw. Packages aus Elekdra lesen die unterschiedlichen XML Dateien aus und beziehen von dort Ihre Daten. Man könnte auch alles in eine einzige grosse XML Datei schreiben aber das wird dann sehr schnell sehr unübersichtlich. Es ist viel einfacher, wenn man Dateien für einen bestimmten Typ definiert.
Bei mir in Bennewitz & Wichern schaut das ganze so aus:
- 100_Bennewitz-Wichern_Configuration.xml
- 200_Bennewitz-Wichern_etis60.xml
- 200_Bennewitz-Wichern_Graphics.xml
- 300_Bennewitz-Wichern_Baseroutes.xml
- 310_Bennewitz-Wichern_Routes.xml
- 400_Bennewitz-Wichern_ZNA.xml
- 500_Bennewitz-Wichern_TCP _TCP_Block.xml
Wer genau hinschaut, stellt fest, das es zwei Dateien mit 200 gibt. Eine endet auf „Graphics“, die andere auf „etis60“ – Hier sind zwei verschieden Typen von Stellwerken (siehe oben) definiert. Eines in ELUI und eines im ETIS60 Client.
Grundbausteine: Gleise & Weichen
Ich habe mir einen Grundsätzlichen Aufbau festgelegt. In der Datei „100_Bennewitz-Wichern_Configuration.xml“ sind die Elemente wie folgt gegliedert:
Zeile 1-6: XML Präambel und Kommentare, was diese Datei einhält.
Zeile 7: Das Start-Tag <interlocking>
Zeile 10-42: Die Grundsätzliche Konfiguration wie Ports, Namen und globale
Parameter
Zeile 44-164: Definition aller Weichen
Zeile 166-265: Definition aller Gleise
Zeile 270-290: Definition aller Fahrziele innerhalb der Betriebsstelle
Zeile 291-293: Definition der Einfahrtsignale
Zeile 294-296: Definition der Vorsignale
Zeile 298: Definition des Ausfahrtsignals
Zeile 300-303: Definition der Rangierverbotsignale
Zeile 304-308: Definition der Zwergsignale
Zeile 309-432: Definition der Virtuellen Rangiersignale
Ab Zeile 434: Definition der Stromfühler Sensoren und der Bedingungen, die
sie Auflösen.
Es braucht also – mit Kommentaren zur Dokumentation so gegen 500 Zeilen sauberen XML-Codes um nur die Basics von Bennewitz & Wichern zu definieren.
Damit wird schnell klar, dass hier mehrere Tausend Zeilen XML Code erstellt werden müssen. Am besten kopiert man sich aus einem Beispiel die verschiedenen Elemente heraus und fügt sie in die eigene Datei ein.
Unter der URL:
http://fremo-stw.sourceforge.net/elekdra/userdocs/debug_version/index.en.html#Elekdra
Findet man alle Tags, die pro Package in einer XML Datei vorkommen können.
Die Datei beginnt mit dem „globalen“ Tag
<interlocking>
Dieser Tag steht nach ein paar Zeilen Kommentar und wird nicht direkt wieder abgeschlossen. Also wird alles bis </interlocking> gelesen.
Der nächste Abschnitt dient der Grundsätzlichen Konfiguration:
<!-- Grundsaetzliche Konfigurationen -->
<elekdra.configurations>
<!-- Name, Kurzname und IP-Port des Bhf -->
<stationname>Bennewitz_Wichern</stationname>
<stationShort>BWW</stationShort>
<stationport>9090</stationport>
<!-- Weichenverhalten und Weichenmodi-->
<!-- TQ: Was ist "simple switch mode"??? -->
<simple_switch_mode>false</simple_switch_mode>
<!-- Anzahl der Weichen die gleichzeitig gefahren werden koennen - wichtig für die Stromversorgung -->
<maxsimultanemotorson>7</maxsimultanemotorson>
<!-- Fahrstrassenverhalten und Weichen- und Signalbeeinflussung -->
<routecanswitchturnout>true</routecanswitchturnout>
<routecanclearsignal>true</routecanclearsignal>
<routeclearsstarttrack>true</routeclearsstarttrack>
<routeoccupiestargettrack>true</routeoccupiestargettrack>
<routesetslcss>false</routesetslcss>
<!-- Listen und Zugnummern -->
<listen_time>true</listen_time>
<elekdra_gives_virtual_train_numbers>true</elekdra_gives_virtual_train_numbers>
<!-- Blockverhalten und Weichen- und Signalbeeinflussung -->
<blockblocksroute>true</blockblocksroute>
<blockclearssignal>true</blockclearssignal>
<turnout_send_extended_state>false</turnout_send_extended_state>
<!-- IP-Adresse und IP-Port des LocoNet Buffer Servers -->
<lbserverip>127.0.0.1</lbserverip>
<lbserverport>1234</lbserverport>
</elekdra.configurations>
Anschliessend geht es mit den Weichen weiter:
<!-- xxxxxxxxxxxxxxxxxxx Start WEICHEN B&W xxxxxxxxxxxxxxxxxxxxxx -->
<elekdra.turnout>
<!-- W1 = Einfahrtsweiche von Hauptstrecke - Grundstellung GRADE auf der Hauptstrecke - Lage auf Modul 1 -->
<name>W1</name>
<!--Weichenverschluss -->
<hastrafflock>true</hastrafflock>
<selflocking>false</selflocking>
<!--Loconet bezogene Daten... -->
<loconet>
<!-- Definition: Weichen Adressen sind immer im 100er Bereich und starten von hinten mit 01, 02, 03... -->
<lnaddress>101</lnaddress>
<protocol>sw_req1</protocol>
<inverted>false</inverted>
<resend_sec>30</resend_sec>
</loconet>
</elekdra.turnout>
Wenn alle Weichen definiert sind, kommen die Gleise dran.
<!-- xxxxxxxxxxxxxxxxxxx Start Gleise B&W xxxxxxxxxxxxxxxxxxxxxx -->
<elekdra.track>
<name>G114</name>
<hastrafflock>true</hastrafflock>
</elekdra.track>
Fahrziele
Weichen und Gleise sind noch „verständlich“. Im Folgenden habe ich dann die sogenannten Fahrziele – also Targets - definiert. Ein Fahrziel ist ein Punkt auf dem Gleis zu dem eine Zugbewegung oder Lokfahrt gehen soll.
<!-- xxxxxxxxxxxxxxxxxxx Start Fahrziele B&W xxxxxxxxxxxxxxxxxxxxxx -->
<elekdra.target> <name>rt_115L</name> </elekdra.target>
<elekdra.target> <name>rt_115R</name> </elekdra.target>
Ich habe mir für die Targets eine Notation ausgedacht.
rt bedeutet Route-Target getrennt mit einem „_“. Danach kommt das Gleis „115“ aus meinem Gleisplan. „L“ und „R“ bedeuten Links oder Rechts. Die genaue Position wird dann mit dem User-Interface bzw. dessen Dokumentation festgelegt.
Als bedeutet „rt_115L“, dass ich auf das linke Ende von Gleis 115 einfahren möchte.
Signale
Weiter geht es mit den Signalen.
<!-- xxxxxxxxxxxxxxxxxxx Start Signale B&W xxxxxxxxxxxxxxxxxxxxxx -->
<elekdra.signal>
<name>SIG_14P</name>
<loconet>
<!-- Definition: Signal Adressen sind immer im 200er Bereich und starten von hinten mit 01, 02, 03... -->
<lnaddress>201</lnaddress>
<protocol>opc_se</protocol>
<inverted>true</inverted>
<resend_sec>1</resend_sec>
</loconet>
</elekdra.signal>
Das Signal hat wie auch die Weichen eine Loconet Adresse, also diejenige Adresse, die der Hardware zugewiesen worden ist.
Sensoren und Rückmelder
Zum Schluss werden noch die Sensoren definiert. Während Weichen und Signale zu den Aktoren gehören, brauchen wir ggf. Sensoren, um Zustände überprüfen zu können.
<elekdra.sensor>
<name>Sensor_W1</name>
<loconet>
<lnaddress>301</lnaddress>
<protocol>sw_rep1</protocol>
<inverted>false</inverted>
</loconet>
<triggered_event>
</triggered_event>
<changing_event>
<occstate>
<name>W1</name>
<delay_sec>1</delay_sec>
</occstate>
</changing_event>
<rising_event>
<signalstop>
<name>ES_B</name>
<delay_sec>1</delay_sec>
</signalstop>
</rising_event>
<falling_event>
<signalstop>
<name>AS_B</name>
<delay_sec>1</delay_sec>
</signalstop>
</falling_event>
<falling_event>
<routecleartarget>
<name>224</name>
<delay_sec>1</delay_sec>
</routecleartarget>
</falling_event>
</elekdra.sensor>
Ganz am Ende der Datei wird das Interlocking-Tag wieder abgeschlossen.
</interlocking>
Jetzt haben wir alle Komponenten definiert, mit denen wir eine Betriebsstelle beschreiben können. Sehen können wir aber noch nichts. Es gibt bisher nur die Beschreibungen der Komponenten. Es fehlt nun die Definition des Stellwerks bzw. des Stelltisches.
Stellwerkstyp für ELUI
Elekdra verwendet ein Sub-System namens Elui zur Abbildung von Stelltischen. Es existieren verschiedenste Implementationen von Stellwerken und Stelltischen. Zwei davon möchte ich kurz darstellen und aufzeigen, wie man die Stellwerkstische definieren kann.
Auf dem Screenshot erkennt man den Gleisplan von B & W. Auf dem Gleisplan kann man nun auch einige weitere Elemente erkennen. In Gelb die sogenannten Verschubsignale. Ich habe die gleichgesetzt mit den Route-Targets als den Fahrzielen.
Weiterhin erkennt man die Weichen, Gleise und in Rot die eigentlichen Signale wie z.B. das Vorsignal 14P ganz links oben.
Des Weiteren in Schwarz mein Stellwerk (der Halte Punkt fehlt) und die beiden Blocksymbole an der Hauptstrecke, die oben durch geht.
Alle definierten Gleise, Weichen, Signale und Fahrziele (Verschubsignale) müssen nun von uns einzeln platziert werden. Leider existiert kein grafischer Editor, der das Zeichnen von einem Gleisplan erlauben würde. Andererseits gibt das manuelle Vorgehen auch einigermassen Flexibilität. Auf die Bedienung der Bedieneroberfläche gehe ich separat ein.
Eigentlich ist es recht einfach.
In der Datei „200_Bennewitz-Wichern_Graphics.xml“ sind die Informationen für Elui hinterlegt.
Zeile 1-2: XML Präambel und Kommentare, was diese Datei einhält.
Zeile 3: Das Start-Tag <graphics>
Zeile 7-22: Die Grundsätzliche Konfiguration und globale
Parameter
Zeile 24-33: Definition des Elui-Fensters, Ports, Ip-Adresse und Fenster Parameter
Zeile 35-388: Position aller Gleise
Zeile 390-516: Position aller Weichen
Zeile 517-824: Position aller Signale
Zeile 828-870: Position der Block-Symbole
Zeile 873: Das End-Tag </graphics>
Schaut man sich den ersten Definitionsblock an, werden hier lediglich Parameter vergeben, wie die Oberfläche reagieren soll, oder wie schnell Grafik Update Intervalle sind.
<elui.configurations>
<intervall_update_layer>500</intervall_update_layer>
<dynamicrouting>true</dynamicrouting>
<highlight_elements>false</highlight_elements>
<enablesignalclear>true</enablesignalclear>
<enable_sounds>false</enable_sounds>
<fixmeldungsverwalter>true</fixmeldungsverwalter>
<autofocusmeldungsverwalter>true</autofocusmeldungsverwalter>
<switch />
<path_sound_mv_request />
<path_sound_mv_fail />
<path_sound_mv_operation />
<path_sound_mv_system />
<path_sound_info />
<wait_sec_reconnect>1</wait_sec_reconnect>
</elui.configurations>
Dazu kommt noch die Möglichkeit, Sounddateien zu definieren, die bestimmte Aktionen mit Ton hinterlegen. Davon habe ich aber keinen Gebraucht gemacht.
Die Fensterdefinition ist schon wesentlich interessanter und erstreckt sich über die gesamte Datei (daher fehlt hier das End-Tag).
<elui.window>
<name>Bennewitz_Wichern WUst (BWW)</name>
<type>detail</type>
<open>true</open>
<ip>192.168.10.49</ip>
<port>9090</port> <!--Urs: 51401-->
<pos_x>1</pos_x>
<pos_y>1</pos_y>
<size_x>1075</size_x>
<size_y>400</size_y>
Oben angefangen vergibt man den Namen. Vorsicht mit Umlauten! In XML lassen sich direkt KEINE Umlaute darstellen.
Xoxoxoxoxo XML Umlaute und TESTEN wie das mit ELUI geht xoxoxoxoxoxo
Was die Tags <type> und <open> bedeuten weiss ich im Moment nicht.
Der Tag <ip> verweist auf die IP-Adresse, auf der unser Elekdra läuft. Alternativ kann man sich auch den eigenen Rechner Namen hier eintragen. Auf das Thema „Elekdra im Arrangement mit DNS“ gehe ich gesondert weiter unten ein. Es würde hier den Rahmen sprengen.
Der Tag <port> definiert den Port, auf dem Elekdra lauscht. Beide Tags sind unbedingt notwendig.
<pos_x> und <pos_y> definieren, wo mein Elekdra Fenster anfängt, also den „Null-Punkt“.
Fensterdefinition ELUI
Wie man sehen kann habe ich Fenster von 1075 x 400 Pixeln für meine Betriebsstelle definiert. Das ist meiner Vorliebe und meiner Hardware geschuldet. Moderne System bieten Auflösungen von über 1600 x 1200 Pixeln auf einem grossen Monitor aber für die Modellbahnerei werden es sicher ältere Systeme sein. Wahrscheinlich hat man eine Auflöung von 1200 x 1024 zur Verfügung. Mein Fenster ist als etwas schmaler und deutlich kleiner.
Für diese Definition verwendet man den Tag <size_x> und <size_y>.
Wenn ich die obigen Parameter mit dem Tag </elui.window> abschliesse und danach Elui starte bekomme ich folgendes Fenster zu sehen:
Monitor Testbild
Lässt sich das Raster für den Bildschirm darstellen. Dieses Raster brauchen wir unbedingt, um die Position der einzelnen Elemente auf dem Gleisplan nachbilden zu können. So können wir einfach einen Screenshot oder Bildschirmaustruck machen und mit Faserschreiber unseren Gleisplan darauf skizzieren und haben am Ende alle Parameter beisammen.
Das Raster sieht so aus:
Ohne Raster verkommt das Definieren zu einem frustrierenden Ratespiel.
Der komplette Gleisplan von B & W sieht im Raster/Testbild Modus wie folgt aus:
Man erkennt hier deutlich, wie einige Gleise unterteilt sind, um in verschiedene Bereiche einfahren zu können. Diese Unterteilung dient der Logik und die muss man sich leider selbst erarbeiten. Für einen ersten Wurf macht es vielleicht Sinn, jedes Gleis aus 3 Segmenten anzulegen.
Hier mal vergrössert das Gleis G2 zwischen den Weichen W4 und W8:
Damit kommen wir auch schon zu der Definition von Gleisen und Weichen. Hier die Definition der Weiche W4 und der Definition von Gleis G2. Zuerst alle Gleise:
<graphic>
<type>track</type>
<name>G2links</name>
<label>false</label>
<display>G2</display>
<coordinate>
<axle_x>46</axle_x>
<axle_y>5</axle_y>
</coordinate>
<coordinate>
<axle_x>55</axle_x>
<axle_y>5</axle_y>
</coordinate>
</graphic>
<graphic>
<type>track</type>
<name>G2mitte</name>
<label>true</label>
<display>G2</display>
<coordinate>
<axle_x>55</axle_x>
<axle_y>5</axle_y>
</coordinate>
<coordinate>
<axle_x>77</axle_x>
<axle_y>5</axle_y>
</coordinate>
</graphic>
<graphic>
<type>track</type>
<name>G2rechts</name>
<label>false</label>
<display>G2</display>
<coordinate>
<axle_x>77</axle_x>
<axle_y>5</axle_y>
</coordinate>
<coordinate>
<axle_x>88</axle_x>
<axle_y>5</axle_y>
</coordinate>
</graphic>
Gleise sind Grafikelemente. Daher zunächst das <graphic> Tag. Danach kommt der <type> in diesem Fall „Track“ für Gleis. Danach gibt es den internen Namen – bei mir nach der Notation „Gleislinks/mitte/rechts“ – hier „G2links“, „G2mitte“, „G2rechts“. Damit der Plan nicht zu voll wird, kann man entscheiden, ob das Label erscheint oder nicht (hier mit <label>false</label> ausgeschaltet). Der Displayname lautet G2 gesetzt im Tag <display>. Danach die Koordinaten. Die vier Werte für die beiden Koordinaten lassen sich aus dem Raster auslesen. Wer in das Raster reingemalt hat, hat es jetzt leichter und kann einfach ablesen.
<coordinate>
<axle_x>88</axle_x>
<axle_y>5</axle_y>
</coordinate>
Eine Koordinate wird aus X- und Y-Achse gebildet und muss abgeschlossen sein!
Das Grafikelement wird mit dem entsprechenden End-Tag </graphic> abgeschlossen.
Relativ viel Aufwand für einen einzigen Strich, aber ein Grafik-Editor würde auch nichts anderes Aufschreiben und man müsste dann in Pop-Up Fenstern die Namen etc. angeben. So kopiert man sich einen Block und ändert ein paar Zahlen.
Eine besondere Art eines Gleises ist der Prellbock. Er wird wie folgt gebildet:
<graphic>
<type>trackend</type>
<name>d.c.</name>
<coordinate>
<axle_x>70</axle_x>
<axle_y>8</axle_y>
</coordinate>
</graphic>
Um die Weiche W4 zu definieren geht wir wie folgt vor:
<graphic>
<type>turnout</type>
<name>W4</name>
<display>W4</display>
<mirror_x>true</mirror_x>
<mirror_y>false</mirror_y>
<coordinate>
<axle_x>44</axle_x>
<axle_y>4</axle_y>
</coordinate>
<parameter>
<type>longer</type>
<bool>true</bool>
</parameter>
</graphic>
Der <type> ist turnout, Name und Displayname sind wie oben beschrieben definiert. Die beiden Mirror Tags geben an, wie die Weiche in Bezug auf das Stammgleis liegt und ob sie ggf. um eine der Achsen gespiegelt werden muss.
Die Grundstellung einer Weiche ist also diejenige, wo unten waagerecht das Stammgleis durchläuft und das Abzweig nach oben rechts abzweigt. Die Weiche W4 ist nur an der X-Achse gespiegelt (<mirror_x>true</mirror_x>) daher zeigt die Weiche mit dem Abzweig nach rechts unten.
Die Lage des Herzstücks wird mit den Koordinaten angegeben. Diese werden wie auch beim Gleis definiert.
Der Abschnitt <parameter> steuert ob die Weiche im Abzweig verlängert dargestellt werden soll – mit Hilfe des Tags <type>longer</type> wird das erreicht. Der Tag <bool>true</bool> weisst Elui an, die Gleise verbunden darzustellen.
Welche Parameter im <graphic> Tag erlaubt sind, kann man hier herausfinden:
Leider ist die Darstellung auf der Webseite nicht so klar gelöst und die Erläuterungen sind etwas sparsam gehalten.
Nach Gleisen und Weichen werden – so vorhanden – als nächstes die Signale und Verschubsignale definiert.
Ein Verschub- oder Rangiersignal bzw. ein Fahrziel sieht wie folgt aus:
Es wird so gebildet:
<graphic>
<type>signal_shunt</type>
<name>rt_G2L</name>
<mirror_y>false</mirror_y>
<coordinate>
<axle_x>28</axle_x>
<axle_y>5</axle_y>
</coordinate>
</graphic>
Die Unterschiede zwischen beiden Definitionen ist der Inhalt des <type> Tags. Zum einen gibt es das signal_mandatory und das signal_shunt.
Das Gebäude für das Stellwerk wird ebenfalls einfach als Grafikelement gebildet:
<graphic>
<type>house</type>
<name>Stellwerk</name>
<coordinate>
<axle_x>30</axle_x>
<axle_y>5</axle_y>
</coordinate>
<coordinate>
<axle_x>36</axle_x>
<axle_y>5</axle_y>
</coordinate>
</graphic>
Welche Typen hier erlaubt sind, wird leider aus der Dokumentation nicht ganz klar. Hier muss ich bei Gelegenheit in den Source Code schauen.
Der Streckenblock wird wie folgt definiert:
<graphic>
<type>block</type>
<name>G115</name>
<display>G115</display>
<label>true</label>
<displayonly>true</displayonly>
<coordinate>
<axle_x>125</axle_x>
<axle_y>2</axle_y>
</coordinate>
<mirror_y>false</mirror_y>
<mirror_x>false</mirror_x>
<parameter></parameter>
<ip>127.0.0.1</ip>
<port>4115</port>
</graphic>
Das Besondere am Streckenblock ist, dass er mit der Nachbar-Betriebsstelle oder Bahnhof kommunizieren muss. Die IP-Adresse ist wahrscheinlich diejenige des Block-over-TCP Servers und dessen Port. Da auf meinem Beispiel alles auf einem PC läuft ist hier mit 127.0.0.1 der sogenannte „localhost“ angegeben.
Wenn alles korrekt definiert ist, können wir die XML Datei speichern und Elekdra und Elui starten. (Start-Scripte siehe Anhang).
Wenn wir uns eingelogt haben, sieh es wie folgt aus:
Halt- einen Unterschied gibt es. Auf der Abbildung ist eine Fahrstrasse gezogen und das entsprechende Gleis ist gelb hinterlegt. Fahrstrassen behandeln wir im nächsten Kapitel.
WIP - Work in Progress
Nach dem die Sommerpause durch ist und die Arbeit uns wieder hat, hier mal die To-Do Liste für die nächsten Wochen:
- Fahrstrassen
- Betrieb auf meiner Betriebsstelle
- Start-Scripte
- Abhängigkeiten & Automation
- XML Scripting (Funktionen in XML)
- Blocksicherung (Block über TCP)
- Zugnummernserver
- Vorbereitung für ein Treffen - Meine Betriebsstelle im Arrangement
- Entwicklung
- Aufsetzen einer Entwicklungsumgebung
- Abgleich der Sourcen von SVN / Sourceforge
- Fehler melden