Alternative RepRap Elektronik im Eigenbau

Da ich mit der offiziellen Elektronik aufgrund der unnötigen Komplexität und des teuren Preises nicht zufrieden war, habe ich mir heute ein RepRap Motherboard selbst gebaut, die auf das tatsächlich Benötigte reduziert ist und so die Möglichkeit für den Anschluss eines LCD bietet.

Es ist zwar noch nicht alles getestet, aber das, was ich eben getestet habe, lief alles auf Anhieb. Die nächsten Tests betreffen die Stepper, für die die Treiber ja schon vorgesehen sind, und die Anbindung an den Host über die RS-232-Schnittstelle.

Ein Foto mit einer Kurzbeschreibung ist dieser Message beigefügt.

Das Board ist in die Arduino Entwicklungsumgebung integriert, sodass die üblichen Arduino-Sketche zum Testen und die Libraries (Pin-Ansteuerung, LCD-Library) wie unter Arduino gewohnt laufen, was äußerst bequem ist. Der Controller läuft mit 20 MHz, sodass etwas Leistungsreserve vorhanden ist. Die RS-232-Schnittstelle arbeitet mit einem MAX232. Über das LCD will ich später Debug-Meldungen wie z.B. die laufenden G-Codes anzeigen, es hat 2 Zeilen à 16 Zeichen.

Es ist noch nicht alles angeschlossen, und zwar fehlen noch die Opto-Endschalter, die Temperatursensoren und Transistoren zum Schalten von Extruder- und Druckbettheizung. Die Schaltungen dafür sind sehr einfach, aber wegen des begrenzten Platzes kommen die vermutlich auf eine zweite Platine, für die ich links unten noch einen kleinen Steckverbinder nachrüsten werde.

Die Platinengröße beträgt 10 * 8 cm², sodass sie gerade noch mit dem kostenlosen EAGLE layoutet werden könnte. Möglicherweise kann man es schaffen, die Platine weitgehend einseitig zu layouten. In dem Fall sollte man allerdings die LCD-Anschlüsse an den Unterrand verlegen, um Leitungskreuzungen (die beim Aufbau auf Lochrasterplatte ja kein Problem sind) durch eine bessere Entflechtung zu vermeiden. Der Aufbau wäre dann halt etwas anders, aber das macht ja nichts.

Wenn diese o.g. Komponenten dann alle laufen, werde ich die Firmware anpassen.

Sieht sehr gut aus! Sieht auch einfacher zu bauen aus als die SMD Boards. Eine Elektronik mit diskreten Teilen welche auch in Deutschland vernünftig zu beschaffen sind wäre schon eine gute Sache.

Auf der Pololu-Seite gibt es schon eine ganze Reihe Leute, die ebenfalls von vorne angefangen haben. Wäre sicher eine gute Idee, Deine Entwicklung ebenfalls dort einzubringen.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

> Entwicklung ebenfalls dort einzubringen

Gute Idee. Hab's dort eingetragen.

Hier ist noch ein Bild.
Dabei habe ich das LCD abgenommen, damit man die "bare minimum" Version und den Controller sieht.
Außerdem habe ich alle Pololus eingesteckt.

Ein paar Teile sind noch unter dem Controller, der auf einer Fassung sitzt.

Links habe ich eine Nebenplatine hingelegt, die Klemmleisten für den Anschluss der Opto-Endstops und der Temperatursensoren hat, außerdem kommt noch der Transistor für die Extruderheizung dazu. Ein Anschluss ist für ein Solid-State Relais vorgesehen, das das Heizbett ansteuern wird.

Außerdem als Bonus noch ein Anschluss für einen XY-Kreuzknüppel wie bei einer Fernsteuerung, für experimentelle Zwecke (z.B. die Bedienung eines Menüsystems oder die Kalibrierung der beiden Temperatursensoren für Extruder und beheiztes Druckbett). :-)
Vielleicht baue ich auch noch ein paar Tasten an, oder einen Drehencoder.

