Fussbodenheizung mit PWM steuern

[jamesgo]

Hallo Jürgen,

gegeneinander werden die 3 PWMR nicht steuern. Sie können ja nur heizen und nicht kühlen. Der eine dann mehr und der andere weniger. D.h. die vom Boden abgegebene Energie ist unterschiedlich. Der Boden evt. unterschiedlich warm.

Wenn du die Temperatur des PWMR variierst, kannst du sehen dass mal mehr oder weniger geheizt wird.

Das mit dem Auskühlen ist meiner Meinung nach nicht so schlimm. Meine Heizung brauch ca. 45-60 Minuten bis man die Wärme spüren kann. Es dauert nicht wirklich länger wenn am Vortag der Kachelofen an war oder an einem sonnigen Tag die Heizung nachmittags nur wenig an war um die Wunschtemperatur zu erreichen. Nach der Sommerpause sind es ungefähr zwei Tage an denen ich mehr Energie in den Boden stecken muss bis der Boden auf Betriebstempertur ist.

Viele Grüße
Andy

[Albatros_]

Hallo zusammen,

ich hätte eine Frage zur Implementierung des I-Anteils des PWMR:

my $ISum = 0;
foreach my $t (@{$IBuffer}) {
    $ISum += ($desiredTemp - $t);
}
$ISum = $ISum;

my $IVal = $room->{c_PID_IFactor} * $ISum;

Im Grunde wird die Regelabweichung für die letzten 3 oder 5 Werte gebildet (je Nach konfiguration) und die Summe der Abweichungen mit dem IFactor multipliziert.

Ich hätte erwartet das ISum eine kontinuierliche Summe ist. d.h. bei jedem Rechnenzyklus wird die aktuelle Abweichung (multipliziert mit IFactor) addiert. Mit einem Anti-Wind Up würde diese SUmme dann auf 0 bzw. 1 begrenzt.

Grüße
Albatros

[jamesgo]

Hallo Albatros,

weiter unten findest du die Begrenzung von (-1..+1).

Grüße
Andy

[Albatros_]

Servus,

danke für die schnelle Antowrt. Mir geht es eher um die Berechnung des I-Anteils selbst als die Begrenzung.

ISum = ISum + (Regelabweichung * IFactor)

So hat man eine fortlaufende Integration der Regelabweichung. Aktuell ist es mehr ein PP Regler. Es wird die Reglerdifferenz mit einem Faktor multipliziert. Das ist genau die Berechnung von P.
Wir brauchen einen Integrator. Also die kontinuierliche Summierung.

Grüße

[jamesgo]

Das verstehe ich leider nicht.

Für mich ist (bis auf den Rundungsfehler)

( dT(1) + dT(2) + dT(3) + dT(4) + dT(5) ) * Factor = dT(1) * Factor + dT(2) * Factor + dT(3) * Factor + dT(4) * Factor + dT(5) * Factor

[Albatros_]

Hallo,

also ich hatte immer verstanden, dass I die SUmme aller bisherigen Regelabweichungen ist. d.h. PWMR hat einen internen Wert "ISum".
Bei jedem durchlauf wird auf diesen Wert die aktuelle Reglerabweichung aufaddiert.

Die Berechnung erfolgt nach dieser Formel: ISUM = ISUM + (Abweichung * IFactor)
IFactor = 0.1 (einfacher zu rechnen)

0. Initialisierung: ISum = 0
1. Durchlauf, Abweichung 1° ;  0 + (1 * 0.1) =0.1
2. Durchlauf, Abweichung 0.8°; 0.1 +(0.8 * 0.1) = 0.18
3. Durchlauf, Abweichung 0.5°;  0.18 + (0.5 * 0.1) = 0,23
4. Durchlauf, Abweichung 0.3°;  0,23 + (0.3 * 0.1) = 0,26
5. Durchlauf, Abweichung -1°;   0,26 + (-1 * 0,1) = 0,16
6. Durchlauf, Abweichung -1.5°; 0,16 + (-1,5 * 0,1) = 0,01
usw..

d.h. man braucht sich die alten Werte nicht merken. Diese sind bereits im ISum enthalten. Uns bei jedem Rechenschritt wird die aktuelle Abweichung gewichtet und dann auf die SUmme addiert.


Quelle: http://rn-wissen.de/wiki/index.php?title=Regelungstechnik#PI-Regler

Code Auswählen Erweitern


Software I-Regler:

esum = esum + e
y = Ki * Ta * esum

esum ist die Summe aller bisherigen Abweichungen e. Der Parameter des Software I-Reglers ist abhängig von der Rechenschrittweite Ta (Abtastzeit). Je öfter gerechnet wird, desto öfter wird auch hinzugezählt (aufintegriert). Eine kleine Abtastzeit erfordert also einen kleineren Faktor, dies wird durch die Multiplikation mit Ta verwirklicht.


Grüße

[jamesgo]

ja, dann hab ich ja alles falsch gemacht.

bei mir kommt nämlich folgendes raus: (1 + 0.8 + 0.5 + 0.3 + (-1) + (-1.5)) * 0.1 = 0.01

[Albatros_]

Naja,

wenn der "Buffer" nur auf 3 Werten steht dann werden die ersten Werte nicht mehr berücksichtigt, dann komm ich auf -2.2.
d.h. es entsteht ein Fehler über Laufzeit.

Natürlich stellt sich die Frage welche Auswirkung das auf die Regelung  hat, aber ein Versuch wäre es Wert.
Ansonsten vielen Dank für die Module in denen sicherlich viel Arbeit steckt. Ich habe sie gestern innerhalb kürzester Zeit ohne Probleme in Betrieb nehmen können.

Grüße

[der_oBi]

Hi Andy,

ich wäre zwar ehrlich gesagt nie auf die Idee gekommen Deinen Code zu durchstöbern, aber ich befürchte Albatros hat recht. So zumindest mein Verständnis mit dem bisschen was bei mir von Regelungstechnik haften geblieben ist  Bitte straft mich Lügen, wenn hier jemand unterwegs ist, der Regelungstechnik wirklich verstanden hat 

Natürlich stellt sich die Frage welche Auswirkung das auf die Regelung  hat, aber ein Versuch wäre es Wert.

Sehe ich auch genauso. Die Regelung funktioniert ja heute schon super (zumindest bei mir  ), aber versuchen könnte man es ja.
Ich vermute, dass es den Code sogar vereinfachen würde.

[jamesgo]

Hallo,
zum Ausprobieren einfach mal 30 Werte (oder mehr) verwenden und den Faktor entsprechend anpassen. Oder den Code in einer lokalen Kopie anpassen. Bin gespannt auf eure Erfahrungen und Berichte.
Grüße
Andy

Gesendet von meinem Nexus 7 mit Tapatalk

[der_oBi]

Hi Andy,

ich habe mir erst einmal nicht die Mühe gemacht, Deinen Code lokal zu ändern, sondern habe die vorgeschlagene Variante mit entsprechend hohem ILookBackCnt versucht (für's erste sollte das ja genügend Aufschluss geben).

Ergebnis:
Wenn ein Raum von Komforttemperatur auf Absenktemperatur geht, zieht sich der I-Anteil natürlich auf, bis er am negativen Ende (-1) angekommen ist. Umgekehrt natürlich genauso, ist aber weniger schlimm (im Gegenteil).
Bedeutet: bei jeder Änderung der Solltemperatur müsste natürlich auch der I-Anteil initialisiert werden. 

Das gilt unabhängig davon, wieviele LookBackCnts man verwendet (oder eben den I-Anteil kontinuierlich aufsummiert, wie es ein PID-Regler normalerweise machen würde). Bei wenigen LookBackCnts ist die Auswirkung nur geringer.

Gruß
Obi

[jamesgo]

D.h. die aktuelle Implementierung ist "besser", da sie die deltaT mit der aktuellen Solltemperatur rechnet, statt den aufkummulierten I-Anteil der alten Wunsch-Temperatur mitzuschleppen?

Gesendet von meinem Nexus 7 mit Tapatalk

[der_oBi]

Verdammte Axt...
Du hast recht. In meinem Falle (also ohne Code-Änderung, nur mit Erhöhung der LookBacks) ist das ja doch nicht so eingetreten wie ich beschrieben habe... Leider logge ich die Regler-Anteile nicht mit, dachte nur vorhin so etwas beobachtet zu haben. Der Rest war wahrscheinlich mehr Interpretation als alles andere 

Ja, in dem Falle wäre die aktuelle Implementierung natürlich besser, da somit ja der I-Anteil automatisch auf den neuen Sollwert initialisiert. Buffern tust Du ja nur die Ist-Temperaturen, nicht die Abweichungen.

Also funktionieren würde es so wie es ist schneller, als mit einer "richtigen" Umsetzung des I-Anteils, der jedes Mal neu mit 0 initialisiert werden müsste. Ich würde aber dennoch die Anzahl der LookBacks deutlich erhöhen (vorher bei mir: 5).

Bitte korrigier mich jemand wenn ich Müll verzapfe, Regelungstechnik war nie mein Steckenpferd 

[Albatros_]

Hallo zusammen,
ich habe meine lokale Kopie angepasst und experimentiere jetzt noch mit den Reglerwerten. Bei der aktuellen Implementierung wird immer eine Regelabweichung bleiben. Im eingeschwungenem (ist=20°,soll=20°) Zustand werden P und I Anteil bei dir immer 0 sein und die Heizung aus. Dann muss der Raum erst wieder abkühlen bevor die Heizung angeht. Der I-Anteil soll genau das verhindern und kontinuierlich mit einem gewissen Anteil heizen. Das ist unabhängig von den Anzahl "lookBack" Werte.

Wegen der beschriebene Probleme. Wenn der I-Anteil zu schnell aufläuft, muss man ihn entsprechend reduzuieren. Ich bin aktuell bei 0.005. d.h bei einer Reglerabweichung von 1° wird er pro Minute die Heizung um 0,5% Punkte öffnen oder schließen.
Bei einem Sollwertsprung sollte der P Anteil den I Anteil kompensieren. d.h. bei einem Sollwertsprung von -2° wird der P-Anteil bei einem PFactor von 0.8 direkt auf -1.6 Springen und damit den I-Anteil (maximal 1) kompensieren. Die Heizung geht sofort aus ! Genauso andersrum. Ein Reset des I-Anteils ist nicht notwendig.

Ich lade nachher den angepassten Code mal hoch.

[jamesgo]

Bitte das Modul nicht überschreiben!!

Gesendet von meinem Nexus 5 mit Tapatalk