[Featurewunsch] Kommando zur Abfrage/Bewertung von Konditionen

[saft6luck]

Die Programmierung des eibPCs erscheint mit zunehmender Komplexität der Logiken immer unverständlicher.

Für mich liegt der Grund klar in der SPS-artigen, eventgetriebenen Abarbeitung des Codes. D.h. Abfragen werden nur dann erneut bewertet, wenn sich eine Eingangsgröße 'geändert' hat.

z.B.

01: //Steuerung Rollo Essen EG
02: Sommer = month(01,04) and !month(31,10) 
03: Hoch = ( ("Helligkeit.Süd-1/0/22">200.0) and Zeit) and Sommer ) \\
            or ( ("Helligkeit.Süd-1/0/22">20.0) and Zeit) and !Sommer )
04: Zeit = AUS
05: if wtime(08,30,00,WOCHENENDE) then Zeit=EIN endif
06: if wtime(05,30,00,WERKTAGS) then Zeit=EIN endif
07: Werktags = wtime(5,30,00,MONTAG) \\
             or wtime(5,30,00,DIENSTAG) \\
             or wtime(5,30,00,MITTWOCH)\\
             or wtime(5,30,00,DONNERSTAG) \\
             or wtime(5,30,00,FREITAG)\\
08: if Hoch and Sommer and Werktags then \\
09:    write("%Pos.anfahren Rollo Essen Ost OG-3/2/105",0%); \\
10:    write("%Pos.anfahren Rollo Essen Süd OG-3/2/115",0%); \\
11:    write("%Pos.anfahren Rollo Essen West OG-3/2/125",0%); \\
12:    Zeit=AUS \\
13: endif

Hier wird z.B. die Deklaration 'Zeit = AUS' aus Zeile 04 nur direkt nach Programmstart ausgeführt, da sich ja das 'AUS' nicht mehr ändert.

'Zeit' wird auf 'EIN' gesetzt, wenn es Werktags genau 5:30 bzw. am WE genau 8:30 ist, wobei 'Werktags' exakt zur gleichen Zeit (5:30) wochentags (für ca. 1ms) auf 1b01 geht. 'Sommer' ist 1b01 von April bis inkl. Oktober.

Nun kann man sich da durchbeissen, welcher Event bzw. welche Änderung wann kommen muss, damit da der Rolladen fährt.

Für mich würde hier ein eval() getauftes Kommando helfen, das die angegebene Bedingung immer prüft, also nicht nur, wenn sich ein Parameter ändert. Entsprechend soll die if-Anweisung dann immer ausgeführt werden, wenn 1b01 heraus kommt bzw. der else Zweig bei 0b01. Dies würde ich übrigens einem neuen if-Kommando vorziehen.

Hier das Beispiel mit eval(), wobei der Rolladen nur fährt, wenn um 5:30 werktags die Helligkeit im Sommer 200.0 bzw. im Winter 20.0 übersteigt.
('Zeit' wird übrigens nicht benötigt oder 'Werktags' ist falsch)

01: //Steuerung Rollo Essen EG
02: Zeit = AUS
03: Werktags = wtime(5,30,00,MONTAG) \\
             or wtime(5,30,00,DIENSTAG) \\
             or wtime(5,30,00,MITTWOCH)\\
             or wtime(5,30,00,DONNERSTAG) \\
             or wtime(5,30,00,FREITAG)\\
04: if wtime(08,30,00,WOCHENENDE) then Zeit=EIN endif
05: if wtime(05,30,00,WERKTAGS) then Zeit=EIN endif
06: if [B][COLOR=red]eval[/COLOR][COLOR=red]([/COLOR][/B] month(01,04) and !month(31,10) [B][COLOR=red])[/COLOR][/B] then
07:    // Sommer
08:    if ( "Helligkeit.Süd-1/0/22">200.0 ) and Zeit and Werktags then
09:       write("%Pos.anfahren Rollo Essen Ost OG-3/2/105",0%); \\
10:       write("%Pos.anfahren Rollo Essen Süd OG-3/2/115",0%); \\
11:       write("%Pos.anfahren Rollo Essen West OG-3/2/125",0%); \\
12:       Zeit=AUS \\
13:    endif
14: else
15:    // Winter
16:    if ( "Helligkeit.Süd-1/0/22">20.0 ) and Zeit and Werktags then
17:       write("%Pos.anfahren Rollo Essen Ost OG-3/2/105",0%); \\
18:       write("%Pos.anfahren Rollo Essen Süd OG-3/2/115",0%); \\
19:       write("%Pos.anfahren Rollo Essen West OG-3/2/125",0%); \\
20:       Zeit=AUS \\
21:    endif
22: endif

