Hallo Forum,

ich befasse mich gerade mit den üblichen Verdächtigen der PC Modellbahnsteuerungssoftware (Windigipet/TrainController etc.) und frage mich, welche Software welche Art von Algorithmen unterstützt, mit denen sie Lokbewegungen in Relation zu Melderauslösungen erlernen kann.

Beispiel: Ich habe auf den ca. 30cm langen Anfahrten zur Drehscheibe ungefähr 10 Melder installiert (5 mal linker gegen rechter Schienenstrang und 5 mal Mittelleiter-Besetztmelder). Jetzt trainiere ich einmal die Software indem ich die Anfahrt zur Drehscheibe manuell durchführe und die Lok manuell bis auf Null abbremse. Die Software speichert mit einem Timecode jede Fahrstufe in jedem Moment jeder der Melderauslösungen ab und ist so in der Lage, die von mir manuell durchgeführte Fahrt als Makro zu reproduzieren. Die Software sollte natürlich mehrere manuelle Anfahrttrainigsdurchläufe statistisch mitteln können und auch Interpolationswerte für die kurzen Zeiträume errechnen können, die nicht durch einen Melder repräsentiert sind.

...eigentlich alles so, wie es jedes normale Steuerungsprogramm aus der Industierrobotik seit 20-30 Jahren tut

Da die Programme ja keine Sharware sind, sondern echtes Geld kosten, sollten sie das können ...doch warum finde ich darauf keine Hinweise in den Beschreibungen?

Viele Grüße
Jörn

Hallo,

Zitat von Lichtleiter

---

...sollten sie das können ...doch warum finde ich darauf keine Hinweise in den Beschreibungen?

---

weil sie es nicht können (aber auch nicht brauchen).

Du solltest dich mal mit den Programmen auseinandersetzen, nachdem du deren Handbücher gelesen hast. Von beiden gibt es eine kostenlose Probeversion.

Zitat von Christian A.

---

Hallo,

Zitat von Lichtleiter

---

...sollten sie das können ...doch warum finde ich darauf keine Hinweise in den Beschreibungen?

---

weil sie es nicht können (aber auch nicht brauchen).

Du solltest dich mal mit den Programmen auseinandersetzen, nachdem du deren Handbücher gelesen hast. Von beiden gibt es eine kostenlose Probeversion.

---

Hallo Christian,

ich tue mich etwas schwer mit den Thesen, dass

A. Die Entwickler der Industiersteuerungsprogramme alles Pappnasen sind, die aus lauter Langeweile in den letzten 20-30 Jahren Algorithmen entwickelt haben, mit denen man Steuerungsvorgänge durch manuelle Manipulation am Objekt trainiert und danach durch Interpolation glattrechnet und ausführt.

B. Eine Modellbahnsteuerung natürlich "gaaaaanzzz was anders" ist und deswegen nicht der bekannten Steuerungstheorie gehorcht.

C. Es für den Anwender komfortabler ist, die Meldung von 10 Sensoren händisch im Programm mit Fahrbewegungen der Loks zu verknüpfen

...

Viele Grüße
Jörn

Hallo Lichtleiter,

die 3 Thesen hat ausser Dir keiner aufgestelt. Oder?

Viele Grüße
Frank

Zitat von Gast_001

---

Hallo Lichtleiter,

die 3 Thesen hat ausser Dir keiner aufgestelt. Oder?

Viele Grüße
Frank

---

Hallo Frank,

irre ich mich, oder hat Christian nicht nur ausgeführt, dass Modellbahnsteuerungen das nicht nur nicht können, sondern auch nicht brauchen?

zu A.: Christian stellt es so da, als hätten die Entwickler von Modellbahnsteuerungen kybernetische Mechanismen nicht nur mangels Befähigung nicht eingebaut, sondern weil sie ganz bewußt diese nicht brauchen. Es stellt sich die Frage, wie ich in der Zeit, die ich zum trainieren der Lok auf den Kontakten benötigen würde, den selben Ablauf in die Programme eingeben könnte?

zu B.: Christian bleibt mit die Erklärung schuldig, warum das Abbremsen einer Lok zu Haltepunkt anderen Gesetzmäßigkeiten folgt, als z.B. das Heranführen eines Schweißelektrode an eine Fahrzeugkarosserie.

zu C.: Wenn Christian schreibt, dass an das nicht braucht, entscheidet er über meine Zeit, die ich länger brauche, Verknüpfungen einer Lokfahrt auf 10 Sensoren als Verknüpfungen einzugeben.

Bei dieser Gelegenheit:

Wie ermittele ich die einzugebenden Abhängigkeiten der Lok von den 10 Sensoren, ohne "try und error" und ohne "scharfes Hingucken", wann wohl die Räder und der Schleifer welchen Sensor berühren?

Gruß, Jörn

Hallo Lichtleiter,

natürlich ist eine Modellbahnsteuerung etwas anderes als eine "Fertigungsstraßensteuerung".

Wir haben es hierbei (Loks) mit unzuverlässigem "Spielzeug" zu tun. Je nach Tagesform (Temperatur) verhalten sich Loks unterschiedlich.

Bei der Modellbahnsteuerung soll alles erst mal möglichst nix kosten. Du selbst schreibst ja schon dass die wenigen hundert Euro die eine Modellbahnsteurung kostet schon "teuer" sind!

Du gehst meiner Meinung nach falsch an die Sache dran. Du denkst Dir etwas aus, wie es funktionieren müsste. Dann muss der Markt diese möglicherweise doch recht "exotische" Idee einfach können?

