UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[mcm1957]

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

@mcm57 Der ganze PID-Algorithmus in der S7 ist eine Kombination aus Funktions-Aufrufen. Ist es hilfreich, wenn ich das alles mal zusammensuche? Ich glaube eher nicht, dazu sind wir hier schon weit genug, würde ich sagen.

Danke für das Angebot.
Aber ich glaube auch, dass wir das nur (mehr) machen sollten, wenn es hier Probleme gibt die am Algorithmus liegen könnten.

McM

[Ben1983]

@mcm57 Jetzt ist es aber so, wenn man während hold einen Reset macht, passiert nichts => OK
setzt man dann hold wieder auf false, beginnt der Regler mit y = 0 neu zu regeln.

Wäre es keine Option, wenn Hold = true ist den rst state einfach zu bestätigen, aber nichts zu machen?

[Ben1983]

@mcm57 Liegt das am Hold bit, dass die diff nicht passt?

[mcm1957]

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

@mcm57 Jetzt ist es aber so, wenn man während hold einen Reset macht, passiert nichts => OK
setzt man dann hold wieder auf false, beginnt der Regler mit y = 0 neu zu regeln.

Wäre es keine Option, wenn Hold = true ist den rst state einfach zu bestätigen, aber nichts zu machen?

RST sollte keine außertourliche Neubrechnung auslösen, genausowenig wie das Ändern von act, set, ... RST mcht genau eines - der Integralspeicher wird resetted. Damit wird die Vorgeschuchte vergessen und beim nächsten Rechenzyklus wie bei einem ersten Start berechnet.

Das bei hold=true keine Reaktion auf y zu sehen ist ist daher gewunschen und m.E. ok.

Beim Restart (hold=false) wird y auf set-act/kp + offset gesetzt. Beim ersten Zyklus gibt es keinen Integralteil da dt mangels Vorgängerwert null ist. Wenn also am Ausgang y 0 angelegt wird, dann muss err = 0 sein (bzw. err*kp-off).

Bitte ggef das Loggend er Berechnungen aktivieren:

Dann sollten die Berechnungszyklen im Log auftauchen:

RST während eines Holds zu ignorieren wäre m.E. unlogisch.

[mcm1957]

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

@mcm57 Liegt das am Hold bit, dass die diff nicht passt?

Ich gehe mal davon aus, dass act nach dem letzen Update von y (und diff) sich wieder geändert hat. Diff wird NICHT ständig aktualisiert sondern spiegelt jenen diff Wert dar der bei der letzen Berechnung verwendet wurde. Act und Set können sich dann bis zur nächsten Berechnung ändern.

Änderungen von Act oder Set lösen keine extra Neuberechnung aus.

Ansonsten bitte wie oben die Berechnungslogs aktivieren und den zugehörigen Output posten.

[MartinP]

Instinktiv habe ich gewisse Vorbehalte, einen Regler zu weit weg von der zu regelnden Strecke zu implementieren.

Dass bei gutmütigen Regelkreisen auch eventuelle Latenz, die beim Durchschleusen durch den iobroker entstehen kann kein Problem ist, ist sicherlich einleuchtend. Schwieriger wird es, wenn schneller nachgeregelt werden muss.

Kennt noch jemand den "Magnet-Schweberegler"?

https://www.mikrocontroller.net/attachment/43883/Artikel_zum_Magnet-Schweberegler.pdf

Wäre ein so zeitkritischer Regelkreis auch mit einem iobroker Regler-Adapter möglich?

[mcm1957]

@martinp
Sorry, dass kann ich dir nicht beantworten.

Die Entfernung spielt wahrscheinlich keine Rolle - wenn schon die Laufzeit des Signals am Kabel relevant wird, dann bruachen wir über Regler in Software wohl nicht sprechen. Prinzipiell ist aber ioBroker sicher nicht als Echtzeitsystem zu sehen.

[fu_zhou]

Das Verhalten von y bei Änderung von Tn bei laufendem Regler ist jetzt so, wie ich es mir gewünscht habe - danke! Die Kombinationen aus man, hold, rst, die ich jetzt mal so beim Rumspielen probiert habe, sind nachvollziehbar. @Ben1983 was meinst du?
Philosophiefrage ist folgendes Szenario: Regler auf hold, dann rst = true => y bleibt stehen, dann hold = false => rst wird jetzt ausgeführt und der Regler fängt bei 0 an bzw. mit der Kp Sprungantwort. Heißt also, solange der Regler auf hold ist, bleibt das y stehen, das zum Zeitpunkt von hold ausgegeben wurde, selbst wenn rst = true gesetzt wird. Die philosophische Frage ist jetzt: so lassen oder bei hold = true führt ein rst = true zu y = 0 (das dann stehen bleibt, weil ja hold = true). Wenn dann hold = false gesetzt wird, ist das Ergebnis das gleiche (Regler startet y zu verändern ab 0), nur sieht man durch y = 0, dass rst betätigt wurde. Der Unterschied ist der Zeitpunkt, wann y = 0 wird. Einmal bei rst = true, das andere mal bei hold = false.

Ah sehe gerade, dass das weiter oben schon diskutiert wurde, lasse es trotzdem mal stehen...

[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!