Abstract

Digitale Pixel sind omnipräsent. Unser Smartphone, unser Fernseher, der Monitor, mit dem wir arbeiten, das Display in der Mikrowelle. Uns fällt das gar nicht mehr auf, wie viel wir täglich auf Displays starren. Wissenschaftler stellen sich schon lange die Frage: „Wie viel ist zu viel?“

Doch es gibt Hoffnung. Ein Trend sich anderen visuellen Reizen auszusetzen. Sich die Natur in Form von Zimmerpflanzen in die Wohnung zu holen oder eben sich selbst in die Natur begeben.

Ich habe mir die Frage gestellt, ob und wie man aus Pflanzen Pixel machen kann. Solche, die Information übermitteln können und sich ganz im Sinne von ShyTech auch in eine natürliche Umgebung einfügen können. Das Konzept eines Pflanzen-Billboards ist entstanden. Ein System, das sich mit Hilfe von Sensortechnik und einem Roboter selbst versorgt. Einzelne Pflanzen werden durch Wassermenge und Farbstoff so manipuliert, dass sie ihre Farbe ändern und so Information darstellen können, die vom Menschen vorgegeben werden.

Pixel Plants sind Experimente, das heißt auch, dass es noch kein fertiges Produkt ist. Viel mehr ein Konzept, das weiterentwickelt werden kann.

Filmische Dokumentation des Projekts

Recherche / -ergebnisse

Ich habe Anfangs natürlich recherchiert in welcher Form Pflanzen-Pixel schon existieren, aber auch im weiteren Verlauf des Projekts habe ich immer wieder Recherche betrieben.

State of the Art

Bei meiner ersten Recherche zu Pflanzen-Displays bin ich auf einige schon gängige Anwendungsmöglichkeiten und ganz ähnliche Projekte gestoßen, wie ich mir auch meines vorgestellt hatte.

Ich habe erfahren, dass Pixel-Gärten weit verbreitet sind und diese auch als große Installation und mit integriertem Bewässerungssystem verbaut werden. Allerdings sind sie in den seltensten Fällen tatsächlich dazu bestimmt auch Information darzustellen, sondern sind in Mustern angelegt oder sollen einfach nur eine Alternative zur gängigen Topfzimmerpflanzen geben.

Dann bin ich auf das sehr interessante Projekt MOSS-xels, das an der Keio Universität in Japan entwickelt wurde, gestoßen. Hier wurde mit Hilfe von Wasserzufuhr ausgetrocknetes Moos an bestimmten Stellen wieder Grün. Diesen Ansatzpunkt habe ich herangenommen, um mein eigenes Konzept zu formulieren, das Sensorik und mehr Farbe beinhaltet.

Sensorik

Mein Konzept hat vorausgesetzt, dass ich mich in die Welt der Sensorik einarbeite. Zunächst habe ich mich mit einem einfachem Lichtsensor und dem Arduino Uno auseinandergesetzt und dann mit dem Grove Seeed Smart Plant Care Kit. Daraufhin habe ich eine Mind-Map angelegt, die alle Möglichkeiten zusammenfasst, wie Pflanzen beeinflusst werden können.

Roboter

Um nicht für jeden einzelnen Pixel eines PixelPlant-Beetes ein System aus Sensoren und Pumpen bauen zu müssen, habe ich recherchiert, welche Arten der automatischen Pflanzenversorgung bereits existieren.

Letztendlich hat sich dadurch die Idee entwickelt, meine Beete mit einem kartesischen Roboter zu versorgen.

UX / Userjourney

Da PixelPlants zunächst Experimente sind, gibt es nicht direkt eine User Experience oder User Journey.

Die Zielgruppe meiner Experimente musste ich dennoch bestimmen, da ich zur Dokumentation des Projekts einen Instagram-Account angelegt habe. Dieser Account richtet sich an technik-begeisterte Personen, die bestenfalls schon Berührungspunkte mit Coding, Physical Computing, Arduino, usw. hatten. Sie sollen in meinen Posts Ähnlichkeiten zu ihren eigenen Projekten/Experimenten erkennen können und daraus Inspiration und Motivation ziehen.

