BLDC Regelung

[bert89]

Hallo Ikarus,

sorry, mit dem Motormodell habe ich mich bisher nicht befasst. Ich habe in meiner Anwendung Sensoren, d.h. ein Drehgeber und Hallsensoren, daher habe ich mir das gar nie überlegt.
Aber ich schaus mir nachher an, vielleicht kann ich dir trotzdem ein wenig weiter helfen.
Dafür kannst du mir auch was verraten

Oder besser gesagt 2 Dinge.

1. Mein Drehgeber liefert mir einen Wert zwischen 0 und 1024 für die Rotorposition. Ich habe mir eine Lookuptable gemacht für sin und cos, die grade die 1024 Werte aufnimmt. Zwar hat mein Mikrocontroller eine FPU, aber sin und cos möchte ich dann doch nicht in Echtzeit rechnen müssen So, also, die Clarke und Park Transformation sowie deren Inverse sind jetzt mit dieser Tabelle lauffähig. Ich rechne alles in floating point (weiss zwar nicht ob es nötig ist, Integer würde wohl auch reichen). So, ich messe ia, ib und ic, gehe damit über Clarke zu alpha und beta über, und mit Park erhalte ich d und q. Dann regle ich (das ist der einfachste Teil von allen ) und dann wird mit inverser Parktrafo nach alpha und beta transformiert, mit clarke erhalte ich wieder ia, ib, und ic. Jetzt ist die Frage: wie berechne ich nun aus diesen Werten den Duty cycle für meine PWM? Es ist eine Center aligned PWM mit 10 Bits Auflösung. Mit Hilfe der Hallsensoren kann ich ja den Sektor bestimmen, aber dann?

2. Wie soll ich die Ströme in den Phasen messen. Zwar kann ich meinen ADC mit den Timern synchronisieren, aber ich möchte zwei Motoren ansteuern, der ADC lässt sich aber nur von einem Timer triggern, was ein bisschen unschön ist..... Hast eine Idee? Ich habe bei jedem lowside FET einen Shunt mit Differenzverstärker. Ich habe mir überlegt, da ein kleines Tiefpassfilter einzubauen, damit der OpAmp die PWM nicht "sieht" und dann so auf den Mikrocontroller zu gehen und einfach "irgendwann" zu messen, durch das Tiefpass kriege ich ja dann so eine Art Mittelwert, der ja auch meinem Strom entspricht. Meinst du, das würde gehen?

Gruss

[ikarus_177]

Hallo bert89!

1.) Mit der PWM kannst du ja primär die drei Phasenspannungen ausgeben, eigentlich sollen ja aber die Ströme beeinflusst werden. Nach meinem derzeitigen Verständnis des Themas sollte das aber kein Problem sein, da ja Spannung und Strom nur durch eine konstante Phasenverschiebung getrennt sind (im Idealfall 90°). Soll heißen, du gibst einen um 90° dem gewünschten Stromvektor vorauseilenden Spannungsvektor aus (bitte korrigieren, falls falsch - ist einfach nur so daherüberlegt!).
Dafür gibt es jetzt mehrere Möglichkeiten (siehe AN955): einerseits die "straightforward"-Methode, bei der du einfach gemäß dem gewünschten Spannungsvektor (resultiert in drei eindeutigen Phasenspannungen) verschiedene Spannungen an die Phasen legst (einfach durch unterschiedliche PWM-dutycycles).
Zweitens gibt es die Raumzeigermodulation, die lt. AN955 eine bessere Ausnutzung der Zwischenkreisspannung (bzw. DC-Speisespannung) mit sich bringt. Die Raumzeigermodulation ist dort auch gut beschrieben. So wie ich die Grafiken verstehe, benötigt man bei dieser Art als primäre Eingangsgröße nicht die geforderten Phasenspannungen/Phasenströme sondern kann direkt mit alpha und beta arbeiten, wodurch die letzte Rücktransformation obsolet wird (stimmt das?).