Es geht nicht um den Sinn des Beispieles (das ist geklaut, danke an redstar), sondern die Funktionsweise des eval(), das immer einen Event auslösen soll und den entsprechenden Wert des Ausdruckes für die if-Abfrage liefert.

Werbetrommel: Wer sich vorstellen kann, dieses Kommando (oder eine analoge Implementierung von Michael) einsetzen zu wollen/können, melde sich bitte hier im Thread, damit der tatsächliche Bedarf ersichtlich wird.

[IBFS]

Für mich liegt der Grund klar in der SPS-artigen, eventgetriebenen Abarbeitung des Codes. D.h. Abfragen werden nur dann erneut bewertet, wenn sich eine Eingangsgröße 'geändert' hat.

Erstmal zum allgemeinen Verständnis, damit hier keine
falschen Terminologien verwendet werden:

Ein SPS ließt alle Eingänge (bzw. das Eingangsabbild)
klappert durch den kompletten Code solange der nicht
durch Sprünge ausgeblendet wird und schreibt
anschließend alle Ausgänge (wenn nicht schon direkt
vorher mitten im Code). Ich habe mal alle Sonderformen
weggelassen.

Daher ist das Wort SPS-artig gerade eben leider falsch,
denn du wünscht dir ja eben KEINE "NurBeiÄnderung"-Ausführung
sondern exakt wie bei der SPS:

Bestimmte Codesequenzen sollen IMMER, unabhängig ob die
Eingangsvariable sich verändert hat, ausgeführt werden.

Ich muß zugeben (da jetzt auch die Begrifflichkeiten klar sind)
das man, wenn man sowohl SPS-Steuerungen programmiert
als auch C (und früher Delphi) es hier mit einer wirklich fehlenden
Funktion zu tun hat. Für einfache Konstrukte, die sehr nahe am
KNX-Prinzip sind, bräuchte man es nicht. Aber umso komplexer
die Bedingungen werden - erst recht mit Jahreszeiten - und
viel schlimmer noch - mit verzögert kommenden Rückmeldungen
von STATUS-GAs - kommt man da doch an Grenzen.

So ein "eval() getauftes Kommando" hat dann schon Sinn.

Gruß

Frank

[OColu]

Hallo,

mit genau den verzögert kommenden Rückmelungen der Status-GAs habe ich auch so meine Probleme.
Ich denke mit einer eval() Funktion könnte man ein paar dieser Probleme lösen.
Also dafür.

Gruß,

Olaf

[chg]

Die Programmierung des eibPCs erscheint mit zunehmender Komplexität der Logiken immer unverständlicher.

Ich muß zugeben (da jetzt auch die Begrifflichkeiten klar sind)
das man, wenn man sowohl SPS-Steuerungen programmiert
als auch C (und früher Delphi) es hier mit einer wirklich fehlenden
Funktion zu tun hat. Für einfache Konstrukte, die sehr nahe am
KNX-Prinzip sind, bräuchte man es nicht. Aber umso komplexer
die Bedingungen werden - erst recht mit Jahreszeiten - und
viel schlimmer noch - mit verzögert kommenden Rückmeldungen
von STATUS-GAs - kommt man da doch an Grenzen.

So ein "eval() getauftes Kommando" hat dann schon Sinn.

100% Ack!

Gerade komplexe Logiken könnte man im EibPC so schön umsetzten, wenn einem nicht immer das Validierungschema dazwischen funken würde.

[enertegus]

Was spricht gegen:

if  month(01,04) and !month(31,10) and ( "Helligkeit.Süd-1/0/22">200.0 ) and Zeit and Werktags then
....  
  else
 ... 
endif

[/QUOTE]
Da wäre der auszuführende Code recht schnell (ja nur bei Änderung) und m.E. auch genauso lesbar.

