Grundsätzliche Fragen zu "Schlagwörter" und "Benutzerdefinierte Ereignisse" etc.

[Swen44]

Danke. In der Langfassung habe ich es kapiert. Ich habe nämlich nicht nachvollziehen können, was da mit der Text-Liste in dem Beispiel passiert. 

Noch mal für ganz Dumme: Wenn ich von einem Ereignis aus ein anderes Ereignis aufrufe, das eine Verzögerung in sich enthält, dann wird die Verzögerung zwar in dem zweiten (aufgerufenen) Ereignis logisch abgearbeitet, aber das erste (aufrufende) Ereignis wird derweil weiter abgearbeitet, dass ja keine Verzögerung hat.

Das ist aber streng genommen unlogisch, weswegen ich so lange zum Kapieren brauchte. Denn ein aufgerufenes Programm (Ereignis) ist ja von der Logik ein Unterprogramm. Und das Unterprogramm wird durch den Aufruf in die Abfolge des Hauptprogramms eingeschoben, so dass rein logisch das Hauptprogramm anhalten müsste, bis das aufgerufene Unterprogramm vollständig abgearbeitet ist. Die Zeitverzögerung des Unterprogramms wird im Hauptprogramm ignoriert.

[Phrontistes]

vor einer Stunde schrieb Swen44:

Das ist aber streng genommen unlogisch

Nein, das ist es nicht. Es gibt auf der Anlage ständig Ereignisse, welche alle sofort vollständig abgearbeitet werden müssen, sonst gäbe es Chaos.

vor einer Stunde schrieb Swen44:

Die Zeitverzögerung des Unterprogramms wird im Hauptprogramm ignoriert.

Es gibt keine Haupt- und Unterprogramme. Jedes Ereignis, auch das benutzerdefinierte, ist gleichwertig.

Die Verzögerung ist keine Pause. Vielmehr wird dadurch das gleiche Ereignis nach der eingestellten Zeit nochmals aufgerufen. Innerhalb eines solchen Ereignisses sorgen Bedingungen dafür, dass das so verarbeitet wird, dass es aussieht wie eine Verzögerung. Das kannst Du sofort sehen, wenn Du auf Lua umschaltest.

[EASY]

Hallo @Swen44,

Vielleicht hilft Dir diese Betrachtungsweise weiter:
Das was Du zu einem bestimmten Ereignis in der EV festlegst, ist eine Liste von Aktionen, die ausgeführt werden sollen, wenn das Ereignis ausgelöst wird und hat mit "Hauptprogramm" und eventuellen "Unterprogrammen" nichts zu tun... die Liste wird einfach nur abgearbeitet.

Gruß
EASY

[Swen44]

Hallo Phrontistes und Easy,

das ist schon alles klar. Es gibt kein Haupt- und Unterprogramm in dem Sinne. Das richtet sich ganz nach der Art des Aufrufs. -

Jedes Ereignis in der Steuerung ist quasi ein kleines Programm. Und es ist auch klar, dass diese Ereignisse parallel abgearbeitet werden müssen, wenn da mehrere Züge unterwegs sind. Sonst würde das Alles ja auch nicht funktionieren.

Wenn ich aber von einem dieser Ereignisse ein anderes Ereignis aufrufe, was vor allen bei den benutzerdefinierten Dingern meist der Fall ist, dann ist das aufgerufene Ereignis dem Ereignis untergeordnet, wovon ich es aufgerufen habe. Und das ist dann mit anderen Begriffen ein Hauptprogramm, was ein Unterprogramm aufruft und im Hauptprogramm nutzt. Die Art des Aufrufs definiert, wie das jeweilige Ereignis einzuordnen ist. Ob jetzt Ereignis oder Programm - das sind nur Begriffe für die selbe Sache. 

Mich hat irritiert, dass das aufrufende Programm (was dadurch zum Hauptprogramm wird) weiter abgearbeitet wird, obwohl das dort aufgerufene sozusagen Unterprogramm noch gar nicht fertig ist. In einer normalen Programmiersprache stopp das aufrufende Programm die Abarbeitung an der Stelle des Aufrufs des anderen (Unter-)Programms, bis das Aufgerufene (Unterprogramm) fertig ist und setzt dann die Abarbeitung des eigenen Programms fort. Es sei denn, man programmiert direkt, dass das ursprüngliche Programm parallel weiter laufen soll. 

