Anlagen-Bausteine mit vorgefertigter Ereignissteuerung (Diskussionsforum)

[h.w.stein-info]

Hallo Roter Brummer 

Kann ich auch bestätigen , ich wollte erst sagen es geht . habe bemerkt das ich das falsche Vorsignal genommen hatte bei Blocksignal Hp .

Viele Grüße

HnS

[Roter Brummer]

Hallo @BahnLand,

danke für den Hinweis. Bei mir trat der Fehler auch auf. Im Modelleditor dagegen wurde das Signalbild korrekt angezeigt, ebenso in Blender. Ich habe das Modell dann noch einmal gespeichert und siehe da, auch in der Anlage war der Fehler weg. Komisch das.

Ich habe jetzt das Vorsignal einfach in dieser Form noch einmal neu hochgeladen. Es wäre schön, wenn mir jemand Rückmeldung geben könnte, ob jetzt alles funktioniert.

HG

Brummi

[Roter Brummer]

Hallo @BahnLand,

vielen Dank für deine Fehlermeldung. Bei mir trat der Fehler auch auf. Komischer weise wurde sowohl im Modelleditor als auch in Blender alles richtig angezeigt. Ich habe das Modell dann noch einmal abgespeichert und siehe da: der Fehler ist weg! Komisch das.

Ich habe das Blockvorsignal jetzt noch einmal neu in den Katalog hochgeladen und würde mich freuen, wenn mir jemand Rückmeldung geben könnte, ob jetzt alles funktioniert.

HG

Brummi

Doppelpost durch Absturz des Forums bei mir - nix schlimmes-

Bearbeitet 26. August 2019 von Roter Brummer

[BahnLand]

Hallo Brummi,

also ich bin jetzt völlig ratlos:

Zunächst habe ich im Online-Katalog auf das Veröffentlichungs-Datum geschaut (26.08.2019, 08:32 Uhr), wonach ich davon ausgehe, dass es sich bei dem Modell bereits um die korrigierte (und von @Neo freigegebene) Korrektur handelt. Dann habe ich das Signal wie in den nachfolgenden Bildern gezeigt zunächst 9 mal (in 3 Dreiergruppen aufgeteilt) auf die Bodenplatte gesetzt. In jeder Dreiergruppe habe ich den Signalen von links nach rechts die 3 Signalzusstände 0 = Vr0, 1 = Vr1 und 2 = Vr0 (Zs1) zugewiesen. Die mittlere Dreiergruppe steht auf der Koodinate (0,0) die beiden äußeren Dreiergruppen sind jeweils um 50 mm seitlich nach außen gerückt.

In dieser Konfiguration habe ich mir die Signale nacheinander in den Variationen "Blockvorsignal" (Standard), "Blockvorsignal für Ausleger", "Blockvorsignal für Ausleger ohne Schild", "Blockvorsignal für Mastmontage" und "Blockvorsignal hoch" angeschaut. Das Ergebnis geben die nachfolgenden 5 Bilder wieder:

Blockvorsignal

Blockvorsignal für Ausleger

Blockvorsignal für Ausleger ohne Schild

Blockvorsignal für Mastmontage

Blockvorsignal hoch

Wie man leicht erkennen kann, wird nur die Variation "Blockvorsignal für Ausleger ohne Schild" in allen Stellungen fehlerfrei angezeigt. Beim "Blockvorsignal mit Ausleger" tritt derselbe Fehler wie beim "Blockvorsignal mit Mastmontage" auf. Das Fehlerbild beim "Blockvorsignal" ist jedoch ein anderes, das sich wieder beim "Blockvorsignal hoch" wiederholt.

Total verblüfft mich hierbei, dass das Verhalten in der Mitte (also um die Koordinate y = 0 herum) ein anderes ist, als wenn die Signale seitlich nach außen verschoben sind. Ich wollte daher ausprobieren, ob sich in der Darstellung des Signals etwas ändert, wenn ich es in der angezeigten Stellung einfach verschiebe. Die Anzeige des verschobenen Signals blieb dabei allerdings unverändert (auch der Wechsel der Kameraposition ergab keine Änderung der Anzeigen). Also habe ich eines der 9 Signale kopiert und auf die Seite gestellt (in den obigen Bildern das 10. Signal ganz links). Durch den "Copy&Paste" wurde jedoch das Verhalten des Vorsignals geändert. Es zeigte nun immer das Verhalten der mitteren Gruppe.

Zur Gegenkontrolle habe ich dann mit der "Ersetzen"-Funktion die 3-wertigen Vorsignale gegen das 4-wertige Modell (zusätzlicher Zustand Vr2) ausgetauscht, und, nachdem ich alle Signaldarstellungen hier als in Ordnung befunden hatte, eine erneute Ersetzung (wieder) durch die 2-wertigen Signale vorgenommen. Nun verhielten sich die äußeren Gruppen wie die innere. Beim Versuch, durch neues Zusammenstellen der Signalgruppen aus dem Online-Katalog die ursprüngliche Situation zu rekonstrieren, bin ich dann gescheitert.

Fazit:
Durch zufällige örtlich verschiedene Konstellationen kann sich das betrachtete Vorsignal an verschiedenen Stellen möglicherweise unterchiedlich verhalten. Dieses Phänomen lässt sich aber nicht konkret nachstellen, sondern tritt nur zufälligerweise auf. Rekonstruierbar ist jedoch die Fehlersituation bei der Stellung 1 = Vr1 bei den Variationen "Blockvorsignal mit Mastmontage" und "Blockvorsignal mit Ausleger", die beim 4-wertigen Vorsignal definitiv nicht auftritt.

