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

void ParkInv(struct McParm *pM)
{
  //Spannungsvektor Phase ist phU
  int icos=Cosinus(pM->teta + pM->phU);
  int isin=Sinus(pM->teta + pM->phU);
  //Spannungsektorbetrag wäre MagU
  pM->valpha=(int)((long long int)pM->MagU*(long long int)isin))>>32);
  pM->vbeta =(int)((long long int)pM->MagU*(long long int)icos))>>32);
}

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.

// das Ergebnis wird in pM->valpha und pM->vbeta gespeichert
// das >>32 anstelle >>31 bedeutet, dass valpha und vbeta durch
// 2 geteilt wird um ein ?berlauf des Wertebereiches zu verhindern
void ParkInv(struct McParm *pM)
{
  int icos=Cosinus(pM->teta);
  int isin=Sinus(pM->teta);
  pM->valpha=(int)((((__int64)pM->vD*(__int64)icos)-((__int64)pM->vQ*(__int64)isin))>>32);
  pM->vbeta =(int)((((__int64)pM->vQ*(__int64)icos)+((__int64)pM->vD*(__int64)isin))>>32);
}

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/...

Als Drehgeber dürfte dieser verbaut sein:
http://www.maxonmotor.ch/maxon/view/product/sensor...

(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-mot...
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

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

int qV1 = va;
int qV2 = -(va>>1) + vsq3h; 
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 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...

Vielleicht weist du ja, wie dieser Effekt zustande kommt?

Viele Grüße,
Adrian