DuT- Device under test

Ich habe mich länger nicht um den Blog gekümmert, das ändert sich hoffentlich wieder!

Das Sandwichdesign aus dem letzen Post habe ich zwar gebaut und auch getestet aber für nicht gut genug befunden. Bei dem Design der Phasen hatte ich einen Widerstand für alle Gates vorgesehen und dann schmerzlich fest zu stellen dass man die Schaltzeiten der FETs so einfach nicht eingestellt bekommt weil durch die Induktivität der Gate-Bahn die FETs näher am Treiber zu erst schalten und dann weiter weg wie bei einer Laola-Welle....

Dazu kommt noch das die Führung der Source der FETs zu dem Treiber ungünstig war. Weil ich einfach die Masse bzw. die Phasen Fläche angezapft habe. Da dort aber Laststrom fließt stört der resultierende Spannungsabfall sofort die Gates. Was gerade im Umschaltmoment (bei U_th der FETs) zu klingeln am Gate führt und dieses Klingeln sorgte dafür das der FETs schwingend einschaltete und durch den Stromfluss und miese die Source-Anzapfung diese Schwingung rückgekoppelt wurde.... Total super. Hat funktioniert aber schön ist anders.
Merke: Source und Gate bei jedem FET immer separat zum Treiber führen und zwar so das nur Treiberstrom fließen kann und keine Querströme für böse Rückkopplungen sorgen!

Weitere Probleme ware das Handling des STM32 DMA für die ADCs und die PWM gleichzeitig. Außerdem hat mich das doch aufwändige fertigen der Kühlbleche und der generelle mechanische Aufbau mit der seitlichen Platine genervt. Wenn ich an einer Phase messen wollte konnte ich den ganzen Aufbau demontieren, Lackdraht anlöten und alles wieder zusammen setzen. Mal davon abgesehen das der Einsatz einer Masse Feder am Tastkopf überhaupt nicht möglich war. Deshalb waren die Messungen immer mit Vorsicht zu genießen.

Wenn du eine totes Pferd reitetest steig ab!

Deshalb habe ich
ein komplett modulares Design gewählt. In den Bilder rechts am Rand sieht man das Ergebnis, die Platine umfasst nur eine Phase mit Isoliertem Gatetreiber SI8274 und dem isolierten SD-Modulator AMC1304M05. Die freien Flächen sind für 20x5mm² Kupferschienen gedacht 😊.  Alle großen Leitungen werden mit Kabelschuhen angeschlossen und verschraubt. Die Gate-Versorgung ist bipolar (10/-5V) und erfolgt separat für die High-Side und die Low-Side über ein externes isoliertes Netzteil. 

Um das Design zu prüfen habe ich mich mit einem Freund in seinem Labor getroffen und wie habe die Brücke mit Doppelpuls-Tests in Betrieb genommen. Bei diesen Tests haben wir die Gate-Widerstände der 4 FETs bei 300A 😉 Pulsen eingestellt. Das Ganze lief extrem zufrieden stellend. 

Warum habe ich jetzt so lange nichts mehr gepostet?

Die Brücke aus den Bildern ist schon lange fertig, das Netzteil dafür auch aber die Prozessor-Frage stand die ganze Zeit im Raum. Ich erreiche mit den Sigma-Deltas ca. 19Bit Auflösung wobei TI nur ca. 14Bit als maximale ENOB für die AMC1304 angibt. Folglich habe ich viele Möglichkeiten mit dem Setup des Dezimationsfilters das SNR der Strommessung hoch zu treiben. Was ich auch getan habe ich bin jetzt bei 50mA Peak to Peak Rauschen wobei der gesamte Messbereich +-216A beträgt. 

(Ich muss noch kleinere Shunts als 0.3mR finden). 

Jedoch hatte ich mit den STMs immer nur ca. 10Bit Auflösung in der PWM.  Da ich diesen ganzen Aufwand treibe um die Motoren so sauber und lautlos wie möglich zu betreiben ist das etwas Mau. Nur kurz gerechnet: Rs des Motors 20mR und Stromsollwert 1A im Stillstand.

Dafür muss ich also 20mV ausgeben. Bei 24V Versorgungsspannung ist das mit einer 10Bit PWM nicht mehr möglich. Der Stromregler schwankt also immer zwischen 1 und 0. Und das gibt ein schönes Stromrauschen. Da nützt es mir auch nix den Strom extrem genau zu messen wenn ich den Strom nicht auch so genau einstellen kann. Also musste eine HRPWM her. 

Und dann folgte eine Odyssee... Es begann mit dem STM32H743 trotz der unterirdischen Verfügbarkeit dieser CPUs habe ich ein Nucleo mit dem Prozessor drauf ergattern können. Also auf ans testen. Meine SW konnte ich komplett neu bauen weil ST sehr viel an den Peripherien geändert hat. Und dann der Show-Stopper, die HRPWM des H7 ist buggy mehr als die 400MHz Basistakt sind nicht möglich, yeah 11Bit PWM.... 😠

Ok dann der XMC4400 von Infineon. Der ist zwar etwas lahm aber das müsste reichen. Die genaue Ausarbeitung meiner Probleme mit diesem uC spare ich mir hier. Nur eins der Support von Infineon im Forum ist nicht vorhanden! Zumindest wenn die Community keine Antwort weiß kommt von Infineon anscheinend auch keine....

Ok abgehakt aber was nu? 

Alte Hassliebe rostet nicht

Ich bin schlussendlich bei der Prozessorfamilie gelandet die ich bereits hassen gelernt hatte, TIs C2000 CPUs. Diese Architektur hat eine Besonderheit die einen Wahnsinnig machen kann wenn man Kommunikationsstacks von ARM Prozessoren auf sie portieren muss. Der C2000 adressiert WORD weise und kann deshalb keine 8Bit Variablen sondern ein char ist immer 16Bit lang. Das ist besonders toll wenn der Code den man portiert Compiliert aber nicht läuft weil jeder Union in C der ein char enthält auf einmal nicht mehr passt. Aber lassen wir das. 

Wenn man um diese Problematik weiß und auf grüner Wiese anfängt ist die Architektur genau auf meine Anforderungen zugeschnitten. Deshalb habe ich mir gleich mal das große F28379D LaunchPad geordert um erstmal keine Ressourcen Probleme zu bekommen. Bisher brauche ich aber nur ein CPU und deren CLA (Control Law Accelerator) .

Der CLA ist ein Co-Prozessor und ein Segen. Der CLA ist für mich eine Art intelligenter DMA (den hat der C2000 natürlich auch). Er kümmert sich um das abholen der SigmaDelta Messwerte summiert sie auf und rechnet nebenbei die Clark Transformation dazu passt er auf die PWM auf und passt die Dutycycle der HRPWM 😀 für jede Flanke automatisch an. Die eigentliche CPU hat aktuelle 1! IRQ in dem die FOC und die Beobachter laufen und fertig. Well Done TI.

Ein kleiner Teaser

Ferdisch

Ein Board sie alle zu binden...

Und jetzt ist auch das letzte Layout auf einem Stand das es mir gefällt.

Nach einer CAD-Session (Cardboard Aided Design) musste ich das gesamte Board neu routen, weil die Stecker gespiegelt belegt waren. Aber jetzt passen die Stecker zusammen.

Top-Ansicht des Boards.

Auf diesem Board befindet sich die komplette Signalverteilung sowie Anschlüsse für einen Brems-Chopper, zwei zusätzliche analog Eingänge und potentialfreie Kontakte für die Freigabe der Gates und die Freigabe für die Spannungsregler. Deshalb sind auch die Spannungsregler selbst auf diesem Board.

Aufbau der Spannungsregler

