Validierungsschema: welche Funktionen werden invalid, welche nicht?

[Tessi]

Es gibt sicherlich noch etliche andere Gründe (Du könntest mir ja noch einige nennen, ich (er)kenne sicher nicht alle), aber ich denke, diese hier decken den größten Teil der Geräteerwerbungen ab.
Ob ein Produkt als gut (genug) eingestuft wird, hängt natürlich auch vom jeweiligen Standpunkt ab. Für Hersteller und Verkäufer zählt üblicherweise der erzielbare/erzielte Gewinn, alles andere ist Mittel zum Zweck - manchmal wird das vergessen.
Da ein Interessent aber normalerweise nicht kauft, wenn er das Produkt schlecht oder überteuert findet, schließe ich für meinen Teil aus einer Kaufentscheidung darauf, das es zumindest als gut genug befunden wurde.

Du scheinst aber andere Kaufmotive gehab zu haben, darf ich erfahren, welche es waren?

[enertegus]

Aber zu welcher Kategorie gehören stringcast() und stringset()?

Also nochmals zur Klarstellung (ab eibparser 2.222)

x=stringcast(...)
verhält sich wie eine "normale" Funktion, d.h. sie wird von ihren Eingängen bei deren Änderung invalidiert.

stringset(...)
wird von nicht ihren Eingängen bei deren Änderung invalidiert. Bisher war das so, dass stringset wie eine Queue behandelt wurde, also erst am Ende der Verarbeitung der String verändert wurde (und dann erst wenn die anderen Variablen bereits abgearbeitet waren). Daher:
[highlight=epc]
if systemstart () then stringset(x,2,t);t=t+1u16 endif
[/highlight]
hat immer auf die t+1-Stelle die "2" geschrieben und nicht auf t. Im neuen Compiler wird das aber nun abgefangen und die Anordung der Objekte umgebaut, so dass nun auf die t-Stelle geschrieben wird.

Noch ein Beispiel:
Der folgende Code hat bisher nur an die Stelle 4 (einmal) geschrieben, der neue Compiler schreibt an Stelle 0 und 4.
[highlight=epc]
z=$$
t=0u16
if systemstart() then {
stringset(z,convert(2,0u16),t);
t=t+4u16;
stringset(z,convert(2,0u16),t)
} endif
[/highlight]

[Tessi]

x=stringcast(...)
verhält sich wie eine "normale" Funktion, d.h. sie wird von ihren Eingängen bei deren Änderung invalidiert.

Das bedeutet auch, falls ich 1000 1-Byte-Werte per 1000 stringcast()-Aufrufe aus einem String laden würde und nun ändere ich ein einziges Byte in diesem String per stringset(), das dann anschließend alle 1000 stringcast() erneut abgearbeitet werden?!
[highlight=epc]
var0=stringcast(String, 0u08, 0u16)
var1=stringcast(String, 0u08, 1u16)
var2=stringcast(String, 0u08, 2u16)
var3=stringcast(String, 0u08, 3u16)
var4=stringcast(String, 0u08, 4u16)
var5=stringcast(String, 0u08, 5u16)
var6=stringcast(String, 0u08, 6u16)
var7=stringcast(String, 0u08, 7u16)
if (irgend ein Trigger1) then {
var0=0u08;
var1=1u08;
var2=2u08;
var3=3u08;
var4=4u08;
var5=5u08;
var6=6u08;
var7=7u08;
stringset(String, var4, 4u16)
} endif
[/highlight]Wenn Trigger1 auslöst, erhalten die Variablen var0 bis var7 die festen Werte zugewiesen. Aber sobald stringset() ausgeführt wurde werden dann var0 bis var7 gleich wieder per stringcast() die Werte aus String zugewiesen, so das außer für var4 alle Änderungen verloren gehen?

Der folgende Code hat bisher nur an die Stelle 4 (einmal) geschrieben, der neue Compiler schreibt an Stelle 0 und 4.

Da wäre ich früher oder später drauf reingefallen! Gut das es sich jetzt so verhält, wie ich es ohne diese Warnung ohnehin erwartet hätte.
Das wirft aber gleich eine generelle Frage auf, was kommt hierbei heraus?
[highlight=epc]
t=0u16
if systemstart() then {
var0=t;
t=t+4u16;
var1=t;
t=t+4u16;
var2=t;
t=t+4u16;
var3=t;
t=t+4u16;
var4=t;
t=t+4u16;
var5=t;
t=t+4u16;
var6=t;
t=t+4u16;
var7=t;
t=t+4u16;
} endif
[/highlight]Welche Werte enthalten danach var0 bis var7 und welchen Wert hat t? Ist überhaupt sicher, das der Compiler das wenigstens immer in der gleichen Reihenfolge anordnet (auch wenn das nicht dieselbe ist, in der es im Programm steht) oder kann selbst das von Version zu Version, ggf. sogar von Programm zu Programm verschieden sein?

Klar, ich würde hier besser schreiben:
[highlight=epc]
t=0u16
if systemstart() then {
var0=t;
var1=t+04u16;
var2=t+08u16;
var3=t+12u16;
var4=t+16u16;
var5=t+20u16;
var6=t+24u16;
var7=t+28u16;
t=t+32u16;
} endif
[/highlight]Die Zuweisungen an var0 bis var7 könnten nun in beliebiger Reihenfolge erfolgen, aber es bliebe immer noch die Ungewissheit, wann t neu berechnet wird, ob vor, zwischen oder tatsächlich wie von der Reihenfolge im Code beabsichtigt nach den Zuweisungen an var0 bis7.

