Lua Geschwindigkeitsunterschied zu EEP

Hallo Heiner,

Lua ist in EEP erst relativ spät integriert worden. Allein das spricht dagegen, Lua synchron im Spielverlauf einzusetzen. Aber selbst wenn Lua von Anfang an dabei gewesen wäre, wird es nie wirklich synchron im Spiel laufen. Jede Simulation hat so etwas wie eine Haupt-Schleife, die immer wieder durchlaufen wird. Darin werden die Veränderungen der Blickrichtung und der Umgebung abgearbeitet und auf das nächste auszuliefernde Bild angewendet. Dazu gehört alles, vom Wiegen der Bäume im Wind über animierte Wasseroberflächen, andere Animationen, fahrende Züge und Autos, Auslösen von Kontaktpunkten, Prüfen oder Vermeiden von Zusammenstößen und und und. In dieser Schleife wirst Du nie an jeder beliebigen Stelle mit Lua dazwischen funken dürfen.

Also bleibt Lua in gewisser Weise asynchron zum Spielverlauf. Und dann spielt es meines Erachtens keine Rolle mehr, ob Lua nun 5- oder 500-mal pro Sekunde aktiv wird. Die einzige Einschränkung dieser Aussage, die ich gelten lassen würde, wäre, dass man für den Eindruck von Bewegungen, die man durch Platzierungen in Lua darstellen wollte, etwa 25mal in der Sekunde "zuschlagen" können müsste.

Damit wir aber keine Scheinargumente austauschen, wäre es hilfreich, wenn Du die Probleme konkret benennen könntest, die durch eine höhere Taktung gelöst würden.

Gruß

Christopher

Hallo Heiner Hein von Frohnau ,

die meisten "Verschlucker" treten auf, weil EEP und Lua zwei asynchrone Programme sind. Einige Lua-Anwender vergessen das und wundern sich, dass ein Lua-Befehl in Lua nicht sofort ein abrufbares Ergebnis liefert.

Lua muss immer erst seine Daten an EEP übergeben, EEP muss darauf reagieren und seine Daten wieder zurück übergeben. Die Übergabe erfolgt immer nur einmal innerhalb der main-Schleife, also im günstigsten Fall alle 200 Millisekunden.

Dabei kann schon mal im ungünstigsten Fall ein main-Schleifendurchlauf in Lua übersprungen werden, daher rührt die Angabe 400 Millisekunden.

Die 5 mal pro Sekunde sind ein Kompromiss zwischen schneller Kommunikation Lua <-> EEP und der Notwendigkeit, möglichst alle anstehenden Befehle in einem Durchlauf in Lua abzuarbeiten. Verkürzt man diese Zeit kann es vorkommen, dass nicht alle Aufrufe in Lua abgearbeitet wurden und dadurch "Verschlucker" in der Zusammenarbeit auftreten. Deshalb ist es beispielsweise angebracht, zeitintensive aber nicht zeitkritische Funktionen in Lua nicht bei jedem main-Schleifendurchlauf aufzurufen.

Gruß Holger

Hein von Frohnau wrote:

Obwohl ich denke, dass gerade bei hohen (Zug-) Geschwindigkeiten eine häufigere Kommunikation zwischen EEP und Lua so manches (Zeit-) Problem minimieren könnte.

Hallo Heiner,

ich denke, dass wird eher das Gegenteil bewirken.

Gerade beim hohen Geschwindigkeiten ist EEP stark ausgelastet. Wie sehr EEP dabei zu tun hat siht man an den manchmal einbrechenden Frameraten. Alle 0.2 Sekunden sagt jetzt Lua "pausiere mal Deine Artbeit, ich möchte mit Dir Daten austauschen". EEP muss seine aktuellen Arbeiten kurz pausieren, zwischenspeichern um Daten mit Lua auszutauschen, dann seine Daten wieder abrufen und weiter normal arbeiten.

Wenn die Abstände dieser Lua-Zwischenrufe noch weiter verkürzt werden hat EEP immer weniger Zeit und damit sinkt die Framerate und unter einer bestimmten Framerate kam es in der Vergangenheit immer wieder zum Überspringen von Kontakten. Dieser 0,2 oder 0,4 Sekunden Verlust bei der Zusammenarbeit zwischen EEP und Lua stellt in den seltensten Fällen ein Problem dar, wenn sich der Lua-Nutzer (Programmierer) dieses Zusammenspiels zwischen EEP und Lua bewusst ist.

Er sollte also zum Beispiel wissen, dass er in einem main-Durchlauf nicht ein Signal stellen und danach im gleichen Durchlauf die neue Stellung abfragen kann.

Gruß Holger

Hallo,

wenn man diese Lua-Zykluszeiten kennt, muss man sie bei der Programmierung entsprechend berücksichtigen.

Kenne ich schon aus den 80ern seit dem Umgang mit den ersten SPS-Steuerungen.

200ms von EEP ist zwar min 10 mal langsamer als damalige SPS aber aufgrund der wichtigeren Echtzeit-Visualisierung/Berechung nicht schlimm, wenn man sich dessen bewusst ist.

Habe bei meine Anlagen selbst mit grossen Lua-Programmen bisher keine Probleme. Bisher befanden sich die Fehler immer vor dem Bildschirm

https://de.wikipedia.org/wiki/…programmierbare_Steuerung

Hey Maik !

Das Like musste sein.

Ich finde das der Satz :Bisher befand sich der Fehler immer vor dem Bildschirm ,

in den meisten Fällen stimmt!

VLG Angelika

Hein von Frohnau wrote:

dass Hyperthreading, was ja jeder halbwegs moderne Rechner beherrscht, keine Pausierung an der Stelle nötig sein lässt.

Hallo Hein,

dazu müsste EEP aber Hyperthreading unterstützen. EEP kann aber nur mit einem Core, deshalb ist für EEP nicht die Anzahl der Kerne sondern die Taktfrequenz entscheidend.

Schau Dir doch mal bei laufendem EEP die Prozessorauslastung nach Cores an.

Hein von Frohnau wrote:

Des Weiteren sprichst Du etwas später von Problemen bei geringen Framerates.

Auch das lget zum größten Teil nicht an der Grafikkarte, sonst müsste EEP auf jedem halbwegs modernen Rechner laufen wie am Schnürchen.

Nein EEP bereitet die gesamt Ausgabe in der CPU vor (ein Kern) und übergibt es dann an die Grafikkarte zur Ausgabe. Deshalb erreicht man mit Tricks und Einstellungen an der Grafikkarte nur unwesentliche Verbesserungen.

Gruß Holger

Hein von Frohnau wrote:

Wäre vermutlich sehr umfangreich;

aber auch machbar?

Hallo Hein,

da haben schon andere sich den Kopf zerbrochen und aufgegeben.

Gruß Holger