ThirtyTwo - Eine 32Bit-Firmware für RepRap 3D-Drucker

Hallo "Glatzemann",

das was du in deinem letzten Absatz ansprichst, ist meiner Meinung nach wohl genau der entscheidende Ansatz in die richtige Richtung.

Der Umstand, das für jedes System eine eigene Konfiguration erforderlich ist, macht es ja erst aus, das die FW so Umfangreich und "Riesig" wird.

Mal ne dumme Frage, warum nicht für jedes System eine Eigene? Autark, jeder sucht sich die FW aus die er braucht, mehr nicht und nicht weniger.
Einfacher für den Benutzer und auch für den Programmierer, weil alles übersichtlicher ist.

Versteh mich bitte nicht falsch, ich kritisiere nicht deine Arbeit. Möchte nur mal einen Gedanken zum Thema in die Runde werfen.

Gruß Didi

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Ok, dann liege ich da ja nicht sooo verkehrt :-)

@Didi: Ich finde die Idee ehrlich gesagt nicht wirklich schlecht. Aus Anwendersicht würde dies sicherlich alles sehr vereinfachen. Wenn man sich nur mal eine Firmware-Konfiguration (z.B. Repetier) anschaut und da alles rauswirft, was für den eigenen Drucker uninteressant bzw. nicht verfügbar ist, dann wäre die Konfiguration schon deutlich kleiner.

Danke für diese Idee, ich werde das ernsthaft in Betracht ziehen und mir Gedanken darüber machen.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Kannst ja ähnlich machen wie Repetier mit der Due-Version und der AVR-Version. Ne Batch-Datei oder so, die die Ordner synchronisiert und nur das wichtigste mitnimmt. Aber ich denke du willst doch eh für jede Kinematik ne eigene Datei basteln. Und ob du nun 100 unterschiedliche Ordner hast oder 10 verschiedene Einträge in der config macht ja nun auch keinen Unterschied. Eigentlich brauchst ja nur ne delta-config, corexy-config und wasweißich-config. Macht Repetier und Marlin afaik auch so. Zumindest habe ich in meiner Config für CoreXY keine Delta-Sachen mit drinne.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Die Variante mit dem Ordner synchronisieren bei Repetier finde ich ja ehrlich gesagt sowas von bescheiden. Ich frag mich schon die ganze Zeit, was dieser Quatsch soll. Verursacht bei jeder Änderung, die man ins Repository commiten will Aufwand. Ätzend und unnötig.

Ja, ich wollte für jede Kinematik eine eigene Datei schreiben. Im Endeffekt, wenn man die Software von Grund auf anständig aufgebaut hat und die spezialisierten Teile entsprechend "abkapselt", dann kann man mit unterschiedlichen Make- oder Projektfiles (je nachdem welche Umgebung man verwendet) einfach unterschiedliche Versionen kompilieren. Und da ich ja sowieso für den End-Anwender nur Binaries anbieten wollte, liegt der Aufwand und die Komplexität dafür ja ausschliesslich bei mir :-)

Zum Config-File: Wenn man bei Repetier den Konfigurator nimmt, dann ist da kaum was von den anderen Kinematiken drin. Leider hinkt der Konfigurator immer etwas hinterher und man kann auch nicht alles darin konfigurieren. Und da man dort die Konfig-Files auch nur einlesen kann, wenn man diesen JSON-Kommentar in der Konfig anpasst, bin ich davon komplett weg gegangen. Und in der "kompletten" Config aus den Quellen hast du dann sowas drin:

/* Define the type of axis movements needed for your printer. The typical case
is a full cartesian system where x, y and z moves are handled by separate motors.
0 = full cartesian system, xyz have seperate motors.
1 = z axis + xy H-gantry (x_motor = x+y, y_motor = x-y)
2 = z axis + xy H-gantry (x_motor = x+y, y_motor = y-x)
3 = Delta printers (Rostock, Kossel, RostockMax, Cerberus, etc)
4 = Tuga printer (Scott-Russell mechanism)
5 = Bipod system (not implemented)
Cases 1 and 2 cover all needed xy H gantry systems. If you get results mirrored etc. you can swap motor connections for x and y.
If a motor turns in the wrong direction change INVERT_X_DIR or INVERT_Y_DIR.
*/
#define DRIVE_SYSTEM 0