Mein Konzept des PixelPlant-Billboards richtet sich zunächst an Personen, die aufgrund ihrer Arbeit viel auf Displays sehen und in Parks Ruhe suchen. Innerhalb Parks muss dennoch Information (Leitsystem, Gebotsschilder, usw.) dargestellt werden. Hier sollen sich PixelPlant-Billboards in das Gesamtbild einfügen. Ich kann mir diese Billboards allerdings auch in ganz anderen Kontexten vorstellen wie auf Firmengeländen, als Werbeträger in der Stadt oder als Installation in öffentlichen Gebäuden.

Skizzen / Entwürfe

Billboard

Zuerst habe ich händisch Skizzen auf Papier angefertig, bin dann aber recht schnell auf Blender umgestiegen, da ich da sehr schnell ein und das selbe Objekt aus verschiedenen Perspektiven rendern konnte, was für mein PixelPlants-Billboard sehr wichtig war. Ich habe immer wieder neue Skizzen angefertigt und das Blender Modell aktualisiert und zum Schluss auch animiert.

Beete

Später habe ich auch kleine Prototypen der Beete entworfen und ein Modell gebaut, um das Stecksystem zu prüfen.

Studien / Prototypen

Pflanzen färben

Eine Studie, die sich durch das ganze Projekt gezogen hat, war das Färben von verschiedenen Pflanzen. Ich habe mit Kapuzinerkresse, diversen Schnittblumen und Moos, sowie mit Wassermalfarbe, Füllertinte und Lebensmittelfarbe experimentiert.

Replicator 1

Da nach Preisrecherchen die spontane Neuanschaffung eines AxiDraw oder anderen Robotern unrealistisch war, habe ich mich entschieden, mit dem zu arbeiten, was schon da ist. Dem Replicator 1 von Makerbot und später auch mit dem uArm. Aber zuerst zum Replicator:

Eigentlich hatte ich vor den 3D-Drucker direkt über Processing mit G-Code anzusteuern. Das hätte den großen Vorteil gehabt, dass der G-Code auf auf Echtzeit-Sensordaten hätte reagieren können. Das hat leider aber mit der Firmware und dem Mainboard nicht funktioniert.

Davon habe ich mich aber erst einmal nicht demotivieren lassen und habe versucht mit dem Replicator einen guten Prototypen zu bauen, auch wenn ich die Reaktion auf Sensoren und die Kommunikation mit einem Pumpensystem zunächst händisch faken musste.

Über Trial-and-Error habe ich die Eckpunkte des Druckbetts ausfindig gemacht und ein Koordinatensystem kalibriert. Den fertigen G-Code habe ich mit der Software RelicatorG ins richtige Dateiformat mit Anfangs- und Endcode schreiben lassen und per SD-Karte ausführen lassen.

uArm Swift Pro

Um doch noch die Möglichkeit zu erproben, einen Roboter direkt per G-Code anzusteuern, habe ich mit dem uArm Swift Pro experimentiert. Schon in früheren Projekten habe ich mit dem Roboterarm gearbeitet und kannte schon seine Tücken. Angefangen habe ich mit einem einfachen Blockly Sketch zur Einarbeitung. Dann bin ich übergegangen, den Arm über den Seriellen Monitor in der ArduinoIDE anzusteuern. Später auch direkt mit Processing. Direkt über den Seriellen Monitor hat alles perfekt funktioniert, im Code gibt es noch Probleme.

Umsetzung

