I-Anteil begrenzen

Bei langer Regelabweichung summiert der Integrator das über die ganze 
Zeit auf -> man erhält also bei langen Zeiten / großer Abweichung eine 
riesen Summe. Diese wird mit dem Faktor Ki multipliziert und weiter 
gegeben. Diese Summe verschwindet mit stationärer Genauigkeit nicht mit 
einmal, sondern muss wieder runter summiert werden.

und wieso stört es mich, wenn die Summe zu groß ist?

>und wieso stört es mich, wenn die Summe zu groß ist?

Weil das Abbauen dieser Summe lange dauert! Und in dieser Zeit 
funktioniert der (I)-Regler nicht korrekt.

ok, dass es zu lange dauert, das ist klar.
Aber wieso funktioniert der I-Regler nicht korrekt?
Kommt eine negative Differenz, dann wird der I-Anteil doch kleiner. 
Klar, nicht klein, aber kleiner!

ich hab irgendwo gelesen, dass der I-Anteil nur davon läuft, wenn sich 
der Regler in der Stellgrößenbegrenzung befindet. Wieso?

Der Einschwingvorgang dauert viel laenger, als noetig. Das ist zB beim 
Einschalten von Bedeutung. Standardmaessig blockiert man den Integrator 
wenn das Stellglied am Anschlag ist.

Wenn die Regelabweichung 0 ist und der aufsummiert Wert im I-Regler 
nicht schwingt der Ist-Wert solange bis der Integrator annähernd 0 
erreicht hat. Diese Ausschwingzeit hängt von der Größe des Wertes im 
Integrator ab.

-> Großer Wert im Integrator = lange Ausschwingzeit = doof

@ Slash-N:
was hat das denn mit dem Anschlag zu tun?

Anti Wind Up heisst das Zauberwort, einfach mal die Scuhmaschine 
anschmeissen

|-> e(k)=w(k)-y(k)
|   u(k)=u(k-1)+Ke*[e(k)-z0*e(k-1)]
|   if (u(k)<umin) u(k)=umin
|   if (u(k)<umax) u(k)=umax
|   u(k-1)=u(k)
|-- e(k-1)=e(k)

Ich empfehle eine PC Simulation zu schreiben. Da kann man alle Effekte 
ausprobieren und untersuchen.

@ gast:
das was du hast, heißt Stellgrößenbegrenzung, nicht Antiwindup

Man sollte sowieso bei jedem Projekt das Zeitkonstanten groesser als 
Sekunden hat eine Simulation laufen lassen. Sonst wartet man viel 
zulange.

Das Antiwindup ist noetig, unter anderem auch wegen der 
Stellgroessenbegrenzung. Alle natuerlichen Systeme haben eine 
Stellgroessenbegrenzung.

@Slash-N:
ja, genau das versteh ich nicht. Wieso wegen der Stellgrößenbegrenzung. 
Im Internet hab ich folgendes gefunden:
"
Die Ursache des Windup-
Effekts liegt beim I-Anteil des Reglers, da der lang anhaltende 
Regelfehler (z.B. durch physikalische Begrenzung der Stellgröße) am 
Integrationseingang zu (unbegrenzt) hohem bzw. niedrigem Wert des 
Integratorausgangs führt. Der eingeschränkte Stellbereich hat eine 
schwerwiegende Folge für den I-Anteil des Reglers.
"
Frage: wie kann ein lang anhaltender Regelfehler durch die physikalische 
Begrenzung der Stellgröße zustande kommen? Wenn mein Ventil z.B. 70% 
öffnen soll, dann begrenze ich die Stellgröße auf 100% und nicht mehr.
wie kommt man denn in die Stellgrößenbegrenzung?

Beispiel:

Ein Gefäß soll bis zu einer Höhe von 1m gefüllt werden. Dabei ist es 
aber leer. Dein Ventil kann bei voller Öffnung nur 1 ml/s. -> Regler 
will das Ventiel zu 1000% öffnen um den Zulauf zu verschnellern.
Geht aber nicht -> Stellgrößenbegenzung -> I-Anteil des Reglers würde 
explodieren.

Hallo,

das genannte Problem tritt auf, wenn man als Sollwert eine Zahl vorgibt, 
die vom realen System NIE erreicht werden kann. Dannn hat man 
logischerweise IMMER eine Regelabweichung, die dazu führt, dass der 
I-Anteil immer weiter aufintegriert.

Jetzt passieren einige unangenehme Effekte:

Ändert man den Sollwert wieder auf etwas, das erreicht werden kann, 
dauert es ewig, bis der Regler in die richtige Richtung steuert, weil er 
vorher ewig lang in die flasche Richtung aufintegriert hat.

Der zweite unangenehme Effekt tritt vor allem bei embedded Systemen auf, 
bei denen mit geringer Auflösung (z.B. 16 bit) gerechnet wird. Hier kann 
es zum Überlauf der Integrationsvariable kommen, wenn man nicht mit 
saturierten Operationen arbeitet.

Unangenehmer Effekt 3 tritt auf, wenn man in Gleitkommadarstellung auf 
großen Rechnern arbeitet. Angenommen man verwendet eine 64 bit 
Floatingpointdarstellung. Nun integriert der Integrator mit einem großen 
Fehler auf. Das macht er solange, bis die Mantisse die Auflösung für den 
anstehenden Fehler nicht mehr hat. Dann stoppt das weitere 
Aufintegrieren.

Möchte der Integrator jetzt mit einem geringeren Fehler in die andere 
Richtung wieder abintegrieren, passiert nichts, weil auch dafür die 
Auflösung der Mantisse nicht mehr ausreicht.

Beispiel: Auflösung 3 Nachkommastellen.

Regelfehler sei +1;

Das integriert auf bis 9,999 e3, dann geht ihn die Auflösung aus, um +1 
noch aufzulösen und +1 kann nicht weiter addiert werden. Demnach kann 
auch -0,1 nicht mehr addiert werden und der Regler hängt.

Mein Beispiel bezog sich natürlich beispielhaft auf ein Dezimalsystem, 
nicht auf ein Binärsystem, bei dem die Grenzen zum Umschalten des 
Exponenten anders liegen. Natürlich ist in einem 64 bit System die 
Mantisse auch viel länger, das alles war nur als einfach zu verstehendes 
Beispiel gedacht um das Prinzip zu verstehen.


Viele Grüße,

Peter

@Peter Diener,

-ich kenn niemanden, der mit float rechnet. Macht auch keinen Sinn. Ich 
rechen solche dinge seit ueber 20 Jahren in Integern und hatte nie ein 
Beduerftnis nach float.

-klar muss man mit gesaettigten Zahlen Rechnen, dh solchen die bei einem 
Overflow kleben bleiben und nicht wrappen.

-longint 32bit sollte in den meisten Faellen genuegen.