Zustände einer Fahrstraße - Auswertung per EV

[AndreasWB]

Hallo,

vor längerer Zeit wurden ja schon einmal die Zustände von Fahrstraßen beschrieben:

• 0 : Inaktiv, 
• 1 : Blockiert, 
• 2 : Wird aktiviert, 
• 3 : Aktiv

Wie aber kann per EV der Unterschied "Fahrstraße aktiv" und "Fahrstraße durch Fahrzeug belegt" unterschieden werden?
Hat sich da ab V9 etwas weiterentwickelt?

Fragt

Andreas

[Phrontistes]

vor 15 Minuten schrieb AndreasWB:

Hat sich da ab V9 etwas weiterentwickelt?

Nein.

[Phrontistes]

vor einer Stunde schrieb AndreasWB:

Wie aber kann per EV der Unterschied "Fahrstraße aktiv" und "Fahrstraße durch Fahrzeug belegt" unterschieden werden?

Die Zustände kann man (mit Lua) schon unterscheiden, das Problem ist aber, dass es nur ein Ereignis gibt, welches zwischen

• 0/1/2 (= nicht aktiv und gesperrt) einerseits und
• 3 (= aktiv und gesperrt) andererseits unterscheidet.

Den Wechsel von 0 auf 1 oder 2 bekommt man also nicht mit. Das kann nur @Neo ändern.

[AndreasWB]

@Phrontistes,

der Wechsel über alle Zustände von 0 bis 3 ist auch über die EV erfaßbar.
Für meine EVs in meinen Anlagen fehlen aber genau die oben angefragten weiteren Informationen.

Das ist das Thema meines Threads.
Über die Stati weiß isch bescheid - danke.

Das Wesentliche ist aber das Detail, ob insbesondere bei den Zuständen 0 oder 3 ein Zug in der Fahrstraße ist oder nicht.
Das sind genau die Feinheiten, die bei vielen der hier im Forum angefragten Aufaben, zur Lösung beitragen können.

Z. B. im GBS:
Fahrstraße reserviert (aktiv, aber ohne Zug): Ausleuchtung gelb,
Fahrstraße aktiv (belegt mit Zug): Ausleuchtung rot,
Fahrstraße inaktiv (belegt durch Zug, der den "End-"Kontakt erreicht hat) Ausleuchtung weiterhin rot,
Fahrstraße inaktiv (kein Fahrzeug im Bereich der Fahrstraße): keine Ausleuchtung.

Es ist schade, daß die Schöpfer von MBS das bisher noch nicht gesehen haben.

Gruß

Andreas

Bearbeitet 22. Februar von AndreasWB
Beispiel GBS

[Hawkeye]

vor 50 Minuten schrieb AndreasWB:

Z. B. im GBS:
Fahrstraße reserviert (aktiv, aber ohne Zug): Ausleuchtung gelb,
Fahrstraße aktiv (belegt mit Zug): Ausleuchtung rot,
Fahrstraße inaktiv (belegt durch Zug, der den "End-"Kontakt erreicht hat) Ausleuchtung weiterhin rot,
Fahrstraße inaktiv (kein Fahrzeug im Bereich der Fahrstraße): keine Ausleuchtung.

Genau das macht die folgende Demoanlage, die ich schon vor einiger Zeit vorgestellt hatte. Die ist aber hauptsächlich in Lua programmiert. 

GBS-Demo.mbp

VG,

Hawkeye

[Phrontistes]

vor 3 Stunden schrieb AndreasWB:

ob ... ein Zug in der Fahrstraße ist oder nicht

Du meinst offenbar, ob ein Zug sich in einem Abschnitt befindet, den Du als Fahrstraße eingerichtet hast. Das ist aber keine Frage der Fahrstraße, sondern eine der Gleisbelegung. Das muss man auseinanderhalten.

[Hawkeye]

Hallo @AndreasWB, 

vor 10 Stunden schrieb AndreasWB:

Das Wesentliche ist aber das Detail, ob insbesondere bei den Zuständen 0 oder 3 ein Zug in der Fahrstraße ist oder nicht.

