Goetz

Hi Pete, that's not what you should be striving for. Instead, you should work on gaining a better understanding. Here's an example from your current attempt: The outer condition checks if the variable has a value greater than 1. And when that is not the case, the inner loop checks if it is greater than 0. When both conditions (not > 1, but > 0) are met, the barriers are closed. If the value of Test Barrier 1.trains crossing is not greater than 1, but greater than 0, what is it's value, considering it's always a whole number? And when you close the barriers, it's also time to set the deceleration value to 0. Only then! The afore mentioned aspects are only cosmetic. The behaviour is correct. When it comes to opening the barriers however, matters are a little more serious. You once had a smart system, where you first raised the barriers and then, after a short time delay, set the cars in motion. Now you shuffled that order of events to where it no longer makes any sense. Yyou are making progress. But it's very difficult for me to decide if your understanding improves or if you're just following orders ... Greets Goetz No, Doug, they don't! Because his code only lowers the barriers for the first train.

Dann lass den Zug im vorherigen Abschnitt die nächste Fahrstraße aktivieren. Irgendwann fährt er in diesen vorigen Abschnitt ein. Dabei überfährt er einen Kontakt. Nämlich den vom Signal, dass ihm die Einfahrt erlaubt hat. Das ist dein Ereignis, auf das du reagieren musst um die Fahrstraße für den Folgeabschnitt anzufordern. Wenn "Zug ist da" dein Argument ist, dann nimm "Zug trifft ein" als Auslöser. Ich habe versucht es bildlich darzustellen. Das ist eventuell verständlicher: Ein Zug überfährt das letzte Blocksignal vor der Ausfahrt. Dieses Ereignis nutze ich, um die Fahrstraße vom Ausfahrtsignal zum nachfolgenden Blocksignal zu aktivieren. Denn wenn der Zug das Blocksignal (vorne rechts) überfährt, dann wird er als nächstes die Ausfahrt aus diesem Abschnitt haben wollen. Ich schalte eine Ausfahrt nicht, wenn der Abschnitt bis zum folgenden Blocksignal frei geworden ist. Weil das überhaupt nicht sinnvoll ist. Diese Taktik nutze ich ausschließlich für Blockstrecken, die ich im Selbstblock Verfahren verwalten will. Eine Ausfahrt schalte ich dann, wenn ein eintreffender Zug sie benötigt. Viele Grüße Götz

That's already the case, Pete With the code for track 1 and track 2, you affect the same counter. Trains on both tracks increment your number in barrier 1 when passing the entry contact. And the decrement this one number when they pass the exit contact. What's wrong is your condition for opening the barrier. Your code states that any number larger than 0 will do. Ponder on why that isn't what you want. Greets Goetz

Hallo Hawkeye, Dazu benötigst du aber keine Fahrstraße. Der Zug steht auf dem Kontakt, der ihn im Bahnhof gestoppt hat. Da kannst du ihn "ertasten" Und er kann auch alternativ gleich bei der Einfahrt die Ausfahrt anmelden. Natürlich mit der zeitlichen Verzögerung, die für seinen Aufenthalt im Bahnhof vorgesehen ist. Die Fahrstraße ist für diesen Zweck - du ahnst es sicher schon? - das falsche Mittel. Dass du die Dinge unbedingt von hinten durch die Brust ins Auge angehen möchtest, ist kein starkes Argument für Änderungen im MBS. Viele Grüße Götz

Hallo Andreas, Das brauchst du mit Fahrstraßen nicht mehr prüfen, Andreas. Jede Fahrstraße hat nur ein Ziel. Und mit dem Ziel ist auch der Weg klar definiert, einschließlich aller Weichen und ihrer Stellungen. Damit ist auch die Signalstellung an der Einfahrt eindeutig definiert. Und diese Signalstellung legst du in der Fahrstraße selbst fest. Das erspart dir alle bisher notwendigen Prüfungen. Für Durchfahrten schaltest du jetzt eine Fahrstraße bis zum folgenden Wegpunkt, mit dem Ausfahrsignal als Zwischenstation. Das Ende dieser Fahrstraße ist in der Regel das erste Blocksignal nach der Ausfahrt. Und wenn du diesen Weg stellen kannst, ist auch die Signalstellung für das Vorsignal unter dem Einfahrsignal eindeutig. Du siehst: Solche Situationen werden durch die Fahrstraßen in V7 wirklich einfacher. Viele Grüße Götz

