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

fu_zhou

Hut ab - alleine für die neuen Optionen in der Instanz-Konfiguration. Begebe mich mal ans Testen...

Der Adapter tut erst mal alles, wie erwartet - echt stark! Habe bisher allerdings nur mit der Kp Konfiguration gespielt und D Anteil nur auf Ist.
Mir ist aufgefallen:

Kp kann in den Objekten auch negativ angegeben werden und der Regler reagiert dann invertiert - für mich erwartet und in Ordnung. Aber: Bei negativem Kp startet der Adapter bei Instanz-Neustart nicht mehr mit entsprechendem Hinweis im Log/ Protokoll
wird "man" aktiviert, bleibt der Reglerausgang stehen, es wird nicht "man_inp" auf den Ausgang geschrieben, aber im Hintergrund ermittelt der Regler weiter einen neuen Wert für "y", auf den der Regler dann springt, sobald man "man" wieder deaktiviert - aber mit "man" wolltest du ja später erst weitermachen... aber "man" sollte im Hintergrund quasi "run" auf "false" setzen, oder?
Wäre ggf. noch eine Ebene mit Ordnern sinnvoll, um die States/ Objekte zu sortieren/ gruppieren? Die sind jetzt komplett alphabetisch sortiert. Ich würde da irgendwie an "Config static" (z.B. mit dao, cycle time, useXp, ...) - "Config dynamic" (z.B. Kp, Xp, Tn, Tv, off, sup, ...) "Input/Output" (z.B. mit act, y, ...) - "Statistic" (z.B. mit i_**, last_*, ...) denken.
Vorhin war der eine Regler, den ich konfiguriert habe in den Objekten rot mit (!) daneben, das scheint mit dem erreichen von min/max (lim: true) zusammenzuhängen. Ist das Absicht?
Bei Neustart der Adapter-Instanz bleibt das eingestellte "max" erhalten, während "min" auf 0 gesetzt wird, auch "off" wird genullt. Ich denke, es sollten sämtliche Werte bei Adapter-Neustart erhalten bleiben.
Wenn man Kp eingibt, wird ein Xp berechnet (unter Berücksichtigung von min und max) und angezeigt. Wenn man Xp eingibt, wird das entsprechende Kp dazu berechnet und der Regler macht einen Sprung basierend auf dem neuen Kp, auch wenn "UseXp" "false" ist. Ist eigentlich logisch, das mus der Anwender sicherstellen, dass bei Xp nichts reingeschrieben wird, wenn er Kp verwendet. Allerdings wird Xp nur bei Änderung von Kp ermittelt, wird nur min oder max verändert, wird Xp nicht automatisch neu ermittelt, erst wenn man Kp noch mal bestätigt. Durch die automatischen Berechnungen sieht man schön den Zusammenhang zwischen Kp, Xp und min/max.
Ist "sup" schon implementiert? Hier gibt es auch nur positive Werte, man kann aber einen negativen Wert eintragen. Ist der Betrag der Regelabweichung < als der Wert von "sup" wird aktuell trotzdem der Ausgang y verändert.

fu_zhou

beim pausieren des Reglers über "run" = "false" passiert das gleiche, wie bei "man" = "true": der Regler ermittelt im Hintergrund fortlaufend ein neues "y", auf das dann gesprungen wird, sobald "run" wieder "true" ist. Der Regler müsste auf dem letzen Wert vor dem Pausieren aufsetzen (z.B. wird die Regelabweichung bei "run" = "false" intern auf 0 gesetzt).

fu_zhou

Nochmal zur Umrechnung Xp -> Kp und umgedreht:

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

Kp = (MaxOut - MinOut) / Xp

d.h. umso größer Xp wird, umso kleiner wird Kp. Aktuell wird aber bei MaxOut von 100 und MinOut von 0 bei einem Xp von 100 ein Kp von 10000 berechnet. Hier hätte ich ein Kp von 1 erwartet (100-0)/100.

mcm1957

@fu_zhou

Kp kann in den Objekten auch negativ angegeben werden

BUG
wird "man" aktiviert, bleibt der Reglerausgang stehen, es wird nicht "man_inp" auf den Ausgang geschrieben

BUG
aber im Hintergrund ermittelt der Regler weiter einen neuen Wert für "y", auf den der Regler dann springt, sobald man "man" wieder deaktiviert

