Störungen von Relais (EMI) bringen I2C-Display/USB aus dem Takt

[M. B. (bema16)]

Guten Tag zusammen,

ich arbeite gerade an einem Versuchsaufbau für eine Heizungssteuerung 
und habe Probleme mit Störeinkopplungen auf den USB- und I2C-Leitungen.

Verwendete Komponenten:
- Arduino Uno R4 Minima
- 230V Heizpatrone mit 400 W
- Meanwell RS-15-12 12V-Netzteil
- Vier PT100 mit jeweils einem MAX31865 Breakout-Board 
(SPI-Schnittstelle)
- SHT31 Feuchtigkeitssensor (I2C-Schnittstelle)
- OLED-Display (I2C-Schnittstelle)
- Encoder/Drehgeber mit integriertem Taster
- Zwei mechanische Relais, einmal als Sicherheitsabschaltung in 
Verbindung mit einem Thermoschalter und einmal als Regelkontakt

Der Arduino misst die Temperaturen mithilfe der PT100-Sensoren. Einer 
der Temperaturwerte wird verwendet, um mit einem PID-Regler die 
Temperatur an der Heizpatrone auf einem konstanten Wert zu halten.
Auf dem Display ist eine kleine Menüsteuerung realisiert, um die Heizung 
ein- und auszuschalten und die Solltemperatur vorgeben zu können. Die 
aktuellen Messwerte für Temperatur und Feuchtigkeit werden ebenfalls auf 
dem Display angezeigt. Zusätzlich werden diese Werte über die 
USB-Schnittstelle an den PC übertragen, um diese loggen zu können.

Hinweis: Bei den bisherigen Arduinos, die ich verwendet habe, geht die 
USB-Leitung auf einen USB-Seriell Wandler und anschließend auf den 
eigentlichen Mikrocontroller. Bei dem Arduino Uno R4 Minima geht die 
USB-Leitung hingegen direkt auf den Mikrocontroller, es ist kein 
USB-Seriell Wandler dazwischengeschaltet. Der Arduino erscheint am PC 
als virtueller COM-Port.

Weiter Hinweis: In den Relaissockeln sind bereits Freilaufdioden 
integriert, deshalb habe ich diese nicht in den Schaltplan 
eingezeichnet.

Die Software funktioniert soweit problemlos. Die Menüsteuerung 
funktioniert so wie sie soll und die PID-Regelung arbeitet erstaunlich 
genau. Über den Encoder lässt sich das ganze System einwandfrei 
bedienen.
Ein Foto vom Aufbau habe ich angehängt. Ich verwende eine einfache 
Sperrholzplatte mit 3D-gedruckten Hutschienen und Kabelkanälen. Der 
obere Kabelkanal enthält ausschließlich 230V-Leitungen, während der 
untere Kabelkanal nur Steuerleitungen (5V/12V) enthält. Nicht besonders 
schön, aber für diesen Versuchsaufbau erstmal ausreichend.

Leider habe ich mit dem aktuellen Aufbau folgende Probleme:
1. Sobald ich die Heizung einschalte, bricht nach einiger Zeit die 
Übertragung der Messwerte an den PC ab. Über das Terminal kommen die 
ganze Zeit Daten zum PC, aber irgendwann stoppt die Übertragung einfach 
und es kommen keine neuen Daten mehr an. Der Arduino ist nach wie vor am 
PC als COM-Port sichtbar.
Wenn ich das USB-Kabel ziehe, wieder einstecke und anschließend die 
Verbindung im Terminal neu aufbaue, kommen auch wieder Daten an.
Manchmal passiert dies 30 Sekunden nach dem Start der Messung, manchmal 
dauert es mehrere Minuten.

2. Es kommt ab und zu vor, dass die Anzeige auf dem Display einfriert 
und nicht mehr aktualisiert wird. Ich kann das Menü aber nach wie vor 
"blind" mit dem Encoder bedienen. Wenn ich z.B. blind zu dem Menüpunkt 
zum Ausschalten der Heizung navigiere, kann ich die Heizung auch 
ausschalten.
Wenn ich den Arduino resette, bleibt die Anzeige nach wie vor 
eingefroren. Ich muss das Display (bzw. den Arduino und das Display) 
komplett stromlos machen und anschließend wieder einschalten, damit das 
Display wieder funktioniert. Es scheint so, als ob das Display gar nicht 
mehr auf I2C-Kommandos reagiert.

3. Selten (ca. alle 5-10 Minuten) erhalte ich mal einen falschen 
Temperaturwert von einem der PT100 - wenn die Temperatur normalerweise 
bei 90 Grad liegt, bekomme ich bspw. auf einmal einen Wert von 714 Grad 
angezeigt.

Sowohl beim Ausfall des Display als auch der USB-Verbindung regelt der 
Arduino die Temperatur problemlos weiter. Ich gehe also davon aus, dass 
die Software nach wie vor läuft, aber die Kommunikation nach außen nicht 
mehr funktioniert.

Ich habe mal mein Oszilloskop an die Signalleitungen geklemmt und konnte 
beim Einschalten des Relais massive Störimpulse messen. Im Anhang 
beispielhaft drei Screenshots, bei denen ich die USB-Leitungen gemessen 
habe. Man sieht, dass hier kurzzeitig die komplette Datenübertragung 
gestört wird. Ähnliche Störungen sind auch auf den I2C-Leitungen 
vorhanden.
Die Störungen treten beim EINschalten des Relais auf, beim Ausschalten 
triggert mein Oszilloskop nicht.

Folgendes habe ich versucht, um das Problem in den Griff zu bekommen:
- Leitung vom Relais zur Heizpatrone (ca. 1,5 m) mit Alufolie umwickelt 
und diese mit PE oder GND verbunden - keine Veränderung
- Ich habe versucht, das Relais mit Alufolie/Metallplatten, die ich mit 
PE verbunden habe, abzuschirmen - keine Änderung
- Austausch des Relais durch ein SSR - die oben beschriebenen Probleme 
treten nach wie vor auf, ich habe hier aber leider keine Messungen mit 
dem Oszilloskop gemacht; kann ich bei Bedarf nachholen
- Schaltung zur Nulldurchgangserkennung (Zero-Crossing) gebaut, um das 
SSR nur im Nulldurchgang einzuschalten - keine Änderung, beim 
mechanischen Relais ist das Schalten im Nulldurchgang durch das 
verzögerte Anziehen in meinen Augen nicht sinnvoll möglich
- Anfangs habe ich einen Relaissockel von Phoenix Contact (2903362) 
verwendet, welcher laut Datenblatt 6 A schafft. Diesen habe ich durch 
ein Wago 788-311 ersetzt, welcher laut Datenblatt 8 A schafft (ist auch 
auf dem Bild im Anhang zu sehen, das Phoenix Relais links daneben ist 
das zur Sicherheitsabschaltung) - keine Änderung
- Beide Kontakte des Wago-Relais parallelgeschaltet - keine Änderung
- Snubber über die Relaiskontakte abgebracht (Versuch 1: 100 Ohm/100 nF, 
Versuch 2: 50 Ohm (2x100 Ohm parallel)/220 nF) - keine Veränderung
- Heizpatrone testweise abgeklemmt, nur noch die Leitung zur Heizpatrone 
ist am Relais angeschlossen (keine Last) - massive Verbesserung, aber 
selten kommt es doch noch zu Ausfällen

Nachdem ich die Ursache der Störungen nicht eindämmen konnte, habe ich 
mich am Filtern versucht:
- 22 pF Kondensatoren nach GND in die I2C-Leitungen geschaltet + 5V 
direkt am Display mit 100 uF gepuffert - spürbare Verbesserung, aber 
nach wie vor häufige Ausfälle
- Leitungen zwischen OLED und Arduino deutlich verkürzt - erneut leichte 
Verbesserung, aber nach wie vor Ausfälle
- Klappferrite um I2C-Leitungen und USB-Kabel angebracht (an beiden 
Enden) - keine Veränderung
- Pi-Filter in die USB-Leitung eingeschliffen (ich weiß, keine gute 
Idee) - Arduino wird am PC nicht erkannt, Deskriptor kann nicht 
abgerufen werden

Mit meinem Transistor-Tester aus China messe ich an der Heizpatrone nur 
Widerstand und keine Induktivität. Auch, wenn ich eine Spule in Serie 
schalte, messe ich nur die Induktivität der Spule und keine zusätzliche 
Induktivität durch die Heizpatrone.
So langsam bin ich mit meinem Latein am Ende und ich weiß nicht, was ich 
sonst noch tun kann. Würde eine geschirmte Leitung zur Heizpatrone evtl. 
etwas bringen? Ich könnte mir vorstellen, dass die Alufolie nicht 
besonders gut dämpft. Die Störungen an der Quelle einzudämmen erscheint 
mir zielführender, als es mit Filtern zu versuchen.
Ich habe den Eindruck, dass es am Prellen der Relaiskontakte liegt. 
Gleichzeitig frage ich mich aber, warum das SSR hier für keine Besserung 
gesorgt hat.

Vielleicht hat ja jemand eine Idee oder Hinweis, wie ich hier 
weiterkomme. Ich würde mich sehr freuen, wenn mir jemand weiterhelfen 
könnte :-)

Danke und ein schönes Wochenende.

EDIT: Ich sehe gerade, dass ich im Schaltplan die Heizpatrone und die 
Nulldurchgangserkennung direkt an den L (vor dem LSS) angeschlossen habe 
- sorry, das ist falsch, sowohl die Heizpatrone als auch die 
Nulldurchgangs-Erkennung sind über den Leitungsschutzschalter 
abgesichert.

[Jörg R. (solar77)]

Ich würde erst einmal die Verdrahtung ändern. Kurze Verbindungen, 
zentraler Punkt für GND.

