💡 pyMLL für Windows, LINUX und MAC

#576 von EP2Bernie , 02.04.2025 09:46

Hallo Harold,
vielen Dank für deine Mühe.
Sorry, anscheinend habe ich mich doch nicht deutlich genug ausgedrückt.
Auf meiner Anlage funktioniert soweit alles. Lediglich wenn ich das Farbtestprogramm starte, muss sich das Farbtestprogramm mit dem ESP verbinden (unten links die Anzeige dass verbunden).
Mit dem 'LED-Adapter Kanal 2-7' der ESP-Platine kommt keine Verbindung zustande und die Fehlermeldung erscheint. Mit der anderen Adapterplatine des ESP kommt diese Verbindung Farbtestprogramm zu ESP zustande und ich kann z.B. meine Servos einstellen.

Wenn ich das Farbtestprogramm nach der Fehlermeldung schließe, dann ist wohl noch das Programm 'offen', so dass das Excelprogramm nicht mehr reagiert.
Mit dem anderen Adapter kann ich nach Beendigung des Farbtestprogramms wieder alles schalten.

Ich kann also mit dieser Situation gut leben, indem ich den anderen Adapter verwende.
Es sollte nur ein Hinweis, eventuell auch für andere Benutzer sein, falls diese auch so ein Problem haben.
Natürlich kann ich diese Fehlerbeschreibung auch noch in den Hauptthreat übernehmen.

Ich bedanke mich vielmals
Bernd

#577 von GerdR , 06.04.2025 11:22

pyMLL - Python Version der MobaLedLib - hier Version 5.3.5v

Mal ganz bunt durcheinander was mir so aufgefallen ist, bzw, was mir überhaupt nicht gefällt:

1. Programm- und Patterngenerator nutzen nur einen kleinen Teil des Bildschirms, in dieser Version liegt es wohl daran dass das Display angepasst wurde damit es auf einem Laptop mit kleinem Bildschirm läuft (zwecks Vorführung auf der Messe).

Warum hier die TKInter Bibliothek nicht genutzt wird um das Display dynamisch an die verschiedenen Bildschirmgrössen anzupassen, bzw. warum das Display statisch ist und nicht grössenmässig dynamisch verändert werden kann wird Harold @hlinke uns bestimmt erklären können.

So wie es jetzt im Moment ist, kann man nur 8 Zeilen des Prog-Gen Sheets sehen - manchem wird es reichen, aber wenn man ständig ruf und runterscrollen muss ist es schon lästig.

2. Und damit gleich zum nächsten Punkt - kann man nicht auf die "RiesenButtons" verzichten, die zur Zeit etwa 25% der Displayhöhe in Beschlag nehmen (zum Arduino schicken, Zeile einfügen, etc.)
Daß diese Button aus der "Anfangszeit" der MLL stammen ist jedem klar, aber alles ändert sich, auch die Größe und Darstellung von Button. Etwas kleiner und dezenter wäre doch möglich, die Beschriftung kann ja bleiben,aber warum muß eine riesen Grafik dargestellt werden.

3. Was im Moment nirgendwo erklärt ist, bzw.anscheinend noch nicht implementiert ist - was machen die diversen Einstellmöglichkeiten in Programmeinstellungen, bzw dem Config sheet. Bei einigen Sachen habe ich das Gefühl da ändert sich nix, sie haben keinen Einfluss.

Mir ist klar das die Programmiererei an Harold hängen bleiben wird, ich finde es auch fantastisch was er bisher geleistet hat, aber das die PyMLL keine "One Man" Show ist dürfte jedem klar sein, Vlt. findet sich ja ein weiterer Python Programmierei der mit an der MLL arbeiten möchte.

So-jetzt könnt ihr wieder auf mich einschlagen, vor allen Dingen die Leute die noch nie die Python Version gestart haben, sondern nur sehen dass ich etwas zu "meckern" habe -

Zitat "Dann mach es doch besser" Zitat Ende

GerdR

#578 von Eckhart , 06.04.2025 12:38

Hallo Gerd!

Alle deine Kritikpunkte sind berechtigt! (und ich hätte noch zusätzliche dieser Art)

Zitat von GerdR im Beitrag #577
Vlt. findet sich ja ein weiterer Python Programmierer der mit an der MLL arbeiten möchte.

Das alleine wäre unter Umständen nicht mal so sehr das Problem! Python ist heute sozusagen mandatory/verpflichtend zu können, wenn man auch nur ansatzweise in der IT Fuß fassen möchte. Da wird es schon einige geben, die Python können. In meinem beruflichen Fachgebiet sind zwar die Core-Sprachen Assembler, C, C++, C# dominant, aber alle Entwickler schreiben natürlich Service-Code zum Managen von Modulen und Tests in Python. Das sind aber alles Programme, die über die Kommandozeile zu bedienen sind, oder selber wieder eine kleine "Sprache" implementieren, in der man Konfigurationen textuell vornehmen kann.

