Thema: Motorsteuerung und Maschinensatz mit Magnetlagern, für einige kW, kompletter Eigenbau.
Zunächst ging es darum, mit dem C2000-Discovery-Board mit TMS320F28379 (Übersicht, 227 Seiten PDF) zurecht zu kommen. Es sind nicht alle Pins des Mikrocontrollers herausgeführt. Das Board ist mit 50..80 € recht preiswert, bietet der Controller 4 32-Bit-Kerne mit Gleitkomma und je 200 MHz Taktfrequenz. Aber nicht als SMP, sondern zwei DSP320-Nachfolgern und zwei „Control Law Accelerator“ — Rechenkerne mit Spezialisierung auf Regelung — die zugeordnete Flash-Bereich für ihren Kode und Daten haben. Daneben gibt es noch einige Shared-Memory-Bereiche zur Interprozesskommunikation.
Man beachte, dass die C2000-Architektur den Trend der 80-er Jahre
folgt, mit den 16-Bit-Architekturen das Byte zu vergessen:
sizeof(int) == sizeof(char) == sizeof(wchar_t) == 1
entsprechend 16 Bit!
Der C-Compiler ist frei aber altbacken, kann nicht mal C++11.
Vom AVR und ARM ist man da schon verwöhnt, deren Compiler
können C++20 und damit den ternären Vergleich (Raumschiff-Operator)
<=>.
Auch das [[fallthrough]]-Attribut darf zum Einsatz
kommen und helfen, break nicht zu vergessen.
Zunächst stolperte ich über das Problem, dass printf()
zum Absturz führte.
Erst später habe ich gemerkt, dass es am zu knappen Stapelspeicher liegt.
So hatte ich kurzerhand printf() neu geschrieben,
mit Extras wie Festkomma-Ausgabe, Integer-Inf/NaN-Ausgabe und Zifferngruppierung.
Weiterhin wurden nach und nach die umständlich zu handhabenden
TI-C-Bibliotheken (zur Motorsteuerung) in C++ umgesetzt.
Es wurde ein Programm geschrieben,
das die Werte des A/D-Wandlers in Zahlen und mit bunten
Braille-Blockgrafikzeichen als X/Y-Graf (Oszilloskop)
auf ein Terminal ausspuckt und gewisse Eingaben erlaubt.
Prinipiell hätte man so die ganze Motorsteuerung per Terminal
steuern können, aber das sieht elend altbacken aus.
Außerdem benötigt man ein Terminal-Programm, etwa putty;
es ist lästig dieses erst installieren zu müssen.
Es war ein Windows-Programm in C++ in Arbeit,
welches eine grafische Visualisierung wie bei Max gesehen macht.
Mit schneller (10 MBit/s), ggf. isolierter Binärdatenübertragung
über die serielle Schnittstelle.
Ist aber im Corona-Lockdown in Struppen liegen geblieben.
Hatte mich bei einer eigenen Version von DrawText()
festgebissen, die (endlich mal) Subscript und Superscript
(Hoch- und Tiefstellungen), Überstreichungen sowie Farben ausgibt.
Und das überall wo Windows DrawText() ruft,
gewissermaßen als Injected Code, um nicht die
STATIC-Steuerelementeklasse
subklassifizieren zu müssen.
Entgegen dem allgemeinen Trend, alles mit XML machen zu müssen,
mit simplen, Speicher sparenden Steuerkodes.
Dafür RichEdit
zu bemühen fand ich zu schwierig — und auch zu langsam.
Ich will ja gar nicht editieren.
Überaus eklig ist dabei die Wiedergabe von Nicht-ANSI-Zeichen,
etwa griechisch.
Was mit DrawTextW überhaupt kein Problem darstellt.
In keinem Fall habe ich CPU2 oder einen der beiden CLA in Betrieb genommen. Die Erstellung des Linkerskripts habe ich in die eigene Hand genommen, da die vorgefertigten viel zu unübersichtlich sind. Die sich ergebenden Flash-Programmgrößen liegen unter 10 KByte, da ist also noch massiv viel Platz.
Ich habe zudem hinbekommen, das native-USB-Interface des C2000
herauszuführen, weil das etwas mehr Flexibilität als die
serielle Schnittstelle bietet (hier: HID und WebUSB),
unter Verlust der Potenzialtrennung.
Dazu mussten die (ohnehin standardmäßig nutzlosen) Potenzialtrenner
runtergepustet werden, wie man im Foto sieht.
Denn leider beißt sich USB mit der ersten seriellen Schnittstelle.
Es wurde ein Board dazu verwendet, bei dem der
serielle Schnittstellenschaltkreis einen Knacks weg hatte.
Ausgehend vom (völlig undurchsichtigen) C2000-USB-Maus-Beispiel wurde Stück für Stück der TI-Kode durch eigenen C++-Kode ersetzt. Dabei objektorientiert in wenigen Schichten. Eine HID-Maus eignet sich besonders gut, denn das geht nicht seriell, ist vergleichsweise einfach zu implementieren und braucht keinen (Windows-) Treiber.
Maxmaus12.zip 2021-05-30 11:02 11K Maxmaus11.zip 2021-05-25 15:17 11K Maxmaus10.zip 2021-05-23 23:39 9.5K Maxmaus1.zip 2021-05-04 15:31 74K Maxmaus9.zip 2021-05-23 15:35 13K Maxmaus8.zip 2021-05-23 03:29 17K Maxmaus7.zip 2021-05-22 01:10 24K Maxmaus6.zip 2021-05-21 16:40 31K Maxmaus5.zip 2021-05-09 18:33 53K Maxmaus4.zip 2021-05-07 18:03 54K Maxmaus3.zip 2021-05-05 23:30 57K Maximal-Maus.zip 2021-05-01 03:06 18K Maximalschaden.zip 2021-04-30 16:46 28K
Schließlich blieb Max bei seinem Softwaresystem (irgendwas in Matlab oder Simulink eingebautes) und die Zuarbeiten blieben unvollendet.
Nicht mein Verdienst ist es, die eingebauten Dezimierungsfilter mit externen ΔΣ-Wandlern AMC1204 in Betrieb zu nehmen. Dabei stellte sich das Problem, dass sowohl die Dezimierungsfilter als auch die externen 1-Bit-ΔΣ-Wandler ein Taktsignal von 20 MHz erwarten. Maximilian hatte diesen zuvor von einem Quarzoszillator (einer alten PC-Platine) generieren lassen. Dabei kam er wegen der steilen Signalflanken (?) in Teufels Küche, es kam nur Murks heraus. Ich habe daraufhin den TMS320F28379 einen sauberen 20-MHz-Takt generieren lassen (das ist mit Tastverhältnis 1:1 tricky, da die Timer nur mit max. 100 MHz laufen dürfen, aber es geht!) und speise damit sowohl den ΔΣ-Wandler als auch den Takteingang des Controllers; „Rückspeisung“ sozusagen. Es geht nicht anders: Der Takteingang kann nicht zum Ausgang werden, aber der Quarz wird obsolet und alles schön synchron. Dieses Schaltungskonzept findet in den folgenden Schaltungen mit dem 74LVC04 als Takttreiber Anwendung. Klar halte ich das für sinnvoll, so laufen Takt und Daten parallel und die Leitungslänge hat keinen Einfluss auf deren Phasenbeziehung.
Nicht ganz den im Mikrocontroller verbauten Dezimierungsfilter
vertrauend wurde ein
AMC1210
ausprobiert.
Das ist der
Chip auf der (riesigen, grünen) Adapterplatine.
Im Gegensatz zum TMS320F28379 kann dieser auch Takt ausgeben.
Nicht so recht erklärbar für mich sind die vielen
RJ45-Buchsen (Ethernetbuchsen):
Diese machen sich nicht gut in Bastelaufbauten, da sie nicht auf
Lochrasterplatten passen.
Um Mittensymmetrie für die eingebauten A/D-Wandler herzustellen
(die vom Discoveryboard mit 3,0 V Referenzspannung betrieben werden)
habe ich ersonnen, die (konventionelle) Spannungsversorgung ±15 V für die
LEM-Wandler auf 1,5 V (halbe Referenzspannung) zu fixieren.
Es erfordert umständliche und fehlerträchtige Potenzialversatzstufen,
wenn man den Shunt der LEM-Wandler an 0 V betreibt.
Am Verbindungspunkt fließen allenfalls kapazitiv eingekoppelte Ströme
durch den Spannungsteiler.
Daher bietet sich dafür doch ein OPV an.
Wurde stets abgelehnt. Kann man nichts machen. In den folgenden Schaltplänen wurden die Massen trotzdem getrennt gehalten, u.a. um diese Möglichkeit nutzen zu können.
Wurde bereits vorher an einer anderen Schaltung mit 32-Bit-Mikrocontrollerboard so gemacht. Aber auch da habe ich vor allem Skepsis geerntet, obwohl es wunderbar funktioniert hatte.
Für maximale Störarmut wurde ein passendes, konventionelles Netzteil
für potenzialgetrennte 5 V / 3,5 A, 24 V / 1,4 A und ±15 V / 0,8 A gebaut.
Ausgangspunkt war ein bereits zusammengebautes Netzteil aus Pertinaxplatten,
anscheinend aus tiefen DDR-Zeiten, es wurde modernisiert,
mit mehreren parallel geschalteten einfachen Netztrafos
sowie einem großen Rippenkühlkörper „on top“ versehen.
Neue Sicherheits-Bananenbuchsen wurden mit 19 mm Abstand
eingebaut, damit gängige BNC-Adapter passen.
Der Schaltplan ist trivial: Es sind nur bekannte Festspannungsregler verbaut.
Die Zwischenkreisspannung kommt aus einem gesonderten, großen einstellbaren 19"-Labornetzgerät. Die 24 V dienten historisch zur Speisung der DC/DC-Wandler für die Gate-Treiber; inzwischen wurden diese auf solche mit 5 V Primärspannung umgestellt, sodass USB genügt. Allenfalls die ±15 V dienen zur Stromversorgung altmodischer LEM-Wandler. Auch diese gibt es mittlerweile für kleinere, nicht nullsymmetrische Spannungen.
Pardon, Doppelzitat: Hier stand es zuerst.
Hier habe ich mich nur um das Leistungsteil gekümmert.
Ausgangspunkt ist ein Rippenkühlkörper mit 160 × 100 mm Montagefläche,
zu dem die Platine parallel angeordnet wird.
Die Montage der Transistoren erfolgt mittels Durchschraub-Löchern
und geeignet gebogenen Anschlussbeinchen,
genauso wie in Umrichtern und HF-Generatoren
(für Plasma in Vakuumkammern im Reinraum) gesehen.
Da gab es den Reinfall mit der Leiterplattenfirma,
die eine Cu-Innenlage weggelassen hat!
Zu spät bemerkt musste ich alles wieder 'runterlöten.
Herausragendes Merkmal dieser Platine sind beidseitig aufgelötete Kupferdrähte zur Bereitstellung von genügend Querschnitt. Hier wäre es besser, wasserstrahl-zugeschnittene Kupferblechstreifen aufzulöten, ist weniger fummelig. Die Autoindustrie macht das effektiv genauso bei Lampenhaltern, dort sind die Blechstreifen aus billigerem Material, freitragend und durch die Plastkonstruktion isoliert. Weiterhin sind die Löcher für die Anschlüsse der Transistoren im TO-220-Gehäuse mit Durchkontaktierungs-Nieten versehen. Der Erfahrung nach sind die Endstufentransistoren schnell mal „zerforscht“, und dann will man nicht auch noch die Platine riskieren.
Der Schaltplan passt kaum auf eine (A4-)Seite. Die SMD-Bestückung ist beeindruckend. Eine Bestückungsvariante mit Dioden zur Bootstrap-Speisung der Gate-Treiber erspart 6 der 7 DC/DC-Wandler, unter Verzicht auf Gleichstrom-Beaufschlagung der Dreiphasen-Ausgänge. (Braucht man IMHO für Motoren nicht.)
Ausgangspunkt ist hier nicht das C2000-Discovery-Board, sondern eine 500 € teure ControlCARD des Nachfolge-Controllers TMS320F28388 (Übersicht, 309 Seiten PDF) mit 5 Kernen: Ein ARM-Kern ist dazugekommen (CM = Connectivity Manager genannt), dazu Ethernet und EtherCAT. Bei USB hat sich nicht viel getan: Immer noch nur 1 Port Full-Speed, nur dass dieser sowohl von CPU1 und dem Arm-Cortex-M4-Kern ansprechbar ist. Auf einer länglichen Basisplatine, die die Potenzialversetzer drauf hat und ansonsten nur Steckverbinder.
Später (2206xx) wurde der Luftkühlkörper durch ein Wasserkühlrohr ersetzt.
Damit verschwindet aber auch die Möglichkeit eines (vorgesehenen,
lüfterlosen) Wandeinbaus.
Davon existiert kein CAD-Modell, weil nicht von mir erstellt.
230206: Wie es scheint ist da etwas nass geworden. Bei lausigen 80 V Betriebsspannung. Daher erstmal: Keine Glimmerplättchen bei Wasserkühlung verwenden. (War ja für Luftkühlung konstruiert worden.) Die Glimmerplättchen wurden durch einen durchgehendes Stück chinesisches Isolierband ersetzt, die Transistoren mit Silikonkleber festgeklebt und mit Nylonschrauben festgeschraubt. Dabei entsteht immer noch ein Loch in der Isolierlage. Dagegen hilft allenfalls eine Federklemme. Für jene ist eine Neukonstruktion des Kühlrohres erforderlich, mit aufgerichteten Transistoren. Ich gehe davon aus, dass die vorher verwendete Wärmeleitpaste leicht hygroskopisch ist. Silikonkautschuk ist da die sicherere Lösung gegen Feuchtigkeit. Eine ganz andere Möglichkeit ist der Ersatz der MOSFETs durch solche im vollisolierten TO220-Gehäuse.
Weiterhin (2211xx) wurde der Einbau in ein 19"-Gehäuse beschlossen. Und zwar in den gleichen Bausatz wie beim folgenden Exemplar. Dafür braucht es allerdings eine andere Grundplatte (andere Schraublöcher) sowie eine andere Rückwand (andere Durchbrüche für Wasserkühlung).
230512: Einer der 12 Endstufen-Transistoren der einen Platine hat Kurzschluss. Typ: IRFB4127: n-Kanal-MOSFET, 200 V, 76 A, 0,017 Ω @ 10 V, TO-220. Bei fehlenden Restexemplaren muss nachbestellt werden.
CAD-Daten Gehäuse1: Bodenplatte und TODO Rückwand, alle anderen Bauteile entsprechen Gehäuse2.
Auch hier habe ich mich um das Leistungsteil gekümmert und zusätzlich um den Einbau in ein vorhandenes 19"-Leergehäuse. Statt der einen Platine mit 4 Lagen à 70 µm sind nunmehr drei Platinen entwickelt worden, eine mit 6 Lagen à 105 µm unter Verzicht auf aufgelötete Kupfer-Verstärkungen, und zwei Hilfsplatinen. Hauptgrund sind die größeren Endstufentransistoren im TO-247-Gehäuse, die nicht mehr sinnvoll nebeneinander passen. Auch musste auf Durchkontaktierungsniete verzichtet werden, da es für TO-247 nichts passendes gibt. Von Vorteil ist, dass die Gate-Treiber und A/D-Wandler durch den 3D-Aufbau näher an die Transistoren rücken können. In Verbindung mit der Wasserkühlung wurde dennoch der Bauraum gut ausgenutzt. Auf Zwischenkreis-Spannungsmessung und Summenstrommessung mit LEM-Wandlern wurde verzichtet, dies war ursprünglich auf einer gesonderten Platine vorgesehen. Die beiden letzten noch freien der insgesamt 16 vorgesehenen Analogeingänge der ControlCARD messen den Strom durch das Axiallager. Für die A/D-Wandler kommt der Nachfolgetyp AMC3306 zum Einsatz, der eine eingebaute Primärstromversorgung hat.
Da die längliche Basisplatine mit den Steckverbindern passend zum luftgekühlten 2×2-System beibehalten werden sollte, ergeben sich abenteuerlich anmutende Flachbandkabel-Adapter. Diese sind ebenfalls als Schaltplan dokumentiert.
Zusätzlich ist noch eine reine
Doppel-Analogverstärkerplatine
±50 V, ±10 A mit
TDA7293
und gesonderter Wasserkühlung für das Axiallager eingebaut.
Diese kann mit Jumpern J1 bzw. J2
im Modus Ausgangsspanungsregelung
oder Ausgangsstromregelung betrieben werden.
TODO: Die Schwingneigung im Modus Stromregelung
muss noch untersucht werden
und hängt sehr von der Lastimpedanz ab.
Eagle- und CAD-Daten für das erste Gehäuse:
von Maximilian gelieferte CAD-Daten für das erste Gehäuse.
Während beim ersten Gehäuse wegen defekter Wasserstrahlanlage
sämtliche Durchbrüche mühsam (und nicht sonderlich maßhaltig)
von Hand gefertigt werden mussten, erfolgte bei den weiteren Exemplaren
der vorgesehene Wasserstrahl-Zuschnitt mit CAD-Daten aus SolidEdge.
Damit sind verdrehsichere angefaste Löcher sehr einfach möglich.
Zudem wurde eine Lochraster-Platine unter die BNC-Buchsen gesetzt
und dazu die 5 Durchbrüche im Zollraster angesetzt.
CAD-Daten zweites Gehäuse
mit wasserstrahl-geschnittener Frontplatte, Rückseite und Bodenplatte.
Bei dem Modell für die Original-Bodenplatte (nicht: Grundplatte)
wurde auf die Modellierung
der Lüftungsschlitze verzichtet, weil sonst der Rechner abkackt.
Mit selbst gebauten und programmierten Motorsteuerungen habe ich mich schon oft beschäftigt. Sowohl für Schrittmotoren als auch für BLDC; letztere sind diesem Problem (Raumzeigermodulation) ähnlich.