Ein BEC oder ähnliches habe ich diesmal nicht vorgesehen. Ich wollte die Spannungsversorgung so simpel wie möglich halten.


Jetzt muss ich aus allen Boards noch einen Nutzen basteln und die BOMs zusammen führen....

Das Hirn

Das nächste Platinendesign für den neuen Umrichter ist soweit das man was zeigen kann.

Top des Controllerboards

Seitenansicht

Das Board ist rein einseitig bestückt damit es direkt auf die abschließende Alu-Platte des Phasensandwiches geschraubt werden kann.

Ein paar Eckdaten zu dem Design. Aktuell ist ein STM32F767 in LQFP100 vorgesehen. USB und CAN sind galvanisch getrennt, damit bei einem hoffentlich sehr hohen fließendem Strom keine Ausgleichsströme über die angeschlossenen Geräte/Platinen fließen. Da ich den Platinenplatz jetzt hatte habe ich ein externes FRAM für Parameter und SalenKey-Filter für die normalen ADC Kanäle vorgesehen. Links oberhalb des STM sind noch 4 DIP-Switches für die Einstellung einer CAN-Adresse und zum setzten des BOOT0, damit man über USB den STM im Feld programmieren kann.

Jetzt fehlt noch die Verbindungsplatine, sozusagen der Backbone.

Neues Layout für die Leistungsbrücke

Endlich habe ich wieder etwas zu berichten.

Oberseite der neuen Leistungsbrücke

Unterseite der Leistungsbrücke

Wie man an den Bildern sieht habe ich mein Design von diesem Post noch einmal revidiert. Ich brauchte einfach mehr Platinen Fläche. Deshalb bin ich jetzt bei einem ein phasigen Design gelandet, dass gestapelt wird. Auf die freigestellten Kupferflächen auf der Oberseite kommen immer noch 6x3mm Kupferschienen. Jedoch soll jetzt eine 3mm Aluplatte als Basis dienen auf der die Platine mit den FETs und isolierender Wärmeleitfolie dazwischen geschraubt wird. Auf die Kupferschienen kommt dann wiederum Folie und 3mm Alu und dann folgt die nächste Phase usw. Bis das Sandwich wieder durch eine 3mm Alu Plate geschlossen wird.

Der Stecker an der Seite ist ein 26poliger har-flex THR von HARTING (ACHTUNG Productplacement: Die haben mich auf der letzten SPS Drives angelacht und Harting hat mir ein Kit mit den gewinkelten und geraden Steckern/Buchsen zugeschickt.).

An der Seite des Sandwiches mit den Steckern kommt dann eine Verteilerplatine. An der dann auch das Controllerboard angesteckt wird, Und das Controllerboard sitzt dann wieder auf dem Sandwich.

Die Aluplaten zwischen den Phasen können so wahlweise etwas überstehen und "Kühlrippen" bilden oder in einem Kühlkörper mit Wärmeleitpaste verschraubt werden. Und da die har-flex auch als wire-to-board-Verbinder verkauft werden kann das Ganze auch komplett verteilt aufgebaut werden.


Die KiCad Daten sind wieder auf bitbucket.org zu finden.

Kleines Update zum Beobachterthema

Demnächst ist wieder das PRAXISFORUM ELEKTRISCHE ANTRIEBSTECHNIK und in den angekündigten Vorträgen finden sich einige sehr schöne Themen. Für mich ist zum Beispiel der Vortrag:

"Herausforderungen und Lösungsansätze für die geberlose Regelung von Synchronmaschinen: aktuelle Probleme in der Anwendung und Lösungen u.a. mittels Quadratinjektion, die eine sehr recheneffiziente Anisotropiedetektion ermöglicht"

sehr interessant. Für reine Hobbyzwecke ist mir jedoch die Teilnahme-Gebühr etwas hoch. Aber die Ausgründung Bitflux der TUM liefert auf ihrer Seite ein paar nähere Infos. Zum Beispiel unter der Rubrik: Team :)  den CEO und CFO kann man gleich in den Skat drücken aber die beiden CTOs haben gegebenenfalls schöne Veröffentlichungen geschrieben. Google ist hier sehr hilfreich.

So findet man z.B. dieses Paper: Silent and parameter independent Hybrid SensorlessControl for SPMSM based on Current Oversampling  oder noch besser die Dissertation des Herrn Dr.-Ing. Peter Landsmann Sensorless Control of Synchronous Machines byLinear Approximation of Oversampled Current.

Gerade die Dissertation werde ich mir mal zu Gemüte führen und anschließend Matlab Simulink drauf ansetzten, Dann kann ich sicherlich mehr berichten!

Direct Flux Control

Ich bin kürzlich auf einen aktuelleren Beobachteransatz für permanent erregte Synchronmaschinen gestoßen. Der Ansatz wird in dieser Publikation als Direct Flux Control beschrieben.

Rotorlage beobachten im Stillstand

Das größte aktuelle Problem im Bereich sensorloser Regelung von Synchronmaschinen ist der Stillstand. Hier lassen sich ohne weiteres keine Signale erfassen die einen Rückschluss auf die Rotorlage erlauben. Viele gerade nichtlineare Beobachter wie ich sie auch einsetze, hoffen im Stillstand darauf nicht grundsätzlich falsch zu liegen mit ihrer aktuellen Einschätzung der Lage. Wird die Maschine dann bestromt sollte ein ausreichendes Drehmoment erzeugt werden, sodass der Rotor sich zu drehen beginnt. Und dann muss der Beobachter nur genügend schnell auf die Rotorlage konvergieren, die er anhand der induzierten Gegenspannung (BEMF) schätzt. Was ist aber wenn die Rotorwelle blockiert ist oder eine Positionsregelung erfolgen soll und man dennoch möglichst effizient den Strom in Drehmoment umwandeln will?

Dann kommen Beobachter-Verfahren ins Spiel die spezielle Signale in die Statorwicklungen einprägen und anhand der Übertragungseigenschaften der Wicklungen auf die Rotorlage schließen.

Zum Einen kann auf der d-Achse ein sinusförmiger Strom mit ca. 1kHz eingeprägt werden und der sich ergebende Strom auf der q-Achse beoachtet werden. Dafür braucht man aber einen sehr scharfen Bandpass für die Frequenz mit der der Strom eingeprägt wird. Sonst hat man die Signale der Drehmomentregelung mit in der Lageschätzung.

Eine andere Variante bietet INFROM. Mit dieser Methode werden gezielt Stromimpulse in die Wicklungen eingeprägt und es werden die Stromänderungen ausgewertet. Die Stromänderung $\frac{dI}{dt}$ auf grund einer eingeprägten Spannung ergibt eine Induktivität. Und dann sind wir auch wieder beim Knackpunkt der ganzen Methoden. Diese Verfahren funktionieren nur wenn die Induktivitäten $L_d$ und $L_q$ genügend verschieden sind.

Direct Flux Control

Leider ist auch die DFC abhängig von der sog. Achsigkeit der Induktivitäten. Aber im Gegensatz zu INFORM muss hier für die Strommessung nicht in der Lage sein mit hoher Auflösung innerhalb von 1-3µs 2 Samples auf allen drei Phasen aufzunehmen, sondern es ist nur eine schnelle Spannungsmessung notwendig. Aber leider soll hier die Spannung des Sternpunktes der Maschine gemessen werden. Und dafür muss fast jeder Antrieb umgebaut werden....
Ein interessantes Verfahren ist es trotzdem.

Toolchain für Cortex-M7 mit FPUs für einfache und doppelte Genauigkeit.

