Mehr Farben mit dem Ormerod

Diamond Hotend, Alu X-Ausleger
und Alu Druckbetthalter

Der Ormerod stand seit meinem Umzug eigentlich nur unbrauchbar in der Ecke. Die Geometrie einiger Kunststoffteile hat die hohen Temperaturen in diesem Sommer nicht unbeschadet überstanden. Die letzten zwei Tage sind die Problemchen behoben worden und der Drucker ist wieder fit. Außerdem hat er ein kleines Upgrade spendiert bekommen. Dabei ist nicht nur die Firmware auf den aktuellen Stand gebracht worden, sondern auch die Hardware von Grund auf erneuert worden.

Bei 40° im Schatten sind PLA
Teile nicht sonderlich stabil

Die Tr 10×2 Gewindespindel ist schon seit einer Weile verbaut. Dazu habe ich die Spindel erhitzt und in das Standard Zahnrad der 5mm Achse geschmolzen. Dabei habe ich darauf geachtet, dass alles noch rotationssymetrisch geblieben ist. Die Trapezgewindemutter habe ich dann anstelle der originalen Halterung am Auslegerarm befestigt und die Mutter darin festgeklebt.

Ein Anbieter in England bietet für den Ormerod den X-Ausleger und den Druckbetthalter in Aluminium Ausführung. Beides zusammen ist für 100€ zu haben und eine wertvolle Erweiterung für den Drucker.

Zwei von drei Extrudern am Werk

Das Diamond Hotend ist eine geniale Entwicklung für den Druck mit mehreren Farben. Bei einem Druck mit mehreren Extruderdüsen ist es immer schwierig die nicht aktiven Düsen davon abzuhalten zu tropfen. Weiterhin sind die Düsen meistens auf der gleichen Höhe wie die gerade aktive und kratzen somit über die aktuell gedruckte Oberfläche. Das Diamond Hotend löst dieses Problem, indem die maximal drei Filamente über eine gemeinsame Düse gedruckt werden. Alle drei Fäden werden über separate Heatbreaks in eine zentrales Hotend geführt. Das klingt erst mal nicht ganz so einfach und auf den ersten Blick ist der Druckkopf sehr groß und schwer. Auf den zweiten Blick ist das weiterhin so, doch das Potenzial mit bis zu drei verschiedenen Farben drucken zu können ist die Mühe wert, die es kostet den Drucker umzubauen.

Mit dem G-Code Befehl M570 kann der Timeout für das Hotend hochgesetzt werden. Denn das ist jetzt wesentlich größer als vorher und somit braucht es länger um heiß zu werden.

M570 S300 ; Max. 300 Sekunden Aufheizzeit, sonst Heizerfehler

Leider sind hier nur drei verschiedene Farben aus dem gleichen Material möglich zu drucken und nur sehr schwer verschiedene Materialien, da alle Filamente mit der gleichen, oder ähnlichen Temperatur gedruckt werden müssen. Wie genau die Reinigung der gemeinsamen Düsenkammer funktioniert ist noch zu zeigen. Im Moment sieht es so aus als würden innerhalb weniger Zentimeter das alte Filament komplett mit der neuen Farbe ersetzt. Wie sich das mit deutlichen Farbunterschieden bemerkbar macht ist auch noch zu beurteilen.

Dank dc42’s RepRapFirmware Fork ist das Anlegen von mehreren Werkzeugen mit unterschiedlichen Extrudern, aber gleichem Heizer sehr einfach. In der Konfigurationsdatei kann ein Werkzeug einfach hinzugefügt werden.
M563 P0 D0 H1     ; Werkzeug T0 mit Motor 0 nach X, Y, Z, mit Heizer 1
G10 P0 S200 R100  ; 200° Aktiv, 100° Standby
M563 P1 D1 H1     ; Werkzeug T1 mit Motor 1, mit Heizer 1
G10 P1 S200 R100  ; 200° Aktiv, 100° Standby
M563 P2 D2 H1     ; Werkzeug T2 mit Motor 2, mit Heizer 1
G10 P2 S200 R100  ; 200° Aktiv, 100° Standby
M563 P3 D0:1:2 H1 ; Werkzeug T3 mit Motor 0,1,2, mit Heizer 1
G10 P3 S200 R100  ; 200° Aktiv, 100° Standby
M92 E210:210:210  ; 210 Steps pro mm für beide Extruder Motoren 
Ebenso können verschiedene Extruder teilweise zur Mischung von Materialen angesteuert werden. Dafür kann in der Software ein Werkzeug mit mehreren Extruder Motoren angelegt werden. die Mischverhältnisse werden Prozentual angegeben. 
M567 P3 E0.2:0.6:0.2 ; Mische 20% E0, 60% E1 und 20% E2 für Tool 3
Wie das mit dem Diamond Hotend zusammenarbeitet, wird sich zeigen.

