In der Tiefe: Validierungskonzept

[pio]

d=a+b+c+1u08

if (d>=0) then write('2/3/4'u08, d)[/highlight]
richtig
Nein, die werden sofort im Zyklus sich ändern, nur change() reagiert darauf erst im folgenden.
gar nix, weil ja d=>0 schon zum Systemstart gültig ist.
Es hat absolut nichts mit Geheimniskrämerei zu tun. Ich bin drüber, da wa zu malen.

Um das noch weiter zu erklären:
nach dem Neustart ist d=0, d.h. die Bedingung d>=0 ist erfüllt.
Nach meinem Verständniss wird dann auch beim Neustart, d.h. beim allerersten Zyklus NICHTS gesendet, da die Bedingung zwar erfüllt ist, aber sich "nichts geändert" hat.
Das gilt dann für den zweiten Verarbeitungszyklus und alle weiteren: obwohl auf der GA ein neuer Wert (=1) ankommt, ist die Bedingung >= 0 immer noch erfüllt, hat sich also gegenüber dem vorigen Zyklus nicht verändert, ergo wird der Then-Zweig auch nicht ausgeführt.

Mein Vorschlag an Enertex zur Doku:
Macht eine Tabelle, mit einer Zeile pro Verarbeitungszyklus, und listet in jeder Spalte die Zustände der einzelnen "Elemente" auf.
Beispiel siehe Bild.

[saft6luck]

Ehrlich gesagt frage ich mich schon, wieso die Programmierung des eibPCs eine solch Komplexe Angelegenheit sein muss. Mir wäre mehr daran gelegen, dass die Anleitung (und damit die Interpretation der Programmierung) so einfach wie möglich wird. Daraus folgt, dass die Programmierung robust wird.

Und robust ist für mich eine Sprache, wenn sie eindeutig und deterministisch ist und das nicht erst nach mehreren Iterationen. Ich bin zwar ein Schachspieler, will aber trotzdem nicht jede Zeile Code "5 Ausführungszyklen weit" voraus betrachten müssen, schon gar nicht, um triviale Prüfungen zu implementieren.

Leider erfüllt der eibPC mit seiner Programmiersprache meine Anforderungen nicht. Robustheit und Determinismus sind für mich wesentliche Aspekte der Automatisierung und da hatte ich evtl. zu viel erwartet.

[enertegus]

Zum Thema: Objektabhängigkeit und Validierung ein paar Bilder. Ich werde dies ins Handbuch einarbeiten.
Dazu noch zum Thema if:
Die if-Anweisung invaldiert alles im then-Zweig. Daher wird dort alles abhängig von der if-Anweisung ausgeführt. Wenn nun hier auch eine if-Anweisung steht, gilt für diese die Valdierung nicht vom Argument sondern direkt von der übergeordneten Anweisung.
Nochmal zu Valdierung:

• Eine Variablenausdruck ist invalid bedeutet: Berechne ihn und neu und invaldiere von ihm abhängige Variablen.
• Eine Funktion ist invalid bedeutet: Führe die Funktion aus
• Funktionen, die etwas auf den Bus schreiben, tun dies
• Eine if-Anweisung ist invalid: Wenn die Bedingung wahr ist, dann führe den then Zweig aus.
• Ein nicht von einer anderen if-Anweisung abhängige if-Anweisung (="Toplevel If") wird von ihrer Abfragebedingung abhängig invaldiert.
• Ein von einer anderen if-Anweisung abhängige if-Anweisung (="verschachteltes If") wird NICHT von ihrer Abfragebedingung abhängig invaldiert

Ich mach da noch ein paar Bilder, aber wahrscheinlich nicht vor Mitte nächster Woche.
Vielleicht klärt sich das noch auf. Der pio hat es schön mit seiner Tabelle gezeigt und exakt richtig formuliert.

[enertegus]

Ich hab mal das Pdf aus dem internen Stand des Handbuch hochgeladen.
Sind sicher noch jede Menge Tippfehler drinne.

[Tessi]

Schau doch noch mal in Ruhe das PDF dieses Threads durch. Da ist das genau mit Beispielen erläutertet.

Habe ich jetzt mal endlich geschafft!
Schade, das es nach der 5. Seite zu Ende ist. Ich hätte doch gerne gewusst, was der Parser aus dem Makro am Ende macht.

Ich lese auf Seite 118: Ausgabefunktionen werden nie von ihren Argumenten invalidiert.
Demnach funktionieren sie nur als Teil eines Ausdrucks, der von außen invalidiert wird, also in then- oder else-Zweigen. Welche Katastrophe würde denn eintreten, wenn auch hier das VK gelten würde?

[highlight=epc][EibPC]
write("Temperatur-1/2/1",22.3)
write("Schalter-1/2/10",!"Schalter-1/2/10")
write("Temperatur-1/2/1",Temp)



