Posts by frank.buchholz

    Quote

    Kann mann das neue Luascript noch mischen mit ein traditionelles Luascript.

    Das Modul zur automatischen Zugsteuerung lässt sich zur Zeit nur mit unabhängigen anderen Steuerungen über Signale, Fahrtstraßen oder Lua zusammen betreiben. Man kann also leicht Bahnübergänge, Türsteuerungen, Ampelschaltungen für Straßen, Güterverarbeitung usw. kombinieren.
    Eine Kombination mit anderen Zugsteuerungen klappt jedoch nicht. Zur Zeit gilt also für die vom Modul verwalteten Strecken: Ganz oder gar nicht.

    (Ich habe ein paar Ideen in Vorbereitung, um das Modul flexibler zu machen.)

    Slots oder Tag-Texte nehmen nur einfache Daten auf (Boolean, Zahlen, Zeichenketten) nicht jedoch Tabellen. Wenn man in einem Eintrag eine komplette Tabelle unterbringen will, dann muss man die Tabelle in eine Zeichenkette umwandeln.
    Achtung: es gibt eine maximale Länge der Zeichenkette, die gespeichert werden kann.


    In unseren blockControl-Projekt verwenden wir folgende Funktionen um einfache Tabellen (also eine Menge an Schlüssel-Wert-Paaren) in Zeichenketten ("Strings") umzuwandeln, die in Slots oder Tag-Texten gespeichert werden können:



    So sieht ein Testbeispiel dazu aus:



    Übrigens: So kleine Beispiele wie das hier kann man auch einfach auf einer Online-Lua-Seite ausprobieren (dort stehen allerdings keinerlei EEP-Funktionen zur Verfügung):

    https://www.tutorialspoint.com/execute_lua_online.php

    Hallo @Johanes,


    ja, die Mehrsprachigkeit der Meldungen des Moduls ist schon länger auf meiner Arbeitsliste.

    (Die Dokumentation gibt es auf DE und EN und die Online-Tools zur Generierung des Lua-Codes zeigen ja bereits DE, EN, und FR).


    Zu den Meldungen:

    • ´routes´/`parts:Block 195 is not a via or an ending block of any path
      Block 195 ist weder ein Durchgangs- noch ein Endblock eines Pfades
    • ´routes´/`parts:Block 173 is not a starting block of any path.
      Block 173 ist kein Startblock für einen Pfad.

    Das Modul steuert die Blocksignale und weist den Zügen bei Ankunft in einem Block neue Routen (bzw. Pfade) zu. Damit ein sinnvoller Zugbetrieb von Block zu Block möglich ist werden bestimmte Prüfungen gemacht und ggf. (leider noch englische) Meldungen ausgegeben:

    • Für jeden Block muss es mind. eine Route geben über die dieser Block erreicht werden kann.
      Jeder Block muss also in mind. einer Route der Zielblock sein.
      (Das trifft für Block 195 nicht zu.)
    • Für jeden Block muss es mind. eine Route geben über die ein nächster Block erreicht werden kann
      Jeder Block muss also in mind. einer Route der Startblock sein.
      (Das trifft für Block 173 nicht zu.)

    Aufgrund der hohen Signalnummern vermute ich, dass du dich an eine recht große Anlage heranwagst und dass es eine Anlage ist, die bereits eine Signalsteuerung besitzt. Das ist nicht so einfach umzuwandeln. Vielleicht ist es gut, zuerst die einfachen Demos zu untersuchen. (Meine bislang größte Test-Anlage für das Modul verwendet 44 Block-Signale und steuert 14 Züge.)


    Du kannst gerne ein Bildschirmfoto von dem Gleisplan-Programm und den verwendeten Lua-Code entweder hier oder in einen Konversation zeigen. Dann schauen wir und das gemeinsam an.


    Schönen Gruß
    Frank

    What is your calculated minimum lenght of a two-way Block? And is there a role for the sound contact setting (beginning or end of train)?

    Hello Warner ,


    I do not see any special requirements concerning the length of two-way-blocks, just treat both blocks as usual (*).


    As soon as a block-entry-sensor triggers following happens:

    • the block turns from status "reserved" into "occupied" and the wait timer for this block starts tickeling down. As soon as the timer reaches zero, the train will request a new route/path.
    • the turnouts and (if not jet done) the block behind the train turn into status "free". Other trains may now use these turnouts and blocks. Therefore, you should ensure that no part of the train still stays any any turnout behind the train.

    Because of this you usually place block-entry-sensors in stations shortly after the last turnout before the block and use "end-of-train" for triggering the sensor. This way you ensure that the train has left completely all turnouts before entering the block. You do not need to enter any wait time for this sensor.


    If there is plenty of space than you might want to put the sensor nearer to the block signals (to make it easier to find them on the layout) and in this case it does not matter if you use "head" or "end" because the trains do not stay on any preceeding turnouts in any case. However, I still use "end" in most cases.


    (*) If you want reverse the direction of trains in two-way-blocks, then you get special requirements concerning the location of the pre-signals.


    Greetings, Frank

    Hallo Klaus,


    ich gehe davon aus, dass in allen Routen, die von dem Blocksignal vor dem Prellbock ausgehen der Eintrag reverse=true enthalten ist.


    Dann handelt es sich vermutlich um ein Initialisierungsproblem:


    Das blockControl-Modul muss erfahren, welche Züge unterwegs sind und wo sie sich befinden. Das wird in dem "Finde-Züge-Modus" gemacht, der beim Start der Anlage und nach dem Neuladen des Lua-Skripts aktiv ist. Insbesondere wenn die Menge oder die Positionen der Züge geändert werden, muss der "Finde-Züge-Modus" wiederholt werden. Im Zweifelsfall kann man dazu einfach das Skript neu laden.


    Während dem "Finde-Züge-Modus" fahren die Züge zum nächsten auf Halt stehendem Signal (bzw. bleiben dort stehen). Dabei sollten sie auf ihrer Fahrt auch den dazugehörigen Blockeingangskontakt ausgelöst haben.


    Bei Blöcken mit Fahrtrichtungsumkehr ist es sogar notwendig, dass Züge den Blockeingangskontakt passieren weil durch diesen Kontakt auch die aktuelle Fahrtrichtung (vorwärts/rückwärts) festgestellt und gespeichert wird. Solche Fahrtrichtungsumkehrblöcke sind damit keine guten Positionen, um Züge einzusetzen.


    Hier eine zuverlässige Methode zum Einsetzen von Zügen:


    1. Zug auf freier Strecke vor einen freien Block einsetzen, Zugname wählen, Zug-Kupplungen deaktivieren, Geschwindigkeit setzen

    2. Lua-Code aufrufen und in Tabelle trains den Zug mit passender allowed-Tabelle und gewünschter Wende-Geschwindigkeit eintragen

    3. Skript neu laden


    Schönen Gruß

    Frank

    Hello Warner

    That‘s a nice idea - I put it onto the bucket list.


    However, there is a twist, especially in small stations with two-way-blocks. Depending on the positioning of the entry sensor approaching signal of the other two-way-block the train will either stop at this block or skip it. Therefore, I do not see any 100% foolproof solution.


    Greetings. Frank

    Das frage ich mich auch - das wäre für mich ein Kaufargument für den MK (ebenso wie wenn es möglich wäre, Signale auszuwählen bei denen die erste Position „Halt“ bedeutet).


    Jedenfalls versuche ich gerade aus den ini-Dateien der entpackten Ressourcen die beweglichen Achsen auszulesen. Das klappt überraschend gut, aber bevor ich dieses kleine Mini-Programm veröffentliche, warte ich ab, was dieser Thread hier bringt.

    In deinem Fall geht es um eine Liste von Namen bei dem das pattern nur das Trennzeichen erkennen muss.


    In unseren blockControl Projekt werden aktuelle Statusinformationen in Form von Tabelleninhalte in Slots bzw. Tag-Texten gespeichert. Dazu werden folgende Funktionen verwendet:

    Besonderheiten:

    • Die Funktionen wandeln Tabellen in Strings um und umgekehrt.
    • Es werden nur einfache Tabellen, also Mengen an Name-Wert-Paaren unterstützt nicht jedoch geschachtelte Tabellen.
    • Das Trennzeichen ist ein TAB, das daher nicht in Texten vorkommen darf.
    • Integers werden ohne Nachkommasstelle umgewandelt, bei Floats werden genau 3 Nachkommastellen verwendet.
    • Das pattern sucht (im Prinzip genauso wie im Beispiel von gonz ) zuerst das Gleichheitszeichen, das den Namen vom Wert trennt und dann das Trennzeichen (wobei auch nach dem letzten Wertepaar ein Trennzeichen stehen muss da das pattern kein abschließendes „-„ Zeichen enthält).

    Zur Entwicklung hatte ich die Lua 5.3 Dokumentation zu patterns genutzt:

    https://www.lua.org/manual/5.3/manual.html#6.4.1

    Quote

    Although the added exit signals (6 and 8) have no further function, they are included in the Lua file. The reverse function is not overruled, but for some reason the exit signals are delayed set to Fahrt. No delay has been entered. I expected these exit signals to be set to Fahrt immediately.

    Currently these signals act as normal blocks producing routes. Trains travel from block to block and have to request new routes when entering the destination block. Our blockControl program assigns one new route to one train in every cycle of EEPMain - we never let go multiple trains per cycle. Therefore it could happen that there is a small delay.


    The purpose of these exit signals is just to show a signal pattern without affecting the trains. Therefore you can take them out of blockControl and manage them in EEP:

    • You couple the exit signal with the block signal: when the block signal turns green, the exit signal turns green as well
    • A contact which triggers at the rear of the train turns the exit signal to red as soon as the train passes the signal.




    How to tell the generation program to ignore the exit signals?


    If there exist additional signals on the layout which should not get controlled by blockControl (e.g. connected signals for display purpose), you can add them into the „other signals“ field of the generation program.


    As Rudy wrote, you could remove such additional signals temporary before generation the Lua code as well, but that's not recommended.


    If such additional signals do not affect trains, you can place them on extra tracks which are not connected to the main line (or on other track types like control tracks). Such inactive tracks and their signals are ignored as well.


    If you are interested in technical details you find a short description, how the generation of the Lua code works, on the wiki at Github.

    Hello chucksim2


    you are working on non-trivial layouts and you are converting the given control system into automated blockControl. That works fine in general but takes some time to configure. RudyB and me both did this exercise as well, and we both learned that's not as easy as just using our small demo layouts...


    You have to define block signals carefully. It is possible to have additional signals (which are ignored by blockControl), e.g. for display purpose or to support a road crossing, but this requires caution: the automated blockControl assums that it controls all block signals and related turnouts completely. No other process or no user interaction is allowed to touch them.


    Let's have a look to some special cases on your layouts:

    (Later I will add theses examples to the troubleshooting section of the documentation as well)


    Issue "Turnout between approching signal and main signal"


    On layout "Fox River Ver 12- NEW Sgnals" you find signal 38 with turnout 158 beeing located between the approaching signal and the main signal. Depending on the direction of trains running over this turnout this could be possible and useful and it could be possible that you can define the required route definition manually. However, the generation program cannot handle such a complicated case. Let's have a look to the documentation: "With automatic traffic, trains drive from block to block. The first decision to make is which blocks we want to define. There’s only one rule here: turnouts can not be part of a block, they are part of the routes between blocks."


    Issue "Two signals on same track"


    On layout "Fox River Ver 12- NEW Sgnals" you find two signal 29 and 76 on the same track 45. The generation program does not deal with the exact positions of signals on tracks but uses only the connection between tracks to find routes between signals. This simplifies the calculation but runs into trouble if two signals are located on the same track.

    I guess that both signals serve different purposes and only one of it is a real block signal controlling automated traffic. You can put the other signal onto the "ignored list" when generating the Lua code.


    Issue "Dead end without block signal"


    On layout "Boswell Junction - Version 25 - Buffalo" the dead-ends behind turnout 25 do not have block signals yet. The current version of the blockGontrol generation program requires to have a block signal on each dead end. The reason for this is that the program follows tracks and reflects the direction of searching at dead ends. Without a block signal, the same turnout is visited twice while searching for a route into and out of a dead end. This is interpreted as a forbidden cycle.


    Potential issue "Too many two way blocks"


    On both layouts you have defined many two way blocks. That's possible and works fine in the first place - and I love it, because it allows trains to go everywhere in any direction. However, this increases the risk of lockdown situations especially if there are many trains running. I tried it on one of our larger test layouts to define all platform tracks in stations as two way blocks which then forced me to define a long list of anti-deadlock-pathes manually. I suggest to start with only required two blocks and extend it later carefully.



    I love to continue working on your layouts to identify and solve more stuff!


    Greetings, Frank

    Hello chucksim2 ,


    I now got your three EEP 17 anl3-files via mail and had a look into them. Here are the findings:



    Files Fox River Ver 11- NEW Sgnals and Fox River Ver 12- NEW Sgnals


    Some road track definitions are defect. I assume that you do not see any issue in EEP because this program seems to ignore such errors and continues working.


    The previous version of the Gleisplan program is not robust enought to handle such issues and fails. As a consequence it was not able to generate the data for the blockControl module.


    -> This particular issue is now solved. Please try again. However, there might exist more problems with the layout and the placement of the block signals.


    The amazing Tauschmanager program is much smarter: This program is not only able shows the remaining layout correctly but allows to correct the file by deleting the defect tracks!


    -> Use the Tauschmanager program from HStoni54 to remove the defect tracks to repair the anl3-file.




    File "Boswell Junction - Version 25 - Buffalo" shows a similar defect accects some flora elements.


    -> Use theTauschmanager program to remove the defect elements


    (I can run the Tauschmanager program for you as well. In this case I would prefer that you send me the complete layouts including all files as a zip archive. Do you know how to create such a zip archive? I'll try to send some instructions via mail later.)



    In addition, the dead-ends behind turnout 25 do not have block signals yet. The current version of the blockGontrol generation program requires to have a block signal on each dead end. (The reason for this is that the program follows tracks and reflects the direction of searching at dead ends. Without a block signal, the same turnout is visited twice while searching for a route. This is interpreted as a forbidden cycle.)




    Technical details (for experts):


    The defect road tracks and flora elements show positions with NaN (Not a Number) values in the anl3 file.


    @EEP experts: Does anybody knows about this type of issue and how it could occur in EEP 17?

    (If yes, we should open a new thread to discuss this topic.)


    Example for a defect road track:


    Following roads with different track types show this NaN error:

    Road-36 Arc

    Road-159 Line

    Road-160 Line

    Road-161 Arc

    Road-162 Cubic

    Road-163 Arc

    Road-182 Helix

    Road-183 Arc

    Road-184 Arc

    Road-185 Helix


    Example for a defect flora element:


    Code
    1. <Immobile gsbname="\LSElemente\Flora\Gras\Gras_Sommer_02_30x3_RE1.3dm" Smoke="0" Fire="0" Light="0" ImmoIdx="3107" TreeShake="2" LockEd="0">
    2. <Dreibein>
    3. <Vektor x="-nan(ind)" y="-nan(ind)" z="-nan(ind)">Pos</Vektor>
    4. <Vektor x="-nan(ind)" y="-nan(ind)" z="-nan(ind)">Dir</Vektor>
    5. <Vektor x="-nan(ind)" y="-nan(ind)" z="-nan(ind)">Nor</Vektor>
    6. <Vektor x="-nan(ind)" y="-nan(ind)" z="-nan(ind)">Bin</Vektor>
    7. </Dreibein>
    8. <Modell/>
    9. </Immobile>


    Only 8 of quite many of these flora elements show the error. Most look fine like this one:


    Code
    1. <Immobile gsbname="\LSElemente\Flora\Gras\Gras_Sommer_02_30x3_RE1.3dm" Smoke="0" Fire="0" Light="0" ImmoIdx="3115" TreeShake="2" LockEd="0">
    2. <Dreibein>
    3. <Vektor x="32963.76" y="17493.57" z="0">Pos</Vektor>
    4. <Vektor x="-0.1860003" y="0.9825493" z="0">Dir</Vektor>
    5. <Vektor x="-0.9825493" y="-0.1860003" z="0">Nor</Vektor>
    6. <Vektor x="0" y="0" z="1.000016">Bin</Vektor>
    7. </Dreibein>
    8. <Modell/>
    9. </Immobile>

    Es ließ mir keine Ruhe warum ich in meinem Beispiel oben die KP-Aufrufe anders aus dem Gedächtnis hingeschrieben habe und ich glaube ich habe die Antwort im Lua-Handbuch gefunden: Die Möglichkeit, nicht nur den Zugnamen sondern auch die Gleis-ID (hier als eindeutige ID verwendet um den Tabelleneintrag zu identifizieren) zu erhalten gibt es erst ab 16.3 - Vorher, also auch im aktuell von mir verwendeten EEP 15 funktioniert nur die Variante mit BetterContacts:


    Quote

    Seit EEP11.2 Plug-in 2 übergibt EEP den Namen des Fahrzeugverbandes, der einen Kontaktpunkt überfährt, als Funktionsparameter an die im Kontaktpunkt eingetragene Funktion. Diesem Parameter kann man einen beliebigen Namen geben, z.B. mein_Zug.


    Ab EEP 16.3 Plug-in 3 übergibt EEP zusätzlich die ID des Gleises (der Straße, des Wasserweges etc.) auf dem der Kontaktpunkt liegt als zweiten Parameter an die im Kontaktpunkt eingetragene Funktion. Auch dieser Parameter ist frei wählbar, z.B. Kontaktgleis. Durch diesen 2. Parameter kann dieselbe Lua-Funktion für verschiedene Zwecke verwendet werden, je nachdem auf welchem Gleisstück sich der Kontaktpunkt befindet.


    Hmm, damit ist ein schwacher Verdacht für die mögliche Ursache nicht zutreffend.


    Quote

    Die Aufrufe in den KPs Zugtueren_Links_Auf_Kp und Zugtueren_Rechts_auf_Kp müssen ohne Klammer erfolgen. Die Werte für Zugname und Gleis_ID liefert EEP!

    Es handelt sich hierbei jeweils um die Gleis_ID auf dem der KP liegt. Nicht um das Bahnsteiggleis und auch nicht um 1,2,3 ob die Tueren geöffnet oder geschlossen werden.

    Diese Funktionen leiten das dann weiter an Zugtueren_Auf(Zugname, Gleis_ID, Seite) .

    Oj, stimmt, Ich muss mir wohl morgen auch einmal eine Testanlage bauen und nicht nur theoretisch irgendwas schreiben .-(

    genau. Im KP steht "Zugtueren_Auf(Zugname, Gleis_ID, Seite)" wobei Gleis_ID die ID ist und Seite in diesem Fall rechts.

    Um ganz sicher zu sein, steht im Kontakt:
    Zugtueren_Auf(Zugname, Gleis_ID, Seite)

    oder (für Gleis 1):

    Zugtueren_Auf(Zugname, 1, "rechts")

    Du kannst zunächst vor Zeile 65 einen print-Befehl einführen:

    print("Türen öffnen auf Gleis ", Gleis_ID, " für Zug ", (TuerTabelle[Gleis_ID] and TuerTabelle[Gleis_ID].Zugname or "*fehlt*") )


    Vermutlich erhältst du die folgende Anzeige: Türen öffnen auf Gleis nil für Zug *fehlt*


    Wie sehen die Lua-Aufrufe in den Kontakten für

    Zugtueren_Links_Auf_Kp

    Zugtueren_Rechts_Auf_Kp

    Zugtueren_Auf
    aus?


    Es müsste - ohne dass ich das jetzt getestet habe - so etwas in dieser Art sein:
    Zugtueren_Links_Auf_Kp(Zugname, 1)

    Zugtueren_Rechts_Auf_Kp(Zugname, 2)

    Zugtueren_Auf(Zugname, 3, "links")

    usw.
    Beim Aufruf wird also die Variable Zugname und die Nummer des Bahnhofgleises, zu dem dieser Kontakt gehört, angegeben.

    Hallo Frank, hättest Du Lust mit mir so ein Script zu erstellen? Ich würde bestimmt eine Menge dabei lernen.

    Wie händelst Du das denn am Bahnhof mit den Türen? Falls Du sowas überhaupt im Einsatz hast.

    Nein, ich schreibe keine Auftragsskripte. Bei konkreten Fragen zu bestimmten Lua-Themen werde ich, wie etliche andere auch, dagegen gerne antworten.


    Ich würde Zugtüren im Bahnhof entweder ganz einfach und effektiv mit je einer Funktion je Zug bauen - dann kann man die Namen der Rollmaterialien und der Achsen fest eintragen und auch gedrehte Wagen direkt berücksichtigen. In den Funktionen wird je Wagen EEPRollingstockSetAxis aufgerufen.


    Oder ich würde, wie in einer genialen Zugzielanzeige-Demo gesehen, mit Achsgruppen arbeiten, damit das Lua-Skript nicht die unterschiedlichen Namen von Türen bzw. die Ausrichtung der Wagen kennen muss:

    Nachtrag 9.6.22:_ Habe noch einmal nachgeschaut: in dieser Demo werden die Türen zwar per Lua geschlossen (Achsgruppe 1), geöffnet werden sie dagegen mit ein paar Sekunden Zeitverzögerung über Zug-Kontakte kurz vor dem dem Signal (Achsgruppe 3). Und für alle Fälle werden die Türen über Zug-Kontakte vor der Einfahrt in ein Depot geschlossen (Achsgruppe 1).

    In dem Thread schreibt Tufftuff selber folgendes zu diesem Skript: "Hier mal kurz ein Skript, welches so nicht gibt, weil ich es anders mache."

    Und schlingo schreibt etwas später: "Wenn ich das so richtig verstehe, kann das natürlich nicht funktionieren. Ist das so Absicht?"


    Der Thread handelt von Details der Lua-Sprache in Bezug auf lokale und globale Variablen und welche Auswirkungen dies bei Aufrufen in Kontakten hat. Er handelt nicht von einem echten Skript-Beispiel eines wiederverwendbaren Moduls.


    Ich glaube man hätte noch einiges zu tum, um daraus ein lauffähiges Programm zu machen...

    Hallo hurricane65


    Wo finden wir die Originalquelle und die Dokumentation des Skripts von Tufftuff ?


    --


    Zur Fehlermeldung:

    Tuer_auf_zu.lua:29: bad argument #1 to 'EEPGetTrainSpeed' (string expected, got nil)


    Die Meldung passt zum gezeigten Coding - dort steht ein Funktionsaufruf für EEPGetTrainSpeed in Zeile 29 der genau dann den gezeigten Fehler liefert wenn der Funktionsparameter Zugname nicht gesetzt ist :



    Du kannst auch vor diese Zeile ein

    print(Zugname)

    einbauen.


    Der Kommentar hinter der Funktionsdefinition "Der Funktionsaufruf gehört in die EEPMain" ist allerdings etwas überraschend, da die Funktion ja zwei Parameter besitzt, die eher darauf hindeuten, dass man diese Funktion in einer Lua-Zeile eines Kontaktes nutzt.


    Wo verwendest du die Funktion Tueren_Auf_Zu_Abfrage, in einem Kontakt oder in EEPMain? Und welche Parameter sind dabei angegeben?


    --


    Das Bildschirmfoto passt anscheinend nicht zu dem Problen, denn dort steht im Kontakt die Lua-Zeile

    Tueren_Links_Auf_Kp( Zugname , 9)

    die sich auf eine andere Funktion bezieht, die ab Zeile 43 definiert wird.


    In dieser Funktion gibt es einen Befehl
    print(Zugname)

    der auch einen Zugnamen anzeigt, so dass der darauf folgenden Aufruf von EEPGetTrainSpeed keinen Fehler liefern dürfte.

    Vermutlich steht diese Anzeige also nicht im Zusammenhang mit dem Problem.


    --


    Das Skript hat auch anderweiting noch Fehler. Beispielsweise gibt es folgende Definition einer lokalen Funktion (lokal deswegen weil die Tabelle Tueren_Auf_Zu lokal definiert ist):

    function Tueren_Auf_Zu.Auf_ausfuehren(Gleis_ID)


    Der Aufruf in der globalen Funktion Tueren_Auf_Zu_Abfrage sieht allerdings so aus:

    Tueren_Auf_Zu.Auf_ausfuehren(Zugname, Gleis_ID, Seite, Richtung_ZV)


    Die Parameterlisten passen also nicht zusammen. (Die Wirkung wäre, dass iIn Funktion Auf_ausfuehren der Parameter Zugname den Wert von Gleis_ID von Aufrufer bekommt, während die Parameter Gleis_ID, Seite und Richtung_ZV alle den Wert nil erhalten.)