So ein Menü ist nützlich, weil man dann wie bei einem Papierdrucker in einen Offline-Modus umschalten kann, bei dem man das Gerät lokal bedient, insbesondere zum Testen und Kalibrieren. Aber man könnte sich auch vorstellen, dass man Funktionen zum Ausdrucken einfacher Teile integriert, ohne erst ein Teil mit einer komplizierten Software erstellen zu müssen, z.B. einfache Kunststoffplatten oder Elektronikgehäuse einstellbarer Größe, Standard-Klemmteile o.ä., Dinge, die man halt ab und zu zum Basteln brauchen könnte. (Evtl. könnte man sogar deren STLs per Firmware erstellen und an den Host schicken.)

Der gezeigte Stepper lief bei mir schon stundenlang im Kreis herum. Das zwar noch nicht mit der FiveD-Firmware, die kommt aber noch drauf. Dann sollte der RepRap Host ganz normal damit laufen.

Wenn man die "Eagle-Machbarkeit" der Platine aufgibt, kann man alles problemlos auf einer Europakarte (10 * 16 cm²) aufbauen. Auch das Format kann man sich noch recht günstig als Prototyp fertigen lassen oder auch selbst ätzen, dann wäre etwas mehr Luft auf der Platine, was die Herstellung und auch das Layouten vereinfacht.

Eine Frage ist für mich noch die Kühlung der Stepper. Aber dazu fehlt mir noch die Erfahrung, wie heiß die beim Drucken mit einem Mendel tatsächlich werden. Tipps diesbezüglich sind willkommen. Man kann kleine Kühlkörper aufsetzen, mit einem (ungeliebten) Lüfter oben und unten an den Teilen längsblasen, oder sich einen Kupferstreifen zurechtfeilen, den man mit Wärmeleitpaste oben auf alle 4 Stück gemeinsam aufsetzt. Vielleicht ist aber auch ein großzügigeres Layout im Interesse der Wärmeabfuhr erforderlich. (Diese Lochrasterplatine könnte man dazu ggf. zwischen der unteren Stepperdriver-Klemmleiste und der LCD-Klemmleiste trennen.)

Hier noch für unerschrockene Nachbauer der Schaltplan als Lötbild. ><

Während ich hier sitze
in der Sommerhitze
dringt an meine Ohren
das Zwitschern der Motoren.

Das Microstepping hat schon was. ;-)

Diese Platine [www.thingiverse.com] kommt meinem Aufbau schon sehr nahe. Ich kannte sie nicht, obwohl sie vorher da war.

Dort sind Dateien und eine Stückliste. Allerdings scheint die Platine gewisse Fehler zu haben. Siehe im englischen Forum die Diskussion zu dieser Platine: [forums.reprap.org], und es gibt auch einen Wiki-Eintrag dazu: [objects.reprap.org].

Und hier [www.thingiverse.com] gibt es einseitige Stepper-Treiber der v2.3, also Platinen zum Selbstfertigen.

Und hier sind noch ein paar Dinge, die man beachten sollte, wenn man die schwer erhältlichen "Omnifets" des Originals (teilweise 5-9 Monate Wartezeit) durch leichter erhältliche Standardtypen ersetzen will. [forums.reprap.org]

Hier noch ein Beispiel, wie einer seine Pololus kühlt: mit einer einfachen, aufgeklebten Mutter:
[picasaweb.google.com]

Quote

wie einer seine Pololus kühlt

Es gibt Kühlerchen für RAM-Bausteine: [www.caseking.de]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

peer Wrote:
-------------------------------------------------------
> Und hier sind noch ein paar Dinge, die man
> beachten sollte, wenn man die schwer erhältlichen
> "Omnifets" des Originals (teilweise 5-9 Monate
> Wartezeit) durch leichter erhältliche
> Standardtypen ersetzen will.
> [forums.reprap.org]


Oh mann mach mich nicht schwach... das mag ja noch was geben. Da wär ich ja echt gezwungen meine alten Elektronikkenntnisse wieder aus zu graben... (aber ich hab je noch ne Extruderplatine )

---

Mfg
Wolfgang

Aller Anfang war schwer - Wolfstrap

Reprap-fab.org

Erfahrungen kann man leider schlecht weiter geben, die muss man selber machen.

Nach dem Starten von reprap (der RepRap-Software auf dem PC (Host)) sowie Kompilation+Upload der Firmware (mittels Programmiergerät AVR mk II) in den Controller funktioniert die Kommunikation zwischen PC und Controller.