Umgesetzt habe ich jeweils Prototypen, in denen ich meine Experimente zusammengefasst habe. Die Pumpe aus dem Grove Smart Plant Care Kit wird an einen Arduino angeschlossen. Die Pumpe wird händisch per Knopfdruck gesteuert. Die Achsen des Replicators und der Arm des uArms führen dann jeweils den Wasserschlauch zu den Pixeln des selbst gestalteten Moosbeetes und bewässern dieses.

____________________________________

PROJEKTTAGEBUCH

03.05.2020__Erstes Arduino Experiment

05.05.2020__Recherche in Miro

12.05.2020__Bauplan in Miro

Bauplan für einen ersten Pixel-Plants Prototypen. Er dient auch dazu, Stückzahlen und Kosten berechnen zu können.

15.05.2020__FieldKit50 Application

50  Umwelt-Sensorkits werden von FieldKit verlost. Neben einem Wetter-Kit, kann man auch ein Wasser-Kit gewinnen, mit dem sich die Wasserqualität überwachen lässt. Für letzteres habe ich mein Interesse ausgesprochen.

16.05.2020__Elektronik Bestellung

17.05.2020__Blender Modell

Meine Recherchen im Bereich Bewässerungssysteme ergab, dass ich zur optimalen Bewässerung Schlauchpumpen benutzen sollte. Da das Wasser bei dieser Art von Pumpe niemals tatsächlich „durch“ die Pumpe läuft, sondern nur durch Verformung des Schlauches selbst transportiert wird, eignet sie sich perfekt für Wasser, das Farbpigmente enthält. Allerdings ist diese Art von Pumpe auch teurer als eine normale Tauchpumpe aus dem Aquarienbedarf. Eine Pumpe kostet c.a 11€. Da ich vier Behältnisse mit verschiedenen Flüssigkeiten habe (Wasser, +Cyan, +Magenta, +Gelb) würde das sehr teuer werden. Auch ein Klappensystem ist aufwendig und teuer. Weshalb ich eine Lösung mit einem Kartesischen 2-Achs-Roboter ausprobieren möchte. Dafür bräuchte ich drei, maximal vier Schrittmotoren und tatsächlich nur vier Pumpen und hoffentlich keine Ventile. Außerdem hätte das den Vorteil, das die Bewässerung selbst für einen Betrachter spannender und nachvollziehbarer würde.

25.05.2020__Grove Smart Plant Care Kit

Ich habe das Plant Kit aufgebaut und alles nach Anleitung zusammengesteckt und auch direkt mal ausprobiert. Nach ein paar kleinen Fehlerbehebungen hat das Plant Kit funktioniert.

Was ich noch nicht ausprobieren konnte, ist die mitgelieferte Pumpe, da ich noch keinen passenden Wasserschlauch da habe. Sobald dieser da ist, werde ich das Setup vervollständigen.

Außerdem werde ich das System um einen Liquid-Level-Sensor im Wasserbehälter erweitern, um sicherzustellen, dass die Pumpe nicht leer läuft.

26.05.2020__Pflanzenwachstum

Am 6.Mai habe ich zusammen mit Lea für unsere Projekte Kapuzinerkresse und Schleierkraut angesät, um herauszufinden, wie lange diese jeweils zum Wachsen brauchen. Ich habe das Wachstum des Schleierkrauts mit Fotos dokumentiert. Die letzten Fotos sind vom 26.Mai.

Wir haben herausgefunden, dass die Kapuzinerkresse deutlich schneller wächst als das Schleierkraut und zudem nicht ganz so anspruchsvoll in der Anzucht ist.

Sobald die Blüten der Kapuzinerkresse ausgebildet sind, werde ich versuchen diese einzufärben.

01.06.2020__Bewässerungsroboter Recherche

Ich möchte zur Bewässerung meiner Pflanzen einen Roboter verwenden. Dazu musste ich zunächst mal recherchieren, welche Roboter es fertig zu kaufen gibt, aus welchen Hauptbestandteilen sie bestehen, und welche andere Experimente mit Bewässerungsrobotern so zu finden sind.