// ##########################################################################################
// ##                               Calibration                                            ##
// ##########################################################################################

/** Drive settings for the Delta printers
*/
#if DRIVE_SYSTEM==3
    // ***************************************************
    // *** These parameter are only for Delta printers ***
    // ***************************************************

/** \brief Delta drive type: 0 - belts and pulleys, 1 - filament drive */
#define DELTA_DRIVE_TYPE 0

#if DELTA_DRIVE_TYPE == 0
/** \brief Pitch in mm of drive belt. GT2 = 2mm */
#define BELT_PITCH 2
/** \brief Number of teeth on X, Y and Z tower pulleys */
#define PULLEY_TEETH 20
#define PULLEY_CIRCUMFERENCE (BELT_PITCH * PULLEY_TEETH)
#elif DELTA_DRIVE_TYPE == 1
/** \brief Filament pulley diameter in milimeters */
#define PULLEY_DIAMETER 10
#define PULLEY_CIRCUMFERENCE (PULLEY_DIAMETER * 3.1415927)
#endif

Aber man findet zwischendurch auch sowas:

// Delta robot radius endstop
#define max_software_endstop_r true

Man wird halt teilweise etwas davon erschlagen.

Ich denke aber auch, daß man das etwas besser aufteilen kann. Man könnte ja einmal eine Konfiguration nehmen, in der die Hardware beschrieben wird (Motoren, Thermistoren, Board, Pinne etc.) und dann eine weitere, so wie du es geschrieben hast, in der die Kinematik und die restlichen Druckerparameter beschrieben werden. Da findet man sicherlich einen übersichtlicheren und anständigen Weg.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

@ "Wurstnase",

wenn man so wie du, tiefer in der FW -Konfiguration ist, mag das ja kein

Problem sein. Wenn ich da was raus lösche, klappt anschließend nichts mehr.
So geht es bestimmt Vielen.
Also bleibt das Überflüssige drin. Also nix mit übersichtlich.

Gruß Didi

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Quote

Und da ich ja sowieso für den End-Anwender nur Binaries anbieten wollte ...

Hm, das halte ich für suboptimal
Für die Leute, die sich ihren eigenen Drucker stricken und nicht die Konzepte anderer nachbauen, gibt es dann höchstwahrscheinlich keine Firmware.

Ich weiß nicht mehr, bei welcher Firmware das war, aber ich habe einmal einen Konfigurator gesehen, wo man sich seinen Drucker kwasi selbst zusammen stellen konnte (die Umsetzung war eher zum abgewöhnen, aber die Idee hat mir gefallen!). Semantisch gibt es ja für einen Drucker nur 4 Typen (X-, Y-, Z- und Extruder-Stepper), wo aber jetzt wieviele Stepper verbaut wurden ist jucke.
Dort konnte man jeden Stepper einzeln zufügen und dann auswählen: 1. Stepper ist für die X-Achse, 2. Stepper für die Y-Achse, 3. Stepper ist auch für die Y-Achse, dann noch 3 für die Z-Achse usw.
Wer mag könnte dann noch 6 Extruder dazu definieren ...

Wäre schön, wenn dann am Schluss sowas wie eine Make-Datei rausfallen würde, mit der man dann die genau passende Firmware übersetzen könnte
Ich bin ein Fan von autarken Systemen die (z.B. nach einem git clone) auch lokal ohne nette Inder funktioneren.

Auf diese Weise könnte man auch die unterschiedlichen Sensoren handhaben, genauso wie die unterschiedlichen Heizbettansteuerungen ...

Nein, nein. Jeder wird seinen Drucker, soweit es Sinn macht, konfigurieren können wie er möchte. Die "Verschaltung" der Motoren und wofür die verwendet werden habe ich bereits fertig entwickelt. Man kann in meinem System ganz einfach über M-Codes zur Laufzeit festlegen, welcher Motor wofür verwendet werden soll, in welche Richtung er sich drehen muss, ob das Enable-Signal invertiert ist, wieviele Steps/mm der Motor benötigt, etc. Dabei kann man auch für eine Achse mehrere Motoren verwenden. Stand heute kann man sogar die Kinematic zur Laufzeit verändern.