Die inflationäre Unzahl von Sensoren auf nur 30cm die Du vorschlägst, führt dazu, dass Du über die Anlage verteilt, eine absolute Unzahl von Sensoren und Meldern brauchen würdest. Abgesehen davon ob die Modellbahnsysteme diese Datenflut überhaupt bewältigen können, stellt sich hier ganz einfach die Frage der entstehenden astronomischen Kosten.

Wir haben hier im Verein etliche Railware Anwender und einen mit Traincontroller. Eigentlich haben wir unsere Anlagen sehr gut "im Griff", ohne den in unseren Augen völlig überzogenen Aufwand.

Möglicherweise kommt Deiner Idee Railware 5.14 mit dem neuen Zugrecorder recht nahe.

Gruß, Andy

Hallo Andy,

auch ich habe nur auf den Gleisen um die Drehscheibe herum soviele Melder, im Bahnhof ein Fünftel davon und auf Strecken nur jeden halben Meter... der Grund ist halt genau die, von Dir beschriebenen, Ungenauigkeiten der Loks mit mehr Kontrollpunkten auszugleichen.

Vielen Dank für den Tip mit Railware! Der Zugrecorder geht wohl tatsächlich in die richtige Richtung!

Viele Grüße
Jörn

Hallo,

Zitat von A. Piller

---

Die inflationäre Unzahl von Sensoren auf nur 30cm die Du vorschlägst, führt dazu, dass Du über die Anlage verteilt, eine absolute Unzahl von Sensoren und Meldern brauchen würdest. Abgesehen davon ob die Modellbahnsysteme diese Datenflut überhaupt bewältigen können, stellt sich hier ganz einfach die Frage der entstehenden astronomischen Kosten.

---

Mit der wirklich unsinnigen Datenflut hätten sowohl WinDigipet wie auch TrainController keine Probleme, viel eher wäre das verwendete Digitalsystem überfordert (eine Ausnahme bestätigt die Regel ). Beide Programme kommen mit wenigen Meldern aus. Auch ich bin Anhänger von realen Meldern, weil nur reale Melder das Spielzeug MOBA auch wirklich in den Griff bekommen. Durch mehr oder weniger langwierige Einmessvorgänge (Railware und Traincontroller) werden die Loks noch lange nicht präziser, weil keine Software Hardwarefehler (Lokpräzision) korrigieren kann.

Hätte ich eine Drehscheibe, würde ich sowieso in der Mitte der Drehbühne einen realen (;)) Readkontakt installieren und an den Dampfloks einen Minimagneten montieren, damit auch die längste Dampflok ganz genau Mittig auf der Drehscheibe stehen bleibt (vorne und hinten z.B. 5mm Abstand zum Bühnenende). Warum würde ich das so machen? Weil ein Kollege seine mit WinDigipet gesteuerte Anlage/Drehscheibe so modifiziert hat und das absolut fehlerfrei funktioniert. Selbstverständlich funktioniert das auch mit TrainController und Railware.

Ich habe im übrigen die Lizenzen der 3 Programme, im Moment verwende ich bis zum abschliessenden Software-Entscheid (in etwa 2-3 Jahren) aber nur noch WinDigipet und TrainController (Railware ist herausgefallen). Beide Programme haben ihre Stärken und wie sie sich entwickeln in den nächsten Jahren wird dann sicher auch noch zu meinem definitiven Entscheid beitragen (2-3 Jahre, weil ich dann dank Pensionierung endlich (hoffentlich) etwas mehr Zeit für die MOBA aufwenden kann).

herzliche Grüsse

Gian

Zitat von granit

---

Ich habe im übrigen die Lizenzen der 3 Programme, im Moment verwende ich bis zum abschliessenden Software-Entscheid (in etwa 2-3 Jahren) aber nur noch WinDigipet und TrainController (Railware ist herausgefallen). Beide Programme haben ihre Stärken und wie sie sich entwickeln in den nächsten Jahren wird dann sicher auch noch zu meinem definitiven Entscheid beitragen (2-3 Jahre, weil ich dann dank Pensionierung endlich (hoffentlich) etwas mehr Zeit für die MOBA aufwenden kann).

herzliche Grüsse

Gian

---

Hallo Gian,

darf ich erfahren, warum gerade Railware herausgefallen ist? Leider ist es genau das einzige Programm, welches mit dem Recorder einer echten Steuerung/Regelung dem aktuellem Stand der Technik am nächsten kommt... (wird Railware nicht auch im Miniatur Wunderland benutzt?)

Viele Grüße
Jörn

Hallo Jörn,

in unsere Vereinanlage, allerdings das kritischere 2-Leiter-System - sind die Halteabschnitte 0,60 cm (für aus 40 km/h)lang und 30 cm im für Rangierbetrieb fähigen Bahnhof cm (für aus 10-20 km/h) lang. Bremsabschnitte zwischen 1,20 bis 2.40 m und die Fahrabschnitte in den Blöcken noch länger.

Einer der Gründe ist, das für die Verabeitungszeit der Gesamtkette Rückmelder-> Zentarle -> PC -> Zentrale -> Gleis -> Loko realistisch eine Latenzzeit von 0,1 bis max. 1,0 Sekunden entstehen.

Egal wie fein man auch die Rückmelder einteilt, diese Varianz ist bei MoBa-Digital-Systemen gegeben. Bei zu kleinen Rückmeldeabschnitte könnten sich die Rückmeldungen allenfalls auch protokolbedingt gegenseitig "überholen".

Aus diesem Grund sind keine Regelungsprozesse nach deiner Genauigkeits-Vorstellung über den PC realisierbar.

