Test Adapter pid (pid-Regler) V1.0.x
-
@fu_zhou sagte: Mit Min = -100 und Max = 0 bekommt man quasi auch eine Invertierung hin, oder?
Nein, nur eine Verschiebung des Ausgangs.
@fu_zhou sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:
Was passiert bei -100 für Min und +100 für Max? Startet der Regler dann in der Mitte, also bei 0?
Ja.
@fu_zhou sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:
Der Regler muss, wenn er erstmals startet, immer mit einem Reglerausgang = 0 starten
Weshalb? Ein Regler startet mit dem Wert, den ein P-Regler liefern würde. Der I-Anteil startet mit 0.
-
@paul53 sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:
Weshalb? Ein Regler startet mit dem Wert, den ein P-Regler liefern würde.
Ich glaube, wir meinen das Selbe: Der Regler wird freigegeben (hier: die Adapter-Instanz wird gestartet und der Regler ist mit "Automatischer Start" = 1 parametriert) und die erste Reaktion ist dann die Antwort des P-Anteils auf Änderung von Soll- oder Istwert aber ab 0, nicht ab Min oder dem Mittelwert zwischen Min und Max. Ein Stoppen des Reglers (z.B. über die Instanz) lässt den Regler wieder bei 0 starten, während ein HOLD nur die Neuberechnung des Ausgangs pausiert und wenn HOLD wieder aufgehoben wird, macht der Regler da weiter, wo er stand.
-
@mcm57
@mcm57 sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:
P.S. Über eine Verknüfpung mit fremden States als input / output denk ich nach - aber erst für V2.
Das ist ein gutes Feature, finde ich, spart dann die Aktualisierung des Objektes über z.B. Blockly.
-
@mcm57 falls ich Verwirrung gestiftet habe mit "Regler startet bei 0": Das passiert so schon in der alpha.2. Wenn die Instanz gestoppt und wieder gestartet wird, werden alle Werte auf Null / 0 gesetzt und von da geht es dann wieder los.
-
@fu_zhou
Min und Max werden nicht aktiv begrenzt. JS Number-Range sollte reichen
0 / 100 sind nur defaults falls nichts (sinnvolles) angegeben wird.Regler startet immer mit dem P Anteil (act - set)*kpI + offset, oder anders gesagt Integralsummierer ist beim ersten Durchlauf 0, diffenrenzierer detto. Aber ich nehme mal an, das meinst du auch so. Ein expliziter "0" Startwert wäre extra Aufwand und durch den zwangsweise nachfolgenden Sprung um nichts sinnvoller als ein erster Berechneter Wert
Hold suspendiert nur die Berechnungen, resetted aber nicht
Reset setzt Integralteil retour
Instanz stoppen / restarten sollte (bei unveränderten Paramatern) analog wie reset sein, d.h. Integralteil wird resetted. Hier einen extra Merker einzuführen wär aufwandig und der Restart eines "echten Regler" (Strom aus/ein) würde auch keine Integralteile speichern.
-
@mcm57 einwandfrei!
-
Ich hab eine neue Version 0.0.2-alpha.1 erstellt.
Was ist neu?
-) wahlweise xp/tn/tv oder kp/tn/tv Konfiguration
-) wahlweise Berücksichtigung von setpoint beim Differenzialanteil
-) alle Parameter ausgenommen cycle time alternativ von gui oder statesWenn wer Lust hat, bitte Testen.
Meinerseits ist die Testtiefe noch sehr gering - das geb ich offen zu. Auf Grund der regen Diskussion letzte Woche, möchte ich allerdings es auch euch so früh wie möglich anbieten zu testen.
Für jedes Feedback bin ich dankbar.
McM
P.S: Doku ist noch nicht aktualisisiert, gui sollte aber selbsterklärend sein,
-
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.
-
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).
-
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.
-
-
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
-
-
-
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
-
