Unterschiede PID Regler - Berechnung D-Anteil

[Markus (pepe72)]

Hallo.
Hab mich die letzte Zeit mit Motor PID Reglern inkl. Bahnsteuerung 
beschäftigt. Hab jetzt mal eine Frage zu der ich bisher keine Antwort 
gefunden habe.

Normalerweise wird

y = Kp*e + Ki*Ta*esum + Kd/Ta*(e – ealt);

(oder ähnliches) verwendet.
D.h. der D-Anteil wird aus der Differenz zweier Abweichungen berechnet.

Manchmal findet man aber, dass die Berechnung direkt aus den Ist-Werten 
erfolgt. Z.B. im oft zitierten "AVR221"

d_term = pid_st->D_Factor * (pid_st->lastProcessValue - processValue);

Wann wir der eine und wann wird der andere Ansatz verwendet?

Danke.

[M. K. (sylaina)]

Na was meinst du denn, was man mit e bzw. der fliegenden Bezeichnung 
"ProcessValue" meint? ;)

[Markus (pepe72)]

e ist der Fehler.
Aber beim AVR Code ist der "processValue" tatsächlich der aktuelle 
Ist-Wert.
Solange sich der Sollwert nicht verändert, ist damit die Berechnung 
"gleich" (bis auf den Zahlbereich, der ja von der Encoderauflösung 
abhängt).
Aber bei Beschleunigung/Verzögerung geht bei der einen Berechnung auch 
die Änderung des Sollwertes mit ein.

Oder sehe ich das falsch?

[Andras H. (kyrk)]

Markus schrieb:
> Wann wir der eine und wann wird der andere Ansatz verwendet?

Es hängt davon ab worauf du schnell reagieren möchtest.
Bei der Ist-Wert wird der D Teil dann aktiv wenn der Ist-Wert sich 
ändert. Also du kannst damit einen Verlauf besser verfolgen. Aber 
änderungen am ProzessWert, werden nicht berücksichtigt. Also zum 
Beispiel, du machst Temperatur Regelung, und den D teil tust du auf den 
Ist-Wert. Wenn du eine Rampe verfolgst, wird die Rampe den D Teil 
anregen. Die Rampe wird besser verfolgt. Aber wenn sich die Temperatur 
deswegen ändert weil du Kalte Luft reinlässt, wird der D Teil nichts 
machen.

Wenn du den D Teil an den Abweichung bindest, wird der sowohl als auch 
Änderungen berücksichtigen. Ist halt gut um Rampen und auch Änderungen 
am Procezz Wert zu verfolgen.

Du kannst den D Teil nur an das ProzessWert binden, dann wird der nur 
von Änderungen da erregt.

Du musst auch dazu wissen, dass der D Teil ja auf hohe Frequenzen 
reagiert. Daher auch auf Störungen. Der Ist Wert könnte ja rein Digital 
sein. Wobei der Prozess Wert ja eher analog mit Störungen (kann ja auch 
digital kommen aber ist halt mit Störungen).

Es ist halt so eine ballance act zwischen, wie viel Störungen soll der D 
Teil weiterleiten und verstärken, und wie schnell möchte ich auf 
Änderungen reagieren. Und auf welche Änderungen.

[Markus (pepe72)]

@Andras: Vielen Dank. Hab ich verstanden.

[Andras H. (kyrk)]

P.S.: Ich habe vermutlich den Ist-Wert mit den Soll-Wert oben 
verwechselt. Also der Soll-Wert ist ja digital, oder halt ohne noise, 
wenn du denn intern irgendwie selber erzeugst. Der Ist-Wert ist ja 
analog, also mit noise. Kann auch digital sein, aber halt mit noise.


Ich habe die Erfahrung gemacht, dass der D Teil so ganz alleine nicht so 
brauchbar ist. Es ist halt ja so, dass der ja nur 2 Samples vergleicht 
und daraus einen Antwort bildet. Das mag in der Theorie klappen, aber 
Praktisch ist es dann halt so, dass du die Noise da verstärkst.

Abhilfe ist ja dann was ich schon geschrieben habe, dass man den D-Teil 
ans Soll Wert binden.

Oder man tut noch einen PT1 filter davor, damit der D Teil an mehr als 
eine Sample arbeitet. Ist dann wieder so ein Ballancig act, denn der PT1 
ist ja ein Low Pass filter, das filtert das aus worauf der D Teil 
eigentlich arbeitet. Aber es macht schon sinn hier den Frequenz zu 
begrenzen.

[M. K. (sylaina)]

Markus schrieb:
> e ist der Fehler.
> Aber beim AVR Code ist der "processValue" tatsächlich der aktuelle
> Ist-Wert.
> Solange sich der Sollwert nicht verändert, ist damit die Berechnung
> "gleich" (bis auf den Zahlbereich, der ja von der Encoderauflösung
> abhängt).
> Aber bei Beschleunigung/Verzögerung geht bei der einen Berechnung auch
> die Änderung des Sollwertes mit ein.
>
> Oder sehe ich das falsch?

Richtig. Und was steht dazu in der von dir genannten App-Note?:

>> To avoid that changes in the desired process value makes any unwanted rapid
>> changes in the control input, the controller is improved by basing the
>> derivative term on the process value only:

Man bezieht es also auf den ProcessValue um plötzliche Änderungen am 
Steuereingang zu vermeiden und so einer Schwingneigung entgegen zu 
wirken ;)