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

ThirtyTwo ist eine 32Bit-Firmware für RepRap (und verwandte) 3D-Drucker an der ich seit einigen Wochen entwickele. Da ich momentan noch mehr als genug Problemchen mit meinem Zweiten, dem Cub44, zu kämpfen habe, brauche ich hin und wieder einfach etwas, mit dem ich den Kopf frei bekomme. Und da ich sowohl beruflich Software entwickele, als auch privat schon seit der Ära der 8Bit-Heimcomputer programmiere, liegt es nahe, daß ich das mit meinem "Spezialgebiet" - der Softwareentwicklung - mache. Obwohl ich von hardwarenaher Programmierung Ahnung habe (Spieleentwicklung auf PCs, Mobiles und Konsolen) und auch früher bereits einige Erfahrung mit diversen Assemblern gemacht habe und auch schon eine eigene virtuelle Maschine inkl. Assembler und JIT-Compiler entwickelt habe, ist die Entwicklung für Arduino's und den zugrundeliegenden Microcontrollern Neuland für mich. Das macht es aber nur noch interessanter :-)

Was mich von Anfang an an den Firmwares genervt hat, ist die Tatsache, daß man diese ständig neu kompilieren muss und man dazu im Source "rumpfuschen" muss. Vieles ist schlecht oder nicht dokumentiert und vieles ist einfach "historisch" gewachsen, da die Wurzeln der meisten Firmwares gleich oder ähnlich sind. Das ist für Einsteiger oder Anfänger nicht gerade einfach und führt oft zu unnötigen Problemen oder macht einem einfach das Leben schwer. Auch der massive Einsatz von bedingter Kompilierung ist alles andere als schön und in keinster Weise hilfreich um eine vorhandene Code-Basis zu verstehen oder sich darin einzuarbeiten. Klar ist dies an vielen Stellen notwendig, vor allem wenn man bedenkt, daß viele Firmware's auch auf "alter" 8Bit-Hardware mit sehr begrenzten Ressourcen laufen soll. Zusätzlich kommt es auch noch oft zur Herausforderung, daß man spezielle Versionen der Arduino-IDE benötigt und/oder etwas an der Entwicklungsumgebung patchen/erweitern muss (z.B. boards.txt etc.). Sehr nervig, wenn man bedenkt, daß man auch einfach eine binäre Firmware auf den Arduino laden könnte und dafür nur ein kleines Kommandozeilentool und einen Treiber für das Board benötigt.

Daraus habe ich für meine Firmware bereits ein paar Ziele abgeleitet:

• Komfortabel und Einsteigerfreundlich soll sie sein
• Modular und Erweiterbar soll sie sein
• Konfiguration ohne Änderungen am Source-Code
• Übersichtliche und Moderne Code-Basis durch Einsatz von modernen Sprachfeatures (C++, Templates, etc.)
• Nur wirklich zeitkritischer Code soll in C/Assembler entwickelt werden
• Kein Fork einer bestehenden Firmware

Da ich mich nicht mit veralteter Hardware (auch wenn diese oft vollkommen ausreichend ist) rumschlagen möchte, habe ich für mich selbst auch entschlossen, daß ich primär für 32Bit-Elektroniken (Arduino Due, evtl. aber auch Beagle Boards, STM etc.) entwickeln möchte. Da ich momentan ein Radds für meinen Drucker verwende, werde ich auch primär dafür entwickeln, aber alles so gestalten, daß das später auch veränderbar ist.

Zunächst habe ich mich dann ein wenig in die Steuerung von Schrittmotoren mit dem Arduino eingearbeitet. Da die "fertigen" Libraries und die Methoden zum Schalten von Digitalausgängen nicht unbedingt die performantesten sind, habe ich hier schnell auf etwas eigenes umgeschwenkt. Kein großes Zauberwerk. Motoren kann ich bewegen und auch mit unterschiedlichen Geschwindigkeiten. Um die Hardware zu schützen werden natürlich auch Endstopps berücksichtigt und abgefragt. Der größte offene Punkt und gleichzeitig auch die größte Herausforderung in diesem Bereich sind jedoch die Beschleunigungs- und Bremsrampen, sowie die Pfadplanung. Damit werde ich mich später noch ausgiebig beschäftigen, sobald die restliche Infrastruktur steht... Es bewegt sich aber schon mal etwas und das ist ja schon mal was :-)

