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

[mcm1957]

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

@mcm57 ich kann auch @fu_zhou verstehen.
Aber auch deinen Einwand mit Kp.
Generell hätte man die Berechnung auch geteilt aufbauen können in den P den I und den D Anteil.
Somit hätte man bspw. Den I Anteil zwar auch mit Kp *(delta/Tn) berechnen können, aber eben immer nur für den aktuellen Zyklus….
Eben IAnteil = IAnteil + Kp *(delta/Tn)
Somit wäre kein Sprung drin.

Fällt natürlich nur bei Änderungen während des Laufens auf.

Ja schon klar:
Man derzeit wird INTEGRAL(diff) / Tn gerechnet. Im Prinzip könnte man auch INTEGRAL (diff/Tn) rechnen. Solange Tn konstant ist muss da dasselbe rauskommen. Bei Änderungen von Tn wirkt es sich aus.

Werd mal drüber nachdenken. Falls wer eine "offizielle" Doku kennt wo das Verhalten dokumentiert ist bitte um Link. Im Prinzip scheint es mir aber eher so zu sein, dass das Ändern der Regelparamater bei laufendem System eher ein "unspecified" Bereich ist.

https://github.com/iobroker-community-adapters/ioBroker.pid/issues/54

McM

mcm1957 created this issue in iobroker-community-adapters/ioBroker.pid

closed [FEATURE] Evaluate change in I part calculation #54

[fu_zhou]

@mcm57

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

Ich kann deine Erwartung im Prinzip verstehen. Anderseits wird ein Ändern von kp auch einen Sprung auslösen und nicht "irgendwie gleitend" auf den neuen Wert gehen.

Bei Kp würde ich einen Sprung erwarten wg. (act-set)*Kp. Ich habe das gerade mal mit dem Regler in der S7 getestet. Da "beschleunigt" oder "bremst" der Regler die Änderung von "y" bei Veränderung von Tn ausgehend vom aktuellen Wert, ohne Sprung. Mit Sprung wird es auch schwierig, Tn durch Probieren einzustellen oder die Schritte sind so klein, dass die Sprünge vernachlässigbar sind. Ich weiß nicht wie aufwändig es wäre, das entsprechend anzupassen bzw. wie störend das aktuelle Verhalten dann in der ioBroker-Praxis ist...

[mcm1957]

@fu_zhou

Ich schaus mir an
https://github.com/iobroker-community-adapters/ioBroker.pid/issues/54

Ich werd nur ein paar Tage warten ob massive Probleme auftreten. Insbesondere das von Ben gemeldete Verhaklten von RST und HOLD muss ich mir ansehen. Das ist nicht rational erklärbar - im Moment

mcm1957 created this issue in iobroker-community-adapters/ioBroker.pid

closed [FEATURE] Evaluate change in I part calculation #54

[fu_zhou]

@mcm57 Super, vielen Dank für deine Geduld und Arbeit!

[mcm1957]

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

@mcm57 Also wenn ich hold auf true setze, dann rst auf true,
dann bekomme ich
nach 10s rst = true den doppelten Wert wie nach 5s rst = true.
Daraus schließe ich, dass dort nicht y=(act-set)*kp + off gerechnet wird, sondern noch das Tn mit rein spielt.

Sorry, du hast wieder mal recht. Da ist noch ein Wurm dirnnen.
RST sollte KEINE Neuberechnung auslösen wenn der Adapter im "fixed Intervall" Mode arbeitet oder on hold ist.

https://github.com/iobroker-community-adapters/ioBroker.pid/issues/55

mcm1957 created this issue in iobroker-community-adapters/ioBroker.pid

closed [BUG] RST should NOT trigger reculculation #55

[mcm1957]

Ich dachte eigentlich, dass ich nur mal schnell den node-pid code in einen Adapter integriere.
So kann man sich täuschen

Sorry für die immer noch vorhandenen Fehler. Und DANKE für euren Testaufwand. Ohne den würde der Adapter wohl noch viel länger fehlerhaft bleiben.

McM

P.S: Für heute bin ich zu müde um mal schnell was rauszuschießen. Wird wohl morgen od. ev. Freitag werden für die nächste Version

[Ben1983]

@mcm57 alles gut. Top Entwicklung des Adapters.
Mit dem integralanteil wäre es echt cool, wenn der immer nur den letzten Teil mit dem aktuellen Tn auf den alten Wert packt.
Das ist beim einstellen schon wesentlich besser zum Testen.

[fu_zhou]

@mcm57 hier ein Ausschnitt aus dem Quellcode vom S7-PID = der P-I-Teil, der sieht wie folgt aus:

(* read last cycle time in Microseconds *)
tx := T_PLC_US();
tc := DWORD_TO_REAL(tx - t_last);
t_last := tx;

(* calculate proportional part *)
p := KP * IN;

(* run integrator *)
i := (IN + in_last) * 5.0E-7 * KI * tc + i;
in_last := IN;

(* calculate output Y *)
Y := p + i;

Das sieht so aus, wie @Ben1983 oben schreibt: aufgeteilte Berechnung, und daher kein Sprung bei Verändern von Tn im laufenden Betrieb, oder?

[mcm1957]

@fu_zhou

Danke f.d. Beispiel. Im Prinzip hab ich es so umgesetzt.
In deinem Codebeispiel wird nur anscheinen der Mittelwert (?) der Fehlerwerte integriert - anders kann ich mir lastIn nicht erklären. Ich integriere "nur" den Fehlerwert. Glaube aber nicht, dass dies viel Unterschied im Verhalten macht, zumindest sicher nicht wenn der Fehlerwert nicht groß herumspringt.

[mcm1957]

@fu_zhou @Ben1983

Release 0.0.3-alpha.1 ist da

• geändert: Einstellung rst Zustand löst keine Neuberechnung mehr aus
• geändert: State diff zeigt nun den Fehlerwert, auch wenn sup aktiv ist
• geändert: Die Berechnung des I-Teils wurde geändert; Änderungen a, Paramater Tn wirken nur mehr auf zuküftige Anteile",

Offen ist noch die Anpassung der Formel im GUI

Schaut bitte mal ob das jetzt besser passt.

[fu_zhou]

@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.

[fu_zhou]

@mcm57 cool, schaffe ich aber erst heute Abend, auch wenn mich das aktuell mehr juckt, als die Arbeit

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