Bezeichnung von Verzögerungen in der EV

[Hawkeye]

Hallo @Neo,

In der EV werden Verzögerungen, die im gleichen Ereignis stehen, zur Unterscheidung mit einer (Zahl) ergänzt. 

Auch wenn man das nicht in der grafische EV sehen kann, 

 

so wird es bei der Umwandlung in Lua deutlich :

Bei der Automatisierung von Abläufen mit Verzögerungen in der EV kommt es aber immer wieder vor, das "längere" Verzögerungen mit gleichem Namen wieder aufgerufen werden, bevor die zuerst aufgerufene Verzögerung mit dem selben Namen abgelaufen ist. Dadurch wird die erste Verzögerung überschrieben und es fährt z.B. ein ganz anderes, als das gewollte Fahrzeug los. Das zu verstehen, bis man diesen Fehler gefunden hat, dauert lange! 

Hier würde ich mir wünschen, das Verzögerungen intern zusätzlich automatische eine längere Zufallszahl verpasst bekommen, so das auch bei Aufruf des gleichen Ereignisses für andere Fahrzeuge innerhalb der Verzögerungszeit eine Unterscheidung bestehen bleibt. 

Oder alternativ, das man in der grafischen EV selber einen eigenen Verzögerungsnamen mit einer selbst gewählten Variablen (z.B. dem Fahrzeugnamen) setzten oder ergänzen kann, ohne auf Lua zurückgreifen zu müssen. Damit wäre eine Unterscheidung auch sichergestellt.  

Viele Grüße,

Hawkeye

[Neo]

Hallo Hawkeye,

hier kann etwas nicht stimmen. Verzögerungen überschreiben sich nicht, der Name dient nur dafür, die unterschiedlichen Bereiche innerhalb eines Ereignisses anzuspringen. Die Auslöser, die zu dieser Verzögerung geführt haben, werden für jede Verzögerungs-Instanz separat gespeichert und später wieder genutzt, wenn die Verzögerung erneut ausgeführt wird. Es stellt kein Problem dar, wenn eine neue Verzögerung gestartet wird, obwohl die alte Verzögerung noch nicht abgelaufen ist, alle Verzögerungen werden in einer Liste aufgesammelt, die du unterhalb des Ereignisses einsehen kannst.

Viele Grüße,

Neo

[Sintbert]

Hallo @Hawkeye  @Neo

Ich hatte schon das Problem, dass bei verzögerten Aktionen zum Teil die Auslöser nicht mehr zur verfügung standen. Vielleicht ist das hier auch ein Problem?

Gruss
Sintbert

[Hawkeye]

Hallo Sintbert + Neo,

vor 1 Stunde schrieb Sintbert:

Ich hatte schon das Problem, dass bei verzögerten Aktionen zum Teil die Auslöser nicht mehr zur verfügung standen.

ja, um so einen Effekt geht es. Es scheinen dabei Variabeln irgendwie überschrieben zu werden.

vor 3 Stunden schrieb Neo:

hier kann etwas nicht stimmen. Verzögerungen überschreiben sich nicht,

Ich versuche mal etwas einfaches reproduzierbares zu erstellen, ist aber nicht so leicht. 

Viele Grüße,

Hawkeye

Bearbeitet 25. November 2022 von Hawkeye

[Hawkeye]

Hallo Neo,

vor 22 Stunden schrieb Neo:

Die Auslöser, die zu dieser Verzögerung geführt haben, werden für jede Verzögerungs-Instanz separat gespeichert und später wieder genutzt,

da hast du wohl recht, am Auslöser scheint es nicht zu liegen.

vor 22 Stunden schrieb Neo:

Es stellt kein Problem dar, wenn eine neue Verzögerung gestartet wird, obwohl die alte Verzögerung noch nicht abgelaufen ist

Das stimmt aber nur bedingt, es hängt damit zusammen welchen Variablen-Typ man in Verbindung mit einer Verzögerung verwendet. Bezieht man sich auf eine "Objektvariable", bei der das Objekt auch der Auslöser im Ereignis ist, dann geht es. 

Wird jedoch eine Verzögerung in Verbindung mit einer Modulvariablen verwendet, dann können diese Variablen während der "Verzögerungszeit" überschrieben werden. Zur Verdeutlichung hier ein Beispiel mit 4 Variationen und 2 gleich erscheinenden Ereignissen.

5 Signale werden um 2s zeitversetzt auf "Fahrt geschaltet. Die Loks fahren nach der eingestellten Verzögerungszeit (Voreinstellung = 4s) los, um eine Überlappung der Verzögerungen zu erreichen. (Diese Einstellung der Verzögerungszeit kann mit (+)/(-) variiert werden.) 