Nach dem Einschalten des CommsDebug-Modus, wie hier [reprap.org] beschrieben, erhalte ich folgenden Datenaustausch:

Quote
Kommunikation PC <=> Motherboard mit eigener Elektronik:
comms: G-code: N370 M105 *3 dequeued and sent [1621,063s/7ms]
ERROR: GCodeWriter.waitForResponse() - dud response from RepRap:Resend:0 [1621,063s/0ms]
comms: Response: Resend:0 [1621,063s/0ms]
comms: G-code: N370 M105 *3 dequeued and sent [1621,071s/8ms]
comms: Response: ok [1621,071s/0ms]
ERROR: GCodeReaderAndWriter.getETemp() - no value stored! [1621,071s/0ms]
comms: G-code: N371 M105 *2 dequeued and sent [1621,079s/8ms]
ERROR: GCodeWriter.waitForResponse() - dud response from RepRaperial Error: Linenumber (370) is not last + 1 (0), line received: N370 M105 *3 [1621,099s/20ms]
comms: Response: Serial Error: Linenumber (370) is not last + 1 (0), line received: N370 M105 *3 [1621,099s/0ms]
comms: G-code: N371 M105 *2 dequeued and sent [1621,107s/8ms]
ERROR: GCodeWriter.waitForResponse() - dud response from RepRap:Resend:0 [1621,107s/0ms]
comms: Response: Resend:0 [1621,107s/0ms]

Cool!
Da sind zwar Fehlermeldungen, aber was funktioniert, ist dies:
Der PC fordert mit den Codes M105 die Temperature (ETemp = Extrudertemperatur) an, erhält aber nur eine unsinnige Antwort ("dud response"). Die Datenübertragung wird erneut angefordert. Usw.

Dass da keine brauchbaren Werte geliefert wurden, ist normal, da die Sensoren noch nicht richtig angeschlossen sind und die Pinzuweisungen noch nicht stimmen. Aber immerhin läuft die Firmware im Prinzip, und die beiden reden schon miteinander: Dies zu verifizieren war der Zweck dieses Tests. Alles alles soweit bestens.

Das Ergebnis oben ließ mich denken, dass die Firmware vielleicht nicht zur Host-Software passt. Daher habe ich zur Sicherheit die Firmware neu kompiliert, aber nun die Firmware aus demselben Distributionspaket (die 65 MB große Datei von SourceForge) wie die RepRap Java Host Software verwendet und dann in der configuration.h (die man sich aus der configuration.h.dist kopiert) einfach als Motherboardtyp 1 eingestellt.

So sieht die Kommunikation nun aus:

Quote
Wiederholung des Tests mit passender Firmware
comms: G-code: N0 T0 *26 dequeued and sent [0,001s/-1283545758553ms]
comms: Response: ok [0,003s/2ms]
comms: G-code: N1 M113 *1 dequeued and sent [0,011s/8ms]
comms: Response: ok [0,015s/4ms]
comms: G-code: N2 M105 *5 dequeued and sent [0,023s/8ms]
comms: Response: ok T:255 B:401 [0,031s/8ms]
comms: G-code: N3 M105 *4 dequeued and sent [1,539s/1508ms]
comms: Response: ok T:255 B:409 [1,553s/14ms]
comms: G-code: N4 M105 *3 dequeued and sent [3,075s/1522ms]
comms: Response: ok T:255 B:409 [3,079s/4ms]
comms: G-code: N5 M105 *2 dequeued and sent [3,107s/28ms]
comms: Response: ok T:255 B:409 [3,111s/4ms]
comms: G-code: N6 M105 *1 dequeued and sent [4,619s/1508ms]
comms: Response: ok T:255 B:409 [4,627s/8ms]
comms: G-code: N7 M105 *0 dequeued and sent [6,135s/1508ms]
comms: Response: ok T:255 B:409 [6,143s/8ms]
comms: G-code: N8 M105 *15 dequeued and sent [7,651s/1508ms]
comms: Response: ok T:255 B:401 [7,659s/8ms]
comms: G-code: N9 M105 *14 dequeued and sent [7,667s/8ms]
comms: Response: ok T:255 B:401 [7,675s/8ms]
comms: G-code: N10 M105 *54 dequeued and sent [9,183s/1508ms]
comms: Response: ok T:255 B:401 [9,196s/13ms]

