Bahnübergänge mit Fahrstraßen steuern

[Phrontistes]

Hallo @Neo,

im Hinblick auf diese Diskussion und weil ich schon es schon seit einer Weile vermisse (z.B. um schon bei der Anforderung einer Fahrstraße zu verhindern, dass ein für einen anderen Zug bereits geschlossener Bahnübergang in Bahnhofsnähe geöffnet wird) rege ich an, das Ereignis "Fahrstraßenstatus hat sich geändert" einzuführen.

Beste Grüße

Phrontistes

[Goetz]

Hallo @Phrontistes,

Es fehlt nur "FS wurde vorgemerkt".
Und wenn du eine FS für die Ausfahrt aus dem Bahnhof vormerkst, kannst du auch zugleich den BÜ gegen das Öffnen absichern.

Alternativ kannst du vor Öffnen des BÜ den Status der FS für die Bahnhofsausfahrt prüfen:

Viele Grüße
Götz

Bearbeitet 6. Juni von Goetz
Ergänzungen

[Phrontistes]

Halo @Neo,

einfacher in der Umsetzung: Du löst den vorhandenen event "Route is activated/deactivated" immer aus, wenn sich route.state ändert (und nicht nur wie bisher, wenn er 0 oder 3 wird). Die vorhandene Bedingung "if route.active" lässt Du wie sie ist. Dann ändert sich für den "Normaluser" nichts. Man kann dann aber (mit Lua) route.state auch dann behandeln, wenn er 1 oder 2 ist geworden ist.

Konkreter Nutzen wäre, dass ich dann bei meiner BÜ-Steuerung (für n BÜs mit jeweils o Gleisen und p Fahrstraßen, die drüberführen und bei der ich die close- und open-requests auszähle) zusätzlich noch darauf reagieren könnte, dass der Zähler zwar auf 0 steht, in Kürze aber wieder auf 1 springen wird. Konsequenz: Ich öffne den BÜ nicht ,weil öffnen und gleich wieder schließen blöd aussieht und weil es außerdem wegen der Öffnungs- und Schließzeiten knapp werden kann.

Vorbildgerecht wäre eigentlich, die FS erst zu aktivieren, wenn alles BÜs, die zu decken sind, geschlossen sind. Aber es ist halt einfacher, sich an Deine geniale Fahrstraßenlogik anzuhängen.

Beste Grüße

Phrontistes

[Sintbert]

Hallo @Phrontistes und @Neo

Der Vorschlag den Event bei jeder Änderung auszuführen würde wohl in vielen vorhandenen Steuerungen zu unvorhergesehenen Problemen führen, Welche diesen Event zusammen mit dem Check auf FS aktiv verwenden.

Bisher:
Aktivierung der FS: 1x Event mit Test auf FS aktiv = 1
Deaktivierung der FS: 1x Event mit Test auf FS aktiv = 0

Bei Änderung:
Aktivierung der FS: 2x Event mit Test auf FS aktiv = 0 und dann 1x Event mit test auf FS aktiv = 1
Deaktivierung der FS: 1x Event mit Test auf FS aktiv = 0

Viel mehr Sinn ergäbe ein NEUES ELEMENT welches im Fahrweg eingebaut werden kann, z.B. bei einem Bahnübergang.
Dieses könnte auf FS.state = 2 reagieren und einen Event generieren, auf welchen nun der BÜ geschlossen werden kann, verhindert aber zugleich, dass die FS auf state 3 wechselt.
Wenn der BÜ nun geschlossen ist, kann über die Steuerung dieses neue Element umgestellt werden und erlaubt so der FS auf state 3 zu wechseln.

Für Mehrgleisige BÜ müssten dann ensprechenend je eines dieser Elemente pro Gleis verbaut werden. Das selbe kann auch für andere Zwecke verwendet werden, welche auf eine FS reagieren und deren aktivierung verzögern sollen.

Gruss
Sintbert

[Phrontistes]

Hallo @Sintbert,

nein, es würde nach meinem Vorschlag keine unvorhergesehenen Probleme geben. Zwar würde der event "Route is activated/deactivated" in manchen Fällen mehrfach ausgelöst, nämlich falls die action "$("FS-Name").active = true" nicht sofort zum Erfolg (.state = 3 / .active = true) führt, sonst ändert sich aber nichts, wenn man im event "Route is activated/deactivated" weiterhin nur auf .active prüft. Die Prüfung auf .state (mit Lua) wäre "nur" eine neue Möglichkeit.

