Timer in der EV

[Timba]

Hallo @Neo,

wäre es vielleicht möglich (wenn es nicht zu viel Mühe macht), in der Übersicht der Timer neben Dauer und Restzeit auch anzuzeigen, ob automatischer Neustart oder nicht? Manchmal hat man versehentlich auf AutoNeustart geklickt oder vergessen, AutoNeustart rauszunehmen (AutoNeustart ist anscheinend default). Dann kann man das in der Übersicht bereits überprüfen ohne jeden einzelnen Timer anklicken zu müssen. Wäre wirklich ein Erleichterung, finde ich. Kästchen oder Buchstabe oder Kreuz, alles egal, Haupsache man sieht's.

[Neo]

Hallo Timba,

Timer ohne automatischen Neustart sind ein Relikt aus V4 und nur aus Kompatibilitätsgründen heute noch enthalten. Wenn du nur eine einmalige Verzögerung erreichen möchtest, ist die verzögerte Ausführung die bessere Wahl.

Viele Grüße,

Neo

[Timba]

Halo Neo, vielen Dank für den Hinweis. Ich werde das mal umbauen. Im vorliegenden Fall hatte ich mich für Timer entschieden, weil die den zusätzlichen Nutzen haben, auch als Auslöser zu dienen, was die verzögerte Ausführung nicht kann, aber das lässt sich mit einem benutzerdefinierten Ereignis auch irgendwie erreichen.

Abgesehen davon sind die Timer offenbar unzuverlässig geworden, wie ich gerade feststellte. Nachdem gestern einige Male ein Timer lief, der nicht hätte laufen dürfen und die Fehlersuche ergab, dass er auf AutoNeustart stand, was nicht hätte sein dürfen, habe ich peinlich genau darauf geachtet, dass bei keinem Timer der Haken gesetzt ist. Trotzdem hatte ich gerade wieder bei einem Timer den AutoNeustart drin. Das heißt, der stellt sich definitiv irgendwo von selbst ein, was eigentlich nicht sein dürfte. Von daher hätte ich mich sowieso davon verabschieden müssen.

Gruß Timba

[Timba]

Kommando zurück! Habe noch einen versteckten Start des Timers in einer anderen bereits vergessenen Versuchsanordnung entdeckt, der für den Neustart verantwortlich war. Also keine Fehlfunktion der Timers. Sorry.

[Neo]

Hallo Timba,

vor 25 Minuten schrieb Timba:

Im vorliegenden Fall hatte ich mich für Timer entschieden, weil die den zusätzlichen Nutzen haben, auch als Auslöser zu dienen, was die verzögerte Ausführung nicht kann, aber das lässt sich mit einem benutzerdefinierten Ereignis auch irgendwie erreichen.

genau, wenn du die verzögerten Aktionen stärker von dem ursprünglichen Ereignis trennen möchtest, dann verschiebe die Aktionen in ein benutzerdefiniertes Ereignis und rufe dieses Ereignis (mit deinen gewünschten Parametern) nach der Verzögerung direkt auf. Du bekommst dadurch auch noch die zusätzliche Möglichkeit, die "verzögerten Aktionen" manuell zu starten, z.B. durch einen Schalter.

Viele Grüße,

Neo

[Andy]

vor 1 Stunde schrieb Neo:

Timer ohne automatischen Neustart sind ein Relikt aus V4

Oh oh. Das sehe ich nicht so Neo, eher umgedreht.
Ich würde Dir vielleicht zustimmen, wenn ich wüßte, wie ich eine verzögerte Ausführung stoppen kann, sodass der Nachfolgepart garantiert nicht ausgeführt wird.

[Neo]

Hallo Andy,

durch eine einfache Bedingung, die du den verzögerten Aktionen vorschaltest, sollte es sich um eine unterbrechbare Verzögerung handeln. Dafür Timer zu verwenden ist problematisch:

• Die Beziehung zwischen den verzögerten Aktionen ist durch Auslagerung in einen Timer oft nicht sofort ersichtlich
• Es gibt immer nur eine Instanz eines Timers, Verzögerungen können pro Ereignis mehrfach "gestartet" werden, mit eigenen Parametern. Das ist Grundvoraussetzung für eine schlanke EV.

Technisch lassen sich Verzögerungen stoppen, in der EV können Verzögerungen per Benutzeroberfläche gelöscht werden. Das automatisierte Löschen ist jedoch problematisch, weil durch die Mehrfachinstanzen nicht klar genug geregelt ist, welche konkrete Verzögerung gemeint ist. Durch IDs und benutzerdefinierte Kennungen könnte man das lösen, allerdings halte ich das Einfügen einer einfachen Bedingung am Ende für den übersichtlicheren Weg.

Viele Grüße,

Neo

[Andy]