[Monk (roehrmond)]

Ich empfehle darüber hinaus 1,5k Ohm Pull-Up Widerstände am I2C Bus und 
Snubber entweder an den Kontakten der Relais oder (besser) parallel zur 
Last.

[Falk B. (falk)]

M. B. schrieb:

> 1. Sobald ich die Heizung einschalte, bricht nach einiger Zeit die
> Übertragung der Messwerte an den PC ab.

Was heißt das konkret? Nach welcher Zeit? Fällt das mit einem Schalten 
des Relais zusammen?

> ganze Zeit Daten zum PC, aber irgendwann stoppt die Übertragung einfach
> und es kommen keine neuen Daten mehr an. Der Arduino ist nach wie vor am
> PC als COM-Port sichtbar.

Klingt nach Softwarefehler in deinem Arduino.

> Wenn ich das USB-Kabel ziehe, wieder einstecke und anschließend die
> Verbindung im Terminal neu aufbaue, kommen auch wieder Daten an.

Da macht mindestens der USB-Teil einen Reset, ggf. sogar der ganze 
Arduino.

> Manchmal passiert dies 30 Sekunden nach dem Start der Messung, manchmal
> dauert es mehrere Minuten.

Wie oft schaltet das Relais für die Heizung?

> 2. Es kommt ab und zu vor, dass die Anzeige auf dem Display einfriert
> und nicht mehr aktualisiert wird. Ich kann das Menü aber nach wie vor
> "blind" mit dem Encoder bedienen. Wenn ich z.B. blind zu dem Menüpunkt
> zum Ausschalten der Heizung navigiere, kann ich die Heizung auch
> ausschalten.

Also klemmt der USB Teil und der Rest läuft weiter.

> Wenn ich den Arduino resette, bleibt die Anzeige nach wie vor
> eingefroren. Ich muss das Display (bzw. den Arduino und das Display)
> komplett stromlos machen und anschließend wieder einschalten, damit das
> Display wieder funktioniert.

Dann hast du ein Initialisierungsproblem in deiner Software,

> 3. Selten (ca. alle 5-10 Minuten) erhalte ich mal einen falschen
> Temperaturwert von einem der PT100 - wenn die Temperatur normalerweise
> bei 90 Grad liegt, bekomme ich bspw. auf einmal einen Wert von 714 Grad
> angezeigt.

Das kann ein Störpuls am Analogteil oder SPI sein.

> Ich habe mal mein Oszilloskop an die Signalleitungen geklemmt und konnte
> beim Einschalten des Relais massive Störimpulse messen. Im Anhang
> beispielhaft drei Screenshots, bei denen ich die USB-Leitungen gemessen
> habe. Man sieht, dass hier kurzzeitig die komplette Datenübertragung
> gestört wird. Ähnliche Störungen sind auch auf den I2C-Leitungen
> vorhanden.

Wie hast du das GENAU gemessen?

https://www.mikrocontroller.net/articles/Oszilloskop#Tastk%C3%B6pfe_richtig_benutzen

> Die Störungen treten beim EINschalten des Relais auf, beim Ausschalten
> triggert mein Oszilloskop nicht.

Der Kontakt prellt.

> Folgendes habe ich versucht, um das Problem in den Griff zu bekommen:
> - Leitung vom Relais zur Heizpatrone (ca. 1,5 m) mit Alufolie umwickelt
> und diese mit PE oder GND verbunden - keine Veränderung

Ist nicht sinnvoll. Wenn man schirmen will, muss die Schirmung auch auf 
ein Potential gelegt werden, meist PE oder GND.

> - Ich habe versucht, das Relais mit Alufolie/Metallplatten, die ich mit
> PE verbunden habe, abzuschirmen - keine Änderung

;-) Die Störungen breiten sich hier eher über die Kabel aus.

> - Austausch des Relais durch ein SSR - die oben beschriebenen Probleme
> treten nach wie vor auf,

Merkwürdig. SSR prellen nicht. Allerdings schalten die je nach Typ im 
Nulldurchgang der Spannung oder bei  beliebiger Phasenlage.

> - Anfangs habe ich einen Relaissockel von Phoenix Contact (2903362)
> verwendet, welcher laut Datenblatt 6 A schafft. Diesen habe ich durch
> ein Wago 788-311 ersetzt, welcher laut Datenblatt 8 A schafft (ist auch
> auf dem Bild im Anhang zu sehen, das Phoenix Relais links daneben ist
> das zur Sicherheitsabschaltung) - keine Änderung

Nutzlos.

> - Snubber über die Relaiskontakte abgebracht (Versuch 1: 100 Ohm/100 nF,
> Versuch 2: 50 Ohm (2x100 Ohm parallel)/220 nF) - keine Veränderung

Hmm, merkwürdig.

> - Heizpatrone testweise abgeklemmt, nur noch die Leitung zur Heizpatrone
> ist am Relais angeschlossen (keine Last) - massive Verbesserung, aber
> selten kommt es doch noch zu Ausfällen

Ein Indiz, daß da noch was faul ist.

> - 22 pF Kondensatoren nach GND in die I2C-Leitungen geschaltet + 5V
> direkt am Display mit 100 uF gepuffert - spürbare Verbesserung, aber
> nach wie vor häufige Ausfälle

Schon mal gut, kann man bis 100pF hochgehen.

> - Pi-Filter in die USB-Leitung eingeschliffen (ich weiß, keine gute
> Idee) - Arduino wird am PC nicht erkannt, Deskriptor kann nicht
> abgerufen werden

Das ist Unsinn.

> sonst noch tun kann. Würde eine geschirmte Leitung zur Heizpatrone evtl.
> etwas bringen?

Eher nicht.

> besonders gut dämpft. Die Störungen an der Quelle einzudämmen erscheint
> mir zielführender, als es mit Filtern zu versuchen.

Das ist der Idealfall in Lehrbuch, den man aber oft nicht erreicht. Ich 
glaube eher, daß deine Störsenke, der Arduino mit seinem Drumherum zu 
empfindlich ist. Man muss herausfinden, warum das so ist und 
Gegenmaßnahmen treffen.

> Ich habe den Eindruck, dass es am Prellen der Relaiskontakte liegt.

Vermutlich.

> Gleichzeitig frage ich mich aber, warum das SSR hier für keine Besserung
> gesorgt hat.

Gute Frage.

Du hast schon sehr viel gemacht. Dein Aufbau sieht erstmal gut aus. Aber 
hier noch ein paar Anmerkungen.

Die Ausgangsmasse vom Netzteil sollte geerdet sein, sprich mit PE 
verbunden.
Deine Sensoren soltlen nur über das Kabel zum Arduino geerdet sein, 
nicht zusätzlich irgendwo mit einem Kabel (sternförmige Erdung)
Du solltest eine Status-LED auf dem Arduino reglemäßig blinken lassen, 
wenn deine Sendefunktion zum USB aktiv ist. Damit sieht man, ob die noch 
läuft oder nicht.
Dein Kabel mit SPI zu den ADCs ist schon recht lang, das kann schief 
gehen. Hier sollte man mindestens eine Serienterminierung für SCK 
vorsehen, siehe Wellenwiderstand.
Prüfe, ob du den richtigen SPI-Mode eingestellt hast. Manchmal läuft das 
auch sehr grenzwertig und instabil mit dem falschen Modus.

Zum Testen sollte man die Störung STÄRKER machen. Sprich, schalte das 
Relais oft, sagen wir mit 0,5 Hz. Schalte wenn möglich einen stärkere 
Last. Dadurch provoziert man den Fehler leichter und häufiger und kann 
einfacher und schneller Gegenmaßnahmen prüfen.
Beobachte, wann die Funktionsstörung auftritt.
Dein Display braucht keine 100uF, das ist zuviel und nur bedingt HF 
wirksam. Nimm dort einen 100nF Keramikkondensator.
Den Snubber über dem Relaiskontakt sollte man behalten, dort ist er 
optimal.

[Falk B. (falk)]

In der Software sollte man prüfen, ob das Display noch auf den I2C 
Zugriff reagiert. Wenn nein, muss man einen Softwarereset des Displays 
machen. Im Extremfall, wenn das allein nicht reicht, muss man dessen 
Stromversorgung vom Arduino schaltbar machen und einen Hardwarereset 
machen. Das ist zumindest ein Workaround fpr den Fall, daß man die 
Störung nicht bedämpfen kann.

[M. B. (bema16)]

Erstmal vielen Dank für die bisherige Beteiligung.
Der Elektronikaufbau steht gerade im Nachbarort, ich schaue, dass ich 
ihn bis morgen hier herhole, um die Vorschläge testen zu können.

Jörg R. schrieb:
> Ich würde erst einmal die Verdrahtung ändern. Kurze Verbindungen,
> zentraler Punkt für GND.

Ich werde schauen, wo ich hier noch optimieren kann. Aktuell sitzt auf 
dem Arduino eine Aufsteckplatine und alle Sensoren, das Display, das 
Relais etc. sind dort mittels Steckverbinder angeschlossen und bekommen 
dort auch ihre Masse und Versorgung. Einzige Ausnahme ist aktuell die 
Schaltung für die Nulldurchgangserkennung ganz rechts im Bild. Ich kann 
bei Bedarf ein besseres Bild nachliefern, sobald der Aufbau hier ist.

Monk schrieb:
> Ich empfehle darüber hinaus 1,5k Ohm Pull-Up Widerstände am I2C Bus und
> Snubber entweder an den Kontakten der Relais oder (besser) parallel zur
> Last.