vielleicht hilft dir diese Tabelle weiter.

Aus diesen Vorgaben ist die obige Demo-Anlage entstanden.

VG,

Hawkeye

FS Zustand und GBS.pdf

[AndreasWB]

Hallo @Hawkeye,

danke.

Gute Veranschaulichung der Analyse.

Und da alle die von Dir in der Tabelle dargestellten "Zustände" der Fahrstraßen MBS-intern bekannt sind, wäre es wünschenswert, dies auch direkt einfach in der EV ohne zusätzlichen großen Lua-Aufwand nutzen zu können. Denn nicht jeder Nutzer kann mit Programmiersprachen und zugehöriger Umgebung umgehen.

Wenn man sich mal die Entwürfe der Experten von vor einigen Jahren hier im Forum anschaut (Brummi oder Götz ?), sind viele zusätzliche Gleiskontakte notwendig, um die Zustände der Belegung der Fahrstraßen (ähm Blöcke) im GBS korrekt anzuzeigen.

Das muß sich doch entstauben lassen.

Gruß

Andreas

[Phrontistes]

Hallo @Hawkeye,

sehr schöne Darstellung, die keine Wünsche offenlässt. Wie man sieht, kann die GBS-Ausleuchtung nicht allein aus dem Fahrstraßenstatus abgeleitet werden. Die 2. Spalte Deiner Tabelle muss man anderweitig ermitteln - und ebenfalls berücksichtigen.

Frage zur 4. Zeile: Hast Du es mal erlebt, an diesem Zustand nicht selbst schuld zu sein? Ich kenne das nur, wenn ich ein Fahrzeug vom Gleis nehme oder ins Depot teleportiere. Dann kann es natürlich sein, dass eine Weiche zuvor nicht vollständig passiert (und entriegelt) wurde. Und man kann diesen Fehlerzustand auch selbst herbeiführen, indem man (unsachgemäß) Weichen von Hand oder via EV sperrt.

Nur als kleiner Hinweis: Wenn Du Zeile 4 / Spalte 7 um ein Wort ergänzt, ist gedanklich gleich klar, dass hier von der feindlichen Fahrstraße die Rede ist.

Zitat

Prüfung erforderlich, ob sich die Weichen von deaktivierten anderen Fahrstraßen auch entsperrt haben!

Beste Grüße

Phrontistes

[Hawkeye]

Hallo Andreas, 

vor einer Stunde schrieb AndreasWB:

Das muß sich doch entstauben lassen.

Du kannst dich gerne daran versuchen. Aber wenn du zuerst die Anlage baust und nachträglich einen Bezug zum GBS herstellen möchtest, wirst du nicht weit kommen. 

Ich habe von vornherein eine andere Vorgehensweise gewählt. 

Zuerst habe ich alle möglichen Weichen und Gleise mit den GBS-Bausteinen (Variable) ausgestattet und die möglichen Fahrtrichtungsanzeigen an den Bausteinen über Variablen oder Listen eingerichtet. (Hier Märklin C-Gleise und Weichen) 

 

Daraus wird die Anlage (Copy/Paste) gebaut. Die Signale gesetzt, Fahrstraßen eingerichtet und aus den Bausteinen das GBS zusammengesetzt. 

Die Steuerung für die GBS-Anzeigen ist einmalig entwickelt und funktioniert auf jeder Anlage, die aus diesen vorgefertigten "Weichen- und Gleisgruppen" zusammengesetzt wird. So kann schon beim Bau einer Anlage mit GBS die Funktionsweise überprüft und korrigiert werden. 

Hier am Beispiel des Entwurf von Stuttgart 21, mit selbst erstellten Weichen:  FS wird aktiviert, Zug steht noch am Signal

FS ist aktiv, Zug hat die Fahrstraße betreten.  

Die Steuerung braucht nicht angepasst zu werden. 

Ist halt meine eigene Vorgehensweise. Etwas gewöhnungsbedürftig, aber effizient.   

VG,

Hawkeye 