BUG - siehe Anmerkungen im nächsten Beitrag
Wäre ggf. noch eine Ebene mit Ordnern sinnvoll, um die States/ Objekte zu sortieren/ gruppieren?

FEATURE (?) - siehe Anmerkungen im nächsten Beitrag
Vorhin war der eine Regler, den ich konfiguriert habe in den Objekten rot mit (!) daneben, das scheint mit dem erreichen von min/max (lim: true) zusammenzuhängen. Ist das Absicht?

TBD - ich habe den das Instanz Error Flag mit den LIM verknüpft. Ebenso das online Flag mit RUN. Es ist also (derzeit) so programmiert. Falls das stört, bitte diskutieren. Ansonsten würd ich es so lassen. Im Limit ist der Regler ja zumindest teilweise gestört :-). Nur Orange oder Gelb hab ich nicht zur Auswahl.
Bei Neustart der Adapter-Instanz bleibt das eingestellte "max" erhalten, während "min" auf 0 gesetzt wird, auch "off" wird genullt.

BUG
Wenn man Kp eingibt, wird ein Xp berechnet (unter Berücksichtigung von min und max) und angezeigt. Wenn man Xp eingibt, wird das entsprechende Kp dazu berechnet und der Regler macht einen Sprung basierend auf dem neuen Kp, auch wenn "UseXp" "false" ist.

BUG - das sollte man anfangen können
Allerdings wird Xp nur bei Änderung von Kp ermittelt, wird nur min oder max verändert, wird Xp nicht automatisch neu ermittelt, erst wenn man Kp noch mal bestätigt.

BUG
beim pausieren des Reglers über "run" = "false" passiert das gleiche, wie bei "man" = "true"

BUG - siehe nächster Beitrag
Aktuell wird aber bei MaxOut von 100 und MinOut von 0 bei einem Xp von 100 ein Kp von 10000 berechnet. Hier hätte ich ein Kp von 1 erwartet (100-0)/100.

BUG

mcm1957

@fu_zhou

ad run / hold / man

An sich solltre die zyklische Berechnung gestoppt werden. Ich werd mir das nochmals ansehen. Was ich allerdings vermute ist, dass du einen P-Anteil aktiv hast. Und die Berechnung de Integralanteils läuft derzeit weiter, da ja die Zeit zwischen letzter Berechnung und neuer Berechnung nicht wirklich stehen bleibt (ein npm Modul zum echten Anhalten der Zeiot hab ich noch nicht gefunden :-)). Ergo, da werd ich wohl noch was einbauen müssen. Der Integralanteil sollte ja auch eingefroren werden. Oder ?
ad Folderstruktur

Da gibts wahrscheinlich unterschiedliche Ansichten.

Folder sind zuerst mal nur im Admin relevant, einer VIS oder einem SKript sind sie ziemlich sicher egal, mit der Ausnahme, dass im Skript ev. ein paar Zeichen mehr oder weniger zu tippen sind.

Im Admin bin ich nur bedingt ein Freund von Foldern, da man dann in der Übersicht immer mehrere Folder öffnen muss bis man sieht was man sehen mag. Aber im Prinzip bin ich flexibel. Ich würde hier gerne noch kurz warten was andere sagen. Im Prinzip seh ich folgende Möglichkeiten:
- IST Stand, d.h. keine Folder, Sortierung nur nach Namen
- Folder, z.B. wie von dir vorgeschlagen
- Anpassung von Namen (wobei man die über die prefixe noch reden müsste), d.h. zB.
  - config cfg_cycle, cfg_useXp, ...
  - parameter dyn_kp, dyn_tn,..
  - input/output (operational) op_act, op_y, op_lim
  - statistic s_last_*, ...

Da ein Umbenennen der Zustände - egal ob mit Foldern oder mit Namen - ein breaking change ist, möchte ich das allerdings rasch entscheiden um die Form zu wahren und vor der ersten non alpha Version fixieren.

Also an ALLE (insbesonder die fleißigen MIttester / Mitdenker @paul53 @Ben1983 ) könnt ihr dazu kurz eure Meinung sagen - auch wenn ihr im Moment ev. keine Zeit zum testen habt?

DANKE
McM1957

paul53

@mcm57 sagte: Im Limit ist der Regler ja zumindest teilweise gestört

Das sehe ich nicht so.

