I2C-Blockade durch Motoren

Ersatz- und Fremdteile, Modifikationen, etc.
Special Hints - Spare- & foreign parts, Modifications, etc.

Moderator: Jan3D

Forumsregeln
Bitte beachte die Forumsregeln!
atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

I2C-Blockade durch Motoren

Beitrag von atzensepp » 12 Sep 2021, 19:32

Hallo zusammen,

versuche gerade mit 3 ft-Mini-Motoren und 3 magnetischen I2C-Positions-Sensoren mit einem Arduino und 3 H-Brücken anzusteuern (PID-Regler).
Prinzipiell funktioniert es zwar, jedoch hängt sich die I2C-Mess-Routine oft auf, wenn die Motoren laufen. :x Wenn ich die Motoren abkoppele tritt dieser Effekt nicht auf. Habt Ihr Ideen, was man dagegen tun könnte?
Watchdog-Timer um I2C-Block zu identifizieren, Ferrit-Perlen, Block-Kondensatoren, abgeschirmte Motor-Leitungen, Puffer-Kondensatoren auf den Mess-Platinen ...

Für Eure Tipps wäre ich sehr dankbar.
Danke
Florian

Benutzeravatar
fishfriend
Beiträge: 1791
Registriert: 26 Nov 2010, 11:45

Re: I2C-Blockade durch Motoren

Beitrag von fishfriend » 12 Sep 2021, 19:48

Hallo...
Schwache Spannungsversorgung...
Getrennte Kabel / Führung der Kabel...
Getrennte Spannungsversorgung...
PWM streut ein...
Kabelquerschnitt...
Mit freundlichen Grüßen
fishfriend
Holger Howey
ft Riesenräder PDF: ftcommunity.de/knowhow/bauanleitungen
TX-Light: Arduino und ftduino mit RoboPro

Benutzeravatar
elektrofuzzis
Beiträge: 212
Registriert: 25 Jun 2016, 09:40

Re: I2C-Blockade durch Motoren

Beitrag von elektrofuzzis » 12 Sep 2021, 19:53

Hallo Florian,

da gibt es einige Möglichkeiten. Ich tippe darauf, dass Dir die Spannungsversorgung am Sensor zusammenbricht.

Probier mal in der Reihenfolge:

Hast Du die Motoren (und damit die H-Bridges) auf einer eigenen Stromversorgung? Wenn nein, dann von der des Arduino trennen.

Was für H-Bridges setzt Du ein? Fette Elkos >= 10uF in die Versorgung der H-Bridges gegen GND schalten.

4.7kOhm Widerstände zwischen +5V und SDA sowie +5V und SDC am Sensor schalten. Der Wert des Widerstands ist unkritisch, 10k gehen auch.

10uF Kondesatoren direkt am Sensor zwischen GND und +5V.

Wie lange ist das Kabel zu Deinen Sensoren? 1-2 m sind unkritisch, darüber ist Glücksache.

Gruss

Stefan

atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 12 Sep 2021, 20:25

Hallo Holger und Stefan,

erst mal danke für Eure ersten Ratschläge.

Motoren laufen auf eigener Stromversorgung.
Verwende ein Arduino-Motor-Shield für 2 Motoren und für den dritten Motor eine Eigenbau-Mosfet-Brücke.
Elkos habe ich nur für die Mosfet-Ansteuer-Elektronik.

4.7kOhm Widerstände zwischen +5V und SDA sowie +5V und SDC am Sensor sind geschaltet.

10uF Kondesatoren direkt am Sensor zwischen GND und +5V werde ich mal probieren.

Kabel zu den Sensoren sind jeweils 40 cm Flachband ungeschirmt.

Florian

juh
Beiträge: 904
Registriert: 23 Jan 2012, 13:48

Re: I2C-Blockade durch Motoren

Beitrag von juh » 12 Sep 2021, 20:51

Mir kommt bei der Fehlerbeschreibgun das Thema Entstörkondensatoren in den Sinn.