write("Schalter-1/2/10",Status)[/highlight]Zeile:

1. -
2. Kein Problem, die Konstante invalidiert ja sowiso nie.
3. Hm, könnte ein ernstes Problem werden, aber so etwas sollte man an dieser Stelle dann auch nicht schreiben, bzw. der Parser könnte es ablehnen (wie er es an selbiger Stelle ja auch mit a=a+1u08 tun würde)
4. Jede Änderung von Temp - egal wo im Code erfolgt - wird auch geschrieben, und hier maximal nur einmal pro Zklus. Problem?
5. Wie zuvor

Mir ist jetzt nicht klar, warum das wirklich ein Problem werden kann. OK, der Toggle-Befehl in Zeile 2 würde sich immer wieder selbst triggern, aber wenn ich das statt dessen so schreiben würde:

[highlight=epc][EibPC]
if ("Schalter-1/2/10") then {
write("Schalter-1/2/10",!"Schalter-1/2/10")
} else {
write("Schalter-1/2/10",!"Schalter-1/2/10")
} endif[/highlight]hätte ich das gleiche Problem. Nicht ohne Grund mag der Parser so etwas ja nicht:
[highlight=epc][EibPC]
a=a+1u08[/highlight]Statt dessen muß ich derzeit Zeile 3 und 4 (erstes Beispiel), damit eine Änderung auch auf den Bus kommt, so schreiben:
[highlight=epc][EibPC]
if change(Temp) write("Temperatur-1/2/1",Temp)
if change(Status) write("Schalter-1/2/10",Status)[/highlight]Hier muß ich also explizit das schreiben, was das VK sonst implizit macht.

OK, ich kann damit leben, aber dennoch interessiert mich der Grund für diese Art "Sonderbehandlung".

Nächster Punkt:

Ein Telegramm wird aus einem Zyklus heraus so oft in den Sendepuffer gestellt, wie in diesem Zyklus write-Befehle auf die GA invalidiert wurden. Klingt zunächst vernünftig, auch wenn das ggf. den Bus überlastet (ist aber dann ein Fehler des Programmierers). Gesendet wird dabei aber jedesmal der Wert den der zuletzt bearbeitete write-Befehl auf diese GA hatte. Das macht für mich keinen Sinn! Entweder sende ich auch die Folge von Werten, die die verschiedenen write-Befehle hatten (weil die Sequenz für den Empfänger wichtig sein könnte), oder es geht tatsächlich nur um die letzte Änderung, aber dann sollte auch nur einmal pro Zyklus und GA ein Telegramm im Puffer landen.
Welchen Sinn hat das derzeitige Verhalten?

[enertegus]

Habe ich jetzt mal endlich geschafft!
Schade, das es nach der 5. Seite zu Ende ist. Ich hätte doch gerne gewusst, was der Parser aus dem Makro am Ende macht.

Ups, das habe ich versehentlich gemacht. => neu hochgeladen.

Ich lese auf Seite 118: Ausgabefunktionen werden nie von ihren Argumenten invalidiert.
Demnach funktionieren sie nur als Teil eines Ausdrucks, der von außen invalidiert wird, also in then- oder else-Zweigen.

Ja, das ist richtig.

Mir ist jetzt nicht klar, warum das wirklich ein Problem werden kann. OK, der Toggle-Befehl in Zeile 2 würde sich immer wieder selbst triggern, aber wenn ich das statt dessen so schreiben würde:

Das ist der Hintergrund für diesen Verhalten.

hätte ich das gleiche Problem.

richtig, aber das setzt schon einiges voraus an gezieltem Handeln. Einfach nur ein write und dieses Verhalten, da erschien uns die Lernkurve zu krumm...

Nicht ohne Grund mag der Parser so etwas ja nicht:

Eben!

Das macht für mich keinen Sinn! Entweder sende ich auch die Folge von Werten, die die verschiedenen write-Befehle hatten (weil die Sequenz für den Empfänger wichtig sein könnte), oder es geht tatsächlich nur um die letzte Änderung, aber dann sollte auch nur einmal pro Zyklus und GA ein Telegramm im Puffer landen.
Welchen Sinn hat das derzeitige Verhalten?

Das Argument ist gut. Hintergrund ist wohl (ich bin nicht der FW-Spezi) die Sache mit den unterschiedlichen Argumenten (Sequenz). Dass es bei Variablen so funktioniert ist wohl ein "Seiteneffekt", über den man nachdenken könnte.

[Tessi]

Gut, bleibt für mich nur die Frage:
[highlight=epc][EibPC]
write("Schalter-1/2/10",!"Schalter-1/2/10")
write("Schalter-1/2/10",blub)
a=a+1u08
a=b+1u08[/highlight]Zeile 2 und 3 sind erlaubt, aber führen zu nichts da die Argumente die Funktionen nicht triggern können.
Zeile 4 würde sich gemäß VK selbst triggern und wird daher vom Parser an dieser Stelle nicht zugelassen.
Zeile 5 würde gemäß VK getriggert werden und ist OK.