Das ist doch schon viel sauberer. Offenbar war mein Verdacht korrekt.
Die Bedeutung der G-Codes ist hier [reprap.org] erklärt.
T0 wählt Extruder 0 aus.
M113 stellt die Extruder-PWM ein. (??)
M105 fragt die Temperaturen ab. Das sind nach wie vor verkehrte Werte, aber die Kommunikation ist sauberer.

Ist doch gut für deine Strickliesel wirklich nicht schlecht . Gratulation !

> M113 stellt die Extruder-PWM ein. (??)
Stellt in dem Moment die "Kraft" der Extrudermotors ein. ( anstatt Poti)

---

Mfg
Wolfgang

Aller Anfang war schwer - Wolfstrap

Reprap-fab.org

Erfahrungen kann man leider schlecht weiter geben, die muss man selber machen.

Quote

Offenbar war mein Verdacht korrekt.

Yupp, die älteren Firmwaren und Hosts kennen keine Bett-Temperatur ("B:xxx"). Wie die Host-Software so programmiert ist, kommen die neueren Versionen nicht mit den Meldungen der älteren Firmwaren klar.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

> Stellt in dem Moment die "Kraft" der Extrudermotors ein. (anstatt Poti)

Ja, nur habe ich einen Stepper, der gar nicht mit PWM betrieben wird. Außerdem ist durch Auswahl von MOTHERBOARD = 1 schon die ganze Extruderplatine (und damit auch die RS485-Kommunikation) deaktiviert.

Ich habe in den RepRap-Preferences jetzt den Parameter Extruder0_ExtrusionPWM(0..1) von -1 auf 0 umgestellt.
Außerdem in der Firmware eingestellt, dass nur ein Extruder da ist (Standard sind 2 Stück).
Jetzt sagt der Host dem MoBo:

> comms: G-code: N1 M113 S0.0 *92

wobei das S0.0 (Stand vorher nicht dort, s.o.) die PWM deaktiviert.

Komischerweise blockiert er dann aber. Das kommt mir irgendwie verkehrt vor, weil die Umstellung - meiner bloßen Vermutung nach - nur eine Variable umsetzen sollte. Kann aber auch sein, dass ich etwas von der Firmwarefunktion noch nicht verstehe.

Aber meine nächste Aufgabe ist, die Pinzuordnungen meinem Aufbau entsprechend richtig zu definieren. Vielleicht löst das ja auch dieses Problem.

Hinweise zur Pin-Umkonfiguration:

In der Firmware gibt es eine Datei pins.h, in der Pin-Namen bestimmten Nummern zugeordnet sind. Diese Nummern sind "virtuelle Pinbezeichnungen", die ihrerseits in der Arduino-IDE in einer Hardware-Beschreibungsdatei konkreten Pins des Controllers zugeordnet werden. Es handelt sich also um ein zweistufiges Mapping.

Die zweite Mapping-Stufe (virtuelle "Arduino-Pins" auf RepRap-Pinfunktionen) erfolgt in der Datei pins.h der Firmware. Dabei ist allerdings zu beachten, dass das Mapping für die Version mit MOTHERBOARD == 1 selbst Fehler (Doppelbelegungen) und Unklarheiten (fehlende Dokumentation) enthält, die nun also gelöst werden müssen.

Die erste Mapping-Stufe (Controller-Pins auf virtuelle "Arduino-Pins") erfolgt in der Arduino-IDE.
Wie das gemacht wird, sieht man an der Datei:
[...]/arduino-0018/hardware/arduino/cores/arduino/pins_arduino.c (zusammen mit pins_arduino.h).

In meinem Fall habe ich mir eine eigene Hardware mit dem Namen RepRap (wird in einer der Konfigurationsdateien festgelegt) definiert. Die Daten für die Hardwarebeschreibung habe ich zunächst aus der Hardwarebeschreibung für das Sanguino-Board kopiert und werde sie gemäß meiner Hardware umkonfigurieren.
Diese Dateien liegen nun in der Arduino-IDE im Verzeichnis:
[...]/arduino-0018/hardware/RepRap