Zitat von GerdR im Beitrag #577
Warum hier die TKInter Bibliothek nicht genutzt wird um das Display dynamisch an die verschiedenen Bildschirmgrössen anzupassen, bzw. warum das Display statisch ist und nicht grössenmässig dynamisch verändert werden kann

Das ist leider die Crux! ...es geht nämlich gar nicht um "Python können", sondern sich mit GUI Bibliotheken auszukennen (und sich durch den, oft nicht funktionierenden, Schnittstellencode fremder Leute zu quälen) und auch ein Gespür für Anwendungsdesign zu haben. Tja und das würde niemand aus meinem beruflichen Team können, nicht einmal die frischen Mitte 20 jährigen Uniabsolventen... (die haben allerdings auch alle "hardwarenah" studiert)

Wenn ich so sehe, wie grottig viele angeblich "professionellen Webseiten" im Bezug auf "responsive design" aufgestellt sind, wird es richtig schwierig, jemanden zu finden, der das richtig gut kann, was du kritisierst!

Gruß, Eckhart

#579 von hlinke , 06.04.2025 14:44

Zitat von GerdR im Beitrag #577
pyMLL - Python Version der MobaLedLib - hier Version 5.3.5v
1. Programm- und Patterngenerator nutzen nur einen kleinen Teil des Bildschirms, in dieser Version liegt es wohl daran dass das Display angepasst wurde damit es auf einem Laptop mit kleinem Bildschirm läuft (zwecks Vorführung auf der Messe).

Warum hier die TKInter Bibliothek nicht genutzt wird um das Display dynamisch an die verschiedenen Bildschirmgrössen anzupassen, bzw. warum das Display statisch ist und nicht grössenmässig dynamisch verändert werden kann wird Harold @hlinke uns bestimmt erklären können.

So wie es jetzt im Moment ist, kann man nur 8 Zeilen des Prog-Gen Sheets sehen - manchem wird es reichen, aber wenn man ständig ruf und runterscrollen muss ist es schon lästig.

@GerdR
Hallo Gerd
Du rennst mit Deinen Kritikipunkten bei mir offene Türen ein.
Diese Sachen stören mich auch.
Leider hat die TKInter-GUI so ihre Tücken und verhält sich blöderweise auch noch unter Linux und Mac jeweils ein bißchen anders als unter Windows.
Für die Benutzung der pyMLL auf einem kleinen Bildschirm musste ich einige Dinge anpassen.
In meiner Arbeits-Version wird die Größe der Programmgeneratortabelle beim Start an die Größe des Fensters angepasst.
Da die Programmgeneratortabelle Komponenten nutzt, die ich nicht selbst geschrieben habe, ist eine dynamische Anpassung beim Ändern der Fenstergröße leider nicht möglich, bzw ich habe dafür noch keine Lösung gefunden.

Es ist also Besserung in Sicht. Ich möchte diese Version aber erst freigeben, wenn Jürgen siene neue MLL-Version freigegeben hat, da ich dort schon einige Anpassungen für diese neue Version vorgenommen habe.
Du musst also noch etwas warten.

Zitat von GerdR im Beitrag #577

2. Und damit gleich zum nächsten Punkt - kann man nicht auf die "RiesenButtons" verzichten, die zur Zeit etwa 25% der Displayhöhe in Beschlag nehmen (zum Arduino schicken, Zeile einfügen, etc.)
Daß diese Button aus der "Anfangszeit" der MLL stammen ist jedem klar, aber alles ändert sich, auch die Größe und Darstellung von Button. Etwas kleiner und dezenter wäre doch möglich, die Beschriftung kann ja bleiben,aber warum muß eine riesen Grafik dargestellt werden.

Guter Vorschlag. Werde ich in der neuen Version mal umsetzen.

Zitat von GerdR im Beitrag #577

3. Was im Moment nirgendwo erklärt ist, bzw.anscheinend noch nicht implementiert ist - was machen die diversen Einstellmöglichkeiten in Programmeinstellungen, bzw dem Config sheet. Bei einigen Sachen habe ich das Gefühl da ändert sich nix, sie haben keinen Einfluss.

Mir ist klar das die Programmiererei an Harold hängen bleiben wird, ich finde es auch fantastisch was er bisher geleistet hat, aber das die PyMLL keine "One Man" Show ist dürfte jedem klar sein, Vlt. findet sich ja ein weiterer Python Programmierei der mit an der MLL arbeiten möchte.