Ein Blick auf: BLE – Bluetooth Low Energy

BLE, Bluetooth Low Energy, oder Bluetooth Smart ist ein und das selbe und in aller Munde. Jedes modernere Smartphone hat zumindest Bluetooth 4.0 implementiert und könnte somit theoretisch mit einem BLE Gerät kommunizieren. Als Entwickler befinde ich mich gerade in der Situation, dass eine in die Tage gekommene Funkstrecke mit einem moderneren, energiesparenden Verfahren ersetzt wird. Also warum nicht mit BLE?

Das Protokoll, dass von der Bluetooth Special Interest Group als Bluetooth 4.0 definiert und später mit 4.1 aktualisiert wurde ist modular aufgebaut. Ein Hersteller eines BLE Peripherie Gerätes kann das Gerät so aufbauen, dass es für den Host (Mobiltelefon oder PC/Laptop) selbsterklärend ist, welche Daten es zur Verfügung stellt. Dazu werden im Protokoll Stack verschiedene Client/Server Strukturen angeboten. Somit ist es möglich ohne spezielle Software auf der Host-Seite ein BLE Peripherie Gerät zu verwenden. Dabei hat man sich auf eineige Profile geeinigt, die von der Bluetoth SIG veröffentlicht und betreut werden.

Da mein aktuelles Projekt nicht in sehr hoher Stückzahl produziert werden wird (< 10000 / a) lohnt es sich nicht die RF-Hardware selbst zu implementieren und zu zertifizieren. Für diesen Zweck eignet sich ein Modul, dass bereits alle Zertifizierungen im RF-Bereich mitbringt. Die Auswahl an marktreifen Modulen von diversen Anbietern ist groß und viele weitere sind angekündigt. Daher habe ich mich auf eine kleine Auswahl beschränkt.

HerstellerChipsatzProzessorCompilerDebugger
RFduinonRF51822Cortex-M0Arduino IDE/ Keil µVisionSegger J-Link
Laird BL600nRF51822Cortex-M0SmartBASICSmartBASIC / Segger J-Link
LSR SaBLE-xCC2640Cortex-M3Code Composer Studio / IAR WorkbenchSegger J-Link / TI XDS100v3
Panasonic PAN1740DA14580Cortex-M0Keil µVisionSegger J-Link
Cypress EZ-BLE PRoC ModulePRoC BLECortey-M0PSoC CreatorPSoC MiniProg3

Jedes dieser Module habe ich auf meinem Tisch liegen, oder mir näher anschauen können. Jedes Modul hat seine Vor- und Nachteile und spezielle Anwendungsgebiete.

Beginnen wir mit dem RFduino. Wie man an dem Namen schon erahnen kann, ist das Modul im Arduino-Universum angesiedelt. Es kommt mit einem Plugin für die Arduino-IDE und ermöglicht mit einer Bibliothek des einfachen Einstieg in die Entwicklung von BLE-Geräten. Die Einfachheit der Umgebung ist gleichzeitig auch das große Manko dieses Moduls. Wenn die Arduino IDE als Entwicklungunsumgebung verwendet wird, ist man auf die in der Bibliothek vorgegebene Funktionalität beschränkt. Vom ordentlichen Debuggen ganz zu schweigen. Mehr als ein printf() kann man dem Chip dann nicht abverlangen. Wenn jedoch der Arduino Bootloader mit einem J-Link überschrieben wird, kann man den Chip auf dem Board in vollem Umfang programmieren. Dann nicht mehr in der Arduino IDE sondern zum Beispiel in µVision und dem SDK von Nordic. Dass der RFduino allerdings in einigen Jahren noch lieferbar ist, ist zweifelhaft.

Das BL600 von Laird kommt mit einem etwas ungewöhnlichen Aufzug daher. Es wird nicht wie üblich cross-compiliert, sondern dem Modul wohnt ein BASIC Interpreter inne, der Skripte entweder zur Laufzeit, oder vorab als Bytecode interpretiert. Die Skripte werden in einem Teil des Flash-Speichers abgelegt und von dort dann auch Aufgerufen. Die Debug-Möglichkeiten halten sich hier auch begrenzt an ein printf(). Das Ausweichen auf eine richtige IDE mit SDK ist von Laird wohl nicht vorgesehen. Dafür ist der Einstieg mit der BASIC Programmiersprache wesentlich einfacher als bei den anderen Modulen. Die werden in C oder C++ programmiert und haben ein teilweise Echtzeit OS. All das bleibt dem BASIC Anwender verborgen.