Im Schaltplan sind 4,7k als Pullup beim I2C eingezeichnet, aber der 
Feuchtigkeitssensor und das Display sind "Breakout-Boards", auf denen 
ebenfalls nochmal Pullups sitzen. Ich müsste mal die resultierenden 
Pullup-Widerstände mit dem Multimeter nachmessen.
Snubber habe ich aktuell parallel zu den Relaiskontakten, parallel zur 
Last habe ich tatsächlich noch nicht getestet. Werde ich ausprobieren.

Falk B. schrieb:
> Was heißt das konkret? Nach welcher Zeit? Fällt das mit einem Schalten
> des Relais zusammen?

Der Ausfall fällt definitiv mit dem Schalten des Relais zusammen. 
Manchmal kommt es 10 Sekunden nach dem Einschalten der Heizung zu einem 
Ausfall, manchmal erst nach einigen Minuten, ein Muster erkenne ich 
nicht.
Lasse ich die Heizung ausgeschaltet, funktionieren sowohl Kommunikation 
als auch Display dauerhaft problemlos.

Falk B. schrieb:
> Klingt nach Softwarefehler in deinem Arduino.
>
>> Wenn ich das USB-Kabel ziehe, wieder einstecke und anschließend die
>> Verbindung im Terminal neu aufbaue, kommen auch wieder Daten an.
>
> Da macht mindestens der USB-Teil einen Reset, ggf. sogar der ganze
> Arduino.

Der Arduino macht definitiv keinen Reset, die Heizung bleibt 
eingeschaltet und der PID-Regler regelt weiterhin. Dass der USB-Teil 
einen Reset macht, ist aber gut möglich.

Falk B. schrieb:
> Wie oft schaltet das Relais für die Heizung?

Die Periodendauer beträgt eine Sekunde, der PID-Regler gibt eine 
Einschaltdauer von 0-1000 ms vor. Werte unter 50 ms ignoriere ich in der 
Software (Relais wird nicht eingeschaltet), weil es in meinen Augen 
keinen Sinn macht, ein mechanisches Relais nur so kurz einzuschalten.

Falk B. schrieb:
> Wie hast du das GENAU gemessen?
>
> 
https://www.mikrocontroller.net/articles/Oszilloskop#Tastk%C3%B6pfe_richtig_benutzen

Guter Punkt. Ich habe die Masse mit der Krokodilklemme vom Tastkopf 
abgegriffen, was natürlich nicht optimal ist.
Ich werde die Messung mit einer Massefeder wiederholen und auch den Tipp 
mit der GND-Messung anwenden.

Falk B. schrieb:
>> Folgendes habe ich versucht, um das Problem in den Griff zu bekommen:
>> - Leitung vom Relais zur Heizpatrone (ca. 1,5 m) mit Alufolie umwickelt
>> und diese mit PE oder GND verbunden - keine Veränderung
>
> Ist nicht sinnvoll. Wenn man schirmen will, muss die Schirmung auch auf
> ein Potential gelegt werden, meist PE oder GND.

Ich habe die Alufolie mittels Krokokabel auf PE und GND gelegt (das 
meinte ich in dem von dir zitierten Teil), beides hat für keine 
merkliche Besserung gesorgt.

Falk B. schrieb:
>> - Snubber über die Relaiskontakte abgebracht (Versuch 1: 100 Ohm/100 nF,
>> Versuch 2: 50 Ohm (2x100 Ohm parallel)/220 nF) - keine Veränderung
>
> Hmm, merkwürdig.

Falk B. schrieb:
>> Gleichzeitig frage ich mich aber, warum das SSR hier für keine Besserung
>> gesorgt hat.
>
> Gute Frage.

Ich sehe schon, ich sollte das SSR nochmal einbauen und Messungen mit 
dem Oszilloskop machen. Es ist leider eines dieser "China 40 A SSRs" 
(siehe Bild im Anhang), aber das sollte jetzt erstmal keine Rolle 
spielen. Klicken tut es jedenfalls nicht :D

Falk B. schrieb:
> Die Ausgangsmasse vom Netzteil sollte geerdet sein, sprich mit PE
> verbunden.

Ich habe mal das Blockdiagramm des Netzteils aus dem Datenblatt 
angehängt. Hier ist ein Kondensator von GND nach PE eingezeichnet, eine 
gewisse Filterung sollte also schon vorhanden sein. Ich klemme GND aber 
testweise mal direkt auf PE.

Falk B. schrieb:
> Deine Sensoren soltlen nur über das Kabel zum Arduino geerdet sein,
> nicht zusätzlich irgendwo mit einem Kabel (sternförmige Erdung)

Ich werde prüfen, ob das wirklich überall der Fall ist und ggf. 
Anpassungen vornehmen.

Falk B. schrieb:
> Du solltest eine Status-LED auf dem Arduino reglemäßig blinken lassen,
> wenn deine Sendefunktion zum USB aktiv ist. Damit sieht man, ob die noch
> läuft oder nicht.

Das ist eine gute Idee, werde ich so umsetzen.

Falk B. schrieb:
> Dein Kabel mit SPI zu den ADCs ist schon recht lang, das kann schief
> gehen. Hier sollte man mindestens eine Serienterminierung für SCK
> vorsehen, siehe Wellenwiderstand.
> Prüfe, ob du den richtigen SPI-Mode eingestellt hast. Manchmal läuft das
> auch sehr grenzwertig und instabil mit dem falschen Modus.

Serienterminierung werden ich so umsetzen, ggf. kann ich auch das Kabel 
kürzer machen. Für die MAX31865 verwende ich eine fertige Bibliothek von 
Adafruit, ich werde prüfen, welcher SPI-Modus hier verwendet wird und ob 
es zum Datenblatt des MAX31865 passt.

Falk B. schrieb:
> Zum Testen sollte man die Störung STÄRKER machen. Sprich, schalte das
> Relais oft, sagen wir mit 0,5 Hz. Schalte wenn möglich einen stärkere
> Last. Dadurch provoziert man den Fehler leichter und häufiger und kann
> einfacher und schneller Gegenmaßnahmen prüfen.
> Beobachte, wann die Funktionsstörung auftritt.

Das klingt sinnvoll, werde ich so machen. Evtl. finde ich noch eine 
zusätzliche Last, die ich zur Heizpatrone parallelschalten kann.

Falk B. schrieb:
> Dein Display braucht keine 100uF, das ist zuviel und nur bedingt HF
> wirksam. Nimm dort einen 100nF Keramikkondensator.

Falk B. schrieb:
> Schon mal gut, kann man bis 100pF hochgehen.

Werde ich beides entsprechend abändern.

Falk B. schrieb:
> In der Software sollte man prüfen, ob das Display noch auf den I2C
> Zugriff reagiert. Wenn nein, muss man einen Softwarereset des Displays
> machen. Im Extremfall, wenn das allein nicht reicht, muss man dessen
> Stromversorgung vom Arduino schaltbar machen und einen Hardwarereset
> machen. Das ist zumindest ein Workaround fpr den Fall, daß man die
> Störung nicht bedämpfen kann.

Auch hier verwende ich eine fertige Bibliothek von Adafruit. Ich werde 
prüfen, ob das ACK/die Antworten vom Display überprüft werden und ob ich 
ggf. eine Funktion zum Resetten einbauen kann.
Einen Hardwarereset sehe ich als letzte Möglichkeit an, vielleicht 
schaffe ich es ja auch ohne. Wenn es nicht klappt, muss es aber wohl 
sein.



Schon mal vielen Dank für die vielen Hinweise. Ich kümmere mich darum, 
dass ich den Aufbau in die Finger bekomme und werde zeitnah Rückmeldung 
geben, sobald es neue Erkenntnisse gibt.

[Thomas Z. (usbman)]

Besorg dir USBDeviceView von Uwe Sieber. Dann kontrolliere ob nach einem 
USB Absturz noch die die Deskriptoren geliefert werden. Sollten die 
kommen funktioniert USB und die Bulkpuffer sind festgefahren.
Das kann auch an einer schlechten VCP Implementierung liegen. Gibt es 
sowas wie flush?

[Chris K. (kathe)]

Zu viel Text.

Viel zu viel lange Kabel die als Antenne sich gegenseitig beinflussen 
können. Die Relais sind nicht sichtbar.
Getrennte Kabelführung zu dem Poti und "Hochstrom" Schaltern sehe ich 
nicht ....

[Monk (roehrmond)]

Chris K. schrieb:
> Die Relais sind nicht sichtbar.

[Falk B. (falk)]

Chris K. schrieb:
> Viel zu viel lange Kabel die als Antenne sich gegenseitig beinflussen

Blödsinn. Aber Hauptsache geschwätzt.

> können. Die Relais sind nicht sichtbar.
> Getrennte Kabelführung zu dem Poti und "Hochstrom" Schaltern sehe ich
> nicht ....

Weil du blind bist.

[Chris V. (nagut)]

Offenbar fängst Du Dir Störungen vom Laststromkreis (logisch), aber auch 
von der Relaisansteuerung (!) ein. Letzteres wird ersichtlich durch den 
Versuch mit abgeklemmter Last.

Ich würde mir die Relaisansteuerung nochmal genauer anschauen 
(Funktioniert die angeblich im Sockel eingebaute Diode wirklich?), und 
die 12V-Versorgung für die Logikschaltkreise vorm Arduino über ein 
LC-Filter führen. Danach dann auf ordentliche Masseführung achten, und 
alle Leitungen (auch die +5V-Versorgung) weit weg von den mutmaßlich 
"verseuchten" 12V und Netzleitungen.

D.h. Dein gemischter Niederspannungkabelkanal mit Logikleitungen zum 
Dreh-Encoder und Relaisansteuerung schön parallel geführt ist vermutlich 
nicht die beste Idee.


