Hardware » WT150 Hardware Umrüstung auf Replicator-LCD-Interface

@hardy-parts

Mit diesem Beitrag bin ich vermutlich beim Hardware-Hacking am besten aufgehoben:

Ich habe ein paar interessante Dinge über die Funktion des WT150-Displays-Adapters herausgefunden. Bekannt ist ja bereits, dass Weistek sich bei der Leistungs-Hardware ziemlich genau an die Vorlage des Mightyboard von Makerbot gehalten. Daher müsste eigentlich auch jede Firmware laufen, die für diese Boards gedacht ist. Aber wieso tut die das (vermeintlich) nicht und hängt dann die Speicherkarte ab? Weistek hat doch mit großer Wahrscheinlichkeit die Firmware auf dem Board gar nicht angepasst, sondern nur ein wenig an den Gcode-Dateien gespielt.

Egal: Diese Familienähnlichkeit kann man jedenfalls ausnutzen, um ein 2004-Display (20 Zeichen mal 4 Zeilen) nach Makerbot-Vorbild zu integrieren (Stichwortsuche Replicator-Interface Rev-B)! Umsetzungsvorschlag samt "Beweisfoto" anbei.

Wenn man sich den anhängenden (unvollständigen) Schaltplan der Weistek-Erweiterungsplatine mal anschaut, wird auch klar, was die dort gemacht haben:

Im Makerbot-Original ist ein Schieberegister (HEF4094) vorgesehen, mit dem das Mightyboard Byte für Byte an sein HD44780-kompatibles Display schickt. Bei Weistek lauscht aber nicht ein Display, sondern ein 8051-kompatibler Controller (STC12C5204AD mit gigantischen 4k Flash; Datenblatt über STCMCU und ein wenig chinesische Mustererkennung erhältlich) über seinen Port 1 am Ausgang des Shifters. Mit der steigenden Flanke des Strobe-Signals werden die frischen Daten am Ausgang des Shifters eingefroren und mit der folgenden fallenden Flanke des Signals wird im STC (vermutlich, weil an /INT1 angeschlossen) ein Interrupt ausgelöst. Der STC holt sich so direkt den Displaystrom samt Steuer- und Nutzdaten und wird diesen nun filtern und ggf. als seriellen Datenstrom über seinen TxD-Ausgang zum Touchscreen schicken, sofern dort was angezeigt werden soll. Das sind derzeit nur Dateinamen und das Fehlermenü und natürlich die zur Anzeige auf solchen Displays vermutlich üblichen Cursor-Steuersignale.

In umgekehrter Richtung ist der Touch-Screen nichts weiter, als ein "dummes" CGI-Terminal. Ein Tastendruck von dort wird (vermutlich) 1x pro Sekunde oder bei Ereignis als Koordinatenpaar ausgesandt und über RxD vom STC empfangen und ausgewertet. Der STC macht dann daraus an seinem Port 2 und 3 einfach nur einen von fünf möglichen Tastendrücken UP, DOWN, LEFT, RIGHT oder CENTER, sofern die Koordinate auf eine erwartete Stelle zeigt. Sonst macht der NIX. Man sieht das sehr schön, wenn der Touchscreen und das LCD parallel arbeiten: Beispielsweise wird nach An-Touchen des dritten Menüeintrags am Screen einfach nur 2x DOWN und dann 1x CENTER ausgelöst usw. - genau das, was man als User sonst über das Steuerkreuz selber ausführen würde.

Leider ist dieser "LCD-Emulator" aber nur auf genau die eine Muster-Reaktion der Mightyboard Software 7.2 und nur auf das SD-Karten-Menü ausgelegt. Kein Wunder also, wenn jede Firmware, die hier auch nur minimal verändertes schickt, diese Funktion aushebelt! Eine V7.6 oder V7.7-Sailfish arbeiten am Mightyboard eigentlich problemlos, aber die sortieren die Displayeinträge teilweise anders und die schicken als Cursor anstelle der spitzen Klammer (>) ein Pfeilzeichen (->). Damit kann der STC mit der Firmware nichts mehr anfangen. Der User mit seinem 2004-Display und seinem Steuerkreuz aber schon. Die Fehlfunktionen haben also rein gar nichts mit irgendwelchen "verlorenen EEPROM-Inhalten" zu tun...