Ich will auch keine neuen Elemente verbauen (und @Neo wird sie auch nicht konstruieren wollen, wenn es einfacher geht), sondern mich (nicht vorbildgerecht, das weiß ich ja) an Neos Fahrstraßenlogik anhängen. Ich müsste nur ein paar wenige Zeilen Code zusätzlich schreiben und schon würde das bei allen Bahnübergängen funktionieren, denn mein Code ist nicht-redundant und hat keine direkten Objektbezüge.

Dein Vorschlag läuft hinaus, eine vorbildgerechte Fahrstraßensteuerung zu ermöglichen. Das ginge jetzt schon, wenn man etwas trickst und im Fahrweg eine unsichtbare Weiche einbaut, die Ablenkung ins Nirvana schickt und sie in diesem Zustand sperrt. Dann beißt sich Neos Fahrstraßenlogik so lange die Zähne aus (verharrt in .state = 2), bis man die Weiche auf gerade stellt und er sie sperren kann. Probiert habe ich es nicht, weil es mir zu aufwendig ist, es müsste aber gehen.

Beste Grüße

Phrontistes

Nachtrag: Falls Neo diesem Vorschlag folgen sollte, könnte man für eine vorbildgerechte Fahrstraßensteuerung im Zusammenhang mit dem BÜ auch ein Signal (z.B. das BÜ-Überwachungssignal) sperren statt eine unsichtbare Weiche einzubauen.

Bearbeitet 7. Juni von Phrontistes
Nachtrag

[Neo]

vor 8 Stunden schrieb Phrontistes:

Vorbildgerecht wäre eigentlich, die FS erst zu aktivieren, wenn alles BÜs, die zu decken sind, geschlossen sind. Aber es ist halt einfacher, sich an Deine geniale Fahrstraßenlogik anzuhängen.

Sind deine Bahnübergänge über Kontaktpunkte in die Fahrstraße integriert? Dadurch sollten sie ja automatisch geschlossen werden, wenn die Fahrstraße aktiviert wird. Besser ist es, alle zu sichernden Objekte in die Fahrstraße zu integrieren, anstatt über Ereignisse zu gehen.

Viele Grüße,

Neo

[Phrontistes]

Hallo @Neo,

vor 6 Minuten schrieb Neo:

Bahnübergänge über Kontaktpunkte in die Fahrstraße integriert

Welche Kontaktpunkte? Ich baue meine BÜs selbst aus  Straßen, Schienen, Schranken (51F92FDE-3CE1-4EDB-B666-4BF64C3F8305), Ampeln (und im weiteren Sinne BÜ-Überwachungssignalen) usw. Und ich möchte selbst bestimmen, wann - auch bei mehrgleisigen BÜs - die Ampeln umspringen und wann die Schranken in welchem Tempo geöffnet und geschlossen werden - und wann die BÜ-Überwachungssignale auf "frei" schalten, nämlich nur wenn die Schranken geschlossen sind, weshalb sie bei mir nicht Teil der MBS-FS sind.

Beste Grüße

Phrontistes

[Sintbert]

vor 4 Stunden schrieb Neo:

Sind deine Bahnübergänge über Kontaktpunkte in die Fahrstraße integriert? Dadurch sollten sie ja automatisch geschlossen werden, wenn die Fahrstraße aktiviert wird.

Das Problem ist, dass die Fahrstrasse in dem Moment bereits aktiviert ist und der Zug sich in Bewegung setzt. Ein BÜ müsste die FS im State 2 halten, bis er geschlossen ist. Dazu reicht ein Kontaktpunkt nicht aus, oder?

[Phrontistes]

Hallo @Sintbert,

vor 15 Minuten schrieb Sintbert:

Dazu reicht ein Kontaktpunkt nicht aus, oder?

Weist Du, was Neo mit "Kontaktpunkt" meint? Ich rätsle noch immer .

Beste Grüße

Phrontistes

[Goetz]

vor 24 Minuten schrieb Sintbert:

Ein BÜ müsste die FS im State 2 halten

Oder man schließt zuerst den BÜ und aktiviert dann die Fahrstraße, wenn dieser Vorgang beendet ist.
Bei der realen Bahn wird ein BÜ nicht durch das Einlaufen einer Fahrstraße geschlossen. Man schließt zuerst den BÜ. Und dann lässt man die Fahrstraße einlaufen.

