Frage zum Vormerken von Fahrstraßen

[Magnetilo]

Was ist der Unterschied zwischen

fs.active = true
fs.autoActivate = true

und

fs.autoActivate = true
fs.active = true

Nur letzteres funktioniert bei mir wie gewünscht. Im ersten Fall wird zusätzlich eine zuletzt gefahre Fahrstraße wieder aktiv.

[prinz]

fs.activate entspricht hier dem Zustand "Aktiv".
fs.autoActivate entspricht dem Bool "Anforderung vormerken", was wiederum bedeutet, dass, falls die Fahrstraße derzeit blockiert ist, die Fahrstraße dann automatisch aktiviert wird, wenn die Blockade aufgehoben ist. Irgendwo in den Themen gab es mal den Punkt, dass eine Aktivierung in bestimmten Situationen "vergessen" wurde. Dafür wurde dann das autoActivate ergänzt.

Warum bei vertauschter Reihenfolge eine andere Fahrstraße re-aktiviert wird kann ich allerdings nicht sagen, da sich beide Funktionen an das Objekt fs richten.

Grüße,
Wolfgang

[HaNNoveraNer]

Im ersten Fall blockierst du die Fahrstraße und sagst dann, dass sie automatisch wieder aktiviert werden soll wenn sie wieder frei ist. 

Im zweiten Fall sagst du, sie soll aktiviert werden, sobald sie frei ist. Der zweite Befehl ist dann entweder überflüssig, weil sie schon aktiv ist, oder nutzlos, weil sie noch blockiert ist. 

[Goetz]

vor 6 Stunden schrieb Magnetilo:

Nur letzteres funktioniert bei mir wie gewünscht.

Logisch!

fs.active = true setzt die Fahrstraße aktiv oder merkt die Aktivierung vor, falls die Fahrtstraße blockiert ist. 

fs.autoActivate = true merkt eine erneute Aktivierung vor, falls dieselbe Fahrtstraße schon aktiv ist. Mit dieser Option erzwingt man, dass eine Fahrstraße nach Auflösung gleich wieder scharf geschaltet werden soll.

Das eignet sich (nur?) für Gleise im Schattenbahnhof und Selbstblock-Blockstrecken.
Also für solche Abschnitte, die permanent auf Grün stehen sollen, wenn sie nicht gerade besetzt sind. 
Wenn du eine Fahrstraße anforderst, die akkut schon aktiv ist, dann wird deine Anforderung ohne diese Option als "erledigt" abgehakt. 

Eine Fahrstraße muss mit dieser Option aktiviert werden, damit der Effekt greift.
Deshalb ist die Befehlsreihenfolge, die man bei der Umwandlung dieses Befehls bekommt, zwingend und nicht beliebig.

Viele Grüße
Götz

Bearbeitet 2. August 2022 von Goetz
Bild eingefügt

[Old Grey]

Hallo @Goetz,

ich habe gerade versucht eine Selbstblockstrecke wie oben von Dir beschrieben zu erstellen. Ich habe dafür eine einfache Rundstrecke mit 6 Blöcken und zwei Triebwagen erstellt. Dazu einen Schalter, der die Blöcke aktiviert bzw. wieder deaktiviert.

Ich hatte erwartet, daß die Fahrstraße immer aktiviert wird, wenn der wieder Block frei wird. Dummerweise funktioniert es nur in der ersten Runde. Danach sind alle Fahrstraßen wieder deaktiviert.

if controller.state == 1 then
  local t = layout:getRoutesByKeyword("Block")
  for i, Wdh in ipairs(t) do
    Wdh.autoActivate = true
    Wdh.active = true
  end
else
  local t = layout:getRoutesByKeyword("Block")
  for i, Wdh in ipairs(t) do
    Wdh.active = false
  end
end

Wo steckt mein Fehler?

Gruß Old Grey

[Magnetilo]

vor 7 Stunden schrieb Goetz:

Logisch!

fs.active = true setzt die Fahrstraße aktiv oder merkt die Aktivierung vor, falls die Fahrtstraße blockiert ist. 

fs.autoActivate = true merkt eine erneute Aktivierung vor, falls dieselbe Fahrtstraße schon aktiv ist. Mit dieser Option erzwingt man, dass eine Fahrstraße nach Auflösung gleich wieder scharf geschaltet werden soll.

Das eignet sich (nur?) für Gleise im Schattenbahnhof und Selbstblock-Blockstrecken.
Also für solche Abschnitte, die permanent auf Grün stehen sollen, wenn sie nicht gerade besetzt sind. 
Wenn du eine Fahrstraße anforderst, die akkut schon aktiv ist, dann wird deine Anforderung ohne diese Option als "erledigt" abgehakt. 