vg
Jan

atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 12 Sep 2021, 23:06

Was mir aufgefallen ist, dass der alte kleine Mini-Mot signifikant mehr Probleme macht als die neuere Variante.
Das mit den Entstörkondensatoren könnte schon hinkommen. Ich habe eine 4.7nF parallel zum Motor geschaltet.
Das könnte etwas zu klein sein. Und offenbar muss man das öfnnen und 3 Kondenstatoren einbauen. So was auch!

atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 12 Sep 2021, 23:22

Abgeschirmte Kabel verwendet und 100nF-Kondensatoren (nur 1) angelötet. Bringt nix. Ein dicker Motor allein funktioniert. Sobald ich den zweiten (der kreischt übrigens wie ein Schimpanse, wenn das was zu bedeuten hat) dazuschalte treten die Fehler auf.

Karl
Beiträge: 2212
Registriert: 24 Sep 2016, 17:28

Re: I2C-Blockade durch Motoren

Beitrag von Karl » 13 Sep 2021, 06:58

Hallo Atzensepp,
dann gib dem "kreischenden Schimpansen" statt einem Kondensator zum "knabbern" doch
mal ins vordere Lager, zusätzlich ins hintere evtl. auch, einen kleinen Tropfen Öl zu "saufen".
Ein Test mit dem "ruhigen Schimpansen" ohne Partner, ungleichmäßig stark händisch abgebremst.
Meckert er durch Erzeugen von Störungen auch ?

juh
Beiträge: 904
Registriert: 23 Jan 2012, 13:48

Re: I2C-Blockade durch Motoren

Beitrag von juh » 13 Sep 2021, 08:23

atzensepp hat geschrieben:
12 Sep 2021, 23:22
der kreischt übrigens wie ein Schimpanse
Dann mal ein weiterer Schuss ins Dunkel: PWM-Frequenz?

vg
Jan

Edit:

Ansonsten würde ich mal mit einem logic analyzer genauer anschauen, was bei "hängt sich die I2C-Mess-Routine oft auf" genau passiert.

Und haben die verwendeten I2C-Module fest verbaute Pullups? Bei drei Modulen sind die dann parallel geschaltet, ggf. mit Deinem externen dann 4 x 4,7k parallel, das könnte in der Summe sehr (zu) klein und störanfällig werden.

atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 13 Sep 2021, 11:14

Hallo zusmmen,

vielen Dank für Eure Ratschläge!

Inzwischen bin ich weiter gekommen:
Motoren haben 100nF-Kondensatoren über den Anschlusspolen, Motorleitungen sind geschirmt.
Sensor-Platinen haben 33uF-Kondensatoren über Betriebsspannung.

Und folgende Maßnahmen haben dann eine Verbesserung gebracht:
Die Steuerelektronik wird jetzt mit einem separaten 5V-Netzteil betrieben,
der Arduino über USB und Motor-Shield über eine weitere externe Stromversorgung.
Und ich verwende die größeren Mini-Mots.
Beobachtung: Betreibe ich den kleinen Mini-Mot in der Nähe mit einem 40cm-Kabel und einer Batterie setzt die Schaltung sofort aus.

Mit dem Logik-Analysator muss ich mal schauen. Ich hab nur einen Bus-Pirate. Der tut es vielleicht.

@Jan: es scheinen keine Pull-Ups uf den Sensor-Boards zu sein. Nur die SCL-Leitungen sind zusammen geschaltet, die SDA-Leitungen sind über einen CMOS-Multiplexer an den Arduino angekoppelt.

@Karl: Öl vorne brachte jetzt noch nix. Zum Ölen des hinteren Lagers werde ich noch den Motor öffnen.

Karl
Beiträge: 2212
Registriert: 24 Sep 2016, 17:28

Re: I2C-Blockade durch Motoren

Beitrag von Karl » 13 Sep 2021, 12:05