Ich habe mir dann eine Menge Gedanken gemacht, wie man die Firmware nun flexibel steuern und die einzelnen Module so zusammenstecken kann, daß eine möglichst breite Hardwarebasis (Karthesische Drucker mit unterschiedlicher Achsenkonfiguration, CoreXY, Delta) angesteuert werden kann und man dabei auch flexibel bei der Ansteuerung der Motoren (Treiber spiegeln und/oder austauschen etc.) bleibt. Dabei bin ich anfangs bei Konfigurationsdateien gelandet, die beim Start vom Host an den Drucker gesendet wird (auf Anforderung). Nicht wirklich elegant. Dann habe ich - ähnlich wie beim Raspberry Pi - die Konfigurationsdateien auf eine SD-Karte abgelegt und diese beim Einschalten der Elektronik geladen. Schon besser, aber immer noch nicht flexibel genug. Dann bin ich auf die Idee gekommen, daß man den Drucker ja auch per M-Codes konfigurieren könnte und das ich diese einfach auf die SD-Karte packe. Diese werden beim Start geladen, aber auch zur Laufzeit kann man so den kompletten Drucker einfach durch senden der Codes umkonfigurieren (z.B. von Delta auf Karthesisch, Treiber austauschen, Steps konfigurieren, etc.). Das fand ich ziemlich gut und nach einiger Recherche musste ich dann feststellen, daß jemand anderes diese Idee auch bereits hatte. Adrian, der Entwickler der RepRapFirmware, hat das auch so gemacht und hat sogar schon eine Menge M-Codes dafür hier im Wiki beschrieben. Ich habe dann einiges dort abgeschaut um kompatibel zu bleiben und angefangen zu implementieren. Für meinen eigenen Drucker sieht die Konfiguration momentan so aus:

; general settings
M111 S0				; Debug off
M550 PCub44			; set machine name
M555 P5				; set repetier compatibility mode
G21				; use millimeters for coordinates
G90				; use absolute coordinates for axis
M83				; use relative coordinates for extruder

; axis and driver settings
M667 S0				; select cartesian mode
M576 X0 			; map driver 0 to x axis
M569 P0 S1 			; x axis has positive direction
M576 Y1 			; map driver 1 to y axis
M569 P1 S1			; y axis has positive direction
M576 Z2:3			; map drivers 2 and 3 to z axis
M569 P2 S0			; z axis has negative direction
M576 E4				; map driver 4 to extruder
M569 P3 S1			; extruder 0 has positive direction
M92 X1280 Y640 Z6400		; axis steps/mm
M92 E302.74			; extruder steps/mm

; speed settings
M201 X3000 Y3000 Z150 E3000	; Accelerations (mm/s^2)
M202 X3000 Y3000 Z150 E3000	; Travel Accelerations (mm/s^2)
M203 X6000 Y6000 Z240 E12000	; Maximum speeds (mm/min)
M566 X20 Y20 Z0.3 E1		; Minimum speeds mm/minute / Jerk

; thermal settings
M305 P1 R1000 B4267.0		; 1K bias resistor, B value for Semitec 104-GT2
M305 P1 T100000			; 100K thermistor
M305 P0 R1000 B4540		; 1K bias resistor, B value for Epcos B57...
M305 P0 T100000			; 100K thermistor
M140 S0 R0			; set the bed to "0,0" at start up

; extruders
M563 P1 D0 H1			; define extruder 1

Diese befindet sich in der Datei config/config.g. Die Kommentare sollten für's erste andeuten, wie mächtig so ein System ist.

Mein eigener G-Code-Parser übersetzt diese Datei innerhalb von 40ms und führt die entsprechenden Befehle aus. Die Temperaturen werden momentan noch nicht beachtet und die Geschwindigkeiten auch noch nicht, aber alles weitere wird bereits ausgeführt und funktioniert bereits. Sogar das Display gibt bereits sinnvolle Informationen aus, auch wenn es dort noch nichts zu steuern gibt. Die Motoren lassen sich danach über Repetier Host (oder ähnlichem) bereits ansteuern, inkl. Homen und auch schon ein "echtes" Auto-Bed-Leveling mit individueller Ansteuerung von drei Motoren funktioniert bereits.

Ich werde hier in unregelmäßigen Abständen über die Fortschritte berichten und hoffe, daß ich in naher Zukunft auch mal eine Testversion veröffentlichen 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)

Ich bin gespannt.....

---

[www.facebook.com]

Power is nothing.....without control!

Ich ebenfalls

---

Der 3D-Druck ist tot, lang lebe der 3D-Druck!

Schreibt mich nicht mehr an, ich hab das drucken an den Nagel gehängt.

Ich auch

Ich auch. Vor allem bin ich auf deine Rampen gespannt, ohne etwas von bestehenden Systemen zu nutzen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ich bin auch gespannt

Spaß beiseite...

Quote
Wurstnase
Vor allem bin ich auf deine Rampen gespannt, ohne etwas von bestehenden Systemen zu nutzen.

Darin sehe ich momentan auch noch die größte Herausforderung. Einen gesamten Druckvorgang inkl. Beschleunigung, Abbremsen und Lookahead zu orchestrieren wird sicherlich eine harte Nuß.