Ich habe es ja verstanden. Hier ist das das eben so, wie ihr das beschreibt. Da kamen aber meine Missverständnisse her.

Danke für eure Erklärungen.

LG Swen.

[Goetz]

vor 4 Stunden schrieb Swen44:

dann ist das aufgerufene Ereignis dem Ereignis untergeordnet, wovon ich es aufgerufen habe.

Nein, da bist du im Irrtum, Swen.

Von dem Moment an, wo du das benutzerdefinierte Ereignis auslöst, läuft es selbständig und vom Aufrufer unabhängig. Eben parallel.
Eine Verzögerung im benutzerdefinierten Ereignis sorgt dafür, dass dieses Ereignis nach Ablauf der Zeit ein weiteres Mal ausgelöst wird. Davon erfährt das andere Ereignis (in dem der erste Aufruf stand) aber nichts.

Der wichtigste Unterschied zu eigenständigen Programmen ist der, dass hier Lua Skripte in ein anderes, laufendes Programm (die Modellbahn Simulation) eingreifen. Und dieses andere Programm löst wiederum bei bestimmten Ereignissen einzelne Lua Skripte aus. Die Verzögerung läuft nicht in Lua, sondern im Studio. Dort sorgt eine Art Scheduler dafür, dass Skripte nach Ablauf der Zeit ein weiteres Mal ausgelöst werden.

Viele Grüße
Götz

[Swen44]

Danke Götz für die Erklärung. Ich nehme es dann mal so hin. Das ist quasi eine Kompromisslösung, die man eben so akzeptieren muss. Das wird wohl noch eine Weile dauern, ehe ich das richtig verinnerlicht habe. Bei meiner Bespielbahn, die ich vor kurzem ins Netz gesetzt habe, stand ich wieder vor diesem Problem. 
Ich werde da noch eine Weile tüfteln müssen.

[Goetz]

vor 24 Minuten schrieb Swen44:

Ich nehme es dann mal so hin.

Besser wäre, du würdest es logisch nachvollziehen und wirklich verstehen, Swen. Denn ein Kompromiss ist das nicht. Sondern ganz normale Automation.
Lua gibt Befehle an das MBS, wartet aber nicht auf deren Erledigung. Das wäre fatal, denn eine Drehscheibe z.B. braucht lange, bis sie ihr vorgegebenes Ziel erreicht hat. Wenn Lua stillhalten würde, bis dieser Befehl ausgeführt ist, würden viele andere Ereignisse in dieser Zeit alle unbehandelt bleiben.

Viele Grüße
Götz

[AndreasWB]

Hallo @Swen44 und die anderen,

vielleicht mal ein paar Grundsätzliche Erklärungen zu diesem Thema.

Die Begriffe "Hauptprogramm" und "Unterprogramm" sind in der Programmierung übliche Begriffe.

Ein Hauptprogramm ist das, was vom Benutzer oder anderen Initiatoren gestartet wird.
Es gibt aber auch Aufgaben, die immer wieder mal durchgeführt werden müssen. Um diese nicht für jede Ausführung extra wiederholt zu schreiben (unnötige Redundanz), wird jede Aufgabe einmalig im Programm-Code hinterlegt und dann im übergeordneten Programmablauf an der richtigen Stelle aufgerufen. Das sind dann eben die sogannten "Unterprogramme". Das Ganze steht auch im Zusammenhang mit Modularisierung (auch Wiederverwendung) und senkt den Wartungsaufwand von Software erheblich.

Es gibt aber zwei verschiedene Arten dieser Unterprogramme:

Funktionen
Diese Art von Unterprogramm erzeugt am Ende seines Ablaufs ein Ergebnis, das im übergerodneten (aufrufenden) Programm weiterverarbeitet werden soll.
Hier springt also die Verarbeitung vom aufrufenden Programm in diese Funktion. Erst wenn die Funktion fertig ist und das Ergebnis an das aufrufende Programm übergeben wurde, arbeitet das aufrufende Programm mit dem nächsten Programmschritt weiter.

Das ist wohl auch das, worann @Swen44 dachte.

