Herausforderung: verzögerte Ausführung

[AndreasWB]

Hallo,

da es das gewünschte Feature noch nicht gibt, muß ich in der EV innerhalb einer Liste von Fahrstraßen abfragen, welche die aktive ist, um dann nach Öffnen des Gleissperrsignals verzögert das zugehörige Hauptsigan zu öffnen.
Doch dabei erhalte ich beim Programmieren der entsprechenden EV diese Meldung: siehe Bild.

Ich denke mal, dies unterstreicht die Notwendigkeit des gewünschten Features.

Die Entwicklung der EV habe ich daher an dieser Stelle abgebrochen.

Sonst müßte ich die erhaltenen Informationen in Zwischen-Variablen schreiben und dann in weiteren Schritten nach der Schleife separat in entsprechenden Anweisungen verwenden.

Umständlicher geht es nimmer !

Gruß

Andreas

Bearbeitet 19. Oktober von AndreasWB

[Neo]

Hallo Andreas,

wenn du die Anweisungen innerhalb der Wiederholung in ein benutzerdefiniertes Ereignis packst, dann kannst du dort mit Verzögerungen arbeiten.

Viele Grüße,

Neo

[AndreasWB]

Hallo @Neo,

OH!
Also doch "Verzögerungen innerhalb von Schleifen"?

Gruß

Andreas

[AndreasWB]

Hier speichere ich also nicht in Zwischenvariablen, sondern übergebe als Prameter an eine Subroutine.
Läuft auf Gleiche hinaus.

Wie im Feature-Wunsch demonstriert, gibt es zahlreiche Anwendungs-Fälle.

Gruß
Andreas

Bearbeitet 19. Oktober von AndreasWB

[Neo]

vor 5 Minuten schrieb AndreasWB:

Also doch "Verzögerungen innerhalb von Schleifen"?

Indirekt ja. Solange dein Feature-Wunsch noch nicht implementiert ist, ist das deine beste Option.

Viele Grüße,

Neo

[Goetz]

Hallo Andreas,

Gerade eben schrieb AndreasWB:

Also doch "Verzögerungen innerhalb von Schleifen"?

nicht wirklich, denn das benutzerdefinierte Ereignis ist ja von der Wiederholung entkoppelt.

• Eine Wiederholung (for ... do ...) arbeitet nur in schneller Folge alle Elemente einer Liste ab.
• Eine Verzögerung sorgt im 3D-Modellbahn Studio dafür, dass ein Ereignis nach Ablauf der Zeit ein zweites Mal getriggert wird.

Deshalb passt eine Verzögerung nicht in eine Wiederholung. Weil sich die Wiederholung selbst nicht unterbrechen lässt.

Aber wenn jedes Element an ein benutzerdefiniertes Ereignis übergeben wird, dann können all diese benutzerdefinierten Ereignisse nach Ablauf der Zeit jeweils ein zweites Mal getriggert werden. Weil das dann alles separate Ereignisse sind.

Hilft dir das zum besseren Verständnis der technischen Hintergründe?

Viele Grüße
Götz

[AndreasWB]

Hallo @Goetz,

klar, danke.
Natürlich sollte man die Abarbeitung einer Schleife, zumindest in MBS, nicht unnötig verzögern.
Aber manchmal muß eben der nächste Schritt (z. B. in realen Programmen die Abfrage einer Schnittstelle - pollen) verzögert erfolgen.

Da das in MBS so nicht vorgesehen und wohl aus verständlichen Gründen auch nicht erwünscht ist, -> bitte nochmals über den Feature-Wunsch nachdenken.

• Eine Bahnschranke muß erst geschlossen sein, bevor die Fahrstraße, in die sie eingebunden ist, gestartet werden kann,
• ein weiteres Signal (Abfahrt-Signal) schaltet erst mehrere Sekunden später,
• etc.

Danke.

Gruß

Andreas

[Goetz]

vor 15 Minuten schrieb AndreasWB:

nochmals über den Feature-Wunsch nachdenken

Deine Bedürfnisse sind schon klar, Andreas.
Aber der Weg über eine Verzögerung innerhalb der Wiederholung ist der falsche Ansatz zur Problemlösung.

[AndreasWB]

Ja @Goetz,

genau deshalb der Feature-Wunsch.

So, wie Ihr das Workaround vorgeschlagen habt, könnt Ihr das von MBS-Anwendern ohne Programmier-Erfahrung nicht verlangen.

Das sag' ich Euch jetzt als Senior Software Architekt und IT-Dozent.

Gruß

Andreas

[Goetz]

vor 1 Minute schrieb AndreasWB:

So, wie Ihr das Workaround vorgeschlagen habt ...