PS: die USB-Messungen zeigen zwar, dass die Kommunikation genau dann 
abzureißen scheint (Stoerungen_USB_2.png), aber die gemessene Störung 
ist im Gleichtakt auf beiden Busleitungen. Sehr wahrscheinlich ist das 
ohnehin nur ein Artefakt Deiner Messstrippen - aber selbst wenn es 
wirklich so auf dem Busleitungen liegt, würde es den USB-Bus nicht 
durcheinanderbringen. Genau deswegen benutzt man dort ein symmetrisches 
Signal.

[L.S. (lagerschaden)]

Monk schrieb:
> Ich empfehle darüber hinaus 1,5k Ohm Pull-Up Widerstände am I2C
> Bus und
> Snubber entweder an den Kontakten der Relais oder (besser) parallel zur
> Last.

Das ist m.E. die vordringlichste Massnahme. Der häufigste Fehler bei 
I2C-Problemen sind die Pullups, weil viele den I2C-Bus nicht verstehen.

Bei 3V3 kann man mit den Pullups (Geamtwert) sogar bis auf 1 k 
heruntergehen, siehe Bild

[Falk B. (falk)]

L.S. schrieb:
> Das ist m.E. die vordringlichste Massnahme. Der häufigste Fehler bei
> I2C-Problemen sind die Pullups, weil viele den I2C-Bus nicht verstehen.

So wie du EMV nicht verstehst. Für eine HF-Störung ist der Unterschied 
zwischen 5k und 1k Pull Up Widerstand sehr gering. Die deutlich größere 
Wirkung erzielt man dabei mit einem Kondensator, denn der ist um 
GRÖßENORDNUGNEN niederohmiger im entscheidenden Frequenzbereich. Der 
liegt nicht bei ein paar kHz sondern einigen MHz.

XC = 1/(2*Pi*f*C) = 1/(2*Pi*10MHz*100pF) = 160 Ohm

Dort kommt man mit niederohmigen Pull Ups nicht mal ansatzweise hin, 
schon gar nicht bei höheren Frequenzen.

[Frank O. (frank_o)]

M. B. schrieb:
> Folgendes habe ich versucht, um das Problem in den Griff zu bekommen:
> - Leitung vom Relais zur Heizpatrone (ca. 1,5 m) mit Alufolie umwickelt

Versuche doch einmal einen anderen Stromkreis für die Heizpatrone zu 
nehmen, als für dein Netzteil.
Dann dickere Kabel an die Heizpatrone.
Dicke Kondensatoren am Ausgang vom Netzteil.

[Rainer W. (rawi)]

M. B. schrieb:
> Weiter Hinweis: In den Relaissockeln sind bereits Freilaufdioden
> integriert, deshalb habe ich diese nicht in den Schaltplan
> eingezeichnet.

Das ist kein Grund, die Freilaufdioden im Schaltplan zu verschweigen. 
Gerade, wenn es um Störungssuche geht, sind die essenziell. Dazu wären 
auch Angaben zu der Höhe der geschalteten Ströme hilfreich.

Der Schaltplan soll zeigen, wie die Schaltung aufgebaut ist und nicht, 
welche Modules es gibt. Das ist der Unterschied zwischen Schaltplan und 
Blockschaltbild.

[Falk B. (falk)]

Rainer W. schrieb:
> Das ist kein Grund, die Freilaufdioden im Schaltplan zu verschweigen.
> Gerade, wenn es um Störungssuche geht, sind die essenziell. Dazu wären
> auch Angaben zu der Höhe der geschalteten Ströme hilfreich.

Versuchs mal mit Lesen und dem ohmschen Gesetz.

> Der Schaltplan soll zeigen, wie die Schaltung aufgebaut ist

Das tut er!

[M. B. (bema16)]

So, ich habe die Holzplatte mit der Elektronik heute morgen zu mir 
geholt und es gibt neue Erkenntnisse.

Als erstes habe ich mit dem Oszilloskop und einem Tastkopf mit 
Massefeder (ohne Krokoklemme) gegen GND gemessen und die Heizung 
eingeschaltet. Hierbei konnte ich keine Störungen auf dem Oszilloskop 
erkennen - Einkopplungen in die Tastkopfleitung sollten also nicht 
vorhanden sein.

Anschließend habe ich nochmal die Störungen beim Einschalten des Relais 
auf den USB- und I2C-Leitungen gemessen, ebenfalls mit der Massefeder. 
Screenshots vom Oszi habe ich angehängt, die gelbe Linie ist jeweils das 
USB/I2C-Signal und die violette Linie die 230V, die vom Relais 
geschalten werden. Ich denke, damit ist auf jeden Fall klar, dass die 
Störungen beim Einschalten des Relais das Problem sind. Auch auf die 5V 
Versorgung koppeln die Störungen ein.

Anschließend habe ich nochmal das SSR eingebaut und die Messungen 
wiederholt. Hierbei konnte ich überhaupt keine Störungen auf dem 
Oszilloskop erkennen, was mich überrascht hat, weil ich mit dem SSR, wie 
oben beschrieben, ebenfalls Probleme hatte. Auf der anderen Seite macht 
es aber natürlich Sinn, dass ich mit dem SSR keine Störungen habe, weil 
dieses nicht prellt und zusätzlich im Nulldurchgang eingeschaltet wird. 
Das war schließlich auch der Grund, weshalb ich überhaupt auf die Idee 
gekommen bin, das SSR einzubauen.
Die Screenshots habe ich ebenfalls wieder angehängt.

Nun habe ich mit dem SSR nochmal einen Dauerlauf gestartet - Arduino an 
den PC gehängt, Terminal geöffnet, 70 Grad als Zieltemperatur 
eingestellt und die Heizung aktiviert. Der Arduino hat die Temperatur 
geregelt und das SSR wurde jede Sekunde ein- und ausgeschaltet. Nach 
kurzer Zeit (ca. vier Minuten) ist wieder das Display ausgestiegen 
(Anzeige eingefroren), aber die USB-Kommunikation hat die ganze Zeit 
(gute zwei Stunden) problemlos funktioniert und ich hatte keinen 
Ausfall. Komische Temperaturwerte hatte ich ebenfalls nicht.
Ich habe im Kopf, dass ich bei meinem ersten Versuch mit dem SSR auch 
Probleme mit dem USB hatte, aber es kann gut sein, dass ich den Test 
beim ersten Versuch direkt abgebrochen habe, als das Display eingefroren 
ist, und ich das jetzt durcheinanderbringe. Deshalb: Immer alles 
dokumentieren und nicht "mal eben schnell" etwas ausprobieren - hier 
habe ich wahrscheinlich etwas schludrig gearbeitet, mein Fehler.

Durch den Test von oben habe ich das Gefühl, dass das Problem mit dem 
Display eher softwarebedingt ist, ich werde aber trotzdem mal die 100 pF 
Kondensatoren an SDA und SCL hängen und den 100 uF Kondensator durch 100 
nF ersetzen. Auch die Pullups werde ich nochmal überprüfen und ggf. 
verkleinern, mir ist aufgefallen, dass die Anstiegsflanken auf dem Oszi 
nicht so klasse aussehen. Falls das nicht hilft, schaue ich mir die 
Software nochmal genauer an.

Ich will mich noch nicht zu früh freuen und ich werde noch einige Tests 
machen, aber aktuell sieht es so aus, dass es mit dem SSR entgegen 
meinem ersten Test doch (fast) zuverlässig funktioniert. Ich werde auf 
jeden Fall ein Update geben, wenn es Neuigkeiten gibt :-)

Danke an alle, die Gedanken gemacht haben und Hinweise gegeben haben. 
Ich wünsche noch einen schönen Sonntag Abend.

[Stephan S. (uxdx)]

und hast Du jetzt auch mal die Pullups auf 1k geändert und gemessen?

[Frank O. (frank_o)]

Hast du eigentlich einmal den Strom gemessen oder zumindest zusammen 
gerechnet. Bei dem ganzen Zeug, was du da dran hast, sind die 1,3A nicht 
gerade überschwänglich viel Strom.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

M. B. schrieb:
> Anschließend habe ich nochmal die Störungen beim Einschalten des Relais
> auf den USB- und I2C-Leitungen gemessen, ebenfalls mit der Massefeder.
Und wo hast du die Massefeder kontaktiert? Denn wenn du wissen willst, 
wa das jeweilige Bauteil "sieht", musst du direkt am IC den Signalpin 
kontaktieren und direkt an selben IC den nächstgelegenen Massepunkt. 
Dann siehst du auf dem Oszi, was das IC auch sieht.

> mal die 100 pF Kondensatoren an SDA und SCL hängen
Das ist wildes Gebastel. Besser als das Beschönigen von Symptomen ist 
die Behebung der Ursache.

> Auch auf die 5V Versorgung koppeln die Störungen ein.
Miss mal "Masse gegen Masse" also die Masseklemme des Oszis an einen 
Massepunkt (z.B. am µC) und die Messpitze an einen anderen Massepunkt 
(z.B. am I²C-Device). Im Idealfall solltest du dann (wegen Masse = 
Masse) immer einen geraden Strich bei 0V auf dem Oszi sehen. Was siehst 
du tatsächlich? Wenn da genau dasselbe wilde Gezappel zu sehen ist, dann 
hast du einfach nur eine schlechte Masseführung.

> will mich noch nicht zu früh freuen und werde noch einige Tests machen
Das solltest du tun, denn deine Schaltung ist ja nicht nur auf die 
Störungen sensibel, die sie selber produziert, sondern natürlich auch 
auf die, die von aussen kommen.

Ich mache da immer so einen einfachen Burst-Test mit einem "Kerbl 
Handyshock" Nachbau, wie im
Beitrag "Re: Tiefentladungsschutz mit Attiny und P-Kanal Fet" beschrieben. Wenn 
das gut geht, dann ist meine Schaltung ordentlich aufgebaut. Die 
rustikalere Variante eines solchen Tests ist im selben Thread weiter 
unten im Beitrag "Re: Tiefentladungsschutz mit Attiny und P-Kanal Fet" 
beschrieben.

