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.
Angehängte Dateien:
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
1 | void ParkInv(struct McParm *pM) |
2 | {
|
3 | //Spannungsvektor Phase ist phU |
4 | int icos=Cosinus(pM->teta + pM->phU); |
5 | int isin=Sinus(pM->teta + pM->phU); |
6 | //Spannungsektorbetrag wäre MagU |
7 | 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
Angehängte Dateien:
-
Sternpunkt_Variante_1.jpg
36 KB -
Sternpunkt_Variante_2.jpg
33 KB
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.
Angehängte Dateien:
-
bldcPhase.png
12 KB
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
|
4 | void ParkInv(struct McParm *pM) |
5 | {
|
6 | int icos=Cosinus(pM->teta); |
7 | int isin=Sinus(pM->teta); |
8 | pM->valpha=(int)((((__int64)pM->vD*(__int64)icos)-((__int64)pM->vQ*(__int64)isin))>>32); |
9 | pM->vbeta =(int)((((__int64)pM->vQ*(__int64)icos)+((__int64)pM->vD*(__int64)isin))>>32); |
10 | }
|
dann gehts auch.
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 | int vsq3h=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 | int qV1 = va; |
2 | int qV2 = -(va>>1) + vsq3h; |
3 | int qV3 = -(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 zusammen, hab mal die oben veröffentlichte datei erweitert. bitte um kritik und weitere inspirationen
Hallo Jürgen, ich habe bei der Ansteuerung von BLDC folgendes Problem: Beitrag "BLDC Direct-Drive Servo - Sinus Positionsregelung" Vor kurzem habe ich deinen Code mit einem LPCExpresso 1796 ausprobiert um herauszufinden ob es an meiner Art der Ansteuerung liegt. Allerdings tritt mit deinem Code exact dasselbe Phänomen auf. http://www.youtube.com/watch?v=1RSOzZ6Stwk&feature=youtu.be Vielleicht weist du ja, wie dieser Effekt zustande kommt? Viele Grüße, Adrian
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
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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.
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.