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?
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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
:
Bearbeitet durch User
Ä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:).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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....
:
Bearbeitet durch User
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.