PID Regler in VHDL

[Jan (Gast)]

Hallo,

ich bin grade dabei einen PID Regler in VHDl zu schreiben.
Das Peoblem ist, dass der Anti-Windup nicht recht funktioniert und ich 
versteh grad nicht wieso. Wenn ich mir in Modelsim meinen Reglerausgang 
angucke, dann sieht es so aus, als ob mein regler immer erst einen Takt 
zu spät die Antiwindup Rechnung durchführt.

Hier mal mein Code:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use ieee.math_real.all;


entity pid is

port(
      clk   :  in std_logic;
      reset :  in std_logic;
      w    :  in signed(31 downto 0) := "00000000000000000000000001100100";
      x     :  in signed(31 downto 0) := "00000000000000000000000000001111";
      y     :  out signed(31 downto 0) := (others => '0')
  );
end pid;

architecture Behavioral of pid is

signal e     : signed(31 downto 0) := (others => '0');
signal e_alt : signed(31 downto 0) := (others => '0');
signal e_sum : signed(31 downto 0) := (others => '0');
signal k_p   : signed(31 downto 0) := "00000000000000000000000000001010";
signal k_i   : signed(31 downto 0) := "00000000000000000000000000111100";
signal k_d   : signed(31 downto 0) := "00000000000000000000000000000001";
signal y_i   : signed(31 downto 0) := (others => '0');


begin
  Regler: process(clk,reset)
  begin
   
  if rising_edge(clk) then
    if reset = '0' then
      e_alt <= (others => '0');
      e_sum <= (others => '0');
      y_i <= (others => '0');
    else
    
      e  <= w - x;   --Regeldifferenz

      if y_i < x"000009C4" and y_i > x"00000005"  then
        e_sum <= e_sum + e;
      end if;
      
      y_i <= resize(((signed(k_p)*signed(e))+(signed(k_i)*signed(e_sum))+(signed(k_d)*(signed(e)-signed(e_alt))))/k_p,32);
      
      if y_i > x"000009C4" then
        y_i <= x"000009C4";
      elsif y_i < x"00000006" then
        y_i <= x"00000006";
      end if;

      e_alt <= e;

    end if;
  end if;
end process Regler;

y <= y_i;

end Behavioral;

Also der Bereich für y soll zwischen 6 und 2500 liegen. Leider wird wie 
gesagt immer erst einen Takt zu spät auf 2500 begrenzt...

Könnte das an Timing liegen oder überseh ich nur was simples?

Vielen Dank schonmal.

MfG

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jan schrieb:
> überseh ich nur was simples?
Dein Stichwort heißt Latency und spielt sich da ab:

      y_i <= resize(((signed(k_p)*signed(e))+(signed(k_i)*signed(e_sum))+(signed(k_d)*(signed(e)-signed(e_alt))))/k_p,32);
      
      if y_i > x"000009C4" then -- hier wird noch der "alte" Wert von y_i verwendet

Es wird noch der "alte" Wert von y_i verwendet, weil Signale den "neuen" 
Wert erst am Ende des Prozesses zugewiesen bekommen.

[Jan (Gast)]

Danke erstmal,
wäre es nun schlauer einen zweiten Prozess zu schreiben, der dann die if 
Anweisung enthält oder kann man das auch umgehen indem man zB anstatt 
Signalen Variable benutzt?

[Achim S. (Gast)]

Ein zweiter Prozess nützt dir hier wenig. Aber hier kann man tatsächlich 
mal eine Variable einsetzen, um sich Ergebnis der Rechnung zu "merken" 
und um sich Schreibarbeit zu sparen.

Also ungefähr in der Art:

signal y_i: signed....
variable y_var:  ...



      y_var := resize(((signed(k_p)*signed(e))+(signed(k_i)*signed(e_sum))+(signed(k_d)*(signed(e)-signed(e_alt))))/k_p,32);
      
      if y_var > x"000009C4" then
        y_i <= x"000009C4";
      elsif y_var < x"00000006" then
        y_i <= x"00000006";
      else 
        y_i <= y_var;
      end if;

[Klaus F. (kfalser)]

Jan schrieb:
> e  <= w - x;   --Regeldifferenz
>
>       if y_i < x"000009C4" and y_i > x"00000005"  then
>         e_sum <= e_sum + e;
>       end if;
>
>       y_i <=
> resize(((signed(k_p)*signed(e))+(signed(k_i)*signed(e_sum))+(signed(k_d) 
*(signed(e)-signed(e_alt))))/k_p,32);

e_sum und e haben das gleiche Problem.
Zu e_sum wird immer der Wert von e aus dem vorigen Zyklus dazugezählt 
und e_sum wird dann wieder einen Takt später verwendet.
Außerdem :
- Divisionen sind in VHDL nicht empfehlenswert
- PID-Regler ebensowenig, da ein FPGA dazu gedacht ist mit 100 MHz oder 
mehr zu laufen und es dürfte wenig Regelungsaufgaben geben, bei denen 
diese Regelungsfrequenz notwendig ist.

[Christoph Z. (christophz)]

Klaus Falser schrieb:
> - PID-Regler ebensowenig, da ein FPGA dazu gedacht ist mit 100 MHz oder
> mehr zu laufen und es dürfte wenig Regelungsaufgaben geben, bei denen
> diese Regelungsfrequenz notwendig ist.

Zeiten ändern sich :-)

