DigitaleBahn

1 Einführung

Die digitale Steuerung der Modelleisenbahn wird, unabhängig von der gewählten Spur und der Anlagengröße, heute immer mehr zum Standard. Weg von dicken Kabelbäumen, einfachen Steuerungen mit viel zu vielen Relais und teurer analoger Technik! Einfach alle aktiven Komponenten, gleich ob Lok, Weichenantrieb oder Relais über zwei einfache Drähte oder, noch besser, direkt über das an den Schienen anliegende Signal steuern. Wie viel Spaß kann eine nach diesem Prinzip immer wieder schnell aufgebaute LGB Gartenbahn machen! Keine weitere Verkabelung, nur ein Anschluss für die Stromzuführung wird benötigt – und los geht’s.

Auf dem Markt sind eine Vielzahl von digitalen Steuerungssystemen verfügbar. Die Idee ist eigentlich immer ähnlich: In einer Zentrale werden die Steuerbefehle eingegeben, und über einen Verstärker (Booster) an die Modellbahnanlage gegeben. Dort empfangen in den Loks und an anderen aktiven Komponenten eingebaute Decoder diese Signale und führen die „bestellten“ Aktionen aus.

Der PC wird oft als zusätzliche Komponente in ein solches Digitalsystem eingebaut, z.B. zur grafischen Darstellung von Anlagenzuständen oder auch als grafische Oberfläche zur Eingabe von Steuerbefehlen. Kaum zu glauben – aber bei einigen Digitalsystemen muss dafür sogar noch ein Interface gekauft werden! Netter Versuch...

Warum erzeugt jetzt der PC eigentlich nicht die Steuersignale direkt? Technisch gesehen ist dies kein Problem. Die Protokolle sind bekannt und die Ausgabe der digitalen Steuersignale erfolgt dann z.B. über die serielle Schnittstelle an den Booster (Bild 1.1). Eine Zentrale wird nicht mehr benötigt. Bingo!

Bild 1.1.: DDL Standardkonfiguration

Für die Betriebssysteme Windows und Linux existieren „Digitalprojekte“, die genau diese Aufgabenstellung gelöst haben. Stellvertretend soll hier das auf dem freien Betriebssystem Linux basierende „Digital Direct for Linux“ (DDL) [1] vorgestellt werden. Informationen zu einem Windows basierten Projekt DDW Server (Digital Direct for Windows) finden Sie unter [2], [4].

1.1 Das DDL Projekt

Die Leistungsdaten von DDL sind schon beeindruckend (Tabelle 1). Für den Modellbahner mit grundlegenden PC- und Linuxkenntnissen ergeben sich aber eine Reihe von speziellen Vorteilen, die in dieser Vielzahl und Kombination kaum von fertigen Zentralen geboten werden können:

•DDL ist ein Open-Source-Projekt und steht unter der GNU Public License (GPL). Die DDL Software darf somit frei benutzt und auch frei weitergegeben werden. Im Klartext: Diese Software, wie auch das Betriebssystem Linux, kostet nichts! Und alle Programme stehen für die eigene Weiterentwicklung im Sourcecode zur Verfügung.
•Die Hardwareanforderungen von Linux und DDL sind sehr niedrig. Es reicht tatsächlich schon ein 386er PC – für die aber irgendwann sicherlich gewünschte grafischen Oberfläche sollte es aber schon ein Pentium PC sein. Neue Hardware braucht in der Regel nicht gekauft werden. Ein preiswerter, gebrauchter PC reicht.
•DDL ist für die Steuerung einer kleinen Anlage ebenso geeignet wie für Großanlagen. Bei Bedarf können sich sogar mehrere PCs die Arbeit teilen, da DDL nach dem Client-Server-Prinzip aufgebaut ist. Mehrere PCs werden über ein TCP/IP-Netzwerk verbunden und können gemeinsam arbeiten (Bild 1.2).
•Zur eigentlichen Steuerung der Modellbahn stehen viele Oberflächen (DDL Client Programme) zur Verfügung. Angefangen von der direkten Befehlseingabe per Kommandozeile über eine einfache grafische Oberfläche zur Steuerung von Lokomotiven und Weichen bis hin zu einem dem Vorbild sehr weit entsprechenden Gleisbildstellwerk steht eine große Auswahl zur Verfügung. Natürlich können Erweiterungen aus selbst programmiert werden.
•Mit ddsh und rcsh stehen zwei Linux Shells für DDL zur Verfügung, innerhalb derer auch komplizierte Funktionsabläufe über Skripte automatisiert werden können . Das ursprünglich zum Projekt DDL gehörende ddsh wird nicht mehr weiterentwickelt.

Bild 1.2.: DDL Server und Clients im TCP/IP Netzwerk.

Was wird jetzt tatsächlich an Hardware und Software benötigt, um eine Digitalsteuerung mit DDL aufzubauen?

Der PC kann tatsächlich ein für die Büro- (oder Spiel-) Arbeit schon lange nicht mehr ausreichender Pentium PC so ab 150 MHz Taktfrequenz sein. Die Grafikkarte sollte mindestens 800x600 Punkte Auflösung bieten, an Schnittstellen zur Außenwelt reicht ein serielles Interface zum Anschluss eines Boosters. Sollen Rückmeldungen (S88-Rückmeldebus) verarbeitet werden, werden diese über eine parallele Schnittstelle (Druckeranschluss) und ein kleines, leicht selbst aufzubauendes Interface [3] eingelesen.

Die Verstärkung des von der seriellen Schnittstelle abgegebenen digitalen Steuersignals erfolgt über einen geeigneten Booster. Hier können nahezu alle auf dem Markt erhältlichen Fertigbausteine (z.B. Märklin 6604, Märklin 6015/17 ) oder Eigenbauten auf Basis von Bausätzen verwendet werden, wie sie z.B. preiswert von der Firmen Conrad und Völkner angeboten werden.

Für die Auswahl der Decoder gibt es dann (vergleiche Tabelle 1) kaum noch Einschränkungen: eigentlich kann fast alles angesteuert werden, was auf dem Markt in Form von Bauätzen oder Fertigbausteinen verfügbar ist.

Das für den PC benötigte Betriebssystem ist Linux. In den meisten Fällen wird hier eine fertige Distribution wie RedHat 7.3 oder SuSE 8.0 zum Einsatz kommen. Die Installation ist gar nicht mehr so aufwendig und kann auch mit geringen Vorkenntnissen erfolgen. In der Regel stehen sehr gute „Assistenten“ zur Verfügung, die die für DDL notwendige Linux Standardinstallation erleichtern.

Eines sollte aber auf jeden Fall berücksichtigt werden: Die Arbeit mit dem Betriebssystem Linux erfordert mehr und vor allem tiefer in das eigentliche Betriebssystem gehende Kenntnisse als diese im Umgang mit einem Microsoft Windows basierten System notwendig sind. Die dort durch ausgefeilte grafische Oberflächen und stets hilfsbreite „Assisenten“ schon fast vergessene Arbeit in der Kommandozeile steht unter Linux plötzlich wieder im Vordergrund – vergleichbar mit der vor vielen Jahren noch üblichen DOS Oberfläche der ersten PCs.

1.2 Das Protokoll SCRP