Eines meiner favorisierten Lösungen ist das SaBLE-x von LSR. Das Modul bringt den Texas Instruments CC2540 mit, der der neueste BLE Chip von Texas ist und erst seit einigen Monaten auf dem Markt. Zusammen mit dem Fundus an Beispielen und Applikationen auf der Webseite von Texas Instruments, der kostenlosen IDE Code Composer Studio und dem XDS100v3 auf dem Evalboard steht einer erfolgreichen Entwicklung nichts im Weg.

Eines meiner favorisierten Lösungen ist das SaBLE-x von LSR. Das Modul bringt den Texas Instruments CC2540 mit, der der neueste BLE Chip von Texas ist und erst seit einigen Monaten auf dem Markt. Zusammen mit dem Fundus an Beispielen und Applikationen auf der Webseite von Texas Instruments, der kostenlosen IDE Code Composer Studio und dem XDS100v3 auf dem Evalboard steht einer erfolgreichen Entwicklung nichts im Weg.

SaBLE-x mit dem CC2640 auf einem kleinen Prototyp-Board

Das PAN1740 war eines der ersten Module, die ich getestet habe. Es hat im Gegensatz zu den anderen hier aufgezeigten Chipsätzen einen Dialog DA14580 an Board. Dieser besitzt kein Flash Speicher, sondern lediglich ein OTP ROM. Das bedeutet, dass jedesmal, wenn ein Update der Firmware gemacht werden soll das ROM weiter beschrieben wird, bis kein Platz mehr drauf ist und der Chip unbrauchbar. Während der Entwicklungsphase wird der Code im RAM getestet. Das Problem dabei ist, dass das Gerät nicht mit Batterie getestet werden kann, da bei einem Batteriewechsel der Code aus dem RAM verschwindet. Es fällt somit leider für meine Zwecke as.

Ein weiterer Favorit ist das PRoc von Cypress. PRoC steht für Programmel Radio on Chip und ist mit der PSoC (Programmable System on Chip) Familie von Cypress verbunden. Die Entwicklungsumgebung von Cypress, das PSoC Creator, ist eine hervorragende kleine IDE mit Code Generator, Compiler, Debugger und Online Hilfe.

BLE Grundlagen

Die obige Abbildung zeigt die Grundstruktur eines BLE Geräts. Jedes Gerät besitzt mindestens ein Profil. Dieses beinhaltet dann mindestens einen Service (GAP) und diese enthalten Charakteristiken, die Daten des Geräts. Schon zu Beginn wird klar, um BLE zu verstehen und zu Verwenden, müssen einige Begriffe geklärt werden. Es gibt bereits eineige umfangreiche Literatur [1] und viele Webseiten [2], die einen Einblick in BLE geben, daher hier nur das nötigste.

GAP, GATT

Das Generic Access Protocol (GAP) koordiniert das Advertising und die Datenübertragung, wenn keine Verbindung (Bonding) zwischen den Geräten besteht. Weiterhin leitet es bei Bedarf die Verbindung ein, kümmert sich um Authentifizierung und Verschlüsselung der Verbindung. Das Generic Attribution Profile (GATT) ist das Herzstück des Protokolls und kümmert sich um die einzelnen Charakteristiken und wie deren Daten übertragen werden. Es greift, sobald ein Bondig besteht und transferiert aus Charakteristiken und Descriptoren Daten anhand der UUID oder des Handles.  Um den Kommunikationsfluss zwischen Device (Peripheral) und Basis (Central) zu steuern wird der CCCS eingesetzt. Der Client Configuration Characteristic Server. Dieser ist eine GATT Characteristic, die angibt, welche Daten veränderlich sind, ob und wann geschrieben, oder gelesen werden darf, oder ob eine Notification stattfindet, sobald der Wert sich geändert hat. All das sieht auf den ersten Blick sehr komplex aus und alles Andere als Energiesparend. Allerdings kommt hier zu Gute, dass die Kommunikation über BLE ein verbindungsloses Verfahren ist, das bedeutet, dass der ganze Aufwand nur einmalig getrieben wird um eine Verbindung mit Verschlüsselung zu erzeugen und das Gerät kennen zu lernen. Wenn auf beiden Seiten dieses Bonding eingeleitet wurde, kann die Verbindung anhand der ausgehandelten Verbindungsparametern weitergeführt werden. Dieser Teil ist dann erstaunlich energiesparend. Eine Funkstrecke funktioniert nur dann, wenn auf beiden Seiten das Radio eingeschaltet ist. Der Empfänger kann nur dann die Daten empfangen, wenn der Empfangsverstärker eingeschaltet ist. Ebenso kann der Sender nur senden, wenn der Sendeversteärker eingeschaltet ist. Ein Mitteilen, dass eine Sendung folgt muss über die Funkstrecke geschehen und so ist es schwierig eine energiesparende Konfiguration zu wählen, wenn der stromhungigste Teil der Schaltung immer aktiv ist. Daher hadelt das BLE-Protokoll zu Beginn einer Verbindung eine Wiederaufnahmezeit aus, nach der sich das Central wieder bei dem Peripheral meldet. Zu diesem Zeitpunkt muss das Peripheral dann sein Radio eingeschaltet haben um auf Anfragen des Centrals am GATT Server zu hören. Das ganze klingt relativ komplex, wenn man aber einmal die grundlgende Struktur verstanden hat stellt sich BLE als simples Protokoll heraus, das darauf ausgelegt ist, möglichst wenig Daten in sehr kurzer Zeit über die Funkstrecke zu senden und dann den größten Teil der Existenz im Tiefschlaf zu verbringen.