Bei unsere Strassenbahn nutzen wir Lenz-ABC-Module mit konstantem Bremsweg im Decoder. Das ist die erste Lösung die Dank EMK-Auswertung im Decoder einen extrem genauen Regelungsprozess des Haltevorgangs lokal realisiert (fortlaufender Regelungsprozess im Bremsvorgang). Über eine Digitalssystem mit PC wäre das nicht möglich.

Dennoch gelingt es, mit klassischen PC-Steuerungen auch auf eine Drehscheibe zielgenau aufzufahren (grosses Thema mit x Lösungen).

Dabei fährt man einfach langsam auf, und benutzt entweder spezielle Sensoren (Lichtschranken oder Magnetsensor in Bühne), wobei sich dei Bremsgenauigkeit dann duch das Schritttempo einstellt.

Oder man konfiguriert für jede Lok eine eigene Halteverzögerung nach Besetztmeldung der Bühne (bei der die Lok ja noch zum Teil neben der Bühne steht). Kein besonders grosser Aufwand, Stoppuhr reicht.

Danach macht man sich Gedanken, woher die Loko weiss, wann die DS angekommen ist .

Die "Dynamik" der Loks konfiguriert man besser in der Lok, so wie mfx und DCC das vorgesehen haben. Selbst Beschleunigungsprozesse per PC auch nur zu steuern, wird bei grossen Anlagen (Domaine der PC-Steuerungen) schnell grenzwertig.

Aus Sicht des PC-Software-Herstellers hätte man natürlich gerne ähnlich genaue Info über die aktuellen Bewegungszustände der Lokos, wie sie ei Schweissrobotern üblich sind, nur leisten das die Moba-Systeme nicht.

Selbst dann wäre kaum ein Kunde bereit, für die Moba eine Acht-Core-Rechner abzustellen, der die Bewegung von zig Lokos so genau regeln würde, wie das die in der Summe verteilten Lok-Decoder tun.

Railware habe ich auch getestet, konnte aus meiner Sicht seine Versprechungen nicht einlösen. Hamburg sehe ich nicht unbedingt als Referenz, da diese Anlagen mit für Vorführanlagen typische Kreisbahnen + Schattenbahnhof keine besondere Anforderungen an die Steuerung stellen. Automatisierte Rangierbewegungen via Railware habe ich in Hamburg noch nicht gesehen.

Ich benutze lieber gelegentlich Stoppuhr, Tachowagen und ordentliche Decoder, als Tausende in die Revolutionierung der MoBa-Sensorik zu stecken, oder zig mal Auf- und Ab zu fahren, vor allem jeden mal aufs Neue, wenn sich an der Lok oder vielleicht nur die Lok-Temperatur ändert. Alle Moba-Hersteller sehen das auch als geeignetes Vorgehen an, und bauen entsprechend Ihre Digitalsysteme so auf.

Solltest Du dennoch den Railware-Weg gehen, bitte ich Dich, uns auf dem laufenden zu halten.

Viele Grüße
Frank

Zitat von Gast_001

---

Einer der Gründe ist, das für die Verabeitungszeit der Gesamtkette Rückmelder-> Zentarle -> PC -> Zentrale -> Gleis -> Loko realistisch eine Latenzzeit von 0,1 bis max. 1,0 Sekunden entstehen.

Aus diesem Grund sind keine Regelungsprozesse nach deiner Genauigkeits-Vorstellung über den PC realisierbar.

Selbst dann wäre kaum ein Kunde bereit, für die Moba eine Acht-Core-Rechner abzustellen, der die Bewegung von zig Lokos so genau regeln würde, wie das die in der Summe verteilten Lok-Decoder tun.

---

Hallo Frank,

wo ist denn überhaupt das bottleneck zu suchen, das bei der Rückmeldung bis zu einer Sekunde benötigt???

Ich kann das kaum gauben, außer man redet über eine alte Zentrale, die über ein serielles RS323 Interface an den PC angebunden ist, oder über einen schlichten Programmierfehler von ESU (CS, ECoS), der die Zeiten verlängert.

Man braucht übrigens für eine bessere Echtzeitfähigkeit wirklich keine Powermaschine mit vielen Kernen ...sondern nur Programmierer, die die Kunst der Programmierung der Porzesssteuerung im Kernel-Mode als Treiber beherrschen!

Viele Grüße
Jörn

Hallo Jörn,

die Sekunde galt natürlich für die geamte Kette (Belegtmeldung bis resultierender Lokreaktion). Lass mal max. 0,25 sek. auf die Rückmeldekette in den PC gehen. Immer noch zu viel für ein ferngesteurte Motorregelung im Sinne einer Robotorpräzision.

Ich habe bisher auch bei Seite gelassen, das man bei handelsüblichen Rückmeldern und 2-Leitern gar nicht weiss , ob ein C-Kuppler mit der ersten oder letzten Achse auslöst, oder der Steuerwagen mit dem ersten oder 2. Drehgestell. Das muss eine 2-Leiter taugliche Steuerung auch noch verkraften.

Zitat

---

Man braucht übrigens für eine bessere Echtzeitfähigkeit wirklich keine Powermaschine mit vielen Kernen ...sondern nur Programmierer, die die Kunst der Programmierung der Porzesssteuerung im Kernel-Mode als Treiber beherrschen!

---

Ich habe ähnliche Dinge (Echtzeit-Anforderungen) immer durch Multi-Threaded-Programmierung in der Applikationen gelöst (ist leider noch lange nicht Standard, wenigstens nicht in der Windows-Welt, Anwender, Microsoft und Intel warten aber schon sehnsüchtig), und glaube auch, das hier noch einiges drin ist. IN die Treiber-Schicht von PC's habe ich mich noch nicht hinab begeben.

