Hi,
ich hab eine Verständnis-Frage zur Strombegrenzung. Aus dem Code schließe ich, dass die Spannung am Shunt nur direkt nach der Kommutierung gemessen wird. Sollte sich also der Motor nicht drehen (und die Phasen nicht kommutieren) zieht folglich auch die Strombegrenzung nicht?

Spontan würde ich denken, dass ein abruptes Abstoppen der Propeller (wenn man wo hängen bleibt) zu einem ebenso abrupten Abbrennen des Controllers führen würde?

-michel

mehel meinte

Spontan würde ich denken, dass ein abruptes Abstoppen der Propeller (wenn man wo hängen bleibt) zu einem ebenso abrupten Abbrennen des Controllers führen würde?

Das hast du nicht ganz unrecht. Außerdem wird das Fehlersignal HW-mäßig integriert, damit nicht jeder Spike zur Begrenzung führt. Da vergeht natürlich Zeit...

mehel meinte

Spontan würde ich denken, dass ein abruptes Abstoppen der Propeller (wenn man wo hängen bleibt) zu einem ebenso abrupten Abbrennen des Controllers führen würde?

-michel

Ja, leider ist das so. Mein MK ist beim Start etwas gekippelt mit Propeller-Grasberührung : FET auf der Stelle abgeraucht!

Bei den 12 Euro BL-Reglern in meinen Flächenmodellen passiert das nie! Die schalten sauber ab.

In der Luft kann kaum jemand den H&I-BLR überlasten. Für alle kleinen Unfälle fehlt die Absicherung in der Soft. Wann schreibt das einer rein?

Micha

Heling meinte

Wann schreibt das einer rein?

Na du.
Ich verstehe die Kritik nicht so ganz. Mir ist noch keiner meiner 28 Regler abgeraucht. Crashfest in jeder Beziehung kriegt man keine Fluggerät. Allerdings sollte man sich angewöhnen, nicht mit Vollgas aufzuschlagen.

/me fliegt auch noch seine ersten 4 Regler... Obwohl ich es nicht für ganz Unmöglich heiße, das so mancher Regler auf Grund der Flug-/Absturzkünste des Einzelnen, draufgegangen ist.

grüße

eigentlich braucht es bei blokierung keinen überstromschutz.
wenn die Kommutierung überwacht wird.

wenn ein zeitüberschreitung in der Kommutierung erfolgt,
müsste die software davon ausgehen das ein fehler vorliegt und abschalten.


.

ja genau, ne Totmanschaltung auf dem timer für die kommutierung.

öhm... möchte anmerken, dass ichs vergangenes Wochenende wirklich geschafft habe einen Regler in der Luft... öhm... ausser Betrieb zu setzen... War wohl eine unvorteilhafte aneinanderreihung von Tatsachen...

Core: 50er CD-Spindel, Geschlossen, durchsichtig...
Regler: 1.2er vorbestückt mit starken Fets
Wetter: Pralle Sonne...

War in ca. 10m höhe am schweben, sogar über GPS... kein Rumgeheize.
Plötzlich absturz mit mehreren Überschlägen. Leider ging die Haube ab und dadurch auch etwas Elektronik kaputt...
GPS und FC sind aber heile... :-)

Was war passiert...
Es stellte sich schnell heraus, dass an einem Regler zwei Fets fehlten und die 3 Motorkabel weg waren. Jedoch waren die nicht etwa abgerissen... Sie wurden fast schon fachgerecht weggelötet...
Denke, dass sich durch die fehlende Kühlung in kombination mit praller Sonne die zwei Fets so stark erhitzt haben, dass sie sich wirklich weggelötet haben... Denke zwei neue Fets werden den Regler wieder beleben...

War wohl wirklich eine ungünstige aneinanderrreihung von verschiedenen Faktoren.
Stehende Luft, Treibhauseffekt dank durchsichtiger Haube, schwarzer Fet, pralle Sonne...

Naja, ist das meiste reparierbar...


Gruss Martin

Ja, kaum raucht einem ein Regler ab, schon bekommt man ... Bemerkungen.

Nicht umsonst haben H&I die Testroutine auf Kurzschluss rausgenommen, nachdem bei Einigen und auch bei mir, die BLs grundlos am Boden abgeraucht sind. Oschni hats gesehen?

