Grafisch Programmieren

[Iangillan]

Hi Leute,

 

Kennt jemand von euch die grafische Sprache Scratch?

http://scratch.mit.edu/

Damit könnte man ohne neues zu erschaffen, direkt grafisch die bricks und deren Sensoren ansteuern.

 

Ian

[FabianB]

Kenne ich. Finde es aber besser, wenn man grafisch programmieren auf Basis häufiger verwendeter Programmiersprachen kann. Mein beliebtes Stichwort "Codegenerierung" usw.

 

 

[M4ST3R]

Naja aber muss man auch den Aufwand dafür betreiben

[FabianB]

Wo du Recht hast, hast du Recht. Ich habe da nochmal drüber nachgedacht. Traurig wäre ich zwar schon, wenn am Ende kein Programm rauskäme, was Java-Code generiert. Aber vielleicht ließe sich das ja noch auf anderem Wege erschaffen, wenn man Scratch schon als Grundlage hat.

Jedenfalls hätte die Geschichte mit Scratch auch noch andere Vorteile.

(Wie immer, ich schau ja immer Richtung Schule :-)):

Scratch wird an vielen Schulen in der Mittelstufe zum allerersten Programmieren eingesetzt. Wäre ja auch toll, wenn man da dann TF benutzen könnte.

 

 

 

[M4ST3R]

So ich hatte nun mal die Zeit mir das Video auf der Seite anzugucken und muss sagen, dass das ne ganz nette Spielerei ist. Besonders dein Aspekt mit der Schule trifft es bei Scratch sicherlich. Allerdings ist in meinen Augen die Oberfläche wirklich was für Schulen. Ich persönlich würde eine etwas weniger verspielte, gut aufgeräumte Oberfläche durchaus vorziehen. Zudem denke ich, dass mit Java eine Programmiersprache vorhanden wäre, die es auf jeden Fall langfristig geben wird und weiter plattformunabhängig ist. Um kleine Spiele und Animationen zu generieren ist Scratch sicherlich ne gute Sache.

Was meint der Rest?

Wer wäre denn bei einem Javaprogramm dabei? Hab bisher erst von einer Person eine "Zusage" erhalten.

Wirkliche Leute die an Alternativen arbeiten wollen hab ich bisher auch noch nicht gehört.

[photron]

Iangillan, ich habe mir gerade mal Scratch angeschaut. So einfach ist die Anbindung zu Tinkerforge dann auch nicht, denke ich. Wie es aussieht kann man nicht so einfach neue Blöcke hinzufügen, ausser man erstellt eine Scratch Modification:

 

http://wiki.scratch.mit.edu/wiki/Scratch_Modification

 

Das ist dann ein eigenständiges Programm das nicht mehr Scratch heißen darf. Das Problem daran ist, dass Scratch in Squeak programmiert ist.

 

Ein einfachere Variante wäre es wohl das Remote Sensors Protocol für Tinkerforge zu implementieren (z.B. in Form eines Proxies zwischen Brick Daemon und Scratch):

 

http://wiki.scratch.mit.edu/wiki/Remote_Sensors_Protocol

 

So weit ich das verstehe könnte man damit die Ausgabewerte der Tinkerforge Sensoren in Scrach per Sensor Block verfügbar machen und in Scratch darauf reagieren. Die Rückrichtung für Aktoren könnte man wohl über Broadcasts bauen.

 

Ob das im Endeffekt ordentlich funktioniert und wie viel Arbeit das ist kann ich gerade nicht einschätzen.

[M4ST3R]

So ich war den Linux Usern ja noch etwas schuldig

www.cyrex-it.de/projekte/Tinkerforge/visuallibrarytest-linux.7z

[Holy]

Mittels LabVIEW könnte die grafische Programmierung folgendermaßen aussehen:

 

 

Das zugehörige GUI sieht dann folgendermaßen aus:

 

 

 

Das ist hierbei die direkte LabVIEW Entwicklungsumgebung. Gerade für die Mindstorms wurde seitens des Herstellers das UI angepasst und eine spezielle kindgerechte Version bereitgestellt.

[Paul]

Coole Sache Wie einfach ist denn die "Kindergerechte" Programmieroberfläche? Könntest du davon auch Screenshots zeigen?

[Holy]

Das sieht dann folgendermaßen aus:

 

 

Gegenüber der normalen Entwicklungsumgebung dann mit erheblich weniger Möglichkeiten. Ist denke ich aber für die Zielgruppe bei den Mindstorms genau richtig.

[M4ST3R]

So ich greif das hier dann noch mal auf.

Am 5-7 September wird ein Netbeans Platform Training in Lingen (EMS) stattfinden.

Als Projekt während des Trainings werden wir eine GUI Version ähnlich der, die ich bereits vorgeschlagen hatte.

Wünsche und Anmerkungen (gerne auch für den Aufbau der Gui) können hier gerne noch geschrieben werden. Bitte bedenkt, dass es nur ein 3 Tages Kurs ist und keine Wunder vollbracht werden können. Im Anhang findet sich noch mal ein Bild mit den ersten Überlegungen. Hinzu kommen natürlich noch Funktionen wie "wenn, etc." damit man auf Events reagieren kann.

 

 

 

[The_Real_Black]

http://www.heise.de/newsticker/meldung/Blockly-Grafische-Programmierung-im-Web-Browser-1616980.html

 

Wir brauchen JS Bindings...

[tefi]

Vielleicht kann ich auch mal ein Beispiel einstreuen...

 

Dienstlich hab ich mit SPS-Programmierung zu tun - nun ja, eher mit Soft-SPSen als Nicht-Echtzeitanwendungen. Wir nutzen zur Steuerung ein Tool, mit dem graphisch programmiert werden kann. Unterteilt ist dieses Tool in eine Entwicklungsumgebung (graphische Programmierung und Drag'n'Drop-GUI-Editor) und der Runtime.

 

Das Tool bietet eine Grundfunktionalität in Form von verwendbaren Objekten (z.B. Formelobjekte; Wertfilterung, -begrenzung, -skalierung; Flipflops; Flankendetektion; SQL; Profibus; TCP/IP; Logikgatter; Mittelwertbildung; Multiplexer; Trenddiagramm; etc etc etc). Wem das nicht ausreicht, kann eigene Objekte programmieren (C++ oder C#), die dann in der Entwicklungsumgebung eingebunden und für die graphische Programmierung verwendet werden können. Beispielhaft habe ich äußerst rudimentär eine Anbindung für ein Temperatur- und AmbientLight-Bricklet programmiert.

 

Nachteilig an dieser Lösung ist die fehlende Code-Generierung (und die Runtime-Abhängigkeit).

 

Anbei 2 Screenshot einer minimalen Beispielanwendung.

 

dev.png: Temperature und Illuminance der beiden Bricklets werden periodisch ausgelesen. Illuminance geht direkt auf's Diagramm (Trend). Die Temperatur geht einerseits auch direkt auf's Diagramm (wird aber nicht angezeigt), zum anderen werden die Temperaturen mit einem Block-Median und anschließender Blockmittelwertbildung ordentlich glattgebügelt dargestellt.

 

run.png: laufendes Programm mit der Darstellung der Temperatur und Umgebungshelligkeit in meinem Büro (linke Temperaturskala ist abgeschnitten)...

 

Lange Rede, kurzes Fazit: Für's Rapid Prototyping ist das genial - für eine autarke Lösung (embedded pc ö.ä.) ist es jedoch nicht geeignet... Vielleicht kann das ja als Anregung dienen.