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:
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
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?
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:
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.
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 :-)
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?
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.
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.
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ß
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.