Ich fände es halt cool, wenn man mit bossac bzw. einer Funktion im Host-Programm die Firmware-Binary auf das Microcontroller-Board laden kann, ohne das eine Entwicklungsumgebung auf dem Rechner des Anwenders installiert sein muss. Das hat den Vorteil das es einfacher für den Anwender ist. Er lädt das Host-Programm bzw. das Firmware-Konfigurationstool auf seinen Rechner. Damit konfiguriert er alles wie es notwendig ist und das Teil lädt die passende Firmware aus dem Internet oder einem lokalen Verzeichnis. Das wird auf das Board geladen und fertig.

Das bedeutet natürlich nicht zwangsweise, daß man - wenn man den Quellcode und die passende Entwicklungsumgebung hat - sich nicht auch selbst Binaries kompilieren kann.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

ups, da bist du mir zuvor gekommen!



Hallo "Brummi",

hier geht es ja nicht um die Anzahl der Stepper die eingestellt werden sollen.

> ... Semantisch gibt es ja für einen Drucker nur 4 Typen (X-, Y-, Z- und Extruder-Stepper), wo aber jetzt wieviele Stepper verbaut wurden ist jucke. <

Hier ging es um die unterschiedlichen Systeme, egal wieviele Stepper angeschlossen sind. Es geht um die Steuerung und das Prinzip der Programierung.

Und nicht zum Schluss auch darum etwas fortschrittliches für die zukünftigen Projekte zu Keieren.

Ich find das voll gut und bin da genau wie Glatzemann ganz dabei, wenn es heißt mal die alten Zöpfe abzuschneiden.

Gruß Didi

1-mal bearbeitet. Zuletzt am 06.11.15 12:00.

---

Aktuell:
Selfmade-Drucker mit Wasserkühlung u. Carbon-Wechselplatte,
Selfmade-Drucker ( Nr. 7 in Arbeit . . . ), CAD Creo 3.0/4.0 , Mac, Cura, Prusa Slicer . . .

Hey Didi,

wie kommst Du denn auf das schmale Brett, dass ich ein Verfechter alter Zöpfe wäre

Nee, nee - da könntest Du falscher nicht liegen.
Es gab bislang viele unterschiedliche Aspekte in der Diskussion, ich bin nur auf enige eingegangen.
Wenn es nicht gerade offensichtlich ist, auf was ich mich beziehe, dann zitiere ich auch

In meiner letzten Antwort wollte ich nur andeuten, dass man heute ja garnicht wissen kann, was ein Anwender übermorgen für einen Drucker baut. Deshalb plädierte ich für Flexibilität.
Die hat Glatzemann ja schon umgesetzt, also ist meine letzte Antwort schon überholt

Quote

Ich fände es halt cool, wenn man mit bossac bzw. einer Funktion im Host-Programm die Firmware-Binary auf das Microcontroller-Board laden kann, ohne das eine Entwicklungsumgebung auf dem Rechner des Anwenders installiert sein muss.

Da bin ich voll bei Dir.
Es gibt nix schlimmeres, als Arduino und Co, die einen "zwingen" sich eine bestimmte Entwicklungsumgebung anzutun.
Wenn Du die Schnittstellen unterstützt, die der Hersteller vorsieht, dann kann jeder sich aussuchen, wie er seine Firmware auf die Hardware bringt.

Genau...

Standards nutzen, Anwender möglichst wenig einschränken, aber gute und einfache Vorschläge machen :-)

EDIT: P.S: Aber nichts gegen die Arduino IDE. Die ist zwar nicht toll, bietet aber einen hervorragenden Einstieg in die Programmierung und erleichtert vielen das Leben deutlich. Versuch mal z.B. Eclipse oder Visual Studio so zu konfigurieren, daß man auf ein MC-Board laden kann. Das ist echt nicht ohne, wenn man das mit dem Arduino-Installer vergleicht :-)

1-mal bearbeitet. Zuletzt am 06.11.15 12:19.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

... ich habe momentan von der Marlin4Due-Firmware 8 oder 9 Varianten auf den Rechnern, mit denen ich verschiedene Geräte oder Varianten flashe - das ist für mich einfacher zu handeln, als das über eine Config einzustellen ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Ich flashe meinen Due nur mit Eclipse.
Arduino IDE runterladen. Eclipse von Baeyens installieren. Und dann ist man quasi durch, wenn die Firmware das unterstützt, wie Marlin4Due und Reprap-Firmware.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