Eine Fahrstraße muss mit dieser Option aktiviert werden, damit der Effekt greift.
Deshalb ist die Befehlsreihenfolge, die man bei der Umwandlung dieses Befehls bekommt, zwingend und nicht beliebig.

Viele Grüße
Götz

Hallo @Goetz,

ich möchte, dass auf einen Trigger hin, ein Zug ausfährt, auch wenn die Fahrstraße noch blockiert ist.
Das gelingt mir nur, wenn autoActive zuerst kommt. Aus meiner Sicht ein Fehler.

Ich kann das an einem einfachen Kreis, mit einer Lok, zwei Fahrstraßen und zwei Signalen, die jeweils den nächsten Halbkreis aktivieren nachvollziehen.

Bei

fs.active = true
fs.autoActivate = true

sind irgendwann beide Signale immer offen, weil komischerweise die letzte Fahrstraße vorzeitig aktiviert wird.

Bei

fs.autoActivate = true
fs.active = true

habe ich das erwartete Verhalten.

Viele Grüße
Magnetilo

[Roter Brummer]

Hallo Old Grey

local t = {$("Fahrstraße 1"), $("Fahrstraße 2"), $("Fahrstraße 3")}
for i, Wdh in ipairs(t) do
  --[[
  In der Liste müssen alle Fahrstraßen aufgelistet werden. Wenn man also noch mehr Blockstrecken in die Anlage einfügt, müssen deren Fahrstraßen entsprechend hinzu gefügt werden.

  Am Ereignis selber braucht nichts geändert zu werden.

  Neu hinzu gefügte Signale zur Absicherung eines Blocks müssen mit dem Schlagwort "Blocksignal" ausgestattet sein.
  --]]

  Wdh.active = true
end

Das Script stammt aus "ME Blockstrecke" (4F78D142-55BB-4CF9-A8FA-64272A71295D) von mir, wurde dort aber mit der grafischen EV erzeugt. Es können beliebig viele neue Blockstrecken hinzugefügt werden und der Blockbetrieb läuft so lange, bis man irgendwann händisch eingreift.

HG
Brummi

[Magnetilo]

vor 55 Minuten schrieb Old Grey:

Hallo Goetz,

ich habe gerade versucht eine Selbstblockstrecke wie oben von Dir beschrieben zu erstellen. Ich habe dafür eine einfache Rundstrecke mit 6 Blöcken und zwei Triebwagen erstellt. Dazu einen Schalter, der die Blöcke aktiviert bzw. wieder deaktiviert.

Ich hatte erwartet, daß die Fahrstraße immer aktiviert wird, wenn der wieder Block frei wird. Dummerweise funktioniert es nur in der ersten Runde. Danach sind alle Fahrstraßen wieder deaktiviert.

if controller.state == 1 then
  local t = layout:getRoutesByKeyword("Block")
  for i, Wdh in ipairs(t) do
    Wdh.autoActivate = true
    Wdh.active = true
  end
else
  local t = layout:getRoutesByKeyword("Block")
  for i, Wdh in ipairs(t) do
    Wdh.active = false
  end
end

Wo steckt mein Fehler?

Gruß Old Grey

Hallo @Old Grey,

füge mal print-Anweisungen hinzu. Dann kannst Du sehen, wann was ausgeführt wird.

Viele Grüße
Magnetilo

[Goetz]

vor einer Stunde schrieb Magnetilo:

ich möchte, dass auf einen Trigger hin, ein Zug ausfährt, auch wenn die Fahrstraße noch blockiert ist.

Das widerspricht der Fahrstraßenlogik. 
Sinn der Fahrstraßen ist, dass Züge nur in Abschnitte eingelassen werden, die nicht blockiert sind.

 

vor 2 Stunden schrieb Old Grey:

Wo steckt mein Fehler?

Er steckt darin, dass die ganze Mimik überhaupt nicht dafür gedacht ist, in Schleifen permanent aufgerufen zu werden.

Reagiere doch einfach auf das Ereignis "FS wird aktiviert/deaktiviert".
Prüfe, ob sie deaktiviert wurde und aktiviere sie in diesem Fall wieder.
Ganz einfach.

[Magnetilo]

vor 6 Minuten schrieb Goetz:

Das widerspricht der Fahrstraßenlogik. 
Sinn der Fahrstraßen ist, dass Züge nur in Abschnitte eingelassen werden, die nicht blockiert sind.

 