Zwei Übertragungsarten

BLE besitzt im Grund zwei Arten der Datenübertragung. Eine unidirektionale, verbindungslose Übertragung von kleinen Datenmengen. Diese Werden in einem so genannten Advertisement Paket verschickt. Dieses Paket besitzt eine Länge von maximal 32 byte und überträgt eine festlegbare Payload. Diese beinhaltet zum Beispiel den Namen des Gerätes, die ID, oder um weche Art es sich handelt. Erzeugt und gehandhabt wird das Paket vom GAP Server. Hier wird dem Zuhörer mitgeteilt, welche Möglichkeitem für eine weitergehende Verbindung bestehen. Verbindungslos bedeutet aber auch, dass die 32 Byte ausgesendet werden, wenn gerade niemand zuhört. Somit besteht für das Peripheral keine Möglichkeit zu erkennen, ob die Daten empfangen wurden. Der Rückkanal ist normalerweise für eine gebondete Verbindung vorgesehen. Dennoch wurde im GAP eine Möglichkeit geschaffen, eine Empfangsbestätigung zu simulieren. Das Peripheral sendet ein Advertisement Paket mit Scanable Flag aus und wartet dann für kurze Zeit auf einen Scan Request.

Beim aktiven Scanen wird vom Central eine Scan Request abgeschickt, auf den
das Peripheral mit einer Scan Response antwortet.

Sobald ein Central ein Advertisement Paket mit diesm Flag empfängt, kann es diesen Scan Request abschicken und dem Peripheral so einerseits mitteilen, dass das Paket empfangen wurde, andererseits auch noch weitere Daten gewünscht sind. Der Scan Request selsbt kann keine Payload übertragen. Für eine echte Bidirektionale Verbindung muss dann auf eine GATT Verbindung mit Bonding zurück gegriffen werden. Soweit erst einmal zu BLE. Der zweite Teil folgt dann in Kürze und wird den GATT-Server sowie eineige Profile näher betrachten.

[1] Townsend, Getting Started with Bluetooth Low Energy: Tools and Techniques for Low-Power Networking (2014) http://www.amazon.de/gp/product/B00K1N23LA [2] Ti.com,TI Bluetooth Smart tutorial – How to get started part 1 (2013) https://training.ti.com/ti-bluetooth-smart-tutorial-how-get-started-part-1

Abschaffung von Bargeld

Heute mal etwas nicht so technisches. Ich habe gerade einen Artikel im Stern zum Thema Bargeld gelesen. Darin ging es um Gründe, weshalb wir weiterhin Bargeld brauchen. Ich bin mir nicht sicher, ob diese Gründe ernst gemeint sind, denn sie sind alles andere als stichhaltig.

Der erste Grund ist gleich der für mich gewichtigste. Kein Geld mehr von der Oma. Dass ohne Bargeld das Zustecken von kleinen Geldgeschenken nicht mehr möglich ist, ist schade, dennoch gibt es auch hierfür Alternativen. Zum Beispiel eine Prepaid Kreditkarte, Guthabenkarten, oder ähnliches. Der zweite Punkt ist auch wieder ein alltägliches und weit verbreitetes Anwendungsgebiet von Bargeld. Der Flohmarkt. Wobei auch hier auf alternative Bezahlmöglichkeiten ausgewichen werden kann, sollte es zu einer Abschaffung von Bargeld kommen. Ich denke hier an Systeme, die mit dem Mobiltelefon funktionieren und den Geldtransfer übernehmen. Ein Feilschen mit dem letzten 5€ Schein, ist dann natürlich nicht mehr so einfach möglich, aber es wird sich sicherlich eine andere Möglichkeit finden für innovative Bezahlmethoden.