[saft6luck]

Dies ist momentan eines der vielen offenen Themen in diesem Forum, auf deren Antwort ich auch gespannt warte. Michael, hast du da noch Infos für uns?

[martenss]

... meinst Du vielleicht die change()-Funktion. Diese wurde aber nicht geändert.

Despite this statement from Michael I am observing a change in behavior of the following code since applying patch v2.304/Eibstudio v2.308:

[highlight=epc]SendValue="WP verwarmen/koelen feedback aan/uit-4/4/201" and !"WP 3-way valve status open/dicht-4/4/205"
if change(SendValue) and SendValue and Name^ActorOnOffStatus then write(GA,Name^ActorOnOffStatus) endif
if change(SendValue) and !SendValue and Name^ActorOnOffStatus then write(GA,0b01) endif[/highlight]
Prior to the introduction of the new validierungscheme every change of 4/4/205 (so SendValue) resulted in an update of GA (ActorOnOffStatus and 4/4/201 are in both cases always ON).

Sce1: 4/4/205 update received ON -> OFF (SendValue OFF => ON): GA = ON written on KNX bus
==> both w/ old&new fw (as expected)

Sce2: 4/4/205 update received OFF -> ON (SendValue ON => OFF): GA = OFF written on KNX bus
==> only w/ old fw (not expected)

I do not understand why the new validierungscheme would change this behavior. It this a bug or misinterpretation of the changes from my side?

Best regards, martenss

[enertegus]

Despite this statement from Michael I am observing a change in behavior of the following code since applying patch v2.304/Eibstudio v2.308:

Well, this is true, but the compiler and the processing was heavily changed.

Sce2: 4/4/205 update received OFF -> ON (SendValue ON => OFF): GA = OFF written on KNX bus
==> only w/ old fw (not expected)

I'm not sure, if I understand properly:the new firmware doesnot work as expected? What means " ==> only w/ old fw (not expected)"

[martenss]

Well, this is true, but the compiler and the processing was heavily changed.

I am aware, but the change() command did not change - right?

I'm not sure, if I understand properly:the new firmware doesnot work as expected? What means " ==> only w/ old fw (not expected)"

==> new firmware does not send the GA update in scenario 2 (so behaves different compared to old firmware. This is not what I expected.

[enertegus]

I am aware, but the change() command did not change - right?

Right, but the compiler change could have an impact on this.

==> new firmware does not send the GA update in scenario 2 (so behaves different compared to old firmware. This is not what I expected.

We will check.

[martenss]

We will check.

Any update on this problem?

[enertegus]

Any update on this problem?

I made the following program, which operates as expected.
[highlight=epc]
SendValue= "EssenLED9-0/3/6"and !"InfoLedBus-0/3/8"
if change(SendValue) and SendValue and "InfoLEDAus-0/3/7" then write("EssenLED6-0/3/3",EIN) endif
if change(SendValue) and !SendValue and "InfoLEDAus-0/3/7"then write("EssenLED6-0/3/3",AUS) endif
[/highlight]
Perhaps you can send a running example with "manual" GAs for a further check.

[martenss]

Reproduced the problem! The compiler has problems with the inversion when the arguments are provided to a makro without ().
As a solution/workaround one could add these but would be better if the compiler could cope with double inversions.

First define a makro inverting one of its arguments:

1. :begin myMakro(SendValue)
2. if change(SendValue) and SendValue and "InfoLEDAus-0/3/7" then write("EssenLED6-0/3/3",EIN) endif
3. if change(SendValue) and !SendValue and "InfoLEDAus-0/3/7"then write("EssenLED6-0/3/3",AUS) endif
   
4. :end

Depending on the arguments provided, the inversion works or fails:

1. myMakro("EssenLED9-0/3/6" and !"InfoLedBus-0/3/8") --> fails
2. myMakro((("EssenLED9-0/3/6") and (!"InfoLedBus-0/3/8"))) --> works

[enertegus]

Depending on the arguments provided, the inversion works or fails:

1. myMakro("EssenLED9-0/3/6" and !"InfoLedBus-0/3/8") --> fails
2. myMakro((("EssenLED9-0/3/6") and (!"InfoLedBus-0/3/8"))) --> works

This is fixed in the next release. Nevertheless, there is an issue, if you use combinded expressions as an macroargument in [EibPC].

Deep explanation:
In this section, the compiler completely treats the macro as functions (when parsing), till it finds, the function is a macro. The orginal "text" of the argument must be re-constructed from the already disassembled formula tree. After reconstruction it will compile again.

Therefore the compiler re-constructs in the first step from
"EssenLED9-0/3/6" and !"InfoLedBus-0/3/8"
to a version
and "EssenLED9-0/3/6" !"InfoLedBus-0/3/8"
which must be read as
and-Funktion with arguments "EssenLED9-0/3/6", !"InfoLedBus-0/3/8"
If you try, you will find an error message, where you can see the re-constructed expansion. The macro error-message might be confusing.

You can avoid this by using functional-expressions for the logic-operations as
myMakro(and("EssenLED9-0/3/6", !"InfoLedBus-0/3/8"))