Was mir noch aufgefallen ist:
Es gibt im Online-Katalog kein Lichthauptsignal ohne integriertes Zs1-Signal (Ersatzsignal zur Weiterfahrt am gestörten Hauptsignal). Ist dies beim Vorbild bei den Lichtsignalen immer vorhanden?

Viele Grüße
BahnLand

 

[streit_ross]

Hallo BahnLand,

vor 1 Stunde schrieb BahnLand:

Es gibt im Online-Katalog kein Lichthauptsignal ohne integriertes Zs1-Signal (Ersatzsignal zur Weiterfahrt am gestörten Hauptsignal). Ist dies beim Vorbild bei den Lichtsignalen immer vorhanden?

zu Deiner Frage habe ich im Internet folgende Antwort gefunden:

Gruß

streit_ross

[h.w.stein-info]

Hallo Roter Brummer

Hier ein paar Bilder zu der Signalbegriffe der Scheiben vom Blockvorsignal [ Ausleger ] .

         ?

 

Ich bin der Meinung das die grünen Lichter des Signals nicht genug nach vorne heraus kommen - somit sind sie nicht mehr sichtbar .

Ist vielleicht die Animation ( Bewegung ) verschoben ? 

Viele Grüße

HnS

Wenn ich hier schonmal bin , ich habe einen Wunsch zum SperrSignal Hoch .

Im Bahnsteigbereich sind diese unterhalb des Daches befestigt - hier werden Teilbereiche getrennt der Züge [ kurze Züge ] 

Vielen Dank , wenn es geht Roter Brummer !

[BahnLand]

Hallo @streit_ross,

vor einer Stunde schrieb streit_ross:

zu Deiner Frage habe ich im Internet folgende Antwort gefunden

Danke für die Information. Leider kann man daraus nicht ersehen, ob das Zusatzssignal Zs1 (oder ersatzweise Zs7) an allen (Licht-)Signalen zwingend vorhanden sein muss, oder ob es auch Signale gibt, wo dieses Zusatzsignal nicht vorhanden ist. Die Konsequenz aus Letzterem wäre das Abwarten des "schriftlichen Fahrauftrags" bei gestörem Signal. Und das könnte dauern. Deshalb vermute ich, dass schon allein aus "prakischen" Erwägungen heraus das Zusatzsignal allen Signalen (zumindest in "freier Wildbahn") zugeordnet ist.

Viele Grüße
BahnLand

[streit_ross]

Hallo @BahnLand

Bei der Bahn ist ja sogut wie alles geregelt. Trotzdem ist es aber in der Realität so, dass es keine Regelungen gibt, die stoisch anzuwenden sind. Deshalb, glaube ich, lässt sich auch die Bahn von dem Grundgedanken leiten, dass dort, wo etwas gebraucht wird, es sinnvoll eingesetzt wird. Das dürfte auch für Zs1 gelten. So wie Du es schon richtig gesagt hast, spielen da die praktischen Erwägungen wohl die Hauptrolle. Als Beispiel hier mal die Situation, dass das Zs7 (Vorbeifahrt an Halt zeigenden Hauptsignal und Fahren auf Sicht bis 400 m hinter dem nächstfolgenden Hauptsignal) angezeigt wird. Wenn nun das nächste Hauptsignal in freier Wildbahn z.B.als Blocksignal in 10 km Entfernung folgt, wäre das eine enorme physische bzw. psychische Anstrengung  für den TF. Hier ist dann in jedem Fall ein Zs1 am Hauptsignal sinnvoller und reduziert den Fahrzeitverlust. Und dann gilt noch ganz allgemein: Was durch den  Gleisplan auf Anlage A notwendig erscheint, ist für die Situation auf Anlage B entbehrlich. Insofern halte ich für das MBS ein Hauptsignal mit integriertem  Zs1 nicht für zwingend erforderlich, als andockbares Zusatzsignal schon eher. Nicht nur in der Frage Zs1 immer am Hauptsignal geht es eigentlich stets um die wünschenswerte Sinnhaftigkeit.

Gruß

streit_ross

[Roter Brummer]

Hallo zusammen,

bis ich den Fehler gefunden hab, mann eh! Es war ein winziger, aber folgenreicher Tippfehler in einigen anim-Dateien.

Jetzt müsste es funktionieren.

HG

Brummi

Zu den Zs1 muss ich mal recherchieren.

[BahnLand]

Hallo zusammen,

ich habe die bisher veröffentlichten Anlagenbausteine nochmals aktualisiert und dabei auch die von @Goetz in diesem Thread formulierten Vorschläge einfließen lassen:

1. Die Sperrgleise wurden zugunsten entsprechender "Nothalt"-Gleiskontakte entfernt. Es wurden jedoch nicht die in den deutschen MBS-Form- und MBS-Lichtsignalen integrierten Gleiskontakte verwendet, sondern eigene Gleiskonrakte dafür spendiert. Der Hauptgrund hierfür ist das Fehlen der integrierten Gleiskontakte bei den schweizerischen MBS-Lichtsignalen, wo sie auch nicht sinnvoll eingebaut werden können, weil die Signale sowohl in der Höhe als auf seitlich zum Gleis in verschiedenen Positionen angesiedelt sein können. Mit dem separaten Gleiskontakt hat man dann noch eine zusätzliche Flexibilität in der Positionierung relativ zum zu schützenden Hauptsignal.
   
   Die Ersetzung ist ein "Nullsummenspiel": An die Stelle des Objekts "Sperrgleis" tritt das Objekt "Sperrkontakt". Das benötigte Ereignis "Sperrkontakt wird ausgelöst" wird durch den Wegfall des Ereignisses "Zug verlässt Sperrgleis" kompensiert.
    
2. Die Ereignisdefinition "Initialisierung" ist weggefallen. Die "Initialisierung" erfolgt nun einmalig implizit beim Passieren eines Brems- oder Haltekontakts durch das zu initialisierende Triebfahrzeug. Dazu habe ich allerdings eine Abfrage auf die Existenz der Triebfahrzeug-Variablen "VSoll" benötigt, die nur einmal "neu angelegt und initialisiert", aber - nach einer danach eventuell händischen Änderung der Sollgeschwindigkeit - bei späteren Fahrten über einen Brems- oder Haltekontakt nicht mehr auf die Initialisierungswerte zurückgesetzt werden darf.
   
   Diese Abfrage kann man aber nicht mit "Bordmitteln" lösen, weil die Abfrage einer Objektvariable auf "[Leer]" deren Existenz bereits voraussetzt. Und auf "nil" kann man nur über ein Lua-Script abfragen. Deswegen habe ich jetzt doch mein "erstes" Lua-Script eingesetzt, obwohl ich die Steuerungen alle möglichst ohne Benutzer-definierte Lua-Scripts realisieren wollte. Die Ereignisdefinitionen "Bremskontakt ..." und "Halte-kontakt ..." enthalten nun jeweils als erste Aktion einen Lua-Script-Aufruf, ...
   
   
   
   ... in welchem die Triebfahrzeug-Initialisierung (Anlegen und Initialisieren der Objektvariablen "VSoll" und "VBrems" sowie Festlegen von Beschleunigung und Bremsverzögerung) nur dann durchgeführt wird, wenn die Objektvariable "VSoll" tatsächlich noch nicht existiert. Die Initialisierungswerte sind hierbei einmalig als Variablen des "obersten" Ereignismoduls hinterlegt.
   
   
   
   An diesen Scripts stört mich bisher, dass man bei einer Änderung (z.B. hinzufügen zusätzlicher Aktionen) immer noch das komplette Script austauschen muss. Nun ja, man kann auch die Bedingung allein als eigenständiges Lua-Script definieren, ...
   
   
   
   ... und dann die eigentlichen Aktionen "ganz normal" in die Zweige für "Bedingung zutreffend" und "Bedingung nicht zutreffend" einfügen - und hätte damit die an der EV-Oberfläche vorhandene Flexibilität voll gewahrt. Wenn man sich dann aber anschaut, was das MBS als Gesamt-Script daraus macht, ...
   
   
   
   ... sieht man gegenüber dem ersten Bild deutlich mehr Code: Anstatt die Aktionen direkt in die Bedingung einzufügen, wird die "Auswertung" der Bedingung zunächst als "Funktion" definiert. Die eigentlich auszuwertende Bedingung wird dann als "Funktonsaufruf" formuliert, dessen Ergebnis "true" dann schließlich zur Ausführung der auf der EV-GUI-Ebene eingeklammerten Aktionen führt.
   
   Frage an @Neo:
   Hat dieser zusätzliche Code Auswirkungen auf die Performance, oder ist dieser "vernachlässigbar"?
   Bezüglich der Flexibilität an der grafischen EV-Schnittstelle würde mir nämlich dieser Ansatz wesentlich besser gefallen als die "starre" Lösung von Bild 1.
    
3. Beim Anlagenbaustein "Streckenblock-Abschnitt" verwende ich nun wie im von @Goetz modifizierten Anwendungsbeispiel von HnS vorgeschlagen eine bei den Triebfahrzeugen mitgeführte Objektvariable "Letztes Hauptsignal", um die ID des Hauptsignals in den nächsten Blockabschnitt mitzunehmen. Hierdurch entfällt die bisher notwendige händische "Verkettung" der aneinandergereihten Streckenblock-Abschnitte. Diese erfolgt nun automatisch beim jeweils ersten Übergang eines Triebfahrzeugs von einem Blockabschnitt in den nächsten und wird in entsprechenden Objektvariablen des jeweiligen Hauptsignals gespeichert. Damit ist ab dem zweiten von einem Blockabschnitt in den nächsten wechselnden Triebfahrzeug auch die "Vorwärtsverkettung" präsent (d.h.der Zugriff auf das Hauptsignal im nächsten Blockabschnitt möglich).
   
   Zur Durchführung der Verkettung lässt man nach dem Aufbau der Blockabschnitt-Kette ein "Arbeitsfahrzeug" von hinten einfahren und bei geöffneten Signalen die komplette Kette passieren. Danach ist die Verkettung abgeschlossen, und der Betrieb mit "ordentlichen" Zügen kann aufgenommen werden.
    