Der dritte Punkt, das Sparschwein, ist auch ohne Probleme digitalisierbar. Wieso sollte nicht ein Sparschwein mit Digitalanzeige funktionieren? Der Betrag auf dem Sparschwein wird über die Cloud mit einem Verrechnugnskonto abgeglichen. Immerhin ist es nur eine Frage der Zeit, bis Münzen im Geldbeutel zu Last fallen und dann nur alle paar Monate aus dem Sammelbehälter zur Bank gebracht werden. Das ist lästig, denn die Filialen haben immer nur dann offen, wenn ich arbeiten bin.
Dass Kinder den richtigen Umgang mit Geld lernen müssen ist klar, doch auch jetzt schon ist Geld nicht mehr das in der Hand haltbare Zahlungsmittel, sondern ein viel abstrakteres Modell. Für die Erziehung kann also auf eventuelle Ersatzmittel zurück gegriffen werden und später auf die Realität. Geld ist nur noch virtuell vorhanden und das sollten Kinder durchaus lernen.

Das nächste schwerwiegende Argument ist die Zahnfee. Wie soll die denn das nächste mal für den Zahn bezahlen? Vielleicht mit etwas Anderm als Geld. Das schafft ja auch der Osterhase und der Weihnachtsmann. Teilweise.

Argument fünf zählt nicht. Im Land des Trinkgeldes wird überwiegend mit Kreditkerte bezahlt und das funktioneirt hervorragend. Ich habe es selbst schon ausprobiert. Klar muss ein Umdenken stattfinden, aber dass muss es ständig. Anders werden wir mit unserer Gesellschaft nicht vorran kommen.

Das sechste Argument kann mit dem Fünften in Verbindung gebracht werden. Das Zahlen von Kleinstbeträgen mit der Kreditkarte ist ohne PIN möglich. Um das Argument des Sterns weiter auszubreiten wären hier noch zu nenen: Parkuhren, Kaugummiautomaten, Fahrscheinautomaten,. Zeitungskiste, das Kiosk von Nebenan usw. Für alle diese kleinen Transaktionen gibt es bereits Alternativen. So gibt es zum Beispiel Systeme wie das DipJar, dort können Trinkgelder einfach mit der Kreditkarte bezahlt werden. Karte rein und fertig. Es gibt auch schon Automaten im Parkhaus zum Beispiel. Die akzeptieren eine EC-Karte. Alternativen werden sicher auch auf dem deutschen Markt erscheinen, sobald es sich abzeichnet, dass Deutschland in eine neue Ära der Bezahlung geht.

Das letzte Argument werde ich einfach ignorieren, denn das ist wozu man Bargeld wirklich braucht. Alternativ kann man natürlich auf eine der vielen Kryptowährungen ausweichen. Die sind dann sogar noch schwerer zu verfolgen.

Ich bin generell der Meinung man sollte Bargeld nur noch als Alternative betrachten und nicht als alleiniges oder Hauptzahlungsmittel. Wir leben in einer Zeit, in der Bargeld nur noch einen virtuellen Wert wiederspiegelt und somit keinen echten Wert mehr besitzt. Das haben wir die letzten Jahre gelernt, als wir die Kursschwankungen des Euros erleben durften. Dieser Zwischenschritt zwischen dem Münzwert und dem Geldwert ist nötig, aber ich denke wir sind bereit uns langsam davon zu verabschieden. Zumindes könnten wir mit Münzen anfangen. Lästiges Kleingeld.

ESP8266 – 2: Ferngesteuerte Steckdose

Ein anständiger Name für eine Steckdose

Nachdem der Fenstersensor so weit funktioniert benötigen wir noch einen Aktor, der anhand des Signals sinnvolle Aufgaben erledigen kann. Wie zum Beispiel die Abzugshaube abschalten, wenn das Fenster geschlossen wird. Das ist ziemlich praktisch, wenn man nicht möchte, dass die Abzugshaube Luft durch den Kamin zieht. Daher die Regel, wenn das Fenster in der Küche offen ist, kann man die Abzugshaube einschalten, wenn nicht, dann nicht. Herzstück der Steckdose wird wieder ein ESP8266 Modul sein. Zusätzlich ein AC/DC Converter, der aus der Netzspannung eine akzeptable 5V macht. diese wird über einen LDO auf 3,3V für den Controller heruntergeregelt. Das Relais, dass die Phase schaltet wird aus den 5V versorgt und über einen Transistor gesteuert. Die Schaltung ist also so simpel, dass es sich noch nicht einmal lohnt einen Schaltplan zu zeichnen. Nichtsdestotrotz gibt es hier einen.

