Freitag, 26. Dezember 2014

Home automation done in one afternoon

So there they are. The winter holidays. And you finally I have all the time to make that stuff I wanted to do. But what to do first.
Remote-control
The challenge is to build the things as fast as possible. So we start with the home automation thing I had in my mind for a few month now. First up we need a cool name so it does stick out of the masses. Well it's name is going to be Herbert.
Next up we need a processing base station for WiFi integration.

Remote-controlled Socket
This nice Raspberry Pi will do the job pretty well I guess. I have a collection of 6 remote controlled wall-adapters for the power sockets and a remote-control to toggle 3 of them individually on and off. the all-off button also exists. Dismantling the remote I found a circuit-board with an ASIC, 12V battery, four tactile switches, 434MHz crystal, one LED and a 8bit-dip switch bank.
Basically just an ASIC
 A quick glance at the backside of the PCB shows that 7 of the 8 switches are connected to the ASIC. Looks like some sort of channel selection. Nice. The operation voltage for the remote is 12V so we can not directly hook the Pi up.
I need some sort of isolation between the two circuits. Something like a optocoupler or a relay. I just happen to have two dual-relay-modules laying around so why not use them. A really quick solder-job later the tactile switches had a wire attached as well a a wire to short one of the channel-selectors. Now all six sockets can be operated with one remote module. the all-off switch is not connected. So I can not switch them all off at once. For now. A look inside the socket adapters show that they also consist of an ASIC. This one isn't even labeled! A switch mode power-supply and an antenna.

The socket-module seems not to answer the command in a way to determine of the signal was received. I will have a look into this later. For now one-way communication will have to be sufficient.

Everything hooked together like this:
5V -> Relay supply
3.3V -> Relay driver
GPIO -> Relay switch signal
The relays short the tactile switches ans one of the channel-selectors. 


The next step is software. The Pi I use has Raspbian installed. This is a Linux based on the Debian distribution and comes with python and bindings to access the GPIO directly from the script. With Python you get a HTTP-server up and running in no time.

from BaseHTTPServer import BaseHTTPRequestHandler,HTTPServer
import RPi.GPIO as GPIO
class myHandler(BaseHTTPRequestHandler):
    
    #Handler for the GET requests
    def do_GET(self):

        self.send_response(200)
        self.send_header('Content-type','text/html')
        self.end_headers()
        # Send the html message
        self.wfile.write("Hello World")
        GPIO.setmode(GPIO.BCM)
        GPIO.setup(4, GPIO.OUT, initial=1)
        GPIO.output(4, 1)
        
        return

try:
    #Create a web server and define the handler to manage the
    #incoming request
    server = HTTPServer('', 8000), myHandler)
    print 'Started httpserver on ', server.server_address
    
    #Wait forever for incoming http requests
    server.serve_forever()

except KeyboardInterrupt:
    print '^C received, shutting down the web server'
    server.socket.close()

With little additions the first version of Herbert was built. Have look at the git if you want.

Donnerstag, 20. November 2014

Electronica 2014

Ich war am 13.11. auf der Electronica in München. Das ist eine der Großen Elektronik Messen.

Es gab sehr viele interessante neue Dinge zu sehen. Allerdings kann man an einem Tag nicht einmal ansatzweise alles sehen, das ausgestellt ist. Allerdings habe ich einige interessante Neuigkeiten erfahren, die für zukünftige Projekte von Nutzen sein können.


Sonntag, 16. November 2014

Back on track... Es druckt wieder

Nach einigen Reparaturarbeiten ist der Drucker wieder unter den Lebenden. Einige Dinge, die ich dabei gelernt habe und die für andere nützlich sein könnten:


Stotternder Schrittmotor

Nachdem ich die Treiber des Duet Controller-Boards getauscht hatte ist der Y-Motor nicht mehr korrekt verfahren. Ich habe das auf die Tatsache geschoben, dass dieser Treiber eventuell nicht richtig verlötet wurde. Also habe ich das Board noch einmal nachgelötet und mit einem ausgebauten Motor getestet. Das Ausbauen des Motors war schnell erledigt und nachdem ich die Lötstellen noch einmal erwärmt hatte hat der Motor sich auch korrekt gedreht. Also alles wieder eingebaut und diesmal die Verkabelung genau überprüft und der Motor stottert immer noch. Nach Erhöhen des Motorstroms und verringern der Beschleunigungswerte ist die Achse auch wieder verfahren. Allerdings ist der Tisch anstatt der 10mm ist der Tisch aber 80mm verfahren. Ein eindeutiges Zeichen, dass mit den Microstep Jumpern etwas nicht stimmt. Wie im Schaltplan des Duet Boards zu erkennen ist, wird jeder Motortreiber auf 1/16 Microstep konfiguriert. Ein kurzes nachmessen des betroffenen Treibers und siehe da, die Konfiguration für MS2 war auf low statt high. Da hat sich beim Tauschen der Treiber wohl eine Leiterbahn gelöst. Ein Draht von Pin 6 auf 3,3V und schon lief wieder alles wie geschmiert.

Stotternder Schrittmotor 2

Ein weiteres Stottern der Y-Achse nach dem erfolgreichen Zusammenbauen und dem ersten Druck ließ sich auf eine lose Steckverbindung des Motors zurück führen. Nicht immer ist das Controller-Board der Verursacher. 

Kabelführung

Die Verschiedenen Kabelstränge des Druckers sind jetzt in einem Bündel mit einem Spiralschlauch zusammen gefasst und somit nicht mehr so gefährdet sich zu verheddern. Der Spiralschlauch ist günstig auf Amazon zu haben.

Luftzug

Der Lüfter für die Hotend-Kühlung kann keinen nennenswerten Druck aufbringen. Da die Luftdüsen des Kühlerteils allerdings nicht dem Durchmesser des Lüfters entsprechen, wir eine große Menge der Luft zur Zuführungsseite zurückgedrückt und weht auf das Druckbett. Das soll angeblich zu schlechteren Drucken führen. Mit einer Abdeckung kann dem entgegengewirkt werden. Ob das wirklich funktioniert, wird sich zeigen.

Stromversorgung

Ich habe das ATX Netzteil durch ein 400W LED Netzteil ausgetauscht. Die Druckplatte ist wesentlich schneller auf Temperatur, die Steigung der Temperaturgerade ist fast doppelt so hoch wie vorher, und der Lüfter des Hotends bekommt beim Einschalten der Heizplatte oder des Hotends kein Drehzahleinbruch mehr. Ich hoffe dass dadurch die Druckergebnisse Konstanter werden, da teilweise der gleiche Druck einmal gelungen ist und beim nächsten Mal wieder nicht.
Die 400W sind allerdings auch viel zu hoch ausgelegt, aber was soll's, es funktioniert.

Hotend Kühlung

Wie bereits oben beschrieben ist die Drehzahl des Lüfters am Hotend ab sofort nicht mehr davon abhängig, ob die Heizplatte oder das Hotend eingeschaltet ist. Wie und ob sich da bei den Druckergebnissen bemerkbar macht bleibt abzuwarten. Besonders interessant werden Brücken, die nun konstant gekühlt werden können. 

Wärmeleitpaste

Ich habe zwischen Heizplatte und Aluminiumabdeckung eine gehörige Portion Wärmeleitpaste verteilt. Das Ergebnis ist , dass die Glasplatte jetzt wesentlich näher am Wert der im Web-Interface eingestellt ist liegt als vorher. Der thermische Verlust zwischen PCB und Aluplatte war durchaus signifikant. Wenn ich im Web-Interface 50°C einstelle hat die Glasplatte nach einiger Zeit auch zwischen 48°C und 49°C erreicht. Erstaunlich.
Den Schalttransistoren im Netzteil habe ich ebenfalls eine Portion Wärmeleitpaste verpasst, denn die waren einfach nur auf einen Alu-Heatsink geschraubt. Der Thermistor im Hotend ist durch diverse Unfälle mittlerweile komplett mit PLA im Heizblock eingegossen. Insofern dient hier das dauernd geschmolzene PLA als 'Wärmeleiter'.

