Ereignisverarbeitung überlastet

[fzonk]

Hallo @Neo und an Alle,

Ich glaube ich habe das MBS kaputt gemacht  denn ich habe auf einmal diese Meldung bekommen: „Die Ereignisverarbeitung ist aufgrund von Skriptfehlern deaktiviert: control structure too long near 'end'“. Eigentlich handelt es sich um eine recht kleine Anlage (für meine Verhältnisse) Ich habe die Hauptsteuerung in ein Ereignis gepackt, wo es einige Bedingungen und entsprechende Aktionen gibt. Eigentlich dachte ich das Ereignis wäre gar nicht so lang (groß), ich habe es mit der grafischen EV erstellt. Wenn ich es in Lua wandle (was schon mal eine Weile dauert bist es gewandelt ist) sagt es mir tatsächlich das dieses Ereignis aus 29227 Zeilen besteht. Bis dieser Fehler alles gestoppt hat lief die Steuerung sehr stabil und fehlerfrei.

Ist es richtig, dass es ein Maximum an Ereignisfolgen in einem Ereignis gibt? Und gibt es Vorschläge was ich nun machen kann, außer das eine Ereignis auf mehrere wieder aufzuteilen?

Gruß Frank

[Timba]

Hallo Frank,

das MBS hast du ganz sicher nicht kaputt gemacht. Kann man sich das mal anschauen? Ob es ein Maximum gibt bei den Ereignisfolgen weiß ich nicht. Aber was in der grafischen EV läuft sollte auch in Lua laufen, meine ich.

Gruß Timba

[Neo]

Hallo,

vor 4 Minuten schrieb fzonk:

Eigentlich dachte ich das Ereignis wäre gar nicht so lang (groß), ich habe es mit der grafischen EV erstellt. Wenn ich es in Lua wandle (was schon mal eine Weile dauert bist es gewandelt ist) sagt es mir tatsächlich das dieses Ereignis aus 29227 Zeilen besteht.

vom Studio aus gibt es keine Grenzen, womöglich bist du hier auf eine Lua-Grenze gestoßen, die ich selber noch nicht kannte, aber 30.000 Zeilen sind schon extrem viel. Mehr lässt sich aber nur mit einem praktischen Beispiel sagen.

Viele Grüße,

Neo

[fzonk]

Ich habe die Anlage als Entwurf in den Katalog geladen Content ID: 82F8F6B7-0C05-4A47-B16F-3B1FE472D350

Die Anlage befindet sich noch im Bau, die grundlegende Zugsteuerung ist aber bereits fertig. Das „schuldige“ Ereignis findet ihr im Ordner „Zugsteuerung“ > „Ausfahrt aus Schattenbahnhof zu Klappbrücke“ > „Variable "Überprüfung" wird gesetzt“.

Gruß Frank

[Timba]

Hi Frank,

da muss sich mal Chef drum kümmern. Beim Versuch, die EV nach Lua zu konvertieren, hat sich mein MBS gerade verabschiedet. Rien ne va plus - nichts geht mehr.

Wird echt Zeit, dass hier ne andere Kiste untern Schreibtisch kommt.

Gruß Timba

[fzonk]

Hallo Timba,

ja es dauert eine gefühlte Ewigkeit bis es gewandelt ist und das Studio reagiert in dieser Zeit auch nicht mehr. Einmal geschafft bekommt man dann diese Meldung.

@Neo Ich befürchte mit meinen Ereignissen bin ich in der Tat an die Grenzen von Lua gekommen. Denn das letzte End schließt an einer Stelle ab, wo eigentlich noch etwas kommen müsste.

Gruß Frank

[fzonk]

Kleiner Nachtrag: es ist tatsächlich so, sobald ich aus dem einen Ereignis zwei mache funktioniert wieder alles und wird ordnungsgemäß abgearbeitet.

Gruß Frank

[Andy]