Auf dem Weg zum uclinux auf dem STM32H7xx stolperte ich zuerst über die Toolchain. Emcraft benutzt einen GCC von 2010. In Buildroot ist nur eine Konfiguration für dem F429 ohne hard float support vorhanden. Die GNU ARM GCC Toolchain, die ich sonst immer benutze ist leider gegen newlib gelinkt und newlib ist zwar schön klein für Bare-Metal-Implementierungen aber für Linux Applikationen brauche ich anscheinend ein recht vollständiges glibc Derivat. Im restlichen Netz war auch nix zu finden was mir passte. Da bleibt nur selber bauen.

OpenADK

Um direkt alles aus den Sourcen zubauen habe ich keine Zeit und Lust, deshalb habe ich mir ein Buildsystem alla Buildroot, Yocto und Konsorten gesucht. Dabei bin ich auf OpenADK gestoßen. Wie bei Buildroot gibt es hier auch nur die STM32F429 Konfiguration mit soft float aber der Cortex M7 war bereits in der Konfiguration eingefügt. Außerdem bringt OpenADK bereits alle notwendigen Tools mit um sich selbst zu bauen. Es läuft quasi out of the box. 

Ich hab mir also erstmal einen Fork auf github gemacht und anschließend das Target st-stm32f429 kopiert und in st-stm32f769 umbenannt. Dabei kam dann erstmal diese minimal Konfiguration raus.

config ADK_TARGET_SYSTEM_ST_STM32F769
 bool "STMicroelectronics STM32F769"
 depends on ADK_EXPERIMENTAL
 depends on ADK_TARGET_LITTLE_ENDIAN
 select ADK_TARGET_CPU_ARM_CORTEX_M7
 select ADK_TARGET_HARD_FLOAT_DP
 select ADK_TARGET_ARCH_ARM_WITH_THUMB
 select ADK_TARGET_WITH_SERIAL
 select ADK_TARGET_UCLINUX
 select ADK_TARGET_KERNEL_XIPIMAGE
 help
   STMicroelectronics STM32F769

Die wesentlichen Änderungen betreffen die Namen und die CPU. Die Namensänderungen sind selbst erklärend, deshalb mache ich gleich mal weiter mit den CPU Einstellungen. Die Einstellung select ADK_TARGET_CPU_ARM_CORTEX_M7 spricht ebenfalls für sich selbst. Jedoch musste ich die verschiedenen FPUs des Cortex-M7 irgend wie unterscheiden. Dafür dient das Setting select ADK_TARGET_HARD_FLOAT_DP, damit kann ich zwischen der "fpv5-sp-d16" und der "fpv5-d16" wählen. Die "fpv5-sp-d16" ist die FPU die nur einfache Genauigkeit unterstützt und die "fpv5-d16" kann einfache und doppelte Genauigkeit. Da der auf dem Board verwendete STM32F769 und auch mein geplanter STM32H743 die "fpv5-d16" haben muss die Einstellung gesetzt sein, wenn ich die FPU auch vollständig nutzen will. Ein angenehmer Nebeneffekt ist, das die uclibc-ng gleich mit der Verwendung der FPU gebaut wird, was hoffentlich dem Math-Library zu gute kommt.

Und läuft

Um zu Testen ob die Toolchain auch den erwarteten Code generiert habe ich ein simpel Beispiel ohne Optimierung gebaut und siehe da der Compiler nutzt die FPU Instruktionen wie "vadd.f64" für doubles und "vadd.f32" für floats.

ucLinux oder wie nutze ich übrige Rechenzeit

Ich habe mir über den Jahreswechsel viele Gedanken zu der Software des neuen Umrichters gemacht. Dabei spielte meine Abneigung gegen das Schreiben von Protokoll-Stacks zur Kommunikation eine große Rolle. Denn ansich brauche ich für den Umrichter kein RTOS oder einen Scheduler oder ähnliches Konstrukt. Aber ich und ggf. auch mal andere Leute müssen das Ding ja bedienen.

Das fängt schon mit der Anbindung an externe System an, die Sollwerte liefern sollen. Üblicherweise nimmt man dafür einen Feldbus. CAN braucht nur einen Tranceiver und los gehts. Aber so einfach ist das dann doch nicht. Denn dann bin ich wieder bei der Frage was für ein Protokoll läuft denn dadrauf usw..

Mit geringem Hardware Aufwand ließe sich z.B. CAN oder CAN-FD als Physik für die Kommunikation bereitstellen. Nur dann brauche ich z.B. einen CANOpen-Stack damit der Umrichter eine halbwegs einheitliche Schnittstelle bekommt.

Wenn ich dann weiter gehe und mir über die generelle Inbetriebnahme und Parametrierung Gedanken mache bin ich ganz schnell bei USB. Klar USB-CDC bietet ST fertig an auch ChibiOS-RT, das ich aktuell verwende hat bereits USB implementiert. Aber auch hier muss in irgendeiner Weise ein Protokoll drauf laufen. Klar das kann ich selber definieren und dann auch programmieren... kotz.

Also muss was anderes her. Und da will ich gleich mit der Gießkanne dimensionieren, denn der F7xx hat bei der aktuellen Implementierung meiner Regelung ca. 50% Freizeit. Die Sleep-Modes in der restlichen Rechenzeit zu nutzen ist totaler Humbug, also kann man die Rechnenzeit auch mehr oder weniger sinnvoll verbraten. Gerade im Hinblick auf den Pinkompatiblen H7xx muss für die restliche Rechenzeit eine gescheite Lösung her.

ucLinux

Durch den CCC der über den Jahreswechsel gerade in Hamburg war, durch neue Kontakte und auch durch meine Arbeit bin ich immer weiter gedanklich in den Unix/Linux Bereich vor gedrungen. Und dann stieß ich auf ucLinux. Eine Portierung des Linux-Kernel auf Architekturen ohne MMU, wie den Cortex-Mx und Cortex-Rx. Die Portierung ist sogar bereits in der Mainline des Kernel enthalten, es lässt sich also ein Linux Kernel für das STM32F429-Discovery bauen ohne weitere Anpassungen. Dazu gibts auch YT-Videos usw. 

Dieser Talk vom dies jährigen CCC https://media.ccc.de/v/33c3-7946-console_hacking_2016 ist übrigens Schuld :).

Das Thema ucLinux schien aber unter den Linux-Entwicklern etwas eingeschlafen zu sein und erst in letzter Zeit tut sich an der Front wieder mehr. Ich habe mir Deshalb zum Testen des Ganzen und auch für ein anderes Projekt das 32F769I-Discovery gekauft. Dieses Board ist jetzt mein erstes Opfer für meine Einarbeitung in die Linux-Entwicklung und die Portierung des Kernel auf eben dieses Boards. Da ich in dem Bereich quasi keine Erfahrung habe wird das sehr interessant für mich. Meinen Fortschritt werde ich dann hier zu gegebener Zeit veröffentlichen. 

Architektur

Noch kurz zu dem was ich eigentlich vorhabe. Die Cortex-M7 haben einen sog. TCM (tightly coupled memory). Dieser RAM Bereich hängt direkt an dem 64Bit breiten Hauptbus des Prozessorkerns. Der Speicher ist quasi genauso schnell wie der Cache der CPU. In diesen Speicher lädt ein Linux Treiber den Code des Reglers. Ein hoch priorisierter IRQ führt dann immer die Funktion aus. Da man beim Cortex-M die Interrupts nesten kann und hoch priore Interrupts gezielt aktiv gelassen werden können, auch wenn Linux in einer Critical-Section ist, hat der IRQ keine zusätzliche Latenz außer die Normale die auch im Bare Metal Betrieb da sein würde (9-11 Takte oder so). 