@VDX: Die Idee ist ja, daß du nur noch ein Binary für alle Geräte hast. Das muss nur dann geflashed werden, wenn es eine neue Version gibt. Wenn du etwas an der Konfiguration ändern willst, dann kannst du das per M-Codes machen, über die serielle Schnittstelle eine neue Konfiguration hochladen oder einfach eine Datei auf der SD-Karte austauschen. Ist vielleicht in deinem speziellen Fall eine etwas umständlichere Arbeitsweise, aber ich denke, daß dies für den "Otto-Normal-Anwender" so einfacher ist.

@Wurstnase: Das möchte ich definitiv auch ermöglichen, aber ich möchte den Anwender halt nicht zwingen, daß er extra Eclipse installieren muss, nur um zu flashen.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

... das Problem ist dabei, daß ich sowohl in der Marlin4Due-Firmware, als auch in Pronterface/Printrun einiges an Programmänderungen mache, nicht nur Konfigurationsvarianten

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Na dann müsstest du die in meiner Firmware auch selbst machen und dir selbst Binaries kompilieren. Wenn du sie einsetzen möchtest. Wäre doch kein Problem

Aber auf jeden Fall ein interessantes Szenario, welches ich gerne im Auge behalten würde...

1-mal bearbeitet. Zuletzt am 06.11.15 14:49.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Halb-OT:
Btw. Viktor. In der fastio.h ist das "|" zu viel. PIO_SODR ist atomic. Das könnte ggf. auch Probleme machen, wenn man es nicht ändert. [github.com]
Zudem wird das Write dann quasi um Faktor 3 schneller

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Moin moin,

Quote

Versuch mal z.B. Eclipse oder Visual Studio so zu konfigurieren, daß man auf ein MC-Board laden kann.

Lach - ich würde nicht mal im Traum auf so eine Idee kommen.

Bin mit Unix aufgewachsen. Dort ist die Filosophie: jedes Programm kümmert sich genau um eine Aufgabe. Nicht mehr nicht weniger. Die eine Aufgabe macht es gut und passt sich im Verhalten in die Unix-Philosophie ein (Ein-/Ausgabe-Umleitung, Aufruf, etc.). So kann sich der Anwender dann selbst die Werkzeuge zusammen stellen, die er braucht (Pipes bei Befehlen).
Das war schon in den 80er Jahren so flexibel, dass Unix vielen anderen Systemen überlegen war.
Bei Linux ist dann diese Filosophie aufgeweicht und pervertiert worden, bis dann so ein Moloch wie die Bash oder jetzt SystemD entstand
Eclipse ist ähnlich erfolgreich, weil es die Idee mit Plugins aufgreift und umsetzt. Ich mag Eclipse ...

Was das Flashen angeht - es gibt viele kleine Tools, die das hervorragend können. Es gibt für mich keinen Grund, warum eine IDE flashen können sollte. Ich bin irgendwann über burnomat gestolpert und hängen geblieben (zumindest im AVR-Kontext). Das ist ein Tool, welches man auch nach Jahren (der Abstinenz) wieder einsetzen kann, ohne vorher Handbücher wälzen zu müssen

Quote

Die Idee ist ja, daß du nur noch ein Binary für alle Geräte hast.

So sehr ich auch Respekt vor Deiner Arbeit habe, so suboptimal finde ich diesen Ansatz.

Wie realistisch ist es, dass aus einem Delta plötzlich ein CoreXY wird oder umgekehrt?
Wenn jemand wirklich seinen Drucker so stark umbaut, dass plötzlich eine andere Kinematik zum Tragen kommt, ist es doch viel sinnvoller, auch eine neue Firmware zu aktivieren. Anders herum halte ich es für wahrscheinlicher, dass man (in dem Wissen, dass die Firmware alles kann) nach so einem Umbau die Software unverändert lässt und der Drucker dann anfängt Samba zu tanzen

Auch wenn es sehr flexibel ist, alles per GCode konfigurieren zu können - führt es doch dazu, dass jeder Drucker viel zu viel ungenützen Code mit herum schleift (der auch noch aus Versehen aktiviert werden könnte - von böswilligen Eingriffen ganz zu schweigen). Das ist nicht nur eine Resourcenverschwendung (wäre auf einem AVR sicherlich nicht durchführbar) sondern auch ein Risiko, dass Fehler zu völlig abstrusem Verhalten führen könnten.
Selbst wenn die 32bitter soviel Platz böten, dass nie ein Resourcenengpass entsteht, halte ich die bedingte Übersetzung für viel sinnvoller, sicherer und bässer.
So vie VW-Styler es vorschlug: für jeden Drucker eine (separate) Firmware.
Ich denke auch bei GCodes gilt: weniger ist mehr.