(Ähnlich liegen die Dateien für Sanguino, die als Beispiel dienen können, im Verzeichnis:
[...]/arduino-0018/hardware/Sanguino,
wobei immer auch alle Unterverzeichnisse und deren Dateien kopiert und nach Bedarf angepasst werden müssen.
Ähnlich wiederum gibt es weitere Dateien in weiteren Verzeichnissen für die Standard-Arduino-Boards (s.o.). Durch Vergleichen kann man herausfinden, was wie angepasst werden muss. In den Dateien gibt es auch einige erläuternde Kommentare und Zuordnungsdiagramme.
Außerdem muss ggf. der Bootloader für die Übertragung der Software in den Controller-Chip angepasst werden, oder die Arduino-Software auf Nutzung eines Programmiergeräts umgestellt werden -- was ich in meinem Fall getan habe.)

Die Sanguino-Dateien dienen dabei also als Vorlage, was besonders einfach ist, da ich auf meiner Hardware denselben Prozessor verwende. Somit sind besonders wenig Anpassungen erforderlich.

Durch dieses Kopieren und meine bisherigen Anpassungen habe ich jetzt im Menü Tools der Arduino-IDE für die Option Board die Auswahlmöglichkeit RepRap.

In der Datei:
[...]/arduino-0018/hardware/RepRap/cores/arduino/arduino.c
müssen nun die Pinbelegungen an die Verhältnisse meiner Hardware angepasst werden.

Man muss dies nicht alles verstehen, wenn man nicht selbst eine Hardware in die Software integrieren will. Wenn erstmal alles läuft, wird dies alles nicht schwerer sein als die Anpassungen für das Sanguino-Board, die im RepRap-Wiki beschrieben ist. Ich schreibe diese Dinge hier also vor allem für andere Entwickler auf.

Edited 1 time(s). Last edit at 09/03/2010 05:54PM by peer.

Hier noch mal ein Bild, das einen anderen Test zeigt:



Hier läuft meine Testsoftware.
In der zweiten Zeile sind ein Umdrehungszähler (0), die Analogwerte eines angeschlossenen Kreuzknüppels (X und Y) und schließlich der Analog(roh)wert eines angeschlossenen Thermistors.
Die erste Zeile weist aus, dass die Software 894866 Sekunden (also > 10 Tage) durchgängig gelaufen ist (das "o" ist der Anfang von "on", das wegen der 6-stelligen Zahl nur halb sichtbar ist).

Wenn das auch später alles so zuverlässig laufen sollte =>

So schön das alles läuft, ich habe heute unerwartet starke Probleme mit der Firmware entdeckt.

Die ist für verschiedene Hardwareversion einstellbar, aber wenn man einzelne Komponenten davon mischen muss -- wie es hier erforderlich ist --, dann muss man weitgehende Eingriffe in die ganzen Auswahlvariablen vornehmen.

Ein Problem ist, dass es zwei Extrudervarianten gibt:

Quote
Firmware-Varianten:
static extruder ex0(
EXTRUDER_0_MOTOR_DIR_PIN,
EXTRUDER_0_MOTOR_SPEED_PIN,
EXTRUDER_0_HEATER_PIN,
EXTRUDER_0_FAN_PIN,
EXTRUDER_0_TEMPERATURE_PIN,
EXTRUDER_0_VALVE_DIR_PIN,
EXTRUDER_0_VALVE_ENABLE_PIN,
EXTRUDER_0_STEP_ENABLE_PIN,
E0_STEPS_PER_MM);

static extruder ex0(
EXTRUDER_0_STEP_PIN,
EXTRUDER_0_DIR_PIN,
EXTRUDER_0_ENABLE_PIN,
EXTRUDER_0_HEATER_PIN,
EXTRUDER_0_TEMPERATURE_PIN,
E0_STEPS_PER_MM);

Die erste wird bei Motherboard-Version 1 verwendet, die zweite bei Version 3. Aber man kann nicht einfach auswählen, sondern diese Versionsvariablen haben Auswirkungen auf viele andere Dinge.
Wenn man das alles von Hand umprogrammiert, hat man am Ende einen Fork, also eine Insellösung, was ja danach dann ein Update-Alptraum ist.
Wenn man das gemeinsam mit der Kerngruppe verändert, gibt es eine Chance, die Insellösung zu vermeiden und eine universellere Auswahlsache zu programmieren. Machbar ist es sicher, und der Buzz arbeitet auch schon an sowas. Aber seine Arbeit ist noch nicht fertig, und ich habe dafür momentan nicht die Zeit. Freiwillige / Nachbauer können sich da sicher einklinken.