Er steckt darin, dass die ganze Mimik überhaupt nicht dafür gedacht ist, in Schleifen permanent aufgerufen zu werden.

Reagiere doch einfach auf das Ereignis "FS wird aktiviert/deaktiviert".
Prüfe, ob sie deaktiviert wurde und aktiviere sie in diesem Fall wieder.
Ganz einfach.

Hallo @Goetz,

entschuldigung, da habe ich Müll geschrieben. Richtig muss es heißen:

Ich möchte, dass auf einen Trigger hin, ein Zug ausfährt. Falls die Fahrstraße noch blockiert ist, dann soll der Zug ausfahren sobald sie frei ist.

Also genau das, wofür es AutoActive gibt.

Kann ich Dir meinen Kreis mal schicken?

[EASY]

Hallo,

vor 7 Stunden schrieb Magnetilo:

Ich möchte, dass auf einen Trigger hin, ein Zug ausfährt. Falls die Fahrstraße noch blockiert ist, dann soll der Zug ausfahren sobald sie frei ist.

... und genau das macht...

vor 17 Stunden schrieb Goetz:

fs.active = true setzt die Fahrstraße aktiv oder merkt die Aktivierung vor, falls die Fahrtstraße blockiert ist.

... die Fahrstraße wird dann freigegeben, wenn die Blockade z.B. durch eine andere Fahrstraße aufgehoben wird.
Wenn Du über einen (externen) Trigger arbeitest, brauchst Du "AutoActive" nicht.

vor 17 Stunden schrieb Goetz:

fs.autoActivate = true merkt eine erneute Aktivierung vor, falls dieselbe Fahrtstraße schon aktiv ist. Mit dieser Option erzwingt man, dass eine Fahrstraße nach Auflösung gleich wieder scharf geschaltet werden soll.

... dadurch ersparst Du Dir einen neuen (externen) Trigger... dies erledigt die Fahrstraße von sich aus.

P.S. Ich habe noch nicht viel Erfahrungswerte mit Fahrstraßen... aber dies wäre meine Interpretation dieser beiden Befehle.

Gruß
EASY

[Goetz]

vor 11 Stunden schrieb Magnetilo:

Also genau das, wofür es AutoActive gibt.

Wenn du das meinst, dann fürchte ich hast du meine Beschreibung nicht sehr aufmerksam gelesen.
Das tut nämlich etwas anderes. Für diese Option ist nicht von Bedeutung, ob die FS blockiert ist, sondern ob sie aktiv ist.

Wenn du eine aktive Fahrstraße ohne diese Option anforderst, dann regiert die EV mit "wurde schon erledigt. FS ist aktiviert".
Die FS wird in diesem Fall nicht für eine erneute Aktivierung vorgemerkt.

Ist die Option hingegen aktiv, dann reagiert die EV mit: "Ich werte nicht, dass sie schon aktiv ist und merke sie für eine erneute Aktivierung bei nächster Gelegenheit vor."

Viele Grüße
Götz

[streit_ross]

Gestatten Sie eine kleine Zwischenfrage, Herr Kollege ?

Das MBS in Version 7 ist nun bald wieder Geschichte. Aber es scheint so, das bis zu deren Ablösung hin die Fahrstraßenlogik hin ein Brocken bleibt, den immer noch nicht jeder schlucken kann. Ich schließe daraus alleine gestützt auf die Menge der Anfragen zu nach wie vor bestehenden Anfragen in Bezug auf Fehlerursachen bei der Erstellung von Fahrstraßen, das dieses mit V7 angebotene Werkzeug kein Erfolgsschlager für die Mehrzahl der Nutzer geworden ist. Mir erschließt sich bis heute nicht die Notwendigkeit der Einführung eines solchen Features. Das mag aber meinem konservativem und meinetwegen auch begrenztem Verstand geschuldet sein. Andererseits erscheint es mir daher um so erstaunenswerter, das es mir nach wie vor gelingt, dass auch ohne Fahrstraßenlogik auf meinen Anlagen Züge ihren Weg von A nach B über 7 und mehr Weichen finden und unterwegs nicht zusammenstoßen. Zugeben muss ich allerdings, dass ich bei meinen "Fahrstraßen" nicht immer die Eisenbahnverordnung der DB praxisgerecht umsetze. Dafür brauche ich mich ja wohl nicht entschuldigen und viel wichtiger noch aus meiner Sicht: Ich brauche viel seltener hier um Rat fragen.. Aber eines ist mir dann doch klar. Was die Konkurrenz schon früher angeboten hat, muss auch das MBS aus Wettbewerbsgründen auch haben - ob es der Nutzer haben will bzw. vermisst hat oder nicht.  Vor allem lässt sich damit eine ganze neue Version gut vermarkten. Solange mir der Herausgeber neben der Regierung nicht den Gashahn zudreht, bleibe ich glücklich mit meiner Version 5. Ach so, vielleicht noch zu einem möglichen Argument, dass ja niemand auf das Fahrstraßenfeature zwingend angewiesen ist. Dann hätte ich allerdings stattdessen andere aus meiner Sicht längst überfällige Verbesserungen anzuführen.

