I²C - Motortreiber

[Jakob L.]

naja, der Test ohne Motoren war aber leider auch ohne externe Dioden...
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...
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) 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