Das Problem dabei ist, der Regler darf auf keine Strukturen des Linux Bereiches zugreifen zu keiner Zeit. Denn ein Zugriff durch den Regler, wenn Linux nicht damit rechnet führt im schlimmsten Fall zum crash. Deshalb muss ich einen RAM Bereich für Parameter zum Regler auf dem der Regler nur ließt und einen RAM Bereich auf dem Linux nur ließt definieren. Außerdem sind die Daten auf 32Bit Breite Typen begrenzt, weil die vom Prozessor grundsätzlich in einer Instruktion gesetzt werden können. 

Interessant wird auch wie sich der Prozessor verhält wenn Linux eine Exception, wie einen Hard-Fault haben sollte, läuft dann der IRQ für den Regler noch? Kann Linux ggf. den verursachenden Prozess killen und der Umrichter läuft weiter? Das wäre ein Träumchen aber wir werden sehen.

Aber bis ich das so hin habe vergeht noch viel Zeit :) ist ja Hobby.

Schaltverluste verringern

Bei meinem letzten Post kam ich rechnerisch auf ca. 45W Schaltverluste. Um diese Wärme abzuführen kommt man, um aktive Kühlung nicht herum. Jedoch stellt sich die die Frage, wie kann man diese Verluste verringern? Ganz klar mit einer geringeren Schaltfrequenz. Geht man von 24kHz auf 8kHz so bleiben nur 15W Schaltverluste übrig. Aber 8kHz sind nicht schön anzuhören und die Regelfrequenz ist auf höchstens 16kHz begrenzt. Was kann man also tun um die Verluste elektrotechnisch runter zu bekommen?

Und hier gehe ich auf dünnes Eis. Deshalb sind die nach folgenden Infos als meine derzeitige Meinung anzusehen. 

Also warum entstehen Schaltverluste? Der Strom bleibt durch die Wicklungsinduktivität weit gehend konstant und die über den FETs abfallende Spannung steigt an im Schaltmoment. Wenn in diesem Umschaltmoment ein anderes Bauteil den Strom übernimmt während die FETs Umschalten so reduziert das massiv die Schaltverluste. Weil diese proportional zu dem von den FETs geführten Strom sind.

Zur Erklärung gehe ich von einem einzigen Schaltvorgang aus. Es sei die Highside gerade aktiv und die Lowside soll einschalten.
Außerdem sei ein Kondensator mit einer hohen Impulsstromfestigkeit von der Phase zur Lowside respektive GND eingebaut.
Dieser Kondensator ist auf $U_{BAT}$ geladen. Durch die Phase fließt ein Strom von 82A in eine stark induktive Last.

Jetzt schaltet die Highside ab. Der Strom will auf Grund der Induktivität der Last konstant bleiben. Da der Widerstand zur $U_{BAT}$ durch das Abschalten der Highside steigt, muss der Kondensator zwischen der Phase und GND den Strom weiter tragen. Das kann der Kondensator solange wie er genügend Ladung hat. Aber so lange sind die FETs quasi Stromlos und können ohne Verluste umschalten.

Snubber

Bei Umrichtern mit hoher Leistung verwendet man gern sogenannte Snubberglieder. Der Kondensator zwischen Phase und GND von dem ich schrieb ist quasi so ein Snubber. Jedoch werden Snubber eigentlich dafür eingesetzt um die Spannungsspitze, welche entsteht wenn während der Totzeit der High- und Lowside kein FET leitend ist, abzufangen bzw. zu dämpfen. 

Bei den Spannungen bei denen ich hier arbeite habe ich jedoch keine allzu lange Totzeit. Allein schon deshalb weil ich die FETs sehr schnell umschalten kann, ohne das mein dV/dt an der Phase weit über 400V/µs steigt. was wiederum die EMV auf einem vernünftigen Maß hält. 

Eine Frage ist aber noch offen. Wie dimensioniere ich so einen Kondensator. Ich wähle hier einen Kerko mit hoher Spannungsfestigkeit und sehr geringem Innenwiderstand (Große Bauform bei wenig Kapazität).

$\cfrac{dU}{dt} = \cfrac{I}{C} = \cfrac{\approx 100V}{200ns} = 400V/µs $

$\cfrac{I}{\cfrac{dU}{dt}} = C = \cfrac{82A}{400V/µs} = 205nF$

Um den Strom durch die FETs mit einer flacheren Spannungskurve abzufangen brauche ich einen 200nF Kondensator an jeder Phase jeweils gegen GND für den Schaltvorgang High -> Low und von der Phase gegen $U_{BAT}$. 

In der Realität ist das alles natürlich nicht so einfach aber es ist eine schöne Vorstellung. 

Und deshalb hoffe ich jetzt, dass das funktioniert. :)

Berechnen der Schaltverluste einer dreiphasigen Brücke

Auch dieser Beitrag basiert wieder auf der App-Note "Calculating Motor Driver Power Dissipation" von TI. Bei allen verwendeten Daten beziehe ich mich ebenfalls wieder auf mein letztes Brücken-Design.

• Betriebsparameter
• $U_{BAT} = 4,2V \cdot 18 = 75,6V$
• $I_{BAT} = 100A$ 
• PWM Frequenz: 24kHz 
• MosFETs
• $R_{DS(ON)_{MAX}}  = 4,5m\Omega$
• $Q_g = 58nC$
• 8 x FETs parallel

Treiberleistung

Der Vollständigkeit halber will ich auch kurz auf den Leistung- bzw. Strombedarf des Treibers eingehen. Dabei beziehe ich mich auf das Wiki von mikrocontroller.net zu MosFet-Treibern. Dort wird die Treiberleistung wie folgt berechnet.

$P_{Drv} = f_{sw} \cdot Q_{g_{Gesamt}} \cdot U_{Drv}$

Die Spannung $U_{Drv}$ ist hier die Spannungsversorgung des Treibers und damit die Spannung auf die die Gates umgeladen werden. Das die Highside noch 0,7V über die Bootstrap-Diode einbüßt vernachlässige ich in den folgenden Rechnungen. 

Die Ladung $Q_{g_{Gesamt}}$ steht hier für die Total-Gate-Charge $Q_g$ aller mit der PWM Frequenz $f_{sw}$ geschalteten FETs. In meinem Fall also $48 \cdot 58nC = 2784nC$. 

$P_{Drv} = f_{sw} \cdot Q_{g_{Gesamt}} \cdot U_{Drv} = 24kHz \cdot 2784nC \cdot 12V = 0,8W$

Daraus lässt sich dann auch der Strombedarf für den Treiber mit $I_{Drv} = \cfrac{P_{Drv}}{U_{Drv}} = \cfrac{0,8W}{12V} = 67mA$ berechnen.

Schaltverluste

Wirklich zubuche schlagen aber die eigentlichen Schaltverluste während des Umschaltens zwischen Low- und Highside.

Dafür setzt man üblicherweise eine linear steigende/fallende Spannung bei konstantem Strom voraus. Die Fläche des Spannungsdreiecks bestimmt damit die eigentliche Schaltverlustleistung. TI gibt deshalb pro Phase folgende Gleichung an:

$P_{sw_{Ph}} = 0,5 \cdot U_{BAT} \cdot  I \cdot t_{rf} \cdot f_{sw}$

Bis auf die Anstiegs- bzw. Fallzeit der Spannung sind alle benötigten Werte bereits bekannt. Für eine halbwegs gute Näherung setze ich einfach mal an, das der LM5101A 3A in die Gates von 8 FETs schiebt. Um die Gateladung der FETs mit 3A auf 12V zu laden braucht er:

$t_{rf} = \cfrac{8 \cdot Q_g}{3A} = \cfrac{8 \cdot 58nC}{3A} = 154ns$

Ja dabei vernachlässige ich bewusst die Abflachung des Anstiegs je höher die Spannung steigt. Aber im Grunde muss der FET ja auch nur über seinen Threshold und das ist bei 63% von 12V auf jeden Fall so. Zur Sicherheit nehme ich $t_{rf} =200ns$ an.