Alles wieder am Laufen

Zukunftspläne

In nächster Zukunft werde ich einen Halter für den Kabelschlauch des Trägerarms machen, denn der führt im Moment dazu, dass sich die Steckverbinder zum Controller-Board bewegen und das ist kein guter Zustand.
Ebenso ist das Kabel zum Heizbett zu lang. das werde ich auch noch kürzen.

Samstag, 8. November 2014

BTW: What's inside a cheap Chinese LED power supply?

I got a cheap 400W 12V switching power supply in the mail the other day. I wanted to use it as replacement for an ATX power supply for my 3D-printer.

But what is inside those things?
400W / 12V Power supply from china

First of all let's have a look at the outside of the power brick. The Frame is made from two 1.5mm aluminium sheets. There is a fan in the top and the screw terminals are covered with a plastic lid. The frame has two screw holes on each side for mounting. It does not have a switch but there is an indicator LED next to the terminal.
The fan on the top cover is connected to a pin header so it can be removed with the lid. The housing itself is pretty sturdy so it looks good so far.

The input voltage can be selected via a switch that is accessible from the outside. You can select a supply voltage of 110V and 220V. So it can be used worldwide since the frequency of the input current does not matter for a switching power supply.


After lifting the cover up we can have a look at the PCB inside. It looks like there is a single sided through hole board inside. Four high power semi-conductors are placed near the side walls and thermally connected to them.One thing I noticed was a loose screw flying around inside the supply. This can be extremely dangerous since it can cause a short in the supply. Also there where two mounting screws missing on the board. One in the middle and one in the upper left corner. 


The underside of the PCB shows the different components of the circuit. The picture below shows the different parts of the power supply. First of all we can see the terminal at the right side and the high voltage AC input at the lower part of the screw terminals. The yellow area is protective earth and surrounds the hot part of the high voltage mains circuit. This is where one of the mounting screws where missing! The mains voltage is decoupled via a transformer and goes from the yellow part into the green area. There it is rectified and buffered in two 680µF caps. Those are rated 250V so I'm not sure what voltage this area has. It certainly can not be rectified mains voltage since this is nearly 400V! The pink area is control circuitry with a central controller KA7500B. It brings everything along to control the switching regulator found at the back side heat-sink. The blue square is the main transformer, that transforms the higher voltage on this side to the desired 12V on the other side. There you can see that the traces on the PCB get flooded with solder to decrease their resistivity. The PCB trace width calculator gives a rough estimation for about 97.9mm trace width. This is certainly not the case so the added solder leads to a reduced trace width. The output of the Terminals is monitored by the chip. So they have to be connected to the 12V output traces. Since the high current leads to a voltage drop over the distance from the transformer to the terminals the measurement of the output voltage should be done at the terminal point. Therefore there should be at least one sens line going back to the controller circuit. Yes, there it is. Marked with the orange arrow.



Oh wow they are high quality Rubycon Caps... Oh wait. no they aren't


So after all I can say you get what you pay for. The power supply is not bad. But it certainly is no high end laboratory style power brick. Let's see how it works out under load.


The output voltage at the terminal droped one volt after loading the power supply with 350W. This can be compensated at the trimmer next to the terminal. so now the output voltage is bang on 12V and the ripple is in an acceptable 0.2Vpp. The supply can now deliver 12V without dropping to 10V like the ATX did. Let's fix up the printer to get going again.

Donnerstag, 6. November 2014

Never assume... Immer einmal mehr überprüfen

Mein Umbauvorhaben, ein leistungsfähigeres Netzteil als das ATX-Netzteil an den Drucker zu bauen ist leider gescheitert. Um die benötigten 20A zum Heizen des Druckbetts an den Drucker zu liefern habe ich mich für den Einsatz einer 3-adrigen 2,5mm² Netzleitung entschieden. Also Braun, Blau und Grün-Gelb. Der Austausch hat vor einigen Tagen stattgefunden und ich habe lediglich die vorgegebene Leitung mit der neuen ersetzt. Dabei habe ich nicht auf die Polarität geachtet, sondern lediglich darauf die gleichen Anschlüsse wieder zu treffen. Tja und genau das habe ich vergessen. Als ich das neue Netzteil anschließen wollte habe ich Blau als 0V und Braun als 12V verwendet, ohne es nochmal auf dem Controllerboard zu überprüfen, denn diese Farbcodierung wird auch im 12V kapazitiven Näherungsschalter verwendet. Die Schaltung zur Generierung der 5V und 3,3V ist mit einer Diode gegen Verpolung gesichert, die Motortreiber hingegen sind in Flammen aufgegangen...

Ersatz ist bestellt und ich kann die Treiberbausteine austauschen. Das ärgerlichste an der Sache ist, dass ich es hätte besser wissen müssen.

Never assume. Double check. Every time. 

Sonntag, 2. November 2014

Zeitraffer Aufnahmen mit dem RaspberryPi und einer PiCam

Es hat etwas faszinierendes dem 3D-Drucker dabei zuzuschauen, wie er Schicht für Schicht ein Teil erstellt. Allerdings ist der Prozess ein zeitintensives Unterfangen. Kleine Drucke sind in einigen Stunden gedruckt, größere Drucke dauern hingegen gerne mal etwas länger. 7 Stunden sind für einen mittelgroßen Druck eine realistische Zeit. Um den Prozess in seiner ganzen Faszination abzubilden können Zeitrafferaufnahmen gemacht werden. Dabei wird die Zeit, die benötigt wird auf ein einstellbares Minimum reduziert und die Entstehung des Objektes in seiner ganzen Pracht gezeigt. Das Hilfsmittel meiner Wahl ist ein RaspberryPi mit PiCam und die Software RPi-Cam-Webinterface. Die Installation der Software ist mit wenigen Eingaben, entweder über die Konsole des Pi's oder über SSH erledigt.

sudo apt-get update
sudo apt-get dist-upgrade
sudo rpi-update
mkdir ~/cam
cd ~/cam
git clone https://github.com/silvanmelchior/RPi_Cam_Web_Interface.git
cd RPi_Cam_Web_Interface
chmod u+x RPi_Cam_Web_Interface_Installer.sh
./RPi_Cam_Web_Interface_Installer.sh install

Jetzt sind alle benötigten Dateien und Programme installiert, sodass mit einem Webbrowser auf die Cam zugegriffen werden kann. Das sehr minimalistische Webinterface ermöglicht eine einfache Konfiguration und die Vorlage für Zeitrafferaufnahmen hat alles für einen schnellen Test bereits eingestellt. Wir wählen also unter 'Load Presets: Stf FOV, x30 timelapse' aus. Ein simpler Druck auf 'record video start' startet die Aufnahme.

RaspberryPi mit PiCam


Nach einiger Zeit hat sich auf Grund der hohen Auflösung der Kamera eine beachtliche Datenmenge angesammelt. Mein aktueller Druck läuft seit 4:30 Stunden und die dazugehörige Filmdatei ist bereits 3,6GB groß. Meine Speicherkarte wird also demnächst überlaufen und die Aufnahme abbrechen. Schade, denn der Druck wird noch einige Stunden laufen.

Eine weitere Möglichkeit ist, die Kamera nur Bildaufnahmen machen zu lassen. Eine Aufnahme mit voller Auflösung und 85% Bildqualität führt zu einer ungefähr 3MB großen Datei. Wenn alle 3 Sekunden ein Foto geschossen wird entsteht innerhalb einer Minute 60MB Daten. Eine Stunden sind dann 3,5GB. Auch hier ist uns nicht weitergeholfen. Um hochwertige Aufnahmen für den Zeitraffer zu bekommen werde ich wohl oder Übel den Speicher des RaspberryPi erweitern.