Bis irgendwann mal jemand mit einer 2004-Display-Voll-Emulation-mit-Steuerkreuz um die Ecke kommt, werde ich wohl den schönen Touch-Screen aus- und mein LCD2004 samt einen physischen Steuerkreuz einbauen. Schade eigentlich, aber in diesem Fall ist der Hardware-Hack deutlich flexibler und deutlich schneller umsetzbar, als der anderenfalls erforderliche Software-Mod.

PS: Es scheint so zu sein, dass die höchste Firmware-Version, mit der ein Makerbot-Clone auf Basis Mightyboard-Clone (und damit das Weistek-Board) noch arbeitet, die V7.5 ist. Bei mir lief zwar auch schon eine V7.7-Sailfish auf dem Weistek, aber mit der habe ich merkwürdige Reset-Probleme. Mal bootet das Board und mal nicht. Der Spuk war sofort vorbei, als ich wieder (ging irgendwann nur noch per ICT) auf V7.2 zurückgeflasht und von dort wieder über RepG auf V7.5 umgestiegen bin...

PPS: Auch Doraware kommt nicht mit allen Firmware-Versionen zurecht. Bei mir geht Doraware tatsächlich nur mit der originalen V7.2 - aber das ist mir eigentlich egal, wenn RepG 40r30 mit PyPy 4.01 (wirklich >5x schneller als Python 2.7 beim Slicen) so schön arbeitet.

Viel Spaß beim Nachbauen,
Arnd

@hardy-parts

Nochmal zu dem EEPROM: Es ist sicherlich plausibel, dass das Mightyboard nicht mehr zu erreichen ist, wenn die EEPROM-Inhalte verloren gehen oder Müll enthalten. Aber im EEPROM sitzt nicht ein Extra-SailFish oder so drin und allem Anschein nach auch kein sonstiges Hilfsprogramm, sondern nur Parameter, die im Gegensatz zum FLASH häufig geändert werden und/oder maschinenabhängig einstellbar sind.

Sailfish ist lediglich eine Art Klassenbezeichnung für eine Generation der Mightyboard-Firmware, die außerhalb von Makerbot durch eine "private" Community weiterentwickelt wurde (wird?). Ansonsten ist das ganz normale Firmware im FLASH. Kleiner Nachteil: Features der Firmware müssen von der PC-Software (RepG und Co) unterstützt werden! Wenn das nicht beachtet wird, haben wir schon den nächsten Grund für merkwürdiges Verhalten.

Das EEPROM im 1280er wird jedenfalls schon von Makerbot zur Ablage von variablen Parametern benutzt. Anhand der Fehlermeldungen (ALL) von RepG kann man schließen, dass es durchaus Befehle gibt, die EEPROM-Inhalte über USB in den Bot schreiben und von dort lesen können. Logisch, sonst könnte man ja keine User-Parameter ändern. Die ersten beiden Bytes des EEPROM enthalten zum Beispiel die Firmware-Version in Binär Code (bei V7.2. steht dort 07 02). Auch die Onboard-Preferences aus der RepG-Oberfläche sind dort abgelegt! In meinen Bildern sieht man bspw. den Botnamen "Weistek WT150" im Display. Das ist der Name, den ich der Maschine über die Onboard-Paramater mitgegeben habe und den Text-String findet man dann auch im EEPROM-Dump wieder. Kleine Anmerkung: Mit RepG40r30 genügt jetzt ein einziger Commit für ALLE Pages der Onboard-Prreferences ;-)