$P_{sw} = 3 \cdot 0,5 \cdot U_{BAT} \cdot  I \cdot t_{rf} \cdot f_{sw} = 1,5 \cdot 75,6V \cdot 82A \cdot 200ns \cdot 24kHz = 44,6W$

Gesamtverluste der Brücke

Alles in allem komme ich so auf eine Verlustleistung $P_v = 11,4W + 0,8W + 44,6W = 56,8W$. Wenn die Brücke bei dieser Verlustleistung bei 30°C Umgebungstemperatur nicht die zulässige Sperrschichttemperatur der FETs von 150°C übersteigen soll dann muss der thermische Widerstand der Kühlung unter $\cfrac{150°C - 30°C}{56,8W} = 2\cfrac{K}{W}$ liegen. 

Da ist es goldwert 48 FETs zuhaben. Denn ein FET allein hat bereits einen thermischen Widerstand von der Sperrschicht zum Gehäuse von $\approx1\cfrac{K}{W}$. Dieser reduziert sich glücklicherweise bei 48 FETs die doppelseitig an einen Kühlkörper angebunden sind auf  $\approx1/96\cfrac{K}{W}$ sprich $\approx0,01\cfrac{K}{W}$. Nichts desto trotz sind Kühlkörper mit weniger als $2\cfrac{K}{W}$ nicht gerade klein geschweige den leicht.

Wie ich das gekühlt bekomme werden ich sehen wenn der elektrische Aufbau steht.

Soweit erstmal die mathematische Auslegung. 

Die Tücken der Verlustleistung

Gleich vorweg der ganze Beitrag basiert auf der App-Note "Calculating Motor Driver Power Dissipation" von TI. Bei allen verwendeten Daten beziehe ich mich auf mein letztes Brücken-Design.

• Betriebsparameter
• $U_{BAT} = 4,2V \cdot 18 = 75,6V$
• $I_{BAT} = 100A$ 
• MosFETs
• $R_{DS(ON)_{MAX}}  = 4,5m\Omega$
• $Q_g = 58nC$
• 8 x FETs parallel

Durchlassverluste

Die App-Note geht hier zwar von einem DC Motor aus, aber das lässt sich ja auf Drehstrom übertragen. Für DC setzt TI folgende Gleichung an:

$P = (R_{DS(ON)_{HS}} \cdot I^2) + (R_{DS(ON)_{LS}} \cdot I^2)$

Der Strom fließt also aus der Highside in die Lowside und passiert bei einer DC-Vollbrücke genau zweimal einen FET. Bei einer dreiphasigen Maschine fließt in allen 3 Phasen der Strom. Deshalb passiert der Strom eine Lowside und zwei Highsides oder umgekehrt. Da nie die Highside und die Lowside einer Phase gleichzeitig aktiv sind (sein sollen) und die Thermodynamik langsam ist sieht die Gleichung für dreiphasenige System so aus:

$P_v = 3 \cdot (R_{DS(ON)} \cdot I^2)$

Ich habe hier gleich die $R_{DS(ON)}$ zusammen gefasst, weil alle gleich sind.

Jetzt ist aber noch eine Frage offen für die Berechnung der Verlustleistung. Wie hoch ist $I$ eigentlich? Da setze ich einfach mal den Energieerhaltungssatz an. Die Energie die rein geht muss auch wieder raus. Wenn man jetzt noch annimmt, dass der Wirkungsgrad des Umrichters $\approx1$ ist. Gehen schlanke $ U_{BAT} \cdot I_{BAT} = P_{BAT} = 75,6V \cdot 100A = 7560W$ von der Batterie in den Umrichter. Und die müssen ja auch wieder raus, aber da wird es dann auch wieder knifflig.

Warum? Weil der Innenwiderstand der Motoren so niedrig ist wird die Länge des Spannungsvektors nahezu allein durch die Drehzahl der Maschine bestimmt. (EMK Spannung) Der Spannungsabfall über dem Wicklungsinnenwiderstand kann vernachlässigen. Das Problem ist also wie sieht die Betriebsdrehzahl des Antriebs aus. Für ein Traktionsantrieb, also Fahrrad, KFZ usw. ist die Leerlaufdrehzahl der Maschine kein normaler Betriebspunkt. Da wird sich die Drehzahl im Mittel auf 50% der Leerlaufdrehzahl der Maschine belaufen. Bei einem Propellerantrieb, hingegen ist eine Betrieb nahe der Leerlaufdrehzahl sehr wahrscheinlich.

Langer Rede kurzer Sinn: Niedrige Drehzahlen bedeuten mehr Strom und damit ist der Antrieb als auch der Umrichter in einem ungünstigeren Betriebspunkt. ABER: Das soll ja eine Abschätzung sein und deshalb nehmen wir einfach einen Betriebspunkt und zwar Leerlaufdrehzahl und volle Lotte Strom. Bei voller Leerlaufdrehzahl muss der Umrichter den längst möglichen Spannungsvektor fahren.

Stern oder Dreieck

Egal. Zumindest für den Umrichter. Für die Rechnung nicht. Und um diese möglichst "einfach" zu halten nehme ich Stern an. Weiterhin sage ich an dem Motor liegt ein gültiger Spannungsvektor von $[1; 0,5; 0]$ an. Phase A ist hierbei fest auf $U_{BAT}$, Phase B bekommt eine 50% PWM und Phase C liegt fest auf $GND$. In dem Fall sehen die Spulen A und C eine Spannung von $0,5 \dot U_{BAT}$. Bei geschickter Modulation (SVPWM) lassen sich ca. 15% mehr Spannungshub rausholen. Deshalb sieht jede Spule im Stern maximal $1,15 \cdot 0,5 \cdot U_{BAT}$. 

Für die Leistungsberechnung ist aber nicht der Spitzenwert, welchen wir jetzt berechnet haben , interessant sondern der RMS Wert. Somit ergibt sich eine wirksame Spannung von

$U_L = \cfrac{1,15 \cdot 0,5 \cdot 75,6V}{\sqrt(2)} = 30,74V$

pro Phase. Weil wir drei Phasen haben die mit $P = U \cdot I$ zusammen auf $7560W$ kommen sollen, muss noch etwas umgestellt werden und siehe da:

$I = \cfrac{ P_{BAT}}{3 \cdot U_L} = \cfrac{7560W}{3 \cdot 30,74V} = 82A$

Es fließt also ein Strom mit dem Effektivwert von $82A$ durch jede Phase und damit durch jeden aktiven $R_{DS(ON)}$

$P_v = 3 \cdot (R_{DS(ON)} \cdot I^2) = 3 \cdot (\cfrac{4,5m\Omega}{8} \cdot 82A^2 = 11,4W$

Und spätesten die $11,4W$ sollten jedem klar machen, dass dieses Brücken Design mit 65x85mm echt klein ist. Ich bin gespannt. 

Die Schaltverluste kommen Morgen im nächsten Post.

Leistungsbrücke: "Monster MK II"

Als die CPU feststand habe ich erst einmal überlegt, wie ich eine deutlich leistungsfähigere Brücke, als die des TDC bauen kann.

Die Schlüsselerkenntnis aus dem TDC ist für mich: Leiterbahnen haben einen NICHT zu vernachlässigenden Widerstand :).

Aber mehr als 70µm Kupferauflage ist für Einzelstücke quasi nicht zu bezahlen, bzw. will ich nicht allein für die unbestückte Platine 500€ ausgeben. Deshalb musste eine einfache Platine mit 4 Lagen a 70µm Kupfer reichen. Wirklich Strom bekommt man da aber nur mit mehr Fläche durch. Oder ....

Leiterquerschnitt erhöhen

