![]() |
![]() |
||
RocRail |
bidibSlotserverAktionenInitialisierungAutomatikEinmessenxmlScriptraspberryRCPSRCPAlternativen
Pfad: mknetz/Eisenbahn/Digital/RocRail |
||
Impressum |
|
Vor dem Start der Züge müssen Weichen, Signale, Rückmelder und Blockbelegungen initialisiert werden.
Unter 'Automatik' gibt es die Möglichkeit, alles zurückzusetzen.
Im Bahnhof Hohenecken finden Zugbegegnungen statt, die auch ein Umsteigen der Reisenden ermöglichen sollen. Dazu soll der Zug auf Gleis 1 so halten, dass er am Bahnsteig rechts des Empfangsgebäudes steht und gerade den Übergang zu Gleis 2 freigibt. Das soll unabhängig von Zuglänge und Einfahrtsrichtung gelten. Der Zug auf Gleis 2 hingegen soll symmetrisch zum Übergang halten. Auch hier unabhängig von Zuglänge und Einfahrtsrichtung.
Als physikalische Melder stehen Strommelder in Gleis 1 und Gleis 2 zur Verfügung, dh. die Spitze eines Zuges wird bei der Einfahrt in ein Gleis erkannt. Das gelingt nur, wenn die erste Achse genügend Strom leitet. Die Strommelder stellen das Rocrail-enter-Ereignis dar. Gebremst wird beim in-Ereignis. Es wurden für jedes Gleis ein 'virtueller' in-Melder definiert, der über Timer zug- und richtungsabhängig ausgelöst wird. Zwei Skripte, für jedes Gleis eins, realisieren die Idee. Da die Geschwindigkeiten und Bremswege der Züge eingemessen wurden, halten die Züge mit geringen Abweichungen so wie sie sollen.
Wir benutzen im EMK Rocrail-Blöcke für Bahnhofsgleise und Streckenblöcke. Verbunden sind die Blöcke durch Weichenbereiche, die ebenfalls über Stromfühler überwacht werden. Rocrail durchfährt einen Block mit anschließender abzweigender Fahrstraße mit verminderter Geschwindigkeit. Das passt bei uns mit unseren langen Streckenblöcken nicht so richtig. Aus diesem Grund haben wir bei den Rocrail-Eigenschaften unter 'Automatik' die Option 'Keine Geschwindigkeitsänderung bei Weichen' angehakt. Jetzt wird der Block mit anschließender abzweigender Fahrstraße mit Reise-Geschwindigkeit durchfahren. Das ist gut. Schlecht ist, dass die Geschwindigkeit in der anschließenden abzweigende Fahrstraße dann zu hoch ist. Gesucht ist also eine Möglichkeit, die Geschwindigkeit einer Lok in einer Fahrstraße einzustellen.
Im Folgenden wird eine Lösungsmöglichkeit vorgestellt.
In einem erstem Schritt soll die Id der durchfahrenden Lok ermittelt werden. Hierzu benutzen wir die Möglichkeit Dynamischer Text. Wir erstellen also zu dem Weichenbereich, hier HoW4, ein Text-Objekt 'txHoW4'.
Zu diesem Textobjekt wird eine Aktion 'LokHoW4' definiert, die die richtige Lok-Id einträgt.
Die Aktion wird ausgelöst durch die betroffenen Fahrstraßen. In diesem Kontext ist die Variable %lcid% passend belegt.
Der nun bekannten Lok kann jetzt über eine von dem entsprechenden Rückmelder, hier rHoW4, ausgelöste Aktion 'vHoW4' der Geschwindigkeits-Befehl erteilt werden.
Die Aktion ist ein xml-Skript.
Die Aktionssteuerung wird durch den Rückmelder, der den Weichenbereich überwacht, ausgelöst.
Im folgenden Bild sieht man wie die Fahrstraße von SHoKs nach HoG2 gestellt ist. Die Verriegelung der Fahrstraße hat die Zugnummer (Lok-Id) in die Textvariable in der Mitte des Bilds übertragen.
Das Bild gehört zur Fahrt HoG2 nach SHoKs. Der Rückmelder rHoW4 hat angesprochen und, wie man sieht, die Geschwindigkeit der Lok/des Zuges wurde auf '50' reduziert. Zusätzlich wird auch aus Debugging-Gründen der Text gelöscht. Der Text kann ganz unsichtbar gemacht werden, wenn man in der Plan-Datei beim Objekt 'txHoW4' das Attribut show="false" hinzufügt.
Beim Testen fiel auf, dass der Zug zunächst noch im Block 'HoG2' auf 80 beschleunigt, im Weichenbereich 50 fährt, um im Folgeblock wieder 80 zu fahren. Will man das vermeiden, so kann man die Ankunfts-und Abfahrts-Geschwindigkeit reduzieren.
Die vorgestellte Lösung funktioniert, aber die gleiche Funktionalität kann anscheinend zumindest für abfahrende Züge auch durch Reduzierung der Ankunfts-und Abfahrts-Geschwindigkeit im Block HoG2 erreicht werden ;-). Für uns bleibt weiterhin die Möglichkeit interessant, an die Id der durchfahrenden Lok zu kommen.
Im Rocrail-Wiki las man bis Oktober 2015:
Rocrail benötigt für jeden Block zwei Rückmeldeereignisse, die definieren, wann ein Zug sich am Beginn eines Blocks befindet und wann er vollständig eingefahren ist. Diese Rückmelder werden als enter und in bezeichnet.Zur Zeit, Oktober 2015, steht dort:
Rocrail benötigt für jeden Block zwei Rückmeldeereignisse, die definieren, wann ein Zug in den Block einfährt und wann er sich (fast)1) am Ende des Blocks befindet. Diese Ereignisse werden als enter (am Beginn des Blocks) und in (am Ende des Blocks) bezeichnet. 1)im Bremsabstand zum gewünschten HaltepunktIm EMK benutzen wir Stromfühler, um Gleisabschnitte zu überwachen. Diese Melder sind nicht punktuell, sondern sprechen sofort mit der ersten Achse des Zuges an und geben den Abschnitt erst mit der letzten Achse frei. Dieses idealtypische Verhalten wird allerdings nur erreicht, wenn alle Achsen des Zuges einen Stromfluss verursachen und wenn kurzzeitige durch Kontaktschwierigkeiten versuchte Zustandsänderungen durch geeignete Software vermieden werden. Das enter-Ereignis wird so in idealer Weise direkt realisiert. Um das auch für das in-Ereignis zu erreichen, muss der angrenzende Gleisabschnitt betrachtet werden, von dem der Zug einfährt. Genau dann, wenn dieser angrenzende Abschnitt frei wird, tritt das in-Ereignis ein. Wenn ein Weichenabschnitt frei wird, so heißt das, dass ein Zug vom Weichenabschnitt in einen angrenzenden Block vollständig eingefahren ist. Welcher Block das ist, lässt sich über die eingestellte Fahrstraße ermitteln. Rocrail verlangt für das Auslösen des in-Ereignisses das Ansprechen eines zugeordneten Rückmelders. Für diesen Zweck werden für die angrenzenden Blöcke virtuelle Rückmelder eingerichtet, die je nach eingestellter Fahrstraße durch das Verschwinden der Belegtmeldung des Weichenbereichs getriggert werden.
Das Vorgehen soll nun am Beispiel erläutert werden. Die Blöcke HoG1, HoG2 und SHoWf grenzen an den Weichenbereich HoW1, der über rHoW1 überwacht wird. In einem ersten Schritt werden nun virtuelle Rückmelder rHoG1i, rHoG2i und rHoWfi eingerichtet. Sie sind im folgenden Bild zu Debug-Zwecken sichtbar, später wollen wir sie unsichtbar machen.
In einem zweiten Schritt wird eine Aktion, hier setInHoW1, definiert, die mit der 'fallenden Flanke' von rHoW1 aufgerufen wird. Die Aktion ruft ein angepasstes xml-Script auf.
In einem dritten Schritt wird die Aktion mit der fallenden Flanke von rHoW1 verbunden.
Das Script xmlSetInHoW1.xml sieht so aus.
<xmlscript> <!-- setzt In-Melder beim Verlassen eines angrenzenden Bereichs --> <!-- in-Melder für Block HoG1 --> <if state="st [SHoWf-]-[HoG1-] = locked"> <then> <fb id="rHoG1i" cmd="on"/> <sleep time="300"/><!-- Debug, kann entfallen --> <fb id="rHoG1i" cmd="off"/> <exit/> </then> </if> <!-- in-Melder für Block HoG2 --> <if state="st [SHoWf-]-[HoG2-] = locked"> <then> <fb id="rHoG2i" cmd="on"/> <sleep time="300"/><!-- Debug, kann entfallen --> <fb id="rHoG2i" cmd="off"/> <exit/> </then> </if> <!-- in-Melder für Block SHoWf--> <if state="st [HoG1-]-[SHoWf-] = locked"> <then> <fb id="rSHoWfi" cmd="on"/> <sleep time="300"/><!-- Debug, kann entfallen --> <fb id="rSHoWfi" cmd="off"/> <exit/> </then> </if> <if state="st [HoG2-]-[SHoWf-] = locked"> <then> <fb id="rSHoWfi" cmd="on"/> <sleep time="300"/><!-- Debug, kann entfallen --> <fb id="rSHoWfi" cmd="off"/> <exit/>q </then> </if> </xmlscript>
Im vierten Schritt müssen bei den angrenzenden Blöcken bei 'Fahrstraßen' die virtuellen Melder für 'in' eingetragen werden. Im Beispiel wird der Zeitgeber2 mit 0ms benutzt, um die Verzögerung durch Timer1 für das enterin-Ereignis von der +-Seite zu umgehen.
Zunächst müssen mal Information gesammelt werden, siehe Links unten.