THEMA: Rocrail (RR) vs TrainController (TC)

Hi Bernd,

zwei unterschiedliche Programme, zwei unterschiedliche Konzepte.

TC kennt den Vorgang des Einmessens einer Lok bzw eines Zugs. Dabei wird die Lok/der Zug mehrmals mit unterschiedlichen Fahrstufen eine bestimmte Strecke entlang gefahren, sodass die Software berechnen kann, wann der Zug mit welcher Geschwindigkeit unterwegs sein muss, um punktgenau zu stoppen. Dabei kommt TC mit einem Melder pro Block aus.

RR kennt diesen Vorgang nicht, dadurch wird hier üblicherweise mit 2 Meldern pro Block gearbeitet. Der erste Melder löst das "Enter"-Ereignis aus, dabei wird die Lok/der Zug langsam auf Kriechgeschwindigkeit abgebremst. Und sobald die Lok/der Zug den zweiten Melder erreicht, wird das "In"-Ereignis ausgelöst, was dazu führt, dass unter Anderem die Lok/der Zug gestoppt wird. Und weil das idealerweise bereits bei Kriechgeschwindigkeit erfolgt, sollte das augenblicklich - also ohne weitere Verzögerung - erfolgen, sodass die Lok punktgenau steht.

Kurz gesagt: Du brauchst für RR doppelt so viele Melder wie für TC, ersparst Dir aber den Aufwand, all Deine Loks und Züge vorher einmessen zu müssen.

Hier die Anleitung zu RR: https://wiki.rocrail.net/doku.php?id=sensors_and_blocks-de

Herby

PS: Es gibt auch in RR die Möglichkeit, dass man mit nur einem Melder auskommt, dabei wird im laufenden Betrieb geprüft, ob ein Zug über das Ende eines Blockes hinaus fährt, weil er nicht rasch genug abgebremst wurde. Diese Information läuft dann in eine Berechnung ein, sodass der selbe Zug später etwas heftiger abgebremst wird, und beim Anfahren wird wieder gemessen, wie lange der Zug braucht, um ans Ende des Blockes zu kommen. Allmählich soll so eine relativ genaue Steuerung seitens der Software erfolgen. Aber so richtig überzeugt scheinen die meisten Modellbahner davon nicht zu sein, denn das wird meines Wissens kaum genutzt.

Hallo Herby,
danke für die Info. Glaube mir, das RR Wiki kann ich fast auswendig.
Ich habe für jeden Block 2 Melder aktiv , einen "enter" und einen "in".
Die Loks bremsen bei enter auch auf min ab, allerdings halten sie nicht punktgenau,
sondern fahren zum Teil sogar bis über den Halteabschnitt hinaus, der im SBF jeweils 25cm lang ist.
Eine Gleichmäßigkeit ist nicht zur erkennen.
Weder bei den Blöcken, noch bei den Dekodertypen. Mal hält die Lok im Block punktgenau,
ein anderes Mal, gleiche Lok, gleicher Block, hält sie nicht mehr genau.

"Allmählich soll so eine relativ genaue Steuerung seitens der Software erfolgen"

Ja, das Teil schimpft sich BBT. Hab ich aktiv. Im SBF ist es zum Teil deaktiviert, um zu sehen wie sich die Loks
ohne verhalten. Aber auch das ist ohne Erfolg geblieben.
Foto anbei, mein SBF in RR.

Meine Loconet Module habe ich auch überprüft,
Wenn eine Lok einen Melder erreicht, wird dieser auch gleich aktiv.

Im TC hab ich die Loks nicht groß eingemessen, sondern nur, sh. Bild, angepasst.
Klappt wunderbar, die Loks halten da, wo sie sollen. Auch im TC 2 Melder pro Block

Dann werde ich mich nochmal nen paar Stunden auf Fehlersuche oder Mißkonfiguration meinerseits machen.

Gruß Bernd