Den ersten Code-Bereich den ich vollständig fertig gestellt habe ist der GCodeParser. Dieser ist als endloser Automat (also eine Final State Machine) realisiert und benötigt zur Laufzeit nur ca. 44 Byte Arbeitsspeicher. Dem Automaten werden zu einem beliebigen Zeitpunkt beliebig viele Zeichen aus einer beliebigen Quelle (Serielle Schnittstelle, Datei, etc.) übergeben. Anhand des aktuellen Zustand des Automaten und des jeweiligen Zeichen wird dann intern entschieden, wie weiter zu verfahren ist. Wurde ein vollständiges Kommando inkl. Parameter erkannt, so wird ein Callback aufgerufen. Dieser Callback transportiert das Kommando inkl. aller Parameter und enthält alles um dieses Kommando ausführen zu können. Bei einigen G-Kommandos zur Bewegung werden diese in einen Buffer geschrieben und beizeiten verarbeitet, andere werden sofort ausgeführt. Mit dieser Art der Verarbeitung habe ich in der Vergangenheit bereits einige sehr erfolgreiche Erfahrung sammeln können (z.B. ein JSON-Parser). Dieser Code-Teil war daher recht schnell abgehakt und ist auch schon recht gut getestet. Auch sehr große (einige Hundertausend Zeilen), echte G-Code-Dateien werden problemlos verarbeitet.

Auch Zeilennummern, Kommentare und Prüfsummen werden verarbeitet.

Durch die Leichtgewichtigkeit ist es außerdem möglich, mehrere Parser gleichzeitig zu verwenden. Einer wird beispielsweise sofort nach dem Einschalten der Elektronik instanziiert und ist ständig mit der seriellen Schnittstelle verbunden. Dieser wartet damit auf Kommandos von einem Host. Ein weiterer Parser wird zusätzlich instanziiert und dient der Ausführung von G-Code-Dateien, wie beispielsweise die oben gezeigte Konfigurationsdatei, aber auch "Macros", die mittels M98/M99 ausgeführt werden können.

Es können übrigens zum aktuellen Zeitpunkt 6 unterschiedliche G-Codes und 26 M-Codes verarbeitet werden. Erstere dienen hauptsächlich der Bewegung und Einstellung der Positionierung (Absolut, Relativ, Inches, Millimeter) und die anderen dienen hauptsächlich der Konfiguration.

Die nächsten Entwicklungsschritte die ich nun geplant habe sind:

• Abfrage und Konfiguration der Thermistoren (Thermocouples kommen später)
• Ansteuerung der Heizungen (erstmal nur ein einfacher Algorithmus wie Bang-Bang)
• Notstop
• Watchdog
• Debugging/Testing-Schnittstelle um weitere Entwicklungen einfach realisieren zu können

Danach werde ich mich um die Beschleunigung kümmern und ein System zur Generierung von Step-Signalen mit dem richtigen Timing entwickeln. Dabei geht es erstmal nicht um Höchstgeschwindigkeiten, sondern ein funktionierendes und stabiles System. Das kann dann im darauf folgenden Schritt immer noch optimiert werden.

---

--
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,

was ich ich bei den bestehenden Firmwares immer gefragt habe (aber nie recherchiert habe), warum das Display so angebunden wurde, wie es ist. Als beim Ramps über Eins des Arduino.
Ich würde es besser finden das Display über seriell oder I2C anzubinden, und etwas eigene Logik in das Displaybord zu setzen. Also in die Firmware nur eine generische Schnittstelle für eine "externe" Steuerung bauen.

Die Logik zur Steuerung dann in das Display selbst programmieren. Da kann man dann ein normales mit drehender nehmen, oder eben auf was aufwändiges mit Grafik und Touch. Wichtig wer doch, das das Interface zum Display generisch ist.

Aber vielleicht ließe sich das heute schon machen, und ich habe es nur nicht verstanden.

Gruß
Christian

Ich habe erst jetzt von dem Projekt gehört und gelesen. Wow. Sehr spannend. Da bleibe ich definitiv am Ball, denn diese Ansätze sagen mir schon jetzt sehr zu.
Hut ab.

Gruß
Andreas

---

Einen Sparkcube 1.1XL für größere Objekte, einen Qidi Tech Q1 Pro, einen Trinus3D im Gehäuse und einen Tantillus R im Bau.
Sparkcube: Komplett auf 24V - DDP 8mm + 1,5mm Carbonplatte - Octopus max EZ - BTT Pi2 - EZ2209 - Nema 17/1,7A 0,9 Grad - Eddy USB - Filamentsensor - BIQU H2 V2S REVO Extruder - Klipper/Mainsail - HDMI 7 V1.2 Touchscreen - Simplify3D

respekt, das thema werd ich mir auch öfters anschaun

Franz

Hallo "Glatzemann", grüß Dich.

So wie ich dich einschätze, hast du mit Sicherheit auch meinen Beitrag Welche SW (Freeware) zur Steuerung v. Robot Arm verfolgt. ( edit )