Sonntag, 26. Oktober 2014

Druckprobleme und -lösungen

Seit meine Rolle weißes PLA von FilamentPrint zu Ende ging habe ich eine 1kg Rolle schwarzes Filament aus China am Drucker hängen. Seit dem hatte ich keine so guten Ergebnisse mehr erzielt. Nach einigen Versuchen habe ich jetzt einige Methoden ermittelt mit denen der Druck dann auch mit dem billigen China PLA zum Erfolg wurde.

PLA darf nicht auf einem zu heißen Druckbett gedruckt werden

Im Gegensatz zu ABS biegt sich PLA auf einem zu heißen Druckbett, was zum Crash mit dem Lüfter führt. Dadurch wird dann der schon gedruckte Körper vom Bett weggerissen. Ein zu kaltes Druckbett führt allerdings zu geringeren Haltekräften auf dem Kaptonband. Daher ist die Einstellung der Temperatur ein klein wenig aufwändig und man muss einige Versuche für verschiedene PLA Rollen durchführen. Aktuell habe ich das Druckbett auf 48°C eingestellt. Was nicht bedeutet, dass das Kapton 48°C heiß wird, denn der Thermistor ist in der Heizplatte lediglich eingeklemmt. Es ist davon auszugehen, dass die Heizplatte etwas wärmer ist. Die Oberfläche der Glasplatte kann allerdings kälter sein. ich habe leider kein Thermometer da um das zu bestätigen.

Langsamer drucken ist für die erste Schichte keine Allgemeinlösung

Die erste Schicht einfach langsamer zu drucken ist für nicht haftende Drucke (zumindest aus PLA) kein allgemein gültiges Heilmittel. Die Zeit, die die Düse auf dem schon aufgebrachten PLA verbringt, führt dazu, dass es zu Biegekräften kommt. Die sind dann ebenfalls für das Hochbiegen von Ecken und Kanten verantwortlich. Eine für mich erfolgreiche Geschwindigkeitsreduzierung ist 50% Druckgeschwindigkeit für die erste Schicht mit innernen Kanten zuerst, dann Äußere Kante und dann Füllung. Die so erzielten Druckergebnisse sind sehr zufrieden stellend.

Z-Achen Refernez und Druckbettausgleich

Der Abstand der Z-Ache zum Druckbett sollte im Bereich von 0,1mm sein. Der Druckkopf darf auf keinen Fall mit Kraft auf das Druckbett drücken, wenn er auf Z=0 gefahren ist. Da das Druckbett des Ormerod Druckers nicht parallel zur X-Achse verläuft ist eine Kompensation notwendig. Diese wird auf Grund des etwas klapprigen Y-Tisches nach jedem Start und beim Referenzieren der Z-Achse ausgeführt. Diese Kompensation führt zwar zu einem erhöhten Betrieb der Z-Achse, führt aber zu wesentlich besseren Druckergebnissen als ohne. 
Schiefes Druckbett des Ormerod Druckers
Die stärkere Belastung der Z-Achse ist nicht schlimm, da in meinem Drucker die M5 Gewindestange gegen eine gut geschmierte Tr10x2 Gewindestange getauscht wurde. So ist es immer wieder schön zuzuschauen, wie die Z-Achse mit verfährt um eine Ebene zu schaffen, die Schräg zur X-Achse liegt.


Samstag, 18. Oktober 2014

Das unendliche Projekt

Warum gibt es 3D Drucker für 2000€ wenn man sich einen ähnlichen schon für 500€ selbst bauen kann?

Diese Frage hat mich in der letzten Zeit beschäftigt. Einerseits sind die offensichtlichen Punkte einen fertig montierten Drucker zu kaufen offensichtlich. Er muss nicht mehr zusammengebaut werden. Andererseits ist das auch eine Aufgabe, die ich persönlich als sehr faszinierend empfinde.

Nach einigen Wochen der regelmäßigen Benutzung meines Ormerod 1 Druckers kann ich allerdings die Kaufentscheidung für einen fertig montierten und in Betrieb genommenen Drucker verstehen. Die meiste Zeit ist mein Drucker nämlich nicht mit drucken beschäftigt. Es ist leider nicht möglich direkt nach dem Einschalten loszudrucken. Die Mechanismen, die den Druckkopf zum Druckbett referenzieren sollen sind leider (noch) nicht in der Lage an verschiedenen Tagen gleiche Ergebnisse zu liefern. Weiterhin muss ich nach jedem beendeten Druck den Drucker resetten und die Z-Achsen Referenzierung durchführen. Somit kann ich den Drucker leider nicht wie erhofft von einem entfernten Rechner mit Daten füttern, die er dann gedruckt hat, wenn ich nach Hause komme. Das ist im Moment das angestrebte Ziel.

Bis es soweit ist sind mir noch einige Dinge Aufgefallen, die eine Verbesserung verlangen:
  • Das Druckbett ist aus 3mm MDF und alles andere als Stabil. Einige Unfälle haben dazu geführt, dass die Ecken deutlich wegsacken. Noch sind sie leicht oberhalb der Y-Achse, wenn sie allerdings weiter absinken, wird das unweigerlich zum Crash am Ende der Achse führen. Hier muss also eine Stabilisierung eingebaut werden.
  • Die M5 Gewindestange der Z-Ache ist mittlerweile eine 10mm Trapezgewindespindel. Das hat zu einem sehr ruhigen Lauf der Z-Achse und wunderschönen Ergebnissen der Schichten geführt. Allerdings passt der Abstand der Achse noch nicht zur Spindel und so neigt sich die Spindel, je tiefer die Z-Achse steht. 
  • Der kapazitive Sensor der Z-Achse hat eine Reproduziergenauigkeit von 4% das sind bei den Einstellungen zur Zeit ca. 0,3mm und somit ausschlaggebend, ob ein Druck gelingt, oder von vornherein zum Scheitern verurteilt ist.
Allerdings hat sich in der letzten Zeit auch einiges Positive entwickelt. Ich habe den Drucker auf Vibrationsdämpfern stehen. Jetzt kann man sich in dem Raum auch wieder unterhalten, wenn der Drucker aktiv ist. Ich habe außerdem eine Rollenhalterung gedruckt, die die Filamentrolle für den Feeder bereit hält. Auch das funktioniert hervorragend.

Mittwoch, 1. Oktober 2014

Anschnallen und festhalten! 3D-Drucker in Hyperspeed

Die neuse Version des Ormerod Firmware Branches ermöglicht die Einstellung eines Geschwindigkeitsmultiplikators. Zusammen mit einem erhöten Motorstrom kann hier an der Druckgeschwindigkeit gedreht werden. Die Motoren des Ormerod sind für 1,4 A ausgelegt und die Treiber können bis zu 2 A treiben. Dabei ist darauf zu achten, dass die Treiber nur passiv ohne zusätzliche Heatsinks außer dem PCB gekühlt werden. Der obere Berecih der Motorströme sollte also möglichst gemieden werden. Ich habe aktuell die Achsenmotoren auf 1 A und den Extruder bei 800 mA gestellt und erreiche damit bei 300% Druckgeschwindigkeit zufriedenstellende Ergebnisse.
Der Geschwindigkeitsmultiplikator beeinflusst jede Geschwindigkeit des Druckers und kann somit von 0% bis ???% den Drucker auch mal an die Grenzen des Möglichen bringen. Die Bewegungen werden linear Skaliert, was für die Beschleunigungswerte ebenfalls eine skalierung bedeutet. Hierdurch werden im System neue Schwingungen eingebracht, die durch die ruckartigen Start- und Stopbewegungen entstehen. Neben dem erhöhten Geräuschpegel führen die Vibrationen auch zu mechanischen beeinträchtigung. Meine Druckbettbefestigung hat sich im hinteren Bereich gelöst, was dazu führte, das das Bett abgesunken und der Druck damit nach zwei Stunden 300% Druckgeschwindigkeit leider doch noch fehlgeschlagen ist.

