Frage zu systemstart()

[klaus_kraemer]

ich fände es am Ende des Tages fast logischer, wenn es eine Sektion [Systemstart] gäbe, wo man gezielt eigene Befehle für Zyklus 0 ergänzen kann. Und hier dann z. B. after() und delay() und ähnliches verbietet, weil es über die Grenzen des Systemstarts hinaus Wirkung hätte. Aber nur eine persönliche spontane Idee.

Wäre vielleicht wirklich ein guter Ansatz - wobei erst einmal eine genauere Aufklärung von foobar0815 oder enertegus schon hilfreich sein könnte - wenn sie diesen Thread nicht weiter ignorieren wollen. (Entschuldigt bitte den Sarkasmus - aber ich fühle micch gerade so richtig in der Servicewüste Deutschland, wo der Kunde schuld ist, wenn er ein Problem am bezahlten Produkt findet! Ihr konntet doch mal anders!)

[foobar0815]

Hi zusammen,

ich dachte eigentlich, die Antworten ergeben sich mit dem nächsten Update auf Version 6, an dem wir arbeiten.

Hier kommen mehrere Sachen zusammen:
- die Initialisierung der Objekte selbst
- die Erstellung von Ausgabeobjekten
- Die asynchrone Ausgabe.
- potentielle Definitionslücken (oder Bugs)
- die Historie des EibPC.

Früher (tm) gab es kein [InitGA], deswegen der alte Code aus EnertexV2.
Früher gab es auch nicht die Funktion initga(), deshalb gibt es da eine Mischung.

Die Verzögerung der Zeitausgabe liegt vmtl daran, dass das Objekt für die Ausgabe erzeugt wird, aber die programmgesteuerte Telegrammausgabe noch nicht freigeschalten ist. Das erfolgt erst nach dem Abfragen.