Ich habe einiges gefunden und muss jetzt entscheiden, welche Roboterarten für mich in Frage kommen würden. Ich tendiere zu einem, der dem Axidraw nachempfunden ist, möchte aber auch noch den uArm erproben.

Der uArm hätte den Vorteil, dass mein „Beet“ wahrscheinlich auch vertikal funktionieren würde.

Bei einem kartesischem Roboter wird die Befestigung vertikal etwas tricky.

Der Drawingbot von EleksMaker wäre eine vergleichsweise günstige Option. Außerdem kann ich mir vorstellen, dass man die mitgelieferten Aluprofile gegen eigene längere Profile einfach austauschen, den Code anpassen kann und dann einen viel größeren Roboter hat.

02.06.2020__Kapuzinerkresse färben

Die Kapuzinerkresse ist endlich so groß geworden, dass wir sie nun umgetopft haben. Da ich etwas ungeduldig bin und nicht warten wollte, bis sie Blüten bekommt, habe ich zwei Pflanzen jetzt schonmal mit pigmentiertem Wasser gegossen.

Eine Pflanze habe ich mit in Wasser gelöster Wasserfarbe (Cyan) und die andere mit in Wasser gelöster Füllertinte (Cyan) gegossen. Ich bin sehr gespannt, ob und wie stark sich die Pflanzen einfärben. Ich hoffe auch, dass sie das ganze Experiment gut überleben.

Als nächstes möchte ich noch eine Pflanze mit Lebensmittelfarbe einfärben. Das sollte hoffentlich auch gut funktionieren, ist aber wahrscheinlich die teuerste Variante.

Außerdem haben wir auch noch 16 weitere Kapuzinersamen gesät.

Links im Wasserglas die Füllertinte.

Rechts im Fläschchen die Wassermalfarbe.

Beide Pflanzen sind (noch) wohlauf und bestens gerüstet für das Experiment (hoffentlich).

09.06.2020__Schnittblumen färben

Meine Experimente Kapuzinerkresse mit roter Füllertinte und roter Wasserfarbe zu färben, haben leider nicht funktioniert.

Also habe ich beschlossen Schnittblumen zu färben. Hierfür habe ich Lebensmittel in Form von Pulver mit Wasser gemischt und die verschiedenen Pflanzen in das gefärbte Wasser gestellt.

Die Stiele der Pflanzen habe ich mit einer Schere schräg angeschnitten, da ich aus mehreren Quellen erfahren habe, dass die Pflanzen so besser Pigmente aufnehmen.

Das Experiment hat auch ganz gut geklappt. Mit Abstand am besten wurden die blauen Farbpigmente aufgenommen. Schon weniger gut die violetten und roten. Und fast garnicht sichtbar die orangen.

Der Schlangenknöterich hat die Farbe besonders gut aufgenommen.

16.06.2020__MakerBot Replicator III Erster Versuch

Ich habe mir für diese Woche den MakerBot Replicator 1 aus dem Lab geholt. Mein erster Versuch mit dem 3D-Drucker bestand darin, ihn mit modifiziertem G Code anzusteuern. Spoiler: Experiment vorerst gescheitert, aber in Überarbeitung.

Zunächst habe ich versucht die richtige Software für den Replicator 1 zu finden. Das wäre eigentlich ReplicatorG. Leider ist mein OS zu aktuell für die Software.

Also habe ich die neue Software von MakerBot heruntergeladen, dort ließ sich auch der Replicator 1 mit zwei Extrudern auswählen.

Ich habe ein Standard .stl von Thingiverse reingeladen und mir einen G Code generieren lassen.

Den Code habe ich dann in Sublime geöffnet und mich eingelesen.

Mit Hilfe von diversen Reference-Websites ließ sich auch die Bedeutung von fast jeder Zeile herausfinden.

- RepRap G code

- Replicat

- Makerbot Wikidot

