Test Adapter pid (pid-Regler) V1.0.x
-
@paul53 Aber Kp scheint mir für den unerfahrenen wie erfahrenen Anwender nachvollziehbarer, weil das ändern von Min und Max keinen Sprung am Reglerausgang verursacht. Und selbst wenn Min und Max mit statischen Werten versehen wird, wird ja die Funktionalität des Reglers durch Kp anstatt Xp nicht beeinträchtigt.
-
@paul53 sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:
Soll eine variable Max-Begrenzung erfolgen, sollte dies im Anschluss mit dem Stellsignal passieren.
Wenn der Regler Max bei 100% hat und ich das Stellsignal bei 50% begrenze, läuft der Regler ja bei entsprechender Regelabweichung weiter Richtung 100%. Dieses "Überschießen" muss ja wieder abgebaut werden, wenn sich das Vorzeichen der Regelabweichung ändert, was ja dauern kann (Wind-Up). Außer ich halte den Regler an, wenn der Ausgang > Begrenzung Stellsignal ist, sonst weiß der Regler ja nix von der Stellgliedbegrenzung = zusätzlicher Aufwand. Vielleicht sollte der Adaptername präzisiert werden: "PID-Regler mit Stellsignalaufbereitung"
-
@mcm57 sagte in Test neuer Adapter pid (pid-Regler) V0.0.1-alpha.x:
Welchen Vorteil bringt es min / max hier zwingend als fixen Regelparameter zu sehen?
Wenn ich nachher nochmals begrenze hab ich doch nur zusätzlichen Aufwand. Und da xp in kp leicht umrechenbar ist und min / max sonst keinen Einfluß auf die Regelung haben, seh ich da wenig Vorteile.Also in der Praxis möchte man bspw. bei Tests den Max oder Minwert verändern und wenn der Regler dann nicht schon in der Begrenzung ist, sollte sich definitiv nicht die Stellgröße davon beeinflussen lassen.
Max und Min sollten immer als letzte Begrenzung einspringen. nicht schon in der grundlegenden Berechnung. -
@mcm57 gibt es schon Änderungen, oder ist die erste Version noch aktuell?
-
@ben1983
Neuer Version ist in Arbeit. Ich geb Bescheid wenn was auf Github zum Testen kommt. -
Ok, es gibt bezüglich xp/kp verscheidene Meinungen und Arbeitsansätze.
Bezüglich Tn7Tv scheint Einigkeit zu herrschen.Da ich es immer allen Recht machen will
werde ich jetzt mal folgendes UmsetzenKp / Tn / Tv System als Default
Xp / Tn / Tv System als wählbare Option - aber nur auf Instanzebene umschaltbar, nicht für den einelnen ReglerMin/Max werden zwingende Parameter mit Default 0 / 100
Fast alle Reglerparameter werden im ersten Ansatz via GUI eingestellt. Die Paramater stehen auch als States RO) zur Verfügung. Optional wird die Einstellung via States (RW) umgesetzt - bei Aktivierung ist die Einstellung via GUI ausgeblendet.
Ausnahme ist die Zykluszeit des Reglers. Die wird nur via GUI einstellbar bleiben. Ich sehe auch keinen technischen Grund diese im laufenden Betrieb zu ändern. Hier wird man ja meist eine Zeit wählen die rasch genug für das System ist aber nicht unnötig den Rechner belastet.
McM
P.S. Über eine Verknüfpung mit fremden States als input / output denk ich nach - aber erst für V2.
Und ja was den Zeitrahmen betrifft:
Hoffe am Wochenende zum Test einladen zu können.
Hab grad aktuellen Fehler im envertech-pv Adapter zu beheben. Das er schon weiter im Testing ist, hat das im Moment prio. Sollte aber heute erledigt sein. -
wobei man Min auch < 0 wählen können sollte, während du Kp und Xp > 0 machen möchtest aber einen Invertiereingang zur Verfügung stellst. Was passiert eigentlich, wenn man Min auf -100 setzt und Max auf 0? Startet der Regler dann bei -100, also bei Min? Was passiert bei -100 für Min und +100 für Max? Startet der Regler dann in der Mitte, also bei 0? Der Regler muss, wenn er erstmals startet, immer mit einem Reglerausgang = 0 starten, also ohne Ansteuerung eines Stellglieds, unabhängig, wie die Grenzen eingestellt sind. Ich denke, das ist schon so gelöst.Mit Min = -100 und Max = 0 bekommt man quasi auch eine Invertierung hin, oder?
-
@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.