2.) Hmmm, ein Tiefpassfilter erzeugt immer auch eine Phasenverschiebung, die bei höheren Drehzahlen schnell unangenehm werden kann (ich hatte zuvor die klassische Brushlessregelung mit Blockkommutierung versucht; da zeigte sich bei hohen Drehzahlen - die für meinen Quadrocopter unerlässlich sind - eine Verschiebung des Kommutierungszeitpunktes und somit eine Verschlechterung des Wirkungsgrades).
Andere Frage: welchen Controller/DSP verwendest du? Beim dsPIC33FJMC202 (den ich verwenden werde) lässt sich der ADC über die PWM-Einheit triggern, d.h. es wird in der Mitte jeder PWM-Periode (center-aligned) gesampled. Wenn du dir jetzt einen Controller mit ausreichend vielen PWM-Kanälen für 2 Motoren suchst und alle center-aligned betreibst, kannst du problemlos zum optimalen Zeitpunkt messen.
Allerdings ist wohl die Rechenleistung, die der ganze Algorithmus braucht, nicht zu unterschätzen (lt. AN1078 ca. 21MIPS für 20kHz-PWM).

Schöne Grüße!

[bert89]

Hallo Ikarus,

ja ich denke deine Aussage über die letzte Rücktransformation dürfte korrekt sein. Wie man nun aber von Alpha und Beta auf die drei Duty Cycles kommt, das verstehe ich noch immer nicht!

Wegen des Tiefpassfilters. Die Phasenverschiebung dürfte relativ gering sein, da das Filter ja eine Grenzfrequenz von einigen kHz hat, und die Frequenz des Motors ja relativ gering ist (einige 100Hz wohl) dürfte das doch passen. Oder nicht?

Das Problem ist, dass in dem Lowside Shunt der Strom auch negativ werden kann, d.h. man benötigt eine bipolare Strommessung, was auch recht haarig wird denke ich

Der Algorithmus ist allerdings nicht so komplex, dünkt es mich; ich benutze einen DSP mit 160 MHz Takt und Floatingpoint Unit. So kann ich die Clarke, Park und deren inverse Transformationen in knapp einer Mikrosekunde rechnen, das passt. Für sin und cos habe ich eine Lookuptable, die auch direkt zur Auflösung meines Drehgebers passt

[ikarus_177]

Hi bert!

Zur Dutycycle-Berechnung mit Raumzeigermodulation: sieh dir mal die Gleichungen auf S. 4 von AN955 an.

Zur bipolaren Strommessung: ich zitiere wieder AN1078 bzw. den Schaltplan dazu - dort ist die Strommessung so realisiert (die Anschlüsse links kommen von den Shunts, davon messen die oberen beiden direkt 2 der 3 Phasenströme (der dritte kann ja daraus berechnet werden), der untere den Gesamtstrom - der Komparator rechts unten gibt ein Überstromsignal an den Controller zurück):