Beim Spielen mit den diversen Firmware-Versionen ist mir aufgefallen, dass die verschiedenen Makerbot-Varianten das EEPROM sehr unterschiedlich nutzen. So unterschiedlich, dass sich die Firmware und auch die PC-Software wohl manchmal aufhängt, wenn eine neue Firmware und/oder PC-Software auf alte EEPROM-Parameter trifft. Aber mit mangelnder Rückwärts- oder Kreuzkompatibilität muss man bei Software manchmal rechnen; nicht nur, wenn die aus der freien Community kommt. Ich habe es mir zur Gewohnheit gemacht, nach einem Firmware-Wechsel (egal ob Up- oder Down-Grade) erstmal die Maschine und damit das EEPROM komplett zurückzusetzen - sofern die Onboard-Paramter erreichbar sind. Wenn nicht, hilft eh nur noch der Debugger (ich verwende einen einfachen myAVRlight für 15,-)

Die ATmegas kann man übrigens mit einem Fuse-Bit (nur über ICT bzw. Debug-Schnittstelle) so konfigurieren, dass die das EEPROM eigenständig(!) löschen, wenn das FLASH komplett (Chip-Erase) gelöscht wird. Diese Fuse ist aber anscheinend nicht gesetzt. Und beim Nachflashen über USB (dann wird der Boot-Loader im FLASH des 1280 benutzt) überleben die EEPROM-Daten ohnehin, weil der Boot-Loader aus naheliegenden Gründen nur mit Page-Erase arbeitet und die Fuse nur am Chip-Erase hängt.

Beim Display habe ich noch Zweifel, ob wirklich dort die Steuer-Intelligenz zu verorten ist. Ich weise die im Moment eher dem STC12C5204 auf dem Erweiterungs-Board zu. DER müsste doch eigentlich wissen, was er mit einer vom Display "dumm" gemeldeten X/Y-Koordinate samt "Touch-Info" anstellen muss. Oder sollte tatsächlich das DWIN Steuerbefehle zum STC schicken??? Ich glaube, ich klemme da bei Gelegenheit mal ein Terminal an...

Gruß,
Arnd

@hardy-parts

Cool! Danke für Hex-Info. Die bestätigt nur meine Vermutung, dass es von der Mightyboard-Firmware abhängt, was und wieviel vom EEPROM genutzt wird. Am HEX kann man auch gleich sehen, dass die zu einem 7.2 gehört (ziemlich am Anfang steht 02 07) und zu einem "The Replicator". Weil ich "meine" HEX schon ausgelesen habe, werde ich mal ausprobieren, wie sich der Bot verhält, wenn man ihm einfach sein EEPROM löscht. Ich habe ihn wegen des Hardware-Mods mit dem LCD eh gerade offen. Wenn er dann per RepG noch erreicht werden kann, kann man mit "Reset Onboard Parameter" eine saubere EEPROM-Startkonfiguration bekommen und wenn nicht, kommt halt wieder das Image rein.

Aber nochmal zur Funktion der Erweiterungsplatine: Ich habe jetzt auch die Dokus von DWIN mal überflogen und auch das bestätigt meine Hypothese, dass das Display nur ein "dummes" CGI-Terminal ist. Wir müssten zum "Modden" des Displays leider zwei Baustellen angehen, weil die eigentliche Übersetzungsinstanz zwischen Mightyboard-Firmware (egal welcher Fisch da gerade werkelt) und Display im STC12c5204 (im folgenden "STC" genannt) sitzt! Denn der STC teilt sich seine Aufgabe mit dem Display ungefähr wie folgt:

Das Display enthält lediglich "Grafikbibliotheken", "Seitenkonfigurationen", "Variablenkonfigurationen" und dergleichen, die ihm durch den Programmiervorgang von der SD-Karte quasi statisch (die Erkenntnis ist wichtig!) ins FLASH gelegt werden. (Zwischensatz: Die Batterie auf dem DWIN versorgt lediglich die Real-Time-Clock "RTC".) Die außen wahrnehmbare Dynamik am DWIN entsteht erst dadurch, dass diese Bibliothekselemente von außen(!), hier über die serielle Schnittstelle zwischen STC und DWIN, gezielt abgerufen werden können. Das gilt sinngemäß auch für die Feststellung einer "Button-Betätigung" am Touch-Screen: Man muss vorher die gewünschten Buttons im Display definieren, ihnen Statusvariablen im Display zuordnen und kann dann laufend deren Betätigungsstatus von außen abfragen.