Bei günstiger Leistungselektronik sieht man immer wieder aufgelötete massive Kupferdrähte, die den leitenden Querschnitt einer Leiterbahn erhöhen sollen. Aber dafür muss ich viele Kupferdrähte ziehen, zuschneiden und auflöten was ziemlich fummelig ist und dafür bringt es immer noch zu wenig Querschnitt. Da hilft nur richtig massives Material. Deshalb habe ich mir 6x3mm Flachkupfer Stäbe auf ebay bestellt. Die kann ich hochkant auf die Platine löten und komme so auf mehr als 18mm² Querschnitt (es kommt ja noch die Bahn darunter mit dazu). Nach VDE Norm kann ein 16mm² Leiter frei in der Luft verlegt 98A bei einer Umgebungstemperatur von 30° ab.

Ich bin gespannt wie sich die Temperatur bei meinem Aufbau verhlt. Aber da die Flachkupferstangen stehend verlötet sind bilden sie quasi "Kühlrippen" und ich erhoffe mir jetzt einfach mal, dass das etwas bringt 😉.

Die FETs

Da mache ich keine großen Experimente. Ich bleibe bei SO-8 ähnlichen Gehäusen nur braucht es bei dem Strom ein paar mehr. Meine Wahl fiel auf die TPW4R50ANH. 

Absolute Maximum Ratings

Characteristics	Symbol	Rating	Unit
Drain current	ID	92	A
Power Dissipation	PD	142	W
Drain-Source voltage	VDSS	100	V
Gate-Source voltage	VGSS	+/-20	V

Electrical Characteristics

Characteristics	Symbol	Condition	Value	Unit
Input capacitance (Typ.)	Ciss	-	4000	pF
Total gate charge (Typ.)	Qg	-	58	nC
Drain-Source on-resistance (Max)	RDS(ON)	|VGS|=10V	0.0045	Ω

Mit einer Spannungsfestigkeit bis 100V ist dann auch gleich der Spannungsbereich fix. Für 18 - 20S (72V) sollten diese FETs hobbytaublich Dimensioniert sein. 60V Batteriespannung sollten aber sicher problemlos möglich sein. 

Außerdem war für mich das DSOP-Gehäuse der FETs ein wichtiges Auswahlkriterium. Denn das Gehäuse führt den Source Kontakt an der Gehäuseoberseite flächig nach außen.

Toshiba nennt das dann "double sided cooling". Das Prinzip ist aber ähnlich wie bei den Directfets von Infineon/IR.

Nur kosten die 1/3 von dem was ein vergleichbarer Directfet kostet. 

Die Frage ist jetzt noch wie viele von den FETs schaltet man parallel. Antwort: Soviele wie möglich 😁

Leider gibt es Grenzen. Damit die FETs in den Genuss von doppelseitiger Kühlung kommen, müssen alle auf die selbe Platinenseite. Sonst würden sich die FETs gegenseitig erwärmen. Denn die Lötseite des DSOP-Gehäuses ist immer noch, die mit dem besten Wärmewiderstand. Wenn jetzt aber alle FETs auf eine Seite kommen, darf auf der Seite auch kein höheres Bauteil bestückt werden, wenn ich einen unbearbeiteten Kühlkörper verwenden will. Da ist dann 0402 angesagt. (Die FETs sind 0,8mm hoch, 0402 ist 0,5mm hoch)

Ausgehend vom TDC der mit 2 ungekühlten FETs ca. 20A dauerhaft fahren kann und ich auf 100A kommen will brauche ich schlanke 10 FETs in parallel...puhhh. Aber die Kühlung ist ja besser 😉

macht also 8 FETs. Außerdem klingt 48 auch besser als 60 FETs. Das macht dann lumpige 464nC Total Gate Charge insgesamt. Eigentlich kein schlechter Wert. 2 Dicke D²-PAK-7 FETs haben mehr.

Der Gate-Treiber

Eigentlich wollte ich meinen Feld, Wald und Wiesen Treiber den IR2186 nehmen, doch dann hatte ich kurzzeitig die Schnapsidee einen isolierten Gatetreiber zu verwenden. Da ich dafür 4 separate isolierte 12V DC/DC Wandler bräuchte fällt das gleich flach. Aber beim recherchieren nach isolierten Treibern ist mir ein Kennwert aufgefallen, der bei unisolierten Treiber quasi nicht erwähnt wird. Die Propagation Time, also die Zeit zwischen logischem Eingang auf High und dem High am Ausgang des Treibers. Und da ist der Steinzeit IR2186 auf dem Niveau eines normalen isolierten Treibers. Der braucht dafür 170ns!!! Folglich habe ich mich mal auf die Suche nach einem neuen Treiber begeben und ich bin bei TI fündig geworden. Der LM5101A hat einen Propagation Delay von nur 25ns und ist auch noch in fast allen anderen Werten besser. Einziger Haken ist er kann nur 100V ab. Was mich aber nicht stört, mehr können die FETs auch nicht. 

Die Strommessung

Wenn ich die Leitfähigkeit der Bahnen erhöhe dann muss ich mir auch die Strommessung als solches vornehmen. Aber meine aktuelle Lieblingstechnologie bietet auch hier Linderung. Der AMC1304M05 hat einen Eingangsspannungsbereich von +/-50mV bei einem SNR von 80dB typisch.

(20dB  entsprechen Faktor 10, da dB eine logarithmische Einheit ist bedeutet eine Addition von 20dB + 20dB = 40dB  = 10x10 = 100, bei 80dB SNR ergibt sich ein Signal zu Rauschabstand von 1 zu 10000, 20dB x 4 => 4 Nullen hinter der 1) 

Er löst also auf ca. 5µV effektiv auf 😎. Als Shunt passt da wunderbar der WSLP5931 von Vishay mit 0,3mR. Damit bin ich bei einer absoluten Messbereichsgrenze von 216A und einer linearen Messung von +/-166A. Außerdem kann der AMC1304M05 über die Bootstrap Spannung der High Side FETs versorgt werden, den er hat einen internen LDO. Leider merkt man dass auch am Gehäuse Wide Body SOIC-16. 

Das Board

KiCAD Daten: https://bitbucket.org/thunderdrive/power_bridge

STM32F767 oder STM32H743 mit Delta Sigma Demodulatoren

Nach dem mich ein stiller Mitleser daran erinnert hat, dass den Blog vllt. doch jemand ließt schreibe ich wieder. Zumal ich meine Gedanken mal wieder nieder Schreiben muss, sonst drehe ich gedanklich noch 5 Runden nur im vor den selben Entscheidungen zustehen.

In meinem letzten Post habe ich zwischen den XMC4xxx von Infineon und dem ADSP-CM4xx von Analog geschwankt. Der XMC war mir zu langsam allein von den Daten her. Der ADSP-CM4xx ist schlecht erhältlich  und es existiert quasi kein GCC portierter Code für den Prozessor. Alle Libs von Analog sind für IAR. Drum habe ich mich sehr über die STM32F76x Prozessoren mit Delta Sigma Demodulatoren gefreut. Dabei habe ich die Ankündigung für den STM32H743 gesehen, den es auch noch in LQFP100 gibt.

Da der STM32H743 und die STM32F76x pinkompatibel sein sollen habe ich mich auf den STM32F767 in LQFP festgelegt. Mit der Option später auf einen STM32H7 upgraden zu können. Außerdem bietet der STM32H743 noch eine HRPWM, die vllt. noch eine Möglichkeit ist um die Systemgenauigkeit weiter zu erhöhen.

Die Controllerauswahl

Vorwort

Wie so oft bin ich der Zeit am grübeln, was man noch anders und besser machen kann bei den Motorreglern. Der größte Punkt ist hier bei für mich eine maximal saubere Strommessung. Bisher bin ich mit den ACS Sensoren von Allegro wie auch der Lowside Shuntmessung nicht zufrieden.