Verzeih mir Frank, dass ich da mal richtig grinsen muß. Das mußte ja irgendwann so kommen  Voll verzonkt! Die anderen trauen sich immer noch nicht in den Fluß zu hüpfen, da rauschst Du schon wieder mit Caracho den Wasserfall runter

liebe Grüße
  Andy

p.s.: Suche ergibt: Link
Die 70 elseif wird er schaffen, aber wohl nicht mit soviel Zeilen dazwischen.
Auslagern ist natürlich schlecht wegen defer...

Bearbeitet 3. Dezember 2019 von Andy

[BahnLand]

Hallo Frank,

schau Dir bitte mal das "ziemlich einfache" Beispiel an, das nur ais einer einzigen Ereignisdefinition besteht:

Pfad-Vervielfältigung.mbp

Ich habe hier einen Hauptpfad mit 3 hintereinander gereihten "Bedingungen", bei denen jeweils der "Erfüllt"-Pfad "normal" durchlaufen wird, während der "Nicht-Erfüllt"-Pfad jeweils eine weitere Bedingung enthält, wo in beiden Pfaden eine Zeitverzögerung eingebaut ist. Als "Inhalte" habe ich jeweils nur einen Kommentar eingefügt - genauso zwischen den Bedingungen des Hauptpfads. Und das war's dann auch schon. Insgesamt besteht die Ereignisdefinition aus 31 Einträgen.

Wenn Du jetzt das dazugehörigre Lua-Script anschaust, wirst Du dort 128 Zeilen anstelle der 31 Einträge in der grafischen EV-Derfinition finden, wobei die Mehrzahl der Zeilen als "Wiederholungen" auftreten.

Dies liegt daran, dass das Modellbahn-Studio die sich in der grafischen Ereignisdefinition wieder vereinigenden Pfade in Lua nicht ebenfalls wieder vereinigen kann. Der Grund liegt darin, dass auf eine Zeitverzögerung folgende Aktionen ablauftechnisch in einem neuen "Ereignis" abgearbeitet werden. Und dort müssen dann natürlich auch alle Pfade komplett hinterlegt sein, die im Anschluss an die Zeitverzögerung abgearbeitet werden sollen. In der grafischne EV nach einer Zeitverzögerung sich wieder vereinende Pfade müssen also in Lua jedem der Zeitverzögerungs-Ereignisse separat zugeordnet werden, wo sie durchlaufen werden sollen, und werden daher notgedrungen vervielfältigt.

Wenn also in der grafischen EV viele Verzweigungen, in denen unterschiedliche Zeitverzögerungen eingebaut sind, später wieder in gemeinsame Pfade einmünden, werden diese entsprechend vervielfältigt. Treten dann solche Verzweigungs-Konstellationen noch mehrmals hintereinander auf, führt das zu einer entsprechenden Multiplikation (nicht nur Addition!) der Vervielfältigungen aus den EInzelkonstellationen, was dann letztendlich zu einer "Explosion" der nach Lua umgewandelten Ereignisdefinition führt.

Und genau das ist bei Deiner Ereignisdefinition passiert!

Viele Grüße
BahnLand

Bearbeitet 3. Dezember 2019 von BahnLand

[fzonk]

Hallo BahnLand,

Vielen Dank für die ausführliche Erklärung. Das jede Verzweigung und Verzögerung zusätzliche Einträge (Zeilen) erstellt um es abarbeiten zu können war mir indirekt bereits bewusst. Das knapp 30000 Zeilen dadurch zusammengekommen sind erklärt dein Beispiel ja auch wunderbar. Jetzt ist nur noch die Frage warum Lua dies grundlegend nicht mehr abarbeiten möchte. Denn stabil gearbeitet hat das System, bis ein Eintrag zu viel hinzugefügt wurde.

Gruß Frank

[Goetz]

Hallo Frank,

darf ich dir einen Tipp geben?

vor 3 Stunden schrieb fzonk:

Das „schuldige“ Ereignis

