Test Adapter pid (pid-Regler) V1.0.x

[mcm1957]

@fu_zhou
Ich möchte eigentlich konsequent den Y Ausgang nur bei einer Neuberechnung ändern.
Warum?
hold = true y=bleibt unverändert ist klar nachvollziehbar

Wenn man bei hold=true auf RST reagiert, dann kommt als nächstes die Frage warum ein Ändern vion OFFS, MAN, MIN nichts ändert. Und warum sich die Änderung von SET, ACT nichts auswirkt.
Das führt in einen Teufelskreis - meiner Ansicht nach.

Und bei JEDER Änderung von Eingangsgrößen sofort neu zu berechnen führt bei einer Regelstrecke mit kurzer Verzögkerung (z.B. Y wirkt unverzögert auf act) zu einer Dauerberechnungsloop die den iob potenziell lahmlegt. Also auch nicht so toll.

Ich würde das Ganze mal so lassen.
Falls es wirklich Bedarf für ein erweitertes (!), soll heißen explizit einstellbares oder auslösbares und kompatibles Verhalten gibt, kann man natürlich über einer Erweiterung reden. Denkbar wäre z.B. ein Calculate Now Triggerstate. Ich bezweifle nur dass der Bedarf hier nennenswert ist.

Insofern bitte mal den aktuellen Stand anschaun und allfällige Fehler melden. (Oder auch kurz, dass nix aufgefallen ist).

Ich werde - sofern keine Probleme hier auftauchen - nach Update der Doku den Stand mal in den regularäen Beta Test (incl. Lates Request) schicken.

[fu_zhou]

@mcm57

@mcm57 sagte in Test neuer Adapter pid (pid-Regler) V0.0.3-alpha.x:

Ich würde das Ganze mal so lassen.

Ansonsten läuft das Ding jetzt bei mir ohne Auffälligkeiten und ich nehme den Adapter mit dem aktuellen Stand mal produktiv.

[fu_zhou]

@mcm57 jetzt fällt mir im Produktivbetrieb doch was auf: wenn max erreicht ist (lim = 1), in meinem Fall unten 11, wird i_sumerr schlagartig auf den 10-fachen Wert vom vorherigen Wert gesetzt und trotz großer Regelabweichung hält der Regler y bei max, obwohl y schnell kleiner werden müsste. Bei 10.9 war i_sumerr z.B. 110, dann springt i_sumerr bei Erreichen vom Limit (11) auf 1100. Und von dort kommt der Regler dann nicht mehr weg, weil vom hohen i_sumerr verhältnismäßig kleine Werte abgezogen werden bei einer Regelabweichung in die andere Richtung.

[mcm1957]

@fu_zhou
Bitte aktiviere "log calculation" und poste mal die logs