Der Aufbau auf Lochraster ist wenig Spektakulär, nur dass darauf zu achten ist, möglichst zu keiner Zeit die Netzspannung in der Nähe des Digitalteils zu haben. Das kann sehr schnell zu magischem Rauch führen.

Aufbau der Hardware im Inneren der Steckdose.

Der Code für den ESP ist wieder auf GitHub zu finden. Es besteht aus zwei Dateien, dem Startup Script und dem eigentlichen Program.
http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/init.lua?footer=minimalNach der Initialisierung wird der WiFi Accesspoint eingerichtet. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=1:6Eine Funktion zum ausschalten der Steckdose durch ein Timeout wird festgelegt http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=7:11Der Server, der auf Port 80 nach Verbindungen lauschen soll wir über eine Zeile gestartet. Der Accesspoint hat nach vorgabe der NodeMCU Software die IP_Adresse 192.168.4.1, sie muss also nicht gesondert festgelegt werden. Zusätzlich wird noch ein Event-Handler angegeben, wenn der Server ein Request erhält. Fertig ist der Software Teil dieses zugegebenermaßen sehr einfachen Aktors. Allerdings kann die Hardware auch dazu verwendet werden, um in das Herbert-Netzwerk eingebunden zu werden. Allerdings ist Herbert am Einsatzort dieser Steckdose noch nicht verfügbar. http://gist-it.appspot.com/github/DasBasti/esp8266/blob/master/Aktoren/Steckdose/Timeout/AP.lua?footer=minimal&slice=13:29

Wichtig ist, dass nach einem vollendeten Projekt der Schreibtisch in den Ursprungszustand zurück 
gesetzt wird, um beim Nächten Projekt alles wieder vor Ort zu finden. 

Finish eines 3D-Druck aus ABS Kunststoff

Marvin für 3D Hubs

Meistens erkennt man einen 3D-Druck am Linienmuster der einzelnen Schichten. Jede neue aufgetragene Schicht führt dazu, dass das Ergebnis dieses Linienmuster aufweise. Um ein optisch ansprechendes Ergebnis für den Druck zu erziehlen kann daher nach dem Druck ein Prozess in Gang gebracht werden, der mit Aceton das eben gedruckte ABS wieder anlöst. Da Aceton allerdings ABS sofort auflöst, darf es nicht direkt auf den Druck aufgebracht werden. Bei dieser Methode wird Aceton als Dampf um den Druck herum gebracht. Die Oberfläche löst sich an und ‚verschmilzt‘ zu einer glatteren Struktur. Die Linienmuster komplett kann man damit nur sehr schwer entfernen, aber eine glänzende Oberfläche wird auf alle Fälle erziehlt. Um den Dampf zu erzeugen lege ich in Aceton getränktes Küchenpapier an den Rand einer Tasse. Die kommt dann auf das noch warme Druckbett. Das ganze lasse ich dann für 15 Minuten stehen. Danach ist die Außenseite des Modells noch ziemlich weich und sollte nicht mit dem Finger berührt werden. Nach einigen Minuten ist das Aceton verdunstet und die Ausßenseite des Drucks wieder fest. Und immer an genügend frische Luft denken!

Marvin ist frisch poliert
Aceton-Dampfbad

 

Renkforce RF1000 von Conrad

Als ich im Februar auf der Embedded World bei Conrad meine Visitenkarte an einen Gewinnspielzettel getackert habe, habe ich tatsächlich den Renkforce RF1000 3D Drucker gewonnen. Noch auf dem Stand habe ich mich mit einem der anwesenden Verkäufer über den Drucker unterhalten und fand ihn für den Preis von ~2.000€ viel zu teuer. Die Möglichkeit den Drucker zur Fräse umzubauen allerdings hat was. So durfte ich gestern in der Conrad Filiale meinen Hauptgewinn abholen. Zwei sehr nette Mitarbeiter haben mir dann auch noch das Angebot der Mannheimer Conrad Filiale näher gezeigt. Nach der Führung ging es dann in die Abteilung mit den Druckern und 3D Druckern. Dort wurde ich von einem Verkäufer in die Verwendung des RF1000 und den Workflow von Stl Modell nach GCode eingewiesen. Gleichzeitig wurde ein 3D-Scan von mir angefertigt. Der hat allerdings nicht so gut funktioniert; ich bin wohl nicht 3D-fotogen. Neben einem riesigen Karton gab es noch eine 750g Rolle PLA Filament (3mm) dazu und ich war Besitzer eines 2.000€ teuern 3D Druckers. Abgefahren.