Da sind eine Menge Einstellungen drin, die ich für mich zum Testen eingebaut hatte und die keine Funktion mehrhaben.
Da muß ich auch mal aufräumen.

Zitat von GerdR im Beitrag #577

So-jetzt könnt ihr wieder auf mich einschlagen, vor allen Dingen die Leute die noch nie die Python Version gestart haben, sondern nur sehen dass ich etwas zu "meckern" habe -

Zitat "Dann mach es doch besser" Zitat Ende

GerdR

Ich sehe Deine Anmerkungen nicht als "meckern", sondern als willkommene Anregungen etwas zu verbessern.

Wenn Du noch weitere Ideen hast, was verbessert werden könnte oder Dich stört, immer her damit. Wir können das Tool nur gemeinsam verbessern.

Viele Grüße
Harold

#580 von oliwel , 06.04.2025 17:44

Hallo,

Blöde Idee...wäre es eine Option UI und Backend zu trennen und das ganze Frontend in einen Webbrowser zu verlagern? WebUI Toolkits haben zwar auch ihre Macken und Tücken aber das würde es auch viel einfacher machen zB mit einem Raspi an den ESP zu gehen und dann einfach vom HeimPC per Browser seine MLL zu konfigurieren....

Oli

#581 von hlinke , 07.04.2025 10:32

Zitat von oliwel im Beitrag #580
Hallo,

Blöde Idee...wäre es eine Option UI und Backend zu trennen und das ganze Frontend in einen Webbrowser zu verlagern? WebUI Toolkits haben zwar auch ihre Macken und Tücken aber das würde es auch viel einfacher machen zB mit einem Raspi an den ESP zu gehen und dann einfach vom HeimPC per Browser seine MLL zu konfigurieren....

Oli

Hallo Oli,

diese blöde Idee hatte ich auch schon.
Würde einiges vereinfachen, würde aber auch ein fast komplettes Neuschreiben der pyMobaLedlIb GUI bedeuten.
Es gibt GUI-Frameworks, mit denen das geht z.B. Remi. Remi hat ähnliche Widgets wie TKinter, aber eben nur ähnlich.
Das wäre eine interessante Herausforderung. Wenn ich mal viel Zeit habe, schaue ich mir das auch mal an.
Kann aber noch etwas dauern ...

Den Zugriff auf den RASPI mache ich mit VNC. Die pymobaledlib läuft auf dem RASPI und mit VNC verbinde ich mich mit einem VNC-Client auf meinen PC. Funktioniert problemlos. Über VNC übertrage ich auch das geänderte Programm. Sonst wären Tests auf dem RASPI immer sehr aufwendig.

Viele Grüße
Harold

#582 von oliwel , 07.04.2025 21:42

Zitat von hlinke im Beitrag #581
Es gibt GUI-Frameworks, mit denen das geht z.B. Remi. Remi hat ähnliche Widgets wie TKinter, aber eben nur ähnlich.

Ich würde eher dazu tendieren eine echte RESTlike API zu bauen und das GUI dann mit einem "echten" Webansatz - Bootstrap mit Angular oder Ember, dann kann man beides getrennt entwickeln und die Arbeit auf mehrere Schultern verteilen - ich weiß nicht wie fest du an den Excel Aufbau gebunden bist durch deine VBA Adaption aber ich finde nicht das wir hier eine 1:1 "Abbildung" brauchen solange die Funktion da ist....würde mich hier auch am API Design und vielleicht sogar am WebUI beteiligen (macht in meiner Firma inzwischen ein anderer Kollege aber ich hab das über 10 Jahre selber gemacht)

#583 von hlinke , 09.04.2025 12:12

Zitat von oliwel im Beitrag #582

Ich würde eher dazu tendieren eine echte RESTlike API zu bauen und das GUI dann mit einem "echten" Webansatz - Bootstrap mit Angular oder Ember, dann kann man beides getrennt entwickeln und die Arbeit auf mehrere Schultern verteilen - ich weiß nicht wie fest du an den Excel Aufbau gebunden bist durch deine VBA Adaption aber ich finde nicht das wir hier eine 1:1 "Abbildung" brauchen solange die Funktion da ist....würde mich hier auch am API Design und vielleicht sogar am WebUI beteiligen (macht in meiner Firma inzwischen ein anderer Kollege aber ich hab das über 10 Jahre selber gemacht)

Hallo Oli,

