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

fu_zhou

@mcm57 ich möchte nicht drängeln, aber gibt es schon einen Zeitraum, wann die nächste Version zum Testen bereitsteht? Ich bin bereit...

mcm1957

@fu_zhou
Neine du drängelst nicht. Ich bin dir und alle anderen SEHR dankbar für eure Zeit zum Testen.

Alle Jiras die mit to be tested markiert sind sind implementiet und in meinem fork Repo mcm1957/ioBroker.pid umgesetzt. Ich möchte / wollte die Funktionen nur noch explizit durchtesten bevor ich wieder andere beschäftige :-). Leider hat mir eine Fehler in Rules einiges an Zeit gekostet. Rules rechnet nämlich im 2 States module statt A=A-B A=B-A ... (https://github.com/ioBroker/ioBroker.javascript/issues/1291) und damit hab ich beim Test der Inverteirung natürlich kein vernünftiges Verhalten bekommen. Nur kann man da im Adaopter lange suchen :-(.

Egal - ich hoffe ich kann die nächet Version im community Bereich heute od. morgen releasen. Die wär dann zwar noch imer alpha aber vergessene Codeteile wie das invert sollte es dann nicht mehr geben. Wenn wer mag, kann er natürlich jederzeit die head von mcm1957/ioBroker.pid nehmen. Das ist meine Arbeitsversion. Da kann sich nur jederzeit was ändern.

Danke nochmals
Martin

fu_zhou

@mcm57 Ich bin grade am testen:

Die Ordnerstruktur finde ich echt gut
"hold", um den Regler zu pausieren und "run", um den aktuellen Status zu zeigen, ist super
"supr" um Rauschunterdrückung zu melden (und damit diff = 0 zu erklären trotz Regelabweichung) ist auch klasse
"hold" auf "false" und dann wieder "true" => Zyklus wird weiterhin eingehalten
bei "hold" (run = false) pausiert der Regler "echt" = im Hintergrund wird "y" nicht neu ermittelt und angesprungen, wenn "hold" = "false" gesetzt wird.

Bis jetzt funktioniert alles, echt stark!

mcm1957

@fu_zhou
Ich bin grad am release der 0.0.3-alpha.0.
Sollte nicht mehr viel Unterschied zu der mcm1957 Version sein. Ein paar Texte wurden noch korrigioert bzw. ergänzt. Das ist aber Cosmetic.

Sobald Releasebau grün ist und Testinstallation bei mir gut ging kommt Infoposting.
Gröberer Umbauten (wie zuletzt die Ordnerstruktur) möchte ich nunmehr vermeiden und zunächst nurmehr Bugs fixen.

Verlinkung zu anderen States und ev. weitere Feature werde ich zunächste zurückstellen und erst in 0.1.x einbauen. Ich möchte sobald als möglich in einen "offiziellen" beta Tests incl. Aufnahmeantrag ins Lates Repo gehen.

DANKE dir nochmals für deine Testmühe und Feedback.

mcm1957

@fu_zhou @Ben1983 @paul53

Ich habe nun die neueste und (hoffentlich) letzte ALPHA Release 0.0.3-alpha.0 erstellt.

neu: Eine optionale Ordnerstruktur für Zustände wurde implementiert.
geändert: Timer wird bei Neustart nach Pausierung nun resetted.
geändert: Werte für act und set werden nun gespeichert und beim Starten des Adapters verwendet
geändert: Zustandsänderungen mit ack=true werden gelogged
geändert: Falsche Updates beim Schreiben des act Zustands werden nun verhindert
geändert: Funktionsfehler des Invert-Flags wurden behoben
geändert: Die Fehleranzeige beim Erreichen der Limits wurde entfernt.
geändert: q-Flag-Handling wurde korrigiert
geändert: Unerwartetes Verhalten des sup-Parameters wurde behoben
geändert: Der Eingabe-Zustand 'run' wurde auf 'hold' umbenannt."

Die bekannten Probleme sollten nun behoben sein. Die gewünschte Ordnerstruktur wurde (optional und per Default) umgesetzt.

Bekannte Probleme siehe Issues im Repository.

Falls wer Zeit zum Testen hat - ich sage ganz ganz herzlich Danke wenn ihr es versucht. Falls was nicht gehtr bitte Bescheid geben. Falls alles ok scheint, bitte auch kurz sagen.

DANKE
Martin

Ben1983

@mcm57 Soweit alles gut,
ich habe nur bei etwas spielen folgendes bemerkt:
wenn man den Regler mit hold = true stoppe und dann einen
Rest mit rst = true mache, dann springt y nicht auf 0, sondern auf den neu berechneten Wert.
=> Wenn man den Regler eine gewisse Zeit angehalten hat und dann RST betätigt, springt er in die maximale Begrenzung (und man kann ihn somit im Zustand Hold nicht auf 0 zurück setzen.
(Wie kann man eigentlich den einzelnen I Anteil resetten?)
=> Das wird bei manchen Anwendungenbenötigt... ok, sind Zeitkritische, die wird man sicher nicht mit ioBroker Lösen. Von daher denke ich nicht so wichtig.

Aber könnte man beim Reset nicht das delta der Zeit auf 0 setzen, sodass der Regler wirklich bei 0 beginnt? (Wie im ersten Zyklus). Und eben wenn er auf hold = true ist auch nicht den P-Anteil ausgibt?
das Delta bzw. die Zeit würde ich während hold = true nicht weiter laufen lassen

mcm1957

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

wenn man den Regler mit hold = true stoppe und dann einen
Rest mit rst = true mache, dann springt y nicht auf 0, sondern auf den neu berechneten Wert.

RST resetted (nur) den I Anteil. Damit sollte der Adapter auf jenen Wert springen, den er ganz zu Beginn einer Berechnung hat, d.h. auf diff * kp.

=> Wenn man den Regler eine gewisse Zeit angehalten hat und dann RST betätigt, springt er in die maximale Begrenzung (und man kann ihn somit im Zustand Hold nicht auf 0 zurück setzen.

Ob der Regler angehalten ist oder nicht sollte hier eigentlich keine Rolle spielen. Bei RST sollte der Regler auf diff*kp "springen". Das kann durchaus in der Begrenzung liegen. RST resetted den I Anteil. Will man y auf null zwingen kann man MAN / MAN_INP verwenden. Beim ersten Rechenzyklus wird y aber jedenfalls auf y=(set-act)*kp + off springen.

Wir hatten ganz am Anfang schon die Diskussion dass RST eben NICHT alles auf null setzen soll, weil dann der Regler jedesmal auf 0 springt und dann sofort wieder auf den Regelwert zurück. Das ist nicht sinnvoll war die einhellige Meinung.

(Wie kann man eigentlich den einzelnen I Anteil resetten?)
=> Das wird bei manchen Anwendungenbenötigt... ok, sind Zeitkritische, die wird man sicher nicht mit ioBroker Lösen. Von daher denke ich nicht so wichtig.

Genau das macht RST. (außer es funktioniert nicht
Das kannst du kontrollieren indem nach RST y=(act-set)*kp + off sein sollte.

Aber könnte man beim Reset nicht das delta der Zeit auf 0 setzen, sodass der Regler wirklich bei 0 beginnt? (Wie im ersten Zyklus). Und eben wenn er auf hold = true ist auch nicht den P-Anteil ausgibt?

Das Delta wird beim Start auf null gesetzt damit sich kein astronomischer I Anteil (bei langer Pause) ergibt.

das Delta bzw. die Zeit würde ich während hold = true nicht weiter laufen lassen

Da die Systemzeit nicht angehalten werden kann bewirkt das Rücksetzen der Zeitdifferenz beim starten (hold geht auf false) genau das. Im Ersten Berchnungszyklus nach hold bleibt der integralanteil unverändert und der differentialanteil wird ausgeblendet. Ein theoretisch mögliche genaue Zeitberechnung (Intervall ist 10s, nach 3 sekunden wird wird pausiert, daher integral miot 3s berechnen) ist den Aufwand meiner Ansichtnach nicht Wert. Nach dem Anhalten einer Regelung muss jedenfalls mit Regeloperationen gerechnet werden und hold/run sollte ja auch nicht der Normalzustand sein.

McM

Ben1983

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

das Weiteren:
Wenn ich die hysterese (supr) auf 5 (oder sonst einen Wert setze). Worauf bezieht diese sich denn? Ich dachte auf die regelabweichung, dies ist anscheinend nicht der Fall. oder?
Sonst wäre ja hier diff nicht 0.

ich würde es wie schon mal geschrieben nicht auf eine Änderung beziehen, sondern wirklich auf die Regelabweichung, denn:

Wenn die Differenz dauerhaft sagen wir +1/2*Hysterese ist, dann kann der Stellwert und damit der Regler langsam weglaufen.
Wenn die Hysterrese sich auf die Regelabweichung bezieht, kann dies nicht passieren, da spätestens nach dem 2. zyklus die volle hysterrese erreicht wurde und die regelung wieder greift-

fu_zhou

@mcm57 wenn ich Tn bei laufendem Regler verändere, z.B. von 10s auf 2s macht y einen riesen Sprung, z.B. von 4 auf 20, also ca. um den Faktor, um den ich Tn reduziert habe. Umgedreht genauso: von 2s auf 10s kommt ein Sprung von 30 auf 6. Ist das richtig? Ich hätte eher erwartet, dass y entsprechend schneller (10s -> 2s) oder langsamer (2s -> 10s) verändert wird, aber ausgehend vom aktuellen Wert (kein Sprung).

fu_zhou

@ben1983

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

Wenn ich die hysterese (supr) auf 5 (oder sonst einen Wert setze). Worauf bezieht diese sich denn? Ich dachte auf die regelabweichung, dies ist anscheinend nicht der Fall. oder?
Sonst wäre ja hier diff nicht 0.

Das Verhalten stimmt doch: Dein set = 50, dein act = 49,43, damit ist die Regelabweichung < 5 (dein sup), damit wird diff = 0 und supr = true

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.

OK, muss ich mir ansehen
Danke f.d. genaue Beschreibugn was du tust

mcm1957

@fu_zhou
Da sich der Integralwert nicht ändert ist das lt. angegebener Formel das implementierte und zu erwartende Verhalten. Es wird der Fehlerwert integriert und geht mit dem angegebenen Faktor in das Ergebnis ein.

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.

Ben1983

@fu_zhou Du hast Recht. Da war ich wohl eben etwas durcheinander und habe es selber nicht gemerkt, dass die Regelabweichung < 5 ist.
@mcm57 ich denke was mich hier verwirrt hat ist, dass Diff als 0 angezeigt wir und die Regelabweichung ja nicht 0 ist, oder was zeigst Du als Diff an?

mcm1957

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

@ben1983

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

Wenn ich die hysterese (supr) auf 5 (oder sonst einen Wert setze). Worauf bezieht diese sich denn? Ich dachte auf die regelabweichung, dies ist anscheinend nicht der Fall. oder?
Sonst wäre ja hier diff nicht 0.

Das Verhalten stimmt doch: Dein set = 50, dein act = 49,43, damit ist die Regelabweichung < 5 (dein sup), damit wird diff = 0 und supr = true

ja
der State diff zeigt die für die Berechnung BENUTZTE Differenz an. Schlägt sup zu ist diese 0 um eben keine weitere Regelung zu bewirken. Dass sup aktiv ist wird im State supr angezeigt.

Falls es stimmiger erscheint, könnte ich auch die echte differenz ausgeben. Wär wahrscheinlich sogar sinnvoller da es ja nun den State supr gibt der die Situation supression aktiv anzeigt. (Der State kam erst später dazu). Ich werde das noch ändern.
(https://github.com/iobroker-community-adapters/ioBroker.pid/issues/53)

Ben1983

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

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

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

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

NEWS

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

Support us

503

32.4k

81.4k

1.3m