Mit meinen zeitlichen Möglichkeiten fahre ich momentan sicher besser, wenn ich (auch jetzt noch) einfach auf die Arduino Mega-Lösung umsteige. Die Hardware dafür ist schnell gestrickt; sicher schneller, als ich als einsamer Programmierer für den Firmware-Umbau bräuchte. Ich werde dies daher wohl erstmal auf Eis legen. Wenn der Buzz fertig ist mit dem Umbau oder sich eine andere geeignete Lösung zeigt, kann ich das Board ja reaktivieren. Einige Infos dazu stehen ja auch schon in diesem Thema.

Quote

Ein Problem ist, dass es zwei Extrudervarianten gibt:

Die erste Variante ist offensichtlich für den Extruder mit Gleichstrommotor, die Zweite für den mit Schrittmotor. Da beide Varianten bereits genutzt werden, müsste das eigentlich recht einfach umzuschalten sein. Allerdings kann ich den Code für die Schrittmotorvariante nirgendwo im Subversion Repository finden. Wo hast Du das denn her?

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Das ist alles in derselben Firmware, und zwar habe ich mit dafür das aktuelle Gesamtpaket von SourceForge geholt. Die Varianten werden mit verschiedenen Schaltern aktiviert (MOTHERBOARD = ...). Aber wie gesagt, damit wird jeweils ein Haufen anderes Zeugs umgeschaltet, und das macht es kompliziert.

Eine Möglichkeit wäre noch FiveD on Arduino. Das kennt weder Gleichstrommotor noch Extruderkarte, müsste für Dich also recht gut passen.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Das habe ich auch schon überlegt, aber kaum Infos darüber gefunden. Das ist ja auch ein Fork, oder? Ist es überhaupt möglich, sowas aktuell zu halten? Oder was sind die Entwicklungsziele davon? Ich sorge mich einfach, dass es mit einer Insellösung letztlich mehr Arbeit gibt, als wenn man einfach den offiziellen, von der Kerngruppe betreuten und mit der Host-Software synchronisierten Kram nachbaut.

Und diese ganzen Softwarefragen sind sehr zeitintensiv. Da muss man sich für jeden Kleinkram, der dann so anfällt, ja erst wieder einarbeiten, das kann dann insgesamt Tage dauern. Die andere Hardware hingegen habe ich in ein paar Stunden auf- oder umgebaut. Ist letztlich viel überschaubarer.

> Das ist ja auch ein Fork, oder?

Da ist alles von Grund auf neu geschrieben. Kein C++, keine Fliesskommaberechnungen.

> Ist es überhaupt möglich, sowas aktuell zu halten?

Bislang halten sich die Änderungen auf der Firmware-Seite doch recht in Grenzen. Ein, zwei Mal im Jahr ein neues Feature wie Heated Bed oder vermutlich bald Support-Material und das war's dann. Dass man den Code zum Teil abschreiben kann macht die Sache auch nicht gerade komplizierter. Wenn der Triffid dann noch lernt mit Git umzugehen, dann ist das das beste Projekt der Welt

> Oder was sind die Entwicklungsziele davon?

Die effektivere Nutzung der vorhandenen Hardware bei gleichem Funktionsumfang. C++ ist aus Prozessorsicht umständlich, Fliesskommaberechnungen kosten eine Menge Zeit und in den Interrupt-Routinen sollte man mit jedem einzelnen Prozessortakt geizen. Das Ergebnis ist recht gut gelungen.

> Ich sorge mich einfach, dass es mit einer Insellösung letztlich mehr Arbeit gibt, als wenn man einfach den offiziellen, von der Kerngruppe betreuten und mit der Host-Software synchronisierten Kram nachbaut.

