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
Für den RX62T gibt es ein Entwicklungsboard inkl. Motor. Distributor u.a. ist MSC. Vielleicht hilft Dir der Link weiter. http://am.renesas.com//applications/key_technology/motor_control/reference/rx/
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.