Bei der Konfiguration ist es doch egal, wie komplex sie ist, solange man die Komplexität vor dem Anwender verstecken kann. Es gibt viele einfache Werkzeuge, mit denen eine UI gestrickt werden kann, die die Komplexität in logische Schritte aufteilt.

Wenn das jetzt alte Zöpfe sind, dann bin ich wirklich ein Fan von alten Zöpfen

Hallo,

ich bin ja keine Programmiererin, sondern nur eine Administratorin.

@ Brummi:

Nichts gegen Unix oder Linux, aber wenn man erst eine Firmware mit einem "Make" compillieren lassen und dann auf den Controller übertragen lassen würde, würde man alle, die kein Wissen über Linux oder nur Linux-Anwender sind, doch überfordern und auch gleich die Win-Leute außen vor lassen.

Und noch ein Nachtrag zu Marlin:

Ich finde nicht, dass Marlin schlecht wäre, aber als ich z.B. meinen Velleman auf eine Ramps 1.4 umstellte, die Erfahrung machen dürfen, dass Marlin einige Probleme macht, die erst Wurstnase für mich ausräumen konnte (An dieser Stelle nochmals vielen Dank).

Zuerst lief der Pieper am Display ständig und egal, was ich an der configuration.h editierte, das Ding piepte weiter. Und als ich dann ABL aktivieren wollte, meldete die Arduino-IDE, dass da bestimmte Abhängigkeiten nicht aufgelöst werden konnten.

Das alllein zeigt aus meiner Sicht die Probleme mit Marlin: z.T. unübersichtlich (Ich habe einen 20 Zoll Monitor und konnte in der IDE nicht alle Untermenüs der Firmware anwählen), dann, um bestimmte Dinge zu finden, muss man unendlich suchen.

Da ist der Ansatz von Glatzemann interessanter, da er vielleicht genau diese Features eben nicht einsetzen will.

Liebe Grüße,

Rebecca

---

EX: Velleman K8200, nun Anet 8 Plus

Hi,

Quote

ich bin ja keine Programmiererin

um sich Gedanken über Sicherheit zu machen, muss man kein Programmierer, sondern eher ein wenig paranoid sein

Quote

Nichts gegen Unix oder Linux, aber wenn man erst eine Firmware mit einem "Make" compillieren lassen und dann auf den Controller übertragen lassen würde, würde man alle, die kein Wissen über Linux oder nur Linux-Anwender sind, doch überfordern und auch gleich die Win-Leute außen vor lassen.

Hm, scheint irgendwie Mode zu sein, mich falsch zu interpretieren.
Ich rede von Philosophie und plötzlich geht es um Ausgrenzung?

Als M$ noch kein Visualstudio hatte, da war es selbstverständlich, dass beim C-Compiler auch ein make-Prozessor dabei war
Wer sich nicht die Gigabytes des Visualstudios auf Platte spülen will, kann z.B. WinAVR einsetzen. Da ist selbstverständlich auch ein make dabei.
Ähnliche Tuhls wird es auch in der 32bit Welt geben ...

avrdude und Co gibt es auch unter Windows. Gibt also keinen Grund, warum man sich eine IDE zum Aufspielen einer Firmware installieren muss ...

Quote

Ich finde nicht, dass Marlin schlecht wäre

Nur weil ich Arduino nicht mag, heißt das nicht, dass ich Marlin schlecht finden würde. Ganz im Gegenteil.
Ich verwende auch ein Exemplar des weltschlechtesten Druckers und da läuft natürlich Marlin drauf

... aber wir sind uns sicher einig: ohne den unermüdlichen Einsatz von Wurstnase wäre Marlin kaum der Rede wert

Quote

(Ich habe einen 20 Zoll Monitor und konnte in der IDE nicht alle Untermenüs der Firmware anwählen), dann, um bestimmte Dinge zu finden, muss man unendlich suchen.

Es gibt unendlich viele Beispiele, wie man es nicht machen sollte.
Da macht Glatzeman es schon richtig indem er das umsetzt, was er für richtig hält