Offensichtlich ist ja "offiziell" nicht gleich "öffentlich". Vielleicht liege ich falsch, aber für mich sieht das so aus, als ob da irgendwo im virtuellen Hinterzimmer, innerhalb der "Core"-Entwicklergruppe was unter Ausschluss der Öffentlichkeit gebastelt wird. Du sagst Du hättest Deinen Code von SourceForge und dort hab ich den meinen auch her. Damit stimmt der Inhalt des Repositories nicht mit dem Inhalt der Download-Pakete überein. Irgendwie schmeissen die hier bei RepRap alles über den Haufen, was ich die letzten 15 Jahre bei diversen Open Source Projekten gelernt habe.

Unter dem Strich hat man also gar keine andere Möglichkeit als selber einen Fork anzulegen. FiveD on Arduino hat immerhin schon eine Hand voll Benutzer und mehr als einen Entwickler, man ist also nicht allein.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

> Damit stimmt der Inhalt des Repositories nicht mit dem Inhalt der Download-Pakete überein.

Huch? Das ist da doch alles drin. Die eine Version für MOTHERBOARD == 1 und die andere für MOTHERBOARD == 3. Diese beiden Varianten ziehen sich dann durch mehrere Dateien.

Die offizielle Firmware erscheint mir in manchen Punkten noch nicht so ganz ausgereift. Auch die Hard-Codierung der Timing-Konstanten gefällt mir nicht. Meine Hardware hat einen 20-MHz-Quarz, aber bei der Programmierung müsste man einige Konstanten neu berechnen. Das ist nicht schön gelöst. Gibt noch andere ähnliche Sachen.

Der Buzz arbeitet an einem Fork, der woanders auf github liegt, wo er die Auswahlstruktur für die Hardwares umstellen will. Ich hab das ja auch auf -dev geschrieben (hast Du vermutlich gesehen). Da tut sich schon was, und auch öffentlich, und vermutlich wird das später in die offizielle Firmware eingehen. Ist halt noch ein eher kleines Projekt ohne viele Kommissionen oder einem Linus als Chef, und das dauert halt alles irgendwie. Für Adrian scheint auch einiges neu zu sein, von Controllern bis zu github, aber er hält sich doch wacker. Mit Java hat er wohl mehr Erfahrung.

Die Beschreibung von eurer Reimplementierung klingt sehr gut und sehr sinnvoll. Ich hatte beim Lesen der Dialoge auch schon das Gefühl, dass das Leute machen, die wissen, was sie tun.
Ich hatte auch mal ein Projekt auf Arduino angefangen, aber dann später alles separat gemacht in einem eigenen Projekt ohne die Arduino-Libraries. Die Umstellung war schwierig, weil die IDE einem vieles abnimmt (Makefiles! Hardware-Initialisierung! Fuses!), aber hinterher war ich sehr froh, weil alles viel besser lief und man volle Kontrolle über alles hat. Ein Geigerzähler, der schon monatelang völlig problemlos nonstop läuft. Der PC, der die Daten übernehmen soll, ist viel unzuverlässiger.

peer Wrote:
-------------------------------------------------------
> Huch? Das ist da doch alles drin.

Vielleicht blick' ich's auch einfach nicht. Den von Dir zitierten Code kann ich zumindest mit "grep" nicht finden. Bei der letzten Zählung habe ich 8 (acht) Varianten der Firmware im Repo gefunden, danach habe ich mich mit aus diesem Grund dem Werk vom Triffid zugewandt.

> Meine Hardware hat einen 20-MHz-Quarz, aber
> bei der Programmierung müsste man einige
> Konstanten neu berechnen.

Dann soll der Buzz mal beim Triffid rein schauen, dort ist das schon gelöst.

> (Makefiles! Hardware-Initialisierung! Fuses!)

Seit gerade eben geht's wieder ganz normal mit der Arduino-IDE.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> wie einer seine Pololus kühlt
>
> Es gibt Kühlerchen für RAM-Bausteine:
> [www.caseking.de]
> m-Kuehler-Heat-Spreader/Zalman-VGA-Ram-Heatsinks-Z
> M-RHS1::1938.html

Ich benutze diese:

Ram Heatsink

Sind mit ihren Maßen (10mm x 10mm x 14mm) super geeignet!

> Den von Dir zitierten Code kann ich zumindest mit "grep" nicht finden.

Weil ich den Whitespace umformatiert habe, um die Parameter besser vergleichen zu können.

> Kühlerchen für RAM-Bausteine [Enzotech MOS-C10]

Oh ja, die gefallen mir.