Neues Modul PID20 - Der PID-Regler

[John]

Hallo Joachim,

folgendes halte ich für absolut kontraproduktiv:

Code Auswählen Erweitern

attr PID_CB_HZ_BZ_FB event-min-interval actuation:300,actuationCalc:300,delta:300,desired:300,measured:300,p_d:300,p_i:300,p_p:300

Beispiel actuationCalc: wird nur als Event weitergereicht, wenn mindestens 5 Minuten vergangen sind. D.h es werden effektiv bestimmte Änderungen ignoriert und somit nicht gelogged.

Das führt zum Ausschnitt wie im Bild dargestellt.
(http://forum.fhem.de/index.php?action=dlattach;topic=17067.0;attach=22061)
Actuation fährt hoch ohne dass ActuationCalc diese induziert.

Die Readings werden nicht regelmässig aktualisiert, sondern nur dann wenn es nötig ist.
Es gibt durchaus Zustände, in denen die P/I/D-Anteile nicht mehr aktualisiert werden (z.B. Anti-Windup).
Also verzichte event-min-interval und alles wird gut. Man sieht dass alles plausibel ist, wenn du dieses Attribut nicht verwendest.

Würde ich die Ursache nicht kennen, müsste man meinen PID20 arbeitet fehlerhaft.

John

[Joachim]

Moin John,
dann ist meine Frage geklärt, und ich muss das Problem nicht bei mir suchen.
event-on-change und event-min-intervall funktionieren nicht wie gewohnt mit PID20.
Wenn man einen durchgehenden Plot haben möchte, sollte man darauf verzichten.

Wieso Du das für kontraproduktiv hälst, erschliesst sich mir allerdings noch nicht ganz.
Gerade in der Einregelungszeit des Thermotaten (oder zur Fehlersuche) ist ein Plot genial, um zu verstehen, wie sich Änderungen auswirken.
Unnötig ist es aber, jedes mal alle Werte, auch die nicht geänderten, zu Loggen.

Danke für Deine Antwort, werde mich nun an die Optimierung meiner FB_Heizung machen.

Gruß Joachim

[John]

Wieso Du das für kontraproduktiv hälst, erschliesst sich mir allerdings noch nicht ganz.

event-on-change-reading habe ich nicht kritisiert, aber event-min-intervall.

Wenn letzteres dazu führt, dass wichtige Änderungen nicht dargestellt werden, kommt man zu einem falschen Bild
und zu  falschen Rückschlüssen. (Siehe vorheriger Post)

John

[Joachim]

Ich hege den Verdacht, wir reden aneinander vorbei.
Bisher hatte ich die Kombination auch event-on-change und event-min-intervall so verstanden, dass jede Änderung eines angegebenen Wertes zu einem Event, und damit zu einem Eintrag im Log führt. Da dadurch allerdings Werte, die sich nicht verändert haben nicht zu einem Event, und damit zu einem Eintrag im Log füren benötigt man event-min-intervall, um nach einer Vorgegbenen Zeit (die 300 Sekunden sind natürlich zu kurz) auch für diese Werte, z.B. desired einen Eintrag im Log zu haben.
So war es zumindest bisher bei jedem anderen Log. deshalb irretierte mich dieses Verhalten.

Joachim

[justme1968]

ja. so hängen beide zusammen.

wenn es dir aber nur um die plots geht ist min-intervall nicht nötig wenn du logProxy verwendest.

gruß
  andre

[Joachim]

Moin Andre,
danke für die Info, mit logProxy bin ich schon am ausprobieren, ist schön geworden, werde ich auch die Tage noch mal im richtigen Thread eine Frage stellen.
Ich war halt nur irritiert, das es bei PID20 nicht so geht, wie gewohnt, und wollte den Fehler bei mir ausschliessen.
(es würde mich natürlich brennend interessieren, warum?)

Gruß Joachim

[John]

Hallo Joachim,

ich glaube ich habe das Problem entdeckt. Muss es noch genauer untersuchen.

John

[Joachim]

Moin John,

ich glaube ich habe das Problem entdeckt. Muss es noch genauer untersuchen.

Das ist schön, dass Du da dran bist.

Mittlerweile habe ich meine ersten Gehversuche mit dem Regler gemacht, und dabei ist mir etwas aufgefallen.
Meine wunderschön auf Linie laufende PID_Regelung kommt bei Sollwertänderung aus dem Tritt.
Das liegt mMn an der Sollwertänderung, und könnte durch eine Anti-WindUp-Strategie II beseitigt werden.
Hier mal meine nicht wissenschaftlich korrekte Begründung dazu:
Wenn man von außen (also durch Sollwertänderung) den Regler aus dem Tritt bringt, macht es Sinn, den I-Anteil bis zum Erreichen der neuen Solltemperatur einzufrieren, da sich die eigentlichen Regelparameter (Energiezufluss, Energieabfluss) nicht verändert haben. Der I-Anteil darf sich also bis zum Erreichen der neuen Solltemperatur nicht verändern, da sonst bei erreichen der Solltemperatur ein Überschwingen erfolgt, welches sich nur sehr langsam abbaut.
Im Bild ist es sehr gut zu erkennen.

Gruß Joachim

[John]

Hallo Joachim,

sind das die aktuellen Regelparameter ?
     factor_D   0
     factor_I   0.01
     factor_P   50

Überleg dir zunächst mal bei welcher Regeldifferenz, das Ventil zu 100% geöffnet sein soll.

Gehen wir von Delta T=1 °C aus.
Mit einem P-Faktor von 100 würde der P-Anteil schon 100% Öffnung fordern. Der Regler wäre im "Wind-UP" , der I-Anteil eingefroren.

Ich denke du solltest erst die Reglerparameter ausloten, bevor wir uns neue noch komplexere Mechanismen überlegen.

Woher kommen eigentlich die Nadelimpulse beim Istwert ?

John

[Joachim]

Moin John,

sind das die aktuellen Regelparameter ?

Nein, habe da natürlich schon versucht, das Regelverhalten zu ändern, allerdings ist das Haus super gedämmt, und draussen ist es noch zu warm.
Es ist mir halt nur ins Auge gefallen, dass mir der I-Anteil nach Sollwertänderung einen Strich durch die Rechnung macht.
Aktuelle Regelparameter:

Code Auswählen Erweitern

Internals:
   CFGFN      ./FHEM/000_max.cfg
   DEF        TS_BZ:helper_T CB_HZ_BZ_FB:maxValveSetting
   NAME       PID_CB_HZ_BZ_FB
   NR         248
   NTFY_ORDER 50-PID_CB_HZ_BZ_FB
   STATE      processing
   TYPE       PID20
   Readings:
     2014-11-27 15:59:24   actuation       0
     2014-11-27 15:59:54   actuationCalc   -2.76341361607922
     2014-11-27 15:59:54   delta           -0.170100000000001
     2014-11-27 15:59:24   desired         19
     2014-11-27 15:59:24   measured        19.1701
     2014-11-27 15:59:54   p_d             -0.000173616079222227
     2014-11-27 15:59:54   p_i             3.19026000000006
     2014-11-27 15:59:54   p_p             -5.95350000000005
     2014-11-27 15:59:54   state           processing
   Helper:
     actor      CB_HZ_BZ_FB
     actorCommand maxValveSetting
     actorErrorAction freeze
     actorErrorPos 0
     actorInterval 840
     actorKeepAlive 1800
     actorLimitLower 0
     actorLimitUpper 35
     actorThreshold 1
     actorTimestamp 2014-11-27 15:59:24
     actorValueDecPlaces 0
     adjust
     calcInterval 30
     deltaGradient -0.000192156850932329
     deltaOld   -0.190100000000001
     deltaOldTS 2014-11-27 16:00:04
     deltaTreshold 0
     desiredName desired
     disable    0
     factor_D   0.1
     factor_I   0.08
     factor_P   35
     isWindUP   1
     measuredName measured
     reading    helper_T
     regexp     ^([\+,\-]?\d+\.?\d*$)
     reverseAction 0
     sensor     TS_BZ
     sensorTimeout 3600
     stopped    0
     updateInterval 60
Attributes:
   pidActorInterval 840
   pidActorLimitUpper 35
   pidActorTreshold 0.5
   pidActorValueDecPlaces 0
   pidCalcInterval 30
   pidFactor_D 0.1
   pidFactor_I 0.08
   pidFactor_P 35
   pidUpdateInterval 60
   room       Badezimmer,PID

Woher kommen eigentlich die Nadelimpulse beim Istwert ?

Duschen!
Ich habe jetzt ersteinmal pidActorLimitUpper auf 35 % reduziert, und werde jetzt mal den nächsten Versuch fahren.
Wie bekomme ich eigentlich p_I auf 0 gesetzt?
Mit löschen von pidFactor_I und restart 0 geht es nicht.
Hier noch einmal ein Bild in besserer Auflösung mit dem überschiessenden I_Anteilund eins nach löschen und restart von pidFactor_I und pidFactor_d

Gruß Joachim

[John]

Wie bekomme ich eigentlich p_I auf 0 gesetzt?

wenn du das Attribut pidFactor_I =0 setzt.

"I" steht für Integral-Anteil.

John

[John]

Die neue Version 1.0.0.4 ist eingechecked.

Die Readings werden nun zyklisch aktualisiert, so daß die Standardmechanismen von FHEM greifen:  event-on-change-reading, event-min-interval.

Mit der neuen Version erhöht sich die Aktualisierung der Readings dramatisch.

Damit die Log-Dateien nicht übermäßig gross werden sollte man die Events begrenzen.

Ich habe mich bei meinem Regler für folgende Einstellungen entschieden:


Event nur feuern, wenn sich Reading um einen Mindestwert ändert:

Code Auswählen Erweitern


attr PID.PID event-on-change-reading actuation:1,actuationCalc:0.5,delta:0.2,desired,measured:0.2,p_d:0.1,p_i:1.0,p_p:1.0



Event auch dann feuern, wenn dieser innerhalb eines festgelegten Zeitraums (hier 30 Minuten)  nicht gefeuert wrude (für die Charts sinnvoll)

Code Auswählen Erweitern


attr PID.PID event-min-interval .*:1800


John

[My-FHEM]

Tolles Modul.

Ist es gewollt, das definierte UserReadings aktualisiert werden, wenn "desired" geändert wird?
und nicht zum definierten CalcIntervall?

Gruß

[John]

Hallo My-FHEM,

wenn du desired aktualisierst, wird in jedem Fall auch das Reading "desired" beschrieben.

Die Aktualisierung von UserReadings wird nicht im PID.Modul, sondern im FHEM-Kern geregelt.

Die CommandRef sollte hier weiterhelfen.

John

[My-FHEM]

@ John, Danke für deinen Hinweis.

Wie kann ich erreichen, d.h. welcher Event kann als trigger benutzt werden sodas ein userReading synchron zum CalcInterval aktualisiert wird?

Gruß