GUI für nodeMCU

[HaWe]

achso, zur Webseiten-Gestaltung...!
Das klingt super !!

[Moppi]

Zuerst werde ich mich auf Flussdiagramme konzentrieren.
Mal sehen, was da so die Grenzen sind, also inwieweit ich mein bisheriges Diagramm-Modell für das verwenden kann, was ich mir so in etwa vorstelle.
Z.Z. baue ich eine neue Oberfläche.

[Moppi]

Schön, dass ich mit dem Thema schon einmal begonnen habe, dann
kann ich gleich hier anknüpfen, da die Entwicklung nicht stehen
geblieben ist.


Stapelverarbeitung für Arduino und Co.


Man denkt immer wieder einmal über verschiedene Dinge nach.
So kam es gestern, dass ich wieder über die Geschichte mit
einer grafischen Oberfläche für nodeMCU nachgedacht habe.
Ich habe inzwischen damit angefangen - manchem wird es
vielleicht nicht entgangen sein - eine Stapelverarbeitung
für meine ATmega328P-PU, in Verbindung mit einem nodeMCU,
umzusetzen. Weg von der grafischen Oberfläche, die "alles"
möglich macht, hin zu dem, was ich zurzeit benötige.


Ich habe inzwischen einige Codezeilen, auch für nodeMCU ESP-12E,
geschrieben und eigentlich nicht mehr wirklich Lust, jedesmal
von vorn anzufangen, wenn ich nur mal "schnell" etwas
zusammenbauen und ausprobieren will. Also bin ich dazu
übergegangen, die Kontroller nur noch mit einer Firmware zu
versehen und diese zu ändern, sowie neu aufzuspielen, wenn
sich Hardwareschnittstellen ändern.
Meine Vorgehensweise sieht also so aus, dass ich eine
funktionierende Hardware baue, der am Ende nur die Steuerung
fehlt. So habe ich z.B. einen Kontroller für eine Ansteuerung
eines Motors. Hier muss ich softwareseitig so viel programmieren,
dass der Kontroller den Motor in jede Richtung drehen kann,
dass Odometriedaten erfasst werden und rudimentäre Grundfunktionen
(die auf jeden Fall notwendig oder wenigstens sinnvoll sind)
erstellt und auf den Kontroller, als Firmware, übertragen werden.
Dazu kommt noch die Kommunikation mit anderen Kontrollern, in
irgendeiner Form.
Was ich dann noch benötige ist eine simple Stapelverarbeitung. Um
die einzelnen Grundfunktionen des Kontrollers sinnvoll zu nutzen,
sowohl experimentell, als auch endgültig. Dazu gehören auch Befehle,
die nur der Auswertung dienen, so dass z.B. Werte verglichen und
geändert werden können und Befehle, die mit der Außenwelt
des Kontrollers direkt nichts zu tun haben, wie Vergleiche und
Sprungbefehle.


Meine Umsetzung ist nun die, dass jeder Kontroller, der flexibel
programmiert werden muss, diese Stapelverarbeitung in
die Firmware integriert bekommt. Der Mikrokontroller für
eine Motorsteuerung benötigt das nicht. Weil hier die Aufgaben
genau festgelegt sind und diese nicht mehr geändert werden müssen.
Ein übergeordneter Kontroller soll aber damit kommunizieren,
um aus einer einfachen Motoransteuerung eine sinnvolle Fahrt
zu machen, Daten zu sammeln und diese ggf. sichtbar zu machen,
indem die Daten zu einem nodeMCU transferiert und dort, über
WLAN, im Webbrowser sichtbar gemacht werden können. Dieser eine
übergeordnete Kontroller würde die Stapelverarbeitung bekommen
und wäre dann von außen, per WLAN und Webbrowser-Interface,
ansprechbar. Von einfachen Testszenarien, zum Analysieren bestimmter
Werte unter bestimmten Umständen, bis hin zu komplexen Aufgaben,
die auch - durch Ereignisse gesteuert - ausgeführt werden können.
Über die Nutzeroberfläche soll also die Programmierung und
Debugging durchgeführt werden.

Als Schnittstellen zur Übertragung der Programmdaten für
die Stapelverarbeitung habe ich derzeit I2C und serielle
Schnittstelle. Die Software für die Kontroller muss hierfür
angepasst werden.

Wenn alles gut verläuft, kann ich mir vorstellen, später nur
Projekte auf dieser Grundlage umzusetzen. Was dann eben so
aussehen könnte, dass ich Grundfunktionen der Firmware (vor allem
Hardwareschnittstellen) projektbedingt entferne, ändere oder
hinzufüge und diese dann auf den Zielkontroller aufspiele, inkl.
Stapelverarbeitungsmodul.


