Posts by koelnpub

    Leider gibt es nur eine Anleitung für das anzeigen Daten in Phyton, aber nicht als kontinuierliche Visualisierung.

    Hier kannst du allerdings auch ansetzen:

    1. lass dein Sensorprogramm die Daten in eine Datei schreiben
    2. Lass dein Anzeigeprogramm in einer Schleife laufen. Dabei wird die Datei regelmäßig geöffnet, gelesen und wieder geschlossen. Mit den gelesenen Daten aktualisierst du deine Ausgabe.


    Da dein Sensorprogramm so wie so in einer Schleife läuft, kannst du eventuell das Anzeigeprogramm als Funktion einbinden und bei jedem Schleifendurchlauf aufrufen.

    Alternative lokale Anzeige auf dem Pi:

    Da bietet sich einmal eine Ausgabe via GUI (z.B. tkinter oder guizero) an. Das ist aber nur bei vorhandener graphischen Oberfläche (X-Server) sinnvoll, sonst musst du einige Zusatzhürden überwinden die dich garantiert deutlich ausbremsen.

    Ein weiterer Weg für die Darstellung kann auch eine Browser Anzeige sein, allerdings setzt auch das voraus dass du keine lite Version des Betriebssystems am Start hast.

    Für die Browservariante schreibst du die Messergebnisse des Sensors in eine Datei. Hier solltest du aber darauf achten, die Datei nach jedem Schreibzyklus wieder zu schließen, sonst kann kein anderes Programm die Datei öffnen solange deine Sensoranwendung läuft. Die Datei kannst du dann im Browser auslesen und anzeigen. Basierend auf meinem Hintergrund würde ich persönlich die Browserausgabe mit PHP umsetzen. Das geht aber garantiert auch mit Python, nur fehlt mir dazu die Erfahrung.

    Danke allerseits für die schnelle Hilfe.


    DeaD_EyE Die Klasse funktioniert klasse! :danke_ATDE::) Mein Darstellungsproblem kam wohl daher, dass ich in der Bilderliste Dateinamen hatte statt ImageTK.PhotoImage Objekte. Zumindest verstehe ich deinen Code so. Daran, dass ich nicht sofort eine Klasse sondern eher proceduralen code geschrieben habe muss ich noch nachbessern. War mir völlig klar, aber bisher hatte ich noch nicht die Zeit mich in die Syntax einzulesen. Mit Python beschäftige ich mich seit ca. 3 Wochen, da war die Zeit, um gleichzeitig alles zu lernen, halt etwas knapp. Zumal wenn man gleichzeitig noch ein paar andere Nebenbeschäftigungen hat.


    Mir ist auch noch nicht wirklich klar, was ich ändern muss um die Klasse ImageViewer später in eine andere App einzubinden, also dort zu importieren. Aber ich werde mich erstmal drauf stürzen und mich schlau lesen.


    Ich setze dean Thread auf erledigt


    Gruß

    Gunter

    Ansonsten solltest du anfangen auf 'global' zu verzichten und die mit objektorientierter Programmierung zu beschäftigen

    Mit dem Vorschlag stößt du offene Türen auf.

    Das angemeckerte 'global' war eine Relikt meiner Tests bei der Ursachenforschung. Ich war mir nicht sicher, wie 'pointer' als Parameter übergeben wurde, ob by value oder by reference. Leider hatte ich den Test mit einer globalen Variablen noch nicht rückgängig gemacht, bevor ich den code hier vergestellt hatte.


    vorher sah der code so aus:

    Code
    Button(root,text="<=",command=lambda:step_backward(root,label,img,thumbs,pointer),height=5)


    'partial' hat das Verhalten nicht verändert, der neue Code zeigt das gleiche Verhalten:

    Code
    Button(root,text="<=",command=partial(step_backward,root,label,img,thumbs,pointer),height=5)

    Ich beobachte gerad ein seltsames Verhalten eines Programmes. Dieses Programm habe ich zu Testzwecken schnell und völlig unstrukturiert zusammengekloppt. Aber es läuft!

    Der weitere Plan war, diesen Code ein wenig zu strukturieren:

    Das Programm läuft, aber sobald ich einen der Buttons klicke, verschwindet das aktuelle Image und lediglich ein leerer Bereich in der Größe des Bildes wird dargestellt.

    Starte ich das Programm mit dem Thonny Debugger, und steppe mich durch, dann wird sehr wohl das nächste Bild dargestellt. Ich vermute mal, das ist irgend ein Timing Problem, weiß aber nicht wirklich ob ich damit richtig liege.


    Ich hoffe, jemand kann mir hier eine Marschrichtung zur Lösung zeigen.

    Hi,

    wir nutzen ESP32 in Sensoranwendungen die LiPo versorgt werden und nur alle paar Minuten Daten via WLan und MQTT senden müssen. Aus dem Tiefschlaf können die sich selber aufwecken und nur für das Absetzen der Daten an NodeRed brauchen sie fühlbare Energie. Während des Schlafs gehen sie mit dem Energieverbrauch soweit runter, dass unsere vier 18650 Zellen gefühlt ewig halten. Ein Temperatur und Lichtsensor an der Gewächshausdecke läuft mittlerweile fast zwei Jahre. Der Licht und Wind Sensor hätte das sicher auch geschafft, wenn nicht ein Sturm das Windrad gekillt hätte und wir den Sensor zur Reparatur abbauen mussten. Ein gutes Jahr hatte er aber sicherlich auf dem Buckel. Die Pläne für das neue Windrad liegen auf dem Tisch müssen aber noch verwirklicht werden, zumal jetzt auch noch ein Windrichtungsmesser dazukommen soll.

    Könnte ich also nun 2 verbinden um 5V und 2000mAh als Output zu haben?

    Grundsätzlich schon, aber sinnvoll ist ein Battery-Management-Controller der mehrere Zellen direkt managed. Power-Banks mit eigenen BMCs zusammenschalten (Parallel) geht zwar, aber nur mit Nebenwirkungen. Falls die banks unterschiedlichen Spannungen haben, fließt Strom von der Bank mit der höheren Spannung in die Bank mit der niedrigeren Spannung. Das hat nichts mit den Ladezuständen der einzelnen internen Zellen zu tun, sondern mit den Toleranzen der Ausgangsspannungen (5V) der jeweiligen BMCs der Banks.


    Und kann der Pico 2000mAh vertragen?

    mAh ist eine Angabe zur Kapazität der Powerbank und sagt nichts anderes, als dass die Bank einen Strom von 2000mA eine Stunde lang liefern kann, zumindest theoretisch. In der Praxis kommen hier noch ein paar andere Faktoren ins Spiel, brauchen uns aber momentan nicht zu interessieren.

    Wichtig ist zu wissen, wie hoch der maximale Entladestrom sein darf, also das was die Bank zu liefern bereit ist.


    Gehen wir mal davon aus dass der maximale Entladestrom 1000mA beträgt bevor die Bank abschaltet.


    Nun hilft ein kurzer Blick auf das Ohmsche Gesetz (Gesetze sollte man fast immer beachten ;) ) Der tatsächliche Strom (I)wird bei konstanter Spannung (U=5V) vom Widerstand (R) der Last (Pico) bestimmt.

    Beispiel: R = U / I => R ist der Lastwidersrtand des Picos und U die angebotene Spannung der Powerbank


    Szenario 1:

    aktuelle Spannung = 5V

    momentaner lastbedingter Strom = 500mA

    demnach ist der derzeitige Lastwiderstand 10 Ohm


    braucht der Pico nun mehr als 500mA, da der Motor mehr Kraft aufwenden muss/soll, dann sinkt der Innenwiderstand auf z.B. 5 Ohm. Daraus ergibt sich ein Strom von 1000mA.


    Das geht gut, da die Powerbank 1000mA liefern kann.


    Szenario 2:

    aktuelle Spannung = 5V

    momentaner Lastwiderstand = 4 Ohm

    demnach ist der derzeitigelastbedingter Strom = 1250mA

    (Wenn R = U / I ist, dann ist I = U / R)


    Denn - sinkt aber jetzt der Lastwiderstand, wegen höherer Motorlast, noch weiter, dann bekommt die 1000mA Powerbank Probleme und schaltet ab. Sie kann nun mal keinen höheren Strom liefern, dar aber benötigt würde um z.B einen Last von 4 Ohm noch zu versorgen. Dazu müsste die Bank 1250mA liefern können.


    Fazit: 2000mAh verträgt der Pico, denn er bestimmt, wieviel Strom tätsächlich fließen soll.

    Sorry das ich kein 'guizero' genutzt habe, aber 'tkinter' war mir für die "schnelle" vertrauter. Hoffe du kannst so in dieser Art dein GUI auch aufbauen.

    Da gibt's nichts zu entschuldigen. Nachdem ich mir auf youtube ein 5,5 Stunden tkinter Tutorial gegönnt habe, weiß ich nun, dass ich guizero besser übersprungen und gleich mit tkinter gestartet hätte. Aus Schaden wird man klug.

    Eine Klasse wäre in diesem Minimalbeispiel nicht unbedingt nötig gewesen, aber sobald man sich Werte/Zustände merken muss, wird sie benötigt und ist für die GUI-Programmierung grundlegend.

    Dein Klassenbeispiel hilft mir erheblich mich bei Python in die OOP einzuarbeiten. Bei PHP mache ich das schließlich auch - aus gutem Grund.


    Danke euch allen für die tolle Unterstutzung, ich werde mich jetzt erstmal auf die Umsetzung der vielen Tips konzentrieren und den Thread erstmal als erledigt markieren. :bravo2: :danke_ATDE::danke_ATDE::danke_ATDE::danke_ATDE::bravo2:

    Was soll sich denn durch die GUI inhaltlich/sachlich an der Bedienung ändern?

    Wenn es letztlich das gleiche sein soll, wie die Lösung über Taster an GPIOs, dann könntest du auch ein Nextion-Display nehmen.

    Das ist allerdings ein hochinteressanter Ansatz, Auch für einige unserer anderen Projekte. Dem werde ich wohl nachgehen und mir 10" Display (NX1060P101) bestellen. Allerdings wird das wohl erst im nächsten Release des Projektes zum Einsatz kommen.

    Aktuell muss ich den bisherigen Weg weitergehen - auch wenn's mir sehr umständlich erscheint.


    Danke für den Tip.


    global`will man normalerweise nicht benutzen, weil es den Zustand des Programms unübersichtlich und schwer bis nicht nachvollziehbar macht. Funktionen übergibt man Parameter explizit. Machst du an den meisten Stellen ja.

    Richtig, zumal einige der Variablen eigentlich Konstanten sein könnten.

    Einige der genutzten globalen Variablen sind systemweit gültige Statusvariablen auf die ich kaum verzichten kann

    `os.system` ist veraltet, das steht sogar wörtlich in der Python-Doku. `subprocess` ist das Modul der Wahl

    subprocess werde ich mir vornehmen. Wenn ich die Doku gelesen hätte, wäre ich womöglich selber drauf gehommen. Sowas passiert wenn man sich den Code im Netz zusammenklaut.

    Keine kryptischen Variablennamen benutzen k, s und t , sondern aussagekräftige Namen. Sonst ist der Code schwer verständlich.

    Das ist reine Faulheit gewesen und wird im offiziellen Release geändert. Sowas mache ich normalerweise zusammen mit der Doku-Erstellung. Ohne Doku geht bei uns überhaupt nix.


    Aber mich drückt der Schuh ja an einer ganz anderen Stelle: die verdammte GU . Denn ich bin's absolut nicht gewohnt mich schon während des Programmierens bereits um das Layout kümmern zu müssen.

    Hat jemand einen Vorschlag wie ich das Projekt in einen OOP Ansatz bringen kann um dann bei meinen Objekten, möglichst von außen, Margins setzen kann

    Nun denn, mal sehen wer zuerst die Nerven verliert über den Code


    Bitte wundert euch nicht über die seltsame Farbgebung, so erkenneich halt besser den Stand der Dinge. Vorallen da die Boxen durchaus Eigenleben enwickeln sobald sie gefüllt werden.

    Die GUI bsteht aus einem Header, einem Footer, und einem geteilten Mittelteil.

    Im Header steht ein dreizeiliges Formular

    Der Footer ist für spätere Statusausgaben vorgesehen

    Im linken Mittelteil befinden sich die Buttons zur Kamerasteuerung und zukünftig (die gelbe Box) auch noch zwei Slider zur Steuerung des Leuchttisches.

    Über PWM werden die blaue nund die grüne Leds gedimmt (MeanWell Power supplies mit PWM Steuerung)

    In der rechten (grünen) Box werden erstmal Thumbnails der gespeichten Images angezeigt.


    Um Fehlermeldungen vorzubeugen

    wird folgende Deiteistruktur benötigt

    /home/pi/Camera

    /home/pi/Pdf

    /home/pi/Pictures

    /home/pi/Thumbs

    meine Python Scripte sehen in /home/pi/Camera


    Übrigens sind mir die Grundsätze der Objektorientierten Programmierung durchaus vertraut, lediglich die Mehrfachverermung kenne ich von PHP her nicht.

    Klassen, Instanzen, Methoden, Eigenschaften (Properties), Funktionen ... sind für mich keine Schimpfwörter sonder Teil meines Programmieralltags.

    Dazu kommt noch Elektronik und andere Hobbies. (Ich habe neine Ausbildung zum Rundfunk- und Fernsehtechniker vor über 50 Jahren beendet.)

    Mein erster Heimcomputer was 1977 eine PDP 11/20 mit einem DEC-Tape als Massensteicher und einer Teletype als Konsole. Googled das mal.

    Meine Programmiersprachen waren damals Fortran, Cobol und Assenbler.

    Basic war auch damals schon eher etwas für Kinder.

    Natürlich bin ich nicht auf diesem Wissen des letzten Jahrtausends stehen geblieben sondern habe mich weiterentwickelt.


    So, nachdem Ihr nun fast meinen Lebenslauf kennt, seid ihr drann.


    Danke für eure Mühe. :danke_ATDE:

    Hallo Allerseits,

    meine ursprüngliche Aufgabe war ein etwas sehr in die Jahre gekommenes Gerät wieder Labortauglich zu machen. Bei dem Gerät handelt es sich um einen sogenannten Gel-Dokumenter. Dabei werden unter einer Haube Agarose-Gel-Platten auf einen Leuchttisch fotographiert und dokumentiert. Bisher diente dazu eine betagte Digital-Kamera mit der gigantischen Auflösung von 800x600 Pixeln.


    Das einzig wirklich Gute an der Apparatur ist die Haube und die Optik mit einem C-Mount.

    Ich habe die veraltete Kamera gegen eine HQ-Cam und einen RPi4 getauscht. Der Pi übernimmt mit der PiCam auch die Nachbearbeitung, sprich Archivierung, der Aufnahmen.


    Mit Python und PiCamera habe ich ein Preview auf den Bildschirm gegeben und über einen GPIO-Pin die eigentliche Aufnahme ausgelöst. War auf dem Weg auch recht schnell erledigt, aber dann kam jemand aus dem Labor und wünschte sich statt der GPIO-Buttons eine GUI.

    In meiner grenzenlosen Naivität habe ich zugesagt diesen Wunsch zu erfüllen und dazu auch Python zu nutzen. Normalerweise löse ich sowas über eine PHP-getriebene Web-Oberfläche mit CSS und JS. Wie da allerdings die Camera hineingepasst hätte, weiß ich nicht.


    Als GUI Library habe ich mir guizero ausgesucht, das schien am schnellsten für mich als Python-Neuling erlen- und nutzbar zu sein.

    Ob das wirklich so klug war, wage ich jetzt, nach mehreren Tagen frustrierenden Experimentierens, zu bezweifeln.

    Allein das Positionieren der Widgets ist, CSS-verwöhnt wie ich nun mal bin, eine Zumutung.


    Also hier meine wichtigsten Fragen:


    • Gibt's einen Weg Logik und Verarbeitung vom Layout zu trennen?
    • Gibt's eine "bessere" GUI Library für meine Zwecke, die auch in angemessener Zeit erlernbar ist?
    • Momentan lege ich die Vorschau camera.start_preview(...) ganz brutal über einen Bereich des Bildschirms - geht das cleverer?


    Die restlichen Fragen kenne ich noch garnicht. :wallbash:

    Hallo Dennis,


    deine Hinweise sind absolut willkommen und hilfreich. Auf meinen versehentlichen Verzicht von "app.display()" war ich bereits selber gekommen, das das kurze Aufblitzen bei meinem Versuch über ein Terminalfenster zu starten es auch nur kurz blitzte.

    Die Thonny IDE scheint sowas irgendwie abzufangen, denn hier erschien die App.


    Danke nochmals

    Ich lag mit meiner Vermutung richtig: kaum hatte ich die aktuelle Version von guizero installiert, schon klappt's.

    Bei dem Box-Widget kann ich jetzt das property "align" setzen. Das layout property zickt zwar immer noch, aber damit kann ich leben - in allen Boxen kommt so wie so das grid lauout zum Einsatz.

    Ich glaube fast, ich kann's mir schon selber beantworten:

    Derzeit nutze ich die guizero-Version 0.6

    mal sehen was ich machen muss um die aktuelle stabile Version 1.2 zu installieren, falls ich das nicht selber herausfinde (Google sei dank) gehe ich Euch erneut auf den Kranz.

    Vorerst schließe ich den Thread

    Hallo Allerseits,


    der Versuch mich in guizero einzuarbeiten scheitert leider an einem Verständnisproblem.

    Weshalb kann ich die property: "align" und die property: "layout" meines Objekts nicht nachträglich setzen/verändern?

    Hier mein Code:

    und so sieht die Fehlermeldung aus:

    Code
    Traceback (most recent call last):
      File "/home/pi/Camera/gui02.py", line 26, in <module>
        main()
      File "/home/pi/Camera/gui02.py", line 19, in main
        item_setup(rahmen1,"red","100","fill","top")
      File "/home/pi/Camera/gui02.py", line 13, in item_setup
        item.align = align
    AttributeError: can't set attribute

    den gleichen Fehler wie hier bei "align" habe ich vorher auch für "layout" bekommen, deshalb habe ich dann "layout" als initial property gesetzt.


    Mach ich was falsch? Die Doku zu guizero listet sowohl align als auch layout als veränderbare properties auf.

    Hallo,

    ich möchte Bilder der PiCam in voller Auflösung speichern. Das klappt auch ohne Probleme in meiner Entwicklungsumgebung mit einer uralten PiCam. Da ich aus technischen Gründen nur ein kleines Vorschaufenster zulassen kann, zeigt mir die Vorschau nur einen zentralen Ausschnitt des Bildes und ist deshalb für eine Vorab-Beurteilung des Bildes eher ungeeignet.

    Code
    with PiCamera() as camera:
        camera.resulution(2592,1944)
        camera.start_preview(fullscreen=False, window=(10,10,800,600))
        ...

    Ich möcht in dem Vorschaufenster aber das ganze Bild sehen, also einschließlich aller Ränder - auch wenn ich dafür eine schlechtere Bildqualität und eine geringe Frame-Rate während der Vorschau in Kauf nehmen muss.

    Später soll eine HQ-Kamera an einem RPi 4 den Job übernehmen und da wäre der Vorschauausschnitt ja noch kleiner.