Zuhause angekommen begann dann das Aufbauen. Neben dem komplett zusammengebauten Drucker befindet sich noch eine Tüte mit Einzelteilen und dem Stromkabel in der Packung. Der Verkäufer hat mir gesagt, der Drucker sei einsatzbereit und kann sofort losdrucken, dass die Druckerdüse auf dem Druckbett schleift, wenn man um den Achsennullpunkt herum fährt, stellte diese Aussage als nicht ganz die Wahrheit hin. 

Also in der Anleitung geschaut und den Übeltäter gefunden. Die Kontermutter des Z-Achsen Nullpunkt ist nicht ganz festgezogen worden. Die Schaube schnell neu eingestellt, Kontermutter fest gezogen, Automatische Druckbettvermessung gestartet. Kalibrierungswürfel von der SD-Karte gestartet und schon ging sie los, die wilde Fahrt. Was während der Vermessung schon aufgefallen ist zeigt sich beim Drucken sehr deutlich. Der RF1000 ist laut. Nicht nur die Drehenden Motoren machen einen riesen Lärm, sondern auch die Halteströme der Motoren sind so getaktet, dass sie noch im höhbaren, aber hohen Frequenzspektrum liegen. Hier wird hoffentlich ein Firmwareupdate Abhilfe schaffen denn der Drucker ist so laut, dass es kein Spaß macht sich im gleichen Raum aufzuhalten. 

Die mitgelieferte Filamentführung ist bescheiden und das Filament bleibt teilweise im Schlauch hängen, bzw die Reibung am Schlauch ist so hoch, dass der Extruder es nicht schafft das Filament durch den Schlauch zu ziehen. Glücklicherweise gibt es auf der SD-Karte bereits eine alternative Halterung zum Drucken. Beim Druck musste ich dem Extruder dann Händchen halten um eine konstante Zuführung des Filaments zu erreichen. Dabei ist mir aufgefallen, dass der Extruder noch einiges an Optimierungspotential mitbringt. Das Filament ändert je nach Position des Druckkopfes den Eintrittswinkel in den Extruder. Dieser schabt dann im ungünstigsten Fall kleine Kunststofffäden ab. Diese sammeln sich dann im Extruder und werden von dem geriffelten Rad mitgenommen. Allerdings bleiben sie meistens in den Riffeln hängen und führen so langsam aber sicher zur Verstopfung. Hier werde ich in der nächsten Zeit einige Versuchsobjekte drucken, die das hoffentlich beheben.
Die blaue Bauraumbeleuchtung mit dem orangenen Filament ist allerdings schon ein Hingucker!

Reinigen einer 3D Drucker Düse

Ich habe heute ausprobiert, wie gut man die Düse eines FFM Druckers mit einer Lötlampe reinigen kann das Ergebnis ist erstaunlich. Die Düse sieht fast aus wie neu. 

In den Bildern zu sehen ist die 1mm Düse. Durch den großen Durchmesser muss die Temeratur der Düse beim Drucken auf 255°C erhöht werden. Das führt dazu, dass Kunststoffreste außen an der Düse verkohlen. Mit einer einfachen Propangas Flamme aus der Lötlampe lassen sich die Kunststoffreste problemlos entfernen. Nebenbei wird die Zange gleich noch mit abgeflammt. Die Technik funktioniert auch hervorragend für den Heizblock, sollte der auch mit verkohltem Kunststoff verdreckt sein. Nach dem Flambieren habe ich die Teile auf dem Abziehstein wieder glatt und glänzend geschliffen und eingebaut. Funktioniert hervorragend.

Herbert Reloaded: Haus Automation

Mein Projekt, die Wohnung komplett über ein Automationsbus zu steuern, geht langsam voran. Aber warum noch ein Haus Automations Bus? Weil die bereits verfügbaren nicht genau dem entsprechen, was ich gerne hätte. Einige sind auf eine dauerhafte Verbindung ins Internet angewiesen, andere sind zu teuer, oder nicht vollständig. Oder benötigen Datenleitungen zu den Knotenpunkten.

Herbert wird einmal die Wohnung steuern und dafür werde ich existierende Hardware umbauen, oder eigene Hardware entwerfen, die genau die Aufgaben erfüllt, die ich mir von einem Hausbus wünsche. Der Aufbau wird folgende Topologie besitzen:

Herbert Topologie V2.0

Das Zentrum von Herbert ist ein Raspberry Pi 2, der in einem externen Festplattengehäuse untergebracht ist. Die externe Festplatte ist immer noch in dem Gehäuse und wird die Speicherzentrale für das NAS. Der Pi hat leider nur langsames USB 2.0. Da das WLAN und die Festplatte über USB angeschlossen sind werden keine neune Geschwindigkeitsrekorde aufgestellt werden können. Für regelmäßige Backups ist es allerdings schnell genug.

