Modellbahnsteuerung mit Traincontroller

    Unsere Vereinsanlage steuern wir mit Traincontroller Gold, Version 7.0E1. Ein Vergleich mit anderen Programmen (wie z.B. rocrail oder Windigipet (WDP)) ist schwierig, hängt sehr von der eigenen Anlage und Erwartungshaltung ab und darum will ich hier auch gar keinen anstellen.

    Traincontroller bietet einen großen Funktionsumfang, ist sauber durchdacht und strukturiert sowie stabil im Betrieb, zumindest die Version 7. Bei der Version 8 hatten wir schon die eine oder andere unliebsame Überraschung und TC hat sich einfach selbst beendet. Züge fahren weiter - bis der installierte Watchdog die Anlage anhält.
    Trotzdem erfüllt es nicht den (vom Programmanbieter selbst erhobenen) Anspruch, die Software für die perfekt gesteuerte Modellbahn zu sein, auch bei einem guten Programm gibt es immer noch was zu verbessern.
    Nachfolgend liste ich hier einige Wünsche auf, welche ich aus Sicht des Modellbahners und Zentralen/Dekoder-Entwicklers an Traincontroller habe und würde mich freuen, wenn das eine oder andere in einer zukünftigen Version enthalten ist.
    Momentan benutze ich TC nur zum Fahren, die sonstige Steuerung erfolgt mit rocrail.

Verbesserungen beim Fahrbetrieb

    Der Fahrbetrieb ist die eigentliche Stärke von TC. Durch die Kalibrierung der Fahrzeuge ('Einmessen') und verbunden mit der Zeit-Weg-Simulation in TC lässt sich optisch ansprechender Fahrbetrieb machen. Die Fahrzeugen halten dort wo sie sollen. Die Zeit-Weg-Simulation ist zwar zuerst ein gewisse Hürde (man muß die Fahrzeuge kalibrieren), bietet aber gerade für eine Vereinsanlage den Vorteil der logischen Trennung von Fahrzeug und Strecke: der Haltepunkt innerhalb eines Blockes wird nur einmal definiert und justiert, alle eingemessenen Fahrzeuge halten dann auch dort. So wird der Konfigurationsaufwand bei M Blöcken und N Fahrzeugen auf M + N gedrückt, statt wie bei anderen Steuerungsprogrammen M * N zu sein.

    Störend ist, dass TC bei dieser Zeit-Weg-Simulation nicht mehrerere Stützstellen (die heißen in TC 'Bremsmelder') berücksichten kann. Der erste Bremsmelder zählt. Damit kann es bei längeren Bremsrampen zu Unsicherheiten im Haltepunkt kommen. Selbst wenn weitere Melder zu gezielteren Halten installiert sind, können diese in TC nicht ausgenutzt werden. Auch sind die Bremsrampen für alle Züge gleich lang. Man kann einen Bremspunkt definieren, da beginnt die Bremsrampe. Das ist okay, solange die Züge etwa gleich schnell fahren. Aber die Bremsrampe eines ICE, denn man aus 250km/h runterholt ist einfach länger als die eines Rottenkraftwagen, welcher aus 40km/h gebremst wird.
    Potential gibt es aber auch bei der Behandlung einer Havarie (z.B. Entgleisung). TC kennt zum Abbremsen bzw. Runterfahren hier nur den Zustand 'Einfrieren', der als NOTAUS an die komplette Anlage übermittelt wird. Notaus bedeutet sofortiges Abschalten des Fahrstromes, was blockierende Getriebe in Loks zur Folge hat. Und dadurch können weitere Entgleisungen entstehen, die z.B. bei einem langen Zug erfolgen, wo die Lok gerade um die Kurven gebogen ist: da drückt es dann das erste Drehgestell hinter der Lok aus dem Gleis. Und es bedeutet Abbruch aller ev. laufender Animationen neben der Anlage!

    Wünsche:
  • Berücksichtigung weitere Bremsmelder; mehrteilige Rampen bzw. Rampenkennlinien (Warum muß das linear sein?). Probefahren dieser Rampen unter Berücksichtigung des eingestellten Zuggewichtes und der Antriebs- / Bremsleistung
  • Dynamisches Nachjustieren der Einmessung: Es ist die Blocklänge (Abschnittslänge eines Melders) bekannt, es ist das Integral der Fahrstufen über Zeit bekannt, warum also nicht die Einmessung laufend kontrollieren und fallweise nachjustieren? Und ev. auch 'hängende' Loks so erkennen?
  • Weiches Runterfahren der Anlage auf einen Stopzustand (Softstop); kein Abschalten des Fahrstromes; Wahl der Zentralen, welche vom Stop überhaupt betroffen sind.
  • Besseres Notfallverhalten bei einem Problem in der Steuerung: fällt ein Digitalsystem aus, kommt eine Fehlermeldung (Problem mit System xy, usw), dann sollte auch der Betrieb runterbremsen, sonst kommt es zu Auffahrunfällen. (Wir hatten das mal mit dem HSI88: das stockte, Rückmeldungen sind ausgefallen, aber TC ist ungeniert weitergefahren.)
  • Bei railcom gibt es unterschiedliche Methoden zur Lokerkennung. Die sichere Methode in Channel 2 funktioniert nur, wenn die Loks angesprochen werden. Wunsch: beim Systemstart alle Loks auf der Anlage mit Fahrstufe 0 ansprechen, damit diese adressiert werden und sich melden können.