Vielleicht kannst Du mir mal erklären, wie da noch was grundlegendes zu holen ist. Ein Beispiel, wie man diese Schicht sinnvoll verwenden könnte, wo die Vorteile liegen?

Vielleicht reden wir da über dasgleiche. Über den Schnittstellentreiber würde ich (mindestens) einen eigenen Thread setzen und dahinter in die Applikation queuen, und Du vielleicht einen neuen Treiber schreiben?

Die RS232 war ist aus meiner Sicht bisher keine Schwachstelle bei Echtzeitaufgaben. Zumindest bei bitorientierten Protokollen nicht, wo sie einen exklusiven Zugriff, garantierte Bandbreite gewährleistet und den Informationsbedarf gängiger Zentralen vollkommen abdeckt.

So jetzt geh ich mal "Kernel-Mode" Konzepten suchen. Man lernt ja nie aus.

Viele Grüße
Frank

Hallo Frank,

Zitat

---

Die RS232 war ist aus meiner Sicht bisher keine Schwachstelle bei Echtzeitaufgaben. Zumindest bei bitorientierten Protokollen nicht, wo sie einen exklusiven Zugriff, garantierte Bandbreite gewährleistet und den Informationsbedarf gängiger Zentralen vollkommen abdeckt.

---

der gute Lichtleiter wird dir nie glauben, dass eine RS232 Schnittstelle nicht den Schwachpunkt in der Befehlskette darstellt. Für ihn ist die Ethernet Schnittstelle das Maß aller Dinge.
Dass im Prinzip 9600Baud reichen um die Rückmeldungen zum PC zu transportieren ist seiner Meinung nach ein Ding der Unmöglichkeit.

Hallo Jörn
ich kann es mir nicht verklemmen auch noch meinen Senf dazu zugeben.
Robotersteuerungen und Bahnsteuerungen unterscheiden sich grundsätzlich durch die Tatsache dass der Roboter oder besser gesagt dessen Steuerung immer genau (extrem genau) weis wo sich der Greifer oder was auch immer des Roboters befindet. Bei der Bahn ist das anders. Hier weis die Steuerung, dass sich der Zug in einem Abschnitt (Block) befindet. Innerhalb des Blocks oder des überwachten Abschnittes kann die Steuerung nun rechnen wo sich der Zug befindet wenn alles fehlerfrei läuft. Aber das weisst du sicher ja alles selber. Dies ist aber der Grund, dass die zwei grundlegend verschiedenen Ausgangslagen auch nach anderen Lösungen verlangen. Die wichtigsten PC Programme lösen jedes auf seine Weise diese Problem zur Zufriedenheit der Anwender.
Gruss Robert

Hallo,
seit mehr als zehn Jahren fahre ich mit Soft-Lok (MS-DOS unter Windows). Ein Umstieg auf aktuellere Software fällt mir noch schwer. In Handbüchern und Demoversionen anderer Programme lese ich immer wieder, dass hier beim Abbremsen der Züge die Zuglänge bzw. der Anhalteweg berechnet wird. Was passiert eigentlich, wenn der Zug z.B. 2,50m zum Anhalten benötigt, aber schon nach 50 cm stehen bleibt, weil eine Kontaktstörung auftritt. Bei Soft-Lok frage ich ab, ob der erste Kontakt im Block nach dem Belegen wieder öffnet. Dann weiß ich wirklich, dass der Zug im Gleis steht. Auch kann ich beim Betätigen eines Rückmelders einen direkten Befehl eingeben, z.B. Stellbefehl für Weiche/ Signal oder Lokbefehl-Geschwindigkeit/ Funktion, usw. Bei bisherigen Testversionen anderer Programme konnte ich teilweise nur Fahrstrassen aufrufen.
Im Gegensatz zu den Beispielen in diversen Handbüchern habe ich keine flächendeckende Gleisbesetztmeldung. Diese scheint aber in manchen Fällen notwendig zu sein für einen Automatikmodus der Anlage. Ich fahre ausschließlich mit drei Rückmeldern je Blockabschnitt.

Gruß, Thomas

Hallo Thomas,

wenn Du mit Softlok zufrieden bist, würde ich die Software nicht wechseln........

Ich fange an, mich in Traincontroller einzuarbeiten. Mit dem Programm kann man fast alles verwirklichen. Lies dort einfach mal im TC Forum mit und gibt bestimmte Suchworte ein, die Dich interessieren. Selbstverständlich kannst Du auch Fragen stellen.

Das Forum von Windigipet ist auch sehr gut.......


Viele Grüße von

Harald

Hallo Thomas,

Zitat

---

Was passiert eigentlich, wenn der Zug z.B. 2,50m zum Anhalten benötigt, aber schon nach 50 cm stehen bleibt, weil eine Kontaktstörung auftritt.

---

Was dann passiert hängt weniger von der Software ab, aber mehr von der Gestaltung der Rückmeldestrecken. Du hast bei Railware z.B. die Möglichkeit am Gleisende sog. "Stopmelder" einzubauen. Dann erkennt Railware, ob der Zug bis zum Signal gefahren ist - oder eben nicht. Ideal für den nicht einsehbaren Bereich.

Zitat

---

Auch kann ich beim Betätigen eines Rückmelders einen direkten Befehl eingeben, z.B. Stellbefehl für Weiche/ Signal oder Lokbefehl-Geschwindigkeit/ Funktion, usw.

---

Diese Möglichkeit bietet Railware selbstverständlich auch. MIt der Zug- Wegefunktion oder mit einer Hilfsautomatik - alles problemlos machbar.