Aber eines ist sicher: dein störempfindlicher Aufbau wird keinen dieser 
Tests fehlerfrei bestehen.

[M. B. (bema16)]

Stephan S. schrieb:
> und hast Du jetzt auch mal die Pullups auf 1k geändert und gemessen?

Das wollte ich gerade tun und dabei ist mir folgendes aufgefallen:
- Am Arduino habe ich - wie im Schaltplan eingezeichnet - 4,7 kOhm 
Pullups vorgesehen
- Der Feuchtesensor verfügt über zwei 10 kOhm Pullups nach VCC, die 
bereits auf dem Breakout-Board installiert sind
- Auf der Platine des OLED-Displays ist ein 3,3 V Spannungsregler 
vorgesehen, welcher aus den 5V die Versorgung für das Display generiert. 
Offensichtlich verträgt dieses nur 3,3 V.
Zusätzlich gibt es zwei 10 kOhm Pullups, die aber gegen 3,3 V und nicht 
gegen 5 V geschaltet sind.

-> Das ist natürlich Murks, so arbeiten die Pullups gegeneinander. 
Nachdem ich nochmal mit dem Oszi nachgemessen habe, habe ich 
festgestellt, dass ich nur 4 V Signalpegel auf dem I2C-Bus habe.
Bevor ich jetzt die Pullups verändere, baue ich erstmal einen 
Pegelwandler zwischen Display und Arduino ein, damit die Pegel sauber 
sind. Anschließend gehe ich mal mit den Pullups weiter runter.

Frank O. schrieb:
> Hast du eigentlich einmal den Strom gemessen oder zumindest zusammen
> gerechnet. Bei dem ganzen Zeug, was du da dran hast, sind die 1,3A nicht
> gerade überschwänglich viel Strom.

Ich habe gerade nachgemessen, der Stromverbrauch auf der 12V Seite 
beträgt 90 mA bei eingeschaltetem Relais. Die 1,3 A sollten also auf 
jeden Fall ausreichen.

Lothar M. schrieb:
> Und wo hast du die Massefeder kontaktiert?

Beim I2C habe ich die SDA/GND bzw. SCL/GND Pins direkt am Display 
verwendet, beim USB bin ich auf die ESD-Schutzdioden hinter der Buchse 
gegangen. Auch hier die Tastspitze auf das USB-Signal und die Massefeder 
an das direkt gegenüberliegende GND-Pad von dem Dioden-IC.

Lothar M. schrieb:
> Miss mal "Masse gegen Masse" also die Masseklemme des Oszis an einen
> Massepunkt (z.B. am µC) und die Messpitze an einen anderen Massepunkt
> (z.B. am I²C-Device).

Einen so großen Abstand kann ich mit dem Tastkopf und der Massefeder 
nicht überbrücken, hiermit kann ich nur benachbarte Pins messen. Oder 
ist es ok, wenn ich an der Tastspitze einen kurzen Draht anbringe, um 
zum Display zu gelangen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

M. B. schrieb:
> Oder ist es ok, wenn ich an der Tastspitze einen kurzen Draht anbringe,
> um zum Display zu gelangen?
Du kennst diese üblichen Masseclips, die mit jedem Tastkopf ausgeliefert 
werden? Damit kann man gut 20cm überbrücken.

[Falk B. (falk)]

Lothar M. schrieb:
>> Oder ist es ok, wenn ich an der Tastspitze einen kurzen Draht anbringe,
>> um zum Display zu gelangen?
> Du kennst diese üblichen Masseclips, die mit jedem Tastkopf ausgeliefert
> werden? Damit kann man gut 20cm überbrücken.

Genau DAS wollte er VERMEIDEN!

[Frank O. (frank_o)]

M. B. schrieb:
> Ich habe gerade nachgemessen, der Stromverbrauch auf der 12V Seite
> beträgt 90 mA bei eingeschaltetem Relais.

Du hast noch ein Display dran, das, wenn ich mich recht erinnere, bis zu 
300mA ziehen kann. Dein Arduino zieht mit Sicherheit auch schon mal 
kurzzeitig mehr. Beim Anziehen braucht dein Relais sicher auch deutlich 
mehr Strom, als im Betrieb.
Und wer weiß, ob das überhaupt 1300mA bringt.
Ich tippe immer noch auf das Netzteil.

[Falk B. (falk)]

Frank O. schrieb:
> Du hast noch ein Display dran, das, wenn ich mich recht erinnere, bis zu
> 300mA ziehen kann.

So ein Käse. Außerdem zieht das keine 300mA bei 12V.

> Dein Arduino zieht mit Sicherheit auch schon mal
> kurzzeitig mehr.

Nö, warum auch?

>Beim Anziehen braucht dein Relais sicher auch deutlich
> mehr Strom, als im Betrieb.

Schon wieder falsch! Relais haben keinen Einschaltstrompuls!

> Und wer weiß, ob das überhaupt 1300mA bringt.
> Ich tippe immer noch auf das Netzteil.

Was für ein sinnloses Gelaber!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Falk B. schrieb:
> Genau DAS wollte er VERMEIDEN!
Genau DAS ist mir schon klar, aber man kann ja auch einfach mal als *1. 
Schritt* und Bezugsmessung die lange Masseklemme und die Prüfspitze an 
exakt den selben Massepunkt in der Schaltung halten und sehen, was 
dann einkoppelt (das sind die Funkstörungen, die in diese 
"Tastkopfschleife" einstrahlen).

Und dann kann man im *2. Schritt* die Masseklemme an der selben Stelle 
lassen und mit der Spitze andere Massepunkte messen. Wenn dann immer 
noch dasselbe wie bei der 1. Messung zu sehen ist, dann ist die Masse 
tadellos. Wenn mehr Störungen zu sehen sind, dann kommen die mit hoher 
Wahrscheinlichkeit von Strömen, die sich auf der weit verstreuten Masse 
tummeln.

M. B. schrieb:
> Es kommt ab und zu vor, dass die Anzeige auf dem Display einfriert
Nicht zu selten kommen solche Fehler als Folgefehler: weil vorher auf 
irgendeinem anderen Portpin eine Störung aufgetreten ist, tut die 
Software als Reaktion auf diese Störung irgendwas Anderes und hat a) 
keine Zeit mehr für den Rest oder b) beginnt eine Aktion, die natürlich 
nicht weitergeht.

Die allermeisten "abgestürzten" Programme laufen mit Vollgas in einer 
endlosen Scheife mit irgendeiner Abfrage und warten darauf, dass eine 
externe oder interne Hardware etwas tut, was nie kommen wird.

Frank O. schrieb:
> Ich tippe immer noch auf das Netzteil.
Ich tippe immer noch auf die nicht ungeplante Masseführung, Und die 
insgesamt vogelwilde Verkabelung. Vermutlich in Zusammenhang mit einer 
nicht ausreichend gegen Störungen resistenten Software. Denn alle 3 
beschriebenen Fehler deuten darauf hin, dass die Software "im Prinzip" 
weiterläuft, aber nicht in der Lage war, die aufgetretenen Störungen zu 
behandeln.

[Axel R. (axlr)]

Schwarz, rot, rosa, weiß gehen zu den beiden Relais, wenn man das auf 
dem Foto so interpretieren mag und verschwinden im Kabelkanal. (Foto ist 
immer schlecht zu deuten, is ja klar) Wo kommen die wieder raus und wo 
sind die angeschlossen?
Der kleine gelochte Kasten scheint das Netzteil zu sein. Mit schwarz und 
gelb (statt rot und schwarz). Das geht genau wohin?

Nimm dir doch bitte mal n A3 Blatt, Lineal, Bleistift und Radiergummi 
und zeichne das in geraden Strichen genau so auf, wie der tatsächliche 
Verlauf deiner Verdrahtung aussieht.
Dann sieht man unter Umständen sofort, wo die Ströme nicht nur hin - 
sondern auch zurückfließen.
Nütz ja kein Mustergültiger Aufbau mit adernendhülsen usw. Wenn die 
umspannten Leiterflächen da n halben Quadratmeter am Ende umspannen und 
die Masseleitungen samba tanzen.
Bei Schaltreglern werden diese Stromschleifen/Flächen hier im Forum 
immer gern eingezeichnet.
Wundere mich, diesen Hinweis hier noch nicht gelesen zu haben. Würde ich 
hier auch mal einzeichnen. Das einzige, was klickt und Last abwirft, 
sind die Relais.
Deren Rückleitung muss direkt zum Netzteil verlegt werden. Da darf kein 
anderer Strom drüber fließen.

Bei so einer Zeichnung kann man dann den Kabelkanal auch so breit 
zeichnen, dass alle Kabel nebeneinander laufen und man man kann den 
Deckel quasi weglassen.
Ist ne scheissarbeit, das zu zeichnen, hilft aber ungemein.
Vielleicht in Zukunft (für andere, wenn nicht für sich selbst) sinnvolle 
Kabelfarben verwenden und nicht die vier Farben, die man gerade zur Hand 
hat.
Das Netzteil reicht ja wohl dicke aus. Verstehe die Diskussion darum 
garnicht. Liegt definitiv an der Leitungsführung.

[Axel R. (axlr)]

https://docs.arduino.cc/resources/schematics/ABX00080-schematics.pdf

Was steckt denn da noch oben auf dem Arduino für’n „shield“ drauf? 
Gibt’s da auch nen Link dazu?

[Monk (roehrmond)]

M. B. schrieb:
> Nachdem ich nochmal mit dem Oszi nachgemessen habe, habe ich
> festgestellt, dass ich nur 4 V Signalpegel auf dem I2C-Bus habe.

Dem Arduino UNIO reichen sogar 3,3 Volt aus.