Lessons learned:
  • Schraubensicherungslack für Schraube-Mutter alle Verbindungen verwenden
  • Vibrationsdämpfer für den Drucker herstellen
  • Druckgeschwindigkeit im G-Code Generator festlegen und nicht manuell alles beschleunigen
  • Z-Achse ist das ausbremsende Element
  • Große Druckaufträge dauern auch mit 300% Geschwindigkeit sehr lange.
Zum Schluss: Verfahrgesräusche bei 300%

Sonntag, 28. September 2014

3D Drucker Augen zu und kapazitiv testen

Im Rahmen einer kleinen Umbauaktion des Druckers habe ich auch den optischen Sensor gegen einen kapazitiven Nährungesschalter getauscht. Das ging nicht so leicht wie erwartet. Der optische Näherungsschalter wird zum Einstellen der X- und Z-Achse verwendet. Diese Konfiguration kann mit einem kapazitiven Sensor nicht durchgeführt werden, da der Sensor wesentlich größer ist als die kleine Platine des optischen Sensors.
Druckkopf mit vorläufig angebrachtem kapazitiven Sensor zur Druckbettbestimmung
Im Hintergrund der Abbildung kann man den neuen Endschalter der X-Achse erkennen. Der wird, wie der Endschalter der Y-Achse am Duet Board an den Pins neben dem Z-Motor. Dabei wird der Schalter wie der Y-Endschalter angeschlossen. Die LED auf dem Duet Board soll nun leuchten, wenn der Endschalter nicht betätigt wird. Die Löcher zur Montage des Tasters sind im X-Achstenträger schon vorhanden und müssen nicht neu angebracht werden.

Der schwierigste Teil ist es den Endtaster jetzt als Quelle für den Nullpunkt zu etablieren. Dazu muss die Firmware geändert werden. Dank 3D-ES gibt es aber ein script, mit dem man sich das git Repository von dc42 herunterladen kann. Dort muss in der Auswahl allerdings der dev tree und nicht der duet tree aus.

   - git clone -b duet ${FW_REPO}/${FIRMWARE} ${FIRMWARE}
   + git clone -b dev ${FW_REPO}/${FIRMWARE} ${FIRMWARE}

Nachdem das Repository heruntergeladen wurde kann mit 

   ./make.sh && ./make.sh install

Der Code kompiliert und installiert werden. Die zu ändernden Werte befinden sich in der Datei "Platform.h" bei Zeile 120

   - #define Z_PROBE_AXES {true, false, true}
   + #define Z_PROBE_AXES {false, false, true}

Damit wird der Firmware gesagt, dass nur noch die Z-Achse mit Hilfe des Z-Sensors genullt werden soll. Alle anderen Achsen haben eigene Endstops.

Bei der Einstellung des Z-Nullpunkts kann wie in der Anleitung beschrieben vorgegangen werden, nur dass man jetzt einen definierten Schaltpunkt hat und daher der Wert keine Rolle spielt. Ich habe mich langsam an den Nullpunkt herangetastet und dann 1,5mm nach oben gefahren. Der Schaltpunkt des Sensors habe ich dann so eingestellt, dass er gerade an diesem Punkt schaltet. Dann den Punkt noch einmal angefahren und der neue Wert für M31 stand fest.

   M31 Z1.66 P600

Wobei der Wert bei P wie oben schon beschrieben relativ egal ist, da der Sensor einen Schaltpunkt hat ab dem er dann von 0V auf einen festen Wert springt. Dieser Wert ist meistens die Betriebsspannung des Sensors. In unserem Fall ist das aber ehr hinderlich, da der Sensor mit 12V betrieben werden muss. Also ein Spannugnsteiler zwischen Signal und Masse, sodass ein ca. 3V starkes Signal am ADC Eingang anliegt. Den Sensor, wie den Taster für die X-Achse, als einfacher Enschalter zu verwenden scheitert, da der Sensor auf Versorgungsspannung schaltet und nicht auf GND, wie es von den Endschaltern getan ist. Hier kann man eventuell noch etwas verbessern.

Alle Änderungen in der Firmware des Ormerod werden in meinem github Repository eingespielt und stehen zur Verwendung zur Vefügung.

Samstag, 27. September 2014

3D Drucker der zweite Akt

Ein paar Drucke sind erfolgreich beendet worden, es sind sogar ein paar brauchbare Sachen dabei herausgekommen. Aber was wäre denn ein RepRap, wenn er nicht direkt mit besseren Teilen erweitert wird. Wie im ersten Bericht schon beschrieben sind die Zahnräder für die Z-Achse bereits ersetzt. Heute habe ich das Flachbandkabel für das beheizte Druckbett mit einem 1,5 mm² Kabel ersetzt. Das ist jetzt wesentlich leichter zu verlegen und blockiert nicht die komplette Steuerplatine. Weiterhin habe ich das Netzteil so angeschlossen, dass ich über G-Code Befehle die 12V Steuerspannung zu und abschalten kann. Das benötigt allerdings eine angepasste Firmware. Ich habe es heute mit der Version von dc42 versucht. Die bringt auch gleich eine neue Weboberfläche mit. Somit ist jetzt lediglich die Logik mit dem Standbystrom des Netzteil verbunden und bei bedarf wird die komplette Energie des Netzteils hinzugeschaltet.
Ormerod 1 mit erhöhtem Druckbett und neuem Kabelbaum für den Heizer
Das Software update hat allerdings auch seine Nachteile mit sich gebracht. Einmal führte es dazu, dass der X-Achsen Motor falsch herum angesteuert wurde. Im Nachhinein sind jetzt alle Achsenmotoren gleich angeschlossen und es funktioniert wieder. Ein weiteres Problem, das leider weiterhin besteht ist, dass der Vorgang des Nullens der Z-Achse das Koordinatensystem verschiebt. Und das führt dazu, dass die Punkte für den automatischen Bettabgleich nicht mehr an den ursprünglichen Punkten zu finden sind. Ich hatte aber heute keine Zeit mehr die Punkte anzupassen und zu testen, ob ich mit neuen Referenzpunkten auf ein annehmbares Ergebnis komme. Laut dc42 liegt dieser Fehler an einem Bug in der RepRapPro Firmware, die auch in sinem Fork nicht behoben wurde. Der Bug tritt auf, wenn Achsenkompensation verwendet wird. Eine weitere Untersuchung folgt. Update: Die heute erschienene Version 0.78t zeigt dieses Verhalten nicht mehr.

Geplant sind weitere Erweiterungen, wie ein Schwingungsdämpfer, sowie ein Schutz für den Lüfter. Auch werde ich auf lange Sicht den optischen Sensor gegen einen kapazitiven tauschen, ich habe nämlich heute einige Tests gemacht, die sehr vielversprechend auf die Reproduzierbarkeit der Ergebnisse gelaufen sind. Das Problem des optischen Sensors ist, neben der Empfindlichkeit gegenüber Tageslicht, die ungleichen Refektionseigenschaften der unterschiedlichen Tastpunkte. Mit dem kapazitiven Sensor habe ich an zwei unterschiedlichen Stellen den Nullpunkt einwandfrei bestimmen können.

Ein weiterer geplanter Umbau ist die Neustrukturierung des X-Auslegers. Dort wird im Moment eine M5 Gewindestange verwendet um den Arm nach obern und unten zu verfahren. Ich habe mir überlegt die vorhandenen Kunststoffteile so neu zu drucken, dass die Kraft nicht mehr von der Seite, sondern zwischen Führungslinie und Biegekraft liegt, also auf einer Achse mit dem Ausleger. Außerdem soll die M5 Spindel gegen eine stabilere und spielfreie Tr10x2 Trapezspindel getaucht werden. Der Motor wird auch nicht über Zahnräder die Achse antreiben, sondern direkt über eine Kupplung. Dieser Umbau benötigt allerdings einen funktionierenden Drucker, also erst einmal die Fehler der Achsenkompensation auftreiben und eliminieren.