4.  Vom Anwender fallweise zu konfigurierende Objektvariablen sind beim Anlagenbaustein "Streckenblock-Abschnitt" die Variable "Sperrzustand" des Objekts "Vorsignal_voraus" und generell bei allen Anlagenbausteinen die Variable "Vorzeitig schließen" des Objekts "Hauptsignal". Wird die jeweils voreingestellte Konfiguration mit Formsignalen beibehalten, sind die genannten Objektvariablen bereits korrekt vordefiniert. Sollen die Formsignale durch andere Signaltypen ersetzt werden (z.B. durch deutsche oder schweizerische Lichtignale aus dem Online-Katalog), sind für die genannten Variablen möglicherweise andere Werte einzutragen.
   
   Beim am Ort des Hauptsignals stehenden "Vorsignal_voraus" sind dies für den "Sperrzustand" die Werte

   0 für die deutschen MBS-Formsignale (entspricht der Signalstellung 0 = geschlossen)
   -1 für die deutschen MBS-Lichtsignale (Vorsignal mit Dunkelstellung ist separates Modell, das fallweise gegen das "normale" Vorsignal getauscht wird)
   wahlweise 0 oder 16 für die schweizerischen MBS-Lichtsignale (entspricht den Signalstellungen 0 = geschlossen und 16 = aus)
   
   Weitere Einzelheiten dazu findet man in der Beschreibung zum Ereignismodul "Streckenblock-Abschnitt" im gleichnamigen Anlagenbaustein
   
   Mit der Objektvariable "Vorzeitig schließen" vom Typ "Boolescher Wert" spezifiziert man beim Hauptsignal, zu welchem Zeitpunkt dieses beim Passieren eines Zuges geschlossen werden soll. Diese Aktion ist an das Gleiskontakt-Ereignis des Schließkontakts gekoppelt, der in relativ kurzem Abstand hinter dem Hauptsignal angesiedelt ist. Es sind die Werte "true" und "false" mit folgenden Bedeutungen möglich:
   
   false:  Hauptsignal schließt beim Verlassen des Gleiskontakts "Schließkontakt"  (Voreinstellung für die Formsignale)
   true:   Hauptsignal schließt beim Betreten des Gleiskontakts "Schließkontakt"    (für die Lichtsignale zulässige Variante)

Für jeden Anlagenbaustein gibt es eine kleine Demo-Anlage, in der jeweils mehrere Auspägungen des betrachteten Anlagenbausteins integriert sind:

Baustein-Demo Signalhalt.mbp

Die beiden Ausfahrsignale werden mit den Schaltern am rechten Anlagenrand gesteuert.

Baustein-Demo Bahnhofshalt einseitig.mbp

Auch hier gibt es für jedes Signal einen Schalter. Es sollte immer nur ein Zug zum freien Gleis im gegenüberliegenden Bahnhof gestartet werden. Eine "Falschbedienung" wird nicht abgefangen.

Baustein-Demo Bahnhofshalt zweiseitig.mbp

Gleiches Anlagen-Layout wie beim zweiten Beispiel, aber mit in beiden Richtungen befahrbaren Anlagenbausteinen. Entsprechend gibt es doppelt so viele Schalter für eine wahlweise Ausfahrt der gewählten Züge in eine der beiden Fahrtrichtungen. Ein Fahrtrichtungswechsel ist bei jedem in einen der Bahnhöfe eingefahrenen Zug jederzeit möglich.

Baustein-Demo Streckenblock.mbp

Die Züge werden mit dem Schalter rechts gestartet. Nach dem Zurückschalten bleibt das vordere Signal geschlossen, sodass alle Züge nach dem "Aufrücken" zum Stillstamd kommen. Da ich für das "Beenden" der Blockabschnitt-Demo nicht in die Anlagenbausteine selbst eingreifen wollte, beibt das vordere Signal nach dem Zurücksetzen des Schalters nicht wirklich geschlossen, sondern schließt sich sofort wieder nach dem regulären Öffnen durch das Freiwerden des nachfogenden Blockabschnitts, sodass der Zug davor nicht losfahren kann.

Zur Verdeutlichung der unterschiedlichen Verhaltensweisen bei den verschiedenen Signaltypen, sind von den vorhandenen 6 Blockabschnitten jeweisl 2 mit deutschen Formignalen, deutschen Lichtsignalen und schweizerischen Lichtsignalen aus dem Online-Katalog bestückt, wobei in der Mitte jedes Bockabschnitt-Paares das Vorsignal des zweiten Abschntts mit dem Hauptsignal des ersten Abschnitts an einem Ort "gebündelt" ist. 

Die Initialisierung der gegenseitigen Verkettung der aufeinanderfolgenden Hauptsignale ist nicht Bestandteil dieser Demo. Diese sollte auch nicht mit bereits belegten Blockabschnitten erfolgen, sondern mit einer "Arbeitslok" bereits unmittelbar nach dem Zusammenbau der Blockabschnitt-Kette vor der Einfahrt der "regulären" Züge durchgeführt werden (siehe dazu den obigen Punkt 3).

Viele Grüße
BahnLand

[Neo]

Hallo BahnLand,

vor einer Stunde schrieb BahnLand:

weil die Abfrage einer Objektvariable auf "[Leer]" deren Existenz bereits voraussetzt. Und auf "nil" kann man nur über ein Lua-Script abfragen.

du benötigst Lua hierfür nicht. Wenn eine Objektvariable nicht existiert, dann ist sie nil. Du kannst also einfach in der grafischen EV auf [Leer] prüfen. Ein $("") ist intern auch nur ein nil (ich kann das gern in einer zukünftigen Version gleich nach nil konvertieren).

