GUI für nodeMCU

[Moppi]

hallo,

also es ist schon alles sehr theoretisch, was du da schreibst...

Ja, ich weiß. ist auch nicht einfach, etwas zu beschreiben, was zurzeit als diffuser Nebel in meinem Hirn herumspukt.

Am Anfang stand eine Idee, eine bestehende Anwendung umzufriemeln.
Habe ich nun gemacht. Wobei ich mir das, was ich jetzt für das Projekt brauche, aus der Anwendung herauspicke, bzw. alle anderen Funktionen entferne.
Was ich belassen will, habe ich oben aufgeführt.

Du hast das alte Bild aus dem ersten Beitrag angeführt. Im Blog habe ich ein aktuelleres Bild gepostet.
Da es auf dem Server vorhanden ist, kann ich es einfach hier nochmal tun:
Bild hier  

Hier kann man schon mehr erahnen und bekommt ein wenig einen Überblick.
"Platformio" kenne ich nicht. Habe ich mal am Rande gelesen, mehr Kontakt dazu hatte ich nicht.

Die Arduino-IDE ist eine Programmierumgebung für C-Quellcode, inkl. Compiler und Tools zum Hochladen auf einen µC.
Das will ich nicht nachbauen, das leistet auch die Benutzeroberfläche bisher nicht. Bisher deshalb, weil selbst das
aber auch möglich wäre - weit entfernt theoretisch machbar. Das ist aber nicht Sinn der Sache.

Bei dem, was ich baue, möchte ich mir etwas Komfort schaffen. So könnte ich Quelltextfragmente (Funktionen)
aus der Arduino-IDE, die ich dort ausprobiert habe, archivieren und mit Attributen versehen. Dazu ein Werkzeug in
Scriptsprache, das aus allen Fragmenten einen kompletten Quelltext erzeugen kann, den ich dann einfach kopieren könnte,
um ihn in der Arduino-IDE einzufügen und dort zu kompilieren. Das ist aber jetzt nicht Hauptaugenmerk. Zuerst möchte
ich komfortabel auf Funktionen, z.B. für das Prototype Car II, zugreifen können. Werte aus dem Gerät sichtbar machen,
wo man sonst zu LEDs oder Displays greifen würde. Ich möchte gerne Zugriff auf die Funktionen des Prototyps haben,
möglichst auf jede Einzelne. Wie programmiert man beispielsweise, dass so ein Gerät geradeaus fährt? - Man schreibt Code,
der die Encoderwerte auswertet, wo Bedingungen im Code programmiert sind, um bestimmte Reaktionen der Software auf
äußere Einflüsse zu erhalten. Dann kompiliert man den Code, lädt ihn auf den µC und probiert alles aus. Diese Hürden kann
ich umgehen, wenn ich über eine Oberfläche direkten Zugriff, auch programmtechnisch habe. Dazu habe ich mir schon
eine Ablaufsteuerung eingebaut, mit der es möglich ist, Funktionen des Gerätes einzeln anzusprechen - ich nenne es
Stapelverarbeitung. Diese Verarbeitungsstapel kann ich in den µC laden, wenn das Gerät in Betrieb ist. Wenn das Gerät
am Anfang einfach nur stillsteht, könnte ich über die Oberfläche schauen, welche Variablen (Werte) und Funktionen,
das Gerät anbietet (Ultraschallmessung Sensor 1 .. Sensor 2... , Motor 1 .. Motor 2 usw.). Dann kann ich über
die Benutzeroberfläche programmieren, den Code in das Gerät laden und ausführen lassen. Sofern es irgendwelche
Mitteilungen über Werte (oder andere Rückmeldungen) geben soll, kann ich die vom Gerät in die Benutzeroberfläche
übertragen und dort darstellen, sowie weiter verarbeiten. Möglich wäre sicher auch, Prorammabläufe nur über
die Oberfläche zu erstellen und dort auszuführen, so dass das Protoype Car II (jetzt als Beispiel) nur ferngesteuert wird,
damit nicht autonom wäre (Benutzeroberfläche geschlossen: Gerät tot).
Die Möglichkeiten, was ginge sind leider sehr vielfältig und zahlreich, so dass man kaum alles beschreiben kann.

Weil Du schriebst: "wenn's denn fertig ist" ...
Die Einzelteile sind im Grunde alle schon fertig, muss nur noch alles sinnvoll miteinander verbinden.
Alles, was ich oben aufführte (7 Punkte) ist fertig, funktioniert also bereits jetzt. Also das Werkzeug ist schon fertig.
Nun muss ich damit die passende Programmierung vornehmen, um das zu umzusetzen, was ich mir (oder andere sich)
vorstelle(n). Und dafür habe ich noch keinen richtigen Plan, was ich alles genau brauchen werde (programmieren muss),
weil ich keine Vorlage dafür habe. Deshalb ist vieles noch theoretisch. Aber noch ein Zeitpunkt, um das was noch folgt,
zu beinflussen, Ideen einzubringen oder Bedenken zu äußern.

Ich habe den Eindruck es wird nicht mehr so lange dauern, dass es "fertig" wird. Dann ist es das allerdings für dieses
Forum "Ideen zu geplanten eigenen Projekten" auch. Später würde ich das woanders fort führen.



MfG

[inka]

ist sehr schwer zu lesen, wenn's so umbrochen ist, wie es jetzt ist. Wie machst du das? Auch bei deinem blog, da vergeht einem die lust das zu lesen...

[Moppi]

Sind die Zeilen jetzt zu kurz?
Vor einiger Zeit hatte jemand dieses Problem, der Lesbarkeit, mit nicht umgebrochenen Zeilen. Ich meine Rabenauge war es. Irgendwann ist mir das auch mal aufgefallen, dass die Zeilen teils sehr lang sind und es dann nicht so gut zu lesen ist. Deshalb breche ich die Zeilen früher um.

Aber das mit der Lesbarkeit ist mit der Groß-/Kleinschreibung auch nicht besser, wenn die weg gelassen wird und alles überwiegend klein geschrieben wird.

Gruß

[inka]

machst du den umbruch manuell? wozu denn das?

[Moppi]

Fragen zur Textformatierung bitte im Forum Offtopic-und-Community-Tratsch stellen!


Ich habe vor, einen Bereich in die Oberfläche einzubauen, der benutzerdefiniert gestaltet werden kann.
Er könnte dann eingeblendet und mit Inhalt (Buttons, Textfelder usw.) gefüllt werden.
Vornehmlich soll das für Buttons gedacht sein, damit eigene Scripte, die über die Oberfläche zusammengestellt wurden, aufgerufen werden können.


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.

[HaWe]

was ist dann daran anders als bei C++ Libs, die ebenfalls Wrapper nutzen für solche komplexe Funktionen wie drehen oder Encoder auslesen etc?

Außerdem ist "GUI" dann auch noch missverständlich - GUI heißt doch nur "Graphical User Interface":

meinst du eine GUI-IDE, mit der man "graphisch programmieren" kann, indem man Widgets auf eine Form zieht (wie bei qt Creator oder Borland Delphi oder C++ Builder)
oder
soll deine GUI eine graphische Schnittstelle für ein fertiges Programm sein, die Messwerte anzeigt (Monitor, Dashboard) und Buttons, mit denen man zusätzlich durch Mausklick Funktionen steuern kann (Remote Control für diverse Aktoren: an, aus, vorwärts, rückwärts, Stopp, Drehen...) ?

Was genau ist bei dir eigentlich "Graphisch"?