Neues Modul PID20 - Der PID-Regler

[Marcus Naumann]

Hallo John,

okay dann hast du ihn auch nach der gängigen Theorie programmiert. Mich interessiert nur, ob du der I-Anteil in deiner Reglerformel auch in %/min eingesetzt wird oder nicht? Weil ich rechne dies meist in eine Nachstellzeit um: Tn = Kp/Ki

Gruß
manavu

[Marcus Naumann]

Weil das würde dann nämlich von gängigen Einstellregeln von Ziegler & Nichols abweichen.

Gruß
manavu

[John]

Hi manavu,

du forderst mich heftig , mein Studium liegt schon einige Jahrzehnte zurück.

die massgebliche Stelle im Programm:

Code Auswählen Erweitern

  $iPortion = $iPortion + $workDelta * $hash->{helper}{factor_I};

Damit erfolgt die Integration im Takt von pidCalcInterval, steht default auf 60 Sekunden.

Das wäre noch ein Punkt den ich ggf. im Modul ändern sollte, damit die Integration unabhängig vom Scan-Intervall wird.

Ist mir schon bei der Diskussion mit cwagner aufgefallen.

John

[Marcus Naumann]

Hi John,

wollte dich nicht fordern;). Im Grunde passt das auch. Ich meine du solltest den letzten Term mit der Abtastrate  in Sekunden multiplizieren.

  $iPortion = $iPortion + $workDelta * $hash->{helper}{factor_I} * "Abtastzeit"

für den D-Anteil

DAnteil = Kd * (e-e_alt)/Abstastzeit

Somit würde das den gängigen Reglern entsprechen. So habe ich das letztens auch programmiert. Ist aber auch nur ein Vorschlag.

Gruß
manavu

[Marcus Naumann]

Mit Abtastzeit meine ich natürlich die 1/ScanRate. Das würde dann der Zeit entsprechen bis das Programm einmal abgearbeit wurde.

[Marcus Naumann]

Anbei die erste Auswertung. Habe auch ein schwingendes Verhalten feststellen können. Muss mal schauen ob ich das über die Einstellwert noch kompensieren kann.


Gruß
manavu

[John]

Hi manavu,

dein Stellausgang arbeitet am unteren Ende und nutzt nur einen sehr kleinen Bereich zum regeln.
Gerade der untere Bereich ist oft nicht linear.

Ich vermute deine Vorlauftemperatur ist zu hoch. Das wirkt wie ein hoher P-Faktor.

Gut wäre wenn sich die Ventilstellung bei Raum-Auslegungstemperatur (20 Grad) im mittleren Bereich bewegt. (30..70%)
Dann hat der Regler optimale Bedingungen seinen Job zu erledigen.

Ich hatte genau diese Problem mit meinen Max-Thermostaten.
Siehe
http://forum.fhem.de/index.php/topic,18248.msg127704.html#msg127704

John

[Marcus Naumann]

Hi John,

jep das kann natürlich sein. Ich hab eh relativ große Heizkörper wodurch ich eine geringere Übertemperatur benötige. Allerdings habe ich momentan eine Vorlauftemperatur von 45°C und das kommt mir nicht allzu groß vor. Muss auch mal die Heizkörper hydraulisch abgleichen, dann ist das vielleicht auch etwas besser.

Allerdings muss ich auch noch sagen, dass ich mit alten PID die Temperatur besser regeln konnte als jetzt. Ist der alte vom Algorithmus identisch mit dem neuen?

Gruß
manavu

[John]

hallo manavu01,

Ist der alte vom Algorithmus identisch mit dem neuen?

da ist kein Stein auf dem anderen geblieben.

siehe Verbesserungsvorschläge zum alten PID

http://forum.fhem.de/index.php/topic,15060.0.html

John

[dman]

Hallo,

hier sind 3 Beispiele für die Regelungsverläufe bei mir (PID20 regelt FHT8V an normalen Heizkörpern, Sensoren sind S300TH).

Im 1. Beispiel sieht man rechts, wie der Sollwert schön ohne Überschwingen erreicht wird. Könnte vielleicht etwas schneller dort ankommen, da muss ich noch experimentieren.
Im 2. Beispiel sieht man, dass die Temperatur schön konstant gehalten wird.
Im 3. Beispiel sieht es etwas unruhiger aus, das sind die Raumbedingungen auch etwas anders, also da gibt es externe Einflüsse. Aber es wird trotzdem ganz gut geregelt.

[John]

Hallo d-man,
besten Dank für die Rückmeldung.
wichtig für eine Beurteilung wären noch die Einstellung der P,I,D Faktoren.

Weiterhin wäre es hilfreich ,wenn du die Skalierung der rechten Temperatur-Achse veränderst, so dass man den Verlauf besser erkennen kann.

zu Beispiel 1:
  der erste Sollwertsprung um 06:30 Uhr von von 21 auf 22 Grad
      - der Anstieg dauert sehr lange, der Zielwert wird in den 2h nicht erreicht
      - das Ventil öffnet nur bis ca. 25%
     Du solltest den P-Faktor deutlich erhöhen (ggf. verdoppeln).
     Wenn das optimiert ist, kannst du den I-Anteil behandeln

