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

[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:

1. man = true => man_inp wird auf y geschrieben. Bei man = false macht der Regler ab man_inp weiter (ist ja das letzte y)
2. run = false => y wir gehalten. Bei run = true macht der Regler ab dem alten y weiter
3. 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 created this issue in iobroker-community-adapters/ioBroker.pid

closed Buglist 0.0.2-alpha.x #30

[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:

1. Neustart Adapterinstanz
2. set = 0, act = 0, sup = 0.2 => keine Regelabweichung, y "eingefroren" (diff = 0)
3. set = 0, act = -0.1, sup = 0.2 => keine Regelabweichung wg. sup, y "eingefroren" (diff = 0)
4. set = 0, act = -0.2, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch (diff = 0.2)
5. 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.)
6. set = 0, act = -0.3, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch, aber diff = 0.2 sollte aber 0.3 sein
7. set = 0, act = -0.4, sup = 0.2 => Regelabweichung wg. sup, y läuft hoch, diff stimmt jetzt wieder mit 0.4
8. 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.)
9. set = 0, act = 0, sup = 0.2 => keine Regelabweichung, aber y läuft weiter weil diff = 0,1, sollte aber 0 sein
10. 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...

[fu_zhou]

@mcm57 bei run = false: Orange

bei lim = true: rot

[Ben1983]

@mcm57 sieht ganz gut aus.
Ich weiß zwar aktuell nicht, was man_inp oder sup sein soll. Aber ok.

[fu_zhou]

@ben1983
man_inp = Vorgabe für y wenn man = true

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

[fu_zhou]

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

[mcm1957]

@fu_zhou
Danke. Offensichtlich hab ich ne andere Admin version die den Text nicht färbt.
Im Prinzip ist alles klar. Das rote Rufzeichen nehm ich mal raus. Orange bleibt da der Adapter in dem Zustand ja nicht läuft ist das meiner Ansicht nach OK.

https://github.com/iobroker-community-adapters/ioBroker.pid/issues/35

Welche Admin Version hast du aktiv?
Bei mir ist da nix bunt bei Admin 6.3.7 und 6.4.3.

mcm1957 created this issue in iobroker-community-adapters/ioBroker.pid

closed [Feature] remove red exclamation sign if controller has limits exceeded #35

[mcm1957]

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

@mcm57 sieht ganz gut aus.
Ich weiß zwar aktuell nicht, was man_inp oder sup sein soll. Aber ok.

man / man_inp gehören zusammen.
Aktiviert man man, wird der Wert von man_inp direkt auf y durchgereicht.

Ein Anwendungsfall wär z.B. eine (Heizungs-)Steierung bei der ein Steuerventil (z.B. 0-10V) mit Y angesteuert wird. Im Servicefall will man das Ventil auf z.B. 25% stellen - unabhängig v Temperaturen etc. Dann lkann man setzen man=true, man_inp=25.

OK das gibge auch extern zu lösen, aber wenn man das gleich im Adapter hat braucht man für diesen Fall kein zwischengeschaltetes Blockly/Javascript da VIS die States des Adapters ggF direkt ansteuern kann.

Für den normalen Reglerbetrieb gilt man=false, man_inp=irrelevant

sup stellt eine Hysterese dar die kleine Änderungen des Inputs ignoriert. Dazu gibts hier gleich noch ne Diskussion

[mcm1957]

@fu_zhou
Ok, da gibts eine Unterschiedliche Ansicht / Auffassung zu was sup tun soll.
Derzeit ist eingebaut, dass sub kleine Änderungen des Eingangs ignoriert, d.h.

if (act[t] - act[t-1]) < sup) then do_nix

Lt. deiner Beschreibung aus OSCAT soll sich sup aber auf den Wert von DIFF Beziehen, d.h. wenn die Regelabweichung < sup ist soll nix passieren, d.h.

if (set - act) < sup) then assume diff=0

OK, das kann / werd ich ändern. Durch diff=0 sollte dann auch der I Anteil gleich bleiben. Der Differenziereranteil kann sich noch ändern, da ja diff[t-1] ggf ungleich 0 war.

https://github.com/iobroker-community-adapters/ioBroker.pid/issues/32

mcm1957 created this issue in iobroker-community-adapters/ioBroker.pid

closed Parameter sup does not work as expected #32

[mcm1957]