Das betrifft vor allem moderne anspruchsvolle Leistungselektronik:
Zum Einen kenne ich Anwendungen wo einzelne 300 MHz DSPs (12 $ das 
Stück) zu wenig Rechenleistung haben um bei 12,5 us (80 kHz) zu regeln.

Da beginnt man dann nach zu denken, ob man mehrere DSPs nehmen will oder 
ob eine FPGA basierte Lösung am Ende günstiger/flexibler ist.


Das andere Beispiel das ich mal gesehen habe, das mich selber erstaunt 
hat, war ein Motorumrichter aus dem Eisenbahnbereich 
(Traktionsumrichter). Auf der Steruerplatine war nirgends ein Prozessor 
zu sehen, sondern "nur" drei Spartan 3A.

Nehme nicht an, dass die auf dem MicroBlace ihre Regelalgorithmen laufen 
haben. (Gut möglich dass sie einen Soft-Core für langsame Sachen wie 
Temperaturüberwachung etc. drin haben).

Meine begründete Anhame ist eher, dass sie ihre Reglerstrukturen direkt 
mit Simulink entwickeln und testen und danach mit dem HDL-Coder den 
Reglern ins FPGA bringen.


Trotzdem, dividieren willst du immer noch nicht in einem FPGA :-)

[Klaus F. (kfalser)]

Christoph Z. schrieb:
> Das betrifft vor allem moderne anspruchsvolle Leistungselektronik:
> Zum Einen kenne ich Anwendungen wo einzelne 300 MHz DSPs (12 $ das
> Stück) zu wenig Rechenleistung haben um bei 12,5 us (80 kHz) zu regeln.
>
> Da beginnt man dann nach zu denken, ob man mehrere DSPs nehmen will oder
> ob eine FPGA basierte Lösung am Ende günstiger/flexibler ist.

So hingestellt, möchte ich das bezweifeln.
Wenn der Algorithmus so kompliziert ist, dass ein DSP das nicht mit 80 
KHz schafft, dann ist ein FPGA sicher auch nicht die erste Wahl und ob 
Du dann mit einem FPGA zu 12$ das Stück auskommst, bezweifle ich noch 
mehr.

Bei bestimmten Funktionen kann ein FPGA Vorteile haben, z.B eine 
Stromüberwachung aim Microsekundenbereich, aber im Regler selbst?

[132 (Gast)]

Klaus Falser schrieb:
> Wenn der Algorithmus so kompliziert ist, dass ein DSP das nicht mit 80
> KHz schafft, dann ist ein FPGA sicher auch nicht die erste Wahl und ob
> Du dann mit einem FPGA zu 12$ das Stück auskommst, bezweifle ich noch
> mehr.

Was willst du denn machen wenn dir die DSPs nicht mehr reichen? Wieso 
kein FPGA? Die haben HW Multipliere und DSP Funktionalität ist doch auf 
FPGAs bedeutend besser als auf DSPs. Kostet halt ordentlich aber muss ja 
nicht. Gibt auch FPGAs für ~20€ die DSPs ohne mit der Wimper zu zucken 
in die Kiste klopfen. Die wenigsten Servocontroller die ich kenne kommen 
ohne FPGA aus. Warum sich auch mit einem DSP zum gleichen Preis 
rumärgern wenn auch ein FPGA geht den man ohnehin braucht. Da wird auch 
"nur" der Encoder der Rückkopplung ausgewertet, Clark&Park laufen neben 
2 PIDs. Ist doch wunderschön.

[Klaus F. (kfalser)]

132 schrieb:
> Was willst du denn machen wenn dir die DSPs nicht mehr reichen? Wieso
> kein FPGA? Die haben HW Multipliere und DSP Funktionalität ist doch auf
> FPGAs bedeutend besser als auf DSPs. Kostet halt ordentlich aber muss ja
> nicht. Gibt auch FPGAs für ~20€ die DSPs ohne mit der Wimper zu zucken
> in die Kiste klopfen.

Redest Du aus Erfahrung oder nur so vom Hörensagen?
Nett, dass bei bestimmten Stichworten immer wieder alle auf die 
Diskussion anspringen.
Ich lasse mich auch gerne belehren von Leuten die das für professionelle 
Zwecke schon gemacht haben. Meines ist nur eine persönliche Meinung, 
basierend auf jahrelanger Erfahrung mit FPGAs und DSPs in Jugendjahren.
Zu Regelungsaufgaben mit FPGAs habe ich keine Erfahrung, das gebe ich 
zu.
Und ich habe auch nicht behauptet, dass FPGAs schlechter sind.
Ursprünglich habe ich nur behauptet, dass es wenig Regelungsaufgaben 
geben dürfte, die man mit 100 MHz Zykluszeit berechnen muss.

[Simon B. (icerise)]

Hallo,

ich wärme den Threat nochmal auf.
Ich würde den Code gerne für meine VHDL Projekt nutzen. Mit Ersetzen der 
Signale durch Variablen läuft das auch soweit.
Sonst ist der PID Regler ja passend oder? (ich versteh die Materie nicht 
im Detail)
Meine Frage ist nur, das Ausgangssignal y_i muss ich jetzt aber noch auf 
den Sollwert aufaddieren um es dann an meinen Regel ADC weiterzugeben 
oder?

Gruß

[Andreas (Gast)]

Simon B. schrieb:
> Meine Frage ist nur, das Ausgangssignal y_i muss ich jetzt aber noch auf
> den Sollwert aufaddieren um es dann an meinen Regel ADC weiterzugeben

Nein, da sonst nach einiger Zeit über dem Integrator der negative 
Sollwert steht.