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.