vor einer Stunde schrieb BahnLand:

Hat dieser zusätzliche Code Auswirkungen auf die Performance, oder ist dieser "vernachlässigbar"?

Die komplexere Bedingung hat keinen negativen Einfluss auf die Performance. Sie ist jedoch falsch definiert bei dir. Eine Skript-Bedingung muss ein Boolean zurückliefern:

return vehicle.variables["VSoll"] == nil

Mir ist aufgefallen, dass das bisher nirgends dokumentiert ist, das werde ich nachholen.

Viele Grüße,

Neo

[BahnLand]

Hallo @Neo,

Danke für sie Informationen.
Mit der generellen Abfrage auf "[Leer]" für eine nicht existente Objektvariable habe ich jetzt die Script-Aufrufe wieder entfernt und die korrigierten Anlagenbausteine nochmal hochgeladen. Auch die dazugehörigen Beipielanlagen habe ich mit den korrigierten Bausteinen versehen. Ich überschreibe die alten Demo-Anlagen im letzten Beitrag bewusst nicht. So kann man die Ereignisdefinitinen der alten und neuen Demo-Anlagen direkt vergleichen. Hier also die Demos mit den aktualisierten Anlagenbausteinen:

Baustein-Demo Signalhalt.mbp
Baustein-Demo Bahnhofshalt einseitig.mbp
Baustein-Demo Bahnhofshalt zweiseitig.mbp
Baustein-Demo Streckenblock.mbp

Viele Grüße
BahnLand

[udokowalleck]

Hallo,

toll, endlich ist ein programmieren immer für die gleiche Sache (z.B. Bahnhöfe ) nicht mehr erforderlich. Das war auch für mich der Hauptgrund V5 zu kaufen. So weit so gut. Deine Erklärung ist auch sehr gut. Nur leider ist die Weiterfahrt im Bahnhof für mich als dummer Mensch ein Problem. Auch die sollte automatisch erfolgen und ebenfalls im selben Modul untergebracht werden. Zum Beispiel soll ein Zug in 90 Sek. weiterfahren (Signal schaltet). Wie stelle ich das an? Freue mich auf deine Antwort.

Oddseta

[BahnLand]

Hallo Oddseta,

gerade weil die Bausteine mehrfach eingesetzt werden können, ist ein automatischer Start des Zuges ohne Überprüfung, ob eine Ausfahrt überhaupt möglich ist, problematisch. Denn in einem Bahnhof mit mehreren Gleisen, können ja mehrere Züge "gleichzeitig" auf dieselbe Strecke ausfahren wollen. Deshalb halte ich nichts davon, in einem solchen Baustein einen "ungeprüften" Start zu implementieren.

Ich habe schon vor, auch "irgendwann" einen Baustein für eine "koordinierte" Ausfahrt zur Verfügung zu stellen. Nur wird dieser etwas komplexer sein. Da muss ich mir noch überlegen, wie ich den am besten realisiere. Wenn die "koordinierte Ausfahrt" realisiert ist, könnte man den deren Anstoß (die Ausfahr-"Absicht" des Zuges) tatsächlich in den Baustein, der den Zug im Bahnhof zum Halten bringt, integrieren, wobei ich aber dann die "Haltezeit"  des Zuges im Bahnhof z.B. als Objektvariable in der Lokomotive hinterlegen würde (dann könnten verschiedene Zugarten verschieden lang anhalten oder sogar ohne Halt durchfahren wollen).

Ich kann Dir aber nicht sagen, bis wann ich diese Bausteine fertiggestellt haben werde, da dies nur eine meiner vielen "Baustellen" ist.

Viele Grüße
BahnLand

@Neo:
Kannst Du bitte diesen und den vorangehenden Beitrag von @udokowalleck in den Thread "Anlagen-Bausteine mit vorgefertigter Ereignissteuerung (Diskussionsforum)" verschieben? Danke!

Bearbeitet 9. September 2019 von BahnLand

[Timba]

vor 1 Stunde schrieb BahnLand:

Da muss ich mir noch überlegen, wie ich den am besten realisiere.

Du wirst ganz sicher eine super Lösung dafür finden, da habe ich gar keine Sorge. Falls es jemand interessiert, wie ich das gelöst habe, kann ich gerne mein Konzept hier erläutern. Im Prinzip funktioniert das so wie dir das vorschwebt, allerdings haben alle Züge dieselbe Haltezeit. Das finde ich bisher ganz in Ordnung. Wäre aber meines Erachtens jetzt mit Lua leicht zu verbessern, wenn es wichtig ist.

 

[fzonk]

Hallo BahnLand,

vom Lesen her hast du dir da schon wieder sehr viel Arbeit gemacht und die Funktionsweise sehr gut beschrieben.

vor 8 Minuten schrieb BahnLand:

(Content-ID des Anlagen-Bausteins: 3B06DA8D-91E6-4012-82B2-06408DEB4854)

Kann ich aber nicht im Onlinekatalog finden, hast du das Modul schon veröffentlicht?

Gruß Frank

[BahnLand]

Hallo Frank,

bin noch dabei.

Viele Grüße
BahnLand

[BahnLand]

Hallo zusammen,

