Grafisk programmering av Arduino

[Krille Krokodil]

Var "fysiklärare" igår... Varför skrivs det nya fysikböcker när de ser exakt likadana ut som de jag hade på gymnasiet, eller min pappas generation, eller min farfars generation? Där har inte hänt någonting med pedagogiken sedan de gamla grekerna ungefär. Så roligt att nya grepp testas! Men sedan får naturligtvis för- och nackdelar utvärderas grundligt innan man funderar på att inför det i skolor i någon större skala.

Kunde jag lära upp några som aldrig har programmering bara på denna nivån på jobbet så hade vi kunnat spara massor med tid & pengar, de vi köper in på att göra ändringar på vissa system är fan inte mycket skarpare än detta, de behöver stå och kliar sig i håret eller röven ett par timmar innan de kommer på vilken variabel som de ska justera. Ringer man de som är skarpa är de naturligtvis belagda till julen 2018...

[Glenn]

Och apropå lego igen, är inte det där ganska likt språket som medöljde Lego Mindstorms ? ..första versionen då.


Var ett tag sen jag körde det dock.

[ronnylov]

Som LabVIEW-programmerare så upplever jag att grafisk programmering är bra när man ska göra något litet och enkelt. Men det blir snart oöverskådligt när projekten blir större. Misstänker detta lider av samma problem. Men inte desto mindre är det roligt med alternativa sätt att programmera.

[Andax]

Dessa har liknande koncept: http://www.ez-robot.com/
Man kan visst välja på att programmera med block, alt via vanlig kod.

[E Kafeman]

LabView må ha många brister men en styrka är dess överskådligheten vid stora projekt.
Flödesstrukturen kontrolleras genom att dra trådar mellen subrutinerna som kan liknas vid Lego-klossar.

Tror ett vanligt problem i LabView och andra Lego-aktiga miljöer är att man inte planerar programmets struktur så väl som om man skulle göra samma sak i Assembler eller C. Ser allt för mycket spagettikodning i LabView, dvs alla sub-klossar anropas från huvudrutinen, och allt för mycket databearbetning sker sekventiellt i huvudtråden istället för att läggas i sub-block.
Ligger det för mycket funktioner i huvudblocket så byter man överskådligheten mot ett kaos med 100-tals korsande trådar. Det blir extra roligt om man dessutom måste scrolla på skärmen för att kunna avgöra var en tråd slutar/börjar.

Då jag är van att programmera processor-optimerad assembler kändes det mindre optimalt att sprida ut programkod i mängder av underblock när man började med Labview, men Labviews kompilator gör oftast ett väldigt bra jobb med att optimera koden ur processor och tids-optimerad synpunkt, med undantag för viss minneshantering.
Det är lätt att nyttja flerkärniga processorer på ett kontrollerat sätt i LabView, vilket delvis beror på att själva programmerings-strukturen kan delas upp i tydliga understrukturer.
Labview har stöd för flera olika operativ och processormiljöer. Numera även stöd för Arduino, fast det är nog ännu lite beta över själva implementeringen.

Läste att det förslagits i England att barn från 5 år skulle få lära sej programmera i skolan. Det kräver nog miljö typ dra och släppa block med minimala krav på räkne och läskunskaper. Även om det är väldigt förenklad programmering ger det förhoppningsvis en lägre tröskel att senare kiunna gå vidare med text-baserad programmering. Fast det är ju tack vare kraftfulla dator-resurser som grafisk programmering är möjlig och de resurserna ökar varje år. När dessa 5-åringar slutar skolan kanske text-baserad programmering anses som något förlegat som bara gjordes på primitiva fornhistoriska Turing-maskiner. På en framtida kvant-dator har programmering av typen "if_then" troligen ingen direkt funktion.

[Krille Krokodil]

Jag tror textbaserad programmering fortsatt kommer att vara överlägset grundläggande liksom textbaserad information kommer att vara det, finns ingen annan form där man kan utrycka sig lika brett, exakt, koncist, nyansrikt och kreativt, uppfinningen skriftspråk 1000-2000 f. Kr någonting har bara behövt bygga på lite, något större förändring har ju inte skett med den på flera 1000 år nu.

[Nerre]

Men grejen med programmering är ju att den för det mesta måste följa en strikt syntax, annars får man kompileringsfel.

Med "grafisk programmering" så går det inte att bryta mot syntaxen.

Visserligen finns det väl redan idag editorer som mer eller mindre tvingar rätt syntax (eller i alla fall ger stöd så man inte skriver fel).