Prozeduren
Hier haben wir es mit eigenständigen Unterprogrammen zu tun, die vom aufrufenden Programm angestoßen werden und eben ihr eigen Ding machen, ohne ein Ergebnis an das aufrufende Programm zu übergeben. Das Ganze läuft also programm-logisch gesehen parallel (unabhängig; asynchron) ab.

Daher macht das aufrufende Programm einfach ohne Unterbrechung mit seiner nächsten Anweisung weiter, weil es ja eben nicht auf das Unterprogramm warten muß.

Das ist der Mechanismus, der in der grafischen EV in MBS zur Anwendung kommt.

 

Wenn jetzt LUA eine hablwegs normale Programmiersprache ist, werden hier beide Formen von Unterprogrammen unterstützt.
Nicht aber in der grafischen EV von MBS.

Ich hoffe, das trägt etwas zur Aufklärung bei.

Gruß

Andreas

[Goetz]

Benutzerdefinierte Ereignisse sind keine Unterprogramme!

Es sind Ereignisse, deren Auslöser ein Befehl in der EV ist. Darüber hinaus unterscheiden sie sich nicht von anderen Ereignissen, deren Auslöser z.B. das Betreten eines Kontakts, das Schalten einer Weiche oder das Ablaufen eines Timers sind.

[AndreasWB]

Sorry @Goetz,

aber ich zitiere mal aus der Oberfläche zur Erstellung der EVs:

"Wann wird das Ereignis ausgelöst?
Manuell durch eine Ereignis-Aktion()"

Es ist also ein Programmschritt einer anderen EV, die dieses "Unterprogramm" aufruft. Es wird nicht direkt durch den Benutzer, bzw. einem Gleiskontakt, einem schaltenden Signal, ... gestartet.

Also nicht durch ein Ereignis auf der Anlage direkt.

[Phrontistes]

vor einer Stunde schrieb AndreasWB:

Das ist der Mechanismus, der in der grafischen EV in MBS zur Anwendung kommt.

vor 1 Stunde schrieb AndreasWB:

Nicht aber in der grafischen EV von MBS.

Ob graphisch oder Lua-Code spielt überhaupt keine Rolle. Du musst nur mal das graphisch Eingegebene mit dem "<>" umwandeln. Das was Du dort siehst, passiert wirklich.

vor 1 Stunde schrieb AndreasWB:

Wenn jetzt LUA eine hablwegs normale Programmiersprache ist

Wir haben es hier selbstverständlich nicht mit einem vollwertigen Lua zu tun, sondern mit einer kastrierten Lua-Implementation. Probiert einfach mal

file = io.open (filename [, mode])

Das wird aus guten Gründen nicht gehen.

[Phrontistes]

vor 44 Minuten schrieb Goetz:

Es sind Ereignisse, deren Auslöser ein Befehl in der EV ist.

 

vor 9 Minuten schrieb AndreasWB:

Es ist also ein Programmschritt einer anderen EV,

Und wo bitte schön, ist das jetzt der Unterschied?

Die Debatte dreht sich im Übrigen nicht um den Auslöser, sondern darum, dass es

vor 47 Minuten schrieb Goetz:

Darüber hinaus

keinen Unterschied gibt.

[prinz]

vor 3 Stunden schrieb AndreasWB:

Das ist der Mechanismus, der in der grafischen EV in MBS zur Anwendung kommt.

Das kann ich so nicht bestätigen. Ich habe in der grafischen EV schon öfter Benutzerdefinierte Ereignisse eingesetzt, um in mehreren Ereignissen ein Ergebnis ermitteln zu lassen (z.B. freien Platz im SBF ermitteln). Das Ergebnis wird als Variable zu einem als Parameter übergebenen Objekt eingetragen und vom aufrufenden Ereignis weiterverwendet. Wichtig: in dem Benutzerdefinierten Ereignis kommen keine Verzögerungen vor. Wenn also - nach Deiner Sprechart - Prozeduren "parallel" zu dem aufrufenden Ereignis weiterlaufen, könnte das so nicht funktionieren. Also wartet auch in diesem Fall das aufrufende Ereignis auf die Beendigung des benutzerdefinierten.

