In der Tiefe: Validierungskonzept

[Tessi]

Der EibPC sollte nach meiner Meinung erst den Logikteil abarbeiten, wenn er die Systemstart-Abfragen erledigt hat und die Antworten eingetroffen sind, denn erst dann macht die Auswertung Sinn.

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? Z.B. ich habe noch keine aktuelle Uhrzeit (und das könnte noch länger so bleiben) und kann daher alle uhrzeitgesteuerten Teile nicht starten, alles andere ist aber initialisiert und soll nicht mehr länger warten.

Gerade der Teil der Forderung fällt in den Bereich, den ich mit "für jeden Häuslebauer geeignet" fällt und der unbedingt verbessert werden sollte.

Ja, nur über das wie sollte man gut nachdenken, sonst treiben wir Teufel mit Belzebub aus...

[anlo007]

Wenn ich meine Umfrage anschaue, ist die deutliche Mehrheit der Teilnehmer für meinen Vorschlag, und der ist Zielgruppenunabhängig. (Es sei denn, Du betrachtest Installationen, bei denen keine GA durch die Abfrage des Systemstarts eingelesen werden soll, als eine eigene Zielgruppe, die sich gravierend von dem Rest unterscheidet.)

Hier ist ein Mißverständnis, auch ich habe für die Verzögerung des Starts gestimmt. Der EibPC sollte nach meiner Meinung erst den Logikteil abarbeiten, wenn er die Systemstart-Abfragen erledigt hat und die Antworten eingetroffen sind, denn erst dann macht die Auswertung Sinn.

Gerade der Teil der Forderung fällt in den Bereich, den ich mit "für jeden Häuslebauer geeignet" fällt und der unbedingt verbessert werden sollte.

[enertegus]

Ps. hatte oben die Zuweisung als Vergleich, hattest du aber als write() verstanden, oder?

so isses.

[saft6luck]

Die Probleme enstehen bei der Verwendung von der Form
if Ausdruck then verändere(Ausdruck) endif
Dies kommt aus KNX Sicht m.W. nicht vor. Es ensteht erst durch die Verwendung von Variablen etc.

IF GA1 and GA2 == AUS then write( GA2, EIN ) endif

Aber da gibt es kein Problem. Oder wo versteh ich Dich nicht?

Stimmt, nur kommt genau der Ausdruck, den du da ansprichst häufig vor. Ich hatte dich schon verstanden.

Ein Beispiel für if then else endif könnte das Weiterschalten von Lichtszenen sein, mit Abfrage auf Überlauf, aber wie bekannt gibt es mit GAs
ja eh keine Probleme dieser Weise.


Ps. hatte oben die Zuweisung als Vergleich, hattest du aber als write() verstanden, oder?

[enertegus]

IF GA1 and GA2 == AUS then GA2 == EIN endif

Aber da gibt es kein Problem. Oder wo versteh ich Dich nicht?

[saft6luck]

Bitte ein Beispiel.

IF GA1 and GA2 == AUS then write( GA2, EIN ) endif

[enertegus]

Aus KNX Sicht kommt das sehr wohl vor, nur hat es dort keinen Einfluss, da GAs ja frühestens im nächsten Zyklus, so wie ich dich verstehe aber erst mit dem eigentlichen Empfang der Aussendung, einen neuen Wert annehmen.

Bitte ein Beispiel.

[saft6luck]

Was fehlt da denn nun noch? Im Abschnitt zum Validierungskonzept sind dazu Beispiele ist erläutert.

Klar, ich habe es nun ja auch verstanden aber man muss da erst drauf kommen. Das sollte keine Eigenleistung sein, sondern ein klarer Hinweis sollte auf den Sachverhalt hinweisen und eben das Beispiel genau erklärt werden.

Wenn es dann auch noch Unterschiede bei Variablen und GAs gibt ...

Die Probleme enstehen bei der Verwendung von der Form
if Ausdruck then verändere(Ausdruck) endif
Dies kommt aus KNX Sicht m.W. nicht vor. Es ensteht erst durch die Verwendung von Variablen etc.

Aus KNX Sicht kommt das sehr wohl vor, nur hat es dort keinen Einfluss, da GAs ja frühestens im nächsten Zyklus, so wie ich dich verstehe aber erst mit dem eigentlichen Empfang der Aussendung, einen neuen Wert annehmen.

Und das macht es so undurchsichtig. Selbst wenn ich Variablen verwende, muss eine 'direkte' Änderung nicht gegeben sein. Und im 2. Durchlauf wird z.B. systemstart() ja nicht mehr TRUE sein.

NB. bei GAs ist dann u.U. der Zeitpunkt wichtig, zu dem man das write() im Code platziert

[enertegus]

Schreibst du das entsprechend ausführlich ins Handbuch?

Was fehlt da denn nun noch? Im Abschnitt zum Validierungskonzept sind dazu Beispiele ist erläutert.

Bleibt die Frage, warum das Verhalten so gewählt wurde, wie es nun implementiert ist, bzw. ob das wirklich so bleiben muss/soll? Nach meinem Verständnis erwartet ja auch kein Profi-Elektriker solch ein Verhalten, oder?

