Gast
#690099
suche ein fertiges pid.c file! kennt ihr etwas, das man irgendwo herunterladen kann?
|
Anzeige
|
suche fertiger PID-regler
Gast
#690099
suche ein fertiges pid.c file! kennt ihr etwas, das man irgendwo herunterladen kann?
Gast
#690106
Das wird dir höchstwahrscheinlich nicht viel bringen, kommt darauf an was für Eingangs- und Ausgangssignale du hast. PWM? Analog? Wieviel bit? AD/DA-Wandler per I²c, SPI, Parallel? Mit der Berechnung der Stellgröße könnte ich aushelfen, den Rest musst du schon selbstanpassen. In diesem Fall mit Resourcen 'geaast' (double-Variablen), Abtastung alle 20ms
e => Regelabweichung w => Sollwert x => Istwert y => Stellgröße Kp => Proportionalverstärkung I => Integralverstärkung D => Differentialverstärkung Der Schnipsel ist für die Ausgabe über 10-bit-PWM geschrieben und funktioniert prima. Wo ist denn beim D-Anteil die Differenz? Es sollte m.E. heissen ealt2 = e - ealt; // Differenz der Regelabweichungen Sonst wird der D-Anteil ja nicht 0 bei konstantem e. EDIT Und beim Integral ist ja eine Aufsummierung der delta e notwendig.
Gast
#690134
ealt und ealt2 werden mit den jeweiligen Differential- und Integralverstärkungen multipliziert, das Ganze bezieht sich jeweils nur auf die letzten zwei Messwerte. Der D-Anteil ist auch niemals 0, nur wenn die Regelabweichung über längere Zeit genau null ist. Dann erklär mir doch bitte einmal wie der Term (D*ealt2) zu Null werden soll, da ealt2 ja immer die zweitletzte Regelabweichng ist.
Gast
#690147
D*ealt2 wird niemals null, nur wenn der Sollwert null ist. Wie soll denn ein Motor/Lüfter/Pumpe o.Ä. laufen, wenn keine Ansteuerung erfolgt? Eine gewisse Stellgröße braucht jedes Stellglied, um einen Sollwert zu halten. Die Stellgröße y setzt sich ja aus den drei Anteilen zusammen.
Gast
#690152
Ach ja: die Quelle von dat janze: http://www.roboternetz.de/wissen/index.php/Regelungstechnik#Digitaler_Regler Danke für den Quellenhinweis, nur tauchen die dort genannten Rechenschritte esum = esum + e y = Kp * e + Ki Ta esum + Kd * (e – ealt)/Ta ealt = e nur bruchstückhaft und verstümmelt in dem Programm im ersten Post auf. EDIT Ich meinte natürlich im ersten Antwortpost. Also vor geraumer Zeit habe ich hier ein wenig dazu erklärt. Habe die Beiträge oben kurz überflogen. Ich glaube auch, dass der Quelltext oben nicht ganz richtig ist. Also hier ersteinmal für die Interessierten... Beitrag "Re: PID- Regler"
Gast
#690193
Ich denke, wenn man das Thema PID Regler nicht gerafft hat, sollte man's eh seinlassen. Und wenn man's gerafft hat, sind die paar Zeilen in ein paar Minuten geschrieben.
Gast
#690540
Und ich denke, dass jeder einen PID-Regler einsetzen kann, ganz gleich ob er ihn verstanden hat oder nicht. Ist wie beim Autofahren, das kann auch jeder...
Gast
#690639
@ Starter: Ich habe mir elaubt, den Code vom obigen Antwortposting anzupassen:
mit Ta = 0.02 (20ms) Kp = 18 I = 16 D = 0.05 regelt mein Lüfter sauber, schnell und ruhig, ohne großes Zappeln der Stellgröße. Ich bitte um Korrektur, falls ich auf die Schnelle was vergessen habe! Also wieso der Double Datentyp? Braucht meiner Meinung nach einfach zu viel Rechenleistung!! Da ist man mit Int auch leicht bedient! Ausserdem würde ich für den I-Anteil eine Anti-Windup Maßnahme setzen!
Gast
#691127
Für die Regelung einer Lüfterdrehzahl kann man auf den D-Anteil locker verzichten, das brauchts nur bei dynamischen Vorgängen wie Positions- oder Lageregelung mit Motoren.
Gast
#691149
@ JÜrgen G.: Stimmt schon mit den doubles. Habe ich von oben übernommen, da es nicht auf die Rechenleistung ankommt (16MHz, mega32) kann ich die schon nehmen. Bei int muss man die Überläufe abfangen (vermeiden), da kommt dann auch noch Rechenleistung dazu. Was meinst du mit Anti-Windup-Maßnahme? Kannst du das Beispiel damit ausstatten? @ Dieter Werner: Haste Recht. Ich habe grade einen Lüfter mit Reflexkoppler da gehabt, darum habe ich den benutzt. Den D-Anteil kann man problemlos weglassen.
Gast
#691174
OK, hab selber mal gegoogelt. Wird wohl auf AWR (Anti-Windup-Reset) 'rauslaufen. Werde mich mal dransetzen. Hier noch ein recht übersichtlicher Link zum Thema: http://www.energietechnik.fh-dortmund.de/personen/walter/walter/mikrocontroller_infos/Regler_und_Optimierung.htm Anti Windup meint eigentlich nur den I-Anteil "einfrieren" wenn er über die Aussteuerungsgrenzen des Reglers kommt. Ich hab mir die Website durchgelesen -> kommt auf AWR hin! Das Problem ohne AWR: Der I-Anteil integriert immer weiter auf, auch wenn der Regler auf Anschlag steht, bis das der Datentyp erschöpft ist. Wenn jetzt allerdings eine Änderung im System ist, muss der ganze I-Anteil wieder runter gerackert werden, bis das er überhaupt mal zu Aussteuerungsgrenze kommt und dann erst für den Ausgang wirksam zu sinken beginnt... http://virtual.cvut.cz/dynlabmodules/ihtml/dynlabmodules/syscontrol/img1963.gif kleine Demonstration was ohne WindUp-Maßnahme sein kann. Bei dem obigen Source wurde zwar der gesamte Ausgang begrenzt allerdings der I-Anteil nicht "vereist" ^^
Gast
#691267
Wie sollte man dann den Sourcecode ändern, um den I-Anteil einzufrieren?
Gast
#691270
Na, sobald das Ausgangssignal, aka Stellgroesse, an das Limit kommt, wird nicht mehr weiter integriert. Nixvielwissen wrote:
> Wie sollte man dann den Sourcecode ändern, um den I-Anteil einzufrieren?
Schon mal C programmiert?
Gast
#691568
Itemp muss zu Anfang natürlich mit dem Wert von I initialisiert werden. Sollte das Problem beheben, oder?
Gast
#691576
Upps.. so natürlich nicht!
So wir deher 'n Schuh draus. ;)
Gast
#691593
OK, hab's getestet. So geht's nicht. Werde weitertesten. Meine Meinung wär ja sowieso die einzelnen Elemente einzeln zu errechnen und dann zu addieren! So kann man sich die Einzelnen Begrenzungen besser ansehen & Maßnahmen setzen! Ich such ma Quellcode... Vllt liegt irgendwo einer rum... EDIT: http://www.mstarlabs.com/apeng/techniques/pidsoftw.html Hier ist der Algo in eine Klasse gepackt... ein wenig umschreiben und dann geht...
Gast
#691614
Ok, ich habe hier die Aufintegration der Regelabweichung bei übersteuerten Stellglied eingefroren. Fonktioniert auch soweit ...
Die einzelnen Anteile getrennt zu berechnen ist sicher die bessere Lösung.
Gast
#691623
So jetzt mal ein positives Ergebnis:
Hab's getestet, funktioniert prima! :)
So falls Fehler drinne sind melden ^^ Habs nur ein wenig leichter gemacht... In Bezug auf Aufteilung... Vllt optimier ich den Code auch noch ein wenig... EDIT: @THM: Wenn du wie e Begrenzung durch y machst, kann der I-Anteil nicht wirken, während der D-Anteil voll aufdreht... Deswegen NUR das integral begrenzen ^^
Gast
#691640
Ich habe bei übersteuertem Stellglied nur esum eingefroren. Dadurch kann nicht mehr integriert werden. Die anderen Parameter bleiben davon unberührt. Ich hab's auf meiner Hardware laufen, der Unterschied zu vorher ist Welten besser! :) THM wrote: > Ich hab's auf meiner Hardware laufen, der Unterschied zu vorher ist > Welten besser! :) Immer gern xP WENN REGELEN dann RICHTIG ^_^ So aber nun zur Optimierung... Die Datentypen gefallen mir nicht wirklich... Ich hab doch nur einen 10bit AD-Wandler also zurück zu signed INT (16bit)
Gast
#691647
>Die Datentypen gefallen mir nicht
Jo, mir auch nicht! ;) Das kommt als nächstes.
Zur Visualisierung mal den Unterschied des Regelverhaltens.
In diesem Bild OHNE anti-Windup.
Grün => Stellgröße
Rot => Sollwert (70 Hz)
Weiß => Istwert
Der Lüfter gibt eine Frequenz von 0 bis max 140 Hz zurück
Gast
#691648
Und hier MIT anti-Windup.
Gast
#691649
Achso, zur Erklärung: Ich ahbe den Lüfter für ca. 2s angehalten und wieder losgelassen. Im Bild mit anti-Windup sieht man, dass der 1. Überschwinger deutlich kleiner ist. Ohne Anti-Windup wird er umso größer, je länger ich den Lüfter anhalte.
Gast
#691687
Sieht doch schon besser aus ;) nur glaube ich dass
nicht funtioniert, da sonst die nachfolgende Begrenzung der Stellgöße diese Bedingung immer erfüllt. Besser wäre
oder hast du's schon ausprobiert?
Gast
#691702
> (unsigned int) y = prop + integ + diff; // Ausgangsstellgröße
Sorry, müsste das nicht
y = (unsigned int)(prop + integ + diff);
heissen ?
Ich lerne gerne dazu....
Gruß Sven
Sven wrote: >> (unsigned int) y = prop + integ + diff; // Ausgangsstellgröße > > Sorry, müsste das nicht > > y = (unsigned int)(prop + integ + diff); > > heissen ? > > Ich lerne gerne dazu.... > > Gruß Sven sorry... stimmt... wollen ja ANSI C proggen... geht nur in C++ !!! @THM: Das stimmt schon so... Ich muss ja das ganze "Spektrum" vom I-Anteil ausnützen können... und ich fange mit 0 an -> also integ<=0 Ich probiere nicht aus, weil ich keinen µC grad bei der Hand hab -> muss ja so auch gehn ^^
Gast
#691718
>Ich probiere nicht aus, weil ich keinen µC grad bei der Hand hab
Aber ich! :)
Mit größer-gleich geht's nicht. Mit größer schon.
Das Problem ist, wie erkenne ich ob der Ausgang übersteuert ist (z.B.
1028) oder ob er bei genau 1023 ist. Das geht nur, wenn ich ein Bit
abziehe. Darum der 'größer', bzw. 'kleiner'-Verleich anstatt >=, bzw <=.
Wie iniitierst du denn das ganze? integ muss 0 gesetzt werden sonst nimmt das einen bullsh** an... Also es muss bei 0 genauso funktionieren deshalb ja integ<=0 Ja, also probiern hat seinen Wert ^^ Bin nich zuhause - also µC-los heul
Gast
#691895
>Wie iniitierst du denn das ganze?
Kp = 18;
I = 12;
D = 0;
w = 50;
Den ganzen Rest mit 0.
Also esum ist ja das Element, das integriert wird. Wenn ich dieses
einfriere, also den Wert bei überschreiten der Übersteuergrenze (0 und
1023) halte (nicht 0 setzen!), dann bleibt esum außerhalb der
Übersteuergrenzen auf einem konstanten Wert und der Regler 'fängt' sich
bei Rückkehr in den Regelbereich an dem Punkt wieder, an dem das
Stellglied übersteuert wurde. Von dort arbeitet er wieder korrekt.
Wenn du integ auf 0 setzt fängt das ganze furchtbar an zu schwingen,
sobald einmal die Übersteuergrenze überschritten war.
Ok, d.h. wir belassen es bei den bisherigen Werten... Du hast ja nicht mal einen D-Anteil drinnen - hat das einen besonderen Grund?
Gast
#692110
Jo, den D-Anteil brauche ich beim Lüfter nicht, das macht nur die Stellgröße 'hibbelig'. Naja, D-Anteil kann das wahre Wunder bringen... Allerdings auch sehr gefährlich werden ^^
So jetzt mal der fertige Regler... THM - bitte noch mal drübersehn... und dann ab in die Codesammlung ^^
Gast
#692129
>und dann ab in die Codesammlung ^^
Da isser schon :-)
Ok schon gesehen ^^ Von Thomas sind dort auch ein paar SEHR interessante Aspekte bezüglich Optimierung gekommen... Vllt teilen wir das ganze in PID_init und in PID_cyclic od. so... Damit man sich dann wirklich keine Sorgen machen muss und sonst noch was "dazu pfuschen"...
Gast
#692148
Gute Idee, lass' dich nicht aufhalten ! ;) Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|