Zum Zusammenhang Xp / Kp / Offset:
Entweder es kann Xp eingegeben werden, dann berechnet sich daraus Kp = (max - min) / Xp und Offset = (max + min) / 2. Oder es können Kp und Offset eingegeben werden. Dann würde ich auf eine Berechnung von Xp verzichten.

paul53

@mcm57 sagte: run / hold / man

Diese Optionen kenne ich bei Standard PID-Reglern (Gebäudeautomatisierung) nicht.

Ben1983

@mcm57 hi, ich bin noch nicht zum Testen gekommen.
Würde auch erst mal warten, nicht dass ich die gleichen Dinge auffällig finde wie die Kollegen hier.
Aber:
Was ist eine wahlweise Berücksichtigung von Setpoint?

mcm1957

@ben1983

Was ist eine wahlweise Berücksichtigung von Setpoint?

An sich sollte das in der GUI direkt daneben stehen :-)

Oder anders ausgedrückt: Je nach Einstellung wird der Anteil des Differenzierers nur durch die Änderung des ACT Wertes beeinflußt oder durch die Änderung der DIFFERENZ zwischen ACT und SET. Im ersten Fall wirken sich Änderungen des Setpoints nicht auf den Differenziereranteil aus.

Diese Berechnungsvariante hat @paul53 in der ersten Diskussionrunde ins Spiel gebracht.

Bitte lass mich noch wissen wie du zum Thema STATES / FOLDERSTRUKTUR denkst. Hier hat ja @fu_zhou den Einsatz von Foldern angeregt. Das muss ich vor der ersten Beta entscheiden und würde das ungern später noch ändern.

mcm1957

@paul53
Danke für dein Feedback.

ad run / hold / man

Ok, wenn man sie nicht braucht, muss man sie ja nicht benutzen. Sie sollten jedenfalls (bei Nichtbenutzung) nicht stören. Daher seh ich keinen (zwingenden) Grund sie zu entfernen.
Im Limit ist der Regler ja zumindest teilweise gestört / Das sehe ich nicht so.

OK, da kann man drüber nachdenken. Da es keine echte Störung gibt würde ich die (rote) Rufzeichenanzeige für Overflow belassen. Echte Auswirkungen hat das nach meiner Kenntnis nicht. Wenn es aber mehrfach als störend empfunden wird, dann kann ich das auch rausnehmen. Ich würd da auf Rückmeldungen aus dem echten Beta Test warten
Zum Zusammenhang Xp / Kp / Offset:

Da der Regler intern immer mit Kp arbeitet möchte ich schon zur Kontrolle sowohl xp als auch kp verfügbar halten. Ob man Offset nun im Xp Mode mit (Max-Min)/2 fixiert oder als freie Größe belässt muss ich mir noch ansehen. Hast du wo Links auf die man verweisen kann warum das so sein sollte ?

Bitte lass mich noch wissen wie du zum Thema STATES / FOLDERSTRUKTUR denkst. Hier hat ja @fu_zhou den Einsatz von Foldern angeregt. Das muss ich vor der ersten Beta entscheiden und würde das ungern später noch ändern.

mcm1957

@fu_zhou @paul53 @Ben1983

Neue Version 0.0.2.alpha.2

geändert: die Werte von kp, xp und sup werden nun auch überprüft falls diese mittels Zuständen verändert werden
geändert: Werte von min und max werden nun auch überprüftfalls diese mittels Zuständen verändert werden
geändert: Aktivierung von man atzualisiert nun y mit aktuellem Wert von man_inp
geändert: min Wert wird nun beim Neustart der Instanz nicht neu initialisiert
geändert: Umrechnung zwischen kp und xp wurde an mehreren Stellen korrigiert
geändert: kp oder xp werden jetzt gemäß Modeauswahl schreibgeschützt"

Ben1983

@mcm57 ok.
Er hat bestimmt nen Grund dafür gehabt.
Ich persönlich habe noch keinen Fall gehabt.
Die Änderung des Setpoints hat bei einem PID Regler ja eigentlich immer ne Änderung des Inzegralanteils zur Folge, da die Regelabweichung e=Set-act sich ja ändert.

Die Idee mit den Folders finde ich gut.
Etwas strukturiert.
(Ich werde es zwar eh in alias packen, aber ist ne gute Sache).

ich habe die 0.0.2 noch nicht installiert.
Werde wohl über Ostern nicht dazu kommen.
Familie usw. ;-)

mcm1957

