Test Adapter pid (pid-Regler) V1.0.x
-
-
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 -
-
@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. -
@mcm57 sagte: run / hold / man
Diese Optionen kenne ich bei Standard PID-Reglern (Gebäudeautomatisierung) nicht.
-
@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? -
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.
-
@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.
-
-
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"
-
@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.
-
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
-
-
@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?
-
-
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.
-
-
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
-
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.
-
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.
closed Buglist 0.0.2-alpha.x #30
-
@lobomau
Danke fürs Testen.
Anregungen sind immer gern sehen - abenso ist jedes Feedback ohen Problem ebenfalls sehr hilfreich. -
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...
-
@mcm57 bei run = false: Orange
bei lim = true: rot
-
@mcm57 sieht ganz gut aus.
Ich weiß zwar aktuell nicht, was man_inp oder sup sein soll. Aber ok. -
@ben1983
man_inp = Vorgabe für y wenn man = trueAus der OSCAT-Beschreibung: Mit dem Eingang SUP wird eine Rauschunterdrückung eingestellt, der Wert am Eingang SUP legt fest ab welcher Regeldifferenz der Regler einschaltet. Mit SUP wird vermieden, dass der Ausgang des Reglers dauernd schwankt. Der Wert am Eingang SUP sollte so bemessen sein, dass er das Rauschen der Regelstrecke und der Sensoren unterdrückt. Wird zum Beispiel der Eingang SUP auf 0.1 gesetzt so wird der Regler erst bei Regelabweichungen größer als 0.1 aktiv.
-
@mcm57 sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:
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)Ja klar, verstehe. Wenn das implementiert wird das schon passen!