das würde dann eine komplett neue Software bedeuten, mit einer neuen Benutzeroberfläche. Müsste man mal drüber nachdenken. Besonders wenn man die Entwicklung dann auf mehrere Personen aufteilen könnte.
Ich hatte vor 6 Jahren mit einer anderen nit tabellenbasierten Benutzerschnittstelle angefangen.
Ich habe das nach kurzer Zeit aufgegeben, da ich keine Chance hatte die neuen Funktionen und Fehlerkorrekturen von Hardi und Jürgen nachzuvollziehen.
Solange die Excel-Version der Master ist, sehe ich da größere Schwierigkeiten mitzuhalten.
Ich habe den heutigen Ansatz, die Excel-Benutzerschnittstelle nachzubilden und den VBA-Code, wenn immer möglich 1:1 in Pythoncode umzusetzen, gewählt, da ich so die Anleitungen im Wiki 1:1 auch für die Python-Version gelten und ich relativ einfach die Änderungen, die von Version zu Version in der Excelversion gemacht werden, nachvolziehen und übernehmen kann.
Wir können uns aber gerne mal mit Hardi und Jürgen zusammen setzen, um zu sehen, wie wir langfristig mit der Software weitermachen wollen.

Viele Grüße
Harold

#584 von Eckhart , 09.04.2025 16:32

Hallo Oli, hallo Harold!

Zitat von oliwel im Beitrag #582
Ich würde eher dazu tendieren eine echte RESTlike API zu bauen und das GUI dann mit einem "echten" Webansatz - Bootstrap mit Angular oder Ember, dann kann man beides getrennt entwickeln und die Arbeit auf mehrere Schultern verteilen - ich weiß nicht wie fest du an den Excel Aufbau gebunden bist durch deine VBA Adaption aber ich finde nicht das wir hier eine 1:1 "Abbildung" brauchen solange die Funktion da ist....

Sowas würde ich sehr begrüßen!

Da gäbe es sogar die Perpektive, dass man dieses Konstrukt, dass ein größerer Raspi (mit REST API) den Arduino Code für einen ESP32 xcompilieren muss, komplett weglassen kann und der js Code und REST native auf einem mittelgroßen uC laufen. (mit dem ESP32 und nonDMA-RMT wohl nicht, aber mit einem einem DMA fähigen Raspi Pico 2 W vielleicht schon)

Die Herausforderung dafür wäre die Umsetzung des C-Programmcodes aus LED_AutoProg.h in eine gespeicherte Konfiguration außerhalb eines neucompilierens! Hier könnte man, bei der REST Spezifikation natürlich schon Vorarbeit leisten und ein abstrakteres Modell fahren.

Zitat von hlinke im Beitrag #583
Solange die Excel-Version der Master ist, sehe ich da größere Schwierigkeiten mitzuhalten.
Ich habe den heutigen Ansatz, die Excel-Benutzerschnittstelle nachzubilden und den VBA-Code, wenn immer möglich 1:1 in Pythoncode umzusetzen, gewählt, da ich so die Anleitungen im Wiki 1:1 auch für die Python-Version gelten und ich relativ einfach die Änderungen, die von Version zu Version in der Excelversion gemacht werden, nachvolziehen und übernehmen kann.
Wir können uns aber gerne mal mit Hardi und Jürgen zusammen setzen, um zu sehen, wie wir langfristig mit der Software weitermachen wollen.

Ich weiß nicht, ob mittel- bis langfristig die 100% Orientierung an der Excel MLL "das" Konzept ist?

Sobald man etwas hat, was für den User deutlich smarter erscheint (ohne Installation Browser öffnen und "belebtes Haus" zusammenbauen) darf es auch anfänglich Funktionseinbußen geben! Alles hängt dann an der Smartness des Web-UI!

Gruß, Eckhart

PS: Auch wenn Ember evtl. mehr kann, würde ich Angular als lower hanging fruits bevorzugen, da wir dort vermutlich mehr Chancen haben, noch jemanden in's Boot zu holen.

#585 von hlinke , 10.04.2025 17:48

Hallo Oli, hallo Eckhart,

ich glaube wir kommen jetzt gerade etwas vom Pfad ab.

Was Ihr vorschlagt hört sich nach einer kompletten Neuentwicklung an, die mit der MLL vielleicht noch die Stromnversorgung gemeinsam hat (5V Gleichstrom) ansonsten aber in keinerweise kompatibel zu der heutigen MLL ist.

Die MLL hat fast 10 Jahre von den ersten Ideen, die Hardi hatte, bis zu dem Stand gebraucht, den wir heute haben.

Soviele Zeit habe ich leider nicht mehr.