Dass es nicht mehr einfach ist, eine solche verzögerte Ausführung aufzuhalten, liegt in der Natur der Sache.
Ich habe nur ein schlechtes Bauchgefühl, wenn da im Hintergrund noch die Bombe tickt, denn das Einfügen der einfachen Bedingung am Ende ist zwar eine Option, aber der Wahrheitswert der Bedingung kann sich mittlerweile erneut eingestellt haben, bezieht sich aber nicht mehr unbedingt auf das vorher eingeleitete Ereignis, das eigentlich schon längst hätte abgehakt sein können.
Ich kann Dir nicht mal ein Beispiel aus meiner Anlage nennen, ich habe kritische Situationen bislang vermeiden können und nutze die verzögerte Ausführung gerne.
Aber ein Beigeschmack bleibt mir da. Also, ein Singleshottimer sollte, wenn möglich, doch im Programm verbleiben.

Gruß
  Andy

[Andy]

Ich kann Dir noch ein Beispiel aus dem Maschinenbau nennen, das für MBS natürlich ein wenig hinkt.
Da hat man bei Zylindern in der Regel Endstellungsnäherungsschalter, die gelegentlich auch mal kaputt gegangen sind.
So habe ich eine Option zur Verfügung gestellt, die Endstellung stattdessen auf ein Zeitglied umzulenken, damit die Maschine weiter genutzt werden konnte.
Ist dann eine Art Notbetrieb gewesen, denn ein entprellter Näherungsschalter (und bei der Entprellung wird auch wieder ein Timer gebraucht!) ist sicherer.
Aber zumindest stand das Element 'Zeitglied' zur Verfügung.

[Timba]

vor 27 Minuten schrieb Andy:

aber der Wahrheitswert der Bedingung kann sich mittlerweile erneut eingestellt haben,

Das liegt aber doch an der Bedingung, die man dafür auswählt. Wählt man z.B. eine eigens dafür geschaffene Variable, die durch nichts anderes angefasst wird und nur als An/Aus-Schalter für die Verzögerung dient, dann dürfte die sich kaum "unbeabsichtigt" ändern. Oder sehe ich das falsch?

[Timba]

vor einer Stunde schrieb Neo:

Du bekommst dadurch auch noch die zusätzliche Möglichkeit, die "verzögerten Aktionen" manuell zu starten, z.B. durch einen Schalter.

Ja. Einziger Wermutstropfen: Den Ablauf der verzögerten Aktion kann ich im Ereignisprotokoll nicht so schön beobachten und nachvollziehen wie es bei Timern möglich ist.

[Andy]

vor 31 Minuten schrieb Timba:

Das liegt aber doch an der Bedingung, die man dafür auswählt

Ja, da diskutiere ich im Hintergrund auch gerade mit Götz. Das sieht er auch so. Aber ich bin der Meinung, dass wir z.B. bei einer Blocksteuerung sehr häufig zyklisch wiederkehrende Situationen haben, die dann kaum unterscheidbar sind und dann ist schnell mal was aus dem Takt gekommen.

[Timba]

vor 2 Minuten schrieb Andy:

Aber ich bin der Meinung, dass wir z.B. bei einer Blocksteuerung sehr häufig zyklisch wiederkehrende Situationen haben, die dann kaum unterscheidbar sind und dann ist schnell mal was aus dem Takt gekommen.

Das erscheint mir nachvollziehbar. Je umfangreicher und komplexer eine EV und umso mehr verzögerte Ausführungen sie beinhaltet, umso unübersichtlicher und verwirrender wird es, für jede Verzögerung eine eigene Variable zu pflegen. Da ist es mit eindeutig benannten Timern schon einfacher. Es wäre vielleicht leichter, wenn man die Verzögerungen auch nicht einfach "Verzögerung" nennt, sondern auch umbenennen könnte. Nur so eine spontane Idee.

Momentan versuche ich, solche Situationen, die einen vorzeitigen Abbruch einer einmal aufgerufenen verzögerten Ausführung notwendig machen, lieber zu vermeiden.

[Andy]

Das ist letztlich auch alles eine Softwaredesign-Frage. Man kann aber von Anfängern nicht erwarten, dass sie überhaupt designen! Dann lieber ein bewährtes Tool (SingleShotTimer) am Leben lassen. Natürlich reizen die großen Möglichkeiten jetzt auch mit einem großen Projekt anzufangen. Dann kann sowas helfen, es überhaupt noch zu retten...

[Neo]

Hallo,

"SingleShotTimer" werden sicherlich nicht so schnell verschwinden, das Studio unterstützt ja auch alte Anlagen. Und solange die Steuerung sehr einfach ist, gibt es zwischen Timern und Verzögerungen keine großen Unterschiede. Hat man auf seiner Anlage aber 20 Bahnhöhe mit 10 Gleisen, will niemand 200 Timer verwalten, nur um einen Zug nach einer kurzen Wartezeit wieder im Bahnhof zu starten.

Viele Grüße,

Neo

[Timba]

Für 20 Bahnhöfe mit je 10 Gleisen braucht man wahrscheinlich einen Hochleistungsrechner, den ich leider nicht habe.