Hallo zusammen,
Hier im Forum tauchen immer wieder Fragen zur Sinus PWM mit FOC für BLDC
Motoren auf.
Ich habe mich auch für das Thema interessiert und erst mal viel gelesen.
Dabei ist mir folgendes aufgefallen:
Es gibt unendlich viele App-Notes und Beispiele. Bei vielen ist die Doku
ganz gut, der dazugehörige Code aber nicht oder nur schlecht
dukumentiert. Manchmal sind da sogar große Abweichungen zwischen Code
und pdf erkennbar.
Ich habe deshalb mal ein wenig mit einem LPCXpresso 1769 runher
experimentiert. Da gibts zwar eine Lib vom NXP, aber leider ist die auch
nicht so besonders dokumentiert. Weiterhin stört mich da, dass alle
Berechnungen mit 16bit Festkomma und einem eigenen Datentyp gemacht
werden. Das muss bei einem 32bit Cortex M3 nicht sein.
Da ich das Pferd von hinten aufsetzen will, also zuerst die PWM und dann
den Rest davor, habe ich also angefangen mit der SVPWM. Aus den 2
PID-Reglern kommen bei einer FOC die Werte q und d heraus, die
zumindestens auf den Drehwinkel bezogen statisch sind. Diese 2 Werte
nehme ich als Eingangsgröße für die SPVM. In der Literatur kommen jetzt
seitenlange Formeln und Abhandlungen über inverse Clark- und
Park-Transformationen. Diesen Teil habe ich mir aus diversen APP-Notes
abgeguckt, und versucht einen für mich verständlichen Code zu bauen. Um
beim Festkommarechnen mit 32bit zu bleiben, arbeite ich mit "großen
Zahlen". d.h. die Eingangsgrößen q und d gehen von -2147483647 bis
2147483647 und der Drehwinkel teta von 0-360Grad mit 1 Grad Auflösung.
Am Ende stehen in der Struktur McParm dU,dV und dW (im Beispiel jeweils
von 0-2048) mit denen direkt die Register der MCPWM des LPC1769
beschrieben werden. Über 2 Sachen bin ich mir nicht ganz im Klaren. Die
resultierende Spannung der Phasen ist die Hypotenuse aus q und d und die
PIDs sollten versuchen d auf 0 zu halten. So stehts zumindestens in der
Literatur. Damit ich aber den vollen Hub aus der PWM kriege mus sie bei
2147483647 an q voll aussteuern. Kommt jetzt noch ein d-Anteil hinzu bin
ich in der Übersteuerung. Wenn man jetzt nicht aufpasst kommt eine
Wellenform am Ende raus die kein Motor wirklich will. So ähnlich wie bei
den ersten Audio-AD-Wandlern mit Überschlag. Ich habe mich deshalb
entschlossen, auch d=2147483647 und q=2147483647 zu akzeptieren und die
resultierenden Kurven zu begrenzen ohne das die Werte umschlagen.
Weiterhin findet man 2 Varianten der Phasenspannungen gegen GND in der
Literatur. Einmal eine symetrische "Popokurve" und zum anderen eine
asymetrische "Popokurve" bei der jede Phase 120Grad auf hart GND bleibt.
Für den Motor gesehen kommt bei beiden das gleiche raus, nur die
Endstufen können sich in der 2. Variante immer mal ausruhen. Allerdings
erkauft man sich das mit einem wandernden virtuellen Sternpunkt gegen
GND, was in der ersten Variant nicht der Fall ist. Welche Variante
findet denn bei käuflichen Produkten Anwendung?
Ich lege den Code mal in den Anhang und auch ein paar Qszibilder. gelb
und blau sind die phasen u und v gegen gnd. violet u-v, also so wie es
der Motor sieht.
Die Routine CalcSpPwm braucht insgesamt 2,16us. Zum Messen toggle ich im
Code die Led des LPCXpresso.
Vielleicht ergibt sich ein reger Austausch wenn es um die fehlenden
"Baugruppen" geht.
Moin Jürgen,
Wenn ich deine 2. Variante richtig interpretiere ist das
Blockkummutation
und keine RaumzeigerModulation. Das erzeigt zwar augenscheinlich einen
Sinusförmigen Strom im Motor auf dem ist aber ein Ripple drauf, den du
im ungleichmäßigen Drehmoment und damit in Vibrationen hörst.
Die Variante 1 sieht aber schon nach astreiner Raumzeigermodulation aus.
Gratulation. Diese wird auch eigendlich auch ausschließlich in Industrie
Frequenzumrichtern benutzt.
Was du noch einführen könntest um dein Problem mit dem d-Anteil etwas zu
beseitigen, wäre nicht Q und D vor zugeben sondern Amplitude und Phase
des Spannungsvektors. Damit wird die Regelung später robuster und
schneller. Da die Koppeltherme die für Q und D Regelung eine große
Bedeutung haben
quasi weg fallen. Du Trennst das System in eine Phasen Regelung und eine
Strom/Drehmomentregelung diese Trennung ist dann vollständig möglich.
Nur Feldschächung ist dann nicht ganz so trivial, aber das willst du
denke ich erst mal nicht?
Der bei FOC ist ja dein Ziel das der Stromvector der Rotor Position
immer 90° voreilt um maximales Drehmoment zu erzeugen. Wenn du jetzt die
Rotorposition auf irgendeine Weise ermittelst (Sensor oder Sensorlos),
dann misst du zusätzlich den Stromvector den du in den Motor einprägst.
Damit die Phase zwischen Rotorposition und Strom 90° kannst du für
geringe
Drehzahlen einen 90° zur Rotorposition verschobenen Spannungsvektor
schalten. Aber bei höheren Drehzahlen sorgt die Gegen EMK das die Phase
von Strom zu Rotor geringer wird, damit verheizt du Energie, da den
Strom vektor misst kommt jetzt die Phasenregelung zum tragen, die jetzt
nich indirekt den D Anteil runter regelt, sonder gezielt den
Spannungsvektor weiter voreilen lässt ihn also auf 100 oder mehr Grad
steuert damit der Stromvektor genau 90°.
In Matlab siehst du dann das der Regler für die Phase das wesendlich
besser im Griff hat als der D Regler.
PS: Für n STM32 wäre dein Code sicher für mich brauchbar :)
MfG
Tec
pM->valpha=(int)((long long int)pM->MagU*(long long int)isin))>>32);
8
pM->vbeta =(int)((long long int)pM->MagU*(long long int)icos))>>32);
9
}
Ich hab mir mal deinen Code angesehen, sieht ganz gut aus, für die
Vorgabe von Phase und Amplitude müsstest du nur deine InvPark umbauen
wie ich das oben mal getan habe. Wäre toll wenn du das Mal Probieren
könntest. Ich hab das bisher nur Simuliert :)
MfG
Tec
Hallo Tec,
danke erst mal fürs Drüberschauen. Die beiden Varianten oben sind beides
echte Raumzeigermodulationen und aus Sicht des Motors ändert sich
nichts. Sogar die Phasenlage ist die selbe. Die Phasenspannungen
untereinander stimmen,(bis auf das letzte Bit bei 2048), vollständig
überein. Das Problem beim Betrachten von solchen Systemen ist halt, dass
man eigentlich alles aus der Sicht des Sternpunktes betrachten muss. Wir
sind aber gewohnt alles aus der Sicht des GNDs zu sehen. Deshalb kommen
einen manche Kurven komisch vor. Atmel hat z.B. in seinen App-Notes
häufig die Variante 1 von oben. Bei NXP ist es Variante 2. Interessant
ist wie der Sternpunk gegen GND aussieht. Da kann ich heute Abend mal
ein paar Kurven aufzeichnen.
Die Anregung von Dir die Amplitude und Phase zu regeln anstelle von q
und d nehme ich gern auf. Ist sicher der einfachere Weg. Ich wollte nur
von Anfang an die Möglichkeit mit q und d einplanen, wenn sie sinnvoll
ist. Bei der Regelung bin ich aber noch nicht, muss erst mal Hardware
bauen. Wenn ich d mit 0 in meine ParkInv laufen lasse, erziehle ich den
selben Effekt, muss dann nur noch das Delta der Phasenlage zu teta
dazurechnen.
Der einzige Controller abhängige Teil ist die Initialisierung der
Hardware. Das ist sicher beim stm32 nicht so viel anders. Ich habe
eigentlich vor, das ganze auf den kleinen LPC11C24 zu portieren.
Die 3. Kurve stellt nur die Übersteuerung dar und sollte so ja nicht
auftreten. Wenn ich nur Spannung und Phasenlage regele, kann sie auch
gar nicht auftreten.
Hallo Jürgen,
Die Portierung auf einen Controller ist sicher nicht das Problem das
habe ich bei näherem durch sehen auch gesehen. Sind die PWMs bei dir
syncronisiert? Bzw. wie hast du die eingestellt?
Was die HW angeht ist die Endstufe je nach Leistung das geringste
Problem, viel schwieriger ist es den Strom von den Phasen sauber in den
µC zu bekommen. Für Welche Leistungsklasse willst du das ganze auslegen?
MfG
Tec
Hallo Tec
Zuerst wird wohl ein 250W 36V Fahrradnabenmotor mit Hallsensoren ins
Spiel kommen.
Ich habe auch die Oszibilder des Sternpunktes gelb (3 Widerstände) gegen
GND mal angehangen. Blau ist eine der Phasen, violet A-B der beiden
Kanäle also die Spannung zwischen dem Sternpunk und der Phase. Da war
ich dann doch erst mal überrascht.
mfg
Jürgen
Hallo Jürgen,
36V 250W ist ja noch überschaubar. Kennst du den Blog von Shane Colton?
Der hat n FOC Elektro Scooter gebaut,die Boards sind recht sauber
gemacht, aber oft sehr exotische Bauteile drauf.
Bei den Kurven bin ich auch sehr Überrascht. Variante 1 habe ich noch so
erwartet und die GND Phasen der einzelnen Phasen auszugleichen. Aber die
Variante 2 hätte ich so nicht erwartet, fragt sich warum das so ist. Und
da
glaube ich liegen die 15% mehr U_ZK Ausnutzung der SVPWM, denn schaut
man sich die Amplitude der Sternspannung an passt das genau. Wenn man
einen reinen Sinus 3 Phasig raus gibt dann müsste die Sternpkt Spannung
glatt wie ein Kinderpopo sein. EMV Technisch würde ich Variante 2 nehmen
weil dU/dt des Sternpunktes kleiner ist. Aber sonst sehe ich nix was für
die eine oder andere Variante spricht. Wie Erzeugst du die Varianten?
Ich bin bei deinem Code da jetzt nicht explizit drüber gestolpert.
MfG
Tec
Hi Jürgen,
wir haben ja auch schon voneinander gelesen ;-)
hey, genial deine Software. Ich habs noch nicht ganz angeschaut, aber
Bild 2 sagt eigentlich schon alles - genauso muss es nämlich aussehen
;-) wie bist du vorgegangen? obwohl es viel Material zu dem Thema gibt
im Netz habe ich es nie verstanden, trotz dem dass ich mathematisch
eigentlich recht gut bewandert bin.
Werde deinen Code gleich heute Abend testen :-D
Gruss
Also, die beiden Varianten werden durch die Zeile:
#define FW 1 // FW==1 Vollwellenmodus, FW==0 Halbwellenmodus
umgeschaltet.
Die MCPWM im LPC1769 kennt einen AC-Modus. Bei dem werden die 3 PWM
Einheiten von einem einzigen gemeinsamen Timer versorgt und sind damit
natürlich auch immer syncron. Zusätlich haben die eine Art Doppelbuffer
drin, so dass die aktuellen PWM Werte immer am Ende eines Zyklus
gemeinsam übernommen werden.
Moin Jürgen,
Das habe ich übersehen. Ich kann es nur nicht ganz nachvollziehen. Du
halbierst im Vollwellenmodus die Strangspannungen und setzt 1/4 der
Amplitude als Offset drauf. Wenn ich das durch rechne hast du +/-2^30
Amplitude und +2^29 als Offset dh. bei voll negativer Aussteuerung fehlt
dir ein Viertel der Ampitude. Der Halbwellen Modus ist das wie ich es
implementiert hätte, da hast du ja die volle Amplitude. Hast du vllt die
Einstellungen vertauscht? oder Habe ich einen groben Denkfehler?
MfG
Tec
Hallo Tec,
ne, das passt schon. Ich lege mal eine Routine bei um das mit einem
C-Copmiler auf dem PC zu testen. Da werden nur die Werte für den Kreis
mit printf ausgegeben und zwei "Textgrafiken" in Dateien geschrieben.
In beiden Varianten kommt am Ende das selbe raus.
Moin Jürgen,
Aus Juks hab ich das mal zusammen geschmissen, hab hier aber gerade nur
VC6
und da kommt nicht das raus was ich dachte. siehe Anhang
Hab den C Code nur fix zusammen kopiert.
MfG
Tec
VC6 Gott hab ihn seelig....
der kennt kein long long sondern nur __int64. in der ParkInv hast du
daraus 32bit Variablen gemacht. Die Multiplkation geht dort ueber 64bit,
was die ARMs koennen. Sicher auch AVR32, sowas benutzt Atmel in den
App-Notes auch.
1
// das Ergebnis wird in pM->valpha und pM->vbeta gespeichert
2
// das >>32 anstelle >>31 bedeutet, dass valpha und vbeta durch
3
// 2 geteilt wird um ein ?berlauf des Wertebereiches zu verhindern
Moin Jürgen,
Ich ging in meinem Leichtsinn davon aus das long 64bit ist :) weil auf
nem Cortex int ja schon 32Bit hat. Aber gut ich kann das morgen ja noch
mal ändern, wenn ich wieder mal auf Teile warte.
MfG
Tec
Hallo,
ich hab da noch eine allgemeine Frage.
ich habe hier einen maxon EC40 Motor mit Hallsensoren und Drehgeber mit
500 Impulsen/Umdrehung sowie die zum Motor passende Steuerung. Fragen:
- wenn der Motor einen Drehgeber hat - wieso werden trotzdem noch
Hallsensoren benötigt? Im Prinzip könnte man ja auch nur anhand der vom
Drehgeber gemeldeten Position kommutieren.
- wenn ich auf dem PC der Steuerung das Stop-Kommando sende, dann wird
der Motor gebremst. Versuche ich, von Hand an der Welle zu drehen, dann
hält die Steuerung den Rotor mit aller Kraft, und es ist kaum möglich,
die Welle um mehr als einen einzigen Drehgeberpuls zu verdrehen. Das
finde ich ja ein ganz geiles Feature; hab ich noch nie gesehen.
Wohlverstanden: der Motor hat keine Bremse, sondern er wird effektiv von
der Steuerung so kommutiert, dass er steht. Rührt man die Welle nicht
an, fliesst also auch kein Strom, aber bei der geringsten Berührung
"wehrt" sich das Gerät sofort. Wie macht man sowas? könnte man mit dem
LPC17xx sowas auch implementieren?
Gruss Tobias
Moin Tobias,
Die Hallsensoren werden bestimmt dafür gebraucht um eine absolute
Referenzposition zu haben. Der Drehgeber wird Incremental sein, also nur
eine Positionsänderung raus geben keine absolute Position.
Die Betriebsart die du meinst nennt sich Positionsregelung. -> Du willst
den Motor verdrehen und der Regler steuert Drehmoment dagegen.
Jenach Dynamik kannst du das auf nem Cortex m3 locker implementieren.
1kHz Regelfrequenz schafft man sicherlich. ist ja nicht viel bei.
Wenn du die SVPWM hast machst du ne Stromregelung und damit eine
Drehmoment Regelung, da du einen Drehgeber hast ist die Ermittlung der
Rotorlage kein Problem. Jetzt hast du zwei Möglichkeiten.
1. Du regelst die Drehzahl über das Drehmoment und die Drehzahl auf
Grund der Position
2. Du regelst das Drehmoment direkt für die Position.
Ist alles Stand der Technik bei Industrie-Servo-Umrichtern.
MfG
Tec
moin Tec,
der Drehgeber ist inkremental, stimmt. aber er hat noch einen Index. Ich
hätte jetzt versucht, die Hallsensoren einzusparen. Im Prinzip könnte
man ja einmalig beim Start der Steuerung den Motor so lange bestromen,
bis der Indexpuls kommt. Ab da kenne ich die Rotorlage und kann
"Softwarehallsensoren" implementieren. Nicht?
Kannst du das mit der Regelung noch ein wenig verdeutlichen? ist mir
noch nicht ganz klar.
Auf jeden Fall steht mein neues Projekt fest: den Motor ansteuern mit
einem Cortex, unter Verwendung von SVPWM sowie implementieren einer
Drehzahl- und später dann noch Positionsregelung. :-D hältst du das für
machbar mit einem, sagen wir STM32F4? sollte bei 120MHz schon drinne
liegen, oder?
Noch was fällt mir ein:
wenn ich den Motor drehen lasse, und auf Stop klicke, dann kann ich das
so einstellen, dass er wirklich "hart" an einer bestimmten Position
anhält. Ich sage z.B. "fahr mal 1048576 Counts im Uhrzeigersinn", und
tatsächlich, der Motor hält exakt dort an. Wie also ist es möglich, den
so schnell zu bremsen?
Moin Tobias,
Laut ST packt ein STM32F100 mit 24MHz die Feldorientierte Regelung
(SVPWM) für einen Motor mit dem ST Motorcontrol Library ohne Probleme.
Ein F4 ist da eigendlich overkill. Ich würde n F103 nehmen ist günstiger
und für einen Motor vollkommen ausreichend. Bei mir steht die umsetzung
meiner Regelung auf dem µC auch noch aus.
Die Geschichte mit den Softwarehallsensoren würde ich lassen, du hast
doch eine viel höher aufgelößte Position. Ich würde das so
implementieren:
Beim Start über die Hallsensoren den Sektor bestimmen und damit den
Incrementalzähler initialisieren und dann beim ersten Nullpuls den Geber
richtig kalibrieren. Es stellt sich dabei die Frage nach den Polpaares
des Motors ich tippe mal auf 4, das steht aber im Datenblatt. Denn die
Hallsensoren messen ja die elektrische Rotorlage und der Inc Geber misst
die mechanische Rotorlage, dazwischen steht die Anzahl der Polpaare als
Faktor. (elektrische Untersetzung)
Zur Regelung: Wenn du mit der SVPWM arbeitest dann machst du allg eine
Feldorientierte Regelung. Das bedeutet mit der SVPWM erzeugst du einen
Spannungsvektor(Summe aus Ua Ub Uc), daraus resultiert ein Stromvektor
im Motor(Summe Ia Ib Ic). Dieser Strom vektor interesiert dich
eigendlich.
Denn wenn du die elektrische Rotorlage hast muss der Stromvector in
Drehrichtung 90° voreilen damit du den Strom ausschließlich in
Drehmoment umsetzt.
Bei Industriellen Umrichter kommen da für die Clark und die Park
Transformation zum Einsatz. Klingt kompliziert ist aber recht einfach.
Damit bezweckt man den bezug zur Rotorlage in der Regelung weg zu
lassen.
Am Beispiel: Du misst den Stromvektor durch den Motor sagen wir der ist
8A und hat den Winkel von 30° zur Rotornulllage. Um jetzt zu wissen wie
der Vektor zum Rotor steht Transformmiert man den Vektor in die
Rotorkoordinaten, di suptrahierst also die elektrsche Rotorlage die ist
beispielsweise 120° (-> genau am 2. Hallsensor). Der Stromvektor in
Rotorkoordinaten ist also -90° und 8A, das bedeutet du erzeugst mit 8A
Drehmoment gegen den Uhrzeiger sinn. Denn der Stromvektor eilt dem Rotor
um 90° entgegen den Uhrzeigersinn vor.
Angehen tust du das in der Sw wie folgt, Sollstrom vorgeben und
Drehrichtung, Rotorlage messen, Spannungsvektor 90° voreilend in
Drehrichtung vorgeben, Die Spannungsvektorlänge mach ein PID Regler aus
der Länge des Stromvektors. Deshlab musst du diesem Messen. Ein 2. PID
Regler Über wacht den Winkel des Stromvektors zum Rotor ist der kleiner
als 90° was bei höherer Drehzahl auf Grund der GegenEMK des Motors
zwangsläufig so ist. Wird der Spannungsvektor weiter vorgestellt bis der
Strom wieder 90° hat. Wenn du das so hast kannst du mit dem Strom das
Drehmoment vorgeben. Willst du jetzt die Drehzahl regeln musst die
diese Messen (dtheta/dt) Änderungsrate des Drehwinkels. Die Drehzahl
mach dann wieder ein PID Regler der den Stromsollwert für den
Stromregler so vor gibt das die Drehzahl passt. Beim Positionsregler ist
das das gleiche PID Regler der das Drehmoment/Strom entgegen der
Richtung des Positionsfehlers vor gibt.
Ich hoffe das war halbwegs verständlich.
MfG
Tec
Moin Tec,
die Park und Clarke Transformationen und deren Inverse kannte ich
bereits, da ich davon mal gelesen habe und versucht habe mir diese
Matrizengleichungen selber herzuleiten. Die Transformationen sind mir
also aus mathematischer Sicht durchaus bekannt! Aber dennoch herzlichen
Dank für deine Ausführungen.
Das Problem ist eher die Umsetzung in die Praxis ;-)
Eben z.B. die Sache, wie ich den Motor an einer gewünschten Position
festhalten oder sehr schnell bremsen kann.
Zur Software:
ich möchte die ST FOC Library eigentlich nicht einsetzen, der Witz ist
ja eigentlich gerade, das "zu Fuss" zu implementieren. Oder ist das
nicht machbar? Ich stelle mir das ansich nicht so komplex vor: mittels
ADC Ia, Ib messen, dann Clarke und Park, dann der PI-Regler, dann
Inverse Park und dann SVPWM (oder so in der Art). Aus meiner Sicht ist
nach wie vor die einzige Schwerigkeit die Positions- und
Drehzahlregelung, sowie die Berechnung der Zeiten für die SVPWM. Da
hilft der Code hier schon extrem weiter.
Beim STM32 habe ich auch noch das Problem, dass ich die Doku extrem
unübersichtlich finde. Ich weiss noch immer nicht, welchen Timer ich
benutzen muss, um damit SVPWM machen zu können. Da gefällt mir NXP schon
besser, ich bin noch nicht sicher, mit welchem Prozessor ich anfangen
soll, denn ich habe glücklicherweise zu beidem Evalboards hier (einmal
STM32F100 Discovery, STM32F4 Discovery und ein NXP-Board mit einem
LPC17... irgendwas).
Ich hoffe, ich komme heute endlich mal noch dazu, eine passende
MOSFET-Endstufe zu bauen, dann kann ich mal versuchen, es auf dem
NXP-Prozessor zu implementieren. Ich meld mich dann wieder ;-)
Moin Tobias,
Sry ich wusste nicht wie weit du damit vertraut bist. Ich würde das auch
ohne die Lib von ST machen zumindest die FOC lib. Was den Timer angeht
bei ST heißen die Advanced Timer ist aber auch egal Hauptsache 3 PWM
Kanäle
Sychronisiert bekommste die auch so.
Was die Regelung an geht wenn die Drehmoment Commandierung/Vorgabe klar
ist, dann hast du die größte Hürde schon. Du brauchst jetzt für
Positionsregelung nur noch einen Drehzahlregler und darüber den
Positionsregler. Die Drehzahl messen und berechnen ist ja kein Ding
diese mit nem Sollwert zuvergleichen auch net PID und der Ausgang ist
die Drehmomentvorgabe für die FOC. Für Positionsregelung, vergleichst du
Soll und Istposition, daraus ergibt sich der Schleppfehler -> PID und
den Ausgang auf den Drehzahlregler. Oder du machst
DTC(DirectTorqueControl) und gibst den Ausgang des PositionsReglers
direkt auf den Drehmoment Sollwert.
Für Servobetrieb ist das ausreichend. Willst du aber die
Positionsregelung haben das der Motor/Achse einem Master folgt dann ist
Variante 1 besser.
Ich hoffe das war jetzt Aufschlussreicher.
MfG
Tec
Moin Tec,
Naja, wirklich vertraut bin ich nur mit der Mathematik hinter der Park-
und Clarke Transformation. An die konkrete Umsetzung derselbigen habe
ich mich bisher jedoch noch nicht gewagt...
Also, ich werd jetzt erst mal eine ordentliche Endstufe aufzubauen
versuchen und dann werd ich mich wieder melden ;-)
Gruss
PS: machst du beruflich Servoregler, oder wieso kennst du dich damit so
aus? Kannst du da gute Literatur empfehlen? Das Thema finde ich wirklich
höchst spannend.
Moin Tobias,
Ich hab dir mal ne Umfassende Diplomarbeit angehängt da steht alles
drin.
Sonst kann ich nur den Blog von Shane Colton vom MIT empfehlen, der
schreibt immer mal wieder was über seien MC Geschichten. Und hat z.B.
auch diese Arbeit dort verlnkt. Falls ein Mod sie löscht. Was ich nicht
hoffe.
Beruflich setze ich Servoregler ein und da wir speziel an die
Positionsregelung sehr hohe und nicht alltägliche Ansprüche haben müssen
die Regler der Umrichter oft angepasst oder zumidest über geordnete
Regelstrukturen Programmiert werden. Aber vieles ist auch einfach nur
Interesse an der Materie. Ich ma einfach Motoren und von diesen
Amlibsten Permanent erregte Synchronmaschinen (ähnl. bzw. = BLDC jenach
dem wen du fragst).
Bei der Endstufe musst du nur die Strommessung sauber halten. Ich würde
keinerlei Filter physisch einbauen vllt ein RC glied mit als "Snubber"
um die Flanken nicht so hart zuhaben. Die PWM die du dann auf dem Strom
siehst ist quasi egal wenn du Sychron zur PWM die ADCs laufen lässt.
Was für Daten hat den dein Motor, vllt kann ich die Endstufe auch
gebrauchen.
MfG
Tec
Moin Tec,
danke erst mal für das PDF! das schaue ich mir gerne an. Wie gesagt ist
die Thematik extrem spannend. Sobald BLDCs und ähnliches ins Spiel
kommt, wirds sehr intressant ;-) daher befasse ich mich viel mit solchem
Kram.
Mein Motor ist dieser:
http://www.maxonmotor.ch/maxon/view/product/motor/ecmotor/ec/ec32/118892
Als Drehgeber dürfte dieser verbaut sein:
http://www.maxonmotor.ch/maxon/view/product/sensor/encoder/hedl5540/110514
(wobei ich bei letzterem aber nicht 100%ig sicher bin; ich hab den Motor
grade nicht heir und kann daher nicht nachschauen).
Erstmal will ich eine passende Endstufe für diesen Motor bauen. Später
dann möchte ich schon noch was grösseres realisieren, wobei es da dann
allerdings wieder schwierig wird, passende Motoren sich zu beschaffen.
Auch die Drehgeber sind nicht so leicht beschaffbar, soll ja auch noch
im bezahlbaren Rahmen bleiben ;-)
Moin Tobias,
Die Für die Positionsregelung ohne Drehgeber würde ich eine
hochpoligemaschine nehmen 14 oder mehr pole als Außenläufer und die
Hallsensoren außen anbringen dann hast eine auf lösung von 9° bei
14Polen das ist schon mal recht gut, wenn du einen 54Poler findest (kein
Modellbau derivat) kommste fast auf die Drehgeberauflösung.
Als Endstufe wäre diese hier wohl nicht so falsch
http://danstrother.com/2011/01/12/brushless-dc-motor-controller-board/
Schaus dir mal an.
Ich bin auf deine Ergebnisse gespannt. Wenn ich wieder Zeit dafür hab
dann werde ich mich auch mal wieder an meine Regelung setzen. Ich will
das ganze weitest gehen im Zustandsraum bewerkstelligen mal sehen was
das bringt.
Hast du dich schon für Prozie usw. entschieden? Willst du nur n
Steckbrettaufbau machen oder gleich ne richtige Platine? Wenn du ne
Separate Endstufe erstellen willst ohne Prozie und den Extern haben
willst, wäre ich auch dran interessiert dann könnte ich die an mein
STM3210B-Eval bummeln das hat n extra Motorcontrol stecker, Wo die
Endstufe von ST normal rankommt aber die ist mir viel zu teuer.
MfG
Tec
MfG
Tec
Moin Tec,
ich habe mich noch nicht für den Prozessor entschieden. Da ich aber
NXP-Fan bin und hier noch ein paar LPC1766 herumliegen habe, werde ich
wohl die verwenden. Der STM32 ist toll, aber da brauche ich wohl zu
lang, um mich in die Motorcontrol Geschichte einzuarbeiten. Für den
Motorcontrol Timer von NXP haben wir hier ja dank Jürgen einen schönen
Beispielcode ;-)
Allerdings habe ich tatsächlich vor, die Endstufe separat zu bauen,
sodass man ein Mikrocontroller-, Prozessor- oder DSP-Board
draufschnallen kann. Dann würde ich davon eine Platine herstellen
lassen. Wenn du an der Hardware interessiert bist, könnte ich ja mehrere
LPs fertigen und wir teilen uns dann die Kosten... ich denk, auf 2 Lagen
sollte man das vernünftig hin bekommen. Besser wäre zwar 4, aber das
wird dann wohl doch ein wenig teuer...
Was sollte deiner Meinung nach alles auf die Endstufe?
Ich dachte an folgendes:
ein paar kräftige MOSFETs, D2PAK oder so, mit galvanisch getrennten
Gatetreibern, und dann auch noch direkt 3 Stromsensoren. FHS-40 von LEM
möchte ich schon lange gerne mal Einsetzen. Dann noch ein wenig analoge
Signalaufbereitung, und dann das ganze auf den Stecker geführt... was
meinst du?
Gruss
Moin Tobias,
Für wieviel Strom und Spannung willst du das Auslegen? Ich wäre für
10-20A
bei 12-24V, irgendwas indem Bereich. PWM Frequenz muss größer 20kHz
möglich sein da ich bis 2kHz Drehfeldrequenz will(>150krpm). Die FHS-40
gefallen mir scheint aber das man da mit dem Layout sehr aufpassen muss.
Generell wäre ich da für 2 seitig das kann ich auch zur Not selber
herstellen. Aber wenn wir die Platinen von IteadStudio in China machen
lassen kosten die eh nicht viel. Was ich noch gern hätte wäre nicht nur
die Strommessung sondern auch eine zusätzliche Strangspannungsmessung,
die ist einfach aufzubauen und für Experimente gut.
Die Frage ist für mich noch was die Bauteile so Kosten?
Ich würde sonst einfach sagen mach doch mal n Schaltplan wie du dir das
gedacht hattest wahrscheinlich passt mir das dann auch schon. Ich werde
die Endstufe eh nur zur Softwareentwicklung nutzen. Und die Motoren die
ich habe sind alle Modellbaugeräte. Mein Quälmotor ist n 14Pol
Außenläufer mit 200W bei knapp 14V also ähnliche Kategorie wie dein
Motor. Wenn natürlich größere Motoren möglich sind, gut. Aber das hat
auch Nachteile.
Die Strommessung muss genau dimensionierbar sein also wären vllt
bestückbare Shunts auch gut. Quasi n FHS-40 oder OP und Shunt. Über
Jumper auf die Ausgangs Pins legbar. Das du damit auch Motoren mit 1A
Maxstrom gut Regeln kannst und wenns die FETS Packen aber auch ich sage
24V 80A Klopper kein Ding sind. Zum reinen Experimentieren sicher nicht
verkehrt.
MfG
Tec
Hallo Jürgen,
ich habe da noch eine Frage zu deinem Code.
Kannst du mir erklären, wie du auf
1
intvsq3h=vb-(vb>>3)-(vb>>7)-(vb>>10)-(vb>>12);
kommst? interessanterweise multipliziert dieses Statement tatsächlich
mit sqrt(3)/2, aber sowas habe ich ja noch nie gesehen :-D
Dann weiter:
was wird mit
1
intqV1=va;
2
intqV2=-(va>>1)+vsq3h;
3
intqV3=-(va>>1)-vsq3h;
genau gerechnet? ich kann diese Rechnung mit den gängigen AppNotes nicht
nachvollziehen. Korrekt ist sie ja aber zweifelsohne, wie deine
Oszibilder ja zeigen :-O wie bist du darauf gekommen?
Hallo, ist eigentlich ganz einfach.
int vsq3h=
vb 1 * vb
-(vb>>3) = -1/8 = -0.125 * vb
-(vb>>7) = -1/128 = -0.0078125 *vb
-(vb>>10) = -1/1024 = -0.0009765625 *vb
-(vb>>12) = -1/4096 = -0.000244140625 *vb
-------------------
0.865966796875 * vb
sqrt(3)/2 = 0.86602540378443864676372317075294
d.h. Es wird soviel von vb abgezogen, dass nur noch sqrt(3)/2=0.866026
vb übrig bleiben. Dabei kommen nur Terme zum Einsatz die durch 2 teilbar
sind, und somit habe ich die Multiplikation mit sqrt(3)/2 durch 4 mal
Schieben und Subtrahieren ersetzt. Der Fehler liegt bei:
0.86602540378443864676372317075294/0.865966796875=1,00006767800988460590
47674393583 das sind ca. 0.0068% und somit für diesen Zweck
vernachlässigbar.
Damit wird dann aus
int qV2 = -(va>>1) + vsq3h;
int qV3 = -(va>>1) - vsq3h;
die inverse Clark Transformation:
qV1=va;
qV2 = -va/2 + (sqrt(3)/2) * vb
qV3 = -va/2 - (sqrt(3)/2) * vb
Hi Jürgen,
danke für deine Ausführungen. Im Nachhinein betrachtet ist es eigentlich
klar :-) raffinierter Trick, habe ich so noch nie gesehen, aber das ist
ja super elegant. Der Cortex M3 kann ja direkt mit einer einzigen
Instruktion schieben und addieren/subtrahieren, dann wird diese
Geschichte wirklich effizient!
;-)
Gruss
Hallo Jürgen,
noch eine Frage.
Du verwendest den LPC1769. Wie machst du die Messung der Phasenströme,
bzw. wie synchronisierst du den ADC? Soweit ich das aus dem User Manual
erkennen kann, lässt sich die MCPWM nicht wirklich mit dem ADC
synchronisieren, ich sehe da keine Möglichkeit die Conversion zum MCPWM
zu synchronisieren.
Gruss
Tobias
Moin,
Also bei dem STM32 ist es möglich den ADC mit einem Timer zu
syncronisieren. Wieviele parallele ADCs hat den ein LPC17?
Der STM32 hätte 2 damit ließen sich 2 Phasenströme in der Lowphase der
PWM gleichzeitig samplen. Oder man lässt die PWMs bewust asyncron laufen
damit man mit einem ADC im Overflowinterrupt in der LowPhase jeder PWM
samplen kann. was das für EMV Auswirkungen und so hat kann ich nicht
abschätzen.
MfG
Tec
Bei einem LPC17 ist es auch möglich, den ADC mit einem Timer zu
synchronisieren, aber leider haben die wohl nicht daran gedacht, dass es
noch Sinn machen würde die ADCs mit dem Motorcontrol PWM zu
synchronisieren ;-) so wie ich das hier aus dem User manual heraus lese,
kann ich mit Timer 0, 1, 2 und 3 synchronisieren, aber nicht mit dem
MCPWM timer. Hmm...
Wäre es eigentlich auch denkbar, den Strom durch die Lowside-Shunts
irgendwie zu mitteln mittels eines kleinen RC Glieds? Dann spielt es ja
nicht so eine grosse Rolle, wann ich messe....
Irgendwie fände ich es nicht so toll, wenn ich für jede Messung einen
Interrupt brauche.
Mit einem naja damit du mittelst muss die Zeitkonstante des RC gliedes
größer als die PWM Periode sein, damit handelst du dir dann aber schon
eine segnifikante Phasenverschiebung ein. Klar kann man die raus rechnen
aber die ist nicht konstant sondern Spannungsabhängig usw.
Da ich das ganze physisch aber auch noch nicht aufgebaut habe ist das
nur eine vermutung.
MfG
Tec
Hallo zusammen,
dieses Thread ist zwar nicht mehr ganz aktuell aber denke er passt am
besten zu meinem Anliegen.
Habe ein STM32F103 µC und als Treiberstufe einen DRV8301 jetzt würde ich
da gerne einen BLDC mit FOC Regeln kann mir da noch jemand weitere
Informationen/Codeauszüge posten?
Die PWM geschichte ist denk ich soweit klar aber wie regelt ihr
dies(d/q-Anteil) und vorallem wie setzt ihr dies um?
(PWM/ADC-Einstellung)
Hi,
Du kannst mal bei TI nachsehen. Da gibt es eine komplette SW Library zum
Download. Microchip ist auch interessant. Einfach auf der Website mal
nach AN1078 suchen. Auch hier gibt es den Source Code zum download.
Gruß,
Ralf
Hallo Tec, hallo Tobias,
(und alle anderen)
weiter oben im Thread wurde mal geäussert, dass Interesse an einer
separaten
Endstufe besteht... (s. 12.03.2012 14:45)
Ich habe mir auch mal Gedanken über eine etwas "bessere"
BLDC-Ansteuerung,
komplett mit Feedbackzweig, gemacht.
Hier mal paar Stichpunkte die mir wichtig sind:
-separater Aufbau von Controller und Leistungsteil
-High-Voltage-fähig: 48..300V DC, Auslegung mit 450V Bauelementen
-vollständige Opto-Entkopplung von Leistungsteil/Feedbackzweig und
Ansteuerung
-Ausführung möglichst als Shuttle- oder Mainboard von z.B. TI
DK-TM4C123G
-opulente Ausstattung des Feedbackzweigs (3x Strangströme, 3x
Strangspannung, 1x Uhv)
-diskretes Leistungsteil: keine Hybrid-Endstufen, keine
Ladungspumpen-Gatedriver
-0..100% Duty-Cycle bzw. statisches Schalten der Brücken soll möglich
sein
Im Anhang ist mal der 1. Wurf des Konzepts zu sehen.
Es sollte möglich sein, damit unterschiedliche
Controller/Developmentkits zu betreiben.
meine Lieblinge sind abgebildet...
In der Zeichnung sind die favorisierten Bauelemente mit möglichem
Gehäuse
und ein paar Eckdaten angegeben.
Es gäbe noch einige Optionen:
z.B. Auswerten der /Fault-Ausgänge der Stromsensoren,
Anschlussmöglichkeit von 3 gängigen Hallschaltern, Absicherung etc.
Das ganze ist also kein Spielzeug mehr und soll auch für "erwachsene"
Antriebe
geeignet sein.
Der Teufel steckt meistens im Detail (z.B. DC/DC-Wandler) und für
PWM-Ansteuerung gibt's eigentlich nur "bleiben lassen" oder 100%-ig
umsetzen.
Ich bin auf ein paar Hinweise bezüglich Konzept und Bauteilauswahl
gespannt.
Vielleicht gibt es Interesse an einer "gemeinsamen" Hardware.
Viele Grüße TT
Hallo allerseits,
jaja, der Thread ist schon alt, aber meine Frage passt hier grad rein,
weil weiter oben nämlich über die Strommessung diskutiert wurde. Und ich
befasse mich grad wieder ein bisschen mit dem Thema...
Frage dazu:
wenn man die Strommessung im Lowside-Pfad implementieren will, und nicht
schwimmend, wie oben dargestellt, dann misst man ja immer nur positive
Ströme, oder? kann man das dennoch so machen? hat eigentlich jetzt mal
schon jemand so einen Motortreiber incl. Ansteuerung realisiert?
und noch was: wenn man einen BLDC oder PMSM damit ansteuern will, dann
braucht man ja zu den Hallsensoren dazu noch einen Drehgeber, wie
initialisiert man die Startposition vom Drehgeber? muss zwingend eine
Referenzfahrt ausgeführt werden, also dass man den Motor so lange
zwangskommutiert, bis man den Übergang zwischen zwei Hallsensoren
erkennt? irgendwie muss man ja heraus finden, wo der 0° Punkt liegt.
Moin.
1. In der Lowside misst du auch bidirektional. Die Shuntspannung wird
halt negativ und das muss der OP der sie verstärkt dann können. Da gibt
es spezielle OPs für.
2. Du brauchst nicht zwingend einen Geber wenn du schon Hallsensoren
hast du kannst aus den Hallsensoren auch mathematisch einen genaueren
Winkel interpolieren.
Und um einen Inc. Geber zu initialisieren musst du einmal den
Nulldurchgang gesehen haben und die Winkel offsets der Hall Sensoren
Ermessen. Aber das musst du ja nur einmal machen. Die Winkel ändern sich
ja nicht so das du den Inc. Zähler auch grob über die Halls
initialisieren kannst. Bist du halt in der 1. Umdrehung max +-30°
falsch. Das sind aber immer noch cos30° = 87% vom Nennmoment.
Oder du nimmst einen Geber der dafür gedacht ist. Wie einen Resolver
oder SinCos(Hiperface) Geber. Das sind absolute Geber da machst du einen
"Polradabgleich" und der bleibt für ewig bestehen.
Und zu aller letzt: ja ich und auch andere aus dem Thread haben schon
Umrichter für BLDCs/PMSMs gebaut.
Alexander B. schrieb:> 2. Du brauchst nicht zwingend einen Geber wenn du schon Hallsensoren> hast du kannst aus den Hallsensoren auch mathematisch einen genaueren> Winkel interpolieren.> Und um einen Inc. Geber zu initialisieren musst du einmal den> Nulldurchgang gesehen haben und die Winkel offsets der Hall Sensoren> Ermessen. Aber das musst du ja nur einmal machen. Die Winkel ändern sich> ja nicht so das du den Inc. Zähler auch grob über die Halls> initialisieren kannst. Bist du halt in der 1. Umdrehung max +-30°> falsch. Das sind aber immer noch cos30° = 87% vom Nennmoment.
Den Drehgeber habe ich sowieso und möchte ihn gern für
Positionieraufgaben benutzen. Das Problem ist aber, dass es sich um
einen inkrementellen Geber handelt, der zwar fest mit der Welle des
Motors verbunden ist, aber beim Einschalten weiss man die Position
trotzdem nicht - um aber die Park-Transformation richtig durchzuführen,
muss man den Rotorwinkel kennen. Man muss also den Drehgeber zu den
Hallsensoren synchronisieren. Die Frage ist, wie das geht. Klar, man
könnte einfach einen festen Spannungsvektor, zB. 001, ausgeben und eine
Weile warten, sodass sich der Motor ausrichtet. Danach die Zustände der
Hallsensoren angucken, dann kennt man den Sektor und kann den die
Position des Drehgebers initialisieren. Aber kann man das auch, ohne den
Motor drehen zu lassen? angenommen bei einem Segway, einer
Werkzeugmaschine oder e-Bike - dort wäre es doch sehr unerwünscht, wenn
der Motor beim Einschalten des Geräts erst mal wild 'zappelt' um die
Sensoren zu initialisieren.
Eine Lösung ist wie du schon sagst den Motor zu bestromen und ihn
einrasten zulassen. Aber wenn du auch noch Hallsensoren hast brauchst du
das doch gar nicht. Die Hallsensoren geben dir doch schon einen Winkel.
Wie du schon gesagt hast kannst du mit den Hallsensoren den Sektor
bestimmen. Und du kannst den Sektor einen Winkel zu ordnen, den Winkel
in der Mitte des Sektors. Und damit initialisierst du den counter des
incremental gebers fertig. Dann hast du in der 1. Umdrehung bis zum 0
Puls einen Fehler von +-30° elektrisch. Dein nenn Moment beträgt damit
im worst case nur 87%Mn.
Alexander B. schrieb:> Eine Lösung ist wie du schon sagst den Motor zu bestromen und ihn> einrasten zulassen. Aber wenn du auch noch Hallsensoren hast brauchst du> das doch gar nicht. Die Hallsensoren geben dir doch schon einen Winkel.> Wie du schon gesagt hast kannst du mit den Hallsensoren den Sektor> bestimmen. Und du kannst den Sektor einen Winkel zu ordnen, den Winkel> in der Mitte des Sektors. Und damit initialisierst du den counter des> incremental gebers fertig. Dann hast du in der 1. Umdrehung bis zum 0> Puls einen Fehler von +-30° elektrisch. Dein nenn Moment beträgt damit> im worst case nur 87%Mn.
ach soo, also wenn ich anhand der Hallsensoren z.B. im Sektor 1 bin,
dann nehme ich einfach mal an, dass mein Winkel 30° ist. OK klingt
plausibel ;-)
übrigens habe ich nie richtig verstanden, wie man denn eigentlich nach
der inversen Park-Transformation auf die Schaltzeiten der PWM kommt. Ich
hab nochmal alles durchgelesen und eine Simulation in Matlab gemacht,
womit man die PWM-Signale sieht, sowie die ausgegebenen
Spannungsvektoren und die gemittelte Spannung an den Phasen. In der
Beilage 2 animierte GIFs, wie das aussieht (Popokurven). Man kann schön
die beiden PWM-Varianten unterscheiden. 'popo2.gif' müsste meiner
Meinung nach effizienter sein, da dort einer der FETs während 120° gar
nie umschalten muss.
Die Simulation (m-File, sollte auch in Octave laufen) erzeugt in der
alpha-beta Ebene einen rotierenden Zeiger; aus dem Winkel wird der
gegenwärtige Sektor bestimmt und die Schaltzeiten für die Vektoren
bestimmt. Danach wird der Mittelwert von dieser PWM berechnet und
geplottet, und es wird eine Vektoraddition der 3 Einheitsvektoren
vorgenommen. Man sieht, wie die Vektoraddition der 3 Ausgangsspannungen
wieder den ursprünglichen Zeiger ergibt.
Im linken Teil des Plots sind die PWM-Signale dargestellt; oben rechts
die 3 Ausgangsspannungen sowie die Spannung am Sternpunkt. Rechts in der
Mitte sind die Spannungen zwischen den Phasen, sowie gestrichelt
diejenigen Spannungen, die eine inverse Clarke-Transformation ausgeben
würde.
Würde man eine vektorielle Addition der 3 gestrichelten Spannungen
vornehmen, dann käme wiederum genau der selbe rotierende Zeiger heraus,
wie wenn man die 3 SVPWM Spannungen addiert.
Eine Frage, die ich mir noch überlegt habe, ist, wie man bei der FOC den
Motor rückwärts laufen lassen könnte. Würde es dazu wohl genügen, einen
negativen Wert für q vorzugeben? den Wert für d belässt man ja bei 0.
Grüsse
Tobias
Tobias P. schrieb:> übrigens habe ich nie richtig verstanden, wie man denn eigentlich nach> der inversen Park-Transformation auf die Schaltzeiten der PWM kommt. Ich> hab nochmal alles durchgelesen und eine Simulation in Matlab gemacht,> womit man die PWM-Signale sieht, sowie die ausgegebenen> Spannungsvektoren und die gemittelte Spannung an den Phasen. In der> Beilage 2 animierte GIFs, wie das aussieht (Popokurven). Man kann schön> die beiden PWM-Varianten unterscheiden. 'popo2.gif' müsste meiner> Meinung nach effizienter sein, da dort einer der FETs während 120° gar> nie umschalten muss.
Grundsätzlich hast du recht aber du belastest die Fets ungleich mäßig.
Das muss man ggf. in der Kühlung beachten. Generell lohnt sich Flat Top
oder Flat Bottom Modulation nur bei Netzumrichtern also bei Brücken die
ins Netz einspeisen. Bei Antriebsumrichtern wage ich zu behaupten ist
nur die klassische SVPWM Modulation zu finden.
Tobias P. schrieb:> Die Simulation (m-File, sollte auch in Octave laufen) erzeugt in der> alpha-beta Ebene einen rotierenden Zeiger; aus dem Winkel wird der> gegenwärtige Sektor bestimmt und die Schaltzeiten für die Vektoren> bestimmt. Danach wird der Mittelwert von dieser PWM berechnet und> geplottet, und es wird eine Vektoraddition der 3 Einheitsvektoren> vorgenommen. Man sieht, wie die Vektoraddition der 3 Ausgangsspannungen> wieder den ursprünglichen Zeiger ergibt.> Im linken Teil des Plots sind die PWM-Signale dargestellt; oben rechts> die 3 Ausgangsspannungen sowie die Spannung am Sternpunkt. Rechts in der> Mitte sind die Spannungen zwischen den Phasen, sowie gestrichelt> diejenigen Spannungen, die eine inverse Clarke-Transformation ausgeben> würde.> Würde man eine vektorielle Addition der 3 gestrichelten Spannungen> vornehmen, dann käme wiederum genau der selbe rotierende Zeiger heraus,> wie wenn man die 3 SVPWM Spannungen addiert.
Immer wieder diese dämlichen Sektor Implementierungen von 1980. Ich hab
dein m file mal modifiziert. So macht man das heute. 5 Zeiler fertig.
Tobias P. schrieb:> Eine Frage, die ich mir noch überlegt habe, ist, wie man bei der FOC den> Motor rückwärts laufen lassen könnte. Würde es dazu wohl genügen, einen> negativen Wert für q vorzugeben? den Wert für d belässt man ja bei 0.
Bingo. Genau deshalb macht man diesen Spaß mit der FOC damit die
Maschine sich wie eine Gleichstrommaschine verhält. Iq prop. Drehmoment.
Negativer Iq = Negatives Drehmoment.
Alexander B. schrieb:> Immer wieder diese dämlichen Sektor Implementierungen von 1980. Ich hab> dein m file mal modifiziert. So macht man das heute. 5 Zeiler fertig.
LOL, sehr gute Modifikation. SO habe ich das noch nirgends implementiert
gesehen, man findet wirklich immer nur diese "Sektor-Implementierungen
von 1980"!
OK wenn man Hallsensoren noch verwendet muss man ja sowieso irgendwie
den Sektor bestimmen, denke ich, dann würde es nicht so viel ausmachen,
ABER deine Implementierung ist WESENTLICH eleganter! wie kann man das
herleiten?
und: gibt es deine Variante auch für Flat Top / Flat Bottom?
Edit: etwas fällt mir bei deiner Implementierung aber doch noch auf.
Nämlich ist die Amplitude kleiner, weil der Duty cycle gar nie (fast) 1
wird sondern irgendwie begrenzt ist. Weshalb ist das so?
Das muss an der Umsetzung mit der PWM liegen. Ggf. Erreicht er das
letzte Digit nicht? In der realen Implementierung läuft der Algorithmus
von 0-100% und auch in die Übermodulation (Abflachung der Popos weil der
Spannungsvektor zulang ist) hinein.
Flat bottom und top geht auch. Anstelle des mean aus min und max nimmst
du nur max bzw. Min. Für die Modulation
Alexander B. schrieb:> Das muss an der Umsetzung mit der PWM liegen. Ggf. Erreicht er das> letzte Digit nicht?
ich habs grad rausgefunden. Man muss statt mit 0.5 mit 0.577
multiplizieren (sqrt3/3). Dann geht der Duty Cycle von 0 bis 100%!
Kannst du noch etwas genauer erklären, was die Gründe sind, dass man
Flat Bottom nur bei netzbetriebenen Umrichtern zur Einspeisung braucht?
ja, weiter oben hast du gesagt, die FETs würden ungleich belastet,
aber...
... es kommt ja jeder mal dran, immer einer macht Pause
... das Problem tritt ja dann bei Netzbetrieb genauso auf.
Tobias P. schrieb:> muss statt mit 0.5 mit 0.577 multiplizieren (sqrt3/3). Dann geht der> Duty Cycle von 0 bis 100%!
Klar. Weil das ganze auf 1 normiert ist. In meiner normalen
Implementierung liegt der Faktor in der Begrenzung des
sollspannungsvektors.
Tobias P. schrieb:> Kannst du noch etwas genauer erklären, was die Gründe sind, dass man> Flat Bottom nur bei netzbetriebenen Umrichtern zur Einspeisung braucht?> ja, weiter oben hast du gesagt, die FETs würden ungleich belastet,> aber...>> ... es kommt ja jeder mal dran, immer einer macht Pause> ... das Problem tritt ja dann bei Netzbetrieb genauso auf.
Komplett weiß ich das auch nicht. Aber ein wichtiger Punkt ist noch die
Mittenspannung und ihre Frequenzanteile. Oder einfach gesagt EMV. Bei
einem netzumrichter gehst du direkt ans gegen Erde referenzierte Netz
und deine Brücke wandert im Potential. Bei einem Antriebsumrichter
floatet das Motorkabel und der Stator des Motors selbst. Die Brücke des
Netzumrichters ist im Gehäuse und entsprechend designed um EMV
Anforderungen an das Gerät einzuhalten. Beim Antriebsumrichter musst du
dafür das Motorkabel schirmen und den Motor. Außerdem hast du je nach
Modulation mehr Ableitströme gegen Erde durch die Schirmung. I=C*dU/dt,
die Ecken in der Mittenspannung der flat Modulationen sind da deutlich
schlimmer als der immer gleiche Dreieck der SVPWM.
Phasenspannung_Variante_1.jpg
(33 KB)
Phasenspannung_Variante_2.jpg
(34 KB)
volle__bersteuerung.jpg
(33 KB)