Zitat

---

Im Gegensatz zu den Beispielen in diversen Handbüchern habe ich keine flächendeckende Gleisbesetztmeldung. Diese scheint aber in manchen Fällen notwendig zu sein für einen Automatikmodus der Anlage.

---

Die 100% Überwachung ist erstmal vorbildgerecht. Sie ist auch auf Modellbahnanlagen empfehlenswert z.B. um verlorene Einzelwagen auch sicher erkennen zu können.

Railware kommt auch mit Einzelkontakten zurecht. Allerdings sind dann wesesentliche Funktionen nicht erreichbar. Z.B. Halt in Bahnsteigmitte.

Tests mit Demoversionen, selbst mit den zugehörigen Handbüchern bringen halt nur einen sehr rudimentären Überblick. Billig ist es, ob es auch sinnvoll ist muss jeder selbst wissen.

Gruß, Andy

Hallo,

Zitat von thomas1960

---

In Handbüchern und Demoversionen anderer Programme lese ich immer wieder, dass hier beim Abbremsen der Züge die Zuglänge bzw. der Anhalteweg berechnet wird. Was passiert eigentlich, wenn der Zug z.B. 2,50m zum Anhalten benötigt, aber schon nach 50 cm stehen bleibt, weil eine Kontaktstörung auftritt.

---

Kommt darauf an, was Du als Kontaktstörung ansiehst und was Du meinst was passieren soll. Ich sehe da eigentlich kein Problem, weil wenn der Zug , aus welchem Grund auch immer, stehen bleibt, die Besetztmeldung ja nicht freigegeben wird (jedenfalls bei mir, da jeder Wagen auch registriert wird und nicht nur die Lok). Aber Kontaktstörungen sind auf meiner Anlage seltener als 1 stündige Stromausfälle des Elektrizitätswerkes .

Zitat von thomas1960

---

Im Gegensatz zu den Beispielen in diversen Handbüchern habe ich keine flächendeckende Gleisbesetztmeldung. Diese scheint aber in manchen Fällen notwendig zu sein für einen Automatikmodus der Anlage.

---

Ich habe (bzw. baue) eine flächendeckende Besetztmeldung, aber nicht wegen allf. Vollautomatikbetrieb, sondern weil ich meine Züge immer noch am liebsten von Hand oder über Fahrstrassen steuere. Wenn ich Züge in meinen nicht einsehbaren Abstellgleisen mit Prellbock "parkiere" verlasse ich mich einzig und allein auf die Besetztmeldungen im Gleisbild. Das Gleisbild (Bildschirm-Stellpult) ist für mich die wichtigste Schnittstelle zwischen mir und der MOBA und war auch der Grund, mich mit MOBA-Steuerungssoftware zu beschäftigen. Und weil das Auge auch mitisst, kam für mich von Anfang an kein DOS-Programm mehr in Frage (das hat aber rein gar nichts mit der Qualität solcher DOS-Programme zu tun!). Bei meiner MOBA ist auch jede einzelne Weiche mit Rückmeldern erfasst, inkl. Lichtprofil. Das bedeutet, wenn eine Lok oder ein Wagen zu Nahe an der Weiche steht, wird die Weiche als besetzt ausgeleuchtet und die Fahrstrassen werden verriegelt.

Zitat von thomas1960

---

Ich fahre ausschließlich mit drei Rückmeldern je Blockabschnitt.

---

Das ist bei mir das Minimum, weil die Blöcke in beide Richtungen befahren werden (ausschliesslich Einspurbetrieb). So setzt sich ein Block im Minimum aus STOPP - BREMSEN - STOPP (= 3 Melder) zusammen. Bei längeren Blöcken sieht es dann so aus: STOPP - BREMSEN - FAHREN - BREMSEN - STOPP (= 4 Melder).

WinDigipet verlässt sich auf die vorhanden realen Melder, darum müssen bei WDP auch keine Loks eingemessen werden. Bei TrainController und Railware müssen die Loks eingemessen werden, damit die Berechnungen (Geschwindigkeit-Bremslänge usw.) auch stimmen, will man das berechnen lassen. Meiner Schweizer Armbanduhr traue ich diese Präzision zu, Modellbahnen aber nicht. Darum war/bin ich mit den beiden letztgenannten Programmen auch nur mit realen Meldern wirklich zufrieden. Der Einmessvorgang einer Lok protokolliert die Daten anhand des aktuellen Zustands einer Lok (Getriebewiderstand, Schmierzustand, Kohlenzustand, Betriebstemperatur usw. usw.), der sich ständig ändert. Also ändert sich auch die Fahreigenschaft ständig, was aber keine Software feststellen kann. Das wäre möglich, wenn ein Lokdecoder die aktuelle Drehzahl des Motors zurückmelden würde, aber auch dieser Wert ist fragwürdig, wenn eine Lok auf der Bergfahrt schleudert! Trotzdem messe ich die Loks bei TC ein, weil sie sich dann mit den Bildschirmfahrreglern sehr fein steuern lassen. Ist aber auch bei WinDigipet kein Problem, da ich die Lokdecoder-Vmax. sowieso auf meine Bedürfnisse einstelle (keine Lok fährt bei V-max-Fahrstufe 31 schneller als umgerechnet 80-100 km/h).