Was ich bis jetzt nicht herausgefunden habe, ist, wann im G Code die Fans eingeschaltet werden.

Im nächsten Schritt habe ich die Temperaturen der Extruder auf 0°C gestellt und das Modell auf drei Schichten gekürzt.

Als nächstes habe ich den Code auf eine SD-Karte geladen und in den 3D-Drucker gegeben.

Die erste Fehlermeldung: Der 3D-Drucker konnte die SD-Karte nicht lesen.

Nach ein wenig Recherche stellt sich heraus, dass der Replicator nur SD-Karten mit FAT16 Formatierung nimmt. Also nur schnell die Karte formatieren. Schneller gesagt als getan. Letztendlich musste ich einen alten Windows-Laptop von Lea verwenden und die Karte übers Terminal formatieren. Da hat auch geklappt, die Fehlermeldung wird am Replicator nicht mehr angezeigt.

Allerdings erkennt der Drucker keine Dateien auf der Karte. Das kann nun an mehreren Dingen liegen:

1. Sublime gibt kein ordentliches G Code Format aus

2. Im G Code sind Fehler

3. Der ursprüngliche G Code wurde schon mit dem falschen Programm generiert.

Also haben wir jetzt ReplicatorG auf dem Windows Laptop installiert und ich hoffe, dass das dann funktioniert.

23.06.2020__FieldKit 50 Update

Nicht ganz so erfreulich war die Mail von FieldKit, die heute angekommen ist. Leider habe ich keines der 50 Sensor-Kits gewonnen. Das ist aber auch nicht schlimm, da ich es nicht fest mit eingeplant hatte.

Also weiter wie gewohnt.

23.06.2020__Replicator g-Code Update

Fehler gefunden! Der Replicator 1 kann nur per Kabel direkt mit g-Code angesteuert werden. Um von einer SD-Karte aus zu drucken, muss man den modifizierten g-Code nochmals in die ReplicatorG Software laden und ein .x3g File-Format umwandeln lassen. Damit funktioniert es dann einwandfrei.

In der vergangenen Woche habe ich mich damit beschäftigt eine Lösung zu finden, meinen eigenen g-Code für den Replicator 1 zu schreiben. Ein wichtiger erster Schritt hierfür war, herauszufinden, was das jeweilige Minimum und Maximum der Replicator Achsen ist.

Zunächst habe ich mir die x- und y-Achse angesehen. Ich habe einen kleinen Würfel jeweils in die Ecken der Druckplattform gelegt und dann aus dem g-Code die Maximalen Eckpunkte ausgelesen. Das war leichter als gedacht.

30.06.2020__Beete

Für meine Pflanzen brauche ich kleine „Beete“. Hierfür habe ich durchsichtiges Plexiglas bestellt und Dateien zum lasercutten erstellt.

Die Varianten sind 2x3 Spaces (Pixel) oder 3x3 Spaces (Pixel) und eine Variante als ganzes Beet, um darin Experimente mit der Gravur durch einen heißen Extruder zu erproben.

30.06.2020__G-Code in Processing

Nach Vorlage eines Beispiels habe ich einen einfachen Code in Processing geschrieben, der den Extruder des 3D-Drucks nacheinander in die Ecken des Druckbetts schicken soll. Leider habe ich nach einigen Versuchen und mehr Recherche herausfinden müssen, dass das direkte Ansteuern des Replicator 1 mit G-Code gar nicht so einfach ist.

Prinzipiell muss man den G-Code immer vorher in ein x3g-File umwandeln lassen. Man kann das mit der Installation einer anderen Firmware umgehen.

Neben der Standard Replicator 1 Firmware gibt es noch die Alternative Sailfish. Die den 3D-Drucker aber eher hinsichtlich seiner tatsächlichen Druckeigenschaften optimieren soll. Ein Ansteuern über G-Code ist damit trotzdem nicht möglich.

