Unterschiede PID Regler - Berechnung D-Anteil

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

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?

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.

@Andras: Vielen Dank. Hab ich verstanden.

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.

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 ;)