Gruß

streit_ross

 

 

 

 

Bearbeitet 2. August 2022 von streit_ross

[Neo]

Hallo streit_ross,

bei all der weltpolitischen Dynamik aktuell können wir uns wenigstens auf deine immergleiche Kritik zu den neuen Versionen verlassen, danke für diese Konstante

Aber Spaß bei Seite, tatsächlich erkennst du wie bereits selbst vermutet die Situation falsch, denn Fragen zu einem Feature geben allein keine Rückschlüsse auf die Sinnhaftigkeit des Features. Es deutet eher darauf hin, dass die Funktion das Interesse des Nutzers geweckt hat. Mit V5 kannst du sebstverständlich komplexeste Bahnlogiken abbilden, begibst dich dabei aber in einen Dschungel von Ereignissen und Variablendefinitionen. Selbst dir ist klar, dass das nichts für die Masse ist.

Lass mich zum Abschluss auch meinen Lieblingssatz bringen: Wenn du nichts zum Thema beizutragen hast, dann halte dich bitte raus. Magnetilos Fragen werden nicht beantwortet, in dem du in alten Zeiten schwelgst. Und wie immer gilt, wenn du Verbesserungsvorschläge hast, dann bitte immer her damit, aber nutze dafür den entsprechenden Forenbereich.

Viele Grüße,

Neo

[Magnetilo]

vor 8 Stunden schrieb streit_ross:

Gestatten Sie eine kleine Zwischenfrage, Herr Kollege ?

Das MBS in Version 7 ist nun bald wieder Geschichte. Aber es scheint so, das bis zu deren Ablösung hin die Fahrstraßenlogik hin ein Brocken bleibt, den immer noch nicht jeder schlucken kann. Ich schließe daraus alleine gestützt auf die Menge der Anfragen zu nach wie vor bestehenden Anfragen in Bezug auf Fehlerursachen bei der Erstellung von Fahrstraßen, das dieses mit V7 angebotene Werkzeug kein Erfolgsschlager für die Mehrzahl der Nutzer geworden ist. Mir erschließt sich bis heute nicht die Notwendigkeit der Einführung eines solchen Features. Das mag aber meinem konservativem und meinetwegen auch begrenztem Verstand geschuldet sein. Andererseits erscheint es mir daher um so erstaunenswerter, das es mir nach wie vor gelingt, dass auch ohne Fahrstraßenlogik auf meinen Anlagen Züge ihren Weg von A nach B über 7 und mehr Weichen finden und unterwegs nicht zusammenstoßen. Zugeben muss ich allerdings, dass ich bei meinen "Fahrstraßen" nicht immer die Eisenbahnverordnung der DB praxisgerecht umsetze. Dafür brauche ich mich ja wohl nicht entschuldigen und viel wichtiger noch aus meiner Sicht: Ich brauche viel seltener hier um Rat fragen.. Aber eines ist mir dann doch klar. Was die Konkurrenz schon früher angeboten hat, muss auch das MBS aus Wettbewerbsgründen auch haben - ob es der Nutzer haben will bzw. vermisst hat oder nicht.  Vor allem lässt sich damit eine ganze neue Version gut vermarkten. Solange mir der Herausgeber neben der Regierung nicht den Gashahn zudreht, bleibe ich glücklich mit meiner Version 5. Ach so, vielleicht noch zu einem möglichen Argument, dass ja niemand auf das Fahrstraßenfeature zwingend angewiesen ist. Dann hätte ich allerdings stattdessen andere aus meiner Sicht längst überfällige Verbesserungen anzuführen.

Gruß

streit_ross

 

 

 

 

Dem möchte ich kurz widersprechen. Die Fahrstraßen sind ein absolut geniales Feature.

Und der Grund, warum ich noch nicht voll den Durchblick habe, mag daran liegen, dass ich das Modellbahnstudio erst vor ein paar Wochen kennengelernt habe.

