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.