Hallo,

gibt es irgend was Neues von dem Firmware Projekt zu berichten?

Gruß
Gerd

Ich träume von einem git Repository mit z.b. div Branches, ich lade mir die fw (kompiliert, optinal source) und config herunter, mache meine Einstellungen, kopiere alles auf meine SD und fertig.
In den Branches kann dann jeder Druckermodifizierer (Sparkcube, Wurstcube, Skimmy v3) seine Konfig betreuen und teilen.

Das ich eine IDE benötige, diese noch erweitern und einstellen muss um eine Drucker FW zu kompilieren und auf das Board zu flashen, finde ich nicht schön.
Dann lieber fertige FW, auf die SD und der Drucker/Bootloader flasht sie selber.

1-mal bearbeitet. Zuletzt am 16.01.16 08:18.

---

Ich bin ein Maker , mein erstes Teil. [www.thingiverse.com]

Ich verfolge das Projekt gespannt. Endlich mal wieder kein Fork, sondern eine "cleane" Eigenentwicklung ohne Altlasten. 32 bit ist eben die Zukunft.

Es gibt (leider) nicht viel Neues vom Projekt zu berichten, da ich die letzten Wochen mit meinem "kleinen Zwischenprojekt" FSR Board und dessen Firmware sehr beschäftigt war und daher hierfür nicht viel Zeit geblieben ist :-(

Ich habe allerdings ein paar kleine Erfolge: Der G-Code-Parser läuft mittlerweile sehr stabil, da ich diesen in die Firmware für das FSR Board eingebaut habe und er dort hervorragende Dienste leistet. Dabei sind noch ein paar kleine Probleme zu Tage getreten, die ich aber allesamt lösen konnte. Der Command Buffer bzw. der Ring-Buffer laufen mittlerweile ebenfalls sehr stabil. Teile davon konnte ich ebenfalls in der FSR Board Firmware weiterverwenden und für andere Teile habe ich einen Simulator entwickelt, der sehr gute Testergebnisse "herauskitzeln" konnte. Die Step-Generierung ist ebenfalls sehr weit fortgeschritten und liefert bereits gute Ergebnisse. Lediglich bei den Beschleunigungsrampen bin ich noch nicht ganz zufrieden.

Alles in allem konnte ich auf einem karthesischen Drucker bereits sehr gute Ergebnisse erzielen und habe diverse "Trockenläufe" durchgeführt. In der Theorie müsste man mit der Firmware also bereits rudimentär drucken können.

Ich werde mich in den nächsten Tagen/Wochen noch ein wenig mit meinem HexMax-Projekt beschäftigen. Wenn der fertig ist, habe ich zwei funktionierende Drucker mit denen ich die Firmware besser testen kann und gleichzeitig auch noch drucken kann :-)

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Hallo,

Ich würde mir eine Firmware wünschen, die sich einfach auf das wesentliche beschränkt. Im Grunde wird doch nur Gcode mit einem kleinen Befehlssatz interpretiert und in Schrittsignale umgewandelt. Dazu kommt noch eine Temperaturregelung. Was die Firmwares wie Repetier oder Marlin aber so umfangreich macht ist diese ganze Kompatibilität zu jeder Elektronik die es auf dem Markt gibt. Ich finde, eine einfache Pin Map sollte jeder sich selbst erstellen können. Bei mir ist jeder Drucker leicht anders verdrahtet die Pins musste ich so oder so immer ändern. Auch das Kartesische Systeme ,Deltas H-Belts in einer Firmware unterstützt werden, ist meines Erachtens nach eher nervig als Vorteilhaft. Die Kinematik ändert sich ja nicht jeden Tag. Also warum nicht für jede Kinematik eine eigene Firmware. Nur mal so als Beispiel :Bei unserem CRAFTYCUBE benutzten wir Repetier als Firmware. Bei der Innenraumbeleuchtung haben wir auf RGB LED gesetzt und wollten dann diese ansteuern. In der Firmware habe ich dann eine Stelle gefunden die Blau und Rot je nach Temperatur ansteuert.

#define RED_BLUE_STATUS_LEDS 1