Ich bevorzuge eine schrittweise Weiterentwicklung,bei der wir die heutigen Anwender mitnehmen können, und die es auch immer wieder ermöglicht, nach einer relative kurzen Entwicklung, Erfolgserlebnisse zu haben.

Viele Grüße
Harold

#586 von Eckhart , 15.04.2025 10:18

Hallo Harold, hallo Oli!

Zitat von hlinke im Beitrag #585
Hallo Oli, hallo Eckhart,

ich glaube wir kommen jetzt gerade etwas vom Pfad ab.

Was Ihr vorschlagt hört sich nach einer kompletten Neuentwicklung an, die mit der MLL vielleicht noch die Stromnversorgung gemeinsam hat (5V Gleichstrom) ansonsten aber in keinerweise kompatibel zu der heutigen MLL ist.

Das Gegenteil ist der Fall!

Tatsächlich hatte ich, als ich vor ungefähr 3 Jahren anfing, mich mit der MLL zu beschäftigen, kurzzeitig die Idee, die Effekte neu zu entwickeln. Das habe ich aber schnell aufgegeben, als ich merkte, dass das nicht mal eben in ein paar Wochen gemacht ist! Insbesondere die Rumprobiererei, ob etwas "gut aussieht" kostet viel Zeit! Daher ist die orginale MLL mit einkompiliert und alle MLL Effekte, die ich noch nicht neu schreiben konnte (und das sind die meisten!) sind in einer Virtualisierung verfügbar. (eigentlich ist alles verfügbar, ich nutze es nur tlw. nicht, weil ich was eigenes, z.B. mein "Feuer", habe)

Nehmen wir mal an, es gäbe so eine MLL Hauptplatine, die die ein Webinterface hat und über dieses HTTP Interface die Konfiguration des MLL-Chunk (die MLL Binärkonfiguration) mit einem "GET" hergeben kann und mit der am eine solche MLL Konfiguration auch wieder mit einem "PUT" auch wieder übernehmen kann. Kein Neukompilieren der Hauptplatinen-Firmware; diese wird nur einmalig auf den uC geschmissen!

@oliwel 's Idee, als Interface für so eine Hauptplatine REST zu verwenden, ist genial, denn sie wäre universell und natürlich wäre eine "weiche Migration" durchaus möglich! Es ist ja durchaus üblich, dass auch ein Python Programm, wie dein pyPG, so ein Backend über REST anspricht! Ein neues Web-basierendes Frontend könnte dazu parallel angefangen werden und würde nur die Funktionen anbieten, wo das alte Konzept (alles "Excel-like" zu machen) nicht mehr opportun ist.

@hlinke, könntest du dir vorstellen, mit dem pyPG eine MLL Hauptplatine über REST anzusprechen? Hast du eigentlich schon mal den Text, den du in MobaLedLib_Configuration als C-Source erzeugst, innerhalb deines Python Programms, in den binären MLL Config[] Chunk übersetzt, der letzten Endes auf einer MLL Hauptplatine als Konfiguration abläuft?

Gruß, Eckhart

PS: haltet euch nicht zurück, alles anzuzweifeln, was so eine neue MLL Hauptplatine dafür können müsste und wie lange es dauern würde, so etwas wirklich zu entwickeln!

#587 von hlinke , 15.04.2025 17:29

@Eckhart , @oliwel

wir können unsere interessante Diskussion im neuen MobaledLib Forum weiterführen.
Ich habe Eure Beiträge in einen neuen Diskussionsfaden "Diskussion Weiterentwicklung der pyMobaLedLib" kopiert.

https://forum.mobaledlib.de/viewtopic.php?t=29

Viele Grüße
Harold

Beiträge:	68
Registriert am:	21.12.2019
Ort:	710xx
Gleise	ROCO 2,5mm
Spurweite	H0
Steuerung	BiDiB Fichtelbahn
Stromart	DC, Digital

Beiträge:	499
Registriert am:	27.02.2020

Beiträge:	1.231
Registriert am:	28.01.2022
Ort:	Exilfriese in Berlin
Gleise	K-Gleis
Spurweite	H0
Steuerung	CS3+
Stromart	AC, Digital

Beiträge:	376
Registriert am:	31.10.2006
Homepage:	Link
Spurweite	H0
Stromart	Digital

Beiträge:	1.000
Registriert am:	23.11.2014
Homepage:	Link
Ort:	Oberbayern
Gleise	Mä K-Gleis
Spurweite	H0
Steuerung	CS3+, MobaLedLib, Selbstbau
Stromart	Digital

RE: Farbtestprogramm mit ESP32

PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

RE: PyMLL - hier Version 5.3.5v

Bitte geben Sie einen Grund für die Verwarnung an