Bearbeitet 23. Februar von Hawkeye

[Goetz]

vor 1 Minute schrieb Phrontistes:

Wie man sieht, kann die GBS-Ausleuchtung nicht allein aus dem Fahrstraßenstatus abgeleitet werden.

Richtig!
Gelb- und Rotausleuchtung haben unterschiedliche Quellen.

Weiter oben hattest du schon ganz richtig geschrieben: "Das muss man auseinanderhalten."

Gelb wird durch die Fahrstraße bewirkt.
Rot durch das Betreten eines Gleisabschnitts. Völlig unabhängig davon, ob eine Fahrstraße an dieser Fahrt beteiligt war!

[Hawkeye]

vor 5 Minuten schrieb Phrontistes:

Frage zur 4. Zeile: Hast Du es mal erlebt, an diesem Zustand nicht selbst schuld zu sein? Ich kenne das nur, wenn ich ein Fahrzeug vom Gleis nehme oder ins Depot teleportiere. Dann kann es natürlich sein, dass eine Weiche zuvor nicht vollständig passiert (und entriegelt) wurde. Und man kann diesen Fehlerzustand auch selbst herbeiführen, indem man (unsachgemäß) Weichen von Hand oder via EV sperrt.

Genau, diesen Zustand führt man meist unbeabsichtigt selbst herbei und bemerkt es nicht. Genau deshalb habe ich die Warnlampe für die Weichen eingefügt.  

Dann kann man die gesperrte Weiche im GBS leichter erkennen.

VG,

Hawkeye

[Phrontistes]

vor 4 Stunden schrieb AndreasWB:

Das muß sich doch entstauben lassen.

Der einzig sinnvolle Wunsch an @Neo könnte sein, dass er den Zustand "Es befindet sich irgendein Fahrzeug auf der Fahrstraße" (Spalte 2 der Tabelle von @Hawkeye) als zusätzlich abfragbare Eigenschaft bei jeder Fahrstraße hinterlegt. Das wäre vermutlich sehr rechenintensiv weil dauernd für jeden sich bewegenden Zug überprüft werden müsste, ob er in den Bereich einer angelegten Fahrstraße einfährt oder diese verlässt. Am Aufwand für die EV ändert sich dadurch nichts.

Das nehme ich zurück, nachdem @Hawkeye unten aufgezeigt hat, wie einfach sich diese Frage bei Bedarf schon jetzt beantworten lässt.

Bearbeitet 23. Februar von Phrontistes
typo; Streichung

[AndreasWB]

Hallo @Phrontistes,

vor 13 Minuten schrieb Phrontistes:

(...) Das wäre vermutlich sehr rechenintensiv weil dauernd für jeden sich bewegenden Zug überprüft werden müsste, ob er in den Bereich einer angelegten Fahrstraße einfährt oder diese verlässt. (...)

Nein.

Es ist nur zum Zeitpunkt der Abfrage relevant.
Versuch' mal, eine inaktive, jedoch mit Fahrzeug besetzte Fahrstraße zu aktivieren. Von MBS bekommst Du die entsprechende Rückmeldung. Also wird der Zustandswechsel von "belegt" vs. "unbelegt" durch MBS intern registriert.
Wie dies funktioniert, bleibt Geheimnis der Programmierer - hat uns aber auch nicht zu interessieren.
MBS tut es jedenfalls ("... sich bewegenden Zug überprüft ...") -> Teilfreigabe von Fahrstraßenelementen.

Nur das auswertbare Ergebnis zählt.

Die verfügbaren Zustandswechsel einer Fahrstraße, die für die grafische EV genutzt werden können, müßten also um die sinnvollen ergänzt werden.

[gmd]