Mit welcher Warscheinlichkeit siehst du die Chance so eine Firmware um ein neues System zu erweitern.
Die Problematik dieses Roboterarm-Systems besteht ja überwiegend aus der koordination von Wegeberechnung und Geschwindigkeit.

Wenn ich dich richtig verstanden habe, würde diese Steuerung nur ein weiteres austauschbare Modul bedeuten.
Das wäre nicht nur riesig, sondern auch Bahnbrechend für die DIY-Szene.
So wie von mir mit ńer Rumba angedacht und seit einigerzeit in Angriff genommen.

Wie siehst Du das als "Softwareschreiber"?

Beste Bastlergrüße Didi

2-mal bearbeitet. Zuletzt am 28.09.15 15:34.

---

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
vw-styler
...
So wie ich dich einschätze, hast du mit Sicherheit auch meinen Beitrag ms.reprap.org/read.php?247,505151 verfolgt.
...

dein link funktioniert bei mir nicht...

Hi "keiner99" es ist dieser Beitrag:

Deutschsprachiges Forum > Software > Thema >

Welche SW (Freeware) zur Steuerung v. Robot Arm

jetzt müßte es aber gehen.

Bis später 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 . . .

Ich kenne den Thread, habe den aber bisher nur "quergelesen". Was mich aber auf jeden Fall fasziniert hat daran sind die Bilder von den Roboterarmen. Sowas steht sehr weit oben auf meiner Bastelliste, wenn der Drucker mal richtig druckt und dafür Teile produzieren kann. Ich möchte allerdings mit dem Roboterarm nicht drucken, sondern nur "spielen" :-)

Aber zum Thema: Ich entwickele meine Firmware von Grund auf so, daß man sowas machen kann. Es ist - soweit der Plan bis jetzt - tatsächlich nur ein einziges Modul, welches hinzugefügt werden müsste. Dieses wird dann ganz einfach im obigen Skript per "M667 S7" (die Zahl hinter dem S ist jetzt erstmal willkürlich gewählt) aktiviert. Dann müssen noch die Treiber des jeweiligen Boards mit den Achsen/Motoren "verbunden" werden und das war es dann auch schon. Um den Rest kümmert sich dann die Firmware.

Ich habe in meiner Spieleentwickler-"Karriere" mal ein wenig mit inverser Kinematik und virtuellen Muskeln experimentiert. Auch in Sachen Physiksimulation (sprich Physik-Engine) habe ich mit entsprechenden Joints und deren Simulation gearbeitet. Ich denke, daß man aus der Richtung eine Lösung für die Bewegung des Arms entwickeln könnte. Sowas selbst entwickeln kann ich aber nicht. Die Mathematik die dahinter steckt ist mir leider zu hoch. Wenn mir jemand die entsprechenden Formeln erarbeitet, dann wäre das aber ein eher kleines Problem. Als große Herausforderung sehe ich da insbesondere zwei Aspekte:

• Rechenzeit - eine inverse Kinematic zu berechnen ist nicht ganz ohne. Da werden einige Matrix-Operationen durchgeführt, die etwas Rechenzeit benötigen. Ich habe sowas auf relativ schwaren ARM-Prozessoren (Windows Phone der ersten Generation, 1 Kern, unter 1 GHz) bereits gemacht. Die AVRs sind aber noch mal eine ganz andere Nummer und haben nochmal deutlich weniger Rechenleistung (locker Faktor 10-20 würde ich mal schätzen) und es muss ja noch eine Menge anderes gemacht werden. Ich kann ehrlich gesagt noch nicht abschätzen ob das realisierbar ist, da mir zwei Informationen fehlen: Wieviel Performance benötigt die Berechnung der Motor-Positionen des Arms und wieviel Leistung hat ein AVR tatsächlich.
• Geschwindigkeit und Beschleunigung - Besonders wichtig ist ja beim 3D-Druck eine gleichmäßige und sanfte, aber doch möglichst schnelle Bewegung. Kleine Ruckler oder Ungenauigkeiten sieht man deutlich im Druckbild. Mechanisch kann man das Problem sicherlich ganz gut in den Griff bekommen. Softwaretechnisch kommt hier wieder die Mathematik ins Spiel. Wie beschreibt man die Arm-Bewegung möglichst gleichmäßig und sanft. Das hängt auch wieder eng mit dem vorherigen Punkt zusammen.

Was ich anbieten kann ist, daß ich den "Einarm-Robot-Drucker" in der Entwicklung berücksichtige und somit alles in meine Firmware einbaue, was für den Betrieb eines solchen Druckers notwendig wäre. Wenn mich jemand bei der Mathematik unterstützt bzw. mir die Formel vorgibt, dann kann ich die auch gerne in die Firmware einbauen und somit ein experimentieren ermöglichen. Was ich aber in jedem Fall nicht möchte ist, daß dieses "Nebenprojekt" zuviel Zeit verschlingt. Meine erste Priorität ist bei der Firmware, daß ich meinen Drucker (karthesisch) mit echtem ABL ans Drucken bekomme. Die nächste Priorität ist dann die Delta-Kinematic zu implementieren, da ich als nächstes vermutlich einen Delta bauen möchte. Danach (oder vielleicht auch parallel) kommt CoreXY (CoreXZ und CoreYZ) dran, da es viele mit so einem Drucker gibt und ich so sicherlich viel Erfahrung gewinnen kann. Ich denke aber, daß die Teilprojekte gut koexistieren könnten :-)