Also gestern dachte ich darüber nach und kam auf die Idee,
doch schon früher die 1GB-SD-Karte zu nutzen, die ich besitze.
Ich könnte auf dieser SD-Karte sämtliche Dateien für
das Webbrowser-Interface speichern und kann außerdem alle Daten
zu allen Kontrollern, verschiedener Projekte halten. Somit
könnte ich den Datenballast auf einem nodeMCU reduzieren und
dort vor allem nur die Stapelverarbeitungscodes unterbringen, die
auch notwendig sind.

Zurzeit überlege ich mir, wie die grafische Oberfläche gestaltet
sein soll. Hier will ich mir nicht zu viel vornehmen und mich
auf das Nötige beschränken. An dieser Stelle kann es hilfreich
sein, die Meinung und evtl. Vorschläge anderer User zu kennen,
um nicht am Ende irgendwann festzustellen, dass man dies oder
jenes hätte berücksichtigen sollen oder anders machen könnte.
Aus Erfahrung weiß ich, dass sich manche Sachen später nur
schwer ändern lassen.


So weit ...


Freundlichen Gruß!

[Moppi]

Wen der Fortschritt des Projekts interessiert, in meinem Blog berichte ich darüber.
Hier kann man dem folgen: https://www.roboternetz.de/community...eMCU-Webserver

Falls es noch Vorschläge (bezüglich dessen, was man mit der Benutzeroberfläche tun kann / können sollte) oder meinetwegen auch Kritik,
geben sollte, dann bitte gerne hier schreiben!
Ich bin noch nicht sicher, ob ich die Software später mal, zur freien Nutzung, freigeben werde. Das hängt vor allem davon ab,
wie stabil sie in den verschiedenen Browsern ausgeführt wird. Auch Darstellungsprobleme spielen eine Rolle. In der Regel möchte ich
nur äußerlich einwandfreie Sachen weiter geben. Das Feedback dazu spielt am Ende dann auch irgendwo mit in die Entscheidung rein.

MfG
Moppi

[Moppi]

Hallo,


ich kann jetzt mehr zu den Möglichkeiten der Benutzeroberfläche sagen,
nachdem ich einiges für die neue Anwendung exportiert und geändert habe.
Ich habe versucht, das Wirrwarr in meinem Kopf zu ordnen und folgend
3 Absätze daraus erstellt.


1) Zurzeit sieht es so aus, dass die gesamte Funktionalität, auf die der Benutzer
Zugriff hat, überwiegend in programminternen Scripten steckt. Dies betrifft
zum Beispiel das Ordnen von Daten (Neuanlegen, Ändern, Löschen, Wiederherstellen).
Dies zählt zu den Möglichkeiten, welche die Benutzeroberfläche ursprünglich bietet,
in deren Exportierung ich mich noch befinde. Ebenso die Funktionserweiterung über
eine relativ einfache Programmierung. Ich müsste diese entfernen oder für
die normale Nutzung unsichtbar machen.


2) Was ich zunächst angedacht habe, ist die Verwaltung der Stapelverarbeitung,
die ich für Mikrokontroller integriere. Außerdem ist es einfach, über
den Webserver auf einem nodeMCU, an Variablen zu gelangen, die den Betrieb
einer Maschine beeinflussen (Setup-Daten). Über die Benutzeroberfläche
könnten diese ausgelesen, geändert und zurückgeschrieben werden.
Auch Sensor- und sonstige Daten sollen über den Webserver auf dem nodeMCU
abgefragt werden und in der Benutzeroberfläche dargestellt werden können.
Eine Debuggerausgabe für die Stapelverarbeitung der µC soll möglich sein.
Weitere Möglichkeiten sind, durch die freie Programmierung, denkbar.


3) Ein Autostartobjekt will ich dem Nutzer zur Verfügung stellen, um dort eigene
Script-Objekte abzulegen, mit denen die Funktionalität der Oberfläche für
eigene Bedürfnisse erweitert werden kann.
Ein Objekt für Systemskripte, welche die zukünftige Funktionalität abbilden,
also all das, was ich unter Absatz 2 erwähnte.
Beide Objekte sollen ausgeblendet werden. Bei Bedarf könnte man sie sichtbar
machen. Das Systemobjekt könnte auch immer unsichtbar bleiben, so dass der Nutzer
auf die damit verknüpften Scripte keinen unmittelbaren Zugriff hat.


