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
Angehängte Dateien:
-
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
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.
Angehängte Dateien:
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.
Du könntest mal die Relais entstören. Es sieht so aus, als ob du zuerst die 5817 und danach den 548 killen willst.
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: > Ach komm... Weise Worte eines (vermutlich altgedienten) weisen, anonymen Forumsmitglieds.
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.
asdf schrieb: > cool zeig mal! Klickst du Link: Robusto schrieb: > Falls sich jemand für das Projekt interessiert, kann er sich hier > http://rs-vehikel.de/ etwas umschauen
> 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
Da auf der Versorgung ja ähnliche Störungen wie im Auto auftreten, hier mal der so gern von MaWin genannte Link zum Kfz-Bordnetz: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.23
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
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.