Denkfehler oder Fehler?

[klaus_kraemer]

Die stürmischen Tage haben gezeigt, dass eine kleine Anhebung der Vorlauftemperatur bei Sturmwetter gar nicht so schlecht wäre - gedacht, getan, ABER:

Im Makro für die Berechnung der Vorlauftemperatur wurden zwei Variable eingefügt:

// Prozentuale Vorlauftemperaturerhöhung anhand Stundendurchschnitt der Windspitzengeschwindigkeit, also 1,0 + Prozente, da Faktor
Name_Windfaktor = 1f32
Name_UseWindfaktor = WS2225_WindspitzenStundenDurchschnitt > 12.0f16 and "Temp_Aussen-1/0/10" < 15.0f16;

Also der Windfaktor 1 (damit neutral als Multiplikator)
Und UseWindfaktor als b01, um erst ab 15 km/h mit dem Windfaktor die Vorlauftemperatur zu beeinflussen.

Dann kommt der Knackpunkt, denn der Windfaktor wird an exakt einer Stelle berechnet:

if change(pGAtempA) or systemstart() or change(isNacht1@) or change(isNacht2@) or change(isNachtManuell@) or change(Name_txtBF) or change(Name_UseWindfaktor) or change (WS2225_WindspitzenStundenDurchschnitt) then {

......

Name_Windfaktor = 1.0f32 + (convert(WS2225_WindspitzenStundenDurchschnitt, 0.0f32) * convert(Name_UseWindfaktor,0f32) * 1.5f32 / 1000.0f32);

.....
} endif

Also wird der b01-Wert Name_UseWinfaktor in einen f32 Faktor zur Multiplikation gewandelt und sollte bei einem Wert von Falsch bewirken, dass Name_Windfaktor den Wert 1f32 annimmt, ansonsten den berechneten Erhöhungswert.

So schön, so gut - aber was sagt der Debugger?

DebugWindfaktor.jpg

Wie man sieht, ist der Windfaktor trotz des Parameters Name_UseWindfaktor gleich 1 anstatt 1,02475.

Da komm' ich gerade echt nicht weiter...

[HannesKannes]

Für mich sieht das schlüssig aus.
Wenn du sicher bist, dass die Trigger ausgelöst haben sollte die Berechnugn stimmen.
Inwiefern die
convert(Name_UseWindfaktor,0f32) so funktioniert kann ich nicht sagen.Ich würde da sicherheitshalber die
convert(Name_UseWindfaktor,0.0f32) nehmen wie du es bei der vorherigen convert auch gemacht hast.
Und die letzten Berechnungen würde ich der Übersichtlichkeit zusammen fassen zu * 0.0015f32. Das ist aber nur für meinen kleinen Fokus und Tellerrand wichtig😉
Grüße

[klaus_kraemer]

Inzwischen habe ich alles entkoppelt und in eigene

if change(...) then ..... endif gepackt.

Das Verhalten wie im Anfangsthread kann ich einfach nicht nachvollziehen.

Ob man 0.0f32 oder 0f32 schreibt, beides hat bisher immer funktioniert. Ich tendiere aber auch dazu, die 0.0f32 Schreibweise durchzuziehen.

HG
Klaus

[enertegus]

Ob man 0.0f32 oder 0f32 schreibt, beides hat bisher immer funktioniert. Ich tendiere aber auch dazu, die 0.0f32 Schreibweise durchzuziehen.

das ist sicher gleich.

[klaus_kraemer]

Danke enertegus - das hatte ich auch so gesehen!

Allerdings ging ich immer davon aus, dass eine Variable neu berechnet wird, wenn sich ein Wert der Formel ändert, die zur Berechnung verwendet wird. Darum ging es im Eröffnungsthread und da bin ich jetzt vom Glauben abgefallen, wenn Du den Screenshot des Debuggers und den Codeteil vergleichst.

[enertegus]

Da kann ich zu wenig erkennen.
Problematisch ist bei den vielen "change() or change()" ggf., dass sich zwei Änderungen überlagern und daher das nicht wie gewünscht funktioniert. Wenn sich die change() ungünstig abwechseln und zweimal hintereinander in der Verarbeitung auf EIN stehen, dann würde die if nur einmal ausgelöst. Diese Abhängigkeiten kann man aber so nicht erkennen.

[klaus_kraemer]

Ah, ok. Ich habe das Gefühl, Deine Erklärung trifft es.

In der Zwischenzeit habe ich die "vielen" change() in einzelne "If change() ..." zerpflückt und die Sache arbeitet wieder richtig.

Jede dieser einzelnen "if change() ..." setzt dann eine Variable "trigger@", die die Berechnung auslöst.

Wäre aber vielleicht einen Hinweis im Handbuch wert, dass "zu viele" change() in einer if-Konstruktion zu Problemen führen können. Ich stellte mir das so vor, dass alle change(), die auf EIN stehen im Stapel abgearbeitet werden und deswegen alle Berechnungen auch bei parallel auftretenden "EIN"-Zuständen abgearbeitet werden. Aber so erscheint es ein wenig, als ob Threads unkoordiniert nebeneinander arbeiten würden.

Danke und Gruß
Klaus

[enertegus]

Naja, so pauschal kann man das nicht sagen.
Es ist halt so wie beschrieben "Eine Besonderheit der change-Funktionen ist, dass diese nicht bei if-Anweisungen mit else-Zweigstehen dürfen. Ähnlich zur event-Funktion (siehe Seite 122) geht die change-Funktion immer nur für einen Verarbeitungszyklus auf EIN und wird dann bei der if-Anweisung den then-Zweig ausführen. Imnächsten Zyklus geht change wieder auf AUS und nun würde der else-Zweig ausgeführt. Um denAnwender die Programmierung zu vereinfachen, wurde die Verwendung der change-Funktion an die-ser Stelle durch den Compiler beschränkt.Eine Änderung des Arguments aktiviert change in der darauffolgenden Verarbeitungsschleife

Dann kann das halt passieren, dass die Events sich nahtlos aneinander reihen und daher die Verknüpfung mit or zum beschriebenen Verhalten führt.