Ich hatte bisher keinen Crash mit meinen Koptern. Ich fliege auch einrotorige Helis und habe mir das gesteuerte crashen abgewöhnt. Ein ungefragter Looping (Fehler in 0.69k) in Bodennähe endete ebenfalls mit Ablöten der FETs eines BLs, da dieser Prop am Boden blockiert war. Sonst blieb alles heil.

Einzig JUERGEN hat seinen Grips benutzt und einen konstruktiven Vorschlag produziert: Kontrolle der Kommutierung. Eine einfache und simple Sache. Das ist die Stelle im Programm, wo sich immer etwas tun muss, wenn der Drehzahl-Sollwert > Null ist.

Vielleicht lesen H&I hier mal rein und können in der nächsten Version Jürgens Vorschlag realisieren. So hätten alle was davon.

Für alle die bisher keinen BL-Defekt hatten, wäre dies zumindest eine stille Absicherung.
PKw's haben ja auch ESP und andere Dinge, die fast nie benötigt werden.

Micha

Heling meinte

Einzig Jürgen_ hat seinen Grips benutzt

?

Heling meinte

Kontrolle der Kommutierung. Eine einfache und simple Sache. Das ist die Stelle im Programm, wo sich immer etwas tun muss, wenn der Drehzahl-Sollwert > Null ist.

In der Software ist das drin.
Wenn die Drehzahl null ist (weil keine Kommutierung mehr kommt), wird der Motor neu angeworfen und dabei Zwangskommutiert (Zeile 727 in main.c)
Aber der Motor zappelt bei Blockierung im Gras oder im Baum munter weiter und die Drehzahl geht nicht auf null, weil weiter Kommutierungen kommen.

Wer Zeit und Mut hat, kann ja mal 728 in main.c:

if((CheckDelay(MinUpmPulse) && SIO_Drehzahl == 0) || MotorAnwerfen)

durch:

if(CheckDelay(MinUpmPulse) || MotorAnwerfen)

ersetzen. Dann wird der Motor nach 250ms ohne Kommutierung als gestoppt betrachtet und ggf neu gestartet.
Bei einem schnellen Sinkflug könnte dann allerdings schlimmstenfalls auch schon mal die Motoren ausgehen.

Gruss,
Holger

Mich hat das just mindestens einen Axxi Motor gekotestet. Kopter ist beim FPV Fliegen im Hüfthohen grass gelandet und erst nach 20 minuten mit im grass festgefressenen Motoren gefunden worden. Die Motoren waren 3 Minuten nach dem Stromabschalten noch kochend heiss. Die BLC's und der Lipo waren auch total überhitzt. Ausser den Motoren scheint aber kein Schaden entstanden zu sein.

gruss,

Arnd

Okay Holger,
du hast mich überzeugt: die Abfrage genügt nicht. Bei mir bleiben beim schnellen Sinkflug auch mal zwei Motoren stehen.
Somit scheidet eine Softwarelösung aus.

Ich werde die Sache hardwaremäßig angehen und mit Sicherungen in der Zuleitung meine FETs schützen. Wenn ich den idealen Wert gefunden habe, werde ich ihn posten.

Micha

Heling meinte

Ich werde die Sache hardwaremäßig angehen und mit Sicherungen in der Zuleitung meine FETs schützen.

Das ist bestimmt nicht einfach. Erstens geht Leistung verloren und zweitens sind die Si oft nicht flink genug. Ich hatte das bei einem Kyosho-Regler probiert. Obwohl ich spezielle Halbleiter-Si für 8€/Stück verwendete, waren jedesmal Si + FET's kaputt... Technisch ist das bestimmt machbar, aber schwierig, preiswert und zuverlässig zu lösen. Ich bin gespannt, was du rauskriegst. Problematisch sind die Tests. Da wird's evtl. auf'm Versuchsbrett tun und beim harten Einsatzfall nicht. Auch die Dimensionierung will überlegt werden, eine Si-Ansprache beim Abfangen wäre nicht wirklich fein... Zu hoch darf man die Schwelle aber auch nicht setzen.