[Sintbert]

vor 3 Minuten schrieb Goetz:

Bei der realen Bahn wird ein BÜ nicht durch das Einlaufen einer Fahrstraße geschlossen.

Ja, in der echten Welt steckt da schon einiges mehr dahinter.

Aber, eine FS lässt sich in der echten Welt nicht schalten bis der BÜ geschlossen ist. Und dies fehlt hier. (Zumindest für Signal gedeckte BÜs.)

[Goetz]

vor 1 Minute schrieb Sintbert:

eine FS lässt sich in der echten Welt nicht schalten bis der BÜ geschlossen ist.

Ich fürchte, da irrst du dich.
Fahrstraßen und BÜs sind zwei voneinander unabhängige Systeme.
Ich habe mich da erst neulich bei einem aktiven Fdl und guten Bekannten erkundigt.

Bearbeitet 7. Juni von Goetz
Schreibfehler korrigiert

[Phrontistes]

Hallo @Neo,

als Threadersteller würde ich diese Debatte gerne beenden und nicht länger über einen workaround diskutieren, den ich selbst weiß.

Aus meiner Sicht als Programmierer sieht es so aus: Derzeit setze ich im BÜ die Variable "Count do not open" nur deshalb vor der Anweisung "route.active = true" eins hoch, weil ich nicht weiß, ob "route.active = true" zum state 1, 2 oder 3 führt und ich das im Ereignis "Route is activated/deactivated" zwar prüfen kann, aber eben nur, wenn das Ereignis stattfindet und es findet nicht statt, wenn der state auf 1 oder 2 wechselt. Würde ich den Wechsel auf 1 oder 2 als Ereignis mitbekommen, würde ich bei state = 1 or 2 "Count do not open" eins hochzählen und bei state = 3 (wie bisher, das bekomme ich ja mit) "Count close". Es ginge also eleganter, wenn ich zum richtigen Zeitpunkt (Wechsel auf 1  oder 2) an eine Information käme, von der ich genau weiß, dass sie dem Programm bekannt ist. Nach meinem modifizierten Vorschlag müsstest Du wohl nur eine Einschränkung beim Ereignis "Route is activated/deactivated" beseitigen, damit es nicht nur bei state = 0 / 3 auslöst, sondern immer, wenn state sich ändert.

Beste Grüße

Phrontistes

Bearbeitet 8. Juni von Phrontistes
Noch präziser formuliert nachdem es Leute gibt, die es nicht verstehen wollen

[Goetz]

vor 52 Minuten schrieb Phrontistes:

Könnte ich es prüfen

Du kannst und ich habe dir weiter oben auch gezeigt, wie. 

Dein Pech, dass du mich ignorierst. 

[Hawkeye]

Hallo Zusammen, 

habe mich auch mal mit dem Thema beschäftigt. In einem anderen mittlerweile geschlossenen Thread wurde schon viel darüber diskutiert. 

Hier mal eine Lösung, in der das Signal der Fahrstraße erst auf "Fahrt" geschaltet wird, nachdem der Bahnübergang geschlossen ist. 

Aber @Phrontistes hat nicht unrecht, das es schwierig ist, den Zustand einer Fahrstraße mit einem auslösenden Ereignis abzufragen. Eine Fahrstraße wird mit Zustand 3 freigegeben, wenn die Strecke frei ist, und auch alle (animierten) Weichen (Zustand=2, bei ablaufender Animation) gestellt sind.

Das Ereignis "Fahrstraße wird aktiviert/deaktiviert" wird aber nur bei den Zuständen 3-Aktiv und 0-Inaktiv ausgelöst, aber nicht für die Zustände 1-Blockiert oder 2- Wartend.   

Einen Bahnübergang in die Schaltung einer Fahrstraße zu integrieren, ist nicht ohne weiters möglich, da es sich um eine Animation eines Objektes (Schranke) handelt, das kein Teil einer Fahrstraße ist.  

@Neo  Über eine Kontaktpunkt würden die Fahrstraße aber schon aktiv sein, das Signal auf "Fahrt" stehen und der Zug losfahren, bevor die Schranken geschlossen sind.

Schranken müssten als animierte Weichen ausführt werden, um sie als Gleisstück in eine Fahrstraße einbinden zu können. 