Es könnte aber sein, dass dein Display es gar nicht gerne hat, wenn 
seine I/O Pins auf außerhalb der Spezifikation (mehr als 3,8 Volt) hoch 
gezogen werden.

Ändere die Schaltung so, dass alle Pull-Ups auf 3,3V ziehen.

Der Feuchtesensor kann laut Datenblatt mit 3,3V betrieben werden. Ich 
weiß aber nicht, was die auf deinem Modul noch drum herum gebaut haben.

[Frank O. (frank_o)]

Falk B. schrieb:
> So ein Käse. Außerdem zieht das keine 300mA bei 12V.

Stand bei den OLED im Datenblatt. Allerdings habe ich das auch nie 
messen können.

Falk B. schrieb:
> Schon wieder falsch! Relais haben keinen Einschaltstrompuls!

Asche auf mein Haupt. War völliger Quatsch.

Dann halte ich mal die Finger still und bin gespannt was dabei 
rauskommt.

Lothar M. schrieb:
> Frank O. schrieb:
>> Ich tippe immer noch auf das Netzteil.
> Ich tippe immer noch auf die nicht ungeplante Masseführung, Und die
> insgesamt vogelwilde Verkabelung.
Das sicher auch.
Ich bin gespannt.

[Frank O. (frank_o)]

Falk B. schrieb:
> In der Software sollte man prüfen, ob das Display noch auf den I2C
> Zugriff reagiert. Wenn nein, muss man einen Softwarereset des Displays
> machen. Im Extremfall, wenn das allein nicht reicht, muss man dessen
> Stromversorgung vom Arduino schaltbar machen und einen Hardwarereset
> machen. Das ist zumindest ein Workaround fpr den Fall, daß man die
> Störung nicht bedämpfen kann.

Hallo Falk!
Das sind die Beiträge, die ich von dir gewohnt bin und auch schätze.

Falk B. schrieb:
> Was für ein sinnloses Gelaber!

In letzter Zeit öfter so was. Klar, da hast du recht gehabt. Vor allem 
mit dem Relais. Aber was sollen solche Beleidigungen?
Du hast auch keine Lösung und wir machen uns doch alle Gedanken, woran 
es liegen könnte.
Dass ich dir in der Elektronik nicht das Wasser reichen kann und auch 
gar nicht möchte, sollte dir hinlänglich bekannt sein. Aber dennoch habe 
ich 37 Jahre Erfahrung in der Fehlersuche und da ist es sehr häufig die 
Stromversorgung.
Bitte lass diese Art doch sein! Es steht dir nicht, denn damit machst 
du, zumindest bei mir, deinen guten Ruf kaputt.

[M. B. (bema16)]

Danke für die Beteiligung und die vielen Hinweise!
Ich wollte nur kurz Bescheid geben, dass ich mitlese und den Thread hier 
nicht vergessen habe, aber gestern und heute leider keine Zeit hatte, an 
dem Projekt weiterzumachen.
Ich denke, dass ich am Freitag oder am Wochenende etwas Zeit finden 
sollte und dann werde ich auf die Hinweise eingehen und 
Bilder/Informationen nachliefern.
Bis dahin bitte etwas Geduld, Danke :-)

[Frank O. (frank_o)]

M. B. schrieb:
> Bis dahin bitte etwas Geduld, Danke :-)

Gibt keinen Zwang abzuliefern und schon gar nicht zeitlich. Aber schön 
wäre es trotzdem, wenn du dann was gefunden hast und uns das mitteilst.

[Lu (oszi45)]

Viel Lyrik hier. Bei der Sauerkrautverdrahtung würde ich mir ein paar 
Pfeile wünschen, wo genau man den Fehler gemessen hat. Ansonsten werfe 
ich mal die Worte Relais-Kontaktprellen und Snubber ein, wenn die 400W 
geschaltet werden. https://www.mikrocontroller.net/articles/Snubber

[M. B. (bema16)]

Ich hatte über das Wochenende ein wenig Zeit und konnte weiterarbeiten.

Als erstes habe ich einen Pegelwandler für das Display gebaut, damit 
dieses 3,3 V I2C-Pegel erhält. Der Pegelwandler sitzt unterhalb des 
Displays auf einer Lochrasterplatine, auf den Bildern ist er daher 
schlecht zu erkennen.
Die Pullups auf der 5 V Seite habe ich auf 1,5 kOhm verringert, auf der 
3,3 V Seite verwende ich 2 kOhm Pullups. Da der Pegelwandler direkt 
unter dem Display sitzt, ist die Leitungskapazität eher gering und ich 
hatte als SMD nicht wirklich etwas da, was besser gepasst hätte.
Ich habe das Display sicherheitshalber ausgetauscht, um sicherzugehen, 
dass ich das alte Display nicht durch die zu hohen Pegel beschädigt 
habe.
--> Ergebnis: In Verbindung mit dem SSR scheint nun alles stabil zu 
funktionieren - bei einem Dauerlauf über ca. 1,5 h gab es keine Probleme 
mit USB und Display.
Baue ich das mechanische Relais wieder ein, habe ich nach kurzer Zeit 
wieder Probleme.

Ich könnte es nun bei der Lösung mit dem SSR belassen, ich möchte aber 
nochmal ein wenig Zeit investieren, um evtl. doch das mechanische Relais 
verwenden zu können. Ich traue dem AliExpress SSR nicht wirklich über 
den Weg und gleichzeitig würde ich für die Zukunft gerne verstehen, wie 
ich solche Probleme in den Griff bekomme.
Ich habe daher wie empfohlen einige Oszi-Messungen durchgeführt - siehe 
Screenshots + Fotos vom Messaufbau im Anhang.

- Bilder mit Präfix "06": Massefeder + Tastkopf am gleichen Massepunkt 
auf dem Shield --> auch ohne Schalten des Relais sind Störungen 
(Netzteil?) erkennbar, beim Schalten sind die Störungen deutlich 
erkennbar
- Bilder mit Präfix "07": Statt der Massefeder die Krokoklemme 
verwendet, aber nach wie vor am gleichen Massepunkt --> Ergebnis 
unverändert
- Bilder mit Präfix "08": GND-Differenz zwischen Shield/OLED gemessen

Verbinde ich GND direkt mit PE, kann ich keine Verbesserung erkennen - 
vermutlich deshalb, weil GND schon intern im Netzteil über einen 
Kondensator mit PE verbunden ist.

Das Arduino-Shield ist ein Lochraster-Shield, welches ich selbst gelötet 
habe. Einige Taster und LEDs sind bereits auf dem Shield vorhanden, 
bspw. für den Reset. Ich verwende diese aber nicht.

Im Anhang findet sich auch ein PDF, in denen ich die Kabelführung im 
Nieder- und Hochspannungskanal aufgezeichnet habe. Aus meiner Sicht ist 
die Leitungsführung nicht so katastrophal, alle Signale (abgesehen vom 
Thermoschalter) gehen eigentlich auf das Arduino Shield und somit auf 
eine zentrale Masse. Ich lasse mich aber gerne eines besseren belehren 
:-).

[Falk B. (falk)]

M. B. schrieb:

> Die Pullups auf der 5 V Seite habe ich auf 1,5 kOhm verringert, auf der
> 3,3 V Seite verwende ich 2 kOhm Pullups.

Ganz schön wenig, geht aber gerade noch so.

> --> Ergebnis: In Verbindung mit dem SSR scheint nun alles stabil zu
> funktionieren - bei einem Dauerlauf über ca. 1,5 h gab es keine Probleme
> mit USB und Display.

Schon mal gut, aber

> Baue ich das mechanische Relais wieder ein, habe ich nach kurzer Zeit
> wieder Probleme.

Und das trotz ziemlich niederohmiger I2C Pull-Ups. Aber welche Probleme 
hast du jetzt noch konkret?

Display ziegt nix gescheites mehr an?
Virtueller COM Port über USB liefert keine Daten mehr?

Stimmt das?

> den Weg und gleichzeitig würde ich für die Zukunft gerne verstehen, wie
> ich solche Probleme in den Griff bekomme.

Gute Einstellung!

> Ich habe daher wie empfohlen einige Oszi-Messungen durchgeführt - siehe
> Screenshots + Fotos vom Messaufbau im Anhang.

Sieht soweit OK aus. Die 200mV Störung sind natürlich nicht so schön. 
Aber da muss man weiter forschen.

> Verbinde ich GND direkt mit PE, kann ich keine Verbesserung erkennen -
> vermutlich deshalb, weil GND schon intern im Netzteil über einen
> Kondensator mit PE verbunden ist.

Ja, aber nur AC mäßig. Das kann reichen, muss es aber nicht. Kommt drauf 
an. Aber da der Arduino nicht abstürzt, würde ich meinen, es reicht.

> Das Arduino-Shield ist ein Lochraster-Shield, welches ich selbst gelötet
> habe.

Sieht OK aus.

> Im Anhang findet sich auch ein PDF, in denen ich die Kabelführung im
> Nieder- und Hochspannungskanal aufgezeichnet habe.

Hochspannung, soso. :-)
230V Netzspannung ist Niederspannung im professionellen Sprachgebrauch. 
Echte Hochspannung geht bei 110kV los ;-)

> Aus meiner Sicht ist
> die Leitungsführung nicht so katastrophal,

Ist sie auch nicht. Du hast Netzspannung und Schutzkleinspannung 
räumlich getrennt. Es ist auch kein Kabelsalat und riesige Schleifen. 
Passt schon.

Tja, doch wie nun weiter? Der Fehler wurde noch nicht gefunden. Darum 
nochmal die Frage. Welche Störungen treten immer noch wie auf?

[Frank O. (frank_o)]