Ta en sån sak som ett gäng nästlade loopar, med grafisk programmering så går det inte att missa men med skriven kod är det väldigt lätt att göra fel om man inte har bra indentering eller hjälp av en editor som markerar loopen med färgkod eller liknande.

[Krille Krokodil]

Har suttit med ABB:s utvecklingsmiljö i 2 månader nu där man kan arbeta grafiskt eller i kod och synka arbetet fram och tillbaka, där har det gått mot att jag nästan bara vill använda kod. Problemet där är att det är begränsad i en riktningen eftersom att det är väldigt svårt att skapa en grafisk miljö som kan uttrycka allt det man göra i ett språk, det är ungefär som att en målare skulle försöka måla en skriven bok, det är betydligt enklare och snabbare för en författare att beskriva det väsentliga i en tavla. Så det går utmärkt att synka grafik till kod men tvärtom blir där stora luckor vilket i slutändan leder till att det är betydligt enklare att bara jobba i kod och skita i grafiken. Där är en hel del svåra problem att lösa för den grafiska biten...

Men naturligtvis finns där grafiska applikationer som i delar är och kommer att bli (ännu mer) överlägsna kodknackande, ex. högnivåverktygen för FPGA där man lägger till en hel processor, ett grafikkort, en ljudkrets osv genom ett enkelt drag n drop från bibliotek.

[Lennart Aspenryd]

Det grafiska gränssnittet är nog inte tänkt att helt ersätta den skrivna koden.
Men visst finns det en mängd byggdelar som mycket väl skulle kunna lyftas in i ett utvecklingsprojekt.
Tänk bara på husbyggen, det som heter Spjutet här uppe på Fredriksdal. Det lyftes upp i färdiga moduler.
Ett kök är ett kök med dess funktioner, en badrum har ett antal grundläggande saker.
Man byggde en våning i veckan, 14 våningar högt idag.
Att se grundläggande flöden och fasta variabler känns rätt tycker Lasp som också kanske kan bygga själv

Oavsett Os kanske detta är rätt http://haxe.org/

[Nerre]

Har suttit med ABB:s utvecklingsmiljö i 2 månader nu där man kan arbeta grafiskt eller i kod och synka arbetet fram och tillbaka, där har det gått mot att jag nästan bara vill använda kod.

Men det beror kanske på att du är van att skriva kod?

Jag som är van (sen 30 år tillbaka ungefär) att rita med papper, penna och ritapparat har haft jättesvårt att komma igång med CAD, och Sketchup kommer jag inte alls överens med.

Flera gånger när jag har velat få in nåt i CAD så har jag fått skissa med papper och penna först och SEN rita i CAD.

[ronnylov]

Man kan ha färdiga byggmoduler för programmering utan att det måste vara grafiskt.

Jag har inget mot grafisk programmering som sådant (jag är LabVIEW-programmerare på jobbet emellanåt) men för mig har det en förmåga att bli rörigt och svårt att följa programflödet så man får ta till tricks för att styra flödet (jag brukar dra error-tråden genom allting för att få rätt sekvens). För mindre projekt är det underbart men när det växer så blir det lätt spaghetti av alltihopa.

[Krille Krokodil]

Men det beror kanske på att du är van att skriva kod?

Ja, men vi hade först duktiga ingenjörer som försökte med den grafiska miljön och de kom inte så långt, så det är väldigt svårt att göra en grafisk miljö lätt för något komplext, det blir lätt långa vägar man skall klicka sig igenom och alla är inte helt lätta att komma ihåg.

Automator i OSX är en rätt bra pryl där man med drag n drop kan bygga ihop flöden genom olika program a la Unix-pipes.

workflow.png

[Micke_s]

Så länge man lockar in nya att programmera är det bra.
De som fastnar kommer vilja lära sig mer än de grafiska programmeringen i alla fall tror jag.

[hyperion]

Själv började med programmering för ungefär exakt ett år sedan. Valet föll på PIC då jag kände EN person som höll på med elektronik, och han kör PIC.

Vi kör båda ett program som heter Flowcode som görs utav Matrix Multimedia i UK.

Säkert inte det bästa men det har gett oss två ett smidigt verktyg att utgå från och bygga vidare på. Nu kör vi mycket egen C kod i det programmet eftersom alla funktioner och komponenter ej finns (såklart) men vi slipper göra allt "enkelt" i C. Önskar dock att fler börjar använda det då det är lite väl magert på deras forum, och det skulle förhoppningsvis även medföra att de kunde anställa flera personer så att supportfrågor hanteras lite snabbare, men men, jag är nöjd ändå.

[Zkronk]

Är det normalt att bli förvirrad av LabVIEW när man enbart har hållit på med C och PHP innan?