Sie wird ausgewählt, weil du sie aktivierst. Dein System, permanent jeden möglichen Weg zu aktivieren, eignet sich nicht für diese Stelle, Hawkeye. Wenn es nur um die Namen ginge, ja. Aber ich schrieb extra, dass es keine Wortklauberei ist. Weil es eben nicht um die Namen geht, sondern um die drei verschiedenen Situationen: Gleis wird in Abschnitte unterteilt Gleis wird aufgefächert Gleise werden zusammen geführt Diese drei Situationen erfordern drei unterschiedliche Ansätze. Weil aus den drei Situationen drei unterschiedliche Anforderungen resultieren. Falsche Namen führen zu falschen Bildern im Kopf. Und falsche Bilder führen zur Wahl der falschen Mittel. Dieser blaue Abschnitt ist kein Block und darf deshalb auch nicht wie ein Block behandelt werden. Es ist eine Ausfahrt. Und so musst du ihn auch verwalten. Wie eine Bahnhofsausfahrt Deshalb wollte ich die Unterschiede klarstellen. Viele Grüße Götz

Hallo Roland, Genau - das meine ich. Ich habe mir dein Gleisdreieck gestern Abend noch etwas genauer angesehen. Dein Kernproblem ist, dass eine Fahrstraße früher frei wird als die andere. Das hat diese Blockade zur Folge. Wenn die OEBB1163 (unten links im Bild) den Block 1 verlässt und in den Block 2 einfährt, dann ist der Weg für die Siemens - Vectron (oben im Bild) schon frei, während der Weg für die DB V53 (unten rechts) noch blockiert bleibt bis die OEBB1163 die letzte Weiche hinter sich gelassen hat. Und weil hier dichter Verkehr herrscht, wiederholt sich dieser Fall ständig. OEBB1163 und Siemens - Vectron wechseln sich permanent ab, die DB V53 bekommt keine Chance. Du hast damit übrigens ein schönes Beispiel dafür, warum du bei der realen Bahn solche Kreuzungen eher selten findest. Stattdessen führt man das Gleis zum Block 2 nach rechts heraus und in einem großen Bogen über eine Brücke nach Norden. damit der verkehr reibungslos läuft. Viele Grüße Götz

Die sind die logische Konsequenz deiner Methode. Sie eignet sich nicht für Ein- und Ausfahrten, sondern nur für Selbstblock Abschnitte. Wenn mehrere Gleise zusammenkommen, handelt es sich bahntechnisch übrigens um eine Ausfahrt. Wenn ein Gleis sich aufteilt, ist es eine Einfahrt. Deine "Einfahrten" in eine Blockstrecke sind in Wahrheit Ausfahrten aus mehreren Blockstrecken. Das widerspricht unserer alltäglichen Sichtweise, ist aber keine Wortklauberei sondern ein Hinweis darauf, dass der Kern eigentlich die Frage ist, ob ein Gleis aufgefächert wird (wie bei einer Bahnhofseinfahrt) oder Gleise zusammenkommen (wie bei einer Bahnhofsausfahrt)

Hallo Timba, Damit hat er aber nicht gemeint, dass das Studio würfelt. Die Reihenfolge ist weniger zufällig als vielmehr ungeordnet. Das liegt an der Arbeitsweise von in pairs(), welches die Elemente einer Tabelle in einer Reihenfolge durchläuft, die der User nicht beeinflussen kann. (Das ist einer der Unterschiede zur ähnlichen Funktion in ipairs()). Beim Studio kommt hinzu, dass Lua hier nicht alleine werkelt, sondern im Wechselspiel mit der Software (und den Datenstrukturen) des Studios. Kein leichtes Unterfangen, wenn man sich zum Beispiel vor Augen hält, dass Tabellen in Lua alles umfassen, was andere Sprachen in Lists, Tuples, Dictionaries und mehr unterscheiden. Diese Dynamik in Luas Tabellen (Dynamik = variable Größen, Mischung aller Datentypen etc.) hat zur Folge, dass Lua Tabellen per se unsortiert sind. Soweit mein rudimentäres Verständnis der Materie. Ich will damit auch nur sagen, dass die ungeordnete Reihenfolge keine Absicht ist, sondern eine Konsequenz. Viele Grüße Götz