Das DDL Projekt von Torsten Vogt basiert auf dem Simple Railroad Command Protocol ( SCRP ) in der (noch) aktuellen Version 0.7.3. Eine neuere Protokollversion (0.8.0) ist bereits fertig, wird aber noch nicht von der hier vorgestellten Software unterstützt (die vollständige Dokumentation zu beiden Protokollversionen finden Sie in [4] und auf der Heft-CD im Verzeichnis /DDL/scrp).

Das SRCP ist ein TCP basiertes Internetprotokoll zur Steuerung und Programmierung von digitalen Modelleisenbahnanlagen. Beschrieben wird ein Befehlssatz zur Client-Server-Kommunikation zwischen Serverprozessen zur Steuerung von digitalen Modelleisenbahnen und deren Clients. Serverprozesse sind entweder Software Signalgeneratoren oder Treiber für Hardware Interfaces. Clients sind typischerweise Steuerungsprogramme.

In der Einleitung zu SCRP 0.7.3 heißt es zu Idee und Funktion dieses Protokolls:

Ein SRCP Server dient dazu, Informationen von einer Modellbahnanlage einzulesen und entsprechenden Clients in einem IP Netzwerk verfügbar zu machen. Im Gegenzug führt er Befehle der Clients auf der Modellbahnanlage aus. Ein SRCP Server pflegt keinen Anlagenstatus (Weichenstellung etc.) und verfügt nicht über Informationen über die Anlage selbst (Gleispläne, Verdrahtung usw).

Hauptzweck ist es, verschiedene Digitalsysteme einheitlich ansprechen zu können. Ein Client muß sich nicht mehr mit den Details einer Digitalsteuerung auseinandersetzen.

Der SRCP-Befehlssatz besteht aus Kommandos, die direkt das Verhalten des Servers betreffen, und aus Kommandos, die für die Dekoder der Modellbahnanlage bestimmt sind. Weiterhin werden Kommandos, die die Verarbeitung von Rückmeldungen betreffen spezifiziert.

Der Server kann über eigene Informationgeneratoren wie ein Zeitgebermodul verfügen, das alle Clients mit einer einheitlichen Modellzeit versorgt.

Im DDL Projekt werden diese Funktionen durch ein Linux-Programm mit dem Namen erddcd erfüllt, die dazu gehörende Konfigurationsdatei ist erddcdrc. Das Programm läuft als Hintergrundprozess (Daemon) und wartet als Serverprozess darauf, Anfragen von einem oder mehreren Clientprozessen zu bearbeiten (siehe Bild 1.2) und dann die . entsprechenden Steuersignale an der seriellen Schnittstelle zu erzeugen. Da SCRP auf TCP basiert, brauchen dabei Server- und Clientprozesse noch nicht einmal auf dem gleichen PC zu laufen: alle Funktionen können über das TCP/IP-Netzwerk genutzt werden!

Bleibt dann eigentlich nur noch die Frage, ob für einen solchen Server auch leistungsfähige Client Programme zu Verfügung stehen. Und ob! Von der Kommandozeile über einfache grafische Oberflächen bis bin zum komplexen Gleisbildstellwerk ist eigentlich fast jeder Wunsch erfüllt. Per Shellskript (mit den schon erwähnten ddsh / rcsh) können komplizierte Funktionsabläufe vollständig automatisiert werden. Und der erfahrene Programmierer schreibt sich seine spezielle Anwendung auf Basis des ja vollständig bekannten SCRP oder nach Analyse des Programmcodes.

2 Die Hardware

Die grundlegende Hardwarestruktur eines digitalen Steuerungssystems wurde im ersten Kapitel schon kurz vorgestellt. Hier sollen nun die notwendigen Komponenten genauer betrachtet und, wo notwendig, auch beispielhaft gezeigt werden, was an Technik sinnvoll einzusetzen ist.

2.1 Der PC

Einen neuen PC nur für den Einsatz als DDL Server zu kaufen ist wirklich kaum sinnvoll und sollte wirklich nur bei sehr großen Anlagen ernsthaft in Erwägung gezogen werden. DDL als vorübergehende Zusatzaufgabe für einen sowieso für andere Zwecke vorhandenen PC oder als echte Herausforderung für einen ältern, sonst kaum noch nutzbaren PC – das ist ein guter Ansatz. Da als Betriebssystem Linux zum Einsatz kommen wird, wird es vielleicht zweckmäßig sein, eine weitere Festplatte in den PC einzubauen, die dann dieses Betriebssystem als zweite Bootoption zur Verfügung stellt (dies als „Workaround“ für die hartnäckigen Windows Benutzer). Die Aufteilung (Partionierung) und damit gemeinsame Nutzung einer einzelnen Festplatte ist natürlich auch möglich.

Benötigt werden eine serielle und eine parallele Schnittstelle. Dies sollte kein Problem sein, selbst wenn der PC noch eine Maus an der ersten seriellen Schnittstelle erfordern sollte. Soll später mit einer grafischen Oberfläche gearbeitet werden, sollte die Bildauflösung schon bei 1024x768 Bildpunkte liegen. Grundsätzlich reicht aber auch schon eine Textoberfläche völlig aus.

2.2 Der Booster

Der Booster ist das Verbindungsglied zwischen dem PC und der Modellbahnanlage. Er verstärkt das über die serielle Schnittstelle abgegebene digitale Steuersignal und liefert einen Ausgangsstrom von 3 Ampere oder mehr.

Für das DDL Projekt können fast alle auf dem Markt verfügbaren Booster eingesetzt werden, gleich ob es sich um Fertiggeräte, Bausätze oder Selbstbauprojekte handelt. Exemplarisch sollen anschließend auch zwei Beispiele für geeignete Geräte folgen.

Für DDL geeignet sind aber natürlich auch „Markengeräte“ wie die Märklin Delta Control Unit 6604. Erwähnenswert sind auch viele Eigenbauten, wie sie z.B. von Dr. Froitzheim [7] oder Dr. König [8] im Internet veröffentlicht worden sind.

2.2.1 Einschaltsignal und Kurzschlussanzeige

Einige Booster benötigen ein Einschaltsignal oder können dem Signalgenerator einen Kurzschluss anzeigen. Der DDL Daemon erddcd kann beide Signale bedienen, dazu werden die Anschlüsse DTR und DSR der seriellen Schnittstelle genutzt.

DTR ist nach dem Start von erddcd inaktiv (-12V) und wird erst dann aktiv (+12V) gesetzt, wenn der Digitalstrom eingeschaltet wird. Wird der Digitalstrom ausgeschaltet, wird DTR wieder auf inaktiv (-12V) gesetzt. Über diese Steuerleitung kann ein Booster ein- und ausgeschaltet werden.

Die Steuerleitung DSR wird ständig von erddcd überwacht. Im normalen Betriebsmodus muss der Booster DSR auf inaktiv (-12V) setzen. Im Falle eines Kurzschlusses wechselt der angeschlossene Booster DSR auf aktiv (+12V). erddcd erkennt dann den Kurzschluß und beendet nach einer einstellbaren Reaktionszeit den Digitalstrom. DTR wird dann auf inaktiv gesetzt.