SOFT-LOK aber auch MES sind sehr gute Steuerungsprogramme die auch im DOS-Fenster sehr gut laufen. Allein die Grafik entspricht nicht mehr meinen Vorstellungen (ich schaue ja auch nicht mehr schwarzweiss Fern, obwohl man auch in SW alles sieht). Die beiden von mir benutzten Programme WDP und TC erfüllen Steuerungen ebenfalls perfekt (sofern keine Anwenderfehler einen Strich durch die Rechnung machen), nicht genau auf die gleiche Art aber für den Anwender doch recht ähnlich. Letztendlich muss aber jeder Modellbahner selber wissen, welches Programm ihm besser gefällt. Eine Empfehlung, dass XX das beste Steuerungsprogramm ist, gibt es, jedenfalls von mir, nicht.

herzliche Grüsse

Gian

Hallo,

Zitat von A. Piller

---

Tests mit Demoversionen, selbst mit den zugehörigen Handbüchern bringen halt nur einen sehr rudimentären Überblick. Billig ist es, ob es auch sinnvoll ist muss jeder selbst wissen.

---

Das sehe ich nicht so, entsprechen doch die Demoversionen von WinDigipet und Traincontroller den aktuellen Vollversionen. Sie sind lediglich eingeschränkt (WDP=Anzahl Loks (2), Weichendecoder und TC hat einen Timer, schaltet also ohne Registrierung (Kauf) nach 15 Minuten ab). Railware habe ich damals mit der Demo-Version Version 4.x getestet weil es von der aktuellen Version 5.x damals keine Demo gab. Test mit 4.x zufriedenstellend, 5.x gekauft - das war mein grosser Fehler. Test's muss man mit der aktuellen Software machen können, sonst lasse ich heute die Finger vor solchen Programmen!

herzliche Grüsse

Gian

Hallo zusammen,

problematisch ist auch, das die Nutzung von MoBa-Steuerungs-Software (ähnlich) CAD einen rel. hohen Einarbeitungsaufwand erfordert. Schulungen können den minimieren, kosten aber, und sind somit erst nach der Entscheidung sinnvoll.

Deswegen würde ich empfehlen, vorher auf jeden Fall eine "Referenzanlage" aufzusuchen, und sich einfach vom Besitzer die Erfahrungen iim Umgang mit der Software berichten zu lassen.

In diesem Sinne:

Herzlich willkommen beim PFE,
Gast_001

Hallo Andy,

Zitat

---

Gleisende sog. "Stopmelder" einzubauen

---

das hört sich super an. Stopmelder, Dispatcher, etc. Entspricht meinem Ideal von einer aus Anwendersicht "objektorintierten Software". Vor allen dann, wenn die Objekte noch ein lehrreichen Vorbildbezug haben.

In der Praxis hat mich dann Railware doch gezwungen, Dinge wie Datenfluss, die im Programm implementierte Logik eher datentechnisch zu vertstehen. Un dann das ganze noch über ein ziemlich abstraktes Tree-Control zu editieren.

Das war eigentlich die grösste Enttäuschung bei Railware, die die hohen Erwartungen zusammen stürzen liessen.

Mich würde mal interessieren wie Du das siehst: Kann Railware als Baukasten aus verständlichen Elementen angesehen werden, und erfordert es eher eine verarbeitungstechnischen Durchblick?

Viele Grüße
Frank

Hallo Frank,

grundsätzlich erfordert jede Software eine gewisse "Einarbeitungszeit". Und letztendlich stellt sich die Frage wieviel der Möglichkeiten die das Programm bietet nutze ich nachher.

Schwierig wird es nur dann, wenn Du Dir im stillen Kämmerlein eine Lösung ausdenkst, und nachher für diese Lösung ein Programm oder eine Programmfunktion suchst.

Wenn der "Programmdurchblick" mal vorhanden ist, sieht das natürlich anders aus. Dann frage ich umgekehrt "Mein Wunsch kann ich mit welcher Funktion umsetzen?" Also ohne einen zuvor "ausgedachten" Lösungsweg.

Mein Schwiegervater nutzt Railware schon sehr lange. Als dann Railware auch im Miniaturwunderland und in anderen Großanlagen zum Einsatz kam, haben sich die Möglichkeiten des Programms um einen extremen Quantensprung erweitert. Auch die Stabiltät des Programms hat sich damit deutlich verbessert. In unserem Verein haben 12 Mitglieder eine Railware Lizenz. Damit ist natürlich ein Erfahrungsschatz mit gegenseitiger Hilfeleistung und Unterstützung gegeben.

Wir, die wir den "Programmdurchblick" haben sagen, es ist leicht und verständlich damit zurecht zu kommen. Neueinsteiger sehen das naturgemäß - teilweise drastisch - anders.

Im Prinzip ist es schon verständlich und auch logisch aufgebaut. Nur folgt die Bedienung einer anderen Philosophie als alle anderen Steuerungsprogramme. Ausnahme Meyle für Selectrix. Damit tun sich Neueinsteiger - gerade mit den Testversionen - oft recht schwer. Weil das so ist, kann ich mich Gians Einwand nicht anschließen. Unsere praktischen Erfahrungen sind andere.

Dieter Hinz sagt selbst, bis der erste Zug fährt dauert es in Railware länger als bei den Anderen. Aber der dritte, zehnte oder zwanzigste Zug - das ist dann nur noch ein Klax.

Natürlich hat jeder Modellbahner eigene Wünsche und Vorstellungen. Eine PC gesteuerte Anlage kennt erst mal eine völlige Freiheit an Gestaltungsmöglichkeit. Ich kann die Knöpfchen und Signalschaltungen erstmal völlig vergessen. Nix ist mehr "stromlos". Ich kann mich deutlich mehr dem Vorbild anschließen.

Das bedeutet, ich muß mir dann schon mal Gedanken machen - wo steht mein Signal richtig? Und was ist bitteschön ein "Durchrutschweg"?