Hier mal eine einfache Lösung. 

Fahrstraße am BÜ freigeben.mbp

VG,

Hawkeye 

Bearbeitet 8. Juni von Hawkeye

[Cafépause]

Eine Schrankenanlage muss nicht in eine signalabhängige Abhängigkeit eingebunden sein, kann es aber. Soviel zum Thema "vorbildgerecht". Und dann auch nur bei Hp-Anlagen. Fü-Anlagen oder Lo-Anlagen sind nicht Teil von Fahrstrassenlogiken. 

Im Studio ist es bei den letztgenannten Anlagentypen aber völlig gleichgültig ob eine Fahrstrasse über den Bü reserviert ist, oder nicht. Erst wenn wie im richtigen Leben eine Zugfahrt über den Bü stattfinden soll, dann muss man darauf reagieren. Und auch erst dann muss ich mit dem Fahrstrassenstatus darauf reagieren. Und hier genügt dann eigentlich auch die Information "Fahrstrassenmodus = 3".

[Phrontistes]

Hallo @Hawkeye,

vor 5 Stunden schrieb Hawkeye:

einfache Lösung

einfach? Auf jeden Fall sehr originell!

Und vielen Dank, dass Du es akzeptierst, wenn der Threadersteller einen Thread schließt. Das machen leider nicht alle. Und Danke für Deine schöne Zusammenfassung meines Feature-Wunsches:

vor 5 Stunden schrieb Hawkeye:

Das Ereignis "Fahrstraße wird aktiviert/deaktiviert" wird aber nur bei den Zuständen 3-Aktiv und 0-Inaktiv ausgelöst, aber nicht für die Zustände 1-Blockiert oder 2- Wartend.   

Genau das hätte ich gerne von @Neo. Dass man state nur mit Lua auswerten kann, ist m.E. ausreichend, d..h. Neo müsste sonst nichts weiter ändern.

Beste Grüße

Phrontistes

[Hawkeye]

vor 19 Stunden schrieb Hawkeye:

Schranken müssten als animierte Weichen ausführt werden, um sie als Gleisstück in eine Fahrstraße einbinden zu können. 

Hallo Zusammen, 

um das mal zu demonstrieren, habe ich mit meinen bescheidenen Blender Kenntnissen eine Demo-Schranke als animierte Weiche gebaut und als Entwurf veröffentlicht. 

Content-ID:  8A240C04-E8EE-48A5-A406-D6601027A268

Und hier eine Demoanlage.

Demo-BÜ als animierte Weiche.mbp

Anders wird es meiner Meinung nach nicht funktionieren. Da die Schaltung des Signal auf "Fahrt" bei Aktivierung einer Fahrstraße sonst nicht verzögert werden kann.

Vielleicht lässt sich ja der ein oder andere Modellbauer der Schranke darauf ein, seine Schranken als "animierte Weichen" nachzurüsten.  

 

VG,

Hawkeye

[Neo]

Hallo,

ich habe die beiden Themen zusammengeführt, um nicht in zwei Threads über das gleiche Thema zu sprechen.

Grundsätzlich wäre die Anpassung des Ereignisses "Fahrstraße wurde aktiviert/deaktiviert" nur eine kleine Anpassung, die sich aber leider nicht einfach umsetzen lässt, da wie Sintbert korrekt erkannt vorhandene Steuerungen überprüft/angepasst werden müssten. Gerade bei Prüfungen auf "not active" würde das Ereignis nun öfter ausgeführt werden.

Abgesehen davon würde es die Logik komplexer machen, da man Weichen über Fahrstraßen steuern kann, für Bahnübergänge aber die EV heranziehen muss. Diese Unterscheidung ist nicht intuitiv. Daher finde ich die Idee, Bahnübergänge völlig generisch über schaltbare Gleiskontakte in Fahrstraßen zu integrieren, sodass sie sich wie Weichen verhalten, deutlich flexibler. Damit ließen sich auch völlig andere Abläufe über Fahrstraßen steuern, solange ein Gleiskontakt Schalterstellungen besitzt und diese gesperrt werden können. Diese Logiken gibt es bereits an anderen Stellen, müssen wie Phrontistes vorgeschlagen hat aber noch auf weitere Objekte erweitert werden. Das lässt sich alles bewerkstelligen.

Viele Grüße,

Neo