Ausgangs Auflösung PID Regler

[Farbe]

Hallo Leute,

ich probier hier grade den Heizblock einer Nebelmaschine auf Temperatur zu bekommen.
Die Schaltung ist recht einfach:

Ein ATmega kontrolliert 2 Mosfets, an beiden Fets ist je eine Heizung angeschlossen.
Als Eingang dient ein PT1000 mit Op der den ADC mit 0-5V befeuert.
Die Auflösung ist hier bei 0.3682 Counts / °C (ohne Oversampeling)

Die beiden Pins der Mosfets können kein Hardware PWM. Die Last ist thermisch eh Träge, daher ist das wohl egal.

Das ganze läuft auf 18650 Akkus. (auch) Deswegen sind beide Heizungen einzeln Steuerbar, damit kann ich bei leerer werdendem Akku (oder hohem Innenwiderstand) mit nur 50% Heizleistung heizen. Da oft nur 50% Heizleistung nötig sind, erhöht das auch die Effizienz / Batterielaufzeit (I²R Verluste).

Erst hatte ich einen einfachen 3 Punktregler Implementiert -> funktioniert ok.
Ich dachte ich kann das verhalten noch verbessern indem ich auf PID umstelle.

Den Ausgangswert vom PID Regler hab ich deswegen auf 0-2 begrenzt.
Stufe 0 ist dann 0% Heizleistung
1 = Eine Heizung aktiv
2 = Beide Heizungen an

Im falle des leeren Akkus hätte ich dann einfach den Ausgangswert des PID -1 gerechnet und hätte somit nur maximal 50% Heizleistung gehabt.
Zusätzlich würd ich später gerne Feedforward einbauen und den Ausgangswert noch mit der Pumpenleistung verkuppeln. Dadurch kann ich dann "vorheizen" wenn durch hohe Pumpenleistung die Blocktemperatur sinken würde.

Leider regelt das total beschissen.
Ich hatte D erstmal ignoriert, nur P benutzt und dann I hinzugefügt. Irgendwie klappt das aber nur schlecht.

Die Regelstrecke ist wahrscheinlich PT2. Ein wenig Verzögerung bevor beim Heizen die Temperatur steigt dann aber nähert sie sich asymptotisch einer End Temperatur.

Mich würde jetzt interessieren wieviel Auflösung der PID Regler am Ausgang braucht um vernünftig zu funktionieren.
Es gibt ja genug PID Regler mit Relais Ausgang. Die implementieren aber (laut Internet) alle Dutycyle Regelung. -> Langsames PWM.

Das kann ich ohne Probleme in Software machen. Ich würde dann 0-50% mit der einen Heizung abdecken und für alles drüber die 2. Heizung hinzunehmen.

Die Frage ist: Wieviel Auflösung brauch ich da?
Oder hab ich nur die PID Werte verkurbelt und ich sollte mal die Sprungantwort messen?

Würdet ihr das anders lösen?

Lg
Farbe

[Fritzler]

Der PID brauch schon etwas Auflösung für sein Feedback, sonst wirds eben Mist.

Aber was hindert dich denn daran dem PID wieder 8Bit Ausgangswerte zu verpassen und danach bei diversen Ausgangswerten auf 0-2 zu mappen?

Beispiel:
PID 0 bis 100 -> 0
PID 101 bis 200 -> 1
PID 200+ -> 2

Aber auch mit Software PWM lassen sich locker 6Bit erreichen.

[Farbe]

PID 0 bis 100 -> 0
PID 101 bis 200 -> 1
PID 200+ -> 2

Sollte das nicht aufs selbe raus kommen?
Bei nur P=1 und fiktivem Error = 200 wäre der Heizungszustand dann gleich wie mit P=0,01 und E = 200.

Jetzt hab ich ja "schon" 1,5 bit. Ich hätte erwartet das das mit den richtigen PID Werten auch reichen könnte.
Meinst du 6 bit reichen? Ich bin mir nicht sicher mit welche Frequenz ich dann das Soft PWM fahren sollte.
Schneller sollte prinzipiell bessere Regelung bedeuten, gleichzeitig würd ich aber (reines Bauchgefühl) lieber weniger schalten wollen.

Ich muss da sowieso schon rum Rechnen um den Akkuzustand einigermaßen genau zu messen (trotz V-drop in der Zuleitung+Akku).
Aktuell hab ich da den Widerstand ausgemessen und verrechne ADC wert (Akkuspannung) damit.
Ich hatte überlegt immer die Heizung zu deaktivieren um die Akkuspannung genauer zu messen, Leider brauchen die Akkus recht lang bis die Spannung nach Belastung wieder steigt.

[Fritzler]

Ich hab jetzt eher verstanden, dass der Regler selber austickt und nicht die ganze Regelstrecke.
Daher die Idee mit ner höheren Auflösung fürs interne Feedback des Reglers undnur nach außen hin runterschrauben.

[Farbe]

Da fehlt mir jetzt das know how. Ich kann nicht genau sagen ob der Regler nicht passt oder alles inklusive Strecke.

Ich hab festgestellt das ich egal mit welchen (nur) P Werten immer Schwingungen habe. Theoretisch sollten bei kleinen P werten ja keine Schwingungen mehr auftreten.
Auch mit zusätzlichem I werden die Schwingungen nur schlimmer.