Um die Funktionalität der bisher exportierten Scripte zu sichern, muss ich noch
eine Menge überprüfen, ergänzen und ändern. Das ist noch einiges an Arbeit,
bevor ich mit der zweckbestimmten Programmierung (s. Absatz 2) beginnen kann.


MfG

[Moppi]

Hallo,

Da ich nicht weiß, wie abstrakt und greifbar das alles für Andere ist, folgend eine Übersicht,
was an Möglichkeiten vorhanden ist und was (aus meiner Sicht) beibehalten werden sollte.
Dazu muss man wissen, dass unter der Benutzeroberfläche ein Script-Interpreter sein Werk tut.
Ich hatte dies an anderen Stellen schon angemerkt. Es können vom Benutzer Scripte erstellt werden
(Codezeilen eingefügt werden), um das Verhalten der Oberfläche zu steuern / zu beeinflussen / zu ändern.
Es können damit auch komplexe Programmabläufe erstellt werden.

Hier eine Aufzählung:


- einen Autostart (-Ordner, eigentlich nur ein Objekt), um Benutzer-Script-Code automatisch aufzurufen


- neue Projektumgebungen erstellen, um Projekte zu trennen und die Arbeit mit der Benutzeroberfläche zu beschleunigen


- hinzugügen von Ordnungsobjekten, Subobjekten, Codeobjekten, Textanmerkungen und Vorlagen


- Verwaltung und Erstellen von Ojekten für Templates, in Textform und deren Verarbeitung


- Erstellen von Regel-Clustern, um das Abarbeiten von Bedingungen und bedingungsabhängigen Zuweisungen / Änderungen zu beschleunigen


- Ausgabe (z.B. in Listen und Textfelder) um Information anzuzeigen


- Datenübertragung zwischen Webserver und Benutzeroberfläche


- HTML-Scripte in die Benutzeroberfläche (als Fenster) einbinden / darstellen, für neue Schnittstellen zum Benutzer (Listen, Textfelder, Buttons)


Nun kommt es darauf an, etwas daraus zu machen.
Ich werde natürlich weiter dran arbeiten, auch wenn keine Vorschläge, für oder wider irgendwelcher Sachen, hier eintreffen.


MfG

[inka]

es waren ja keine fragen zur formatierung, nur ein bischen meckern über unangenehme lesbarkeit. Ist ja wieder ok...
das mit der kleinschreibung (nur eigennamen sind gross), da wirst mich nicht mehr ändern können, dafür mache ich das schon viel zu lange

der letzter beitrag sprach von buttons und textfeldern, die individuell anpassbar wären. Ist das für eine bidirektionale kommunikation mit dem roboter nutzbar?

was ich in Deinem ersten bild gut fand - zumindest war es meine annahme - das war die gleichzeitige darstellung eines programmablaufplanes und des programmcodes (wenn ich es richtig verstanden habe?). Wenn sich das auch noch wechselseitig automatisch anpassen würde...

[Moppi]

der letzter beitrag sprach von buttons und textfeldern, die individuell anpassbar wären. Ist das für eine bidirektionale kommunikation mit dem roboter nutzbar?

Ja, zum Beispiel. So wie eigentlich alles an dem Programm darauf abzielt.

darstellung eines programmablaufplanes und des programmcodes (wenn ich es richtig verstanden habe?)

Ein Programmablaufplan hat nicht direkt was mit Code zu tun. Der Teil der Ablaufpläne war eigenständig. Dort habe ich mich darin geübt, wie man so einen PAP umsetzen kann. Weil ich so was spannend finde. Da muss man auch die Verbindungen verfolgen und draus Verknüpfungen zwischen Objekten erstellen. Das funktionierte schon so weit, dass der PAP ausgeführt werden kann (auch mit Unterprogrammen, die verknüpft sind), allein aufgrund der Funktion der einzelnen PAP-Symbole, als eine Art Pseudocode. Auch Verknüpfungsfehler im PAP werden erkannt und aufgezeigt. Du hast angenommen, dass irgendein Programmcode, in C oder JavaScript evtl., raus kommt. Ja eigentlich sollte das so sein, tut es aber bisher noch nicht. Mit so einem PAP kann man auch einfach Programmodule untereinander verbinden.

Angefangen hatte ich damit, PAP-Fenster in die Benutzeroberfläche einzubauen. Ursprünglich wollte ich die Oberfläche nach einer anderen Logik gestalten, als jetzt. Jetzt passt es zurzeit nicht ins Konzept.