Dann bin ich auf die Marlin Firmware gestoßen, die laut Gesprächen in Foren geeignet wäre, aber das Mainboard des Replicator 1 nicht passend ist.

02.07.2020__uArm III Erster Versuch

Theoretisch wäre also nach meine jetzigen Erkenntnissen ein Versorgungssystem, das auf Sensorwerte reagiert mit dem Replicator 1 realisierbar. Praktisch habe ich im Moment aber nicht das Know-How dafür und befürchte, dass ich mir das in der Kürze der Zeit nicht mehr erlernen werde. Also muss eine Alternative her.

Der uArm, mit dem ich vielleicht von Anfang anhätte arbeiten sollen, mich aber immer zu sehr von der Idee der Zweckentfremdung des 3D-Druckers faszinieren hab lassen.

Der uArm lässt sich mit g-Code direkt ansteuern. Mein erster Versuch war allerdings - ganz einfach - mit Blockly. Da ich in Blockly die Positionen des uArms nicht mal errechnen muss, sondern ihn einfach per Hand bewegen kann und das Programm die aktuellen Koordinaten übernimmt, ging das wirklich fast zu schnell.

Außerdem habe ich herausgefunden, dass sich an den uArm direkt auch Grove Sensoren anschließen lassen. Und die Werte dessen lassen sich auch direkt in Blockly einbinden.

Die Illustration auf dem Papier soll das spätere Beet mit den einzelnen, abgetrennten Spaces darstellen. Ein 2x3 Raster. Der uArm fährt mit dem angebrachten Wasserschlauch von Space zu Space.

04.07.2020__Replicator Gravur

Die Idee mit einem heißem Extruder über ein Beet mit bodendeckenden Pflanzen so zu fahren, dass durch das Austrocknen bestimmter Teile ein Bild entsteht, ist mit im Laufe der letzten Wochen gekommen.

Also habe ich ein stl erstellt das „Pixel Plants“ schreibt. Dieser Schriftzug soll in ein Moosbeet eingraviert werden.

Der erste Test ohne organisches Material hat sehr gut funktioniert. Jetzt gilt es nur noch herauszufinden bei welcher Temperatur und mit welchem Abstand der Extruder über das Moosbeet fahren muss.

06.07.2020__Beet Prototyp

Ich habe einen 1:2 Prototypen meines Beetes mit Pappe nachgebaut und meine Lasercut-Dateien dementsprechend verbessert. Das Plexiglas ist auch schon angekommen.

06.07.2020__uArm mit Arduino

Ziel ist es den uArm über die Arduino Software zu steuern.

Dafür musste ich zunächst die Marlin Firmware auf dem Roboter-Arm installieren. Das hat nach ein paar Anläufen gut geklappt. Ich kann das Programm mit dem uArm verbinden (Arduino Mega Board) und über manuelle Eingabe in den seriellen Monitor steuern.

Was allerdings noch nicht funktioniert ist das Kompilieren und hochladen eines Codes auf das Mega Board. Das liegt daran, dass ich die SwiftPro Library für den uArm bei Arduino nicht hinzufügen kann.

Fehler:

Arduino: 1.8.12 (Mac OS X), Board: „Arduino Mega or Mega 2560, ATmega2560 (Mega 2560)“

Ein Unterordner Ihres Sketchbooks ist keine gültige Bibliothek

Ungültige Bibliothek /Users/nora/Documents/Arduino/libraries/SwiftProForArduino-develop in keine Header-Dateien (.h) in /Users/nora/Documents/Arduino/libraries/SwiftProForArduino-develop gefunden gefunden

Swift Pro for Arduino

Swift Pro Developer Guide

07.07.2020__Code für Replicator

Ich möchte gerne einen gut gefakten Prototypen für den Replicator bauen. Dafür gebe ich einen G-Code an den Replicator, der mit eingebauten Delays die einzelnen Pixel-Beete anfährt und ich dann über das Grove-Kit wiederum die Pumpe steuere. Wahrscheinlich werde ich einfach die Timecodes angleichen müssen, da eine Verbindung beider Systeme im Moment nicht möglich scheint.