Sonntag, 21. September 2014

3D Drucker Ahoy!

Ich habe mir vor einigen Tagen ein RepRap Ormerod Bausatz gekauft. Das Aufbauen war nicht sonderlich schwer und die Verkabelung ebenfalls sehr einfach. Innerhalb von 6 Stunden stand der Drucker komplett zusammengebaut auf dem Tisch. Probleme gab es dann beim Einstellen der Software. Die Kommunikationsschnittstelle mit dem Board ist nicht sonderlich stabil. Teilweise gehen Nachrichten verloren und so sind die ersten Tests nicht sonderlich viel versprechend gewesen. Die Elektronik dann aber vom 5V Pfad des Netzteils zu betreiben und die 12V lediglich für Heizung und Motoren zu verwenden hat die Stabilität wieder zurück gebracht. Das nächste Problem, das konstant aufgetreten ist, hat mit dem Infrarot-Sensor der Z-Achse zu tun. Die Z-Achse soll Berührungslos genullt werden. Dazu befindet sich an einer bestimmten Stelle eine weiße Fläche auf der Druckplatte. Der Sensor wird von oben zu dieser Fläche bewegt und die reflektierte IR-Strahlung wird registriert. Daraus ergibt sich für ein knappen Berühren der Oberfläche mit dem Druckkopf ein Wert von ungefähr 980 mit einem Rauschen im bereich von +- 3. Dabei sitzt der Sensor ca. 2 mm über dem Druckbett. Wenn der Druckkopf ein Zehntel Millimeter weiter hochgefahren wird, sinkt der Wert um ungefähr 2, was bei dem vorherrschenden Signal-Rausch-Abstand keine gut detektierbare Messwertänderung ist. Die Sensitivität des Sensors ist im Abstand von 4 mm am größten. Da werden dann Messwerte im Berich 650 generiert die pro Zehntel Millimeter um 10 bis 15 abnehmen. In diesem Bereich kann dann mit dem vorherrschenden Offset genullt werden. Interessanterweise ist der Wert des Sensors aber abhängig von welcher Richtung man auf die Stelle fährt. Wenn der Sensorkopf von untern, also von hohen Sensorwerten auf die Stelle gefahren wird, zeiugt er einen höheren Wert an, als wenn er von oben auf die gleiche Stelle gefahren wird. Dieses Verhalten hat zu einigen Abdrücken im Druckbett geführt. Ich habe es jetzt zumindest reproduzierbar hinbekommen. Die Nulk-Funktion der X-Achse liefert immer wieder den gleichen Punkt über dem Druckbett. Allerdings 0,5 mm zu hoch. Diese waren so reproduzierbar, dass ich mir nicht die Mühe gemacht habe herauszufinden weshalb. Sogar die automatische Druckbettabgleichung funktioniert mit diesem Offset jetzt auch einwandfrei.
RepRapPro Ormerod mit Tower of Pi


Eine Bewertung zum Ormerod und weitere Baudetails spare ich mir an dieser Stelle. Es gibt genügend davon im Internet zu finden. [0] [1] [2] Allerdings werde ich in der Nächsten Zeit einige Veränderungen an dem Drucker vornehmen. Darunter fällt das Auswechseln der Zahnräder, sowie der Gewindestange, die hat nämlich eine leichte Biegung. Auch der Druckbettschlitten wird ersetzt, sobald ich die Achsen kalibriert habe.
Links: Originale Zahnräder für die Z-Achse
Rechts: Neue Zahnräder mit Pfeilverzahung für mehr Laufruhe und Stabilität
Wie in den Bildern nicht unbedingt sichtbar ist, sind die Zahnräder gerade verzahnt und haben auf Grund der Fertigungstoleranzen der gedruckten Bauteile teilweise sehr große Reibungskräfte, wenn man sie unglücklich kombiniert. Die Teile auf der rechten Seite werden die Ersatzteile für die Zahnräder sein. Allerdings laufen die gerade relativ gut und ich werde die neue Gewindestange für die neuen Zahnräder verwenden. Erstaunlicherweise sind die Drucke so präzise, dass es bis auf die Kante der ersten Schicht keine Nachbearbeitung der Teile benötigt. Und das waren eine der ersten Drucke ohne Kalibrierung der Achsenlänge und der Winkel.

Pläne für den nächsten 3D Drucker stehen schon, denn jetzt kann ich mir den selbst drucken.

Donnerstag, 4. September 2014

Dual-Energy Radiographie

Grundlagen

Die Möglichkeiten verschiedene Gewebedichten in Röntgenstrahlung darzustellen sind begrenzt. Knochen haben eine wesentlich höhere Dichte als Gewebe. Das führt bei Röntgenaufnahmen zum Abdecken von Gewebeinformationen. Eine Methode diese Informationen zu erhalten ist, die Knochenstrukturen in Röntgenaufnahmen zu isolieren und zu subtrahieren. Diese Technik wird Dual-Energy Radiologie genannt, da zwei Aufnahmen mit unterschiedlicher Strahlungsenergie dafür benötigt werden. Eine Aufnahme mit geringer Energie bildet Gewebestrukturen und Knochen ab. Eine zweite Aufnahme mit höherer Energie bildet nur Knochenstrukturen ab. Mit Hilfe der Dämpfungskoeffizienten der verschiedenen Gewebe bei verschiedener Energie können die Dicken der Gewebeschichten ermittelt werden.

Dienstag, 12. August 2014

PHYTEC liveDVD Installation updaten

Beim starten des Software-Centers oder des Updates kommt es zum Absturz des Programms. Das Problem sind fehlerhafte Schlüssel in apt.

Mit Hilfe von
sudo apt-get clean
sudo mv /var/lib/apt/lists /var/lib/apt/lists.old
sudo mkdir -p /var/lib/apt/lists/partial
sudo apt-get update
sudo apt-get upgrade
kann das Problem der Schlüssel gelöst werden. Sollte es bei dem letzten Befehl zu keinem Fehler kommen, kann mit
sudo rm -rf /var/lib/apt/lists.old
Die Sicherungskopie entfernt werden. Wenn es weiterhin nicht funktioniert, muss man in der Datei /etc/lsb-release der Wert von PHYliveDVD auf Ubuntu ändern.

Samstag, 10. Mai 2014

Funkstrom? Aw Yis!

Qi Empfänger
Qi (Aussprache: [ˈt͡ʃiː]) ist chinesisch und steht für Lebensenergie. Es ist aber auch ein Standard des Wireless Power Konsortiums um drahtlose Energieübertragung durch elektromagnetische Induktion für kurze Strecken zu vereinheitlichen und kompatibel zu halten. Es gibt mittlerweile eine Vielzahl von billigen chinesischen Sende- und Empfangsgeräte, die diese Art der Energieübertragung zum Laden eines Mobiltelefons verfügbar machen, ohne dass dafür die Garantie des Handys erlischt. Diese Module gibt es in verschiedenen Ausführungen und für viele verschiedene Positionen. Wie in den Bildern zu erkennen, sind sie so aufgebaut, dass das Flachbandkabel entsprechend der Konfektion des Moduls angelötet wird. Das Basismodul mit der Sendespule verfügt über einen Micro-USB Buchse und kann somit mit den gewohnten Ladegeräten verwendet werden.


Wie beim Empfänger zu sehen ist, besteht das Modul eigentlich nur aus einem Chip, dessen Beschriftung nicht lesbar ist und einigen passiven Bauteilen. Den größten Teil nimmt die Antennenspule in Anspruch. Sie ist zwischen den beiden Klebeflächen eingeklebt und somit auch ziemlich flach. Das Löten der Steckerverbindung ist jedoch nicht ganz einfach, da die Masseverbindung direkt auf die Kupferfläche der Platine geht und so eine große Wärmemenge aufgenommen werden kann. Nach ein paar Versuchen habe ich allerdings die Lötverbindung so hinbekommen, dass der Anschluss zur Seite des Moduls richtig herum und vor allem in der richtigen Länge herausschaut. Alles wieder zusammengeklebt, auf die Rückseite meines HTC One S geklebt und auf die Basisstation damit. Siehe da, es funktioniert nicht, das Ladelicht blinkt und das Telefon lädt nicht.