(https://forum.iobroker.net/topic/64250/test-neuer-adapter-pid-pid-regler-v0-0-3-alpha-x/191)

Ich schau derweil mal in den Code

Und fährst du "normal" oder "inverted" ?

[fu_zhou]

@mcm57 ich fahre normal, nicht invertiert.
hier das log beim erreichen von max:

pid.0
2023-04-14 18:12:24.112	info	[C-TestRegler2] update() - {"ts":1681488744112,"act":-2,"set":-0.5,"diff":1.5,"off":0,"err":1.5,"y":11,"lim":true,"dt":501,"differr":null,"sumerr":1085,"supr":false}

pid.0
2023-04-14 18:12:23.612	info	[C-TestRegler2] update() - {"ts":1681488743611,"act":-2,"set":-0.5,"diff":1.5,"off":0,"err":1.5,"y":11,"lim":true,"dt":500,"differr":null,"sumerr":1085,"supr":false}

pid.0
2023-04-14 18:12:23.111	info	[C-TestRegler2] update() - {"ts":1681488743111,"act":-2,"set":-0.5,"diff":1.5,"off":0,"err":1.5,"y":10.999374999999967,"lim":false,"dt":501,"differr":null,"sumerr":108.49374999999966,"supr":false}

pid.0
2023-04-14 18:12:22.611	info	[C-TestRegler2] update() - {"ts":1681488742610,"act":-2,"set":-0.5,"diff":1.5,"off":0,"err":1.5,"y":10.991859999999969,"lim":false,"dt":500,"differr":null,"sumerr":108.41859999999967,"supr":false}

und hier das log , wenn ich von act -2 auf act +3 springe, dann müsste y von max weg wieder kleiner werden, passiert aber nicht:

pid.0
2023-04-14 18:15:03.311	info	[C-TestRegler2] update() - {"ts":1681488903311,"act":3,"set":-0.5,"diff":-3.5,"off":0,"err":-3.5,"y":11,"lim":true,"dt":501,"differr":null,"sumerr":1135,"supr":false}

pid.0
2023-04-14 18:15:02.810	info	[C-TestRegler2] update() - {"ts":1681488902810,"act":3,"set":-0.5,"diff":-3.5,"off":0,"err":-3.5,"y":11,"lim":true,"dt":501,"differr":null,"sumerr":1135,"supr":false}

pid.0
2023-04-14 18:15:02.309	info	[C-TestRegler2] update() - {"ts":1681488902309,"act":-2,"set":-0.5,"diff":1.5,"off":0,"err":1.5,"y":11,"lim":true,"dt":501,"differr":null,"sumerr":1085,"supr":false}

pid.0
2023-04-14 18:15:01.808	info	[C-TestRegler2] update() - {"ts":1681488901808,"act":-2,"set":-0.5,"diff":1.5,"off":0,"err":1.5,"y":11,"lim":true,"dt":500,"differr":null,"sumerr":1085,"supr":false}

und 2 Minuten später sieht es noch genauso aus:

pid.0
2023-04-14 18:17:57.000	info	[C-TestRegler2] update() - {"ts":1681489077000,"act":3,"set":-0.5,"diff":-3.5,"off":0,"err":-3.5,"y":11,"lim":true,"dt":500,"differr":null,"sumerr":1135,"supr":false}

pid.0
2023-04-14 18:17:56.500	info	[C-TestRegler2] update() - {"ts":1681489076500,"act":3,"set":-0.5,"diff":-3.5,"off":0,"err":-3.5,"y":11,"lim":true,"dt":501,"differr":null,"sumerr":1135,"supr":false}

pid.0
2023-04-14 18:17:55.999	info	[C-TestRegler2] update() - {"ts":1681489075999,"act":3,"set":-0.5,"diff":-3.5,"off":0,"err":-3.5,"y":11,"lim":true,"dt":500,"differr":null,"sumerr":1135,"supr":false}

[fu_zhou]

@mcm57 noch was: wenn min erreicht wird und die Regelabweichung bleibt, wird bei max weitergemacht und von da läuft der Regler wieder Richtung min. (Tn > 1)

pid.0
2023-04-14 18:46:22.892	info	[C-TestRegler2] update() - {"ts":1681490782892,"act":0.5,"set":-0.5,"diff":-1,"off":0,"err":-1,"y":10.889980000000001,"lim":false,"dt":501,"differr":null,"sumerr":109.8998,"supr":false}

pid.0
2023-04-14 18:46:22.391	info	[C-TestRegler2] update() - {"ts":1681490782391,"act":0.5,"set":-0.5,"diff":-1,"off":0,"err":-1,"y":10.894990000000002,"lim":false,"dt":501,"differr":null,"sumerr":109.9499,"supr":false}

pid.0
2023-04-14 18:46:21.890	info	[C-TestRegler2] update() - {"ts":1681490781890,"act":0.5,"set":-0.5,"diff":-1,"off":0,"err":-1,"y":1,"lim":true,"dt":501,"differr":null,"sumerr":110,"supr":false}

pid.0
2023-04-14 18:46:21.389	info	[C-TestRegler2] update() - {"ts":1681490781389,"act":0.5,"set":-0.5,"diff":-1,"off":0,"err":-1,"y":1.0047899999999956,"lim":false,"dt":501,"differr":null,"sumerr":11.047899999999956,"supr":false}

pid.0
2023-04-14 18:46:20.888	info	[C-TestRegler2] update() - {"ts":1681490780888,"act":0.5,"set":-0.5,"diff":-1,"off":0,"err":-1,"y":1.0097999999999956,"lim":false,"dt":501,"differr":null,"sumerr":11.097999999999956,"supr":false}

[fu_zhou]

@mcm57 sagte in Test neuer Adapter pid (pid-Regler) V0.0.3-alpha.x:

Ich dachte eigentlich, dass ich nur mal schnell den node-pid code in einen Adapter integriere.

[fu_zhou]

@mcm57 es scheint so zu sein, dass bei Tn >1 der Regler sich bei max festhängt und bei Tn < 1 sich der Regler bei min festhängt. Nur bei Tn = 1 funktioniert's. Wenn der Regler mal hängt, bekommt man ihn wieder in Gang, indem man Tn = 1 setzt.

Und bei Tn < 1 läuft der Regler Richtung max, bleibt nicht stehen und fängt wieder bei min an (bei Regelabweichung mit entsprechendem Vorzeichen), habe als max diesmal 3, nicht 11 drin:

pid.0
2023-04-14 19:36:19.924	info	[C-TestRegler2] update() - {"ts":1681493779924,"act":-1,"set":-0.5,"diff":0.5,"off":0,"err":0.5,"y":1.6251,"lim":false,"dt":501,"differr":null,"sumerr":15.751,"supr":false}

pid.0
2023-04-14 19:36:19.423	info	[C-TestRegler2] update() - {"ts":1681493779423,"act":-1,"set":-0.5,"diff":0.5,"off":0,"err":0.5,"y":1.5750000000000002,"lim":false,"dt":500,"differr":null,"sumerr":15.25,"supr":false}

pid.0
2023-04-14 19:36:18.923	info	[C-TestRegler2] update() - {"ts":1681493778923,"act":-1,"set":-0.5,"diff":0.5,"off":0,"err":0.5,"y":3,"lim":true,"dt":501,"differr":null,"sumerr":14.75,"supr":false}

pid.0
2023-04-14 19:36:18.422	info	[C-TestRegler2] update() - {"ts":1681493778422,"act":-1,"set":-0.5,"diff":0.5,"off":0,"err":0.5,"y":2.977000000000001,"lim":false,"dt":501,"differr":null,"sumerr":29.270000000000014,"supr":false}

pid.0
2023-04-14 19:36:17.921	info	[C-TestRegler2] update() - {"ts":1681493777921,"act":-1,"set":-0.5,"diff":0.5,"off":0,"err":0.5,"y":2.926900000000001,"lim":false,"dt":501,"differr":null,"sumerr":28.769000000000013,"supr":false}

[mcm1957]

@fu_zhou
Ja ich glaub ich hab den Fehler schon. Die Umstellung dass sumErr schon beim integrieren tn berücksichtigt dürfte nicht in die Limitierung eingeflossen sein,

Kannst du mir bitte noch deine Parametereinstelliung (kp, tn, tv, max, min, gff off) schicken? Ich will das mal in Excel nachrechnen was ich codiere

sumErr wird nämlich beim begrenzen auch limitiert. Nur muss das zurückgerechnet werden dass sumErr xxx ganu y == lime rgibt. Und dürfte der Wurm drinnen sein.

[fu_zhou]

@mcm57
Kp = 0,1
Tn = > 1 oder < 1 (10 im Produktivbetrieb, wird sich aber noch ändern, wenn der Regler min/max richtig verarbeitet ) oder = 1 um den Regler wieder in Gang zu setzen
Tv = 0
max = 3 (11 im Produktivbetrieb)
min = 1
off = 0
sup = 0,2

[mcm1957]

@fu_zhou
Bitte teste mal die neueste Release (0.0.6).

Lt. Excel sollt es nun passen. Der Sprung um 10 den du beobachtet hast passt auch zu tn=10

[fu_zhou]

@mcm57 Habe jetzt mit Tn > 1 und Tn < 1 getestet. Jetzt passt es, was ich so gesehen und probiert habe! Auf in's Wochenende - PV-Überschuss-Laden geregelt bekommen!

[fu_zhou]

Mal ein kurzes Fazit von der PV-Überschussladung: Echt super, mit dem Regler!

Ich verwende folgende Parameter:

• Istwert: aktuelle Netzleistung (- = Einspeisung, + = Bezug)
• Sollwert: 0,1 kW Netzeinspeisung (= -0,1 kW), wobei ich den verschieben kann, z.B. auf +3,0 kW, um auf jeden Fall zu laden (dann halt nicht PV-Überschuss)
• Kp=0,1, Tn=10s, Tv=0s (bisher nur PI-Regler)
• sup: 0,2 kW: damit werden Schwankungen im Haus (hier ne Lampe an, da startet der Kühlschrank) gut weggefiltert, ebenso wird damit die Situation verhindert, dass der Regler die Wallbox als Sprungantwort ständig zwischen 2 Stromstärken hin- und herschaltet (z.B. 7A - 8A -7A, die Wallbox goE HomeFix arbeitet nur mit ganzen Ampere)
• min: die Wallbox startet bei 230V, 6A (= ca.1,4 kW), d.h. mein min ist fix auf 1.3 kW eingestellt => der Regler braucht nicht die gesamte Totzone von 0 bis 1.4 kW hochreglen, bis die Ladung freigegeben wird
• max: berechne ich dynamisch aus verfügbarer PV-Leistung minus 0,5 kW Grundlast plus Sollwert Netzbezug. Wenn eine Wolke drüber zieht und die PV-Leistung einbricht, muss der Regler nicht erst runterregeln, sondern reduziert die Ladeleistung sehr schnell. Ich nutze daher Kp, nicht Xp, weil die Veränderung von max keinen Einfluss auf y haben darf (außer y > neues max).
• hold: setze ich auf true, wenn die Anzahl der Phasen (1 nach 3, 3 nach 1) aufgrund der angeforderten Ladeleistung umgeschaltet wird. Die Wallbox pausiert hier kurz den Ladevorgang, was dazu führt, dass die vorherige Ladeleistung schlagartig ins Netz gegeben wird und der Regler mit einem Sprung antworten würde, was dazu führt, dass die Phasen ständig hin- und herschalten und gar nicht mehr geladen wird (durch die Ladepause bei der Phasenumschaltung). hold setze ich wieder auf false, wenn die Phasenumschaltung abgeschlossen ist und die Wallbox mit der neuen Anzahl Phasen weiterlädt

Ich muss mal sehen, ob ich noch eine Tv ermittle und in wie weit Kp, Tn und sup noch weiter optimiert werden können. Bisher bin ich aber schon sehr zufrieden!

[mcm1957]

@fu_zhou
Danke für das ausführliche Feedback incl Anwendungsbericht.

[oxident]

Bitte steinigt mich nicht wegen der vielleicht blöden Frage, aber wäre dieser Adapter prinzipiell auch dafür geeignet, die Lade-/Entladeleistung eines PV-Akkus zu berechnen um eine "Nulleinspeisung" zu erreichen?

Derzeit steuere ich mein Victron-System mehr oder weniger "klassisch", d. h., ich regele jede Sekunde nach in der Hoffnung, am Zähler 0kW zu erreichen...

PID ist für mich Neuland ... klingt aber spannend

[paul53]

@oxident sagte: geeignet ... um eine "Nulleinspeisung" zu erreichen?

Ja.

[fu_zhou]

@oxident Du hast aus meiner Sicht genau so einen Anwendungsfall, für den der PID-Adapter gedacht ist.

Wie "regelst" du denn jetzt nach? Wie gibst du dem Victron-System die Lade-/ Entladeleistung vor?

[oxident]

@fu_zhou Ich prüfe jede Sekunde, wie die Bilanz am Stromzähler ist und addiere dieses Wert zum derzeitigen Setpoint des Victron Multiplus:

Setpoint-Neu += (Setpoint-Alt + Netzbezug)

Da dies aber schnell zu krassen Schwingungen geführt hat habe ich die Formel ein wenig verändert:

Setpoint-Neu += (Setpoint-Alt + Netzbezug) * 0.6

Außerdem führe ich die Änderung nur aus, wenn der Netzbezug < -100 oder > 100 ist da ich dummerweise noch einen weiteren, nicht steuerbaren Akku hab.

[fu_zhou]

@oxident da hast du im Prinzip einen P-Regler gebaut mit Kp = 0,6, sup = 100 und Zykluszeit 1 Sekunde. Die Eigenschaft eines P-Reglers ist, dass es bei einer bleibenden Regelabweichung bleibt, diese wird erst durch einen I-Anteil abgebaut. Ist eine Nachstellzeit Tn parametriert, bekommst du einen PI-Regler, parametrierst du noch eine Vorhaltezeit Tv, bekommst du einen PID-Regler, der noch schneller reagiert, als ein PI-Regler.
Wenn du dein System zu gleichmäßigen Schwingungen bringen kannst, kannst du z.B. über Ziegler-Nichols oder Chien, Hrones und Reswick Kp, Tn und Tv ermitteln, siehe: https://de.wikipedia.org/wiki/Faustformelverfahren_(Automatisierungstechnik)
Du musst dabei aber immer bedenken, dass dein System die durch den Regler ausgegebenen Änderungen der Stellgröße = bei dir die Ansteuerung der Lade- und Entladeleistung des Akkus dauerhaft verkraften muss. Es nützt dir ja nichts, wenn du die Nulleinspeisung mit optimalen Reglerparametern hinbekommst, aber nach einem halben Jahr die Elektronik oder der ganze Akku kaputt ist, weil die Bauteile mechanisch/elektronisch nicht für eine stetige Regelung ausgelegt und geeignet sind.

[oxident]

@fu_zhou Wow, danke Dir. Dann hab ich genug Lesestoff für das Wochenende

Über die Grenzen des Akkus muss ich mir zum Glück keine Gedanken machen. Da bremst mich das BMS notfalls. Ubd mehr als 400W/s wird eh nicht geändert. Diese Rampenzeit wird vom Ladegerät forciert.