Hierfür habe ich mir in Illustrator ein File erstellt, das das Druckbett des Replicators und sein Koordinatensystem simuliert. Hieraus kann ich dann ganz einfach bestimmen, welche Punkte der Extruder anfahren muss.

07.07.2020__Storyboard grob

11.07.2020__Moosbeete bauen

Nachdem ich den Papp-Prototypen für mein Beet gebaut hatte, konnte ich die Beete in Originalgröße lasercutten lassen. Die Einzelteile habe ich mit lichthärtendem Acrylkleber von Modulor geklebt. Die Klebestellen sind nicht perfekt, aber das fällt am Ende nicht mehr so auf.

Sobald die Beete getrocknet waren, habe ich sie auch gleich mit Moos bestückt, das ich schon vor Wochen gesammelt hatte. Zum Glück hat das Moos in der Tupperbox einem Flaschengarten geglichen und sich selbst versorgt.

Da ich die Beete so ästhetisch fand und natürlich auch zu Dokumentationszwecken, habe ich so noch einmal in einer provisorischen Fotobox fotografiert.

12.07.2020__Replicator Prototyp II Part 1

Da sich der Replicator 1 ja nicht direkt per Processing ansteuern lässt, habe ich einen G-Code geschrieben und den dann im richtigen Format (.x3g) auf die SD-Karte geladen.

Das war prinzipiell gar nicht so schwer. Wie oben schon einmal erklärt, habe ich mir einfach in eine Maßgetreue Illustrator Skizze des Moosbeets alle Punkte angezeichnet, zu denen der Extruder des Roboters fahren soll.

Dann noch den Replicator -spezifischen Start- und Endcode in den G-Code einfügen, ein wenig modifizieren und fertig.

Dachte ich zumindest... Eigentlich hat das so erstmal funktioniert, allerdings war das Koordinatensystem nicht so schön mittig, wie ich es mir erhofft hatte. Also habe ich einen ganzen Abend damit verbracht, Möglichkeiten zu suchen und zu erproben, einen Koordinatensystem-Offset zu erstellen. Nach 16 unterschiedlichen G-Code Files und unendlichem Suchen, hat das aber auch funktioniert.

Die Lösung war ein einfacher G92 Befehl und ganz viel Trial and Error.

Einen Wasserschlauch habe ich probehalber schonmal mit Kabelbindern befestigt, um das Koordinatensystem daran anzupassen.

13.07.2020__Replicator Prototyp II Part 2

Der zweite essenzielle Teil meines Replicator Prototyps ist die Wasserpumpe. Um das Ganze zu vereinfachen, habe ich diese mit einem Button ansteuerbar gemacht. Die Pumpe ist jetzt so lange an, wie der Button gedrückt wird. So kann ich die Pumpe zu den im G-Code festgelegten Delay-Zeiten einschalten.

Für den Pumpen-Code habe ich mich an dem Beispiel-Code für das Grove Kit orientiert.

Da man mich am Ende im Video nicht sehen darf, wurde auch noch eine wunderschön improvisierte Button-Kabel-Verlängerung gebaut. Sie ist wunderschön!

Der G-Code ist so geschrieben, dass der zunächst alle Achsen kalibriert werden. Leider lässt sich das nicht mit G-Code Befehlen umgehen, das könnte man höchstens im Source-Code ändern. Also habe ich einen kleinen Workaround in Form eines Delays eingebaut. Nachdem die Achsen Kalibriert sind, habe ich 30 Sekunden Zeit, um das Beet und das Wasserauffangbecken darunter auf die Buildplattform zu stellen. Danach geht der eigentliche Code los.

14.07.20__Dokuvideo III Version 1

16.07.20__Dokuvideo III Version 2

21.07.2020__Dokuvideo III Finale Version