UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[fu_zhou]

@paul53 ich würde eher zu einem negativen Xp greifen, als Ist- und Sollwert zu vertauschen, das macht man aus dem von dir angeführten Grund ja lieber nicht. Ich kenne die Möglichkeit des Offsets auf den Reglerausgang eigentlich durchgängig aus der SPS-Welt - s. z.B. auch die OSCAT-PID Beschreibung oben im Link.

[paul53]

@fu_zhou sagte: aus der SPS-Welt

Ich komme aus der DDC-Welt.

[mcm1957]

@paul53 @fu_zhou

OK, dann mach ich Folgendes:
-) expliziter Schalter "invert" (und Limit Xp > 0)
-) expliziter Offset (muss ja nicht benutzt werden)

P.S. Ich hab zwar Regelungstechnik studiert - aber einerseits ist das 40 Jahre her (wobei der PID Regler damals auch schon erfunden war) und andrerseits wisst ihr Eh dass Praxis ein Studium schlägt. Und die Praxis hatte ich von Anfang an im Programmieren (Assembler Intel 8080/8087 für Messgeräte über Pascal auf VMS (Digital Equipment, dann Compaq und HP) bis zuletzt C, Perl, Linux für online Transaktionssysteme)

DANKE euch allen für euren wertvollen Input.

[fu_zhou]

@mcm57 eine Vorbelegung sämtlicher Werte wäre sinnvoll, so dass kein "Null" im Objekt steht, z.B.:
Kp= 1
Tn= 60 (Sekunden)
Tv= 0 (D-Anteil deaktiviert => zunächst nur PI-Regler)
LL: 0
LH: 100
...

[fu_zhou]

@mcm57

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

-) expliziter Schalter "invert" (und Limit Xp > 0)

Das ist eine gute Lösung finde ich, vielleicht auch als Bool Objekt? Dann könnte man z.B. ein Stellglied, das heizen und kühlen kann, in die entsprechende Betriebsart bringen (z.B. über Temperaturdifferenz innen - außen) - auch wenn das wahrscheinlich eher wenig genutzt werden wird, weil das die Geräte selbständig tun, z.B. Lüftung Sommer- vs. Winter-Betrieb: Im Winter möchte ich die Wärmerückgewinnung nutzen, um die kalte Außenluft mit der warmen Abluft vorzuwärmen und im Sommer möchte ich die warme Außenluft mit der kühleren Abluft vorkühlen.

[fu_zhou]

@paul53 @mcm57
Zum Thema Begrenzung nochmal ein Gedanke:

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

Kp = (Max-Min)/Xp = (100-0)/50 = 2
e=act-soll = 500-0 = 500
u=Kp * e (bei I und D Anteil disabled) + offset = 500*2 + 50 = 1050.

Heißt dass, dass sich der Reglerausgang (Stellwert) halbiert, wenn ich Max halbiere, z.B. durch ein Skript, auch ohne dass sich Soll oder Ist verändert? Wenn ich mir die Formeln anschaue, dann schon, weil der Regler ja zyklisch läuft. Das wäre aber kontraproduktiv, weil ich will ja nicht den Reglerausgang verändern, nur weil ich Max verändere. Daher sollte aus meiner Sicht neben Tn und Tv auch Kp angegeben werden und Kp nicht wie oben zyklisch berechnet werden. Habe das grade mal mit der S7 und dem CTRL_PID ausprobiert - da ist es so: Der Reglerausgang verändert sich nur bei Regelabweichung, nicht bei Veränderung von Min oder Max (LL und LH beim CTRL_PID). Außer Max < aktueller Reglerausgang, dann wird der Reglerausgang auf Max gesetzt.

Das ist aktuell auch mein Problem mit dem npm pi-controller: hier muss Xp angegeben werden und Kp wird wie oben berechnet. D.h. Wenn ich hier MaxOut verändere (mit pi.setOutputMax(m);) verändert sich der Reglerausgang y, selbst wenn aktuell ein stabiler Zustand erreicht ist und sich weder Soll noch Ist verändert.

[mcm1957]

@fu_zhou
Ja damit stell ich die Frage an Runde was denn nun als Parameter "üblich(er)" ist?

Xp oder Kp ?

xp = (max - min) * xp

xp geht in die Regelfunktion ein. D.h. gibt man xp an, dann Ändert min/max nichts am Ausgangssignal. Gibt man xp an, dann hat max/min direkten Einfluß auf das Ausgangssignal.

Im Prinzip würde ich eigentlich auch kp als logioscher betrachten. Aber ich bin kein Praktiker in Regelungstechnik.

Und im Prinzip bin ich wertfrei - nur beides gleichzeitig wird schwer :-)
Bitte daher um eure Meinungen, insbesondere @paul53

[paul53]

@fu_zhou sagte: Heißt dass, dass sich der Reglerausgang (Stellwert) halbiert, wenn ich Max halbiere, z.B. durch ein Skript

Ja, Min und Max sollten konstante Parameter sein wie auch Tn und Tv. Soll eine variable Max-Begrenzung erfolgen, sollte dies im Anschluss mit dem Stellsignal passieren.

[fu_zhou]

@mcm57 für mich ganz klar Kp - aus oben angeführtem Grund.

[mcm1957]

@paul53

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.

[mcm1957]

@mcm57

https://de.wikipedia.org/wiki/Regler#PID-Regler

und auch deine Formel hier (https://forum.iobroker.net/topic/64250/test-neuer-adapter-pid-pid-regler-v0-0-1-alpha-x/28) verwenden nur kp und sind damit unabhängig von min/max Werten.

Wo kommt das xp her?
Und welchen Vorteil bringt es via xp statt via kp einzustellen?

[paul53]

@mcm57 sagte Wenn ich nachher nochmals begrenze hab ich doch nur zusätzlichen Aufwand.

Eine variable Maximalbegrenzung ist keine typische Funktion eines PID-Reglers. Als Bestandteil des Reglers dürfte sie sehr selten verwendet werden. Bei Xp gibt es viele Erfahrungswerte zur Voreinstellung bevor man optimiert.

[fu_zhou]

@paul53 Mhm... das ist jetzt eine Frage der Philosophie... Selbst Tn und Tv sind in manchen Fällen dynamisch zu beschalten, weil sich die Regelstrecke im Heizfall anders verhält als im Kühlfall - gut, die Frage ist, wie relevant das im Smarthome-Umfeld ist, aber die Möglichkeit zu haben, schadet ja nicht.

[paul53]

@fu_zhou sagte: die Möglichkeit zu haben, schadet ja nicht.

Viele Möglichkeiten führen zu vielen Fragen unerfahrener Anwender.

[fu_zhou]

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

[fu_zhou]

@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" ;-)

[Ben1983]

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

@paul53

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.

[Ben1983]

@mcm57 gibt es schon Änderungen, oder ist die erste Version noch aktuell?

[mcm1957]

@ben1983
Neuer Version ist in Arbeit. Ich geb Bescheid wenn was auf Github zum Testen kommt.

[mcm1957]

@ben1983 @paul53

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 Umsetzen

Kp / Tn / Tv System als Default
Xp / Tn / Tv System als wählbare Option - aber nur auf Instanzebene umschaltbar, nicht für den einelnen Regler

Min/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.