Bei der Lowside-Messung stört es mich, dass ich nur einen Messwert pro PWM-Periode zur Verfügung habe und darauf angewiesen bin, dass zum Zeitpunkt der Messung der OP auch auf die korrekte Ausgangsspannung eingeschwungen ist. (Stichwort: settling time / slew rate)

Bei den ACS Sensoren kann ich zwar mehrere Messwerte pro Periode aufnehmen, aber diese Sensoren haben gerade bei Strömen um 0A herum das Problem einer Hysterese. Der Sensor kann quasi keine 0A ausgeben sondern er gibt entweder -0,1A oder +0,1A aus. Bei einem Nulldurchgang des Stromes von negativ nach positiv bleibt der Sensor erst auf -0.1A kleben und springt auf 0.1A wenn der Strom auf 0,1A gestiegen ist. Im Mittel geht sich das meißt aus für langsame Signale. Jedoch hört man die Verformung des Stroms bei höheren Drehzahlen.

Da ich die Motorregler ohne kommerziellen Hintergrund baue und beim Hobby immer gilt: Wie kann ich mit möglichst viel Aufwand Zeit und Geld verbrennen, will ich mich mit diesen Lösungen nicht zufrieden geben auch wenn sie gut funktionieren.

Lange Rede kurzer Sinn: Die STM32 sind mir zu General Purpose. Ich suche einen Motor Control spezifischeren µC mit Cortex M Kern und Floating Point Unit um das portieren und die Einarbeitung möglichst einfach zu halten.

2 Interessante Kandidaten sind hier für mich der ADSP-CM403 von Analog Devices und der XMC4700 von Infineon.

ADSP-CM403

• ARM Cortex M4 Core with Floating Point Unit to support advanced programming models and complex algorithms with speed grades of 100 to 240 MHz.
• Dual 16 bit SAR ADCs with no missing codes, 13+ ENOB, 380ns conversion speed for high precision closed loop control.
• 128 to 384KB SRAM and 256KB to 2MB flash memory options for a wide range of program and data memory requirements.
• Advanced PWM and timer functions for improved PV inverter and motor drive performance.
• Two CAN interfaces, three UARTS, two SPIs, two SPORTs, eight 32-bit timers, two two-wire interfaces and four quadrature encoder interfaces.
• SINC filters for glueless connection to AD74xx isolated converters.
• Harmonic Analysis Engine for compliant grid connection.
• 14x14 120 lead LQFP package with 40 GPIO pins, 24 ADC input pins and 2 DAC output pins optimized for PV inverter applications.
• Up to 105C ambient operating temperature for support of industrial applications.

XMC4700

• ARM ® Cortex ®-M4 @ 144MHz
• 1536kB Flash, 276kB RAM
• Data and IP Protection on Flash
• 6 x CAN nodes
• EthernetMAC, USB-OTG, SD/MMC
• 6 channel USIC (configurable to SPI, UART, IIC, IIS)
• External Bus Unit
• 4 x 12-bit ADC, 18 input channels, 4 x parallel sampling and conversion
• 2 channel 12bit DAC
• 4 channel ∆Σ Demodulator
• 24 x 16-bit special purpose timers, dead time generation
• 2 x Position Interface
• Watch Dog Timer, Real Time Clock
• XMC4000 Functional Safety Package
• LQFP100
• -40 - 85°C

Der ADSP ist ein ziemliches Monster mit 240MHz und 16Bit ADCs die eine effektive Auflösung von mehr als 13Bit liefern. Der Infineon stellt quasi den vernüftigen Mittelweg dar, aber der ADC ist nicht wirklich besser als der des STM32. Nur die Timer sind vielfältger.

Wenn man einmal genau überlegt was Analog mit dem ADSP für einen Proze baut bin ich tief beeindruckt. Auch wenn die Dinger doppelt so teuer sind. Der STM32 kommt auf eine ENOB von 10,8Bit bei einem 12Bit ADC ist das meiner Meinung nach schon sehr hingelogen. Aber Analog gibt mehr als 13Bit ENOB für den SAR ADC des ADSP an. Das bedeutet eine um mindestens 4mal (fast 8mal) höhere Auflösung als der STM32 liefern kann.

Ich hatte ursprünglich gedacht ich nehme für den Pitchregler des Constant Speed Prop einen XMC1100 aber irgendwie nervt es, sich für so ein im Vergleich kleines Projekt in einen anderen Prozessortyp einzuarbeiten. Ich hatte eigentlich gehofft das DAVE von Infineon mit seinen konfigurierbaren Peripherieblöcken mir die Arbeit bei der Konfiguration der Timer usw. abnimmt. Aber diese Blöcke sind quasi nicht zu gebrauchen. Ein LED Blinky ist damit zu machen, vllt. auch eine LED dimmen und das war es dann auch schon. Für so eine elementare Funktion wie ein Capture für PPM-Eingänge gibt es nicht. Das ist echt schade. Sonst wäre DAVE eine echte Alternative um schnell die Peripheriekonfiguration zusammen zu kloppen und sich dann um die Applikation zu kümmern.

Deshalb gehe ich wieder auf dem STM32F3 für den Pitchregler und die nächste Ausbaustufe für den ThunderDrive wird dann mit dem ADSP-CM4xx implementiert. Leider bietet Analog nur Beispiele und Code-Unterstützung für IAR an. Ich müsste also für eine freie IDE den Startup Code und das Linkerstript für den Prozessor erstellen. Das sollte aber kein allzu großes Hindernis sein. Vor der Konfiguration des Caches des Prozessors habe ich mehr Respekt. Was solls das ist ja schließlich Hobby. Wenn ich so eine voll Inbetriebnahme mit neuer Toolchain in Angriff nehme ist es denke ich auch gleich sinnvoll nicht auf den betagten GCC zu setzen sonder auf cLang zu gehen. Aber da muss ich mich erstmal weiter belesen, wie die cLang Integration mit Eclipse und dem GDB funktioniert.

Erster Test auf dem Dyno-Teststand

Automatische Schub und Drehzahlregelung bei einem Constant Speed Prop

Im RC-Network wird aktuell ein Thread über den Bau eines Constant Speed Propeller, diskutiert.

Weil das Thema eine interessante Anwendung für einen Umrichter wie den ThunderDrive ist, hatte ich vorgeschlagen die Automatisierung des Props zu übernehmen. Darauf hin kam Jüge, der Threadstarter, auf mich mit ein paar Anforderungen zu.

Im wesentlichen geht es um folgende Betriebsmodi:

• Normal / CUT: Keine Regelung. Motor über Knüppel und Pitch/Verstellung über Slider.
• Idle 2 / FLIGHT IDLE: Hier ist das gleiche, nur dass die Drehzahl bei 12000rpm liegt.
• Idle 1 / GROUND IDLE: Regelung mit Begrenzung bei z.B. 4000rpm. Solange nicht genügend Gas gegeben wird, bleibt der Pitch auf Minimum, um das Moment so klein wie möglich zu halten, damit der Prop auf die gesetzte Drehzahl beschleunigen kann. Hat der Propeller 4000rpm erreicht und es wird mehr Gas gegeben, so erhöht der Regelkreis den Pitch, um das Moment zu überhöhen.

Zu erst dachte ich, das wirt simpel. Drehzahl messen und regeln mit dem Pitch als Stellgröße. Ein simpler PI-Regler würde das schon tun. Aber so einfach wie es auf den 1. Blick wirkt ist das Thema aber gar nicht. Was ich nicht bedacht hatte, war das unterschiedliche Verhalten der Antriebe. Ein Verbrennungsantrieb (Egal ob Zerknalltreibling oder Turbine) ist leistungsgesteuert, Mehr Gas ergibt mehr Leistung, aber bei konstantem Gas bricht bei Belastung die Drehzahl ein. Das ergibt sich aus der Gleichung für die mechanische Leistung.