@ben1983 @fu_zhou @paul53

Da ich eine Tendenz zu einer Folderstruktur sehe, schlag ich hier mal was vor
Bitte um Kommentar(e), d.h. OK, anders, ger nicht gewunschen ...

cfg - statische Config, nur via GUI änderbar
- cycle
- useXp
- dao
  .
in - Regler INPUT
- act
- set
- man_inp
- man
- rst
- run
  .
out - Regler OUTPUT
- y
- diff
- lim
  .
para - Reglerparameter, via GUI und via Stest änderbar; tw berechne´t
- xp
- kp
- tn
- tv
- min
- max
- off
- sup
  .
xtra - extra Daten (statistic, imnternals, ...) - output
- i_differr
- i_sumerr
- last_delta
- last_upd
- last_upd_str

fu_zhou

@mcm57 Die Ordner-Struktur finde ich gut. Die Frage ist, ob xtra so ein guter Name ist, aber wahrscheinlich schon, da die Ordner-Sortierung nach Alphabet (ioBroker Admin) eine sinnvolle Reihenfolge gibt (die oben).

zu run / hold / man: Ich habe das aktuell ja gelöst, in dem ich den Regler "bescheisse" indem ich eine Regelabweichung von 0 vorgebe:

if getState('mqtt.0.go-eCharger.modelStatus').val == 23) { // bei Phasenumschaltung Regler pausieren
        var y = pi.Control(0); // Stellwert nicht verändern
}

Vielleicht ist das eine Idee?

Hold ist aber kein eigenes Objekt, sondern wird erreicht indem run = false gesetzt wird, oder?

mcm1957

@fu_zhou

xtra
hab ich gewählt, damit das nicht in der Mitte der Ordner liegt :-). Hast du richtig erkannt.
'stat' sollte auch gehen.
run/hold
Ja, y soll da "eingefroren bleiben. Und auch ach der Wiederfreigabe nicht springen (außer act/set/ xxx haben sich geändert
hold
ja ist kein eigenes Object sondern hold = !run. Hab ich so gemachrt, damit das "running" (connected) symbol der Instanz damit ansteuerbar ist. Ist der State inactiv (run inactiov) wird connected durchgestrichen dargestellt.

fu_zhou

Habe die neue Version installiert und bin am Testen:

man = true schreibt jetzt man_inp auf y, allerdings setzt bei rücksetzen von man (= false) der Regler nicht auf diesen Wert auf, sondern springt auf dem im Hintegrund durch die Regelabweichung weiter berechneten Wert.
bei run = false beobachte ich auch noch das Verhalten wie oben (y wird angehalten, springt aber auf den im Hintergrund ermittelten Wert wenn run = true)
sup funktioniert irgendwie nur bei Instanzstart, wird sup dann verändert, verliert es seine Funktion und der Regler arbeitet weiter, auch wenn der Betrag der Abweichung< sup ist.

Wenn ich so drüber nachdenke führen eigentlich 3 Fälle dazu, dass dem Regler eine Regelabweichung von 0 "vorgegaukelt" wird:

man = true => man_inp wird auf y geschrieben. Bei man = false macht der Regler ab man_inp weiter (ist ja das letzte y)
run = false => y wir gehalten. Bei run = true macht der Regler ab dem alten y weiter
Betrag der Regelabweichung < sup => y wir gehalten. Bei Betrag der Regelabweichung > sup macht der Regler ab dem alten y weiter

Kombination: bei aktivem sup setze ich man = true. Dann wird y = man_inp und wenn ich dann man = false setze bleibt y auf man_inp (weil letztes y) und wenn sup dann nicht mehr aktiv ist, regelt der Regler ab dem letzte y (=man_inp in diesem Fall) weiter: Das ist jetzt eher ein Testszenario als spezifisch zu programmieren ;-)

bei dao ist noch ein Schreibfehler: deriative act only (v fehlt)
bei lim: contoller mit zwei "l"

Wenn der Regler bei min/max angekommen ist (lim = true) würde ich auch keinen Fehler sehen und auf das Rot sowie (!) verzichten. Ebenso auf das Orange, wenn run = false. Orange würde ich nehmen, wenn der Regler in der Konfig nicht "Aktiviert" ist - oder ist das das Selbe?

Berechnung von Xp ist jetzt plausibel

lobomau