Loks, die nicht stromlos abgewürgt werden halten nicht immer ganz genau an der selben Stelle. Je nach Lokpräzision bzw. Digitalsystem können das +/- 1-2cm, es können aber auch +/- 5cm sein.

Nun befassen wir uns hier einmal gedanklich nur mit einem Bahnhofsgleis. Grundsätzlich sollte auf einer PC-gesteuerten Anlage das Gleis komplett überwacht sein, um auch "verlorene" Wagen sicher erkennen zu können. Nun gibt es Programme die brauchen für dieses Gleis mehrere Überwachungsabschnitte (Rückmelder) Andere Modellbahner wünschen auf dem Bildschirm zu sehen. " Wo befindet sich mein Zug"? Am Anfang, in der Mitte, am Ende des Bahnhofgleises?

Wir gestalten ein Bahnhofgleis folgendermaßen. Das Signal bekommt einen Raum von ca 20cm. Die Lok hält ca 10cm vor dem Signal, hinter dem Signal sind nochmal 10cm bevor z.B. eine Weiche kommt. Wir finden, das sieht so einfach schöner und auch vorbildgerechter aus.

Dann gönnen wir dem gesamten Bahnhofsgleis nur einen einzigen Rückmelder. Dies kommt unserer Vorstellung von vorbildgerechtem Zugverhalten einfach sehr nahe.

Ein D-Zug, der letztendlich das gesamte Gleis ausfüllen wird, kommt in dieses Bahnhofsgleis gefahren. Mit Auslösung des Melders beginnt der Zug gaaanz langsam und kontinuierlich zu verzögern, um dann ca. 10 cm vor dem Signal anzuhalten.

Der nächste Zug ist ein halb so langer Personenzug. Würde der bis zum Signal vorfahren, wäre da etwas falsch. Beim Vorbild stehen dann die "H" Tafeln die die Haltepunkte Zuglängenbezogen festlegen. (Railware macht genau dies automatisch) Also bleibt unser Personenzug mit deutlichem Abstand vor dem Signal stehen.

Der nächste Zug ist eine Schienenbusgarnitur mit nur einem Beiwagen. Auch dieser darf nicht bis zum Signal vorfahren, sonst müssen die "Preisserlein" unnötig rennen! Also auch hier. Halt in Bahnsteigmitte!

Genauso wie ich es hier beschrieben habe setzen wir es mit Railware um - genau wie in unserem "echten" Bahnhof - und uns gefällt es so!

Grüße, Andy

Hallo Andy,

Zitat von A. Piller

---

Hallo Frank,
Damit tun sich Neueinsteiger - gerade mit den Testversionen - oft recht schwer. Weil das so ist, kann ich mich Gians Einwand nicht anschließen. Unsere praktischen Erfahrungen sind andere.

---

An der Philosophie von Railware lag es nicht, dass ich Railware nicht mehr nutze, sondern einzig und allein wegen der mangelhaften Unterstützung meines Systems (nur 28 statt 31 Fahrstufen usw.) und anderer Mängel in der zuletzt verwendeten Version 5.02 (was ja mittlerweile behoben sein soll, habe ich aber nicht mehr überüprüft).

Zitat von A. Piller

---

Dieter Hinz sagt selbst, bis der erste Zug fährt dauert es in Railware länger als bei den Anderen. Aber der dritte, zehnte oder zwanzigste Zug - das ist dann nur noch ein Klax.

---

Richtig, das sagen Dieter Hinz und Andere immer wieder, wenn man gewisse Fragen stellt. Andere Programmhersteller haben solche Auskünfte aber nicht nötig. Mit der Konfiguration von Railware hatte ich keine Probleme, auch nicht mit der dahintersteckenden Philosophie, die eigentlich gar nicht so stark von meiner abweicht (darum habe ich mir seinerzeit Railware auch gekauft). Sogar ein reiner, einfacher Automatikbetrieb war mit Railware sehr schnell funktionstüchtig. Aber auch bei TC und WDP dauert es einige Zeit, bis Züge fahren. Alle Programme brauchen ihre Einarbeitungszeit, nicht nur Railware.

Zitat von A. Piller

---

Je nach Lokpräzision bzw. Digitalsystem können das +/- 1-2cm, es können aber auch +/- 5cm sein.

---

Auf einer durchschnittlichen Anlage mit den beengten Verhältnissen können 5 cm +/- schon viel zu viel sein. Im MIWULA und im LOXX spielt das weniger eine Rolle. Trotzdem hat mir im LOXX der Zug nicht gefallen, bei dem der letzte Wagen jedes x.mal nicht im Perron- sondern im Schotterbereich anhielt, einfach der aktuellen Situation der Lok/Zug entsprechend, wie vom Zufall gesteuert (mit Railware). Das passiert mit klar definierten, realen Stoppmeldern nicht! Aber auch mit Railware halten Züge absolut genau, wenn man entsprechende, reale Melder einsetzt , was ich schnell feststellen konnte (nur zieht dann das Werbeargument 1 Melder/Block nicht mehr).

Zitat von A. Piller

---

Grundsätzlich sollte auf einer PC-gesteuerten Anlage das Gleis komplett überwacht sein, um auch "verlorene" Wagen sicher erkennen zu können.

---

Meine volle Zustimmung (und inkl. jeder einzelnen Weiche!)!

Zitat von A. Piller

---

Nun gibt es Programme die brauchen für dieses Gleis mehrere Überwachungsabschnitte (Rückmelder) Andere Modellbahner wünschen auf dem Bildschirm zu sehen. " Wo befindet sich mein Zug"? Am Anfang, in der Mitte, am Ende des Bahnhofgleises?