Generell hängt systemstart() Objekte in den allerersten Zyklus mit rein. Dieser Umfasst allerdings mehrere Phasen (Objekte mit Initialwert erzeugen, InitGA, Ergebnisse zuweisen + Abhängigkeiten aktualisieren. Und wann welches Objekt dran kommt unterscheidet sich dabei auch je nach Objekt.

Um sich damit aber nicht rumschlagen zu müssen und den Start nicht noch langsamer zu machen gibt es mittlerweile ready(), das genau einmal nach dem ganzen Initialisieren seinen Zustand ändert, wenn der EibPC in die normale Verarbeitung übergeht.


Mit dem Update auf Version 6 bringen wir einen neuen, optimierten Objekt-Scheduler und eine neue Initialisierungs-Option für Gruppenadressen. Diese reduzieren den Start, je nach Projekt, drastisch.

Wer schonmal rumspielen will, hier die Links. Ist noch Beta und ohne Gewähr, die Liste der Änderungen ist aber lang. Einen eigenen Thread dazu mit etwas mehr Infos schreiben wir noch, ich wollte jetzt aber nicht weiter vertrösten.

https://enertex.de/downloads/1159/11...in64-6.003.zip
https://enertex.de/downloads/1159/11...4-6.003.tar.gz
https://enertex.de/downloads/1159/11...bPC2-6.004.zip

Dauerbrenner: Das mitgeleiferte Handbuch ist noch nicht angepasst.

P-S: Am Compiler wurde auch viel geändert, u.A. Geschwindigkeit und Fehlerausgaben.

[Uwe!]

ich dachte eigentlich, die Antworten ergeben sich mit dem nächsten Update auf Version 6, an dem wir arbeiten.

von dem wir hier ja aber nichts wissen, insofern ist dann eine Antwort schon hilfreich.

Was Du schreibts klingt alles gut und vielversprechend.

Aber meine Kernfrage aus dem Thema hier beantwortet es für mich noch nicht: Macht es Sinn "after(systemstart(),xx)" zu nutzen, wenn man nicht sagen kann, wann dieser Befehl ausgeführt wird?
Ich sage nein, da es mal im allerersten Zyklus passiert und mal in der normalen Programmroutine und man vorher nicht weiß was von beiden zutrifft.

Oder anders gesagt, entweder müsste "after(systemstart(),xx)" verboten sein, oder sicher im allerersten Zyklus ausgeführt werden.

==========================
Nachtrag:
Oder die drei Fragen von oben beantwoten:

1. Warum feuern die after(systemstart())-Timer in zwei Schüben? (Test 1)
2. Warum verhalten sich die after(systemstart())-Timer so, als lägen zwischen systemstart() und ready() etwa 107 s, obwohl es laut Uhr nur 48 bis 50 s sind? (Test 2)
3. Ist es so vorgesehen, dass eingehende Telegramme erst ab ready() verarbeitet und dann nachgeholt werden? (Test 4)
   Wodurch ist das Nachholen so langsam (1 bis 5 s pro Telegramm)?

[enertegus]

Die neue FW cached die KOs, d..h. nach dem 2. Update (1. Einspielen -> Cache wird angelegt, ab dann also 2. Einspielen von Software) wird es dann deutlich schneller mit den Start, falls vielleicht die Ausgangssituation gewesen sein mag.

[foobar0815]

Macht es Sinn "after(systemstart(),xx)" zu nutzen [...]?

Aus meiner Sicht im Allgemeinen nicht mehr. Das Problem, dass systemstart() unterschiedlich lange dauert, je nach Objektanzahl, soll durch die Funktion ready() eliminiert werden.

Das gilt aber nicht für alle Situationen. Werte vom Flash sollten zB schon weiterhin im systemstart() geladen werden. Das Schreiben von Variablen hingegen sollte eher nach ready() verlagert werden, oder andere Bedingungen nutzen als

if change(X) then writeflashvar(X) endif.

Zu den anderen Fragen (die durch die obige Antwort unter "nicht empfehlendswertes Vorgehen" fallen):

Warum feuern die after(systemstart())-Timer in zwei Schüben? (Test 1)

Weil die entweder in den Zyklus 1 fallen oder in die normale Verarbeitung danach, je nach Dauer der Initialisierung. Das Verhalten ist undefiniert und basiert auf Ausprobieren, was im Einzelfall funktioniert. Würde ich also nicht empfehlen.

Warum verhalten sich die after(systemstart())-Timer so, als lägen zwischen systemstart() und ready() etwa 107 s, obwohl es laut Uhr nur 48 bis 50 s sind? (Test 2)

Kann ich nich ohne genaue Analyse sagen. Sehe darin aber keinen allgemeinen Nutzen.

Ist es so vorgesehen, dass eingehende Telegramme erst ab ready() verarbeitet und dann nachgeholt werden? (Test 4)
Wodurch ist das Nachholen so langsam (1 bis 5 s pro Telegramm)?

Ja. Irgendwie müssen wir ja zu einem definierten Startzustand kommen. Und der kommt nur durch interne Initialisierung + Leseanforderungen zustande.

Was hast du als Telegrammrate in den Projekteinstellungen stehen?

[EPIX]

Wer schonmal rumspielen will, hier die Links. Ist noch Beta und ohne Gewähr, die Liste der Änderungen ist aber lang. Einen eigenen Thread dazu mit etwas mehr Infos schreiben wir noch, ich wollte jetzt aber nicht weiter vertrösten.

würde mich natürlich "juckern", aber nachdem ich nur 1 eibPC habe, traue ich mich nicht....
Da wäre ein "virtueller eibPC" natürlich praktisch

[foobar0815]

Generell: wir sind offen für Ideen und setzen auch viele davon um. Genauso finden wir es super, wenn ihr euch intensiv mit dem Verhalten beschäftigt, gerade weil ja immer mal wieder Bugs auftauchen.

Auf ein abstraktes Wünsch dir was, à la "

Sektion [Systemstart]

darf es aber nicht rauslaufen.
Konkret heißt das: gebt uns bitte den Kontext. Meist gibt es eine passende, wartungsfreie und wohl definierte Lösung, bei der man gar nicht darauf angewiesen ist, genau zu wissen was in wlechem Zyklus läuft.

Wie enertegus im anderen Thread geschrieben hat, gibt es nun einen Object-Trace und die Option, mit dem Programmstart auf die Trace-Verbindung zu warten. Damit kann man genau schauen, was wann passiert. Übrigens auch live in der Logik und im Experten.

[foobar0815]

würde mich natürlich "juckern", aber nachdem ich nur 1 eibPC habe, traue ich mich nicht....

Wir haben genug auf Lager

[foobar0815]

Auch wenn es hier aktuell etwas durcheinander ist, noch eine Ergänzung zu den Leseanforderungen:

Die GAs in der [InitGA]-Sektion und initga() in der [EibPC]-Sektion ergänzen sich. Die GA-Liste unter Objekte wird auch in [InitGA] übersetzt. Und man kann bei GAs in der Logik auch noch einen Haken für die Initialisierung setzen. Es bleibt also jedem selbst überlassen, was er angenehmer findet.

Viele Init-Haken werden von der Visu auch automatisch für die Status-GAs gesetzt. Deswegen kann man im EibStudio 6 auch die Initialisierung einzelner GAs explizit verbieten.

[klaus_kraemer]

Generell: wir sind offen für Ideen und setzen auch viele davon um. Genauso finden wir es super, wenn ihr euch intensiv mit dem Verhalten beschäftigt, gerade weil ja immer mal wieder Bugs auftauchen.

Auf ein abstraktes Wünsch dir was, à la " darf es aber nicht rauslaufen.
Konkret heißt das: gebt uns bitte den Kontext. Meist gibt es eine passende, wartungsfreie und wohl definierte Lösung, bei der man gar nicht darauf angewiesen ist, genau zu wissen was in wlechem Zyklus läuft.

Wie enertegus im anderen Thread geschrieben hat, gibt es nun einen Object-Trace und die Option, mit dem Programmstart auf die Trace-Verbindung zu warten. Damit kann man genau schauen, was wann passiert. Übrigens auch live in der Logik und im Experten.

Lieber foobar0815,

schön, dass Ihr Euch endlich wieder mal im Forum meldet!

Ideen wie eine Sektion "Systemstart" rühren ja nur daher, dass es, wie in diesem Thread gut nachzuvollziehen, Bereiche des EibPC gibt, zu denen dem User oft ausreichende Informationen fehlen. Da entwickelt man eigene Vorstellungen und Ideen. Ob die immer passen sei dahingestellt. Insbesondere beim Coden schwimmt da dann auch ein wenig das Prinzip Hoffnung mit.

Im Handbuch wäre es halt zielführend, darauf hinzuweisen, dass es zwischen systemstart() und ready() noch einen anscheined etwas diffusen Zwischenzustand - wohl die Initialisierung - gibt.

Da wäre halt auch interessant,was man da reinbringen sollte. Du schreibst ja z.B. von Flashvariablen. Macht es daher Sinn, diesen Zwischenzustand auch abzufragen (!systemstart() && !ready())?

Herzlichen Gruß
Klaus

[EPIX]

so etwa?

// Laden des Variablen , bei Startup
if after(systemstart(),100u64) then readflashvar(EGSZ_Jal_Freigabe) endif

// Speichern der Variablen bei SHUTDOWN und 1xtäglich
if SHUTDOWN or htime(0,20,10) then writeflashvar(EGSZ_Jal_Freigabe); endif

//Speichern der Variablen , wenn sich die Variable ändert
    if ready() and change(BetriebsModus)    then writeflashvar(BetriebsModus) endif  ​
​

und beim Wünschen würde mir

if case....

einfallen...

[enertegus]

und beim Wünschen würde mir

if case....

einfallen...

[foobar0815]

endlich wieder

Letzte Nachricht von mit war am 17.10. In der Zwischenzeit gab es im Forum zwei Threads (die drei neuen gestern nicht mitgezählt).

Es gibt keinen Zwischenzustand.

systemstart() ist unmittelbar im ersten Zyklus auf 1 und bleibt da bis zum Abschluss der Initialisierung und ready() == 1 ist.

[QUOTE=EPIX;n2113016]so etwa? Fast.
Das after() soltlest du normalerweilse nicht brauchen:

if systemstart() then readflashvar(EGSZ_Jal_Freigabe) endif

[klaus_kraemer]

und beim Wünschen würde mir Code:

if case....

einfallen...

Oh jaaaaaaa - und wie das fehlt! Auch wenn ich es lieber

switch variable_or_GA {
case 1: {result = 1}
case 2: {result = 2}
.
.
.
case 15: {result = 15}
}

aufbauen würde.
Auch wenn enertegus da leider sagt.

Es wäre schon eine große Erleichterung des Programmierens, wie auch der Lesbarkeit des Programmcodes, switch ... case zur Auswertung verschiedener Werte einer Eingangsvariablen / GA verwenden zu können, anstatt eine Orgie von if .. endif. schreiben (und später auch lesen) zu müssen. Ich geb's zu, in C# liebe ich switch - case.

Den Umbau des switch in die if ... endif Orgie müsste doch auch noch beim Parsen möglich sein können?

EPIX. Dieselbe Idee hatten wir doch schon mal 2016 im Betaforum bei " Neue Funktionen in der 3.1xx"

[foobar0815]

Das Problem dabei ist nicht die Anweisung selbst, sondern wie aktuell das else abgebildet wird - im Grunde durch ein separates if mit invertierter Bedingung.
Spätestens bei switch/case erwartet aber niemand, dass mehrere cases ausgeführt werden , wenn die Bedingung in einem Case geändert wird.

Na gut, ehrlicherweise erwartet man es bei if/else auch nicht, aber da ist es eben dokumentiertes Verhalten und damit "gewollt".

Die Durchfall-Semantik ohne break wäre wohl leicht, ohne Änderungen am Objektmodell, abbildbar.