Kurz und knapp also: Ich helfe gerne, kann aber die Softwareseite nicht alleine stemmen und möchte das erstmal nicht mit höchster Priorität angehen.

1-mal bearbeitet. Zuletzt am 29.09.15 04:13.

---

--
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 "Glatzemann",

das hört sich ja gut an und macht mir wieder Mut

> Was ich anbieten kann ist, daß ich den "Einarm-Robot-Drucker" in der Entwicklung berücksichtige und somit alles in meine Firmware einbaue, was für den Betrieb eines solchen Druckers notwendig wäre. <

Das ist doch mal ne Aussage. Das ist eine sehr gute Basis die wir alle gerne annehmen, denn wir die "Einarm-Roboter-Interessierten" sind sehr Zahlreich und die Einsatzgebiete der Arme auch.


Mit deiner hilfreichen Zusage, können wir bestimmt "neue" frische Helfer in und für die Sache gewinnen.

Die gleichmäßige Geschwindigkeit des Roboter-Arms über das ganze Druckfeld zu erhalten, das ist ja die Kunst.
Positionieren, von "A" nach "B", nach "C", nach "D" usw. das kann doch schon fast jeder mit ´nem Joystick.

Wenn du nichts dagegen hast, lege ich einen Link in meinem Beitrag (zu deinem Beitrag ThirtyTwo . . .).
Das signalisiert den Anderen, das es weiter geht und da wieder Bewegung rein kommt

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 . . .

Da habe ich selbstverständlich nichts gegen :-)

---

--
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)

Dank dir .

Die Rumba habe ich erst mal so Gedanklich festgehalten für die Steuerung.
Weil, diese "Alleinlauffähig" und somit recht preiswert ist und da man die ja dank Frithjof´s Platine, gut Achsen/Stepper-mäßig erweitern kann.
Ansonsten muss halt ein RADDS und ein DUE dran.

Bis später 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 . . .

Das soll doch ne 32bit-Software werden. Also fällt da nen Rumba ja schonmal weg.

Ansonsten gibt es auch eine Erweiterung für das DUET auf ingesamt 9 Treiber.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Stimmt, hattest du mal erwähnt.

---

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 . . .

Wobei, wenn ich so viele Treiber benötige würde ich wahrscheinlich auf günstige THB aus China zurück greifen. Die kannst quasi direkt an nen Due oder ähnliches anschließen. Da brauchst dann kein Shield wie RADDS. Ist halt nen andere Kabelsalat dann. Aber sonst auch nix wildes. Eigentlich braucht man das Shield ja nur für die Polulus, Thermistor und die FETs.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Das Rumba basiert ja auf dem ATMega2560, welcher ein 8Bit Prozessor ist. Ohne jetzt hier eine Grundsatzdiskussion für oder gegen 8Bit/32Bit und für irgendwelche Shields vom Zaun brechen zu wollen: Ich möchte das Rumba zunächst nicht unterstützen. Ich habe zwar auch einen Arduino mit ATMega2560 und ein RAMPS 1.4 (die Kombination ist ja sehr ähnlich wie das Rumba, zumindest aus Softwaresicht) und habe die Firmware dafür auch schon mal kompiliert, aber möchte mich erstmal nur auf modernere Hardware beschränken. Es gibt auf den moderneren CPUs einige interessante Features, die sehr, sehr hilfreich sein könnten. Ein Beispiel:

Der "normale" Prozess des Homens einer Achse sieht wie folgt aus:

Solange Endstop nicht erreicht
  Generiere einen/ein paar Steps um die Achse in eine Richtung zu bewegen
  Lese den Endstop-Pin aus und prüfe, ob der Endstop erreicht ist
Wiederhole

Das ist zwar einfach, aber der Schritt "Lese den Endstop-Pin aus und prüfe, ob der Endstop erreicht ist" kostet ständig Zeit, insbesondere, wenn man die Endstops auch während des Drucks überwachen möchte.

Auf dem Arduino Due mit der SAM3X8E CPU kann man nun alle Digital-Pins überwachen lassen und einen Interrupt ausführen, sobald ein "Ereignis" am Digital-Pin auftritt (Wert ändert sich, Wert geht auf High, Wert geht auf Low, Wert ist High, Wert ist Low). Dies bedeutet, daß sich die Schleife etwas ändert:

Solange Endstop nicht erreicht
  Generiere ein paar Steps um die Achse in eine Richtung zu bewegen