Ohne es im Detail analysiert zu haben, vermute ich anhand des Look&Feel, dass derzeit im DWIN vier oder fünf Konfigurationen aktiv sind:

1.) Startseite (mit dem Bot-Bild) - eine einfache stationäre Grafik als Bitmap. Da könnte man also einfach sein Schatzi vom Bot lächeln lassen ;-)

2.) Die Seite mit der Scan-Aufforderung - der STC fragt ständig "bist Du betätigt"? Wenn ja, schickt er einen "CENTER"-Tastendruck zum Mightyboard. Das funktioniert so direkt, weil das Mightyboard mit der V7.2 (und mindestens der V7.5) standardmäßig immer auf diesem Menüpunkt verharrt und dort eben einfach nur auf "CENTER" wartet. Beim Original-LCD käme man mit "DOWN" zu den Makerbot-Konfigurationsmenüs, beim Weistek ist dieser Weg dagegen versperrt.

3.) An einem Original-LCD-Display baut sich nach 2.) der SD-Karten-Inhalt auf, gefolgt von einem "exit menu" - diese Zeichenfolgen gibt der STC an die dritte Seite des DWIN weiter, die mit den vier Textfeldern und den beiden Pfeilen unten.

4.) Jetzt wartet der STC darauf welches Feld der User am DWIN auswählt - das können die Pfeiltasten sein oder die Direktauswahl. Der STC wertet das entweder als "CENTER" = Auswahl, als "LEFT" = Escape oder eben als "UP"/"DOWN" = Cursor verschieben aus.

5.) Dann muss es noch eine Fehlerseite geben, die aber auch nur 1:1 die Fehlertexte wiedergibt, die die Firmware sonst auf den vier Zeilen des Orignal-LCD darstellt.

Das ist in Summe zwar nicht viel, was der STC tut und darum kommt der mit max. 4k Flash aus, aber dennoch ist DER die steuernde Instanz, nicht das DWIN. Der STC spricht noch nicht mal die SD-Karte oder die LEDs an, sondern überlässt sogar das 1:1 der Mightyboard-Hardware und -Firmware (vergleiche Schaltplan des Makerbot-LCD-Interface)!

Den STC kann man nun sicherlich ebenfalls anpassen und sogar die Debug-Schnitstelle (P3.0 und P3.1 bzw. RxD/TxD) ist schon rausgeführt, aber ohne Programmierarbeit und Entwicklungsumgebung (C oder Assembler samt Linker) für den STC ist da nichts zu machen. Wenn man nicht von Null aufsetzen möchte, bräuchte man wenigstens die Assembler- und C-Sourcen von Weistek als Absprungbasis... Obwohl: bei STCMCU liegt sogar ein Link zu einem Keil-C-Compiler und sooo kompliziert ist die Sache eigentlich nicht. Aber ob sich der Aufwand wirklich lohnt, wenn keine funktionalen Mehrwerte gegenüber einem Orignal-Makerbot-LCD zu erzielen sind???

Gruß,
Arnd

@hardy-parts

So, es ist vollbracht: Der WT150 ist auf ein LCD-2004 und auf die fünf Tasten eines Original-Makerbot-Replicator umgerüstet. Das ist jetzt quasi ein Replitek oder ein Weisicator.

Die Ergonomie mit den Tasten oben und dem Display darunter ist einfach den internen Platzverhältnissen geschuldet. Weil auf diese Weise keine span-abhebenden Arbeiten am Gehäuse notwendig waren, sieht das Ganze trotzdem so aus, als sei der Bot schon immer so ausgeliefert worden.