Ja aber wo setzt man jetzt die Pins dazu. In der Pin.h sind sie nicht vordefiniert .Also habe ich jede Datei durchsucht bis ich die Funktion gefunden habe. So richtig fertig programmiert schien sie mir nicht . Worauf ich hinaus will ist das es nicht unbedingt vorteilhaft ist alles bequem von der Config.h parametrieren zu können. Wäre die Firmware einfach übersichtlicher,und man könnte den Ablauf besser nachvollziehen bzw. verstehen, dann hätten die Leute mit außergewöhnlichen Ideen oder Umsetzungen eher die Chance das ganze erfolgreich zu implementieren.

Also wenn dein Grundsystem läuft ( GCode interpreter , Ansteuerung der Achsen und die Temperaturregelung ) würde ich ich über den Quelltext freuen. Ansonsten bleib dran , wir dürfen gespannt bleiben
Gruß Jakob

Danke für das Feedback. Tatsächlich ist das auch eine Idee, die ich so ähnlich auch bereits hatte. Ich versuche mich momentan tatsächlich erstmal auf eine Art "Basissystem" zu konzentrieren und einen einfachen "Kern" zu entwickeln, der halt drucken kann.

Ganz, ganz grob beschrieben :-)

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Hi,

klingt schon mal ziemlich cool!

Hast du vor die Firmware dann als Open Source zu veröfffentlichen oder würdest du sie als persönliches oder kommerzielles Projekt betreiben.
Beides könnte ich verstehen bei Open Source würde sich die "Last" der Entwicklung ggf. besser verteilen.

BG Jörg

Hallo Glatzemann,

Respekt!
Leider reichen meine programmierkünste nur so weit damit ich das was repetier und marlin gezaubert haben einigermaßen nach zu vollziehen damit ich etwas mehr kann wie nur die firmware für eigene zwecke anzupassen. Ganz kleines kino also. Aber egal.
Was ich generell vermisse ist ein parameter der den innendruck der düse mit berücksichtigt und mit der bewegung/beschleunigung aller achsen sychronisiert. Mich interessiert in erster linie der extrusionsprozess. Hier wäre es schön auch die möglichkeit zu erhalten mit 2-3 heizzonen pro hotend arbeiten zu können.
Habe bereits vor 2 jahren dass thema bussystem mal angesprochen. Auch eine dezentralisierung im bezug auf die störungsanfälligkeit wäre vorteilhaft. Stepper mit treiber über einen bus verbinden. Das system wäre offener und erweiterbar. Etwas mehr kosten im bezug auf die hardware, dafür aber flexibler. Nur so eine idee. Kommt bestimmt irgendwann.

Gruß
Mirco

---

Druckwerk-3D.com

Aktuelle Planung ist, daß ich die Firmware als Open Source veröffentliche und frei verfügbar mache. Da ich bei meinem FSR Board-Projekt mit der RepRap-Community hervorragende Erfahrungen in Sachen Spendenbereitschaft gemacht habe, werde ich eine Möglichkeit zum Spenden einrichten um den bzw. die Entwickler zu "motivieren" :-)

Weiterhin plane ich, daß es von Community und/oder Herstellern finanzierte Erweiterungen geben wird. Bei größeren Erweiterungen an der Firmware, die ich nicht für den persönlichen Bedarf entwickele oder um die Firmware generell weiter zu entwickeln, möchte ich diese zur Finanzierung "ausschreiben". Ich schätze den Aufwand ab und schreibe da eine Hausnummer dran. Wenn sich genügend Leute zusammenfinden und das finanzieren, dann setze ich mich asap an die Umsetzung des Features.

Weiterhin möchte ich die Bedingungen für Code-Beiträge und Community-Contributions transparent veröffentlichen, so daß jeder freiwillig was zur Firmware beitragen kann, der dazu in der Lage ist und das möchte.



@Mirco: Das mit dem Bussystem ist eine interessante Idee, über die ich auch schon seit einiger Zeit grübele und mich frage, ob und wie man sowas geschickt und sinnvoll umsetzen kann. Ob das allerdings mit den Steppern wirklich funktionieren kann, da bin ich mir nicht ganz sicher. Die Stepper müssen halt synchron und mit durchaus hoher Frequenz angesteuert werden. Und wenn das nicht gleichmäßig passiert, dann kann dies zu Artefakten im Druck führen.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Hi,

klingt für mich super, ich wäre auch bereit da ein paar Euro liegen zu lassen, besonders wenn es dann noch die Gelegenheit gibt "Sonderwünsche" zu realisieren wenn man genug Geld oder Leute findet
Einige Opersource Projekte lassen ja auch über neue Features abstimmen ggf. könnte man es so machen dass Leute die einfach nur Spenden damit mehr Stimmen bekommen.

