Ahoi,
Ich habe folgendes Problem und suche daher Rat:
Ich habe ein Kettenfahrzeug (~54 kg) gebaut, dass von zwei 24 W 250W
Elektromotoren (My1016Z) angetrieben wird der Nennstrom pro Motor liegt
bei 14A. Als Energiespeicher nutze ich zwei 12V 15Ah Blei-Gel Akkus in
Reihe. Sämtliche Elektronik, also Spannungsregler, Motortreiber,
Empfänger und Fernbedienung sind selbstgebaut (mit Ausnahme der
verwendeten RFM12 Funkmodule). Prinzipiell funktioniert alles
zufriedenstellend. Die Steuerbefele werden von der Fernbedienung an eine
Steuerplatine im Fahrzeug gesendet, welche dann über I2C den
Motortreiber ansteuert.
Das Problem ist nun, dass in unregelmäßigen, nicht kontrollierbaren
Abständen der Motortreiber abstürzt, genauer gesagt der verwendete
Atmega8 (Schaltplan siehe Anhang).
In einem solchen Fall fährt das Fahrzeug mit dem letzten Befehl weiter
und der Microcontroller muss neu gestartet werden. Diese Abstürze können
15 Minuten nicht auftreten und dann mehrmals hintereinander,
oder von Beginn an, manchmal auch nie. Der Motortreiber steuert beide
Motoren, wobei jeder Treiber aus einer einfachen
MOSFET-Relai-Kombination besteht. Als MOSFETS verwende ich jeweils einen
IRF3808 mit 140A Maximalstrom. Frühere Treiber mit IRFZ48N sind bei
schnellen
Richtungswechseln (100% auf -100%) mehrfach verstorben. Dennoch bleibt
das Problem mit den Abstürzen. Eine Messung mit dem Oszi hat gezeigt,
dass sowohl auf der 5V Versorgungsspannung, der Masse und etwas weniger
stark auf der 12V Versorgungsspannung aber sogar auf dem Gehäuse (?!)
Spannungsspitzen erkennbar sind. Diese treten immer beim Ein- und
Ausschalten des MOSFETs auf (siehe Bilder im Anhang). Eine erste
Vermutung war, dass die Freilaufdioden zu schwach dimensioniert sind
(MBR 1645, I_FRM=32A) und ihren Dienst quitiert haben. Allerdings sind
diese auch nach mehreren Testfahrten voll funktionsfähig. Die
Freilaufdioden sitzen real jeweils auch direkt neben den FETs. Dann
stellt sich die Frage
nach der Entstörung der Motoren. Diese hatte ich bisher nicht entstört.
Ich habe dann verschiedene Versuche mit Keramikkondensatoren zwischen
den Leitungen sowie den Leitungen und dem Motorgehäuse durchgeführt,
allerdings ohne Erfolg. Ich bin mir aber bei der Dimensionierung dieser
Kondensatoren sehr unsicher, man liest oft von beispielsweise 220nF.
Allerdings denke ich, dass ich für diese Motoren größere Kondensatoren
verwenden sollte. Die Leitungen vom Treiber zum Motor sind verdrillt
(auch das Wickeln der Kabel um einen Ferritkern ~5 Wdg brachte keinen
Erfolg) und etwa 15 cm lang. Die Spannung der Batterien bricht bei
starken Beschleunigungen kurzzeitig auf minimal
20V ein. Allerdings kann ich bei hohen Beschleunigungen keine Häufung
der Abstürze beobachten.
Vielleicht kennt sich ja hier jemand mit den verwendeten Motoren und
deren Entstörung aus. Die verwendete PWM-Frequenz liegt bei knapp 2kHz
(ja, das ist ein schöner Ton).
Falls sich jemand für das Projekt interessiert, kann er sich hier
http://rs-vehikel.de/ etwas umschauen, allerdings habe ich die Seite
schon länger nicht mehr bearbeitet.
Ich würde mich auch über konstruktive Kritik über den Rest der Schaltung
freuen.
Eine andere Frage in diesem Zusammenhang ist auf dem letzten
Oszilloskopbild zu sehen. Wenn ich von einer hohen Geschwindigkeit
schnell auf eine niedrigere schalte,
sehe ich an einem Anschluss des Motors den dargestellten
Spannungsverlauf (letztes Bild). Das erste Plateau bis zu dem kleinen
Spannungsabfall auf ca 20 V entspricht dabei der ON-Zeit der niedrigen
Geschwindigkeit,
das gesamte Plateau (also U>20V) entspricht der On-Zeit der hohen
Geschwindigkeit. Wie ist dieser Spannungsverlauf zu erklären?
Viele Grüße
Robusto
Robusto schrieb:> Das Problem ist nun, dass in unregelmäßigen, nicht kontrollierbaren> Abständen der Motortreiber abstürzt, genauer gesagt der verwendete> Atmega8 (Schaltplan siehe Anhang).> In einem solchen Fall fährt das Fahrzeug mit dem letzten Befehl weiter> und der Microcontroller muss neu gestartet werden.
Das ist wohl das Kernproblem.
Kannst Du durch eine LED per Software blinken lassen, um zu sehen, ob
der µC selbst steht oder die Kommunikation per IIC?
Wenn Sie weiterblinkt, 'lebt' der µC noch.
Da Du schon IIC erwähnst: der Bus kann ohne besondere Maßnahmen
(timeout) bei Störungen hängen bleiben. Kannst Du per LEDs den Status
von SDA/SCL anzeigen? Bei hohem Störpotential sollte der IIC-Bus
unbedingt eine Zeitüberwachung bekommen.
Neben Störungen von der Hardware (ggf. durch Masseschleife?) bleibt noch
die Möglichkeit eines fehlerhaften Programms. Typischer gemeiner Fehler:
Stacküberlauf.
Soviel auf den ersten Blick und Gruß nach MS!
> Die Steuerbefele werden von der Fernbedienung an eine Steuerplatine im Fahrzeug
gesendet, welche dann über I2C den Motortreiber ansteuert.
Das sind 2 Platinen ? Der Motorcontroller mit dem I2C muss natuerlich
auf derselben Platine wie der Mega8 sein. Der Mega8 hat zuwenig Caps.
Zeig mal das Layout, und die Anordnung.
Hallo msx,
Danke für deine frühe Antwort. Ich bin mir sicher, dass der µC im
Motortreiber abstürzt. Als Test dazu habe ich einen Pin einfach pro
Schleifendurchlauf an und ausgeschaltet und mit dem Oszi gemessen. Die
Steuerplatine läuft weiter, der Atmega8 am Motortreiber nicht. Startet
man den Motortreiber durch ein Reset neu (nur den Motortreiber) läuft
die Steuerung ohne Probleme weiter.
Es gibt eine Steuerplatine mit einem Atmega 16. Der empfängt per Funk
die Signale und leitet diese über ein Kabel (~10cm)per I2C an den
Motortreiber, auf dem ein Atmega8 sitzt.
Robusto schrieb:> In einem solchen Fall fährt das Fahrzeug mit dem letzten Befehl weiter> und der Microcontroller muss neu gestartet werden.
Und warum funktioniert das nicht automatisch. Hast du den Watchdog mal
richtig auf seine Funktion getestet?
Da das natürlich nicht die Fehlerursache beseitigt, solltest du zu
Diagnosezwecken auf jeden Fall Watchdog Ereignisse loggen und der
Fehlerursache auf den Grund gehen.
Aus der Ferne und ohne Programm kann man nur spekulieren. Da die
Abstürze unvorhersehbar stattfinden, würde ich die Hardware zunächst
außen vor lassen.
Versuch 1: Klemme die Motoren ab und warte, ob das Programm auch ohne
ext. Hardware(-störungen) stehen bleibt, wenn es wie gewohnt bedient
wird.
Versuch 2: Gib dem µC ein paar Byte mehr Stack (8 - 16) und versuche das
Programm zum Absturz zu bringen.
Die Reihenfolge, wie man es probiert ist egal, aber bitte nicht Beides
gleichzeitig machen.
Mit Tüddeldraht direkt auf den Prozessor zu gehen (SDA, SCL) ist ein
No-Go. Ground-Bouncing und induktive Einkopplungen führen möglicherweise
zu deinen Fehlern.
Ansonsten benutze bitte zukünftig in Schaltplänen exzessiv das
GND-Symbol. Und lerne zweiseitige Layouts zu erstellen. Die sind
produktionstechnisch nicht schwieriger und vermeiden suboptimale
Ergebnisse.
Ansonsten wäre wohl SPI oder UART geeigneter, denn das lässt sich
einfach galvanisch trennen.
Robusto schrieb:> Ich bin mir sicher, dass der µC im Motortreiber abstürzt.
Kein Wunder, bei diesem Aufbau.
- Ich sehe kein Abblock C am AVR Controller
- Quarz in unmittelbare Nähe von geschalteten Leitungen,
--> das muss schief gehen
- Keine massige, stabile Masse, das gibt krasse
Störimpulse wenn viel Strom fliesst.
Die Hochstrom-Schaltung müsste wenigstens deutlich getrennt
von der Controller-Schaltung stehen und nur durch eine
Masseleitung verbunden sein.
Wee oft üblich wird erst mal was gebaut und dann im Forum
nachgefragt warum es nicht funktioniert. Nur nicht von
seinem hohen Ross heruntersteigen und sich vorher beraten
lassen.
Frickelfritze schrieb:> Wee oft üblich wird erst mal was gebaut und dann im Forum> nachgefragt warum es nicht funktioniert. Nur nicht von> seinem hohen Ross heruntersteigen und sich vorher beraten> lassen.
Ach komm... erstens haben "wir" was zur Erheiterung, zweitens lernt der
TO so auf die harte Tour und sehr sehr schnell daß er was lernen muß und
drittens - wenn man so blauäugig an so ein Projekt herangeht... dann
reduziert jedes " mach es besser so" die Wahrscheinlichkeit das es auch
umgesetzt wird....
Abgesehen davon das die Beratung hier meistens ein Zerreißen der Beute
von hungrigen Wölfen ist...
nun hat er seinen Kettenpanzer fahrbereit und wird das Ding wohl
fertigmachen.... Also eh alles wunderbar...
Wenn ich mir meine ersten Bastelprojekte anschaue... na servas....
PS - hier eine ähnliche (externe) Baustelle: Kettenpanzer funktioniert
mit Batterie aber wenn die Lichtmaschine dazukommt entweicht der
magische Rauch... Ursache: Lichtmaschine erzeugt Überspannung bei
heftig wecheselnder Last.... FETs auf Kante genäht und Wumms... wie
immer sehr beeindruckend was für ein Massaker 24V Pb-Akkus, eine
ausreichend dimensionierte Verkabelung und langsame PKW-Sicherungen in
der kurzen Zeit vom Tod der FETs bis zum Auslösen der Sicherung
anrichten können....
Grüße
MiWi
MiWi schrieb:> beeindruckend was für ein Massaker 24V Pb-Akkus, eine> ausreichend dimensionierte Verkabelung und langsame PKW-Sicherungen in> der kurzen Zeit vom Tod der FETs bis zum Auslösen der Sicherung> anrichten können....
Ich liebe diese blumigen Fehlerzustandsbeschreibungen. Wirklich.
Frickelfritze schrieb:> Wee oft üblich wird erst mal was gebaut und dann im Forum> nachgefragt warum es nicht funktioniert. Nur nicht von> seinem hohen Ross heruntersteigen und sich vorher beraten> lassen.
So ein Käse. Besser als drei Jahre fragen und nerven, dass man auch ja
alles richtig macht und dann doch nichts gebacken zubekommen.
Eventuell ist ein bisschen informieren nicht schlecht. Aber ich bin mir
sicher, er vergisst keine Abblockkondensatoren mehr in seinem Leben ;-D
Hallo,
zuerst möchte ich mich für die hilfreichen Antworten und Tipps bedanken.
@ Wolfgang: ich werde mal versuchen die Watchdog Ereignisse zu loggen
@ msx: Der Fehler tritt ohne angeschlossenen Motoren auch über Stunden
nicht auf. Für einen Test in meiner Wohnung, habe ich eine kleine
Plattform gebaut, auf den ich das Fahrzeug stellen kann. Die Ketten
drehen dann frei in der Luft. Hier tritt bei Tests bereits der genannte
Fehler auf. Allerdings ist die Last an den Motoren in diesem Fall
relativ gering, im Vergleich zu richtigen Fahrten
@neuer PIC Freund: Das Groundsymbol werde ich in Zukunft öfter
verwenden. Da bereits das Funkmodul über SPI angeschlossen ist, habe ich
für die Kommunikation damals I2C gewählt
@asdf: Der Link zum Fahrzeug ist im ersten Beitrag
@Frickelfritze: (i) Als Abblockkondensator ist ein 100 nF
Keramikkondensator und ein 330µF Elko eingebaut, falls das ungeeignet
sein sollte, verbessere ich das gern. Ein Fehler, der mir im Layout
aufgefallen ist, ist eine fehlende Verbindung der Masse (5-Pin-Stecker)
zu C8 und C9
(i) Verbindung der Masse zur Hochstromleitung: Die Masse des µC ist an
keiner Stelle auf dem Board mit der Hochstromleitung verbunden. Grund
dafür war, dass ich außen am Gehäuse einen Schalter angebracht habe, der
einen MOSFET steuert, welcher wiederum die im Schaltplan mit "Gnd
Motor1" und "Gnd Motor2" gekennzeichneten Pins auf Masse zieht, Um das
Farzeug im Notfall auszuschalten. Eine zusätzliche Masse-Verbindung am
Motortreiber würde den Strom über die Steuerelektronik ableiten.
(iii) Ich besitze kein hohes Ross auf das ich mich begeben könnte
@ all: Ich beschäftige mich schon länger mit dem Problem und habe
einfach bisher keine Lösung gefunden. Ich bin daher für jeden
hilfreichen Tipp dankbar. Anmerkungen über blauen Augen und Pferde
helfen mir nicht und kosten bloß Zeit.
> Als Test dazu habe ich einen Pin einfach pro> Schleifendurchlauf an und ausgeschaltet und mit dem Oszi gemessen. Die> Steuerplatine läuft weiter, der Atmega8 am Motortreiber nicht.
Also in Software. Womit nicht ausgeschlossen ist das die Schleife
irgendwo hängen bleibt. Wenn möglich wiederhohle den versuch mit einem
PWM Ausgang von einem der Timer. Dann weist du schon mal ob die Clock
stehen bleibt
oder die Software hängt.
Zum Layout:
- C6/C7 GND geht gar nicht.
http://www.lothar-miller.de/s9y/categories/33-Quarz
- Die 2 100nF am AVR fehlen. Nein C8 bringts nicht, viel zu weit weg.
- Pin 7+22 sind nicht verbunden.
Nein, die 5Km Leiterbahn um den Print herum gilt nicht.
Um das zu Retten:
1. C6/C7 auslöten.
2. Auf der unterseite 7+22 Brücken
3. Auch auf der Unterseite 2x 100nF für VCC/AVCC nachrüsten.
4. Quellcode Zeigen.
Robusto schrieb:> Ein Fehler, der mir im Layout> aufgefallen ist, ist eine fehlende Verbindung der Masse (5-Pin-Stecker)> zu C8 und C9
Um Verwirrung zu vermeiden: Der Fehler ist bloß in dem Bild des Layouts.
In der Platine ist die Verbindung vorhanden! ;)
@ Tim: der PWM Ausgang läuft weiter, da sich die Motoren weiter mit der
letzten gesetzten Geschwindigkeit bewegen, somit hängt die Software.
Danke für die vielen Tipps und den schönen Link. Ich werde jetzt erstmal
versuchen die genannten Dinge zu verbessern und melde mich dann nochmal.
Viele grüße und eine schönen zweiten Advent,
Robusto
Robusto schrieb:> Ich würde mich auch über konstruktive Kritik über den Rest der Schaltung> freuen.
Das Layout und die Schaltplandarbietung sind ja schon ausreichend
verrissen worden, daher erspar ich mir das. Ich finde es jedes mal eine
Zumutung wenn um Hilfe gefragt wird und nicht einmal die mindesten
Anforderungen an Lesbarkeiten eingehalten werden... Wenn interessiert
der Wert eines Bauteils im Layout wenn der mangels Platzierung,
Schriftfarbe und Größe nicht lesbar ist sondern nur zur Verschleierung
der relevaten Detials führt.
Was mir bei am Schaltplan aber bisher vollkommen unklar ist: Woher
sollen die FETs wissen, daß sie einschalten sollen? Vom Treiber geht
zwar eine Verbindung zum Gate... aber wie gehts von Source wieder zurück
zum Treiber? (Auch GND genannt)
Wenn die Verdrahtung auch nur annähernd so chaotisch ausschaut wie der
Schaltplan und das Layout... dann passieren auf dieser Verbindung die
wildesten Dinge und die Auswirkungen sind in ihrer Destruktivität
vorhersehbar...
Vermutlich sind GND der Schaltung und GND-Motor (x) irgendwo, irgendwie
und vor allem weit entfernt von allem was Richtig ist miteinander
verbunden...
Wenn man nun bedenkt, daß das Gate vermutlich nicht mehr als +/-20V
aushält und da 14A herumsausen... was soll denn anderes passieren als
kaputtgehen....
Über/Unterspannungsdioden am I2C sind auch keine vorhanden, geschweige
denn 10Ohm Serienwiderstände oder Ferrite (ja, nicht normgerecht, aber
wer I2C in so einem Projekt verwendet kann sich nicht auch noch um die
Richtlinien vom I2C kümmern...)
Kein C am Resetpin... Hast Du Dir einmal durchgelesen ab welchem Huster
die AVRs einen Reset erkennen - und den dann auch durchführen? Nein?
Dann aber schnell...
Lt. Schaltplan gibt es keine Verbindung der 5V vom Eingang mit dem, was
das restliche 5V-Netz sein soll denn es ist kein Verbindungspunkt an der
Stelle wo das sein sollte. Und wenn der Punkt nicht da ist... pech.
Entweder ist das CAD Mist oder der Schaltplan.
Ebenso sind seltsame Punkte am 12V-Netz zu finden...
Beim oberen Motor-FET ist am Gate gegen GND ein Widerstand mit einer
Zener-Bezeichung eingezeichnet. Was jetzt?
Warum kein Snubberzeugs am FET? 14A sind nicht gerade wenig und bis die
Dioden leiten und die div. Induktivitäten der Verkabelung tragen können
sind da schon etliche V am FET, die auf Durchbruch drängen....
Irgendwann ergibt er sich, denn mehr oder weniger gleichzeitig zuviel
Gate- und zuviel Drainspannung hält kein FET lange aus.
Naja, Du hast zu tun.
Viel Erfolg
MiWi
I2C_Motortreiber.png
(81 KB)
5V_PWM__C_small.jpg
(130 KB)
Masse_Spannungsspitzen_small.jpg
(110 KB)
24_V_Motor_Freilauf_small.jpg
(110 KB)