habe den Adapter installiert und erster Test sieht nicht so schlecht aus. kp, tn, tv hab ich nur durch Rumprobieren eingesetzt.
Ein einfaches Script beschreibt hier "actual value" mit dem Wert meines Stromzählers also Bezug/Einspeisung. Der Bezug wird von einem anderen alten Script auf 25 W geregelt; hier wäre die Idee es später komplett mit diesem PID-Regler zu machen.
Min/Max Werte für y habe ich 5 und 800 eingesetzt (in diesem Watt-Bereich regelt mein soyosource).
Differenz SOLL-IST wird immer korrekt berechnet und y nimmt zu/ab je nach pos. oder neg. Regelabweichung. So weit so gut.

mcm1957

DANKE dass du dir so rasch Zeit zum Testen nimmst.

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

man = true schreibt jetzt man_inp auf y, allerdings setzt bei rücksetzen von man (= false) der Regler nicht auf diesen Wert auf, sondern springt auf dem im Hintegrund durch die Regelabweichung weiter berechneten Wert.

Das geht m.E. nicht anders. Sobald der Regler den man Modus verläßt muß y dem entsprechen was sich aus act, sup, ... und den Paramatern ergibt. Im allgemeinen wird da immer ein Sprung passieren. Was derzeit noch nicht funktioniert ist, dass der Integralanteil nicht eingefroren wird.
(sieh issue https://github.com/iobroker-community-adapters/ioBroker.pid/issues/30)

bei run = false beobachte ich auch noch das Verhalten wie oben (y wird angehalten, springt aber auf den im Hintergrund ermittelten Wert wenn run = true)

Ja, ist noch offen - siehe oben.

sup funktioniert irgendwie nur bei Instanzstart, wird sup dann verändert, verliert es seine Funktion und der Regler arbeitet weiter, auch wenn der Betrag der Abweichung< sup ist.

OK, dass muss ich mir ansehen.

Bezüglich man/run
y ist nie ein Input und der Regler kann daher nach man=false / run = true etc. nicht "von y wegregeln". y ist das Ergebnis lt. den angegebenen Formeln, d.h. hängt primär von act - set und xp ab. Dazu kommt noch offset und integral / differentialanteil. Das bedeutet fast immer einen Sprung wenn mann man abschaltet. Wird run auf false gesetzt bleibt y stehen und sollte bei run = true nicht mehr springen als bei jedem Zeitintervall. (Das ist noch offen)

Bezüglich Farben
Wo siehst du den Regler "orange" bzw. "rot"?
Ich seh nur das "rote !" bei lim=true. Ok, das ist klar.
Aber run steuert eigentlich nur das grüne bzw graue Online Zeichen daneben.

mcm1957

@lobomau
Danke fürs Testen.
Anregungen sind immer gern sehen - abenso ist jedes Feedback ohen Problem ebenfalls sehr hilfreich.

fu_zhou

noch was beobachte ich gerade:

diff wird nicht zuverlässig berechnet, daher funktioniert auch sup nicht immer. Ich versuche das mal nachvollziehbar zu machen:

Neustart Adapterinstanz
set = 0, act = 0, sup = 0.2 => keine Regelabweichung, y "eingefroren" (diff = 0)
set = 0, act = -0.1, sup = 0.2 => keine Regelabweichung wg. sup, y "eingefroren" (diff = 0)
set = 0, act = -0.2, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch (diff = 0.2)
set = 0, act = -0.1, sup = 0.2 => eigentlich keine Regelabweichung wg. sup, aber y läuft weiter und diff = 0,2, sollte aber 0 sein (s. 3.)
set = 0, act = -0.3, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch, aber diff = 0.2 sollte aber 0.3 sein
set = 0, act = -0.4, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch, diff stimmt jetzt wieder mit 0.4
set = 0, act = -0.1, sup = 0.2 => eigentlich keine Regelabweichung wg sup, aber y läuft weiter und diff = 0,1, sollte aber 0 sein (s. 3.)
set = 0, act = 0, sup = 0.2 => keine Regelabweichung, aber y läuft weiter weil diff = 0,1, sollte aber 0 sein
act = -0.4, dann act = 0 => diff = 0.4, dann 0 => dann stimmt es wieder und man kann wieder bei Punkt 2. einsteigen und das Ganze wieder beobachten.

Jetzt raucht mir erst mal die Birne...

Community Forum

NEWS

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

Support us

669

32.4k

81.4k

1.3m