Damit man sich die Funktion etwas vorstellen kann und wie alles aufgebaut ist, habe ich hier mal ein Bildausschnitt aus einer anderen Anwendung, weil dort Programmteile enthalten sind, die es jetzt hier noch nicht gibt.

Bild hier  

Die Programmstapel sind hier andere, als ich sie jetzt dann einbaue. UNd es geht nicht um die Steuerung eines Roboters, sondern eines Avatars. Ist aber egal, man kann auch annehmen, der Roboter hieße Lea...
An manchen Begriffen muss man sich nicht stören, ist alles experimentell.


MfG

[HaWe]

soll das so was ähnliches wie Scratch sein? Ich kapier es aber wohl noch nicht, für was das gut sein soll...

[Moppi]

Ich habe etwa 2008 meine ersten Schritte dazu gemacht. Dann hat es mehrere Versionen durchlaufen. Von 2012 bis 2018 habe ich dann dieses System entworfen und umgesetzt. Ich weiß auch nicht, was es ist. Ich wusste auch nie, was irgendwann dabei heraus kommt. Ich hatte mal ein Ziel, Webseiten damit zu erstellen, das dann aber anderen Ideen mehr und mehr gewichen ist, als mir aufgefallen ist, dass ich weit mehr damit machen könnte. Während dieser Zeit habe ich mich abgeschottet, um unbeeinflusst zu sein. Darum weiß nicht, mit was man "es" vergleichen könnte. Es ist auch unheimlich mächtig und komplex, wenn ich bedenke, was man damit alles tun kann. Aber der ganze Funktionsumfang soll hier nicht verwendet werden, eher eine etwas abgespeckte und inhaltlich veränderte Version.

Was man sieht, sind die Ordungsobjekte oder Ordnerobjekte, damit die Informationen etc. irgendwie sortieren kann. Baumstruktur, kennt man. Alles, was darunter steht: links drehen, rechts drehen usw. , sind ausführbare Sachen. Eigentlich ist es ein Multifunktionswerkzeug. Ich habe schon überlegt, ob ich damit nicht auch Hilfeseiten erstelle (an sowas denke ich nicht das erste Mal). Man muss nur den Text entsprechend anlegen.

Ich denke, wenn alles zusammengestellt ist, kann man damit experimentieren. Dafür ist es am Ende jetzt auch gedacht. Wenn man sich damit auseinandersetzt kann man sich nach und nach den vollen Umfang erarbeiten, wenn man es brauchen kann.
Ich schaue mal was Scratch ist....

neee ... hat mit Scratch nichts zu tun, Scratch ist auch unter anderen Gesichtspunkten entwickelt worden.

Man muss betrachten, was ich jetzt brauche. Das ist eine Verwaltungstruktur, wo ich Codebausteine unter einem Dach verwalte, aufbaue, teste und Funktionalität in seiner eigenen Form (als Befehlsstapel) auf einen µC übertragen kann. Außerdem kann ich damit die Kommunikation mit dem Webserver des nodeMCU herstellen. Inwiefern im Detail, das ergibt sich dann demnächst. Heute bin ich so weit gekommen, wie Ausgabebereiche einzufügen, um Daten meines Protype Car II ausgeben zu können. Dann werden wohl die Stapel folgen, die über die Oberfläche aufgebaut werden. Dann sollen die zum nodeMCU übertragen und von dort auch auf die beiden angebundenen ATmega328P verteilt werden. Damit können Aktionen ausgelöst (wie Motor drehen) und Werte ausgelesen werden. Danach könnte man es weiter entwickeln.
Bis jetzt kümmere ich mich noch um die Schnittstellen, z.B. zur Datenausgabe. Es ist noch keine Zeile Code eingeflossen, welche die eigentliche Funktion herstellt. Das werde ich vermutlich alles über genau diese Oberfläche programmieren, jedenfalls will ich mal schauen, ob und wie weit das möglich ist, ich sehe aber keinen Grund, warum nicht. Dann könnte auch jeder alles ändern, oder einfach nur eigene Sachen hinzufügen die er brauchen könnte.

Alles in allem verfolge ich einen modularen Ansatz, auch bei der Hardware, wo eins auf dem andern aufbaut.
Um mal hier im Forum einen Vergleich zu ziehen: Oberallgeier verfolgt auch einen solchen Ansatz, was ich so verfolgt habe. Für viele Funktionen einen eigenen µC, wobei die alle irgendwo zusammenlaufen und verbunden sind. Er schickt dann über die Schnittstellen (meist seriell, wenn ich mich nicht irre - Oberallgeier korrigiere mich!) auch Befehlssequenzen, z.B. um einen Servo zu steuern.