Falk B. schrieb:
> Tja, doch wie nun weiter? Der Fehler wurde noch nicht gefunden. Darum
> nochmal die Frage. Welche Störungen treten immer noch wie auf?

Vor allem, äußern sie sich gleich oder sind es jetzt völlig andere 
Fehler.

Und übrigens, ich bin immer noch bei der Stromversorgung für Arduino und 
sein Gefolge.
Egal was ihr sagt und wie viele Minuspunkte ich dafür bekomme. Ich habe 
ähnliche Fehler so oft gesehen und es lag immer an der Stromversorgung.

[M. B. (bema16)]

Falk B. schrieb:
> Und das trotz ziemlich niederohmiger I2C Pull-Ups. Aber welche Probleme
> hast du jetzt noch konkret?
>
> Display ziegt nix gescheites mehr an?
> Virtueller COM Port über USB liefert keine Daten mehr?
>
> Stimmt das?

Auf einem der Bilder oben kann man das Display-Interface vollständig 
erkennen. Alle 250 ms wird einer der Temperatursensoren (T1 - T2 - T3 - 
T4 - T1 - T2 - ...) gemessen und bei Änderungen wird die Anzeige auf dem 
Display aktualisiert. Auch die Werte für die Luftfeuchtigkeit (H1/H2, 
wobei H2 gerade nicht angeschlossen ist) werden regelmäßig aktualisiert. 
Im Normalfall sieht man also regelmäßig Aktivität auf dem Display.
Drehe ich am Encoder, bewegt sich der kleine Pfeil > links über die 
einzelnen Einträge.
Aktiviere ich die Heizung (= Relais schaltet) friert die Display-Anzeige 
nach einer zufälligen Zeit ein, d.h. die Temperatur-/Feuchtigkeitswerte 
werden nicht mehr aktualisiert und wenn ich am Encoder drehe, ändert 
sich die Position des Pfeils nicht mehr. Ich habe sozusagen ein 
Standbild.

Ich kann das System aber bei eingefrorener Anzeige noch blind bedienen. 
Drehe ich bpsw. den Encoder einige Positionen nach rechts (= Eintrag 
"Back" ist ausgewählt) und drücke anschließend den Taster am Encoder, 
wird die Heizung ausgeschaltet. Das ist genau das, was ich erwarte, weil 
die Software dann in das Hauptmenü wechselt und hier die Heizung 
automatisch deaktiviert wird. Das Display zeigt jedoch weiterhin nur das 
Standbild mit den Temperaturen an und nicht das Hauptmenü.

Die USB-Verbindung fällt ebenfalls nach einer zufälligen Zeit aus, 
jedoch gibt es zeitlich keinen Zusammenhang zwischen Display- und 
USB-Ausfall. Es kann sein, dass das Display nicht mehr läuft, obwohl 
über USB noch Daten kommen und umgekehrt.
Der Arduino ist nach dem Ausfall immer noch am PC als COM-Port im 
Gerätemanager sichtbar, aber HTerm empfängt keine Daten mehr. Erst, wenn 
ich das USB-Kabel ziehe und neu einstecke oder (wie ich gerade 
festgestellt habe) kurz das DTR-Signal in HTerm toggle, werden wieder 
Daten gesendet.

Falk B. schrieb:
> Hochspannung, soso. :-)
> 230V Netzspannung ist Niederspannung im professionellen Sprachgebrauch.
> Echte Hochspannung geht bei 110kV los ;-)

Ich hoffe mal, dass ich im oberen Kanal keine 110 kV habe, dafür wäre 
die Isolation vermutlich etwas zu knapp :D
Ich habe mir schon gedacht, dass es fachlich so nicht korrekt ist, aber 
so ist es auf jeden Fall unterscheidbar.

[M. B. (bema16)]

Frank O. schrieb:
> Vor allem, äußern sie sich gleich oder sind es jetzt völlig andere
> Fehler.

Deine Antwort hat sich zeitlich mit meiner überschritten, aber wie in 
meiniem vorherigen Beitrag beschrieben, sind es nach wie vor dieselben 
Fehler.

Frank O. schrieb:
> Und übrigens, ich bin immer noch bei der Stromversorgung für Arduino und
> sein Gefolge.

Ich kann testweise mal mein Labornetzteil anstelle des 
Meanwell-Netzteils anschließen. Dann kann ich zum einen den 
Stromverbrauch überwachen und das Labornetzteil kann auch 3 A statt nur 
1,3 A wie das Meanwell-Netzteil.

[Rainer W. (rawi)]

Frank O. schrieb:
> Dein Arduino zieht mit Sicherheit auch schon mal kurzzeitig mehr.

Die sechs 22µF Kondensatoren sind schnell aufgeladen.

[Falk B. (falk)]

M. B. schrieb:

> sich die Position des Pfeils nicht mehr. Ich habe sozusagen ein
> Standbild.

Das kann zwei Dinge bedeuten. Das Display reagiert nicht mehr auf 
Steuerbefehle oder es wird nicht mehr angesteuert.

> Ich kann das System aber bei eingefrorener Anzeige noch blind bedienen.
> Drehe ich bpsw. den Encoder einige Positionen nach rechts (= Eintrag
> "Back" ist ausgewählt) und drücke anschließend den Taster am Encoder,
> wird die Heizung ausgeschaltet.

Also reagiert das Display nicht mehr. Es hat sich verschluckt. Hier kann 
man versuchen, regelmäßig einen Softwarereset zu machen. Reicht das 
nicht, dann einen gesteurten Hardwarereset mit Abschaltung der 
Versorgungsspannung für das Display. Damit kann man zumindest die 
Fehlerursache nachweisen.

> Die USB-Verbindung fällt ebenfalls nach einer zufälligen Zeit aus,
> jedoch gibt es zeitlich keinen Zusammenhang zwischen Display- und
> USB-Ausfall. Es kann sein, dass das Display nicht mehr läuft, obwohl
> über USB noch Daten kommen und umgekehrt.

Hier muss man versuchen, regelmäßige Debuganzeigen bei der Ausgabe auf 
USB zu erzeugen, z.B., eine blinkende LED. Damit kann man zumindest 
zeigen, daß  ein Teil der Software zur Datenausgabe noch läuft.

> Der Arduino ist nach dem Ausfall immer noch am PC als COM-Port im
> Gerätemanager sichtbar, aber HTerm empfängt keine Daten mehr. Erst, wenn
> ich das USB-Kabel ziehe und neu einstecke oder (wie ich gerade
> festgestellt habe) kurz das DTR-Signal in HTerm toggle, werden wieder
> Daten gesendet.

Interessant. Könnte eine falsche Einstellung des Handshakes sein. Oder 
ein offener Steuereingang? Nee, geht nicht, der USB-Tranceiver steckt ja 
im Mikrocontroller.

[Falk B. (falk)]

M. B. schrieb:
> Ich kann testweise mal mein Labornetzteil anstelle des
> Meanwell-Netzteils anschließen. Dann kann ich zum einen den
> Stromverbrauch überwachen und das Labornetzteil kann auch 3 A statt nur
> 1,3 A wie das Meanwell-Netzteil.

Kann man probieren, ich glaub aber nicht daran. Denn die ausfallenden 
Komponenten (USB und LCD) hängen an der 5V vom Arduino, nicht direkt am 
12V Netzteil. Außerdem ist deren Stromverbrauch gering. Dein Arduino R4 
hat einen 1,2A Schaltregler für die 5V Versorgung, der reicht hier 
locker.

Bei LCD tippe ich auf eine kapazitive Störeinkopplung. Man könnte das 
LCD auf eine kupferbeschichtete Leiterplatte legen, natürlich isoliert 
und die Platte kurz an den GND Anschluß des LCDs anlöten (<20mm).

[Hubert G. (hubertg)]

M. B. schrieb:

> --> Ergebnis: In Verbindung mit dem SSR scheint nun alles stabil zu
> funktionieren - bei einem Dauerlauf über ca. 1,5 h gab es keine Probleme
> mit USB und Display.
> Baue ich das mechanische Relais wieder ein, habe ich nach kurzer Zeit
> wieder Probleme.
Wenn ich mir Schaltungen aufbaue die, wie hier, auf der 12V Seite noch 
Verbraucher haben, dann kommt in die 12V Leitung zum Arduino eine Diode 
und danach ein 100n und ein 100µ Kondensator. Damit ist der Arduino 
weitgehend von den 12V Verbrauchern entkoppelt. Den GND der 12V 
Verbraucher so nahe wie möglich zum Netzteil legen.

[Falk B. (falk)]

Hubert G. schrieb:
> Wenn ich mir Schaltungen aufbaue die, wie hier, auf der 12V Seite noch
> Verbraucher haben, dann kommt in die 12V Leitung zum Arduino eine Diode
> und danach ein 100n und ein 100µ Kondensator. Damit ist der Arduino
> weitgehend von den 12V Verbrauchern entkoppelt.

Dort sind keine mordsmäßigen Verbraucher angeschlossen, welche die 12V 
einbrechen lassen! Nur ein einfaches Relais!

> Den GND der 12V
> Verbraucher so nahe wie möglich zum Netzteil legen.

Ist hier gar nicht relevant.

[Frank O. (frank_o)]

Jetzt hört sich die Fehlerbeschreibung auch schon etwas deutlicher an.
Das was Falk da mit der Led meint, mache ich auch so und ist immer eine 
gute Debug-Methode.

M. B. schrieb:
> Der Arduino ist nach dem Ausfall immer noch am PC als COM-Port im
> Gerätemanager sichtbar, aber HTerm empfängt keine Daten mehr.

Das kannst du vernachlässigen. Windows ist und war da immer sehr träge.
Mal kann das ziemlich schnell von Windows "bemerkt" werden und ein 
anderes Mal dauert das wirklich sehr lange, bis dem Windows das 
auffällt.
Hat wohl nicht so eine hohe Priorität.