... in some cases, Pete. Craftsmanship for instance. Dexterity and similar skills. But definitely not when you're learning control mechanisms. They are all about cause and effect. Nothing else.

Hallo Hawkeye, Ich vermute, dass du da etwas fehlinterpretierst. Das Studio versucht die Aktivierung bei allen angemeldeten Fahrstraßen. Und manche werden früher frei als andere. Deshalb haben sie scheinbar den Vorzug. Hier wird der Weg ins Gleis 1 zuerst frei. Unabhängig von der Reihenfolge der Anmeldungen. Eine Bearbeitung in der Reihenfolge der Anmeldungen würde z.B. keine Ausfahrt aus einem Bahnhof zulassen, wenn zuvor am anderen Ende des Bahnhofs eine Fahrstraße angemeldet wurde, die noch besetzt ist und erst lange Zeit später frei wird. Weil ein first in, first out Prinzip mehr Nach- als Vorteile hätte, versucht das Studio nicht, die Fahrstraßen in der Reihenfolge der Anmeldungen zu aktivieren. Dort, wo Reihenfolgen erforderlich sind, musst du sie per Tabelle selbst verwalten. Viele Grüße Götz

Hello Pete, in your latest attempt (the small test layout) you are counting the trains going in and out, but without purpose. That was much better before, where at least you checked the number before opening the barriers. All that was missing then was the same check before closing. You need one counter and one counter only for each level crossing. Not four (as you did now) When the first train enters "the zone", you want to close all barriers. When the last train exits "the zone", you want to open them. and therein lies your problem, Pete You try things at random, hoping to strike it lucky. You have no concept and you apply no logic. Don't try to memorise these principles, Pete. You have to understand them. That's the only path to success. Greets Goetz

handelt es sich nicht um einen Block, sondern eine Einfahrt. Deshalb greift hier weder das Selbst-, noch das Zentralblock Verfahren.

Das von Hawkeye verwendete Prinzip entspricht dem Selbstblock Verfahren. Deins entspricht dem Zentralblock Verfahren. Mehr dazu findest du hier:

Hallo Hans, Es geht dabei um Klassen und deren Eigenschaften. Ein Objekt hat beispielsweise Positionswerte. Eine Fahrstraße nicht. Fahrstraßen bilden daher eine eigene Klasse "Route" und gehören nicht zur Klasse "Entity" Der Suchbefehl getEntitiesByKeyword() durchsucht alle Elemente der Klasse "Entity". Er liefert übrigens eine Tabelle zurück. Und wenn man sich anschließend aus dieser Tabelle bedienen will, dann kommt nahezu immer eine Wiederholung ins Spiel. Drum lag es nahe, die korrekte Schreibweise mit einer Wiederholung zu suchen. Viele Grüße Götz

Hello Pete, Grouping has no relevance in the context of EV actions. That's why you want an identical keyword in all four barriers. It enables you to address all four in one loop. And that also clarifies why a keyword is indeed the correct choice (and a number wouldn't be). Anyway, I'm really excited that you still keep me in the dark. I love a good mystery and though I'm pretty certain that the gardener is the evil doer this time, I wouldn't be surprised if you come up with a plot twist at the last minute and present me with an unexpected culprit after all.

Hallo Timba, durch deinen Hinweis, dass table.insert() unter bestimmten Umständen richtig arbeitet, habe ich jetzt als Zwischenspeicher anstelle einer lokalen Lua Variable eine Modulvariable benutzt. Und dann kann man auch in der Reihenfolge remove -> insert arbeiten: Tabelle umschichten 2.mbp

Hello Pete, Your theory is spot on. And your screenshots hold no information as to what's going wrong or why. Greets Goetz

