Hallo,
ich habe eine Atmega 328 basierende Steuerung im industriellen Umfeld im
Einsatz, die hauptsächlich ein paar Magnetventile schaltet und eine
Lichtschranke sowie einen Drehencoder ausliest. Anfangs traten
mannigfaltige Störungen auf, weil ich naiv wie ich bin natürlich keine
Optokoppler für Ein und Ausgänge vorgesehen hatte. Da das ein totler
Fehlschlag war und ich dazugelernt habe, baute ich alle Ein- und
Ausgänge komplett auf Optokoppler um. Alles zusammen ist verbaut in
einem Metallgehäuse aus Stahlblech. Nun funktioniert das ganze ziemlich
gut, oft tagelang oder wochenlang, und irgendwann kommt ein Fehler: Das
Display zeigt Mist an (irgendwas aus dem Schriftensatz), der Controller
an sich läuft dabei weiter ohne Probleme.
Das ist sehr unschön. Der LCD ist in einer Ausssparung des Gehäuses
angebracht, ragt also etwas nach außen. Weiterhin ist dieser NICHT mit
irgendwelchen Abblockkondensatoren versehen, die Datenleitungen gehen
direkt per Flachbandkabel zum Controller. Lediglich an der Versorgung
des LCD habe ich 100nF hingepappt.
Nun ist meine Vermutung, dass über das LCD Display oder das
innenliegende Flachbandkabel Störungen eingekoppelt werden.
Kann ich an die Datenleitungen ein paar pF an beiden "Enden" also
controllerseitig und LCDseitig jeweils gegen GND anschließen? Besteht
Aussicht auf Erfolg, oder wird es nur noch schlechter, weil die
Flankensteilheit leidet?
Wie kann man solche sporadischen absolut unvorhersehbaren Fehler
beheben?
Vielen Dank im Voraus
(Ich bin kein Profi, betreibe die Microcontrollerbastelei nur als Hobby,
und bin eigentlich Maschinenbauer)
Des könnte evtl. auch daran liegen, dass im Datenstrom zum Display ein
Übertragungsfehler auftrat, und dann der LCD Controller durcheinander
kommt.
Wie wird das Display aktualiert, bei jedem Loop (Programmdurchlauf),
oder nur wenn sich die Anzeigewerte ändern.
Der Displaycontroller speichert im Normalfall die letzten gesendeten
Daten, diese werde dann angezeigt solange keine neuen Daten kommen.
Wenn vorlaufend Daten geschickt werden kann es immer wieder zu solchen
Fehlern kommen (meine Erfahrung), daher das Display nicht fortlaufend
aktualisieren, sondern nur bei Bedarf.
Ebenfalls helfen manchmal Ferritringe an den Displayleitungen.
Da der µC ja weiterläuft, denke ich dass das Display einfach zu oft
aktualisiert wird.
Abblock C's an den Datenleitungen habe ich noch nie gesehen, denke dass
würde die Übertragungsprobleme nur noch erhöhen
Gruß Stefan
Dieses Problem ist mir bekannt. Deine vorgeschlagenen Maßnahmen helfen
nicht. Beim Schalten von Induktivitäten benötigt man einen Snubber
https://www.mikrocontroller.net/articles/Snubber
Ich schalte bei Netzspannung zusätzlich einen ausreichend großen
Varistor (275V) parallel dazu. Beim Kondensator auf jeden Fall einen X2
Typ nehmen.
Es kann dir ein datenlogger bei deinem problem helfen. Die störung ist
ein ereignis. Ereignisse lassen sich aufspüren. Rätselraten kann sich
ziehen wie kaugummi ;)
Harry D. schrieb:> Beim Schalten von Induktivitäten benötigt man einen Snubber
Warum unbeding ein Snubber?
Den braucht man nur bei Wechselspannung. Eine Freilaufdiode tut es bei
Gleichstrom einfacher. Falls die Magnetventile schnell abschalten
sollen, nimmt man Zenerdioden oder ein geeigneter Widerstand in Serie.
rbcn schrieb:> Wie kann man solche sporadischen absolut unvorhersehbaren Fehler> beheben?
Notfalls durch einen gelegentliche Reset des Display.
Vorher solltest du sicher stellen, dass auch die Stromversorgung von
Display und µC gut gegen Transienten auf dem Netz gefiltert ist.
Servus,
meistens liegt es an der Spannungsversorgung, die nicht ausreichend
gepuffert wird oder es fließt etwas über die Masse. Es reicht schon,
wenn man einen anderen Verbraucher an die gleiche Steckdose anbringt,
sodass dann der LCD anfängt zu spinnen.
Das sind die s.g.: worst case. Als Programmierer muss man halt hier
gegenhalten. Lese das busy flag aus und starte ggf. den lcd neu.
Oder schreibe eine Routine, die veranlasst den lcd alle 10s
neuzustarten.
Servus,
danke für die Antworten. Ich denke auch, ich muss das Display ab und zu
resetten.
Momentan ist es so, es wird nur auf den LCD geschrieben, wenn der Wert
sich auch aktualisiert. Alleine wegen auftretendem Flimmern machte ich
das von Anfang an so. Die geschalteten Ventile (induktiven Lasten)
hängen ja alle an einem eigenen Netztal, das galvanisch getrennt von dem
Netzteil des Controllers und des LCD ist (Optokoppler). Freilaufdioden
sind natürlich vorhanden. Was mich immer schon etwas irritiert hat ist,
dass auf den LCDs meistens Footprints für smd Kondensatoren sind, diese
sind aber NIE bestückt. Aus Kostengründen?!?
Nun ist die frage, wie kann ich den Displaycontroller am besten reseten,
ohne die ganze Schaltung zu reseten? Würde es reichen, es neu zu
initialisieren mit lcd.begin(x,x,x);? Nun, mal testen.
Es ist einfach so, dass in der Nähe haufenweise andere Magneten,
Schütze, FUs und Gott weiß was alles sind. Diese kann ich nicht alle mit
Snubbern versehen, sondern meine Schaltung muss die Umgebung tolerieren.
rbcn schrieb:> Momentan ist es so, es wird nur auf den LCD geschrieben, wenn der Wert> sich auch aktualisiert. Alleine wegen auftretendem Flimmern machte ich> das von Anfang an so.
Dann machst Du was falsch. Man kann den gleichen Text beliebig oft an
das LCD schicken, da flimmert nichts.
Man darf natürlich nicht das LCD ständig löschen, sondern einfach nur
den alten Text mit dem neuen überschreiben.
Ich lege immer einen Textspeicher im SRAM an (z.B. 4*20 Byte), der alle
200ms an das LCD gesendet wird. Und in den Textspeicher schreibt dann
die Applikation geänderte Zeichen ein.
Hast Recht, das Flimmern kommt nur vom Clear. Ist schon so lang her, das
Projekt zieht sich schon über knapp 4 Jahre in verschiedensten
Ausbaustufen :)
Trotzdem möchte ich nicht wie du, zyklisch z.B. alle 200ms aufs Display
schreiben. Die eigentliche Aufgabe des Controllers ist Zeitkritisch, da
will ich nicht haben, dass Aufgabe und LCD Aktualisierung
aufeinandertreffen. Stattdessen habe ich einen reservierten Zeitslot im
Ablauf, wo nichts zu tun ist und in Ruhe der Bildschirminhalt
geschrieben werden kann.
Ich werde die Anregungen ausprobieren und mich ggf. wieder melden.
rbcn schrieb:> Trotzdem möchte ich nicht wie du, zyklisch z.B. alle 200ms aufs Display> schreiben.
Man muß die 80 Byte ja nicht auf einen Rutsch schreiben, sondern kann in
einem Timerinterrupt alle 2ms je ein Byte schreiben. Damit spart man
auch die Wartezeit auf das LCD ein.
Beitrag "Formatierte Zahlenausgabe in C"
Hi,
komment es schon mal vor, dass plötzlich nur noch schwarze Balken in
Zeile 1 zu sehen sind?
Das ist bei meiner Schaltung immer dann aufgetreten, wenn es eine kurze
aber ausreichende "Brounoutdetection" gab.
D.h. uP fängt das ab, LCD aber nicht, so dass zwar die
Initialisierungsroutine vom uP wieder durchlaufen wird, das LCD aber
nicht genügend Zeit hatte, vorher den Power on self reset durchführen zu
können. Der braucht ja einen definierten Spannungsanstieg innerhalb
einer bestimmten Zeit. (Deswegen keine zu grossen Konds. vor die Vcc des
Displays. In diesem Falle wäre das kontraproduktiv. Ab ca. 100 uF wirds
IMHO kritischer.)
Dann völliger "Reset" der Vcc nötig.
Oder Trennung der Versorgungsspannungen von LCD und uP, so dass
sichergestellt ist, dass immer zuerst LCD Vcc bekommt, dann erst der uP.
ciao
gustav
Karl B. schrieb:> D.h. uP fängt das ab, LCD aber nicht, so dass zwar die> Initialisierungsroutine vom uP wieder durchlaufen wird, das LCD aber> nicht genügend Zeit hatte, vorher den Power on self reset durchführen zu> können.
Dann ist die Ursache aber eine fehlerhafte Init-Routine für das LCD.
Mit einem korrekten Init kann man das LCD aus jedem unbekannten Zustand
in den gewünschten Zustand zurück setzen, quasi ein SW-Reset. Die VCC zu
schalten ist unnötig.
Peter D. schrieb:> Dann ist die Ursache aber eine fehlerhafte Init-Routine für das LCD.> Mit einem korrekten Init kann man das LCD aus jedem unbekannten Zustand> in den gewünschten Zustand zurück setzen, quasi ein SW-Reset.
Wenn der uC die Initialisierung anfängt, bevor das LCD bereit ist, hilft
dir das auch nichts. Im Zweifelsfall muss der uC abwarten, bis Vcc auch
am LCD stabil ist.
Aber das steht ja auch im Datenblatt des LCDs, wann es bereit ist. So
1-2 Sekunden kann man dann ja mal warten, bis die lcd-init-routine
aufgerufen wird,
Pete K. schrieb:> Aber das steht ja auch im Datenblatt des LCDs, wann es bereit ist.
OK,
da ist einmal die Bedingung drin, die für einen ordnungsgemässen POSR
verlangt wird.
Gleichzeitig aber auch, was gemacht werden soll, kann diese Bedingung
nicht eingehalten werden.
Dann sollen die Befehle, die normalerweise beim POSR automatisch
ablaufen, "manuell" eingegeben werden. Tatsächlich wird die MCU die
Scharte dann auswetzen, indem dieser "worst case" in Form von
Warteschleifen in der Initialisierungsroutine mit berücksichtigt wird.
Also, von 40 ms ist da die Rede,
(1-2 Sekunden sind aber reichlich.)
Komisch, ich dachte, die Warteschleifen wären lang genug bei meinem
Programm, sehe mich also genötigt, diese noch länger zu machen.
ciao
gustav