Wobei zuerst müsste es mal überhaupt funktionieren

BG Jörg

Ich habe mittlerweile eine ganze Menge Code angesammelt und einige Varianten durchprobiert... Aktuell habe ich eine Variante, die ich ganz vielversprechend finde und erstmal weiter verfolgen werde... Ich habe dabei einen recht modularen Ansatz gewählt (ähnlich wie bei Smoothieware) und zur Modulkommunikation ein altes Event- und Messaging-System aus meiner "Spieleentwickler-Karriere" wiederverwendet. Das sollte ganz gut zu funktionieren und die Entwicklung, Wart- und Erweiterbarkeit deutlich verbessern.

Neu hinzugekommen ist eine einfache Shell, mit der Kommandozeilenbefehle eingegeben werden können (Hilfe, Verzeichnisfunktionen für die SD-Karte, Konfigurationsdateien laden, Dateien auf SD schreiben, Befehl zum Drucken von SD-Dateien, Druck pausieren und abbrechen, Status- und Hilfeinformationen, etc.). Diese Befehle sind etwas eingängiger als G-Codes und damit Anwenderfreundlicher.

Konfigurationsdateien können nun wahlweise mittels GCode oder mit SON-Dateien (ähnlich JSon, aber etwas freundlicher zu tippen) geschrieben werden.

Für angeschlossene Displays und "Steuerelemente" wie Rotary-Encoder, Push-Buttons etc. habe ich eine einfache Markup-Language entwickelt. Informationsseiten und Menüs können so dynamisch auf SD-Karte in Dateien abgelegt werden und werden dann bei Bedarf geladen (aus dem Cache oder von Karte) und dargestellt. Damit kann man dann z.B. einfach GPIO-Pins ein- und ausschalten und sich z.B. einen Menüpunkt zum Schalten der Beleuchtung bauen.

Weiterhin habe ich noch ein paar Versuche mit einem In-Place-Firmware-Update von SD-Karte gemacht. Neue Firmware auf die SD-Karte, Karte einlegen, Meldung auf dem Display bestätigen und warten könnte funktionieren. Hier muss ich noch ein paar Tests machen, ob das wirklich stabil läuft.

An der Bewegungsfront habe ich auch kleine, aber mühsame Fortschritte gemacht. Sowohl Delta-, als auch XY-Kinematic arbeiten ganz gut, allerdings kämpfe ich noch ein wenig mit der Pfad-Planung und den Beschleunigungsrampen. Aufwendige Tests und leider geht da auch schnell mal was kaputt. Hab jetzt schon vier Hall-E geschrottet :-(

In Sachen Benutzerkomfort habe ich noch ein wenig mit der Auto-Kalibrierung von Delta-Druckern gespielt. Auf Knopfdruck vermisst ein Drucker mit Z-Probe nun automatisch das Druckbett und die maximal erreichbare Höhe. Aus den gewonnen Parametern wird dann auf Endstop-Offsets, Winkelkorrekturen, Rod-Länge und Delta-Radius geschlossen. Ich habe hier noch ein wenig mit der Mathematik zu kämpfen. Mein Verfahren liefert noch nicht so gute Ergebnisse wie die manuelle Kalibrierung oder das Escher3D-Tool, aber ich denke, daß ich hier bald das Ziel erreichen werde. Beim motorisierten Autobed-Leveling konnte ich meine Routinen, die ich in Repetier eingebaut hatte, weiterverwenden. Auch das softwaremäßige ABL ist kein großes Problem (für alle Kinematiken).

Ich komme nicht so schnell vorwärts wie ich mir das wünschen würde, aber ich hoffe, ich kann mit der Firmware in diesem Jahr noch drucken :-)


Gerade beim schreiben ist mir noch eine Idee gekommen: Wäre cool, wenn man eine Tastatur an den Drucker anschließen könnte und dann das LCD als "Bildschirm" für die Shell verwenden könnte. Wäre das nicht mal ein cooles Feature?

@angelo: Danke nochmal für den Hardware-Ersatz. Mit den alten Teilen kann ich nun wunderbar testen...

1-mal bearbeitet. Zuletzt am 03.06.16 12:02.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)