zu Beispiel 2:
  Der Sollwert ändert sich nur sehr wenig, (vielleicht 0.5 Grad), das ist nicht wirkliche eine Prüfung für den PID.
  Die Ventilöffnung ist trotz der Solltemperatur von ca. 21 Grad sehr gering.


zu Beispiel 3:
  ähnliches Verhalten wie bei Beispiel 1, Sollwertsprung dauert zu lange.
  Das Ventil öffnet zwar nun deutlich mehr, aber hat immer noch eine Reserve von 50%.
  Auch hier würde ich den P-Faktor erhöhen

Generell ist die Ventilstellung bei allen 3 Kurven bei Erreichen der oberen Solltemperatur relativ niedrig.
Ich vermute mal , dass du deine Vorlauftemperatur noch reduzieren könntest bei der aktuellen Aussentemperatur.

John

[cwagner]

Moin, John,

beim Suchen nach anderen Fehlern auf meinem System fiel mir nun eine Fehlermeldung auf, die ich in den logs schon ziemlich weit zurück verfolgen kann:

Code Auswählen Erweitern

Use of uninitialized value $d in hash element at fhem.pl line 3073.
Use of uninitialized value $reading in concatenation (.) or string at ./FHEM/98_PID20.pm line 489.
Use of uninitialized value $sensor in concatenation (.) or string at ./FHEM/98_PID20.pm line 489.
Use of uninitialized value $dev in hash element at fhem.pl line 2981.

erhalte ich auf der Console nach meiner Beobachtung immer dann, wenn der measured Wert sich ändert. Das Listing dieses 1-Wire-Device:

Code Auswählen Erweitern

Internals:
   ALARM      1
   ASYNC      0
   CFGFN      ./FHEM/1wire_devices.cfg
   CHANGED   
   DEF        DS1820 787E83020800
   ERRCOUNT   0
   INTERVAL   30
   IODev      OWio1
   NAME       T_Vorlauf_FBH
   NR         63
   OW_FAMILY  10
   OW_ID      787E83020800
   PRESENT    1
   ROM_ID     10.787E83020800.65
   STATE      T: 37.5
   TYPE       OWTHERM
   Readings:
     2014-02-01 16:05:09   T_avg_day       33.4
     2014-02-01 16:05:09   T_avg_month     32.4
     2014-02-01 16:05:09   T_cum_day       1932919.41999999
     2014-02-01 16:05:09   T_cum_month     4676119.42000002
     2014-02-01 15:01:25   T_max_day       50.6
     2014-02-01 15:01:25   T_max_month     50.6
     2014-02-01 05:30:41   T_min_day       22.3
     2014-02-01 05:30:41   T_min_month     22.3
     2014-01-18 14:53:01   humidity        0
     2014-02-01 16:05:39   state           T: 37.50 °C ▾
     2014-02-01 16:05:39   temperature     37.5025
   Tempf:
     factor     1
     offset     -0.56
Attributes:
   IODev      OWio1
   event-on-change-reading state,temperature
   group      Fussbodenkreis
   interval   30
   model      DS1820
   room       Heizung
   stateFormat {"T: ".sprintf('%.1f',ReadingsVal($name,'temperature',0))}
   tempHigh   74
   tempLow    69
   tempOffset -0.56

Besonderheit der OWTHERM-Ausgabe ist, temperature im state so merkwürdig formatiert wird. Das "bügele" ich für STATE in die in Homematic-Devices übliche "T:"-Darstellung. Aber auch wenn ich stateFormat weglasse, habe ich keine Besserung. Praktisch mit jeder Messwert-Änderung kommen die zwei Fehlermeldungen.

-----
Ansonsten läuft das Modul bei mir im Mischerbetrieb zunehmend erfolgreich - dank Deiner vielen Tipps und Ratschläge. Temperaturverlauf, wenn er sich dann einmal eingeregelt hat, ist top. Ich kämpfe derzeit mit der Wiedereintrittsfähigkeit, die physische Mischerstellung bei Neustart u.ä. Ereignissen korrekt wiederherzustellen. Zweites Problem, dass ich in meinem Hilfsprogramm auffangen muss, ist die Tatsache, dass ein Vollausschlag 95 Sekunden dauert - ich der Regelpäzision zuliebe aber mit 30sec/30sec für PicCalcInterval und PicActorInterval arbeite, was ja eine Regelung alle Minute bedeutet, oder?


Herzliche Grüße

Christian

[John]

Hallo Christian,

beim Suchen nach anderen Fehlern auf meinem System fiel mir nun eine Fehlermeldung auf, die ich in den logs schon ziemlich weit zurück verfolgen kann:

Das muss ich mir noch ansehen.

Zweites Problem, dass ich in meinem Hilfsprogramm auffangen muss, ist die Tatsache, dass ein Vollausschlag 95 Sekunden dauert - ich der Regelpäzision zuliebe aber mit 30sec/30sec für PicCalcInterval und PicActorInterval arbeite, was ja eine Regelung alle Minute bedeutet, oder?