Die Kurzschlussüberwachung muss beim Aufruf von erddcd mit den Parametern -c oder -C eingeschaltet werden. Verwendet man -C wird die DSR-Leitung invers behandelt, d.h. der Booster muß DSR ständig auf +12V halten, nur im Falle eines Kurzschlusses muss er DSR auf -12V setzen. Beispiel:

# ./erddcd -c 500000

aktiviert die Kurzschlussüberwachung. Die Reaktionszeit ist 0,5 sec (500000 msec).

2.2.2 Conrad Bausatz 212075

Von der Firma Conrad werden mehrere Booster als Bausatz angeboten. Ein schon älteres Modell ist unter der von der Firma Tams (http://www.tams-online.de/) hergestellte Booster mit der Conrad Bestellnummer 212075. Der Preis (ohne Trafo und Gehäuse) liegt bei ca. 40 €. Der Booster ist auf einer Platine von 100x160 mm aufgebaut und liefert einen maximalen Ausgangsstrom von 3 Ampere. Insgesamt ein einfach aufzubauendes und bei mir seit langer Zeit zuverlässig funktionierendes Gerät (Bild 2.1).

Bild 2.1.: Selbstbau Booster mit geöffnetem Gehäuse

Der Anschluss an den PC erfordert lediglich zwei Leitungen (Tabelle 2).

Die Ausgangsspannung dieses Boosters wird über ein Relais geschaltet, dass erst nach einem Tastendruck anzieht. Im Kurzschlussfall wird der Booster über dieses Relais automatisch von der Anlage getrennt. Ein Einschaltsignal wird nicht benötigt. Ein Kurzschlusssignal wird nicht erzeugt.

2.2.3 Selbstbauprojekt Bogobit

Ein interessantes Selbstbauprojekt gibt es bei Siegfried Grob [6]. Die Eckdaten dieses Boosters sind:

•Belastbar ca. 5-6 A bei guter Kühlung der Leistungstransistoren.
•Kurschlusserkennung und Abschaltung. (mit Rückmeldung an erddcd).
•Optokoppler, dadurch keine Fremdspannung zum Rechner.
•Start/Stop Taster, Optische Anzeigen: Spannung, PC-Online, Datensignal.
•Extraspannungs-Ausgang für andere Verbraucher.

Mehr Informationen zu diesem Gerät gibt es auf den WWW-Seiten von Siegfried Grob.

2.3 Der Anschluss eines Programmiergleises

Bei den meisten in Lokomotiven einzubauenden Digitaldecodern lassen sich die dort gespeicherten Einstellungen durch einen Programmiervorgang ändern. Der Decoder verbleibt zu diesem Zweck in der Lok und wird mit speziellen Befehlen programmiert, wobei NMRA-DCC kompatible Decoder auf Programmierbefehle eine Quittierung senden. Diese Quittungen sollen nun von der Software der Programmierzentrale erkannt und ausgewertet werden.

Benötigt wird dazu ein spezielles Programmiergleis, d.h. ein kurzes, vom Rest der Anlage getrenntes Gleisstück, das mit einer speziellen Schaltung sowohl an dem Booster, wie auch an der seriellen Schnittstelle des PC angeschlossen wird. Einen Schaltungsvorschlag dazu zeigt Bild 2.2. An der seriellen Schnittstelle werden die Steuerleitungen RTS und RI genutzt.

Bild 2.2.: Schaltungsvorschlag für den Anschluss eines Programmiergleises

Wird ein solches Programmiergleis verwendet, darf der erddcd Daemon nicht mit aktiviertem Ringindikatorcheck gestartet werden. Grundsätzlich funktioniert die Programmierung auch ohne diese Schaltung, jedoch ist die Software dann nicht in der Lage die Quittierungen des Decoders auszuwerten.

Ein wichtiger Hinweis: Das Programmiergleis darf nur zur Programmierung der Decoder verwendet werden! Die oben angegebene Schaltung darf niemals in einem Fahrstromkreis benutzt werden.

Um einen Decoder programmieren zu können wird jetzt nur noch ein dafür geeigneter DDL Client benötigt. Die später vorgestellte Programme nrma_programmer und uhl_programmer sind hier sehr gut geeignet.

2.4 Einlesen von Rückmeldungen

Um eine echte Steuerung der Modellbahnanlage zu realisieren, müssen auch Rückmeldungen eingelesen und verarbeitet werden können. Und diese Anforderung kommt in der Regel sehr schnell: Es muss ja nicht immer gleich ein Gleisbildstellwerk nach SpDrS60 sein, in dem auch die aktuellen Zustände angezeigt und Fahrstrassen automatisch aufgelöst werden. Schon eine einfache Blockstreckensteuerung benötigt Rückmeldungen aus der Anlage.

Der DDL Daemon unterstützt den S88- Rückmeldebus. Eine weitere Möglichkeit auf Basis von PC Interfacekarten mit dem Intel 8255 ist in der Entwicklung.

2.4.1 Der S88 Rückmeldebus

Der S88-Bus übermittelt Informationen aus der Modellbahnanlage an die Steuerung. Er wurde von der Firma Märklin entwickelt und hat seinen Namen nach einem Rückmeldemodul dieses Herstellers erhalten.

Ein einzelner S88-Bus kann bis zu 31 Rückmeldemodule mit jeweils 16 Eingängen aufnehmen und damit zu 496 Bit ( 62 Byte ) einlesen. Der aktuelle Datenbestand des gesamten S88-Bus wird von der Steuerung seriell eingelesen.

Der DDL Daemon kann über eine parallele Druckerschnittstelle Daten von bis zu vier S88-Bussen einlesen. Soll nur ein Bus angeschlossen werden, so erfordert dies nur einen einfachen Zwischenstecker. Bei bis zu vier Modulen an einer Druckerschnittstelle muss eine einfache Hardware aufgebaut werden, die später vorgestellt wird. Da der PC in der Regel bis zu drei Druckerschnittstellen unterstützt, kann die Anzahl der Rückmeldemodule noch weiter erhöht werden. Dazu sind dann aber auch bis zu drei DDL Daemons zu starten, da jeweils immer nur eine Schnittstelle unterstützt wird.

Die S88-Module werden wie bei SRCP spezifiziert angesprochen.

Die Rückmeldemodule benötigen eine geregelte Versorgungsspannung von 5 Volt. Dafür sollte in jedem Fall ein eigenes Netzteil verwendet werden, z.B. auf Basis des preiswerten Reglerbausteines 7805 (möglichst sogar für jeden Bus einen eigenes Netzteil).

Weitere Informationen zur Implementierung des S88-Supports im DDL Projekt gibt es auf den WWW-Seiten von Martin Wolf [3].

2.4.1.1 Einen einzelnen S88-Bus anschließen

Der Anschluss eines einzelnen S88-Bus erfolgt über einen einfachen Adapter direkt an der parallelen Druckerschnittstelle des PC. Die Anschlussbelegung zeigt Tabelle 3. Zur Information sind die Signalnamen des S88-Busses und der parallelen Schnittstelle angegeben.

Ein Nachteil soll nicht verschwiegen werden: Da der S88-Bus direkt an der PC-Schnittstelle betrieben wird, können ein Kurzschluss oder Überspannungen zur Zerstörung dieser Schnittstelle führen. Also ist besondere Vorsicht geboten!

Aus Sicht des DDL-Daemon hat der einzelne S88-Bus immer die Busnummer 1, die SCRP Portnummern sind 1 bis 496.

2.4.1.2 Bis zu vier S88-Busse an einer parallelen Schnittstelle

Eine einfache aufzubauende und preiswerte Zusatzschaltung (Bild 2.3., Quelle: Martin Wolf [3]) ermöglicht den Anschluss von bis zu vier S88-Bussen an einer Druckerschnittstelle. Überspannungen und Kurzschlüsse können sich hier nur auf den betroffenen Bus auswirken. Im schlimmsten Fall muss das entsprechende Treiber-IC (74LS241) ausgewechselt werden.

Bild 2.3.: Interface für den Anschluss von bis zu vier S88-Bussen

Der Daemon erddcd liest die Daten aus den angeschlossenen Bussystemen gleichzeitig ein. Über SCRP werden alle Ports in einer fortlaufenden Numerierung angesprochen.88 Bus Nummer

Werden noch mehr Rückmeldeports benötigt, so können bis zu zwei weitere Daemons gestartet werden, die dann die zweite und dritte parallele Schnittstelle dieses PC ansteuern. Aber mal ehrlich - dies dürfte selbst für Großanlagen kaum mehr notwendig sein.

Die Hardware des S88 Interface lässt sich, so wie in Bild 2.4 gezeigt, auf einer Experimentierplatine (Bezugsquelle: http://www.reichelt.de/) schnell aufbauen.

Bild 2.4.: Experimentierkarte mit S88 Interface.

Die Verdrahtung ist in Fädeltechnik ausgeführt, anstelle der beiden im Schaltplan angegebenen Widerstandarrays sind einzelne Widerstände aus der Bastelkiste eingebaut worden. Die 5V Spannungs-versorgung erfolgt über den rechts oben im Bild sichtbaren Baustein, der als preiswerter Bausatz von der Firma ELV (http://www.elv.de/) bezogen werden kann (und natürlich noch in ein entsprechendes Gehäuse eingebaut wird).

2.4.1.3 Ein Gleisbesetztmelder zum Anschluss an S88

Ein S88 Rückmeldemodul kann durch eine einfache Schaltung so erweitert werden, dass besetzte Gleisabschnitte gemeldet werden. Einen Schaltungsvorschlag zeigt Bild 2.5.

Bild 2.5.: Ein einfacher Gleisbesetztmelder

Die Anschlüsse K1 und K3 werden mit dem Booster verbunden, der zu überwachende Gleisabschnitt wird an K1 und K2 angeschlossen. Die beiden Verbindungen zum S88 Modul sind K4 (Meldeeingang) und K5 (Masse). Der Optokoppler ILQ74 enthält in einem Gehäuse immer vier gleiche Bausteine, so dass dieser Gleisbesetztmelder sehr kompakt in jeweils Viererblöcken aufgebaut werden kann.

2.4.1.4 S88-Parameter in der erddcd Konfigurationsdatei

Standardmäßig wird der S88 Bus an der ersten parallelen Schnittstelle des PC betrieben. Bei Bedarf können diese und einige weitere Einstellungen entweder aus der Kommandozeile über die Startparameter des Daemons oder in der Konfigurationsdatei geändert werden.

In der Konfigurationsdatei erddcdrc sind diese Einträge zu finden:

s88-ioadr: 0x378 # hex base addr of parallel port e.g. 0x378

Auswahl der parallelen Schnittstelle, an der der S88 Bus betrieben wird (hier: LPT1). Weitere erlaubte Adressen sind 0x3BC und 0x278. Soll eine andere Adresse zum Einsatz kommen, muss der Quelltext entsprechend erweitert und neu kompiliert werden.

s88-clock-scale: 35 # recommended: 35

Um die Kompatibilität mit den original Märklin Produkten zu erhalten, wird über diesen Parameter die Taktfrequenz zum Einlesen der Daten auf ca. 8 kHz heruntergesetzt. Der Daemon schreibt dazu jeweils 35 mal die gleichen Daten zur Schnittstelle. Technisch sind weit über 100 kHz möglich.

s88-refresh: 100 # recommended: 100

Die Daten aus dem S88 Bus werden nicht ständig eingelesen, sondern nur in dem hier einstellbaren Zeitabstand (in Millisekunden). Bis zum nächsten Aktualisieren werden die Daten werden im PC zwischengespeichert.

2.4.2 Einlesen von Rückmeldungen mit i8255-Karten im PC

Der Daemon erddcd unterstützt auch preiswerte i8255-Karten. Derzeit fehlt zu diesem Thema noch Dokumentation und Unterstützung durch die Clients. Weitere Information zu diesem Thema gibt es bei Kurt Harders (harders@pinserve.de).

In der Konfigurationsdatei erddcdrc ist die Basisadresse der i8255-Karte einstellbar:

i8255-device: /dev/port # e.g. /dev/port

2.5 Hinweise zum Decodereinsatz

Derzeit kann der DDL Daemon erddcd Datenpakete für das alte Märklin-Protokoll (Protokollkennung: M1), für das neue Märklin-Protokoll (Protokollkennung: M2), für diverse Erweiterungen dieses Protokolls (Protokollkennungen: M3, M4, M5) und für NMRA-DCC kompatible Decoder (Protokollkennungen: NB, N1, N2, N3, N4) erzeugen.

Decoder, die nur das alte Märklin-Protokoll verstehen sind C90 (6090), C80 (6080) und alte Delta-Decoder. Das neue Märklin-Protokoll verstehen 60901, 60902, neue Delta-Decoder und alle Decoder von Uhlenbrock (DGL750, DGL751, DAL770, DGR755).

Es können alle NMRA-DCC kompatiblen Decoder eingesetzt werden. Der Daemon kann Pakete des NMRA-Standards mit kurzer 7- oder langer 14-bit-Adresse, 14, 28 oder 128 Fahrstufen und bis zu 4 Zusatzfunktionen erzeugen. Decoder mit der gleichen kurzen und langen Adresse können parallel betrieben werden (Damit stehen 10366 NMRA-DCC-Adressen zur Verfügung.).

Der Daemon kann auch Signale für die alten Märklin Funktionsdecoder (z.B. im Tanzwagen) (Protokollkennung: MF) und zur Ansteuerung der Schaltdecoder (M) erzeugen (k83 und kompatible). Natürlich können auch Schaltdecoder gemäß NMRA-DCC (N) verwendet werden

Die Märklin-Varianten der Conrad-4fach-Weichendecoder (Hersteller Littfinski, http://www.ldt-infocenter.com/) arbeiteten nicht mit DDL und der seriellen Schnittstelle des PC zusammen (es gibt ein Timingproblem). Die NMRA-Varianten dieser als Bausatz und Fertiggerät erhältlichen Decoder funktionieren mit DDL einwandfrei!

Lokdecoder nach NRMA DCC sind so zu konfigurieren, dass sie nicht auf alternative Stromversorgung bzw. andere Digitalprotokolle reagieren. Dies erreicht man, in dem man Bit 2 (Die Bit-Nummerierung beginnt bei 0!) von CV#29 auf 0 setzt. Dies ist zwar lediglich eine Vorsichtsmaßnahme, sollte aber in jedem Fall durchgeführt werden.

3 Die Software

Die Installation von Betriebssystem und der für die Modellbahnsteuerung benötigten Software wird sicherlich zunächst einmal eine ernstzunehmende Hürde darstellen. Die Unterschiede zu der vielleicht schon gewohnten Arbeit mit einem Microsoft Windows basierten Rechner sind da und es wird notwendig sein, sich doch etwas tiefergehend mit den Besonderheiten von Linux auseinander zu setzen.

3.1 Linux Grundinstallation

Das Betriebssystem Linux wird am einfachsten aus einer Standarddistribution wie z.B. SuSE 8.0 oder Redhat 7.3 aufgebaut – das kostet dann zwar ein paar Euro für Medien und Dokumentation, man bekommt dafür aber auch Programme, die die Installation einfach gestalten. Wer es ganz kostengünstig haben möchte, der kann sich sein Linux natürlich auch ohne diese Kosten direkt aus dem Internet laden. Wenn dieser Weg beschritten wird, sollten aber schon einige spezielle Linux Kenntnisse vorhanden sein.

Die Linux Grundinstallation sollte eine grafische Oberfläche (X-Windows, X11) umfassen. Diese erleichtert die Arbeit erheblich. Viele der nachfolgenden Beispiele werden unter KDE gezeigt. KDE ist eine unter Linux oft zu findende Benutzeroberfläche, die von der Bedienung her stark an Microsoft Windows erinnert.

3.2 DDL Software installieren und starten

Die aktuelle Software des DDL Projektes kann im Internet unter der Adresse http://www.vogt-it.com/OpenSource/DDL bezogen werden, die Version ddl-xmas2001 finden Sie auf der Heft-CD im Verzeichnis /DDL/ddl.

Für Redhat Linux basierte Rechner ist dieser Teil der Installation am einfachsten durchzuführen: Es stehen fertige „Pakete“ (RPM) zur Verfügung, die direkt installiert werden können. Die wietere Arbeit ist schnell erledigt: Nachdem das für die Redhat Version geeignet Paket auf den PC gespeichert wurde, wird dies mit

# rpm -i ddl-<release>-<bs-info>.i386.rpm

installiert. Es sind keine weitere Arbeitsschritte notwendig.

Für SuSE Linux steht kein fertiges RPM zur Verfügung, so dass DDL aus dem Quellcode kompiliert werden muss. Dafür sind einige Voraussetzungen notwendig: Die Pakete gcc, lex (flex) und yacc (bison) müssen auf diesem Rechner vorhanden sein oder bei Bedarf nachinstalliert werden.

Das Kompilieren wird direkt aus der Kommandozeile gesteuert, wobei man als Benutzer root angemeldet sein sollte, um alle erforderlichen Berechtigungen zu haben:

# cp ddl-xmas2001.tgz /tmp

# cd /tmp

# gunzip dll-xmas2001.tgz

# tar –xvf ddl-xmas2001.tar

# cd DDL-xmas2001

# ./configure

# make

# make install

# make clean

Die gepackte Datei ddl-xmas2001.tgz wird zunächst im Verzeichnis /tmp gespeichert und dann mit gunzip und tar entpackt. Die DDL Software, die für das Kompilieren benötigt wird, liegt danach in /tmp/DDL-xmas2001. Mit configure und make wird dann eine neue DDL Installation im Verzeichnis /opt/DDL erstellt. Treten während dieser Arbeitsschritte Fehlermeldungen auf, so wird dies in der Regel daran liegen, das eines der o.a. Pakete noch nicht installiert wurde.

Die Konfigurationsdatei des DDL Daemon ist /opt/DDL/erddcdrc. Hier ist kann angegeben werden, mit welcher Portnummer und mit welcher seriellen Schnittstelle der Daemon arbeiten soll. Im hier vorgestellten Beispiel wird COM2 verwendet ( also /dev/ttyS1 ), um die erste serielle Schnittstelle (/dev/ttyS0) für eine Maus oder für den Anschluss einer unterbrechungsfreien Stromversorgung freizuhalten.

Ein Hinweis: Damit die Konfigurationsdatei beim Start des Daemons ausgewertet wird, muss diese im Verzeichnis liegen, in dem auch der Daemon gestartet wird (typischerweise also in /opt/DDL/bin).

Der Start des DDL Daemons erddcd erfolgt dann als Benutzer root aus der Kommandozeile mit

linux15:/ # /opt/DDL/bin/ddld start

erddcd startet

Natürlich kann der Start dieses DDL Daemons auch automatisch bei Start des Betriebs-systems erfolgen. Der Linux Profi weiß wie – Alle anderen finden eine ausführliche Anleitung dazu in den FAQ (Frequently Asked Questions) der DDL Dokumentation [1].

3.3 Der Client-Infoport von erddcd

Ruft man erddcd mit dem Parameter -i auf, wird den Clients ein weiterer Port (portnr+2, default: 12347) zur Verfügung gestellt. Nimmt ein Client über diesen Port Verbindung zu erddcd auf, so wird er ständig über Änderungen bzgl. der Lokdecoder, die er oder andere Clients durchführen, informiert.

Beispielsweise nutzen die DDL Client-Programme monitor und j.man diese Möglichkeit. J-man nutzt die gesendeten Informationen für einen internen Abgleich mit anderen Clients, monitor ist ein einfaches Überwachungswerkzeug.

Der Client-Infoport funktioniert ebenfalls im SRCP spezifiziert.

Weiterhin zeigt der Client monitor, wie die Informationen ausgewertet werden können. Wie man die Informationen in Java auswerten kann, zeigt der Quellcode von j-man (InfoportEvent.java).

Ganz besonders gut kann man den Nutzen des Infoport erkennen, wenn man j-man parallel zu einen ddsh- / rcsh-Script betreibt. Wählt man im Lokomotiv Controler-Fenster eine Lok aus, die auch durch das Script gesteuert wird, dann kann man die Veränderungen im Lokomotiv Controler-Fenster mitverfolgen.

3.4 Die DDL Client-Programme

Für das DDL-Projekt sind eine Vielzahl von Client Programmen verfügbar. Einige gehören zum Standardumfang der DDL Software, viele weitere sind im Rahmen anderer Arbeiten entstanden und nutzen die Dienste des DDL Daemons.

Einfache Clients wie z.B. die Programme simpleclient oder der nmra_programmer werden direkt über die Kommandozeile gesteuert, andere wie j-man nutzen grafische Oberflächen und setzen eine X-Windows-Umgebung auf dem Linux Rechner voraus.

Sehr interessant ist auch die Möglichkeit, komplexe Funktionsabläufe per ddsh oder rcsh Shellskript „in einer DDL Programmierumgebung“ zu automatisieren.

3.4.1 Simpleclient

Der DDL Client simpleclient ermöglicht die Steuerung von Lok- und Weichendecodern über die Kommandozeile. Dieses Programm gehört zum Standardumfang der DDL-Software und ist besonders für die ersten Funktionstests innerhalb einer DDL Umgebung geeignet.

Vor dem ersten Programmstart sind die Daten der vorhandenen Lokdecoder in der Konfigurationsdatei /opt/DDL/bin/loco.dat einzutragen. Für jeden Decoder ist Zeile in der Form

Eindeutiger Name, Decoderadresse, Decodertyp

erforderlich. Eine typische Konfigurationsdatei könnte so aussehen:

Molli,1,NB

Lok2,2,NB

Lok3,3,NB

Hier sind drei Einträge für die Loks mit den Namen Molli, Lok2 und Lok3 vorhanden. Eingebaut sind Standard NRMA DCC Decoder mit den Adressen 1 bis 3. Die Kennzeichner für den Decodertyp entsprechen der im Abschnitt 2.5 erfolgten Darstellung.

Ein Hinweis: Bitte diese Datei vor dem nächsten Programmstart sehr sorgfältig auf Schreibfehler prüfen. Ein „Speicherzugriffsfehler“ oder ein „Segmentation fault“ beim Versuch, simpleclient zu starten, können durch einen Fehler in dieser Konfigurationsdatei entstehen.

Das Programm simpleclient erwartet beim Start die Angabe von zwei Parametern: der Name des Servers, auf dem der erddcd Daemon läuft (ist dies der gleiche Rechner, auf dem auf der Client läuft, kann hier localhost eingetragen werden) und der Portnummer ( in der Regel ist dies 12345):

# ./simpleclient localhost 12345

connected to: erddcd v1.4.0; scrp 0.7.1

…

Currently selected loco:

[molli adr( 1) spd( 0) drct(1) func(0) f1(0) f2(0) f3(0) f4(0)]

Nach dem Programmstart zeigt simpleclient alle in loco.dat gefunden Lokomotiven an. Der erste Eintrag in der Konfigurationsdatei ist die nach dem Programmstart zunächst aktive Lok, deren aktueller Zustand wird angezeigt. Durch Eingabe von „?“ kann eine Übersicht aller möglichen Befehle abgefragt werden (die Eingabe der Kommandos erfolgt zeilenweise und muss jeweils mit einem „Return“ abgeschlossen werden).

Durch die Eingabe von „>“ und „<“ kann die Geschwindigkeit der aktuell selektierten Lok erhöht oder verringert werden. Die direkte Ansteuerung von Weichen- oder Schaltdecodern ist möglich.

Bitte darauf achten, dass mit den Kommandos „start“ und „stop“ die Ausgabe der digitalen Steuersignale ein- und ausgeschaltet werden muss. Das Einschalten erfolgt nicht automatisch beim Programmstart! Mit dem Befehl „logout“ wird das Programm simpleclient beendet.

3.4.2 j-man

Auch das Programm j-man (Tabelle 5) gehört zum Standardumfang der DDL-Software. Benötigt wird eine Java-Umgebung, wie sie bei der SuSE Distribution automatisch mit installiert wird. Unter Redhat ist etwas mehr Arbeit notwendig, hier muss Java aus dem Internet von www.java.sun.com geladen und eingerichtet werden.

3.4.2.1 Installation und Start

Da für den Programmstart von j-man einige Umgebungsvariablen gesetzt sein müssen, sollte zweckmäßigerweise ein Benutzer eingerichtet werden, der die entsprechenden Eintragungen in der zu seiner Startumgebung gehörenden Konfigurationsdatei .bashrc erhält:

export JAVAHOME=/usr/lib/SunJava2-1-3-1

export JAVAVM=java

export DDLHOME=/opt/DDL

export PATH=$DDLHOME/bin:$JAVAHOME/bin:$PATH

In diesem Beispiel hat ein Benutzer mit dem Namen psamulat diese vier Einträge zusätzlich in seiner .bashrc erhalten. Meldet sich dieser Benutzer an, werden diese vier Umgebungs-variablen automatisch gesetzt (die hier angegebenen Pfade entsprechen einer SuSE 8.0 Installation).

Wie wird das Programm j-man gestartet? Vorausgesetzt, die aktuelle Benutzeranmeldung ist root, X-Windows und der erddcd Daemon laufen, so erfolgt dies aus der Kommandozeile mit

linux15:/ # xhost +

access control disabled. clients can connect from any host.

linux15:/ # su psamulat

psamulat@linux15:/> j-man &

Die grafische Oberfläche des Programmes j-man zeigt Bild 3,1. Auch hier sollte nicht vergessen werden, zunächst die Ausgabe der digitalen Signale zu aktivieren.

Bild 3.1.: Der DDL-Client j-man

Für jede Lok kann dann ein eigenes Fenster geöffnet werden (Funktion: Spielen -> Starte neuen Lokdecoder), in dem alle Parameter bequem per Mausklick gesteuert werden können. Die unter simpleclient noch direkt in eine Datei einzutragenden Konfigurationsdaten der Lokdecoder können unter j-man, so wie in Bild 3.1. rechts zu sehen, bequem innerhalb eines Formulares erfasst werden.

3.4.2.2 Handregler für j-man

Als durchaus brauchbarer Handregler für j-man kann ein analoges PC Gamepad (z.B. vom Hersteller Gravis) eingesetzt werden. Der Nachteil: Es fehlt ein Drehregler, d.h. die einzelnen Geschwindigkeitsstufen müssen „per Taste“ getickert werden.

Besser geeignet für den Einsatz mit j-man geeignet sind Selbstbau Handregler. Im Internet. bietet Holger Püschel auf seinen WWW-Seiten [10] einen Bauvorschlag für den Handregler simucopa an.

3.4.3 loco-panel

Der DDL Client loco-panel zeigt den aktuellen Zustand aller aktiven Loks in einer einfachen Übersicht und kann so eine sinnvolle Ergänzung zu anderen Client Programmen darstellen. Eine Lok ist aktiv wenn sie

•fährt oder
•die Fahrtrichtung nicht vorwärts ist oder
•eine der Funktionen aktiv ist.

Das Programm nutzt den Infoport des SRCP-Servers.

3.4.4 NMRA Programmieroberfläche

Ein kommandozeilenorientiertes Programm zur Programmierung von NRMA DCC kompatiblen Decodern. Der aktuelle Inhalt der Konfigurationsvariablen (CVs) kann zur Kontrolle ausgelesen werden. Das Programm nmra_programmer gehört zum Standardumfang der DDL-Software und bietet die Funktionen:

•Direktes Schreiben einer Konfigurationsvariablen (ganzes Byte oder Einzelbit).
•Schreiben mittels physikalischer Registeradressierung.
•Verifikation von Registerinhalten.
•Verifikation der Decoderregister 1 bis 8.
•Auslesen von Konfigurationsvariablen.

3.4.5 Programmieroberfläche für Uhlenbrock Decoder

Ebenfalls zur DDL Software gehört das Programm uhl_programmer. Es ermöglicht die einfache Programmierung von Decodern der Firma Uhlenbrock. Die Funktionen sind:

•Decoder in den Programmiermodus setzen
•Setzen von einem oder mehreren Registern (direkte Programmierung)
•Decoder in den normalen Modus setzen.

3.4.6 Programmierumgebungen für DDL: ddsh und rcsh

Zum DDL-Projekt gehört die heute nicht mehr weiterentwickelte Shell ddsh zur Steuerung komplexer Funktionsabläufe über Skripte. Dieser zum Standardumfang von DDL gehörende Client bietet eine einfache Programmiersprache an, in der Betriebsabläufe automatisiert werden können. Mit ddsh können Loks und Weichen gesteuert und die Rückmeldungen von S88-Modulen ausgewertet werden.

Die Shell rcsh von Dr. Peer Griebel [9] ist eine aktuelle Weiterentwicklung..

Die in der Programmiersprache Phyton realisierte Shell rcsh beinhaltet einen Programmer für Uhlenbrock-Decoder (75200) und für ESU-Decoder (Lokpilot). Ähnlich dem schon vorge-stellten Programm j-man existiert zu rcsh eine auf Curses basierende interaktive Steuerung mit dem Namen rcman, die dann allerdings ohne grafische Oberfläche auskommt.

Ein Beispiel mit wenigen Programmzeilen zeigt die Syntax dieser Shell:

lok = locoM2(4)

# Licht an und langsam aus Bahnhof herausfahren

lok.setFunction(1)

lok.setSpeed(1)

lok.send()

time.sleep(12)

# Beschleunigen auf freier Strecke

lok.setSpeed(7)

lok.send()

Die Lok mit Märklindecoder (Adresse 4) schaltet das Fahrlicht ein und beschleunigt dann langsam aus dem Bahnhof heraus, nach 12 Sekunden wird dann auf der freien Strecke richtig „Gas gegeben“. Kommentarzeilen beginnen mit einem „#“.

Natürlich können ddsh und rcsh auch Rückmeldungen auswerten und so auf Ereignisse reagieren – einer Automatisierung auch komplexer Funktionsabläufe steht nun nichts mehr im Wege. Die Skripte können direkt aus dem schon vorgestellten Programm j-man gestartet werden.

3.4.7 Ein Gleisbildstellwerk nach SpDrS60

Dieser DDL Client von Stefan Preis (Bild 3.2) ist eine sehr gut gelungene Nachbildung des bei der Deutschen Bahn immer noch verwendeten Spurplan-Drucktastenstellwerkes (SpDr) [5]. Wie auch DDL läuft dieses Programm unter Linux.

Bild 3.2.: Ein Gleisbildstellwerk nach SpDrS60

Die wesentlichen Leistungsmerkmale der aktuellen Version sind:

3.4.7.1 Installationsvoraussetzungen

Zur grafischen Darstellung benötigt das Programm die Bibliothek qtlib 1.4x, die unter SuSE 8.0 nicht mehr installiert wird. Neuere Versionen dieser Bibliothek werden leider z.Zt. noch nicht unterstützt. Im Lieferumfang von SuSE 7.2 ist qtlib 1.45-234 enthalten, die auf der SuSE-7.2-CD als RPM-Datei in /suse/xdev2/qtlib.rpm vorhanden ist und von dort manuell nachinstalliert werden kann.

Die Bildschirmauflösung sollte 1024 x 768 Bildpunkte betragen, die maximal gleichzeitig darstellbare Zahl von Stelltischfeldern ist für diese Auflösung programmiert worden..

Die aktuelle Software (Datei spdrs60-0_4_2.tgz) gibt es im Internet auf den Webseiten des Autors [5] oder in der Heft-CD im Verzeichns /DDL/spdrs60.

3.4.7.2 Installation

Zur Vorbereitung der Installation wird die gepackte Datei spdrs60-0_4_2.tgz zunächst in das Verzeichnis /opt kopiert. Damit wird nach dem Entpacken der Dateien eine Verzeichnisstruktur ab /opt/DDL-apps aufgebaut und die zu SpDrS60 gehörende Software in den Unterverzeichnissen abgelegt. Mit

cd /opt

gunzip -d ./spdrs60-0_4_2.tgz

tar -xf ./spdrs60-0_4_2.tar

wird die Software extrahiert und in /opt/DDL-apps gespeichert. Hier befinden sich dann alle weiteren Dateien zu SpDrS60 wie Dokumentation, Quelltexte, Ressourcen und auch das ausführbare Programm.

Zum Standardumfang gehören diese Layoutdateien:

alle_elemente.dat.gbs

Enthält alle z.Zt. verfügbaren Elemente

bahnhof_klein.dat.gbs

Ein kleiner Bahnhof als Beispiel-Layout (mit allen Fahrstrassen).

bahnhof_gross.dat.gbs

Ein großer Bahnhof als Beispiel-Layout (hier sind noch nicht alle Fahrstrassen eingetragen).

Muss das Programm kompiliert werden (unter SuSE und Redhat Linux sollte dies nicht notwendig sein), so erfolgt dies mit dem mitgelieferten „Makefile“, das sich im SpDrS60-Quellcode-Verzeichnis /opt/DDL-apps/spdrs60 befindet. In diesem Makefile ist der g++-Compiler eingestellt, bei Verwendung eines anderen also bitte die entsprechende Zeile ändern. Durch einfachen Aufruf von make install und erhält dann eine neue Laufzeitversion unter /opt/DDL-apps/bin.

Um das Programm starten zu können, muss jetzt noch eine Umgebungsvariable mit dem Namen DDLAPPS gesetzt werden, die den Programmpfad enthält. Auch dies kann, so wie schon bei j-man gezeigt, in der .bashrc eines Benutzers erfolgen:

export DDLAPPS=/opt/DDL-apps

Kann diese Variable beim Programmstart nicht gefunden werden, wird davon ausgegangen, dass die Installation im Home-Verzeichnis des aktuellen Nutzers installiert wurde. Ist dies auch nicht der Fall, bricht das Programm ab.

3.4.7.3 Start und Bedienung des Programms

Der Programmstart erfolgt mit der Kommandozeile

linux15:/ # $DDLAPPS/bin/SpDrS60 &

Auf dem Bildschirm öffnet sich ein zunächst noch leeres Programmfenster, in das über das Menü File -> Open z.B. der Inhalt einer der beiden Beispiel-Layouts geladen werden kann.

Eigene Layouts können mit geringem Arbeitsaufwand erstellt werden, solange dass benötigte Element bereits in der Bibliothek vorhanden ist. Mit Edit -> Layout wird der Editiermodus eingeschaltet (die Stelltischfelder erhalten rote Ränder).

Bild 3.3.: Das SpDrS60 Layout bearbeiten.

Wie in Bild 3.3. gezeigt, kann das eigene Layout jetzt komfortabel mit der Maus bearbeitet werden. Für aktive Elemente (Weichen, Signale, ...) werden die entsprechenden Decoderdaten eingegeben.

3.5 Einlesen von Rückmeldungen (S88-Bus)

Können über den S88 Rückmeldungen aus der Anlage verarbeitet werden, so ermöglicht SpDrS60 z.B. die Anzeige von belegten Gleisabschnitten oder das automatisches Auflösen von Fahrstrassen. Der Feedbackport von erddcd Daemon muss dazu aktiviert sein. Dies erfolgt entweder beim Programmstart mit

# erddcd –r

oder über den entsprechenden Eintrag in der Konfigurationsdatei erddcdrc. Mit der Tastenkombination Ctrl-M oder nach Klick auf das Menü Feedbackport öffnet man das Übersichtfenster für die Rückmeldebusse (Bild 3.4), wobei mit der neuen Version des DDL Daemons (Version > 1.2 ) bis zu 4 Rückmeldebusse à 31 Module mit 16 Ports unterstützt werden.

Bild 3.4.: Übersichtsfenster für S88-Busse

Man erkennt je nach gewählter Art der Anzeige im Programm-Optionen-Menu pro Seite entweder bis zu 31 Module a 16 Ports (Märklin S88 Module) oder max. 62 Module a 8 Ports (EDiTS-Module). Es erscheinen je Bus jedoch nur so viele Module, wie in dem Programm-Optionen-Menu unter Daten für jeden Bus eingetragen sind.

Das Programm SpDrS60 unterstützt keine i8255-Karten.

4 Ein Beispiel : Eine kleine LGB Anlage mit j-man und SpDrS60 steuern

Mir geht es wie sicherlich vielen anderen Modellbahnfreunden der großen Spurweiten: Über die Jahre hat sich einiges an Modellbahnmaterial für eine Anlage angesammelt, es fehlt aber an Platz für den Aufbau einer stationären Innen- oder Außenanlage. Es ist also immer nur ein vorübergehender Aufbau möglich. Gerade hier werden die Vorzüge einer digitalen Steuerung besonders deutlich: Gleich wie komplex eine solche Anlage auch ist, es wird kein besonderer Verdrahtungsaufwand entstehen. Über die beiden Drähte, mit denen der Booster mit den Gleisen verbunden wird, laufen alle Steuersignale für Loks, Weichen und die sonstige aktiven Elemente. Wenn gewünscht, kommt noch der Anschluss für den S88 Bus dazu.

Um gerade die teuren Weichen bei einem fliegenden Aufbau etwas vor mechanischen Beschädigungen durch allzu fest zupackende Kinderhände zu schützen, habe ich eine aus mehreren Weichen aufgebaute Gleisverbindung auf einer ca. XX x XX cm großen Tischlerplatte fest montiert (Bild 4.1). Dieses Teil stellt den Kern der immer wieder etwas anders aussehenden Anlage dar, die übrigen Gleisverbindungen laufen je nach aktuellem Anlagenthema (z.B. „wichtige Transporte in die Sandkiste“ oder „Auslieferung von Getränken während einer Familienfeier“) immer wieder anders.

Bild 4.1.: Das Kernstück der kleinen LGB Anlage.

Das rollende Material stammt nur zu kleinem Teil von LGB, mehrere Loks und viele Wagen stammen aus der schon lange (leider, leider, ...) eingestellten Produktion von Playmobil, die damals sogar eine zweimotorige Lok umfasste!.

Bild 4.2.: Anlagensteuerung mit SpDrS60 und j-man.

Alle Loks sind mit Decodern nach NRMA DCC ausgerüstet, die Schalt- und Weichendecoder (Hersteller: Littfinski) arbeiten nach dem gleichen Protokoll. Die Weichensteuerung erfolgt über SpDrS60, gefahren wird mit j-man (Bild 4.2). Handregler setze ich z.Zt. noch nicht ein.

5 Anhang

5.1 Konfigurationsdateien und Kommandolisten

# erddcdrc

# config file for erddcd (electric railroad digital direct command daemaon)

# by Torsten Vogt, december 2001

serial-device: /dev/ttyS1 # e.g. /dev/ttyS1

pid-file: /tmp/.erddcd.pid # e.g. /tmp/.erddcd.pid

srcp-port: 12345 # e.g. 12345

enable-feedback-port: Yes # Yes/No recommended: Yes

enable-info-port: Yes # Yes/No recommended: Yes

enable-maerklin: Yes # Yes/No

enable-nmradcc: Yes # Yes/No

improve-nmradcc-timing: Yes # Yes/No recommended: Yes

nmradcc-translation-routine: 3 # 1,2 or 3 recommended: 3

enable-usleep-patch: No # Yes/No recommended: No

usleep-usecs: 500 # usecs to sleep, recommended 100 - 5000

force-run-as-root: Yes # Yes/No recommended: Yes

force-fork-on-startup: Yes # Yes/No recommended: Yes

enable-monitoring: No # Yes/No recommended: No

enable-shortcut-checking: No # Yes/No recommended: Yes, if booster supports

inverse-dsr-handling: No # Yes/No recommended: Yes, if booster supports

shortcut-failure-delay: 500 # wait usecs before handle failure

enable-ringindicator-checking: No # Yes/No recommended: No

s88-ioadr: 0x378 # hex base addr of paralell port e.g. 0x378

s88-clock-scale: 35 # recommended: 35

s88-refresh: 100 # recommended: 100

i8255-device: /dev/port # e.g. /dev/port

Die Konfigurationsdatei /opt/DDL/erddrdrc mit den Standardwerten.

Die Kommandozeilenparameter von erddcd (Aufruf mit erddcd –h)

start : Startet die Basisspannung am Gleis

stop : Stoppt die Basisspannung am Gleis

logout : beendet simpleclient und teilt dies erddcd mit

> : erhöht die Fahrstufe der aktiven Lok um 1

< : erniedrigt die Fahrstufe der aktiven Lok um 1

cd : change direction, wechselt die Fahrtrichtung

f_on : schaltet die Zusatzfunktion an

f_off : schaltet die Zusatzfunktion ab

f1 : wechselt den Status von F1 (ON/OFF)

f2 : wechselt den Status von F2 (ON/OFF)

f3 : wechselt den Status von F3 (ON/OFF)

f4 : wechselt den Status von F4 (ON/OFF)

set nr : schaltet Magnetartikel nr (z.B. Weiche abbiegen) (Märklin)

reset nr : schaltet Magnetartikel nr (z.B. Weiche gerade ) (Märklin)

nset nr : schaltet Magnetartikel nr (NMRA-DCC)

nreset nr : schaltet Magnetartikel nr (NMRA-DCC)

Lokalias : macht die bezeichnete Lok zur aktiven Lok

Kommandoliste für das Programm simpleclient

5.2 Tabellen

5.3 Quellenverzeichnis

[1] Vogt, Torsten: DDL - Digital Direct for Linux .Multiprotokoll-Controler und Steuerungssoftware für digitale Modelleisenbahnen.

http://www.vogt-it.com/OpenSource/DDL/

[2] Gräfe, Michael: Digital Direct für Windows.

http://home.snafu.de/mgrafe/

[3] Wolf, Martin: Der S88-Rückmeldebus und das DDL-Projekt.

http://www.stud.mw.tu-muenchen.de/~mw7/familie/martin/hobby/modellbahn/s88/s88.html

[4] DER_MOBA Digitalprojekt.

http://www.der-moba.de/Digital/

[5] Preis, Stefan: SpDrS60. Grafisches Gleisbildstellwerk nach Bundesbahnvorbild.

http://www.linux-modellbahn.de/

[6] Grob, Siegfried: Das Selbstbausprojekt Bogobox Booster.

http://www.bogobit.de/

[7] Dr. Froitzheim: Selbstbauprojekt Booster.

http://www-vs.informatik.uni-ulm.de/Mitarbeiter/Froitzheim/delta/

[8] Dr. König: Dr. Königs Märklin Digital Anlage.

http://home.arcor.de/dr.koenig/digital/homepag.htm

[9] Dr. Peer Griebel: rcsh - Railroad Command Shell.

http://www.griebel-net.de/peer/rcsh/rcsh.html

[10] Holger Püschel: Bauvorschlag für den Handregler simucopa.

http://de.geocities.com/puesch/index.html

STARTSEITE zurück zu Veröffentlichungen