Zum Schalten der Signale kann aus 4 verschiedenen Steuerungsvarianten ausgewählt werden, die eigentlich alle das gleiche Schalt-Ergebnis liefern sollten.  Dazu gibt es 2 Ereignisse, um den Unterschied zu verdeutlichen. "Beispiel 1" mit Verwendung einer Objektvariablen und "Beispiel 2" mit Verwendung einer Modulvariablen. (Welches Ereignis benutzt wird, kann mit dem "schwarzen Taster" umgeschaltet werden.) Erwarten würde ich, das alle 8 programmierten Varianten das gleiche Ergebnis liefern. 

Das tun sie aber nicht. Hier das Beispiel. 

Test Verzögerungen.mbp  

Nur wenn keine Verzögerung (Verzögerungszeit = 0s ) existiert, dann verhält sich das Ereignis mit der Modulvariablen genauso wie das mit der Objektvariablen.  

 => Modulvariablen in Verbindung mit Verzögerungen sind mit Vorsicht zu verwenden. 

Viele Grüße,

Hawkeye

[Goetz]

Bei den Objektvariablen speichert jedes der Signale individuell seine Werte.
Aber du verwendest für alles nur eine Modulvariable.

Ich habe gerade nicht die Zeit, deine EV im Detail zu studieren.
Aber hast du bedacht, dass sich das nicht identisch verhalten kann?

Ich hege den Verdacht, dass nicht die Verzögerung schuld am Fehlverhalten ist. 

[EASY]

Hallo @Hawkeye,

Götz hat es schon auf den Punkt gebracht...

vor 3 Stunden schrieb Goetz:

Bei den Objektvariablen speichert jedes der Signale individuell seine Werte.
Aber du verwendest für alles nur eine Modulvariable.

Eine Variable ist durch die Verzögerung nicht vor dem Überschreiben geschützt. Egal ob es sich um eine Objekt- oder Modulvariable handelt.
"Auslöser" bezieht sich auf das Objekt welches ein Ereignis ausgelöst hat. Diese Information bleibt erhalten, weshalb Du für alle Signale ein Ereignis verwenden kannst auch wenn darin sich überschneidende Verzögerungen vorhanden sind. Wenn z.B. Signal2 schaltet und in der EV würde dadurch die Objektvariable von Signal1 verändert bevor die Verzögerung von Signal1 greift, dann hast Du genau das gleiche Problem.
In Deinem Beispiel funkioniert es also nur, weil mit den Objektvariablen für jedes Signal eine Variable zur Verfügung steht, die von den anderen Signalereignissen unangetastet bleibt. Für den direkten Vergleich müßtest Du also für jedes Signal eine Modulvariable anlegen....

Gruß
EASY

[Hawkeye]

vor 3 Stunden schrieb EASY:

Eine Variable ist durch die Verzögerung nicht vor dem Überschreiben geschützt.

Hallo Easy, 

das ist doch mal eine interessante Information, die man erst mal realisieren muß!  

Nur dumm, wenn einem der Wert, den man benötigt, nicht als Auslöser zu Auswahl angeboten wird und man deshalb auf eine Variable in Verbindung mit einer Verzögerung zurückgreifen muß. Dann darf man sich über ungewollte Effekte auch nicht wundern. 

Ich denke, die meisten Nutzer hier haben sich darüber bisher kaum Gedanken gemacht. 

Gruß,

 Hawkeye

Bearbeitet 26. November 2022 von Hawkeye

[EASY]

Hallo @Hawkeye,

vor 15 Stunden schrieb Hawkeye:

Nur dumm, wenn einem der Wert, den man benötigt, nicht als Auslöser zu Auswahl angeboten wird und man deshalb auf eine Variable in Verbindung mit einer Verzögerung zurückgreifen muß. Dann darf man sich über ungewollte Effekte auch nicht wundern. 

... aus Sicht der Variablen sieht es so aus:
Irgendwo in der EV steht ich soll mir einen Zug merken. An einer anderen Stelle steht ich soll diesem Zug eine Geschwindigkeit zuweisen. Wenn nun zwischen diesen beiden Aktionen noch einmal steht ich soll mir einen (anderen) Zug merken, dann tue ich das und weise eben dann diesem Zug eine Geschwindigkeit zu.

