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
:
Bearbeitet durch User
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.