Warum wird Zeile 2 nicht wie Zeile 4 und Zeile 3 wie Zeile 5 behandelt?
Zeile 2 ist ein Risiko, aber Zeile 4 genauso.
Wenn der Parser den Zirkelbezug in Zeile 4 erkennen und ablehnen kann, hätte man das doch genauso für Zeile 2 implementieren können. Ich fände es logischer, wenn Zeile 3 sich bei Änderungen der Argumente genau so erneut auswerten würde, wie dies Zeile 5 tut.

Warum also diese unterschiedliche Behandlung?

[Tessi]

So, jetzt habe ich auch noch die vollständige Fassung lesen können.
Die Sache mit dem Makro bekräftigt noch mal meine schon vorher aufgekommene Frage:
Warum unterliegen Ausgabefunktionen nicht dem VK, so wie alle anderen auch? Rekursionen können auch anders entstehen und müssen sowiso irgendwie abgefangen werden, das zeigt ein dem Makro folgendes Beispiel. Dafür würde mit VK das Makro eher das machen, was ohne die Warnung sonst wohl die meisten von uns erwartet hätten: Es hätte zumindest bei Änderungen gesendet, auch wenn die Anweisungen dazu nicht im return-Zweig sondern im "globalen" Rumpf stehen.

OK, es ist jetzt, wie es ist, und wenn man das jetzt verstanden hat, kommt man auch so ans Ziel, aber ich sehe jetzt immer noch keinen Vorteil darin, die Ausgabefunktionen aus dem VK herauszunehmen.

Aber habe ich das den Beispielen jetzt richtig entnommen:
1. Nur das, was im return-Zweig eines Makros steht, wird an den Stellen eingefügt, an der es aufgerufen wird? Der Rest steht funktional gesehen einmalig im globalen Code? Oder so oft, wie das Makro aufgerufen wird?
2. Wenn ich ein Makro unbedingt aufrufe, steht dann der Code im Returnzweig genauso im globalen Kontext wie der restliche Makrocode und es greift auch hier das VK?
3. Was bildet den Rückgabewert des Makroaufrufes, wenn im Returnzweig so viel Code stehen darf? Generell das letzte Statement? Was wäre dann, wenn dieses keinen Wert liefert? Oder das letzte Statement das einen Wert liefert? Was, wenn mehrere Statements einen Wert liefern? Werden dann alle Werte bis auf den letzten verworfen? Oder ist das nicht zulässig? Was ist, wenn kein Statement einen Wert liefert? Was ist, wenn an der Stelle des Aufrufes ein Wert erwartet wird? Fängt so etwas schon der Parser ab?

Rekursion:
Wie wird sie erkannt? Wann wird das Event PROC_REPITIONS generiert? Was passiert danach?

[saft6luck]

Mal wieder eine Frage an Michael (und alle anderen, die das Validierungsschema verstanden haben ) zum Validierungsschema und Systemstart:
Sonnenaufgang z.B. 06:57.
Warum kommt hier für Rollo_Sonnenaufgang_h und Rollo_Sonnenaufgang_m 7:50 heraus und nicht 7:00? Nach der ersten Änderung geht es dann aber ...

Sollte Copy&Paste prüfbar sein (Code ist zu Debugzwecken schon sehr umgebaut):
[highlight=epc]
// Rollo - Sonnenaufgang
Rollo_Sonnenaufgang_vorziehen = 7s08
Rollo_Sonnenaufgang_min_h = 07u08
Rollo_Sonnenaufgang_min_m = 00u08
Rollo_Sonnenaufgang_m = 60u08

Rollo_Sonnenaufgang_h = sunrisehour()
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_vorziehen; /* -> Minuten: -15 <= m <= 44 */

if change( Rollo_Sonnenaufgang_m_s ) or systemstart() then {
if ( Rollo_Sonnenaufgang_m_s < 0s08 ) then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08
} endif;
Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 );
if ( ( Rollo_Sonnenaufgang_h == Rollo_Sonnenaufgang_min_h ) and ( Rollo_Sonnenaufgang_m < Rollo_Sonnenaufgang_min_m ) ) then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m
} endif;
if ( Rollo_Sonnenaufgang_h < Rollo_Sonnenaufgang_min_h ) then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m;
Rollo_Sonnenaufgang_h = Rollo_Sonnenaufgang_min_h
} endif;
} endif
[/highlight]

[enertegus]

Mal wieder eine Frage an Michael
Warum kommt hier für Rollo_Sonnenaufgang_h und Rollo_Sonnenaufgang_m 7:50 heraus und nicht 7:00? Nach der ersten Änderung geht es dann aber ...

