Montag, 27. August 2018

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.




Mittwoch, 12. April 2017

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....

Sonntag, 9. April 2017

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.

Freitag, 7. April 2017

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.

Donnerstag, 2. Februar 2017

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!


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.

Dienstag, 20. Dezember 2016

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. :)