darf ich dir ein praktisches Beispiel zeigen?

 

[AndreasWB]

Hallo @Goetz,

gut dargestellte Situation.

nachbauen wird es (fast) Jeder hier können.

Aber der Transfer auf vollkommen andere Situationen?

Gruß

Andreas

[Goetz]

vor 2 Minuten schrieb AndreasWB:

der Transfer auf vollkommen andere Situationen

Mein Anliegen bei dem Video war, dem User anhand des Beispiels soviel Verständnis mitzugeben, dass er nicht auf Nachbauen angewiesen ist. Dass ihm Prinzipien und Zusammenhänge deutlich werden.

Diejenigen, die nur abschreiben können, brauchen auch keine zusätzlichen Werkzeuge. Die wissen ja nicht, was man damit anstellt.
Die bekommen dafür hier jede Unterstützung, die sie brauchen. Egal ob Fehlersuche oder Fallbeispiele ... das ist das Schöne an einer Community. Wir ergänzen einander.

Lieben Gruß
Götz

[Neo]

Hallo Andreas,

der Lösungsvorschlag ist zunächst an dich als Thread-Ersteller gerichtet. Natürlich ist das Thema damit nicht beendet, deinen Feature-Wunsch habe ich gesehen und werde ihn auch prüfen.

Viele Grüße,

Neo

[AndreasWB]

Hallo zusammen,

wie ich meinen Schülern/Studenten immer sage: "Es gibt nicht die eine richtige Lösung, sondern mehrere gute Lösungen.", so habe ich heute eine einfachere, aber genauso gut funktionierende Lösung für die aktuelle Aufgabenstellung gefunden.

Soviel zum Thema "Systemanalyse und Programm-Design".

Gruß

Andreas

P.S. umgestzt sieht es dann so aus:
https://mega.nz/file/R6VQ3QRD#qzV7-TlOpUhLKvSdTmlpYPwMMHQFbHSAZelDqjJG_Tg

Bearbeitet 20. Oktober von AndreasWB
Video hinzugefügt

[AndreasWB]

Hallo @Goetz,

vor 17 Stunden schrieb Goetz:

Diejenigen, die nur abschreiben können, brauchen auch keine zusätzlichen Werkzeuge. Die wissen ja nicht, was man damit anstellt.
Die bekommen dafür hier jede Unterstützung, die sie brauchen. Egal ob Fehlersuche oder Fallbeispiele ... das ist das Schöne an einer Community. Wir ergänzen einander.

das ist schön und auch gut so.
Nur würde den Nutzern das Arbeiten mit MBS wesentlich mehr Spaß machen, wenn sie auch selbständig schnell zum Ziel kommen.

Da können die Entwickler einer Anwendung ganz wesentlich dazu beitragen.

Gruß

Andreas

[Goetz]

vor 10 Minuten schrieb AndreasWB:

Nur würde den Nutzern das Arbeiten mit MBS wesentlich mehr Spaß machen, wenn ...

Du lehnst dich hier sehr weit aus dem Fenster, wenn du dich zum Sprecher für "den Nutzer" machst.
"Den Nutzer" kennt Neo besser als du. Er sieht, was seinen Usern Spaß bereitet und wo was weh tut.

Dass er dabei ein anderes Bild bekommt als du ist kein Indiz dafür, dass er nicht verstehen würde, was die User wollen.

 

[prinz]

Wenn ich mich einmischen darf ...

Wer lange im IT-Bereich oder Software-Entwicklung (wie auch ich) gearbeitet hat, weiß, dass es in fast allen Entwicklungssystemen Restriktionen gibt. Dann gibt es immer zwei Möglichkeiten:

- Jammern und den Softwarehersteller kontaktieren

- Eine kreative und machbare Lösung für das Problem finden

Wenn also jetzt (derzeit) keine Verzögerungen in einer Wiederholung erlaubt sind (aus welchen Gründen auch immer), würde ich in diesen Fall innerhalb der Wiederholung die aktuell aktive Fahrstraße oder das dazugehörige Hauptsignal in eine Variable des auslösenden Sperrsignal schreiben und nach Ende der Wiederholung nach einer Verzögerung dann dieses Hauptsignal schalten. ==> Aufgabe gelöst.

Nichts für ungut, aber musste ich mal loswerden.

Viele Grüße,
    Wolfgang

 

 

[Phrontistes]

Hallo @AndreasWB,

nachdem Du auch die Bahnschranke ansprichst, die zu schließen ist, bevor eine Fahrstraße aktiviert wird: Das ist ein recht kniffeliges Problem.  Ich musste einige Routinen schreiben, um den Bahnübergang zufriedenstellend in der Griff zu bekommen. Eine Möglichkeit ist, dass die Fahrstraße das Schließen anfordert. Das muss natürlich frühzeitig geschehen und geht nur, wenn der Bahnübergang noch ein Stück entfernt ist. Ansonsten muss der close request anderweitig rechtzeitig ausgelöst werden.

