Hallo zusammen!
Ich bin relativ neu in diesem Bereich und Versuche gerade einen
Brushless-Controller zu entwickeln. Ich benutze den Brushless-Motor
ROBBE ROXXY 2824-34. Bisher lief alles ziemlich gut. Nun habe ich jedoch
ein Problem mit dem Start-Up. Dieser geschieht mit folgendem Code:
1
//mosfet_a_p(30);
2
//mosfet_b_n(OPEN);
3
//mosfet_c_n(OPEN);
4
//_delay_ms(200);
5
//
6
//mosfet_closeall();
7
8
while(try_counter<255)
9
{
10
//Kommutator
11
mosfet_commutator(commutator_number,pwm_value);
12
commutator_number++;
13
if(commutator_number==6)
14
commutator_number=0;
15
16
_delay_ms(10);
17
18
//Versuche zählen
19
try_counter++;
20
u_push("%d\n\r",try_counter);
21
}
22
23
u_push("Successful!\n\r");
Ich benutze PWM-Wert 80 und den 1024er-Prescaler.
Jedes Mal, wenn ich dieses Programm ausführe, zuckt der Motor kurz und
dann wird der Mikrocontroller 'resettet'. Dieses zucken reicht manchmal
sogar für 1-2 Umdrehungen. Ich nehme an dies geschieht völlig
willkürlich, je nach Ausgangs-Position des Rotors.
Anscheinend bricht die Spannung beim Beschalten der MOSFETs ein und hat
einen Reset des Mikrocontrollers zur Folge. Kennt sich jemand mit
Brushless-Motoren aus und weiss, warum? Ich habe bereits mit dem
PWM-Wert und dem delay herumgespielt, jedoch ohne Erfolg.
Falls noch weitere Code-Teile benötigt werden, bitte bescheid geben.
Ich bin ein Neuling, seid also nicht zu hart zu mir :)
Gruss
AP
Hi,
Von fundamentaler Wichtigkeit ist hierbei das Layout. Das ist der Dreh
und Angelpunkt und hier entscheidet sich auch, ob es funktioniert oder
nicht. Bei Leistungselektronik müssen da einige Sachen beachtet werden.
Das Netzteil ist zu schwachbrüstig, bricht ein und der Mega stürzt ab.
Auch nicht wirklich schön: Die Strommessung. Ich will nicht wissen,
welche krassen Impulse da rüberkommen.
mfg mf
Das Netzteil, das ich gerade verwende unterstützt "Current 0...5A" und
ist diesbezüglich auch voll aufgedreht. Wie ich gerade mit dem
Oszilloskop messen konnte, bricht die 5V Versorgungsspannung des mC ganz
kurz ein. Die 12V des Motors ebenfalls.
Was jedoch seltsam ist: Werden der 12V und der 5V-Stromkreis voneinander
getrennt (zwei verschiedene Netzgeräte), bricht die Spannung trotzdem
ein.
Tach Mangow,
wie weit bricht die Versorgung zusammen? Bei mehr als 1/10 solltest du
dir Gedanken machen.
Intuitiv würde ich mal sagen, du machst da einen Kurzschluss auf der 12V
Versorgung. Entweder wegen fehlerhafter Ansteuerung oder weil bereits
ein MOSFET durchgeschlagen ist.
Ich finde leider den gatetreiber nicht. Bist du sicher, dass der MCP14E6
heißt?
Was mir noch aufgefallen ist: Die Filterkondis für das BEMF sind
ziemlich fett. Bedenke, dass du mit einem RC Tiefpass dir auch immer
einen Phasenshift einhandelst. Der ist Frequenzabhängig und kann dir uU
die Komutierung verhageln.
Thor
Ich sehe nicht genau wie stark die Versorgung zusammenbricht. Ich sehe
nur, dass der "Strich" des Oszilloskops kurz verschwindet, mehr nicht.
Ich vermute einen Kurzschluss durch fehlerhafte Ansteuerung, da gerade
eben der Widerstand zwischen Motor und GND durchgebrannt ist, als der mC
ausnahmsweise nicht neu gestartet hat.
Und dies ist mein MOSFET-Driver:
http://www.reichelt.de/ICs-M-MN-/MCP-14E6-E-P/index.html?ACTION=3&GROUPID=2914&ARTICLE=109727&SHOW=1&START=0&OFFSET=16&#av_tabdata
Das BEMF ist vorerst sowieso nicht in Betrieb. Zuerst muss ich es
hinkriegen, den Motor ohne Verlust von MOSFETs oder einem
Spannungsabfall ins Start-Up zu kriegen :)
Aber es will einfach nicht.
Wei gesagt, es kann auch ein durchgeschlagener fet sein. Wenn du dann
den zweiten fet in der Halbbrücke durchschaltest sieht das genau so aus.
Was ich mir vorstellen könnte wäre falsches timing bei der Ansteuerung.
ZB könnte der endgültige Zustand eines Schrittes durchaus korrekt sein,
die Reihenfolge in der die fet durchgeschaltet werden aber nicht. Du
solltest in dem Falle immer den auszuschaltenden fet zu erst
ausschalten, bevor du andere fet einschaltest. Sowas kann Unnötige
Stromspitzen erzeugen und den µC uU zum Absturz bringen.
Und wie schon häufig gesagt. Schlechtes layout design kann solche Fehler
begünstigen.
Thor
Vermute ma der Fehler wird hier im Timing liegen, wie du den Motor in
den gesteuerten Modus hochfahren willst.
Vorzugsweise nimmt man hier eine Anlauframpe, die d/T zwischen den
Kommutieren von mal zu mal dekrementiert und somit kann der Motor
"sauber" hochlaufen bis man genug BEMF hat um in den geregelten Modus zu
wechseln.
Für erste "Entwicklungsversuche" empfehle ich dir die Software komplett
ohne Leistungsteil, also FETs und Treiber auszutüfteln. Die 6
Steuerausgänge vom ATmega aufs Oszi gelegt und dann gib ihm.
So geht auch nichts kaputt ;)
Sind die PFETs wirklich so eingebaut wie im Schaltplan gezeichnet? Die
Bodydiode ist doch so in Flußrichtung geschalten und es gibt einen
Zweigkurzschluß sobald der NFET durchsteuert...
Du könntest ja mal probieren, was der Start-up ohne Motor macht. Wenn's
dann immer noch auftritt werden deine FETs falsch angesteuert, oder
einer ist defekt.
Was ratet ihr mir denn für ein Timing? Was für ein delay und was für ein
PWM wert? Und in welchen Schritten soll ich mit dem delay runtergehen
pro Kommutierung? Alles Fragen, die bei mir noch offen stehen^^
ich mache mir gerade eine Liste mit euren Vorschlägen. So kann ich diese
ausprobieren sobald ich wieder in der Werkstatt bin. Aber danke
vielmals! :) Vor allem ohne Motor sollte ich es mal versuchen.
@Andres S.: Sollte der FET falsch herum sein, wie würde sich das dann
zeigen? Geht dann einfach der MOSFET nicht zu oder auf, wenn er den
Befehl dazu kriegt, oder geht das trotzdem?
Danke für eure Antworten!
Wenn der P-FET so eingebaut ist, wie er im Schaltplan steht, wird er
immer durchsteuern. Es reicht also einen Kurzen zu verursachen, sobald
der N-FET durchgesteuert wird.
Die Timings wirst du ausprobieren müssen, das ist von Motor zu Motor
unterschiedlich, ein träger Motor wird mit einer steilen Rampe nie
drehen ;-)
Zu lang sollte das Timing natürlich auch nich sein, sonst rauchts
irgendwann.
Tipp zum Debug: Lass bei jedem Kommutiervorgang einen Pin toggeln, dann
kannst du mim Oszi messen ob die Anlauframpe wirklich funktioniert,
indem die Perioden immer kürzer werden.
Kennst du den Artikel Brushless-Controller für Modellbaumotoren
schon?
Da findest du vielleicht noch ein paar Tipps.
Schau dir vorallem mal die Abschnitte "Treiber" und "Beispielschaltung"
an, das könnte nützlich sein falls du nicht abgeneigt bist, die Hardware
nochmals neu aufzubauen.
Deine Treiber haben ja zwei "IN" Eingänge, es gibt aber auch Treiber
(z.B. IR2104S) mit einem "IN" und einem "Shutdown", das macht vieles
einfacher.
mfg
Solange der PMOS mit Drain an +12V hängt wird das eher nichts. Da hilft
auch kein besseres Timing, optimiertes Layout oder Sonstiges wenn das
Einschalten des NMOS zum Zweigkurzschluss führt.
Gruß, Andreas
Danke für den Artikel. Einer Hardware-Änderung bin ich grundsätzlich
nicht abgeneigt. Jedoch nur, wenn der Fehler auch bestimmt bei der
Hardware liegt. Denkt ihr denn es liegt an den Drivern?
Ich denke ich habe den PMOSFET richtig eingelötet und nur falsch
eingezeichnet. Die einzelnen phasen hab ich nämlich schon mit ein paar
LEDs getestet. Dies lief ohne Probleme. Jedoch habe ich damals nur die
einzelnen Phasen (A+ und A-) mit den LEDs verbunden. Die einzelnen
Phasen untereinander jedoch nicht bzw. nur mit dem Motor.
@Stefan P.: Was meinstu mit decouplen?
Ich habe meine Schaltung getestet. Ein MOSFET war durchgeschlagen. Die
Start-Up-Sequenz ohne Motor läuft ohne Probleme. Nun läuft es auch mit
Motor. Leider jedoch unregelmässig vor und zurück. Dazu kommt noch:
sobald der Motor sich "verhakt" bzw. stehen bleibt, kommt es zu einem
Kurzschluss und es brennen mir weitere MOSFETs durch.
Ich vermute eine schlecht gewählte Start-Up-Sequenz. Auf jeden Fall
vielen Danke für die Beiträge und die Hilfe. Sollte jemand noch einen
Geistesblitz bezüglich der Unregelmässigkeit haben, darf dieser es gerne
posten :)
Falls alles funktionieren sollte, werde ich dies hier ebenfalls posten.
Gruss, AP
Mit wie grossem PWM Duty Cycle arbeitest du?
Beim Startvorgang sind 10 bis 20% für den Anfang nicht schlecht. Ab 40%
oder so kanns gefährlich werden...
Überschneiden sich die oberen und unteren Ansteuersignale der
Halbbrücken ganz sicher nicht?
mfg
Eine Strombegrenzung ist in Arbeit. Bis Freitag/Samstag implementiert.
Ich habe dummerweise mit 100/255 angefangen. Höchstwahrscheinlich der
Killer. Sobald eine Strombegrenzung steht, werde ich mit einem
geringeren Wert anfangen und langsam hochfahren. Aber Danke!
Kurze Zwischenfrage:
Wenn ich mit folgenden Anweisungen ein PWM auf Pin D6, D5 und D4 lege.
Ist es dann Möglich die einzelnen Pins über das DDR-Register (welches
normalerweise den Eingangs und Ausgangs-Status festlegt) ein und
auszuschalten?
1
//P-MOSFETs öffnen: auf Ausgang setzen
2
#define MOSFET_AP_OPEN {DDRD |= (1 << M_AP);}
3
#define MOSFET_BP_OPEN {DDRD |= (1 << M_BP);}
4
#define MOSFET_CP_OPEN {DDRD |= (1 << M_CP);}
5
6
//P-MOSFETs schliessen: auf Eingang setzen
7
#define MOSFET_AP_CLOSE {DDRD &= ~(1 << M_AP);}
8
#define MOSFET_BP_CLOSE {DDRD &= ~(1 << M_BP);}
9
#define MOSFET_CP_CLOSE {DDRD &= ~(1 << M_CP);}
Bei mir scheint es nicht zu funktionieren. Sind die Pins auf Eingang
geschaltet, fliesst trotzdem eine willkürliche Spannung. Jedoch habe ich
hier einen Beispiel-Code von einem Typen, welcher es anscheinend so
gemacht hat. Täusche ich mich, oder ist das Ein- und Ausschalten über
das DDR-Register so gar nicht möglich? Gibt es evtl eine andere
Möglichkeit diese Pins zu steuern, ausser über die Register OCR1A, OCR1B
und OCR2B?
Gruss, AP
> fliesst trotzdem eine willkürliche Spannung.
Sorry, aber Spannung fließt nicht.
> Täusche ich mich, oder ist das Ein- und Ausschalten über das DDR-Register so> gar nicht möglich?
Das Data Direction Register ist was der Name sagt. Setzt du ein bit im
DDR zurück, ist das port bit ein Eingang. Das heißt, es fließ kein Strom
in aus oder aus dem Pin. Wenn du nun randomisiert in deinem PWM Zyklus
das DDR aus machst, steht dort auch eine mehr oder minder zufällige
Spannung an dem Pin. Dem kannst du entgegen wirken, indem du pullups und
-downs verwendest. Seltsamer Weise hast du aber nur an den InAs jeweils
einen pullup eingebaut. InA ist also standartmäßig an.
> Gibt es evtl eine andere Möglichkeit diese Pins zu steuern, ausser über die> Register OCR1A, OCR1B und OCR2B?
Die eleganteste Möglichkeit ist die ensprechenden bits im Port Register
mit null zu initialisieren und bei Bedarf, die COMxx bits in den TCCRxA
Registern zurück zu setzen. Dann werden die OCs wieder von den
entsprechenden Pins abgekoppelt und übernehmen den Wert vom Port
Register, also aus.
Thor
Thread beobachten
Seitenaufteilung abschalten