Brushless-Fahrtregler: Grundlagen und Nachbau

    • Offizieller Beitrag

    Vorneweg, mein Kenntnisstand was das angeht ist solides Halbwissen und generell eher Anwendungsorientiert.

    Zitat von Lars

    Sowas geht natürlich nicht mit einem 6S- oder 12S-Akkupaket (und im Zweifel einigen hundert A Kurzschlussstrom), dazu nutzt man ein regelbares, strombegrenzendes Netzteil (NT) und eine Möglichkeit, die Drehzahl (bzw. PWM) langsam von 0 auf max. zu erhöhen. Der Motor ist dabei fest auf einer Position zu blockieren (nicht mit der Hand) und die Strombegrenzung am NT langsam zu erhöhen. Idealerweise kann man den Strangstrom messen oder zumindest den Batteriestrom am NT ablesen. Nun werden Ansteuerung und NT-Strombegrenzung schrittweise erhöht und zwar maximal solange, bis an den beiden betreffenden MOSFETs (1x H-FET, 1x L-FET) 60 °C erreicht werden. Jetzt geht es darum, die 60 °C zu halten (ggf. die Ansteuerung / PWM schrittweise anpassen) und parallel den Strangstrom zu ermitteln und als reellen Stromwert zu notieren.

    Dabei darf die Elektronik des Controllers aufgrund einer wirksamen Strombegrenzung nicht beschädigt werden, sonst taugt er meiner Meinung nach ohnehin nichts...

    Der Test geht an den Bedingungen im Bot ziemlich vorbei. Die meisten erfolgreich im Bot eingesetzten Systeme würden den Test entweder durchfallen oder nur aus Versehen bestehen. Mit aus Versehen meine ich sensorlose Systeme, da habe ich keine Ahnung wie die sich in einem solchen Szenario verhalten würden.

    Das Szenario Motor blockiert gibt es eigentlich nicht im Roboter, zumindest nicht freiwillig. Ausnahme sind vielleicht noch irgendwelche exotischen Waffensysteme. Alles andere ist zu leichtgängig um durch einen blockierten Motor dargestellt zu werden. Ant/Beetle/Raptor sind alle verbreiteten Brushless Setups sensorlos und üblicherweise auch ohne Strombegrenzung. Bei den Feathers funktioniert sensorlos und ohne Strombegrenzung auch wunderbar, nur bei den hierzulande beliebten Radnabenmotoren bringt ein Setup mit Sensor deutliche Vorteile. Die Strombegrenzung der Vesc würde ich hier eher als nice to have als ein muss bezeichnen. Nur bei (Middle- und) Heavyweight hat sich die Meinung durchgesetzt, dass man eine Strombegrenzung braucht (Ausnahme: Endgame). Was ich bei Battlebots gesehen habe sind auch einige im Heavy sensorlos unterwegs, obwohl die Motoren teilweise sogar Sensoren verbaut haben. Die Gefahr, dass ein Sensor im Kampf ausfällt etc und dadurch das System komplett ausfällt wird als kritischer bewertet, als die (vermutlich kaum spürbaren) Performanceverluste durch den sensorlosen Betrieb.

    Wenn man sich auf Prüfstandstest einlässt macht es meiner Meinung nach nur Sinn ein Lastprofil in einem Kampf aufzuzeichnen und dieses anschließend auf dem Prüfstand zu simulieren.

    Als Entwickler kenne ich zunächst nicht den Anwendungsfall und muss meine Schaltung auf worst-case testen. Der Stall-/bzw. Blockadestrom eines Motors wäre ein Ansatz, natürlich geht auch eine rein ohmsche Last. Eine blockierte Motorwelle ist ein Fall, der leicht vorkommen kann, z.B. bei einem Elektroroller der fest steckt. Ein Controller darf dabei nicht beschädigt werden und muss im Zweifel mit der maximalen Stromstärke an der Strombegrenzung versuchen, den Motor abzudrehen. Gute Systeme messen FET- und Motortemperatur und würden, wenn der Anwender nicht eingreift, das System ab einer bestimmten Temperatur abregeln. So würde selbst bei einer Motorblockade weder der Regler noch der Motor beschädigt werden...

    Allerdings habe ich keine Ahnung, wie das in der Praxis in den versch. Bot realisiert wird und wie die Anwender damit umgehen. Die spezielle Anwendung ist dann immer eine Einzelfallbetrachtung, die sogar mit dem gleichen Regler bei versch. Bot zu versch. Ergebnissen führen kann. So kann man keinen Regler bewerten, für mich zählen die nackten Zahlen. Der von mir vorgeschlagene Test war nur ein Beispiel, wie ihn die meisten ohne besondere Messmittel durchführen können. Bereits die Erkenntnis ein strombegrenzendes Netzteil einzusetzen, anstatt in der Versuchsphase dicke Akkupacks anzuklemmen, wäre ein riesen Vorteil.

    Vermutlich liegen meine Bedenken darin begründet, als Entwickler völlig andere Maßstäbe anzusetzen, als ein reiner Anwender. Mir geht es mehr um die Schaltungstechnik und um die Belastungsgrenzen. Einen kaum belasteten Motor aufzutouren ist eher kein Problem, da, wie ich bereits geschrieben hatte, die Verluste auf alle FETs schön gleichmäßig verteilt werden. Viel interessanter ist es, den aufgetourten Motor bis zum Stillstand - also bis zur Motorblockade - abzubremsen, ohne das dabei etwas beschädigt wird.

    Meine Vorgehensweise sieht eben nunmal vor, Motor und Controller auf einem Prüfstand zu testen, bevor ein Einbau stattfindet. Dabei stellt sich oftmals heraus, dass der betreffende Controller nicht tauglich ist. Das hat mich in der Vergangenheit gefrustet, weshalb ich dann auch bestimmte Projekte nicht weiter verfolgt habe.

    Mir fehlt etwas die Zeit, aber in den nächsten Tagen möchte ich ein neues Thema zur Brauchbarkeit von BLDC-Controllern eröffnen ... schau'n mer mal...

    • Offizieller Beitrag
    Zitat von Lars

    Motor und Controller auf einem Prüfstand zu testen, bevor ein Einbau stattfindet.

    Ich bin prinzipiell bei Dir. Aber leider gibt's dann manchmal in der Praxis noch ein paar Effekte, die man am Prüfstand irgendwie nicht feststellen konnte. Mein aktuelles Problem: Ein Gefährt rollt bergab und wird zu schnell. Also irgendwie über den Motor bzw. dem Fahrtregler bremsen.

    Erster Schritt (neben einer manuell auslösbaren Motorbremse): Sobald der Motor im Generatorbetrieb ist, produziert er eine höhere Spannung als die (geladene) Akkuspannung. Die Betriebsspannung kann ich messen. Bei manchen Fahrtreglern funktioniert dann diese "automatische" Bremse, bei anderen wieder nicht. :wacko: => Hat jetzt mit BL-Fahrtreglern nichts zu tun, aber nur der Hinweis, dass man am Prüfstand soviel testen kann wie man will.... im sogenannten "Feldtest" zeigt sich dann erst die Brauchbarkeit.

    (Wobei ich Dir zustimme, dass viele Hersteller von irgendwelchen Geräten/Baugruppen wohl niemals einen Prüfstand-Test gemacht haben müssen, so marode und unbrauchbar die Teile ausgeliefert werden....)

    Mein eigener BL-Regler ist ja noch weit von einem Layout entfernt. Aber ich würde hier auf die bewährten MOSFET-Halbbrücken (BTN8982) von den Brushed-Reglern zurückgreifen. Können jeweils 55A, das ist im praktischen Betrieb bewiesen (Motoren mit 400 bis 500W, Anlaufstrom kein Problem) und auch durch Messungen mit der Stromzange. Die interne Strombegrenzung bei 55A funktioniert. Einziges Manko: Sobald am Ausgang der MOSFET-Halbbrücke eine Spannung "eingespeist" wird, mögen das die Bauteile gar nicht. Also ableiten mit Supressordioden, etc....)

    Wie Du o.g. beschrieben hast, bin ich kein Freund von Interrupts bei den µC. Hatte damit nur Ärger. Nachdem der gepante Eigenbau-BL ausser mir sowieso niemand haben wollen wird, ist es egal, ob ich Material für 70 Euro oder 100 Euro investiere. Entsprechend werde ich nach derzeitigem Konzept wohl drei µC verbauen. (1: Empfänger-Signale auswerten + Solldaten + Regelgrößen erreichnen / 2: Ansteuerung MOSFET-Endstufen / 3: Erfassen Encoder-Signale und Ist-Größen errechnen.) Ob das Konzept aufgeht, das muss sich zeigen. :saint::?: Ich hänge halt an den 8bit-PICs, möchte auf meine alten Tage nicht auf ein neues System umlernen müssen.

    Zitat von IBF

    Mein aktuelles Problem: Ein Gefährt rollt bergab und wird zu schnell. Also irgendwie über den Motor bzw. dem Fahrtregler bremsen.

    Das kenne ich nur zu gut! Da ich bereits mehrere BLDC-Controller entwickelt habe, weiß ich ungefähr woran das liegt.

    Zunächst einmal gibt es grundsätzlich 2 Arten hallbasierte BLDC-Controller (Rekuperation dabei unbetrachtet), welche auf die jeweilige Anwendung abstellen:

    1.) Einsatz im eScooter- / Elektroroller = unbelastetem Generator (Typ1)

    Hierbei handelt es sich zumeist um Personenbeförderung. Die Ansteuerung erfolgt derart, dass mit schlagartiges Gas-Wegnehmen oder Bremsen in einen Freilauf geschaltet wird (Freigabe sämtlicher MOSFETs). Das entspricht einem unbelastetem Generator, dass Fahrzeug rollt bis zum Stillstand gemütlich aus.

    2.) Einsatz im Bot = kurzgeschlossener Generator (Typ2)

    Das ist eine völlig andere Art der MOSFET-Steuerung. Hierbei erzielt man eine Motor-Reaktion mit sehr hoher Dynamik, sodass beim Gas-Wegnehmen oder Bremsen der Motor SOFORT stehen bleibt. Nebenbei: Darüber hat sich hier im Forum mal ein User gewundert, weil der Motor sofort stehen blieb, als er an der Funke das Gas rausgenommen hat... (offenbar kannte er nur die erste Variante der Ansteuerung und war ob der schärferen Reaktion etwas irritiert...).

    Bei dieser Art der Ansteuerung kann es auch zu einer Überhöhung der Betriebsspannung kommen, was trotzt Body-Diode in den MOSFETs u.a. abhängig vom Ri der Stromquelle und Querschnitt / Länge der Zuleitungen sein dürfte (Tipp: die MOSFETs sollten ein paar Volt mehr abkönnen, Erfahrungswert: 75V-MOSFET (Uds) = max. 55V Ub).

    Somit ist auch klar, dass die Controller zu den o.g. Anwendungen nicht immer kompatibel sind! Beispiel: Würde der Fahrer eines E-Rollers (mit einem absichtlich / versehentlich verbauten Typ2-Controller) das Gas rausnehmen, würde der E-Roller quasi eine Vollbremsung machen (keine Rekuperation, da der Motor nur über die Low-FET der Halbbrücken kurzgeschlossen wird und der Strom nicht über die Batterie fließt) - Folge: Der Fahrer würde möglicherweise stürzen.

    Umgekehrt sollte ein Bot spontan und dynamisch auf Steuerbefehle reagieren und eben nicht gemütlich ausrollen... (aus diesem Grund steuern vermutlich einige schnell von Vorwärt auf Rückwärts, um das zu kompensieren).

    Aber wie werden jetzt die MOSFETs bei Typ2 angesteuert?

    Der erste Anwendungsfall ist klar, bei Gas = 0 sind die MOSFETs ohne Ansteuerung und der Motor tourt ab (Freilauf, nur durch Rollwiderstand etc. belastet).

    Die andere Ansteuerart ist härter und erinnert ein wenig an eine Steuerung für einen Schrittmotor, weil die Reaktion des Motors schlagartig ausfällt und jedem Steuerbefehl sofort folgt. Vereinfacht gesagt wird beim Abtouren des Motors in den Pausen der Ansteuer-PWM der Motor über die L-FETs kurzgeschlossen. Aber es wird nicht einfach nur kurzgeschlossen, während der H-Pulse wird die aktive Bestromung (abnehmend) aufrecht erhalten, jedoch werden die H-Pulse vom Tastverhälnis ggü. den L-Pulse sehr schnell immer kleiner, bis bei PWM= 0 nur noch die L-FETs dauerhaft aktiv sind und den Motor blockieren bzw. schwergängig machen (Generator bleibt kurzgeschlossen bis PWM <> 0 wird!).

    Bei Reiner keimt jetzt mutmaßlich die Frage auf: Wird damit verhindert, dass das Fz. bergab zu schnell wird? Antwort: Jaein! Denn: Bei gleicher Gas-Knüppelstellung könnte das Fz. bergab tatsächlich schneller werden. Würde jedoch Gas zurückgenommen, verzögert auch das Fz., da der PWM-L-Anteil den Motor zunehmend kurzschließt, ggf. bis zum Stillstand mit PWM= 0. Das Fz. würde vermutlich bergab stehen bleiben, oder langsam bergab rollen (je schneller das Fz. rollt, desto größer die Bremswirkung!).

    Hier sieht man auch den Unterschied: mit einem Typ1-Controller rollt das Fz. bei Gas= 0 weiter bergab, wogegen das Fz. mit einem Typ2-Controller bergab stehen bleibt. Aus diesem Grund braucht ein Typ1-Controller vermutlich auch eine (dosierbare) Motorbremse oder der Fahrer muss eben rückwärts steuern.

    Die Lösung für Reiners Problem könnte so aussehen: Der Einsatz eines Typ2-Controllers mit Regelkomponente, anstelle einer reinen Steuerung! Das ginge recht einfach, weil alle benötigten Teile im Prinzip vorhanden sind, hat aber etwas Programmieraufwand zur Folge und - oh Schreck - ich würde das mit Interrupts erledigen...

    Das Prinzip:

    Aus den Hallsignalen wird eine Drehzahlinformation gewonnen, im einfachsten Fall wird ein Hallsignal auf einen IRQ-Eingang gelegt und mit jeder Flanke in der Interruptroutine ein Timer ausgelesen / neu gestartet und der aktuelle Wert in eine Speicherzelle eingetragen (z.B. Wertebereich 0...100 für 0...100 %). Das Hauptprogramm liest permanent den gespeicherten Wert und vergleicht das mit der Vorgabe der Funke. Sowie der Istwert (Drehzahl) > Sollwert (Funke) ist, wird die PWM-Ansteuerung der MOSFETs deaktiviert und der Motor (jetzt Generator) über die L-FETs aller 3 Halbbrücken sofort kurzgeschlossen. Folge: Bergab würde das Fz. jetzt nicht mehr schneller werden. Sowie Istwert wieder <= Sollwert ist, werden die L-FETs freigegeben und die PWM-Ansteuerung übernimmt wieder die Bestromumg des Motors.

    Das Problemchen:

    Die auftretenen Bremsströme beim Typ2-Controller können größer werden, als der eigentliche Motor-Strangstrom bei max. Beschleunigung, was insbesondere die L-FETs stärker belastet, da diese den Kurzschlußstrom verdauen müssen.

    Zudem kann aus sehr hoher Drehzahl der Motor bei Gas= 0 nicht einfach brutal kurzgeschlossen werden, Motor und Ansteuerelektronik könnten beschädigt werden! Mit zunehmender Drehzahl muss der Bremsstrom also auch noch getaktet werden, wobei in den L-Phasen der Kurzschlußstrom über die L-FETs fließt, und in den H-Phasen leider in die Batterie - was zu einer Spannungsüberhöhung an den FETs führen kann.

    Dazu kommen dann auch noch andere nette Effekte, z.B. das der Bremsstrom in die Batterie die Stromrichtung (und damit Polarität) umkehrt und damit der Überstrom über den üblicherweise im Massezweig vorhandenen Strombegrenzungs-Shunt nicht registriert wird, weil die nachgeschaltete Elektronik in der Regel einen positiven Spannungswert zur MOSFET-Strombegrenzung benötigt. Hier könnte der aufmerksame Leser jetzt einwerfen, dass dies ja keine Rolle spielen würde, weil ja auch keine MOSFETs zu exakt diesem Zeitpunkt angesteuert sind. Das stimmt vermutlich, bedauerlicherweise fließt dann aber Strom aus dem Generator über die in dem Power-MOSFETs integrierten Body-Dioden in die Batterie und sorgt dabei für eine höhere Verlustleistung (= höhere FET-Erwärmung) als wenn der Strom über die parallel zur Body-Diode angeordnete MOSFET-Strecke laufen würde...

    Naja, hoffentlich ist mein Geschreibsel halbwegs verständlich, immerhin bin ich hier ja im Bereich BLDC-Grundlagen, da darf es etwas ausführlicher sein.

    Als Käufer eines BLDC-Controllers müsste man sich meiner Meinung nach erstmal klar machen, welchen Typ man da eigentlich gekauft hat, bevor man das Zeugs in einen Bot verbaut. Auch hierzu ist mein Tipp hilfreich: Prüfstand aufbauen und erste Tests mit einem strombegrenzenden Netzteil durchführen kann nie schaden ...

    • Offizieller Beitrag

    Danke für die Erläuterungen. Soweit bin ich da schon bei Dir. Kurz mein Wissens- und Entwicklungsstand, auch zu o.g. Problem mit der Bergabfahrt.

    - kein BL-Regler verwendet, sondern "Eigenbau" für Bürstenmotore

    - Verwendete Motore sind mehrere Typen im Gebrauch. Manchmal werden pro Antriebsseite auch zwei Stück parallelgeschaltet (Also Größenordnung 4 x 270W). Andere Anwender (z.b. mit Kettenantrieb) verwenden 2 x 450W-Motore. Aber mit Schneckengetriebe. Durch die Selbsthemmung gibt es da kein beschleunigtes Bergabfahren.

    - Die o.g. Body-Diode ist nach meinem Geschmack zu lausig (=leistungsarm). Jeder MOSFET-Ausgangskanal (Pin) hat deshalb zwei separate Supressordioden. Die sind spannungsmäßig so "mittig" ausgelegt. Z.B. bei maximal 28.8V-Betriebsspannung (2x BleiGel-Batterien mit je 12V und 24V Lichtmaschine zum Laden => 28.8V Ladespannung): 33V-Supressor-Nennspannung. Je nach Supressor-Typ fangen die bei 33.x Volt schon an, ein bißchen zu leiten. Andere Typen brauchen schon mal 36V, um sich bemerkbar zu machen (P6SMP 33C). Anfangs verwendete ich bidirektionale Dioden, also in beiden Richtungen die 33V zu überbrücken. Durch die letzten Probleme mit der Bergabfahrt verwende ich unidirektionale Dioden, also mit Ableitung in Flussrichtung bei negativen Strömen. War leider nicht die Lösung des Problems.)

    - Bremsen ist bei mir immer gepulst. (Stichwort: Stotterbremse). Sowohl die Anzahl der Bremspulse als auch die Pulslänge lassen sich über den PC von jedem Anwender selber parametrieren. Bei kleinen Motoren oder bei Motoren mit selbsthemmenden Getrieben kann damit Bremszeit gespart werden. Die Maschine lässt sich also schneller in Gegenrichtung umsteuern.

    - Mittlerweile ist die Stotterbremse mit kontinuierlich ansteigender Brems-Pulsbreite programmiert. Also zunächst nur "ganz kurze" Pulse, damit bei den fließenden 55A der MOSFET nicht allzu viel Verlustleistung abkriegt. Dann mit Puls-Pause-Verhältnis 1:2 die Bremspulse. Und final dann Puls-Pause-Verhältnis mit 1:1. Hier fließen dann im Idealfall keine 55A mehr. (Hab' mir extra für das Oszi eine schnelle (und schweinsteure ;( ) Stromzange gekauft, um die Pulse exakt vermessen zu können.) Der Vorteil von den verbauten MOSFET-Halbbrücken ist, dass hier der Strom auch beim Bremsen begrenzt wird. Seltsamerweise schaltet der MOSFET aber nicht ab, sondern der Strom bleibt "konstant". Heißt aber für mich, dass der arme MOSFET hier die Bremsenergie in Wärme umwandeln muss.

    - Damit beim Beschleunigen und Bremsen die Wärmeverluste einigermaßen gleich auf die beiden MOSFET-Halbbrücken verteilt werden, ist eine Aufteilung erfolgt. Eine MOSFET-Halbbrücke (Nr.1) wird mit der PWM vom Controller angesteuert. Der muss sich praktisch um die Geschwindigkeit kümmern. Wird auch ein bißchen warm dabei. Beim Bremsen wird diese MOSFET-Halbbrücke voll durchgeschaltet. Die Bremspulse muss jetzt der L-Teil der zweiten MOSFET--Halbbrücke übernehmen. Bei zackigen Vorwärts-Rückwärtswechselbetrieb wird diese MOSFET-Halbbrücke auch warm.

    Im Unterschied zu manch anderen Bürsten-Fahrtreglern wird der Motor nur aktiv von dem ausgegebenem Puls der Endstufe bestromt. In der Pulspause läuft er "leer". Also wie von Dir o.g. beschrieben, rollt die Maschine dann relativ locker weiter und hemmt sich nicht selber, als wenn in der Pulspause ein Kurzschluss ( wäre Bremse) ausgeführt würde. Ich hatte mal von Sabbertooth einen Regler zum Testen (und einen zweiten zum Reparieren). Der macht das anders. Also immer die MOSFETs durchsteuern. Sowohl im Puls, als auch in der Pulspause (Kurzschlus der Motorwicklungen) Damit hängt der Motor bei kleinen Geschwindigkeiten "gut am Gas", aber mir kommt es dann so vor, als wenn ich beim Autofahren immer kontinuierlich Vollgas fahre und die Geschwindigkeit mit der Bremse reguliere.... <X

    Gestartet habe ich bei o.g. Bergab-Bremsproblem mit einer automatischen Bremse, die immer dann aktiv ist, wenn eine vorgegebene Schwelle der Sollvorgabe unterschritten ist. Z.B. 50%. Also bei langsamen Geschwindigkeiten. Der Motor bremst dann zyklisch durch Auslösen der Stotterbremse. Das nervte aber den Anwender, wenn er "auf der Ebene nur mal langsam" fahren wollte.
    Zweiter Schritt: Eine manuelle Bremse (von der Fernsteuerung auszulösen). Aber das war zu wenig komfortabel, weil immer extra bei jedem Bremsvorgang von der Funke manuell ausgelöst werden muss.

    Die dritte Variante war dann die Messung von der Betriebsspannung, wenn die Maschine bergab rollt und der Motor dann Überspannung produziert. Bei Überspannung wird die Bremse aktiviert. Seltsamerweise funktioniert das je nach Maschine mal sehr gut oder (bei anderen Maschinen an einem längeren Hang) nicht brauchbar. Wobei dann noch der Effekt dazukommt, dass die 130kg von der Maschine zu einer unruhigen Bergabfahrt führen. Offensichtlich ist der Gripp von den Rädern auf dem Gras nicht "symmetrisch". Da kann ich aber ohne zusätzliches ESP nichts machen. Irgendwo sind bei mir auch Grenzen gesetzt....

    Soweit mal zur Info. Auch wenn es Themaverfehlung ist (ich habe noch keinen selbstgebauten BL-Fahrtregler) denke ich, sind die Grundlagen ganz brauchbar auf die BL-Fahrtregler zu überführen.

    Mit dem seit Jahren geplanten BL-Regler ist eine Geschwindigkeitskontrolle vom Motor notwendig. Gleichzeitig möchte ich aber auch noch die reale Geschwindigkeit erfassen. (Separaten Inkrementalgeber auf einem Rad, das nicht aktiv vom Motor angetrieben wird.) Damit könnte ich dann u.U. eine "ESP-Funktion" ;) mit einbauen. Aber ..... erst mal Zeit für den Grundaufbau von dem BL-Regler haben dürfen....

    Zitat von IBF

    - Die o.g. Body-Diode ist nach meinem Geschmack zu lausig (=leistungsarm).

    Sehr gute Regler machen zu exakt diesem Zeitpunkt den parallel zur Body-Diode angeordneten MOSFET leitend, wodurch die Verluste der Diode vernachlässigbar werden. Ich habe das noch nicht realisiert, weil das exakt synchronisiert werden muss. Hauptproblem ist dabei, dass die meisten MOSFET-Treiber mit einem Bootstrap-Kondensator arbeiten, welcher geladen sein muss, bevor der H-FET angesteuert wird. Dies wird realisiert über den eigenen L-FET innerhalb der Halbbrücke, oder - etwas tricky - über die Motorwicklung und den durchgesteuerten L-FET der anderen Seite. Das sollte dann aber auch "der richtige" L-FET sein, eben jener, der gemäß Kommutierungstabelle als nächstes an der Reihe wäre...

    So zumindest habe ich das gelöst und kein MOSFET ist abgeraucht.

    Zitat von IBF

    Ich hatte mal von Sabbertooth einen Regler zum Testen (und einen zweiten zum Reparieren). Der macht das anders. Also immer die MOSFETs durchsteuern. Sowohl im Puls, als auch in der Pulspause (Kurzschlus der Motorwicklungen) Damit hängt der Motor bei kleinen Geschwindigkeiten "gut am Gas", aber mir kommt es dann so vor, als wenn ich beim Autofahren immer kontinuierlich Vollgas fahre und die Geschwindigkeit mit der Bremse reguliere.... <X

    Das klingt für mich nach einem Typ2-Controller. Vielleicht macht er auch noch die oben beschriebene Ansteuerung der MOSFETs zur Entlastung der Body-Dioden.

    Meiner Meinung nach macht es einen großen Unterschied von der MOSFET-Ansteuerung her, ob ich einen MOSFET-Treiber mit Bootstrap-Kondensator einsetze, oder eine echte weitere Spannungsquelle habe, welche die +15 V über Betriebsspannung für den H-FET (N-Channel) dauerhaft bereit stellt. Im Fall Bootstrap-C geht schon mal nicht, den H-FET dauerhaft durchzusteuern (PWM= 100 %). Zudem muss IMMER ein L-FET durchgesteuert werden, bevor das Gate vom H-FET seinen Impuls aus dem Bootstrap-C erhält. Darauf muss übrigens auch eine asynchrone Strombegrenzung abgestimmt sein, welche nach einer Überstrom-Abregelung die Ansteuer-PWM wieder frei gibt - es darf NIE mit einem H-Puls weitergemacht werden!

    In meinem Projekt eQuad2009 hatte ich das so gelöst: Beim Beschleunigen / Auftouren verhält sich der Regler wie ein Typ2, wird Gas rausgenommen wie ein Typ1 (= Freilauf, keine MOSFET-Ansteuerung). Das Typ2-Beschleunigen mache ich so: Die Hallsensoren legen per Tabelle fest, welche beiden Halbbrücken als nächsten angesteuert werden müssen (wie man Hallsignale verifiziert hatte ich hier bereits weiter oben geschrieben). Bei den beiden Halbbrücken sind beim Auftouren immer 3 MOSFETs beteiligt: Die PWM wird dabei auf jene Halbbrücke gelegt, welche gerade gemäß Kommutierungstabelle den H-FET leitend hat, wobei der H-Puls den H-FET und der L-Puls der PWM eben den L-FET über die MOSFET-Treiber ansteuert. Bei der zweiten Halbbrücke wird der L-FET dauerhaft durchgesteuert! Dieser erhält keine PWM sondern wird für die gesamte Dauer des aktiven Hallsignals leitend gemacht. Und wenn das kurz vor der Freigabe der PWM auf die H-aktive Halbbrücke gemacht wird, kann dort sogar mit einem H-Pulse begonnen werden, eben weil der Bootstrap-C dann bereits über die Motorwicklung umgeladen wurde. Das ist vielleicht nicht ganz sauber, aber funktioniert.

    Der Witz ist eben, dass, wenn diese Art der Ansteuerung auf den Motor abgestimmt wurde (auch deshalb Prüfstand, um Parameter anpassen zu können), der Motor eben beim Auftouren nicht abbremst, da ja kurzfristig beide L-FET leitend sind. Ich hatte hierzu Strom- und Temperaturmessungen an Motor und MOSFETs durchgeführt und festgestellt, dass dies die besseren Ergebnisse liefert.

    Allerdings: Viele Regler arbeiten mit einer hohen MOSFET-Schaltfrequenz von > 16 kHz, mutmaßlich um den Anwender die störenden Geräusche zu ersparen. Auch hier habe ich an meinem 5kW-Selbstbauregler sowie am 2kW-Motor von eQuad Messungen durchgeführt und festgestellt, dass der beste Wirkungsgrad bei 2500 Hz liegt und nicht bei 16000 Hz (oder dazwischen oder gar noch höher). Vorgehensweise: Bei 16 kHz konnte ich die Motorwelle bei einer PWM von 5 % mit einem dicken Handschuh am langsam drehenden Ritzel festhalten (blockieren), bei 2,5 kHz hat es den Handschuh in das Ritzel gezogen, Festhalten unmöglich! Und das war bei einer PWM von 5 %, also ca. 2,25 V von meinen 48 V Nennspannung!!

    Ganz nebenbei wurden so auch meine MOSFETs entlastet: Bei 2,5 kHz sind die Schaltverluste wesentlich geringer, die MOSFETs (übrigens IRFP4368 mit einem RDS(on) von marginalen 0,0018 Ohm) bleiben kalt ...

    Deshalb Prüfstand, deshalb Abstimmung von Motor & Regler ...

    • Offizieller Beitrag

    Eine Frage an die BL-Profis und VESC-Versteher:

    Was bedeuted diese Fehlermeldung "Flux linkage detection failed"?

    Jojo hatte mir eine wasserdichte Video-Anleitung geschickt, wie ich die VESC-Software nutzen bzw. bedienen kann, um einen Basistest an einem reparierten Mini-VESC durchzuführen.

    Hab' die Software natürlich erst mal an einem meiner "neuen" MiniVESCs testen wollen. Port-Suche, Einstellungen,... alles nach Vorbild.

    Beim Test läuft dann der Motor kurz an, das war's.

    Motoren: einmal den Scooter-Motor, allerdiings ohne Encoder-Anschluss. Und dann einen kleinen Outrunner. (Der hat gar keinen Encoder).

    Motorgröße, Betriebsspannung, Akku-Kapazität,... alles korrekt eingetragen.

    In den anderen Foren ist das Problem auch schon dargelegt. Aber die Antworten sind mehr als lapidar. (Nochmal von vorne anfangen, Spannung wegnehmen und wieder anlegen,... ) Alles nicht besonders hilfreich.

    Hat jemand einen Schimmer einer Ahnung, was die Ursache sein kann? (Wie gesagt, der Fahrtregler hatte bis heute noch kein einziges Volt an Betriebsspannung gesehen.)

    • Offizieller Beitrag

    Läuft der Motor Frei oder Hängt ein Getriebe dran, definitiv ohne Getriebe Programmieren, sonst kommen immer Falsche Werte zustande, mit Sensor Anschlüsse oder ohne, mit auf jeden Fall mal Prüfen ob Richtig angeschlossen und ob auch kein Kabel beschädigt, ich weiß wem sag ich das, aber manchmal kann es so einfach sein...

    • Offizieller Beitrag

    Danke für die schnelle Rückmeldung.

    Zitat von IceMaster

    Läuft der Motor Frei oder Hängt ein Getriebe dran

    Beide Motoren sind frei. Ohne Getriebe. Sollte laut Jojo bei dem Wizzard aber egal sein.

    Zitat von IceMaster

    mit Sensor Anschlüsse oder ohne,

    Hab' beide Motoren ohne Sensoranschlüsse versucht. Der kleine Motor hat gar keine Sensoren. Bei dem Scootermotor habe ich sie zunächst mal weggelassen.

    Zitat von IceMaster

    ob Richtig angeschlossen und ob auch kein Kabel beschädigt

    Hab' mir aus dem I-Net vorsichtshalber noch einmal die Pinbelegung von dem Sensoranschluss anzeigen lassen. War auch gut so, denn der Anschlussadapter hatte die falschen Farben am falschen Steckplatz. => Dann geordnet .... sollte jetzt passen.

    FSESC 4.20:


    FSESC 4.12:

    Zitat von IceMaster

    ich weiß wem sag ich das, aber manchmal kann es so einfach sein...

    Ist auch gut so. Nobody is perfect und manchmal ist man durch die Erfahrung mit anderen Baugruppen auf einem falschen Weg.

    Ich habe ja den FSESC 4.20 . Zwei Stück. Und jedesmal diese ominöse Fehlermeldung.

    --------------------------------------------------------------------

    Jetzt mal ganz frech den reparierten FSESC 4.12 von Jojo angeschlossen. Diesmal dann eine andere Fehlermeldung.

    Hab' dann bei dem Scooter-Motor die Hallsensoren angesteckt. => Fehlermeldung bleibt bestehen.

    Nächster Versuch: In dem Wust aus gefühlten 100 Parametern eine harmlosen Parametersatz für den kleinen BL-Motor zusammengestellt. Explizit darauf geachtet, dass es "Sensorlos" gilt. => Trotzdem dann keine Reaktion am Motor und die Fehlermeldung, dass er keine Sensoren gefunden hat.

    An manchen Tagen sollte man wirklich nichts anpacken..... :cursing:

    • Offizieller Beitrag
    Zitat von leo-rcc

    Flux Linkage detection failed Ich hatte einmal, als meine Batteriespannung falsch in den Einstellungen von VESC war (low voltage cut off, high voltage protection).

    Danke, dann schau ich mal, ob ich da einen Kurzschluss oder etwas Ähnliches auf der Baugruppe finde. Eventuell ist die Spannungsversorgung defekt. Oder der Shunt-Widerstand zum Messen vom aktuellen Strom.

    Nur blöd, dass ich keinen Schaltplan habe.

    • Offizieller Beitrag

    Keinen Sxhaltplan ?

    Ich dachte, gerade die VESC´s wären Open-Source-Hardware.

    Gibts da auf der VESC-Projekt-Seite nichts ? (oder heisst open Source nur, dass man Gerberfiles bekommt, um sich einen

    Regler nachzubauen ?)

    GitHub - vedderb/bldc-hardware: Brushless DC Motor controller from Benjamin Vedder
    Brushless DC Motor controller from Benjamin Vedder - GitHub - vedderb/bldc-hardware: Brushless DC Motor controller from Benjamin Vedder
    github.com

    (ich weiss jetzt nicht, ob man sich Kicad antun will)

    LG

    -Michael