kannst du anders und viel schlanker strukturieren.

Du rufst mit einer Vielzahl von Bedingungen jedesmal dasselbe benutzerdefinierte Ereignis auf und übergibst dabei unterschiedliche Werte. Damit muss deine EV viel zu viele Prüfungen durchlaufen, die schlicht nicht notwendig wären. Stattdessen könntest du die Werte, welche deine Entscheidungskriterien sind, an das benutzerdefinierte Ereignis übergeben. Und dort anhand dieser Werte ableiten, was zu tun ist.

Die richtige Aktion zu den möglichen Kombinationen hinterlegst du dann am besten in einer Tabelle. Die ist fast immer die bessere Alternative zu mehreren verschachtelten if-Verzweigungen. Weil du beim if alle einzelnen Stationen durchlaufen musst. Einen Tabellenplatz kannst du hingegen direkt adressieren.

Beispiel:
Ein Signal soll auf Fahrt schalten, wenn zwei Weichen dahinter auf Gerade stehen. Bei Abzweig soll Langsamfahrt gezeigt werden.

Signalstellung = { {3 , 3} , {3 , 2} }
a = W1 + 1
b = W2 + 1
Stellung = Signalstellung[a][b]

W1 und W2 stehen in diesem Pseudocode für die Stellungen der Weichen 1 und 2. Weil ich keine 0 gebrauchen kann, addiere ich noch eine 1 dazu.

Mit der Stelle der ersten Weiche wähle ich entweder den erstenoder den zweiten Block aus.
Mit der Stellung der zweiten Weiche wähle ich in dieser Gruppe entweder den ersten oder den zweiten Wert aus.

Nur wenn beide Weichen die Stellung 1 haben (was durch das Hinzuaddieren von 1 dann eine 2 ergibt), lande ich im zweiten Block beim zweiten Wert. Es ist im Beispiel der einzige Fall, in dem die Stellung 2 (= Fahrt) ist. In allen anderen Fällen bekomme ich eine 3 (= Langsamfahrt).

Es ist kein einziges if im Spiel.

Lieben Gruß
Götz

[fzonk]

Hallo @Goetz

Ein sehr interessanter Ansatz, jedoch bin ich bei weiten noch nicht so sicher im Umgang mit Lua, die ersten Versuche habe ich zwar bereits unternommen, aber bin noch weit entfernt um sicher damit zu arbeiten. Daher arbeite ich aktuell lieber noch mit der grafischen EV, zumal ich da schneller Fehler finden kann und beheben kann. Ja in der EV sind extrem viele Bedingungen eingebaut, vor allem verschachtelte. Da eine Vielzahl von Ereignissen aufeinander aufbauen fand ich diese Lösung gar nicht so verkehrt, auch wenn mir bewusst ist das der Steuerungsablauf damit ordentlich beschäftigt wird. Bis auf das der Eintrag offensichtlich zu umfangreich geworden ist funktioniert die Steuerung fehlerfrei! Aktuell habe ich das Ereignis auf zwei Ereignisse aufgeteilt, was in diesem Fall kein Problem darstellt, da ich die Prüfungen so getrennt habe, dass die beiden Ereignisse nicht gegeneinander arbeiten.

Gruß Frank

[Goetz]

vor 54 Minuten schrieb fzonk:

in der EV sind extrem viele Bedingungen eingebaut, vor allem verschachtelte.

und die scheinen mir, nach einer ersten Durchsicht von Variable "Überprüfung" wird gesetzt und Benutzerdefinierte Fahrt SB<KB das Ergebnis einer ungünstigen Taktik zu sein. Denn letztlich ist das, was passieren soll, vergleichsweise überschaubar.

Ich habe mich noch nicht genügend in dein Konzept hineindenken können, um alternative Vorschläge (ohne Lua) anzubieten. Ich habe derzeit den Kopf auch noch nicht richtig frei dafür. Aber vielleicht schaffe ich es nächste Woche irgendwann, dir konkrete Verbesserungsvorschläge zu machen. Wenn du das möchtest.

