Moin, ich habe ein kleines Script das auf Linux 1A und lange läuft, aber auf Windows Dauerhaften Wartecursor hat und abstürzt. Frage erstmal wieso in Linux okay, aber auf Windows nicht? Im Prinzip weiß ich wodran es liegt, das ist eine Endlosschleife serial.readLine mit kurzer Verarbeitung und aktualisierung eines StringVar() als Vermittler zu Tkinter. Ich habe mir jetzt mehrere Tutorials und Beispiele für Threads angeschaut, aber bei den meisten werden Buttons für aktualisierungen etc. verwendet. wundert mich das es kein fertiges Lernbeispiel dazu gibt.
Philipp K. schrieb: > ich habe ein kleines Script das auf Linux 1A und lange läuft, aber auf > Windows Dauerhaften Wartecursor hat und abstürzt. Falls hier jemand mitliest, der theoretisch antworten könnte, hätte dieser es sicher einfacher, könnte er einen Blick auf besagtes Skript werfen, meinst Du nicht?!
M.A. S. schrieb: > meinst Du nicht?! ich meine wer das Problem nicht versteht wird mir zu 99% auch nicht helfen können.. da ich das absolut minimert habe und es dort auch passiert. Minimalversion im Anhang.
Philipp K. schrieb:1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Wenn ser blockierend ist, dann wird root.update_idletasks() niemals ausgeführt. root.mainLoop() wird nie ausgeführt, da die while-Schleife nicht beendet wird. Benutze für ser einen event-Handler, der die Funktion der while-Schleife übernimmt. Der wird immer dann aufgerufen, wenn Daten auf ser anliegen.
Okay danke, dann ist pyserial auf Windows wohl blockierend, die App selber muss auch nur Updaten wenn jede Sekunde etwas serielles ankommt. Auf Linux funktioniert das auch, Windows erkennt das wohl als nicht antwortendes Fenster und will die App schliessen, bzw. Freezt den Prozess.
Gast
#6980802
Philipp K. schrieb: > Okay danke, dann ist pyserial auf Windows wohl blockierend Eigentlich sollte readline() prinzipbedingt blocken, bis ein Newline empfangen wird, sofern Du nicht beim Öffnen des Ports einen Timeout setzt. Philipp K. schrieb: > Auf Linux funktioniert das auch, Windows erkennt das wohl als nicht > antwortendes Fenster und will die App schliessen, bzw. Freezt den > Prozess. Windows mag es nicht, wenn eine GUI-Anwendung keine Window Messages mehr verarbeitet. Deshalb sollte man alles, was länger braucht, in einen separaten Thread packen.
Okay Danke, ich habe es dann mit Threads irgendwie hinbekommen.
Der "Old School" - Weg ohne Threads wäre gewesen, in der mainLoop neben GUI-Events eben auch auf Socket/Serial-Port-Events zu warten&reagieren. in C gäb's dazu "Tcl_CreateFileHandler" im Python sollte das mit tkinter.createfilehandler(ser, tkinter.READABLE, handle_serial_data) umgesetzt sein. https://docs.python.org/3.3/faq/gui.html#can-i-have-tk-events-handled-while-waiting-for-i-o
Εrnst B. schrieb: > in der mainLoop neben GUI-Events eben auch auf Socket/Serial-Port-Events > zu warten&reagieren. Das ist auch ein interessanter Ansatz.
Philipp K. schrieb: > Das ist auch ein interessanter Ansatz. Kann aber gut sein, dass das unter Windows eh nicht geht, unter Unix wird das Serial-Port-File-Handle dann einfach in dasselbe select/poll gepackt wie das X11-Socket. Unter Windows: ?
Εrnst B. schrieb: > Philipp K. schrieb: >> Das ist auch ein interessanter Ansatz. > > Kann aber gut sein, dass das unter Windows eh nicht geht, unter Unix > wird das Serial-Port-File-Handle dann einfach in dasselbe select/poll > gepackt wie das X11-Socket. > Unter Windows: ? Das liegt dann aber am Verhältnis von tkinter(Python) mit Windows. Bei Tcl/Tk unter Windows klappt das nämlich.
Εrnst B. schrieb: > Unter Windows: ? Werden wahrscheinlich File orrientierte Sockets nicht unterstützt da nicht vorhanden.. Vielleicht sieht es irgendwann mit WSL etc. etwas anders aus.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.