[anlo007]

Um eine regelmäßge Abarbeitung der Anweisung zu erreichen kannst du ein "If cycle(x) and " davorsetzen, dann wird alle x Minuten die Anweisung abgearbeitet.

[enertegus]

Erstmal zum allgemeinen Verständnis, damit hier keine
falschen Terminologien verwendet werden:

Wenn man es dann ganz genau nimmt, kann man das ganze auch mit der Theorie der Zustandsautomaten vergleichen. Eine Ähnlichkeit auf abstrakter Ebene zum VHDL Entwurf ist bei komplexeren Aufgaben nicht zu übersehen. Wenn ich hier mal im Urlaub noch etwas Zeit habe, schreib ich dazu mal was für die entsprechende Rubrik im Forum.

Michael

[saft6luck]

Was spricht gegen:

if  month(01,04) and !month(31,10) and ( "Helligkeit.Süd-1/0/22">200.0 ) and Zeit and Werktags then
....  
  else
 ... 
endif

Da wäre der auszuführende Code recht schnell (ja nur bei Änderung) und m.E. auch genauso lesbar.

Sorry wenn ich da schmunzeln muss, aber was macht denn das 'else'? Da wird sich die Hausfrauenlogik freuen

Und wenn ich dann auch noch zurück fragen darf: Was spricht denn nun eigentlich gegen das eval()? Die Rechenzeit für einen "Test" kann es ja nun wirklich nicht sein. Das bekommt der eibPC ja wohl auch "intern" bei allen anderen Vergleichen der Eingänge hin oder willst du damit tatsächlich argumentieren?

[saft6luck]

Um eine regelmäßge Abarbeitung der Anweisung zu erreichen kannst du ein "If cycle(x) and " davorsetzen, dann wird alle x Minuten die Anweisung abgearbeitet.

Genau, oder ich kann alle möglichen anderen Balkone anbauen, wie momentan üblich. Etwas anderes ist das ganze 'after()' oder 'change()' oder 'cycle()' und wie sie noch alle heissen, für diesen Fall eben nicht.

Bist du also der Meinung, ein cycle() ist besser als ein eval()?

[saft6luck]

Wenn man es dann ganz genau nimmt, kann man das ganze auch mit der Theorie der Zustandsautomaten vergleichen. Eine Ähnlichkeit auf abstrakter Ebene zum VHDL Entwurf ist bei komplexeren Aufgaben nicht zu übersehen.

Das erinnert mich ein wenig an mein Vordipom

[enertegus]

S
Und wenn ich dann auch noch zurück fragen darf: Was spricht denn nun eigentlich gegen das eval()?

Nun, es wäre halt anders auch zu lösen. Das ist der Grund. Wenn es gar nicht ginge, würde ich ja das einsehen. Die Verknüpfung sowie geschrieben, geht doch prima, ist m.E. verständlich usw. Der persönliche Programmierstil mag unterschiedlich sein, das ist Geschmacksache, denke ich. Ob man nun verschachteln muss oder nicht, ach ihr wollt mich einfach nicht verstehen ... aber ihr habt mich ja schon bald soweit.

[saft6luck]

... aber ihr habt mich ja schon bald soweit.

Puh, wenn das kommt, kaufe ich dein/euer nächstes KNX-Gerät bestimmt!!!

[enertegus]

Puh, wenn das kommt, kaufe ich dein/euer nächstes KNX-Gerät bestimmt!!!

Das wär ein Deal .
Am besten gleich die nächsten zwei
... so und jetzt in den Garten - ich muss ja noch ein biserl Urlaub machenn

[enertegus]

Puh, wenn das kommt, kaufe ich dein/euer nächstes KNX-Gerät bestimmt!!!

F-000145 und bereits in Firmware v1.210 implementiert...

[saft6luck]

F-000145 und bereits in Firmware v1.210 implementiert...

Ein großes Danke von meiner Seite!!!!!
Da wird der eibPC bei mir wohl nicht das einzige Enertex-KNX-Gerät am Bus bleiben! Was darf ich denn nun kaufen?
Das Warten auf die Release wird nun auf jeden Fall zur Geduldsprobe
Gibt es denn schon einen ungefähren Termin?