Posts by Nero

    Nicci 53


    Erste Frage: Das Gleissperrsignal entfernen, die Rangierhalttafel kommt zwischen Weiche zum Anschluss und der Abzweigung zwischen den beiden Strecken. Die Rangierfahrt zum Anschluss wird dann vom Ausfahrsignal im Bahnhof mittels Sh1 signalisiert.

    Zweiter Frage: An der Rot umkringelten Stelle vom Anschluss Richtung Bahnhof kommt ein Gleissperrsignal und danach optional noch eine Schutzweiche oder Gleissperre, um entlaufende Wagen von der Strecke fernzuhalten.

    halbseemann (RI1) Ich bin davon ausgegangen, das Chicane sich auf den Bahnhofsbereich bezieht, auch wenn er "Block" sagt. Für die Strecke stimmt das natürlich. Da du einmal hier im Thread bist, kann ich dir ja gleich Löcher in den Bauch fragen, wie du deine Signale miteinander verschaltest.

    Guten Abend,


    ich hab noch keine Lösung gefunden, die meinem ausufernden Perfektionismus entspricht.


    Folgende Dinge vorab (Einige mögen ihre Ratschläge darin wiedererkennen):

    • Das Umstellen eines Mehrabschnittsignales muss unterbleiben, wenn es gerade Halt zeigt
    • Die Abfrage des Haltzustandes muss direkt vor dem Umschalten durchgeführt werden, bei Steuerstrecken im selben Kontakt, sonst wird ggf. ein eben gestelltes "Halt" mit einem Fahrtbegriff überschrieben.
    • Ebenfalls muss die Weichenverbindung zwischen MAS und folgenden Hauptsignal noch eingestellt sein und auch überprüft werden
    • Reine Vorsignale und Vorsignalwiederholer lassen sich via Signalverknüpfung machen. Daher hab ich die erstmal außen vor gelassen

    Als ersten Ansatz hatte ich die einfache Aufsignalisierung. Die Signale werden beim Übergang von Halt auf einen Fahrtbegriff auf "Halt erwarten" eingestellt, ggf. mit Geschwindigkeitsbegrenzung falls der Bremsweg verkürzt ist. Für jede Geschwindikeitsabstufung beim Folgesignal wird ein Übergang zwischen Stellungen des MAS-definiert, z.B. wenn das Folgesignal "Fahrt mit 60" anzeigt, wechselt das MAS von "Halt erwarten" auf "Fahrt mit 60 erwarten". Das ist von der Logik her einfach genug, das es sich mit Schaltstrecken lösen lässt.


    Das Schaltauto kann mittels bedingter Kontakte das Hauptsignal und die Weichen zwischen den beiden Signalen abfragen und sich selber die Weichen im Steuerkreis stellen. Wenn alle Kriterien abgefragt sind und stimmen, fährt das Schaltauto über ein Gleis mit einen Kontakt, welcher das MAS aufsignalisiert, sofern es gerade "Halt erwarten" zeigt. Bei den HV-Hauptsignalen mit Vorsignal dran oder den Hl-Signalen will man hier ggf. mehrere Kontakte für jede Geschwindigkeitsstufe (Zs3), die man ja beibehalten will. Also aus "Halt erwarten mit 60" wird "Fahrt mit 60".


    Das geht dann ähnlich so mit Lua und kann dann so aussehen:


    LUA Source Code
    1. EEPRegisterSignal(132)
    2. function EEPOnSignal_132(HS)
    3. if EEPGetSignal(119) > 1 and HS == 4 then
    4. EEPSetSignal(119, 2)
    5. end
    6. end

    Das Signal 132 ist hier das folgende Hauptsignal, das Signal 119 ist das Mehrabschnittsignal. Anfangs zeigt das Signal 119 auf "Halt erwarten".
    Das folgende Hauptsignal wird von seiner Fahrstrasse von 1 "Halt" auf 4 "Halt erwarten" umgestellt, dies löst den Callback aus. Im Callback wird mittels > 1 sichergestellt, das das MAS nicht Halt zeigt und dies dann von "Halt erwarten" auf 2 "Fahrt" eingestellt.


    Das geht, das ist aber unflexibel und kriegt Probleme damit, wenn man händisch an den Signalen rumspielt. Außerdem ist das etwas schwieriger, wenn das Zs3 als separates logisches Signal angebaut wird. Für die Ks-Signale von GK3 hatte ich daher noch was anderes probiert:


    Das Ergebnis hab ich in den beiden Anhängen nochmal abfotographiert. Das kommt auch damit klar, das man an den Signalen händisch herumspielt. Die Anlage gibts bei Wunsch via DM.


    Auch hatte ich die Idee, das man für alle Signale die Stellungen und Zusatzsignale eintragen könnte, dann noch die IDs der Signale, welche sich

    Vorsignalisieren sollen, und das Lua macht den Rest alleine... das konnte ich mit Lua scripten, das war zwar viel Code und lief dann, aber ich fand es dann sehr nervig, für jedes Signal so viele Daten eintragen zu müssen.


    Bei allen Lösungen finde ich es nicht so toll, was für ein Lua- oder Steuerstrecken-Unwuchs da entsteht, wenn man mal einen etwas größeren Bahnhof hat. Davon abgesehen habe ich jetzt grob einen Plan, wie man das angehen kann, das es auch zuverlässig funktioniert. Aber Entschlossenheit hab ich daraus nicht gewonnen.


    LG Nero

    Moin,


    die "HookPleaseStop" selbst kommt nicht von Dauerschleifen! Ich hatte das Problem eben auf meiner Testanlage für MAS-Signale auch.


    Ich habe mir eine weitere Testanlage für die Diagnose gebaut und dort die Ursache gefunden. Lua wird nur alle 200ms Sekunden ausgeführt, zwischen diesen Ausführungszeiten läuft die Anlage aber weiter. Wird in dieser Zeit ein Signal mit aktivierten Lua-Callback umgestellt, wird sich gemerkt, das der Callback ausgeführt werden soll. Normalerweise wird der Callback dann nach spätestens 200 ms im nächsten Lua-Zyklus ausgeführt.


    Wenn der User aber vor der nächsten Ausführung in den 2D-Modus wechselt und dort z.b. irgendein anderes Signal von der Anlage löscht oder den Lua-Editor öffnet, kommt dann die Fehlermeldung und der Callback wird vergessen.


    Minimaler Code zum Reproduzieren (Signal 1 kann z.B. 0-98 Zähler sein):

    LUA Source Code
    1. EEPRegisterSignal(1)
    2. function EEPOnSignal_1(Stellung) end
    3. function EEPMain()
    4. EEPSetSignal(1,0,1)
    5. return 1
    6. end

    Die Main löst in jedem Durchlauf eine Umstellung aus, damit gibt es in jedem Zyklus einen Signal-Callback. Geht man dann in den 2D Modus und lädt das Lua neu, kommt immer der Fehler "HookPleaseStop" und der Callback wird nicht ausgeführt. Wenn man stattdessen eine neue Anlage lädt, kommt die Fehlermeldung dann auf der anderen Anlage. Das ist also eigentlich ein Timingproblem.

    Wieso die Fehlermeldung trotzdem zusammen mit Dauerschleifen auftritt: Es ist halt ein Timing-Problem, wenn aufgrund von langsamen Schleifen der Lua-Code sehr lange braucht, schafft EEP nur noch wesentlich weniger Zyklen und so ein gemerkter Callback wird erst viel später ausgeführt. Damit ist auch die Wahrscheinlichkeit höher, das ein User mit den Wechsel in den 2D-Modus einen gerade gemerkten Callback verhindert und ggf. diese Fehlermeldung auslöst.

    Beim Neuladen vom Lua-Script im 3D-Modus werden die gemerkten Callbacks einfach so vergessen. Das ist insoweit ärgerlich, weil die Callbacks so nicht 100% sicher sind um z.B. die Umstellung von anderen Signalen sicher durchzuführen.

    Abend,


    Die Funktion EEPRegisterTrack heisst richtig EEPRegisterRailTrack, das hatte ich aus dem Kopf heraus falsch zusammengeschrieben.


    Die Reihenfolge bei pairs() ist nicht festgelegt, aber in der Regel wird es keinen Unterschied machen, in welcher Reihenfolge die Gleise definiert werden.

    Dieser Weg wird wohl noch sehr lange andauern. Wenn du nicht darauf bestehst, es selber zu programmieren, kannst du mir vielleicht eine Anlage nur allein mit so einem Schattenbahnhof bauen und zukommen lassen und ich bastel dann eine Ansteuerung dafür. Ich hab gerade wieder eine kleine Sinnkriese mit meiner Elbtalstrecke und würde mich an einer Lua-Bastelei fürs Wochenende sicher erfreuen.

    Abend,


    der Bauvorschub auf meiner Elbtalanlage hat Bad Schandau erreicht und nun tauchen die ersten Ks-Signale auf der Anlage auf. Derzeit evaluiere ich die Ks-Signale von RI1 und GK3.

    Die Signale mit den Vorsignalen zu verküpfen ist ja an sich recht einfach. Was jetzt aber wohl ein größeres Projekt wird ist die Ansteuerung der Mehrabschnittssignale, welche gleichzeitig zur Hauptsignalfunktion auch die Vorsignalisierung für das Folgesignal durchführen. Ich brauche:

    1. Die Vorsignalisierung an den Hauptsignalen (Halt erwarten oder Zs3v)
    2. Abgestufte Geschwindigkeitssignaliserung bei Unterschreiten des Regelbremsabstands (Ks2 Halt erwarten mit Zs3 Geschwindigkeitsbegrenzung wenn Abstand < 950m)
    3. Betriebliche Abschaltung von Signalen bei sehr kurzem Signalabstand (Kennlicht wenn Abstand < 400m)

    Da es mit den RI1 und GK3 Ks-Signalen ja schon mehrere Modellsets gibt, die sowas darstellen können, dachte ich mir, das ich nicht der einzige mit diesen Anliegen bin. Punkt 1 betrifft ja schon die HV-Signale von AH1 im Grundbestand von EEP16.


    Daher bin ich daran interessiert zu erfahren, was andere EEP-Benutzer in der Richtung bereits unternommen haben:

    • Wie macht ihr die Ansteuerung von Hauptsignalen, welche auch Vorsignalfunktion haben?
    • Welche Kompromisse wurden dabei gemacht, auf was wurde dabei verzichtet?
    • Wenn ich dafür eine Ansteuerung in Lua schreibe, bestünde Interesse an einer Veröffentlichung?

    Ich rechne jetzt nicht mit fertigen Lösungen, aber ich wollte mal gucken, was es denn schon gibt.


    LG Nero

    Bei Immobilien und Signalen kannst du im den Objekteigenschaften auf den Button "Aufschriften" klicken, bei Rollmaterialien geht das bei EEP 16 nur mit Lua.


    Moin,


    der sich bestimmt gleich auftuenden Schlammschlacht möchte ich gleich noch Munititon dazugeben:

    1. Ja, Handbücher sind eine Teils sehr trockene Lektüre. Gepriesen sei der, der sich das antut. Wer nicht, muss sich mit dem Fragenstellen begnügen. Sich belesen ist halt Arbeit. Natürlich will jeder sich das sparen!
    2. Wenn dann eine Frage von jemanden kommt der das Handbuch nicht gelesen hat, sind die Menschen, die das Handbuch gelesen haben, natürlich genervt. "Warum macht der Typ sich da nichtmal die Mühe, in der PDF zu suchen?". Das war glaub ich schon immer und überall so. Gepriesen seien die, welche die Fragen trotzdem Inhaltlich beantworten.
    3. Die meisten von uns sind Sesselhocker und Kellerkinder, wären wir das nicht, würden man wohl nicht im Internet in irgendwelchen Foren rumhängen. Wenn man viel vorm Rechner sitzt, sammelt man eher weniger Erfahrungen im Umgang mit Menschen. Sozialkompetenz ist in manchen Fäden Mangelware. Unnötige Eskalationen passieren hier und dort, inklusive Unterstellungen und Beschimpfungen. Gepriesen sei der, der das ignorieren kann.

    Kurz und Knapp: Ja, ist alles nen bissl Scheiße, aber so sind wir Menschen nunmal. Nimm es als Herausforderung, trotz aller Umstände deine Anlagen trotzdem weiterzubauen.


    LG Nero, der leider Ingenieur geworden ist und jetzt jede Woche Handbücher studieren muss.

    Abend AdvEe ,


    ipairs hat in deinem Fall als Argument keine Tabelle, sondern nil bekommen.


    Gucke mal bei print (v10); Richtung = "v10"; v10 ist ein Variablennamen, danach machst du aber Doppelkommas drumherum und Richtung ist nicht das, was in v10 war, sondern eine Zeichenkette mit den drei Zeichen v, 1 und 0.


    Die Variablen in der for k10, v10 in ... sind lokal und nur innerhalb der for-Schleife verfügbar, danach werden sie vergessen. Du brauchst sie daher nicht durchzunummerieren.


    Ich verstehe das so, das du gerade Probleme hast, die entsprechenden Iteratoren ("Durchläufer") für die Tabellen zusammezukriegen:



    Gräm dich nicht, Programmieren ist nicht in einer Woche gelernt. Frustration gehört dazu, aber mit der Zeit lernt man, das abzukönnen.

    Moin Lothar,


    Das sich Signale oder Fahrstrassen unbeabsichtigt schalten ist auf meinen Anlagen zu 99%, das ich im Lua Script eine ID falsch eingetragen habe. Falls du Lua verwendest, suche dir mal die Fahrstrasse von deinem Fahrstrassen-Startsignal heraus und durchsuche dein Script/deine Lua-Tabellen nach dieser ID. Löschen und neu aufbauen bringt da auch nix, wenn die Fahrstrassensignale danach wieder die selbe ID haben wir vorher.


    Wenns daran nicht liegt, wäre es Hilfreich, wenn du uns Bilder von der Situation zukommen lässt.


    Grüße, Nero

    Der Artikel der Süddeutschen gibt nur grob die Inhalte des Zwischenberichtes wieder, generell möchte ich davon abraten, sich bei Sachthemen auf Unterhaltungsjournalistische Artikel zu verlassen. Der tatsächliche Bericht ist hier einsehbar und mit 10 Seiten zwar relativ kurz, aber sehr informativ gehalten. In der Sektion 2.4.1 wird auf die Verbesserungsmöglichkeiten m.M. nach hinreichend eingegangen.

    Guten Morgen AdvEe !


    Das ist ein Mammutprojekt, was du da vor hast, aber möglich ist es. Ich will dir hier ein paar Dinge mit auf den Weg geben, die mir helfen, mit komplexer Anlagenscripterei umzugehen.

    Bei komplexen Schaltungen braucht man die IDs von vielen Komponenten. Das Eintragen ist eine mühselige Arbeit, und wenn man einen Fehler macht, verhält sich die Anlage merkwürdig weil Schaltbefehle sonstwohin gehen. Ist mir schon selber sehr oft passiert.


    Wenn du mehrfach den selben Schattenbahnhof hast, kannst du dir je Schattenbahnhof eine ID merken (wie 1000, 2000, 3000 und so weiter) und stellst dann die IDs von den Weichen und Signalen so um, die Einfahrharfe die Weichen-IDs 1001 bis 1007 im ersten, 2001 bis 2007 im zweiten Schattenbahnhof (und so weiter) haben. In deinem Plan hast du ja praktischerweise schon alles durchnummeriert und das Schema dafür geschaffen.


    Das spart dir sehr viel Tabellenmaterial in Lua.

    Wenn du eine Systematik in den ID's hast, setze das knallhart durch. Mittels EEPGetSignal/EEPGetSwitch kannst du das überprüfen. Dann kannst du sofort eine Fehlermeldung auswerfen und sparst dir die halbe Stunde untersuchen, warum dein Zug jetzt auf das falsche Gleis eingefahren ist.


    Ich stell dir hier mal eine Lua-Codekuchen hin, vielleicht findet du ja ein paar Rosinen zum rauspicken. Den Programmcode habe ich blind geschrieben, kleinere Fehler sind zu erwarten.


    Hallo DH1 ,


    möglicherweise hast mich da etwas missverstanden. Mit "Ziel" meinte ich die Stellung des Fahrstrassen-Startsignales (sofern nicht 1), nicht das Fahrstrassen-Zielsignal.


    Die Fahrstrassen-Zielsignale sind zwar auch Signale, allerding konnte ich bisher noch keine Verwendung für die Abfrage dieser entdecken. Bis auf vereinzelte Experimente habe ich sie in meinen Arbeiten bisher ignoriert.


    LG Nero

    Bei einer Schaltung mittels einer Schleife scheinen also der Reihe nach alle FS bis zum vorgegebenen Ziel tatsächlich geschaltet zu werden. Da alles ja in Bruchteilen von Sekunden geschieht kriegt User davon normalerweise nichts mit.

    Wenn du das Schalten via Kontakt machst, hast du nur einen Zyklus, in dem die Funktion ausgeführt wird. Wenn du von dort versuchst, alle Fahrstrassen zu schalten, geht das nur mit dieser Überlappung.


    Ich versuche hier, einen anderen Lösungansatz darzustellen. Den folgenden Code habe ich aus dem Kopf zusammengeschrieben, da könnte sich noch ein Syntaxfehler drin verstecken:



    Die Schaltung wird nicht durch den Kontakt, sondern durch Abfrage des Signales in der EEPMain gemacht. Dort wird die Überprüfung immer wieder, nicht nur einmal wie beim Kontaktpunkt durchgeführt. EEP hat die EEPGetSignalTrainsCount() Funktion um zu ermitteln, ob ein Zug vor einem Signal steht. Wenn dies der Fall ist und die Fahrstrasse gerade nicht geschaltet ist (EEPGetSignal gibt 1 zurueck), dann versuchst du, die Fahrstrasse zu schalten. Kann die Fahrstrasse nicht geschaltet werden, erfolgt im nächsten Durchlauf der EEPMain der nächste Versuch.

    Willst du Züge auf mehrere Ziele aufteilen, kannst du hier mit math.random dir ein zufälliges Ziel auswählen, beim nächsten Versuch wird dann ein anderes Gleis probiert.


    Wichtig ist: So kann man es machen, das in jedem Zyklus nur maximal ein EEPSetSignal auf ein Fahrstrassensignal abgegeben wird.


    Wird die Fahrstrasse nun geschaltet, wird das Signal von der Fahrstrasse mit auf Fahrt gestellt und EEPGetSignalTrainsCount() gibt 0 zurück, weil kein Zug mehr vor dem Signal hält.


    Anstelle der EEPGetSignalTrainsCount() kann man sich auch in einer Tabelle merken, an welchen Signalen gerade ein Zug wartet, und die IDs in der Tabelle via Kontakte ein- und austragen. Das RUS-Packet von Parry36 macht das z.B. so.

    Warum ich EEP bespiele und nix anderes, auch keine Realmodellbahn:

    • Als Hobbyprogrammierer bastel ich sehr gerne mit Lua herum. Viele meiner Anlagen sind eingleisige Teststrecken von links nach rechts, ohne jegliche Ausgestaltung.
    • EEP Anlagen sind mechanisch und elektronisch zuverlässig, verdrecken nicht und müssen nicht regelmäßig gewartet und gereinigt werden.
    • Hab ich keinen Bock mehr auf ein Projekt, bleibt ein Ordner auf dem Rechner zurück. Bei einer Modellbahnanlage hätte ich ein paar Kubikmeter Sondermüll.
    • EEP-Anlagen können wesentlich größer sein als meine Wohnung für eine reale Modellbahnanlage hergeben kann. Meine Elbtalstrecke wäre in H0 schon 300 Quadratmeter groß. Mit den benachbarten Mietwohnungen würde das zwar gehen, aber spätestens da hört Nachbarschaftshilfe auf.
    • Realistische Radien, Fahrgeschwindigkeiten und Signalabstände: Das geht auf einer Realmodellbahn überhaupt nicht. Ich habe von der verbotenen Frucht gegessen, Fachliteratur vom Vorbild gelesen und habe jetzt entsprechende Ansprüche.

    Früher habe ich auch BAHN 380+ und OpenTTD gespielt, da sind die gestalterischen Möglichkeiten aber stark begrenzt und eine Programmierschnittstelle gibt es auch nicht.


    LG Nero

    Ich hatte anfangs tatsächlich noch mehr Funktionen drin (mehrere Callback-Funktionen für ein Signal, oder onSignalOrSwitch), aber die habe ich wieder rausgeworfen, weil sie mit der Grundaufgabe nicht direkt etwas zu tun haben.

    Ich hab mir für eigene Dinge etwas gebaut, das ich mehrere Funktionen je Callback hab und auch überlegt, ob man mittels __index die Definitionen von Callbacks abfangen und EEPRegisterSignal und dergleichen automatisch aufrufen kann. Jetzt warst du auch schonmal davor, das zu machen. Gab es da irgendwelche Hindernisse?