Dieser Thread wurde ausgelagert aus folgender Diskussion zum Thema Umrichter für E-Kart Anwendung: Beitrag "Umrichter für E-Kart Anwendung 60V / 120A" und bezieht sich auf folgende Fragestellung: [..] 1.) Was mich persönlich noch interessieren würde: wie hast du die SVPWM für den BLDC realisiert? [...] Hingegen beim BLDC musst du ja die Rückmeldung vom Motor (sprich eben die Rotorposition) berücksichtigen, und ich frage mich grade, wie man z.B. die Hallsensor-Signale mit der RZM "verknüpft". Ich nehme einfach mal an, dass die Hallsensoren den "Sektor" (siehe Artikel "Frequenzumrichter mit Raumzeigermodulation") vorgeben, welcher grade aktiv ist. 2.) Werden die Ansteuersignale dann hardwaremässig generiert oder so wie im genannten Artikel per SW? 3.) Und - benutzt du Hallsensoren oder die BEMF, und wenn letzteres: wie lässt du den Motor anlaufen? [..] Hi, also zu 1.) Ich habe die SVPWM als Matlab/Simulink Modell aufgebaut. Als Eingangssignale benötigt die Software den elektrischen Winkel des Rotors und den Betrag des Raumzeigers (Sollwert). In Folge wird dann der Sector und Sectorwinkel bestimmt. Dann mittels Trigonometie die Beträge der verschiedenen Einschaltzeiten der jeweiligen Spulen berechnet. Ausgangssignal SVPWM ist der Dutycycle pro Phase. Das ganze habe ich mit dSPACE TargetLink in fixed-point-arithmetik skaliert und anschließen in ANSI-C Code gewandelt. zu 2.) Hardwareseitig gehen die 3/6 Phasen PWM auf entsprechende Halbbrücken die jede Phase treiben. zu 3.) Ich verwende einen AS5134 zur Bestimmung der Absolutposition und habe eine Interpolationsroutine um aktuell auch bei Drehzahlen bis zu 9000/min noch genug Messwerte liefert um das Feld entsprechend genau zu stellen. Grüße, Toby
Hi toby, Also grundsätzlich verstehe ich dein Vorgehen schon. Allerdings sind für mich Dinge wie dSPACE, TargetLink oder Simulink Fremdwörter :-( wenn ich einen SVPWM-Algorithmus implementiere, benutze ich dazu Excel, das geht auch ;-) Also, wie gesagt - grundsätzliches Vorgehen ist bekannt, ABER: bei "normaler" SVPWM wird das ja wie folgt gemacht: - 1 Sektor = n Schritte - Ein Timer läuft und zählt den Umlaufwinkel Omega hoch - Anhand von Omega und des aktuellen Sektors werden die Einschaltzeiten für jede Phase berechnet (z.B. mittels Sinustabelle) - Wenn Omega = n, dann wird in den nächsten Sektor gewechselt und die Einschaltzeiten neu berechnet; zudem wird Omega = 0 gesetzt. Soweit ist das Vorgehen also klar; Aber wo kommen nun diese Hallsensoren ins Spiel? Wie ich bereits angedeutet habe, nehme ich einfach mal an, dass die Halsensoren den Sektor vorgeben. In meiner Vorstellung wird dann wie folgt vorgegangen: - 1 Sektor = n Schritte - Mittels Timer wird die Zeit t gemessen, in der ein Sektor aktiv ist - Ein weiterer Timer wird dann so konfiguriert, dass er alle t / n Sekunden aktiv ist und Omega hochzählen kann. Anhand von Omega werden dann die Einschaltzeiten der Phasen berechnet - Wenn Omega = n, dann wird in den nächsten Sektor gewechselt, und der Timer, welcher die Sektordauer misst, wird zurückgesetzt Das Problem bei diesem Vorgehen ist natürlich, dass der Motor bereits drehen muss, damit man ihn korrekt kommutieren kann. Das kann ich mir aber irgendwie nicht vorstellen, denn so könnte man den Motor ja nicht "hochfahren", ausserdem hätte man wohl einen Drehmoment- und Drehzahlrippel, der daher rührt, dass die Berechneten Einschaltzeiten von der Zeit für einen Sektor abhängen - sprich: wenn der Motor zu Beginn steht, dann wird die Zeit t für einen Sektor unendlich lang, und somit wird die ersten Phase des Motors unendlich lange eingeschaltet, der Motor "ruckelt" kurz und steht dann in einer bestimmten Position fest. Also toby, wo liegt denn mein Denkfehler? Kannst du mir weiterhelfen? Kann man evtl. ein bisschen Code anschauen? Auf was für einem Prozessor läuft die ganze Geschichte? dSPACE und Targetlink klingen fast irgendwie nach TriCore oder irgendwas in der Richtung (jedenfalls nicht nach ARM oder einem ATMEGA; ich nehme nicht an, dass die kleinen QFP48-ATMegas, die man auf den Photos auf deiner website sehen kann für diese ganzen Algorithmen zuständig sind). Viele Grüsse Tobias
Hallo Tobias, schau dir doch mal den von mir genannten Sensor genauer an. Der liefert mit nicht den Sektor, sondern den mechanischem Winkel der Motorwelle. Mechanischer Winkel deshalb, weil die BLDCs oftmals mehrere Polradpaare besitzen. Ein BLDC mit zwei Polradpaaren macht mit einer mechanischen Umdrehung zwei elektrische Umdrehungen. Der Sensor liefert mir also einen mechanischen Winkel und daraus errechne ich mit mit Hilfe eines Offsets (Offset zwischen Rotorpositionssignal und elektrischem Nullwinkel) den aktuellen elektrischen Winkel des Rotors. Aus dem elektrischen Winkel berechne ich mir wiederum den Sektor in dem ich mich befinde und den Winkel innerhalb des Sektors. Anschließend bestimme ich mit Vektoradditionen einen Vektor, der genau Senkrecht auf dem Rotor-Vektor steht. Dieser Vektor (in der Literatur meist Iq) wird dann in die Einschaltzeiten der Spulen zerlegt. Ein Anlaufproblem ergibt sich gar nicht. Bei mir erzeugt des Feldvektor durch die Positionierung "90° auf dem Rotor-vektor" ein Moment auf den Rotor. Je nach Betrag dieses Vektors der Motor anlaufen oder bleibt eben stehen solange bis die elektische Kraft groß genug ist. Wenn sich der Rotor nicht in Bewegung setzt bleibt das Feld an dieser Stelle stehen. Erst wenn der Hallsensor eine neue Position erkannt hat, wird das Feld weiter gedreht. Gruß, Toby
Hi toby, okay soweit ist mal alles klar. Du hast also einen Sensor, der dir immer die Absolute Position des Rotors liefert. Geht denn die SVPWM bei einem solchen BLDC nur mit einem Positionssensor, oder ist es auch möglich nur unter Zuhilfenahme der Hallsensoren? (oder gar völlig sensorlos, nur anhand der BEMF). Gruss Tobias
Geht auch prinzipiell auch ohne Sensor. Aber nur mit Sensor kann ich auch im bei Stillstand des Rotor das Max-Moment bekommen. Ohne Sensor braucht man einen definierten Startup bis die BEMF auswertbar sind. Gruß, Toby
Hi toby, ja soweit klar. Jetzt mal angenommen, du hast 3 Hallsensoren, die um 120° verschobene Rechtecksignale liefern (du kennst das ja). Wie würde man es da realisieren? Da hast du ja schon beim Startup verwertbare Signale. Aber das Problem ist: Der Rotor kann innerhalb dieser 120°, um die die Sensoren versetzt sind, an jeder beliebigen Position stehen - wie willst du denn dann die richtigen Einschaltzeiten für die PWMs berechnen?
Hi, also das Prinzip mit den 3 Hall-Sensoren hat aus meiner Sicht Grenzen! die Auflösung des elektrischen Winkels ist einfach zu klein. Im Stillstand ist der mögliche Fehler groß, sodass sich das maximal mögliche Moment nicht erzeugen lässt. Für eine Absolutposition braucht man einfach genauere Sensoren, bspw.: Resolver, Inkrementalgeber, Potis, usw... Gruß, Toby
Hi toby, hmm wenn du meinst... also dann ist das wohl Essig mit 3 Hallsensoren + SVPWM einen BLDC anzusteuern. Laut einer Atmel-AppNote geht es zwar, wenn man, wie ich bereits vermutet habe, mittels eines Timers und der Messung der Zeit, die ein Hallsensor aktiv ist, den Umlaufwinkel interpoliert - aber die Genauigkeit dieses Verfahrens wird, denke ich zumindest mal, zu wünschen übrig lassen. Daher muss man offenbar bei BLDCs wirklich einen Resolver (oder ein Drehgeber würde m. E. auch reichen) benutzen - oder aber den Motor konventionell mit einer Blockkommutierung ansteuern (welche ja eigentlich auch nicht schlecht funktioniert). Nachteil der Blockkommutierung ist dann wohl einfach der Drehmomentrippel, aber dafür ist sie recht simpel. Ich meine - mit Blockkommutierung könnte man den BLDC wirklich mit reiner Logik ansteuern; ein Controller wäre nur noch für die Regelung nötig. Gruss Tobias
Also für Anwendungen wo es nicht auf glattes Drehmoment ankommt ist die Trapezförmige Ansteuerung schon in Ordnung. Für ein Fahrzeug is das aber suboptimal. Was aus meiner Sicht ganz gut funktionieren kann ist die Kombi aus 3 Hallsensoren und einem Inkrementalgeber... Nach einem Referenzlauf kann man ziemlich genau steuern. Da bleibt viel Raum für Engineering ;)
hi toby, also das mit den Hallsensoren + Inkgeber ist ansich schon ne gute Idee. Allerdings - wozu braucht man eine Referenzfahrt? Ich meine, wenn man weiss wie viele Inkremente der Geber liefert pro Umdrehung kann man ja auch ausrechnen, wie viele Inkremente es sind pro Sektor. Ah, mich juckts in den Fingern, das mal auszuprobieren. Wenn ich demnächst einen Inkgeber autreiben kann, werde ich sowas mal aufbauen... Mal ne Frage, hast du irgend eine Doku oder sowas dazu, wo die SVPWM beim BLDC erklärt ist? Wie gesagt - ich hatte sowas bereits erfolgreich implementiert für DAMs, was super läuft und sehr schöne sinusförmige Ströme liefert. Allerdings bin ich mir noch nicht so ganz im Klaren darüber, wie es denn mit dem Inkgeber ablaufen soll. Irgendwie ist das dann ja total einfach. Jetzt mal angenommen, der Inkgeber ist so mit dem Mikrocontroller verdrahtet, dass er automatisch ein bestimmtes Register hoch zählt - dann müsste man ja theoretisch nur anhand der Hallsensoren den Sektor bestimmen und anhand des Inkgeberwerts die richtigen Timings aus einer Tabelle lesen. Oder nicht? Wie macht das dein Programm?
Ich hab meine SVPWM-SW auch mal mit einem Inkrementalgeber getestet. Dazu einfach eine Spule bestromen sodass sich der Rotor ausrichtet. Dann den Impulszähler löschen und entsprechend der Drehrichtung neue Impulse addieren oder subtrahieren. Somit kennt man die Rotorposition recht genau. Zur Plausibilisierung bzw. zum Aufsynchronisieren kann man den Zählerstand von Inkrementgeber mit einer bekannten Flanke vom Hallsensor vergleichen und entsprechend handeln. Gruß, Toby
Hi toby, du nochmal ne Frage. Und zwar hast du ja gesagt, dass du das Feld immer so ausrichtest, dass es in einem Winkel von 90° zum Roto steht, damit du maximales Moment hast. Also "eilt" das Feld dem Rotor im Prinzip um 90° "vor", oder? Hierzu habe ich noch eine Frage. Ich hab das jetzt mal so verstanden, dass man für eine FOC im Prinzip eine "gewöhnliche" RZM macht, aber die absolute Position des Rotos berücksichtig und das Feld so steuert, dass es immer diesen 90° Winkel hat. Richtig? Kann ich dann meinen bereits bestehenden RZM-Algorithmus einfach so umbauen, dass er anhand des Drehgebers die aktuelle Rotorposition bestimmt, 90° dazu addiert und dann anhand dieses Ergebnisses die passenden Schaltzeiten für die PWM berechnet?
Ja das geht so prinzipiell schon. Für eine FO-Regelung fehlt aber die Stromrückmessung für die Regelung. Google mal im Netz nach FOC, da findest Du haufenweise Application Notes von TI und anderen Chipherstellern. Grüße, Toby
Hi toby,
naja, wenn ich nach FOC google, dann finde ich eine ganze Menge an PDFs,
welche zwar erklären, wie man das macht mit der Clarke und Park
Transformation, aber der Kram ist immer so wahnsinnig mathematisch
erklärt - und damit habe ich ein bisschen Mühe, denn erstens bin ich
kein Mathematiker, und zweitens habe ich das E-Technik Studium noch
nicht mal begonnen :-( Ich verstehe also nur teilweise, um was es da
immer geht. Die RZM habe ich auch nur verstanden, weil dazu hier auf der
Seite ein guter Artikel ist, wo alles erklärt ist. Und daher läuft meine
RZM auch tadellos. Der nächste Schritt wäre natürlich schon die FOC,
aber wie gesagt finde ich da keinen einigermassen verdaulichen Stoff zu
- das ist alles so höllisch kompliziert beschrieben....
Aber gut, ich versuchs.
Frage 1: Was macht die Clarke- bzw. Park Transformation und wozu
benötige ich die? kann ich das auf einem ARM7 @ 70 MHz innerhalb einer
vernünftigen Zeit rechnen? So wie es aussieht, wird da ja mit Sinus und
Cosinus rum gerechnet. In meinem RZM-Algorithmus bin ich mit zwei
Tabellen gut zurecht gekommen, aber ich bezweifle dass das für die
Clarke- und Park-Transformation auch geht, denn mit den Tabellen hat man
immer gewisse Rundungsfehler, und die Ergebnisse der Clarke- und Park
werden ja weiter verrechnet, wodurch sich der Rundungsfehler immer
weiter vergrössern würde.
Frage 2: Was hat es mit diesen d und q auf sich? In einer AppNote von
Atmel habe ich gelesen, dass man mittels der Clarke (oder war es Park?)
die 3 Phasenströme eines BLDCs in das d und q-Format umrechnen kann.
Aha.
Und was bedeutet denn das schon wieder? So wie ich das verstanden habe,
sind d und q "einfach" ein "Modell" um sich die magnetfelder im Stator
vorstellen zu können. Liege ich damit wenigstens Ansatzweise richtig?
Mann mann, das Thema ist spannend, aber der Einstieg wird einem nicht
grade leicht gemacht ;-)
Ach ja: Du sagst, prinzipiell würde meine Vorgehensweise, wie ich sie
oben beschrieben habe, funktionieren, wenn ich noch eine
Stromrückführung hätte.
Es ist natürlich klar, dass man so eine braucht - ich nehme mal an, dass
der Grund dafür der gleiche ist, wie bei den DAMs. Bei kleiner Frequenz
-> kleinerer Innenwiderstand des Motors -> höhere Stromaufnahme ->
grösseres Drehmment. Richtig? Um das Moment konstant zu halten, wird der
Strom bei der FOC gemessen, und die Pulsbreite dann derart angepasst,
dass der Strom ausreichend gross für das gewünschte Drehmoment ist. Bei
den DAMs kann man das ja mittels konstanter U/f erreichen, aber das ist
nur eine Steuerung und nicht eine Regelung, daher kann es immer noch
sein, dass das Drehmoment nicht wirklich genau stimmt (was auch bei
meiner Anwendung der Fall war; fuhr man über den ganzen Frequenzbereich
des Umrichters, so was das Moment bei kleineren Drehzahlen relativ gut,
während es gegen oben immer weiter abnahm.).
Ich hoffe du kannst mir ein wenig weiter helfen,
Viele Grüsse
Tobias
PS:
Mir ist grade in den Sinn gekommen, dass ich dazu vor langer Zeit mal
irgendwo eine AppNote gespeichert hatte auf meinem PC. Nachdem ich sie
nun wieder gefunden und studiert habe, glaube ich, ungefähr zu wissen,
um was es bei der Clarke geht.
Und zwar sehe ich das wie folgt:
Der Motor hat 3 Phasen, welche durch 3 Vektoren (eben die Raumzeiger)
dargestellt werden können. Und mittels der Clarke kann man nun einen
dieser 3 Zeiger in zwei Komponenten zerlegen (Meist als Alpha und Betag
bezeichnet), und mittels dieser wird der Betrag und die Richtung des
Zeigers eindeutig festgelegt. Da man weiss, dass die 3 Raumzeiger immer
um einen Winkel von 120° zueinander verschoben sind, und man anhand der
Komponenten Alpha und Beta einen Zeiger kennt, kann man die Restlichen
berechnen anhand dieser 120°. Ist das richtig? (Das ist erstmal einen
Annahme, die ich getroffen habe; ich bin immer noch am Lesen ;-)).
Hi, ohne das Studium und mathematisches Handwerkszeug fällt das Thema sicher nicht besonders leicht. Vielleicht fällt Dir das Verständnis der ganzen Appnotes leichter wenn Du weißt warum man diese Transformationen macht. Für die Momentenregelung von E-Maschinen ist es wichtig den Strom zu regeln weil I ~ F. Wenn man den Strom regelt, regelt man die Kraft. Wenn man jetzt von außen auf den Motor schaut mit seinen 3-Phasen, kann man von nur eine Spannung anlegen und der Strom im den Windungen fließt zeitlich veränderlich - wünschenswerter Weise in Sinusform. Der Betrag der Spannungen und der daraus resultierende Feldvektor, der an dem Rotor "zieht" ist aber nicht einfach zu ermitteln. Mit Hilfe der Transformation versetzt man sich in die Perspektive des Rotors, sodass sich der eigene Bezugspunkt mit dem Rotor mitdreht, dadurch ist es einfach den "benötigten" drehmoment erzeugenden Feldvektor zu ermitteln (meistens Iq genannt) und diesen dann mittels Rücktransformation wieder in das 3Phasen-System zu wandeln. Lies Dir auch mal ein paar Notes zu E-Maschinen durch, was Funktionsweise und Momentenerzeugung angeht... Ohne Mathe das aber leider auch nicht so einfach. Grüße, Toby
Hi toby, ja es ist mir klar dass es ganz ohne Mathe nicht geht ;-) Aber wie gesagt besitze ich ja schon einige gewisse Vorkenntnisse. Auch dass der Strom, und nicht die Spannung, für das Drehmoment verantwortlich ist, ist mir bewusst. Ich habe bereits verstanden, dass man mittels der Clarke und der Park-Transformation die 3 Phasenströme, welche auf den Stator bezogen sind, so umrechnen kann, dass sie sich auf den Rotor beziehen. Man hat dann eben d und q, wobei ich gestern dann hier erfahren habe, dass d möglichst auf 0 geregelt werden soll, während q die für das Drehmoment verantwortliche Grösse ist und geregelt werden muss. Da dieses transformierte "Koordinatensystem" mit dem Rotor mit dreht, sind d und q Grössen, welche statisch sind und somit "leicht" zu regeln sind. Was ich mich jetzt noch frage: Wenn d Verluste erzeugt und q das Drehmoment - welches ist dann die Drehzahlbestimmende Grösse? Klar, das ist schlussendlich die Frequenz, aber diese ergibt sich ja dadurch, dass der Motor sich irgendwie dreht und so die Kommutierung vorgibt. Sehe ich das richtig, dass die Drehzahl sich automatisch anhand der Belastung des Motors und eben des Drehmoments ergibt? Wenn ja q geregelt wird, dann hat man ja ein konstantes Drehmoment, was bei fehlender Last eine grosse Drehzahl ergibt und bei grosser Last nur eine kleine Drehzahl. (Das macht ja bei einem Fahrzeug wie deinem Kart Sinn; man braucht ja ein möglichst grosses Drehmoment, um zügig vom Fleck zu kommen). Was ich mich noch frage: Man misst ja die Ströme zweier Phasen, ia und ib. Diese werden mittels Clarke zu ialpha und ibeta, und anschliessend mittels Park zu id und iq. Soweit alles klar, auch die Berechnungen sind, wenn man diese Vektoren sich mal aufzeichnet, einigermassen nachvollziehbar. So, id wird dann auf 0 und iq auf den gewünschten Wert geregelt. Ich habe aber in einigen AppNotes zu dem Thema gesehen, dass bei der Rücktransformation (Park -> Clarke -> PWM) dann Spannungen, nämlich vd und vq, verwendet werden. Und mir ist nicht ganz klar, wie man aus id und iq die entsprechenden Spannungen erhält. Ergeben sich die dann etwa einfach aus der Regelung, oder muss man da noch mehr rechnen? Auf jeden Fall ist mir mittlerweile das Vorgehen schon einigermassen klar. Strom ia und ib messen, mittels Clarke zu ialpha und ibeta transformieren, dann den Rotorwinkel messen und mittels Park den Winkel, ialpha und ibeta in d und q transformieren. Dann regeln, mittels inverser Park zu ialpha und ibeta zurücktransformieren (respektive valpha und vbeta), und mittels inverser Clarke dann zu ia, ib (oder va, vb). ic (oder vc) ergibt sich automatisch, da ia + ib + ic = 0. Diese Werte kann man dann zur Berechnung der PWM heranziehen. Richtig?
Hi, hab Deine Passage überflogen. Wie es scheint hast Du die Sache schon ziemlich gut verstanden. Das mit der Drehzahl hast Du selbst korrekt hergeleitet. Allgemein ist es so - auch bei deinem Auto - dass Du mit dem Fahrpedal das Moment des Motors einstellst, nicht die Drehzahl. Sieht man daran, dass die Drehzahl hochschnellt wenn man die Last wegnimmt (auf die Kupplung steigt). zu Id. Id ist eine eigenständige Feldkomponene, die in Richtung der Feldlinien des Permanentmagneten liegen. Diese wird im Normalfall zu 0 geregelt um keine unnötige Blindleistung zu erzeugen. Es gibt aber eine Ausnahme, und das ist der Feldschwächungsbetrieb. Da nutzt man Id um das Feld des PM zu schwächen und somit die Drehzahl noch weiter steigern zu können (Verringerte Gegeninduktivität). beste Grüße und viel Erfolg bei Deinen Versuchen!
Hallo, ja mittlerweile verstehe ich so halbwegs, wie die FOC funktioniert. Das einzige Problem, was ich noch habe, ist folgendes: wenn ich d und q errechnet habe, dann sind das ja zwei Ströme. Die werden geregelt, und aus der Regelgrösse muss ich ja irgendwie wieder die Zeiten berechnen können für die PWM. Dazu brauche ich ja aber 3 Angaben: Zeit für den Nullspannungsvektor, Zeit für den einen Vektor und Zeit für den Zweiten. Wie kann ich denn diese aus d und q berechnen? Klar, ich transformiere wieder zurück mittels inverser Park und Clarke-Transformation, aber dann habe ich am Schluss einfach wieder 2 Ströme. Was mache ich mit denen? Gruss Tobias
Guten Abend Tobias, ich klinke mich hier mal kurz ein und 'störe' eure Diskussion. zu den Reglerausgangsgrößen: valpha und vbeta kommen daher zustande, dass die Ausgangsgröße der Regler nicht Strom, sondern Spannung ist. Primitiv ausgedrückt hast du ein delta-Strom, das der Regler durch einen entsprechenden Spannungswert ausgleichen will (und tut). Nach den Rücktransformationen hast du deine zwei Spannungsvektoren va und vb, die einen resultierenden 'Gesamtzeiger' ergeben. Dieser definiert dir genau wie deine Spannungszeiger im dreiphasigen System aussehen. Gruß Christian
Morgen Christian, okay, also ist es tatsächlich so, dass ich am Regler-Ausgang eine Spannung habe, und nicht mehr einen Strom. Danke! Aber noch immer ist meine Frage ungeklärt, wie ich aus va und vb die PWM-Zeiten berechnen kann, respektive halt eben die Zeit für die einzelnen Vektoren. Es gibt ja 6 Sektoren, und 6 verschiedene Spannungsvektoren: 001 011 010 110 100 101 So, jetzt wird ja in jedem Sektor zwischen zwei dieser Bitmuster hin- und her geschaltet, z.B. im Sektor 1: 000 t3 / 4 001 t1 011 t2 111 t3 / 4 111 t3 / 4 011 t2 001 t1 000 t3 / 4 wie erhaslte ich denn nun aus den Spannungen va und vb die 3 Zeiten t1, t2, t3, und das auch noch für jede Phase? Das ist mir noch nicht ganz klar. Und ich glaube nicht, dass es sowas einfaches wie dc_a = va / vdcbus dc_b = vb / vdcbus dc_c = vc / vdcbus ist. Oder etwa doch? Grüsse Tobias
Hi, die Anschaltzeiten musst Du für jeden Sektor einzeln berechnen. Es gibt keine Formel die den Ausgang für eine Halbbrücke geschlossen über eine volle Umdrehung bedient. Grüße, Toby
Hi toby, wie berechne ich anhand der Werte für va und vb sowie des aktuellen Sektors die 3 Zeiten der PWM? Gruss Tobias
Hallo Tobias, Ta = Zeit Anfangsvektor = proportional zu: sin (60-omega)* Motorspannung in % Te = Zeit Endvektor = proportional zu: sin (omega)* Motorspannung in % To = Zeit Nullspannungsvektor = Pulsperiode-(Zeit Anfangsvektor + Zeit Endvektor) wenn omega der Winkel im jeweiligen Sektor ist. (von 0 bis 60 Grad) Da immer alle Spannungsvektoren umgeschaltet werden, muss die Zeit für alle drei Phasen nur einmal gerechnet werden. Axel
Hi Axel, deine beiden Formeln sind soweit schon klar. Die habe ich so ja auch benutzt, als ich meine RZM implementiert habe ;-) Aber das Problem ist ja: bei der FOC kriege ich keinen Wert für "Motorspannung in %". Was soll ich denn da in die Formel einsetzen? Gruss Tobias
Tobias Plüss schrieb: > Aber das Problem ist ja: bei der FOC kriege ich keinen Wert für > "Motorspannung in %". Was soll ich denn da in die Formel einsetzen? Der Betrag des resultierenden Zeigers, der durch deine Spannungen ua und ub aufgespannt wird gibt dir den Wert. Gruß Christian
Angehängte Dateien:
-
gr.png
10 KB
Verzeiht mir, dass ich den alten Thread nochmal ausgrabe, denke die Fragen passen hier aber ganz gut :) Ich bin gerade dabei einen FOC Regler für einen sensorlosen BLDC zu bauen. Habe schon diverse App-Notes und Scripts durchgelesen, komme aber leider immer noch nicht ganz dahinter. Es wird ja immer geschrieben, dass alle PWM Signale mit einander und mit dem ADC synchronisiert sein müssen. Außerdem sollen die PWM Signale auf den symmetrischen Modus gestellt werden. Verstehe ich es richtig, dass die Strommessung(en), die gesamte Berechnung mit Clarke Trans- und Rücktransformationen, die Vektorraummodulation und die Nachregelung der PWM Duty für jeden einzelnen, also pro PWM Schritt ausgeführt wird? Laut einem anderen Thread müssen für jede Strommessung, also bei jedem ADC Interrupt, alle Brücken auf LOW-Side geschaltet werden. Damit würde man doch alle Spulen für die Messdauer jedes Mal kurzschließen und den Motor extrem ausbremsen, oder sehe ich das falsch? Wird diese Messzeit als "Totzeit" bezeichnet? Das ganze möchte ich erstmal auf einem ATMega2560 laufen lassen. Ist es mit dem Controller grundsätzlich möglich, einen BLDC auf diese Weise zu regeln? Ich erwarte auch keine hohen Drehzahlen, möchte es nur ersteinmal auf einem ATMega ausprobieren. Meistens werden für diese Anwendung ja schnellere µC’s verwendet, dspic33 zb. Grüße
Hallo Andreas, ja, die Strommessungen und die komplette Transformationskette sind üblicherweise jeden PWM-Zyklus zu berechnen. Die Nachregelung des PWM-Dutys machen deine zwei Stromregler (d/q). Durch die Rücktransformation mit anschließender Vektormodulation stellen sich die entsprechenden PWM-Dutys "automatisch" richtig ein. Wenn du dir im center-aligned-Modus die Schaltmuster eines Spannungszeigers aufmalst wirst du erkennen, dass es für jeden Spannungszeiger eine Phase gibt, wo alle High-Sides aktiv und eine Phase wo alle Low-Side-Schalter aktiv sind. Das ergibt sich aus der Tatsache, dass man mit dem Spannungszeiger den Inkreis des Spannungs-6ecks abfährt und somit nie 100% Vollmodulation hat -> folglich muss es Zeiten geben, wo keine zusätzliche Energie in die Maschine geschoben wird. Die Phasenströme werden üblicherweise in der Zeit gemessen wo die Low-Sides an sind. Das macht die HW einfacher ;) Als Totzeit wird die Überlappungszeit zwischen Low- und High-Side Schalter bezeichnet, damit es zu keinem Querkurzschluss in den einzelnen Brücken kommt. Den ATMega kenne ich persönlich nicht, drum kann ich nicht viel dazu sagen. Einen BLDC wirst du damit bestimmt zum Laufen bekommen, da ist nicht viel dabei. Für die von dir angesprochene PMSM mit FOC verwende ich die dsPIC33FJ-Familie von Microchip. Diese bringen ein vernünftiges PWM-Modul und einen ADC mit 4 S&H Stufen mit, d.h. du kannst alle drei Phasenströme und die Zwischenkreisspannung zum exakt gleichen Zeitpunkt sampeln. Gruß, Christian
Vielen Dank für deine ausführliche Antwort :) Ich werde morgen oder am Wochenende die gesamte Rechnung mit Beispieldaten am Papier mit Spannungszeigern aufmalen und durchrechnen um es 100%tig zu verstehen. Aber es klingt schon einleuchtend, dass es auch Zeiten geben muss, in denen keine Energie in den Motor geschoben wird. Mit der Totzeit sollte ich dann kein Problem haben, die Mosfet-Treiber aus meiner Trapezregelung haben diese integriert, ich glaub 540ns waren es. Wie genau muss die Strommessung erfolgen bzw. welchen Messwiderstand sollte ich verwenden? In einer App-Note von Mircochip wird ein dsPICDEM MCLV-2 DEVELOPMENT BOARD verwendet, hier kommen 0.025R Shunts zum Einsatz. Wenn ich zum Beispiel einen 0.1R Shunt verwenden würde und die Abfallende Spannung direkt mit dem 10Bit (0.049 Volt Genauigkeit) ADC des AVRs auswerte, würde ich den Strom mit riesigen 0.049V / 0.1R = 0.49A Stufen messen. Das ist glaube ich schon seehr ungenau :D. Mit dem 0.025R Shunts von dem oben genannten Board wird noch schlimmer… Also brauche ich unbedingt einen OP-Verstärker und passenden Messwiderstand dazu. Ich will zuerst einen CD Laufwerk Motor regeln(denke mal ~ 1Watt Leistung) und später dann einen üblichen Quadcopter Motor mit ungefähr 15A. Ist die Leistungsspanne vielleicht zu groß um sie mit einem und demselben Shunt und OP abzudecken und darauf die FOC Rechnung aufstellen? Ist es an dieser Stelle problematisch, wenn ich einen Doppelshunt und evtl. einen Doppel-OP verwenden würde? Grüße, Andreas
Ich habe den ganzen Tag PDFs von allen möglichen Chipherstellern mit Beispielanwendungen studiert. Gar nicht so leicht das ganze zu verstehen :-D. Ich finde hier ist es mit Abstand am besten erklärt: http://www.microchip.com/stellent/groups/SiteComm_sg/documents/Training_Tutorials/en532365.pdf Was mich noch interessieren würde: berechnest du mit dem dsPIC33 den Winkel des Rotors Theta und Motorgeschwindigkeit Omega über „Position and Speed Estimation“, also über ein digitales Motormodel + gemessene Werte mit Korrekturfaktorbildung usw. oder verwendest du irgendwelche zusätzlichen Sensoren am Motor? Ist an dieser Stelle der Korrekturfaktor sehr wichtig oder würde es reichen wenn ich (vorerst) diese Werte nur über das digitale Motormodel berechne? Wenn ich es richtig verstanden habe, muss man neben den Phasenströmen auch die Phasenspannungen messen um den Korrekturfaktor zu bilden. Die gesamte Rechnung scheint insgesamt doch sehr aufwendig zu sein, ich zweifle immer mehr daran, das alles mit einem ATMega2560 berechnen zu können. Grüße, Andreas
<comment> Ich will dir nicht die Illusion nehmen, aber an einem Wochenende wirst du diese komplexe Thematik nicht 100%ig verstehen - aber das nur am Rande :) </comment> Das mit der Totzeit kann man nicht pauschalisieren! Es hängt im Wesentlichen von der Schaltcharakteristik deiner Leistungshalbleiter ab, ob du MOSFETs oder IGBTs verwendest etc. Der Widerstandswert des Shunts hängt davon ab welchen Strommessbereich du abdecken willst bzw. was die Verlustleistung des Shunts zulässt. Je größer der Shunt, desto weniger musst du verstärken, desto geringer der/die Fehler (desto höher die Verlustleistung!). Bei einer FOC macht es Sinn "echte" Shuntwiderstände einzusetzen, da man doch einigermaßen genau Messen sollte. Bei Blockkommutierten BLDCs hat es sich bewährt über den RDSon der MOSFETs zu messen. Man sollte noch dran denken, dass du positive und negative Ströme messen können musst. Du brauchst also eine OPV-Stufe mit ADC_ref/2 Vorspannung. Wie man auf den Rotorwinkel kommt hängt immer von der Anwendung ab. Pauschal kann man sagen, dass die meisten (einfachen) Modelle erst ab einer gewissen Drehzahl Funktionieren, deshalb nur für Anwendungen geeignet sind, die "immer drehen" (Lüfter, Waschmaschine, etc). Bei Anwendungen wo Stillstandsmoment, hohes Anlaufmoment, Positioniergenauigkeit (Servos) gefordert sind hat man üblicherweise Rotorlagesensoren auf der Welle. Stürze dich nicht gleich ins Verderben. Fang am Besten mit einem gebergeführten System an, bringe es stabil ans Laufen und verstehe was passiert. Wenn du gleich mit 100% einsteigst verlierst du schnell die Motivation an der doch nicht so ganz trivialen Thematik. Danach kanst du dich an die Rotorlagebestimmung über Modelle oder andere Verfahren hermachen. Wieso hängst du so an einem ATMega? Man nimmt den Controller mit dem man die gestellte Aufgabe am einfachsten lösen kann. Ich will jetzt nicht den Thread kaputt machen und die 1001ste Diskussion um µCs lostreten, aber einen AVR würde ich persönlich nicht auswählen - zumindest für Motorcontrol - da gibts um Welten geeignetere. Grüße, Christian
Hallo Andreas, ohne das ich deinen Controller wirklich kenne (bin bei den alten Atmegas ausgestiegen) denke ich, dass die Rechenleistung ein wenig knapp sein wird. Meine erste Umsetzung habe ich auf einem kleinen 16bitter gemacht und hier musste ich schon sehr stark tricksen. D.h. also nicht jede Pwm Periode rechnen, sehr einfaches Modell für die Berechnung der Motorlage etc.. Ich würde Dir einen Cortex Controller empfehlen. Da hast Du ausreichend Luft und kannst dich auf das Wesentliche konzentrieren. Die Strommessung legt man auf den Motor aus, d.h. auf das Drehmoment und damit den Strom des Motor. Wenn Dein Motor z.B. im Normalen Betrieb einen max. Strom von 1A braucht würde ich die Strommessung auf ca. 1.5A auslegen. Die 0.5A hast Du dann Luft zum Beschleunigen des Motors und z.B auch für Lastsprünge. Die Strommessung wird hierbei auf die Spitzenwerte der Motorstöme ausgelegt und nicht auf die Effektivwerte. Für die Implementierung ist ansonsten immer ein Lagesensor hilfreich. Dass Motormodell für die sensorlose Regelung kann man dann immer noch machen wenn der Rest läuft. Grüße,Ralf
Hallo, nach langer Zeit melde ich mich wieder. Ich habe mich für ein STM32F4 Board entschieden. Zurzeit läuft der Motor mit 3 starren Sinuskurven (ohne SVPWM) und es wird blind kommutiert, sprich der Winkel wird nach einer bestimmten Zeit aufaddiert. Mit richtigen Werten läuft der Motor ruhig, leise und wird nicht heiß. Da mein Motor keine Sensoren für die Positionsbestimmung hat, bin ich gezwungen, erstmal ohne SVPWM zu arbeiten. Jetzt möchte ich anhand der gemessenen Phasenströme den Winkel ermitteln und komme nicht so richtig voran. Ist es überhaupt möglich, den Winkel zu berechnen, während der Motor "blind" betrieben wird und der Winkel "blind" aufaddiert wird oder muss dieser zwangsweise mit der ganzen FOC Regelung laufen damit der Winkel errechenbar ist? Grüße Andreas
Seid ihr sicher, dass RZM mit einem bldc Sinn macht? Bldc sind dafür konstruiert mit Blockkommutierung konstantes Moment zu erzeugen. Sinus kommutierung ist da kontraproduktiv. Schaut mal die induzierte Spannung an. Trapez? Dann Blockkommutierung für konstantes Moment. Lässt sich aus dem energieerhaltungssatz ableiten.
Wenn ich den Motor an einen Oszi anschließe und den Rotor mit der Hand drehe, wird eine Sinusförmige Spannung induziert. Grüße Andreas
Hi Andreas, die Berechnung der Position funktioniert auch so. Das ist ja die normale Anlaufsituation eines des Motors, d.h. die Position ist zunächst unbekannt (abgesehen von einer Positionierung), d.h. der Motor läuft gesteuert hoch. Das Positionsberechnungsmodell schwingt in der Phase ein und dann wird umgeschaltet. Eine komplette FOC brauchst Du dabei nicht. Um die Positionsberechnung richtig einzustellen ist aber ein richtiger Positionssensor sehr hilfreich! Was mir noch nicht so ganz klar ist warum Du die SVPWM nur mit einem Winkelsignal verwenden kannst. Die beiden Dinge sind unabhängig voneinander. D.h. Sinus-Delta und SVPWM sind einfach nur Verfahren um ein 3phasiges Spannungssystem mit einer PWM zu erzeugen. Das was Karl schreibt ist auch richtig. Wenn Du aber eine sinusförmige EMK misst ist alles i.O., d.h. die Sinuskommutation ist dann gut. Gruß
Hallo Gonzo, für SVPWM benötige ich ja den Spannungsvektor, welchen ich von der inversen Park-Transformation erhalte. Für diese Transformation benötigt man den Drehwinkel. Was mir gerade auffällt, bzw. sich eine Frage stellt: Muss ich für die Park- und Inv.Park-Transformation den elektrischen Drehwinkel oder den durch den gemessenen Phasenstromvektor dargestellten Winkel verwenden? Bisher habe ich versucht den Drehwinkel zu verwenden, weil: (Auszug aus Wiki) "Um das d/q-Koordinatensystem mit korrekter Winkelgeschwindigkeit und Phasenlage mit dem Rotor mitrotieren zu lassen, ist es notwendig die genaue Lage in Form des Winkel Theta des Rotors zu kennen" Grüße Andreas
Moin Zusammen, was das "messen" der Rotorlage angeht, wenn der Motor mit eine harten Sinus gefahren wird ist erst mal garnicht so schwer. Du brauchst dafür nur die Maschinen Gleichungen lösen. Wenn du dir eine Phase als Rs, Ls und Spannungequelle(BEMF) vorstellst. Läuft der einfachse Beobachter für den magnetischen Fluss darauf hinaus, dassdu sagst. V = i*Rs + d/dt*i*Ls + e (e ist die BEMF Spannung) nach di/dt umgestellt: di/dt * Ls = -Rs*i + V - e Integriert: i*L = int(V-i*Rs)dt - int(e)dt Mit lamda als Fluss = int(e)dt umdgestellt nach lamba: lamda = int(V-i*Rs)dt - i*L Das lässt sich leicht implementieren, bei dem Integrator solltest du aber n Hochpass hinter setzen, weil die sonst der Fluss weg driftet. Übrigens Integrator und Hochpass ergeben einen Tiefpass mit der Grenzfrequenz wie der Hochpass. Wenn du dann den Fluss für jede Phase oder nur fürs Alpha/Beta System berechnest kannst mit dem atan2 die Rotorlage berechen. das ganze wird durch aller lei Fehler wie etweigen Stromfiltern usw. verfälscht. Geht aber erstmal für einen Versuch. Für einen richtigen beobachter solltest du dich zumindest mit dem Entwurf eines Lunenberger Beobachters auskennen. Da gibts aber von ST. z.b sogar n recht altes Paper zu. Gruß Tec
Hallo Andreas, für die ganzen Transformationen brauchst Du zunächst nicht die realen Winkel. Du kannst hier auch einfach was vorgeben. Der Motor läuft dann eben gesteuert in einem falschen Arbeitspunkt. Der normale Weg der Inbetriebnahme ist auch schrittweise, d.h. man nimmt erst die SVPWM in Betrieb indem mann einfach sin und cos Spannungen einer bestimmten Frequenz vorgibt (alpha beta Simulation). Damit kann man dann auch die Strommessung prüfen. Im nächsten Schritt schaltet man die Eingangstransformationen ein (Clarke/Park) und kann dann im nächsten Schritt die inneren Stromregler samt Rücktransformation in Betrieb nehmen. Zum Schluss folgt dann der Drehzahlregler und dann noch die Lageberechnung. Die einfachste Variante ist die direkte Berechnung über die Spannungsgleichungen des Motors wie von Tec beschrieben. Was sich ggf. auch lohnt ist bei TI zu spicken. Hier gibt es sog. Build Levels. Damit wird quasi die schrittweise Inbetriebnahme eine FOC beschrieben. Viele Grüße, Ralf
Vielen Dank für die Antworten @ Tec und Gonzo! Ich habs dank euch (und den anderen Usern drüber) nun geschafft, den Winkel zu berechnen. Zwar ist das Ergebnis noch um 90° 'falsch' obwohl ich ein Offset mitberücksichtige, aber die Ursache werde ich hoffentlich noch finden. Die Berechnung überprüfe ich so, dass ich den tatsächlichen, künstlichen Winkel und den berechneten Winkel jeweils über die DACs ausgebe und die Signale am Scope vergleiche. (@Tec: habe mir jetzt ein DSO Scope von Tektronix besorgt ;) ) Als nächstes muss ich die Regler zum Laufen bringen. (verstehe noch nicht, wie die Referenzwerte für d und q zustandekommen) Grüße Andreas
Freut mich. Id ist eigentlich immer 0 fürs erste. Und Iq bildet dein Drehmoment. M =Kt * Iq. Kt ist die Motorkonstante fürs Drehmoment. Was die Transformationen nach Clark und Park angeht gibts beim englischen Wikipedia gute Informationen. Gruß Tec
Guten Abend. Ich fahre immer noch mit dem festen Winkel, er wird also fest nach einer bestimmten Zeit erhöht. Ansonsten wird der Motor jetzt komplett über SVPWM gesteuert. Ich hätte eine Frage zu den Reglern. Nach dem Anlaufvorgang, also nach der Umschaltung auf SVPWM merkt man, dass die Stromaufnahme deutlich sinkt, alles gut soweit. Nur wenn ich jetzt eine Störung hineinbringe, in dem ich zum Beispiel kurzzeitig die Phasenstrommessung vom ADC abklemme, steigt natürlich die Stromaufnahme und der Motor läuft unruhig. Es dauert nun sehr sehr lange, bis die PI Regler sich wieder einregeln, bzw. regeln die sich überhaupt nicht mehr auf den Ausgangszustand ein. Kann mir vllt jemand einen Tipp geben? (Ich arbeite vorerst bewusst mit Float, um die Zwischenergebnisse besser nachvollziehen zu können, mit 1kHz keine Performance Probleme) Initialisierung der Regler:
1 | pParm->d_soll = 0; |
2 | pParm->q_soll = 0; |
3 | pParm->p_err1 = 0; |
4 | pParm->i_err1 = 0; |
5 | pParm->d_err1 = 0; |
6 | pParm->p_err2 = 0; |
7 | pParm->i_err2 = 0; |
8 | pParm->d_err2 = 0; |
9 | pParm->ki1 = 0.0003;//1; |
10 | pParm->kp1 = 0.0003;//1; |
11 | pParm->kd1 = 0.0; |
12 | pParm->ki2 = 0.0003;//1; |
13 | pParm->kp2 = 0.0003;//1; |
14 | pParm->kd2 = 0.0; |
15 | pParm->resfactor= 1; |
16 | pParm->imax = 0.9999; |
Regler selbst:
1 | float d_actual_error = 0; |
2 | float q_actual_error = 0; |
3 | |
4 | //
|
5 | m1.PI.d_soll = 0; |
6 | m1.PI.q_soll = 0.0019; |
7 | |
8 | //calculation D factor
|
9 | d_actual_error = (m1.PI.d_soll) - (m1.Id); |
10 | m1.PI.i_err1 += d_actual_error; |
11 | m1.PI.d_err1 = (d_actual_error) - (m1.PI.p_err1); |
12 | |
13 | //calculation Q factor
|
14 | q_actual_error = (m1.PI.q_soll) - (m1.Iq); |
15 | m1.PI.i_err2 += q_actual_error; |
16 | m1.PI.d_err2 = (q_actual_error) - (m1.PI.p_err2); |
17 | |
18 | // PID = GainP * actual error + GainI * SUM(previous errors) + GainD * (actual error - last error)
|
19 | m1.Vd = ((m1.PI.kp1)*d_actual_error) + ((m1.PI.ki1)*(m1.PI.i_err1)) + ((m1.PI.kd1)*(m1.PI.d_err1)); |
20 | m1.Vq = ((m1.PI.kp2)*q_actual_error) + ((m1.PI.ki2)*(m1.PI.i_err2)) + ((m1.PI.kd2)*(m1.PI.d_err2)); |
21 | if(m1.Vd > 0.9999) m1.Vd = 0.9999; |
22 | if(m1.Vq > 0.9999) m1.Vq = 0.9999; |
23 | |
24 | // set actual p_err value to old value
|
25 | m1.PI.p_err1 = (d_actual_error); |
26 | m1.PI.p_err2 = (q_actual_error); |
Grüße Andreas
Noch etwas:
Bei der Winkelberechnung für sensorlose Motoren muss Omega wegen des
Geschwindingkeitsreglers, welcher je nach gewünschter Rotordrehzahl die
Iq anpasst(SpeedPID), gefiltert werden.
Muss man Omega filtern, wenn man keinen solchen SpeedPID hat, sondern Iq
konstant hält?
Könnte ich Drehmoment und somit Drehzahl auch steuern indem ich Iq immer
auf 1 setze aber dafür den PWM Wert anpasse, den ich bei PWM Zeiten
Berechnung in der SVPWM verwende.
z.B:
void CalcTimes(void)
{
T1 = PWM * T1;
T2 = PWM * T2;
Tc = (PWM - T1 - T2) / 2;
Tb = Tc + T1;
Ta = Tb + T2;
}
Wenn nicht verständlich beschrieben, bitte sagen :)
Grüße
Andreas
Versuche mich an einer BLDC Steuerung. Benutze ein STM32F4. Da alles 'geklaute' an code nicht richtig funktioniert hat, der Motor hatte Drehmoment Schwankungen. Habe ich selber ein paar Zeilen geschrieben. Motor hat ein Encoder mit Index, also kenne ich die Rotorstellung. Hatte zuerst eine Sinustabelle, da lief der Motor schon ganz gut, dann habe ich die Popekurven in der Tabelle vorberechnet und der Motor läuft ohne spürbares cogging. Habe folgende Probleme/Fragen ... Wenn der Motor stillstehen soll lässt er sich von Hand kaum noch drehen. Der Motor sollte laut Datenblatt bei 12V auf 80Upm kommen, ich schaffe aber nur 50. Meine China 3Phasen Brücke hat leider nur einen Shunt zu strommessen. Wollte jetzt aber gerne alle 3 Phasen messen (das muss wohl so fürn Foc), und suche nach der einfachsten Möglichkeit 3 Stromsensoren nachzurüsten. Also mit möglichst wenig Bauteilen, weil ich das ja irgendwie an die Platine kleben muss. Habe Allegro ACS Sensoren gefunden, sind aber ganz schön teuer. Gibt's was günstigeres was ähnlich ist?
Shunt + (Strommess-) Verstärker (INAxxx , LT1999, Ad8210) Musst einfach mal die bekannten Hersteller absuchen. Gruß Ert
Die Strommessung ist auch mit "single shunt" möglich. Dazu gibt's einige Application Notes im Netz, das muss man hier nicht wiederkäuen. Man braucht halt einen Controller, der pro PWM-Zyklus den ADC an berechneten Zeitpunkten triggern kann. Gruß Christian
> Die Strommessung ist auch mit "single shunt" möglich.
Ja aber nicht so richtig, es gibt Bereiche bezogen auf die Rotorposition
wo nicht gemessen werden kann. Oder.
Ja, richtig. Da macht man dann quasi einen Blindflug. Es gibt aber auch Verfahren mit denen man sich auch in diesen Situationen ein Messfenster erzeugen kann. Man verschiebt dabei die Pulsmuster so gegeneinander, dass eine Messung möglich ist, der Motor aber quasi nix davon mitbekommt. Ob ein Einsatz möglich ist hängt immer von der Anwendung ab.
Angehängte Dateien:
-
Schaltplan.png
6,1 KB
Guten Abend. Ich arbeite immer noch an der sensorlosen FOC Steuerung. Die gesamte Elektronik habe ich auf einem Steckbrett aufgebaut, was ja nicht gerade förderlich ist, vor allem bei der Strommessung der einzelnen Phasen. Im Anhang ist mein Schaltplan für eine Phase. Diesen würde ich 3x auf einer Lochrasterplatine aufbauen. (Den Teil für die Strommessung natürlich nur 2x) Denkt ihr, der Schaltplan ist so in Ordnung? Ich möchte es "schön" aufbauen und nicht im Nachinein noch 20 Änderungen machen müssen :) Grüße Andreas
Ne Frage zu den Nebenschlusswiderständen. Man bräuchte ja nur 2 Wiederstände. Sollte man aber nicht besser trotzdem 3 Wiederstände einlöten und ggf. nur 2 Messverstärker? 3 Widerstände damit alle Phasen den gleichen Wiederstand nach Gnd bzw. Vcc haben. Oder kann man das vernachlässigen?
Hi, ohne jetzt alle Bauteile im Detail zu kennen... Wieso hast Du den Shunt nach oben gepackt? Ich würde den Shunt in die Fusspunkte der Halbbrücken legen. Dann kannst Du einen einfachen Rail-to-Rail OpAmp für die Strommessung nutzen. Den benötigten Offset stellst Du dann über die Eingangsbeschaltung ein. Du hast keine Gate-Widerstände in der Schaltung. Gruß, Gonzo
Stimmt, man sollte natürlich für jede Phase einen Shunt verwenden. Sind Gate R's unbedingt notwendig? Würden da 20 Ohm ausreichen? Ich messe in der HI Side, weil ich in der Low Side Messung eine neg. Spg. für die OPs erzeugen müsste. Der AD8210 kann mit Single suply bidirektional messen, muss aber dafür in Hi Side sitzen. (Wenn ich das Datenblatt richtig verstanden habe) Grüße Andreas
Für die OpAmps brauchst Du eigentlich keine neg. Spannung. Ich mache das so, dass ich die Ausgangsspannung so einstelle, dass die Ruhespannung bei I=0 in der Mitte des Aussteuerbereichs des ADCs liegt. Diese Offsetspannung rechne ich dann zur Laufzeit wieder raus. Für die Messung verwende ich dann einen OpAmp den ich mit einer einfachen Versorgung von 5V bzw. 3,3V betreiben kann. Der OpAmp sollte ein Rail to Rail Typ sein. Gatewiderstände sind nicht zwangsweise notwendig. Es gibt auch Treiber die entsprechend abgestimmt sind. Schaden kann ein Widerstand aber meines Erachtens nicht. Die Platzierung sollte möglichst nah am Gate sein. Hier lasse ich mich aber auch gerne korrigieren. Komme eher aus der SW Ecke :-) Die Größe des Widerstands hängt von den verwendeten Komponenten/EMV ab. Hier muss man immer ein wenig probieren. Manchmal verwendet man auch noch einen Parallelzweig mit Dioden um das Ein- und Ausschaltverhalten getrennt abstimmen zu können. Gruß
Angehängte Dateien:
-
Schaltplan2.png
7,6 KB
Mit den Gate-Widerständen werde ich wohl ein wenig probieren müssen :). Zur Strommessung: Es wäre natürlich super wenn ich ohne der zwei AD8210 auskommen würde. Habe ich deine Beschreibung richtig verstanden? (Schaltplan) Dann würde ich sogar mit nur einem Bauteil auskommen, denn der AD822 hat ja 2x Rail to Rail OpAmp's die ich für die zwei Phasen verwenden kann. Und zufällig habe ich hier ein paar rumliegen :) Edit: sehe gerade selbst, so wie ich es im Schaltplan gemacht habe, kann es nicht funktionieren :( Grüße Andreas
Schau dir mal das Demo von ST an. Hier findest Du den grundsätzlichen Aufbau der Schaltung wie ichs in etwa machen würde. http://www.st.com/web/en/catalog/tools/PF247220 Nicht verwirren lassen, die OpAmps sind im Halbbrückentreiber integriert. Im prinzip hast Du einen normalen nicht invertierenden Verstärker, d.h. über die Rückkopplung stellst Du die Verstärkung, d.h. den Messbereich ein. Am +Eingang des OpAmps ziehst Du über einen Spannungsteiler die Ruhespannung etwas hoch damit am Ausgang eine Spannung von z.B. 2,5V liegt wenn kein Motorstrom fließt (bei 5V Versorgung des ADC). Der Shunt liegt zu diesem Spannungsteiler in Reihe. D.h. wenn Strom fließt wird das Potential durch den Strom weiter angehoben oder eben abgesenkt. Damit kannst Du positive und negative Ströme messen. Gruß, Gonzo
Andreas True schrieb: > (Ich arbeite vorerst bewusst mit Float, um die Zwischenergebnisse besser > nachvollziehen zu können, mit 1kHz keine Performance Probleme) Habe mal die SVPWM mit LPC hier aus dem Forum in Float umgebaut und verglichen. Festkomma 1.9us, Float 1.7us. Code ist nicht 100% identisch z.b. habe ich eine Volle Sinus und Cosinus Tabelle benutzt. Dafür wird im Float Code zwischen zwei Tabellen Werten interpoliert.
Angehängte Dateien:
-
Schaltplan3.png
5,7 KB
Wie immer vielen Dank für die Hilfe, ohne euch hätte ich bestimmt schon längst aufgegeben :) Ich habe jetzt die Schaltung für die Messung so Ähnlich aufgebaut, wie in der PDF von st. Funktioniert auch wunderbar (zumindest mit einem Lastwiderstand statt H-Brücke) Benötigt aber ganz schön viele Bauteile. Spricht von der Softwareseite aus etwas dagegen, wenn ich bei meiner HI Side Messung bleibe? Speziell bei der Bestimmung des Space Vektors und der PWM Timings. Die meisten App-Notes gehen ja davon aus, dass in der Low Side gemessen wird. Einfach ausprobieren kann ich noch nicht, weil meine Software immer noch nicht anständig läuft (PID Parameter -.- ) @Laufzeit: als ich zuletzt gemessen habe, hat bei mir eine Berechnung mit Float (auf der FPU) ca 20us gebraucht, allerdings ohne Optimierungen oder Ähnliches. Allerdings muss bei mir ja der Winkel Estimator mitlaufen, was ja bei der Version aus dem Forum nicht der Fall ist. (oder doch?) (läuft auf STM32F4 Board) Grüße Andreas
Hallo Andreas, bzgl. der Bauteilanzahl hast Du natürlich ein paar Widerstände mehr. Aus meiner Sicht spricht grundsätzlich auch nichts gegen die Messung im Highside Kreis wobei ich den Baustein von Analog nicht kenne. Die einzigen Argument die mir jetzt dagegen einfallen sind die folgenden: - Die Messung in der Lowside erscheint mit aus Bauteilsicht flexibler, d.h. es gibt eine größere Auswahl an OpAmps - Aus Sicht der Potentiale/GND-Anbindung ist die Messung im Lowside Kreis denke ich günstiger da man immer direkt den GND Bezug hat. Bei der Highside Messung muss man ja alles erst mal runter auf den GND Bezug bringen - Wenn Du in Zukunft mal die Modulation in Bezug auf Schaltverluste optimieren möchtest ist die Messung in der Lowside günstiger da der Lowside auch statisch eingeschaltet werden kann. Das ist bei der Highside aufgrund der Bootstrapbeschaltung nicht möglich. Wenn Du den Lowside statisch einschaltest kannst Du in der Highside aber keinen Strom messen. Bzgl. der Abtastzeitpunkte sollte es denke ich keine Probleme geben. Bei der Highside Messung musst Du halt zum Zeitpunkt des (1,1,1) Vektors messen. Was Du ggf. noch probieren/ansehen könntest wäre die Messung direkt in den Motorphasen. Geht das vielleicht auch mit dem Analog Baustein? Dann wärst Du völlig flexibel und kannst zu beliebigen Zeitpunkten die Ströme messen. Gruß
Angehängte Dateien:
-
AD8210_h_bridge.png
81 KB
Hallo Gonzo, der AD8210 wurde mir hier im Forum empfohlen, soll auch extrem genau sein. Vermutlich weil die Widerstände und alles andere integriert ist. Nachteil ist aber der feste Gain und nur 0.65mm Pinabstand. Und ist nicht gerade günstig, wobei es hier für mich keine Rolle spielt. Das mit der Flexibilität ist wirklich ein Vorteil. Vor allem gibt es ja auch dsPIC (somit bestimmt auch ARM Cortex) Controller mit integrierten OpAmps, die man dann für LowSide Messung verwenden könnte. Optimierung der Schaltverluste ist natürlich auch ein gutes Argument gegen die HI-Side Messung. Bei der Messung direkt in den Motorphasen bin ich mir nicht ganz sicher. Hab schon einen AD8210 gekillt weil ich vermutlich -IN und +IN vertauscht hatte. Zudem heißt der Baustein ja eig. High-Side Current sense. Wenn man sich aber die Grafik im Anhang (Datenblatt s.14) anschaut, sieht es für mich so aus, dass der Chip eigentlich auch in der LowSide, oder eben auch direkt in der Phase des Motors einsetzbar sein muss. Wegen der H-Brücke kann ja auch auf der -IN Seite ein Plus auftauchen. Vllt sollte man die Profis im Analogbereich fragen :) Grüße Andreas
Ist wahrscheinlich besser mal die Experten zu fragen. Wie schon geschrieben beschränken sich meine Kenntnisse auf den diskreten Aufbau. Cortex Controller mit integrierten Verstärkern gibt es auch schon. Hier kannst Du Dir mal die F3 Serie von ST ansehen. Ansonsten gibt es hier auch was von Renesas (irgendein Rx Derivat). Die integrierten Verstärker sind aber aus meiner Sicht auch nicht wirklich die optimale Lösung. Hier ist das Layout sehr entscheidend da ja alles auf der gleichen Masse hängt (eigene Erfahrung :-(). So hat halt alles seine Vor- und Nachteile. Viele Grüße...
Moin, Rein analog ist der STM32F303 usw. sehr gut für FOC. Die internen Opamps würde ich aber nicht mehr verwenden. Weil die interne Verdrahtung im Proze leicht komisch ist. Im RM steht zwar was davon das man den Vout direkt auf einen ADC geben kann. Aber da hatte ich immer komische Störungen drauf. Wenn man den ADC auf den Pin schaltet auf dem auch Vout des OPs raus geht geht das besser. Warum weiß ich auch nicht. Vllt ist der Ausgangstreiber des Pins von Vorteil. Bei einem Redesign würde ich für meine Umrichter den STM32F3 verwenden aber mit externen Opamps und Komperatoren für Überstrom usw. Unabhängig vom Proze. Die 2 SO8 kann ich verschmerzen. Das sind meine Erfahrungen mit dem Proze und internen OPs. Gruß Tec
Andreas True schrieb: > @Laufzeit: Ja Zeiten sind ohne Winkelschätzung. Habe noch ein paar LTC6104 gefunden. Messe damit den Phasenstrom vom Motor. Und es geht besser als ich dachte. Trotz wild west Verkabelung habe ich nur ~5 Counts "rauschen" mit 10bit ADC. Jetzt kann ich auch mal mit der Vorwärts Clark und Park spielen. Habe mir noch INA213 (kosten nur 2€ etwas bei C) besorgt aber die passen nicht auf die SMD Adapter die ich eigentlich benutzen wollte.
Hi Tec, das mit den Störungen auf dem STM32F3 ist interessant. Ich habe dieses Phänomen bisher noch nicht gesehen, d.h. bei mir passt die Messung. Wie haben sich die Störungen bei Dir gezeigt? Würde beim nächsten Projekt aber auch auf eine externe Beschaltung gehen. Spez. da ich im Moment aufgrund meiner Pinbeschränkung den PGA nutzen muss und damit die Signalanbindung bzgl. Masse ziemlich eklig ist. Gruß,Gonzo
Moin, ich hatte Probleme mit EMV, ich hatte synchron zur PWM Ecken in der Messung. Und teilweise Offsets von 20mV, was bei meinen Stromsensoren ca. 1A ist. Über extern gelegt war das Offset weg und der Einfluss der PWM war merklich geringer.
Angehängte Dateien:
-
Screen.png
9,3 KB
Hallo ich bin ein kleiner Neuling auf diesem Gebiet... den sensorlosen Teile habe ich soweit verstanden, allerdings habe ich noch Probleme bei der Umsetzung bezüglich der SVM. Mir ist bewusst das ich mehrere kHz benötige was die Modulationsfrequenz anbelangt um einen sauberen Sinusverlauf zu bekommen, allerdings verstehe ich noch nicht wie/wann ich diese Frequenz mit der Zeitberechnung in Zusammenhang bringen muss um zum Schluss die drei Halbbrücken richtig ansteuern zu können (Motor f=50Hz)... Bis jetzt bekomme ich wie im beigefügten Screenshot zu sehen ist (von oben nach unten): 1. "apha und beta" -Signalverläufe nach er Inversen Parktransformation 2. den "Betrag des resultierenden Zeigers der sich aus alpha und beta ergibt" in dem Fall ist er immer eins da die zwei Signale 90° Phasenverschiebung zueinander haben und sich dann der Quellen-Amplitudenwert, in diesem Fall 1, ergibt ODER liege ich da falsch?!? 3. Winkel in rad des jeweiligen Sektors (natürich auch in deg verfügbar) 4. der "Sektor" des Zeigers, also von 1 bis 6 5. der Winkel im jeweiligen Sektor also von 0° bis 60° Die Formeln für die Zeitenberechnungen wurden in diesem Thread am Datum: 17.12.2009 17:05 geschrieben, demnach müsste ich die Zeiten berechnen können...aber was mache ich mit den drei Zeiten? Das wurde mir bis jetzt durch alles was ich auf Wiki etc..gefunden habe noch nicht klar. Falls sowas schon mal jemand in Matlab-Simulink implementiert hat wäre cool... hab noch nichts gefunden bis jetzt was funktioniert hat bzw. verständlich war für mich. Eine Erklärung für Dumme wäre sehr hilfsreich :-) Mit sehr sehr freundlichen Grüßen
Schau mal unter http://www2.ece.ohio-state.edu/ems/PowerConverter/SpaceVector_PWM_Inverter.pdf G Ert
Oder schau Dir mal das Buch hier an: Vector Control of Three-Phase AC Machines: System Development in the Practice (Power Systems) ISBN:3540790284 Der SVPWM Teil ist bei Google Books fast komplett Gruß
@Ert & @Gonzo D A N K E ! Jedoch kann ich mich noch nicht mit den Formeln auf Seite 11 von deinem oben verlinkten pdf anfreunden da ich für T1 und T2 unterschiedliche Zeiten bekomme wenn ich für einen Sektor mit 30° rechne. Wenn mein resultierter Zeiger bei 270° ist, also ich für n = 5 und den Winkel = 30° bzw. pi/6 wähle bekomme ich für T1= -1 und T2= 0,5 als Ergebnis. Der vordere Therm ändert sich ja nicht da die Gleichspannungsversorgung Vdc und die Periodenzeit Tz etc. gleich bleiben und man ja zudem die Zeiten T1 und T2 zeitgleich berechnet. Komisch finde ich auch dass in dem pdf von einem dq-System gesprochen wird, das ist doch normal die gängige Bezeichnung der zwei Gleichgrößen nach der Clarke&Park-Transformation. Die SVM beginnt bei euch doch normalerweise auch mit alpha_beta welche man erst wieder durch die Inverse-Park-Transformation erhält ?!?
Christian Zimmermann schrieb: > Die SVM beginnt bei euch doch > normalerweise auch mit alpha_beta welche man erst wieder durch die > Inverse-Park-Transformation erhält ?!? Alpha & Beta erhält man nach der Inverse Clark aus d & q. Mir hat dieses Seminar von TI ganz gut geholfen. FOC startet bei ~1:10:00 http://youtu.be/fpTvZlnrsP0
Angehängte Dateien:
-
SwitchingTimes.PNG
31 KB
Hi Christian, ich habe mir das Dokument jetzt nicht wirklich durchgelesen. Auf den ersten Blick finde ich die Gleichungen aber nicht direkt für eine Implementierung tauglich. Zur Berechnung der Schaltzeiten T1, T2, T0 würde ich mir mal die Seite 25 in obigem Buch ansehen. Hier gibt es eine Tabelle (siehe Anhang) die sich direkt für eine Implementierung eignet. Im Grunde genommen lassen sich die ganzen Gleichungen einfach über Dreiecksberechnungen ableiten. D.h. man zerlegt den Alpha/Beta Vektor einfach in zwei Einzelzeiger die man dann geometrisch überlagert. Warum in dem Dokument d/q Komponenten verwendet werden kann ich auch nicht sagen. Im Pinzip kann hier ja jeder machen was er will. Ich kenne eigentlich auch nur den Standard mit d/q-System => Rotorsystem und Alpha/Beta-System => Statorsystem (bei PMSMs). Aus meiner Sicht ist es also so wie du schreibst, d.h. aus d/q kommt man über die inverse Park Transformation zum alpha/beta System und dann über die inverse Clarke zum abc System. Den letzten Schritt spart man sich normalerweise da man auch gleich aus den Alpha/Beta-Komponenten die Schaltzeiten berechnen kann wie in der Tabelle beschrieben. @Michael: Dave Wilson ist echt klasse. Hier gibt es auch noch ein paar Präsentationen und einen Blog zum Thema. Ist wirklich zu empfehlen! Gruß...
Habe jetzt INA213 mit Low-Side Shunts. Die LTC6104 die ich vorher probiert habe, haben beim einschalten der FETs 10V Spikes und mehr am Output rausgegeben. Denke mal das ist nicht so gut für den ADC... Gonzo schrieb: > Hier gibt es auch noch ein paar > Präsentationen und einen Blog zum Thema. Fehlt "hier" was?
Michael schrieb: >> Hier gibt es auch noch ein paar >> Präsentationen und einen Blog zum Thema. > > Fehlt "hier" was? Ist etwas blöd geschieben. War schon ein wenig müde gestern ;-). Ich meinte auf der Seite von TI. Hier kann man einfach mal nach Dave Wilson suchen und findet dann noch mehr Infos zum Thema Motor Control.
Guten Abend, ich habe leider immer noch ein Problem mit meinem WinkelEstimator. Solange ich den Winkel fest aufaddiere, funktioniert der Estimator richtig, auch über einen großen Drehzahlbereich. Wenn ich nun auf den errechneten Winkel umschalte, bleibt der Motor stehen und es wird ein falscher Winkel berechnet. Obwohl der Motor sich nicht dreht sondern nur noch unentschlossen zittert, berechnet der Estimator weiter irgendwelche Winkelwerte, dabei ist die Winkelgeschwindigkeit sogar konstant! Im Closed Loop wird der Referenzwert für 'q' nicht von dem PID Regler für die Drehzahl vorgegeben, sondern einfach der selbe Wert wie in Open Loop, der Einfachheit halber. Ich weiß, dass schwierig ist, per Ferndiagnose so einen Fehler zu finden und dass die Steuerung jeder etwas anders aufbaut, aber vielleicht habt ihr einen Tipp, wo ich ungefähr den Fehler suchen muss, wenn der Estimator aufhört richtig zu arbeiten sobald man auf den errechneten Winkel umschaltet. Edit: Falls es irgendeine Bedeutung hat: wenn ich den Rotor abnehme, wird trotzdem ein Winkel estimated. Grüße Andreas
Moin. Was meinst du mit Winkel umschalten? Du fährst die Maschine mit einem vorgegebenen Winkel. Den du aus der Integration einer vorgegebenen Drehzahl hast. Und Schaltest dann um auf die Fluss berechnung und die Daraus resultierenden Werte? Frage wie sieht dein Schätzer aus? Fluss, mit P Rückführung und dann PLL? Ist das Einfachste und recht robust. Fehler der da gern auftritt ist das vor dem Umschalten die integratoren der Pll nicht mit aktueller Drehzahl und aktuellem Winkel gesetzt werden. Einfachste Lösung ist die Pll zu Steuern beim Start. Folgendes: du berechnest mit einem fixen Faktor eine Winkelbeschleunigung aus dem vorgegebenen Iq (oder ohne Strom Regelung Uq), und das gibste auf den PI regler der PLL. Damit äauft die los bei ca. 100-200 rad/s schaltest du den Eingang der PLL auf den Winkelfehler zwischen Fluss beobachter mit Tiefpass. (Hatte ich weiter oben mal vorgeschlagen). Dann sollte das laufen mit dem start. Ich hab den Thread lange nicht verfolgt. Falls das nicht passt einfach ignorieren. Gruß Tec
Hi Andreas, Wenn ich dich richtig verstehe lässt du den Motor einfach gesteuert über eine Drehzahlrampe hochlaufen, oder? Die Stromregler fütterst Du in der Zeit mit festen Vorgaben ID=0 und IQ=irgendwas. Woher hast Du in dieser Phase die korrekte Position? Wenn Du keinen Positionssensor nutzt stellt sich in dieser Phase ja irgendetwas für d und q Strom ein. Das muss aber nichts mit der Realität zu tun haben. Wenndu dann auf deinen Winkelschätzer umschaltet gibt es dann ggf. einen Sprung in deinem System und der Motor bleibt stehen. Hast Su mal die Winkel aus der Vorgabe und von deinem Estimator verglichen? Bist Du sicher das der Estimator richtig läuft, d.h. hast du das Signal mal mit einem realen Positionssensor verglichen? Gruß, Gonzo
Hallo, vielleicht beschreibe meine Startvorgang. Ich habe 3 PID Schleifen, eine für Iq, eine für Id und eine für Drehzahlsteurung (W). Die W Schleife bekommt als Input die gewünschte Drehzahl und die aktuelle Drehzahl, die aus dem Delta Winkel und Zeit ermittelt wird. Der Output dieser W-Schleife ist dann der Input für die Iq Schleife. Mit PLL meinst du diese W-Schleife oder? Ich fahre den Motor mit einem fest vorgegebenen Winkel hoch (Rampe), dabei bleibt die W-Schleife vorerst aus. Der Winkel wird fest aufaddiert und die Iq Regelschleife bekommt als Input vorerst einen konstanten Wert, anstatt des Outputs der W-Schleife. Zusätzlich gebe ich den fest aufaddierten Winkel und den vom Estimator errechneten Winkel am Oszi aus. Während des HochfahrVorgangs ist der errechnete Winkel dem fest aufaddierten Winkel ziemlich identisch. Nachdem der Motor die "Standgas-Drehzahl" erreicht hat, bekommen die Clarke- und Parktransformationen und somit die gesamte SVPWM Berechnung nicht mehr den aufaddierten Winkel sondern den Winkel des Estimators. Gleichzeitig wird die W-Schleife aktiviert. Als Referenz-Input bekommt sie den aktuellen, mit LowPass gefilterten Omega-Wert damit weiterhin die "Standgas-Drehzahl" gehalten wird. Der Referenz-Input für die Iq Regelschleife bekommt nun nicht mehr einen konstanten Wert, sondern den Output der W-Schleife. Meine Regelschleifen sehen so aus (aus AN1078 nachgebaut):
1 | void CalcPI(void) |
2 | {
|
3 | Err = InRef - InMeas |
4 | U = Sum + Kp * Err |
5 | if( U > Outmax ) |
6 | Out = Outmax |
7 | else if( U < Outmin ) |
8 | Out = Outmin |
9 | else
|
10 | Out = U |
11 | Exc = U - Out |
12 | Sum = Sum + Ki * Err - Kc * Exc |
13 | }
|
Laut AN1078 soll man die 'Sum' Variable des W-Reglers beim Umschalten auf den Referenzwert des Iq Reglers setzen, um den von Gonzo erwähnten Sprung zu vermeiden, das hilft aber leider auch nicht. @Tec: Was meinst du mit: ".. schaltest du den Eingang der PLL auf den Winkelfehler zwischen Fluss beobachter mit Tiefpass". Soll ich den Referenzwert der W-Schleife auf den Winkelfehler zwischen errechnetem und den aufaddierten Winkel setzen? Den tatsächlichen Winkel weiß ich allerdings nicht, weil ich keinen realen Positionssensor habe, aber die Abweichung sollte bei niedriger Drehzahl ja nicht wirklich existieren oder? Grüße Andreas
Mit der PLL meine ich das du eine Winkel Regelschleife baust. Also
______________w
|
wt'--o--PI--Integrator----wt''
|- |
| |
------------------
wt' ist der winkel von deinem Estimator. Die Pll gegelt diesen quasi
aus. Das filtert den Winkel und sorgt für eine stetige drehzahlberechnug
w.
Andere Sache mal zu deinem Aufbau. Fahr doch mal mit konstanter Uq ohne
Regler. Dann kannst die Sprünge aus den Reglern ausschließen. Dann geht
es nur um deinen Winkelfehler den dein Estimator macht.
Was für ein Estimator wird in AN1078 verwendet?
Was mir im Moment noch nicht ganz klar ist, ist warum bei dir der gesteuerte Winkel mit dem geschätzten in etwa übereinstimmen. Wenn Du gesteuerte hochfährst wirst du gewöhnlich nicht den optimalen Arbeitspunkt des Motors treffen. D.h. der q Srom den du mit dem gesteuerten Winkel berechnet wird in der Realität eine Mischung aus d und q sein. Wenn du dann zum Um schält Zeitpunkt den Drezahlregler mit dem zuvor eingeprägten "q" Strom initialisiert hast du wahrscheinlich trotzdem einen Sprung im System. Ich fahre eigentlich immer mit einem recht hohen gesteuerten Strom hoch damit der Motor immer anläuft. D.h. bei mir überwiegt der d-Strom oft. Noch eine Frage: Wie hast Du die Stromregler eingestellt? Laufen die beiden Regler korrekt? Hast du überprüft das hier nichts schwingt? Gruss ....
Den Motor ohne Regler zu steuern hat mich ein wenig weiter gebracht, bzw. ein Erkenntnis. Der verwendete Motor (alte HDD) hat einen Phasenwiderstand von 1.85Ohm, dh es kann ein maximaler Strom von 12V/1.85Ohm = 6.5A fließen. Meine Shunts+OpAmp Beschaltung habe ich auf 1A ausgelegt. Das heißt ich ich kann nur (1/6.5) des max. Stromes messen. Wenn ich jetzt, egal ob mit oder ohne PID Regler die Länge des d-q-Zeigers auf (1/6.5) = 0.15 limitiere, läuft der Motor tatsächlich mit dem Winkel des Beobachters weiter, jedoch sehr schlecht, auf dem Oszi kann man kaum erkennen dass es so ein Winkel sein soll. Bei 0.16 Zeigerlänge dreht der sich nicht mehr. Jedoch komme ich so kaum auf hohe Drehzahlen :(. Geschätzt unter 300umdr. und auch fast kein Drehmoment. Setze ich einen kleineren Shunt (0.005 statt 0.05) ein, ist vermutlich die Messung nicht mehr genau genug, denn der Motor läuft dann wieder nicht. Eigentlich sollte ja der Phasenwiderstand mit steigender Drehzahl sinken und somit könnte ich den d-q Zeiger wieder länger machen oder sehe ich das falsch? Ich denke, mein geschätzter Winkel stimmt mit dem gesteuerten überein weil ich schon während der Anfahrrampe d und q Regler verwende. Mit der Reglereinstellung habe ich viel gespielt, sollte jetzt eig. passen. Werde ich mir morgen noch einmal ansehen. Bin natürlich für weitere Tipps offen :) Grüße, Andreas
Nur am Rande. Ich habe gerade die AN11517 von NXP entdeckt und ein wenig darin rum gestöbert: http://www.lpcware.com/content/nxpfile/an11517-field-oriented-control-foc-pmsm-motor-using-lpc15xx Der enthaltene Code ist recht minimalistisch, so dass man da schnell einen Überblick erhält. Als zusätzliche Lektüre zum Thema sicherlich gut geeignet. Auch sonst ist der LPC15xx ein sehr interessanter Vertreter der M3's. Insbesondere mit integrierter Band Gap und eeprom, was man nicht so häufig antrifft. Ausserdem NXP-typische Treiber im ROM. Insgesamt ist der Chip wie gemacht für SVPWM bzw. Motorcontroll.
Andreas True schrieb: > Ich denke, mein geschätzter Winkel stimmt mit dem gesteuerten überein > weil ich schon während der Anfahrrampe > d und q Regler verwende. Das kann nicht sein. Du prägst mit der Regelung einen Stromvektor in den Motor ein. Der wird dem wenn er kann folgen. Da dein Motor ohne Last läuft wird der Flussvektor (normaler weise in Phase mit Id) fast genau mit dem Stromvektor in Phase sein. Wie Gonzo schon geschriben hat. Irgend was passt mit deinem berechnetem Winkel nicht. Ich würde erwarten wenn du stuhr U_D so fährst das sich ca. 0,5A I_D einstellen. Und dann den Winkel langsam hoch laufen lässt mit steugender Drehzahl bis du den Motor schön schnell drehen hast. Dann lässt du ihn mit Konstanter Drehzahl weiter laufen, rein gesteuert ohner Beobachter. Dann vergleichst du den aktuellen gesteuerten Winkel mit dem geschätzen Winkel. Jetzt sollte der Winkel des Beobachters deinem Gesteuerten Winkel um ca. 1-10° nachlafen. Ohne Belastung der Maschine. Wenn das nicht so ist bei wohl gemerkt Gesteuerter U_D nich U_Q dann musst du deinen Beobachter überarbeiten bis das so ist. Und dann kannst du darüber nachdenken bei Geregeltem I_Q deine Maschine hochzufahren und umzuschalten. Gruß Tec
Angehängte Dateien:
-
20141104_1237521.jpg
110 KB
Hallo Tec, vielen Dank für die ausführliche Beschreibung. Ich habe es jetzt so ausprobiert, wie du es beschrieben hast: - Nicht auf den berechneten Winkel umschalten, auf dem gesteuerten bleiben - U_d auf 0.3 konstant gesetzt, ohne PID Regler Was sollte ich an dieser Stelle für U_q vorgeben? Jetzt ist U_q = 0. Wenn ich den Motor so steuere, ist die Winkelabweichung sehr gering, schätze unter 10° (Beobachter eilt nach) Dazu habe ich ein Foto angefügt. Unteres Signal zeigt den vorgegebenen, gesteuerten Winkel, oberes den vom Beobachter. Es wird quasi von 0-360-0-360-... dargestellt. Wenn ich jetzt auf den Beobachter Winkel umschalte und die PID Regler z.B folgendermaßen regeln lasse: I_q = 0.2; I_d = 0; bleibt der Motor stehen. Wenn ich zusätzlich den beobachteten Winkel um konstant 90° nach vorne shifte, dreht sich der Motor, jedoch ziemlich langsam und ohne Drehmoment (wieder obere Situation). Mittlerweile denke ich, dass es vllt. doch an den Reglerparametern liegen könnte, denn ohne wird der Winkel ja scheinbar richtig berechnet. Ich habe diese jeweils für q und d folgendermaßen eingestellt:
1 | P = 0.05; |
2 | I = 0.01; |
3 | D = 0.99999; |
4 | OutMax = 0.99999; |
5 | OutMin = -OutMax; |
Passt es so oder total daneben? (Regler werden mit 20kHz aufgerufen) @Gast, AN11517: Kennst du die AN10889? Dort es auch sehr ähnlich und sehr gut beschrieben. Grüße, Andreas
Moin, So meinte ich das. Sieht ja erst mal super aus. Du verwendest den Code der AN1078? Hast du mal geprüft was für eine Ud und Uq deine Regler rausgeben? Vllt ist die zu niedrig. Anderer Test wäre mit Uq = 0.3 und Ud = 0.0 zu fahren. Wie zu anfang und bei drehendem Motor auf den Beobachter Winkel umzuschalten. Der Beobachter winkel sollte vor dem Umschalten um ca 90-80° voreilen. Weil der Rotorfluss bei gesteuerten Drehen deinem Winkel folgt und so mit der Q-Achse nach eilt wenn du Uq auf die Maschine gibst. Anderer Test wäre bei Vorgegeben Iq/Uq einen negativen Id/Ud einzustellen. Es gibt Beobachterstrukturen die einen Id verschieden von null brauchen um sauber mit niedrigen Drehzahlen zulaufen. Du drehst zwar schon schön schnell aber vllt bringts was. Andre Sache wäre deinen Gesteuerten Winkel und den Beobachteten gewichtet zu mitteln.
1 | wt_est // Beobachter Winkel |
2 | wt_ctr // Gesteuerter Winkel |
3 | g // Gewichtung |
4 | |
5 | wt = wt_est*g + (1000 - g)*wt_ctr |
g bleibt erst mal auf 0 und dann wenn du umschaltest, dann incrementierst du g alle ms um 1. Damit solltest du einen stetigen Übergang der Systeme haben. Gruß Tec
Ich habe jetzt U_q = 0.3 U_d = 0 eingestellt und der Beobachter eilt, wie du es gesagt hast um ca 90° vor :) Muss man bei dem gewichtetem Mittel nicht zusätzlich durch 1000 teilen?
1 | wt = ( wt_est*g + (1000 - g)*wt_ctr ) / 1000; |
Ich habe es jetzt mit 1000 probiert, also 1 Sekunde Übergangszeit und auch mit 10000, also mit 10 Sekunden Übergangszeit . Damit ich am Anfang der Übergangszeit quasi so gut wie nur mit dem gesteuerten Winkel fahre. Trotz der 10 Sekunden bleibt der Motor sofort nach der Umschaltung stehen. Das deutet darauf hin, dass der PID Regler total falsch regelt oder? EDIT: Wenn ich auf den Beobachter Winkel umschalte, aber weiterhin bei meinen konstanten U_q = 0.3 U_d = 0 bleibe, bleibt der Motor nicht sofort stehen sondern dreht immer 'schlechter', bis der Übergangszeit vorbei ist, dann bleibt er ebenfalls stehen. Grüße, Andreas
Andreas True schrieb: > Muss man bei dem gewichtetem Mittel nicht zusätzlich durch 1000 > teilen?wt = ( wt_est*g + (1000 - g)*wt_ctr ) / 1000; Jop richtig erkannt. Andreas True schrieb: > EDIT: Wenn ich auf den Beobachter Winkel umschalte, aber weiterhin bei > meinen konstanten > U_q = 0.3 > U_d = 0 > bleibe, bleibt der Motor nicht sofort stehen sondern dreht immer > 'schlechter', bis der Übergangszeit vorbei ist, dann bleibt er ebenfalls > stehen. Das deutet darauf hin das dein Beobachterwinkel 90° versetzt ist. Addiere mal Pi/6 bis pi/3 bzw. 30-60° auf deinen Beobachterwinkel auf. Ist das verhalten dann immer noch so? Gruß Tec
Leider ist das Verhalten immer noch so, mein Beobachter muss ziemlich schlecht sein :D Aber wenn man es rechnerisch betrachtet: Dazu nehme ich Rotor vom Motor ab, es bleiben also nur die Spulen. Beim Beobachter setzte ich den Slide Gain auf 1. 1) Wenn man jetzt U_d = 0.3 und U_q auf 0.0 setzt muss die Abweichung zwischen Beobachter Winkel und gesteuerter Winkel Null sein. (bzw. minimal nachlaufen da keine ideale Spule) 2) Bei U_d = 0.0 und U_q = 0.3 muss der beobachtete Winkel um 90° voreilen. Sind diese Test ohne Rotor korrekt? Dann könnte ich den Beobachter darauf trimmen. Hatte heute leider keine Zeit das ordentlich einzustellen und auszuprobieren. Grüße, Andreas
Moin, Ohne Rotor fehlt dir aber die entscheidende Komponente die dein Beobachter beobachten soll. Ohne Rotor kein Rotorfluss, dadurch keine BEMF, also ist der Fehler der Berechnung des Stroms aus dem Z für dem SMC gebildet wird, quasi NULL. Wenn das n Festplatten Motor ist hat der doch Hallsensoren. Vllt bringst du erst mal die zum laufen? Wenn Englisch nicht das Problem ist guckt dir mal folgendes an. https://b94be14129454da9cf7f056f5f8b89a9b17da0be.googledrive.com/host/0B0ZbiLZrqVa6Y2d3UjFVWDhNZms/motordrive/sensorless_gen1_Rev1.pdf http://scolton.blogspot.de/p/motor-controllers.html Gruß Tec
Hallo Andreas, hast du bei deiner Inbetriebnahme des Beobachters auch schon mal den geschätzen Strom mit dem gemessenen zusammen dargestellt? Die beiden sollten eigentlich relativ über einander lieber. Hierzu gibt es auch ein AppNote von Microchip das den Einstellprozess beschreibt. Der Winkel muss auch nicht 100% stimmen. Wenn er nicht 100% passt schlägt sich das erst mal im Wirkungsgrad nieder. Der Motor sollte aber trotzdem laufen. Das könnte man dann aber z.B. auch noch quick and dirty über einen Offsetwinkel korrigieren. Den Stromregler kannst du über eine Sprungvorgabe prüfen, d.h. einfach die Regler arbeiten lassen und den Winkel festhalten. Dabei dann einen Sollsprung des d-Reglers vorgeben und gucken was der Motorstrom macht. Damit kann man zumindest die d-Achse grob überprüfen. Wie hast Du die Reglerparameter ermittelt? TN wird normalerweise auf die elektrische Zeitkonstante eingestellt und KP sodass der Regler nicht so doll über schwingt (Betragsoptimum). Wie sieht eigentlich der Stromverlauf in der Anlaufphase aus? Der Anlauf findet normalerweise mit einem recht hohen Strom statt. Wenn dann auf den korrekten Winkel umgeschaltet wird fällt der Strom dann sehr stark weil dann der Arbeitspunkt passt. Besonders im Leerlauf wird dann der Strom sehr klein und die ADCs werden nur noch gering aus gesteuert. Vielleicht ist das noch ein Problem bei dir? Viele Grüsse
Angehängte Dateien:
-
post.jpg
150 KB
Hi, ich habe meinen Beobachter überarbeitet, nun läuft der Motor mit dem beobachteten Winkel :) Wenn ich zu dem Winkel einen künstlichen Offsetwinkel addiere oder subtrahiere, wird der Lauf schlechter, also nehme ich an, dass der Winkel jetzt stimmt. Die Tests, die Tec vorgeschlagen hat (U_q = 0.3, U_d = 0, ..) erfüllt der Beochter auch. Dieser Festplattenmotor hat leider keine Hallsensoren. Die Regler über eine Sprungvorgabe habe ich noch nicht getestet, werde es aber noch machen. Ich habe die Regler jetzt erstmal soweit vereinfacht, dass es nur noch P-Regler sind. Für Parameter P habe ich den Wert 1.5 eingestellt. Wenn ich jetzt den Phasenstrom betrachte (mit Scope direkt an einem der Motoranschlüsse über LowPass Filter) sieht es schon ziemlich sinusförmig aus, jedoch mit Ripple. Problem dabei ist, dass der Motor ziemlich laute Geräusche von sich gibt, nicht ein regelmäßiges Pfeifen, wie zB bei 1kHz PWM sondern unregelmäßig. Liegt das an dem Ripple auf dem Oszi Bild? Bis jetzt habe ich es nicht geschafft, die Kurve glatter zu machen. Der Stromverlauf während der Anlaufphase sieht genau so aus, wie Gonzo es beschrieben hat, sobald es auf den Beobachter umgeschaltet wird, sinkt die Stromaufnahme. Ich hätte noch eine Frage bezüglich der Parameter für inverse Park-Transformation. In AN1078 wird die Vektorlänge aus Vq und Vd (also die Pfeillänge aus den Parametern für inverse park.) auf 0.95 limitiert mit der Begründung, dass man genügen Zeit für die Strommessung übrig lässt. Dabei wird zuerst der V_d Anteil per PID Regler berechnet und dann wird per Pythagoras der maximale Output Wert für den V_q Regler aus der Restlänge ermittelt. Sprich V_q wird limitiert, V_d nicht. In etwa so:
1 | Vs = SQRT(Vd^2 + Vq^2) < 0.95 |
2 | Vq = SQRT(0.95^2 - Vd^2) |
1) Braucht man hier wirklich so viel Zeit für die Messung? 2) Wenn ich diese Limitierung mitlaufen lasse, kann ich als Referenz für I_q auch extrem hohe Werte einstellen, diese werden von der Limitierung abgeschnitten. Somit bekomme ich für V_q nicht besonders für raus -> Weniger Drehmoment. Ist das wirklich so gewollt mit der Limitierung? Grüße, Andreas
Hallo Andreas, das ist doch super wenn der Motor jetzt läuft! Hast Du von deinem Motor schonmal die EMK aufgenommen? Ist die sinusförmig oder auch verzerrt? Ggf. ist das die Ursache für deine Stromform und auch dein Geräusch. Geräusche entstehen oft dadurch, dass das Drehmoment nicht konstant ist, d.h. die Stromform passt nicht zur EMK. Zur Begrenzung: Die ist schon wichtig wenn Du an die Auststeuergrenze des Umrichters gehst. Du musst immer einen Nullzeiger haben damit Du die Motorströme messen kannst. Wie groß dieses Zeitfenster sein muss hängt von deinen Strommesskreisen ab, d.h. davon wie schnell die Schaltung am Ausgang, bzw. am ADC Eingang, einschwingt. Auch hier würde ich mal einen Sprung draufgeben und dann mal gucken was der Messverstärker macht. Da du in der Mitte des Nullzeigers misst musst Du auch das berücksichtigen, d.h. Einschwingzeit mal 2. Wie viel das dann in Prozent ist hängt natürlich auch von der PWM Frequenz ab die Du einsetzt. Über diese Begrenzung stellst Du im Endeffekt sicher, dass Du nicht die Schwingungen deines Strommessverstärkers misst, sondern den realen Motorstrom. Bei der Ansteuerung hast Du eigentlich zwei Begrenzungen: Eine aus der SVPWM (=> Kreisbegrenzung auf cos 30°) und eine für die Strommessung (im Beispiel 95%). Viele Grüße...
Angehängte Dateien:
-
post1.jpg
63 KB
Guten Abend, ich habe mit den PID Reglern alles mögliche ausprobiert, leider ohne Verbesserung. Ich denke die sollten passen, ich habe jetzt die Werte aus der AN1078 übernommen. Die Strombegrenzung habe ich auf 95% eingestellt. Die EMK ist sinusförmig. Wenn ich den Motor nicht mit SVPWM sondern mit drei um 120° verschobenen Sinuskurven ansteuere (sinusoidal drive?) und den Phasenstrom direkt am Motor per Scope betrachte, sehe ich absolut perfekte Sinuskurven. Der Motor läuft dabei absolut ohne Geräusche. In der SVPWM dagegen hört man den Motor sogar pfeifen wenn man rein mit dem vorgegebenen Winkel fährt, also noch bevor es auf den Beobachter umgeschaltet wird. Währenddessen fahre ich mit U_q = 0.2; U_d = 0; Im Anhang ist ein Foto während der Motor mit einem vorgegebenen Winkel und SVPWM läuft. Habt ihr eine Idee vorher dieser "Knick" bei 0° und bei 180° kommt? Auch wenn ich auf den Beobachter Winkel umschalte ist dieser Knick da. Vielleicht kommen die Laufgeräusche daher? EDIT: die Obere Kurve stellt den beobachteten Winkel dar, die untere den Phasenstrom, gemessen direkt am Motor. Grüße Andreas
Moin, Das der Strom nicht ganz Sinusförmig ist wenn du mit gesteuertem Winkel fährst ist klar. Der Motor Lockt ja. (er kann dem Spannungsvektor schneller folgen als du den Winkel incrementierst. Folglich holt der Motor regelmäßig auf den Spannungsvektor auf und überschwingt. Daher die Rippel auf dem Strom) Ich vermute mal deine SVPWM ist nicht stetig. Prüfe bitte mal ob deine SVPWM saubere POPO Kurven produziert. Und ob die Phasenrichtig sind. Ist n Böser Fehler es gibt SVPWM implementierungen die ein 30° Offset haben, bzw die alpha Achse (Alpha-Beta-System) nicht auf der A Achse (ABC-System) liegt. Gruß Tec
Hallo Tec, reicht es, einen Kreis mit dem Zeiger aus Valpha und Vbeta (also mit den Input - Parametern der Inversen Clarke) abzufahren und den Ausgang der Halbbrücken anzuschauen um die Popokurven zu überprüfen? (ohne Motor, denn der würde ja die Popokurven glätten(?)). Jetzt ist es bei mir so, dass der Sprung in der Sinuskurve (Foto letzter Beitrag) auch ohne eines angeschlossenen Motors kommt, also muss der Fehler wirklich in der SVPWM liegen :( Grüße, Andreas
Jap die Spannung kannst du auch ohne Maschine prüfen. 3 RC Kombi im Stern an die dreiphasen und dann Phase gegen Gnd messen. Der mittelpunkt sollte dabei gegen Gnd einen Dreieck fahren. Kennst du den Thread über die SVPWM mit einem LPC musst mal im forum suchen vllt findest da auch infos.
Angehängte Dateien:
-
post2.jpg
150 KB
Hallo, ich habe zwar den Strom noch nicht gemessen (bin noch nicht zu hause). Dafür habe ich meine SVPWM mit
1 | V_q = 0.2 |
2 | V_d = 0.0; |
gefüttert und den Winkel von 0 bis 2PI rotiert. Die Angefügten Kurven sind dabei rausgekommen. (links die drei Phasen, rechts diese drei übereinander gelegt) Das sind quasi die Signale, die ich aktuell auf die PWM Duty lege. Meine Vektorumrechnung muss wohl einen Fehler haben. Gruß, Andreas
Ich würde mal sagen du würfelst die Sektoren wild durch ein ander. Bzw die Sektoren 2/3 und 4/5 sind invertiert. Prüf mal ob du die Phasenreihenfolge nicht durch einander kriegst.
Angehängte Dateien:
-
post3.jpg
210 KB
Tec, du hattest wie immer Recht :) Ich hatte alle Vektoren invertiert. Hier das Ergebnis, oben der Output der InverseClarke, unten die POPO Kurven. U_q ist jetzt probeweise auf 1.0 gesetzt. Vielen Dank! Jetzt setze ich das ganze mal in den uC und mal schauen was der Motor dazu sagt. Gruß Andreas
Angehängte Dateien:
-
post4.jpg
120 KB
Bei dem letzten von mir geposteten Diagramm beginnt keine der drei Phasen bei Theta = 0. Hast du das mit "30° Offset" gemeint? Würde ich diesem Offset dann nicht zwangsweise im Beobachter dazuaddieren müssen? Ich habe die Vektorumrechnung so abgeändert, dass nun eine der Phasen bei Theta = 0 anfängt. (siehe Anhang) Der Beobachter erfüllt die Tests, die du weiter oben vorgeschlagen hast immer noch. Mit gesteuertem Winkel läuft der Motor perfekt, auch die Spannungskurven direkt am Motor gemessen sehen top aus. Mit Beobachter Winkel Winkel und PID Regler läuft er auch, aber noch nicht so gut. Gruß Andreas
Moin, Bei dir ist p1 genau im maximum bei theta 0. Also super. Wenn an dem punkt alpha auch max ist und beta 0. Dann ists phasen richtig. Wenn spannung und strom nicht phasen richtig sind dann stimmt die beobachter Gleichung ja nicht. Hast du filter in der Strommessung? Die erzeugen dir ja einen phasen fehler beim strom. Weshalb dann auch hier die beobachter gl. Nicht korrekt ist der fehler sollte aber soklein sein das der beobachter nicht gleich glaubt die maschine dreht rückwärts. ( was du in vollem lauf hättest wenn du phasen fehler nicht vorher schon ausmerzt. Stichwort Singularität von sin/cos).
Jap, ich habe zwei Lowpassfilter, welche laut AppNote zusammen eine 90° Verschiebung ergeben. Was ich bei der SVPWM, unabhängig vom Beochbachter noch nicht ganz verstehe ist Folgendes: Das Programm läuft ja Folgendermaßen ab: Phasenströme messen -> Clarke -> Park -> (PID Regler) -> Inverse Park -> Inverse Clarke -> SVM -> Duty Zeiten Setzen. Alpha und Beta ergeben sich ja aus der Messung der Ströme. Diese werden wiederum von der letzten Iteration bestimmt, also SVM(n-1). Mit der SVM lege ich die Spannung fest. Der Strom eilt der festgelegten Spannung um 90° nach. Wenn man das jetzt auf mein oberes POPO Kurvendiagramm anwendet: p1 (also der Wert, den ich auf Duty lege) ist bei Theta = 0 maximal. Damit die SVPWM phasenrichtig ist, muss gültig sein: (Alpha = max && p1 = max && Theta = 0) -> ist sowas möglich oder habe ich es falsch verstanden? Strom eilt ja bei Spule trotzdem immer nach. Ich hätte gemeint, dass folgendes richtig wäre: ( Alpha(n+1) = max ) && ( p1(n) = max ) && ( Theta(n) == 0 ) Also dass Alpha erst beim nächsten Durchlauf der jetzigen p1 phasengleich wird. (mit n meine ich die Anzahl der Programmdurchläufe) Grüße, Andreas
Andreas True schrieb: > Jap, ich habe zwei Lowpassfilter, welche laut AppNote zusammen eine 90° > Verschiebung ergeben. Bei welcher Drehfrequenz? Andreas True schrieb: > Damit die SVPWM phasenrichtig ist, muss gültig sein: > (Alpha = max && p1 = max && Theta = 0) > -> ist sowas möglich oder habe ich es falsch verstanden? Strom eilt ja > bei Spule trotzdem immer nach. Richtig. Wir reden hier nur von der Spannung. Was ich meine Du regelst Id/Iq für einen Strom dessen Transformation abc/dq darauf bassiert das für theta = 0 id in Phase mit Ia ist. Dann muss das Zwingend auch für die Spannungen der SVPWM so sein. Sonst ist den Modell Ja falsch. Denn alle beruht genau darauf. Außerdem empfinde ich die 90° Phasen Lag durch deine Filter als sehr hoch. Zumal das ja arg(R+1/(jwC)) ist also Drehzahl abhängig. Durch denk das noch mal genau.
Zum Beobachter: Der Filterkoeffizient wird in der Appnote drehzahlabhängig angepasst:
1 | #define LOOPTIMEINSEC (1.0/PWMFREQUENCY)
|
2 | #define SPEEDLOOPTIME (1.0/SPEEDLOOPFREQ) // Speed Control Period
|
1 | // Filter estimated BEMF voltages
|
2 | EalphaFinal = EalphaFinal + Kslf * Ealpha - Kslf * EalphaFinal; |
3 | EbetaFinal = EbetaFinal + Kslf * Ebeta - Kslf * EbetaFinal; |
1 | // Calculate smc filter coefficient from omega
|
2 | Kslf = OmegaFltred * (LOOPTIMEINSEC/SPEEDLOOPTIME); |
Omega wird dabei alle 'SPEEDLOOPTIME' aus dem aufaddierten Theta ermittelt. Wobei ich das ehrlich gesagt noch nicht verstanden habe. Zu SVPWM: Nur nochmal zur Sicherheit: Es gilt: 1)Ich fahre mit vorgegebenem Winkel 2)jetzt gerade (n=1) ist Theta = 0. Ich messe die Ströme. Diese müssen soweit verschoben sein, dass in diesem Moment (n=1) Alpha = max sich aus den gemessenen Strömen ergibt. Nun berechne ich die SVM. Diese muss mir (immer noch n=1) für p1 = max ausspucken. Das schicke ich dann auf die PWM Duty. Also schickt man die Spannung um 90° nacheilend in den Motor? Bzw. man schickt die Spannung phasengleich zum gemessen Strom, immer noch bei (n=1) Ich nerve bestimmt schon mit meinen Fragen :/
Hallo Tec & Andreas, ich glaube ihr redet von unterschiedlichen Filtern. In der AppNote gibt es zwei Tiefpassfilter innerhalb des Sliding Mode Observers. Diese TP Filter werden entsprechend der Drehzahl nachgeführt sodass sich immer 90° Phasenverschiebung ergeben. Ich denke Du, Tec, meinst TP Filter direkt in der Strommessung des Motors, d.h. außerhalb des Beobachters, oder? Wann rechnest Du eigentlich deinen Beobachter? Das geht aus deinem Ablauf oben nicht hervor. Normalerweise sollte der Ablauf wie folgt sein: 1. Strom messen 2. Clarke 3. Beobachter rechnen um aktuelle Winkel zu haben 4. Park 5. PI-Regler für die Ströme 6. inv. Park 7. SVPWM Ist das so bei Dir, Andreas? Dann noch was. In den Beobachter fließt ja auch die Ausgegebene Spannung Richtung Motor ein. Hier muss man beachten, dass man hier die richtigen Spannungen verwendet da sich aufgrund der meist verwendeten gepufferten Ausgabe meist eine Verschiebung um einen Reglertakt ergibt. Was Du hier probieren kannst ist, einfach mal einen Offset einzurechenen und diesen dann im Motorlauf mal zu verändern. Ggf. kannst Du damit den optimalen Winkel finden. Noch eine Sache ist die Abtastfrequenz des Reglers. Wenn ich es oben richtig sehe rechnest Du nur 5-6 mal pro elektrischer Periode. Entspricht das auch deiner PWM Frequenz, d.h. rechnest Du in jedem PWM Takt oder nur jedes n-te mal? Ggf. solltest Du etwas häufiger rechnen. Gruß, Gonzo
Hallo Gonzo, den Beobachter rechne ich gleich nach der Strommessung. Da man bei Clarke den Winkel noch nicht braucht, kann man sagen dass es deiner oberen Liste entspricht :) Edit: hier lag ich falsch->Clarke muss man vor dem Beobachter rechnen, denn dieser braucht die Ergebnisse der Clarke. Die d und q Regler rechne ich jeden PWM Zyklus. Das mit dem Offset im Beobachter werde ich auf jeden Fall ausprobieren. Zuerst möchte ich SVPWM an sich richtig und phasenkorrekt einstellen. Übrigens: mit dem HDD Motor brauche ich 6 elektrische 0-360 Durchläufe für eine Umdrehung. Wenn ich das hochrechne, schaffe ich dem Motor ohne Platten 20kRPM mit vorgegebenem Winkel :D Gruß Andreas
Hallo Zusammen, @Gonzo: Du hattest recht ich meine Filter im Strom Pfad. An die BEMF Filter des Beobachters der AN1078. @Andreas: Deine SVPWM würde ich erst mal so lassen. Wie es aus sieht braucht dein Beobachter eine gewisse drehfrequenz damit der vernönftig läuft auch wegen der Filter. Außerdem ist das Phasengang ja recht fix bei 90° mit der w-Kompensation. Ich würde folgendes Probieren. Maschine OpenLoop hoch drehen auf sagen wir 200rad/s = w, dann auf den Beobachter umschalten. Jetzt würde ich mir irgend einen Kanal suchen mit dem du einen Offsetwinkel im Lauf ändern kannst. Tip: Bei ST-Link und STM32 sieh dir STMStudio an damit kannst du Variablen im lauf manipulieren. Oder so tools wie FreeMaster (braucht aber ne gegenstelle im Controller und ist von FreeScale, zwar frei soll aber laut lizenz nur auf FreeScale Controller eingesetzt werden. Hobby mäßig kräht da aber bestimmt eh keiner nach. ) Gruß Tec
Guten Abend. Achso, nein, ich habe noch keine Filter im Strompfad. Zur Zeit verändere ich meine Variablen, wie zb den Winkeloffset während der Laufzeit mit ein paar Tastern, mit denen ich dann + und - rechne. Vielen Dank für den Tipp mit STMStudio: Tecnologic schrieb: > Bei dir ist p1 genau im maximum bei theta 0. Also super. Wenn an dem > punkt alpha auch max ist und beta 0. Dann ists phasen richtig. Welches Alpha und Beta beziehst du dich hier? Ich habe ja zwei davon: 1. Erhalte ich ein Ialpha und Ibeta nach der ClarkeTransformation aus den gemessenen Strömen. 2. Valpha und Vbeta nach Inverse Park Transformation. Allerdings wird ja Valpha = max und Vbeta = 0 bei Theta = 0 nur wenn man U_d != 0 und U_q == 0 eingestellt hat, sonst nie, da iniverse Park:
1 | Valpha = Vd * cos_angle - m1.Vq * sin_angle; |
2 | Vbeta = Vd * sin_angle + m1.Vq * cos_angle; |
Ich will meine SVPWM richtig einstellen, wie alle anderen :D, auch wenn meine jetzt so scheinbar läuft, hätte ich es ganz gerne richtig rum ;) Gruß Andreas
Andreas True schrieb: > Allerdings wird ja Valpha = max und Vbeta = 0 bei Theta = 0 nur wenn man > U_d != 0 und U_q == 0 eingestellt hat, sonst nie, da iniverse Park: Genau das ist der Punkt. Wenn bei Theta = 0 und Vq = 0 und Vd = 1 gilt Valpha = Vd = Va =1, Vbeta = Vq = 0, Vb und Vc ergeben sich dann. Für Theta = 0 liegen alle Koordinatensystem über einander. Vd-Achse auf Valpha-Achse und auf der Va-Achse. Für Theta pi/2 bzw. 90° muss dann Vd mit Vbeta gleich sein und Vq = -Valpha. Wenn diese Bedingungen passen sollte die SVPWM phasenrichtig sein und sich auch in die richtige Richtung drehen. Wenn dann deine Stromtransformationen genauso richtig sind also das gleiche gilt. Dann ist die Basis sauber. Dann kannst du dich in Ruhe um die Eigenheiten des Beobachters wie die 90°Phase kümmern. Du suchst sonst immer beim Beobachter dabei sinds Grundlagen die nicht passen. Da fallen auch gestandene Umrichter Entwickler drauf rein. Also Thumbs up fürs saubere Prüfen der Transformationen. Gruß Tec
Angehängte Dateien:
-
post5.jpg
180 KB
Tec Nologic schrieb: > Genau das ist der Punkt. Wenn bei Theta = 0 und Vq = 0 und Vd = 1 gilt > Valpha = Vd = Va =1, Vbeta = Vq = 0, Vb und Vc ergeben sich dann. > > Für Theta = 0 liegen alle Koordinatensystem über einander. Vd-Achse auf > Valpha-Achse und auf der Va-Achse. Für Theta pi/2 bzw. 90° muss dann Vd > mit Vbeta gleich sein und Vq = -Valpha. vielen Dank für die Zusammenfassung (y) Dann waren meine Transformationen richtig :) Das einzige was mich jetzt dabei noch stutzig macht: Tec Nologic schrieb: > Für Theta pi/2 bzw. 90° muss dann Vd > mit Vbeta gleich sein und Vq = -Valpha sieht bei mir so aus: Theta| Vd| Vq| Valpha| Vbeta| P1| P2| P3| 90| 1| 0| 0| 1|0,5| 0| 1| Vq = -Valpha, sind aber beide 0, da Vq durchgehend auf Null ist. Dreht sich meine Transformation in die falsche Richtung?
Ne alles OK. Sieht gut aus. Mach das noch mal für Vq =1 VD=0 dann sollte die 2. Bedingung auch passen
Ich habe jetzt die nun korrekte svpwm in meine Motorsteuerung übernommen. Habe dafür leider auch den Beobachter wieder umschreiben müssen. Aber nun erfüllt er wieder die Tests von Tec. Vorerst aber noch ein wenig quick&dirty mit einem künstlichen Offset. So dass der beobachtete Winkel bei U_d = 0 und U_q = 0.3 um fast 90° voreilt. Sobald ich aber auf den Beobachter Winkel umschalte blockiert der Motor sofort :( Etwas anderes: Jemand von euch hat mir ja zusätzlich diesen Link vorgeschlagen: https://b94be14129454da9cf7f056f5f8b89a9b17da0be.googledrive.com/host/0B0ZbiLZrqVa6Y2d3UjFVWDhNZms/motordrive/sensorless_gen1_Rev1.pdf auf der Seite 60 unten schreibt er: "Multirotor motor controllers are typically “speed” controllers. (They control PWM duty cycle, which sets the average voltage. Ignoring the voltage drop across the motor’s resistance and assuming proper timing, this correlates to the back EMF, which is a function of rotor speed.) Field-oriented control is fundamentally a current control strategy. A speed control outer loop must be applied to make it compatible with standard flight controllers." Wieso braucht man unbedingt einen Regler für omega, welcher dann den Sollwert für den q-Regler vorgibt? Kann, wie in seinem Beispiel, die zentrale Quadcopter Regelung nicht direkt den Sollwert für den q-Regler vorgeben? Gruß Andreas
Dann müsstest du halt alle Messwerte mit deiner Reglerfrequenz vom Regler zum zentralen Regler übertragen und genauso schnell zurück. Außerdem kann das m.W.n. keine Standard Quadrocopter-Regelung. Diese müsstest du auch selber bauen. Dann ist es wohl einfacher direkt im Regler des Motor auf die Soll-Drehzahl zu regeln. Viele Grüße Michael
Andreas True schrieb: > Wieso braucht man unbedingt einen Regler für omega, welcher dann den > Sollwert für den q-Regler vorgibt? Überleg dir einfach wenn du den Iq konstant einregelst. Und der Motor beschleunigt wird die BEMF größer. Damit muss der Regler die Vq erhöhen um die BEMF zu kompensieren. Und das macht der dämliche BLDC-ESC nicht. der gibt quasi stuhr Vq = Duty und Vd = 0 vor. Und dann kommen die Spinner mit ihrem geilen Timing und geben noch n bischen Vd negativ vor. Um die Induktivität zu Kompensieren. Mit FOC bist du da viel besser beraten. Ind nur nicht so simpel. Einfachste Möglichkeit wäre Stuhr Vq vorgeben und Id zu 0 regeln. Wäre mal interessant das zu Probieren. Oder du baust n Drehzahlregler der Iq vor gibt. Das hat den scharm das du viel dynamischer bist als n normaler BLDC-ESC. Du kannst ja zum Bremsen auch negativen Strom vorgeben. USW. Gruß Tec
Guten Abend, so langsam verzweifle ich an der sensorlosen FOC :/ In Openloop liefert der Beobachter ordentliche Werte, doch sobald es auf auf Closedloop umgeschaltet wird ists vorbei. Könnt ihr mir vielleicht einen kleinen Motor mit einem integrierten Winkeldecoder empfehlen? Am besten einen, bei dem ich den Winkel über irgendeine Kommunikationsschnittstelle direkt auslesen kann (SPI, I2C, ...) oder eine bestimmte Anzahl von Ticks pro Umdrehung erhalte, so dass ich diese dann aufaddieren kann. Ich finde nichts passendes und für einen Studenten bezahlbares. @Tec: nochmal vielen Dank für den Tipp mit STM Studio, es erleichtert die Arbeit wirklich ungemein :) Grüße Andreas
Moin. Nimm einen Festplattenmotor mit HallSensoren da hast du alle 60° ne genaue Position. Damit kannst du deinen berechneten Winkel abgleichen. Siehe auch Paper von Shane Colton. Das ist wohl das günstigste. Hast du mal mit einem Winkel Offset rumgespielt?
Jup, bin mit Offset von -2.5Pi bis +2.5Pi mit 10Grad Schritten durchgegangen mit dem Ergebnis dass an manchen Stellen der Motor komplett blockiert und an anderen kommutiert die Steuerung vor sich hin mit zb 10000Pi / sekunde. Da wackelt der Rotor natürlich nur noch an der Stelle. Gruß Andreas
Das hört sich danach an das der Beobachter glaubt der Antrieb sei schneller. Hast du mit Rs und Ls gespielt? Deine Parameter sind wahrscheinlich falsch. Lass mal Rs in ruhe. Fahre Obenloop und spiel mal mit Ls rum. und sieh dir das verhalten an. Und dann guckmal das dein Beobachter deinem Winkel leicht hinterher eilt. Und denk an die 90° Phase die der Beobachter eh schon hat.
Hallo Tec, Tec Nologic schrieb: > denk an die 90° > Phase die der Beobachter eh schon hat Diese 90° sind aber in den Voraussetzungen: 1) V_q = 0.3 und V_d = 0 => eilt Beobachter Winkel um 80°-90° vor 2) V_q = 0 und V_d = 0.3 => Beobachter Winkel = vorgegebener Winkel schon mit eingerechnet oder? Wenn die Voraussetzungen erfüllt sind, stimmt dann die Beobachtergleichung? Verstehe ich das richtig, dass mein Beobachter mit vorgegebenem Winkel scheinbar "perfekt" läuft, auch mit falschen Parametern, weil ich den Motor sozusagen zwangsbestrome? Den Widerstand und die Induktivität habe ich mit einem recht teueren Gerät gemessen: R = 1.925[Ohm] und L = 0.000449[H]. Habe aber daran viel rumprobiert und tatsächlich eine Konfiguration gefunden mit der der Motor sehr gut mit dem Beobachter Winkel läuft, allerdings nur mit folgenden Einstellungen: R = 1.925; L = 0.005; // um Faktor 1000 mehr! dazu muss ich den maximalen und minimalen Ausgabewert der D_PID Schleife auf +0.01 und -0.01 setzten, sprich d wird so gut wie nicht nachgeregelt. max_output Q_PID = 0.2; min_output Q_PID = -0.2; So läuft der Motor wirklich sehr schön, allerdings schlagen die q und d Regler an die unteren output Grenzen, also ständig: pid_q.out = -0.2; pid_d.out = -0.01; So lässt sich das Drehmoment nicht Regeln, sobald ich die Grenze für Q-PID.output größer mache, wandert der Regler sofort wieder an den neuen Anschlag. Viele Grüße Andreas
Andreas True schrieb: > Diese 90° sind aber in den Voraussetzungen: > 1) > V_q = 0.3 und V_d = 0 => eilt Beobachter Winkel um 80°-90° vor > 2) > V_q = 0 und V_d = 0.3 => Beobachter Winkel = vorgegebener Winkel > > schon mit eingerechnet oder? Wenn die Voraussetzungen erfüllt sind, > stimmt dann die Beobachtergleichung? Moin, Sowie ich den Beobachter verstehe hängt er durch die beiden TPs immer 90° hinter her. Soll heißen Vd = 1 und Vq = 0 ohne +90° auf dem Winkel (bei w positiv) müsste bedeuten Vq = -1 und Vd = 0 für die Maschine. Also Grundsätzlich alles was aus dem Beobachter kommt +90° bei positiver Drehrichtung und -90° bei neg Drehrichtung. Andreas True schrieb: > Den Widerstand und die Induktivität habe ich mit einem recht teueren > Gerät gemessen: R = 1.925[Ohm] und L = 0.000449[H]. Habe aber daran > viel rumprobiert und tatsächlich eine Konfiguration gefunden mit der der > Motor sehr gut mit dem Beobachter Winkel läuft, allerdings nur mit > folgenden Einstellungen: > > R = 1.925; > L = 0.005; // um Faktor 1000 mehr! Hast du mal mit dem K Faktor des SMO gespielt. Ein hohes L deutet auf eine zu niedrig angesetzt BEMF. Also deine geschätzte Bemf ist zu niedrig. Wie fährst du die Maschine an? Mit Vd != 0 und Vq = 0? und dann umschalten oder mit geregeltem Iq ?? Mach bitte mal Folgendes. Iq auf einem guten Wert einregeln. Auf ca. w= 100/s Openloop beschleunigen. (Iq muss so groß sein das der Motor mühelos folgen kann!!!!, also bei dir min 0.5A besser 1A, das der in jedem Fall im lockenden Betrieb ist und der Fluss in Phase mit dem Strom ist.) Jetzt muss der Beobachter Winkel exakt 90° nach eilen. und zwar genau nach eilen. Nicht voreilen (180° also Vorzeichenfehler), Nicht 180° nacheilen dann ist den 90° Offset in die Falscherichtung. Und dann mit einem Poti langsam die Gewichtung auf den Beobachterwinkel fahren. bis das sauber geht. Gruß Tec
Mit dem K Faktor habe ich ich noch nicht gespielt, werde es gleich probieren. Die Maschine fahre ich mit V_d = 0.3; V_q = 0 damit ich beim Umschalten auf Openloop keinen Winkelsprung machen muss. Tec Nologic schrieb: > Iq auf einem guten Wert einregeln. Auf ca. w= > 100/s Openloop beschleunigen. (Iq muss so groß sein das der Motor > mühelos folgen kann!!!!, also bei dir min 0.5A besser 1A, das der in > jedem Fall im lockenden Betrieb ist und der Fluss in Phase mit dem Strom > ist.) Soll ich währenddessen Id auf Null regeln oder einfach V_d = 0 setzten? Wenn ich Iq = 0.5 und Id = 0 regeln lasse, mit gesteuertem Winkel, gibt der D-Regler ständig den maximalen Wert, also 1 aus. Somit zieht der Motor extrem viel Strom und der Beobachter läuft gar nicht mehr. (Wahrscheinlich weil bei so viel Überstrom die OpAmp Beschaltung nicht mehr passt) EDIT: gerade die Regler Parameter etwas abgeändert, jetzt läuft der D-Regler nicht mehr ständig an die Grenze und der Motor zieht auch nicht mehr so viel Strom. Grüße Andreas
Moin, Fahr den Motor so hoch wie du ihn auch Fahren willst. Also Iq = x und Id = 0 eingeregelt. Und mache für den Anfang die Regler ruhig etwas träge (wenig P Verstärkung). Dann sind sie robuster. Das mit dem auf den beobachter umschalten über Zeit haben wir ja schon mal besprochen, das würde ich erstmal auch so machen. Du hast nicht zufällig Matlab zur Verfügung? Ich persönlich Simuliere das gern vorher. Das ersparrt das Debugging am Motor. Kennst du das Ke oder Kt des Motors? Bzw. die Amplitude der Bemf bei 1000rpm oder so? Dann könnte man über Prüfen ob dein Beobachter die BEMF richtig schätzt. So wie ich das Problem einschätze. Wird die Amplitude der BEMF zu niedrig geschätzt. Bzw es wird ein Teil der BEMF der drehzahlabhängigen Spannung über der Spule zu geordnet. Also Rs und Ls auf realen Wert. Und dir die e_alpha und e_betas ansehen. Vllt auch e +z. Das Setzt der SMC ja als Bemf an. K muss hier dann so gewählt werden das die BEMF amplitudenmäßig mit der realen passt. Dann läuft der Motor auch. Selbst n unscented Kalman Filter mit Drehmomentschätzung usw. läuft nicht sauber wenn Ke daneben ist. Rs und Ls sind dem z.B. ziemlich egal, aber Ke muss passend sein. Gruß Tec
Hallo, vielen Dank für die Tipps, werde versuchen, diese umzusetzen. Ohne jetzt den unscented Kalman Filter zu kennen, ist dieser anders aufgebaut als der Beobachter in der AN1078? Ich habe heute n altes Thema (2011 oder so) gefunden, in dem du geschrieben hast dass du gerade dabei bist die AN1078 umzusetzen und dann die FOC Steuerung in einen Quadcopter einzubauen. Hast du das Projekt zu Ende realisiert, bzw. hast du die FOC genauso wie in AN1078 umgesetzt? Ich bin auch durch Quadrocopter auf das FOC Thema gekommen :) Grüße Andreas
Andreas True schrieb: > Ich bin auch durch Quadrocopter auf das FOC Thema gekommen :) Da sind wir dann schon zu dritt ;)
Michael Mayer schrieb: > Andreas True schrieb: >> Ich bin auch durch Quadrocopter auf das FOC Thema gekommen :) > > Da sind wir dann schon zu dritt ;) Ein kleines Motivationsvideo zwischen durch: http://vimeo.com/57710874
Andreas True schrieb: > Ich habe heute n altes Thema (2011 oder so) gefunden, in dem du > geschrieben hast dass du gerade dabei bist die AN1078 umzusetzen und > dann die FOC Steuerung in einen Quadcopter einzubauen. So lange ist das schon her :) Das lustige ist das ist mittlerweile viel mehr geworden :). Im Moment dreht sich meine Masterthesis um Beobachter für PMSM/BLDC Maschinen. Was AN1078 angeht. Habe ich den PIC schnell verworfen. Und bin beim STM gelandet. Programmiert sich einfach besser. Was mich an AN1078 immer gestört hat. Ist der Anlauf. Du hast dieses Problem jetzt auch. Du musst bei dem SMO/SMC K, Rs und Ls immer auf den Antrieb und die Applikation Abstimmen. Und vorallem musst du den Anlauf für jede Konfiguration von neuem Robust machen. Mich hats genervt. Das Problem haben aber alle BEMF basierten Beobachter. Dann kommen noch Probleme mit der Strommessung dazu dann brauchst du noch ne PLL die ripple auf Theta raus glättet. Man kann da viel machen. Ich verfolge mittlerweile den Ansatz. Aus dem Stand anzufahren immer mit Beobachter. Oder bei angetriebener drehender Maschine den Umrichter einschalten, und gleich ein Bremsdrehmoment einregeln. (Nutze ich als Lastmaschine). Bei sowas ist so ein Modellbasiertes Filter wie ein Kalman Filter sehr hilfreich. (Die werden meist auch bei Coptern für die Lagebestimmung benutzt.) Gruß Tec
Tec Nologic schrieb: > Du musst bei dem SMO/SMC K, Rs und Ls immer auf den Antrieb und die > Applikation Abstimmen .. Tec Nologic schrieb: > Aus dem Stand anzufahren immer mit Beobachter Das hört sich wirklich spannend an! Habe dazu ein wenig gelesen. Basiert es auf diese Ausarbeitung?: Terzic, B. & Jadric, M., 2001. Design and Implementation of the Extended Kalman Filter http://scindeks.ceon.rs/article.aspx?query=ISSID%26and%2611541&page=3&sort=8&stype=0&backurl=%2Fissue.aspx%3Fissue%3D11541 Kannst du dann wirklich aus dem Stand, auch ohne motor auf 0 grad einrasten zu lassen, und auch ohne Motordaten L und R, mit korrektem Winkel anfahren? Der Kalman Filter benötigt ja auch eine gewisse "erfahrung" während der Motorlaufzeit um sicher zu werden. Sind aber nur überlegungen, ich sollte wohl erstmat die An1078 zum laufen bringen. Aber ein bisschen informieren schadet ja nicht :) Sorry für die Rechtschreibung, schreibe mit smartphone Grüsse Andreas
Ganz ohne Abstimmung läuft auch ein EKF nicht. Aber ich hoffe mit Rs und der Modellbau üblichen KV Angabe auszukommen. Ld und Lq werde ich wohl über einen RLS Schätzer ermitteln. Gerade läuft aber der EKF zu langsam. Wird aber. Zu den Fähigkeiten. Ja ein EKF kann ohne die Rotorlage sauber anfahren und auch bei sehr langsamer Drehzahl noch gute Ergebnisse liefern. Richtungs Wechsel ist dann auch kein Problem. Er verliert bei 1000rpm auf -1000rpm nur 1 Umdrehung. Beim Vorzeichen Wechsel. Ist schon cool. N UKF ist da noch besser. Der hat den Antrieb immer im Griff. Braucht aber noch mal 50% mehr Rechenzeit im Vergleich zum EKF. Was in den papers immer nicht steht. Wie die die Beobachter auf realer HW laufen lassen. Dann stößt man auf Probleme wie NaNs und andere numerische Schreinereien. Im März will ich fertig sein dann poste ich mal was dazu. Vorher wird nix veröffentlicht. Sonst wirft mir noch wer vor ich hatte das nicht selbst gemacht. Gruß Tec
Hallo zusammen, Gonzo und Tec, ich hoffe ihr seid noch da, aber natürlich gerne auch andere ;) Da ich mit meinem Winkelbeobachter immer noch nicht so richtig weitergekommen bin, habe ich mir erstmal einen anständigen Motor und optischen Drehencoder gekauft und diese mithilfe von zwei L Profilen miteinander verbunden. Zur Kontrolle des Encoders habe ich dem Motor einen künstlichen Drehwinkel vorgegeben und mit dem des Encoders verglichen -> liegen übereinander: passt. Der Motor wird nur noch über Encoderwinkel steuert. Wenn ich der SVPWM feste Werte, z.B V_d = 0.2 und V_q = 0.0 vorgebe, dreht sich der Motor schön, mit anständigem Drehmoment. Sobald ich auf die PI Regler umschalte, passiert alles Mögliche, nur nicht das Richtige, der Motor ruckt, ändert die Drehrichtung und Geschwindigkeit willkürlich. An den Parametern habe ich schon ein wenig rumgespielt. Code:
1 | m1.PIParmD.InMeas = m1.Id; |
2 | m1.PIParmD.Err = m1.PIParmD.InRef - m1.PIParmD.InMeas; |
3 | m1.PIParmD.Sum += m1.PIParmD.Err; |
4 | m1.Vd = m1.PIParmD.Err * P + m1.PIParmD.Sum * I; |
5 | if(m1.Vd > m1.PIParmD.OutMax) m1.Vd = m1.PIParmD.OutMax; |
6 | if(m1.Vd < m1.PIParmD.OutMin) m1.Vd = m1.PIParmD.OutMin; |
1 | float P = 0.005; |
2 | float I = 0.001; |
Wenn ich den Motor wiederum mit festen V_d = 0.2 und V_q = 0.0 steuere und mir dabei die resultierenden I_d und I_q ansehe, schwingen diese Sinusförmig. Ist das so in Ordnung? Die Clarke und Park sind ja eigentlicht dafür da, diese Variablen "winkelunabhängig" zu machen. Wenn diese sinusförmig sind, kann der PI(D) Regler doch schlecht regeln oder sehe ich das falsch? Frohe Weihnachten! Grüße Andreas
Andreas True schrieb: > Wenn ich der SVPWM feste Werte, z.B V_d = 0.2 und V_q = 0.0 vorgebe, > dreht sich der Motor schön, mit anständigem Drehmoment. Moin, da liegt schon der erste Fehler. V_d soll mit dem Fluss in Phase liegen. Folglich muss bei V_d > 0 und V_q = 0 die Maschine stehen bleiben und nix machen. Die Energie wird dann rein im Wicklungswiderstand um gesetzt. Wenn Id und Iq als sinusförmig gemessen werden. Dann dreht deine Transformation falsche herrum. Also erstmal alles so lassen und einfach das Vorzeichen von theta vor der Transformation drehen. Dann sollte zumindest ein sauberer I_d und I_q gemessen werden. Dann der gegen Test mit V_d = 0 und V_q > 0. Bei deinem jetzigen Einstellungen sollte die Maschine also stehen bleiben. Wenn das so ist bist du mit deinen Achsen (d/q) um 90° falsch. Ich würde dann an deiner stelle folgendes machen. dein Theta = 0 setzen. V_d>0 und V_q = 0 setzen. Warten. Dann die Lage vom Encoder einlesen und als Offset speichern. Dieses Offset ziehst du dann immer so von dem Encoder Winkel ab. dann Spannung wieder aus. und mit I_d = 0 un d I_q >0 anfahren. dann sollte der Antrieb laufen. Frohe Weihnachten Tec
Ich habe mal eine Frage zu den ganzen Transformation. Ich habe bei meiner Realisierung einfach diese Mc Donald Ms im Speicher abgelegt und die PWM Amplitude damit Multipliziert. Der Stromregler sieht nur einen einfachen DC Motor. Die App läuft prima...
Tecnologic schrieb: > da liegt schon der erste Fehler. V_d soll mit dem Fluss in Phase liegen. > Folglich muss bei V_d > 0 und V_q = 0 die Maschine stehen bleiben und > nix machen. Die Energie wird dann rein im Wicklungswiderstand um > gesetzt Ok, das habe ich jetzt in den Griff bekommen, mit V_q = 0, V_d > 0, wird die Energie in der Wicklung verbraten, ohne dass sich der Motor dreht, wenn man ihn währenddessen mit der Hand dreht, hat man das Gefühl, dass der Winkel so anliegt, dass der Motor sich gerade noch nicht drehen kann. Tecnologic schrieb: > Vorzeichen von theta vor der Transformation drehen
1 | void park_transform(void) |
2 | {
|
3 | park_angle = -park_angle; |
4 | |
5 | sin_angle_once = sine_rad(park_angle); |
6 | cos_angle_once = cosine_rad(park_angle); |
7 | |
8 | Id = Ialpha * cos_angle_once + Ibeta * sin_angle_once; |
9 | Iq = Ibeta * cos_angle_once - Ialpha * sin_angle_once; |
10 | }
|
I_d und I_q sind immer noch sinusförmig Wenn ich vor der Rücktransformation das Winkelvorzeichen nicht wieder zurückdrehe blockiert der Motor:
1 | void inverse_park_transform(MOTOR * m) |
2 | {
|
3 | park_angle = -park_angle; |
4 | |
5 | sin_angle_once = sine_rad(park_angle); |
6 | cos_angle_once = cosine_rad(park_angle); |
7 | |
8 | Valpha = Vd * cos_angle_once - Vq * sin_angle_once; |
9 | Vbeta = Vd * sin_angle_once + Vq * cos_angle_once; |
10 | }
|
Tec Nologic schrieb: > Wenn bei Theta = 0 und Vq = 0 und Vd = 1 gilt > Valpha = Vd = Va =1, Vbeta = Vq = 0, Vb und Vc ergeben sich dann. > > Für Theta = 0 liegen alle Koordinatensystem über einander. Vd-Achse auf > Valpha-Achse und auf der Va-Achse. Für Theta pi/2 bzw. 90° muss dann Vd > mit Vbeta gleich sein und Vq = -Valpha. Tec Nologic schrieb: > Für Theta pi/2 bzw. 90° muss dann Vd > mit Vbeta gleich sein und Vq = -Valpha Ich habe die Rücktransformationen jetzt wieder tabellarisch dargestellt, einmal mit V_d=1 und V_q=0 und umgekehrt um diese Tests die du weiter oben empfohlen hast nochmal durchzuführen, aber es sieht eigentlich alles richtig aus, siehe Anhang. (von -2PI bis +2PI rotiert) Hallo Disco, du hast quasi soetwas wie eine Lookup Tabelle, wie man sie für Sinus macht, für diese POPO Kurven gemacht oder? Sieht diene Clarke_Inv so aus:
1 | Vr1 = Valpha; |
2 | Vr2 = (-Valpha + sqrt3*Vbeta) / 2; |
3 | Vr3 = (-Valpha - sqrt3*Vbeta) / 2; |
Ich habe meine aus einer AppNote und sie sieht so aus:
1 | Vr1 =Vbeta; |
2 | Vr2 = ( -Vbeta + sqrt3*Valpha ) / 2; |
3 | Vr3 = ( -Vbeta - sqrt3*Valpha ) / 2; |
Wenn du die erste Version hast, holst du wahrscheinlich schon in der inversen Parktransformation die sin und cos Werte aus deiner Tabelle richtig?
1 | Valpha = Vd * cos_angle_mc - Vq * sin_angle_mc; |
2 | Vbeta = Vd * sin_angle_mc + Vq * cos_angle_mc; |
Grüße Andreas
Ich hole für jede Pahasenlage 3 um 120 grad gedrehte Amplituden aus der Tabelle. Diese ist bis 60 grad 0 und verläuft dann sin förmig bis 120 grad dannach bis 240 grad als Summe zweier Sin Funktionen. Die Werte multipliziere ich mit der Ausgangsspannung. Maximal darf diese 95 Prozent haben, da ich die Motoren als Servo betreibe un die Augangstreiber Bootstrap haben.
Andreas True schrieb: > Wenn ich vor der Rücktransformation das Winkelvorzeichen nicht wieder > zurückdrehe blockiert der Motor: Stop. hast du dabei V_d > 0 und V_q = 0? Noch mal zur Klarstellung: I_d ist in Phase zum Rotorfluss und damit der "flussbildende Strom". I_q ist 90° rechtsrum voreilend gezählt und ist damit der "drehmomentbildende Strom". Folglich darf V_d keine Drehmoment erzeugen. Nur V_q. Und wenn du meinst V_d und V_q konstant zu halten sich aber ein sinusförmiger I_d / I_q ergibt. Dann dreht die Rücktransformation das Koordinatensystem anders herum als die SVPWM. Folglich ist nur das Vorzeichen von Theta für die Rücktransformation zu drehen. Andere Frage kommt die Sinusimplementierung mit Tabelle mit negativen Winkeln klar? Gruß Tec
Ich drehe einfach das Vorzeichen des PWM. Winkel kommen so wie sie sind aus dem Encoder.
Tec Nologic schrieb: > hast du dabei V_d > 0 und V_q = 0 Jup, habe ich. In die inverse_park_transform() gebe ich die konstanten Werte V_d = 0.1 V_q = 0 ein.
1 | void clarke_transform(void) // Ia und Ib sind gemessene Phasenströme |
2 | {
|
3 | m->Ialpha = m->Ia; |
4 | m->Ibeta = (m->Ia + 2.0 * m->Ib) * inv_sqrt3; |
5 | }
|
1 | void park_transform(void) |
2 | {
|
3 | sin_angle_once = sine_rad(park_angle); |
4 | cos_angle_once = cosine_rad(park_angle); |
5 | |
6 | Id = Ialpha * cos_angle_once + Ibeta * sin_angle_once; |
7 | Iq = Ibeta * cos_angle_once - Ialpha * sin_angle_once; |
8 | }
|
1 | void inverse_park_transform(void) |
2 | {
|
3 | if(encoder_ready == 1) park_angle = -park_angle; |
4 | |
5 | sin_angle_once = sine_rad(park_angle); |
6 | cos_angle_once = cosine_rad(park_angle); |
7 | |
8 | Valpha = Vd * cos_angle_once - Vq * sin_angle_once; |
9 | Vbeta = Vd * sin_angle_once + Vq * cos_angle_once; |
10 | }
|
1 | void inverse_clarke_transform(void) |
2 | {
|
3 | Vr1 = Vbeta; |
4 | Vr2 = ( -mVbeta + sqrt3*Valpha ) / 2; |
5 | Vr3 = ( -Vbeta - sqrt3*Valpha ) / 2; |
6 | }
|
Dann noch die svpwm, und es kommen die im letzten Beitrag angehängten POPO Kurven raus. Tec Nologic schrieb: > Andere Frage kommt die Sinusimplementierung mit Tabelle mit negativen > Winkeln klar? Ja, ich habe oben im Screenshot von -2PI bis +2PI transformieren lassen, im negativen Bereich kommen auch richtige Werte raus. Und ich wundere mich wieso der Beobachter nicht funzt... wenn es sogar schon hier bei mir happert :/ Gruß Andreas
Falls es von Bedeutung ist, die umgerechneten Phasenströme Ia und Ib sind bei mir sinusförmig über der x-Achse, sprich sie schwingen zwischen positiv und negativ.
Servus Andreas, ich war zwischenzeitlich mal ein wenig ruhiger, bin aber noch da ;-) Deine Transformationen sehen aus meiner Sicht i.O. aus. D.h. die Vorzeichenumkehr ist denke ich nicht notwendig wenn nicht an anderer Stelle noch ein Dreher ist. Bist Du die gesamte Kette schon mal durchgegangen? (Sorry wenn ich das nochmal fragen sollte :-)) Ich hatte z.B. mal einen Dreher in der Strommessung weil ich nicht berücksichtigt hatte das ich in der Freilaufphase den Strom Messe und diesen damit noch invertieren muss. Zur Anlaufphase vielleicht noch was. Die habe ich etwas anders umgesetzt als Du Tec. Ich mache es so: ID= Anlaufstrom IQ= 0 Theta soll konstant auf 0 Ich gehe hier davon aus, dass ich in der Anlaufphase im wesentlichen einen d-Strom habe. Dann warten bis der Rotor eingerastet ist. Im eingerasteten Zustand kann ich dann auch den d-Stromregler überprüfen indem ich id soll verändere und den Phasenstrom ansehe. Sollte hier was Schwingen passt der Regler nicht. Dann fahre ich den Winkel Theta entsprechend einer Drehzahl Solltampe hoch. Alle Funktionen laufen hier schon. Nur der Drehzahlregler hat noch nichts zu melden und der Transformationswinkel kommt aus der gesteuerten Rampe, d.h. d und q Strom haben noch nix mit der Realität zu tun. Der Observer läuft parallel mit. Bei einer bestimmten Drehzahl schalte ich dann um auf den Drehzahlregler. Dieser wird dann mit dem realen Wert des aktuellen qStroms initialisiert. Der d-Stromregler bekommt den aktuellen realen d- Strom als Sollwert vorgegeben. Später wird dieser dann auf 0 gefahren. (Ld ==Lq). Damit habe ich zum Zeitpunkt der Umschaltung keinen Sprung im Strom und der Motor bekommt zunächst nix mit. Für die Berechnung der realen Ströme nehme ich dann natürlich den Winkel aus dem Observer. In meiner Anlaufphase ist also eigentlich alles aktiv und kann damit auf Funktion geprüft werden. Den Encoder kannst du z.B. auch in der Positionierphase abgleichen um dann damit später in der hochlaufphase den Observer zu prüfen. Viele Grüße und schöne Weihnachten an euch alle, Gonzo der jetzt Kuchen essen geht ;-)
Guten Tag, Gonzo schrieb: > Ich hatte > z.B. mal einen Dreher in der Strommessung weil ich nicht berücksichtigt > hatte das ich in der Freilaufphase den Strom Messe und diesen damit noch > invertieren muss Das habe ich natürlich auch vergessen.. Habe jetzt auf die Schnelle das Vorzeichen von Ia und Ib umgedreht. Jetzt sieht Id und Iq viel "weniger wellenartig" aus, und hat einen gewissen Offset zu der x-Achse, es könnte also die Lösung sein :)
1 | void MeasCompCurr(void) // Rechnet ADC Werte in tatsächliche Stromwerte (in Ampere) um |
2 | {
|
3 | adc1 = ADC_GetConversionValue(ADC1); |
4 | adc2 = ADC_GetConversionValue(ADC2); |
5 | |
6 | m1.Ia = -(adc1 / ADCMaxValue * ADC_Max_Voltage - ADC_Ref_Voltage) / AmpGain / R_Shunt; |
7 | m1.Ib = -(adc2 / ADCMaxValue * ADC_Max_Voltage - ADC_Ref_Voltage) / AmpGain / R_Shunt; |
8 | }
|
Ich glaube meine RefSpannung, also die Spannung die bei 0Ampere Strom geliefert wird (bei mir soll 1.5Volt), bei Phase 1 und Phase 2 etwas unterschiedlich ist. Könnte dadurch Id und Iq auch schwingen, weil ja dann Winkelberechnungen (sin+cos) nicht übereinander liegen? Könnte ich einfach zu meiner Variable 'ADC_Ref_Voltage' einen gewissen Grundoffset solange dazu rechnen rechnen, bis Ia und Ib am Scope den gleichen Mittelwert haben? Ich werde es nachher ausprobieren. Zu der Anlaufphase werde ich auf jeden Fall nochmal zurückkommen! Noch brauche ich sie nicht (Außer um den Encoder zu initialisieren), da ich jetzt erstmal nur mit dem Encoder die SVPWM richtig haben möchte, um mich dann auf den Beobachter zu konzentrieren. Gruß Andreas
Hi Andreas, das mit dem Offset ist auch so eine Sache und kann auch eine Welligkeit mit rein bringen. Ich messe die Spannung deshalb zur Laufzeit und rechne den gemessenen Offset mit in die Stromberechnung ein anstatt einen festen Offset zu verwenden. Eine andere Sache die eine Welligkeit mit rein bringen könnte ist ein gewisser Unterschied zwischen Ld und Lq. Meine Erfahrung ist, dass auch bei SPMSM Motoren die beiden Induktivitäten nicht 100% gleich sind. Zuletzt hat auch noch die Zwischenkreisspannung einen Einfluss. Speist Du deinen Motor aus einer DC Quelle? Gruß Gonzo
Hi, Gonzo schrieb: > Ich messe die Spannung deshalb zur Laufzeit und rechne > den gemessenen Offset mit in die Stromberechnung ein anstatt einen > festen Offset zu verwenden Das hört sich gut, werde mir auch überlegen, wie ich das mache. Nimmst du dafür den Mittelwert von den Sinusspitzen, bzw die Spitzenwerte aus den ADC Messungen? Gonzo schrieb: > Speist > Du deinen Motor aus einer DC Quelle? Dafür muss bei mir leider ein umgebautes PC Netzteil herhalten :( Auch meine Halbbrücken und die Strommessung ist wahrscheinlich nicht gerade super aufgebaut und voller Störungen. Werde vielleicht die Tage eine Platine entwerfen und ätzen lassen. Mein Motor läuft übrigens endlich mit der SVPWM, mit dem Encoder und sogar samt der drei Regler :) Reicht es eurer Erfahrung nach, für d und q nur PI Regler zu verwenden und für Omega PID? So wie es jetzt bei mir ist, scheinen mir meine Regler etwas träge zu sein, und beim wieder entlasten des Motors reagieren sie auch zu langsam und der Motor baut viel zu viel Drehzahl auf und schwingt sich dann ein. Stelle ich die Parameter schärfer, fängt der Motor an, laut zu pfeifen. Aber ich bin erstmal froh, dass das ganze so läuft. Vielleicht kann ich mich bald nochmal an den Beobachter ranwagen. Grüße Andreas
Moin, den Offset Messe ich immer dann wenn kein Strom fließt, d.h. wenn der Motor steht. Ich nehme dann einfach den aktuellen AD Wert und lasse ihn in ein Tiefpassfilter laufen. Den Ausgangswert des Filters rechne ich dann zur Laufzeit des Motors in die Stromberechnung ein, d.h. Imotor=Adc-Offset. Das der Motor jetzt läuft ist doch super! Ich baue meine Regler immer nur mit PI Reglern auf. Meiner Erfahrung nach ist das völlig ausreichend. Bei PID Reglern war ich bisher immer etwas vorsichtig da ich öfters mal Probleme hatte wenn die Signale stark vertauscht waren. Ich muss hierbei aber auch sagen, dass sich meine Erfahrungen auf Lüfter und Pumpen beschränken. Bei Servoantrieben kann das wieder anders aussehen. Hierzu kann ich keine Aussage treffen. Bei mir ist der Aufbau PI für Iq,Id und Omega auf jeden Fall absolut dynamisch genug. Gruß, Gonzo
Hi zusammen, @PID: habe den 'D' Anteil auf 0 gesetzt, so dass die Regler jetzt als PI Regler arbeiten. Noch an den Parametern gespielt, die Dynamik passt jetzt erstmal. Der Motor läuft jetzt komplett eigenständig, ohne Encoder, mit Beobachter und SVPWM :), vielen Dank an Tec und Gonzo für die Zeit, die ihr dafür genommen habt! Aber ab einer gewissen Drehzahl (~4k rpm bei ca 20% des max. Stroms des Motors) gibt es Aussetzter, das ganze schaukelt sich auf und der Motor ruckt nur noch wild. Habt ihr einen Software-LowPass in der Phasenstrommessung? Ich glaube Tec hat es mal kurz erwähnt. Hattet ihr auch das Problem, dass die Steuerung nach einem Messfehler/Spike total durchdreht? Man könnte an die OpAmps noch Kondensatoren hägen, aber dann würde man ja wieder eine Phasenverschiebung reinbringen. Ich habe jetzt das eingebaut:
1 | adc_filtercoef = 0.2; |
2 | |
3 | Ia_filtered = Ia_filtered + adc_filtercoef * Ia - adc_filtercoef * Ia_filtered; // auch so entsteht Phasenverschiebung! |
hilft aber nur bedingt. Die adc-offsets werden jetzt gleich am Anfang rausgemessen, während der Motor noch steht und es kein Strom fließt. Grüße Andreas
Andreas True schrieb: > Aber ab einer gewissen Drehzahl (~4k rpm bei ca 20% des max. Stroms des > Motors) gibt es Aussetzter, das ganze schaukelt sich auf und der Motor > ruckt nur noch wild Frohes Neues, klingt danach das deine Rotorlage Drehzahl anhängig zu weit vor eilt. Ein kleiner TP auf den ADC-Werten der Strommessung könnte dies kompensieren. Mit der Grenzfrequenz musst du experimentieren aber als start weißt du das du bei 4krpm 90° Fehler da ist. Also würde ich den Filter als IIR direkt auf die Drehfrequenz der Ströme bei 4kRPM setzen. Dann haste da zusätzliche 45° Lag und damt nur noch einen Fehler von 45° anstelle von 90°. Damit läufts dann erstmal. Gruß Tec
Hallo Tec, dir auch ein frohes Neues! Das heißt, dass ich nicht drum herum kommen werde, geschwindigkeitsabhängige Offsets einzubauen, damit der Motor bei jeder Drehzahl wirklich sauber läuft oder? Gehe ich bei der Offsetbestimmung richtig vor, wenn ich mir den Phasenstrom am OpAmp Ausgang ansehe und den Offset so einstelle, dass dieser möglichst sinusförmig ist? Was mir aufgefallen ist, wenn ich Vd regeln lasse und Vq fest vorgebe, erreiche ich höhere Drehzahlen und die Steuerung kommt nicht "plötzlich" durcheinander. Wäre es nicht besser, die Ströme erst nach der Park-Transformation, also Id und Iq zu filtern und nicht direkt die Sinussignale der Strommessung, weil ich dann drehzahlunabhängig bin und Phasenverschiebung kein Problem darstellt? Jetzt nicht auf den Winkeloffset, sondern auf meine (vermutlich) Spikeprobleme bezogen. Gruß Andreas
Id und Iq zu filtern ist nicht falsch. Aber ein TP für ia, ib und ic bringt dir ja eine Drehzahl Abhängigkeit der Phase. Das willst du ja. Der Beobachter scheint ja darauf ausgelegt zu sein.
Es ist ein BEMF Beobachter bei dem die berechnete BEMF mit einem LowPass gefiltert wird. So wie ich den Beobachter verstehe, wird der Filterkoeffizient des LPF ständig an das aktuelle Omega angepasst. Quasi so, dass die BEMF immer an der Grenzfrequenz gefiltert wird und somit eigentlich keinen geschwindigkeitsabhängigen Offset bekommt sondern jeweils -45° pro Filter (da Grenzfrequenz) Koeffizient anpassen:
1 | Kslf = Omega_fltred / 20; // weil 20 Interrupt-Durchläufe pro Omega Aktualisierung |
2 | // Omega wird mit 1ms aktualisiert
|
BEMF filtern:
1 | Ealpha_fltred = Ealpha_fltred + Kslf * m1.Ealpha - Kslf * Ealpha_fltred; |
Am Ende der Beobachter Routine wird ein fester Offset von 90° auf den Winkel addiert. Deshalb "darf" ich keine Phasenverschiebung auf Ia, Ib und Ic legen. Oder habe ich den Beobachter falsch verstanden? Habt ihr, Tec und Gonzo, einen BEMF oder einen PLL Beobachter? Ich hätte noch eine Frage zum Filtercoeffizienten von Omega: Dieser wird in der AN10899 so berechnet:
1 | FiltOmCoef = (OMEGA0 / IRP_PERCALC / 10 ); |
2 | // IRP_PERCALC ist hier wieder gleich 20, siehe oben
|
3 | //OMEGA0 ist die niedrigste Geschwindigkeit, bei der mit Beobachter gefahren wird
|
Warum wird es hier zusätzlich durch 10 geteilt? Das kann ich absolut nicht nachvollziehen. Bis jetzt habe ich diese Division weggelassen. So läuft der Beobachter gut, aber nur bis zu einer bestimmten Drehzahl, weil ich vielleicht eben trotz des adaptiven Beobachters einen Winkeloffset bekomme, wie Tec schon gesagt hat. Mit der Division schwingt sich das ganze auf bis der Observer komplett durcheinander kommt und nichts mehr geht. Edit: Tec, wie geht es mit deinem Beobachter für niedrige Drehzahlen/aus dem Stand voran? Freue mich schon, davon zu lesen :) Gruß Andreas
Moin, zu der Implementierung von AN1089 kann ich nix sagen. Wir hatte das aber schon mal meine Gonzo hatte geschrieben dass das 2 TP mit der Grenzfrequenz auf w sind. also immer 90°. Aber anscheinend überkompensiert der Beobachter. Entweder weil dein w nicht simmt auf das die Filter gesetzt werden oder weil der SMO durch den K Faktor zu aggressiv ist. Ne TP direkt auf dem Strommesswert ist in deinem Fall aber nicht verkehrt. Auch in der dsPIC Hardware muss in RC-Filter drin sein vor dem ADC. Bei den niedrigen sample raten muss der auch auf ca.10kHz oder noch weniger liegen. Und der fehlt dir würde ich tippen oder dein Hardware TP liegt deutlicher höher mit der Grenzfrequenz. @edit: PLL, Fluss, BEMF nervt etwas. N Flussbeobachter der über ne PLL w bestimmt war für mich immer das robusteste. Du bist aber genau so Parameterabhängig wie mit nem modellbasierten Beobachter. Und zur Zeit schwöre ich da auf n UKF. Der Braucht zwar wesendlich mehr Rechenleistung aber auf nem STM32F4 ist das kein Ding. Mit aus Matlab generiertem Code in C++ und mit float kann ich die Stromregelung mit Filter mit 16kHz laufen lassen. Mit etwas zusätzlicher Beobachterrei komme ich dann vllt. auf 8kHz Beobachter 16kHz Stromregler und 8 bzw. 16kHz PWM jenach Maschine. Das einzige Problem bei mir ist zur Zeit die Bestückung von DRV8302 mit dem Fön und die starke Abhängigkeit des Beobachters von der Flusskonstanten der Maschine also quasie dem ominösen KV Wert der bei Modellbaumotoren immer so angegeben wird. Gruß Tec
Jup, da liegst du richtig, externe LPF vor den ADCs habe ich (noch) nicht, werde aber auf meiner geätzten Platine, die ich irgendwann mal machen werde, dafür auf jeden Fall Platz lassen. 10kHz Filter wird ja noch keine starke Phasenverschiebung verursachen. Tec Nologic schrieb: > SMO durch > den K Faktor zu aggressiv Mit dem K Faktor meinst du den SMO Gain, nicht Kslf aus den BEMF Filtern oder? Der DRV8302 scheint ja ein sportliches Teil zu sein. Braucht der externe Beschaltung für die Bootstrap Schaltung (Kondensator, Diode)? Mit den integrierten OPVs hat man wohl viel weniger Rauschen oder? Ich verwende zurzeit 3x IR2104 als FET Treiber, diese generieren zumindest eigenständig die Totzeit um die Halbbrücke nicht zu grillen, und man kann allg. bei denen nicht HI und LO gleichzeitig durchschalten. Soweit ich mich erinnere sind die auch intern getaktet, damit der C aus der Bootstrap nicht leergesaugt wird. Der UKF scheint ja doch jede Menge Leistung zu brauchen. Mit dem STM32F4 brauche ich zurzeit mit dem Beobachter, absolut alles in Float, ohne jegliche Optimierung, der gesamte Code total durcheinander ca 60-70% der Leistung bei 20kHz (alle Programmteile). Bis ich allerdings zu dem UKF kommen und verarbeiten werde, werden wohl noch Jahre vergehen :D EDIT: Aus dem KV Wert sollten sich doch die Konstanten (R und L), die ich für dem SMO brauche, auch ableiten lassen. Oder muss ich dafür den Spulendurchmesser, etc wissen.. Gruß Andreas
Moin, ich habe noch eine Verständnisfrage zur Phasenstrommessung. Ich rechne meine 12Bit ADC Werte in tatsächliche Phasenstöme um, sprich ich erhalte zwei 120Grad verschobene Sinus, die zB von -1.5A bis +1.5A gehen. Diese Werte gehen in Ia und Ib. Sie gehen in die Clarke Transformation:
1 | void clarke_transform() |
2 | {
|
3 | Ialpha = Ia; |
4 | Ibeta = (Ia + 2.0 * Ib) * inv_sqrt3; |
5 | }
|
Da ich ja den Strom in der Freilaufphase messe, muss dieser zuvor invertiert werden. Bisher habe einfach das Vorzeichen von Ia und Ib umgedreht. Ist das so richtig? Der Motor hat ja drei Anschlüsse, so wird sich die induzierte Spannung ja über diese drei verteilt. Darf man da wirklich einfach das Vorzeichen umdrehen? Ich hatte ja vor ein paar Tagen das Problem, dass Id und Iq bei mir sinusförmig ist, dann habe ich einfach die Vorzeichen getauscht. Gruß
Du musst ja beide Ströme Invertieren und das sollte transformationsinvariant sein. Also alles ok. Einfacher gesagt setz mal -Ia und -Ib für Ia und Ib ein. Dann kommt ganz normal -Ialpha und -Ibeta raus. Also alles ok.
Alles klar, wenigstens eine Sache richtig gemacht :D Ich habe mich nur gefragt, weil wenn Iq so regeln lasse, dass ich meine unüberwindbaren 4kRpm fast erreiche, speziel bei mir
1 | I_q_soll = 1.3; |
2 | I_d_soll = 0.0; |
und mir dabei I_d_IST, I_q_IST am Oszi leicht vergrößert ansehe, sind diese immer noch Sinusförmig, und das nicht zu knapp. Iq schwankt zwischen ca 0.5 und 1.2. I_q_soll ist wie gesagt const. Ich frage mich gerade, wie das ganze so stark schwankend überhaupt laufen kann. Können die Abweichungen zwischen den zwei ADCs und der 2 Kanäle des doppel OPVs so stark sein, dass durch diesen Unterschied eine Art Schwebung zwischen ADC1 und ADC2 und somit auf Iq und Id entsteht? Oder der Stromverlauf des Motors strahlt so stark in die restliche Schaltung... Eine (noch) nicht ganz so wichtige Frage: Als uC verwende ich das Evalboard von ST mit STM32F4 drauf. Die Treiber-, Leistungs- und OPV-Schaltung ist auf einem Lochrasterplatine aufgebaut. Ich möchte erstmal eine Leistungsplatine ohne des uC machen. Sprich, das was ich jetzt auf Lochraster habe, ätzen lassen und den Controller erstmal extern lassen. Ich habe mich bei den STM32s für diese Anwendung noch nicht festgelegt. Ist das Okay, oder sollte der uC unbedingt auf der selben Platine sitzen, was ja natürlich weniger Masseprobleme, Spikes und andere Schweinereien reinbringt. Grüße Andreas
Das schwingen klingt nach Regler. Mach mal reine P Regler zum probieren. Was das Board angeht. Sieh dir das BOOST-BLDC oder so Board von Ti an mit dem DRV8301. Ist günstig und gut. Wen du es doch selber machen willst kannste die Discoverys mit Buchsenleiste direkt aufs Board klemmen sollte auch nicht schlechter laufen als jetzt. Klar das das nicht hoch genau wird von der Strommessung aber du fährst ja kleiner 5A da ist das nicht so wild. Ich sag mal so ab 20A Auslegung würde ich ein Board machen. Ich hab aber auch bei 100A noch getrennte Boards. Jedoch ist die 2. nur ein "Halter" für die Fets. Gruß Tec
Hallo zusammen, wegen der Klausurphase im Studium arbeite ich zurzeit an der Motorsteuerung nicht weiter. Ab und zu google ich trotzdem nach verschiedenen FOC Themen. Habt ihr (zB Gonzo und Tec :D ) schon mal InstaSPIN von TI angeschaut? Dort wird es versprochen, aus einer Drehzahl von 0 heraus mit vollem Drehmoment anfahren zu können. Nach weniger als einer elektrischen Umdrehung soll der Motor schon vollständig geregelt laufen. Man braucht keine besonderen Motordaten wie Induktivität oder Kv Angaben. Nur max. Spannung und Stromstärke. Rs misst er anscheinend ständig während der Laufzeit. Und anscheinend soll der Beobachter auch auf Rotorfluss basieren: FAST™-Software-Encoder - Regelung/Kalkulation des Rotorflusses Sind diese Angaben von TI doch sehr optimistisch oder arbeiten sie hier nicht mit dem üblichen BEMF Observer sondern mit so etwas wie INFORM (Indirect Flux detection by Online Reactance Measurement)? Benötigt man für INFORM und für Rs Messung während der Laufzeit zusätzliche Hardware zu meinen 3 Halbbrücken und Strommessung an zwei Motorphasen? Gruß Andreas
Moin, InstaSpin finde ich auch recht interessant ist aber nicht viel drüber zu finden als Videos mit wie toll und einfach es geht. Ich gehe davon aus das der Beobachter die Gleichungen im dq-System umsetzt und dann wurde mit Lyapunov die Stabilität untersucht und die Gleichungen darauf hin nicht linear ergänzt. Ich hab da mal n paper von einem Schweden gesehen. Vllt schätzen sie dann noch Rs und Ls über einen RLS-Schätzer, ist aber alles nur vermutet anhand des Verhaltens und was TI so bekannt gibt. INFORM werden die nicht machen. 1. Weil du das dann nicht auf nem 28xxx DSP laufen lassen könntest ohne in böse Laufzeit-Probleme zu bekommen. bzw. du musst dir ganz schön den Kopf zerbrechen. 2. INFORM braucht recht gute Kenntnisse von Ld und Lq bzw. muss diese online ermessen. Das ist eher was wenn man n Industrie-Servo mit sauberem Datenblatt in Positionsregelung ohne Geber betreiben will. Für INFORM generell brauchst du nichts weiter mehr außer die Rechenleistung und System mit ca. 1kHz drehen zulassen und das mit kleiner Amplitude auf den Antrieb zu geben quasi als Summe zu deiner normalen SVPWM. Dann kannst du dir die Impedanz bestimmen und aufgrund dieser Aussagen zu der Rotorlage machen. Du hast aber immer noch die Sigularität bei 180°. Also wenn du dir die Induktivität als Ellipse vorstellst weißt du ja nicht an welchem ende bist wenn du den Radius kennst. Es gibt genau 2 gegenüberliegende Punkte die passen. Was mich aber speziell interessieren würde wie FAST reagiert wenn du da n Innenläufer anschließt und dann danach n großen 60iger Außenläufer. Wie kommen die da klar mit ihrer Parameterschätzerei. Der Parameterschätzer ist nicht eingeschwungen und liefert dem Lagebeobachter falsche Werte der schätzt falsch und damit passt das Modell des Parameterschätzers nicht mehr. Das ist im Stillstand etwas problematisch. Da kommen die wohl nur raus in dem sie Strom fix einregeln den Winkel vorsteuern und dann halt in unter einer Umdrehung ne zuverlässige Lage haben. So interpretiere ich die Marketing Infos die TI bisher raus gegeben hat. Aber wie gesagt das ist nur meine Einschätzung des Ganzen. TI ist auf jeden Fall am weitesten bei dem Thema. Gruß Tec
Hallo, es wäre schon interessant, von denen so ein InstaSPIN Board zum experimentieren zu haben. Ganz günstig sind sie aber nicht für privat. Aber ob diese automatische Parameteranpassung am Ende genau so gut funktioniert (zB Wirkungsgrad) wie wenn man den Beobachter händisch per Oszi einstellen würde? Falls es euch interessiert, hier der Link zur Entwicklung meines Motorcontrol-Boards. Vielleicht habt ihr auch ein paar Tipps für mich. Habe dort bischer leider noch nicht viel Feedback bekommen. Beitrag "Schaltung für Motorsteuerung" Gruß Andreas
Hallo Andreas, INSTASpin und INFORM kenne ich ehrlich gesagt auch nur aus dem Internet bzw. aus Vortragsunterlagen von Professor Schroedl. Ich hatte zwar mal einen Vertriebler von TI im Haus aber die Infos waren nur sehr spärlich. Theoretisch könnte ich mir das ganze wie Tec schon geschrieben hat vorstellen, muss jedoch auch sagen das ich mich noch nicht wirklich damit befasst und dadurch noch einige Verständnislücken habe. Die Umsetzung der INFORM Methode ist denke ich auch sehr aufwendig. Ich bin mir auch nicht sicher ob es hier schon richtige Umsetzungen in Serie gibt. So wie ich meine Kollegen verstanden habe die die Schulung besucht haben, wird hier auch noch aktiv gearbeitet. Das ist denke ich auch der Grund warum es hierüber noch recht wenig zu finden gibt. @Tec: Bitte korrigier' mich wenn das Quatsch ist ;-) Sorry, aber leider kann ich nicht mehr dazu schreiben. @Andreas: Werde versuchen mir deinen Schaltplan mal anzusehen. Bin im Moment auch recht stark beruflich eingebunden. Deshalb dauert es immer etwas :-)... Gruß, Gonzo
Hallo Gonzo, sehe ich auch so. Ich habe INFORM oder ähnliche HF-Injection Verfahren auch bisher nur auf dem Papier/im Labor gesehen. Wobei ich mir die TI Docs nach meinem Post noch mal angesehen habe. Anscheinend messen die vor Motorstart die Parameter. Da steht was von typisch 2min Messdauer. Gehe davon aus das die dann einfach ne Impedanzmessung machen. Wegen der Schaltung werde ich auch mal rein sehen. Gruß Tec
Angehängte Dateien:
Hallo, ich würde hier auch nochmal kurz eine zwischen Frage stellen. Ich versuche mich aktuell auf an einer BLDC-Ansteuerung über FOC. Im Moment versuche ich die Single-Shunt-Strommessung in Betrieb zu nehmen. Wenn ich den Motor durch drei Lastwiderstände in Sternschaltung ersetzte kommen auch schon ganz passable Ströme raus. Messe ich jedoch mit dem Motor als Last, dann sehen die Ströme nicht wirklich toll aus. Kann dies davon kommen, dass ich den Motor ja nur mit erzwungenem Winkel fahre, oder liegt hier ein Fehler vor? Zur Strommessung verwende ich einen ACS709 Hall-Effekt-Stromsensor. Vielen Dank schon mal für eure Mühen und die vielen tollen Info hier in dem Thread. Viele Grüße und Schönen Abend Michael
Moin, Wenn du den Motor gesteuert fährst dann lockt er aber das sollte bei gesteuertem Winkel deinen Strom nicht so stark beeinflussen. Ist dein Stromregler in Ordnung? Bzw. bist du mal mit fixer Spannung Ud/Uq gefahren? Ich bin gerade kannst du mal eine PWM Periode mit dem Scope aufzeichnen wo man die Messintervalle sieht? Also PWM auf 51% 50% 49% jeweils einer Phase und die Strommessung, damit man sieht ob da nicht Überschwinger auf dem Signal sind. Von wie viel Strom reden wir bei deinen Bildern? Gruß Tec
Hallo, ich verwende bisher nur den SVPWM Teil und geben Teta fest vor. Dann kommen hinten die drei bekannten Spannungsverläufe raus. Diese passen auch zu den Bilder. Der Strom nur eben nicht. Ich habe leider nur ein zwei Kanal Oszi, aber die Messung kann ich heute Mittag gerne machen. Ich triggere die Messung 2µs vor der nächsten Flanke eines PWM-Kanals. Die ADC-Messung dauert knapp über 1µs. Viele Grüße Michael
Wie viel Duty fährst du? Mich stört an der 1 Shuntmessung immer das du immer darauf angewiesen bist das alle 3 PWM Dutys weit genug aus einander liegen. Bei dir müsste ja mindestens ein Unterschied von 1µs sein, damit du alle Ströme messen kannst. Willst du Sensorlos fahren später?
Hi Michael, wenn Du Single-Shunt-Lösung schreibst meinst Du die Messung im Zwischenkreis, oder? Wenn ja ist der Abtastzeitpunkt sehr wichtig da Du hier nicht immer den Strom "siehst". Zudem gibt es hier auch immer Zeitfenster in denen ein Strom nicht messbar ist. Hier gibt es dann noch Verfahren die das wieder kompensieren. Was mir zur Stromverzerrung noch einfällt ist die EMK des Motors. Ist deine EMK sinusförmig? Wenn nicht könnte das auch eine Ursache sein. Wenn Du als Ersatzlast nur Widerstände verwendest könnte Dir die fehlende Induktivität ggf. Probleme machen. Ich verwende hier immer Statorpakete ohne Rotor als Ersatzlast um hier bei der ersten Abstimmung möglichst nah an der Realität zu sein. Ansonsten würde ich wie Tec schon geschrieben hat auch mal den Stromregler etc. anschauen. Gruß, Gonzo
Angehängte Dateien:
-
BEMF_Messung_2_Phasen.png
3,4 KB
Guten Abend Tec Nologic schrieb: > Wie viel Duty fährst du? Das Duty ist ja vom Winkel der SVPWM abhängig. Ich gehe mit Iq=max und Id=0 in die Brechung der SVPWM. Tec Nologic schrieb: > Mich stört an der 1 Shuntmessung immer das du > immer darauf angewiesen bist das alle 3 PWM Dutys weit genug aus > einander liegen. Ich verwende ein zentriertes PWM. Liegen zwei Tastverhältnisse zu nahe beieinander, dann verschiebe ich eins oder evtl. auch bei so, dass das Messfenster groß genug wird. Dadurch wird das PWM unsymmetrisch. Dieses Prinzip wird in einigen App-Notes von Herstellern beschrieben, deshalb denke ich, dass dieses Verfahren schon funktionieren müsste. Gonzo schrieb: > Ist deine EMK sinusförmig? Im Anhang eine Messung dazu. Sollte passen oder? Gonzo schrieb: > Wenn Du als Ersatzlast nur Widerstände verwendest könnte Dir die > fehlende Induktivität ggf. Probleme machen. Ich verwende hier immer > Statorpakete ohne Rotor als Ersatzlast um hier bei der ersten Abstimmung > möglichst nah an der Realität zu sein. Das kann ich natürlich noch versuchen. Danke für den Tipp! Vielen Dank und viele Grüße Michael
Michael Mayer schrieb: > Ich verwende ein zentriertes PWM. Liegen zwei Tastverhältnisse zu nahe > beieinander, dann verschiebe ich eins oder evtl. auch bei so, dass das > Messfenster groß genug wird. Dadurch wird das PWM unsymmetrisch. Dieses > Prinzip wird in einigen App-Notes von Herstellern beschrieben, deshalb > denke ich, dass dieses Verfahren schon funktionieren müsste. Das ist natürlich eine Möglichkeit. Die BEMF ist ja sehr schön. Was ist das für ein Motor? Mich würde die Strommessung mit dem Stator auch interessieren ich vermute wie Gonzo das dir der Stromfluss mit Widerständen zusammen bricht mangels Induktivität. Gruß Tec
Hallo, ist ein recht kleiner Motor: http://www.amazon.de/gp/product/B00HA0T2OI?psc=1&redirect=true&ref_=oh_aui_detailpage_o01_s00 Den Motor hab ich einfach mal zum Testen bestellt, weil er günstig war. Für die Messung ohne Rotor brauche ich erst noch einen Motor. Nur den Rotor zu fixieren bringt ja vermutlich nichts, oder? Viele Grüße Michael
Moin, Rotor fixieren bringts schon. Die BEMF entsteht ja durch die Rotation des Rotors. Die Effekte durch das Magnetfeld des Rotors sind für die Messung zu vernachlässigen. Gruß Tec
Moin, ich bin mir nicht sicher wie es bei solchen Motoren mit dem Thema Demagnetisierung steht? Die Motoren die ich ansteuere können schon mal beschädigt werden wenn ich einen falschen Strom auf die Wicklungen gebe. Du könntest alternativ auch was mit diskreten Induktivitäten und Widerständen basteln. Gruß
Ich habe unter anderem hier fast den gleichen Motor liegen. Normalerweise kannst die Klammer hinten, an der dünnen Achse abmachen bzw. die Madenschraube lösen und die "Glocke" mit etwas Kraft abziehen. Die Achsen sind ja bei den meisten auch austauschbar. Geht in 2 Minuten. Gibt auch Videos bei YT dazu. Dann musst du nichts fixieren und kannst auch nichts entmagnetisieren. Gruß Andreas
Angehängte Dateien:
-
29.01.png
94 KB
Hallo, Andreas True schrieb: > Normalerweise kannst die Klammer hinten, an der dünnen Achse abmachen ja stimmt. Ging ganz einfach. Aber die Messung die ich dann nur mit dem Stator gemacht habe, hat mich etwas Überrascht. Sieht ziemlich komisch aus. Vermutlich stimmt meine Software doch nicht. Viele Grüße Michael
Das sieht in der Tat so aus als wenn da was nicht passt. Was mich wundert ist warum Passt das bei den Widerständen als Last, bei denen würde ich eher vermuten das dass nicht passt, wegen fehlender Induktivität. Prüfe das ganze doch mal Phasenweise. Die Messung der Anderen Phasen ignorieren und erstmal prüfen misst du die erste Phase an allen Stellen an denen du sie messen willst. Und prüfe mal die Versorgungsspannung des Sensors, wenn die PWM läuft und Strom fährt. Diese Hallsensoren sind da sehr empfindlich.
Angehängte Dateien:
-
MAP01.png
3 KB
Guten Abend, Tec Nologic schrieb: > Und prüfe mal die Versorgungsspannung des Sensors, wenn die PWM läuft > und Strom fährt. Habe ich nun gemacht. Und diese sieht wirklich nicht besonders gut aus. Ich weiß allerdings nicht ob es von meinem Oszi kommt, oder ob das Signal echt so schlecht ist. Habe extra den LT1461 verwendet, weil ich dachte damit bekomme ich die Spannung recht sauber. Muss ich wohl nochmal nacharbeiten. Danke euch! Schönen Abend noch. Grüß Michael
LT1461 ist doch eine Spannungs referenz der kann den Sensor doch gar nicht treiben. Nimm mal einen lowdrop Liniear regler wie TC2117.
Guten Morgen, 50mA Outputcurrent sollten eigentlich völlig ausreichend sein oder? Dachte ich zumindest. Viele Grüße Michael
ok, dann hat die recht viel Power für ne Referenz. Was hattest du da für einen Ripple gemessen, das waren ja wenige 10mV. Das ist eigendlich OK. Es passiert aber gern das beim schalten der PWM die Spannungen absacken. und dass mögen die Hallsensoren garnicht.
Michael, hast du eigentlich mal deine SVM mit zB d=1 und q=0 über 360° in Mathlab, excel o.ä. durchsimuliert? Ich hatte diese Transformation zuerst aus der AN1078, aus dem C Kommentar neben dem Assembler Code rauskopiert. Und leider waren dort ein paar Fehler drin, sprich ich habe keine sauberen POPO Kurven rausbekommen, siehe meine Screenshots weiter oben. Der Motor hat sich trotzdem gedreht. Gruß Andreas
Angehängte Dateien:
-
bild.png
3,7 KB
Hallo, ich habe im Anhang mal ein Oszibild von zwei Ausgangs-Phasen des Reglers. Die Popo-Kurven sehen meiner Meinung nach gut aus. Viele Grüße Michael
Angehängte Dateien:
-
05.02.png
94 KB
Guten Abend, ich habe nun nochmals alle kontrolliert. Auch die Triggerung des ADCs habe ich nochmals mit dem Oszi kontrolliert. (Geht mit einem 2-Kanal nicht so ganz optimal). Mir sind aber keine Fehler dabei aufgefallen. Ich habe noch minimale Verbesserungen am Code vorgenommen. Aber zufrieden bin ich immer noch nicht. Eine Phase sieht recht gut aus, die anderen beiden aber eher nicht. Von euch noch jemand eine Idee? Viele Grüße Michael
Die Blaue Phase sieht gut aus. Der Rest passt irgendwie nicht. Kannst du mal die Spannung über dem Shunt mit dem Scope aufzeichen? Wieviel Strom fährst du im mittel und wie groß ist der Shunt? Das muss doch hinzubekommen sein.!!!
Hallo, Tec Nologic schrieb: > Kannst du mal die Spannung über dem Shunt mit dem Scope aufzeichen? ich verwende ja statt eines Shunt einen Hall-Effekt-Sensor. Dieser sollte ja aber eigentlich genau so funktionieren. Aber ich kann man die Spannung über dem ACS709 messen. Dieser hat einen Innenwiderstand von 1,1mOhm. Viele Grüße Michael
Ach ja. ne dann mach mal bitte die Messung am Ausgang des ACS. Wie viel Strom fährst du da durch?, Und könntest du in der Messung auf dem 2. Kanal immer eine der drei Phasen PWM mit messen damit man sehen kann wann für die Phase gesampled wird? Ist es vllt möglich PWM zufahren und durch den ACS von einem 2. LabNt einen strom durch zu fahren. So habe ich bei meinen ACS758 den Fehler gefunden mit der Versorgungsspannung. Also ACS zwar von der Schaltung versorgt aber der Strom durch den ACS wird von einem externen NT eingeregelt. Das du theoretisch einen DC Strom messen müsstest. auf allen 3 Phasen. Um zu prüfen ob alle Messungen plausibel sind.
Tec Nologic schrieb: > Wie viel Strom fährst du da durch? Kann ich nicht genau sagen. Meinem Multimeter vertraue ich bei der Kurvenform nicht wirklich. Tec Nologic schrieb: > Und könntest du in der Messung auf dem 2. > Kanal immer eine der drei Phasen PWM mit messen damit man sehen kann > wann für die Phase gesampled wird? Kann ich machen. Aber der Ausgang des ACS709 ist auf dem Oszi ziemlich unsauber. Tec Nologic schrieb: > Ist es vllt möglich PWM zufahren und durch den ACS von einem 2. LabNt > einen strom durch zu fahren. So habe ich bei meinen ACS758 den Fehler > gefunden mit der Versorgungsspannung. Ja ist möglich. Ich versorge gerade Leistung und Steuerung aus unterschiedlichen Quellen. Masse habe ich natürlich verbunden. Fahre ich mit einem Gleichstrom durch den ACS, dann bekomme ich jedoch keinen Gleichstrom bei der Messung. Die Messwerte werden ja abhängig vom Winkel ausgewertet. Oder wie meinst du das genau? Vielen Dank für deine Hilfe! Michael
Guten Abend, wenn du mit einem gesteuerten Winkel fährst und einfach mit dem Scope am Ausgang deines Stromsensors misst, müsste man doch auch einen Sinus erkennen. (ist vllt nicht sofort zu erkennen, da mit PWM überlagert) Vielleicht einen kleinen Lowpass vor Scope schalten. Hat dein Controller einen DAC Ausgang? Beziehungsweise, hast du mal geschaut ob dein uC saubere Stromwerte von dem Stromsensor bekommt. Ich meine, ohne dieser "ein Shunt Messung". Falls noch nicht: ADC ganz normal in der PWM Mitte triggern, ohne Messpunktverschiebung. Ich habe es bei mir so kontrolliert, dass ich gleich in der EOC Routine des ADC den ausgelesenen ADC Wert sofort auf den DAC gelegt habe. Den DAC Ausgang habe ich dann per Scope mit meinem OPV Ausgang verglichen. So konnte ich zumindest sicherstellen, dass die richtigen Stromwerte im uC ankommen. Ich denke es ist nicht so einfach gleich eine FOC mit Singleshunt Messung zu implementieren. Du hast quasi 4 Themengebiete auf einmal: SVPWM, Beobachter, Regler, Singleshunt. Meine Steuerung läuft auch noch nicht anständig :D Gruß Andreas
Michael Mayer schrieb: > Fahre ich > mit einem Gleichstrom durch den ACS, dann bekomme ich jedoch keinen > Gleichstrom bei der Messung. Die Messwerte werden ja abhängig vom Winkel > ausgewertet. Oder wie meinst du das genau? Naja Aber Sektorweise müssten die Ströme doch gleich sein. Es darf sich auf jeden Fall kein Sinus ergeben sonder eher eine art Pulsmuster. und dass müsste symetrisch sein wenn die Messung ok ist.
Angehängte Dateien:
Hallo, Tec Nologic schrieb: > Naja Aber Sektorweise müssten die Ströme doch gleich sein. Es darf sich > auf jeden Fall kein Sinus ergeben sonder eher eine art Pulsmuster. Ach jetzt verstehe ich. Im Anhang die Ergebnisse der Messung. Diese ergab eine Art Pulsmuster, das auch nahezu symmetrisch ist. Also scheint dieser Teil soweit zu funktionieren. Viele Grüße und nochmals Dank für eure Bemühungen! Michael
Jop das sieht so aus wie ich vermutet habe. Spricht dafür das deine Messung Hardware Maßig geht. Lief die PWM auch?
Ja die PWMs liefen auch. Nur habe ich die Mosfets "überbrückt". Viele Grüße Micharl
Hast du einen dicken Widerstand? denn du als Shunt testweise nehmen kannst? Nur um mal zu Prüfen ob vllt die Bandbreite des ACS dafür zu gering ist.
Hallo, ich habe die Messung auch mit einem Leistungswiderstand mit 0,15 Ohm gemacht. Die Ergebnisse sehen ähnlich aus. Wenn ich drei Lastwiderstände als Motor anschließe, kommt auch bei Ansteuerung über die PWM das Pulsmuster raus. Allerdings kein Sinus. Auch wenn ich den Stator anschließe kommt kein annähender Sinus zu standen. Ich würde den Fehler in der Software vermuten. Was meint ihr? Viele Grüße Michael
Du fährst rein die SVPWM oder Stromregler? Vllt ist es sinnig mal einen robusten PI Regler anzusetzen vllt ist deine Last ja nicht wirklich symetrisch.
Guten Morgen, ich betreibe rein die SVPWM ohne Stromregelung. Wie meinst du das mit dem PI-Regler? Als Regler für Iq? Viele Grüße Michael
Id und Iq regeln. Und das schön robust. Also wenig Verstärkung mit wenig Überschwingen in der Sprungantwort.
Angehängte Dateien:
-
13.02.png
60 KB
Hallo, einen Stromregler habe ich noch nicht eingebaut. Habe erst nochmals anstelle des ACS mit einem Shunt-Widerstand und einem Differenzverstärker getestet. Aber das Ergebnis ist nicht viel Besser. Ich werde es dann mal mit einem Regler, wie von Tec Nologic vorgeschlagen versuchen. Viele Grüße Michael
Bin gespannt. Wäre schön das laufen zusehen dann könnte man wirklich die teuren ACS oder LEM Stromwandler einsetzen bei hohen Strömen.
Hallo, ich hätte wieder ein paar Fragen zu den PID Reglern für die FOC. Verstehe ich es richtig, dass ein solcher Regler sich aufgrund des I Anteils "aufhängen" kann, so dass er nur noch den Max Wert liefert? Grundsätzlich läuft die Motorsteurung, auch der Drehzahlregler. Allerdings schaffe ich gerademal die Hälfte der angegebenen MaxDrehzahl. Und dafür muss ich die Reglerparameter schon extrem scharf stellen, so dass die Maschine bei langsamen Drehzahlen stark surrt. Die Parameter habe ich über STMStudio durch ausprobieren ermittelt, angefangen bei den Werten aus AN1078. Müsst ihr die Parameter auch immer so extrem individuell anpassen, weil der Motor sonst nichtmal die Hälfte der Drehzahl schafft? Habt ihr vllt einen Tipp für mich, wie ich die Parameter für d, q, w am besten finde? Ich verwende einen kleinen Modellbaumotor von robbe mit 10A. Noch etwas: Definiert sich die maximale Stromaufnahme eines BLDC nur über das maximale Drehmoment oder hängt es auch von der vorliegenden Drehzahl ab? Konkret: Sollwert für w Regler auf 1000rpm, ich belaste den Motor -> w Regler regelt q nach -> bei 2.5A bricht die Steuerung zusammen. Sollwert für w Regler auf 2000rpm -> die Steuerung bricht erst bei 3.2A zusammen. Ist dieses Verhalten normal oder muss der Motor auch bei niedriger Drehzahl (1/10 der Maxdrehzahl) 10A aufnehmen können? Gruß Andreas
Du hast die Koppeltherme vergessen:) Die Spannungsgleichungen für Ud und Uq sind gekoppelt. Sieh dir das bitte man in der Thesis von James Mevey an, da ist alles drin was du brauchst. Grob musst du auf den Ausgang des d regelers -w Lq Iq rechnen. Und auf den Ausgang des q Reglers w Ld Id + w Psi_M. Psi_M ist der Rotorfluss in Vs/rad den kannst du aus dem KV berechnen. Musst nur die Einheiten umrechnen. w ist auch immer in rad angegeben sonst passt das nicht. Oder du siehst dir den Modified Synchronous Regulator von Shane Colton an. Da regelt der d-Regler den Strom durch Änderung der Phase des Spannungsvektors. Was dein Problem angeht: Du musst immer daran denken für den Strom musst du nur den Innenwiderstand der Wicklung von ca. 20mOhm bedenken. -> 10A = 200mV. Die die notwendige Spannung wird also fast nur durch die BEMF bestimmt. Und das ist eben w*Psi_M. Das erklärt auch warum dein Drehzahlregler so viel muken macht weil der Stromregeler total nicht linear arbeitet. Gruß Tec
Klingt einleuchtend, obwohl ich es noch nicht ganz verstanden habe. Werde mir die Thesis auf jeden Fall ansehen. Ich habe mal Probeweise den Op Gain in der Software testweise 10x so hoch gesetzt wie er eig. in der Schaltung ist. Interssanterweise lässt sich die Maschine jetzt viel besser kontrollieren. Schaffe nun bis zu 5.5A und ca 2/3 der max Rpm. Ist es richtig dass ich damit die von dir angesprochene Nicht - Linearität auf diese weise hinausgeschoben habe? Gruß Andreas
In gewisserweise. Der Regler ist jetzt so hart eingestellt das er auch die BEMF kompensieren kann.
Moin, habe mir das ein wenig angeschaut und ins Programm eingebaut. Wenn auf meinem BLDC "1100kv" steht bedeutet es ja 1100Umdrehungen pro Minute bei 1Volt Spannung. Für eine Umdrehung des Rotors benötige ich 7 elektrische Rotationen. Also haben die Spulen eigentlich 7 * 1100 = 7700kv. Wenn ich das jetzt in Psi_M [Vs/rad], also Ke umrechne: 7700kv / 60s = 128.33 Psi_M = 1 / 128.33 * 2Pi = 0.00124 [Vs/rad] Sehe ich das richtig oder sind diese kv Angaben auf den Motoren bereits auf einzelne Spulen bezogen? Ist es richtig, dass ich Ld und Lq, bzw Ls bei James Mevey erstmal schätzen muss? In welchem Bereich sollte ich deiner Meinung nach anfangen? Gruß Andreas
1mVs/rad klingt gut. Von der Größenordnung her. habs jetzt nicht angerechnet. Ls würde ich mit ca. 10µH erstmal annehmen. Bei dem kleinen Motor könnte das halbwegs passen. n Rotomax 150cc hat ca. 8µH auf Ld und 12 auf Lq. Das ist aber n Dreieck Maschinchen. Und leicht größer :). Die Kopplung über Ld/Lq sind nicht stark. Ein genauer Rs und Psi_M sind wichtiger. Gerade der Psi_M macht viel aus.
Puh ich glaube ich werde das Thema niemals ganz umreißen :) Rs steht leider nicht im "Datenblatt". Ich habe das mit einem 4 Punkte Messgerät an den Kabelenden (10cm) gemessen und komme auf 0.145Ohm. Kann es sein, dass für diese Entkopplung von d und q Folgendes nicht gut ist: d und q Regler bekommen als Ist- und Sollwerte echte Größen, also den tatsächlich fließenden Strom. Die Ausgänge der Regler bewegen sich aber nur -0.95 < 0 < +0.95 und werden direkt auf SVM gelegt. Sprich, ich bin an dieser Stelle bereits nicht linear. (Oder doch?) Die Regler regeln direkt die PWM Duty. Kann so ein Regler in diesem Fall funktionieren oder muss ich zwingend so Regeln dass ich als Ausgang Spannung erhalte und diese erst dann in PWM Duty umrechne? In der AppNote von MicroChip bewegen sich die Regler auch nur -0.95 +0.95, allerdings weiß man auch nicht, wie dynamisch deren Regelung dann in Wirklichkeit ist.
Wenn du den Widerstand von Anschlussleitung zu Anschlussleitung gemessen hast, dann musst du den Halbieren. 70mOhm bei so einem kleinen Motor klingen dann für mich erst mal ok. Was Duty als Stellgröße angeht. Kannst du das so lassen du siehst deine Brückenspannung als konstant an. Bricht diese ein dann reduziert die ja deine Verstärkung vom Regelkreis, damit ist das unkritisch. Vllt sogar robuster weil du nicht jede Welle auf der Versorgungsspannung mit ausregelst.
Angehängte Dateien:
-
20150407_195401.jpg
240 KB
Weil mein Iq und Id absolut nicht Gleichstrommäßig aussieht, habe ich auf der Suche festgestellt, dass meine Ialpha und Ibeta nach Clarke T. total unsymetrisch sind. Wenn ich mir die adc1..2 werte für phasenströme über die DACs ausgebe bekomme ich im Screenshot zu sehen. Das kann doch nicht richtig sein oder? Es sieht wie fast 180grad verschiebung aus. Währenddessen war en Vq und Vd nicht geregelt sondern fest vorgegeben. Die POPO Kurven aus der svm sehen dagegen schon um 120Grad verschoben aus. Interssant wie die Phase Währenddessen aussieht.
Sind das nicht etwa I_alpha und I_beta? Da wäre ja alles ok. Hast du mal mit dem Scope direkt an den OPs gemessen für die Strommessung? Irgendwas ist da faul. Ist jetzt übers Forum auch schwer zusagen. Kannst du den Antrieb mit nem Akkuschrauber oder so drehen? Dabei alle Phasen nur mit Lowside an. Und langsam drehen und den Strom ansehen. Ohne PWM.
Es waren wirklich die Ströme. N Brückentreiber war tot :(. Jetzt passen die Ströme wieder. Sollten Ialpha und Ibeta immer 180grad phase haben? Hängt es nicht von den Amplituden der Ströme ab? Mal sehen ob die Entkopplung der Regler jetzt klappt. Gruß Andreas
Andreas True schrieb: > Es waren wirklich die Ströme. N Brückentreiber war tot :(. Jetzt passen > die Ströme wieder. > Sollten Ialpha und Ibeta immer 180grad phase haben? Hängt es nicht von > den Amplituden der Ströme ab? > Mal sehen ob die Entkopplung der Regler jetzt klappt. > > Gruß > Andreas Nein 90° Phase. Sind ja Senkrecht zu einander stehende Achsen. Bin gespannt obs dann passt. ggf. musst du w noch filtern, damit die Regler nicht schwingen. Musst du probieren.
Hallo, habe das Problem immer noch nicht lösen können. Es sieht folgendermaßen aus: PI Regler für d und q mit Kp = 0.001, Ki = 0.001 Als Last dient ein 8x5 Propeller. Bei niedriger Drehzahl läuft der Motor. Steigere ich langsam Iq_soll, steigt auch die Drehzahl. Bei einer gewissen Drehzahl bleibt der Motor abrupt kurz stehen, dreht wieder hoch und bleibt bei der selben Drehzahl wieder stehen.. Bremse ich die Maschine zusätzlich mit der Hand, kann ich mehr Iq_soll vorgeben, ohne dass der Motor abrupt stehen bleibt, solange ich unter dieser bestimmten Drehzahl bleibe. Das passiert unabhängig davon, ob ich die Koppeltherme verwende oder nicht. Ich addiere diese Therme auf den Ausgang der Regler wie weiter oben empfohlen. Mir ist aufgefallen, dass durch die Entkopplung der I Anteil der Regler auf Null geht sobald der Sollstrom erreicht ist. Ist dies genau das Ziel der Entkopplung? Wäre es nicht besser, die Koppeltherme noch vor dem Regler von dem Ist_Wert abzuziehen(?) weil deren Berechnung auf Iq und Id basiert, aus dem Regler kommen aber Spannungen und nicht Ströme raus:
1 | i_d_Discouple = -OmegaFltred * Ls * Iq; |
2 | i_q_Discouple = OmegaFltred * Ls * Id + OmegaFltred * Ke; |
Ich habe auch den Modifizierten Regler von Shane Colton versucht nachzubauen. Allerdings hatte ich hier absolut das selbe Problem nur schon bei viel geringerer Drehzahl. Gruß Andreas
Das hört sich für mich danach an, dass dein Beobachter nicht sauber arbeitet. Addiere mal bitte zu deinem Winkel Ts * w. Ts ist die Zykluszeit mit der du den Beobachter aufrufst. w ist die Drehzahl in rad/s. Ich vermute das dir deine Abtastzeit (Ts) einen strich durch die Rechnung macht. Denn du berechnest den Winkel für den nächsten Schritt im Vorherigen. In der Zeit zwischen jedem Schritt dreht sich die Maschine aber. Deshalb grundsätzlich phi_k+1 = Ts*w + phi_k. Gruß Tec.
Hab es eingebaut, leider das selbe Ergebnis. Es passiert schon bei geringer Drehzahl wo (Ts * w) nur 0.08 beträgt. Wenn ich aber den OpAmp Gain im Programm mit 10 multipliziere und Kp, Ki auf 0.1 stelle (scharf) kann ich ca 90% Dutyzeit fahren. Allerdings ist Iq_soll dabei total nicht linear, kaum Drehmoment und summen bei geringer Drehzahl.
Die Strommessung passt? Welchen Opamp Gain? Den vom Stromopamp? Mit wieviel kHz arbeitet die PWM und die Regelung?
Strommessung passt (ADC1..2 über DAC1..2 ausgegeben machen zwei 120° Sinuskurven am Scope) Der echte OPV Gain beträgt 10. Winkelbeobachter, PWM, RZM und die d,q Regler laufen mit 20kHz.
Mir ist noch Folgendes aufgefallen: Wenn ich den Gain in SW nicht künstlich anhebe, sehen die Sinus-Stromkurven total unrund aus. Mit Gain*10 sind die dagegen schön rund.
Mhh aber mit Gain*10 sind deine Gemessenen Stromwerte doch falsch um eben Faktor 10 oder sehe ich das falsch? Das der Sinus unrund ist kann am Winkel liegen hast du den Mal dazu geplottet?
Tec, du hattest wie immer recht (y), das Problem lag/liegt am Beobachter. Wenn ich die Eingangsströme Ialpha und Ibeta innerhalb des Beobachters geteilt durch 10 nehme und den OPV Gain bei 10 belasse, so wie es auch in der Realität ist, laufen die Regler wesentlich besser. Jedenfalls bleibt der Motor nicht einfach bei einer bestimmten Drehzahl stehen. Ich muss den Beobachter nochmal durchrechnen, wird wohl an irgendeinem LPF Koeff. liegen. Ist es empfehlenswert auf einen PLL Beobachter umzusteigen? Zu der Frage oben: Macht es einen Unterschied, bzw. ist es nicht besser die Entkoppelungstherme nicht auf die Reglerausgänge zu addieren sondern von den gessenen Strömen abzuziehen und erst dann den Regler auszführen? Weil diese Therme sich auf die Ströme beziehen. Gruß Andreas
Andreas True schrieb: > Ist es empfehlenswert auf einen PLL Beobachter umzusteigen? Ja und nein. 1. Wenn du ein generelles Problem hast bringt die PLL auch nix. Die bringt nur was wenn einen stark rauschenden Lagebeobachter hast. Und selbst dann, ist eine PLL ein schwingfähiges System. Soll heißen wenn die nicht sauber eingestellt ist schwingt die und das noch schlimmer als deine Variante jetzt. Der nächst bessere Beobachter wäre meiner Meinung nach ein Rotorflussbeobachter mit PLL. aber wie gesagt die sind nicht einfach einzustellen. Grob: (Us - R*is) integrieren. Dann -L*is und dass dann wieder auf den Eingang des Integrators mit ner Verstärkung zurückführen. Mit der Verstärkung in der Rückführung stellst du den dann ein. Dann machst du atan2 von den Werten vor der Rückführung. also: Int(Ualpha - R*Ialpha - g*PsiAlpha) - L*Ialpha = PsiAlpha das auch für beta. g ist dabei die Verstärkung die du Einstellen musst. Und dann Atan2(PsiAlpha, PsiBeta) = phi. Oder du nagelst an den ne PLL. Dann brauchst du den trigonometrischen Additionssatz. Winkeldifferenz von a und b = sin(a)*cos(b) - cos(a)*sin(b) (prüf das bitte das ist nur aus dem Kopf geschrieben.) Das Signal was daraus kommt auf n PI-Regler und der auf n Integrator für phi. Kurz Integrator in Sw: Alter Wert + Ts*Neuer Wert (Ts Abtastzeit = 1/20kHz bei dir) Andreas True schrieb: > Zu der Frage oben: > Macht es einen Unterschied, bzw. ist es nicht besser die > Entkoppelungstherme nicht auf die Reglerausgänge zu addieren sondern von > den gessenen Strömen abzuziehen und erst dann den Regler auszführen? > Weil diese Therme sich auf die Ströme beziehen. Nein!!! Die Entkopplungstherme ergeben Spannungen die kannst du nicht von Strömen abziehen. (jedenfalls ist das nicht richtig!)
Angehängte Dateien:
Recht ähnlich macht die AN1078 den Beobachter auch glaube ich, aber ohne PLL. Ich habe übrigens den modifizierten Regler von Shane Colton eingebaut(hoffentlich richtig). Die Regelung funktioniert nun recht gut. Mit den Entkopplungsthermen hat sie aber auch gut funktioniert. Allerdings bremse ich mit der Velocity Loop noch nicht aktiv (Iq negativ) Tec Nologic schrieb: > stark rauschenden Lagebeobachter Im Screenshot sieht man den Winkel und OPV Ausgang Phase1. Der Winkel sieht gut aus oder? Es ist sogar so, wenn der Motor die Rampe ein mal hochgefahren ist, kann ich den Strom auf Null stellen (0 Drehzahl) und dann wieder ohne Rampe anfahren. Auf was beziehen sich eigentlich die Stromangaben auf den Modellbau BLDCs? Mein Motor ist mit 8A ud 9A_Peak spezifiziert. Als ich diesen Screenshot aufgenommen habe, war Iq_soll auf 9.0 eingestellt. Wenn ich die Amplitude aus dem ScopeBild nachrechne fließen da auch -9 bis +9 Ampere. Auf dem DC Bus logischerweise weniger. Ca 5A, also nicht ganz den Effektivwert. Bezieht sich die Angabe auf dem Motor auf den Effektivwert oder sozusagen auf Iq?
Andreas True schrieb: > Auf was beziehen sich eigentlich die Stromangaben auf den Modellbau > BLDCs? Auf DC bzw. den Effektivwert. Aber da du den Antrieb ordentlich betreibst und keinen spielzeug steller aus dem Modellbau nimmst kannst du locker noch mal 10% mehr geben oder der wird nicht wirklich Wärmer. Also 10Aeff ist ok. Winkel und Strom sehen sehr gut aus! Andreas True schrieb: > Allerdings bremse ich mit der Velocity Loop noch nicht aktiv (Iq > negativ) Da musst du bei der Colton Variante aufpassen. Du musst die Länge des Spannungszeigers Negativ machen. also der Iq-Regler muss das aus regeln. Sonst zerlegts die Maschine beim bremsen. Ich habe fest gestellt das die Entkopplung da robuster funktioniert. Colton ist nur einfacher in die Gänge zu bekommen. Andreas True schrieb: > Es ist sogar so, wenn der Motor die Rampe ein mal hochgefahren ist, kann > ich den Strom auf Null stellen (0 Drehzahl) und dann wieder ohne Rampe > anfahren. Das ist gut, dann ist die Grenzfrequenz des Beobachters schön niedrig. Wenn du den Rotor jetzt vorher mit einem Strom auf d Achse ausrichtest kannst du auch ohne Anlauf anfahren. Nur bei großer Last bzw. Trägheitsmoment an der Welle wird das problematisch sein. Für ne Luftschraube ok. Wie ists mit dem Leerlauf? Kann der Beobachter der Maschine folgen wenn die mit 10A beschleunigt in den Leerlauf rein? Da musst du dann aufpassen wegen den I anteilen der Regler. Die musst du an halten bei maximal Spannung.
Tec Nologic schrieb: > Da musst du bei der Colton Variante aufpassen. Du musst die Länge des > Spannungszeigers Negativ machen. also der Iq-Regler muss das aus regeln. > Sonst zerlegts die Maschine beim bremsen. Mein Drehzahl Reger gibt dem q-Regler beim Bremsen -10 als Sollwert vor. Den WinkelPhasenregler(Colton) für Id lasse ich unverändert. Kann es sein dass ich an dieser Stelle diesen Output auch invertieren muss? So wie es jetzt ist, bremst der auch schön, und erzeugt schöne Überspannungen auf dem DC Bus beim Bremsen. Gut, dass du mir das mit dem Bremschopper gesagt hast. Funktioniert wuderbar :) Tec Nologic schrieb: > Strom auf d Achse ausrichtest > kannst du auch ohne Anlauf anfahren Funktioniert, das ist ja nice! Ich kann sogar den Motor festhalten, der Drehzahlregler gibt dabei auf Iq_soll maximalen Strom und der Beobachter kommt nicht durcheinander. Tec Nologic schrieb: > Kann der Beobachter der Maschine folgen wenn > die mit 10A beschleunigt in den Leerlauf rein? Jep, folgt dem bis in die Maximaldrehzahl (ohne FieldWeakening) Zu dem maximalen Strom: Wenn der Motor mit dem Propeller dran aus dem q-Regler Vq=0.95 bekommt, fließt leider auf dem DC Bus keine 8-9A wie im Datenblatt sondern ca 5.5A. Dabei dreht die Maschine aber ca nur 7,5k rpm, also keine max Drehzahl. Sprich ich bekomme trotz genügend Belastung nicht den max. DC Strom durch. Woran könnte das liegen?
Andreas True schrieb: > Sprich ich bekomme trotz genügend Belastung nicht den max. DC Strom > durch. Woran könnte das liegen? du brauchst ne größere Luftschraube um den Motor mehr zu belasten. Die erreichbare Drehzahl sinkt ja mit der Belastung 7k rpm ist da recht normal. Leerlaufdrehzahl ist ja quasi ohne Last aber selbst ohne Luftschraube hast du ja noch die Reibung der Maschine. Freut mich das das so gut funktioniert. Das mit dem BremsChopper ist wichtig eben gerade an einem Labornetzteil. Weil die sonst aussteigen oder sterben.
Mit der 8x5 Schraube und dem 8A Motor erzeuge ich ca 370g Auftrieb (nach unten, gegen eine Küchenwaage), ist das in Ordnung für den Motor? Ich sollte mir ein China ESC mit SimonK SW besorgen und mal die Dynamik und maxDrehzahl vergleichen. Jetzt muss ich noch schauen, wie der Beobachter und Shane Colton Regler rückwärts funktionieren, damit ich umdrehen kann.
Gibt es einen Grund, dem Drehzahlregler den Iq Regler zu unterlagern wenn man nicht Drehmoment sondern nur Drehzahl regeln möchte? Ich habe probeweise den Ausgang des Drehzahlreglers direkt auf Vd gelegt und ein IF eingebaut, damit bei zu viel Strom der Drehzahlregler nicht noch weiter schiebt. So habe mit der Schraube drauf die Beschleunigungszeit 1500rad/s - 4500rad/s um ein Viertel verbessern können. Das ganze natürlich mit Shane Colton d-Regler, da sonst keine Entkopplung möglich ist.
Andreas True schrieb: > Ich habe probeweise den Ausgang des Drehzahlreglers direkt auf Vd gelegt meinte natürlich Vq
Andreas True schrieb: > Gibt es einen Grund, dem Drehzahlregler den Iq Regler zu unterlagern > wenn man nicht Drehmoment sondern nur Drehzahl regeln möchte? Rein von den Differentialgleichungen muss das so. Normalerweise erhöht sich durch den Stromregler die Dynamik des Drehzahlregelkreises. Weil man die Zeitkonstante des Stromregelkreises durch den PI-Regler verkleinern kann. Das du mit Spannungsvorgabe bessere Ergebnisse hast deutet darauf hin das mit der Stromregelung etwas nicht stimmt. Aber wenns so geht ist auch erst mal ok.
Tec Nologic schrieb: > muss das so Achso, alles klar :) Ich hätte noch zwei noch zwei Fragen zum Beobachter. 1. Ich habe es nun geschafft dass der Beobachter vorwärts wie rückwärts funktioniert, aber speziell beim Bremsen während die Maschine sich noch vorwärts dreht, der Spannungsverktor aber negativen Strom erzeugen will. Muss ich schon an dieser Stelle den Beobachter auf "rückwärts" stellen oder erst dann wenn die Maschine bereits tatsächlich rückwärts läuft? 2. Damit ich mit max. Iq (und max Drehmoment) anfahren kann, ohne dass der Beobachter blockiert oder sich durchdreht, benötige ich extrem genaue R und L Daten. 0.005 Ohm machen da schon ein Unterschied. Sprich ausprobieren. Du hast vor ein paar Monaten geschrieben, dass du mit der Kv bzw. Ke und R Angabe auskommst. Ich sehe keine Möglichkeit die Gleichungen so umzustellen, dass ich ohne L auskomme. Der Beobachter ist so ziemlich so aufgebaut, wie du in deinem letzten Post beschrieben hast. Nur, dass die Verstärkung ab einer gewissen Abweichung zwischen geschätztem und gemessenem Strom sogar nicht-linear verstärkt. Kannst du vielleicht noch etwas dazu schreiben?
Was vorwärts rückwärts angeht habe ich immer Probleme mit den Stromregelern beim Bremsen gehabt, dem Beobachter wars egal. Und Colton wird mit dem Vorzeichen der Stellgröße für den Betrag des Spannungsvektors auf Vorwärts oder rückwärts umgestellt. Was die Parameter angeht. Wenn der Flussbeobachter z.B. nach Rasmussen ausgelegt ist kommt der mit ca. 20% Parameterfehler aus. Speziell auf L Abweichungen ist der aber recht unempfindlich. -> man kommt mit einem gewählten L recht weit. Ich habe mittlerweile die Strategie die Parameter zu messen mit dem Umrichter. Nur so kann ich wirklich eine sehr gute Performance erreichen. Du kannst z.B. die Parameter gut vor wählen und dann n RLS auf jeden Parameter einzeln nacheinander im round-robin los lassen. Das dauert dann aber etwas bis die Parameter korrigiert sind. In das Ganze kann man dann noch mehr Arbeit stecken. Gruß Tec
Nimmst du für die Messung der Motordaten mit dem FU den Rotor von dem Motor ab? Speziell für L Messung. Ich habe auf Phase1 und Phase2 eine niedrige konstante Duty gelegt, also quasi DC Spannung mit PWM und den Strom an den Shunts gemessen. R = U/I. Allerdings sind da viel zu große Werte rausgekommen :( Andreas True schrieb: > Damit ich mit max. Iq (und max Drehmoment) anfahren kann, ohne dass > der Beobachter blockiert oder sich durchdreht, benötige ich extrem > genaue R und L Daten Mir ist aufgefallen, dass das nicht so viel von den Parametern, sondern viel mehr vom eingestellten Gain des Beobachters abhängt. Stelle ich den Gain 0.0001 kann ich mit wirklich extrem viel Drehmoment anfahren. Dafür ist die Performance bei hoher Drehzahl extrem schlecht. Gain auf 0.4 und der Beobachter "dreht durch" bei niedriger Drehzahl, sprich er denkt, dass der Rotor mitgekommen ist. Dafür gute Performance bei hoher Drehzahl. Ist das bei dir auch so? Gruß Andreas
Ähnlich. Ich erhöhe die gains mit der Drehzahl. Von dem einfachen wert bis zum ca 20 fachen bei w=10000rad/s Bei der R Messung ist der Leitungswiderstand immer mit drin. Bei den paar milliohm im stator musst du die rausrechnen.
Wenn ich das richtig verstehe, ist in der AN1078 diese nicht-lineare Verstärkung dafür zuständig. Allerdings bekomme ich ständig NaN und inf Probleme wenn das Programm in diesen Zweig lenkt. Ist gar nicht so leicht, sowas auf nem uC zu lokalisieren. Ein Teil davon:
1 | if(Abs_Float(IalphaError) < MaxSMCError) |
2 | {
|
3 | // ich glaube dieser Zweig ist die Ursache für Entstehung sehr vieler
|
4 | // NaNs
|
5 | Zalpha = (Kslide * IalphaError) / MaxSMCError; |
6 | }
|
7 | else if(IalphaError > 0) |
8 | Zalpha = Kslide; |
9 | else
|
10 | Zalpha = -Kslide; |
Kslide ist dabei der normale Gain. R Messung: ist es richtig, dass ich hierzu die ADC Messung in HIGH Phase der PWM Duty triggern muss?
NaN kommt wegen einer Division durch 0. ist MaxSMCError wirklich immer größer 0. mach mal ne Abfrage davor. Das ganze was du da hast ist der SMC, sliding mode controller. Im Prinzip ein p-regler mit Begrenzung. Ich hätte jetzt Kslide mit w erhöht. Zur Rs Messung. Wieviele Schritte hat deine PWM? Wieviel Auflösung erreichte du damit? Das Problem ist die Induktivität. Die hält dir ja den Strom hoch. Nur muss die PWM muss schnell genug sein dass der Strom nicht lückt. Also im PWM Zyklus 0 wird. Deshalb Messe ich vorher die Induktivität. Das kann ich aber erst in 4-6 Wochen erklären. Dann ist die thesis beim Prof durch hoffe ich.
Jep, MaxSMCError ist immer != 0. Komischerweise werden einige Variablen, die mit dem Beobachter zu tun haben zu NaN wenn ich die Variable < 0.15 und > 0 setze. An anderen Stellen werden keine Divisionen gemacht. Setze ich diese Variable negativ, werden einige Variablen nicht Nan sondern Infinity. Könnte es sein, dass die float Verarbeitung bzw. die FPU keinen konstanten Speicherverbrauch hat und dieser kurzzeitig voll wird Oder die FPU Einheit mit dem Rechnen nicht fertig wird, sich aufhängt, aber der Rest des uC's weiter läuft? Ist natürlich nicht optimal mit Floats zu rechnen, aber dafür ist das Programm für mich viel leserlicher und die Werte nachvollziehbarer. PWM läuft mit 12 Bit Auflösung. Mal schauen ob ich es so einstellen kann dass der Strom nicht lückt. Gruß Andreas
Andreas True schrieb: > Könnte es sein, dass die float Verarbeitung bzw. die FPU keinen > konstanten Speicherverbrauch hat und dieser kurzzeitig voll wird Oder > die FPU Einheit mit dem Rechnen nicht fertig wird, sich aufhängt, aber > der Rest des uC's weiter läuft? NEIN. Andreas True schrieb: > Ist natürlich nicht optimal mit Floats zu rechnen, aber dafür ist das > Programm für mich viel leserlicher und die Werte nachvollziehbarer. Genau dafür ist sie da. Ich rechne auf dem STM32F4 nur in Float!!! und die Berechnungen sind schneller als in Integer. Weil ich keine Skalierung und Überlaufbetrachtung machen muss. Die FPU des Cortex M4F macht float Berechnungen bis auf die Division in 1 oder 2 Takten. Die genauen Zahlen gibts im Netz musst mal googlen. Aber die FPU ist nicht dein Problem. Der Code und der Compiler sinds. 1. wenn du den GCC verwendest. Setzt du bitte das Compiler Flag -fshort-double Use the same size for double as for float. und vllt probierst du mal -ffast-math Sets -fno-math-errno, -funsafe-math-optimizations, -fno-trapping-math, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans and fcx-limited-range. Aber mit vorsicht. Dann zum Code. INF ist das Ergebnis bei der Division mit sehr kleinem Nenner. NaN kommt gern bei Division durch 0 oder wenn der Stack korrupt ist. Beide Werte sagen mir das dein Code nicht sauber ist. Mach mal ne Abfrage if(isnan(xyz)) auf Werte die du in Verdacht hast NaN zu werden. und setz da n Breakpoint. Dann kannst du die Rechnungen nachvollziehen die dazuführen warum der Wert NaN ist. Oft kommt man dann dazu das ein weiterer Wert davor schon NaN war. Dann das gleiche Spiel bis du die Ursächliche Operation gefunden hast. Ist nervig, vor allem wenn der Code aus Matlab rauspurzelt. Aber es Hilft.
Tec Nologic schrieb: > -fshort-double > -ffast-math Ok, das hat die Laufzeit auf ein Drittel reduziert, nice :) @NaN: ich habe das komplizierte IF von oben umformuliert, von der Logik her aber das selbe, nun läuft der ohne Probleme durch :/ Hast du Erfahrungen mit internen OPVs? Ich werde später ein kleineres Board machen und würde gerne auf STM32F303 M4 setzen. Der hat auch sonst mehr interessante Sachen. Testweise kann ich dieses Board auf meine Platine stecken: http://www.ebay.de/itm/STM32F3-DISCOVERY-USB-STM32F303VCT6-STM32-ARM-Cortex-M4-Development-Board-/151665309864?pt=LH_DefaultDomain_77&hash=item234ff4f8a8 Ich würde gerne auf den drv8302 verzichten, da er doch nicht ganz günstig ist. Gruß Andreas
Der DRV8302 macht mir auch immer mal wieder Problem bei Bestücken per Hand. Ich mag das Gehäuse nicht. Die Internen OPVs sind mit vorsicht zu genießen. Ich hatte Probleme mit der Definition der Pins. Die interne Verbindung des OPV Ausgangs auf den ADC ging nicht obwohl meiner Meinung nach alles sauber eingestellt war. Hab dann den Ausgang des OPV aufn Pin gelegt und denn Als ADC eingang. Ging auch. Musst du eh machen wenn du den OPV als Verstärker nutzen willst ich hatte den nur als Impedanzwandler eingestellt um meinen Sensor nicht zu belasten. An sonsten waren die OPVs sehr gut zu gebrauchen. Ich mag den STM32F3 auch sehr gern. Hat analog einfach mehr drauf. Aber leider braucht meine Regelung noch zu lange das ich den nehmen kann. Ich muss mal wenn ich zeit habe alles raus schmeißen und Auf den F3 gehen. Was ich an dem Ding richtig super finde ist wie robust der Ausgelegt ist. Wenn der STM32F4 schon dreimal n Hardfault wegen EMV hatte , interessiert es den F3 garnicht. Das ist schon schön. Der F3 hat ja aber auch military grade:).
Moin, Tec Nologic schrieb: > Ich muss mal wenn ich zeit habe alles raus schmeißen und > Auf den F3 gehen habe mittlerweile ein Adapter für mein Board und STM32F3 Disco Board gebastelt und die wichtigsten ADC und Timer Konfigurationen auf dem F3 gemacht. Die Software mit w, q, d Regler und dem Winkelbeobachter, alles @ 20kHz läuft nun. Benötigt ca 38uS Rechenzeit, mit FPU. Reicht aber :) (zum Vergleich, auf F4 brauchte es 16uS) Allerdings hat meine PWM jetzt nicht mehr 12Bit (=4095) Auflösung sondern nur 1800 Schritte, damit ich weiterhin mit 20kHz fahren kann. Wirkt sich das auf irgendeine Weise negativ auf die Steuerung aus? Zurzeit läuft der Motor bei höheren Drehzahlen nicht mehr so gut wie mit STM32F4, was aber hoffentlich nur an dem gebastelten Adapter liegt. @DRV8302: Wollte bei meinem nächsten kleineren Board wieder auf 3 einzelne Brückentreiber setzen, aber die können alle an Vcc maximal 25Volt ab. Da ist der DRV8302 natürlich meilenweit voraus mit seinen 60V.
Andreas True schrieb: > läuft nun. Benötigt ca 38uS Rechenzeit, mit FPU. Reicht aber :) > (zum Vergleich, auf F4 brauchte es 16uS) Da läuft aber auf dem F3 noch nichts aus dem CCM-Ram oder? Andreas True schrieb: > Allerdings hat meine PWM jetzt nicht mehr 12Bit (=4095) Auflösung > sondern nur 1800 Schritte, damit ich weiterhin mit 20kHz fahren kann. > Wirkt sich das auf irgendeine Weise negativ auf die Steuerung aus? ne, überleg dir einfach mal den Fehler den die PWM macht. Bei deinen 12V sinds dann immer noch 6,7mV/LSB, das geht im rauschen unter. alles gut. Andreas True schrieb: > @DRV8302: Wollte bei meinem nächsten kleineren Board wieder auf 3 > einzelne Brückentreiber setzen, aber die können alle an Vcc maximal > 25Volt ab. > Da ist der DRV8302 natürlich meilenweit voraus mit seinen 60V. Vorsicht!!!. Der DRV hat n Stepper drin für 5V supply und die Gatetreiber haben auch ne Art Netzteil. Denn die meisten Fets können nur 20V am Gate max ab. Also eher 18V versorgung für die Treiber. Meine Große 100A Brücke hat zwar ein paar andere Designfehler aber bei der habe ich vor den IR2113S Treibern einen TPS Stepdown für 60V+ auf ca. 17,5V drin. Mein Fehler war aber das ich von diesen 17V dann eine Stepper auf 5V gebaut habe. Da aber die Treiber nur Impulsweise Strom ziehen siehst du die SChaltflanken der Fets auch in dem 5V was der STM32F4 garnicht mag -> Hardfault. Besser 2 separate Stepper von 60V runter auf 18V und einen von 60 auf 5V für die Logik. Aber dann ist das ohne Probleme zumachen.
Tecnologic im Urlaub schrieb: > Da läuft aber auf dem F3 noch nichts aus dem CCM-Ram oder? Nein, alle Variablen ganz normal angelegt. Habe erstmal lesen müssen was CCR-Ram ist. Hört sich sehr interessant an. Tecnologic im Urlaub schrieb: > Besser 2 separate Stepper von 60V runter auf 18V und einen von 60 auf 5V Vielen Dank für den Tipp!! Diesen Fehler hätte ich garantiert auch gemacht. Ich will als nächstes ein kleines ESC für Quadcopter o.ä. machen. Sollte aber trotzdem Encoder, vllt minimalistische CAN und ein paar DAC, ADC, TogglePins für Debugging rausgeführt haben. So wie das Vedder ESC das auch macht. Waere natürlich schön wenn ich es über einen breiten Spannungsbereich (11-60V) einsetzen könnte. Hoffentlich werde ich ohne 5V Zwischenstufe auskommen, denn: Für OPVs kommen voraussichtlich die internen vom F3 zum Einsatz. Habs bischer noch nicht geschafft, den Folger-OPV Ausgang nach Außen zu führen, sondern nur direkt an ADC. Muss noch prüfen ob mein Encoder (5-12Volt spez.) auch mit 3.3V ordentlich läuft. Gruß Andreas
Hallo zusammen, ich befasse mich auc gerade mit der Thematik der feldorientierten Regelung. Ich konnte schon einiges an Infos aus diesem Thread entnehmen. Ich habe allerdings gerade ein kleines Problem bei der Umsetzung bzw. zum Verständnis der Inversen-Park-Transformation. Diese generiert ja aus v_q und v_d die Spannungen v_alpha und v_beta. Jetzt habe ich die gesamte Rechnung bis zu diesem Punkt nachvollzogen. Annahme: Rotorwinkel theta= 0 Phasenstrom i_a= 1, i_b= -0.5 Das ergibt nach der Clarke-Transformation : i_alpha= 1, i_beta= 0 Park-Transformation: i_q= 0, i_d= 1 PI-Regler: Vorgabe: i_q_ref= 1, i_d_ref= 0 v_q= 1, v_d= -1 Inverse-Park-Transformation: v_alpha= -1, v_beta= 1 Der Rotor steht in diesem Szenario auf der a/alpha-Achse und es fließt alpha- bzw. d-Strom. Mit den Stromvorgaben sagt der Regler: q-Spannung erhöhen, d-Spannung runter. Das scheint mir so weit auch logisch, nur jetzt kommt die inv. Park. Diese erzeugt mit v_alpha und v_beta einen Winkel von 135°. Sollte hier nicht eigentlich ein Winkel von 90° heraus kommen, um das maximale Moment zu erzeugen? Sprich v_alpha= 0 und v_beta= 1? (Bzw. -90°, wenn man den q-Strom negativ wählt) Habe ich hier ein Verständnisproblem? Oder falsche Annahmnen gemacht? Die Berechnungen habe ich aus der Application Note "Implementation of a Speed Field Oriented Control of 3-phase PMSM Motor using TMS320F240" von TI übernommen. Ich habe diese auch mit anderen verglichen (z.B. AN908 von Microchip, Berechnungen sing gleich.) Danke und Gruß
Moin paul, Dein Regler macht alles Richtig. er kompensiert einen d-Strom Fehler und versucht gleichzeitig einen q-Strom einzuregeln. Die 135° des Spannungsvektors kommen nur daher, dass beide Regler von einander entkoppelte Systeme betrachten. Wenn du dir dazu mal die Untersuchungen in dem pdf hier an siehst: https://b94be14129454da9cf7f056f5f8b89a9b17da0be.googledrive.com/host/0B0ZbiLZrqVa6Y2d3UjFVWDhNZms/motordrive/MSCR_Rev1.pdf siehst du das die Trajektorie die eine getrennte d/q-Stromregelung beschreibt nicht optimal ist. Was man dazu auch wissen sollte die MSCR Variante hat auch ihre Tücken. Gerade bei Drehrichtungswechseln usw. Gruß Tec
Hallo Tec, vielen Dank für die Rückmeldung. Dann bin ich schon mal zufrieden, dass ich alles bis zur inv. Park richtig verstanden, interpretiert und umgesetzt habe :-) Das pdf habe ich mir angeschaut, bin allerdings noch nicht ganz dahinter gestiegen. Auf den ersten Blick sieht es für mich so aus, dass dort statt zwei Spannungen, eine Spannung und ein (Vorlauf-) Winkel vorgegeben werden. Das muss ich mir nochmal genauer ansehen. Gibt es andere Möglichkeiten die Regelung anzupassen? Anscheinend wird in fast jeder AppNote das Prinzip so erklärt, wie ich es umgesetzt habe. Ist ein Entkoppelungsnetzwerk eventuell der richtige Ansatz, da v_q und v_d jeweils von i_q und i_d abhängig sind? Gruß Paul
paul schrieb: > Ist ein Entkoppelungsnetzwerk eventuell der richtige Ansatz, da v_q und > v_d jeweils von i_q und i_d abhängig sind? Immer. Aber selbst dadurch ist wird die Trajektorie beider Regler in deinem Fall nur mäßig besser. Aber dein Beispiel stellt auch keinen realistischen Fall dar. Normal beginnst du ja mit beiden Strömen gleich Null. Und dann geht sich das alles aus. Und das Entkopplungsnetzwerk ist nur noch eine Störgrößenaufschaltung sofern du die Motorparameter genau genug kennst. paul schrieb: > Auf den ersten Blick sieht es für mich so aus, dass dort > statt zwei Spannungen, eine Spannung und ein (Vorlauf-) Winkel > vorgegeben werden. Das muss ich mir nochmal genauer ansehen. Richtig mehr ist das auch nicht. Da der Winkel auf beide Spannungskomponenten wirkt. Verkürzt sich die Trakjektorie. Wobei eine korrekte Vorsteuerung und Entkopplung den beiden PIs so auf die Sprünge hilft, das die klassische Regelung ähnlich gut wird. Die MSCR Variante ist nur einfacher einzustellen. Weil der Winkel-Regler immer gleich ist. Gruß Tec
Warum stellt mein Besipiel keinen realistischen Fall dar? Ich habe in meiner Simulation jetzt folgendes versucht: i_a= 0, i_b= 0, theta= 0. Dann ist es so, wie du gesagt hast. Die Regler geben nur v_beta aus und damit steht der resultierende Zeiger bei 90°. Wenn ich theta ändere, ändert sich der Winkel des Zeigers immer auf theta+90°. Sobald ich aber Werte für i_a und i_b != 0 angebe, wird der Winkel größer als 90° (unter der Annahme, dass der Rotor bzw. Theta auf eine Achse ausgerichtet ist und d-Strom fließt). Wenn ich das auf meinem Controller ausprobiere, funktioniert die Regelung auch nicht besonders gut. Der Motor ruckelt stark, bleibt hängen, gibt Geräusche von sich.... Gruß Paul
paul schrieb: > Sobald ich aber Werte für i_a und i_b != 0 angebe, wird der Winkel > größer als 90° (unter der Annahme, dass der Rotor bzw. Theta auf eine > Achse ausgerichtet ist und d-Strom fließt). Natärlich weil dein i_aund i_b einen i_d !=0 darstellen wird. Dann muss doch der Spannungsvektor weiter voreilen damit der Stromvektor wieder rein i_q != 0 und i_d = 0 wird. Ich glaube du bringst die Spannung und die Ströme durch einander, mit den 90°. Der Spannungsvektor ist mittel zum Zweck! Das ist deine Stellgröße. Für die Maschine und deren Effizienz ist nur relevant das der i_d = 0 ist und i_q das Drehmoment einstellt. Wenn die dir die Koppeltherme für i_d und i_q ansiehst sollte dir auf fallen das für omega mit ausreichender höhe v_d < 0 sein MUSS damit i_d = 0 ist. Mach mal die Gegenprobe stell mal einen i_d < 0 ein dann hast du an Stelle von 135°, einen 45° Spannungsvektor.
Alles klar. Du hast Recht ;-) Bei i_d < 0 kommen 45°. Es macht schon irgendwie Sinn, dass der Vektor dann weiter vor eilen muss, aber die ganze Sache ist doch nicht so einfach zu verstehen. Ich habe die ganze Sache nochmal auf meinem stm überprüft und die Ergebnisse verglichen. Mit ist aufgefallen, dass die Berechnung der PWMs gedreht war. Ich habe das Bild aus der Application Note so interpretiert, dass bei v_alpha= 1 und v_beta= 0 (als Beispiel) der resultierende Vektor 100 ist und damit PWM_a einen Duty-Cycle größer 50% fährt, PWM_b und PWM_c kleiner 50%. Die Rechnung ergibt aber genau das Gegenteil. Jetzt sollte das passen. Ich werde mich dann mal an die Einstellung der Regler machen. Erst Strom, dann Drehzahl. Danke nochmal Tec
hallo, bin der alex. und beschäftige mich für ein Projekt mit der FOC für einen BLDC. der SVPWM habe ich schon. und es funktioniert super. ich benutze einen inkrementalgeber (ENCODER), der mir nur den relativen winkel liefert. da ich mit simulin arbeite, habe ich schon alle böcke und Subblöcke. ich glaube, dass mein Problem nur noch den absolut Winkel zu bekommen ist. wie komme ich drauf? LG alex zebaze
Alexander B. schrieb: > Du verwendest den Code der AN1078 Ich lese mich gerade in das Thema sensorloses FOC ein. In meinem Projekt läuft der Motor bereits mit Hallsensoren, nach dem "Kochrezept" der ST-Dokumentation UM1052. Sensorlos ist hier aber nur sehr rudimentär beschrieben. https://github.com/stancecoke/LishuiFOC Ich habe mir die AN1078 zu Gemüte geführt und werde wohl versuchen, es analog in mein Projekt zu implementieren, hier im Thread haben das ja offensichtlich einige erfolgreich umgesetzt. Leider scheint keiner seinen Code veröffentlicht zu haben. Im VESC-Projekt ist offensichtlich ein anderer Ansatz implementiert und ich frage mich, ob es einfacher wäre, diesen zu verstehen und zu adaptieren. Ausser den Kommentaren im Code habe ich keine Dokumentation gefunden, die den Ansatz erklärt :-( https://github.com/vedderb/bldc Hat jemand eine Empfehlung welcher Ansatz für im Gegensatz zu Modellbaumotoren schwere und langsam drehende Pedelec-Motoren besser geeignet ist? Gruß hochsitzcola
hochsitzcola schrieb: > Hat jemand eine Empfehlung welcher Ansatz für im Gegensatz zu > Modellbaumotoren schwere und langsam drehende Pedelec-Motoren besser > geeignet ist? Ganz einfach. Für langsam drehende Motoren braucht man sinnvollerweise immer einen Positionsgeber, erst recht wenn man im Stand Drehmoment erzeugen und regeln will.
Hm, grundsätzlich sicherlich richtig, ändert aber nichts daran, daß Millionen von Pedelecs sensorlos unterwegs sind :-) Gruß hochsitzcola
Ah nö. Die haben alle Hallsensoren! Das Papier für den Beobachter des VESC ist im Kommentar im Code angegeben. Wo ist das Problem?
Alexander B. schrieb: > Ah nö. Die haben alle Hallsensoren! Ah nö. Die meisten Baumarkträder haben sensorlose Motoren. http://www.topbikekit.com/akm85sx-24v250w-front-driving-32holes-ebike-hub-motor-hall-sensorless-p-303.html Alexander B. schrieb: > Das Papier für den Beobachter des VESC ist im Kommentar im Code > angegeben Ich habe die verdächtig klingenden Dateien durchgescrollt und nichts gefunden. Kannst du mir auf die Sprünge helfen? Gruß hochsitzcola
Ah, hab's grad gefunden! http://cas.ensmp.fr/~praly/Telechargement/Journaux/2010-IEEE_TPEL-Lee-Hong-Nam-Ortega-Praly-Astolfi.pdf Gruß hochsitzcola
Gut, ist doch schon mal ein Anfang. Da noch eine PLL dahinter und du hast den Beobachter des VESC. Aber so wie Falk es dir prophezeit hat wird der dir bei niedrigen Drehzahlen Probleme machen. Aber implementiere den erstmal und dann können wir uns über die Lageschätzung im Stillstand unterhalten und ob das bei deinen Motoren mit deiner HW überhaupt geht.
Alexander B. schrieb: > Gut, ist doch schon mal ein Anfang. In dem Paper werden kurze Id Pulse in der Ansteuerung beschrieben. Sind die wirklich erforderlich? Deren Sinn verstehe ich nicht. :-( Gruß hochsitzcola
Moin. Die dienen dazu dem Beobachter mehr Informationen nahe dem Stillstand zu geben. Brauchst du nicht. Da gibt es bessere Methoden. Bekomme den erstmal so zu laufen. Dann wissen wir schon mal das deine Strom und Spannungsmessung OK sind.
Alexander B. schrieb: > Bekomme den erstmal so zu laufen. OK, im VESC Code wird Gamma über eine Iteration angepasst. Ist das nötig, oder kann ich da auch erst mal mit einer Konstante starten? Die Motorkonstanten muss ich auch erst mal "Raten" ich hoffe das Ganze konvergiert irgendwie :-) Gruß hochsitzcola
Erstmal kannst du Gamma konstant lassen. Und die Motor Parameter kann man Recht einfach messen. Hast du ein RCL Meter? Sonst tut es auch ein gutes Multimeter und Labor Netzteil das min 5 eher 10A schieben kann. Dann kannst du den Rs messen und für Ls brauchst du noch ein scope um die Entladekurve zu messen. Außerdem kannst du mit dem scope und einem Akkuschrauber die bemf messen.
Alexander B. schrieb: > Und die Motor Parameter kann man Recht einfach messen. Ich werde wohl erst mal mit den Werten aus EPACsim für meinen Motor starten... Ich experimentiere mit einem BionX IGH3 Motor. https://www.pedelecforum.de/wiki/doku.php?id=elektrotechnik:epacsim 5A Labornetzteil und Uralt-Oszi habe ich auch, zur Not könnte ich die Werte also noch mal gegenmessen. Gruß hochsitzcola
Warum verwendest du eigentlich nicht Instaspin/FOC von ti. Das erspart dir viel Ärger und Zeit.
Alexander B. schrieb: > Warum verwendest du eigentlich nicht Instaspin/FOC von ti Reiner Basteltrieb. Der Controller den ich nutze ist in vielen E-Bikes verbaut und in dem werkelt nun mal einen STM32 Prozessor. https://www.pedelecforum.de/forum/index.php?threads/open-source-firmware-f%C3%BCr-lishui-controller.61113/post-1141645 Gruß hochsitzcola
Ah okay. Witzig über das GitHub Projekt bin ich schon gestolpert:). Hat der Controller Phaseshunts Oder Lowside?
Der Controller hat drei Phasenshunts, siehe Foto im Pedelecforum https://www.pedelecforum.de/forum/index.php?attachments/upload_2019-3-14_21-16-4-png.237133/ Gruß hochsitzcola
Das ist ja schonmal nicht schlecht. Wenn du alles in Ruhe lässt wie viele Bits der des ADC für die Shunts ändern sich nicht? Ggf. geht da was.
Angehängte Dateien:
Hier der Plot der AD-Wandler-Werte (12Bit Auflösung) im Stillstand mit aktiver PWM, Strom Iq auf Null geregelt. Ich gebe derzeit noch den Offset der Phasenströme noch manuell vor, ich werde das noch beim Startup automatisiert machen. Gruß hochsitzcola
hast du mehr Rauschen wenn die Regelung aus ist?
Angehängte Dateien:
Wenn ich die das Tastverhältnis fest auf 50% setze, sieht es so aus. Mit aktiver Regelung habe ich je nach Rotorlage verschieden starkes Rauschen. Es wird ja im Moment noch je nach Hall-Muster von den beiden Phasen gemessen, die gerade das niedrigere Tastverhältnis haben. Wo bekomme ich denn einen plausiblen Wert für die Flussverkettung her? Gruß hochsitzcola
Ok das sieht doch so aus als wenn die Chinesen das ganz gut gemacht hätten. die letzten 2 Bits scheinen zuwackeln du hast also gut 10Bit Auflösung, Mehr hat der VESC auch nicht. Läuft der Beobachter aus dem Paper schon?
Nein, ich suche mir gerade Startwerte für die Motorkonstanten zusammen. Darum ja auch die Frage nach einem sinnvollen Wert für die Flussverkettung... Ich hab auch grad noch keine Idee, wie ich den Winkel aus der Hall-Interpolation und den Winkel vom Beobachter zum Debuggen einigermaßen in Echtzeit sichtbar machen kann. DACs zur Ausgabe aufs Oszi hat der Prozessor nicht. Gruß hochsitzcola
Wenn du noch Platz im Controller hast kann ich dir FreeMaster empfehlen. Damit kannst du Werte im Regeltakt aufnehmen. Brauchst aber mindestens n Uart zum PC.
Hmm, UART zum PC habe ich schon, da kommen ja die gezeigten Plots her. Ich fürchte nur, wenn der Motor etwas mehr Drehzahl macht, ist UART zu langsam. Ich probier einfach aus, wie weit ich komme. Ich werde erst mal versuchen, die 360° in 255 steps auszugeben, dann muß ich pro Step nur zwei nackte Bytes übertragen. Gruß hochsitzcola
Du musst die werte doch gar nicht streamen! Der Freemaster macht z.b. einen Recorder shot von 600-100Punkten a 4 Werte. Un die übe trägt er dann hoch das läuft mit einem 115200 Uart ohne Probleme. Mir hat das immer gereicht.
Für die atan2-Funktion nutzt der VESC eine eigene Routine mit floating points. Ich habe in meiner Interrupt-Abarbeitung in PWM-Frequenz (16kHz) möglichst auf floating-points verzichtet und stattdessen die arm_xxx_q31 Funktionen benutzt. Der Winkel ist hier von -2^31 (-180°) bis +2^31 (+180°) definiert. Der Prozessor hat keinen externen Quarz und läuft mit "nur" 64 MHz. Eine arm_atan2_q31 gibt es leider nicht. Gibt es da einen Workaround für eine schnelle atan2 Berechnung ohne Fließkomma? Gruß hochsitzcola
Gut das du fragst:), Vergiss das atan2 geraffel. Das ist ungenau und unstetig das gibt nur Probleme. Du nimmst dir deine beiden Bemf Werte und drehst die genauso wie die Ströme ins Rotor Systemystem. Dann wird das zu einem konstanten Vektor. Davon regelst du dann den q Anteil auf 0 mit einer PLL. Der Winkel der PLL ist dann dein Winkel für das Rotor System.
Hm, Bahnhof? Die BEMF-Werte sind (in der Syntax vom VESC-Code):
1 | BEMF_alpha = *x1 - L_ia; |
2 | BEMF_beta= *x2 - L_iv; |
Und die dann per Park-Transformation unter Verwendung des Winkels aus dem vorherigen Schleifenlauf ins rotierende System bringen und dann?! Das mit der PLL-Regelung verstehe ich nicht. Gibt es da ein Code-Beispiel?! Gruß hochsitzcola
Genau du drehst die alpha beta Werte ins dq System mit der Drehmatrix die du auch für die Ströme genau in diesem Zyklus verwendet hast. Dann brauchst du was 4 bis 6 Takte dafür und nicht 30 wie für einen atan2. Wenn du jetzt einen d Strom > 0 einregelst und den Winkel deines Rotorsystems künstlich drehst muss der transformierte BEMF Vektor ungefähr auf den Q Achse liegen. Wenn das der Fall ist. kannst du jetzt die d Komponente des Vektors zu 0 regeln in dem du die d Komponente als Fehler in einen PI Regler gibst und den Ausgang das Regler der dann deine "Drehzahl" darstellt integrierst du. Der Integral ist dann dein Winkel für die Park. Das ist alles dann hast du eine PLL ohne dir um die Berechnung des Phasenfehlers sorgen zu machen.
wheelheels schrieb: > was hat denn der Bemf für eine Einheit? > > Gruss, > Wheelheels Das sollten Volt sein. Da die Werte aber bei ihm q31 sind hat das mit Volts nicht viel zu tun.
Alexander B. schrieb: > Wenn du jetzt einen d Strom > 0 einregelst ??? Sinn des FOC ist es doch id auf Null zu regeln?! Ich regel also BEMF_d zu Null und summiere den Regler-Output (der die Winkelgeschwindigkeit repräsentiert) über die Schleifenläufe auf. Der aufsummierte Wert ist gleich dem Winkel, durch den Variablenüberlauf muß ich mich um nichts weiter kümmern, er zählt halt immer brav von -2^31 bis +2^31. UiUiUi, bei so vielen Parametern/Konstanten die da eingehen, bin ich echt gespannt, ob das konvergiert. Die BEMF_d Regelung könnte auch außerhalb der Interrupt-Routine passieren, da die BEMF dann ja quasi ein konstanter Vektor ist ?! Mache ich für die Stromregelung ja auch schon so. Gruß hochsitzcola
hochsitzcola schrieb: > Alexander B. schrieb: >> Wenn du jetzt einen d Strom > 0 einregelst > > ??? Sinn des FOC ist es doch id auf Null zu regeln?! > > Gruß > hochsitzcola 1. nur für den Test des Subsystems. 2. id wird auf den Wert geregelt der gebraucht wird das sind auch werte != 0!!! hochsitzcola schrieb: > Die BEMF_d Regelung könnte auch > außerhalb der Interrupt-Routine passieren, da die BEMF dann ja quasi ein > konstanter Vektor ist ?! Mache ich für die Stromregelung ja auch schon NEIN!!! der Winkel muss immer in jedem Zyklus geupdated werden und du wirst die Bandbreite der PLL brauchen und willst die nicht künstlich langsamer laufen lassen. Der VESC wird oft auf hohe PWM Frequenzen gesetzt damit die PLL öfter läuft.
Alexander B. schrieb: > der Winkel muss immer in jedem Zyklus geupdated werden Ja, aufaddiern natürlich in jedem Zyklus, das Inkrement muß aber ja nicht zwangsläuftig jedes mal neu berechnet werden, wenn die Geschwindigkeitänderungen nicht besonders groß sind (sind sie ja beim E-Bike nicht) Ich fürchte für die Regelung werde ich um floats nicht herumkommen und das wird in Echtzeit nicht mehr klappen, darum hatte ich das ja schon bei der Stromregelung ausgelagert. Ob ich bei den ganzen Motorparametern mit Ganzzahlen auskomme weiß ich auch noch nicht :-( Gruß hochsitzcola
Warum? Du nimmst die halbe pwms Frequenz dann reicht die Zeit dicke. Oder baust du den Code noch mit O0? Nimm wenigstens Og. Die meisten alten Applikation Codes von ti sind komplett fixed. Normier die Werte auf sinnvolle zahlen und gut ist. Der f103 packt das schon. St hat es ja auch hinbekommen mit ihrem lib geraffel. Läuft wie ein Sack schrauben aber die Rechenzeit ist nicht das Problem. 8kHz Regelung und beobachten reicht für das E-Bike
Alexander B. schrieb: > Oder baust du den Code noch mit O0? Nimm wenigstens Og. Kannst du mir das mal übersetzen? Gruß hochsitzcola
hochsitzcola schrieb: > Alexander B. schrieb: >> Oder baust du den Code noch mit O0? Nimm wenigstens Og. > > Kannst du mir das mal übersetzen? > > Gruß > hochsitzcola Die Optimierungsstufe des Compilers. Beim GCC heißen die Stufen O0 keine Optimierung, Og für alle Optimierungen die das Debugging nicht beeinflussen, O1 für leichte Optimierung, O2 ist meist Standard, O3 nimmt keine Rücksicht auf die Code Größe und dann gibt's noch Os für die kleinste Code Größe. Für den GCC gibt's dann noch einige andere Optionen die ggf. sinnvoll sind.
OK, die Compilereinstellungen haben ich bisher gar nicht näher angeschaut. Das Projekt ist ja aus CubeMX automatisch erstellt worden, ich habe da nichts an den Default-Einstellungen geändert. Gibt es zu dem von dir beschriebenen Ansatz eigentlich irgendeine Literatur, in die ich mich einlesen kann? Gruß hochsitzcola
Puhhh CubeMX, warum nimmst du dann nicht die MCLib von ST?
Weil ich es von Grund auf verstehen will, was da passiert und keine BlackBox. In das Motor-Control-Tool habe ich ganz zu Anfang mal reingeschaut und es dann wieder sein lassen. CubeMX habe ich nur für das Grund-Setup benutzt. Für die ganzen Initialisierungen ist das echt hilfreich, wenn man nicht das Reference Manual auswendig lernen und auf Registerebene Bits schubsen will. Die HAL-Geschichte ist echt nicht selbsterklärend :-( Gruß hochsitzcola
Ok, sei aber vorsichtig mit den HAL Funktionen im Interrupt. So direkt Literatur kann ich dir nicht nennen, ich habe glaube ich über 200 Papers hier zu dem Thema. Ich kann dir da nur empfehlen viele Papers zu lesen. James Mevey https://core.ac.uk/download/pdf/5165531.pdf gibt z.B. einen guten überblick.
Der Ansatz selbst ist recht weit verbreitet. Und die Methode um den Atan2 los zu werden ich meine eigene Präferenz. Weil ich lieber alles im Rotor-System habe und so auch die Drehmatrix der Ströme weiter verwendet werden kann.
Angehängte Dateien:
-
Motormodell.PNG
26 KB
hochsitzcola schrieb: > BEMF_alpha = *x1 - L_ia; Wofür stehen eigentlich die Terme x1 und L*i_alpha. Das müssen ja beides Spannungen sein. x1 wird aus dem vorherigen Schleifenlauf aufaddiert, L*i_alpha jedes mal neu berechnet. Ich glaub mir fehlt doch das E-Technik-Studium ;-) Die allgemeine Formel im Anhang verstehe ich ja noch. http://edoc.sub.uni-hamburg.de/haw/volltexte/2014/2272/pdf/Abschlussarbeit.pdf Die Stelle ich nach der BEMF um, OK. Bei der Ableiterei bzw. Aufintegrierei hört dann mein Maschinenbauer-Hirn auf. Gruß hochsitzcola
// float x1_dot = -R_ia + v_alpha + gamma_tmp * (*x1 - L_ia) * err; // float x2_dot = -R_ib + v_beta + gamma_tmp * (*x2 - L_ib) * err; // *x1 += x1_dot * dt; // *x2 += x2_dot * dt; x1 und x2 sind Ausgänge der 2 Integratoren die x1_dot und x2_dot am Eingang haben. Siehe obige Gleichungen aus dem hingedängelten VESC Code. Zitat: // Iterative with some trial and error Vllt. ist das eine Struktuiertere Erklärung: https://community.nxp.com/thread/477109 Oder lies mal etwas bei Shane Colton, seines Zeichens Mechaniker genau wie du, vllt hilfts :) https://scolton.blogspot.com/p/motor-controllers.html Ich empfehle dir die Sektion Theory: Sensorless. Lies die bitte erst die Posts durch bevor du das WriteUp ließt dann verstehst du es besser was er da macht. Das ist zwar auch nur ein BEMF Beobachter aber auch der Funktioniert in Traktionsanwendungen. Wenn du dann noch weiter lesen willst google mal nach "PMSM Rotor Flux Observer", die sind dann noch robuster aber auch etwas komplizierter. Wenn du sowas wie SMO oder Sliding Mode Observer ließt dann ignoriere das bitte.
Danke für die Links! Ich denke, daß ich das Grundlegende verstanden habe. Ich hadere im Moment mit der Umsetzung im Code. Beim VESC gibt die Funktion observer_update ja direkt den beobachteten Winkel zurück. Nach deinem Tipp muß ich aber e_alpha und e_beta zurückgeben, um dann mit der Park-Transformation e_d im rotierenden Bezugssystem auf Null zu regeln... Gruß hochsitzcola
Genau. Du nimmst also allen Code außer die Zeile return util_atan2 bla. Und die Argumente des Atan2 sind die alpha Und Beta Werte.
Beitrag #5857779 wurde von einem Moderator gelöscht.
Jetzt habe ich es mal so implementiert, wie vorgeschlagen. Leider ist e_d beliebig am schwanken zwischen 2^-31 und 2^31. Da kann der Regler nix regeln. Für die Motorkonstanten habe ich erst mal Ganzzahlen angesetzt, da ich ja nur q31_t verwende, habe aber keine Ahnung in welcher Größenordnung ich die ansetzen soll. Die physikalischen Größen habe ich so grob ermittelt. Aber in welcher Zehnerpotenz die Sinn machen, das kann ich mir nicht herleiten :-( Gruß hochsitzcola
In welchem Betriebszustand schwanken die Werte beschreib Mal was du jetzt implementiert hast und wie du testest.
Ich habe nach wie vor Schwierigkeiten, die physikalische Bedeutung der einzelnen Terme zu deuten und habe damit auch kein Gefühl in welchem Zahlenbereich sie liegen müssen. Der Term err läuft immer ins Nirvana die Terme R*i_alpha, L*i_alpha, usw. sind in ihrer Größenordnung klar, die sind ja durch die von mir definierten Konstanten und die AD-Wandlerbreite begrenzt. v_alpha, v_beta sind auch klar, die sind ebenfalls durch die PWM-Periode und den AD-Wandlerwert für die DC-Rail-Spannung begrenzt. Wobei ich v_alpha und v_beta derzeit noch nicht auf die reale Spannung skaliere. Überall wo x1 bzw. x2 drinsteckt, konvergiert derzeit nichts, das läuft immer beliebig in den Himmel, egal ob der Motor im Leerlauf dreht oder unter Last (Winkel zur Kommutation kommt derzeit noch von den Halls) Der Code ist in einem Fork zu finden: https://github.com/stancecoke/LishuiFOC/tree/Sensorless Gruß hochsitzcola
Hm, da ich ja nur mit Ganzzahlen arbeite kann ich Gamma nicht kleiner 1 machen. Ich werde es mal mit "rigth shift gamma" versuchen statt mit "mal gamma" Gruß hochsitzcola
OK, 1. Verwendest du die Funktionen aus der arm-math.h zum Rechnen mit q31? 2. Ich glaube wir müssen die Differentialgleichungen Mal durch gehen in Bezug auf den Wertebereich. Da werde ich heute Abend Mal was zusammen schreiben Mal gucken hab ich so auch noch nicht gemacht, es gibt schon zu lange FPUs in den DSPs.
Ich muss jetzt erst noch mal einen Schritt zurück machen und die Terme in der gleichen physikalischen Größenordnungen berechnen, sonst wird das wohl nicht klappen.
1 | q31_t x1_dot = -R_ia + v_alpha + gamma_tmp * (*x1 - L_ia) * err; |
Die einzelnen Terme in dieser Zeile müssen ja alle Volt, Millivolt oder welche Spannungseinheit auch immer haben, Hauptsache immer die Gleiche. Gruß hochsitzcola
Angehängte Dateien:
-
BemfObsEq.png
2,4 KB
Irgendwie mag ich diese Gleichungen mit dem Dengelfaktor nicht. Sieh dir mal die angehängten Gleichungen aus diesem Link an: https://community.nxp.com/thread/477109 Ua sind hier V und bitte nicht PWM Duty. Das ist zu ungenau. Die Eingangsspannung schwankt einfach zu stark. Das sorgt nur für Winkelfehler. Ich würde die V zum Beispiel auf 50V normieren also 1 entspricht 50V. Dann kommt der Spannungsabfall über dem Widerstand. Ich weiß jetzt nicht deinen Max. Strom aber ich gehe mal großzügig von 50A aus. Den Wicklungswiderstand würde ich mit ca. 100-200mOhm bei einem Ebike motor an nehmen also kannst du den Rs auf 1Ohm normieren. Somit wäre für diesen Term die Skalierung auf 50V => 50A*1Ohm = 50V, das passt schon mal ganz gut ohne Umrechnung. Die Ableitung des Stromes mit der Induktivität wird jetzt etwas schwieriger. Eine typische Induktivität eines EBike Motors nehme ich mal mit 200-500µH an. Somit würde ich mal 1mH als Skalierung wählen. Für di/dt würde ich bei den 50A bleiben. Dann kannst du einfach die Differenz der bereits skalierten Stromwerte bilden. Somit haben wir 1mH*50A/T wobei T = 1/f ist. Du hattest ja 16kHz PWM also nehmen wir mal 8kHz Regelung an und somit 125µs für T. macht also 1mH*50A/125us = 400V, da du aber auf 50V runter müsstest sollte man vorskalieren. Die Differenz der Strome wird Erwartungsgemäß deutlich kleiner sein als 50A/125us. Folglich könntest du die Differenz der Ströme mal 8 nehmen, bzw. shiften. Dann bist du wieder bei 50V=1 in q31. Somit ist dann die BEMF auf 50V skaliert. Damit solltest du dann weiter arbeiten können.
Erst mal ein dickes Danke für deine Geduld :-) Ich zweifel grad an meinem Grundsetup mit Hallsensoren. i_alpha und i_beta müssten ja näherungsweise den gleichen Winkel im stationären Koordinatensystem bilden wie u_alpha und u_beta. Haben sie aber nicht. Ich hatte mich schon immer gefragt, warum ich bei der inversen Park mit einem invertierten Sinus-Wert arbeiten musste. Der Winkel des Stroms läuft sozusagen vorwärts und der der Spannung rückwärts. Der Motor läuft so aber an den Hallsensoren wunderbar. Mit vertauschten Phasen habe ich ihn nicht vernünftig ans Drehen bekommen. Ich fürchte, das muß ich erst lösen, sonst kann die sensorlose Ansteuerung nicht funktionieren :-( Gruß hochsitzcola
Kein Ding. Diese Fehler sind selbst kommerziellen BLDC Treibern drin. Prüfe bitte Mal einzeln die zu Ordnung von pwm zu Strom Sensor. Also 10% duty auf einer Phase und die anderen auf 0. Und n paar Meter Kabel Aufwickeln als Spüle dann nur die Test Phase mit vllt der ohne Strommessung verbinden. Dann muss der richtige ADC wert was anzeigen und ganz wichtig es muss ein positiver Wert sein! Oft liegt hier der Fehler.
hmm, die Zuordnung von Phase zu Sensor passt, allerdings ist der Ausschlag negativ. Gruß hochsitzcola
Dreh dann Mal das Vorzeichen deiner Ströme. Das sollte schon reichen.
Angehängte Dateien:
Hm, ich krieg so langsam die Pimpernellen :-) Ich habe es jetzt so weit, daß die Winkel zueinander passen sollten. Ich habe zum debuggen doch erst mal die atan2 Funktion asyncron benutzt, um mir die Winkel des Stroms und der PWM-Spannung im Vergleich zu den Winkel aus den Hall-Sensoren anzuschauen. Strom und Spannung sind einigermaßen in Phase, der Hall-Winkel eilt aber ca. 90° nach ?!. Den Beobachter bekomme ich immer noch nicht stabil, die Werte springen immernoch scheinbar vollkommen willkürlich :-( Gruß hochsitzcola
Moin 90° nacheilend ist völlig korrekt. Die Halls messen das Magnetfeld und der Strom muss 90° voreilen damit die Maschine sich dreht. Also alles ok. Dann gehe die Teile der Formel einzeln durch. Also alles raus bis auf R*i und dann stück für stück teile der Formeln weiter dazu. Dann kannst du sehen welcher teil der Formel problematisch ist.
Also wenn ich mir atan2(-R_ia + v_alpha,-R_ib + v_beta) ausgeben lasse, kommt ein um ca. 180° zum Strom verschobener Winkel raus. Das scheint also noch irgendwie zu passen. Vollkommen wirr wird es immer, sobald x1 oder x2 in Spiel kommen :-( Gruß hochsitzcola
Ok. Lassen wir Mal diesen komischen Beobachter vom VESC ich mag den nicht. Lies dir Mal bitte das angehängte PDF durch speziell den Abschnitt ab Seite 45. Dort wird ein robuster Rotorfluss Beobachter mit Rückkopplung beschrieben.
Hm, ich hab mich jetzt so in diesen Ansatz reingekniet, ich werde erst mal versuchen, das anhand von Zahlenbeispielen in Excel nachzurechnen. Ich hoffe das ich dann verstehen werde, warum das im Moment nicht konvergiert. Den Anhang von dir hab ich mir kurz angeschaut, ich muß zugeben, daß ich grad keine Lust habe, wieder von vorn anzufangen :-( Gruß hochsitzcola
Ok, ich hab mit dem Beobachter bisher nur wenig Erfahrung.
ich hab das jetzt in Excel ausprobiert und einen Wert für Gamma gefunden, mit dem es für ein Beispiel konvergiert, wenn auch der iterierte Winkel um 180° zum Eingangswinkel verdreht ist: https://onlinegdb.com/By64VObAE Im richtigen Code mit laufendem Motor funktioniert es leider immer noch nicht. Der Winkel aus atan2(e_beta/e_alpha) springt nun immer zwischen zwei mehr oder weniger konstanten Werten hin- und her. Gruß hochsitzcola
Angehängte Dateien:
Doch noch ein Lichtblick :-). Wenn ich x1 und x2 bei jedem Interrupt erst mal wieder auf Null setze und dann neu iteriere funktioniert es. Warum auch immer. Gruß hochsitzcola
Das Erklärt diese komische Implementierung im VESC. Das ist im Wesentlichen ein Filter für das Winkelsignal. Die Abweichung von 90° ist okay. Weil der Beobachter die Bemf ermittelt und die Halls den Fluss messen. Dein Strom müsste jetzt mit der Bemf in Phase sein.
Na ja, der beobachtete Winkel läuft 90° nach dem Hall-Winkel, ist also 180° phasenverschoben zum Strom. So lange das konstant ist, soll's mich nicht stören. Die 180° muss ich dann halt auf den Winkel draufaddieren, der sich aus der e_d = 0 Regelung ergibt. Oder ich gebe gleich die invertierten Werte von e_alpha und e_beta in die Park-Transformation. Aber nicht mehr heute. Bin mal gespannt :-) Gruß hochsitzcola
Ich geb so langsam auf :-( Bei der jetzigen Implementierung gibt es ein merkwürdiges binäres Verhalten. Ist das Verhältnis von i/u groß genug, hinkt der Beobachter-Winkel 90° nach, der Wert von u ist dann komplett egal, kann im Winkel sogar total verdreht sein, spielt keine Rolle. Wird u größer, kippt das Ganze irgendwann plötzlich, der Beobachter-Winkel eilt dann 90° vor und es ist ganz egal was man für i einsetzt. Da kann man mit dem online C-Compiler schön mit rumspielen. Gruß hochsitzcola
In deinem onlinegdb Code fehlte aber jegliches Motor Modell. Das ganze ist kein Thema das man in 5min verstanden hat. Es hilft nur lesen. Ich lege dir nochmal die Diss, die ich verlinkt habe ans Herz. Aber grundsätzlich wird es nix dem Beobachter mit irgendwelchen Werten zu füttern, die Physik muss sich in den Werten schon wieder spiegeln. Ich hab für den VESC vor kurzem ein Motormodell geschrieben. Das solltest du in zu deinem Test hinzufügen. http://cpp.sh/33vcz Beispiel Code. Hier der pull request. https://github.com/vedderb/bldc/pull/82#issuecomment-480506937
Das Strom und Spannung über die physikalischen Eigenschaften des Motors zusammenhängen ist mir schon klar. Das oben beschriebene Phänomen tritt aber beim unter Last laufenden Motor mit echten Messwerten 1:1 genauso auf. Gruß hochsitzcola
Ein Problem könnte sein dass der Motor nur über die Halls läuft und somit der eigentliche elektrische Winkel sehr stark schwingt. Du musst von +-60° ausgehen. Außerdem ist atan eher suboptimal. Implementiere Mal die PLL die dämpft die Störungen des Bemf Beobachters. Bei wie viel % der Nenndrehzahl machst du die Tests? Bist du sicher das die Parameter passen und Strom und Spannung korrekt skaliert ist? Denk daran das der Motor nur 1/sqrt(3) als max Spannung auf einem Strang sieht. Bzw. +-50% und nicht 0-100% pwm.
Ich denke im Moment, daß ich noch einen Bock in der Skalierung der Größen in den ganzzahligen Bereich habe. Das kann ich aber jetzt mit deiner Kommentierung im Beispielcode besser nachvollziehen. Danke dafür :-) ggf. gehe ich noch mal mit der Frequenz runter und probiere es doch mit floats. Gruß hochsitzcola
Meine Überlegung: Motorwerte: L = 1200µH = 0,0012 H R = 350 mOhm = 0,35 Ohm Psi = 0,666 V*s/rad Ich müsste also alle Werte mal 10.000 nehmen um auch den kleinsten Wert in den Ganzzahlbereich zu bekommen. Dann die Messwerte von Strom und Spannung ebenfalls *10^5 einsetzen. Wenn ich dann einen Phasenstrom von 100A annehme, bekomme ich allein für den Term R*i schon einen Überlauf einer q31 Variable :-( Also werde ich wohl doch mit floats rechnen müssen. Gruß hochsitzcola
wow, der Prozessor ist mit floats echt überfordert. Ich muß die FOC-Update-Frequenz auf 2kHz herunternehmen und kann dann nicht mal pro Aufruf mehrfach iterieren ... Sinnvolle Werte spuckt der Beobachter immer noch nicht aus :-( Gruß hochsitzcola
Der hat ja auch keine FPU, der muss das alles in Software machen dafür braucht er dann gut Faktor 100 länger als für integer. Was kommt den raus wenn du nur -ua + R*ia und ub - R*ib rechnest? Sieht das plausibel aus?
Angehängte Dateien:
Ich hatte noch ein paar kleine Bugs in der Umrechnung der Konstanten. Die Werte sehen jetzt plausibel aus und es kommen auch sinnvolle Winkelwerte raus. Allerdings hat der Verlauf des beobachteten Winkels jetzt einen "Bauch". Kann das an nicht exakten Werten der Motorkonstanten liegen? Die Phasenverschiebung ändert sich mit dem Wert von Gamma. Ich habe für Gamma nach einigem rumprobieren einen Wert von 3000 eingestellt. Ich überlege noch, ob ich probiere mit long long int zu arbeiten, mit den floats bleibt selbst 2kHz kaum noch Zeit für was anderes... Gruß hochsitzcola
Super! Der Bauch kann verschiedenste Ursachen haben. Wenn die Drehzahl nicht konstant ist dann liegt der Winkel natürlich nicht auf einen geraden. Dein Hallwinkel scheint aber auch einen Bauch zu haben bzw. am oberen Ende einen Versatz. Ein anderer Grund kann die BEMF Form des Motors selbst sein. Gerade bei billig gebauten Motoren sind oft die 3. 5. usw. Oberwelle sehr präsent. Die Machen den Unterschied zwischen einen Trapezformigen BEMF (Ideal für Blockkomutierung) und einer Sinusförmigen BEMF(Ideal bei FOC) 99% der Motoren die ich kenne liegen irgend wo dazwischen. Das der Beobachter vom VESC alles andere als genau ist hatte ich dir ja schon gesagt, aber er funktioniert relativ robust im VESC. Als nächstes könntest du ja mal die Winkel durch ein Offset die Winkel angleichen und dann auf den Beobachterwinkel umschalten.
Der Unstetigkeiten im Hall-Winkel-Verlauf kommen aus dem überladenen Prozessor. Die UART-Übermittlung wird in der Hauptschleife angestoßen, die wird vor lauter Interrupt-Abarbeitung mit den floats nicht mehr regelmäßig ausgeführt. :-( Ich werde noch mal Hall-Winkel gegen Beobachter-Winkel auftragen, vielleicht ist der "Bauch" nur ein Artefakt der nicht äquidistanten Stützstellen auf der Zeitachse. Gruß hochsitzcola
Angehängte Dateien:
Nachdem ich immer noch auf keinen grünen Zweig gekommen bin, habe ich mal 200 Werte für I_alpha und I_beta während des Laufes unter Last in ein Array geschrieben und dann ausgelesen. Irgendwas ist da noch im Argen. Ich werde wohl noch mal direkt die ADC-Wandler Werte loggen müssen, um zu sehen ob das schon an den Messwerten liegt oder an der Clarke-Transformation :-( Gruß hochsitzcola
Jetzt bist du im Hasenbau :), all diese kleinen Schnitzer in der Hardware oder der Rechnung zu finden ist sehr Zeit aufwendig. Aber du kommst doch vorran, sieh es positiv!
Angehängte Dateien:
-
current_sampling_case_3.PNG
100 KB
Ich überlege gerade, ob es Sinn macht, die Strommessung erst mal wieder statisch von immer den selben zwei Phasen zu machen, auch wenn damit keine sehr hohen Tastverhältnisse realisierbar sind. Der Prozessor hat nur zwei ADCs und aktuell schalte ich die je nach aktuellem Sektor auf die zwei Phasen mit dem geringeren Tastverhältnis. Bei ganz hohen Tastverhältnissen schiebe ich dann den Trigger zum Auslösen der Strommessung vor das Abschalten der Highside der Phase mit dem höchsten Tastverhältnis, so wie es im Paper von ST beschrieben steht. https://www.st.com/content/ccc/resource/technical/document/user_manual/5e/5e/d2/cb/07/35/45/a6/CD00298474.pdf/files/CD00298474.pdf/jcr:content/translations/en.CD00298474.pdf Ich fürchte, diese Hin- und -Herschalterei ist der Stabilität des Beobachters nicht förderlich. Gruß hochsitzcola
Das kann sein muss aber nicht. Grundsätzlich musst du dabei bedenken dass durch die Stromsteigung eine Verschiebung ein Offset der Strommessung bedeutet. Das führt also zu mehr rauschen. Ich Frage mich aber warum machst du das? Sample einfach in der Mitte der lowside on time wie alle anderen auch. Und eine pwm kleiner 5% und Größer 95% lässt du nicht zu. Wenn du eine normale SVM verwendest entspicht 000 auf allen Phasen 50% pwm. Du limitierst damit also nur deine enddrehzahl. Wenn der Beobachter in dem Bereich sauber arbeitet dann kannst du anfangen die Grenzen auszuloten. @edit: Autokorrektur....
Alexander B. schrieb: > Sample einfach in der Mitte der > lowside on time wie alle anderen auch. So habe ich ja erst gemacht, bei hohen Tastverhältnissen (jedoch deutlich kleiner 95%) fängt die Strommessung so an, Mist zu messen... Darum habe ich es wie bei dem ST-Paper beschrieben umgebaut. siehe auch im Pedelecforum: https://www.pedelecforum.de/forum/index.php?threads/open-source-firmware-f%C3%BCr-lishui-controller.61113/post-1169767 Gruß hochsitzcola
Thread beobachten
Seitenaufteilung abschaltenBitte 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.