Verbesserungen bei der Lokzuordnung und Fahrwegabsicherung

    Die BiDirektionale Übertragung, die mit BiDi (Railcom®) möglich ist, wird von TC fast komplett ingoriert. Erst mit den letzten Versionen kommen erste railcom-Unterstützung. BiDiB wird nicht unterstützt.

    Wünsche:
  • Lokeinlesen zu Sitzungsbeginn, Fahrwegüberwachung durch Auswerten der Adressmeldungen, Richtungskontrolle der Anzeige in den Blöcken
  • Support BiDiB, insbesondere auch Loküberwachung, Wartunghinweise, 'dreckiges Gleis'-Meldung.
  • Übersichtliche Anzeige aller fahrenden Loks mit ihren Fahrstufen.
    •

Verbesserungen bei der Signalisierung

    Signale werden in TC generell mit Weichenschaltbefehlen angesteuert, also nur 2 Stellungen: rot/grün. Mehrbegriffige Signale sind mehr oder minder mühsam auf diese Weichenschaltbefehle abzubilden, was jedesmal wieder Verwirrung stiftet und auch undurchsichtig in der Wartung ist. Die vielen Fragen im TC Forum zu diesem Thema belegen die Problematik.

    Wünsche:
  • Direkter Support von BiDiB-Accessory
  • Unterstützung des Extended Accessory-Befehls von DCC: da kann man den Signalbegriff direkt einstellen, kein Konfig-Wust und keine Adressenverschwendung mehr.
    •

Sonstige Anlagensteuerung

    Ist der Fahrbetrieb die Stärke von TC, so sieht es bei der Ansteuerung sonstiger Objekte eher düster aus. TC kennt hier nur die Grundelemente (Zubehörbefehle, Delays und via Bahnwärter eine Verknüpfung mit Rückmeldern). Abläufe lassen sich nur mühsam mit Makros darstellen, innerhalb dieser Makroumgebung ist sowohl die Erstellung also auch die Wartung erstellter Abläufe nicht wirklich prickelnd.
    Verzweigungen im Ablauf sowie Verknüpfung mit der Modellzeit ist oft nur von hinten durch die Brust ins Auge möglich - hier fehlen einfach entsprechende Konstrukte.

    TC kennt zwar eine Modellzeit, diese ist aber nicht automatisiert stellbar und wird auch nicht an das Digitalsystem übermittelt. Zeitabhängige DCC-Artikel (wie z.B. die Kirchturmuhr) werden nicht angesteuert. Wünsche:
  • Lokale Schaltwerke (wie z.B. ein Nocken/Reiterschaltwerk), die solche Sequenzen kontrollieren können. Diese Schaltwerke sollten wie die anderen Objekte in TC als Operationen eingetragen werden können und z.B. von einem fahrenden Zug oder vom Fahrplan ausgelöst werden können.
  • Graphische Eingabe und Konfigurationsmöglichkeit für Abläufe (z.B. entlang einer Zeitachse verschieben)
  • Übermittlung der Modellzeit an das Digitalsystem (inkl. Anhalten der Uhr beim Einfrieren), leichtere Manipulation der integrierten Uhr (Stelloperationen).

Verbesserungsvorschläge für Trainprogrammer (und die Programmierumgebung beim Einmessmenu)

  • Trainprogrammer kann eine Lok nicht am Hauptgleis auslesen (Railcom®-Read)
  • Testfenster für Accessory fehlt.
  • Testfenster Extended Accessory fehlt.
  • Programmierbefehle für Accessory am Hauptgleis fehlen.
  • Verknüpfung eines Melders mit Trainprogrammer, so dass TP automatisch mit dem Auslesevorgang beginnen kann, wenn die Lok auf dem Wartungs-(Programmier)gleis steht.
  • Unterstützung Railcom-Plus