Die Basisstation des Ladegerätes ist in einem rechteckigen Kunststoff Gehäuse untergebracht. Das Gehäuse an sich ist sehr leicht und es macht nicht den stabilsten Eindruck. Die Angaben in der Bedienungsanleitung sind auf Chinglish und nicht sehr hilfreich. Nur das Netzteil, das dort erwähnt wird, war nicht in der Packung. Mist. Auf der Rückseite des Tischgeräts sind neben 'Made in China' die üblichen Angaben gemacht, die darauf hinweisen, wo das Problem liegen könnte. Ich habe das Ladegerät an meinem Laptop betrieben. Da kommen aus dem USB Anschluss nur 500mA Strom und somit nicht genug für dieses energiehungrige Teil. Laut USB Spezifikation ist der Maximalstrom der über einen Port kommt 500mA aber das Gerät möchte 2A Eingangsstrom sehen. Also schnell einen der nicht standardkonformen chinesischen USB-Steckdosengeräte dran und siehe da, mit genug Power geht es. Das blaue Ladelicht ist dauerhaft an und das Telefon zeigt an, dass es geladen wird.

Der Inhalt der so leichten Ladestation hat mich dann doch gewundert. Ich habe damit gerechnet, dass eine schlecht gewickelte Spule mehr schlecht als recht an eine Platine gelötet ist auf der ein Schwingkreis das Ladesignal erzeugt. Dem ist nicht ganz so.

Innenleben der Ladestation

Neben einer durchaus ansehnlichen Spule (dieser Aufbau wird auch bei uns in der Firma verwendet) die auf einer Ferrit-Platte sitzt und stabil ins Gehäuse geklebt ist befindet sich ein Board mit mehreren ICs. Der Gehäusedeckel hat an der Stelle an der die Spule sitzt sogar eine Verjüngung, sodass die elektromagnetischen Wellen nicht unnötig durch das Gehäuse gedämpft werden. Die Zentrale Steuerung des Ladegeräts dürfte wohl der Microcontroller U3 im 20 Pin Gehäuse sein.

IC U3: Der Controller?
Die Beschriftung sagt, es handelt sich um einen MSP430G2558. Allerdings hat Texas Instruments keinen MSP mit dieser Bezeichnung im Programm, der Controller, der dieser Modellnummer am nächsten kommt ist der MSP430G2553. Auch das Datenblatt des 2553 zeigt an, dass Das hier verwendete Package nicht zweizeilig, sondern einzeilig beschrieben ist. Also weiter bei Ti.com nach Informationen zu dieser Controllerfamilie gesucht und auch einiges gefunden. Der Teil 'G2' steht für einen Controller aus der Value Line Familie. Aber auch hier findet sich kein Exemplar, dass mit einer 8 im Namen endet. Ich gehe davon aus, dass es sich hier um eine Kopie eines MSP430 handelt, selbst wenn dazu ein Datenblatt existiert, besteht keine Garantie, dass die dort genannten Werte eingehalten werden können.

MOSFET
Betrachten wir ein weiteren Chip auf der Baugruppe. Die Spule wird von zwei ziemlich starken MOSFETs getrieben. Die DTM4606 sind in der Lage über 5A zu steuern. Jeder Chip beinhaltet zwei dieser FETs, jeweils ein P- und ein N-Kanal. Allerdings ist der P-Kanal bei beiden nicht verbunden. Weiterhin sind pro Spulenseite 4 NPN Transistoren verbaut, von denen aus der Controller die MOSFETs steuert.

Operationsverstärker
Eine weitere sehr interessante Baugruppe ist auf der Platine zu finden. Ein vier in einem Gehäuse Operationsverstärker, was die auffallend vielen Kondensatoren und Widerständen erklärt. Es sieht so aus, als würde die Spule neben der reinen Aussendung der Energie auch noch eine Überwachung des Ladezustands durchführen. Das erklärt, weshalb das Ladegerät in der Lage ist zu erkennen, ob ein Gerät in Reichweite der Sendespule ist, aber nicht genügend Energie übertragen wird um im Empfänger einen Ladestrom zu erzeugen, wie es mit dem Betrieb am USB-Port offensichtlich der Fall war.

Samstag, 26. April 2014

Statusupdate April

Lange Zeit gab es nun schon keine neuen Beiträge, das wird sich in der nächsten Zweit ändern, denn ich bin zur Zeit mit zwei sehr interessanten Projekten beschäftigt. Das erste Projekt ist die Miniaturisierung eines USB-Repeater. Dazu wird es in die Wafer Level Chip Scale Technologie, sowie in die USB2.0 Spezifikationen gehen. Das Andere Projekt hat mit kapazitiven Touchsensoren zu tun. Vor allem in Betracht auf Sicherheitsanforderungen im Bereich Medizintechnik.

Das Projekt Kaffeeautomat mit WLAN wurde beendet, leider ist die Dokumentation für die Weitergabe an Dritte gesperrt. Bei Gelegenheit werde ich die Arbeit mit einem Gerät eines anderen Herstellers noch einmal durchführen und die Dokumentation diesmal frei zur Verfügung stellen.

Weiterhin habe ich noch ein paar Ideen, die ich in den nächsten Monaten umsetzen möchte, dazu aber später mehr.

Mittwoch, 19. Februar 2014

Using the 'Console' to talk to the Yún MCU from Python

Playing around with the Yún led me to the problem that I had a Sketch up and running on the MCU that could be controlled from the Arduino serial console. To move the commanding part to a python script all I had to do was to do this communication from the Linux side of the Yún-Bridge system.

To initialize the Bridge all you have to do is call the Bridge.begin(); function in the setup part of the sketch. After that we initialize the Console with Console.begin(). To stop the execution of further commands we can poll the Console to become ready.
void setup() {
  // put your setup code here, to run once:
  Bridge.begin();
  Console.begin();
  while (!Console) {
  ;
  }
}
You can now use the print functions as usual:
  if(Console.available()) {
   c = Console.read();
   .
   .
   .
  }
On the Linux side we have a python script that will conncet to the bridge server and do the same as the Arduino serial console.
import telnetlib, time

tn = telnetlib.Telnet("localhost", 6571)

while True:
  print "w"
  tn.write("test")
  print tn.read_eager()
  time.sleep(1)

Mittwoch, 12. Februar 2014

WLANKaffee Code Repository

Wir haben vom Hersteller der Maschine die Auflage bekommen, die Informationen nicht öffentlich zur Verfügung zu stellen. Daher wird das Projekt und der Quellcode nicht mehr zur Verfügung stehen.

Ich habe den Code für den Arduino auf einer Google Code Projektseite hochgeladen. Der Code ist teilweise ungetestet, da die Kaffeemaschine noch nicht vollständig verdrahtet ist. Diese Arbeit wir nächste Woche beendet. Der Zeitpunkt für den ersten Release ist dann auch der nächste Dienstag.
Aktuell sind für den ersten Release diese Funktionen geplant:
  • Yún
    • Arduino
      • Firmware die über die Console Klasse gesteuert werden kann.
      • Steuerung der Menüknöpfe am HID
      • Drehencoder wird ausgewertet
      • Drehencoder Impulse werden simuliert
    • Linino
      • Python mit Django
      • Webseite mit Benutzerverwaltung
      • Steuerung über Console Klasse des µController
  • Dokumentation
    • Python
      • SPI Protokoll für Display Frames


Sonntag, 2. Februar 2014

Arduino Yún, Linux mit Arduino auf einem Board