Der Reglermarkt stützt meine These, weil selbst aufwändige Regler namhafter Hersteller keine Si im heißen Stromkreis haben. HW-seitige Versuche, permanenten Überstrom zu verhindern, habe ich als Sollbrandstelle (Mäanderleiterbahn) gefunden. Aber das schützt keine FET's bei kurzem di/dt.

die verwendeten FETs belasten wir mit max. 10A und laut Spezifikation können sie 30A Spitze (gekühlt). Bei meinem letzten Schaden war der Prop, ca. 1 Sek blockiert. Ich habe mir das Video 10al angesehen. Das 1mm² Zuleitungskabel war deutlich warm als ich den Kopter hochhob. Eine 15A FF würde bei 30 A ca 100msek benötigen. Laut Logger verbraten meine Motoren 12 A/St. bei voller Beschleunigung.
Das hilft also wenig.

Eine Rückführung des Stromes mit passiven Bauteilen an den Steuereingang des FET wäre auch noch denkbar. Dann wäre die Software aussen vor. Aber der Aufwand ist nicht ohne. Obwohl, die paar Bauteile wären billiger als ein Satz FETs.

Was tun? Ich hätte eine Option auf eine gebrauchte Bestückungsmaschine für meine FETs ;-)

Micha

Hm, scheint nicht so einfach zu sein. Aber wie machen es denn dann die 12-EUR-BL-Regler aus Helings Post #3? Müßte Quax da nicht etwas wissen?

 while(!CheckDelay(MinUpmPulse)); // kurz Synchronisieren
 PWM = 15;
 SetPWM();
 MinUpmPulse = SetDelay(300);
 while(!CheckDelay(MinUpmPulse)) // kurz Durchstarten
 {
 if(Strom > LIMIT_STROM/2) 
 {
 STEUER_OFF; // Abschalten wegen Kurzschluss
 RotBlink(10);
 MotorAnwerfen = 1;
 } 
 }
 // Drehzahlmessung wieder aufsetzen
 

Wieso findet ich LIMIT_STROM nicht im restlichen Code? Welchen Wert hat diese Variable? Sollte sie die Größe 10A repräsentieren, so ist LIMIT_STROM/2 bei mir schon flotter Steigflug. /4 würde in der Motorstartphase auch genug Power sein. Damit schwebt der Durchschnittskopter.


Micha

Ups. Da fährt man in Urlaub und plötzlich ist ein toter Thread sehr lebendig...

Würde es nicht sehr viel Sinn machen dem BL-Design noch einen OP Verstärker zu spendieren um die Null Durchgänge per Digital-Pin am Controller zu ermitteln? Dann könnte der AD Wandler auf Überspannung "warten" und entsprechend reagieren?
Die OP Verstärker plus Vogelfutter sollten den Preis nun auch nicht wesentlich nach oben treiben? Quax Kontroller sahen die OP Verstärker vor (allerdings spreche ich nur C und kein Assembler deshalb kann ich nix über seinen Code sagen.)

Mich würde interessieren was man sich noch so für den PERFEKTEN BL-Controller wünschen würde.... zB mehr Strom, Bessere Halblast-Fähigkeit (durch schnelleres Umladen der FETs?), Bremse für grössere Schrauben (zusätzliche FETs zum kurzschliessen der Fasen?) und einen Umbau auf Brush-Betrieb (für Mehrfachnutzung im Modellflugzeug)? Ich finde ein paar Euro mehr darf der Controller schon kosten vorausgesetzt er ist dann flexibel genug und man hat vollständige Kontrolle über alle Features.

-michel

mehel meinte

Ich finde ein paar Euro mehr darf der Controller schon kosten

Verbesserungen sind immer gut. Aber bitte als separate Advanced Version. Wenn nämlich alles Machbare gepimt wird, ist es preislich kein Volkskopter mehr. Trügerisch ist die Tatsache "Kleinvieh macht auch Mist". Jeder Cent schlägt auf den Gesamtpreis und der dürfte incl. aller H&I-Standardausbauteile bald mal locker die 1K€ tangieren.

Hallo Heling,

Zitat

Wieso findet ich LIMIT_STROM nicht im restlichen Code? Welchen Wert hat diese Variable?

das ist keine Variable sondern ein #define. Den findest du im main.h.

Peter

Danke, woggle! Dann werde ich mal neu compilieren.