[fzonk]

Hallo @Goetz

 du kannst gern für die Anlage eine Alternative Steuerung erstellen. Aber ich möchte dir gleich sagen dass diese dann nicht für mich ist (auch wenn ich sie mir anschauen werde), denn meine Steuerung mag vielleicht nicht die beste Lösung zu sein (wenn es sowas überhaupt gibt) aber wie schon erwähnt, sie funktioniert! Daher habe ich auch nicht vor etwas grundlegendes daran zu ändern, ganz im Gegenteil, ich arbeite bereits weiter daran und werde die Steuerung noch erweitern.

 Gruß Frank

 

[Neo]

Hallo Frank,

du hast da tatsächlich eine Lua-Grenze erreicht, die mir bisher unbekannt war. Die sehr lange Verzögerung beim Wechsel von der grafischen EV zu Lua kann ich mir anschauen, weil hier im Studio sehr viel Zeit draufgeht. Das Problem mit den zu langen Blöcken werde ich vermutlich nicht auf die Schnelle beseitigen können, hier bleibt dir nur übrig, Teile des Ereignisses in benutzerdefinierte Ereignisse auszulagern und das Hauptereignis zu entschlacken.

Viele Grüße,

Neo

[fzonk]

Hallo @Neo,

 danke für deine Antwort, ich hoffe es hilft dir um das tolle Programm weiter zu entwickeln. Ich selbst habe mir bereits erfolgreich geholfen indem ich das eine Ereignis in zwei aufgeteilt habe. So funktioniert es auch wieder fehlerfrei, gibt halt zwei Ereignisse mit dem selben Auslöser, diese stehen aber nicht direkt in Konkurrenz, daher habe ich da auch keine Funktionsbedenken. In dem Ereignis selbst sind bereits einige benutzerdefinierte Ereignisse mit eingebaut. Ich könnte zwar in der Tat noch mehr in separaten benutzerdefinierten Ereignissen zusammenfassen, was ich vielleicht zu einem späteren Zeitpunkt noch machen werde, aber wie gesagt, momentan funktioniert alles wieder.

 Danke Frank

[fzonk]

Hallo an Alle,

hier noch mal ein kleiner Nachtrag. Ich habe mich dann doch noch mal hingesetzt und das Ereignis überarbeitet. Ich habe nahezu alle Verzögerungen aus dem Ereignis verbannt und diese Abläufe in benutzerdefinierte Ereignisse gepackt. Damit gibt es nahezu nur noch Bedingungen und benutzerdefinierte Ereignisse in diesem Ereignis. Die grundlegende Funktionsweise habe ich nicht geändert, ABER durch die Verbannung der Verzögerungen und die damit verbundenen Ereignisse konnte ich das Gesamtskript auf ein Zehntel „zusammenkürzen“. In Zahlen bedeutet dies, dass ursprüngliche Skript (nach Teilung) hatte 23833 Zeilen, nach der Bearbeitung und Nutzung von noch mehr benutzerdefinierten Ereignissen sind dann „nur noch“ 2048 Zeilen übriggeblieben. Daher kann ich als Fazit nur empfehlen, wenn man so wie ich mit einem Hauptereignis arbeitet, so viele wie mögliche benutzerdefinierte Ereignisse einzubinden und Abläufe die sich ähneln aus dem Ereignis zu verbannen, vor allem, wenn sie Verzögerungen beinhalten.

Gruß Frank

[Andy]

Das mit den benutzerdefinierten Ereignissen auf einem Level höher hatte ich angedacht, wie ich von 'Auslagern' gesprochen habe. Ich hatte aber nicht geschaut, wie Du's in der grafischen EV hättest machen können, mitsamt der Verzögerungen. Aber zum Glück findest Du immer einen Ausweg.

Gruß
  Andy