Aber auf die Fahrstraßen würde ich nicht mehr vberzichten wollen. Absolut empfehlenswert.

[BahnLand]

Hallo zusammen,

auch ich bin der Meinung, dass die Fahrstraßen ein sehr wichtiges Feature der Version 7 darstellen und unbedingt beibehalten werden müssen. Ich habe zwar schon lange nichts mehr mit Fahrstraßen gemacht, da ich momentan - neben "Bahn-fremden" Aktivitäten - schwerpunktmäßig mit dem Bau des Railjet-Wagenzuges beschäftigt und daher bezüglich der Funktionalität der Fahrstraßen möglicherweise nicht auf dem aktuellen Stand bin.

Da die Fahrstraßen aber momentan in 4 Threads sehr intensiv diskutiert werden ("Fahrstraßen", "Frage zum Vormerken von Fahrstraßen" (dieser Thread), "Programmierung von Fahrstraßen", "Konkurrenz von Zügen bei Bahnhofsausfahrt"), möchte ich noch einmal meine Realisierung in diesem Beitrag vom Oktober letzten Jahres hinweisen, ohne auf die konkreten Fragen aus den oben genannten Threads explizit eingehen zu wollen.

Die dort beschriebene Anlage besteht aus 3 identischen vorgefertigten Bahnhofsmodulen, die jeweils vordefinierte Fahrstraßen und eine funktionsfähige Gleisbildsteuerung enthalten. Diese wurden über die Gleisstummel an ihren Enden miteinander verbunden. Hierauf fahren 6 Züge, die sich im Vollautomatik-Modus ihren Weg in den nächsten Bahnhof selbst suchen und sich dabei mit den anderen Zügen über die Aktivierung der jeweiligen Fahrstraßen koordinieren.

Es gibt auf dieser Anlage 3 Stufen der Koordinierung:

In der 1. Stufe sucht sich der Zug zunächst einen Zielbahnhof, dessen aktuelle Gleisbelegung (einschließlich vorgemerkter Reservierungen) eine weitere Gleisreservierung für diesen Zug erlaubt. Dies ist nur eine Kontingent-Reservierung ohne eine konkrete Festlegung auf ein bestimmtes Gleis im Zielbahnhof.

Ist diese Reservierung erfolgreich, kann in der  2. Stufe die Fahrstraße bis zum Einfahrsignal in den Zielbahnhof  festgelegt und zur Freigabe angefordert werden. Diese Fahrstraße umfasst auch das hinter dem Ausgangsbahnhof befindliche Weichenfeld, für dessen Passage sich der Zug nicht explizit mit möglichen weiteren konkurrierenden Zügen koordinieren muss (dies besorgt die Fahrstraßensteuerung des Modellbahn-Studios automatisch).

Nähert sich der Zug dem Einfahrsignal des Zielbahnhofs, sucht er sich in der 3. Stufe ein "freies" Gleis im Bahnhof aus (dieses muss ja vohanden sein, weil es bereits als "Kontingent" reserviert wurde) und fordert die Fahrstraße in dieses Gleis an, welche wiederum das Weichenfeld zwischen dem Einfahrsignal und den Bahnhofsgleisen umfasst. Auch hier übernimmt die Koordinierung mit möglicherweise das Weichfeld gleichzeitig befahren wollenden anderen Zügen wieder automatisch die Fahrstraßensteuerung.

Gerade die Vereinfachung den Ereignissteuerung in den hier beschriebenen Stufen 2 und 3 sind der große Vorteil der in MBS V7 bereitgestellten Fahrstraßensteuerung, die in den Vorgänger-Versionen des Modellbahn-Studios in der Ereignisverwaltung noch mühsam von Hand realisiert werden musste.

Die seinerzeit nur als Entwurf veröffentlichten Anlagen habe ich nun final veröffentlicht:

Einzelnes Bahnhofsmodul:    411EA6C5-36E3-49A3-9BB4-1084C02A9E5A
Komplette Demo-Anlage:     8DE83A85-E844-482C-AD3C-E2C18633EFCA

Der im oben genannten Beitrag zur Modul-Anlage beschriebene Fehler, dass auf der Anlage nicht mehr als 3 Module untergebracht werden konnten, wurde von @Neo behoben. Ob sich bezüglich meines damaligen Vorschlags, die "Reparatur" von durch Verschieben der Gleiskontakte ungültig gewordenen Fahrstraßen zu vereinfachen ("Refresh"), inzwischen etwas getan hat, weiß ich nicht.

Viele Grüße
BahnLand

Bearbeitet 3. August 2022 von BahnLand