Wiederhole

Das spart bei jedem Schleifendurchlauf ein paar Microsekunden. Die können dann wieder dafür verwendet werden um Steps zu generieren und somit können die Achsen etwas schneller bewegt werden.

Diese Interrupts sind sicherlich auch noch für einige andere Digital-Pins sehr interessant (z.B. bei der Display-Steuerung bzw. dem "Rotary Encoder") :-) Die 8Bit-Elektroniken ermöglichen zwar auch solche Interrupts, aber nicht auf allen Digital-Pins, sondern nur auf einigen wenigen. Beim Mega sind das beispielsweise nur 6 Pins. Wenn man sich das Rumba anschaut, dann sind das nicht die Endstop-Pins.

Für den Anfang empfehle ich daher einen Arduino Due und ein RADDS (1.5). Darauf werde ich entwickeln. Um die Kosten etwas zu drücken, werde ich einen Arduino Due Clone für die Entwicklung verwenden.

---

--
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)

Irgendwie habe ich da noch im Hinterkopf, dass es da irgendein Problem mit gab. Sowas wie dass die Software-Interrupts die gleichen Ports belegen wie die Hardware-Interrupts. Aber ich steh da gerade auf dem Schlauch.

1-mal bearbeitet. Zuletzt am 29.09.15 08:56.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

@Glatzemann
Deine Idee finde ich als "normaler Anwender" echt super
Super Anleitungen für den mechanischen Aufbau eines 3D-Druckers gibt es bereits - auch für Leute mit 5 Daumen an einer Hand.
Die "Software" bereitet vielen - auch hier im Forum - bisher so manches Kopfzerbrechen.
Das wäre ein großer Schritt in Richtung Anwenderfreundlichkeit und würde sicherlich noch mehr Leute zu einem Eigenbau bewegen.
Ich kann dich zwar hierbei nicht aktiv unterstützen, jedoch bin ich in ungeduldiger Erwartung des 1. Releases
Gruß
Walter

Quote
Wurstnase
Irgendwie habe ich da noch im Hinterkopf, dass es da irgendein Problem mit gab. Sowas wie dass die Software-Interrupts die gleichen Ports belegen wie die Hardware-Interrupts. Aber ich steh da gerade auf dem Schlauch.

Ich hab bei den "kleineren" einiges darüber gefunden. Beim Due/SAM3X8E hatte ich das so verstanden, daß dieser Nested Vector Interrupt Controller alles in Hardware macht und der Prozessor sogar spezielles Silikon hat um den Kontext zu sichern und noch einige andere Feinheiten um die Interrupt-Behandlung zu beschleunigen.

Ich werde das aber definitiv im Hinterkopf behalten, danke für den Hinweis.

---

--
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)

Länger nichts mehr geschrieben in diesem Thread, daher mal eine kurze Zwischenmeldung:

Ich habe mich in den letzten Wochen intensiv mit der Step-Generierung für die Schrittmotoren beschäftigt und auch ein wenig mit den unterschiedlichen Varianten der Kinematic. Die CoreXY (und verwandte) Kinematic ist dabei kein großes Problem. Die Delta Kinematc, vor der ich nach wie vor etwas Respekt habe, ist eigentlich auch kein großes Problem und hat sogar ein paar interessante Ansätze, die ich als Vorteil dieser Technik ansehe. Bei der Arm-Kinematic für vw-styler sehe ich nach wie vor das größte Problem in der Rechenzeit und in der noch nicht vorhandenen inversen Kinematic-Funktion zur Ermittlung der Motorpositionen.

Ich habe mich nach einer Menge Input aus unterschiedlichsten Quellen dafür entschieden einen Bresenham / Digital Differential Analyzer für die Step-Generierung einzusetzen. Das ist der Standard. Meine Recherchen haben nichts anderes ergeben und auch wenn ich mehrere andere Möglichkeiten gefunden habe, daß Problem anzugehen, denke ich, daß mit heutigen Mitteln (da geht es hauptsächlich um die Rechenzeit, auch bei 32Bit Elektroniken) dies die sinnvollste bzw. einzigst mögliche Variante ist. Einige werden sich sicherlich denken oder auch schreiben, daß sie mir das auch hätten vorher sagen können. Ja, richtig. Ich habe mir das auch vorher bereits gedacht, aber trotzdem wollte ich genauer verstehen, warum dies so ist und wo die Probleme liegen.

Aktuell habe ich einen 2D-Bresenham und einen passenden Buffer entwickelt, mit dem man die X- und Y-Achse synchronisiert verfahren kann. Gesteuert über die normalen G-Codes. Das funktioniert soweit ganz gut.

