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.