Hallo,
zum einen elegante loesung von Hawkeye !
Fahrstrasse vs Block ist immer die frage. Neo hat fahrstrassen implementiert um mit einer einfachen zieldefinition alle notwendigen weichen etc. automatisch zu schalten um den erstellungsaufwand zu verringern. Wenn man nun eine feinere aufteilung moechte (so wie ich), dann denkt man in bloecken und die werden nicht mit fahrzielen definiert, die sind definiert durch signale und zwischen the signalen befindet sich ein zug oder nicht. Man muss eine "Blockverwaltung" implementieren und die ist nicht unbedingt kompatibel zu dem konzept der fahrstrassen wie es das Mbs definiert. Das naechste problem in der diskussion ist fuer mich die verbindung zum GBS. 

In meiner welt ist die visualisierung gekoppelt zunaechst an den block und wenn man will auch an das fahrziel. Die belegung ist alleine blocksache. Das GBS kann nur eine anzeige pro baustein und man muss sich entscheiden ob man eine blockstruktur order eine fahrzielanzeige darstellen will.  

Wenn ich schreibe - in meiner welt - dann meine ich damit, meine eigene sicht auf die dinge, hat nichts mit meinem programm zu tun und auch nicht notwendigerweise mit dem realen sachverhalt. Hawkeye hat in seiner welt eine loesung gebaut und jeder muss fuer sich entscheiden wie er die gegebenheiten nutzt oder auch nicht.

Auf jeden fall sollte man erst einmal klar die zielsetzung definieren - Block oder Fahrstrasse oder - fuer mich ist eine fahrstrasse eine folge von bloecken, die nicht alle auf einmal gesperrt werden muessen, sondern nur vorausschauend gemaess dem fahrziel und fahrplan eines zuges.

Gruss
Gmd

 

[Hawkeye]

vor 28 Minuten schrieb AndreasWB:

Versuch' mal, eine inaktive, jedoch mit Fahrzeug besetzte Fahrstraße zu aktivieren. Von MBS bekommst Du die entsprechende Rückmeldung. Also wird der Zustandswechsel von "belegt" vs. "unbelegt" durch MBS intern registriert.

Hallo Andreas, 

"belegt" und "unbelegt" sind keine Zustände, sondern eine einfache Prüfung mit vorhandenen Funktionen. 

Daraus ergibt sich, ob (bei Anforderung) eine Fahrstraße aktiviert werden kann (Zustand = 3), oder blockiert wird (Zustand = 1). 

Hawkeye

Bearbeitet 23. Februar von Hawkeye

[AndreasWB]

Hallo @Hawkeye,

Dein eigener Code oder Teil des MBS-Programms?

Ich hatte bei V7 ein Lösung versucht. Wobei die GBS-Ausleuchtung nicht das Start-Thema der Anlage war.
@gmd: Dabei habe ich die Fahrstraßen für die Anzeige im BGS (im Bahnhofsberech) unterteilt in

• Gleisvorfeld (Weichenstraße),
• Bahnhofsgleis

Alles mit wenigen Gleiskontakten und ein paar EVs.

Gruß

Andreas

P.S.
Zur Durchführung der Zugfahrten gibt es im GBS in den Blöcken Start-/Ziel-Taster, so wie sie von Brummi mal (vor Urzeiten) vorgestellt wurden.
Auf der Strecke rufen sich die Fahrstraßen dann selbständig auf (Folge-FS).

Gruß

Andreas

Ks-Signale und Fahrstraßen.mbp

Bearbeitet 23. Februar von AndreasWB

[Hawkeye]

vor 35 Minuten schrieb AndreasWB:

Dein eigener Code oder Teil des MBS-Programms?

Die Funktionen sind Teil des MBS. 

Hier in der grafischen EV:

Und hier die Lua- Anweisungen.

Die Bedingungen in Lua zu definieren ist einfacher als in der grafischen EV.

VG,

Hawkeye

[AndreasWB]

Hallo @Hawkeye,

vor einer Stunde schrieb Hawkeye:

Die Bedingungen in Lua zu definieren ist einfacher als in der grafischen EV.

... für Nutzer mit einiger Programmiererfahrung.

Das ist genau der Grund, weshalb die Status-Informationen erweitert werden sollten um:

• inaktiv, aber trotzdem belegt
• aktiv und belegt

So und nun wollen wir das Thema nicht weiter "zer-"reden.

Gruß

Andreas