Der nächste Schritt wäre nun einen 4D-Bresenham zu implementieren, was auch nicht weiter schwierig ist. Damit wäre es dann möglich zusätzlich die Z-Achse und auch den Extruder entsprechend anzusteuern und zwar synchronisiert mit X und Y. Das ist insbesondere beim Extruder sehr wichtig, denn die extrudierte Kunstoffmenge hängt ja direkt mit der Bewegung auf den Achsen zusammen.

Was mir jedoch immer noch Kopfzerbrechen bereitet ist die Beschleunigung bzw. überhaupt die Geschwindigkeit. Eigentlich ist dies nicht weiter schwierig, wenn man für alle Achsen die gleiche Geschwindigkeit annimmt. Die aktuelle Geschwindigkeit wird einfach mit einer Rampe auf die Zielgeschwindigkeit über einen gewissen Zeitraum erhöht oder verringert. Es wird einfach die Frequenz mit der die Steps ausgegeben wird entsprechend angepasst und fertig ist die Beschleunigung. Leider ist es dann unter realen Bedingungen nicht ganz so einfach: Die vier Motoren können und haben unterschiedliche Geschwindigkeitsprofile. Hier wird es dann kompliziert. Wenn der "führende" Motor (der mit den meisten Steps) ein langsamer ist, dann werden alle anderen Achsen ausgebremst. Auch in diversen anderen Situationen gibt es hier Zusammenhänge, die die tatsächlich erreichbare Geschwindigkeit beeinflussen. Da die meisten Firmwares suggerieren, daß man die Geschwindigkeit der einzelnen Achsen frei wählen kann, bin ich mir nicht sicher, ob ich hier noch ein Verständnisproblem habe und nur die richtige Methode noch nicht entdeckt habe, oder ob dieses Modell eher "ungünstig" ist und die tatsächlich verwendete Druck-Geschwindigkeit von mehr Faktoren abhängig ist.

Wenn hier jemand Input liefern kann, wäre ich sehr erfreut :-)

---

--
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,

Quote

Wenn der "führende" Motor (der mit den meisten Steps) ein langsamer ist, dann werden alle anderen Achsen ausgebremst. Auch in diversen anderen Situationen gibt es hier Zusammenhänge, die die tatsächlich erreichbare Geschwindigkeit beeinflussen. Da die meisten Firmwares suggerieren, daß man die Geschwindigkeit der einzelnen Achsen frei wählen kann, bin ich mir nicht sicher, ob ich hier noch ein Verständnisproblem habe

Ich denke nicht, dass Du ein Verständnisproblem hast

Ist doch so - egal wieviele Achsen ...
... wenn alle Achsen in einem Befehl angesprochen werden, heißt das, dass alle gemeinsam anfangen und gemeinsam aufhören (sollen/müssen).
Klar bestimmt die Achse mit der geringsten Geschwindigkeit die Vmax und die Achse mit den meisten Schritten führt.
Das kann dann durchaus bedeuten, dass eine Achse nicht so schnell fährt, wie wenn sie führen würde oder sich alleine bewegen würde ...
Aber so ist das nunmal im Team - das schwächste Glied bestimmt die Stärke des gesamten Teams

Trotzdem kann es sinnvoll sein, für jede Achse Beschleunigung und Vmax speparat konfigurieren zu können. Es gibt ja die unterschiedlichsten Konstellationen mit 2 synchronisierten Motoren und/oder Riemen die (nicht) in die Resonanz kommen (sollen) ...

Wie Brummie sagt. Warum soll Motor 1 denn schneller am Ziel ankommen als Motor 2?
Aber lustig wird die Sache erst bei nem Delta. Da hast du theoretisch keinen 'führenden' Motor. Dort hast ja eigentlich immer eine Art Sinus-Verlauf der Motoren und du musst theoretisch nach jedem Schritt die Geschwinigkeiten neu berechnen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hallo, grüßt Euch.

Erst mal an Glatzemann ein großes Lob, das du noch "bei der Stange" bist und den Arm nicht vergessen hast.

@ Brummi > Trotzdem kann es sinnvoll sein, für jede Achse Beschleunigung und Vmax speparat konfigurieren zu können < das trifft aber nicht auf den Delta und den Robo-Arm zu,

bei dem müssen meines Erachtens X u. Y-Konfiguration identisch sein, sonst gib´s da richtig Probleme.

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
Wurstnase
Wie Brummie sagt. Warum soll Motor 1 denn schneller am Ziel ankommen als Motor 2?

Ich würde das sogar noch etwas krasser formulieren: Motor 1 DARF nicht schneller am Ziel ankommen als Motor 2 :-)

Danke für eure Kommentare, die waren sehr hilfreich. Ich hatte nämlich tatsächlich eben noch ein kleines, aber feines Verständnisproblem: Ich hatte bei meiner Analyse "verdrängt", daß ein Bewegungsbefehl für sich alleine steht und immer erst abgearbeitet wird, bevor ein anderer ausgeführt wird. Irgendwie war ich auf einem anderen Zug und dachte, wenn ich z.B. eine langsame Z-Bewegung mache und danach eine schnelle X-Bewegung, daß die dann parallel ausgeführt werden, was aber ja nicht so ist :-)