Zum Tiefpassfilter: da hast du wohl recht (ich hab' nachgesehen - mein Tiefpass hatte eine Grenzfrequenz von um 350Hz), käme auf einen Versuch an. Für die maximal geforderte Kommutierungsfrequenz spielt neben der max. gewünschten Drehzahl aber auch die Polpaarzahl des Motors eine Rolle.

OK, da ist dein Controller natürlich ein paar Nummern größer als meine Plattform, da sollte das schon hinhauen

Schöne Grüße!

[bert89]

Hallo Ikarus

danke für deinen Schaltplan. Ich habs mittlerweile auch rausgefunden wie ich es machen kann und bin auf dieselbe Lösung gekommen

Die Berechnungen der Dutycycles schaue ich mir grade an. Ich frage mich gerade, ob ich es wirklich wagen soll, die FOC zu implementieren. Das ist nämlich ein Semesterprojekt an meiner FH, und ich muss zuerst alle Konzepte etc. entwickeln, jetzt habe ich noch keine Hardware, wo ich das alles richtig testen kann. Zwar rechnet mein DSP recht locker mit Floatingpoint rum (Takt 160 MHz), aber ich möchte zwei BLDC-Motoren regeln, d.h. es sind insgesamt 4 digitale Regler zu implementieren (je einer für d und q). Dann noch ein überlagerter Drehzahlregler pro Motor, gibt 6 zu implementierende Regelkreise.
Auf der englischen Wikipedia habe ich soeben noch gelesen, dass für eine gescheite feldorientierte Regelung der Regler alle 1ms ausgeführt werden soll - mindestens. Das packt mein Controller zwar schon, aber ob es dann reicht?

Bisher habe ich immer mit Blockkommutierung gearbeitet und habe damit einige Erfahrung; ich wollte aber schon immer mal FOC machen, und da ich in diesem Projekt die Motoren besonders genau regeln möchte, dachte ich das wär eine gute Idee

Ich denke ich werde mal meine Hardware dann so planen, dass ich FOC machen kann, aber erst werde ich Blockkommutierung implementieren und dann wenn die Zeit noch reicht auf feldorientiert wechseln. Hmm.... Okay aber das ist eine andere Baustelle.



EDIT:
habe soeben die Gleichungen in der AN995 angeschaut. Diese kenne ich bereits Da gibt es aber ein Problem:
Zwar stehen da schon Gleichungen für TA und TB, aber da kommt noch der Winkel Psi vor, also der Winkel den der auszugebende Vektor mit der reellen Achse bildet. Nun, Psi kenne ich ja nicht... Ich habe nur d und q, bzw. nach der inversen Park-Transformation alpha und beta. In alpha und beta ist Psi ja implizit gegeben; muss ich da wirklich mit trigonometrischen Funktionen noch den Winkel ausrechnen? Wenn das so ist, erscheint mir dies recht verwegen, auch auf einem DSP. Dazu wäre ja ein arctan() nötig -- der braucht Rechenleistung ohne Ende :-/

[ikarus_177]

Hallo!

Ich hab' mir mal den entsprechenden Codeteil der AN1078 angesehen - wie es scheint wird die inverse Clarke-Transformation doch noch ausgeführt, d.h. ins 3-Achsen-System zurückgerechnet.
Die Gleichungen zur Berechnung der PWM-Werte aus den Werten für die 3 Phasen scheinen sehr sehr einfach zu sein und enthalten keine Winkelfunktionen. So ganz verstehe ich den Lösungsweg aber noch nicht

Der folgende Code ist eine C-Übersetzung des eigentlichen Codeteils, der in Assembler geschrieben ist. Alle verwendeten Variablen scheinen global zu sein.

void CalcRefVec( void )
{ 
    if( Vr1 >= 0 )
        {       
        // (xx1)
        if( Vr2 >= 0 )
            {
            // (x11)
            // Must be Sector 3 since Sector 7 not allowed
            // Sector 3: (0,1,1)  0-60 degrees
            T1 = Vr2
            T2 = Vr1
            CalcTimes();
            dPWM1 = Ta
            dPWM2 = Tb
            dPWM3 = Tc
            }
        else
            {            
            // (x01)
            if( Vr3 >= 0 )
                {
                // Sector 5: (1,0,1)  120-180 degrees
                T1 = Vr1
                T2 = Vr3
                CalcTimes();
                dPWM1 = Tc
                dPWM2 = Ta
                dPWM3 = Tb

                }
            else
                {
                // Sector 1: (0,0,1)  60-120 degrees
                T1 = -Vr2;
                T2 = -Vr3;
                CalcTimes();
                dPWM1 = Tb
                dPWM2 = Ta
                dPWM3 = Tc
                }
            }
        }
    else
        {;        // (xx0)
        if( Vr2 >= 0 )
            {
            // (x10)
            if( Vr3 >= 0 )
                {
                // Sector 6: (1,1,0)  240-300 degrees
                T1 = Vr3
                T2 = Vr2
                CalcTimes();
                dPWM1 = Tb
                dPWM2 = Tc
                dPWM3 = Ta
                }
            else
                {
                // Sector 2: (0,1,0)  300-0 degrees
                T1 = -Vr3
                T2 = -Vr1
                CalcTimes();
                dPWM1 = Ta
                dPWM2 = Tc
                dPWM3 = Tb
                }
            }
        else
            {            
            // (x00)
            // Must be Sector 4 since Sector 0 not allowed
            // Sector 4: (1,0,0)  180-240 degrees
            T1 = -Vr1
            T2 = -Vr2
            CalcTimes();
            dPWM1 = Tc
            dPWM2 = Tb
            dPWM3 = Ta

            }
        }
}


void CalcTimes(void)
{
    T1 = PWM*T1
    T2 = PWM*T2
    Tc = (PWM-T1-T2)/2
    Tb = Ta + T1
    Ta = Tb + T2
}

Der Teil, in dem der Sektor bestimmt wird ist ja noch verständlich, die drei ersten Gleichungen von CalcTimes() ja auch - die beiden nächsten verstehe ich aber überhaupt nicht, vor allem, da anscheinend die Zeitwerte der vorhergehenden Berechnung ebenfalls eine Rolle spielen...

Schöne Grüße!

[bert89]

Hmm also so ganz blick ich das nicht. Warum nur wird das so mystifiziert, wie man diesen Duty cycle berechnet?

Gut, im Prinzip ist es ja einfach: aus Alpha und Beta kann der Winkel berechnet werden. (Dieser müsste mit dem vom Drehgeber gelieferten Winkel übereinstimmen, oder?)
Anhand des Winkels bestimmt man den Sektor, und danach berechnet man den Winkel innerhalb des Sektors. Anschliessend ist

t1 = sin(60 - x)
t2 = sin(x)

die Zeiten für Vektor 1 und Vektor 2, wobei x der Winkel in diesem Sektor ist.

Beispiel:

Winkel des Rotors sei 70°. Dies ist im Sektor 2. Also subtrahiere man 60°, man erhält 10°. Somit ist

t1 = sin(50°) = 0.766
t2 = sin(10°) = 0.173

die Zeit für den Anfangs- und den Endvektor. Der Nullvektor muss während der Zeit

1 - t1 - t2 = 0.061

ausgegeben werden.

Das ist alles schön und gut und auch sehr trivial, aber

a) was mache ich denn nun mit alpha und beta, die benötige ich ja gar nicht, denn den Winkel kann ich ja auch vom Drehgeber ablesen
b) irgendwie ist das doch ein wenig komisch, innerhalb jedes Sektors immer dieselben Winkel wieder zu berechnen -- das sollte doch auch einfacher gehen, direkt mit alpha und beta, denn diese geben den winkel doch implizit an, oder nicht?

