Hallo zusammen,
für ein aktuelles Projekt wird ein BLDC-Kontroller benötigt. Die
Anforderungen sind unter anderem eine Drehzahlregelung bis 50.000rpm,
Soft-Start und Betrieb eines sensorlosen BLDC-Motors. Hierzu muss ich
eine entsprechende Hardware aufbauen. Mein Hauptproblem ist nun die
Auswahl eines passenden Mikrocontrollers. Die Hauptanforderung an den
Controller ist, dass es sich um einen Cortex-M3 handelt, da hierfür
schon die komplette Toolchain (IDE, Debugger, etc.) vorhanden ist. Des
Weiteren wäre eine CAN-Schnittstelle wünschenswert – einen zusätzlichen
externen CAN-Controller (wie z.B. den MCP2515) würde ich aus Platz- und
Kostengründen gerne vermeiden.
In den letzten Tagen habe ich mich im Netz umgesehen und mir einige
Möglichkeiten angesehen:
Als erstes sind hier die STM32F100/STM32F103 von ST. Erstens weil ich
mit den Controllern schon Erfahrung habe und zweitens weil es von ST
hierfür eine „Motor control firmware“ gibt
(http://www.st.com/internet/com/SALES_AND_MARKETING_RESOURCES/MARKETING_PRESENTATIONS/PRODUCT_PRESENTATION/stm32_motor_control_firmware_library_marketing_pres.pdf).
Allerdings habe ich bisher noch keine großen Erfahrungen im Bereich
BLDC-Motoren, so dass ich noch nicht beurteilen kann, ob die ST-Firmware
was taugt. Auch konnte ich bisher nicht rausfinden ob die Controller
bzw. die Firmware einen Betrieb (vorzugsweise mit FOC) bis 50.000RPM
ermöglichen.
Als nächstes habe ich das Motor-Eval-Kit „Motor RDK“ von TI gefunden.
Dieses Kit basiert auf einem Stellaris LM3S8971 und würde im Groben und
Ganzen meine Anforderungen erfüllen. In der Dokumentation steht hier
auch das ein Betrieb bis 60.000RPM möglich ist. Allerdings ist der
LM3S8971 relativ groß und teuer. Allerdings habe ich bei TI auch den
deutlich günstigeren LM3S2276 gefunden, dieser sollte auch genug
Leistung für meine Anwendung haben, oder habe ich dabei was übersehen.
Die dritte Möglichkeit, die ich gefunden habe ist die TMPM370er-Serie
von Toshiba, hier vor allem der TMPM374, da dieser schön kompakt ist.
Vorteil: Der Controller hat eine Vector-Einheit zur Motorsteuerung in
Hardware.
Nachteil: Keine CAN-Schnittstelle (nicht mal I2C).
Ein zusätzliches Problem ist, das man den Controller bisher wohl nur als
Engineering-Sample bekommt. Mein Distri meinte, ich könnte
Übergangsweise auf die 350er-Serie gehen. Da diese Controller inzwischen
verfügbar seine – ich konnte im Netz aber nichts dazu finden. Dazu
kommt, dass die 350er Automotive spezifiziert sind und damit deutlich
teurer als die Lösung mit dem 374er. Mit den Samples und den verfügbaren
Eval-Boards könnte ich mit der Entwicklung anfangen und auf den
Serienstart der 374er (Ende des Jahres?!) hoffen, oder ist das zu
riskant? Hat jemand von euch Erfahrung mit Toshiba? Halten die ihre
Versprechen bezüglich Verfügbarkeit ein? Bei Atmel würde ich mich
garantiert nicht darauf verlassen.
Was meint ihr, welche Controller-Familie soll ich nehmen? Im Moment
tendier ich zu den STM32, da ich mit denen schon Erfahrung habe und man
hier die Controller bezüglich Speicher und Features schön hoch und
runter skalieren kann bei gleichem Pinning. Allerdings habe ich da noch
Bauchschmerzen, ob damit 50.000RPM möglich sind. Bei den anderen beiden
Lösungen habe ich entsprechende Angaben gefunden (TI 60.000RPM / Toshiba
>100.000RPM).
Oder habe ich die beste Lösung bisher komplett übersehen.
Würde mich sehr freuen wenn ihr mir helfen könntet
Gruß
Joe
die LPC von NXP haben auch eine BLDC Unterstützung. Wie gut die ist
weiss nicht, habe damit noch nichts gemacht. CAN Interface haben von den
LPC auch einige.
Ein spezielles Board für Motor-Controller Anwendungen bietet z.B. EA an:
http://www.embeddedartists.com/products/lpcxpresso/xpr_motor.php
Also ich habe mal den Workshop zum M374 bei Glyn mitgemacht und habe
auch 5 Exemplare des M374 zum Preis von ca. 2.50€ von Glyn erhalten (ca.
2 Wochen Waretzeit). Ob 1000 auch in 2 Wochen lieferbar gewesen wären?
Keine Ahnung. Die Aussagen zum Workshop waren: Ja. Ich glaube 60.000RPM
mit FOC wird wohl ehr nicht möglich sein. Das sind ja bei einem! Polpaar
schon 1KHz. Wieviel hat deiner? Wenn da über die PWM der Sinus noch
halbwegs abgebildet werden soll, liegst du bei Zeiten die wohl ehr
unrealistisch sind. Dann ist die Frage ohnehin zu stellen ob bei dem
Motor eine Sinus-Kommutierung überhaupt sinnvoll ist. Der Aufwand aus
den Phasenströmen dann noch die Back-Emf zu errechnen ist alles andere
als einfach.
Der M374 ist eigentlich auf der einen Seite durch die Vektoreinheit sehr
interessant, andererseits durch den spartanischen Rest nicht
unproblematisch. Da müssen 10K Ram reichen und es kommen da schon
Zweifel auf, wenn bei der Demo-Software zum Workshop ständig an den
Stackeinstellungen der FreeRTOS-Tasks geschraubt wurde, damit das noch
irgendwie passte. Wenn der M374 nur für den Motor zuständig ist, ist das
sicher kein Problem. Die ganze Waschmaschine wird aber eine Nummer zu
groß. Dass der Chip mit 5V läuft ist sicher im Motorumfeld nicht
verkehrt. Beachtet werden muss aber, dass ein High erst bei 0.75 * VCC
erkannt wird, damit gibt es eingangsseitig keine 3,3V Kompatibilität.
Der Strom den die Ausgänge schalten können, ist mit 1.6mA auch knapp
bemessen. I2C ist überall zu Hause aber sicher nicht im Motorumfeld. Das
CAN fehlt lässt sich über SPI relativ leicht verkraften. Also für einen
Motor bei dem FOC Sinn macht und bei normalen Anforderungen an die
Drehzahl ist das eine interessate Alternative.
Deine Anforderungen sind aber anders. Bei Dir wird eine
Blockkommutierung reichen und eine Back-Emf Erkennung auf dem üblichen
Weg. Wenn CAN Pflicht ist, dann würde ich sehen ob ein LPC11C24 reicht.
Das ist sogar der Treiber schon drin. Die PWM mit 3 Ausgängen schafft
einer der Timer. Die Kommutierung wird sicher Interrupt getrieben werden
und das Gehäuse ist "handlich".
Moin,
die Firmware LIB von ST für Motion Control kannste knicken, an der
"freien" Version kannste nix anpassen, und somit eignet sich das über
haupt nicht für drehzahlen von über 6000rpm (im elektrischen Feld/
2Pole).
Wenns schnell gehen soll sieh dir den canBLC auf xkopter an. Ist n
STM32F103 mit CAN aber nur Blockkommutiert, reicht aber erst mal. Sonst
musste wohl selber entwickeln. Die Drehzahl sehe ich da noch nicht als
Problem, 100000rpm aufm Feld bekommste damit auch hin, wenn du die PWM
richtig einstellst. Was die FOC angeht. ST gibt bei deren FW lib an das
der µC bei 72MHz ca 25% ausgelastet ist. Wenn du von vornherein auf
Geschwindigkeit im Code achtest zumindest in der Strom Regelschleife
dann packt das der F103 gut. siehe scolton bei Blogspot.
überleg dir was du willst. Selber machen dauert etwas. Deine bisherigen
Posts sagen mir bisher das dein Verständnis für Motion Control noch
nicht sehr groß ist, da musst du also als erstes ansetzen.
MfG
Tec
Vielleicht noch ein paar Zahlen. Wenn der Motor 4 Pole hat und mit
100000rpm dreht, dann sind das für 1Grad Drehwinkel gerade mal noch
0.833us wenn ich mich nicht verrechnet habe. Das sind maximal 60 Befehle
für den mit 72MHz getakteten STM32. In diesem Zeitraster die Position
der Welle mit Rechnen und ADC zu erfassen um den Kommutierungszeitpunkt
(oder Theta) zu bestimmen wird wohl nicht möglich sein. Ich denke unter
die FOC bei diesen Drehzahlen kannst du getrost einen Haken machen...
Eine Blockkommutierung wird aber machbar sein.
Der dsPIC33MC hat zwar eine extrem schnelle PWM drin, mehr aber auch
nicht. Die Cortex M3 können eine 32bit Festkomma Multiplikation/Division
in einem Rutsch. Schneller wird der dsPIC mit Sicherheit nicht rechnen
können.
Hallo Jürgen,
Das siehst du richtig aber die 100krpm bei 2 Polen also reiner
Felddrehzahl sind möglich, aber da ist dann auch irgend wo die Grenze.
Mir sind aber auch keine schnelleren Synchronmaschinen bisher
untergekommen.
Aber wenn sich einer bei 2kHz Felddrehzahl noch über Torqueripple
aufregt dann ist dem eh nicht zu helfen.
Der TO muss erst mal schreiben was für Anforderungen er an den Antrieb
und dessen Regelverhalten hat.
MfG
Tec
@Edit: nur mal rumgerechnet. Bei einer 4 Pol Maschine mit 120krpm n_N
ergibt das 4kHz Felddrehzahl, wenn man für den Sinus 36 Schritte bei
4kHz an sieht hat man 6,944µs alle Berechnungen für den nächsten
Stromvektor vor zu nehmen. Das sind beim Cortex ca. 500 Instruktonen.
Der dsPIC berechnet im 16kHz PWM Zyklus in der AN1078 den Observer und
den Stromregler und kommt auf eine Ausreichende Qualität. Dem Cortex
traue ich durchaus die doppelte Rechen/Sample- usw. Geschwindigkeit zu.
Also 32kHz Stromregelzyklus.
Hi newBLDC,
zu Toshiba.
Was Dir der Disti gesagt hat ist totaler Quatsch. Der TMPM374 ist seit
einem Jahr verfügbar, Evakits und Software gibt's auch. Was Jürgen
Liegner gesagt hat stimmt da schon eher.
Die Anforderung von 50.000rpm ist irrelevant!
Wichtig ist, wie bereits andere mit ihren Rechnungen gezeigt haben, die
elektrische Drehfrequenz, da diese am Ende die Belastung des Prozessors
bestimmt. Also: Wieviele Polpaare hat Dein Motor? Daraus kann die
elek. Frequenz leicht errechnet werden. Damit und der Anzahl Stützpunkte
für die Sinuskommutierung kann die PWM errechnet werden. Pro PWM-Zyklus
sollte eine neue Berechnung des Stromvektors erfolgen.
Es gibt dafür verschiedene Lösung. Der Toshiba hat den Vorteil, dass die
Berechnungen durch Hardware entsprechend beschleunigt werden, ohne die
Genauigkeit und damit die Qualität zu verlieren. Selbst in der FOC
sollte der Toshiba noch 4-5kHz Drehfrequenz erzeugen können.
Gruß
Hallo alle zusammen,
vielen Dank für die ganzen Tipps und Anregungen. Wie bereits ein bischen
angeklungen ist, hab ich noch nicht allzuviele Erfahrungen im Bereich
BLDC-Motoren, also seid gnädig wenn die ein oder andere "dumme" Frage
kommt :)
Zum Motor, oder besser zu den Motoren, habe ich bis jetzt noch nicht
allzuviele Informationen bekommen. Die bisherigen Eckdaten, die ich
kenne sind eine Versorgunsspannung von 24V bzw. 36V und Leistungen im
Bereich von 50W. Ich bekomme aber die Tage noch ein Datenblatt von einem
der Motoren, dann weiss ich mehr. Die Anforderungen sind wie schon
gesagt, das man die Drehzahl bis 50.000rpm (min. so um die 5.000rpm)
regeln können muss. Die Drehzahl wird über eine serielle Schnittstelle
von einem Master vorgegeben. Die Schnittstelle selbst ist noch nicht
definiert. Ich hab die Aufgabe verschieden Möglichkeiten vorzuhalten -
bisher ist RS485, I2C und CAN im Gespräch.
Der Controller selbst hat hauptsächlich die Aufgabe den Motor
anzusteuern. Wenn also die Regeleung des Motors 80%CPU-Load erzeugt ist
das keine großes Problem.
@Jürgen: Vielen Dank zu für deinen Erfahrungsbericht zu dem
Glyn-Seminar, ich hab mir auch schon überlegt zum nächsten Termin
hinzugehen, leider ist der nächste Termin erst relativ spät und bis
dahin muss ich mich auf einen Controller festgelegt haben. Auch den
Hinweis auf die auf die recht begrenzte Peripherie find ich sehr gut,
hab mir darufhin das Datenblatt nochmal etwas näher angesehn und im
Vergleich zu den Controllern von ST NXP und TI ist der 374 doch recht
mager ausgestattet, auch wenn die Vector-Einheit eine tolle Sache ist.
@Tec: Vielen Dank für den Hinweis zu dem canBLC. Ich hab die
Projektseite mal kurz überflogen und das sieht rech interessant aus. Das
werde ich mir definitiv nochmal näher ansehen.
Das man die ST LIB nicht anpassen kann ist sehr schade. Ich hatte da
bisher noch nicht so genau hingesehn und dacht, die liegt wie die
Std-Lib auch als C-Code vor.
@Pako: Vielen Dank mit dem Hinweis auf den dsPIC, aber wie schon
angesprochen sollte es ein Cortex-M Controller sein.
Wieviele Pole die Motoren haben weiss ich noch nicht, aber bis zum Ende
der Woche sollte ich mehr wissen.
Ich hab heute mit einem Kollegen nochmal über das RDK-BLDC von TI
diskutiert, und so wie es aussieht könnten wir die Motoren direkt daran
betreiben, was natürlich eine coole Sache währen um in die Sache
einzusteiegen. Daher meine Frage: Hat jemand konkret Erfahreungen mit
dem RDK-BLDC und kann mir etwas darüber berichten?
Vielen Dank schon mal an alle.
Gruß
Joe
PS: Ich bin die nächsten Tage auf Geschäftsreise, werde mich aber danch
wieder melden.
Hi.. Ich habe im letzten Jahr intensiv mit Motorcontrollern(ST, Toshiba,
Asic...) gearbeitet, hauptsächlich für BLDC-Motoren. Die Toshiba
Controller und auch der TMP374uC sind echt stark, kein Vergleich. Habe
heute gerade das TMP374 Demobvoard bekommen, die VectorEngine ist
genial. Von der Firma Glyn gibt es auch nen tollen workshop wo man das
Demoboard vergünstigt bekommt. Kann ich bis jetzt wärmstens
empfehlen...
Hi,
die Toshiba Controller mit der Vector Engine sind sicher gut, aber was
man dabei evtl. auch beachten sollte ist die Portierbarbeit des Codes.
Man ist anschließend mit solchen Controllern praktisch verheiratet. Wenn
man eine SW Lösung realisiert ist man da wesentlich flexibler und kann
anschließend einfacher wechseln. Meine Erfahrungen mit dem STM32 sind im
Bereich FOC recht gut. Ohne große Optimerung kann man die komplette
Regelung, d.h. Strom, Drehzahl und Positionsberechnung in etwa 30us
berechnen. Wenn man hier noch ein wenig Arbeit in die Optimierung steckt
kann man sicherlich noch einiges rausholen. Der Wert bezieht sich auf
einen STM32 mit 72MHz internem Takt (STM32F103).
Viele Grüße,
Flabes