Hallo,
....., die SDA-Leitungen sind über einen CMOS-Multiplexer an den Arduino angekoppelt.
wenn der Multiplexer für diesen Kanal hochohmig ist hängt SDA des Sensors in der Luft ?

Hätte noch einige Punkte:
Zentraler Massepunkt unter Berücksichtigungen der einzelnen Schaltungsteile - Polaritätswechsel z. B..
Verzögerungen durch den Multiplexer weil nur SDA geschaltet wird - dazu Leitungskapazitäten und Eingangs-
kapazitäten. Eigentlich nur bei höheren Geschwindigkeiten relevant. Multiplexer schaltet genau genommen
auch nicht schlagartig, die Kapazitäten müssen auch umgeladen werden.

atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 13 Sep 2021, 12:56

@Karl: habe ein Delay von 10us zwischen Umschltung des Multiplexers und der Messung eingebaut. Das sollte für die Umschaltung reichen.
Immerhin brachte eine beidseitige "Motorölung" den Schimpansen zum Schweigen :lol:

Der Aufbau läuft jetzt mehrere Minuten ohne Fehler. Dann kommt wieder ein Hänger. Und dann drehen die Motoren durch ohne zu stoppen.
Nicht auszudenken, wenn das eine Regelung in einem Flugzeug wäre.

Noch auszuprobieren wären:
- Bereinigung des "fliegenden" Aufbaus (Schleifen in Kablen des Steckboards)
- abgeschirmte Leitungen zu den Sensoren verwenden
- Oszillografieren des I2C-Busses
- I2C durch Bit-Banging auslesen, damit ich auf die Hänger reagieren kann

Benutzeravatar
Kali-Mero
Beiträge: 595
Registriert: 21 Nov 2017, 12:28
Wohnort: Karlsruhe
Kontaktdaten:

Re: I2C-Blockade durch Motoren

Beitrag von Kali-Mero » 13 Sep 2021, 17:14

…was auch immer gerne als Fehlerquelle auf I2C-taugt, ist der 5s-Bug.

Im „Online“-Modus muss spätestens alle 5 Sek auf dem Bus gequasselt werden, sonst hängt sich RoboPro auf…

Bestimmt hier nicht der Fall, aber es muss ja mal wieder drüber gesprochen werden. ;-)

Grüßle
Der Kali

juh
Beiträge: 904
Registriert: 23 Jan 2012, 13:48

Re: I2C-Blockade durch Motoren

Beitrag von juh » 13 Sep 2021, 18:04

atzensepp hat geschrieben:
13 Sep 2021, 11:14
@Jan: es scheinen keine Pull-Ups uf den Sensor-Boards zu sein.
Du benutzt doch die von Seed Studio, richtig? Lt. Schaltplan sollten die 4,7k Pullups haben. Ich würde ja mal versuchen, den Stecker zu umgehen und direkt an TP8 und TP9 zu gehen, um das als Fehlerquelle auszuschließen.

vg
Jan

pullups.png
pullups.png (15.34 KiB) 4892 mal betrachtet

atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 13 Sep 2021, 22:19

Leitungen zu den Sensoren sind jetzt abgeschirmt. Es treten immer noch Hänger auf.
Die Multiplexer-Schaltung ist auch nur eine Notlösung, da ich keinen 4051 zur Hand hatte.
MUX1.jpg
MUX1.jpg (21.34 KiB) 4848 mal betrachtet
Vielleicht muss die SCL-Leitung auch gemultiplext werden. EDIT: habe ich ausprobiert, funktioniert trotzdem nicht.

@Jan: wenn ich direkt auf TP8 und 9 gehe sind doch auch noch Pull-Up-Widerstände dran. Oder sollte ich die Pull-Ups ggf. ganz rausnehmen?

Benutzeravatar
elektrofuzzis
Beiträge: 212
Registriert: 25 Jun 2016, 09:40

Re: I2C-Blockade durch Motoren

Beitrag von elektrofuzzis » 13 Sep 2021, 23:31

Hallo,

