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 hat recht. Aber es kann trotzdem durch andere sachen entstehen
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"
Ist denn der AtMega mit genügend Abblockkondensatoren versehen? AVCC und Aref angeschlossen? Ein Schaltplan würde helfen.
Tipp: Miss nach, welche Kerko-Lötpads auf der Displayplatine die Eingangsspannung puffern und ergänze die fehlenden. 100n oder gleich 1µ.
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,
:
Bearbeitet durch User
Angehängte Dateien:
-
HD44780_POS.png
200 KB
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.