Weiterer Hintergrund: Vor einiger Zeit (Jahren) hatten ich und ein paar andere Anwender Probleme bei einer Vorfahrtsteurung für Abzweigungen. Ein wesentliche Punkt war dabei, dass Zähler für die aktuellen Fahrzeuge auf der Abzweigung manchmal falsche Werte ausgaben. Meine Vermutung damals, dass Ereigniss, welche den Zähler hoch- oder herunterzählen, sich dabei in die Quere kommen und so der Zähler verfälscht wird. Laut @Neo kann das jedoch nicht vorkommen, da vom MBS erst ein Ereignis abgearbeitet wird bevor das nächste begonnen wird. Wird die Abarbeitung durch eine Verzögerung unterbrochen (Frage: eventuell auch bei Aufruf eines benutzerdefinierten Ereignisses?), so können auch andere Ereignisse abgearbeitet werden bevor die Abarbeitung nach der Unterbrechung fortgesetzt wird.

Viele Grüße,
    Wolfgang

 

Bearbeitet gestern um 15:38 Uhr von prinz
Tippfehler

[AndreasWB]

Hallo @Phrontistes,

wenn Du Zitatschnipsel aus dem Zusammenhang reiß, versteht niemand mehr, worum es da geht.

vor 5 Stunden schrieb Phrontistes:

Wir haben es hier selbstverständlich nicht mit einem vollwertigen Lua zu tun, sondern mit einer kastrierten Lua-Implementation.

Habe ich gesehen. Es fehlt z.B. der gesamte Überbau (Programm-Rahmen) der Prozedur (benutzerdefiniertes Ereignis in MBS-EV).

@prinz:

Daß Du das Ergebnis in eine extra Variable außerhalb der Prozedur (benutzdefinierts Ereignis) stecken mußtes, liegt ganau an dem, was ich beschrieben habe: Prozedruren besitzen keine Rückgabe ihrer Ergebnisse.

Klar können Sie tun was auch immer sie wollen, das aufrufende Programm bekommt es nicht direkt zurückgegeben, sondern nur über den von Dir bechriebenen Umweg. Das ist aber keine saubere Software-Architektur.

Und über die asynchrone Abarbeitung hatte ich auch geschrieben. Wenn dann mehrere Prozeduren auf dieselben Variablen zugreifen, kann es genau zu den von Dir beobachteten Verwirrungen kommen.

Also ein weiterer Grund, die von mir beschriebenen Aspekte im Hinterkopf zu behalten.

So - das war's von meiner Seite zu diesem Thema.

Gruß

Andreas

[Goetz]

vor 17 Stunden schrieb AndreasWB:

Es ist also ein Programmschritt einer anderen EV, die dieses "Unterprogramm" aufruft.

Hallo Andreas,
beim ersten Aufruf, ja. Und hier wird die Kontrolle auch erst nach Abarbeitung der Befehle an das aufrufende Ereignis zurück gegeben. So weit verhält sich das benutzerdefinierte Ereignis wie ein Unterprogramm. 

Aber dort, wo eine Verzögerung im Ereignis steht, endet die Prozedur mit einem Befehl an das MBS, dieses Ereignis nach Ablauf der Zeit ein weiteres Mal aufzurufen. Dieser erneute Aufruf kommt also nicht mehr aus dem ursprünglichen Ereignis, sondern durch ein Ereignis auf der Anlage direkt, einer Art Fahrplan für den erneuten Aufruf verzögerter Ereignisse.

Deshalb wird die Kontrolle bei der ersten Verzögerung im benutzerdefinierten Ereignis an den Aufrufer zurückgegeben und nicht erst nach Ablauf der Verzögerung. Letzteres wäre auch fatal, weil die Verzögerung sonst die komplette EV für die Dauer lahm legen würde.

Dass ein Ereignis mit der ersten Verzögerung endet und verlassen wird, siehst du auch in Lua:

if not deferredCall then
  -- mach was
  defer(10, "Verzögerung")
elseif deferredCall == "Verzögerung" then
  -- mach was anderes
end

Wenn die Bedingung erfüllt ist, erledige alles vor dem elseif und gehe dann direkt zum Ende.

Viele Grüße
Götz

[prinz]

Hallo lieber @AndreasWB ,

