Hallo ! Ich habe soweit ein Board gemacht, dass den PWM3B zur Ansteuerung eines BLDC Motors mit Hall-Sensoren verwendet. Läuft er einmal, dann ist alles O.K. Nur mit dem Anlaufen ist das so eine Sache. Ich habe es so gemacht, dass durch die Hall Sensoren ein Interrupt ausgelöst wird wenn er die Stelle passiert. Doch nur auf einer Stelle (z.B. Stelle U tut sich etwas (wenn man mal noch von V und W ausgeht). Ich dachte dass eigentlich an jeder der drei Stellen U V und W ein anlaufen stattfinden müßte, aber irgendwie denkt der Motor gar nicht dran. Bei Stelle U wackelt er wenn man ihn bis dahin zurückdrehen möchte. Die Hall-Sensoren bringen auch ein exaktes Signal. Irgendwie sollte doch gerade bei Hall-Sensoren der Anlauf in jeder Stellung ohne Probleme sein - denke ich. Ich habe es so programmiert, dass bei der steigenden Flanke ein Interrupt ausgelöst wird nur jetzt wollte ich mal sehen ob das auch auf Pegel-gesteuert funktioniert, aber offensichtlich kann das der PWM3B gar nicht - glaube ich. Irgendwie komm ich da nicht weiter. Gruß Uli
Hallo ! Die Frage bzw. die Aussage ist im Betreff. Kurz - trotz Hall-Sensoren läuft er nicht an ! Anker mit dem Finger einbischen drehen und schon läuft der Motor, aber dies ist ja nicht Sinn der Sache. Ich habe den PSC auf positiver Flanken-Erkennung eingestellt -> damit Interrupt ausgelöst wird. Aber wenn er komplett steht - wie soll dann ein Interrupt ausgelöst werden. D.h. irgendwie muss der Motor erst gedreht werden bevor er losläuft und das trotz Hall-Sensoren. Gruß Uli
Das ist viel zuwenig Info. Bring mal ein paar Kurven. zB die drei Phasenspannungen und das Hallsignal. Dann vielleicht noch die Stroeme dazu. Der Anker hat ein Massentraegheitsmoment, das ist bekannt ?
Sein Problem ist, dass er nur bei Änderung der hallsensorwerte kommutiert. Beim Stillstand des Motors (beim starten bzw. anlauf) hat er eben diese Änderung nicht. Das ganze ist ein Softwareproblem mehr nicht. Kannst du beim Start nicht einfach die Interruptfunktion von Hand aufrufen und auf den aktuellen Zustand bestromen?
Beim Start hast du eh eine init Funktion, bevor du in dein while loop über gehst. Dort einmal von Hand den Hallsensor-Zustand abfragen und die erste Kommutierung anstoßen. Habe ich dein Problem verstanden?
Hallo ! Der xGast hats absolut richtig erfaßt. Hier über den Motor genaue Diagramme oder Ansteuerungen zu bringen würde denke ich nicht viel bringen, denn wie gesagt wenn man ihn dreht läuft er sauber und die Ansteuerungen sehen eben so aus wie sie sollen. Ich glaube auch dass es nur ein "einfaches" Software-Problem ist. Ich konnte mittlerweile die Flanken-Erkennung auf Pegel-Triggerung umstellen, aber das hat auch nichts gebracht. Ich vermute dass wie der xGast schon richtig sagte, die einzige Möglichkeit ist, die Spulen wie in einem Openloop erstmal zu bestromen, sodass der Anker sich irgendwie mal bewegt. Ich werds ausprobieren. Gruß Uli
Hallo, ich habs nicht mehr ganz genau in Erinnerung. Für den Start müssen die Phasen in einer anderen Reihenfolge bestromt werden, als für den normalen Lauf. Mir hat damals eine Appnote von Renesas weitergeholfen. Muss mal meine Sourcen für einen Tiny861 raussuchen. oder bist du schon weitergekommen ? Gruß Bagi
Der Motor kann doch auch im Open-Loop ohne Hall Info´s gestartet werden => erst mal Drehmoment aufbauen ! Ab Drehzahl x in den Closed-Loop schalten und mit den Informationen der Hall-Sensoren arbeiten. Ggf. nach Open-Loop Start-/Anlauframpe googln.
---- Oh es kamen schon zwei Antworten während ich schrieb, aber der gist hats auch erfasst. ---- Hallo ! HHmm, jetzt ist das irgendwie eine nicht ganz so einfache Geschichte. Ich weiß nicht ob ich einfach so die Ausgänge von den PSCs mal so "händisch (per Befehle)" setzen kann (Ich würde die PSC vorher initialisieren aber noch nicht starten). Ich hab ja die Bootstrap Treiber sowie die Low-and High-Side-Treiber dranhängen. D.h. ich muss nur aufpassen, dass nicht beide MOSFETs einer Halfbridge gleichzeitig geschaltet werden (Cross Conduction). Wenn ich z.B. nur die High-Side Treiber nacheinander bestrome, sollte doch irgendwie ein Wackeln sichtbar sein. Ich hab mir auch gedacht, nachdem ich die Tabelle von ATMEL zur Bestromung der Spulen genommen habe - ob ich anhand dessen die Ausgänge "händisch" auf 1 bzw. 0 setze. Wenn ich dann sehe er dreht sich bzw. macht einen Wackler so kann ich ja anschließend die PSCs nachstarten. Gruß Uli
Hier in der AVR492 von Atmel ist genau das programmiert. http://www.atmel.com/dyn/resources/prod_documents/doc7518.pdf Schau mal dort die Startroutine
1 | mc_interface.h: |
2 | void mci_run(void) |
3 | • Used to start the motor. The regulation loop function is launched to set the duty |
4 | cycle. Then the first phases commutation is executed. |
an. http://www.atmel.com/dyn/products/tools_card.asp?tool_id=3764 avr
Hallo ! Erstmal danke für die Antworten ! Ja, dieses Listing kannte ich schon aus einem anderen Projekt aber nützt mir im Augenblick eher weniger. Jetzt habe ich folgendes versucht (nur da ist noch ein Gedanken-Fehler drin - glaub ich.) Ich habe jede einzelne Spule mal angesteuert ohne den PSC zu starten. Der Motor zeigt aber noch nicht mal ein zucken oder sonstiges. Nun ich glaube aber das dies keinen Sinn macht, denn der Sternpunkt ist ja so gesehen nicht erreichbar (um ein Potential drauf-zu-schalten). D.h. ich müßte also mindestens zwei Spulen gleichzeitig bestromen um überhaupt einen Strom zu erzielen (kam ich leider noch nicht dazu das zu testen). Das ganze dann in der Reihenfolge der Spulen UVW z.B. U-V dann V-W und als letztes W-U auf die z.B. High-Side-Treiber ausgeben. Zumindest müßte ja dann ein Strom durch beide Spulen fließen, sodass das Netzteil auch mal was anzeigt. Gut das mag keine elegante Lösung sein, aber vielleicht... Könnte das letzt-gesagte in etwa hinkommen ? Gruß Uli
Hallo, ich arbeite gerade mal wieder mit einem BLDC mit Hall-Sensoren. Wenn Du mit Block-Kommutierung arbeitest, ist es doch ganz einfach: Jede Kombination der Hall-Sensoren (6 mögliche!) entspricht einer Ansteuerung der 3 Anschlüsse: high/low/open Da wird der Motor optimal angedreht. Das mußt Du immer sicherstellen. Beim Start fragst Du die Sensoren ab und aktivierst die entsprechenden Ausgänge, im Betrieb kannst Du ja Interrupts nutzen... Wo soll das Problem liegen ?
Hallo ! So, jetzt konnte ich folgende Experimente durchführen. Wenn ich die Reihenfolge 1.) U-V 2.) V-W 3.) W-U nehme bewegt sich der Anker schon (ohne die Hall-Sensoren zu überprüfen). Das mache ich im schematischem C-Code bei 16MHz Taktung wie folgt: Schleife-beginn Ports setzen 2us warten //damit Spannung lang genug anliegt alle Ports wieder auf Null setzen 12us warten Schleife-ende Das wiederhole ich ca. 1000 mal. Kurz dreht er sich rückwärts und dann springt er manchmal an - in der richtigen Richtung. An manchen Stellungen des Ankers aber tut sich gar nichts oder er dreht sich piepsend stotternd nur rückwärts. Debugger stoppen - wieder anstarten und ein paar Grad weiter springt er event. wieder an. Jetzt habe ich die Ansteuerung so gemacht wie sie im Atmel-Diagramm vorgeschrieben ist ( wie du schon sagtest 6 mögliche Stellungen ). Doch hierbei bewegt sich zwar der Anker aber nicht kraftvoll um eine kleine Drehung zu vollführen. Ich benütze hierzu den IR2301S und der Gatewiderstand der MOSFETS liegt bei 47 Ohm. Der Ausgangsseitige Kapazität des IR... liegt bei 470nF. Vielleicht sollte ich da etwas ändern. Ich möchte im Openloop nur eine ganze Drehbewegung erzeugen, damit ich sofort in den closed-Loop reinspringen kann. Ich überprüfe aber im Openloop keine Hall-Sensoren. Gruß Uli
fahr doch beim start für 100-200ms einen festen pattern für 500-1000 u/min ohne die hallsensoren zu beachten. sollte reichen damit das feld den anker mitnimmt. evtl. mit dem strom aufpassen, wenn du sehr niederohmige wicklungen hast mußt du per PMW oder so den strom begrenzen.
Hallo !
Hallo Ben. Genau an das dachte ich auch.
Diesen Pattern gebe ich ja so gesehen aus. Schau mal oben bei "2us
warten"
Die 2us sind nämlich genau das: 2 x asm volatile("nop");
O.K. diese Zeiten stimmen natürlich nicht, sondern waren nur Annahme.
Bei 16Mhz Takt wäre die Ausführungszeit pro Befehl bzw. nop dann exakt
0.0625us.
D.h. ich lasse das Signal ungefähr 2*0.0625us an der Spule anliegen.
Danach setze ich per PORTx = (0<<...) an den entsprechenden Ausgängen
und dann kommt
12*0.0625us Warten -> also 12x asm volatile("nop");
Wenn ich jetzt statt den 2*nop nun 3*nop nehme dann tut sich am Motor so
gut wie gar nichts mehr.
Bei 1*nop sieht es ähnlich aus wie bei 3*nop.
Deshalb denke ich werden 100ms viel-zu-viel sein um das Ding zum drehen
zu bewegen.
Am Oszi konnte ich im laufenden Betrieb bei mittlerer Geschwindigkeit
folgendes am Gate eines der MOSFETs messen:
High-Phase ca. 4us und Low-Phase ca. 12us.
Vielleicht bringt es ja was wenn ich diese Zeiten auf die genaue
Ausführungszeit umrechne, sodass das PWM-Signal zumindest einigermaßen
stimmt.
Werde ich morgen im Geschäft machen.
Gruß Uli
Ohje ohje, so wird das nichts. Auch wenn der Motor Hall-Sensoren zur Kommutierung hat, wirst du nicht drumherum kommen eine Open-Loop Rampe zu fahren. Natürlich ist das mit dem PSC der AT90PWM3B möglich. Wie sonst soll man mit dem Chip sonst Sensorless BLDC ans Laufen kriegen? Und dass das möglich ist, kann man auch in der entsprechenden AppNote zum ATAVRMC100 nachlesen. Da gibts sogar einen kompilierbaren Source-Code dabei. Die Open-Loop Rampe für den Start macht man dann eigentlich mit Timern und nicht mit "Warte 3µs" oder sowas. Das ist zu ungenau.
ich finde das sind verdammt kurze impulse. im betrieb okay, aber ich denke beim start brauchts längere. die abstände zwischen den impulsen sollten auch einigermaßen stimmen sonst kommt kein vernünftiges drehfeld zustande. denk auch dran, daß eine phase wahrscheinlich nicht reicht, du mußt das komplette drehfeld für alle drei phasen in software vorgeben. oder schreib dir einen algoritmus dazu, der dir das drehfeld aus eingabewerten wie pausen (zur strombegrenzung) und soll-drehzahl berechnet. dieses programm würde ich dann für 100-200ms beim start des motors laufen lassen (nicht die impulsbreite soll 100ms betragen), danach sollte der motor schnell genug drehen, daß du auf die hallgeber-steuerung wechseln kannst. wird bei automotoren genauso gemacht. zum starten kriegen die einfach eine bestimmte startmenge an sprit mit der sie auf jeden fall anspringen und erst wenn die leerlaufdrehzahl erreicht ist wird zur steuerung nach parametern wie abgasverhalten, drehmomentverlauf oder leerlaufstabilisierung übergeben.
Was denn für Impulse? Natürlich muss man das Drehfeld beim Starten auf allen Phasen anlegen! Wie soll der Motor sonst anfangen zu drehen?! Dabei kommutiert man einfach "von Hand" mit einem gewissen Zeitabstand. Dabei gibt man aber keine Impulse aus, sondern legt die PWM immer auf die entsprechende Brücke(n). Ich würde wesentlich länger als 200ms den Motor beschleunigen. Du musst dabei vor allem bei einer kleinen Drehfeld-Frequenz anfangen.
Hallo ! Oh Sorry ! Das ging wohl bei meiner Erklärung etwas unter. Ich habe die Beschreibungen nur für eine "Spule" gemacht - in meinem Programm werden natürlich alle drei Spulen angesteuert und zwar nach ATMEL-Beschreibung, da gibt es ja die Tabelle mit den Schaltern. Ich werde das morgen mal im Geschäft ausprobieren, aber falls das nicht hinaut: Wie sieht denn eine Anfahrrampe aus ? Ich könnte mir vorstellen, dass allmählich die High-Signale jeder Spule kontinuierlich länger werden bis der Anker bei einer bestimmten Dauerbestromung bzw. das Magnetfeld ausreicht dann den "Überschwinger" zu schaffen und dann so gesehen zur nächsten Kommutierung gehen kann. Wie sieht es aber dann mit den Low-Zeiten aus - aus Sicht des PWM-Signals beim Anlauf ? Wie schon erwähnt das gilt nur für den Anlauf, denn wenn ich ihn von Hand drehe dann läuft er ja. Gruß Uli
Uli B. schrieb: > Ich könnte mir vorstellen, dass allmählich die High-Signale jeder Spule > kontinuierlich länger werden bis der Anker bei einer bestimmten > Dauerbestromung bzw. das Magnetfeld ausreicht dann den "Überschwinger" > zu schaffen und dann so gesehen zur nächsten Kommutierung gehen kann. > Wie sieht es aber dann mit den Low-Zeiten aus - aus Sicht des > PWM-Signals beim Anlauf ? Du zäumst das falsch auf. Die PWM (also der PSC im AT90PWM3B) läuft immer. Dann gibst du vor dem Starten einen bestimmten (festen) PWM Wert vor (oder benutzt einen Stromregler) und führst dann die Kommutierungen aus. Anfahrrampe bedeutet jetzt, dass du mit ganz langsamen Kommutierungen anfängst und diese immer schneller werden. Der Rotor folgt diesem Drehfeld dann. Irgendwann sagst du, dass du die manuellen Kommutierungen einstellst und aktivierst die Komparatoren, bzw. die Hall Sensoren, sodass die automatische Kommutierung in Kraft tritt. Mit "High Zeiten" oder "Low Zeiten" ist da nix. Beziehungsweise, die PWM kümmert sich darum. > Wie schon erwähnt das gilt nur für den Anlauf, denn wenn ich ihn von > Hand drehe dann läuft er ja. Ja.
Hallo Simon ! Diese Methode ist O.K. Ich hab das schon begriffen dass die PSCs laufen. Ich hab sie aber mit Absicht gestoppt, sodass ich diese PWM von Hand generieren muss. Sicher, mein Vorhaben ist wohl die schlechteste Methode, aber zum damaligen Zeitpunkt dachte ich dass die PSCs mir irgendwie in die quere kommen, sodass ein Anlaufen nicht möglich ist. Nachdem ich das schon in Variablen vorgesehen habe, würde das heißen, ich könnte für ein paar Millisekunden z.B. die Variable Neue_PWM von 1 bis 2048 langsam hochzählen lassen (ich setze dann die PWM in einer entspr. Routine in den Registern des PSCs), bis bei einer bestimmten Frequenz dann der Motor von allein loslaufen müsste - theoretisch. Werde ich morgen ausprobieren. Gruß Uli
der motor läuft nicht bei irgendeiner frequenz wie von wunderhand los. der rotor des motors folgt dem drehfeld, das du in den spulen erzeugst. sprich erzeug ein drehfeld was langsam und stark genug ist um den stehenden rotor samt dem anlaufmoment der anzutreibenden last mitzunehmen DANN rennt das ding auch los, wird aber nicht schneller drehen als das drehfeld es erlaubt... irgendwie kommts mir so vor du hast die funktionsgrundlagen solcher motoren noch nicht verstanden.
Genau, es reicht nicht einfach nur die PWM von 0% auf 100% hochzufahren. Genauer gesagt ist das sogar Quatsch! Die PWM kann (bei kleineren Motoren) sogar konstant sein beim hochfahren. Du musst aber ein Drehfeld erzeugen, indem du kommutierst (von Phase zu Phase weiterschalten). Und DAS muss in der Geschwindigkeit schneller werden. Also die Zeit bis zur nächsten Kommutierung muss immer kürzer werden.
Aus meiner Arbeit mit BLDC-Motoren mit Hallsensoren kann ich nur sagen: Ich glaub den ganzen Kram nicht. Bei Blockkummutierung schaltest Du die Phasen gemäß den Stellungen der Hallsensoren. Das erzeugt immer ein Drehfeld, das den Rotor dreht. Basta. Die Regelung der Drehzahl erfolgt NUR über die PWM, also Strom bzw. Spannung. Das ganze Anlaufen braucht man doch nur bei sensorlosen Motoren. Es fehlt nur die Schaltung der Phasen beim Einschalten des Motors, wo es keine Hall-Sensor-Wechsel gibt, die Interrupst erzeugen können um Phasen zu schalten.
eben, deswegen muß er die ersten umdrehungen mit einer anfahr-steuerung machen welche die hallgeber nicht braucht.
Hallo ! Nun, ich arbeite so gesehen erst seit 2 Monaten mit BLDC Motoren und als ich damit anfing war ich erstmal ziemlich damit beschäftigt mir lesbares Material für BLDC zu besorgen. Die Vorgänge am Motor sind mir klar (auch wenn es nicht so aussieht, aber vielleicht sind Störungen im Spiel die das ganze deshalb nicht lauffähig machen - siehe unten) nur im Geschäft hatte ein Arbeitskollege die ganze Sache mit dem Controller AT...16M1 realisiert. Nachdem der Controller aber erst nächstes Jahr zu kriegen ist, gaben wir es nach wochenlanger Suche auf und ich musste mich dann auf den PWM3B einarbeiten und so schrieb ich das Programm auf dem PWM3B um. Der hat etwas andere Register und somit war die Sache für mich nicht ganz einfach, aber ich habe es geschafft - zumindest durch "anschucken" des Ankers damit er sich dreht. Laut Oszi waren die Phasen der PSC an den MOSFETS korrekt. Heute allerdings habe ich die gigantischen Stützelkos (12 Stück in Reihe = 500 mF / mit 32V) direkt am Motor abgetrennt weil wir die Vermutung hatten dass diese Stützelkos event. etwas mit dem schlechten Anlaufverhalten zu tun haben könnten und wollte den Motor ohne diese laufen lassen. Ich hab ohne Elkos brechend massivste Einstreuungen von Spikes sodass alles zu spät ist. Ich habe einen AD-Wandler Eingang dazu verwendet um die PWM zu generieren und konnte per Poti die Geschw. auch ändern. Das funktionierte bis "gestern". (Anmerkung zu den Elkos: Unter Belastung zieht der Motor zwischen 10-15A für ein paar millisekunden). Ich denke es macht im Augenblick keinen Sinn hier, da ich erst diese Störungen irgendwie beseitigen muss. Was ich allerdings hier nicht verstanden habe ist, ich habe nur eine Möglichkeit an der Geschwindigkeit etwas zu ändern, nämlich die PWM zw. 0 und 100% zu variieren (während des laufs) - wie sollte ich aber beim PWM3B das Drehfeld beeinflussen ? Gut ich könnte beim PLL von fast Clock auf slow Clock umschalten aber ob das was bringt kann ich nicht sagen. Ich würde mich auch gerne mit jemanden telefonisch oder persönlich unterhalten, falls das jemand mitmacht (Ich komme aus dem Raum zwischen Stuttgart und Ulm.) Er sollte sich halt beim PWM3B auskennen. Der Kaffee oder das Bier geht auf meine Rechnung. Gruß Uli
Uli B. schrieb: > Nachdem der Controller aber erst nächstes Jahr zu kriegen ist, gaben wir > es nach wochenlanger Suche auf und ich musste mich dann auf den PWM3B > einarbeiten und so schrieb ich das Programm auf dem PWM3B um. Der AT90PWM316 ist übrigens kompatibel zum AT90PWM3B. Aber wo genau jetzt der Unterschied zum ATmega16M1 ist, konnte ich noch nicht rausfinden (außer dem Gehäuse und dass der ATmega16M1 nicht gut beschaffbar ist). > Der hat > etwas andere Register und somit war die Sache für mich nicht ganz > einfach, aber ich habe es geschafft - zumindest durch "anschucken" des > Ankers damit er sich dreht. Laut Oszi waren die Phasen der PSC an den > MOSFETS korrekt. Heute allerdings habe ich die gigantischen Stützelkos > (12 Stück in Reihe = 500 mF / mit 32V) 12 Stück in Reihe?! > direkt am Motor abgetrennt weil > wir die Vermutung hatten dass diese Stützelkos event. etwas mit dem > schlechten Anlaufverhalten zu tun haben könnten und wollte den Motor > ohne diese laufen lassen. Wie kommt ihr auf diese Vermutung? > Ich hab ohne Elkos brechend massivste > Einstreuungen von Spikes sodass alles zu spät ist. Das kann ich mir vorstellen. > Ich habe einen > AD-Wandler Eingang dazu verwendet um die PWM zu generieren und konnte > per Poti die Geschw. auch ändern. Wie erzeugt man denn per A/D Wandler eine PWM? ;-) > Das funktionierte bis "gestern". > (Anmerkung zu den Elkos: Unter Belastung zieht der Motor zwischen 10-15A > für ein paar millisekunden). Sicher, dass es der Motor ist? Ich denke nicht. Der Motor ist induktiv und kann seinen Strom gar nicht so schnell ändern. Ich vermute eher, dass das Cross-Conduction in eurer MOSFET-Brücke ist. Also für kurze Zeit sind zwei MOSFETs einer Seite gleichzeitig eingeschaltet -> Kurzschluss. Erhöhe mal die Dead Time. > Ich denke es macht im Augenblick keinen Sinn hier, da ich erst diese > Störungen irgendwie beseitigen muss. Siehe oben. Wie hoch ist eure Dead Time, und mit welchen FETs und mit welchen Treibern arbeitet ihr? > Was ich allerdings hier nicht verstanden habe ist, ich habe nur eine > Möglichkeit an der Geschwindigkeit etwas zu ändern, nämlich die PWM zw. > 0 und 100% zu variieren (während des laufs) - wie sollte ich aber beim > PWM3B das Drehfeld beeinflussen ? Im Closed Loop Modus kannst du nur über die PWM (also die Spannung am Motor quasi) die Drehzahl ändern. Im Open Loop (Ramp-Up) musst du das Drehfeld selber erzeugen. Und wie ich schon 3 mal geschrieben habe, musst du einfach manuell kommutieren. Die Geschwindigkeit der Kommutation bestimmt die Drehzahl. Synchronmotor eben. Weißt du überhaupt, was Closed-Loop und Open-Loop ist? Was eine Kommutierung ist? Du hast eigentlich einen Motor mit Hall Sensoren, ich glaube da muss ich meine Meinung von oben noch mal revidieren. Ich denke, du brauchst gar kein Open Loop Ramp-Up, da du ja schon im Stillstand weißt, wo der Rotor sich befindet und kannst sofort Closed-Loop vorgeben. > Gut ich könnte beim PLL von fast Clock > auf slow Clock umschalten aber ob das was bringt kann ich nicht sagen. Hallohooo. PWM und Kommutierungsfrequenz sind völlig unabhängig voneinander. Du hast einen Drehstrommotor. Der Rotor dreht sich genau so schnell, wie das Feld, was du ihm vorgibst (Oder halt Vielfache/Teiler von dieser Feldfrequenz). Es gibt übrigens eine Unmenge von Informationen über BLDC Ansteuerung im Internet. Ok, die sind nicht alle für AVRs gemacht, sondern auch für Philips oder Renesas Mikrocontroller. Aber du sollst und willst ja auch keinen Code kopieren. Du willst nur wissen, wie der Motor funktioniert und das ist ja unabhängig vom verwendeten Mikrocontroller. Für den Anfang hier was nettes: http://scholar.lib.vt.edu/theses/available/etd-09152003-171904/unrestricted/T.pdf Ist aber für sensorlose Motoren.
Hallo Simon !
Folgendes habe ich heute getestet und meine Vermutung mit den Spikes hat
sich nachher bestätigt das der Mikrocontroller einen Schuß bekommen hat,
denn mit Kondensatoren hätte er wie gehabt laufen müssen - tat er aber
nicht. Nachdem ich den Controller ausgetauscht habe lief wieder alles
wie gehabt, aber halt ohne Anlauf. Anschucken - läuft. Ich habe
allerdings heute ein Vierkanal-Oszi drangehängt und dann jede Spule mir
anzeigen lassen und dann sah man folgendes:
PWM-Signal steht erst an Spule U. Danach kam sofort Spule V mit dem
PWM-Signal, aber bei der Spule W ist das PWM-Signal über die ganze länge
von U und V dran.
_________
U _____ ___________
_________
V _______________ __
__________________
W ______ ___
Wenn der Strich oben ist, dann ist das PWM-Signal da.
Gut das sieht man hier nicht so gut, aber dass das PWM-Signal der Spule
W über die ganze Zeit von U und V an ist, ist seltsam.
Vielleicht ist bem Umschreiben der Konfiguration vom 16M1 zum PWM3B
etwas nicht richtig. Ich benütze den One-Ramp-Mode.
Die Antworten schreib ich Dir zwischen die Zeilen.
Simon K. schrieb:
> Uli B. schrieb:
>> Nachdem der Controller aber erst nächstes Jahr zu kriegen ist, gaben wir
>> es nach wochenlanger Suche auf und ich musste mich dann auf den PWM3B
>> einarbeiten und so schrieb ich das Programm auf dem PWM3B um.
> Der AT90PWM316 ist übrigens kompatibel zum AT90PWM3B. Aber wo genau
> jetzt der Unterschied zum ATmega16M1 ist, konnte ich noch nicht
> rausfinden (außer dem Gehäuse und dass der ATmega16M1 nicht gut
> beschaffbar ist).
O.K. aber Vorgabe ist PWM3B.
>> Der hat
>> etwas andere Register und somit war die Sache für mich nicht ganz
>> einfach, aber ich habe es geschafft - zumindest durch "anschucken" des
>> Ankers damit er sich dreht. Laut Oszi waren die Phasen der PSC an den
>> MOSFETS korrekt. Heute allerdings habe ich die gigantischen Stützelkos
>> (12 Stück in Reihe = 500 mF / mit 32V)
> 12 Stück in Reihe?!
Ja, 12 Stück in Reihe. Einer hat 5F mit 2.7V
>> direkt am Motor abgetrennt weil
>> wir die Vermutung hatten dass diese Stützelkos event. etwas mit dem
>> schlechten Anlaufverhalten zu tun haben könnten und wollte den Motor
>> ohne diese laufen lassen.
> Wie kommt ihr auf diese Vermutung?
Wir haben Messungen gemacht (mit dem 16M1) und mussten durch Vorgaben
vom Kunden die PWM von 1% schlagartig auf 99% erhöhen unter Last. Also
fast von Stillstand auf volle Last erhöhen. Die aufgezeichneten Ströme
zeigten etwas zw. 8-12A und mehr.
>> Ich hab ohne Elkos brechend massivste Einstreuungen von Spikes sodass >> alles
zu spät ist.
> Das kann ich mir vorstellen.
>
>> Ich habe einen
>> AD-Wandler Eingang dazu verwendet um die PWM zu generieren und konnte
>> per Poti die Geschw. auch ändern.
> Wie erzeugt man denn per A/D Wandler eine PWM? ;-)
>
>> Das funktionierte bis "gestern".
>> (Anmerkung zu den Elkos: Unter Belastung zieht der Motor zwischen 10-15A
>> für ein paar millisekunden).
> Sicher, dass es der Motor ist? Ich denke nicht. Der Motor ist induktiv
> und kann seinen Strom gar nicht so schnell ändern. Ich vermute eher,
> dass das Cross-Conduction in eurer MOSFET-Brücke ist. Also für kurze
> Zeit sind zwei MOSFETs einer Seite gleichzeitig eingeschaltet ->
> Kurzschluss. Erhöhe mal die Dead Time.
An das hatte ich auch schon gedacht, nur der Kollege der das auf dem
16M1 programmiert hat, ist nicht mehr im Konzern. Er hatte aber an der
Dead-Time nichts "rumgeschraubt". Bevor er ging sagte er nur das es
keine Überlappungen und damit Cross-Conductions gibt.
>> Ich denke es macht im Augenblick keinen Sinn hier, da ich erst diese
>> Störungen irgendwie beseitigen muss.
> Siehe oben. Wie hoch ist eure Dead Time, und mit welchen FETs und mit
> welchen Treibern arbeitet ihr?
Wir benutzen den IR2301S und MOSFET IRF1010z...
>> Was ich allerdings hier nicht verstanden habe ist, ich habe nur eine
>> Möglichkeit an der Geschwindigkeit etwas zu ändern, nämlich die PWM zw.
>> 0 und 100% zu variieren (während des laufs) - wie sollte ich aber beim
>> PWM3B das Drehfeld beeinflussen ?
> Im Closed Loop Modus kannst du nur über die PWM (also die Spannung am
> Motor quasi) die Drehzahl ändern.
> Im Open Loop (Ramp-Up) musst du das Drehfeld selber erzeugen. Und wie
> ich schon 3 mal geschrieben habe, musst du einfach manuell kommutieren.
> Die Geschwindigkeit der Kommutation bestimmt die Drehzahl. Synchronmotor
> eben.
> Weißt du überhaupt, was Closed-Loop und Open-Loop ist? Was eine
> Kommutierung ist?
Willst Du mich jetzt ärgern ? Warum erklärst du mir das 3 mal ?
> Du hast eigentlich einen Motor mit Hall Sensoren, ich glaube da muss ich
> meine Meinung von oben noch mal revidieren. Ich denke, du brauchst gar
> kein Open Loop Ramp-Up, da du ja schon im Stillstand weißt, wo der Rotor
> sich befindet und kannst sofort Closed-Loop vorgeben.
Ja, genau das ist das Problem. Normalerweise kannst Du ja sogar bei
Hall-Sensoren unter Voll-Last anfahren. Das ist ja das was ich nicht
verstehe. Ich glaube aber, dass es an den oben "gezeichneten"
U-V-W-Diagramm der Fehler zu suchen ist. Wenn alle drei Spulen sauber
angesteuert werden, dann vermute ich das der Motor sofort ohne
"anschucken" laufen wird. Um deine Frage zu beantworten, der Open-Loop
Ramp-up ist ja so gesehen dazu da um den Motor erstmal durch seine
Trägheit in Bewegung zu versetzen, sodass man die Position ermitteln
kann (gerade bei BLDC ohne Hall-Sensoren) sobald er in einer
Drehbewegung ist, kann man dann in die closed Loop umschalten.
Sicher kann man jetzt an meiner Erklärung rumnörgeln, aber ich möchte
hier keine Haarspalterei betreiben. Im übrigen wenn ich das Prinzip der
Kommutierung nicht verstanden hätte, warum läuft der Motor ? Ich habe
die Kommutierung aus einer ATMEL-Tabelle. Und was noch schlimmer ist, in
dieser Kommutierungs-Tabelle hat ATMEL selbst einen Fehler !!!!!!!!!!!
(Ich bin heute mit einem Arbeitskollegen die Kommutierung zum dritten
mal duchgegangen - keine Fehler ! )
>> Gut ich könnte beim PLL von fast Clock
>> auf slow Clock umschalten aber ob das was bringt kann ich nicht sagen.
> Hallohooo. PWM und Kommutierungsfrequenz sind völlig unabhängig
> voneinander. Du hast einen Drehstrommotor. Der Rotor dreht sich genau so
> schnell, wie das Feld, was du ihm vorgibst (Oder halt Vielfache/Teiler
> von dieser Feldfrequenz).
>
> Es gibt übrigens eine Unmenge von Informationen über BLDC Ansteuerung im
> Internet. Ok, die sind nicht alle für AVRs gemacht, sondern auch für
> Philips oder Renesas Mikrocontroller. Aber du sollst und willst ja auch
> keinen Code kopieren. Du willst nur wissen, wie der Motor funktioniert
> und das ist ja unabhängig vom verwendeten Mikrocontroller.
> Für den Anfang hier was nettes:
>
http://scholar.lib.vt.edu/theses/available/etd-09152003-171904/unrestricted/T.pdf
>
> Ist aber für sensorlose Motoren.
Gruß Uli
Ah, das sieht doch schon besser aus. Nein, natürlich möchte ich dich nicht ärgern :-D Verändert sich der PWM-Dutycycle, während die jeweilige Phase aktiviert ist? Sieht nach einem "Halbschritt" Betrieb analog zu Stepper Motoren aus. Oder sogar 3 "schöne" um 120° versetzte Sinüsse. Ist der Strom in den Phasen ähnlich einem Sinus? Das geht mit einem Sensorless Brushless nicht, da macht man die "einfache" Kommutierungsmethode (Blockkommutierung). Aber du hast ja auch keinen. Zumindest ist das meine Vermutung. Wenn der Motor aber damit läuft, sollte das so funktionieren. Bist du die Spikes denn losgeworden?
Hallo Simon !
Die Spikes sind mit den Elkos fast weg und sind jetzt in einem
akzeptablen Bereich, sodass auch der Dragon nicht mehr aussteigt !
Aber Kopfzerbrechen macht mir gerade dieses Verhalten mit dem Diagramm
immer noch. Ich verwende z.B. nicht dieses Compare ...OCRnRAH/L usw.
Register. Soviel ich weiß ist das nur dazu da wenn Du den internen
Waveform-Genrator verwenden willst.
Mit unserem Vierkanal Oszi sieht das halt so aus als ob nur der PSC 0
(Master) gut läuft und die anderen (Slave) zwar auch aber irgendwie
nicht so wie es sein soll.
Die PWM-Burst der Spulen sollten ja quasi nacheinander (überlappend)
kommen und daran liegt es dass er nicht anläuft. Also quasi so:
________
U _________ ___________________
________
V ______________ ______________
________
W ___________________ _________
Hast du vielleicht eine minimale Initialisierungs-Routine z.B. Mode
One-Ramp ohne diese OCRnRAH/L-Register ?
Ich weiß, da gibts schon ein Demo-Prog von ATMEL aber die arbeiten mit
diesem OCR... und das wollte ich nicht verwenden.
Außer Du würdest jetzt sagen ohne dieses OCR... gehts nicht, dann weiß
ich wo der Fehler liegt, nur irgendwie weiß ich nicht wie das Register
einzusetzen ist.
Gruß Uli
Uli B. schrieb: > Hallo Simon ! > > Die Spikes sind mit den Elkos fast weg und sind jetzt in einem > akzeptablen Bereich, sodass auch der Dragon nicht mehr aussteigt ! Sind die Spikes etwa auf die 5V/3.3V Versorgung durchgeschlagen? :-O > Aber Kopfzerbrechen macht mir gerade dieses Verhalten mit dem Diagramm > immer noch. Ich verwende z.B. nicht dieses Compare ...OCRnRAH/L usw. > Register. Soviel ich weiß ist das nur dazu da wenn Du den internen > Waveform-Genrator verwenden willst. "Waveform Generator", ja sowas in der Art. Also die PSC kann für jeden Ausgang eine Dead-Time, sowie eine PWM erzeugen. Dafür sind die Register gedacht. Jede "Sub-PSC" (Also PSC0, 1, 2) hat einen eigenen Zähler, der ständig hochzählt, bis er einen bestimmten Wert erreicht hat und dann wieder von vorne anfängt. Dadurch wird ein mal die PWM erzeugt, sowie die Dead Time beim Umschalten. > Mit unserem Vierkanal Oszi sieht das halt so aus als ob nur der PSC 0 > (Master) gut läuft und die anderen (Slave) zwar auch aber irgendwie > nicht so wie es sein soll. Kannst du eventuell ein Bild davon machen? > Die PWM-Burst der Spulen sollten ja quasi nacheinander (überlappend) > kommen und daran liegt es dass er nicht anläuft. Also quasi so: > ... Hm, hm. So viel Ahnung habe ich davon jetzt auch nicht. Aber es würde eventuell schon der verwendete Motor helfen. Ist es eine "echte" permanenterregte Synchronmaschine (mit "echter" 3 Phasen Wicklung), oder ist es ein Brushless-DC (zB Modellbau), die so gewickelt sind, dass man mit Blockkommutierung arbeiten kann? Da der Motor Hall Sensoren besitzt, tippe ich fast auf ersteres. Weißt du, welche Kommutierungsart verwendet wird, bei deinem Gerät? Kannst du den Strom der Phasen mal oszilloskopieren? > Hast du vielleicht eine minimale Initialisierungs-Routine z.B. Mode > One-Ramp ohne diese OCRnRAH/L-Register ? Leider nicht. Ich habe (noch) nichts mit dem AT90PWM3B am Hut, nur letztens schon mal durchgelesen, da ich einen kleinen FU bauen möchte. > Ich weiß, da gibts schon ein Demo-Prog von ATMEL aber die arbeiten mit > diesem OCR... und das wollte ich nicht verwenden. Warum nicht? Bzw. wie erzeugst du dann die PWM? Software? > Außer Du würdest jetzt sagen ohne dieses OCR... gehts nicht, dann weiß > ich wo der Fehler liegt, nur irgendwie weiß ich nicht wie das Register > einzusetzen ist. Ich sag mal so: Ohne OCR wüsste ich gar nicht, wie man das machen sollte ;-) Auch die Dead-Time Erzeugung wird ja damit gemacht. Sofern du keine externe Dead Time Erzeugung hast (hat der IR2301 nicht), solltest du schon den Waveform Generator bzw. den PSC dafür benutzen. Wenn du das nicht machst, kommt es eben zu den Strompeaks, die du gesehen hast. Klar, ganz kurzzeitig (<100ns) mal 10A ist (thermisch) nicht viel, aber kann sehr gut unter anderem EMV Störungen erzeugen.
Hi Simon ! Du sitzt gerade auch vor der Kiste. In meinem leichtsinn, habe ich gerade gesehen, dass mein Vorgänger die Prozedur eingebaut hat und ich die nur einmal vom 16M1 zum PWM3B umgesetzt habe und danach nie wieder angeschaut habe. Insofern ist das schon dringewesen. Jetzt bin ich gerade am analysieren, was er da genau eingestellt hat, vielleicht mit den richtigen Zeiten komme ich dann auf meine PWM. Gruß Uli
Hi Simon ! Um es kurz zu machen. Jetzt funzt er ! Das kam dadurch, dass ich mir halt die Timing-Diagramme von OCR... intravenös anschauen musste. Danach stellte ich fest das während der Übersetzung vom 16M1 zum PWM3B ich eine Sache nicht gewusst habe und auf später verschieben wollte. Nun das war nicht gut, hätte ich gleich prüfen müssen. Als ich den Fehler beseitigt hatte lief er lammfromm an und die Diagramme sind jetzt so wie sie auch in der Literatur zu sehen sind. Das heißt wenn es jetzt einen Danke-Button für Dich hier im Forum gäbe, dann müsste ich 10 mal draufdrücken - mindestens. Danke Gruß Uli
So viel hilfreiches habe ich doch gar nicht beigetragen :-) Was hast du denn genau geändert an den Timings? Bzw. an den OCR Registern. Ich dachte da sind beide Chips gleich.
Hi Simon ! Das war so. Beim umsetzen des Programms las ich nur ein OCRnRB-Register. Beim 16M1 gabs ein einziges Register für alle drei PSC. Deshalb musste mein Kollege nur ein Register beschreiben. Ich hab das zwar übernommen und seltsamerweise hat der Compiler nicht gemeckert. Erst als ich ja von Dir erfuhr dass der OCR-Teil für die PWM Erzeugung zwingend erforderlich ist, habe ich den Teil vom Kollegen nochmals angeschaut und bemerkt, dass hier im Atmel-Datenbuch dafür nicht ein Befehl sondern für alle drei Register explizit gesetzt werden sollte/muss. Das erklärt jetzt auch, warum PSC0 gefunzt hat und PSC1 und 2 nur halb-lebig. Vielleicht täusche ich mich da auch, denn vielleicht muss man für den 16M1 ebenfalls alle 3 OCRnRB reinschreiben. Mein anderer Kollege erzählte mir heute das der Programmierer irgendwas an den Header-Dateien vom PWM3B geändert hatte - und diese Änderungen waren auf meinem anderen PC nicht drauf. Aber gut - wo ein Wille ist - ist auch ein Bit. Gruß Uli
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.