Die Probleme enstehen bei der Verwendung von der Form
if Ausdruck then verändere(Ausdruck) endif
Dies kommt aus KNX Sicht m.W. nicht vor. Es ensteht erst durch die Verwendung von Variablen etc.

Wie sind in diesem Zusammenhang GAs zu bewerten? Der Inhalt ändert sich doch erst beim Schreiben auf den Bus. Ist das dann also kein Problem für das else, da alles erst am Ende des Zykluses in die Warteschlange kommt ?

Ja. Außerdem wird das Abbild erst wieder beim Entreffen des Telegramms neu gesetzt.

[saft6luck]

Da kann ich nix helfen. Es ist schon so wie im pdf beschrieben. Wir hatten noch überlegt, else gar nicht erst zuzulassen, weil uns diese Problematik bewusst war. Allerdings gibt es da eben manchmal doch eine gewisse Eleganz beim Coden...

Schreibst du das entsprechend ausführlich ins Handbuch?

Bleibt die Frage, warum das Verhalten so gewählt wurde, wie es nun implementiert ist, bzw. ob das wirklich so bleiben muss/soll? Nach meinem Verständnis erwartet ja auch kein Profi-Elektriker solch ein Verhalten, oder?

Wie sind in diesem Zusammenhang GAs zu bewerten? Der Inhalt ändert sich doch erst beim Schreiben auf den Bus. Ist das dann also kein Problem für das else, da alles erst am Ende des Zykluses in die Warteschlange kommt (und damit auf den Bus)?

[saft6luck]

[..]nachdem ich das erste mal das Validierungskonzept en Detail gelesen habe, bin ich erst mal alle "else" Dinger in meinen Makros und Programmen durchgegangen und habe

Habe ich gestern auch gemacht. Inzwischen habe ich auch noch alle Verschachtelungen entfernt. Bei mir sind da min. 2 Fälle aufgetaucht, die sicher problematisch waren.

Meine Empfehlung lautet derzeit: kein else benutzen

Mein Programm ist nun nicht mehr wirklich strukturiert, dafür hoffentlich fehlerfrei.

[bmx]

Tach auch,

nachdem ich das erste mal das Validierungskonzept en Detail gelesen habe, bin ich erst mal alle "else" Dinger in meinen Makros und Programmen durchgegangen und habe

if a then b else c endif

ersetzt durch

if a then b endif

if !a then c endif

Somit kann mir nicht mehr der Lapsus passieren dass ich irgendwo aus alter C-Manier was stehen lasse, was kann anders bearbeitet wird.

Meine Empfehlung lautet derzeit: kein else benutzen

Gruß,
Bernd

[enertegus]

Wenn ich jetzt mal die zyklische Abarbeitung voraussetze, entspricht das ja auch normaler, z.B. C-Logik: eine Änderung einer Variablen wird direkt in allen folgenden Abfragen beachtet. Allerdings soll beim eibPC das ELSE dem negierten IF_THEN entsprechen, das dann auch gleich ausgeführt wird, wenn die geänderte Bedingung nun EIN ist. Siehe erstes Beispiel "Der 'ELSE-Zweig'". Michael, hilf!

Da kann ich nix helfen. Es ist schon so wie im pdf beschrieben. Wir hatten noch überlegt, else gar nicht erst zuzulassen, weil uns diese Problematik bewusst war. Allerdings gibt es da eben manchmal doch eine gewisse Eleganz beim Coden...

[saft6luck]

Also der ELSE in der gleichen IF_THEN bestimmt nicht, das wäre extrem unlogisch.

Ich hoffe zwar noch, das PDF lässt aber große Zweifel aufkommen!!!

Aber alle nachfolgenden einzelnen IFs reagieren schon auf den geänderten "Inhalt (=Wert) der Abfragebedingung".
Wenn man das nicht will, muss man über einen Zwischenmerker gehen, der erst am Zyklusende den Zielwert an den sog. "Inhalt (=Wert)" überträgt.
(auch wenns wieder einige nervven wird, aber das Verhalten ist auch in einer SPS so anzutreffen)

Wenn ich jetzt mal die zyklische Abarbeitung voraussetze, entspricht das ja auch normaler, z.B. C-Logik: eine Änderung einer Variablen wird direkt in allen folgenden Abfragen beachtet. Allerdings soll beim eibPC das ELSE dem negierten IF_THEN entsprechen, das dann auch gleich ausgeführt wird, wenn die geänderte Bedingung nun EIN ist. Siehe erstes Beispiel "Der 'ELSE-Zweig'".

Michael, hilf!

[IBFS]

D.h. wenn der Inhalt (=Wert) der Abfragebedingung durch den then Zweig geändert wird, weil z.B. die abgefragte Variable geändert wird, kann es passieren, dass sofort, also im gleichen Zyklus(!), auch noch der else Zweig bearbeitet wird?

Also der ELSE in der gleichen IF_THEN bestimmt nicht, das wäre extrem unlogisch.

Aber alle nachfolgenden einzelnen IFs reagieren schon auf den geänderten "Inhalt (=Wert) der Abfragebedingung".
Wenn man das nicht will, muss man über einen Zwischenmerker gehen, der erst am Zyklusende den Zielwert an den sog. "Inhalt (=Wert)" überträgt.
(auch wenns wieder einige nervven wird, aber das Verhalten ist auch in einer SPS so anzutreffen)

Frank