Das Problem im Code ist ein (sicher unschönes) Verhalten der Verschachtelten if-Abfrage beim Initialisieren (siehe die vorigen mails): Einfach gesprochen: Jede if-Abfrage wird beim Initalisierungsvorgang auf einmal ausgewertet, egal ob verschachtelt oder nicht. Wir haben das auf dem Radar fürs nächste Relase.

[saft6luck]

Das Problem im Code ist ein (sicher unschönes) Verhalten der Verschachtelten if-Abfrage beim Initialisieren (siehe die vorigen mails): Einfach gesprochen: Jede if-Abfrage wird beim Initalisierungsvorgang auf einmal ausgewertet, egal ob verschachtelt oder nicht. Wir haben das auf dem Radar fürs nächste Relase.

Hm, was: "wird ... auf einmal ausgewertet" bedeutet verstehe ich nicht. Meinst du 'in einem Stück' oder 'plötzlich'?

Egal, gibt es einen Fix? change( sunriseminute() ) löst es jedenfalls nicht, auch wenn du das im angegebenen Posting geschrieben hast.

[enertegus]

Hm, was: "wird ... auf einmal ausgewertet" bedeutet verstehe ich nicht. Meinst du 'in einem Stück' oder 'plötzlich'?

Sorry, da war ich in Eile... streich das einfach.
Wird beim Intialsieren ausgwertet (unabhängig von der übergeordneten if-Anweisung).
Workaround ist nur die Verschachtelung vermeiden, wenn sie sich so wie bei Dir auswirkt.

[saft6luck]

Sorry, da war ich in Eile... streich das einfach.
Wird beim Intialsieren ausgwertet (unabhängig von der übergeordneten if-Anweisung).
Workaround ist nur die Verschachtelung vermeiden, wenn sie sich so wie bei Dir auswirkt.

Ehrlich gesagt habe ich das schon probiert, nur wird der Code (der Ausschnitt ist ja nur ein kleiner Teil) dann schon ziemlich gestelzt.
Es ist auch etwas sonderbar, dass aus dem Code:

if ( Rollo_Sonnenaufgang_h < Rollo_Sonnenaufgang_min_h ) then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m;
Rollo_Sonnenaufgang_h = Rollo_Sonnenaufgang_min_h
} endif;


scheinbar nur der rote Teil nicht ausgeführt wird ... liegt evtl. an der vorausgehenden Zuweisung?

EDIT: Heute sind die Minuten auch falsch (1. eigenständige Änderung seit gestern): 7:48 -> da ist der Wurm drin! Mit dem Debugger kann ich eine Änderung anstoßen und dann klappt es.

[saft6luck]

Ist schon absehbar, wann es für obiges Problem einen Patch gibt? (nicht das Initialisierungsproblem!)

[enertegus]

Ist schon absehbar, wann es für obiges Problem einen Patch gibt? (nicht das Initialisierungsproblem!)

Ich habs mal eingespeist. Das wird aber noch dauern...

Was spricht gegen das: (oder hast Du hier auch ein Problem festgestellt?
[highlight=epc]
// Rollo - Sonnenaufgang
Rollo_Sonnenaufgang_vorziehen = 7s08
Rollo_Sonnenaufgang_min_h = 07u08
Rollo_Sonnenaufgang_min_m = 00u08
Rollo_Sonnenaufgang_m = 60u08

Rollo_Sonnenaufgang_h = sunrisehour()
Rollo_Sonnenaufgang_m_s = convert( sunriseminute(), 0s08) - Rollo_Sonnenaufgang_vorziehen; /* -> Minuten: -15 <= m <= 44 */

Sonne=change( Rollo_Sonnenaufgang_m_s ) or systemstart()


if ( Rollo_Sonnenaufgang_m_s < 0s08 ) and Sonne then {
Rollo_Sonnenaufgang_m_s = Rollo_Sonnenaufgang_m_s + 60s08;
Rollo_Sonnenaufgang_h = sunrisehour() - 1u08
} endif
if Sonne then Rollo_Sonnenaufgang_m = convert( Rollo_Sonnenaufgang_m_s, 0u08 ) endif

if ( ( Rollo_Sonnenaufgang_h == Rollo_Sonnenaufgang_min_h ) and ( Rollo_Sonnenaufgang_m < Rollo_Sonnenaufgang_min_m ) ) and Sonne then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m
} endif

if ( Rollo_Sonnenaufgang_h < Rollo_Sonnenaufgang_min_h ) and Sonne then {
Rollo_Sonnenaufgang_m = Rollo_Sonnenaufgang_min_m;
Rollo_Sonnenaufgang_h = Rollo_Sonnenaufgang_min_h
} endif
[/highlight]