Aber ich sehe das doch richtig, daß ich mit dem Extruder-Stepper theoretisch X- und/oder Y ausbremsen könnte bzw. der Extruder von X- und/oder Y ausgebremst wird, je nachdem was gedruckt wird und welche Beschleunigungswerte eingestellt wurden? Dies führt mich eigentlich auch zu meinem nächsten Punkt:

Ich denke, daß man sogar die unterschiedlichen Kinematicen gesondert betrachten sollte oder sogar muss. Bei einem karthesischen Drucker ist es ja ganz einfach. Alle Achsen bewegen sich unabhängig von den anderen. Ich kann problemlos für alle Achsen eigene Beschleunigungs- und Maximalgeschwindigkeiten angeben. Die führende Achse (und die kleinste Maximalgeschwindigkeit aller zu bewegenden Achsen) bei einer Bewegung bestimmt dann einfach die tatsächliche Geschwindigkeit. Das steht glaube ich außer Diskussion?

Bei einer CoreXY-Kinematic sieht das hingegen etwas anders aus. Die Motoren A und B, welche für die Bewegung auf der X- und Y-Achse zuständig sind beeinflussen jeweils zwei Achsen, wenn sie bewegt oder nicht bewegt werden. Hier sollten meiner Meinung nach die Konfigurationen beider Motoren gleich sein.

Bei einem Delta ist es noch eine Nummer krasser, denn hier sollten alle drei Motoren A, B und C gleich konfiguriert sein, da die Bewegung aller drei Motoren die Bewegung auf drei Achsen beeinflusst.

Und daraus ergibt sich meiner Meinung sogar noch ein Punkt: Die Drehgeschwindigkeit der Motoren hängt nicht 1:1 mit den Verfahrgeschwindigkeiten auf den Achsen zusammen, sondern ergibt sich aus der tatsächlichen Geschwindigkeit aller bewegten Motoren.

Vielleicht macht es daher Sinn, daß man mehrere Geschwindigkeitskonfigurationen hat: Einmal eine für die Motoren. Die maximal Verfahrbare Geschwindigkeit und Beschleunigung, die für den jeweiligen Motor möglich ist, ohne das dieser Schritte verliert und ohne das dieser Kraft verliert. Und dann noch eine Geschwindigkeitskonfiguration für eine/alle Achsen, bei der festgelegt wird, mit welcher Geschwindigkeit und Beschleunigung sich der Druckkopf bewegt. Bei den beliebten PET-Filamenten ist ja eine möglichst homogene Geschwindigkeit angesagt, aber durch ungünstige Objekte/Konfiguration kann dies ja durchaus negativ beeinflusst werden. Besonders, wenn z.B. eine ungünstige Stepper-Konfiguration oft die anderen Achsen beeinflusst.

---

--
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)

Richtig! Die Geschwindigkeiten und Beschleunigung willst du eigentlich vom Effektor aus betrachten um gute Druckergebnisse zu bekommen. Wenn die Motoren das nicht schaffen, dann muss die Geschwindigkeit und Beschleunigung runter. Letzendlich wollen wir ja schön drucken und nicht so schnell fahren wie die Motoren es können.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hi,

Du musst Dir nur vor Augen halten, für wen die Parameter sinnvoll sind.
Wenn man Vmax für die einzelnen Stepper betrachtet, macht es nur dann Sinn, Vmax zu reduzieren, um unerwünschte Resonanzen zu vermeiden, bzw. beim Extruder eben Schrittverluste zu vermeiden.

Was ganz anderes ist die reale Geschwindigkeit, also wie schnell die extrudierte Wurst verlegt wird oder z.B. bei einer Fräse, wie schnell durchs Material gerauscht wird. Ist die Geschwindigkeit zu groß reißt die Wurst ab, bzw. bricht der Fräser. Ist die Geschwindigkeit zu langsam, kann schon mal Material zur Seite raus sabbern, bzw. der Fräser schmilzt das Material (Kunststoff) oder sorgt für Brandstellen (Holz).

Noch anders verhält es sich mit der Beschleunigung. Der Wert ist "eigentlich" dazu da, die Lager zu schonen.

Wie Du schon erkannt hast, ist jede Kinematik anders. Es gibt doch diesen Scheibendrucker (von Terry Pratchet?), bei dem die Scheiben bei einer geraden Linie sogar mehrfache Richtungswechsel erfahren. Somit gilt die Beschleunigungsrampe nicht für die zu druckende Gerade, sondern für die Strecken, die ein Stepper ohne Richtungswechsel drehen kann. Das kann - wie gesagt, bei jeder Kinematik zu völlig anderen Rampen führen.
Der erste Stepper, der einen Richtungswechsel erfordert ist auch der erste, der die Bremsrampe aktiviert.