Samstag, 28. Januar 2017

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.

Donnerstag, 19. Januar 2017

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.



Donnerstag, 5. Januar 2017

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.