In der Tiefe: Validierungskonzept

[Uwe!]

Wie sieht denn das der Rest hier so?

siehe eins oben drüber

[MarkusL]

Bitte implementieren. (am Besten Uwe's Vorschlag)

[SnowMaKeR]

Bin ich heut schwer von Begriff?
Ich versteh Uwes Vorschlag nicht.
Wie soll das dann funktionieren?

[Uwe!]

Wie soll das dann funktionieren?

Na statt irgendwo zu definieren "Systemstart ist nach 20 Sek. zu ende" eben eine Funktion die das Ende "auslöst". Also

EndSystemstart(after(systemstart();1200000)))

oder eben

EndSystemstart(GA hat bestimmten Wert) etc.

[SnowMaKeR]

Und was wird dann verarbeitet während EndSystemstart() aktiv ist?

[anlo007]

nur wenn ich die Bedingung "endsystemstart" in jede Abfrage einfügen muß hab ich ja keine Änderung zum jetzigen Zustand. Auch heute kann ich doch definieren:

endsystemstart=after (systemstart(), 10000)

und endsystemstart in jede Abfrage einbauen.

Ich meine, das das Logikprogramm erst x sec nach den systemstart() -Abfragen überhaupt gestartet wird.

Wo man die Zeit einstellt, in einer Programmzeile oder in den Voreinstellungen, genau wie die maximale Telegrammrate, ist eigendlich egal.

[Uwe!]

Und was wird dann verarbeitet während EndSystemstart() aktiv ist?

Nein, da hab ich meine Idee noch immer nicht richtig rüber gebracht...

Michael schrieb

Wie wärs denn mit einer paramertierbaren Zeit bis zum Erstabarbeiten nach dem Systemstart()-Aufruf?

Also ich parametriere (wo und wie auch immer) 20 Sek. und dann legt die Kiste erst 20 Sek. nach Systemstart() mit dem allem los, was nicht ausdrücklich als

if systemstart() then ....

definiert ist.

So hab ich jedenfalls Matthias verstanden.

Meine Idee war es nun eben nicht irgend wo nur eine Zahl (die 20 Sek.) hinterlegen zu können, sondern während der Systemstarttätigkeiten selbst mit Logik den Schalter umlegen zu können. Das kann dann der eine trotzdem einfach mit einer festen Zeit machen, der andere übrprüft, ob bestimmte Antworten eingetroffen sind und der dritte lässt sich ganz was anderes einfallen (vielleicht einen Taster, den er manuell bedient)

[saft6luck]

Wie sieht denn das der Rest hier so?

Flexibel finde ich die Lösung:
[highlight=epc]
[Systemstart]

//tu was

if 'alles da' then
{
systemstart() = EIN;
}

[eibPC]

// systemstart() geht immer noch wie gewohnt
if systemstart() then
{
...
}

// jetzt geht's los
...
[/highlight]

Der Charm dieser Lösung ist:

• jeder kann für sich entscheiden, wann der Systemstart-Bereich verlassen wird, indem der systemstart() auf EIN setzt, also auch über after() einfach nur zeitlich gesteuert
• Wenn der Programmierer den Systemstart-Bereich nicht verwendet, setzt das System wie gewohnt systemstart() auf EIN.
• die Lösung ist voll kompatibel mit der 'alten' Logik, da man im eigentlichen Programm wie gewohnt auf systemstart() abfragen kann.

Ist das denn wirklich zu kompliziert?
Mit einem EibStudio, das die Bereiche in eigenen Tabs darstellt, könnte man dann wirklich schön arbeiten.

[saft6luck]

Meine Idee war es nun eben nicht irgend wo nur eine Zahl (die 20 Sek.) hinterlegen zu können, sondern während der Systemstarttätigkeiten selbst mit Logik den Schalter umlegen zu können. Das kann dann der eine trotzdem einfach mit einer festen Zeit machen, der andere übrprüft, ob bestimmte Antworten eingetroffen sind und der dritte lässt sich ganz was anderes einfallen (vielleicht einen Taster, den er manuell bedient)

So würde ich mir das auch vorstellen.

[Uwe!]

Flexibel finde ich die Lösung:

hey, da sind wir ja mal einer Meinung. Gleiche Idee nur etwas anders realisiert
Dein "systemstart()=EIN" entspricht meinem "endsystemstart()=EIN"
Das ist dann mehr Geschmackssache...

Nachtrag: hat sich mit Deinem letzten Beitrag überschnitten

[SnowMaKeR]

Jetzt hab ich es auch verstanden.
Bis SYSTEMSTARTEND=EIN verarbeite alles wo systemstart() drin vorkommt.
Danke für die Sondererklärung

Mir gefällt diese Lösung aber nicht so recht.
Zu unübersichtlich. Da muss man zu viel überlegen.
Denk doch mal an die armen Elektriker.

Marc´s Lösung find ich Spitze.
Klar strukturiert, einfach zu verstehen. Passt.
Auch wenn ich schon die ersten schreie höre: Mein EIBPC verarbeitet mein Programm nicht, weil in der Sektion [SYSTEMSTART] vergessen wurde systemstart=EIN zu setzen

Eine neue Funktion braucht es dann wegen dem Validierungsschema trotzdem, oder?
Ein READ braucht ja immer einen Auslöser.
Oder wird das genau einmal ausgeführt?
[HIGHLIGHT=EPC]
read (GA)
[/HIGHLIGHT]