der I2C Bus arbeitet auf OpenCollector Technik. Will ein Baustein auf dem Bus eine 0 senden, so schaltet der Baustein mit einen Transistor die Leitung auf GND. Für eine 1 macht der Baustein nichts und verlässt sich auf die Pullup Widerstände. Es reicht in der Regel aus, je Leitung einem Pullup zu haben (in der Größenordnung 4.7 bis 10k).

Ein zweiter Pullup schadet nicht. Der Bus funktioniert genauso. Um nicht nachdenken zu müssen, kleistert man in der Regel einfach an jeden Baustein einen Pullup. Der Transistor der nun auf 0 schaltet, bekommt durch mehr Pullups zwar einen höheren Strom ab, aber diese können meist 20mA ab. Bei 4.7k Pullups liefert jeder Pullup ca. 1mA, damit wird es erst beim 20. Sensor problematisch.

Der AS5600 arbeitet mit einer 3.3V Logik, der normale Arduino arbeitet mit 5.5V. Deshalb sind auf vielen 3.3V Sensorboards zwei FETs zur Anpassung des Logiklevels eingebaut (s. Schaltplan von Jan). Du schließt an VCC die Versorgungsspannung deines Controllers an und bist so immer richtig. 3.3V gehen genauso wie 5V.

Was nicht stabil geht, den Arduino an TP8 und TP9 anzuschließen, weil Du dann 3.3 und 5V Logik mischst. Für den OC-Transistor völlig egal, aber nicht für die Eingabgsbeschaltung wenn der Sensor liest.

Mit der Technik kannst Du an eine Leitung im Prinzip beliebig viele Sensoren anschließen, solange Du die Logiklevel beachtet. Die Grenzen des Systems liegen im Protokoll des I2C Bus (klassisch gehen 127 Adressen) und der Kapazität des Kabels.

Die Kapazität des Kabels liegt bei normalen Flachbandkabel bei 72pF je Meter. Mit dem Pullup Widerstand entsteht ein sogenanntes RC Glied. Das Signal ist nicht nachdem der Transistor schaltet 0 oder 1, sondern erst nach 5t = 5*R*C. Der Wert darf die 400kHz der Busfrequenz nicht erreichen. Mit 1 oder 2m Ksbellänge bist Du auch hier meilenweit von der Maximallänge weg.

Deshalb kannst Du ohne Probleme bis zu 20 Sensoren an Deinen Arduino anschließen. Multiplexer brauchst Du nicht und führen nur zu weiteren Fehlerquellen.

Am Anfang des Threads hast Du vom schreienden Gorilla in Motorform gesprochen. Neben der akustischen Ohrbeleidigung hat ein solcher Motor im Zweifelsfall ein lustiges Magnetfeld und fette Störungen auf seinen Steuerleitungen. Deshalb kann dieser Motor problemlos den I2C Bus stören bzw auch auf Deinen Magnetsensoren Störsignale hinterlassen. Der Tropfen Öl hilft dem Ohr und zum Teil auch der Elektronik. Aber wahrscheinlich stört der Motor auch mit Öl noch eine ganze Menge. Mit normalen Hausmessgeräten kannst Du das aber nicht messen.

Störungen auf der Versogungsspannung kannst Du mit Elkos am Sensor minimieren. An SDA und SCL würde der Elko die Kapazität der Leitung erhöhen. Der Spike wird gekillt, aber Du erreichst mit den 5t auch schnell Deine 400kHz und nichts geht mehr. Die geschirmte Leitung hilft da mehr.

Die Klassiker Pullup und Schirmung hast Du schon hinter Dir. Du kannst jetzt nochmal kontrollieren, ob Du irgendwo kalte Lötstellen oder Wackelkontakte am I2C Bus hast. Wenn das alles ok ist und mit anderen Motoren das Problem weg ist, hilft nur den Gorilla ins Altersheim zu stecken und in einen jungen Gorilla zu investieren. (Der Weg über Entstörkondensatoren, Spulen und Feritkerne ist möglich aber extrem aufwendig.) Bislang hatten wir in vielen I2C Modellen noch keine Störprobleme durch aktuelle Mitoren.