Leistung = Drehmoment * Drehzahl

Ersetzt man den Verbrennungsantrieb durch einen BLDC-Motor mit einem Standard BLDC-Regler, hat man keinen leistungsgesteuerten Antrieb mehr sondern einen drehzahlgesteuerten Antrieb. Das ergibt sich einfach gesagt aus der Drehzahlkonstante Kv die üblicherweise in rpm/V angegeben wird und der Arbeitsweise der BLDC-Regler. Denn diese "Regler" stellen abhängig von ihrem Sollwert (0% - 100%) eine Spannung von 0 - Akkuspannung ein. Im Leerlauf entspricht die Drehzahl des Motors

Drehzahl = Sollwert * Kv * Akkuspannung

Jetzt mag man geneigt sein zu sagen, dass die Drehzahl unter Belastung auf bei E-Motor absinkt und das stimmt auch aber nur um einen sehr geringen Teil:

Drehzahl = Sollwert * Kv * Akkuspannung - Rs * Wicklungsstrom

Rs ist der Innenwiderstand der Wicklung (Der wird sogar bei Modellbaumotoren oft angegeben). Der Strom durch die Wicklung welcher sich durch die Belastung des Motors ergibt sorgt somit für einen Spannungsabfall in der Wicklung. Das hat zur Folge das die Spannung die der Motor in Drehzahl umsetzen kann sinkt und folglich auch die Drehzahl an der Welle. ABER der Rs ist so gering, dass man diese Spannung auch vernachlässigen kann. Übliche Werte für Rs liegen je nach Leistungsklasse des Motors bei 100mOhm bis runter zu 10mOhm. Die Drehzahl sinkt so unter Volllast nur um gut 10% ab.

Selbst wenn man den Innenwiderstand der Motor- und Akkuzuleitungen sowie den Innenwiderstand des Akkus selbst mit einbezieht kommen nicht mehr als 20% Drehzahleinbruch zusammen.

Long story short: Wenn der Gasknüppel so steht das der Prop an die eingestellte Drehzahl des Pitchreglers kommt, dann würden 2 Rasten mehr am Knüppel dazuführen das der Motor überlastet wird weil der Pitchregler versucht die Drehzahl mit mehr Pitch zu halten und der Motor der höheren Spannung des Reglers folgt. Die einzige Variable Größe ist hier der Strom und der steigt soweit an des entweder der Motor oder der Regler stirbt.

Deshalb braucht der Pitchregler nicht nur die Drehzahl sondern auch den Strom des Motors um die Motorleistung zu messen. Damit kann dann auf den Gasknüppel eine Antriebsleistung von 0%-100% gelegt werden.

So glaube ich ließe sich zum einen ein Scale-Verhalten des gesamten Antriebs erreichen und eine maximale Feinfühligkeit für den Schub am Knüppel. Außerdem kann der Pitchregler so immer sicherstellen, dass Motor und Regler nicht überlastet werden.

Und all das will ich fürs erste in ein XMC2Go packen.

Erster Test mit Propeller

Ich habe jetzt mal ein Video gemacht wie sich der TDC an ein einem GTX3546 mit einem Kv von 650rpm/V verhält. Leider hatte ich nur eine 10x8" Latte da, aber für einen ersten Eindruck reichts.

Löppt.

Nach dem ich lange nichts geschrieben habe gibt es jetzt mal wieder bewegte Antriebe in bewegten Bildern zusehen. Der kleine TDC läuft und das sehr Problemlos.

Ich war aber in der Zwischenzeit nicht untätig, ich hab mal wieder einen Großteil der Software umgebaut um die Regelung zu vereinfachen. Dabei raus gekommen ist ein Konzept in dem nur noch die Drehmomentregelung und der Beobachter mit 24kHz laufen. Alle anderen Regelungen und Auswertungen laufen nur mit 1kHz. Für die Drehzahlregelung welche ich z.B. neu eingebaut habe ist das vollkommen ausreichend. Damit ich aber keine Probleme mit einer Unterabtastung bekomme musste ich die 24kHz Momentanwerte mit einem Tiefpass filtern. Da ich aber nicht für alle Werte wie Spannungen, Ströme, Drehzahl und Lastmoment IIR-Filter in der 24kHz schneller Regelung berechnen wollte wurde für jeden einzelnen Momentanwert ein Puffer eingeführt. Jetzt werden die letzten 50 Werte in einem Ringpuffer gespeichert und ich kann in der langsamen 1kHz Regelung
FIR-Filter berechnen. Das reduziert den Rechenaufwand auf ein 24tel (Wenn IIR und FIR eine ähnliche Ordnung haben).

Außerdem können so Unabhängig von der Regelung Algorithmen zur Offline Parameter-Identifikation benutzt werden. In der Hoffnung die Motorparameter während des Betriebs immer genauer bestimmen zu können. Die Regelung wird davon nicht direkt beeinflusst und ggf. instabil,
sondern wenn alle Parameter auf einander abgestimmt sind können sie gleichzeitig definiert übernommen werden.

Inbetriebnahme vollständig

Es ist geschafft die Inbetriebnahme ist komplett. Alle Messungen laufen sauber und die Phasenzuordnung der Strommessungen zu den PWM-Kanälen sowie zu den Anschlüssen passt.

Es gibt aber noch ein paar Punkte die ich in einer nächsten Hardware-Version ändern würde.

• Footprint der Shunts, die Trennung von Messanschluss und Leistung ist parallel zum Shunt besser zu löten. Aktuell musste ich Silberdrahtstücke neben die Shunts löten.
• Die Pads für die Batterieanschlusskabel müssen nach außen auf der Platine, aktuell stören die Kabel über der Platine.
• Die HOTT-Pads müssen auch auf die Stirnseite neben den PPM Eingang, an der Seite sind die Pads ungünstig.
• Die Kerkos an der Brücke bei den Shunts müssen gleichmäßig gleichmäßig verteilt werden, damit die Elkos flach über die Shunts passen. Die Elkos über den STM zu legen geht aber auch sehr gut, ist vllt. auch etwas kühler also über den Shunts.
• AVDD mit Ferrit an 5V anschließen. 
• Befestigung der Goldkontakte für den Motor durch feste PADs mit Kantenmetallisierung(teuer) am Rand der Platine ersetzen. Die aktuelle Variante ist nicht so schön. 
• Vllt. BEC Stepdown durch einen Integrierten im TO-PMOD-Gehäuse ersetzen. Sowas wie den LMZ14203.
• Größere Gehäuse für die diversen Kerkos vorsehen die höheren Spannungen ausgesetzt sind.
• den JTAG/SWD Anschluss etwas weiter nach links verschieben, das der Stecker fürs Flachbandkabel sauber passt.

Die ersten Prototypen mit allen Anschlüssen (oben: 3,5mm Goldis, unten 4mm Goldies)

Aber alles in allem können diese Prototypen jetzt gequält werden. Der untere Umrichter kommt an den Motorteststand mit einem Dymond HQ6060 als Antriebsmaschine und einem Turnigy 6374
mit 192 Kv als Lastmaschine. Und dann muss diese Variante zeigen das sie die gleichen Tests kann wie der große Umrichter. Und ich bin sehr gespannt auf das Wärmeverhalten der Kleinen.

Das Ziel ist es dann beide Prototypen an je einer Maschine zu betreiben und die Energie im Kreis
zu fahren. Damit sollte mein 30V 15A Labornetzteil erstmal reichen um beide Regler ordentlich zu belasten.