Ich möchte hier nicht unbedingt eine Diskussion über verschiedene Softwareentwicklungs-Paradigmen anstoßen. Trotzdem kann ich das von Dir geschriebene nicht einfach so stehen lassen. Du redest immer von Hauptprogramm und Unterprogrammen. Dies sind zwar geläufige Begriffe, aber nur in der Welt der Prozeduralen Software-Entwicklung, so wie sie z.B. bei alten EVA-Verfahren (Eingabe - Verarbeitung - Ausgabe) verwendet wurde.

Bei objektorientierter Softwareentwicklung sieht das etwas anders aus. Meiner Meinung gibt es in der EV kein "Hauptprogramm", wahrscheinlich eher in der MBS-Engine. Bei der Objektorientierung werden Datendefinitionen und Methoden zu Objektklassen modelliert, die Daten dann bei den einzelnen Objekten der Klasse gekappselt. Dort ist es selbstverständlich, dass auch Daten eines Objekts innerhalb einer Methode der Klasse modifiziert werden können. Diese Methoden können auch von anderer Seite (Dein Sprech: Hauptprogramm) aufgerufen werden.

Unserer Teil der Ereignisbearbeitung ist daher einfacher in der Welt der Objektorientierung zu realisieren, da es hier immer darum geht, auf ein spezifisches Ereigniss zu einem oder mehreren Objekten zu reagieren. Leider gibt es (innerhalb der EV) keine Möglichkeit der Klassenbildung. Aber man kann durch die Zuweisung von Schlagwörtern Quasi Klassen bilden und so auf Ereignisse zu Objekten einer Klasse reagieren. (Übrigens gibt Lua an, dass es sowohl prozedurales als auch objektorientiertes Arbeiten unterstützt.) Ein Beispiel:

Auf einer Anlage kommen meistens verschiedene Klassen von Signalen vor. Nehmen wir einmal ein Blocksignal und ein Ausfahrtsignal eines Bahnhofs. Beide haben einige Eigenschaften gemeinsam: Bei Halt den Zug anhalten, bei Fahrt den Zug auf einen bestimmten Wert beschleunigen, eventuell nächste Fahrstraße ermitteln und aktivieren.
Beim Blocksignal eventuell nach Verlassen des Zuges den vorigen Block freigeben. Beim Ausfahrtsignal Handling des Zug-Aufenthalts (Türenmanagment, Haltezeit).

Objektorientiert sähe das ungefähr so aus, dass es eine gemeinsame Oberklasse Signal gibt, in welcher die gemeinsamen Aufgaben abgehandelt werden. Blocksignal und Ausfahrsignal wären demnach Unterklassen (Ableitungen) von Signal, in denen dann die genannten "Sonderaufgaben" abgehandelt werden. Es gibt also Ereignisse für Signale mit Schlagwort Blocksignal und solche für Ausfahrtsignal (z.B. Signal erreicht). In beiden Ereignissen wird das Benutzerdefinierte Ereignis "Signal erreicht" zur Abhandlung der gemeinsamen Aufgaben aufgerufen. Insofern lässt sich in der EV durchaus objektorientiert arbeiten (Auch wenn mir leider die Klassenbildung fehlt).

Und nochmal zur "asynchronen Verarbeitung": Asynchron wird die Verarbeitung nur, wenn in Ereignissen (initiert durch Ereignis oder benutzerdefiniert) Verzögerungen vorkommen, bei denen die Abarbeitung e. Ein Ereignis gleich welcher Art wird ansonsten immer von Anfang bis Ende abgearbeitet, bevor das nächste Ereignis in Angriff genommen wird. Auch die Teile zwischen Anfang/Verzögerung/Ende wird immer für sich ohne Unterbrechung abgearbeitet. Von daher kann es auch nicht vorkommen, dass mehrere "Prozeduren" gleichzeitig auf Variable zugreifen (es sei denn: siehe Verzögerung). Darauf kann man sich verlassen. Man merkt das sehr deutlich, wenn ein längerer Zug aus einem Depot abgerufen wird. Weil für diesen Vorgang (unter anderem) die Darstellung aller Objekte des Zuges neu erstellt werden muss, was nun mal einiges an Zeit kostet, kommt es hierbei zu unerwünschtem "Ruckeln" der Anlagendarstellung.

Zum Schluß: Ich habe das nicht als Kritik an Dich geschrieben, sondern um meine Erfahrungen in der EV hier einzubringen. Also nichts für ungut.

Viele Grüße,
    Wolfgang