Von der Bedienung her ist einiges nützlich, wie das Menü zum Laden des Filaments oder die "ESCAPE"="LEFT"-Taste, anderes funktioniert wegen der unterschiedlichen Maschinenparameter offensichtlich nur mit einem Original-Replicator. Bei mir laufen bspw. die Motoren beim "Homing" über das Menü in die falsche Richtung (über RepG geht's aber richtig rum). Immerhin: die vermeintlichen Zugriffsprobleme auf die SD-Karte dürften jetzt auch für Firmware-Stände jenseits der 7.2 gelöst sein. Im Moment fahre ich mit RepG40-33(Sailfish) und Firmware Makerbot 7.5. Dringende Empfehlung: Nach dem Flashen Immer erst einen Total-Reset über die Onboard-Preferences.

Für die, die das gerne nachbauen möchten, habe ich noch eine bebilderte Ergänzung beigefügt. Die Grundlagen für diese Umrüstung und ein Schaltplanauszug sind ja weiter oben schon abgelegt.

Und weil ich schon dabei war, habe ich gleich die Anschlussmöglichkeit für eine Bauplattenheizung (BPH) bzw. Heated Build Platform (HBP) nach außen geführt. Das Stromversorgungskonzept des WT150 gibt ohnehin keine interne Nachrüstung her und mit diesem "Fernsteuerausgang" kann man sich die Heizung komplett extern aufbauen und trotzdem dem WT150 die Regelung überlassen. Nach Nachrüstung der erforderlichen MOSFET (ein IRF7455 genügt zur Ansteuerung eines externen Leistungsrelais völlig) und sonstigen Bauteile versteht sich. Kurze Anleitung mit Bild ebenfalls anbei. Ja, das hinten im Gehäuse ist tatsächlich einfach nur eine 180°-DIN-Buchse: billig, robust und leicht zu verlängern, sogar geschirmt. Es fließen ja nur ein paar 10 Milli-Ampere.

Frohes Fest und einen Guten Rutsch an alle!

Gruß,
Arnd

Hallo caravanserei, Toll gemacht, die muße hatte ich noch nicht!

Was für ein heatbed nutzt du?

@MSN

Hi!

Noch nutze ich kein Heatbed; ich wollte einfach nur den Vorhalt dafür schaffen, weil der Bot wegen meines LCD-Umbaus eh schon mal offen war.

Ich habe mir auch schon über die Bucht aus China für 7,50 inklusive Versand (kein Tippfehler) so ein FR4-RepRap-Board für 12/24V besorgt. Aber das müsste man noch abschneiden und die Mäanderkämme an den Seiten neu verbinden.

Im Moment bin ich aber mit meiner unbeheizten 3mm-Glasplatte und einem kleinen Beschichtungstrick sehr zufrieden: Selbst ein dem ABS im Warpen kaum nachstehendes Billig-PLA (der 20mm-Testwürfel warpte selbst mit Base oder Brim) haftet darauf nun sehr gut bis fast zu gut. Der Trick liegt daran, die Glasplatte mit stark in Wasser gelöstem Weißleim zu beschichten. Wenn das Zeug erstmal über Nacht zu einem dünnen Film angetrocknet ist, hat man einen wasserfesten, harten Film, der offensichtlich ein wenig angeschmolzen wird (derzeit mit 210°C und dem o.a. PLA) und dadurch eine starke Anfangshaftung vermittelt. Wenn man den Film kurz vor dem Druck auch noch kurz mit Alkohol (Iso-Propanol) abwischt, wird die Oberfläche sogar etwas klebrig und dadurch nochmal extra-haftend; einen 20mm-Testwürfel musste ich danach sogar mit der Wasserpumpenzange regelrecht abbrechen...

Dieser Trick kursiert im I-Net in 3D-Kreisen übrigens unter "Elmer's Glue". Ich verwende stattdessen "einheimischen" Bindulin Bindan-P Propellerleim wasserfest, den ich sowieso für Holzarbeiten im Haus habe (und sehr schätze). Laut Sicherheitsdatenblatt ist der Hauptinhaltsstoff dieser Weißleime Poly-Vinyl-Acetat PVA. Bindan-P im speziellen ist wasserfest (nach Trocknung ;-), geruchsneutral, ungiftig und sogar für Kinderspielzeug geeignet. Das Ganze ist mir deutlich sympathischer, als das Gepansche und der Gestank von in Aceton gelöstem ABS, das im Endeffekt vermutlich auch nur denselben Kleb-/Schmelzeffekt haben dürfte.

Gruß,
Arnd