helloBavaria Für die Nachwelt: Bei welchem OS mit welchem Displayserver (X11 oder Wayland) hat es funktioniert?
Es läuft die Debian version 10 "Buster" und X11
Posts by helloBavaria
-
-
Schau Dir mal das Qt-Property windowFlags an und da insbesondere den Qt::WindowStaysOnTopHint. Achtung: Die Dokumentation von dem Flag lesen, es kann sein, dass das nicht alleine funktioniert. Und der Windowmanager muss das unterstützen. Openbox müsste das können, bei mutter weiss ich es nicht, und das ist alles für X11, zu Wayland kann ich nix sagen.
Qt::WindowStaysOnTopHint hat funktioniert, vielen Dank
-
Hi,
ich habe mir eine Fotobox gebastelt mit angeschlossenem Drucker. Dazu läuft ein Pythonprozess, der ein aktuelles Bild von einer Kamera anzeigt, per Knopfdruck kann man ein Foto machen. Und anschließend speichern/drucken. Soweit funktioniert das alles.
Hat der Drucker aber einen Fehler (z.B. Papier aus), so wird ein Popup-Fenster angezeigt: "Druck-Fehler: Es gibt ein Problem beim Senden.... ". Dieses Fenster überdeckt dann den Python-Prozess, stört also.
Gibt es eine Möglichkeit, dieses Popup-Fenster nicht oder nur im Hintergrund anzuzeigen?
Gibt es alternativ die Möglichkeit, den Pythonprozess immer im Vordergrund anzuzeigen? Die Anzeige funktioniert mittels QWebView (PyQt5.QtWebKitWidgets). Ich habe leider kein Flag gefunden, dass die QWebView immer im Vordergrund hält.
Danke schon mal für hilfreiche Tipps.
-
-
Wer hat dir solchen Unsinn erzählt ?
Ich habe das in der Schule gelernt. Wenn man "Einschaltstrom LED" googelt dann kann man das auch nachlesen.
Ein Einschaltstrombegrenzer (Heißleiter) brachte mir nun Abhilfe. Seit ich so einen mit verbaut habe treten keine Störungen mehr auf
-
Danke erstmal für eure Antworten, Tipps und Hinweise.
Es ist so, dass das Relais mit 5V vom Pi versorgt wird und mit den 3,3V geschalten wird.
Die Last, die am Relais hängt ist eine LED-Lampe.
Mein Verdacht ist mittlerweile, dass der Funke beim Schalten die Probleme verursacht, da LEDs ja einen sehr hohen Einschaltstrom haben....
-
Also ein Relais ist erstmal dazu da den Rechner von der zu schaltenden Last unabhängig zu machen. Wenn Dein Rechner dann nur in Abhängigkeit der Last ein Fehlverhalten zeigt, dann ist im allgemeinen nicht das Relais daran schuld. Die Spule, welche die Relaikontakte bewegt, benötigt immer gleich viel Strom, egal welche Last damit geschaltet wird.
Suche den Fehler lieber wo anders...
Danke für Deine Antwort.
Im Grunde gebe ich dir da natürlich Recht. Allerdings muss ich sagen, dass ich das Ganze schon mal runtergebrochen habe auf ein Minimalprogramm...
Relais wird angesteuert...
1. ...ohne dass eine Last angeschlossen ist: Relais schaltet, keine Probleme treten auf
2. ...mit kleiner Last: Relais schaltet, es treten selten Probleme auf
3. ...mit größerer Last: Relais schaltet, es treten häufig Probleme auf
Ich kann mir das noch nicht so ganz erklären, vielleicht auch EMV-Probleme?
-
Hat Dein System Logfiles ?
Servus !
Bzgl. Logging habe ich nichts aktiviert, geschweige denn logge ich selbst was mit.
Mit Logfiles allgemein habe ich mich ehrlich gesagt auch noch nie wirklich beschäftigt...
-
Servus Zusammen,
wollte mal fragen, ob hier jemand ein Relais empfehlen kann, welches mit dem Raspberry gesteuert werden kann? High-Level oder Low-Level ist mir egal.
Es müssen 230V/0,5...1A geschalten werden.
Ich habe mir dieses Relais bestellt: https://www.makershop.de/module/relais/1-kanal-relais/, bin damit aber nicht glücklich.
Je nachdem wie groß die Last ist, die tatsächlich über das Relais geschalten wird, bekomme ich am Raspi manchmal andere Probleme, die auf einen Spannungseinbruch zurückzuführen sind (trotz original Netzteil).
VG
-
Ich habe nochmal neue Erkenntnisse, die gerne mitteilen möchte. Leider bin ich jedoch noch nicht wirklich weiter gekommen.
- Der Tausch des Netzteils hat nichts verändert
- Die USB-Sticks, bei denen die Probleme aufgetreten sind, habe ich mit "h2testw.exe" überprüft, es wurden keine Fehler gefunden
Außerdem bin ich mir mittlerweile eig. sehr sicher, dass die Bilder nach der Aufnahme nicht korrupt sind, sondern erst später korrupt werden. Es gib eine Art "Vorschau", bei der das aufgenommene Foto angezeigt wird, zu diesem Zeitpunkt ist es auf der SD-Karte gespeichert -> hier ist immer alles fein. Will ich mir später alle Fotos, die mittlerweile auf den USB-Stick verschoben wurden, nochmal Durchschauen, fallen die korrupten Bilder auf.
In Verdacht hatte ich bisher trotzdem den USB-Stick, auch wenn h2testw.exe keine Fehler gefunden hat. Ich hatte vermutet, dass vielleicht erst nach gewisser Zeit Daten verloren gehen. Allerdings habe ich nun einfach mal in Windows viele Daten drauf geschrieben, diese waren auch nach längerer Zeit alle vorhanden und nicht korrupt.
Ich habe mein Skript jetzt mal noch geändert, sodass die Bilder von SD-Karte zu USB-Stick nicht verschoben sondern kopiert werden. Seitdem ist das Problem nicht mehr aufgetreten, allerdings war das auch noch kein Dauertest.
-
Das kommt drauf an, was auf dem Stick gespeichert werden soll. aufgrund der eingeschränkten Dateigröße von 4 GB bei fat32.
Die max. Dateigröße von 4 GB ist nicht kritisch. Es geht um Bilddateien, Textdateien etc., aber nichts was den 4 GB nahekommt, geschweige denn überschreitet
-
Hallo Zusammen,
gibt es eine Empfehlung, wie der USB-Stick am Raspi formatiert werden sollte?
Der USB-Stick sollte sowohl vom Raspi als auch an Windows-PCs gelesen/beschrieben werden können.
Ich habe bisher nur FAT32 genutzt.
VG
-
Wie viele von denen, die bewertet haben, haben Ahnung und haben mal nachgemessen?
Solange es funktioniert, sprich NT in die Steckdose und das Gerät leuchtet, sind doch 99,74% zufrieden. Spätere Probleme werden in allererster Linie gar nicht mit dem NT in Verbindung gebracht.
Da hast Du natürlich recht. So gehts ja auch mir
Hier ist man halt auch bisschen verwöhnt, z.B. als Smartphone Netzteil wird es hier nie Probleme geben denke ichSpare nie am Zubehör für einen Raspberry, wenn er durchweg sicher laufen soll und man glücklich werden möchte.
Ich werde es mir zu Herzen nehmen und mal schauen, ob das Problem mit einem Original Netzteil vielleicht schon behoben ist. Gehäuse verwende ich eins von Geekworm (Aluminium, Passivkühlung). Hier habe ich mehr Acht gegeben welches ich nehme, andere User haben bei diesem Gehäuse mal die Temperatur gemessen und waren sehr zufrieden.
-
Interessant, hatte ich ehrlich nicht auf dem Schirm, dass dieses Netzteil problematisch sein könnte. Hab es empfohlen bekommen und Bewertungen sind auch gut...
Erfahrungswerte aus erster Hand kann ich auch bieten.
hast du auch Vergleichswerte von einem anderen Netzteil? Wäre spannend zu sehen ob es tatsächlich zu Spannungseinbrüchen kommt
-
Vielen Dank für eure Hinweise und Tipps.
Da dieses Problem so sporadisch auftritt ist es etwas mühsam alles zu testen.
Was ich mittlerweile ausschließen kann, ist dass es am USB Stick liegt. Dasselbe Problem ist auch mit einem anderen USB Stick aufgetreten.
Netzteil verwende ich folgendes:
[Official Standard 5.1V 3.5A 17.9W] Raspberry Pi 4 Power Supply, iUniker USB C Power Supply with On/Off Switch Raspberry Pi 4 Power Supply with On/Off Switch for Raspberry Pi 4 8GB/4GB/2GB/1GB https://amzn.eu/d/87pFq70
Gibts hier andere Empfehlungen?
Ich werde als nächstes mal versuchen die Bilder zu kopieren anstatt sie zu verschieben.
-
Das Programm kann schon lange fertig sein, was aber nicht zwangsweise bedeutet, dass die Kopieroperation erfolgreich beendet worden ist
Vielleicht muss ich noch dazu sagen, dass es mehr ein "Dauerbetrieb" ist. Der USB-Stick ist ab Bootvorgang eingesteckt, das Programm läuft einige Stunden und immer wieder wird mal auf den USB-Stick ein Foto gespeichert. Nach einigen Stunden wird ausgeschaltet und auf dem USB-Stick sind z.B. 100 Fotos gespeichert worden, wobei Foto Nummer 3, Foto Nummer 51 und Foto Nummer 78 korrupt sind, alle anderen wurden "erfolgreich" abgespeichert. Der USB-Stick wird erst entfernt, wenn das System heruntergefahren ist.
Deshalb kann ich mir irgendwie nicht vorstellen, dass der Grund für den Fehler ist, dass der Kopiervorgang noch nicht beendet wurde.
-
Hallo Zusammen,
ich habe eine Fotobox gebaut, bei der sporadisch Probleme auftreten. Auf dem Raspi läuft ein entsprechendes Pythonskript.
Workflow:
- Tastendruck -> Bilder wird mit RaspiCam aufgenommen, temporär auf der SD Karte gespeichert und eine Vorschau angezeigt
- Das Bild gefällt? dann wird mit einem weiteren Tastendruck das Bild von der SD Karte mittels python und "shutil.move(..)" auf einen USB-Stick verschoben
Das ganze funktioniert grundsätzlich recht gut (...dachte ich bisher..).
Wenn an einem Abend aber so um die 100 Fotos gemacht werden, dann sind ca. 3 - 5 Fotos korrupt auf dem USB-Stick.
Ich konnte kein wirkliches Muster erkennen (mal kurz nachdem ein anderes Foto verschoben wurde, mal als die Fotobox länger nicht benutzt worden ist... )
Möchte ich mit dem Fotoeditor von Raspbian das Foto öffnen kommen unterschiedliche Fehlermeldungen, z.B. "Fehler beim Lesen einer JPEG-Bilddatei (unsupported marker type 0x9c)", "Fehler beim Lesen einer JPEG-Bilddatei (Not a JPEG file: start with 0xff 0xff)", "Fehler beim Lesen einer JPEG-Bilddatei (invalid JPEG file structure: two SOI markers)".
Hat jemand eine Idee was hier schief laufen könnte? Hatte schon mal jemand Probleme mit "shutil.move()"?
Oder wäre es von Haus aus empfehlenswert, das Bild direkt auf dem USB-Stick zu speichern, sodass man auf das verschieben verzichten kann?
Vielen Dank schon mal!
-
Display More
Hallo,
ist der Code denn von dir oder hast du denn + die config-file irgendwo her?
Auf den ersten Blick ist das ein großes Chaos für mich. Es geht schon los, dass das 'initSystem' das in einer Klasse steckt in der '__init__' einer anderen Klasse aufgerufen wird.
Was steckt denn hinter fotoboxCfg['nopi'] ?
Kann es sein, dass die Kameraverbindung immer offen ist und du dadurch Fehler bekommst? Jedes Objekt/Verbindung/Datei die geöffnet wird, sollte nach der Verwendung wieder geschlossen werden. Pi-Camera kann auch mit dem 'with'-Statemant verwendet werden, dann übernimmt das Schließen automatisch.
Nur mal so als Gedanke. Ansonsten würde ich das Programm mal stark reduzieren und Schritt für Schritt immer wieder testen, irgendwann solltest du ja an den Punkt kommen von geht -> geht nicht mehr.
Grüße
Dennis
Ich habe den Code im Netz gefunden und ihn erweitert. Er war davor sicherlich nicht 100% sauber und ich habe es bestimmt auch noch schlimmer gemacht
. Bin noch Anfänger auf dem Gebiet, hab dadurch aber schon einiges gelernt und nehme mir Deine Worte zu Herzen -> ich werde mal versuchen "aufzuräumen".Zu deinen Fragen:
- fotoboxCfg['nopi'] -> Es kann konfiguriert werden ob eine Raspi-Cam angeshclossen ist oder eine andere Digitalkamera
- Die Verbindung ist immer offen, das ist aber schon so gewollt. Es soll halt immer ein aktueller Livestream ausgegeben werden, bis jemand den Button drückt um ein Foto zu machen, anschließend wird die Vorschau beendet und das soeben geschossene Foto angezeigt. Anschließend wieder zurück zum Livestream...
-
@ Der kritische Fehler tritt auf, wenn der Button 1 gedrückt wird und die Methoden "self.ui.screenCapture(self)" und "self.ui.lightOn(self)" gerufen werden
Wenn lightOn den Fehler verursacht, dann hast Du möglicherweise einen Spannungsabfall, der das BS beeiträchtigt.
Anzahl /Verschaltung der LEDs oder untaugliches Netzteil, könnten die Ursache sein, die auch in den Logfiles dokumentiert sein sollte.
Servus !
Danke für den Tipp! Ich glaube genau hier liegt das Problem. Leider kam ich anhand der Logfiles nicht drauf..
Scheinbar ührt "self.ui.lightOn(self)" dazu, dass die Verbindung zur Kamera nicht mehr richtig funtioniert und somit der preview beendet wird.
Der Absturz ist dann später bei "self.camera.stop_preview()", vermutlich weil hier ein preview gestoppt werden soll der gar nicht mehr läuft.
"self.ui.lightOn(self)" schaltet ein Relais, laut Beschreibung sollte es eig. für den Raspberry einwandfrei geeignet sein. Es funktioniert ja auch, allerdings in Verbindung mit der Kamera kommt es wohl zu diesem blöden Fehler, wahrscheinlich wegen Spannungsprobleme.
Ein erneutes starten der Vorschau in der Methode "def screenCapture(self, Form)" brachte mir beim rumprobieren jetzt Abhilfe. Seit ich das eingebaut habe hatte ich keinen Absturz mehr.
-
Jetzt habe ich gerade nochmal ausführlich getestet und das Problem tritt auf einmal ständig auf (bei jedem zweiten Foto :((( )
Verantwortlich ist die Methode
Codeself.camera.stop_preview()also das beenden der Vorschau.