Herbert 2.0

Neben dem NAS besitzt Herbert ein openHAB Interface. openHAB ist ein offenes Haus Automation System, dass in Java entwickelt wurde, dadurch ist es auf vielen Plattformen lauffähig. Es besitzt Module um viele bereits verfügbaren Systeme zusammen zu schließen und über die eine Plattform zu steuern. Ich habe mich entschieden die Kommunikation über MQTT zu lösen. MQTT ist eine Kommunikationsplattform für Maschine-zu-Maschine Kommunikation. Man kann sich ein einem Verteiler (Broker) anmelden und für verschiedene Nachrichten anmelden. Danach erhält man die Nachrichten auf diesem Kanal. Der Part des Brokers wird von der offenen Software Mosquitto übernommen, die ebenfalls auf dem Raspberry Pi läuft.

Die Firmware NodeMCU besitzt ein Lua Modul, dass die Kommunikation mit einem MQTT Broker sehr einfach gestaltet. Das Modul mqtt.Client() bietet Funktionen zum Anmelden für Nachrichten, als auch zum Verschicken von Nachrichten.

Diese Nachrichten werden an vereinbarte Topics gesendet. Diese sind in der Konfigurationsdatei von openHAB und in der Lua Quelltext abgespeichert. Weitere Funktionen des NodeMCU sind der Stromsparende Tiefschlafmodus und die Kommunikation über die serielle Schnittstelle. Beide dieser Funktionen werden an unterschiedlicher Stelle benötigt. Der Tiefschlaf ist für die Sensoren notwendig, wenn diese nur Nachrichten senden, aber keine Empfangen sollen. Die serielle Schnittstelle ist für die Kommunikation mit einem anderen Controller gedacht, der dem ESP die nötige Berechnungspower zur Verfügung stellen kann.

Der Auf/Zu Sensor ist in der Aktuellen Version dem Fensterwächter sehr ähnlich. Allerdings ist er noch nicht so weit veröffentlicht zu werden. Alle Module mit allen Programmen und Schaltungen werden aber in der nächsten Zeit hier zur Verfügung stehen. Der Code und die Konfigurationsdateien für Herbert liegen ebenfalls auf GitHub.

Resourcen:
Raspberry Pi Debian Variante: Rasbian
openHAB Dokumentation + Autostart Anleitung
MQTT auf dem Raspberry Pi installieren
NodeMCU API Dokumentation

Unboxing: Raspberry Pi 2 B++

Ich habe heute ein Paket mit dem neuen Raspberry Pi 2 B++ erhalten. Nachdem die Hardware des Raspberry Pi in der neuen Version 2 auf einen bessern CPU Chip geändert wurde sind die Schnittstellen zu USB und Ethernet die Flaschenhälse zum Controller gewesen. Mit der neuen Version des Raspberry Pi 2 B++ wurde das jetzt auch behoben. Wie angekündigt sind zu Beginn des zweiten Quartals 2015 die ersten Muster des neuen Modells mit Gigabit Ethernet und USB 3.0 verfügbar.

Der neue Raspberry Pi 2 B++

Gleich zu Beginn sieht man, die Muster wurden schnell verpackt, um dem Liefertermin gerecht zu werden. Neben dem relativ aussagelosen Ettikett, dass einfach auf die Verpackung geklebt wurde finden sich keine Hinweise zu der neuen, bessern Embedded-Hardware-Plattform, die im Inneren auf uns wartet. Schnell aufmachen, um die trostlose Erscheinung der Verpackung hinter uns zu lassen und zu sehen, wie die Performance des neuen Gigabit Ethernet im Vergleich zum Alten Pi 2 abschneidet.

ESD – Schutzverpackung im passenden Kartonausschnitt

Der Pi 2 B++ ist in einer ESD-Schutzhülle verpackt und wird in einem Kartonträger geliefert. Was die trostlose Kartonhülle zu erwarten ließ wurde vom Inhalt weit überboten. Das Auspackerlebnis gleicht dem eines hochwertigen Apple Produktes. Nach genauer Betrachtung zeigt sich, dass die Module einfach nur mit auf das Board gebracht wurden. Die Hardware unterstütz zwar USB 3.0 allerdings erkennt der Kernel des aktuellen Rasbian den USB 3.0 und Ethernet Controller nicht. Doch wie bereits angekündigt soll das nächte major Release von Rasbian (RasbiAF) die nötige Software mitbringen.

rPi 2 B++ mit USB 3.0 und Gigabit Ethernet