Was Du Dir dabei gedacht hast, ist der Variablen vollkommen egal, sie folgt Deinen Anweisungen und unterscheidet auch nicht in welchem Umfeld diese Anweisungen stehen. Auf Deinen Erwartungswert, sie ist in einer Verzögerungsschleife und soll sich nicht ändern, geht die Variable nicht ein... sie weiß das gar nicht, daß sie in einer Verzögerungsschleife ist.
Etwas auf die Spitze getrieben: Es könnte sein, daß ich die Variable unter dem Umstand ändern möchte, wenn Signal2 schaltet, bevor die Verzögerung von Signal1 greift und die Variable wüde in ihrem Verhalten Deinem Wunsch entsprechen sich (beim Verzögerungsaufruf) nicht zu verändern. Dann würde ich mich darüber beschweren, daß die Änderung der Variablen nicht greift, weil sie in einer Verzögerungsschleife aufgerufen wird. Dies wäre dann mein nicht erfüllter Erwartungswert an die Variable. Aber auch diese Erwartungshaltung wäre der Variablen egal... sie weiß nichts davon.

Gruß
EASY

[Hawkeye]

vor 4 Stunden schrieb EASY:

Was Du Dir dabei gedacht hast, ist der Variablen vollkommen egal, sie folgt Deinen Anweisungen und unterscheidet auch nicht in welchem Umfeld diese Anweisungen stehen. Auf Deinen Erwartungswert, sie ist in einer Verzögerungsschleife und soll sich nicht ändern, geht die Variable nicht ein... sie weiß das gar nicht, daß sie in einer Verzögerungsschleife ist.

Hallo Easy, 

eine schöne Erläuterung.  

Wenn ich z.B. das folgende Ereignis ausführe, ist klar, das der ICE auch sofort losfährt. 

Jetzt baue ich eine Verzögerung von 10 s ein, damit genau dieser Zug, den ich ja genau hier definiert habe, verzögert abfährt. Und jetzt erwartest du, das ich mir darüber absolut im Klaren sein muss, das vielleicht doch ein anderer Zug zu dem Zeitpunkt losfährt, weil die Variable ja in der Zwischenzeit während der Verzögerung überschrieben werden könnte.

Echt jetzt?  

Viele Grüße,

Hawkeye

[Eggu]

vor 34 Minuten schrieb Hawkeye:

Und jetzt erwartest du, das ich mir darüber absolut im Klaren sein muss, das vielleicht doch ein anderer Zug zu dem Zeitpunkt losfährt, weil die Variable ja in der Zwischenzeit während der Verzögerung überschrieben werden könnte.

Echt jetzt?  

Die Antwort auf diese Frage ist ein eindeutiges:  JA!

Auf so etwas muss man bei Ereignis-gesteuerten Echtzeit-Systemen immer achten, oder "höhere" Konzepte benutzen.

Solch ähnliche Diskussionen gab es in der Vergangenheit mehrfach, aber "meistens" verhält es sich so:

Wenn ein Event ausgelöst wird, dann wird der ganze zugehörige Code (EV oder Lua) "am Stück" abgearbeitet,
so dass benutze Variablen nicht "von außen"  (durch einen anderen Event)  überschrieben werden können.

Anders verhält es sich bei einer Verzögerung, da dann der Event-Code ja (zunächst) beendet wird,
und später (an anderer Stelle) wieder aufgenommen wird.

Dann können natürlich (gemeinsam benutze) Variablen überschrieben werden, je nachdem was die anderen Events in der Wartezeit so treiben,
aber das programmiert man ja selbst, manchmal will man das so. 

Wie oben schon mehrfach beschrieben, benutzt man vorzugsweise bei generisch programmierten Events (also Reaktionen auf Auslöser mit einem Schlagwort)
eine Objektvariable, weil die gibt es dann mehrfach und exklusiv (indem man diese bei dem auslösenden Objekt definiert, also Gleiskontakt, Signal usw,).

Näheres findet man bei "Programmierung von Echtzeitsystemen, Multi-Tasking, Multi-Threading, Semaphore-Konzept, Monitor-Konzept usw.)

Gruß Eggu

 

 

[Goetz]

vor einer Stunde schrieb Hawkeye:

Echt jetzt? 

Nein, da hast du ihn komplett missverstanden.

Denn in diesem Signal wird gewiss kein anderer Zug hinterlegt, bevor dieser nicht abgefahren ist.
Weil hier in dieser Zeit kein anderer Zug ankommen kann.

Aber ganz grundsätzlich:
Ja! Wenn du logische Systeme aufbaust, dann musst du dich mit logischen Konsequenzen befassen.
Du musst vor Augen haben, wer wann wo was speichert und ob er das darf oder nicht.

Viele Grüße
Götz

Nachtrag: Sorry @Eggu, ich hatte deinen Beitrag erst im Anschluss gelesen. 

Bearbeitet 27. November 2022 von Goetz
Ergänzungen