Kleiner Überblick über aktuelle Probleme und noch anstehende Änderungen. In Klammern die jeweiligen Issuenummern zur Evidenz)

• Umordnung der States und Gruppierung in Foldern (BREAKING) (#36)
• run/hold funktioniert nicht richtig, Integralanteil läuft weiter (#30)
• man sollte implizites hold auslösen (#30)
• sup funktioniert nicht wie erwartet (#32)
• kein rotes Rufzeichen bei Limitüberschreitung (#35)
• q Flags werden teilweise falsch gesetzt (#34)
• invert Flag funktioniert nicht (#39)

[fu_zhou]

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

OK, das kann / werd ich ändern. Durch diff=0 sollte dann auch der I Anteil gleich bleiben. Der Differenziereranteil kann sich noch ändern, da ja diff[t-1] ggf ungleich 0 war.

das wäre Klasse, weil sonst kann der Istwert ja langsam weglaufen und die Regelabweichung wird immer größer, ohne dass der Regler eingreift. Deswegen ist if (set - act) < sup) then assume diff=0 das Mittel der Wahl.

Ich benutze Admin 6.4.3 mit dunklem Farbthema, aber bei deinem Screenshot oben ist C-1 auch rot, nur sehr schwer erkennbar, durch den weißen Hintergrund,

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

Orange bleibt da der Adapter in dem Zustand ja nicht läuft ist das meiner Ansicht nach OK.

Der Adapter läuft ja, nur der Regler ist mit run = false angehalten. Habe mal einen 2. Regler in der Konfig hinzugefügt. Der eine ist grün, der andere Orange => auf eine Blick erkennbar, welcher Regler arbeitet und welcher pausiert => OK.
Die Frage ist dann, ob er auch Orange wird, wenn man = true, weil da passiert ja auch erstmal nix mehr - im Gegensatz zu sup, da ist diff = 0 ja nur temporär und wenn (set - act) > sup geht es ja automatisch weiter, während run und man ja umgeschaltet werden müssen.

[mcm1957]

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

das wäre Klasse, weil sonst kann der Istwert ja langsam weglaufen und die Regelabweichung wird immer größer, ohne dass der Regler eingreift. Deswegen ist if (set - act) < sup) then assume diff=0 das Mittel der Wahl.

Nein, das nicht. Ich vergleiche den letzten ANGENOMMENEN act Wert mit dem neuen Act Wert, also bei sup =0,3

• act = 0 (Start)
• act = 0,5 -- wird angenommen, Regler regelt mit act = 0,5
• act = 0,6 -- wird ignoriert, Regler regelt mit act = 0,5 weiter
• act = 0,7 -- wird ignoriert, Regler regelt mit act = 0,5 weiter
• act = 0,8 -- wird angenommen da 0,8 - 0,5 >= 0,3; Regler regelt mit act = 0,8

Aber wie schon geschrieben ist es wahrscheinlich sinnvoller auf DIFF abzustellen, da dann auch Änderungen an set mit beachtet werden UND sich der Ausgang nicht ändert wenn diff zu gering (was ja das eigentliche Ziel) ist.

Der Adapter läuft ja, nur der Regler ist mit run = false angehalten.

Die Anzeige betrifft den einzelnen Regler innerhalb der Instanz und nicht den Adapter bzw. die Instanz des Adapters. Und der Regler läuft nach meinem Begriff nicht.

Die Frage ist dann, ob er auch Orange wird, wenn man = true, weil da passiert ja auch erstmal nix mehr

Muss ich mir ansehen ob das geht. An sich kann nur ein State verknüpft werden. Also entweder führ ich einen State HOLD ein und mach RUN einen XTRA / readonly state der die Verknüpfung von HOLD und MAN enthält oder mir fällt noch was anderes ein ( )

[Ben1983]

@fu_zhou @mcm57
Ich bin da der Meinung von @fu_zhou.
Sup sollte auf die Regelabweichung bezogen werden und nicht auf die Änderung von act.
Der Regler könnte sonst wirklich weg laufen.

[Ben1983]

@mcm57 mir fällt als erstes das hier auf:

Eine Änderung der Auswahl verändert zwar den Text, aber es wird immer noch angezeigt, dass Kp /Tn / Tv ausgewählt ist.

[Ben1983]

@mcm57
Die Tn Tv Eingaben sind für mich in der Config nicht erischtlich. (Feld zu kein)