32bit für 50€ all inkl.

Packe ich viele WRITE() hintereinander, kommt er tatsächlich mit 2 Takten hin. Der Puls ist jeweils nur 41 ns. Die beiden Werte für den Pin sind dann auch in zwei verschiedenen Registern gespeichert, so wie es sein soll.

Naja, meistens. An einer Stelle hat er dann doch noch 2 Takte Denkpause. Der Prozessor ist schon bemerkenswert.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Das meine ich mit diesen sporadischen Verzögerungen:



Der zugehörige Assembler ist ...

 496:	3104      	adds	r1, #4
 498:	621a      	str	r2, [r3, #32]
 49a:	6219      	str	r1, [r3, #32]
 49c:	621a      	str	r2, [r3, #32]
 49e:	6219      	str	r1, [r3, #32]
 4a0:	621a      	str	r2, [r3, #32]
 4a2:	6219      	str	r1, [r3, #32]

..., müsste also drei genau gleiche Pulse ergeben.

So langsam muss ich mich wohl von der Idee verabschieden, dass die Laufzeit genau vorhersehbar ist. Es gibt ja diesen SysTickTimer, der da besser sein soll.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Das schaut echt schräg aus. Aber in der Tiefe muss ich aktuell aussteigen.

Btw. hier mal das was Eclipse draus macht:

do {  if (1) {((Pio    *)0x400E1000U) -> PIO_SODR |= (1 << 27); } \
                                else {((Pio    *)0x400E1000U) -> PIO_CODR = (1 << 27); }; \
                          } while (0)

mein Code schaut so aus:

#define WRITE(IO, v) do {  if (v) {DIO ## IO ## _WPORT -> PIO_SODR |= MASK(DIO ## IO ##_PIN); } \
                                else {DIO ##  IO ## _WPORT -> PIO_CODR = MASK(DIO ## IO ## _PIN); }; \
                          } while (0)

#define DIO13_PIN 27
#define DIO13_WPORT PIOB

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
mantus
nich verwechseln, das auf banggood ist MKS-BASE (=MEGA2560) und nicht MKS-SBASE(=Cortex)
SBASE ist wirklich sehr neu.

Au weia, da hast Du wohl wahr, da war ich wohl etwas vorschnell.., bei allinclusive sträuben sich meine Nackenhaare

quote=mantus]und wie meinst friss oder stirb?[/quote]
allinclusive halt.
Prozzi putt -> board putt, Treiber putt -> Board putt,..etc..
Außerdem kann ich die Treiber nicht nach Belieben tauschen.

Wenn 32bit, dann bitte schön irgendein günstiges Entwicklungsboard + Aufsteckplatine.

@Traumflug
Welcher ARM schwebt Dir denn so vor, STM32?
Dein Ozci tut's ja offensichtlich noch, sollte ich mir auch so langsam mal zulegen.
Mein DiscoveryF3 liegt seit einem jahr inner Ecke, da für Java ne teure Spezialversion vonnöten ist, Assembler ist für mich passe'.

Traumflug baut auf den LPC1114. Einziger, oder einen der wenigen, ARM im DIP.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hier, dieser LPC1114 ist mit seinen bescheidenen 48 MHz schon schneller als die Konkurrenz. Seit heute laufen die Schrittmotoren, mit bis zu 128.000 Schritten/Sekunde:

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Sauber! Nen Due ist da nicht schneller. Vor der letzten Optimierung hat Roland mal 115kHz bei Marlin (single Step) gemessen. Das war allerdings noch ohne direkten Registerzugriff.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
bianchifan
Mein DiscoveryF3 liegt seit einem jahr inner Ecke, da für Java ne teure Spezialversion vonnöten ist, Assembler ist für mich passe'.

Dann hole das mal wieder hervor, zwischen Java (wie abartig für ein embedded Board) und Assembler gibt's noch eine ganze Reihe Optionen. Die Teacup nimmt den arm-none-eabi-gcc, der funktioniert ganz ordentlich.

Wenn Du Dir den aktuellen gen7-arm-Zweig mit gitk --all & anschaust, dann sieht der so aus:



Der eignet sich prima als Tutorial. Einfach mit dem untersten Commit anfangen, einen eigenen Zweig darauf erstellen und dort die Änderungen einbringen, die Dein Board braucht. Etwa so:

$ git checkout gen7-arm~59   # Aktuell 59. Wichtig ist, dass man beim ersten Commit auf diesem Zweig landet.
HEAD is now at a3697ff... ARM: start generic port by splitting out AVR specific serial code.
$ git checkout -b stm

Dann hast Du einen eigenen Zweig. Die Commit-Beschreibungen enthalten jeweils welche Änderungen eingebracht wurden und wie man das testet. Sogar der notwendige Code dafür ist meist rein kopiert. In Deinem Zweig probierst Du das auf Deinem Board aus und bringst ggf. die notwendigen Änderungen ein. Das dann committen, Du hast einen Schritt geschafft.

Für den nächsten Schritt hängst Du Deinen Zweig einen Commit weiter oben ein:

git rebase gen7-arm~58

Dann wieder probieren, ggf. ergänzen, committen. Dann noch eins weiter hoch ... und so weiter. Das geht dann in schönen kleinen Schritten und wenn Du mit deinem Zweig stm oben im Zweig gen7-arm angekommen bist, dann laufen auch bei Dir die Schrittmotoren.

Das MBED, von dem da immer die Rede ist, gibt's hier: [github.com] Wenn da die Dateien für Dein Board fehlen, muss man die irgendwo beim Hersteller ausgraben.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
bianchifan
allinclusive halt.
Prozzi putt -> board putt, Treiber putt -> Board putt,..etc..
Außerdem kann ich die Treiber nicht nach Belieben tauschen.

Also das RADDS set kostet mal eben so 200€ ... da bekomme ich 4 solche boards, da kann schonmal was kaputt gehen und man ist immer noch günstiger.
ja das mit den fixen Treibern find ich auch nicht berauschend, aber es sind alle Leitungen über Pfostenstecker zugänglich, also kann man leicht externe Treiber anschließen.

Quote

Hier, dieser LPC1114 ist mit seinen bescheidenen 48 MHz schon schneller als die Konkurrenz. Seit heute laufen die Schrittmotoren, mit bis zu 128.000 Schritten/Sekunde

Sehr schöne Arbeit.

Habt Ihr Euch schon mal die M Serie der ATmegas angeschaut? - ist zwar kein 32bit, ...
... aber deren ADC kann 2MS/s und dank interenem Takt von 64MHz können PWM mit 250kHz erzeugt werden.
Die Powerstage kann direkt mit dem ADC als Trigger verdrahtet werden ...

1-mal bearbeitet. Zuletzt am 03.08.15 01:27.

Quote
Brummie
Habt Ihr Euch schon mal die M Serie der ATmegas angeschaut?

Mach' ein Board, dann kannst Du die Teacup drauf portieren. Nur ... Schrittmotoren laufen nicht mit PWM.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

Schrittmotoren laufen nicht mit PWM.

Nicht?

OK, ich habe ja keine Ahnung - dachte bislang, dass die Strombegrenzung der einzelnen Schritte über PWM gelöst würde und somit die Samplingrate des ADC der limitierende Faktor wäre.

Wenn dem nicht so ist, was limitiert dann die Übertragungsrate, bzw. die Schritte pro Sekunde?

Der Strom wird von den Treibern bergrenzt. Da hat der AVR/ARM nix mit am Hut. Die Treiber benötigen nen High/Low-Signal auf dem STEP-Eingang. Dann macht der Motor einen Schritt. Und das wird über eine digitalWrite gelöst. Wobei dieses digitalWrite in den meisten Firmwares über eine direktere Variante gelöst wird. (Registerzugriff) Und das ganze in einem Interrupt.

Der ADC ist nur für die Temperatur zuständig. Und die laufen vielleicht mit 2kHz wenn es hoch kommt.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Traumflug
Dann hole das mal wieder hervor, zwischen Java (wie abartig für ein embedded Board)

Das bleibt solange verbuddelt, bis mir eine sinnvolle Anwendung dafür einfällt.
Ich bin vor einiger Zeit auf konsequentes objektorientiertes Design umgestiegen.
Das ist für mich ein kompletter Paradigmenwechsel, prozedurale Geschichten haben da keinen Platz mehr.
Einzige Ausnahmen sind minimale kosmetische Korrekturen.

Quote
Traumflug
Die Teacup nimmt den arm-none-eabi-gcc

Teacup hatte ich mir vor einem Jahr kurz angeschaut.
Es gab keine Unterstützung für grafische Displays, der Aufwand einer Implementation war mir zu hoch.

Quote
mantus
Also das RADDS set kostet mal eben so 200€ ... da bekomme ich 4 solche boards, da kann schonmal was kaputt gehen und man ist immer noch günstiger.

Für meinen DUE habe ich zwischen 13 und 14 Euronen gelatzt, für das letzte RAMPS 5,50 Euro.
Kleinteile wie gescheite FETs e.t.c waren vorhanden, mehr als 10 Euro werden da sicherlich nicht zusammen kommen.
Für weitere 10Eur bekommt man ein 5er Set DRVs, optional kann man für 25Euro noch zwei TMEs drauf packen.

Fazit: Pi x Erbsensuppe bekommt man für den gleichen Betrag eine solide HW für Marlin4DUE, sofern man Seitenschneider und Lötkolben halten und bedienen kann.

Quote
bianchifan
Das bleibt solange verbuddelt, bis mir eine sinnvolle Anwendung dafür einfällt.

Eine mögliche Anwendung ist, damit einen Drucker zu steuern. Muss man nur passend verdrahten.

Quote
bianchifan
Ich bin vor einiger Zeit auf konsequentes objektorientiertes Design umgestiegen.
Das ist für mich ein kompletter Paradigmenwechsel, prozedurale Geschichten haben da keinen Platz mehr.

Ah, immer diese Fetischisten :-) Der Lauf eines Druckers ist eine Prozedur, also kommt man um ein prozedurales Design gar nicht herum. Man kann natürlich versuchen, da Objekte rein zu pressen, doch die Schrittmotoren werden keine Events schicken, um nach dem nächsten Schritt zu fragen.

Quote
bianchifan
Teacup hatte ich mir vor einem Jahr kurz angeschaut.
Es gab keine Unterstützung für grafische Displays, der Aufwand einer Implementation war mir zu hoch.

Da werkeln inzwischen mehrere dran, das Verlangen nach einem Mäusekino ist schon hoch. Zumindest das Display funktioniert wohl, Tastenbedienung ist noch in Arbeit. Ist nicht einfach, die Leute vom komplizierten Marlin weg, hin zu einer einfachen und intuitiven Bedienung zu bekommen.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

Der Strom wird von den Treibern bergrenzt. Da hat der AVR/ARM nix mit am Hut. Die Treiber benötigen nen High/Low-Signal auf dem STEP-Eingang.

OK, dann wiederhole ich meine Frage nochmal: wodurch wird dann die Step-Rate begrenzt?
... oder anders gefragt:
Wieso sind 128kHz als Digital-out ein guter, bzw. überhaupt bemerkenswerter Wert?
Da sollte doch jeder Tiny im Traumflug beherrschen

Bitte nicht falsch verstehen - nicht als Kritik! Ganz im Gegenteil - ich würde es nur gerne verstehen.

... der Controller muß ja nicht nur takten ... er hat nebenher noch ein paar andere Berechnungen zu machen - z.B. für die Temperaturregelung, Beschleunigung/Abbremsung von 4 Achsen mit Bahnvorausschau, Serielle Kommunikation, u.a.m. ...

Die kommerziellen CNC-Controller tun sich auch schwer damit - ich habe einen, der kann bis zu 8 Achsen simultan, hat aber mit nur 3 Achsen scon seine Mühe auf 120kHz zu kommen ohne daß die Mommunikation abstürzt

---

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]

Dazu musst ja auch ein wenig mehr machen als nur einen Pin von 1 auf 0 zu schalten. Im Quadstepping, eine unregelmäßige Schrittverteilung, schafft der Due mit Marlin wohl irgendwas um die 300kHz. Und ganz nackt ohne Rampen etc. ist wahrscheinlich noch viel mehr möglich. Aber du musst Rampen berechnen, die Temperatur regeln, gcode empfangen und verarbeiten, usw.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Hi,

danke für die Aufklärung!

Aus den Ossi-Screenshots konnte ich nicht heraus lesen, unter welchen Bedingungen die zustande kamen.
Wenn man alle Tasks zusammen nimmt - klar, da kommt schon was zusammen.

Quote

Aber du musst Rampen berechnen, die Temperatur regeln, gcode empfangen und verarbeiten, usw.

Ok, aber die Tätigkeiten haben doch unterschiedliche Priorität, sodass die Schritterzeugung dadurch nicht beeinträchtigt werden dürfte.

Bei einer simplen Home-Funktion sind dann wohl schnellere Übertragungs- / Verfahrgeschwindigkeiten drin - nicht wahr?
Wenn man die Pins geschickt belegt, dürfte es auch keine Rolle spielen, ob 3 oder 8 Motoren angesteuert werden.

1-mal bearbeitet. Zuletzt am 06.08.15 04:45.

Es werden ja selten alle Motoren "gleich" angesteuert. Die brauchen schon alle eine eigene Taktung, da die ja auch unterschiedlich laufen. Und auch während des Homen's laufen ja noch andere Dinge auf der CPU, die die Geschwindigkeit ausbremsen.

Ich habe irgendwo ne Seite gesehen wo jemand mit einem Arduino Mega 2560 einen einzelnen IO-Pin mit 4 MHz geschaltet bekommt. Dann macht die CPU aber nichts anderes, außer den PIN zu schalten. Bei dem Test ging es um einen Benchmark, was die schnellste Art ist um einen PIN zu schalten... Also sehr theoretisch...

Normal laufen die Motoren mit einem Bresenham-Algorithmus. Da wird der schnellste Motor genommen und die Schritte von den anderen Motoren darauf gleichmäßig verteilt.

Auch beim homen werden weiterhin die Temperatur etc ausgelesen. Zudem muss beim homen auch noch der Endschalter gelesen werden.

Und die Rampen werden je nach Firmware unterschiedlich berechnet. Teacup hat dafür einen eigenen Timer der alle glaube ich alle 10ms die Schrittrate neu berechnet. Marlin berechnet bei jedem neuen Segment die Beschleunigung neu aus und bei jedem Schritt dann auch noch die Dauer. Dadurch laufen die Motoren recht ruhig, was allerdings auch sehr Performancelastig ist. Wobei die Ruhe dann auch im double und quadstepping beim AVR wieder verloren gehen (ob man das hören kann, kann ich nicht sagen).

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Brummie
Aus den Ossi-Screenshots konnte ich nicht heraus lesen, unter welchen Bedingungen die zustande kamen.

Es ist das Step-Signal eines einzelnen Schrittmotors, wenn man einen Verfahrbefehl nur für diesen einen Schrittmotor schickt. Das sind sozusagen die Idealbedingungen. Eine zweite Achse gleichzeitig und man erreicht diese Schrittrate schon nicht mehr.

Quote
Brummie
Ok, aber die Tätigkeiten haben doch unterschiedliche Priorität, sodass die Schritterzeugung dadurch nicht beeinträchtigt werden dürfte.

Prioritäten erhöhen die Rechenleistung nicht. Ist die CPU voll ausgelastet, ist sie voll ausgelastet. Die Berechnung der Schritte beansprucht im Extremfall ungefähr 99% der Rechenleistung. Nur um herauszufinden, wann welcher Motor den nächsten Schritt machen soll. Sowohl AVR als auch ARM brauchen dafür etwa 300 - 350 CPU-Takte. Wenn Dir ein einfacherer Algorithmus einfällt, der mit weniger Takten auskommt: nur zu. Bei der Teacup sind all die Berechnungen in dda_step().

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@Traumflug und @Wurstnase, da ihr euch da ja besonders gut auskennt: Wenn man mal von der bisherigen Funktionsweise einer Reprap-Firmware wegdenkt und die Aufgaben etwas neu verteilen würde, wäre das folgende eine mögliche Lösung für das Problem der maximalen Motorfrequenz?

Anstatt den G-Code aus dem Slicer/Host direkt an die Firmware zu senden, sende ich diese an ein Stück Software, daß auf einer schnellen Maschine läuft. Diese Maschine kann nicht nur mit dem G-Code umgehen, sondern kennt auch die exakten mechanischen und elektronischen Parameter des Drucker. Somit ist dieses Stück Software in der Lage, die gesamten notwendigen Schritte und die Beschleunigungskurven aller Motoren "Ahead of Time" vorzuberechnen. Ob man diese jetzt komplett im Vorraus berechnet oder Häppchenweise ist dabei ja erstmal egal. Diese Daten werden nun anstelle des G-Codes an die Firmware gesendet. Die Firmware ist nun nur noch dafür verantwortlich, daß die IO-Pins in der richtigen Reihenfolge ein und ausgeschaltet werden um das STEP-Signal für die Treiber zu generieren. Dazu muss dann aber nicht mehr viel gerechnet werden und so sollten sich die 300-350 CPU-Take zur Berechnung der Schritte deutlich senken lassen. Damit sollte dann doch die mögliche Motorfrequenz deutlich erhöht werden können und/oder die Zeit für andere Aufgaben frei werden.

Sehe ich das jetzt zu naiv oder wäre das theoretisch eine denkbare Lösung (mal unabhängig davon, daß dies die gesamte Kompatibilität mit aktueller Software über den Haufen werfen würde und sicherlich ein nicht unerheblichen Aufwand darstellen würde)?

---

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

Und wie schnell denkst du kann man den haufen an Daten an den ARM/AVR senden? Und das auch noch Pünktlich? Woher soll die Software dann noch wissen wo sich der Drucker befindet?
Da gibt es dann noch ein haufen anderer Sachen die man lösen müsste. Sicherlich nicht schneller, und vor allem deutlich komplizierter und wahrscheinlich teurer.

1-mal bearbeitet. Zuletzt am 06.08.15 08:42.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Glatzemann
Wenn man mal von der bisherigen Funktionsweise einer Reprap-Firmware wegdenkt und die Aufgaben etwas neu verteilen würde [...] ?

... dann würde exakt das heraus kommen, was die Teacup derzeit macht. Der Bresenham-Algorithmus ist das Schnellste, was sie Welt der Algorithmen für derartige Probleme kennt.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Das ist sicherlich unmöglich, wenn man einfach die reinen Step-Daten über das serielle Interface an den ARM/AVR sendet. Meine grundsätzliche Idee ist halt, soviele aufwendige Berechnungen auszulagern um Zeit zu sparen und den ARM/AVR zu entlasten. Ist ein sehr früher Gedanke... Ich habe mir die ganzen Dokumente zur Ansteuerung von Step-Motoren und Beschleunigungsrampen etc. und die Sources der unterschiedlichen Firmwares noch nicht komplett reingezogen und stehe da noch recht am Anfang, daher übersehe ich vielleicht noch einen wichtigen Aspekt...

---

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

@Traumflug: Teacup plant die gesamte Bewegung aller Achsen inkl. der Beschleunigungen bevor der eigentliche Druck losläuft?

Im Endeffekt sagst du, daß Teacup die beste aller möglichen Lösungen für die Herausforderung der Ansteuerung von 3D-Druckern darstellt?

---

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

Quote
Glatzemann
daher übersehe ich vielleicht noch einen wichtigen Aspekt...

Ja, z.B. dass wenn man für jeden Schritt nur ein einziges Byte schickt, man eine Datenübertragunsrate von > 1 Mbit braucht.

Einen Schrittmotor zu bewegen ist einfach:

WRITE(X_STEP_PIN, 1);
WRITE(X_STEP_PIN, 0);

Alles Andere sind Berechnungen, wann genau welcher Motor einen Schritt machen soll. Alle Motoren synchron, Beschleunigung, für Fortgeschrittene auch noch kontinuierliche Richtungsänderungen wie Kurven und/oder die Umrechnung Delta->karthesisch.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Die Idee ist ja auch nicht, daß ich die einzelnen Step-Daten einfach über die serielle Schnittstelle an den ARM/AVR sende und dieser dann nur noch digitale Writes ausführt. Die Idee ist, den G-Code "Ahead of Time" soweit aufzubereiten und eine Datenstruktur zu erzeugen, die an den ARM/AVR gesendet wird, so daß diesem die Aufgabe zur eigentlichen Taktgenerierung der Stepper-Motoren deutlich einfacher fällt und damit weniger Zeit verbraucht.

Mir ist schon vollkommen klar, daß die jetzige Vorgehensweise sicherlich nicht schlecht ist. Das wäre auch vermessen das zu behaupten, denn sie wird ja schon seit vielen Jahren erfolgreich (nicht nur bei 3D-Druckern) eingesetzt. Das bedeutet aber ja nicht, daß diese Lösung auch das Optimum ist. Wenn niemand mehr über den Tellerrand schauen würde und sich keine Gedanken über vielleicht bessere Lösungen machen würde, dann hätten wir keinen Fortschritt mehr...

---

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

Quote
Glatzemann
Teacup plant die gesamte Bewegung aller Achsen inkl. der Beschleunigungen bevor der eigentliche Druck losläuft?

Das ist nicht möglich. Ein Druck braucht Milliarden von Schritten, da müsste man eine ganze Festplatte vollstopfen. Eine Stunde drucken bei 100.000 Schritten/Sekunde bedeuten 100.000 * 60 * 60 = 360 Millionen Schritte.

Sie entkoppelt aber die Geschwindigkeitsberechnungen (Beschleunigung, Richtungsänderungen) von den einzelnen Schritten. Bei hoher Geschwindigkeit werden zwischen 2 Geschwindigkeitsberechnungen 10, 20, 40 Schritte ausgeführt. Die Geschwindigkeit 500 Mal in der Sekunde zu berechnen ist völlig ausreichend.

Quote
Glatzemann
Im Endeffekt sagst du, daß Teacup die beste aller möglichen Lösungen für die Herausforderung der Ansteuerung von 3D-Druckern darstellt?

Wäre das nicht so, hätte ich es schon geändert.

Quote
Glatzemann
Wenn niemand mehr über den Tellerrand schauen würde [...]

Über den Tellerrand schauen reicht nicht. Den Entwicklern fehlt es ganz sicher nicht an Ideen. Es braucht Code.

Anfangs wurden die Beschleunigungsberechnungen sogar tatsächlich ausgelagert, da bestand jede Bewegung aus 3 Zeilen G-code: 1 Zeile für die Beschleunigung, 1 Zeile für den gleichmässigen Teil, 1 Zeile für das bremsen. Damit fand das ganze Lookahead im PC statt. Der Haken war, dass die RepRapFirmware, die das als Erste konnte, keinen Puffer hatte, nach Ende der Beschleunigung also eine kleine Pause eintrat, um die nächste Zeile zu laden. Die Teacup hat das behoben, doch das hat niemanden interessiert. Statt dessen wurde überall herum trompetet, dass Beschleunigung Quatsch ist.

So läuft das bei RepRap. Logik oder Sorgfalt interessiert niemanden. Es zählt die Lösung, die am schnellsten zum "es druckt" führt. Egal wie dämlich sie ist und fast egal was sie kostet.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY