Hallo John,
ich bin gerade mal wieder dabei meine PID20 Regler zu optimieren. Dabei habe ich auch mit dem pidFactor_D herumgespielt.
Da ich fur p_d nur merkwürdige Peaks in meinen Grafiken gesehen habe, habe ich etwas weiter nachgeforscht:
In der Notify-Funktion wird die deltaGradient-Berechnung zu oft getriggert, da das Patternmatching für das Reading nicht eindeutig ist:
next if ( $s !~ m/$sensorReadingName/ );
Meine Devices enthalten neben temperature (dem eigentlichen Sensorreading) auch Readings der Form Out_temperature, Out_temperature_avg, ...
Ich habe jetzt das Patternmatching etwas angepasst:
next if ( $s !~ m/^$sensorReadingName:.*$/ );
damit funktioniert p_d wie erwartet (anbei auch in Form eines Patches).
Noch eine Anmerkung:
Ich finde es etwas unschön, dass die deltaGradient-Berechnung abhängig ist vom Intervall in dem das Notify durch die Temperaturwerte ausgelöst wird.
Ich bekomme das naturlich auch von außerhalb in den Griff. Zur Zeit verwende ich einen event-aggregator, der alle 5 Minuten ein Temperatur-Event auslöst.
Schöner wäre es den deltaGradient an das normale pidCalcInterval zu koppelt oder sogar ein eigenes Attribut/Intervall dafür zu spendieren.
Gruß,
Gero
Hallo gero,
deinen Vorschlag bezüglich
next if ( $s !~ m/^$sensorReadingName:.*$/ );werde ich übernehmen.
ZitatIch finde es etwas unschön, dass die deltaGradient-Berechnung abhängig ist vom Intervall in dem das Notify durch die Temperaturwerte ausgelöst wird.
Das verstehe ich nicht. Man kann doch erst dann den Gradienten berechnen, wenn ein neuer Wert kommt.
John
Zitat von: John am 06 November 2015, 21:28:09
Das verstehe ich nicht. Man kann doch erst dann den Gradienten berechnen, wenn ein neuer Wert kommt.
Ein einfaches Beispiel:
Ich habe einen Temperatursensor, der z.B. mit einer Auflösung von 0.1 Grad alle 30 Sekunden den aktuellen Wert sendet. Wenn jetzt die Raumtemperatur um 0.1 Grad pro Minute steigt (sehr schnelle Änderung für eine Raumtemperatur), wird in der aktuellen Implementierung der D-Anteil unwirksam bleiben, da der berechnete Gradient meistens 0 ist (durch die begrenzte Auflösung des Sensors). Ab und zu sieht man kurze (viel zu hohe ) Peaks, falls die Berechnung (gesteuert durch das Calcintervall) zufällig in den richtigen Zeitslot fällt.
Zur Zeit verwende ich daher für die Sensordaten einen event-aggregator, der mir die Daten über 5 Minuten mittelt. Meiner Meinung nach gehört dies besser in das Modul rein. Im gleichen Zuge würde ich die Gradientberechnung in die Calc Funktion verschieben, damit man ein definiertes Intervall für die Berechnung hat und nicht vom Event-Intervall des Sensors abhängig ist.
Zusätzlich ist mit aufgefallen, dass der Gradient basierend auf den Deltawerten berechnet wird. Dies führt bei einem Sollwert Sprung zu unschönen Ausschlägen des D-Anteils. Wäre es nicht korrekter den Gradienten direkt auf den Sensorwerten zu berechnen?
Noch eine Frage:
Wenn ich es richtig verstehe, bezieht sich der Faktor für den I-Anteil auf Minuten, der Faktor für den D-Anteil jedoch auf Sekunden. Ist das so korrekt oder sollte nicht die d_portion noch mit 60 multipliziert werden? Ohne diese Änderung habe ich ziemlich große Werte für den D-Anteil. Wenn ich z.b. gegen einen Anstieg von 0.1 Grad pro 3 Minuten (Calcintervall) mit 20% Ventilausschlag entgegenwirken will, müßte mein D-Faktor bei 200 liegen.
Gruß und Danke für deine Arbeit,
Gero
ZitatWenn jetzt die Raumtemperatur um 0.1 Grad pro Minute steigt (sehr schnelle Änderung für eine Raumtemperatur), wird in der aktuellen Implementierung der D-Anteil unwirksam bleiben, da der berechnete Gradient meistens 0 ist (durch die begrenzte Auflösung des Sensors)
Die Unterdrückung von gleichen Werte lässt sich ja mit event-on-change-reading & Co regeln.
Der D-Anteil bleibt bis zum nächsten Event erhalten.
ZitatZusätzlich ist mit aufgefallen, dass der Gradient basierend auf den Deltawerten berechnet wird. Dies führt bei einem Sollwert Sprung zu unschönen Ausschlägen des D-Anteils. Wäre es nicht korrekter den Gradienten direkt auf den Sensorwerten zu berechnen?
Alle Berechnungen im PID basieren auf dem Deltawert, also der Differenz von Soll und Istwert.
Alles andere wäre kein PID-Regler mehr.
John
Zitat von: John am 07 November 2015, 21:43:39
Die Unterdrückung von gleichen Werte lässt sich ja mit event-on-change-reading & Co regeln.
Der D-Anteil bleibt bis zum nächsten Event erhalten.
Für mich habe ich auch eine Lösung gefunden. Ich wollte nur sagen, dass ich es etwas unglücklich finde, dass der Benutzer sich mit der Implementierung des PID20-Moduls beschäftigen muß, um den D-Anteil vernünfig zum Laufen zu bekommen. Ein einfaches event-on-change-reading reicht leider nicht, da dann der D-Anteil bei gleichbleibendem Istwert nie wieder auf 0 gehen wird.
Zitat von: John am 07 November 2015, 21:43:39
Alle Berechnungen im PID basieren auf dem Deltawert, also der Differenz von Soll und Istwert.
Alles andere wäre kein PID-Regler mehr.
In der Theorie hast du recht. In der Praxis kommt das durchaus vor.
Gruß,
Gero