Anwendung nicht wirklich 24/7 fähig

  • Hallo Experten,

    ich habe eine kleine Betriebsdatenerfassung für Maschinen mit Python programmiert, die zwar grundsätzlich zufriedenstellend läuft aber leider am Stück nur max. mehrere Wochen


    Aufbau:

    raspi zero (teilweise auch raspi 3b+), Touchscreen mit Adafruit 480x 320 resistive Touchdisplay, raspbian

    stretch (wie laut adafruit final getestet: release März 2018). Anzeige/ GUI mit Python und Tkinter programmiert.

    Ein gpio-Eingang (als pullup intern geschaltet) ist mit einem reed-kontakt verbunden, der ein zyklisch bewegtes Teil an einer Maschine abfragt. Im Programm wird ermittelt, wie lang das letzte "Maschine-läuft"-Signal am Eingang her ist

    und bei Überschreiten eines Wertes muss eine Eingabe am T.-Screen erfolgen, welche Art von Störung vorliegt

    Bei einigen Geräten geben drei Ausgänge zusätzlich ein Signal zu einem Relais für eine Ampel aus.

    Das ganze läuft ohne Netzwerkanbindung.


    Problem:

    der Bildschirm steigt aus, d.h. keine Touchfunktion mehr und meistens zusätzlich kein Videosignal am Bildschirm.

    Wie ich jetzt erst herausfand: das hdmi-Signal, das sonst parallel vorliegt, ist auch tot. Das Programm läuft aber im Hintergrund weiter: der Eingang wird weiterhin abgefragt und auf drei Ausgängen korrekt Signale ausgeben!


    Bisherige Versuche:

    da das Programm immehin 800 Zeilen hat und der Zero in Richtung 100% läuft, habe ich den 3+B getestet: gleiches Problem.


    Ausstehende Versuche:


    Einsatz geschirmter Kabel zum Reedkontakt (Kabellänge immerhin 6m) , obwohl soweit ich das erkenne keine falschen Impulse ankommen.

    Testen eines ähnlichen Touchscreens von joy-it.

    Testen von empfohlenen, höherwertigen SD-Karten (obwohl das Programm hier keine Daten permanent liest oder speichert), ggf. auch Industrie-SD-Karte

    Vereinfachung der Programmierung der Bildschirmaktualisierung: in der Hauptschleife, die auch den Zustand des Eingangs abfragt wird mehrfach pro Sekunde per ".config"-Befehl aktualisiert. Ich möchte dies zukünftig nur bei Änderungen anstoßen.


    Wer kann mir hier weitere Tips geben? Gibt es andere Dinge, die auf der Testliste ggf. fehlen ?

    Bin ich hier im Allgemeinen Bereich im Forum richtig (dies ist mein erster Beitrag)?

    Ich habe schon sehr viel Zeit in die Anwendung gesteckt und es ist schon echt frustrierend, hier quasi unmittelbar vor der Ziellinie aufzugeben obwohl sie ja grundsätzlich läuft :wallbash:


    Vielen Dank schon mal im Voraus!

  • Hallo Tueftler,


    ohne zu wissen, ob das RAM ausgeht, welcher Prozeß die 100% CPU Zeit zieht (beim Zero ist dann schnell Schluß, da der nur einen Core hat), Trendverläufe... wird es schwer, gezielte Hinweise zu geben. Generell wird man versuchen, das Problem einzukreisen. Du könntest Dein Hintergrundprogramm versuchen zu strippen, sodaß Du es mal mehrere Wochen ohne Touch UI laufen läßt (danach Vergleich der Vor- Nachherzustände). Nachdem Dein Programm aber wohl weiterhin im Hintergrund läuft, wird's das wohl nicht sein. Analog kannst Du ja mal Deinen Tochscreen mit einer sehr einfachen UI ausstatten und diesen (ohne Dein jetziges Programm) laufen lassen. Hängt sich das UI wieder auf? Anderes Touchdisplay nebst Treibern verwenden (das hattest Du ja selbst schon in Erwägung gezogen). Du kannst auch mal einen voll ausgestatteten Raspi mit "kurzgeschlossenen" Eingängen auf dem "Schreibtisch" (also im Laborzustand) liegen lassen, um zu sehen, ob sich hier ein anderes Fehlerbild zeigt, als beim produktiv eingesetzten. GPIO-Ausgänge definieren und auf die Eingänge klemmen, um so Schaltvorgänge per Hilfsprogramm zu simulieren wäre eine weitere Variante, um Fehlern auf die Schliche zu kommen...

    Schau auch noch mal kritisch auf Deine andere installierte Software. Aktualisiert die sich ggf. im Hintergrund...


    Viel Erfolg,


    schnasseldag

  • Was steht denn dazu in den Logfiles ?


    Servus !

    Evtl. htop mit laufen lassen und schauen ob deine Anwendung / Programm einen oder mehrere "z" (Zombie) Prozesse generiert. Die Z-Prozesse lassen sich nur beenden, wenn das Hauptprogramm beendet wird. Ein kill -9 pid hilft nicht als Gegengift, weil der Prozess schon terminiert ist, aber noch als Geist / Zombie im Speicher verbleibt. Nur so als Idee, normalerweise sollte der Kernel die Z-Problematik verhindern. Gruß ux

    • Official Post

    Hallo tueftler,


    willkommen im Forum! ;)

    da das Programm immehin 800 Zeilen hat und der Zero in Richtung 100% läuft

    Ich bin versucht Dich zu bitten das Programm hier zu zeigen, denn oft fehlen in Schleifen einfach nur kleine Pausen um die Auslastung zu senken.


    Bin ich hier im Allgemeinen Bereich im Forum richtig (dies ist mein erster Beitrag)?

    Ich lass den Thread erstmal hier, bis sich evtl. das Problem enger eingrenzen läst.

  • Hall tueftler,


    willkommen im Forum.


    Meiner Meinung nach liegt die Ursache an einem aktiven Bildschirmschoner. Bist du Dir sicher, dass der abgeschaltet bzw. deaktiviert ist Normalerweise sollten die HDMI-.Signale nicht einfach so ausgeschaltet werden.


    Hast Du mal die üblichen Kommandos ausprobiert, um einen Bildschirm einzuschalten - also das HDMI-Signal wieder zu senden?


    Wenn die Analyse der Log-Dateien einen Hinweis daraufbringt, dass und wann HDMI ausgeschaltet wird, dann sollte Dein Programm bei Gelegenheit mal die einschlägigen Log-Dateien bzw. die Ausgabe von dmesg dahingehend auswerten und ggf. das "Gegenmittel spritzen".


    Wenn keine langlaufende Anwendung ein Speicherleck enthält, spricht nichts dagegen, dass eine Anwendung "ewig" läuft.



    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • vielen Dank erstmal an alle, die so schnell geantwortet haben. Bin begeistert!


    Also sowas wie logfiles, daran habe ich auch schon gedacht. Nur habe ich damit noch nicht gearbeitet.


    Code
     mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal

    das habe ich im Netz dazu gefunden. Was muss ich da sonst noch einrichten?


    Andreas

    den Bildschirmschoner habe ich über Einträge im autostart deaktiviert.


    Eine frühere Version der Anwendung, die allerdings keine Eingänge abfragt, hat schon einmal 8 Monate lang problemlos funktioniert. Der Bildschirmschoner war da auf die gleiche Weise deaktiviert.


    hyle


    der pi 3B+ läuft mit dem Programm nur mit 40% Auslastung, zeigt aber die gleichen Symptome.

    Das Programm zu posten ist auch ein Vorschlag. Wirklich komplett? Vielleicht sollte ich in der Hauptschleife noch aussagefähige Kommentare einbringen.

    Wie stelle ich die 800 Zeilen hier am besten ein? Ich würde einen Dateianhang einstellen. Sorry, leider habe ich wenig Foren-Erfahrung.


    Carsten

  • Moin!


    Stell sie in einen Spoiler. Dann ist es erst ausgeklappt groß, Spoiler ist das 2te Zeichen von Rechts in der Funktionsleiste. Geh mal langsam mit der Maus drüber.


    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"

    Vielleicht trifft man sich in der RPi-Plauderecke.

  • ok. Den Freunden der eleganten objektorientierten Pythonprogrammierung sei aber gesagt: Achtung Erstlingswerk in Python! Auf B-Note wurde nicht geachtet und boolsche Algebra,...na ja, das üben wir noch mal.


    Zum Programm: es startet mit Klick auf "Schichtanfang" oben im Menü und dann "ok". Die Wert sind Minuten, also nicht wundern, dass sich erstmal nichts tut.


    Der Kern des ganzen ist die "def signalcheck ()", die als Hauptschleife durchlaufen wird und im wentlichen prüft, ob innerhalb der eingestellten Offset-Zeit ein Signal am Eingang anliegt. Ist die verstrichene Zeit größer als der Offsetwert, geht die Zeit zunächst auf das Konto "unbegründete Störung". Bis zum nächsten Eingangssignal kann der Wert einem konkreten Störungsgrund zugebucht werden.

    Alle Unterbrechungen außer Rüsten und Pause werden von einem anliegenden Eingangssignal automatisch beendet.


    Das ist ganz grob das Konzept.

    Edited once, last by tueftler ().

  • Hi zusammen,

    schön dass vier von euch das Programm mal heruntergeladen haben. Gibt es nach erster Durchsicht etwas das kritisch werden könnte?


    Von meiner Seite gibt es erste Zwischenstände:


    1) Die Geschichte mit den geschirmten Kabeln hats nicht gebracht


    2) Zur Zeit läuft auf zwei Geräten ein Test mit einer "entspannteren" Hauptschleife.

    Statt ...after(50,...) nun after (200,...) vielmehr geht nicht, weil dann kurze Eingangssignale zu häufig ins Leere laufen


    3) morgen wird ein Gerät mit dem Joy-it -Bildschirm statt adafruit an den Start gehen


    4) Bildschirmschoner deaktivieren fiel ja auch als Stichwort. Ich hatte mich für die Variante entschieden, wo das im Autostart gleich nach dem Öffnen eines lxterminals für den Programmstart (dieser dann über bash.rc-Eintrag) passiert.
    Ich will mal andere Methoden testen, die im Netz zu finden sind.


    Weiß das jemand?

    der origanale Autostart sieht ja so aus:


    @lxpanel --profile LXDE-pi

    @pcmanfm --desktop --profile LXDE-pi

    @xscreensaver -no-splash

    @point-rpi


    ich habe das so abgeändert (natürlich irgendwo im Netz gefunden und nicht wirklich verstanden, was die Einträge bedeuten):


    @lxterminal


    @xset s off

    @xset -dpms

    @wset s noblank


    kann sich da im Dauerbetrieb irgendwas "verknoten", wenn die ganzen ursprünglichen Einträge fehlen?? Wie oben erwähnt, wir haben es mit stretch, März 2018 zu tun.

    Gemeint ist hier der autostart unter home/pi/.config/lxsession/LXDE-pi.

    Soweit ich weiß gibt es wohl noch einen globalen autostart.


    Freue mich weiterhin auf eure Unterstützung,

    Carsten

  • Bei Programmen, die einige Zeit 'Däumchen drehen' und dann etwas machen, eventuell auch Unterprogramme oder externe Programme aufrufen, kann es sein, dass sie, wenn das Unterprogramm/externe Programm zu lange laufen, nach und nach immer mehr dieser 'verzweigungen' starten, so dass dann der Speicher vollläuft.

    Auch bei Interrups, die schneller kommen, als das Programm, das sie aufrufen, abgearbeitet werden, können dazu führen.

    Also auch solche Engpässe prüfen.

    Das Programm z.B. mit Checkpoints (Timstamps etc) testen, die werden den Ablauf zwar auch verlangsamen, liefern aber auch ein Hinweis, was ein Problem sein könnte. Wobei aber diese Verzögerungen die anderen Problem schon beheben können. ;)

    Selber denken,
    wie kann man nur?

  • Ich hätte diese Ansätze:


    1) Dein Programm sollte ein eigenes Logfile anlegen, um mitzuschreiben, was es gerade tut und wo es eventuell auf Zustände gestoßen ist, die Dir bisher vielleicht nicht aufgefallen sind. Für mich ist ein Logfile für ein Programm, das unbeaufsichtigt läuft, Pflicht und keine Kür.

    2) Schaue mal, ob es für den Interpreter so etwas wie Warnings mit verschiedenen Stufen gibt. Beim gcc/g++-Compiler für C/C++-Code gibt es solche Schalter, die gegen eine sehr hohe Anzahl von verschiedenen Fallen prüft.

    3) Führe eine Codeanalyse durch um zu sehen, wo Dein Code verbesserungswürdig ist. Ich bin kein Python-Programmierer sondern mit C/C++ unterwegs und mir haben solche Code-Analysen sehr viel gebracht.

    4) Wenn Du die Heavy-Metal-Stufe erreicht hast, dann prüfe mit Valgrind das Programm auf Speicherleks.

    Mein Github-Repository ist hier zu finden.

  • lxpanel ist die Taksleiste. pcmanfm ist der Dateimanager und mehr. xscreensaver ist der Bildschirmschoner. point-rpi setzt den Mauspfeil nach oben links. Was du davon brauchst oder nicht, musst du selber entscheiden. Wenn du wissen möchtest was das "Zeug" macht, dann sind die Manpages eine gute Anlaufstelle. Z.B. man lxterminal oder man xset in der Shell eingeben. Online gibt es die Manpages auch.


    Bei Änderungen in Textdateien wie autostart muss man nicht unbedingt Einträge löschen, wenn die deaktiviert werden sollen. Ein Auskommentieren (mit #) ist oft die bessere Wahl. Vor allem wenn man nicht weiss, was man tut.

  • also dass mit der codeanalyse werde ich mir auf jeden Fall mal anschauen. Ich hoffe nur, dass man sich da auch ohne top-level expertenwissen reinfindet.


    Gibt es hier jemanden, der mit pychecker, pylint oder pyflakes gearbeitet hat und mir eins davon empfehlen kann? Oder jemanden der ggf. das Fachchinesisch einer Analyse, die da wohl irgendwie stattfinden wird, ein wenig erläutern kann, wenn ich das Tool auf mein Programm losgejagt habe?


    Rasp-Berlin

    kannst du das mit den checkpoints etwas konkretisieren? Ich habe beim Programmieren, wenn mal etwas auf dem UI nicht wie gewünscht funktioniert hat, zum Testen häufiger mal Variabelwerte in die shell schreiben lassen. Um halt zu sehen, ob sich da überhaupt was tut (wenn sich vermeintlich nichts tut).


    Meintes du sowas- nur mehr auf einer anderen Ebene (Speicherebene)? Hast du ein Beispiel? Oder meintest du damit eine Software?

    Edited once, last by tueftler ().

  • habe nun einige Dauertests und Änderungen vorgenommen:


    1) Hauptschleife vereinfacht, so dass die Anzeige nur dann aktualisiert wird, wenn sich die Werte geändert haben: Ergebnis: Prozessor läuft nun bei 40% Auslastung statt nahe 100% aber Problem besteht weiterhin (Anzeige reagiert nicht mehr- Programm läuft meist noch im Hintergrund weiter


    2) einmal am Tag ein automatischer Reboot. Keine Verbesserung. Ein Speicherleck kann damit aber denke ich ausgeschlossen werden


    3) zu den Logdateien bin ich noch nicht gekommen. Aus Zeitgründen. Wäre aber interessant


    4) Da ich mit der time.time () Funktion arbeite: Mir wurde gesagt, dass mal Probleme bekannt wurden, wenn phasenweise eine Internetverbindung besteht, phasenweise nicht. Wegen falscher Zeitstempel. Die Erstinbetriebnahme der drei Raspis war zu Hause mit Internetverbindung, der Dauerbetrieb in der Firma dann ohne. Dann hätte das Problem aber nicht erst nach Wochen auftauchen dürfen sondern gleich beim Hochfahren, denke ich. Wer kann dazu was sagen?


    5) Folgende Tests laufen noch:


    a) komplette Hardware aus unbenutzten neuen Komponenten aufgebaut. Neue SD_karte benutzt und Raspbian sowie Programm neu eingichtet.

    1x in der Firma, 1x zu Hause. Keine Probleme im Dauerlauf seit 10 Tagen. Aussagekräftig wären aber mind. 4 Wochen. Man wird sehen.


    b) Ein Gerät mit Touchscreen v. anderem Hersteller ausgestattet. Läuft auch seit 10 Tagen.

    • Official Post

    Das Thema ist ja schon ein paar Tage alt und ich habe ehrlich gesagt jetzt nur nochmals überflogen und deshalb die Frage. Sorry falls diese schon gestellt wurde!


    Welche Netzteile werden für die RPi verwendet und sind das alles die gleichen oder gibt es da Unterschiede?

  • es sind alles die gleichen, und zwar die originalen Raspberrynetzteile. Hatte auch schon den Verdacht, dass unser Stromnetz in der Fertigung wegen der Maschinen

    Schuld ist aber es passiert auch in der Verwaltung. Diese hängt laut Elektriker an einem eigenen Trafo.

    Bisher lief bei den drei Probanden in meinem Keller seit dem 15.03. alles glatt.

    Aber heute hatte ich das Fehlverhalten bei einem, bei dem ich den Eingang dauerhaft kurzgeschlossen habe. Der Tipp kam von Schnasseldag weiter oben.

    Ich werde nun bei allen Probanden im Keller den benutzten Eingang dauerhaft schließen. Wenns dann auch nach ein paar Tagen passiert, ist zumindest die Ursache geklärt. Spannender wir die Geschichte, wie man das Problem dann umgeht. Aber man wird sehen.

  • nachdem ich nun zwei Geräte in der "sicheren" Umgebung meines Kellers über Monate betrieben habe, ohne dass Probleme aufgetreten sind und nachdem ich fast genauso lange bei den Geräten in der Firma es verhindert habe, dass sich "mal eben" der Stecker ziehen lässt, kann ich sagen: es funktioniert alles wie es soll.


    Ursache offensichtlich falsche Handhabung. Das Gute: ich habe viel auch durch die Vorschläge hier gelernt, danke nochmal an alle Aktiven. Was mir auch klar geworden ist: bei Anwendungen für andere Nutzer muss alles intuitiv und "narrensicher" funktionieren. Wenn nicht nachvollziehbare Zustände entstehen, wird jeder erstmal auf eine Fehlfunktion tippen und dann halt den Stecker ziehen.

  • ... und dann halt den Stecker ziehen ...

    Ist i.d.R. auch ein guter Ansatz.


    Wie heisst es doch immer wieder: Reboot tut gut


    Nur leider ist ein Stecker ziehen beim Raspi um ein Reboot zu erwirken keine gute Idee. Dann empfielt sich einen Reset Knopf HW maessig ueber einen GPIO anzubauen.

    "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect."

    Linus Benedict Torvalds, 28.9.2003


    Hast Du die Woche schon Deine Raspberry gesichert =O Bei mir tut das raspiBackup automatisch ;)