Bilder fehlten :(

Die von rr_bernie zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hallo Bernd,

Habe mich gerade mal in BBT eingelesen, oh das ist ja nicht ohne.
Ich selbst fahre mit nur einem Rückmelder und Ereigniszeitgeber, was gut funktioniert.

Jetzt hast du geschrieben das du einige BBT deaktiviert hast, kann es sein das RR da durcheinander kommt ?

Aus dem Wiki :

Wenn im Block vor BBT gehalten werden kann, dann bitte beachten: Reduziere Geschwindigkeit .Wenn diese Option deaktiviert ist, dann sind im Folgeblock 2 BBT Geschwindigkeitseinträge möglich, je nachdem ob der Zug im Vorblock halten musste oder durchfahren konnte.

Vielleicht sollte man alle Aktivieren aber das ist nur ne Idee.

Wie funktioniert es den ohne BBT ?
Sollte eigentlich gut klappen bei 2 Meldern.


Grüße Ralf

Hi,
wichtig für RR ist eine geringe Bemsverzögerung der Lokdecoder (meine steht auf 3) und eine geringe Auslastung des RR-Rechners.

Die Bremsverzögerung ist bei RR eher hinderlich, weil keiner weiß wie lange die Lok nach Stop noch fährt.  Mit BBT halten die Loks dann aber trotzdem sachte an - ohne BBT abbrupt. Bei BBT musst du aber schauen, dass die Loks abhängig von der BBT-Einstellung pro Block oder Fahrstufe usw. ein paar Durchläufe brauchen. Ich arbeite mit der Einstellung "pro Fahrstraße" und reduziere die max. erlaubte Korrektur nach ein paar Fahrübungen. Mit der Zeit halten die Loks cm-genau.

Das zweite Problem ist die Rechner-Last. RR muss ja die Melder verarbeiten und dann den Lokbefehl schedulen. Das kann zeitlich in die Hose gehen mit dem Ergebnis, dass die Loks völlig unbestimmt zu weit fahren.

VG, Steffen

Erstmal Steffen, Hallo,
Im Zuge des testens, habe ich bei den Loks die CV4 = 1 gesetzt, auch wenn das Bremsverhalten nun gruselig ist.
Aber was tur man nicht alles um Erfolg zu haben.

BBT habe ich auf "Geschwindigkeit" gesetzt, werde ich mal auf "Fahrstrasse" setzen.
Bist Du erfahren, mit den Werten Schritte/Start-Intervall/Max. Diff und Korrektur ?

Rechnerlast und meine Hardware:
IB2, Uhlenbrock Loconet Rückmelder, Digikjeis Rückmelder, Power 3,
Decoder Mix aus ESU/D&H./Zimo/UB/Selectrix.
PC Intel I5, 4 Core, 2,6 Ghz, 8 GB Hs.

Sollte eigentlich langen, habe in rocrail.ini auf max. fahrende Züge/Loks auf 5 begrenzt.

Ich werde heute Nachmittag/Abend mal testen, ob Umstellung auf Fahrstrasse was ändert.

erstmal Danke und Gruß
Bernd

Hallo Ralf,
"Reduziere Geschwindigkeit bei Enter" habe ich z.Zt. aus.. Im Zuge des testens abgeschaltet.
Ich werde das heute mal wieder umstellen.



Ohne BBT bringt auch keinen Erfolg, Hab es im kritischen Bereich SBF abgeschaltet -> keine Verbesserung.

Ich melde mich nach erfolglosen oder erfolgreichen Test

VG Bernd

Hallo Bernd,

vielleicht kannst Du über die Tracing-Einstellungen von RocRail etwas erkennen, beispielsweise wie lange es nach dem IN-Event gedauert hat, bis das Stop an die Lok geschickt wurde.
https://wiki.rocrail.net/doku.php?id=rocrailini-trace-de

Viele Grüße
   Andreas

Hallo Andreas,
na da verlangst Du ja was, aber werde mal ein Auge oder 2 drauf werfen.
Vielleicht erkennt man ja wirklich was,

Danke und Grüße
Bernd

Hi,

wenn ich es richtig verstehe, funktioniert das Anhalten grundsätzlich schon, nur erfolgt das immer mal wieder zu spät.

Das Phänomen kenne ich von RR auch. Ich hatte ursprünglich ein altes Windows-Power-Notebook genommen. Da ist RR aber effektiv nicht hinterhergekommen, weil zuviel sonstiges da noch mit reingestört hat (obwohl eigentlich nichts anderes auf dem System lief). Das ging soweit, dass sogar mal eine Weiche nicht umgeschaltet wurde und es damit zu einem Frontalcrash zweier Züge kam. Das Problem lies sich etwas entschärfen, aber nicht wirklich lösen.

Das Grundproblem ist, dass RR effektiv eine Realtime-Anwendung ist, Windows aber kein Realtime-Betriebssystem.

Ich habe daraufhin gewechselt auf 2 Raspberry PI 4 (einen für die Steurung und einen für die Anzeige). Das Raspi-OS ist zwar auch kein Realtime-System, da läuft aber wesentlich weniger####parallel, was sich da einmischt oder Zeit klaut.

Seit dem funktioniert das ganze swoeit zufriedenstellend.

zur Referenz: hier der Thread im RR-Forum (der eigentlich um ein anderes Problem ging, was sich aber hier in dem Zusammenhang dann auch gezeigt hat): https://forum.rocrail.net/viewtopic.php?f=56&t=20210&p=223652#p223652

Grüße Micha

Hi zusammen,

ich kenne das Verhalten auch von linux (mint), wenn der Rechner halb ausgelastet ist läuft die Steuerung nicht mehr rund. Mit neuerem Laptop auch unter Windows gar keine Probleme mehr,

Grüße
Andreas

Hallo Bernd,
ich kann heute Abend gerne ein paar Screenshots machen.

Dein Rechner sollte es von derCPU her schaffen.

Noch eine Frage zur Rückmelder-Erfassung... wie sieht das System hier bei dir konkret aus? Welche Sensor-Hardware? Welcher Bus, wo wird erfasst? Zentrale oder PC?  

Eventuell ist der IN-Melder auch sehr lange in den beteiligten Komponenten unterwegs, bis RR überhaupt was entscheidet. Wie gesagt, ohne BBT und DCC-Bremsverzögerung wird die Lok bei_Erkennen_ der IN-Meldung auf Fahrstufe 0 gesetzt. Die Umlaufzeit dessen resultiert im 'Durchrutschweg'

Bis nachher, Steffen

Habe gestern den Umbau einer Trix Ae 6/6 mit Micromotor und D&H Decoder abgeschlossen und nach dem Einfahren  "eingerichtet", wie ich es immmer mache:
1. CV 48 Kurve auf 0 gesetzt.
2. max. Geschwindigkeit mit Hilfe der Messstrecke eingerichtet.
3. CV 3 (10) Beschleunigung so justiert, dass ich es als ok fand
4. CV 4 (10) Bremsverzögerung so justiert, dass ich es als ok fand
5. Im RR Mid. und Min. Geschwindigkeit so angepasst, dass der Haltepunkt meiner Vorstellung entspricht.
Die Lok bremst so kontuinierlich ab, bis ca. 3 cm vor IN und bremst dann bis zum Halt mit einer Tolleranz von höchsten 5mm.  
Im Bahnhosbereich 3 Melder:
1. Belegtmelder ENTER
2. Red-Kontakt PRE2IN und auch SHORTIN (ca. 35cm vor Halte-Punkt)
3. Red-Kontakt IN (ca. 5cm vor Halte-Punkt)
In den übrigen Blöcken nur 2 Melder :
1. Belegtmelder ENTER
2. Red-Kontakt IN.

Funktioniert auch bei der Gartenbahn sehr Punktgenau (<2cm). Dort verwende ich jedoch nur Reed-Konkate und keine Belegtmelder.

PS hatte früher als Centrale DCC232. Mit den Uhlenbrock Lok-Decoder gab es Probleme wie im Startbeitrag beschrieben. Die reagierten unberechenbar vorallem auf die Bremsbefehle. Die Tran-Decoder hatten keine Probleme damit.
Bei der Gartenbahn hatten die LGB Decoder Probleme die Lenz überhaupt keine.

Hallo Bernd,
ich hatte die selben Probleme mit RR und habe nach reichlicher verzweifelung die Brocken hingeschmissen und mir TC-Silber gekauft.
Da hat es auf Anhieb geklappt.
RR ist wirklich nicht schlecht, aber es hat einfach zuviele Einstellungen und ich möchte mich auf meine letzten Jahre nicht mehr durch unzählige Einstellungen und Möglichkeiten durcharbeiten wo ich am Ende nicht weiß ob alles richtig oder falsch ist. Das überlasse ich lieber den jüngeren, die mehr Nerven und Geduld haben als ich.

Grüsse
Klaus

Moin an Alle,
@ Klaus

Ich hab ein paar Jahre mehr auf dem Buckel. Aber die Jüngeren wissen wohl auch keine Lösung.
Hab zum Glück noch meinen alten TC7(S) aktiv und da kann ich sehen wie es wunderschön funtioniert.
Wird wohl das Ende von RR für mich sein. Schade, weil er eigentlich gut schafft, wenn RR  allerdings im kritischen Bereich SBF Probleme bereitet, nicht schön.

@ALL
erstmal Danke für die Unterstützung.
Habe gestern alle Vorschläge getestet. Alles ohne Erfolg.


-> Uhlenbrock Loconet Rückmelder, Digikjeis Rückmelder

wenn ich in der heutigen Zeit lese, man sollte den Defender deaktivieren, dann stimmt grundsätzlich was nicht mit der Software

Was habe ich noch geprüft:
CPU: nicht über 10% Auslastung
Loconet: mit Loconet Tool von Uhlenbrock getestet. Ohne aktiven RR.
Sobald eine Lok den Meldeabschnitt erreicht, wird der RM sofort, ohne Verzögerung, aktiv.

Heute werde ich das "Blech" nochmal in Richtung USB kontrollieren, nicht das da noch etwas schief ist.

Ansonsten weiß ich nicht weiter und nach einem 1/4 Jahr Fehlersuche wird es auch nervig.
Wird wohl das Ende von RR für mich sein.

Wenn noch jemand tolle Ideen hat, bitte her damit.

bisse denne und Grüße aus dem Norden

Bernd

Hallo Bernd,

ich hatte mal das gleiche Phänomen. Ich hatte am Anfang das Rocrail-Verzeichnis/Ordner auf einem Netzlaufwerk. Ob es dann am WLAN oder dem langsamen NAS lag kann ich nicht sagen. Das Problem war aber sofort weg, als ich es auf die lokale SSD vom Notebook geladen habe.

Ich denke die CPU ist bei dir nicht das Problem, aber eventuell die Festplatte. Hast du eine SSD verbaut?

Wie schnell ist bei dir die Min-Geschwindigkeit bei den Loks eingestellt? Meine Loks stehen bei "min" auf 30 km/h, das funktioniert hervorragend. Meine Rückmeldergleise sind in der Regel 15 cm lang, die Züge kommen aber meist nach ca 4 bis 5 cm zum Stehen.

Viele Grüße
Samuel

Hallo Samuel,
bei mir liegt alles lokal und SSD Festplatte ist verbaut.



Mit der "min" hab ich auch schon genügend rumgespielt.

Danke für die Infos.

VG Bernd

Vielleicht ist es ja die Kommunikation zwischen Zentrale und dem Notebook.

Ich nehme an das Notebook hängt im WLAN? Besteht eine Möglichkeit zum Test es per LAN-Kabel anzuschließen?

VG Samuel

Hallo zusammen!

Ich habe mich mit dem ganzen auch ziemlich lange beschäftigt. Ein automatisches Einmessen der Loks wäre eventuell hilfreich. Aber momentan gehe ich bei RR immer folgendermaßen vor bei neuen Loks:
Mittels einer definierten Messstrecke (Anzeige in km/h) werden die Loks so eingestellt, das sie in den Fahrstufen I-30 km/h, II-80 km/h, III-130 km/h und in IV-Vmax fahren. Zuerst stelle ich über CV 5 die Vmax der Lok plus ca. 10% ein. Danach werden über die Eigenschaften der Lok in RR die % Zahlen für die Fahrstufen eingestellt. Natürlich gibt es kleine Schwankungen, aber alle Loks fahren somit ziemlich gleichschnell. Ist auch hilfreich für Doppeltraktion. Als nächstes wird an einem Haltabschnitt der Auslauf der Lok angepasst. Bei Enter wird die Fahrstufe I ausgelöst. Nach dem IN wird geschaut wie weit die Lok ausrollt. Es wird dann über CV 4 das Bremsverhalten so angepasst, das die Lok möglichst nahe an einer festgelegten Markierung zum stehen kommt.. Somit halten alle Loks relativ gleich, was vor allem sehr hilfreich auf der Drehscheibe ist. Mit BBT habe ich mich noch nicht beschäftigt. Wird wohl eine der nächsten Aufgaben.

Gruß  FraNk

PS: ich nutze bei meiner Bahn immer mehr Lichtschranken zur Steuerung der Blöcke. Damit wird z.B. verhindert, das wegen Kontaktproblemen die Melder später reagieren. Auch brauche ich mir dabei keine Gedanken machen über geschobene Züge. Der Halt erfolgt immer ziemlich genau. Funktioniert auch hervorragend im Lokschuppen.

Moin.
in meinen Augen liegt das Problem an der gesamten Kette an Schnittstellen:
Der Meldesensor muss von der Zentrale erkannt werden -> die Zentrale muss es an Rocrail übertragen -> RR muss eine Entscheidung treffen -> RR muss den Fahrbefehl an die Zentrale übertragen -> die Zentrale muss es in den Gleisausgabe-Puffer legen -> der Decoder muss den Befehl erkennen und steuert dann mit seiner Bremkurve auf 0.
BBT kann diese Kette nicht optimieren, sondern sorgt nur dafür, dass die Lok schon vor diesem Ereignis linear abbremst. Im einge-tune-ten Idealfall landet die BBT-Funktion zeitgleich mit Erreichen des IN-Melders, aber ich glaube soweit sind wir noch nicht. Wenn die Lok eine Bremsverzögerung von 0 hat, dann hält die doch abbrupt an, sobald sie den Befehl erkennt. Die Zeit vom IN-Melder bis zum tatsächlichen Halt ist dann die Zeitdauer der eingangs von mir genannten Kommunikationskette.
Vielleicht ist auch etwas in RR verbogen, sodass der Zwischenschritt 'RR muss eine Entscheidung treffen' klemmt. Vielleicht ist auch der Rocrail-Treiber für die Zentrale das Nadelöhr. Kannst du deine Rocrailkonfig zum Vergleich mal irgendwo für uns ablegen?

VG, Steffen

Edit: ach so und ein Trace von RR wäre schön, da kann man Teile der Kommunikationskette mit Zeitstempeln sehen... ;- )