Wenn es wirklich nur mit dem Relais so ist, dass der Fehler auftritt, 
dann fehlt da irgendwo der Strom. Andernfalls ist durchaus auch ein 
Softwarefehler möglich. Wie sieht der Stack aus? Wenn dem der Speicher 
knapp wird, kommt es auch zu solchen ungewöhnlichen Fehlern.

[M. B. (bema16)]

Ich habe den Feiertag heute genutzt, um das Problem weiter zu 
untersuchen:

M. B. schrieb:
> Ich kann testweise mal mein Labornetzteil anstelle des
> Meanwell-Netzteils anschließen.

Das hat leider nicht geholfen, ich hatte erneut Ausfälle. Meine 
Digitalanzeige am Labornetzteil zeigt einen Strom von 0,1 - 0,12 A an. 
Das passt zu den 90 mA, die ich weiter oben gemessen habe. Dass die 
Anzeige am Labornetzteil etwas höher ist, würde ich als normal 
einstufen, es ist kein besonders hochwertiges Gerät.

Falk B. schrieb:
> Hier muss man versuchen, regelmäßige Debuganzeigen bei der Ausgabe auf
> USB zu erzeugen, z.B., eine blinkende LED. Damit kann man zumindest
> zeigen, daß  ein Teil der Software zur Datenausgabe noch läuft.

Das habe ich so implementiert, vor dem Aufruf der Funktionen zum Senden 
über USB wird die LED eingeschaltet und danach wieder ausgeschaltet. 
Trotz USB-Ausfall flackert die LED fröhlich weiter. Ich kann damit 
natürlich nicht beurteilen, ob sich evtl. die USB-Peripherie im 
Mikrocontroller verschluckt hat, aber an der Software scheint es nicht 
zu liegen. Das passt auch zu der Tatsache, dass es mit dem SSR und 
derselben Software zuverlässig funktioniert.

Mit dem Display habe ich nach wie vor Probleme, aber je länger ich mit 
dem mechanischen Relais teste, desto mehr habe ich den Eindruck, dass es 
seit dem Wechsel auf 1,5 kOhm Pullups stabiler funktioniert. Ich habe 
zwar nach wie vor Ausfälle, aber gefühlt dauert es länger als vorher, 
bis es zu einem Ausfall kommt - und das, obwohl ich aktuell keine 
Kondensatoren mehr in den SDA- und SCL Leitungen und in der Versorgung 
vom Display habe. Ich glaube also, dass wir hiermit schon auf dem 
richtigen Weg sind.

Für die Probleme mit dem USB habe ich zwischenzeitlich einen Workaround 
gefunden: Ich lasse die Daten über den Hardware-UART (TX) vom Arduino 
ausgeben und leite das Signal über ein geschirmtes Kabel auf eine kleine 
Lochraterplatine mit einem RC-Filter (330 Ohm/1 nF). Das Signal hinter 
dem Filter geht direkt auf einen USB-UART Adapter und dieser in den 
USB-Anschluss vom PC. Das UART-Signal ist deutlich unkritischer zu 
filtern und hiermit funktioniert nun die Datenübertragung dauerhaft 
problemlos (Baudrate 115200). Im Anhang ein Foto von dem Aufbau.

Über das Wochenende bin ich leider unterwegs und kann deshalb nicht 
weitermachen, aber als nächstes werde ich das mit der Kupferplatte und 
dem Software-Reset am Display testen. Die 100 pF Kondensatoren in SDA 
und SCL werde ich ebenfalls mal testen, bisher hatte ich ja nur 22 pF 
versucht. Den Hinweis mit dem LC-Filter und dem Stack habe ich ebenfalls 
gelesen, aber beim Stack bin ich mir unsicher, wie ich das genau prüfen 
soll - evtl. den Stackpointer regelmäßig per UART ausgeben und prüfen, 
ob er immer weiter anwächst...? Oder wie sollte ich hier vorgehen?

[Frank O. (frank_o)]

Wenn es doch dauerhaft mir dem SSR funktioniert, dann muss man sich 
Gedanken machen was beim Betrieb mit SSR anders ist, als mit dem Relais.
Das SSR wird sicher schneller schalten und weniger Strom brauchen als 
dein Relais.
Wenn es ein Problem mit der Zeit ist und dann ein paar Befehle zu viel 
auf dem Stack landen, kann man in diese Richtung suchen. Ist es der 
Strom, dann muss das Relais irgendwo etwas weg ziehen. Letzteres ist 
sicher leichter zu finden.
Danke für deine ausführliche Rückmeldung. Ist auf jeden Fall immer noch 
interessant.
Und zum Stack: Vielleicht kannst du mal testweise eine nicht so wichtige 
Routine sperren. Ist womöglich einfacher als jetzt den Speicher 
überwachen zu wollen.

[Falk B. (falk)]

Frank O. schrieb:
> Wenn es doch dauerhaft mir dem SSR funktioniert, dann muss man sich
> Gedanken machen was beim Betrieb mit SSR anders ist,

In der Tat.
> als mit dem Relais.

Auch ein SSR ist ein Relais, Solid State Relais, Halbleiterrelais

> Das SSR wird sicher schneller schalten und weniger Strom brauchen als
> dein Relais.

Mit dem Stromverbraucht hast du wohl einen Narren gefressen? Der ist 
vollkommen OK. Der Unterschied ist, daß ein SSR prellfrei schaltet, 
während ein einfaches, mechanisches Relais das nicht kann. Der Snubber 
kann hier aber helfen. Tut er aber nur bedingt, wie die Test zeigen. 
Also liegt die Störung und der Koppelpfad anders.

> Und zum Stack: Vielleicht kannst du mal testweise eine nicht so wichtige
> Routine sperren. Ist womöglich einfacher als jetzt den Speicher
> überwachen zu wollen.

Man muss keinen Speicher überwachen. Wenn das Display ausfällt und der 
Controller normale weiter läuft, heißt das zu 99%, daß sich das Display 
verschluckt hat. Sowas kommt häufiger vor. Eine Gegenmaßnahme habe ich 
mehrfach genannt.

[Falk B. (falk)]

Noch ein Trick. Synchronisiere die Zugriffe auf des Display mit dem 
Schalten des Relais. Sprich, wenn das Relais schaltet, dürfen definitiv 
keine I2C Zugriffe stattfinden! Natürlich auch ein paar Dutzend 
Millisekunden danach, denn so ein mechanisches Relais braucht um die 
10-20ms zum Schalten und Prellen. Man kann auch die 100pF Kondensatoren 
an SDA/SCL wieder einlöten, aber nah am Display! Dann mal testen.

[Manfred P. (pruckelfred)]

Frank O. schrieb:
> Ist es der
> Strom, dann muss das Relais irgendwo etwas weg ziehen.

Oder etwas anheben oder zurück pupsen, weil es induktiv ist.

Falk B. schrieb:
> Mit dem Stromverbraucht hast du wohl einen Narren gefressen? Der ist
> vollkommen OK. Der Unterschied ist, daß ein SSR prellfrei schaltet,

Der eine am Strom, der andere am Prellen.

Falk B. schrieb:
> Man kann auch die 100pF Kondensatoren
> an SDA/SCL wieder einlöten, aber nah am Display!

Kondensatoren auf Digitalleitungen ist Bastelpfusch.

[Falk B. (falk)]

Manfred P. schrieb:
>> Man kann auch die 100pF Kondensatoren
>> an SDA/SCL wieder einlöten, aber nah am Display!
>
> Kondensatoren auf Digitalleitungen ist Bastelpfusch.

Meistens ja, manchmal nein.

[Frank O. (frank_o)]

Falk B. schrieb:
> Mit dem Stromverbraucht hast du wohl einen Narren gefressen?

Stimmt! Falk, du weißt doch, man sucht immer dort, wo man üblicherweise 
die meisten Fehler erwartet. Bei den Staplern ist es häufig die 
Stromversorgung  und zwar meistens die Batterie.
Klar weiß ich, dass ein SSR auch ein Relais ist, nur eben aus 
Halbleitern.
Aber trotzdem danke für deine Ausführungen!
Ich habe jetzt bei dem Bremsentester (den ich nun leider nicht mehr 
fertig bau, weil ich nicht wieder arbeiten gehen) zum ersten Mal nach 
langer Zeit wieder etwas mit Display gemacht.
Damals, als ich zum ersten Mal mit den Mikrocontrollern anfing, da waren 
das eher nur Übungen. Dazwischen habe ich eher Tiny10 verwendet.  Dann 
weißt du wie "umfangreich" meine Sachen waren. Deshalb kenne ich das 
"Verschlucken" von so einem Display nicht.
Ich stelle eh nur Mutmaßungen an. Aber es ist natürlich interessant für 
mich, wenn Leute wie du und deiner Erfahrung, solche Speicherfehler 
ausschließen. Für mich ist das insgesamt interessant und Lernstoff für 
eigene Sachen. Allerdings werde ich auch ohne solche profunde 
Erfahrungen, wie du sie hast, den einen oder anderen Gedanken 
beisteuern.

[Frank O. (frank_o)]

Falk B. schrieb:
> Synchronisiere die Zugriffe auf des Display mit dem
> Schalten des Relais. Sprich, wenn das Relais schaltet, dürfen definitiv
> keine I2C Zugriffe stattfinden! Natürlich auch ein paar Dutzend
> Millisekunden danach, denn so ein mechanisches Relais braucht um die
> 10-20ms zum Schalten und Prellen.

Das halte ich auch für eine ausgesprochen gute Idee!

[Frank O. (frank_o)]

Manfred P. schrieb:
> Oder etwas anheben oder zurück pupsen, weil es induktiv ist.

Richtig, Manfred!