BLDC Regelung

[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

[ikarus_177]

Hallo!

Der Winkel, der durch alpha und beta (im Grunde ja das Ergebnis der ganzen Regelung), ist (bzw. sollte) ein "bisschen" größer als der aktuelle Winkel vom Drehgeber sein. Du willst ja den Rotor im Vergleich zur aktuellen Position um ein Stückchen weiterbewegen.
Würdest du den Winkel vom Drehgeber nehmen, könntest du dir die ganze Rechnerei gleich ganz sparen, dann würde sich der Rotor aber nie bewegen.

Das Ergebnis der Regelung (= der Winkel, der auf den Motor / die 3 Phasen gegeben werden soll) ist sicher in alpha und beta enthalten, wie genau man dann aber die PWM-Werte mit der Methode der AN1078 berechnet, weiß ich auch noch nicht so ganz...

Schöne Grüße!

[bert89]

Hallo Ikarus,

hmm stimmt eigentlich

heute in der Mittagspause war mir ein wenig langweilig, und daher habe ich nochmals ein wenig über Vektorgeomtrie nachgedacht. Ich habe mir überlegt, wie man ohne nervige Winkelfunktionen den Vektor (alpha, beta) auf die 6 Achsen vom "SV PWM Star" projizieren kann -- genau das möchte man ja tun, um die Einschaltzeiten für den Anfangs- und den Endvektor zu berechnen.
Nun, es hat sich gezeigt, dass dies recht simpel ist. Es ergeben sich so sechs 2x2 Matrizen, mit denen man einen Vektor (alpha, beta) nun so umrechnen kann. Der aktuelle Sektor gibt an, welche der sechs Matrizen zu benutzen ist. Ich habe mir mal in Excel ein Sheet erstellt, wo ich die Duty cycles mit diesen Matrizen berechne und in einem Diagramm darstelle, und siehe da, es ergeben sich diese schönen SVPWM-Kurven. (Die man, glaube ich, Supersinus nennt??)

Ich werde dann morgen schnell ein PDF hochladen, wo das beschrieben ist. Eigentlich ist es recht einfach

[schorsch_76]

Nur als Bestätigung für mich das ich das halbwegs verstanden habe, hier geht es um so eine Regelung und die 6 Sektoren die in diesem [1] [2] PDF gezeigt werden?

Gruß
Georg

[1] http://www.arpnjournals.com/jeas/res...s_0710_362.pdf
[2] http://www.ti.com/lit/an/bpra073/bpra073.pdf

[ikarus_177]

Hallo!

@bert: deine Matritzen würden mich sehr interessieren! Ich hab' auch schnell versucht, eine Umrechnung im ersten Sektor zu formulieren, hab aber noch nicht verifiziert, ob da was brauchbares herausgekommen ist...

@schorsch: ganz genau

Mittlerweile bin ich am Bestücken der Reglerplatine - bin schon gespannt auf die ersten Testläufe mit dem Motor!

Schöne Grüße!

[schorsch_76]

Hab hier noch ein Appnote [1] von Atmel gefunden das auf die Kommutierung und PWM eingeht.

[1] http://www.atmel.com/Images/doc7518.pdf

[bert89]

Also, die nötigen Matrizen für die Projektion eines (alpha, beta) - Vektors auf die SVPWM-Achsen lauten wie im beigefügten Bild.
Ich hoffe ihr seid mit der Matrizenrechnung vertraut



Die Berechnung erfolgt dann wie folgt: Man multipliziert die Matrix mit dem Vektor (alpha, beta). Heraus kommt der Vektor (t1, t2), der die Projektion von (alpha, beta) auf die Achsen darstellt. Die Matrizen habe ich selber hergeleitet, ich habe die bisher noch nie so gesehen, aber es ist eigentlich einfach darauf zu kommen, ist nur ein wenig Vektorgeometrie

[ikarus_177]

Hallo!

Danke für das Bild!
Da war meine Herleitung ja doch äquivalent zu deiner - ich hab' nur die Matritzenschreibweise nicht benutzt und die Vorfaktoren ausgeschrieben.

Freut mich - das hat doch einiges zur Klärung des "Mysteriums" SVM beigetragen

Schöne Grüße!