Ahoi, ich möchte eine Raumzeigermodulation implementieren. Wie kann ich aus dem Real- und Imaginärteil des gewünschten Vektors die beiden Zeiten berechnen für die auszugebenden Spannungsvektoren? Des Weiteren verfügt mein Microcontroller über eine PWM-Einheit, welche im 'center aligned mode' arbeitet, wie komme ich am einfachsten auf den duty cycle für die 3 Kanäle?
ftp://ftp.analog.com/pub/www/marketSolutions/motorControl/applicationCod e/admc401/pdf/svpwm.pdf Da werden die Zusammenhänge ganz gut hergeleitet.
Leerzeichen und Zeilenumbruch bei "Cod e" im Link entfernen... StromTuner
Mitleser schrieb: > Des Weiteren verfügt mein Microcontroller über eine PWM-Einheit, welche > im 'center aligned mode' arbeitet, wie komme ich am einfachsten auf den > duty cycle für die 3 Kanäle? Es gibt zwei Möglichkeiten, Raumzeigermodulation auf einem uC zu implementieren. 1. Du berechnest die nötigen Zeiten mithilfe der benachbarten Grundspannungsvektoren (jene, welche den entsprechenden Sektor definieren). Die berechneten Zeiten gibst du dann einfach als Ausgang an den Pin deines uC, der den jeweiligen IGBT triggert. Totzeiten werden hardwareseitig realisiert (z.B. bereits integriert in einigen MOSFET/IGBT Treiber ICs) 2. Du berechnest den gewünschten Raumzeiger in Amplitude und Winkel, und führst ihn direkt mittels inverser Clark-Park Transformation in dein ABC System (oder UVW oder 123 oder wie auch immer du dein dreiphasiges System nennen magst). Nun hast du deine drei gewünschten Phasenspannungen, die du direkt in das PWM Registers deines uCs geben kannst, der entsprechend die passenden Tastgrade für deine MOSFETs/IGBTs ausgibt. Je nachdem, welchen uC du verwendest, kannst du die Totzeit sogar elegant softwareseitig realisieren (z.B. die DSPs von TI oder Microchip). Beide Varianten führen zum selben Ergebnis, lediglich über zwei unterschiedliche Wege. Da du bereits entsprechende PWM Register hast mit Center Aligned Mode Funktionalität, gehe ich davon aus, dass du ebenfalls integrierte Totzeitmodule in deinen PWM Registern setzen kannst. Ich würde an deiner Stelle zu Variante 2 raten, da du mehrere Fliegen mit einer Klappe schlagen kannst und sogar Berechungen (bzw. if-Anweisungen) einsparen kannst. Melde dich, wenn weiterer Klärungsbedarf vorhanden ist.
Ja, Variante 2 interessiert mich. Deine Annahme bzgl. Totzeit etc. ist korrekt, ich habe das alles in Hardware. Aber wie ich aus dem Raumzeiger auf die abc PWM-Werte komme, ist mir definitiv nicht klar :-( kannst du mir das genauer erläutern?
Mitleser schrieb: > Aber wie ich aus dem Raumzeiger > auf die abc PWM-Werte komme, ist mir definitiv nicht klar :-( kannst du > mir das genauer erläutern? Wie hast du denn deinen Raumzeiger (bzw. deinen gewünschten Vektor mit Real- und Imaginäranteil) bestimmt? Beantworte bitte die Frage, damit man dir gezielt helfen kann. Gruß,
Ich persönlich finde Microchips AN955 am verständlichsten. Die dort verwendeten Formeln hab ich mal in ein kleines MATLAB GUI gepackt, weil ich persönlich Schwierigkeiten mit der Vorstellung hatte, wie aus dem Zeiger 3x Werte für die center-aligned PWM werden. Das Tool gibts hier: https://de.mathworks.com/matlabcentral/fileexchange/51322-vf-control-of-3-phase-induction-motor-using-svpwm-embedded-design-help
Hi, ich glaube, dass es oftmals ein grundsätzliches Verständnisproblem bezüglich des Raumzeigers gibt. Der Trick dabei heißt: Clark-Park Transformation Die Theorie: In einem Dreiphasensystem (Dreileiter, d.h. ohne explizieten Rückleiter) mit drei 120° verschobenen Phasen beträgt der Summenstrom 0A (entsprechend die Summenspannung 0V oder der magnetische Flußdichte 0T). Das heißt, dass man das System mit lediglich 2 Phasen beschreiben kann, da gilt: I1+I2+I3=0 -> I1+I2 = -I3 Nun kann man also ein 3 Phasensystem in ein 2 Phasensystem überführen. Das ist reine Mathematik, die sich der Clark Transformation bedient. Mathematisch bedeutet das also Iabc -> Ialphabeta Das ist reine Mathematik, und das resultierende Ialphabeta System ist nun ein rechtwinkliges Koordinatensystem. Anders ausgedrückt: Das Dreiphasensystem mit 3 um 120° versetzten Phasen kann in ein Zweiphasensystem überführt werden, bei dem die beiden Phasen 90° zueinander versetzt sind. Da wir jetzt von einem rechtwinkligen Koordinatensystem sprechen, können wir uns der komplexen Rechnung bedienen, und entsprechend einen Zeiger aufstellen, der einen Real- und Imaginäranteil besitzt. Dieser Zeiger ist im Zweiphasensystem äquivalent zu den drei Phasenspannungen im Dreiphasensystem. Um auf vom Zweiphasensystem wieder ins Dreiphasensystem zu kommen, muss man die Mathematik einfach nur umkehren, und nennt sich "Inverse Clark Transformation". Soll heißen: Der Raumzeiger ist eine reine mathematische Beschreibung des Dreiphasensystems. Heißt also, dass es für jeden Raumzeiger mit gewünschter Amplitude und Winkel drei fest definierte Phasenspannungen gibt. Die Übersetzung zwischen Raumzeiger und Dreiphasensystem geschieht mittels Clark-Transformation: Iabc -> Clark-Transformation -> Ialphabeta Ialphabeta -> Inverse Clark-Transformation -> Iabc Die Park-Transformation ist lediglich ein weiterer Schritt, das rotierende Zweiphasensystem in ein ruhendes Zweiphasensystem zu überführen, damit der PI Regler anschließend sauber arbeiten kann. Darauf muss zu diesem Zeitpunkt aber nicht eingegangen werden. Fazit, um damit die vom TO gestellte Frage zu beantworten: Wie kommt man auf die drei Phasenspannungen? Indem man den Raumzeiger mittels der Inversen-Clark-Park Transformation multipliziert. Bei weiteren Fragen einfach melden. Gruß,
Also meiner Meinung nach erhalte ich ja einen Raumzeiger, indem ich cos(omega*t) + j*sin(omega*t) rechne, wobei omega meine gewünschte Kreisfrequenz ist, mit der der Raumzeiger rotieren soll. Und es ist dann tatsächlich so einfach, aus diesem einen komplexwertigen Raumzeiger mittels Clarke-Transformation die drei Phasenspannungen zu erhalten?
Angehängte Dateien:
-
pwm-popofull.jpg
160 KB -
pwm-popohalf.jpg
160 KB -
pwm-sin3h.jpg
150 KB -
pwm-sinus.jpg
150 KB
Man kann die Sache auch anders versuchen zu erklären. Es geht ja erst mal nur um die Erzeugung eines 3Phasensystems. Unser Bezugspunkt ist GND und die PWM erzeugt im übertragenen Sinne 3 Spannungsverläufe gegen GND die in der Regel alles andere als Sinus sind. Misst man aber zwischen je 2 Ausgängen der PWM ergibt das einen reinen Sinus. In der verschiedenen Veröffentlichungen trifft man mehrere unterschiedliche Varianten an. Ich hänge mal die Bilder von 3 gängigen an sowie einer Sinus-PWM. Da sieht man auch das Problem mit der Aussteuerung bei der Sinus-PWM. Es wird da nicht der max. Hub erreicht. Allerdings kann das bei einen 3 Phase-Wechselrichter zwingend sein, wenn man einen belastbaren Sternpunkt braucht. Der Sternpunkt gegen GND ist in den Bildern immer die violette Linie. Rechnet man die Veröffentlichungen mit Clark und Park Transformationen ergibt sich immer sowas wie pwm-popofull.jpg. Man sieht auch, dass die Kurven schon relativ verzerrt sind. Besser geht das mit der Methode einem Sinus noch einen Teil seiner 3. Harmonischen dazu zu addieren pwm-sin3h.jpg. Da kommen am Ende wesentlich weniger Verzerrungen raus was sicher in einer besseren EMV endet. Die Variante pwm-popohalf.jpg hält jeder der 3 Brücken für 1/3 der Zeit auf konstanten Pegel was einerseits die Schaltverluste senkt dafür aber noch mehr Verzerrungen in den Kurven hat. Wolhgemerkt, es geht hier um Verzerrungen gegen GND. Die Spannungen zwischen den Phasen sind immer Sinus. Mich würde selbst mal interessieren, welche Varianten es noch so gibt und mit welchen Vor- und Nachteilen. Die o.g. PI-Regler ergeben eigentlich 2 Werte einmal die Höhe der Effektivspannung die die Brücke liefern soll (q) sowie einen Wert für den Phasenversatz des gesamten Zieldrehfeldes zum gemessenen. Man könnte damit auch zum aktuellen Winkel den Drehfeldversatz (der sich hinter d verbirgt) dazurechnen und mit diesem neuen Winkel die Werte der PWM aus einer Tabelle holen und mit q scalieren. So hab ich das allerdings noch nirgends gesehen.
Muss die Bilder noch erklären: Das obere Diagramm der 3. Bilder sind die Spannungen (oder PWM-Werte) gegen GND. Hier auf einen Bereich von 0-2048 scaliert. Unten die Spannungen Phase gegen Phase. Sollte Bedarf bestehen an Code für die Generierung der Tabellen, bitte melden.
Mitleser schrieb: > Und es ist dann tatsächlich so einfach, aus diesem einen komplexwertigen > Raumzeiger mittels Clarke-Transformation die drei Phasenspannungen zu > erhalten? klar. https://www.microsemi.com/document-portal/doc_view/132799-park-inverse-park-and-clarke-inverse-clarke-transformations-mss-software-implementation-user-guide https://en.wikipedia.org/wiki/Alpha%E2%80%93beta_transformation http://www.ti.com/lit/an/bpra048/bpra048.pdf
temp schrieb: > Mich würde selbst mal interessieren, welche Varianten es noch so gibt > und mit welchen Vor- und Nachteilen. Es gibt noch weitere abgewandelte Varianten der Raumzeigermodulation. Einmal eine Discontinuous PWM (DPWM), die die Schaltverluste weiter reduziert, weil die Phase mit der höchsten Amplitude auf DC+ geklemmt wird, während die anderen beiden Phasen schalten. https://www.google.dk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiRvIC1qbnVAhXB1RQKHWv4DcMQFggmMAA&url=http%3A%2F%2Fe2e.ti.com%2Fcfs-file%2F__key%2Fcommunityserver-discussions-components-files%2F38%2F7444.DPWM2.pdf&usg=AFQjCNHBnYKdah2c_oXGlDVhZS9co1AJ2w https://www.researchgate.net/profile/Federico_Barrero/publication/224224279/figure/fig2/AS:302718733307905@1449185178075/Fig-4-Modulating-and-zero-sequence-signals-for-continuous-TIPWM-and-discontinuous.png Und dann gibt es noch Raumzeigermodulationen, die die Common Mode Voltage reduzieren. Ist im Prinzip die gewöhnliche Raumzeigermodulation, jedoch mit klugen Zwischenschaltzeiten. Gruß EDIT: Hier ein schöner Artikel zu diesem Thema: https://pdfs.semanticscholar.org/dc33/cefd155f4f2a645d8d9b1ecd2d354b4535ae.pdf?_ga=2.203973651.2080309764.1501703882-1578205473.1501703882 Letztendlich lassen sich alle Raumzeigermodulationen auf Carrier basierte Modulationsverfahren zurückführen.
:
Bearbeitet durch User
Al3ko -. schrieb: > Es gibt zwei Möglichkeiten, Raumzeigermodulation auf einem uC zu > implementieren. Einspruch :-P Es gibt die dritte Methode, bei der eine Tabelle benutzt wird. Für Motorantrieb synchronisiert man den Pointer mit den Hallsensoren - dieses Verfahren findet sich z.B. in der Application Note AVR447 von Atmel. Vorteile ergeben sich aus dem völligen Verzicht auf trigonometrische Berechnungen.
Danke für eure Hilfe. Die Popokurven kenne ich, aber wenn ich mit ialpha = cos(omega*t) ibeta = sin(omega*t) einen rotierenden Raumzeiger konstander Länge erzeuge, dann erhalte ich mit der Clarke-Transformation (https://en.m.wikipedia.org/wiki/Alpha%E2%80%93beta_transformation Abschnitt 'simplified transformation') keine solchen Popokurven. Wie auch? also wie muss ich die Clarke-Trafo anders rechnen, um auf die Popokurven zu kommen?
Ich hänge mal etwas Code an mit dem ich meine Tabellen erzeuge. Zielplattform ist bei mir STM32F334 mit FPU. Deshalb mache ich auch im Controller die Berechnungen in float. Die calctables.cpp kann unter Linux oder Windows übersetzt werden. Sie erzeugt float-Tabellen für meine 4 Kurven. Wenn man sie mit "calctables 360" aufruft werden die Tabellen mit 360 Stützstellen erzeugt. Für die spätere PWM Erzeugung benutze ich die Tabellen um mit einer liniare Interpolation, wie sie auch so ähnlich in der dsplib zu finden ist, die Werte fuer die PWM Register zu berechnen. Die Hauptfunktion dabei ist
1 | void CalcPwm(float Theta, float value); |
Sie erzeugt aus dem Winkel Theta (in radians) und dem Value (Aussteuerung von 0-1.0f) die Werte fuer die PWM. Das Testprogramm spwm.cpp verdeutlicht das und erzeugt csv-Dateien mit denen man in Excel sich die Liniendiagramme anzeigen lassen kann. Auf die Art und Weise kann man sich aber auch feste Tabellen berechnen lassen, da bracht man dann zur Laufzeit keine Berechnung mehr.
Hi Mitleser, Mitleser schrieb: > Wie > auch? also wie muss ich die Clarke-Trafo anders rechnen, um auf die > Popokurven zu kommen? hast du bereits die Lösung für dein Problem finden können oder besteht nach wie vor Klärungsbedarf? Gruß,
Mitleser schrieb: > Nö, bisher nicht. Wenn du einen Vorschlag hast? Einfach nach deiner Rücktransformation den entsprechenden Offset hinzuaddieren:
Der gibt dir die gewünschten Popokurven. Gruß,
Matthias S. schrieb: > Es gibt die dritte Methode, bei der eine Tabelle benutzt wird. Für > Motorantrieb synchronisiert man den Pointer mit den Hallsensoren - > dieses Verfahren findet sich z.B. in der Application Note AVR447 von > Atmel. Vorteile ergeben sich aus dem völligen Verzicht auf > trigonometrische Berechnungen. Das ist dann aber eine Frage der Auflösung der Tabelle und der richtigen Ansteuerung und wie man mit den Unsymmetrien im System umgehen möchte. Alle Regelfälle auf einen Tabelle zu projizieren halte Ich für nicht machbar.
Thomas U. schrieb: > Alle Regelfälle auf einen Tabelle zu projizieren halte Ich für nicht > machbar Na, biste gerade beim Rundumschlag nach langer Abwesenheit? Warum sollte die Regelung was mit der Sinustabelle zu tun haben?
Ich bin aus einem anderen Thema hierher gelinkt worden und habe das zufällig gelesen. Ich wollte nur drauf hinweisen, dass in der Realität eine Regelung der PWM erfolgen muss, die über das starre ausgeben der 3 Phasenwerte hinaus geht und damit nicht alles durch die Tabelle selbst vorgezeichnet werden kann. Darüber hinaus sehe Ich keinen echten Bedarf für Sinustabellen, weil sich ein Sinus in der Praxis einfach berechnen lässt. Wo siehst Du den Vorteil von Tabellen? Ich nehme an low cost apps?
Thomas U. schrieb: > Wo siehst Du den Vorteil von Tabellen? Ich nehme an low cost apps? Das ist nur ein Aspekt. Motorkontrolle besteht zum weitaus grössten Teil aus der Überwachung und muss dafür Rechenzeit zur Verfügung haben. Da ist Gleitkomma und Trigonometrie ein unnötiger Ballast. Da die Ausgabe dann meist eh nur mit 8 oder 16bit erfolgt, ist eine Tabelle im nativen Format in der Genauigkeit mehr als ausreichend. Und nochmal: Matthias S. schrieb: > Warum sollte > die Regelung was mit der Sinustabelle zu tun haben?
:
Bearbeitet durch User
Die fixed point DSPs von TI haben eine in-built Sinus- und Kosinustabelle. Es wird insgesamt 1,25 Sinusse abgebildet (ein ganzer Sinus plus 90°, um noch einen ganzen Kosinus abzudecken). Insgesamt hat besteht ein voller Sinus aus 512 Einträgen. Die DSPs sind u.A. auf Motorapplikationen maßgeschneidert, siehe controlSUIT. Eine Lookup Tabelle auf fixed point finde ich schon sinnvoll. Die Tabelle ist normiert (p.u.). Wieso sollte das negativen Einfluss auf die Regelung haben? Gruß,
Matthias S. schrieb: > Und nochmal: > Matthias S. schrieb: >> Warum sollte >> die Regelung was mit der Sinustabelle zu tun haben? Weil eine solche Sinustabelle eine endliche Auflösung hat und somit Fehler produziert.
Thomas U. schrieb: > Weil eine solche Sinustabelle eine endliche Auflösung hat und somit > Fehler produziert. Jede Berechnung hat endliche 'Auflösung'. Und spätestens beim Umwandeln deiner berechneten Werte in eine PWM hast du die Auflösung begrenzt. Wenn man sich also beim Erstellen der Tabelle nach der verfügbaren Auflösung der PWM richtet, dann hast du die volle mögliche Auflösung. Besser gehts sowieso nicht, wäre also verschwendete Mühe. Und natürlich kann ich die 6 Sektoren so fein auflösen, wie ich will. Es ist nur sinnlos, das weiter zu treiben, als der Motor überhaupt zulässt oder es erforderlich ist. Und natürlich hat es keine Auswirkung auf eine Regelung, wo ich die Sinuswerte herhole.
:
Bearbeitet durch User
Matthias S. schrieb: > Jede Berechnung hat endliche 'Auflösung'. Und spätestens beim Umwandeln > deiner berechneten Werte in eine PWM hast du die Auflösung begrenzt. Schon, aber dies wäre ja eigentlich der letzte Schritt.
Der Raumzeiger der Richtung in die der Motor stellen soll beinhaltet schon sin und cos. Es ist keine Tabelle nötig. Man benötigt nur noch 3 um 120 Grad versetzte (normierte) Vektoren und bildet 3x das Vektorprodukt dieser Vektoren mit dem Richtungsvektor. Das ergibt direkt die 3 PWM Werte. Über das Vektorprodukt errechnet man quasi auf sehr einfache Weise die Länge eines Vektors in Richtung des 2. Vektors.
:
Bearbeitet durch User
Angehängte Dateien:
-
motor-pwm.png
200 KB
Korrektur: Man berechnet nicht das Vektorprodukt, sondern das Skalarprodukt S*A = S_r * A_r + S_i * A_i S*B = S_r * B_r + S_i * B_i S*C = S_r * C_r + S_i * C_i Anbei eine Visualisierung, bei der die Motorwicklungen bei 45°, 165° und 285° angenommen wurden (damit man besser sieht, wie sich die Phasen A, B, C gegenüber dem Eingangsvektor S verschieben).
:
Bearbeitet durch User
Joe F. schrieb: > Der Raumzeiger der Richtung in die der Motor stellen soll beinhaltet > schon sin und cos. Es ist keine Tabelle nötig. Das Huhn enthält bereits ein Ei. Es sind keine Eier nötig, um Hühner zu erzeugen. Oder anders: woher kommt der Sinus, mit dem der Raumzeigerwert gebildet wird? ... bzw genauer: ... der Sinus, auf dessen Basis der Raumzeiger moduliert wird?
Thomas U. schrieb: > Oder anders: woher kommt der Sinus, mit dem der Raumzeigerwert gebildet > wird? Das weiss ich nicht. So wie der Thread begann ist der (drehende) Raumzeiger als Eingangsgröße vorhanden. Der Raumzeiger kann ja z.B. aus einem Steuergerät kommen, das einen Sinus genauer berechnen/erzeugen kann als es mit einer Tabelle in einem uC möglich wäre. Mir ging es darum zu zeigen, dass die Transformation in 3 neue Richtungsvektoren für die PWM mit dem Skalarprodukt sehr einfach zu bewerkstelligen ist (2 Multiplikationen, 1 Addition pro Vektor).
:
Bearbeitet durch User
Joe F. schrieb: > Mir ging es darum zu zeigen, dass die Transformation in 3 neue > Richtungsvektoren für die PWM mit dem Skalarprodukt sehr einfach zu > bewerkstelligen ist (2 Multiplikationen, 1 Addition pro Vektor). Ich glaube die Umrechnung auf drei Vektoren mit Drehfaktor ist in heutigen Prozessoren ein Leichtes und beliebig genau. Die Problem hocken in anderen Ecken.
Thomas U. schrieb: > Ich glaube die Umrechnung auf drei Vektoren mit Drehfaktor ist in > heutigen Prozessoren ein Leichtes und beliebig genau. Die Problem hocken > in anderen Ecken. Achso, wie geht denn das auf "den heutigen Prozessoren", wenn man nicht weiss wie? Gibt es da ein Hardwaremodul? Eine Library? Ich werde aus deinen Beiträgen nicht schlau. Worauf willst du hinaus?
:
Bearbeitet durch User
Nein, einfach komplexe Rechnung. 3 Vektoren mit beliebigem Winkel, meistens 120 Grad, als X + jY und auf den I + jQ des Zeigers aufmultiplizieren.
Thomas U. schrieb: > 3 Vektoren mit beliebigem Winkel, > meistens 120 Grad, als X + jY und auf den I + jQ des Zeigers > aufmultiplizieren. = Skalarprodukt ;-)
:
Bearbeitet durch User
Hier ein Auszug aus meiner RZM, auf das Wesentliche gekürzt:
1 | #define L1_H 1
|
2 | #define L1_L 0
|
3 | |
4 | #define L2_H 1
|
5 | #define L2_L 0
|
6 | |
7 | #define L3_H 1
|
8 | #define L3_L 0
|
9 | |
10 | #define L1 0
|
11 | #define L2 1
|
12 | #define L3 2
|
13 | |
14 | const uint32_t SwitchSate_R [7][3]={ |
15 | { L1_L , L2_L , L3_H }, // Sektor 0 |
16 | { L1_H , L2_L , L3_H }, // Sektor 1 |
17 | { L1_H , L2_L , L3_L }, // Sektor 2 |
18 | { L1_H , L2_H , L3_L }, // Sektor 3 |
19 | { L1_L , L2_H , L3_L }, // Sektor 4 |
20 | { L1_L , L2_H , L3_H }, // Sektor 5 |
21 | { L1_L , L2_L , L3_H }, // Sektor für Überlauf = Sektor 0 |
22 | };
|
23 | |
24 | uint32_t RZMTable[] ={ |
25 | 0 , |
26 | 45 , |
27 | 91 , |
28 | 137 , |
29 | 183 , |
30 | 228 , |
31 | 274 , |
32 | 319 , |
33 | 365 , |
34 | 410 , |
35 | 455 , |
36 | 500 , |
37 | 545 , |
38 | 590 , |
39 | 635 , |
40 | 679 , |
41 | 723 , |
42 | 767 , |
43 | 811 , |
44 | 854 , |
45 | 897 , |
46 | 940 , |
47 | 983 , |
48 | 1025 , |
49 | 1067 , |
50 | 1109 , |
51 | 1150 , |
52 | 1191 , |
53 | 1232 , |
54 | 1272 , |
55 | 1312 , |
56 | 1351 , |
57 | 1391 , |
58 | 1429 , |
59 | 1467 , |
60 | 1505 , |
61 | 1542 , |
62 | 1579 , |
63 | 1616 , |
64 | 1651 , |
65 | 1687 , |
66 | 1722 , |
67 | 1756 , |
68 | 1790 , |
69 | 1823 , |
70 | 1856 , |
71 | 1888 , |
72 | 1919 , |
73 | 1950 , |
74 | 1981 , |
75 | 2010 , |
76 | 2040 , |
77 | 2068 , |
78 | 2096 , |
79 | 2123 , |
80 | 2150 , |
81 | 2176 , |
82 | 2201 , |
83 | 2226 , |
84 | 2250 , |
85 | 2273
|
86 | };
|
87 | |
88 | uint32_t RZMTableInv[] ={ |
89 | 2273 , |
90 | 2250 , |
91 | 2226 , |
92 | 2201 , |
93 | 2176 , |
94 | 2150 , |
95 | 2123 , |
96 | 2096 , |
97 | 2068 , |
98 | 2040 , |
99 | 2010 , |
100 | 1981 , |
101 | 1950 , |
102 | 1919 , |
103 | 1888 , |
104 | 1856 , |
105 | 1823 , |
106 | 1790 , |
107 | 1756 , |
108 | 1722 , |
109 | 1687 , |
110 | 1651 , |
111 | 1616 , |
112 | 1579 , |
113 | 1542 , |
114 | 1505 , |
115 | 1467 , |
116 | 1429 , |
117 | 1391 , |
118 | 1351 , |
119 | 1312 , |
120 | 1272 , |
121 | 1232 , |
122 | 1191 , |
123 | 1150 , |
124 | 1109 , |
125 | 1067 , |
126 | 1025 , |
127 | 983 , |
128 | 940 , |
129 | 897 , |
130 | 854 , |
131 | 811 , |
132 | 767 , |
133 | 723 , |
134 | 679 , |
135 | 635 , |
136 | 590 , |
137 | 545 , |
138 | 500 , |
139 | 455 , |
140 | 410 , |
141 | 365 , |
142 | 319 , |
143 | 274 , |
144 | 228 , |
145 | 183 , |
146 | 137 , |
147 | 91 , |
148 | 45 , |
149 | 0
|
150 | };
|
151 | |
152 | //Timer für Frequenz ISR
|
153 | if (++Omega >= 60) { |
154 | Omega = 0; |
155 | if (++Sektor > 5){ |
156 | Sektor = 0; |
157 | }
|
158 | }
|
159 | |
160 | Anfangsvektor = (RZMTableInv[Omega] * Amplitude.ist) / 100; |
161 | Endvektor = (RZMTable[Omega] * Amplitude.ist) / 100; |
162 | Nullvektor = (RZM_PERIOD-Anfangsvektor-Endvektor) / 2; |
163 | |
164 | TIM_SetCompare1(TIM1, ((SwitchSate_R[Sektor][L1]) * Anfangsvektor) + ((SwitchSate_R[Sektor+1][L1]) * Endvektor) + Nullvektor); |
165 | TIM_SetCompare2(TIM1, ((SwitchSate_R[Sektor][L2]) * Anfangsvektor) + ((SwitchSate_R[Sektor+1][L2]) * Endvektor) + Nullvektor); |
166 | TIM_SetCompare3(TIM1, ((SwitchSate_R[Sektor][L3]) * Anfangsvektor) + ((SwitchSate_R[Sektor+1][L3]) * Endvektor) + Nullvektor); |
Die PWM läuft Center Aligned
:
Bearbeitet durch User
Hi Ingo, vielen Dank für deinen Code. Eine Frage aus reiner Neugier: Ingo L. schrieb: > TIM_SetCompare1(TIM1, ((SwitchSate_R[Sektor][L1]) * Anfangsvektor) + > ((SwitchSate_R[Sektor+1][L1]) * Endvektor) + Nullvektor); > TIM_SetCompare2(TIM1, ((SwitchSate_R[Sektor][L2]) * Anfangsvektor) + > ((SwitchSate_R[Sektor+1][L2]) * Endvektor) + Nullvektor); > TIM_SetCompare3(TIM1, ((SwitchSate_R[Sektor][L3]) * Anfangsvektor) + > ((SwitchSate_R[Sektor+1][L3]) * Endvektor) + Nullvektor); Wieviel Rechenzeit wird für diesen Codeausschnitt benötigt? Gruß,
Al3ko -. schrieb: > Wieviel Rechenzeit wird für diesen Codeausschnitt benötigt? Das kann ich dir nicht sagen, habe mir die Zeiten nicht notiert. Viel ist es jedoch nicht, es ist ja kaum etwas zu tun. Es sind ja nur 3 Additionen.
:
Bearbeitet durch User
Hi Ingo, vielen Dank. Ich frage deshalb, weil ich selbst immer die Carrier Based Variante verwendet habe, in dem ich den Wert des Sinus direkt in Compare Register gegeben habe. Das ist eine andere Implementationsweise als die "übliche" Raumzeigermodulation, in der die On-Zeiten der IGBTs berechnet werden.
1 | PWMRegister = sine(Winkel)+RMZ_offset; |
Wobei RMZ_offset die Spannung angibt, die letztendlich für die "Popo"Kurven zuständig ist. Die übliche Raumzeigermodulation erfolgt über das Berechnen der On-Zeiten der IGBTs in Abhängigkeit von den Vektoren (Anfangsvektor, Endvektor und Nullvektor). Jetzt würde mich mal interessieren: In deinem Code berechnest du die "übliche" Raumzeigermodulation mittels Anfangsvektor, Endvektor und Nullvektor. Das Ergebnis scheinst du aber ebenfalls in ein PWM Register zu geben. Verstehe ich das richtig? Ingo L. schrieb: > TIM_SetCompare1(TIM1, ((SwitchSate_R[Sektor][L1]) * Anfangsvektor) + > ((SwitchSate_R[Sektor+1][L1]) * Endvektor) + Nullvektor); > TIM_SetCompare2(TIM1, ((SwitchSate_R[Sektor][L2]) * Anfangsvektor) + > ((SwitchSate_R[Sektor+1][L2]) * Endvektor) + Nullvektor); > TIM_SetCompare3(TIM1, ((SwitchSate_R[Sektor][L3]) * Anfangsvektor) + > ((SwitchSate_R[Sektor+1][L3]) * Endvektor) + Nullvektor);
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.