---

Ich bekenne mich zu den "Anderen", das hat aber nichts mit einem bestimmten Programm zu tun, das können alle Programme, theoretisch auch mit nur einem Melder.

Zitat von A. Piller

---

Ein D-Zug, der letztendlich das gesamte Gleis ausfüllen wird, kommt in dieses Bahnhofsgleis gefahren. Mit Auslösung des Melders beginnt der Zug gaaanz langsam und kontinuierlich zu verzögern, um dann ca. 10 cm vor dem Signal anzuhalten.

Der nächste Zug ist ein halb so langer Personenzug. Würde der bis zum Signal vorfahren, wäre da etwas falsch. Beim Vorbild stehen dann die "H" Tafeln die die Haltepunkte Zuglängenbezogen festlegen. (Railware macht genau dies automatisch) Also bleibt unser Personenzug mit deutlichem Abstand vor dem Signal stehen.

Der nächste Zug ist eine Schienenbusgarnitur mit nur einem Beiwagen. Auch dieser darf nicht bis zum Signal vorfahren, sonst müssen die "Preisserlein" unnötig rennen! Also auch hier. Halt in Bahnsteigmitte!

Genauso wie ich es hier beschrieben habe setzen wir es mit Railware um - genau wie in unserem "echten" Bahnhof - und uns gefällt es so!

---

Etwas anderes erwarte ich auch nicht von einer Software, solche normalen Vorgänge muss ein Programm können. Das können aber auch alle anderen Programme problemlos und präzise, unabhängig von der Präzision der Loks. Um das zu erreichen, brauchen alle Programme jedoch reale Melder, soll das Ergebnis immer genau sein, auch wenn einige Programmhersteller auf virtuelle Melder schwören, um den Modellbahnern Kostenersparnis bei der Anzahl der zu verwendenden Melder vorzugauckeln. Als Werbemassnahme zieht das halt bei unbedarften Modellbahnern immer wieder, bis sie eines besseren belehrt werden, was meine Erfahrungen mit Railware, Traincontroller und Windigipet immer wieder bewiesen haben.

Über das Thema der Anzahl einzusetzender Gleismelder im Zusammenhang mit Programmen wurde schon viel diskutiert und wird immer wieder diskutiert werden. Meine Erfahrungen mit allen von mir getesteten und verwendeten Programmen (nicht nur die 3 genannten) waren immer gleich, langfristig hat man am wenigsten Probleme mit genügend realen Meldern, unabhängig vom verwendeten Programm. Als Kaufargument für ein bestimmtes Programm ist das leider kein Argument (mehr). Dass ich pro Block, der in beide Richtungen befahren wird, mindestens 3 Melder einsetze, hat rein gar nichts mit der verwendeten Software zu tun sondern ist allein meine Antwort auf die mangelhafte Präzision jeder Lok (Markenunabhängig). Es gibt leider keine Software (nicht nur bei der Modellbahn) die Hardwaremängel ausmerzen kann. Verbiegen kann man immer etwas .

Dass unsere Loks trotz schöner Detaillierung ein unpräzises Spielzeug sind, ist leider eine Tatsache. Präzisere Loks würden vom normalen Modellbahnern auch nicht mehr bezahlt, weil sie wesentlich teurer wären.

Das wichtigste für ein Programm ist der Support des Anbieters, sei es direkt oder über ein Forum. Und genau da sind WinDigipet und Traincontroller führend, mit grossem Abstand auf die anderen. Sinngemäss gilt das auch für das verwendete Digitalsystem! Die Anzahl benötigter oder sinnvoller Melder ist zum Glück ein reiner Nebenschauplatz!

herzliche Grüsse

Gian

Hallo Gian,

Zitat

---

(nur 28 statt 31 Fahrstufen usw.)

---

Das war ein kurzes zeitliches Zwischenspiel in einem neuen Programmteil das längst vergessen ist.

Zitat

---

Auf einer durchschnittlichen Anlage mit den beengten Verhältnissen können 5 cm +/- schon viel zu viel sein.

---

Das ist natürlich richtig. Nur, +/- 4,3 Meter sind beim Vorbild im Bahnhof auch nichts völlig ungewöhnliches.

Diese Tolerenz braucht ein Lenz oder ein Selectrix System nicht. Aber es gibt auch noch andere. Die Toleranzen bei Loks/Lokdecodern darf auch nicht vergessen werden. Und für diese Differenzen ist nicht die Software ursächlich.

Zitat

---

(nur zieht dann das Werbeargument 1 Melder/Block nicht mehr).

---

Ich werde einen Teufel tun, und mich auf diese Diskussion einlassen. Wie wir es seit Jahren absolut erfolgreich praktizieren, habe ich bereits geschrieben. Besonders die Lenz Anwender in unseren Reihen schaffen damit eine absolute "Punktlandung". Die "Märklinsten" müssen größere Toleranzen einbauen, mit denen man allerdings - mit ein bisschen Erfahrung - auch noch gut leben kann.

Zitat

---

Dass unsere Loks trotz schöner Detaillierung ein unpräzises Spielzeug sind, ist leider eine Tatsache. Präzisere Loks würden vom normalen Modellbahnern auch nicht mehr bezahlt, weil sie wesentlich teurer wären.

---

Besser kann man das eindeutige Hauptproblem eigentlich absolut nicht beschreiben! Volle Zustimmung.

Herzliche Grüße, Andy

Hallo Andy,

Besten Dank für Deinen anständigen, informativen Beitrag. So sollten alle Diskussionen sein .

herzliche Grüsse

Gian