Wenn nicht:
Nachdem systemstart() unverändert bleibt, benötigen wir noch sowas wie startup()

Dann würde es so aussehen
[HIGHLIGHT=EPC]
[SYSTEMSTART]
if startup() then read(); .... endif

if a=b then systemstart=EIN endif

[EIBPC]
if systemstart() then .... endif
[/HIGHLIGHT]

Gefällt mir...

[saft6luck]

Eine neue Funktion braucht es dann wegen dem Validierungsschema trotzdem, oder?
Ein READ braucht ja immer einen Auslöser.
Oder wird das genau einmal ausgeführt?
[HIGHLIGHT=EPC]
read (GA)
[/HIGHLIGHT]

Wenn nicht:
Nachdem systemstart() unverändert bleibt, benötigen wir noch sowas wie startup()

Dann würde es so aussehen
[HIGHLIGHT=EPC]
[SYSTEMSTART]
if startup() then read(); .... endif

if a=b then systemstart=EIN endif

[EIBPC]
if systemstart() then .... endif
[/HIGHLIGHT]

Ja, genau! Ich dachte ja zuerst noch an:
[HIGHLIGHT=EPC][SYSTEMSTART]
if !systemstart() then
{..}
[/HIGHLIGHT]
oder
[HIGHLIGHT=EPC][SYSTEMSTART]
if after( X, 1u64 ) then
{..}
[/HIGHLIGHT]
aber dein Vorschlag ist deutlich verständlicher.

Schade eigentlich, das ausgerechnet systemstart() schon belegt ist, sonst hätte ich es im systemstart-Bereich verwendet.

Wie wäre es dann, den Bereich Startup-Bereich zu nennen?

[HIGHLIGHT=EPC]
[STARTUP]
if startup() then read(); .... endif

if a==b then systemstart=EIN endif

[EIBPC]
if systemstart() then .... endif
[/HIGHLIGHT]

[enertegus]

Flexibel finde ich die Lösung:

Was mir nicht gefällt, ist der eigene Bereich. Das gibt wieder Fragen...

Ich fände besser, alles per Funktion gemacht wird:

[highlight=epc]
// Nur was in dieser if-Anfrage steht, wird gemacht
if startup() then {
FixSystemStart();
tuwas()
} endif
// Und nun gehts erst los...
if after(startup() ) then ReleaseSystemstart () endif
[/highlight]

[saft6luck]

Was mir nicht gefällt, ist der eigene Bereich. Das gibt wieder Fragen...

Ich kann das schwer beurteilen! Wenn du sagst: "Das gibt wieder Fragen", sind dann wirklich die Nutzer das Problem oder geht es eigentlich um die Umsetzung, die zu aufwändig ist?

Ich fände besser, alles per Funktion gemacht wird:

[highlight=epc]
// Nur was in dieser if-Anfrage steht, wird gemacht
if startup() then {
FixSystemStart();
tuwas()
} endif
// Und nun gehts erst los...
if after(startup() ) then ReleaseSystemstart () endif
[/highlight]

Das bedeutet, dass durch FixSystemStart() alle Abfragen im Code ohne startup() als Bedingung ignoriert werden?

Also wird jetzt das Programm zyklisch abgearbeitet und nur die Bedingungen mit der zusätzlichen Abfrage startup() werden beachtet, oder? Ansonsten kann ich ja nicht auf das Eintreffen bestimmter Ereignisse warten, bevor ich den restlichen Code ausführen will.
Wenn es allerdings nur das eine if gibt, ist es problematisch. Leider ist man dann bei der Programmierung nicht mehr frei, denn das Validierungsschema schränkt einen bei der Verschachtelten if-Anweisung sehr stark ein.

Im Beispiel wird dann nach einer gewissen Zeit das startup() durch ReleaseSystemstart() wieder AUS gesetzt und der eigentliche Code abgearbeitet.

Wenn ich das so richtig verstanden habe, verwirrt das ja nicht ganz unerheblich -> mir persönlich gefällt das nicht.

Evtl. meinst du aber, dass startup() einfach ein Flag ist, das über Befehle kontrolliert wird und man in allen Abfragen bzw. Zuweisungen, die verzögert werden sollten, einbauen muss, entweder startup() oder als !startup()?
Dann gibt es diese Lösung eigentlich schon -> Ist nicht mein Ding.

Oder ich liege einfach falsch und brauche mehr Input

[pio]

Stimmt schon, aber es wird kompliziert, wenn Antworten nicht kommen. Ewig warten geht nicht, unendlich oft nachfragen auch nicht. Wie bestimme ich also, wann ich den Systemstart als abgeschlossen betrachte und ab wann der Logikteil loslaufen soll? Was ist mit teilweisem Start?

Das ist ja mein Ansatz mit der Vorgabe von Zeitverzögerungen ab Systemstart in den Sektions-Headern:
[EibPC=50000u64]
xxx
yyy

Die regelmässige Abarbeitung startet erst 50 Sek nach Systemstart.

Damit, dass man nicht sicher sein kann, dass z.B. 10 read() - Befehle nach spätestens 2 Sekunden abgearbeitet sind, muss man leben. KNX ist nicht deterministisch und arbeitet erst recht nicht nach harten Echtzeit-Anforderungen.
Man kann aber überschlagen, wie lange man für 10 read()-Anforderungen ungefähr brauchen sollte, und wenn man dann nochmal 10 Sekunden Sicherheit aufschlägt, bringt einen das nicht um (mich zumindest nicht).