Hallo Roland, das ist selbstverständlich möglich. Aber du musst bitte verstehen, dass Abschnitte, die über verzweigende Weichen führen, keine Blöcke sind. Das sind entweder Ausfahrten oder Einfahrten. Eine Einfahrt hast du dann, wenn Gleise aufgeteilt werden. Eine Ausfahrt ist es, wenn Gleise zusammen kommen. Du kannst solche Stellen nicht wie einfache Blockabschnitte behandeln. Ein ankommender Zug muss die für ihn benötigte Fahrstraße "anfordern". Diese Anforderung geht am besten mittels Gleiskontakt. Und sie kann schon weit vor dem Signal erfolgen, das den entsprechenden Abschnitt deckt. Im Grunde kannst du die Ein- bzw. Ausfahrt schon anfordern, wenn der Zug das letzte Blocksignal passiert. Denn an dieser Stelle ist ja schon klar, wo die Reise hingehen soll. Viele Grüße Götz

Ja, Wolfgang, die gibt es. In der EV findest du unter "Aktionen -> Fahrzeuge" den Befehl "Zug/Fahrzeug von einem virtuellen Depot starten" Eigentlich ist das doch selbsterklärend, oder? Und dann stellst du ein, aus welchem Depot du das Fahrzeug schicken möchtest und ob es das erste, letzte oder ein zufälliges sein soll: Auch klar und verständlich, oder nicht? Viel Spaß beim Ausprobieren Götz

Nur eine Kleinigkeit, Hans. Fahrstraßen sind keine Entities (= Objekte) Mit layout:getRoutesByKeyword() bekommst du sie zu fassen. Woher ich das weiß? Ich habe das hier in der grafischen EV erstellt und dann in Lua gewandelt: Viele Grüße Götz

Verstehe. Mein Umweg über das lokale t war damit Blödsinn. Auf dem Weg erzeuge ich eine Kopie der Objektreferenz, aber keine neue Tabelle. table.remove() funktioniert mit einer Liste, die ich über die Objektreferenz erreiche. Die Funktion entfernt ein Element und lässt alle nachfolgenden aufrücken. Und sie liefert mir auch das entfernte Element zurück. Nur table.insert() scheitert. Wenn ich ein Element ans Ende anhängen möchte, dann kann ich herausfinden, wo das Ende ist und dann ein neues Element an der gewünschten Stelle erzeugen. Das funktioniert zuverlässig. (Und table.concat() klappt auch!) Deine Implementierung von Lua und das Zusammenspiel mit Objektvariablen ist bemerkenswert gut, Neo! Beispieldatei: Tabelle umschichten.mbp

Ja, ist es auch für mein Verständnis.

True, Simon. The flexible track is a different beast altogether and cannot be treated the way I demonstrated with a straight piece and a curve. The mathematics behind the flex track is very different. Even when you place a switch manually ontop of the flex track and then reconnect one flex end to this switch, it produces a rather different curve. Greets Goetz

Daran hänge ich auch gerade, Timba. Ich hatte versucht das letzte Beispiel für dich umzuschreiben: local t = $("Ereignisse").variables["Beispiele"] table.insert(t, table.remove(t, 1)) $("Ereignisse").variables["Beispiele"] = t Das ist etwas kompakter, aber im Prinzip dasselbe, was du auch gemacht hast. Dein Ansatz ist vollkommen richtig. Wenn ich das "standalone" in Lua Demo mache, klappt es einwandfrei: Beatles = {"John", "Paul", "George", "Ringo"} local t = Beatles table.insert(t, table.remove(t,1)) Beatles = t for k, v in ipairs(Beatles) do print(v) end Aber in der EV verliere ich mein Element. Es macht in der EV auch keinen Unterschied, ob ich das Element, welches ich mit table.remove() entferne, zunächst in einem Zwischenträger ablege. table.insert() schreibt das entfernte Element nicht zurück in t. Da scheint etwas kaputt zu sein, weil ich weiß, dass ich dieses Prinzip früher schon mit der EV benutzt habe. @Neo? Viele Grüße Götz