Für unsere Projektarbeit haben wir entschieden, dass ein Linux fähiges Board und ein Arduino Mikrocontroller zum Einsatz kommen soll. Um das ganze möglichst klein zu halten haben wir den Arduino Yún ausgewählt. Der Yún hat neben den Funktionen, die auch ein Leonardo mitbringt zusätzlich einen voll funktionsfähigen Computer an Board, der mit einem speziellen openWRT Distribution läuft. Das Besondere ist, dass die beiden Geräte miteinander kommunizieren können und somit beide Geräte direkt miteinander verbunden sind. Auf der Linuxseite bietet die Linino Distribution einiges an Funktionalität, wie zum Beispiel eine REST-Full API um die Pins des Arduinos direkt anzusteuern. Eine weitere großartige Funktion wird in der Bridge Bibliothek zur Verfügung gestellt. Die Kommunikation zwischen Mikrocontroller und Programmen auf der Linuxseite.

SSH Konsole des Yún mit Erweiterung für die Kaffeemaschine

In unserem Falle wird der Mikrocontroller die Ansteuerung der Kaffeemaschine übernehmen und bestenfalls den SPI Bus abhören und die übertragenen Displaydaten in einen seriellen Bytestream umwandeln. Die Linuxseite wird die komplette Benutzerschnittstelle bereitstellen, also ein Webinterface mit dem die Kaffeemaschine gesteuert werden kann. Außerdem wird die Webseite den Inhalt des Displays darstellen. Wie die Daten von der Maschine in ein Bild gewandelt werden, habe ich letzte Woche schon beschrieben.

Diese Woche habe ich mich mit dem SPI Interface beschäftigt. Die Displaydaten werden über den SPI Bus vom Benutzerpanel an den Displaycontroller gesendet. Diese Daten können vom Arduino aufgezeichnet werden. Um klein anzufangen, habe ich verschiedene Ansätze ausprobiert. Die Grundvoraussetzung war, dass der Bustakt von 1 MHz eingehalten wird. Dann werden alle 0,1 Sekunden 541 Bytes übertragen. Der genaue Aufbau des Protokolls lässt sich relativ kurz beschreiben. Zuerst bekommt das Display den Wert 0x89 übertragen. In den Datenblättern, die etwas mit dem Display zu tun haben könnten habe ich diesen Befehl leider nicht finden können. Weiter geht es mit dem Byte 0xB4 was laut Datenblatt die Speicherseite 4 als Startadresse angibt. Darauf folgen 134 Bytes mit Bilddaten, bis dann 0xB5 (page 5) übertragen und die nächste Speicherseite ausgewählt wird. Nach weitern 134 Bytes folgt 0xB6 (page 6) und nach weiteren 134 Bytes folgt 0xB7 (page 7). Die abschließende Speicherseite und somit die letzte 'Zeile' des Displays hört auch hier nach genau 134 Bytes auf. Da das Display auf dem Benutzerpanel auf dem Kopf stehend eingebaut ist, sind auch die Daten 'gekippt' Eine einfache Spiegelung hilft das Bild wieder sichtbar zu machen.

Der Arduino Yún
Um mit dem SPI Bus zu arbeiten, ohne die Maschine dabei zu haben, habe ich die Daten eines Frames in ein Arduino-Sketch geladen. Dieser Arduino macht nichts als ein und dasselbe Bild immer und immer wieder alle 0,1 Sekunde über den SPI Bus zu übertragen. Die nächste Aufgabe ist jetzt, die Daten mit dem Yún zu empfangen und zu verarbeiten. Da ich bis jetzt nur einen funktionierende SPI Kommunikation mit Yún als Master und einem Nano als Client zum Laufen gebracht habe, kann ich noch nicht davon berichten, in wieweit sich die Idee mit der Bildgenerierung verwirklichen lässt.

Sonntag, 19. Januar 2014

Das SPI Protokoll für das Kaffeemaschinen Display

Dieses Wochenende haben wir im Projektteam die Kommunikation vom Controller auf dem Benutzerboard zum Display genauer unter die Lupe genommen. Da wir keine genauen Informationen über die verwendeten Bauelemente hatten sind wir mit google auf die Suche nach Datenblättern von Displays ähnlicher Bauart gegangen. Die meisten Displays mit SPI Interface verstehen das gleiche Protokoll zum Setzen der Kofigurationswerte und Übertragene der Daten. Die Daten haben wir mit Hilfe des Logic Analyser ja schon das letzte mal aus der Maschine extrahiert. Nach einigen Anläufen haben wir im Datenbaltt eines Displaycontrollers (ST7565R) die Konfiguration des Display RAMs gefunden. Mit dem Wissen wie das Bild, das im Display angezeigt wird zu übertragen ist, gelang es uns den Datenstream so zu formatieren, dass wir das Bild des Displays gespiegelt auf dem Bildschirm sehen konnten. Mit ein wenig Bearbeitung der
Daten ist es gelungen das Bild, das am Display angezeigt wird zu rekonstruieren.
Der Inhalt des Datenstreams in serieller Formatierung

Datenübertragung in der Maschine

Die Maschine kommuniziert einmal mit der Steuerplatine und dann mit dem Display. Dabei ist die Verbindungsleitung zwischen den Platinen mit einem Enable
Signal verehen. Wenn dieses Signal High ist, ignoriert die Steuerplatine die Daten; wenn der Pin auf Low gelegt wird, sind die Daten am Bus für die Steuerplatine.
Vom Controller gehen, neben der Datenleitung MOSI, nicht nach Außen geführte Leitungen an das Display. Es ist also anzunehmen, dass dort auch eine Enable und/oder
Clock Leitung dabei ist. Die Daten, die über den SPI Bus bei dauerhaftem High Zustand auf Enable an der Controllerplatine gehen sind somit aller Wahrscheinlichkeit
nach an das Display gerichtet. Genauer betrachtet wurden jedes Paket 541 Bytes übertragen. Das Display hat eine Bildmatrix von 128 * 32 Pixeln, somit werden
4096 Bit zum Darstellen eines monochromen Bildes benötigt. Die übertragenen Bytes beinhalten diese Datenmenge und zusätzlich noch einige Steuerbefehle.
Das Bild steht noch auf dem Kopf und die Page-Select Befehle sind noch links sichtbar

Display RAM

Wichtig ist dabei zu beachten, dass die Pixelreihen des Display nicht wie erwartet seriell mit Daten bestückt werden, sondern der serielle Kommunikationsport nur vor den parallelen geschaltet wurde. Dadurch ergibt sich die Eigenschaft, dass die Daten 'Zeilenweise' in den Speicher des Displays geladen werden. Zeilenweise
bedeutet dabei, dass der Speicher in 8 bit breite Pages eingeteilt wird. Jede Page wird zuerst ausgewählt und dann von Spalte 0 an aufgefüllt. Dadurch erscheinen die Bilddaten nicht waagerecht, sondern senktrecht und werden so zusammen gesetzt. Nachdem der Aufbau des Speichers bekannt war, konnten wir unsere Software danach ausrichten und haben den Displayinhalt 'CAPPUCCINO' in den sortierten Matrxwerten erkennen können. Jede Zeile oder Page begann mit einem Page-Select Befehl, der getroßt ignoriert werden konnte. Der letzte Schritt war es, die Matrix der Bilddaten in ein PNG zu gießen um es später als Bild in einer Webseite verwenden zu können.
Die rekonstruierte Grafik des Maschinendisplays

Analyse des Protokolls zur Maschinensteuerung

Nachdem jetzt die Übertragung der Displaydaten bekannt ist, müssen noch die vorherigen 10 Bytes der Maschinensteuerung in einen Kontext gebracht werden. Mit Hilfe eines kleinen Scripts habe ich die Logic Analyser Mitschnitte in Kommando- und Bildabschnitte zerlegt. Das Bild wird generiert und die Kommandodaten werden daneben in einer Tabelle abgebildet. Jetzt müssen wir nur die passenden Befehle herausfinden. Dazu gibt es dann nächste Woche mehr.