Gruss

[Christian84]

Moin alle zusammen,

ich wollte dieses Thema mit der Regelung der Geschwindigkeit eines BLDC aufgreifen. Es geht um die feldorientierte Regelung.


Wenn ich einen BLDC in Blockkommutierung betreibe, verstelle ich die Geschwindigkeit, indem ich die Spannungshöhe mit der PWM-Duty verändere.

Wie funktioniert es aber bei der feldorientierten Regelung? Wenn ich 2 verschiedene Geschwindigkeiten haben möchte, muss ich dann doch auch 2 verschiedene Spannungshöhen erreichen oder ?


VIelen Dank im Voraus

Christian

[robin]

Du hast durch deine drei Spulen, die du ja einzeln bestromen kannst, 6 (durch die polarität) verschiedene Vektoren (A, A', B, B', C und C'). Wenn alle drei Spulen die selbe Potential haben, dann hast du auch noch die beiden Nullvekroten.

Für die Rotation musst du A, A', B, B', C und C' kombinieren, sollte denk ich klar sein. Für die Spannungshöhe kommt dann noch der Nullvektor, also alle oberen oder unteren Transistoren an, ins Spiel. Für die halbe Spannung musst du entsprechend die halbe Zeit noch den Nullvektor anlegen.

E: Auch mal bei Wikipedia geschaut? Wird da mMn. recht gut erklärt.
http://de.wikipedia.org/wiki/Raumzeigermodulation