Brushless Gimbal Controller - SOFTWARE
- Themenstarter Lonestar78
- Beginndatum
- Status
Hallo, hab gestern Abend ein wenig versucht Passende Werte für meine Motoren zu finden, allerdings mit mäßigem Erfolg. Mir fehlt ein wenig die Ideale Vorgehensweise. Habe einen 22p24n Motor nochmal 1/2 untersetzt. Müsste ich dann in der GUI die Anzahl der Pole auf 44 idealer weise Setzten? Wie gehe ich am besten vor. P I und D auf null stellen. P solange erhöhen bis es schwingt, D erhöhen bis es weg ist und I bei bedarf nachstellen.??? Wie geht ihr da for? wie kann ich mich am besten an die Einstellungen heranfühlen?
Ich habe es bisher in etwa so gemacht:
P der Achse die ich gerade nicht einstelle auf P=1 stellen, ACC auf 0.0001 stellen, Max PWM der jeweiligen Achse so einstellen das die Kamera beim bewegen des Gimbals gerade so gehalten werden kann.
Dann ausgehend von der Standardconfig P der Achse an der du arbeitest erhöhen. Wenn sich die Achse dann aufschwingt bzw. starke Vibrationen zu merken sind dann D der jeweiligen Achse langsam hoch bis die Vibrationen verschwinden.
Dann P weiter erhöhen bis der Winkel passt und ggf. D nochmal erhöhen.
Bei der zweiten Achse das gleiche.
I musste ich bisher nie anheben .... merke da aber auch keinen Unterschied.
Im Anschluss ACC etwas anheben, im Handtest macht das wenig Sinn. Am besten diesen Wert erfliegen.
PS: ich denke dass du irgendwo bei P = 70 auf Nick und P= 150 auf Roll landen solltest.
Viele Grüße
Henry
P der Achse die ich gerade nicht einstelle auf P=1 stellen, ACC auf 0.0001 stellen, Max PWM der jeweiligen Achse so einstellen das die Kamera beim bewegen des Gimbals gerade so gehalten werden kann.
Dann ausgehend von der Standardconfig P der Achse an der du arbeitest erhöhen. Wenn sich die Achse dann aufschwingt bzw. starke Vibrationen zu merken sind dann D der jeweiligen Achse langsam hoch bis die Vibrationen verschwinden.
Dann P weiter erhöhen bis der Winkel passt und ggf. D nochmal erhöhen.
Bei der zweiten Achse das gleiche.
I musste ich bisher nie anheben .... merke da aber auch keinen Unterschied.
Im Anschluss ACC etwas anheben, im Handtest macht das wenig Sinn. Am besten diesen Wert erfliegen.
PS: ich denke dass du irgendwo bei P = 70 auf Nick und P= 150 auf Roll landen solltest.
Viele Grüße
Henry
Zuletzt bearbeitet:
Ja - die Untersetzung ist Schuld an den hohen P Werten. Ich hatte damals so meine Schwierigkeiten da die Software nur bis 32 ging und ich höher gehen musste.
P=20 finde ich jetzt sehr niedrig. Ich habe mich aber auch schon sehr oft im Flug gemerkt das die Werte noch deutlich zu gering waren.
Kannst uns ja mal ein Video zur Analyse zeigen - das hilft bestimmt auch ;-)
Viele Grüße
Henry
P=20 finde ich jetzt sehr niedrig. Ich habe mich aber auch schon sehr oft im Flug gemerkt das die Werte noch deutlich zu gering waren.
Kannst uns ja mal ein Video zur Analyse zeigen - das hilft bestimmt auch ;-)
Viele Grüße
Henry
im Ernst?
i) wenn die Schaltverluste dermassen wären dass nur noch der halbe Strom fliesst (Driver-Wirkungsgrad <50%) dann würde da einiges zum Kochen kommen
ii) defaultmässig wird die phase korrekt PWM genommen, das sind 31.25kHz, laut Datenblatt ist der L6234 für 50kHz gut...
(ich tippe eher auf svm)
i) wenn die Schaltverluste dermassen wären dass nur noch der halbe Strom fliesst (Driver-Wirkungsgrad <50%) dann würde da einiges zum Kochen kommen
ii) defaultmässig wird die phase korrekt PWM genommen, das sind 31.25kHz, laut Datenblatt ist der L6234 für 50kHz gut...
(ich tippe eher auf svm)
300nS Cross Conduction Protection
Mit Verlust hat das also erstmal wenig zu tun.
Ist halt so bei dem Treiber... Der schützt sich selbst vor der Programmierwut der Softies
Dafür ist es eine "einfache Lösung" fertige Treiber zu verwenden.
Wenn man nicht will das die Brücken jedes mal, also auch beim PWM diese 300nS machen, muss man sie sich selbst aufbauen und auch ansteuern Da kann mann also dann auch den ein oder anderen Kurzschluss programmieren LOL
http://www.st.com/st-web-ui/static/...ical/document/application_note/CD00004062.pdf
Mit Verlust hat das also erstmal wenig zu tun.
Ist halt so bei dem Treiber... Der schützt sich selbst vor der Programmierwut der Softies
Dafür ist es eine "einfache Lösung" fertige Treiber zu verwenden.
Wenn man nicht will das die Brücken jedes mal, also auch beim PWM diese 300nS machen, muss man sie sich selbst aufbauen und auch ansteuern
Da kann mann also dann auch den ein oder anderen Kurzschluss programmieren LOLhttp://www.st.com/st-web-ui/static/...ical/document/application_note/CD00004062.pdf
am Ende doch... in dieser Zeit schalten die Fets um, d.h. haben vergleichsweise hohen Widerstand, d.h. RI^2 ist gross => Schaltverluste... es hätte nur dann wenig mit den Schaltverlusten zu tun wenn die Fets erheblich schneller schalten würden als diese 300 ns, aber dann wäre das auch Quatsch weil es ja keine Schaltverluste kosten würde die Zeit kürzer zu wählen aber die PWM würde besser, d.h. man wird immer versuchen diese Zeit so kurz wie möglich zu wählen, und wir können davon ausgehen dass die ST Leute das auch versucht haben...
ich zweifle nicht an dass bei der hohen PWM die Motoren bereits schwächer werden... ein bischen... ich bezweifle allerdings ganz schwer dass der Strom dadurch um nen Faktor 2 abnimmt wie smuggler berichtete, und sich daher so der Unterschied zwischen BruGri und AlexMos erklären liesse... IMHO völlig klar die falsche Fährte
(stellt euch das nur mal vor, um von 0.8A auf 0.4A zu kommen, müsste beim BruGri der Motor für 50% der Zeit ausgeschalten sein... für 16us...)
(mir scheint es nicht unnützlich den wirklichen Grund rauszufinden... ich meine, wie soll BruGri sonst besser werden?)
ich zweifle nicht an dass bei der hohen PWM die Motoren bereits schwächer werden... ein bischen... ich bezweifle allerdings ganz schwer dass der Strom dadurch um nen Faktor 2 abnimmt wie smuggler berichtete, und sich daher so der Unterschied zwischen BruGri und AlexMos erklären liesse... IMHO völlig klar die falsche Fährte
(stellt euch das nur mal vor, um von 0.8A auf 0.4A zu kommen, müsste beim BruGri der Motor für 50% der Zeit ausgeschalten sein... für 16us...)
(mir scheint es nicht unnützlich den wirklichen Grund rauszufinden... ich meine, wie soll BruGri sonst besser werden?)
am Ende doch... in dieser Zeit schalten die Fets um, d.h. haben vergleichsweise hohen Widerstand, d.h. RI^2 ist gross => Schaltverluste... es hätte nur dann wenig mit den Schaltverlusten zu tun wenn die Fets erheblich schneller schalten würden als diese 300 ns, aber dann wäre das auch Quatsch weil es ja keine Schaltverluste kosten würde die Zeit kürzer zu wählen aber die PWM würde besser, d.h. man wird immer versuchen diese Zeit so kurz wie möglich zu wählen, und wir können davon ausgehen dass die ST Leute das auch versucht haben...
ich zweifle nicht an dass bei der hohen PWM die Motoren bereits schwächer werden... ein bischen... ich bezweifle allerdings ganz schwer dass der Strom dadurch um nen Faktor 2 abnimmt wie smuggler berichtete, und sich daher so der Unterschied zwischen BruGri und AlexMos erklären liesse... IMHO völlig klar die falsche Fährte
(stellt euch das nur mal vor, um von 0.8A auf 0.4A zu kommen, müsste beim BruGri der Motor für 50% der Zeit ausgeschalten sein... für 16us...)
(mir scheint es nicht unnützlich den wirklichen Grund rauszufinden... ich meine, wie soll BruGri sonst besser werden?)
ich zweifle nicht an dass bei der hohen PWM die Motoren bereits schwächer werden... ein bischen... ich bezweifle allerdings ganz schwer dass der Strom dadurch um nen Faktor 2 abnimmt wie smuggler berichtete, und sich daher so der Unterschied zwischen BruGri und AlexMos erklären liesse... IMHO völlig klar die falsche Fährte
(stellt euch das nur mal vor, um von 0.8A auf 0.4A zu kommen, müsste beim BruGri der Motor für 50% der Zeit ausgeschalten sein... für 16us...)
(mir scheint es nicht unnützlich den wirklichen Grund rauszufinden... ich meine, wie soll BruGri sonst besser werden?)
Da hast Du nun was nicht verstanden...
Das ist das Gap zwichen abschalten der Low und einschalten der High seite, bzw umgekehrt...
Das einzige was Verluste macht ist die Anzahl der Schaltspiele, da ist aber "Wirkungsgrad" bei den hier benötigten 100-300mA eigentlich fast egal.
Der RDSon = 0.3 Ω ist da viel schlimmer... aber bei unseren Anforderungen auch nicht wirklich.
Hier mal das Datenblatt, bevor noch mehr Fragen kommen
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/CD00000046.pdf
Um es kurz zu machen, die Software hat wirklich keine Schuld
1) wir sind uns (hoffentlich) einig, dass die "Schaltverluste" diejenigen Verluste bezeichnet, die beim Umschalten der Fets (und evtl Dioden) in den low-high oder umgekehrt bezeichnet
[] ja
[] nein
2) wir sind uns (hoffentlich) einig, dass es die Umschaltzeit der Fets (und evtl Dioden) ist welche die Frequenz der PWM nach oben hin begrenzt
[] ja
[] nein
3) wir sind uns (hoffentlich) einig, dass es günstiger ist die Totzeit beim Umschalten möglichst klein zu wählen (bedenke, das ist keine Kommutierung wie beim "normalen" BLDC)
[] ja
[] nein
bitte beantworte einfach diese Fragen mit ja/nein, ich denke dann kommen wir sicher schnell zusammen
[] ja
[] nein
2) wir sind uns (hoffentlich) einig, dass es die Umschaltzeit der Fets (und evtl Dioden) ist welche die Frequenz der PWM nach oben hin begrenzt
[] ja
[] nein
3) wir sind uns (hoffentlich) einig, dass es günstiger ist die Totzeit beim Umschalten möglichst klein zu wählen (bedenke, das ist keine Kommutierung wie beim "normalen" BLDC)
[] ja
[] nein
bitte beantworte einfach diese Fragen mit ja/nein, ich denke dann kommen wir sicher schnell zusammen
ja
ja
ja, nein, bzw bedingt... Totzeit ist eigentlich völlig egal bei einem Motor, der sich fast nicht dreht
Aber sag das mal dem hier verwendeten Treiber
Also:
Bei normalen BLDC´s wird eine Phase voll geschaltet und die gegenseite PWM Moduliert, das geschieht bei P/N FET Kombinationen sinniger Weise auf den N-FET, da diese in der Regel schneller schalten und geringere Innenwiedersand haben.
Somit kann man im PWM Betrieb mit triggern eines FET auskommen.
Dieser hier verwendete Treiber hat diese Möglichkeit der Einzelansteuerung nicht
Der Treiber hier macht ja alles intern selbst.
Dieser Treiber wird im PWM jedesmal komplett ein und aus geschaltet und somit sichert er sich auch jedesmal mir seinen 300nS ab.
Somit hast Du Schaltverzögerungen, was nicht verlust bedeuten muss
Die Schaltverzögerungen werden eben um so größer, je öfter man pro Sekunde schaltet...
Das ergibt natürlich ein Delay, was aber nicht bedeutet das es 50% Verlust sind
300mA über den Treiber und 300mA Verlust, da würde der ziemlich heiß nach kurzer Zeit
ja
ja, nein, bzw bedingt... Totzeit ist eigentlich völlig egal bei einem Motor, der sich fast nicht dreht
Aber sag das mal dem hier verwendeten Treiber
Also:
Bei normalen BLDC´s wird eine Phase voll geschaltet und die gegenseite PWM Moduliert, das geschieht bei P/N FET Kombinationen sinniger Weise auf den N-FET, da diese in der Regel schneller schalten und geringere Innenwiedersand haben.
Somit kann man im PWM Betrieb mit triggern eines FET auskommen.
Dieser hier verwendete Treiber hat diese Möglichkeit der Einzelansteuerung nicht
Der Treiber hier macht ja alles intern selbst.
Dieser Treiber wird im PWM jedesmal komplett ein und aus geschaltet und somit sichert er sich auch jedesmal mir seinen 300nS ab.
Somit hast Du Schaltverzögerungen, was nicht verlust bedeuten muss
Die Schaltverzögerungen werden eben um so größer, je öfter man pro Sekunde schaltet...
Das ergibt natürlich ein Delay, was aber nicht bedeutet das es 50% Verlust sind
300mA über den Treiber und 300mA Verlust, da würde der ziemlich heiß nach kurzer Zeit
da haben wir also den ersten Unterschied: das Verhältniss zu An und Auszeit bestimmt die (mittlere) Spannung und (insb. wenn der Motor sich kaum dreht) den Strom. Durch die Totzeit wird der Strom und damit das Drehmoment niedriger als ohne Totzeit... ergo, wenn es darum geht maximales Drehmoment zu erhalten, muss die Antwort hier ja lauten.
=>
3) wir sind uns jetzt hoffentlich einig, dass es günstiger ist die Totzeit beim Umschalten möglichst klein zu wählen
[] ja
[] nein
EDIT: ich füge noch hinzu
4) wir sind uns (hoffentlich) einig dass der L6234 nach der Totzeit von diesen 300ns vollständig umgeschalten hat
[] ja
[] nein
Zuletzt bearbeitet:
- Status