Mittwoch, 15. Januar 2014

Reverse Engineering einer Kaffeemaschine

Meine aktuelle Projektarbeit befasst sich mit dem Innenleben eines Kaffee Vollautomaten der Firma Severin, Genauer gesagt der KV8023 S2+. Ziel dieser Arbeit ist es die Kommunikation zwischen Bedienpanel und Kaffeemaschine zu analysieren und gegebenenfalls so zu manipulieren, dass die Maschine über einen Mikrocontroller ferngesteuert werden kann. Dazu habe ich die Maschine erst einmal geöffnet und zwei Flachbaugrupppen gefunden. Eine ist Netzteil, Netzspannung-Schaltung und Controller für die eigentliche Maschine, die andere ist ein Bedienpanel mit einem eigenen ATmega1284P an board. Das Flachbandkabel, mit dem beide Platinen verbunden sind deutet darauf hin, dass die Steuerung der Maschine über ein Bussystem gelöst ist. Wo die eigentliche Intelligenz steckt ist mit eines der ersten Punkte, die es herauszufinden gibt.
Geöffneter Vollautomat Controller des Bedienpanels

Nach einer genaueren Betrachtung des Panels habe ich die Verbindungen der Bauteile in einem Plan aufgestellt. Dieser Plan zeigt alle Steckverbinder, das Displayinterface und die, an den Controller angeschlossene Hardware (Taster, Drehencoder und LED). Eine Erweiterung des Verbindungskabels mittels eines Schneidklemmsteckers erzeugt den Zugriff auf den vermeindlichen Bus. Dieses Kabel ist verbunden mit dem SPI Interface des Controllers, mit dem Display (hier fehlt noch die Belegung der Kontakte).

Ein kurzer Test mit dem Logic Analyser zeigt, dass auf dem SPI Bus tatsächlich reger Betrieb herrscht. Nach einigen Kaffees habe ich jetzt mehrere Minuten Kommunikation mitgeschnitten und werde im nächsten Schritt versuchen die Telegramme auszuwerten und zuzuordnen.

Mitschnitt zweier Telegramme der Buskommunikation


Die Übertragung startet zyklisch alle 0,126 Sekunden, es werden 10 Byte über den Bus mit Enable Low (An) übermittelt. Auf diese Bytes gibt es eine Antwort auf der MISO Leitung. Darauf folgen 540 Bytes ohne Antwort, bei denen der Enable des Flachbandkabels konstant auf High (Aus) liegt. Es liegt nahe, dass es sich hierbei um Daten für das Display handelt, denn auch dorthin ist MOSI des Controllers verbunden. Mit einem Arduino und einem kleinen Sketch kann ich also nächste Woche die 10 Byte Telegramme abfangen und zur Auswertung aussortieren. Dadurch reduziert sich die Menge der Telegramme auf ein Minimum und die Entschlüsselung ebendieser wird hoffentlich leichter fallen.

Um eine Fernsteuerung durchzuführen, muss die Kommunikationsverbindung unterbrochen werden, da sonst das Bedienpanel in die automatisierten Telegramme zusätzliche Telegramme schicken würde. Gleichzeitig muss dem Bedienpanel die Antwort der Maschine vorgespielt werden, da sonst ein Fehler angezeigt wird. Wie sich die Anzeige des Displays manipulieren lässt habe ich mir noch nicht überlegt, da der Enable Eingang des Displays nicht nach Außen geführt wird.

Mittwoch, 8. Januar 2014

Projektarbeit ASURO

Der ASURO war zentraler Bestandteil der letzten Projektarbeit. Das Ergebnis ist eine Betrachtung der Hardware und eine Umsetzung in Software.

Zusammenfassung
In dieser Studienarbeit wurde die Firmware des ASURO Roboters erweitert. Ziel war es, die Sensorwerte der sechs Sensoren zyklisch abzufragen, um die Werte für den Programmierer direkt zur Verfügung zu stellen. Der Controller des ASUROs besitzt einen AD-Wandler mit sechs Messkanälen, deren Aktivierung in der Software koordiniert und deren Messwerte in die realen Werte umgerechnet werden.

Bei den Sensoren handelt es sich um Reflexionslichtschranken, optoelektronische Sensoren, Taster und Batteriespannung. Von den Reflexionslichtschranken kann auf die Umdrehungen der Räder geschlossen werden; von den optoelektronischen Sensoren kann auf die Helligkeit des Untergrunds geschlossen werden. Die Taster dienen zur Kollisionsabfrage an der Roboterstirnseite und die Batteriespannung dient zur Überwachung der Stromversorgung.

Die Abfrage der Sensoren wurde durch zyklische Auswahl der Messkanäle innerhalb der AD-Wandler Interrupt Service Routine realisiert. Die Werte werden in einem öffentlichen struct dem Rest der Roboter Software zur Verfügung gestellt.

Zusätzlich beschreibt diese Arbeit noch die Verwendung der Softwaresimulation in Atmel Studio und eine Methode für Unittests mit AVR Mikrocontrollern.

Samstag, 4. Januar 2014

Sicherheit im Internet der Dinge (Fonera mit SSL)

Sollte es einmal so weit sein, dass sogar der Kühlschrank mit der Heizung und der Waschmaschine spricht um ein möglichst Strom effizientes Miteinander zu gewährleisten, wird das aller Wahrscheinlichkeit nach über Funk passieren. Doch eine Kommunikation über Funk ist alles andere als sicher und so muss der Sicherheitsaspekt von Beginn an in die Entwicklung internetfähiger Haushaltsartikel mit einfließen. Ich experimentiere zur Zeit mit einem kleinen Linuxboard, das unter anderem eine WLAN-Schnittstelle hat.

Sollte dieses Board einmal zum steuern eines Haushaltsgegenstandes verwendet werden, bleibt zu überlegen, wie die Kommunikation von der Kontrollstelle zum Board gesichert werden kann. Eine Möglichkeit wäre das erstellen eines abgeschlossenen WiFi Netzwerks das nur zur Steuerung der Geräte dient und nicht mit dem Internet verbunden ist. Das führt allerdings nicht dazu, dass das Gerät im Internet erreichbar ist, was unserem Ziel nicht gerecht wird. Eine zweite Möglichkeit ist eine normale HTTP Verbindung mit HTTP Auth zu implementieren. Somit ist schon mal eine einfache Sicherheitsebene dazugekommen und das Gerät steht nicht mehr jedem Internetteilnehmer zur Verfügung. Die nächste Schicht wäre eine Verschlüsselte Kommunikation über HTTPS. Dadurch wird das Passwort nicht mehr sichtbar übertragen und einem eventuellen Mithörer bleibt der Anmeldeprozess verborgen. Ein Passwort ist allerdings selten sicher, wenn man dem Benutzer keine vorgegebenen Grenzen setzt. Deshalb bietet sich die Kombination aus Passwort und Zertifikatslogin an. Dabei besitzt der Client ein Public / Private Schlüsselpaar und ein Passwort mit dem das Zertifikat im Client geöffnet werden kann.

Um eine SSL Verbindung über HTTPS zur Fonera zu ermöglichen, benötigt man einen anderen Webserver als den Busybox httpd. Ich habe mich für den mini-httpd entschieden, der bringt auch die Erweiterung für SLL nämlich matrixssl mit. Im OpenWrt Wiki findet sich eine gute Anleitung, wie man mini-httpd mit SSL durchführt. Anders als in der Anleitung angegeben muss allerdings das Paket mini-httpd-matrixssl anstelle von mini-httpd-openssl installiert werden. Ansonsten kann der Anleitung gefolgt werden. Jetzt steht auf der Fonera nur noch  HTTPS mit einem eigenen Zertifikat zur Verfügung. Der nächste Schritt ist nun ein Frontend zu Anmeldung auf der Fonera zu programmieren.