pidCalcInterval ist der Takt, in dem der Regler die Regelabweichung überprüft.
pidActorInterval ist die Mindestwartezeit für ein weitere Ausgabe am Aktor.
letztere wird aber im Takt von pidCalcInterval überprüft.

Du hast einen sehr schnellen Prozess, also rate ich dazu pidActorInterval auf 1 zu setzen, damit er mindestens im Takt von pidCalcInterval
ausgegeben wird. (Funk verwendest du offensichtlich nicht zur Ansteuerung)

John

[frank]

hallo john,

ich versuche gerade deinen regler geschickt in mein system einzubinden, bin mir aber nicht im klaren, ob es überhaupt gut funktionierieren kann.

szenario:

ich habe mir ein heizsystem mit variablem referenzraum angelegt. der raum mit dem aktuell grössten heizbedarf wird referenzraum und serviert dem heizkessel raumsollwert und raumistwert. daraus ermittelt der kessel die vorlauftemperatur. in diesem fall übernimmt der regler des kessels die temperaturregelung des aktuellen referenzraumes über die vorlauftemperatur und das zugehörige stellglied muss auf 100% öffnen.
die stellglieder der restlichen räume sollen dann mit deinem regler gesteuert werden.

die problematik ergibt sich nun beim umschalten der regler, wenn der referenzraum wechselt.

zur zeit stoppe ich deinen regler, wenn der kesselregler übernehmen soll und setze das ventil separat auf 100%. soweit ganz klar.
doch wie realisiere ich den umgekehrten fall, wenn dein regler wieder übernehmen soll?
es kann ja durchaus vorkommen, dass dein regler über mehrere stunden, vielleicht sogar tage, gestoppt war. dass würde bedeuten, dass die gespeicherte reglervergangenheit nicht mehr sinnvoll ist.
im moment nutze ich "restart 100", da das stellglied kurz vor dem umschalten auf 100 stand. macht aber irgend wie keinen sinn, wenn Tist ungefähr Tsoll entspricht. ein einfaches start macht auch nicht wirklich sinn.
wenn ich das richtig verstanden habe, ist der einzige unterschied zwischen start und restart der anfangswert von actuation. aber beide nutzen die gleiche vergangenheit. irgendwie könnte ich einen "echten" restart gebrauchen, bei dem der regler resettet wird. oder habe ich da was übersehen?

für welches szenario hast du die steuerung deines reglers (start, stop, restart) genau konzipiert? soll es dabei nur um die verhinderung der stellglied kommandos gehen? so etwa wie play, pause bei einem player? welchen unterschied bringt disable? fragen über fragen. ich hoffe du kannst mich ein wenig beraten.

gruss frank

[John]

Hallo frank,

zu Deinen Fragen:

für welches szenario hast du die steuerung deines reglers (start, stop, restart) genau konzipiert?

Ich wollte meine Fussbodenheizung regeln, bin mit dem alten PID nicht klargekommen und habe angefangen mit anderen
Usern zu diskutieren. Daraus ist PID20 entstanden.

soll es dabei nur um die verhinderung der stellglied kommandos gehen? so etwa wie play, pause bei einem player? welchen unterschied bringt disable? fragen über fragen.

stop und disable wirken identisch. "stop" ist eher dazu gedacht temporär den Regler zu deaktivieren.
Deaktivieren heisst, dass der Regler, nichts mehr rechnet, bewertet oder verstellt und keine Befehle mehr zum Stellglied schickt.

"start" bedeutet, dass der Regler mit allen vorhandenen readings seine Arbeit wieder aufnimmt.
Er nimmt keine Rücksicht darauf, wo sich das Stellglied zu diesem Zeitpunkt befindet.

"restart" arbeitet wie "start", allerdings übernimmt er "sprungfrei" die als Parameter übergebenen Position des Stellgliedes.
Damit das mathematische Modell funktioniert, muss einmalig I-Anteil so angepasst werden, dass am Reglerausgang der gewünschte
Stellwert ansteht. Damit wird der zuvor erlernte I-Anteil zugunsten einer sprungfreien Übernahme des Stellausgangs "geopfert".

Zu deinem Problem einige Überlegungen:
Zum Zeitpunkt der Raum-Umschaltung ist beim alten Raum die Position des Stellgliedes stimmig mit der Raumtemperatur.
Wenn  neue "Führungs-Raum" einen höherer Vorlauftemperatur fordert, wird es im alten "Führungsraum" zu einer Übertemperatur kommen.
Entsprechend umgekehrt im Fall einer niedrigeren Vorlauftemperatur.

Die Phase der Umschaltung wird also zu größeren Regelabweichungen führen.
Aber es scheint mir noch der konkreteste Ansatz zur Wiederaufnahme der Regelung.

Wie sind den deine Erfahrungen, wenn du  mit "restart 100" den Regler im alten Führungsraum startest ?

Am besten du stellt einen Plot rein dann können wir mehr sehen.

Ich hoffe zu änderst den Führungsraum nicht zu oft,
da sich ändernde Vorlauftemperaturen wie sich ändernde P-Faktoren auswirken.

Besteht nicht die Möglichkeit eine aussentemperatur-geführte Vorlauftemperatur vorzusehen ?

John