I²C - Motortreiber

[MichaelH]

Hallo,

ich habe grad ein echt blödes Problem. Es geht um einen Roboter. Dieser verwendet die Motortreiber MD03 (http://www.roboter-teile.de/Shop/themes/kategorie/detail.php?artikelid=13&source=2) mit I²C-Interface. Die Steuerspannung ist 5V über einen Schaltregler (4A) erzeugt und die Arbeitsspannung ist 24V.

Jetzt zum eigentlichen Problem: Sobald die Motortreiber eine PWM ausgibt, bricht der I²C-Bus (nach einigen Sekunden) zusammen und das Err-Bit in Bascom liefert eine 1. Das Problem lässt sich auch nur mit dem Wegnehmen der Versorgungsspannung bzw. Reset des Controllers wieder zurückstellen.
Ich suche schon ewig den Fehler. Zuerst dachte ich, es wäre ein Problem durch Induktion zwischen I²C-Leitung und PWM-Leitung. Jetzt habe ich aber die Motoren testweise vom Motortreiber abgeklemmt. Dann war das Problem aber immer noch da, sobald der Treiber PWM ausgab wars das mit dem I²C. Also kanns ja folglich kein Problem durch Induktion sein, denn eine Induktion kommt ja durch wechselndem Strom zustande...

Beim überprüfen der Datenleitung mit dem Oszi hab ich dann festgestellt, dass in den Datenleitungen vom I²C feine "Nadeln" (synchron zur PWM) auftauchen (siehe Bild). Die "Nadeln" tauchen auch in der 5V-Versorung etwas schwächer auf. Ich vermute darin die Ursache für mein Problem. Ich es mit einem fetten Elko+großem Folienkondensator in der 5V-Leitung versucht. Hat aber ebenfalls nicht geholfen...

Hoffe, dass ich nichts vergessen hab zu schreiben, sonst editier ichs hier rein...

Hoffentlich kann mir jemand helfen, bin echt verzweifelt mit dem Problem. :cry:


Gruß
Michael






http://i51.tinypic.com/2ikcors_th.jpg (http://i51.tinypic.com/2ikcors.jpg)

[Richard]

Hallo,


Jetzt zum eigentlichen Problem: Sobald die Motortreiber eine PWM ausgibt, bricht der I²C-Bus (nach einigen Sekunden) zusammen

Du solltest Dich einmal eingehend mit dem Datenblatt befassen.

http://www.roboter-teile.de/datasheets/md03.pdf

Icvh kann so gut wie kein Englisch aber ich verstehe da der Treiber selber kein PWM liefert sondern das auf einer der I²C Anschlüsse ein PWM Signal angelegt werden soll?

Der Treiber hat verschiedene Betriebsmodi und kann anscheinend auch mit Gleichspannung geregelt werden und sogar auch mit PPM = Funkfernsteuerung.....

Gruß Richard

[radbruch]

Hallo

Wie groß sind denn die PullUps an SDA und SCL? Je kleiner umso störsicherer.

Gruß

mic

[MichaelH]

Hallo,

doch klar, der Motortreiber erzeugt PWM (siehe Bild, oberer Channel). Es gibt nur mehrere Möglichkeiten, wie man ihn seinen Soll-Tastgrad und die Drehrichtung vorgeben kann. Ich hab mich halt für I²C entschieden, da ich den Bus auch noch für nen anderen Sensor brauche.

Ich hatte noch vergessen, zu erwähnen, dass die Motortreiber in einem früheren Aufbau problemlos gingen. Als ich dann etwas Ordnung in die Verdrahtung (die war ziemlich wurstelig...) rein gebracht hab kam es zu dem oben genannten Problem. Die Verdrahtung ist aber korrekt, sonst würde es nicht kurzzeitig gehen...



Die Pullups bei SDA und SCL liegen bei 4,7kΩ. hab auch mal testweise noch jeweils nen zweiten 4,7kΩ parallel dazu gehängt. Hat sich aber ned viel geändert (ich bin mir ned sicher, aber es kann sein, dass es länger gedauert hat, bis o.g. Fehler auftrat).



Achja, die Masse am Logikteil hab ich nicht angeschlossen (um Masseschleifen zu vermeiden...), da diese bereits intern auf dem Treiber gebrückt sind.


Gruß
Michael

[radbruch]

Hallo

Mit I2C habe noch nicht so viel gemacht, das letzte waren zwei PCF8574 als Porterweiterungen (https://www.roboternetz.de/phpBB2/zeigebeitrag.php?p=525681#525681). Das funktionierte erst zuverlässig, nachdem ich zusätzlich zu den schon vorhandenen 4k7 noch jeweils 1k als PullUps eingebaut hatte.

Gruß

mic

[Jakob L.]

Die Störsicherheit des I2C-Busses könnte man einerseits durch eine Reduzierung der Pullup-Widerstände und andererseits auch durch zusätzlich eingebaute Kapazitäten zwischen SDA bzw. SCL und GND erhöhen. Die Kapazitäten helfen gegen die kurzzeitig eingekoppelten Störsignale von dem Motortreiber, begrenzen aber auch die maximal mögliche Busgeschwindigkeit. Laut Spezifikation darf die Gesamtkapazität maximal 400 pF sein. Da könnte man also testweise mal ca. 100-300 pF zusätzlich einbauen.

Das mit der nicht angeschlossenen Masse des Logikteils könnte auch der Fehler sein. So hat man wahrscheinlich eine relativ grosse Fläche zwischen der Groundleitung über den Leistungsteil und den I2C-Steuerleitungen. Über die Fläche können induktiv Störungen einegkoppelt werden. Das ist auch der Grund, warum man bei einem Oszilloskop immer den Masseanschluss von jedem Tastkopf anschliesst, auch wenn die Massen schon anderweitig (z.B. Schutzleiter) verbunden sind. Die Tatsache, dass kein Motor angeschlossen ist, heisst auch nicht zwangsläufig, dass bei den PWM-Schaltvorgängen nicht doch kurzzeitig ein recht hoher Strom fliesst (Umladen von Kapazitäten oder kurzzeitiger Kurzschluss durch gleichzeitiges Leiten der beiden Leistungstranistoren).

[RoboHolIC]

Verdrahtung wurstelig --> geht
Verdrahtung geordnet --> geht nicht

Da bist Du nicht der Erste, dessen (?kopplungsarmer?) Drahtverhau besser funktioniert als die aufgeräumte Variante.

Kommt der Fehler mit PWM auch, wenn die Versorgung der Brücke weg ist?

Weitere Maßnahmen, ergänzend zu Jakob L. :
- Induktions- und widerstandsarme Zuleitungen auf der Leistungsseite.
Kurz und dick schadet hier nie.
- Räumliche Trennung von signal- und energieführenden Leitungen.
Erschwert der bösen Induktion ihr übles Treiben.
- Batterieabgriff für die Logikversorgung unmittelbar am MD03.
So hat Dein µC bestmögliche Tuchfühlung zur MD03-Masse.
- Besser noch: getrennte Versorgung. Die wird ja wärmsten empfohlen.

[MichaelH]

Hallo,

erstmal danke für die Tipps. Aber leider hab ichs immer noch nicht hinbekommen...


Die Störsicherheit des I2C-Busses könnte man einerseits durch eine Reduzierung der Pullup-Widerstände und andererseits auch durch zusätzlich eingebaute Kapazitäten zwischen SDA bzw. SCL und GND erhöhen.
Ich habs mal ausprobiert (sowohl beides einzeln, als auch beides zusammen). Widerstände auf ca. 1k reduziert und Kondensatoren mit ca. 200pF eingebaut. Das Bild am Oszi ist aber leider (bis auf die runderen Flanken) gleich.



Das mit der nicht angeschlossenen Masse des Logikteils könnte auch der Fehler sein.
Das wird es vermutlich aber bei mir nicht sein, weil ich die Masse erst abgeklemmt hab, als der Fehler auftrat (habe gedacht, das könnte die Fehlerursache sein, u.a. da im Herstellerdokument auch das Thema Masseschleife angesprochen wird...).



Umladen von Kapazitäten oder kurzzeitiger Kurzschluss durch gleichzeitiges Leiten der beiden Leistungstranistoren.
Ok, du hast recht. Das würde auch mit dem Oszibild übereinstimmen. Da ja quasi bei jeder Änderung vom Mosfet (sowohl steigende, als auch fallende Flanke) diese blöde "Nadel" auftritt.



Kommt der Fehler mit PWM auch, wenn die Versorgung der Brücke weg ist?
Ich hab die 24V Versorgung der Brücke weggenommen (5V Logikteil hatte noch Saft) und da ist er nicht vorhanden.



- Induktions- und widerstandsarme Zuleitungen auf der Leistungsseite.
Kurz und dick schadet hier nie.
Der Querschnitt ist etwa 2,5x so hoch, wie er eigentlich für die Maximallast des Motors (läuft gerade bei nur einem Bruchteil von dessen) sein müsste.
Zusätzlich hab ich diese Leitung heute geschirmt neu gelegt.



- Räumliche Trennung von signal- und energieführenden Leitungen.
Erschwert der bösen Induktion ihr übles Treiben.
Soweit es möglich war, gemacht.



- Besser noch: getrennte Versorgung. Die wird ja wärmsten empfohlen.
Das werd ich morgen mal mit einem zweiten Netzteil (läuft momentan noch nicht mit Akkus) versuchen. Der momentan verbaute Schaltregler hat nämlich keine galvanische Trennung. Von dem her eine gute Idee.



Ich vermute mittlerweile, dass die Störung hauptsächlich über das Massesignal kommt. Wenn ich nämlich zwischen Netzteil-GND und zwischen meinem "Logikpegel"-GND messe, hab ich auch diese netten Störungen auf meinem 0V-Signal. Die Störung ist auch zwischen GND und 24V messbar.

Wäre es ansonsten mal zu empfehlen vor meinem Schaltregler eine Entstörschaltung aus dem KFZ-Bereich einzubauen?



Gruß
Michael

[MichaelH]

Guten Morgen,





- Besser noch: getrennte Versorgung. Die wird ja wärmsten empfohlen.
Das werd ich morgen mal mit einem zweiten Netzteil (läuft momentan noch nicht mit Akkus) versuchen. Der momentan verbaute Schaltregler hat nämlich keine galvanische Trennung. Von dem her eine gute Idee.

Ich hab das grad mit nem getrennten 2. Netzteil versucht, hat leider keine Änderung gebracht... :frown:


Gruß
Michael

[uffi]

hast Du schon mal versucht, an den PWM Leitungen zum Motor Entstörkondensatoren anzuschließen?
Empfehlung: sowohl direkt am Motortreiber als auch direkt am Motor 100nF Keramik Kondensatoren.

[MichaelH]

Hallo,

ich habs grad probiert. Hab mal Folienkondensatoren mit 100nF verwendet. Jeweils von beiden PWM Ausgängen zur Masse. Aber dann blinkt die Überlastungs-LED am Motortreiber. Frag mich nur warum. der Blindwiderstand durch den Kondensator ist ja bei den Werten nicht sonderlich niedrig. Und dass der Motortreiber für ein paar uS überlastet ist glaub ich eigentlich auch ned, der kann ja 20A...

Gruß
Michael

[uffi]

ja, das kann ja wirklich nicht sein!
Hat der Motortreiber eigentlich interne Freilaufdioden?

[MichaelH]

Hallo,

stimmt das mit den freilaufdioden hatt ich mich auch schonmal gefragt, ist aber irgendwie in Vergessenheit geraten... :oops:

Da ich mich mit SMD Bauteilen ned so auskenne, hab ich mal nach nem Schaltplan für den Treiber gesucht. Bin fündig geworden.
http://www.robot-electronics.co.uk/images/md03sch1.gif
http://www.robot-electronics.co.uk/images/md03sch2.gif -> Leistungsteil

Also im Schaltplan find ich keine Freilaufdioden! Irgendwie unverständlich, dass bei so einem Motortreiber keine verbaut sind.

Wie müsst ich denn die Freilaufdioden bei der H-Brücke anbringen?
Könnte man das so machen?
http://i54.tinypic.com/wqoqyp.png


Wenn ja, müssen es unbedingt Shottkys sein? Ich weiß nämlich ned, ob ich welche da hab...


Gruß
Michael

[uffi]

Also dann ist die Sache wohl klar:
ohne Freilaufdioden hast Du immense Überspannungspikes an den Motoren aufgrund der induktiven Last, die beim Abschalten den Strom weiter führen will.

Normale pn-Diode gehen auch als Freilauf, es müssen keine Schottky-Dioden sein. Dein Schaltbild ist o.k.

[uffi]

schau lieber nochmal in das Datenblatt: normalerweise haben solche MOS-FETs interne Freilaufdioden, die intrinsisch zum Transistor gehören. Würde mich auch sehr wundern, wenn die hier fehlen.

Das sind hier p-Kanal MOSFETs. d.h. dass die p+ dotierte Drain und source haben und dazwischen liegt ein n-Gebiet. Eigentlich sind die Dioden im Schaltplan auch angedeutet durch den Pfeil am Kanal des Transistors.

[RoboHolIC]

Allerdings ist diese interne antiparallele Diode m.W. parasitärer Herkunft und längst nicht bei jedem MOSFET auch als echte Freilaufdiode spezifiziert, sodaß man bei massiv induktiven Lasten nicht um echte externe Freilaufdioden herumkommt.

Zum Typ der Dioden: Wenn nur selten geschaltet wird, mag eine einfache Diode -sogar 1N400x- funktionieren. Aber nur im lückenden Betrieb, d.h. wenn der Strom zwischendurch auch mal wieder Null wird.
Im nichtlückenden Betrieb ist ein Schottky-Typ angezeigt, das entspricht dann nämlich einem Schaltnetzteil: keine Erholungsphase zwischen leitendem und sperrendem Zustand der Freilaufdiode. Das wäre sparen am falschen Ende.
PWM überstreicht i.d.R. beide Bereiche. Bei klein(st)en Tastverhältnissen lückend, bei steigendem Tastverhältnis dann ab einem bestimmten Punkt bis zum Bodenblech nichtlückend.

[MichaelH]

Hallo,

Danke für die Infos!


Shottkys hab ich leider keine gefunden. Ich hab mal den Typ MR851 (Datenblatt (http://www.datasheetcatalog.org/datasheet/on_semiconductor/MR850-D.PDF)) getestet. Soll laut Datenblatt schnell sein.

Hat aber leider nix gebracht, I²C-Fehler tritt weiterhin auf und das Oszibild sieht ähnlich aus. Lohnt es sich da Shottkys zu holen und den Test dann nochmal zu wiederholen?


Gruß
Michael

[MichaelH]

Hallo nochmal,


ich hab mal den Strom von den Zuleitungen von einem Motortreiber gemessen. Das sieht so aus (CH2):
http://i55.tinypic.com/6hmcnt.jpg
Ist das normal? Müsste der Strom nicht gleichmäßiger sein? Auf den Motortreibern ist ja jeweils ein großer Elko, daher müsste der Strom doch da herkommen (und der Elko relativ gleichmäßig geladen werden), oder?
Der Strom direkt am Netzteil ist übrigens sauber. Kann es sein, dass der Strom der Treiber sich auf mehrere Elkos von den Motortreibern (übrigens 3 Stück) verteilt?

Und was mir grad noch eingefallen ist, was ich aber schon erwähnt hab: Der Fehler tritt ja auch auf, wenn die Motoren NICHT angeschlossen (aber die 24V Versorgung am Motortreiber anliegt) sind. Also dürfte es ja nicht an den Freilaufdioden liegen...

Bei so nem Mist bekommt man doch echt die Krise... :cry:


Gruß
Michael

[RoboHolIC]

Na ja, deine Diode ist zwar wirklich schnell, läßt aber einen riesigen reverse recovery Strom durch: ein 2A-Peak am Motor vorbei jedes mal, wenn der im Freilauf abklingende, aber noch immer fließende Motorstom mit der nächsten ON-Phase der Brücke wieder auf die vorherige Höhe gepusht wird. Dazu noch der Motorstrom selbst.
Vergleiche das mal mit einer Schottky SB350 -nur ein willkürliches Beispiel-, da sind es gerade mal temp.abhängige 0,5..20mA. Also, den Versuch mir Schottky-Dioden würd ich mir schon noch geben.

Wenn der Fehler von deinen externen Dioden herrührt, dann braucht's keinen Motor dazu. Allerdings müsste man dann konsequenterweise auch die parasitären Dioden der MOSFETs auslöten :)

Mann, da hast du dir ja wirklich ein sch.... ähm: hochinteressantes Problem an Land gezogen! Bleib dran, das wird schon noch!

[MichaelH]

Guten Morgen,


naja, der Test ohne Motoren war aber leider auch ohne externe Dioden... :-k
Ich werd aber mal schauen, ob ich irgendwo noch Shottkys herbekomm...

Ich hab hier aber noch was interessantes gefunden... ist mir bisher aber noch ned wirklich aufgefallen (vllt. isses auch erst seit kurzem?!):
http://i51.tinypic.com/25u1o2u.jpg

Die ersten Rechtecksignale gehen nicht auf 0V runter. Man muss aber dazusagen, dass der Motor nicht läuft. Das eigentliche Problem tritt ja nur auf, wenn mindestens einer der beiden Motoren läuft.


Das ist bestimmt mal wieder nur nen Problem, was einfach zu beheben ist, wo man aber die Ursache nur schwer findet... :-s


Gruß
Michael

[Jakob L.]

naja, der Test ohne Motoren war aber leider auch ohne externe Dioden... :-k
Ich werd aber mal schauen, ob ich irgendwo noch Shottkys herbekomm...


Die Dioden werden sowieso nur gebraucht, wenn ein Motor angeschlossen ist. Wenn der Fehler auch ohne Motor auftritt, dann kann es nicht an den fehlenden Dioden liegen. Ausserdem würde ich bei so einem Motortreiber-Board erwarten, dass da schon geeignete Dioden dabei sind. Wenn du ein Labornetzteil mit Strombegrenzung hast, dann kannst du das auch einfach überprüfen (ca. 1A Konstantstrom bei maximal ca. 2-3V von einem Motoranschluss zu positiver Versorgungsspannung fliessen lassen und Spannung messen).



http://i51.tinypic.com/25u1o2u.jpg


Schreib doch bitte dazu, was du da gemessen hast. So kann man mit dem Photo nichts anfangen.



Das eigentliche Problem tritt ja nur auf, wenn mindestens einer der beiden Motoren läuft.


Weiter oben im Thread hast du doch geschrieben, dass der Fehler auch ohne angeschlossenen Motor auftritt.

[MichaelH]

Hallo,




Schreib doch bitte dazu, was du da gemessen hast. So kann man mit dem Photo nichts anfangen.

Stimmt, du hast recht...
An Channel 1 ist die Taktleitung des I²C-Busses. Channel 2 ist nicht belegt(vergessen auszuschalten...). Vllt könnte das auch das Problem sein und nicht die im ersten Beitrag genannten "Nadeln". Aber der Absturz des Busses kommt ja erst (nach unregelmäßigen Zeitabständen) bei einer PWM der Motortreiber.





Das eigentliche Problem tritt ja nur auf, wenn mindestens einer der beiden Motoren läuft.


Weiter oben im Thread hast du doch geschrieben, dass der Fehler auch ohne angeschlossenen Motor auftritt.
Jop, sorry, ich hatte mich verschrieben... :oops:
Der Satz müsste so heißen:
"Das eigentliche Problem tritt ja nur auf, wenn mindestens einer der beiden Motortreiber eine PWM ausgibt."



Wenn der Bus "abgestürzt" ist, dann dauern immer die I²C-Befehle von BASCOM sehr lange (im Vergleich zum normal laufenden Bus), beide Bus-Datenpegel liegen dauerhaft auf 5V und danach ist das Err-Bit gesetzt. Das mit der Befehlsdauer hab ich mit setzen eines Ausgangs und mit dem Oszi herausgefunden. Theoretisch könnte man mit dem Watchdog einen Neustart nach "Busabsturz" erzwingen. Das funktioniert, wie ich getestet hatte auch.
Aber der Watchdog sollte ja im normalen Betrieb nicht auslösen... Außerdem ist dann ja der SRAM wieder geleert. Das ist also keine Lösung...


Gruß
Michael

[uffi]

Ja kannst Du denn mal die I2C Kommunikation, und zwar beide Leitungen SDA und SCL mit dem Oszi zeigen zu dem Zeitpunkt, wo der Fehler dann auftritt?

[RoboHolIC]

Den Effekt der Clock-Signale ohne vollen Spannungshub solltest Du m.E. vorrangig bearbeiten. Schwache Clocks sind verlorenen Clocks, dann geht das Busprotokoll sofort baden.
Das sieht nach gegeneinander verschobenen Bezugspotentialen zwischen MD03 und deiner Steuerung aus. Das könnte passieren, wenn versehentlich der Motorstrom über die Masseverbindung der I2C fließt.
Haben die (beiden) MD03-Module jeweils eine eigene Stromzuführung oder sind sie parallel (verdrahtungsmäßig hintereinander geschaltet oder mit stark unterschiedlichen Leitungswiderständen (Länge, Querschnitt) ? In letzteren Fällen sind unterschiedliche GND-Potentiale möglich am I2C-Bus.

Hier wäre es noch gut zu wissen, von welcher Stelle genau das Oszi GND und Signal kriegt. Macht deine Steuerung bei gekapptem Bus ein sauberes Taktsignal? Sehr wahrscheinlich schon; zur Fehlereingrenzung soltest du das sicherstellen.

Vielleicht solltest Du das MD03 auch erstmal analog ansteuern und sicherstellen, daß es für sich allein sauber läuft. Sind die internen Dioden der MOSFET wirklich als Freilaufdioden zu gebrauchen? Datenblatt geprüft? Welche MOSFETs sind verbaut? Vielleicht stören die internen Dioden nicht, reichen aber auch nicht aus. Es können ja zwei verschiedene Ursachen zum selben Fehler Busstörung führen.

[MichaelH]

Hallo,

erstmal Danke für die Antwort.




Ja kannst Du denn mal die I2C Kommunikation, und zwar beide Leitungen SDA und SCL mit dem Oszi zeigen zu dem Zeitpunkt, wo der Fehler dann auftritt?
Jap, werd ich am Donnerstag machen.


Das könnte passieren, wenn versehentlich der Motorstrom über die Masseverbindung der I2C fließt.
Das lustige ist ja, dass das mit den Signalflanken ja immer auftritt. Also auch wenn der Motortreiber gar nix ausgibt und es folglich keinen Motorstrom gibt. "Aufhängen" tut sich der Bus hingegen (zumindest fast) immer nur wenn die Treiber was ausgeben.



Hier wäre es noch gut zu wissen, von welcher Stelle genau das Oszi GND und Signal kriegt.
Das Oszi bekommt sein GND über einen Sternpunkt, an dem alle meine 5V Verbraucher, wie Mikrocontroller und Sensoren angeschlossen sind. Der Motortreiber ist (wie bereits erwähnt) nur auf der Leistungsseite mit GND verbunden (dessen GND führt also noch vom Oszi über den Schaltregler und über die Motorleitungen...). Wenn die Morortreiber laufen würden, dann hätte das der Fehler mit den Flanken sein können, aber so? Ich werd das trozdem mal wieder umverdrahten, dass beide Leistung- und Steuerungsteil wieder einen eigenen GND haben...

Vom Querschnitt sind die Motorleitungen großzügig (1,5²), die Steuerleitungen hingegen sind dünn (0,2² oder so...).



Macht deine Steuerung bei gekapptem Bus ein sauberes Taktsignal? Sehr wahrscheinlich schon; zur Fehlereingrenzung soltest du das sicherstellen.
Werd ich machen.



Vielleicht solltest Du das MD03 auch erstmal analog ansteuern und sicherstellen, daß es für sich allein sauber läuft.
Hab ich mir auch schon überlegt. Aber früher lief es ja mal mit I²C, ohne Fehler...
Mal schauen...



Sind die internen Dioden der MOSFET wirklich als Freilaufdioden zu gebrauchen? Datenblatt geprüft? Welche MOSFETs sind verbaut?
Es sind vier IRFIZ48V (Datenblatt (http://www.robot-electronics.co.uk/datasheets/irfiz48v.pdf)) verbaut.


Gruß
Michael

[RoboHolIC]

Das IRFIZ48V-Datenblatt hab ich mir zu Gemüte geführt; schaut im Hinblick auf die Reverse Diode sehr gut aus. Diesen Punkt würde ich doch wieder ganz hinten anstellen.

Hast du die Motortreiber auch mal gründlich sichtgeprüft? Lötzinnreste, Brücken, kalte Lötstellen, eben die klassischen Fehlerquellen.

Der nächste große Schritt wäre m.E., die Verdrahtungen wieder zu lösen und von deiner Steuerung ausgehend Stück um Stück wieder neu zu verbinden, z.B. auch den I2C-Bus mal ohne +5V-Leitung zu betreiben, dabei die MD03-Logik getrennt von deiner Steuerung zu versorgen undsoweiter.
Dabei die Bussignale auf beiden Seiten prüfen (Oszi + Software). Irgendwann kommt man dann der Störungsursache auf die Spur.

[Richard]

Wie lang ist denn die I²C Verbindung? Schon einmal mit geschirmten Kabel versucht bei dem der Schirm EINSEITIG an GND liegt?

Gruß Richard

[MichaelH]

Hallo,



Hast du die Motortreiber auch mal gründlich sichtgeprüft? Lötzinnreste, Brücken, kalte Lötstellen, eben die klassischen Fehlerquellen.
Ja, das hatte ich schon einmal geprüft



Der nächste große Schritt wäre m.E., die Verdrahtungen wieder zu lösen und von deiner Steuerung ausgehend Stück um Stück wieder neu zu verbinden
Hmm, ok. Werd ich demnächst mal machen.


Wie lang ist denn die I²C Verbindung?
ca. 30 cm


Schon einmal mit geschirmten Kabel versucht bei dem der Schirm EINSEITIG an GND liegt?
Ja, das hatte ich. Allerdings hatte ich danach das starke Gefühl, dass der Schritt kontraproduktiv war, weil der Fehler dann ziemlich früh auftrat. Deshalb hab ich die Leitung wieder ersetzt.
Das die Adern verdrillt waren, dürfte ja egal sein, oder?

Gruß
Michael

[Richard]

Das die Adern verdrillt waren, dürfte ja egal sein, oder?

Gruß
Michael

Hmmm ?

Normal werden Signal Führende Leter immer mit Nasse / GND verdrillt. Zwei unterschiedliche Signalleiter eher nicht, das kann Ärger geben. deshalb haben bei Flachband Kabeln auch gewöhnlich jede 2. Leitung GND. Bei Deiner Kabellänge sollte das aber noch gehen?

Langsam tippe ich auf einen derart saublöden Fehler auf denen kein Mensch normal kommt, ist mir selber auch gelegentlich passiert. :-(

Gruß Richard

[MichaelH]

Hallo,


hier zwei Bilder vom "Absturz". Die letzte Datenübertragung, die noch stattgefunden hat.

http://i51.tinypic.com/ye1yf.jpg
http://i52.tinypic.com/30w5tlw.jpg
CH1 = SCL
CH2 = SDA




Langsam tippe ich auf einen derart saublöden Fehler auf denen kein Mensch normal kommt
Das kann gut sein. :?


Gruß
Michael

[Jakob L.]

In dem Oszibild sieht man ja kurze Spikes auf den SDA/SCL Leitungen. Der Abstand zwischen zwei direkt aufeinanderfolgenden Spikes liegt bei ca. 5 µs. Wenn das von dem PWM kommt, dann hätte man eine sehr hohe PWM-Frequenz (ca. 100 kHz bei 50% PWM-Tastverhältnis). Was ist denn die tatsächliche PWM-Frequenz?

Bei dem Oszi-Bild ist die genaue Amplitude nicht genau bestimmbar, da die Sample-Rate wohl zu niedrig ist und man immer nur einen Messpunkt irgendwo im Verlauf des Spikes hat. Es kann auch durchaus sein, dass die Spikes durchgängig mit 5 µs Abstand kommen und in dem Bild nur manchmal entsprechend der Abtastung sichtbar sind. Kannst du mal eine Messung mit höherer Sample-Rate machen (CH1: SDA, CH2: Ein Ausgang des Motortreibers)? Dann kann man besser sehen, ob die Spikes tatsächlich mit den PWM-Schaltvorgängen korrelieren.

Welchen Wert verwendest du eigentlich im Moment für die I2C-Pullups? Den Wert der Widerstände auf dem Motortreiber kannst du einfach durch Messung des Stroms zwischen SDA bzw. SCL und GND mit einem Multimeter bestimmen.

[MichaelH]

Hallo,


Die Spikes sind Synchron zur PWM.
Die PWM-Frequenz liegt ca. bei 16kHz. Das mehrere Spikes aufeinander folgen kann unter anderem daran liegen, dass sie manchmal auch bei fallender Flanke der PWM sichtbar (und nicht nur bei der steigenden) sind. Zudem sind es ja 2 Motortreiber. Also sind 4 Spikes kurz nacheinander gut möglich.

Die Sipikes sind aber auch abgeschwächt in der 5V-Versorgung. Könnte es sein, dass die Masse verzogen ist? Mit nem speraten Netzteil für die Logik hab ichs aber auch schon probiert...

http://i52.tinypic.com/2uxwqhj.jpg
Das Bild ist ebenfalls zum Abstürzzeitpunkt.

Hier noch nen Bild mir der Flanke der PWM.
http://i51.tinypic.com/2d7ge3c.jpg

Der Pullup liegt gerade bei ca. 1k.


Gruß
Michael

[Jakob L.]

Die Flanke in dem zweiten Bild hat eine Amplitude von ca. 2V. Das kann reichen, um den Logikpegel zu verändern. Versuch es doch mal mit einem Kondensator ( 100-200 pF ) zwichen SDA/SCL und GND an beiden Seiten der I2C-Leitung. Vielleicht reicht das, um die Störungen zu unterdrücken.

Noch ein Vorschlag zur Fehlersuche; PWM Einschalten, dann I2C-Stecker ziehen und mit dem Oszi schauen, ob auf den I2C-Leitungen am Motortreiber Störungen vorhanden sind.

[MichaelH]

Hallo,


so langsam hab ich das Problem glaub in Griff.

Hab jetzt jedem Motortreiber bei der 24V-Versorgung einen LC-Tiefpass mit 4,7nF und 15uH verpasst.
Zusätzlich hab ich der 5V Versorgung auch einen LC-Tiefpass mit mit 4,7nF und 30uH verpasst.

Danach kam der Fehler immer noch ab und zu (aber glaub seltener)... jetzt aber der entscheidende Punkt. Die Schirmung der I²C-Leitung war seither mit dem Gehäuse verbunden (das ja, leitungstechnisch weiter entfernt auch mit der Controllermasse verbunden ist)... jetzt hab ich die mal an direkt an die Masse des AVRs angeschlossen... dann lief alles Perfekt, nach ca. 15-20 Mins kein Busfehler! Hoffe, dass das jetzt auch so bleibt...

Ich möchte mich nochmal an alle, die hier geholfen haben bedanken!


Gruß
Michael

[RoboHolIC]

Ein schöner Lohn für deinen Fleiß.
Herzlichen Glückwunsch!