einen schönen Abend,
es gibt z. Zt. nichts Neues zu berichten.
Bin noch am Testen und versuche BBT noch besser zu verstehen.

Ich werde berichten

VG Bernd

@Steffen

Tja, wenn ich wüsste wo, gerne

Moin,
bisher alles ohne Erfolg.
Hab nun mal nen Plan gemacht, der nur 3 Loks beinhaltet. Bei diesen 3 Loks werde ich
mal einen Decoder Reset machen und neu einstellen.

Was mich immer noch umtreibt, ist die Info aus dem RR Wiki, Definition einer IB.

Query address
The standard query address for getting the current sensor state is 1017.
For Uhlenbrock sensor modules this must be set to 1016.

Ich habe aber nun Uhlenbrock und Digikjeis installiert.
Kann es hier zu einem Problem kommen ?

VG Bernd

Moin in die Runde,
das Problem sitzt, wie so häufig, mal wieder zwischen Tastatur und Stuhl (Pebkac)

Hab meinen Geschwindigkeitsmesser wieder gefunden.
Alle Lok Decoder RESET,
Neu eingemessen VMax 120/VMid 80/VMin 30.
Und siehe da, bis auf ein paar ältere Decoder (Lenz/UB) machen die Loks was sie sollen.

Danke euch allen für Tipps und Tricks

VG Bernd

Danke für die Rückmeldung!

Weiterhin viel Freude,
VG, Steffen