Letzte Woche bei Railware

09.02.2003

Eigentlich könnte hier ein Reisebericht über die Abenteuer einer Bahnfahrt von Dillingen nach Nürnberg und zurück stehen. Aber das wäre wohl verschwendete Zeit, denn Sie alle haben sicherlich mehr echte "Bahnerfahrung" als ich, der nur gelegentlich mal die Dienste der Deutschen Bahn AG nutzt. Wir sollten unser Hobby hegen und pflegen. Denn in wenigen Generationen wird man staunend vor unseren alten, technisch perfekten Modellbahnanlagen stehen und unsere Nachkommen werden von einem Verkehrsmittel berichten können, dass es längst nicht mehr in der Realität gibt.

Wer aktuelle Messeinfos aus Nürnberg haben möchte, sollte mal beim MOBA vorbeischauen:
http://www.moba-deutschland.de/main.htm

Wegen der unumgänglichen Messereise dauerten die Tests zu 4.07 immer noch an. Nur keine Eile ... lieber langsam und dafür gründlich. Aber das wird auch nichts helfen: in aller Regel wird bereits in der ersten Stunde nach Freigabe eines neuen Updates ein Bug gemeldet.

Wieder einmal wird an verschiedenen Stellen (besonders im Internet) über eine angeblich zu geringe Geschwindigkeit der Digitalsysteme diskutiert. Mal ist der eine Hersteller "dran", mal ein anderer. Meist handelt es sich um eher philosophische Betrachtungen selbsternannter Spezialisten. Die meisten Modellbahner können dies technisch nicht einschätzen und lassen sich verunsichern. Gelegentlich fragt auch der eine oder andere Hersteller bei Softwareentwicklern nach, ob sie denn ebenfalls Probleme haben.
Natürlich würde auch ich mir ein schnelleres Gleisprotokoll wünschen oder eine effizientere Datenkommunikation zwischen PC und Digitalsystem. Aber gibt es das nicht schon ? Das Selectrix Protokoll und die Hersteller der passenden Komponenten sind genau die ideale Kombination mit einem PC, wenn es denn wirklich auf die Geschwindigkeit ankommen sollte.

Es gibt nun wahrlich genug Hersteller von Digitalsystemen und Komponenten. Die Gleisprotokolle Motorola, Motorola2, DCC und Selectrix sind hinreichend standardisiert. Fast 20 Jahre sind vergangen, bis sie eine Akzeptanz bei den Modellbahnern gefunden haben. Darum ist es falsch, das angebliche Unvermögen von Digitalsystemen den Herstellern anzulasten. Vielmehr sollte man die vorhandene Technik so akzeptieren wie sie ist und sie eher so effizient wie möglich einsetzen. Wenn denn ein Softwareentwickler weiß, dass eventuell ein Befehl an die Zentrale technisch erst in einer Sekunde auf das Gleis gegeben werden kann, dann sollte er doch in der Lage sein, dies entsprechend zu behandeln und Zugfahrten selbsttätig zu korrigieren. Anders gesagt: wieso haben Programme wie SoftLok oder Railware vielfach auf größeren Anlagen in der Praxis bewiesen, dass selbst das gute alte Märklin Digitalsystem von der Geschwindigkeit ausreicht ist ?

Fairerweise muss man doch sagen, das die Geschwindigkeit heutiger Digitalsysteme bei einem reinen Handbetrieb auch in Zukunft mehr als ausreichend ist. Nur ein PC ist in der Lage, die heutige Technik bis an ihre Leistungsgrenzen zu treiben. Doch dafür muss man doch kein neues, schnelleres (inkompatibles ?) Digitalsystem schaffen !

Railware wird auch weiterhin auf standardisierte Hardwarekomponenten aufsetzen und Softwarelösungen für technische Probleme erarbeiten. Wer dem nicht vertrauen mag, sollte auf das Selectrix Protokoll und seine Komponenten ausweichen.

Auf Wunsch eines alten Kunden und zur eigenen Bestätigung des oben gesagten wurde ein alter Praxistest nochmals wiederholt. Damals ging es um einen Vergleich einiger bekannter Steuerungsprogramme in Bezug auf das gleichzeitige Anhalten mehrerer Züge. Die Gleisaufbauten waren noch vorhanden und so wurden die Tischlerplatten aus der Garage geholt. Aufgebaut waren 8 Gleise von je 7 Metern Länge. Außerhalb der Gleise waren noch 4 einzelne Weichen montiert. Die Verkabelung war für die Intellibox und Märklin geeignet. Damals ging es um einen Leistungsvergleich, der übrigens einige Überraschungen bot. Denn von den 6 getesteten Produkten waren nur 2 in der Lage mit nur einem Rückmeldekontakt bis zu 8 Züge gleichzeitig und gleichmäßig abzubremsen, so dass sie am gleichen Punkt zum halten kamen. Aber darum sollte es jetzt nicht gehen.

Gefahren wurde mit lastgeregelten Motorola Lokdecodern von Märklin, Uhlenbrock, Lenz und ESU. Zunächst wurden 10 Messfahrten zum "warmlaufen" gemacht, bei denen es um Toleranzen der Lokdecoder und der Fahrzeuge selbst ging. Hier gab es Toleranzen von bis zu 15 Zentimetern. Sie traten bei 2 Loks auf, deren Motore per Hamo- Magnet zu einem Gleichstrommotor umgebaut wurden. Den beiden Lenz und Uhlenbrock Lokdecodern kann man das nun wahrlich nicht vorwerfen, dass die sogenannte EMK zur einwandfreien Lastregelung nicht ausreichte.

Danach wurden je 5 Messfahrten mit 2, 4 und 8 Lokomotiven durchgeführt. Der Start der Loks erfolgte mit einem Taster im Gleisbild, der die 8 Signale auf Fahrt stellte und die Loks abfuhr. Sie mussten bereits nach 2 Metern ihre Höchstgeschwindigkeit erreichen, um dann den 2. Rückmelder auszulösen, der die Loks dann nach knappen 4 Metern zum Stillstand bringen sollte. Die Modellgeschwindigkeit spielte keine wichtige Rolle. Es wurde lediglich darauf geachtet, dass die Höchstgeschwindigkeit vor dem Abbremsvorgang wenigstens der Fahrstufe 12 entsprach. So hielten die Loks durchaus an verschiedenen Punkten. Wichtig aber: sie sollten trotz unterschiedlicher Anzahl von Loks immer an der gleichen markierten Stelle halten. Das taten sie dann auch mit einer durchschnittlichen Toleranz von etwa 3 cm. Nach Wechsel zum Märklin System zeigte sich das gleiche Bild. Auch hier nur Toleranzen von etwa 3 cm. Bemerkenswert lediglich, dass alle Haltepunkte einige cm nach vorne rutschten. Aber wer tauscht schon regelmäßig sein Digitalsystem. Nun wurden die gleichen Tests wiederholt, aber diesmal wurden während des Bremsvorganges die 4 Weichen je zweimal geschaltet. Dadurch stiegen die Toleranzen auf bis zu 12 cm.

Ein insgesamt exzellentes Ergebnis !

Zum Abschluss ein weiterer privater Einblick. So wohnt und arbeitet man bei den Railware's ...

Weiterhin viel Spaß mit Railware wünscht

Dieter Hinz

 

© Copyright by Andrea Hinz. Kontakt zum Railware Team
Alle Logos, Hersteller- und Produktnamen sind Warenzeichen ihrer jeweiligen Hersteller.