Hallo Zusammen,
ich habe eine offene Firmware für einen FOC-Controller, der in vielen
"Baumarkt"-EBikes wie Fischer, NCM, Prophete... verbaut ist geschrieben.
In dem Controller werkelt ein STM32F103.
Das Ganze läuft robust und hat auch schon einige zufriedene Nutzer :-)
https://github.com/EBiCS/EBiCS_Firmware/wiki
Wir kämpfen aber noch mit einem sporadischen hörbaren "Ticken" bei
einigen Motoren.
https://www.pedelecforum.de/forum/index.php?attachments/vergleich-pll-und-extrapolation-zip.378415/
In dem Hörbeispiel kurz vor Schluß. Das Ticken ist eigentlich nur ein
"Schönheitsfehler" der Motor zeigt keine Drehzahlschwankung oder so.
Ich habe schon versucht durch Interruptpriorisierungen und Abschalten
der Interrupts in kritischen Code-Bereichen eine Verbesserung zu
erzielen, leider ohne Erfolg.
Was kann die Ursache für solche zufälligen, nicht reproduzierbaren
Störungen sein und wie kann man die Identifizieren? Ich bin grad mit
meinem Latein am Ende...
Gruß
hochsitzcola
hochsitzcola schrieb:> zufälligen, nicht reproduzierbaren Störungen
a) MOSFET Entsättigungserkennung einer der MOSFET-Treiber schlägt zu.
* Stromregler-Parameter passen nicht zum Motor, Regler schwingt
* Totzeit zu klein gewählt
* Strommesszeitpunkte passen nicht zum Schaltpattern, Stromregler
bekommen falschen Input
b) Sporadische Fehlkommutierung
* Softwarefehler, Überlauf oder Wert außerhalb normalen Bereichs oder
falsche Implementierung eines Winkelfilters lässt das führende
Winkelsignal kurz hin-und herspringen
* Sensorfehler lässt lässt das Winkelsignal springen
* Softwarefehler, Überlauf o.ä. führt zu falschen PWM-Patterns
* Logischer Softwarefehler, z.B. Strategie
FlatTop-FlatBottom-Umschaltung kommt zum falschen Zeitpunkt
* Logischer Softwarefehler, z.B. ganz bestimmte Ua-Ub-Kombinationen
führen zu falschen PWM-Patterns
c) Fehler im Variantenhandling
...
Kannst du Signale in der Software in originaler Samplefrequenz abgreifen
und anzeigen?
Also nicht asynchron übern Debugger sondern synchron mit dem
PWM-Perioden-Interrupt? Nur so bekommt man solche Laufzeitfehler
aufgedeckt.
Wenn nein, Hierzu kannst du von NXP z.B. den "Freemaster" benutzen, das
ist sozusagen eine OnTarget-Speicheroszi-Funktion. Gibt es kostenlos,
ist einfach zu konfigurieren und einfach integriert. Achtung, Variablen,
die man liest, sollten innerhalb gerader 4byte-Grenzen liegen, das liegt
am Speichermodell von dem Ding. Eine Serielle Schnittstelle genügt zur
Kommunikation und man braucht ein paar K RAM Und ROM. Die Motor- und
Algorithmen-Experten auf der Arbeit benutzen es ziemlich gern.
mfg mf
PS
hochsitzcola schrieb:> Ich habe schon versucht durch Interruptpriorisierungen und Abschalten> der Interrupts in kritischen Code-Bereichen
Ich hoffe doch inständig, dass die Nebenläufigkeit, Synchronisation und
Parallelität sowieso schon mit passenden Synchronisations-Methoden
eingefangen wird. Abschaltung der Interrupts kann übrigens wegen
Interrupt-Latency genau zu deinem geschilderten Knackser-Problem führen.
Double-Buffer hilft da beispielsweise...
Ich würde mir auch zuerst die Software ansehen. Und zwar in erster Linie
die Sensordatenverarbeitung, insbesondere um Umfeld der Kommutierung und
Stromregelung. Neben den schon genannten Punkten wie Überläufen usw. ist
Präzisionsverlust bei Fließkommazahlen (wenn verwendet) eine beliebte
Quelle für "komisches" Verhalten. Wenn beispielsweise der Motorwinkel,
der für die Kommutierung verwendet wird, nach 360° nicht wieder bei Null
anfängt, sondern immer weiter steigt (was ja theoretisch keinen
Unterschied macht), geht irgendwann Präzision verloren.
Ich habe jetzt nur mal in die "FOC.c" reingeschaut. Da verwendest du ja
scheinbar eh schon ein Festkomma-Format.
Eine andere beliebte Baustelle ist der I-Anteil im Stromregler: Durch
die Stellsignalbegrenzung der Endstufe kann es sein, dass der I-Anteil
immer weiter anwächst, obwohl die Endstufe schon auf Anschlag ist. Die
Zeit, die es braucht, um den I-Anteil wieder zu "leeren" kann dann auch
zu komischen Effekten führen. Hier sollte der (vermutlich PI-)Regler
einen Mechanismus haben, der das Anwachsen des I-Anteils in den
Stellsignalgrenzen verhindert (Stichwort Anti-Wind-Up).
Danke für eure Hinweise, die muß ich erst mal nachvollziehen und
versuchen was draus zu machen. Ich bin Maschinenbauer und mache die
ganze Programmiererei in keinster weise professionell, suche mir in der
Regel aus code-Beispielen was zusammen.
Da der verwendete STM32F103C6T6 keine FPU hat, habe ich inzwischen
jegliche floats rausgeschmissen, da er nur 32kB Speicher hat, verzichte
ich auch auf Sachen wie FreeRTOS. Für die FOC-Arithmetik nutze ich die
CMSIS Festkomma-Funktionen. Damit gibt es kein Problem mit
Winkelüberläufen, da hier die -180° bis +180° auf -2^31 bis +2^31
abgebildet werden.
Im PI-Regler ist der I-Anteil auch beschränkt, der kann nicht davon
laufen.
Mal schauen....
Bisher mache ich die Motor-Hall-Sensor-Auswertung mit EXTIx Interrupts.
Ich versuche gerade, das auf Input Capture von timer2 umzubauen, aber
ich bekomme noch nicht zu jeder Zustandsänderung einen Interrupt.
Irgendwie habe ich die XOR Funktion für IC Channel 1 noch nicht richtig
initialisiert....
Gruß
hochsitzcola