wie Ihr teilweise schon festgestellt habt, gibt es einen neuen "Anlagen-Baustein Kopfbahnhof", der nach einer noch in dessen Kurzbeschreibung benötigten Referenz auf diese Beschreibung nun online ist (Content-ID 3B06DA8D-91E6-4012-82B2-06408DEB4854 - wegen der Referenz musste ich die Beschreibung veröffentlichen, bevor ich den Baustein selbst veröffentlichen konnte). Auch hierzu gibt es ein Demo-Beispiel, bei dem der Baustein sowohl als Gleis eines Kopfbahnhofs als auch als solches eines Endbahnhofs mit angeschlossenem Stumpfgleis realisiert ist.

(zum Vergrößern bitte anklicken)

Demo-Anlage Anlagenbaustein Kopfbahnhof+Endbahnhof.mbp

Die Demo-Anlage besitzt ein kleines "Schaltbrett", auf dem die zum Betrieb notwendigen Schaltelemente installiert sind. Die Anlage wird im Handbetrieb bespielt, indem die Züge und Loks auf dem Schaltbrett über die Signale, bei denen sie stehen, gestartet werden. Die Abläufe auf den durch weiße Flächen unterlegten Gleisen erfolgen automatisch, wobei die mit roter Umrandung gekennzeichneten Gleise jeweils den neuen Anlagen-Baustein repräsentieren, während es sich bei den mit blauer Umrandung markierten Gleisen um Anlagen-Bausteine von Typ "Signalhalt" handelt.

Um das Verhalten der Züge bei unterschiedlichen Eintrittsgeschwindigkeiten zu zeigen, sind den einzelnen Triebahrzeugen folgende Sollgeschwindigkeiten zugeordnet:

Diesellok V200:         250 km/h    (zu schnell - wird bei den einzelnen Anlagen-Bausteinen durch den jeweiligen Sperrkontakt zwangsgestoppt
BR 110:                     200 km/h    (wird ab dem "Einfahrkontakt auf die beim Bremskontakt erwarteten 150 km/h "vorgebremst")
SBB Ae 8/14a + b:    150 km /h   (höchste am Bremskontakt zulässige Geschwindigkiet für ein korrektes Anhalten durch den Haltekontakt)
BR 01-118:                120 km/h   (im Toleranzbereich zwischen 50 km/h und 150 km/h)
SBB RAe TEE II:        160 km/h

Gegenüber den bisherigen Anlagen-Bausteinen ist hier der Einfahrkontakt zur Drosselung "überhöhter" Geschwindigkeiten vor dem Betreten des Bremskontakts hinzugekommnen. Während die übrigen Kontakte (mit Ausnahme des Wendekontakts) alle "feste" Abstände besitzen, kann man den Einfahrkontakt entsprechend der auf der zu betreibenden Anlage gefahrenen Geschwindigkeiten bei Bedarf so weit nach hinten verschieben, dass auch deutlich höhere Geschwindigkeiten (wie z.B. beim ICE) bis zum Bremskontakt auf 150 km/h gedrosselt werden können (der Wendekontakt wird beim Einbau des Anlagen-Bausteins als Endbahnhof-Gleis in das Rumpfgleis verschoben).

Ich habe den Einfahrkontakt auch in die anderen Anlagenbausteine nachträglich eingbaut und deren Beschreibungen entsprechend angepasst. Um bei bestehenden Anlagen in den "Genuss" der Einfahrkontakts zu kommen, müssen die Anlagen-Bausteine entfernt und neu importiert werden. Hierzu ist die bereits existierende Ereignissteuerung des Anlagen-Bausteins vorher zu löschen, damit dieser beim nachfolgenden Import unter derselben Bezeichnung des Ereignis-Moduls neu eingerichtet werden kann.

Sollten auf der Anlage "von außen" auf die Komponenten der Anlagen-Bausteine zugreifende Referenzen bestehen, müssen diese nach dem Einbau der neuen Anlagen-Bausteine wiederhergestellt werden.

Noch eine Bitte an @Neo:
Könntest Du bitte diesen Beitrag und die Antwort dazu aus dem Thread mit den Anlagen-Beschreibungen hierher in den Diskussions-Thread verschieben?  Danke.

Viele Grüße
BahnLand

[BahnLand]

Hallo zusammen,

der nächste Anlagen-Baustein, den ich mir vornehmen möchte, ist der Ablaufberg.

Meine bisherige Realisierung beruhte darauf, dass die über den Berg zu schickenden Wagen alle mit Nummern bezeichnet waren, und aufgrund der Abarbeitung der Nummernsdchleife diese auf 100 (und damit auch der Güterwagenpool auf 100) begrenzt war. Mit der Lua-Funktion

layout:getVehicleGroup(Triebfahrzeug) ,

wobei als Argument "Triebfahrzeug" die schiebende Lok des über den Ablaugberg zu drückenden Güterzuges eingesetzt wird, kann man sich nun alle im Zug vorhandenen Wagen in einer Liste ausgeben lassen und diese abarbeiten. Damit kann die Einschränkung auf rein numerische Fahrzeugbezeichnungen und die Begrenzung auf 100 Fahrzeuge aufgehoben werden.

Im Vorgriff auf diesen neuen Anlagen-Baustein habe ich ein paar Versuche gemacht und bin dabei auf ein paar Eigenarten gestoßen, die ich so nicht verstehe.

Basis für meine Vesuche ist eine kleine Testanlage, die ich auch hier zum Nachvollziehen der von mir beobachteten Effekte hinzufüge:

Fahrzeuglisten.mbp

Die Züge stehen auf 3 Bahnhofsgleisen und können über die Signale jeweils in beiden Richtungen losgeschickt werden. Beim Ausfahren eines Zuges wird mit dem automatischen Stellen der Ausfahrweiche auch die gegenüberliegende Einfahrweiche entsprechend gestellt, sodass der ausgefahrene Zug immer auf seinem eigenen Gleis wieder einfährt, ohne dass man sich um die Weichenstellungen kümmern muss. Allerdings darf ein weiterer ZUg deshalb immer erst dann ausfahren, wenn der erste Zug bereits wieder eigenfahren ist.

Auf der gegenüberliegenden Seite des Gleisovals sind 3 Gleiskontakte positioniert, welche jeweils als Objektvariable eine Liste (Gleiskontakt 1), eine Tabelle (Glleiskontakt 2) und beides (Gleiskontakt 3) besitzen. Diese sollen beim Überfahren durch einen Zug jeweils mit dessen Fahrzeugen bestückt werden. Hierbei möchte ich die Liste/Tabelle des überfahrenen Gleiskontakts bzw. den Gleiskontakt selbst sowie den befahrenden Zug (dessen Triebfahrzeug) als Parameter an ein benutzerdefiniertes Ereignis übergeben, in dem dann mittels der oben angegebenen Lua-Funktion die Fahrzeuge des Zuges in die Liste oder Tabelle übetragen werden, um dann in weiteren über die grafische EV-Schnittstelle definierten Ereignisdefinitionen ausgewertet werden zu können.

Die Objektvariablen der Gleiskontakte habe ich dabei wie folgt initialisiert:

Die Definitionen für die Gleiskontakte 1 und 2 sind hier absichtlich so gewählt, um später aufzeigen zu können, dass sie nicht aktualisiert werden. Die Objektvariablen des Gleiskontakts 3 werden dagegen tatsächlich korrekt aktualisiert.

Die durch die Gleiskontakte ausgelösten Ereignisdefinitionen dienen nur dazu, die als benutzerdefinierte Ereignisse definierten Lua-Scripts mit den am jeweiligen Gleiskontakt als Auslöser identifizierten Objekten als Parameter aufzurufen:

Die in den benutzdefinitierten Ereignissen hinterlegten Lua-Scripts basieren auf den Beispielen aus diesem Beitrag von @EASY (vielen Dank dafür!). Ich habe diese wie folgt abgewandelt:

Bei den Tests hat sich dann herausgestellt, dass die Beispiele mit den Gleiskontakten 1 und 2 nicht funktionieren. Betrachtet man hier das Ereignisprotokoll, ...

... erkennt man, dass die Listen im jeweiligen Lua-Script selbst zwar korrekt erzeugt werden, die Ergebnisse aber in den Objektvariablen der Gleiskontakte 1 und 2 aber nicht ankommen. Ich vermute, dass das daran liegt, dass anstelle der in den aufrufenden Ereignisdefinitionen hinterlegten Parameter "([Gleiskontakt].Fahrzeugliste)" und "([Gleiskontakt].Fahrzeugtabelle)" in den aufgerufenen Lua-Script-Ereignisdefinitionen "irgendwie" deren Inhalte übergeben wurden (Anzeige "(3 Elemente)" im Ereignisprotokoll). Und das verstehe ich nicht.

Nur beim Gleiskontakt 3 wird dieser als Paramter korrekt übergeben, sodass auch hier nach der Bearbeitung das Ergebnis korrekt in den Objektvariablen des Gleiskontakts hinterlegt ist:

Unabhängig davon ist mir noch eine weitere "Ungereimtheit" aufgefallen:

Wenn ich in der Testanlage die Züge nach rechts ausfahren lasse, sodass sie die 3 Gieskontakte in der Reihenfolge 1+2+3 passieren, werden auch genau die 3 zugehöigen Ereignisprotokolle in der richtigen Reihenfolge angezeigt. Die Reihenfolge stimmt zwar auch in der entgegengesetzten Richtung (hier 3+2+1), doch werden in dieser Richtung im Ereignisprotokoll zufallsgesteuert einige Gleiskontakt-Ereignisse mehrfach aufgelistet:

Im obigen Protokoll werden die Ereignisse sowohl für den Gleiskontakt 2 als auch für den Gleiskontakt 1 mehrfach aufgelistet, wobel die Anzahl der Wiederholungen bei unterschiedlchen Durchläufen zufällig ist. Und es tritt ausschließlich bei der Fahrt im Uhrzeigersinn auf. Entgegen dem Uhrzeigersinn triitt jedes der 3 Ereignisse im Protokoll immer korrekt genau einmal auf.

Mir ist jetzt allerdings nicht klar, ob die Ereignisdefinitionen nun tatsächlich mehrfach ausgeführt wurden, oder ob es sich nur um einen Ausgabefehler in der Protokolldatei handelt. Denn eine Wiederholung der Ereignisauswertungen führt in der hier vorliegenden Konstallation zu keinem geänderten Ergebnis.

Viele Grüße
BahnLand

[Goetz]

Hallo BahnLand,

die Argumente FzListe bzw. FzTabelle enthalten in den Ereignissen für die Kontakte 1 und 2 eine Kopie deiner Tabellen aus den Kontaktpunkten. Diese Kopie wird mit dem Inhalt der temporären Liste "namen" befüllt, aber nicht das Original. Damit versickert FzListe bzw. FzTabelle im Lua Code und wird an niemanden im MBS weitergereicht. Du erkennst das daran, dass das Ereignis "Objekt Variable wird gesetzt" nicht getriggert wird.

Im Kontakt 3 übergibst du nur den Kontakt selbst als Argument und sprichst dann im Code direkt die Tabelle in diesem Objekt an. Damit erreichen die Daten das gewünschte Ziel.

Viele Grüße
Götz

Bearbeitet 1. Dezember 2019 von Goetz
Ergänzungen in der Erklärung

[BahnLand]

Hallo @Goetz,

vielen Dank für Deine sehr hilfreiche Antwort.
Erst hierdurch bin ich darauf gekommen, dass ich bei den Gleiskontakten 1 und 2 als erstes Argument nicht ein Objekt, sondern eine Variable ( "([Gleiskontakt].Fahrzeugliste)" und "([Gleiskontakt].Fahrzeugtabelle)") übergeben habe. Und Variablen, die im Aufruf des benutzerdefinierten Ereignisses übergeben werden, können wohl nicht überschrieben werden. ich werde mich daher auf das Beipiel mit Gleiskontakt 3 konzentrieren.

Viele Grüße
BahnLand

Bearbeitet 1. Dezember 2019 von BahnLand

[EASY]

Hallo BahnLand,

vor 6 Stunden schrieb BahnLand:

Im obigen Protokoll werden die Ereignisse sowohl für den Gleiskontakt 2 als auch für den Gleiskontakt 1 mehrfach aufgelistet, wobel die Anzahl der Wiederholungen bei unterschiedlchen Durchläufen zufällig ist. Und es tritt ausschließlich bei der Fahrt im Uhrzeigersinn auf. Entgegen dem Uhrzeigersinn triitt jedes der 3 Ereignisse im Protokoll immer korrekt genau einmal auf.

... es tritt auch auf, wenn die Überfahrt die Reihenfolge Gleiskontakt 1-2-3 hat....
Bei meinen Versuchen ist es so, daß sobald die "BR 110" die Gleiskontakte mit einer ab einer gewissen negativen Geschwindigkeit überfährt (egal ob ziehend oder schiebend) die Ereignisse der Gleiskontakte teilweise mehrfach aufgelistet werden. Bei mir fängt es bei ca. -120km/h an... bei positiver Geschwindigkeit oder kleiner negativen Geschwindigkeit ist alles gut... nur woran das nun liegt, kann ich Dir nicht sagen...

Fahrzeugliste_1.mbp

P.S. ich habe ein seperates Oval gemacht, damit es durchläuft...

Gruß
EASY

[BahnLand]

Hallo,

vor 7 Stunden schrieb BahnLand:

Mir ist jetzt allerdings nicht klar, ob die Ereignisdefinitionen nun tatsächlich mehrfach ausgeführt wurden, oder ob es sich nur um einen Ausgabefehler in der Protokolldatei handelt. Denn eine Wiederholung der Ereignisauswertungen führt in der hier vorliegenden Konstallation zu keinem geänderten Ergebnis.

Mit einem zusätzlich eingebauten "Ereigniszähler" konnte ich nun nachweisen, dass die Ereignisse "Gleiskontakt 1/2/3 wird beim Betreten asugelöst" tatsächlich (zufällig) mehrmals ausgelöst werden.

Warum dies so ist, und weshalb dieses Phänomen beim meiner Testanlage nur bei der Fahrt im Uhrzeigersinn auftritt, während gegen den Uhrzeigersinn alles korrekt abläuft, ist mir allerdings ein Rätsel.

Hier noch einmal die Testanlage, nun mit dem eingebauten Ereigniszähler:

Fahrzeuglisten 2.mbp

Viele Grüße
BahnLand
 

@EASY:

Danke für Deinen Test.
Das lag dann bei mir tatsächlich an den "rechts herum" nur mit positivien Geschwindigkeiten gefahrenen Versuchen.

Bearbeitet 1. Dezember 2019 von BahnLand

[Goetz]

vor 2 Stunden schrieb BahnLand:

Erst hierdurch bin ich darauf gekommen, dass ich bei den Gleiskontakten 1 und 2 als erstes Argument nicht ein Objekt, sondern eine Variable

Keine Variable, sondern die ganze Tabelle.

Mit

bekommst du:

Aber diese Tabelle ist eine Kopie. Und alles, was du hier in "FzListe" speicherst, landet in dieser Kopie und nicht in der ursprünglichen Tabelle.

Zu deinen neuen Fragen muss ich erst einmal schauen, was da im Einzelnen passiert ...

[BahnLand]

Hallo @Goetz,

Danke für die Korrektur.
Ich hatte mich da wohl missverständlicherweise bei der "Verkürzung" des Begriffs "Objektvariable" (vom Typ Liste oder Tabelle)  auf "Variable" selbst reingelegt. Wäre die Objektvaribale vom Typ "Objekt" gewesen, hätte es wahrscheinlich funktioniert. Ein Parameter vom Typ "Liste" oder "Tabelle" kann im aufgerufenen Script wohl grundsätzlich nicht verändert zurückgegeben werden? Oder gibt es da eine andere Möglichkeit?

Viele Grüße
BahnLand