Warscheinlich liegt das aber an der zu geringen Auflösung der Heizleistung. Die Thermische Masse der Heizelement und der Widerstand zum Block sind so hoch das es erst spät zu einer Reaktion am Sensor kommt. Wenn da was messbar ist, ists schon zuspät und zuviel Energie in den Heizelementen gespeichert. -> Harter Overshoot

[Fritzler]

Wie oft wird die Regelschleifenfunktion denn aufgerufen?
1x Sek wär vllt sogar schon zu oft, wenns wirklich so träge is.

[Farbe]

Ich schätze ich bin so bei unter 50ms.
Da sind mehrere Interrupts und anderer code dazwischen.
Für I und D rechne ich dann mit der Zeit zwischen den Wiederholungen, daher sollte die exakte Zeit nicht so eine große Rolle spielen.

Ich war der Meinung das öfters ausführen vom Loop eher besser als schlechter ist. Immerhin würde künstliches verlangsamen zu trägerer Regler Response führen.
Extrembeispiel: Loop jede minute einmal. Also kann nur jede Minute der soll Heizwert geändert werden. 1Min Vollgas Heizen wäre aber schon Kernschmelze. -> Regeln unmöglich.

Die I und D Werte müssen natürlich zum loop passen, wenn sich die zeit ändert, müssen auch die Werte angepasst sein.

Der Block ist in ca 3-4 min (je nach Akkuspannung) von Raumtemperatur auf 280°C.
Von Heizung an bis Sensorwert Änderung vergehen ca 4-5s.
Um mal eine Vorstellung der Zeitkonstanten zu haben.

Ich hoffe das kann ich mit HT Wärmeleitpaste (woher) und/oder mit Wasserglas eingeklebten Heizelementen Verbessen. Die Bohrung hat keine gute Oberfläche, da ist viel Luft dazwischen. Ich denke auffüllen mit Ofenschnurkleber um die Luft raus zu bringen sollte schon helfen. Das will ich aber erst bei fertigem Gehäuse machen.

[ferdimh]

Generell funktioniert ein PID-Regler erstmal analog und in einem LTI-System (also Linear und zeitinvariant). Wenn wir von diesen Idealen abweichen, funktioniert das Ding mindestens in der Theorie nicht mehr. In der Praxis verträgt das Ganze einige Sauerei, aber 3 Stufen ist echt etwas sehr wenig.
Ich behaupte, wenn man dem Ganzen noch etwas D Anteil gibt, wirds was (einfach weil man damit mehr Rauschen einfängt, das die Stufen verwischt). Alternativ direkt Rauschen oder Dreieck zumischen...

[Alexander470815]

Hast du denn ein Anti Windup + Winddown eingebaut?
Ansonsten macht der I-Anteil was er will und sorgt nur für Schwingungen.
Selbst wenn das keine Hardware PWM Pins sind kann man mit einem Timer ja eine mittelmäßige PWM damit implementieren.
Den Regler auf jeden Fall zu festen Zeiten ausführen nicht einfach so im normalen Programmablauf, alle Zeitvarianten Reglerteile werden sonst beeinflusst sobald man was am Programm ändert.
Die Auflösung der Temperaturmessung ist schon ziemlich lausig, fast 2,7°C je Count da würde ich auch etwas nachbessern.
Entweder einen externen ADC verwenden oder den Messbereich auf den interessanten Bereich entsprechend skalieren.

[Farbe]

D hat keine starke Besserung gebracht. Ich probiere grad mit Software PWM und 50 Stufen rum.
Damit bin ich bei ca 2,5s oder 0,4Hz PWM und nicht ganz "5,5 Bit".

Das macht den Regler sogar mit nur P direkt mal brauchbar.
Etwas I und schon hält das stabil seine Temperatur ohne mit beiden Heizern nachzuheizen.

Feedforward funktioniert auch gut. Ich rechne einfach die angeforderte Nebelmenge Proportional auf den Ausgang des Temperatur PID drauf.

Gut dann werd ich das wohl so lassen und die Werte tunen wenn das mit Steinwolle und eingeklebten Heizelementen im Gehäuse sitzt.


@Alexander:
Die Auflösung hab ich falschrum angegeben, ich meinte 0,3682°C / Count.

Antiwindup/down ist drin.

Regler zu festen Zeiten ausführen ist nicht unbedingt nötig. Man kann auch die zwischen aufrufen vergangene Zeit mitschreiben und in I und D einrechnen:

ala:

Code: Alles auswählen

now = millis();						                       //set current time
unsigned long TimeDiff = now - before;                                         //calculate time difference
iErrorTemp += TempDiff * TimeDiff;                                             //I term, gets integrated
PIDoutputTemp = (TempKp * TempDiff) + (TempKi * iErrorTemp);                   //calculate PID output
now = before;  								       //safe last time

Dann kann man die Timer interrupts für andere Sachen verwenden.



Danke
lg Farbe

[berlinerbaer]

Was hier diskutiert wird, liegt weit jenseits dessen, was ich nachvollziehen könnte.

Aber die Kollegen, die in PID reingefallen sind, als sie noch klein waren, würden sich wahrscheinlich das komplette Code-Segment, um das es hier geht, wünschen.

So können dann sowohl Formel- als auch Implementations-Probleme diagnostiziert werden.