Ein Blick in Deine SW solltest Du noch machen. Gerade wenn Du mit Interrupts arbeitest und auf gleiche globale Variablen in Deiner Loop und den Interrupts benutzt, dann wäre das auch ein Klassiker.

Von Deiner Beschreibung müsste es aber der Gorilla sein.

Gruss

Stefan

juh
Beiträge: 904
Registriert: 23 Jan 2012, 13:48

Re: I2C-Blockade durch Motoren

Beitrag von juh » 14 Sep 2021, 00:57

atzensepp hat geschrieben:
13 Sep 2021, 22:19
@Jan: wenn ich direkt auf TP8 und 9 gehe sind doch auch noch Pull-Up-Widerstände dran.
Ja, und das war nicht mein einziger Kurzschlussfehler. Dass Du noch mit 5V arbeitest, war der andere, s. elektrofuzzi.

@elektrofuzzi, der AS5600 kann beides, 5V und 3,3V, ist bei diesem Modul aber auf 3,3V Modus konfiguriert, 5V-Arduino direkt wäre da in der Tat nicht so gut. Vor zu vielen parallelen pullups wird bei I2C oft als mögliche Fehlerquelle gewarnt, Deine Herleitung, dass es hier nicht das Problem ist, ist aber überzeugend.

vg
Jan

Benutzeravatar
elektrofuzzis
Beiträge: 212
Registriert: 25 Jun 2016, 09:40

Re: I2C-Blockade durch Motoren

Beitrag von elektrofuzzis » 14 Sep 2021, 06:08

Hallo,

wenn es dieser Sensor ist https://wiki.seeedstudio.com/Grove-12-b ... or-AS5600/, dann kannst Du an den Lötpads die 3.3V Level abgreifen. Am 4-pol JST Stecker kannst Du an Pin 2 mit dem Anlegen von 3.3V oder 5V die Logikspannung für diesen Stecker festlegen.

Damit die Logikspannung zum Arduino passt musst Du deshalb diesen Stecker nehmen und 5V vom Arduino als Versorgungsspannung anlegen.

Aber der Sensor selbst kann nur eine Adresse. Das heisst, Du kannst nur einen Sensor von dem Typ an den Bus anschließen. Weiter oben schreibst Du von mehreren Sensoren. Mehrere AS5600? Dann brauchst Du mehrere getrennte I2C Busse oder musst dies durch einen Multiplexer herstellen. Wegen der OC-Technik muss es entweder ein analoger Multiplexer oder ein expliziter I2C Multiplexer sein.

Gruss

Stefan

atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 14 Sep 2021, 08:13

Hallo Stefan,

Vielen Dank für Deine ausfühlrichen Erläuterungen. Ich verwende derzeit die 5V vom Arduino und einen Multiplexer mit CMOS-ICs (MC14016 +
74LS139) wie in dem Schaltplan gezeigt.

In der SW habe ich jetzt einen Timeout beim I2C eingebaut, der schon eine Vielzahl von Glitches abdeckt.
Leider habe ich festgestellt, dass es auch Hänger des ganzen Systems gibt (evtl. Serial, die mit 250000 Bd läuft). Hier wird vermutlich ein Watchdog Abhilfe schaffen. Die Einstrahlungen durch die Motoren sind offenbar beträchtlich.

atzensepp
Beiträge: 658
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 14 Sep 2021, 10:35

Ich habe jetzt mal die I2C-Signale mit dem Mini-DSO angesehen.
Dabei fallen mir im Regelbetrieb sporadische kurze Spikes auf, die mir spanisch vorkommen.
Auch beim Motor-Betrieb sehen die Signale so aus.
I2C.jpg
I2C.jpg (62.71 KiB) 4721 mal betrachtet
Wie kann ich rausfinden, woran es liegt?

Antworten