Dein Wunsch

Zitat

Eine Bahnschranke muß erst geschlossen sein, bevor die Fahrstraße, in die sie eingebunden ist, gestartet werden kann,

würde meine Logik "Close request by route" zerstören. Neo muss also schon aufpassen, was er bei der Erfüllung von Wünschen an anderer Stelle kaputtmacht.

Beste Grüße

Phrontistes

Bearbeitet 20. Oktober von Phrontistes

[AndreasWB]

Hallo @Phrontistes und die Anderen,

ja, der Bahnübergang ist ein besonders wichtiger Grund, weshalb es die Möglichkeit der Zeitverzögerungen für die Aktivierung der einzelnen Fahrstraßen-Objekte geben sollte.

Solange es diese Möglichkeit nicht gibt, benötigt die Fahrstraße eben eine EV (wer will, auch ein LUA-Skript), die die Abläufe steuert.
Nur das erst zu schaltende Element kann durch die Fahrstraße direkt geschaltet werden, alle weiteren dann durch besagte Workaround-EV. Wie diese dann gestaltet wird, bleibt natürlich jedem selbst überlassen und hängt von den Gegebenheiten auf der Anlage ab.

Für eine einfache Konstellation hänge ich eine kleine Beschreibung an, die in erster Linie den zu treibenden Aufwand anschaulich machen soll, jedoch keine EV-Programmieranleitung darstellt.

Am 20.10.2024 um 16:19 schrieb Goetz:

Du lehnst dich hier sehr weit aus dem Fenster, wenn du dich zum Sprecher für "den Nutzer" machst.
"Den Nutzer" kennt Neo besser als du. Er sieht, was seinen Usern Spaß bereitet und wo was weh tut.

@Goetz,

ich lehne mich nicht aus dem Fenster, sondern spreche aus Erfahrung als langjähriger Software-Architekt und IT-Dozent.
Und wo es bei manchen Nutzern "hängt", erkannt man hier im Forum aus den sich wiederholenden Fragen zu immer den gleichen Problemen.

Aber diese Mankos mit der Bedienbarkeit haben große kommerzielle Anwendungen aber auch.

Gruß

Andreas

Signale zeitversetzt in FS schalten.pdf

[Cafépause]

Hmmm ... natürlich müssen Bahnübergänge gesichert sein bevor ein Zug sich annähert. Nur muss das doch nicht zwingend direkt bei der Fahrstrassenfreigabe erfolgen?

Wenn ein Bahnübergang ziemlich am Ende einer Fahrstrasse liegt, müssten die Autofahrer ewig bis zur Zugkreuzung warten. Noch dazu ist auch im echten Leben noch lange nicht jeder Bahnübergang signalgedeckt.

Ich sehe das eher so das hier weiterhin Handarbeit angesagt ist. Ob Lua oder grafisch ist nebensächlich. Der Einbauort jedes Bahnübergangs und die Anforderungen an Signalabhängigkeiten ist und bleibt eine individuelle Anforderung.

VG, Cafépause

[Phrontistes]

vor 7 Stunden schrieb AndreasWB:

die Möglichkeit der Zeitverzögerungen für die Aktivierung der einzelnen Fahrstraßen-Objekte

würde ich an der Stelle von @Neo wahrscheinlich nicht vorsehen, weil das für den Spielbahner logisch zu komplex ist und derjenige, der mit komplexer Logik umgehen kann, sich das für ihn und die jeweilige betriebliche Situation genau passend mit der EV basteln kann. Und alles könnte auch dieses Feature nicht abdecken, z.B. nicht Bahnübergänge und erst recht nicht BÜ-Überwachungssignale.

vor 4 Stunden schrieb Cafépause:

Ich sehe das eher so das hier weiterhin Handarbeit angesagt ist.

Für die erforderliche Handarbeit, wäre schön, wenn @Neo das Ereignis "Fahrstraßenstatus hat sich geändert" einführen würde, wie ich es an anderer Stelle schon mal angeregt habe. Bisher weiß ich nicht, ob die Anweisung "route.active = true" zum route.state 1, 2 oder 3 führt. Ich kann das im Ereignis "Route is activated/deactivated" zwar prüfen, aber eben nur, wenn das Ereignis stattfindet und es findet nicht statt, wenn der state auf 1 oder 2 wechselt, nur wenn er auf 3 (oder 0) wechselt.

Beste Grüße

Phrontistes

Bearbeitet 27. Oktober von Phrontistes
typo