32bit für 50€ all inkl.

Hi,

inzwischen ist der Fred etwas abgedriftet, aber das Thema interessiert mich sehr.

Quote

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.

Ok, da habe ich mich schlecht ausgekwetscht
Mit Prio meinte ich, wie oft der Code pro Zeiteinheit ausgeführt werden muss. Oft kann man ja die CPU-Last senken, indem man den Code einfach nicht sooft ausführt, bzw. ihn zu dedizierten Zeiten ausführen lässt.
Aber das hast Du ja schon gemacht:

Quote

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

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.

Ich bin gerade erst dabei, den Code zu lesen und etwas zu verstehen ...
... kann also noch keinen Code liefern.

Aber was ich schon gesehen habe: die Step-Signale werden mit dem WRITE-Makro erzeugt. Das ist natürlich eine gewaltige Performancebremse.
Es ließe sich bestimmt einiges an Geschwindigkeit herausholen, wenn bei den Geschwindigkeitsberechnungen die Bits in einer Speicherstruktur gesetzt würden und zur Erzeugung der Step-Signale ein ganzes Byte auf den Port geschrieben würde.

Wenn man festlegt, dass man max. 4 Stepper unterstützen will, könnte man ein halbes Byte für die Step-Signale reservieren und ein halbes Byte für die Dir-Signale. In der zeitkritischen Routine wären dann beide Signale für alle Stepper gleichzeitig gesetzt. Wenn man bis zu 8 Steppern unterstützen will, gibt es eben 2 ganze Bytes und die zeitkritische Routine hätte zwei Schreibaktionen.
Damit sind die Geschwindigkeiten der Stepper zwar von einander abhängig, aber das scheint ja sowieso schon so zu sein.

Wenn die Schrittmotor-Treiber max. 300kBit/s am Eingange annehmen können, braucht die Firmware ja nicht mehr liefern können. Allerdings wäre es schick, wenn es die Schrittmotor-Treiber ausreizen könnte

Das WRITE Macro ist eines der wichtigsten Teile für die Geschwindigkeit. Damit werden die Register direkt beschrieben. Das dauert 2 bis 3 Cycles.
Zwei Register gleichzeitig beschreiben kann glaube ich nur der ARM und dazu müssen die Pins auf der gleichen Bank liegen. Sparen wird man dadurch aber kaum was.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Brummie
Aber was ich schon gesehen habe: die Step-Signale werden mit dem WRITE-Makro erzeugt. Das ist natürlich eine gewaltige Performancebremse.

So, ist es das? Weil Du es bist, habe ich mal ein kleines Beispiel programmiert:

In C:

#include "pinio.h"

void onestep(void) {
  WRITE(X_STEP_PIN, 1);
  WRITE(X_STEP_PIN, 0);
}

Nach dem Preprozessor:

void onestep(void) {
  do { ((LPC_GPIO_TypeDef *) ((0x50000000UL) + 0x10000) )->MASKED_ACCESS[(1 << 5)] = (1) ? (1 << 5) : 0; } while (0);
  do { ((LPC_GPIO_TypeDef *) ((0x50000000UL) + 0x10000) )->MASKED_ACCESS[(1 << 5)] = (0) ? (1 << 5) : 0; } while (0);
}

In Assembler:

	mov	r2, #32
	ldr	r3, .L2
	str	r2, [r3, #124]
	mov	r2, #0
	str	r2, [r3, #124]

.L2:
	.word	1342242820        ; = 0x50010004

Wo genau willst Du da jetzt noch einen Takt sparen?

*hmpf* Nicht nur, dass man die Fleissarbeit in der Firmware quasi allein machen muss, man wird auch noch für blöd hingestellt. Da waren schon diverse sehr fähige Leute dran ich und selber habe ich schon dutzende Stunden mit SimulAVR verbracht, um auch den letzten Takt rauszuquetschen.

Quote
Brummie
Es ließe sich bestimmt einiges an Geschwindigkeit herausholen, wenn bei den Geschwindigkeitsberechnungen die Bits in einer Speicherstruktur gesetzt würden und zur Erzeugung der Step-Signale ein ganzes Byte auf den Port geschrieben würde.

Nur tun Dir die Controller-Hersteller eben nicht den Gefallen, alle Step-Pins auf einem einzelnen Port anzuordnen, denn das macht das PCB-Layout deutlich komplizierter. Dazwischen sind Pins, die nicht beschrieben werden dürfen. Und das schreiben dieser Bitmaske in die Variable dauert genauso lange wie wenn man sie gleich auf den Port schreibt.

Quote
Brummie
Damit sind die Geschwindigkeiten der Stepper zwar von einander abhängig, aber das scheint ja sowieso schon so zu sein.

Diese Abhängigkeit ist aber nicht 1:1. Eine völlig normale Bewegung macht auf dem X-Motor 297 Schritte, auf dem Y-Motor 22 Schritte, auf Z 0 Schritte und auf E 57 Schritte. Trotzdem müssen alle Motoren zur genau gleichen Zeit mit allen ihren Schritten fertig sein und dazwischen die Schritte gleichmässig verteilt haben. Letzteres schafft der Bresenham übrigens nur bedingt, deswegen gibt es da dieses ACCELERATION_TEMPORAL, das ohne Bresenham auskommen will.

Soweit so gut. Es gibt einige Verbesserungen für den Bresenham-Algorithmus, der ja ursprünglich für die Pixel-Grafik erdacht wurde. Bislang habe ich aber keine gefunden, die sich auch auf Schrittmotoren anwenden liesse.

Sowieso, den Bresenham mal für Bezier-Kurven zu implementieren wäre viel sinnvoller. Mit konstanter Geschwindigkeit(!), ohne Zerlegung in Geradenstückchen. Damit könnte man einige sehr schöne Sachen anfangen, z.B. jerk-freies Lookahead.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Nicht immer so garstig
Aber sehr schöne Zusammenfassung!

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
Nicht immer so garstig

Sag' mir mal ein Rezept, wie man die Leute dazu bringt, sich mit was Sinnvollem zu beschäftigen. Die Teacup hat rund 50 bekannte Macken, alle fein säuberlich im Issue Tracker aufgelistet. Manche davon sogar schon gelöst, man müsste das nur ausprobieren.

Da kümmert sich niemand drum. Aber wenn man was macht, springen die Leute genau da drauf und wollen das Ergebnis von mehreren Wochen Recherche und Detailarbeit mit einem Fingerschnippen noch besser machen. Noch so ein Beispiel: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Ich hab ja ne Ahnung womit das zusammenhängen könnte

---

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

Ja ja, weil ich so garstig bin.

Ich kann das auch anders, habe ich lange genug praktiziert. Doch dann macht man sich als Entwickler vollends zum Trottel. Fragen über Fragen beantworten, bis die Leute wirklich nur noch meine Antworten mit Copy&Paste eintragen müssen, um es als ihre eigene Arbeit verkaufen zu können. Da gab's zeitweise so einen Australier, dem ich im IRC noch erklären musste, welchen Texteditor er am besten nimmt und wie man ein paar Zeilen von hier nach dort kopiert. Genau der wollte dann auch eben mal so einen Multicore-PIC bauen und eine Firmware dafür schreiben.

Seit ich meine Laune recht ungeniert raus hängen lasse, geht wenigstens überhaupt was vorwärts.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Ich kann dich schon verstehen...

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote

... man wird auch noch für blöd hingestellt.

Ich bin verantwortlich für das, was ich schreibe - nicht für das, was Du verstehst

Quote

Wo genau willst Du da jetzt noch einen Takt sparen?

5 Anweisungen um einen Pin zu setzen, ist schon ne Menge Holz.

Mal sehen - 4 Stepper brauchen jeweils 2 Pins (Step und Dir), macht also zusammen 20 Anweisungen.

Wenn man jetzt Bits in einem Feld einer Struktur setzt, braucht man kein so exzessives Makro wie WRITE - sollte also mit weniger Takten gehen.
In der zeitkritischen Schleife wird dann ein ganzes Byte kopiert. Wenn man das aus einer Struktur nimmt, sollte das auch in 4 Takten gehen - aber eben einmalig.

Wenn ich dann noch davon ausgehe, dass das Byte in der Speicherstruktur in weniger zeitkritischen Phasen geschrieben werden könnte, dann wäre die Einsparung sicher messbar.

Quote

Nur tun Dir die Controller-Hersteller eben nicht den Gefallen, alle Step-Pins auf einem einzelnen Port anzuordnen, denn das macht das PCB-Layout deutlich komplizierter. Dazwischen sind Pins, die nicht beschrieben werden dürfen.

??? - sorry, aber ich kenne nur 8-Bit Controller von Atmel - bei ARM kann ich nicht mitreden.
Also bei den (zumindest größeren) Atmel-Professoren gibt es mit Sicherheit 2 Ports, die man als gesamtes beschreiben kann.
... und ich kann mir beim besten Willen nicht vorstellen, dass es sowas bei den ARM-Prozessoren nicht geben soll.

Vielleicht ist es ein Problem am Boardlayout?

Ist eben die Frage: muss sich die Firmware dem Boardlayout unterordnen, oder kann die Firmware auch Richtlinien für zukünftige Boards vorgeben?
Wenn man jetzt feststellen würde, dass die Firmware bei anderem Boardlayout die Stepper 10% schneller ansprechen könnte, dann wäre das doch eine Grundlage, auf der man ein neues Board layouten könnte.

Quote

Diese Abhängigkeit ist aber nicht 1:1. Eine völlig normale Bewegung macht auf dem X-Motor 297 Schritte, auf dem Y-Motor 22 Schritte, auf Z 0 Schritte und auf E 57 Schritte.

Naja - ich habe gesehen, dass der Timer in der Periode variiert, aber das obige Beispiel ist sicherlich nicht mit einem Timer umsetzbar.
Deshalb würde ich es als hilfreich ansehen, wenn nicht Äpfel mit Birnen verglichen werden, sondern dass man die Zugeständnisse, die es sowieso schon gibt, auch in der Diskussion berücksichtigen würde.
Ich halte mich auch für nicht ganz doof - auch wenn ich derzeit noch keinen Code besteuern kann.

Quote

Soweit so gut. Es gibt einige Verbesserungen für den Bresenham-Algorithmus

Hm, also da muss ich auf jeden Fall passen. Bin kein Mathematiker, der mal eben einen neuen Algoritmus aus dem Ärmel schüttelt.
Ich denke, wenn man das Optimierungspotential ausschöpft, was derzeit noch vorhanden ist, ließe sich auch die eine oder andere Anweisung einsparen
frei nach dem Motto: mühsam ernährt sich das Eichhörnchen

Ich kann natürlich nur Sachen ansprechen, die mir auffallen.

Da ich das große Ganze noch nicht auf der Tafel habe, muss natürlich jemand die Vorschläge unter die Lupe nehmen, der sich damit auskennt.
Wenn man diese Diskussion in einem Klima gegenseitigen Respekts und Verständnisses führen könnte, würde das sicher auch vieles entspannen.

Quote

Sag' mir mal ein Rezept, wie man die Leute dazu bringt, sich mit was Sinnvollem zu beschäftigen.

Hm, man sollte den zweiten Schritt nicht vor dem ersten tun

Wenn man sich mit der Firmware beschäftigen möchte, ist erstmal Lesen angesagt.
Ich habe mir beispielsweise Marlin, Teacup und Smoothieware herunter geladen. Nach kurzem Überfliegen der unterschiedlichen Baustellen musste ich feststellen, dass mir persönlich Teacup am ehesten zusagt.
Also habe ich mir den Code näher angeschaut.
Wenn man selber schon einige Firmwares erstellt hat, dann fällt einem eben "on-the-fly" Optimierungspotential auf.
Ich denke, es macht wenig Sinn, wenn ich über Dinge rede, von denen ich keine Ahnung habe. Also beschränke ich mich auf das, was ich überschauen kann. Ob meine Vorstellungen sinnvoll sind - das kann ich noch nicht beurteilen.

Wenn ich Optimierungspotential anspreche und das dann als Majestätsbeleidigung aufgefasst wird - nun gut - dann macht es wohl wenig Sinn, mich noch näher mit der Firmware auseinander zu setzen.

Quote

Seit ich meine Laune recht ungeniert raus hängen lasse, geht wenigstens überhaupt was vorwärts.

Das ist auf jeden Fall ne gute Basis. Ich mag Leute, die gerade heraus sind und mir auf den Kopf heraus zusagen, was sie denken.
Wenn wir jetzt noch schaffen, dass Du nicht bei jedem Pups eingeschnappt bist, dann könnte das eine fruchtbare Basis werden

1-mal bearbeitet. Zuletzt am 07.08.15 01:28.

@ "Brummi"

Was soll das hier eigentlich werden?

Wenn du anderer Ansicht bist, andere Vorschläge od. bessere Lösungen hast, dann kannst du sie hier im Forum gerne rüberbringen.
Ich bin hier nicht der einzige der deine Beiträge liest und auch nicht der einzige, der sicherlich der Meinung ist; es geht auch anders.

Warum lässt du hier den Oberlehrer raushängen und wunderst dich, wenn dann die Leute die sich schon sehr lange mit den Dingen
intensiv auseinandersetzen und mit Sicherheit versiert sind, dann stinkig werden?

> Wenn wir jetzt noch schaffen, dass Du nicht bei jedem Pups eingeschnappt bist, dann könnte das eine fruchtbare Basis werden<
Was willst du denn überhaupt? Willst du elegant stänkern, oder brauchst du Anerkennung?

Bis jetzt ist es hier im Forum recht wohlwollend zuvorkommend und freundlich zugegangen.

> Ich bin verantwortlich für das, was ich schreibe - nicht für das, was Du verstehst <
So ne plumpe Anmache, wie soll man das wenn anders verstehen.

Beste Bastlergrüße 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 . . .

Also vorneweg, ich möchte keine Firmware optimieren aber ich finde, Ihr seid etwas ungerecht.

Er kann nichts dafür, wie die Botschaft bei Euch ankommt aber in seinem erweiterten Post erklärt er sich ja. Er möchte keine Leute beleidigen oder für unfähig halten. Er hat nur ne Idee, die er anbringen will. Mal ganz unabhängig, ob er keine Ahnung hat oder auf dem Holzweg ist. Er greift doch höchstens den Ego des Entwicklers an, der aber über diese Anmaßung stehen muss. Wenn der Code nicht optimierbar ist, kann @Brummi nur auf die Schnautze fallen und die Profis haben es geahnt.
Lasst Ihm doch wenigstens die Chance, nicht schon im Vorfeld zerrissen zu werden und zwar so, dass er ganz die Lust verliert.

@Brummi: Mein Tipp an Dich wäre ja, Deinen Idee in einem Codeteil einfach mal selbst umzusetzen und mit echten Ergebnissen Interesse zu wecken.

Gruß Andreas,
der vor vielen Jahren auch schon Mnemonics büffeln durfte, aber darin dann schließlich nicht seine Lebensaufgabe sah.

1-mal bearbeitet. Zuletzt am 07.08.15 03:37.

---

Einen Sparkcube 1.1XL für größere Objekte, einen Trinus3D im Gehäuse und einen Tantillus R im Bau und einen Qidi Tech Q1 Pro im Zulauf.
Sparkcube: Komplett auf 24V - DDP 8mm + 1,5mm Carbonplatte - RADDS 1.5 + Erweiterungsplatine + RAPS128 - Nema 17/1,7A 0,9 Grad - ind. Sensor für Z-Probe (kein ABL) - FTS - Titan Booster Hotend - Sparklab Extruder - Firmware Repetier mit @ Glatzemanns G33 - Repetier Server pro - Simplify3D

Ich hab zwar nur die Hälfte von dem Verstanden, was hier zum Thema Steppertaktung geschrieben wurde, aber mir ist klar geworden, dass man mit "ein paar eingesparten CPU Takten" keine Verdoppelung der Taktrate hinbekommt. Und genau das wäre ja nötig um 1/64 Microstepping ( oder sogar 1/128 ) mit dem Mega2560 hinzukriegen.

Also bleibt alles wie es ist und wir widmen uns wieder dem Thema, gelle?
In der internationalen Diskussion hatte ich gefragt, ob man die DC-DC-Rausch-Probleme die das MKS-Sbase bord V1 zu haben scheint, damit in den Griff bekommt, das man den onboard Regulator abklemmt und statt dessen einen RC-UBEC einsetzt oder die 5V von einem PC PSU?

-Olaf

1-mal bearbeitet. Zuletzt am 07.08.15 03:43.

Quote

Warum lässt du hier den Oberlehrer raushängen und wunderst dich, wenn dann die Leute die sich schon sehr lange mit den Dingen
intensiv auseinandersetzen und mit Sicherheit versiert sind, dann stinkig werden?

Hm, vielleicht haben wir unterschiedliche Auffassung von Höflichkeit.
Ich habe anfangs nur eine Frage gestellt und bin gleich wie ein Trottel behandelt worden.
Erst danach habe ich - wenn Du so willst - den "Oberlehrer" ausgepackt.
Von meiner Seite aus war das kein Oberlehrer, sondern ich wollte nur den Vorschlag konkretisieren, da ich absichtlich falsch verstanden wurde.

Quote

Was willst du denn überhaupt? Willst du elegant stänkern, oder brauchst du Anerkennung?

weder noch - wenn möglich würde ich gerne mithelfen, die Firmware zu verbessern.

Auch im Nachbarfred bin ich verrissen worden, obwohl ich mich eingebracht und Ergebnisse gezeigt habe.
Keine Ahnung, warum Neulinge erstmal als Trottel eingestuft und angefeindet werden :O

@Boui3D
danke für Dein Verständnis!

Quote

Mein Tipp an Dich wäre ja, Deinen Idee in einem Codeteil einfach mal selbst umzusetzen und mit echten Ergebnissen Interesse zu wecken.

Wenn ich das könnte, hätte ich es sicherlich schon gemacht.
Allerdings ist die Parser und DDA-Geschichte so verflochten, da braucht es schon eine ganze Weile, ehe ich da ansetzen kann.

Deshalb dachte ich, man könnte quasi auf Augenhöhe sachlich diskutieren.
Wenn mein Vorschlag Mist ist, kann man das ja auch begründen, ohne persönlich zu werden.

Aber ok - wenn ich hier unerwünscht bin, kann ich auch die Klappe halten.

Quote
Traumflug
Ah, immer diese Fetischisten :-) Der Lauf eines Druckers ist eine Prozedur, also kommt man um ein prozedurales Design gar nicht herum

Das hat nichts mit Fetischismus zu tun sondern eher mit der Entwicklung im Software-Design -> Design-Pattern
Z.B. habe ich seit geraumer Zeit keine Klasse mehr geschrieben..
Die hier gerade angespochene Stepperproblematik ist dafür ein Paradebeispiel.
Anstatt sich für jeden möglichen Prozessor über dessen Taktung/Registerstruktur das Hirn zu zermartern, sich auf die Optimierung möglicher Strategien zu konzentrieren und die hardwaretechnische Umsetzung dem Compiler/Optimierer zu überlassen.

Quote
Traumflug
Da werkeln inzwischen mehrere dran, das Verlangen nach einem Mäusekino ist schon hoch.

In meiner im Frühjahr letztendlich angeschafften rework-Station werkeln gemultiplexte 7-Segment-Anzeigen... sowas hatte ich irgendwann auch mal verbrochen. Heute gibt es OLEDs
Ich hatte eben einen RRD-fork entdeckt und geladen, leider hapert es mit der Compilierung in meiner IDE -> Konfigurierungsaufwand treiben.
Momentan keine Böcke...

Quote
o_lampe
Also bleibt alles wie es ist und wir widmen uns wieder dem Thema, gelle?
In der internationalen Diskussion hatte ich gefragt, ob man die DC-DC-Rausch-Probleme die das MKS-Sbase bord V1 zu haben scheint, damit in den Griff bekommt, das man den onboard Regulator abklemmt und statt dessen einen RC-UBEC einsetzt oder..f

RC-UBEC? Was soll das sein? Ein Drohnen-Controler-Spannungswander/-versorger?
Ist das denn rauschfrei?

1. Ein jeglicher Wandler rauscht prinzipbedingt, der Wandler auf dem DUE rauscht mit Sicherheit auch.
Wenn's stört -> filtern.
2. Problematik erkannt, all incl., also auch inclusive eventueller Nebengeräusche.

2-mal bearbeitet. Zuletzt am 07.08.15 05:54.

Quote
Brummie
Deshalb dachte ich, man könnte quasi auf Augenhöhe sachlich diskutieren.
Wenn mein Vorschlag Mist ist, kann man das ja auch begründen, ohne persönlich zu werden.

Aber ok - wenn ich hier unerwünscht bin, kann ich auch die Klappe halten.

So oder so ähnlich gilt das eigentlich eigentlich für sämtliche technisch orientierte Foren - ausnahmslos!

Da kann man auch drüber stehen..., man muss nicht auf jeglichen Pups reagieren.

Traumpflug ist 100%ig in Ordnung.
Sollte Dir einer seiner Beiträge launisch vorgekommen sein, es sei ihm gegönnt...

2-mal bearbeitet. Zuletzt am 07.08.15 06:04.

... zum Bresenham - es gibt/gab Varianten für Kreisbogenoptimierung (ich glaube der hieß "circular Bresenham") und für 3D-Interpolation - hier werden 3D-Splines aber in kurze lineare Segmente unterteilt und dann als Standard-3D-Bresenham gerechnet ...

---

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]

Quote
Brummie
Mal sehen - 4 Stepper brauchen jeweils 2 Pins (Step und Dir), macht also zusammen 20 Anweisungen.

Genau. Wenn Du jetzt 10 von diesen 20 Takten einsparst ist die Firmware gerade mal 3% schneller.

Quote
Brummie
[...] dann wäre die Einsparung sicher messbar.

Dann mache doch mal aus dem "wäre" ein "wenn". Da braucht es weder ein Oszilloskop noch Hardware. Es gibt einen prima Simulator, der das Ergebnis auf die Nanosekunde genau dokumentiert: [reprap.org]

Damit kann man die Zeit zwischen zwei beliebigen Punkten im Code messen, einfach am Anfang der Messstrecke die Debug-LED einschalten und am Ende wieder abschalten. Das Skript run-in-simulavr.sh lässt dann einen kompletten G-code ablaufen und protokolliert all die Einschaltzeiten der LED.

Quote
Brummie
Frage: muss sich die Firmware dem Boardlayout unterordnen

Ja.

Quote
Brummie
oder kann die Firmware auch Richtlinien für zukünftige Boards vorgeben?

Nein. Kein Mensch tauscht seinen Controller für Brummies Experimente aus.

Quote
Brummie

Quote

Diese Abhängigkeit ist aber nicht 1:1. Eine völlig normale Bewegung macht auf dem X-Motor 297 Schritte, auf dem Y-Motor 22 Schritte, auf Z 0 Schritte und auf E 57 Schritte.

Naja - ich habe gesehen, dass der Timer in der Periode variiert, aber das obige Beispiel ist sicherlich nicht mit einem Timer umsetzbar.

Es funktioniert bereits mit einem Timer.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@Brummie: Schau dir vielleicht mal diese beiden Dokumente an. Die sind für das Verständnis, wie man die Stepper mit AVR/ARM ansteuert recht hilfreich. Ich denke, daß diese Dokumente weitestgehend "State of the Art" sind:

AVR446: Linear speed control of stepper motor
Generate stepper motor speed profiles in real time

Das "Problem" mit der Hardware und Firmware ist sicherlich, daß hier weitestgehend günstige Standard-Boards (Arduino, etc.) eingesetzt werden. Es gibt Lösungen in Hardware, die die Aufgabe sehr elegant und sehr einfach für den Entwickler lösen. Da liegt dann aber bereits der Preis eines einzelnen Motortreibers deutlich über dem Preis eines günstigen Kompletts-Sets (Mega, Ramps, 5 Treiber inkl. Kühlkörper). Aber wenn es alles so einfach wäre, dann würde die Herausforderung ja schliesslich auch keinen Spaß mehr 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)

Quote
Brummie
Allerdings ist die Parser und DDA-Geschichte so verflochten, da braucht es schon eine ganze Weile, ehe ich da ansetzen kann.

Es ist gar nicht so kompliziert:

Bewegungen werden mit dda_create() vorbereitet, lange bevor sie ausgeführt werden. Da wird berechnet, wie viele Schritte man braucht, um das Ziel zu erreichen und so weiter. All die vorbereiteten Bewegungen liegen dann in einem Puffer; jeder Eintrag in diesen Puffer hat die Struktur DDA.

In dda_start() wird die Bewegung dann zu einem späteren Zeitpunkt gestartet, indem dda->life auf 1 und der Timer für den ersten Schritt gesetzt wird.

Der Schritt-Interrupt passiert in dda_step(). Das sind etwa 290 dieser 305 Takte. Am Ende eines Schrittes wird der Timer für den nächsten Schritt gesetzt.

Nebenher läuft dda_clock(), das alle 2 ms die benötigte Geschwindigkeit anpasst.

Wie der G-code geparst wird, ist also gar nicht wichtig. Auch nicht, wie und wann die DDAs in den Puffer kommen. Wichtig ist nur, dass das DDA in dda_create() und das in dda_start() zwei unterschiedliche DDAs sind, man kann also in dda_start() nicht auf die Variablen des dda_create() zurück greifen. Man hat nur, was im DDA steht.

Auch noch wichtig für das Verständnis: die Teacup kennt drei verschiedene Algorithmen, ACCELERATION_REPRAP, ACCELERATION_RAMPING und ACCELERATION_TEMPORAL. Davon wird immer nur eine rein kompiliert, man kann die beiden anderen ausser Acht lassen. Das ..._RAMPING ist die Voreinstellung und das, was am besten funktioniert.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
bianchifan
Das hat nichts mit Fetischismus zu tun sondern eher mit der Entwicklung im Software-Design -> Design-Pattern
Z.B. habe ich seit geraumer Zeit keine Klasse mehr geschrieben..
Die hier gerade angespochene Stepperproblematik ist dafür ein Paradebeispiel.

Richtig, gutes Beispiel! Nimmt man die von den Herstellern oder Arduino zur Verfügung gestellten Klassen, braucht alleine das ein- und ausschalten eines Pins satte 72 Takte. Und damit hat man schon verloren, bevor man sich über irgendwelche Patterns auch nur Gedanken machen muss. Eine Firmware ist eben keine Business-Software.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hallo,

danke, dass die Diskussion wieder sachlich wurde

Quote

Genau. Wenn Du jetzt 10 von diesen 20 Takten einsparst ist die Firmware gerade mal 3% schneller.

Danke! Das ist doch jetzt mal ein Argument, mit dem ich was anfangen kann.
Heißt also kwasi: die Zeit sollte man lieber woanders reinstecken :O

Quote

Dann mache doch mal aus dem "wäre" ein "wenn".

Bin dabei. Bitte aber um Nachsicht. Teacup ist so komplex, dass ich das nicht in einem Tag gebacken bekomme.
Selbst wenn ich mich auf das wesentliche beschränke ...

Quote

Nein. Kein Mensch tauscht seinen Controller für Brummies Experimente aus.

Das ist klar!
Aber wenn Traumflug sagt, dieses oder jenes Layout würde mehr Sinn machen, gäbe es sicherlich genügend Beachtung / Interessenten

Quote

Es funktioniert bereits mit einem Timer.

Mit den krummen Werten? Da wird doch sicherlich gerundet, oder nicht?

Quote

Schau dir vielleicht mal diese beiden Dokumente an.

Danke für den Tip, aber die kannte ich bereits.
Meiner Ansicht nach ist es ein großer Unterschied, ob ich nur einen Stepper steuere, oder versuche, dies mit mehreren gleichzeitig zu machen ...

Quote

Es ist gar nicht so kompliziert:

Sorry, aber ich bin schon ein alter Dackel - so schnell kapier ich so Geschichten dann nicht mehr :O
Trotzdem danke für die Erklärung.
Bis auf das Verhältnis der Takte hatte ich den Großteil auch schon rausgefunden

Quote

Richtig, gutes Beispiel! Nimmt man die von den Herstellern oder Arduino zur Verfügung gestellten Klassen, braucht alleine das ein- und ausschalten eines Pins satte 72 Takte.

Yepp, der Meinung bin ich auch. Das ganze Arduino-Geraffel ist doch nur Augenwischerei.
Man muss sich da genauso einarbeiten - und in (fast) der gleichen Zeit hätte man sich auch in "normale" AVR-Programmierung eingearbeitet.
Ist mit ein Grund, warum mir Teacup gefällt.

Quote
Brummie

Quote

Dann mache doch mal aus dem "wäre" ein "wenn".

Bin dabei. Bitte aber um Nachsicht. Teacup ist so komplex, dass ich das nicht in einem Tag gebacken bekomme.

Das Schöne an diesem SimulAVR ist, dass darin ein unverändertes Binary läuft. Du musst Dich also gar nicht um die Teacup kümmern, nur den SimulAVR an der richtigen Stelle an den Start bringen und das Makefile benutzen. Das Makro SIMINFO muss im Makefile gesetzt werden.

Man kann die Teacup auch auf dem Host-PC kompilieren und laufen lassen. make -f Makefile-SIM. Das ist was ganz anderes und eher für andere Themen wie Pfadplanung brauchbar.

Die Konfiguration erstellt man am besten mit dem Configtool, darin Menü -> File -> Save config.h. Das erstellt so Hilfsdateien wie temptables.h. Ist die config.h gespeichert, kann man auch mit dem Makefile bauen.

Quote
Brummie
Aber wenn Traumflug sagt, dieses oder jenes Layout würde mehr Sinn machen, gäbe es sicherlich genügend Beachtung / Interessenten

Wenn der Traumflug das sagt, dann will es erst recht keiner haben. Der Traumflug ist der Bad Boy bei RepRap. Über kein anderes Board wurde so viel geschimpft wie über die Gen7, obwohl die nach wie vor das schnellste ATmega-Board ist und, anders als all die RAMPS und Sanguinololus, mit tauglichen MOSFETs ausgestattet ist.

So oder so hat es aber keinen Zweck, für nur ein einziges Board zu programmieren. Das muss überall laufen, zumindest auf den gängigen Boards.

Quote
Brummie

Quote

Es funktioniert bereits mit einem Timer.

Mit den krummen Werten? Da wird doch sicherlich gerundet, oder nicht?

Nein, da wird nicht gerundet. Es geht trotzdem. Entweder mit dem Bresenham-Algorithmus oder indem man einen Timer für alle 4 Motoren verwendet. Letzteres kann man in dda_step() sehen, der Teil, der mit ACCELERATION_TEMPORAL eingezäunt ist. Trickreich, aber geht und ist fast noch schneller als der Bresenham.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
bianchifan
RC-UBEC? Was soll das sein? Ein Drohnen-Controler-Spannungswander/-versorger?
Ist das denn rauschfrei?

Genau sowas meine ich. Die sind rauscharm genug um die 2.4Ghz Empfänger nicht zu stören.
Ob das auch Vorteile für das MKS board und die AD-Wandler bringt, kann ich nicht sagen.
Analog ground sollte schon getrennt sein vom Rest, sonst legt man sich gleich die Karten bei all dem PID-geschalte... Ebenso wäre es sinnvoll nicht Vcc als Referenzspannung zu verwenden, sondern eine separate Vref, aber ich habe k.A ob das beim MKS oder anderen Boards so ist.

Zumindest ist die Störquelle nicht onboard.
-Olaf

Quote
Traumflug
Eine Firmware ist eben keine Business-Software.

Da hast Du wohl wahr..

Quote
Traumflug
Nimmt man die von den Herstellern oder Arduino zur Verfügung gestellten Klassen, braucht alleine das ein- und ausschalten eines Pins satte 72 Takte. Und damit hat man schon verloren, bevor man sich über irgendwelche Patterns auch nur Gedanken machen muss.

Was sagt uns das?
Letzten Endes doch nur, das es niemals ein wirkliches Konzept gegeben hat.
Das von irgendwem irgendein Code geschrieben wurde, welcher irgendwie läuft.

Nur zur Erinnerung: Arduino war nie ein Elektronik-Projekt, es war ein Kommunikations-Projekt als Schnittstelle Mensch-Maschine aus dem künstlerischen Umfeld.
meines Wissens nach gab es da einige Fans der Combo "Kraftwerk"

Ich habe ganz allgemein von OO-Design gesprochen, Arduino ist dort außen vor, für keinen Arduino gibt es virtuelle Maschinen.
Nur am Rande..für den STM32 aber wohl schon, z.Z. aber noch als exorbitant teure Spezialversion.

War viel Gelaber, im Kern soll das heißen, ich war zu keiner Zeit embedded-Entwickler und habe auch nicht vor, einer zu werden.
Mikrocontroller sind und waren nie mein Ding, ich weiß nicht einmal, wie sie aufgebaut sind.
Ich hätte nie gedacht, dass sie sich so lange halten würden.

Quote
Brummie
Das ganze Arduino-Geraffel ist doch nur Augenwischerei.

Damit liegst Du zweifelsohne richtig.
Arduino hatte mich nie interessiert, bis ich Anfang letzten jahres die Idee entwickelte, allen Vorbehalten zum Trotz über einen Drucker nachzudenken, mit dem ich nicht mehr erhältliche Ersatzteile für diverse Maschinen zusammenschustern kann.
Von der zwischenzeitlichen Verbreitung war ich erschlagen

Quote
Brummie
Man muss sich da genauso einarbeiten - und in (fast) der gleichen Zeit hätte man sich auch in "normale" AVR-Programmierung eingearbeitet.

Nö.
IDE aus dem Netz kopieren und installieren.
Sketches im Netz suchen, kopieren, laden.
Wenn Processing, friss oder Pech gehabt.
Wenn C ähnlich, also gcc, Änderungen theoretisch möglich.
Meistens funzt es, manchmal net, weil keine Ahnung vom Controller...manchmal hilft die Doku weiter.

Davon abgesehen geht es hier nicht um AVR...

Quote
Traumflug
Über kein anderes Board wurde so viel geschimpft wie über die Gen7, obwohl die nach wie vor das schnellste ATmega-Board ist und, anders als all die RAMPS und Sanguinololus, mit tauglichen MOSFETs ausgestattet ist.

Ich hatte das Gen7 seinerzeit überflogen, bevor ich mich für RAMPS - sprich modularer Aufbau - entschieden habe.
Ich hatte dazu u.a. auch hier eine Anfrage gestellt und wurde mit einer Flut hilfreicher Antworten zugeschüttet.
Auf allen meinen RAMPS werkelt ein IRLB3034, kennst Du einen besseren?

Quote
o_lampe
Genau sowas meine ich. Die sind rauscharm genug um die 2.4Ghz Empfänger nicht zu stören.
..
Analog ground sollte schon getrennt sein vom Rest, sonst legt man sich gleich die Karten bei all dem PID-geschalte... Ebenso wäre es sinnvoll nicht Vcc als Referenzspannung zu verwenden, sondern eine separate Vref,

Solange wir unsere Drucker nicht ins W-Lan hängen oder blauzahnen sind uns die 2,4 GHz schnuppe.
Ansonsten hast Du prinzipiell recht, andererseits fluppt das völlig außerirdisch designte RAMPS in den allermeisten Anwendungsfällen offensichtlich zufriedenstellend, allen grotesk zuwiderlaufenden Designrichtlinien.
NUr ab und an hapert es mit der Masse..

Gestern habe ich mir den thread noch mal grob angeschaut, der Entwickler ist wohl im Bilde und wird sein PCB überarbeiten.
Offensichtlich ist er auch wirklich bemüht, denn er hat wohl auch die Datenblätter der Stepperbetreiber gelesen und das krasse Fehldesign der Pololu/Stepsticks entdeckt und will die Käfer PCB-seitig kühlen.

Trotzdem bleibt es immer noch all inclusive und wenn ein Bauteil aushaucht darf ein unbedarfter Normalanwender das komplette Board tauschen.
Zumindest die Motortreiber sollten steckbar sein a la' Rumba.

Quote
bianchifan

Trotzdem bleibt es immer noch all inclusive und wenn ein Bauteil aushaucht darf ein unbedarfter Normalanwender das komplette Board tauschen.
Zumindest die Motortreiber sollten steckbar sein a la' Rumba.

Da bin ich deiner Meinung, weshalb ich gerade mit dem RADDS liebäugle. Allerdings kostet das ( ohne Treiber und Due board) schon so viel wie das komplette MKS-SBASE.
Da wäre es schlauer gleich 2 -3 MKS boards zu kaufen, neue Projekte finden sich dafür immer
-Olaf
PS: Ich kenne einen A112 Abarth Fan aus Minden....das bist nicht zufällig du?

Quote
o_lampe
, weshalb ich gerade mit dem RADDS liebäugle. Allerdings kostet das ( ohne Treiber und Due board) schon so viel wie das komplette MKS-SBASE.
Da wäre es schlauer gleich 2 -3 MKS boards zu kaufen, neue Projekte finden sich dafür immer

Irgendwer verkauft einzelne Platinen zum Selbstbestücken.
Vom SBASE wird im September eine neue Version erscheinen.

PS:
Ich radel im Normalfall durchs Bergische mit gelegentlichen Abstechern ins Sauerland, zum Niederrhein oder Richtung Eifel

Hallo zusammen,

inzwischen habe ich einige Versuche mit Teacup gemacht und will Euch die Ergebnisse nicht vorenthalten.
Zuerst war ich erstaunt, dass Codeteile, für die man noch vor nicht allzulanger Zeit nachsitzen musste, mit dem derzeitigen Compiler das gleiche Ergebnis bringen, wie handoptimierter Code
Yau - da bin ich wieder etwas klücher geworden.
Mit den derzeitigen Compilereinstellungen ist es schwer, da noch was zu reißen.

Einige Umbauten hätten dann mal 10 Byte oder auch 40 Byte eingespart, aber in Summe, nichts, was den Aufwand rechtfertigen würde.
Bei der Laufzeit sieht es ähnlich aus - 2-3% sind mit viel Mühe erreichbar, ...

... also Fazit: es gibt an Teacup nicht mehr viel zu verbessern.
@Teacup: habe mir die Issues-Liste angeschaut.
Das meiste dreht sich ja um das Configtool und ich kann wedern Python, noch interessiert mich das Configtool - also sorry

Manche Kommentare haben mich dann doch ins Grübeln gebracht und ich dachte, derlei Limitierungen sind suboptimal, zumindest wenn man etwas größere Projekte vor hat.

Macht also doch Sinn, sich mit 32bit zu beschäftigen.
Für die all-in-one-Lösungen habe ich auch eher wenig übrig, weshalb Smoothieboard, wie auch das MKS mich nicht ansprechen.
Aber ...

ich habe was für den stm32 gefunden
Schnuckelig klein, mit Ethernet, USB und SD-Karte ...
Wenn man da ne Huckepack-Platine mit Sockel für externe Steppertreiber und vielleicht ein paar Relais für Heizbett und so schnitzt, dann könnte das doch eine Alternative zum Smoothieboard oder zum MKS-S sein?

Was meint Ihr? Sinnvoll? ... oder lieber gleich ne Banane kaufen?

Die günstigen Odroids sind ja - dank Arduino - vom Markt verschwunden
Wäre eher ein Argument gegen die Banane ...

Quote
Brummie
@Teacup: habe mir die Issues-Liste angeschaut.
Das meiste dreht sich ja um das Configtool

Da hast Du aber nicht besonders weit geguckt. Das Configtool gibt's erst seit ein paar Monaten und alle Issues davor beziehen sich auf die Firmware direkt. Zum Beispiel das hier: [github.com] oder das hier: [github.com]

Oder der hier: [github.com]. Manche sagen, Scara geht, Andere sagen, dass es nicht geht. Eine sehr schnelle Integer-Mathematik ist teilweise auf dem Zweig thermistortable implementiert, mehr gibt es hier: [www.mikrocontroller.net]

Klar, sexy ist das alles nicht. Da muss man suchen, probieren, mit Mathematik hantieren, einen Weg finden, der nicht nur für einen, sondern für alle Drucker passt. Es ist die Fleissarbeit, die zählt.

Quote
Brummie
Für die all-in-one-Lösungen habe ich auch eher wenig übrig

Ein Sanguinololu ist nicht komplizierter als ein RAMPS ohne Arduino drunter. "Modular" bedeutet also, dass man das Design so lange umständlicher gestaltet, bis man es auf zwei Platinen verteilen kann. Ist bei der Gen7-ARM genauso, die hat nicht mehr Teile als das RADDS ohne Due drunter. Und der Due kommt natürlich noch dazu. "Modular" bedeutet also, dass man das Design so lange umständlicher gestaltet, bis man es auf zwei Platinen verteilen kann.

Quote
Brummie
Was meint Ihr? Sinnvoll?

... was mich dann zu der messerscharfen Schlussfolgerung geführt hat, dass die RepRapper es vor allem kompliziert mögen.

Ja, wenn man es kompliziert und umständlich mag und einen funktionierenden Durcker möglichst lange hinaus schieben will, ist es der richtige Weg, erst mal ein komplett neues Board zu entwerfen.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Hi,

ich habe schon alle offenen Punkte angeschaut, aber nicht in aller Tiefe.
Wenn ich mir die beiden ersten verlinkten Punkte so durchlese, dann beschleicht mich der Verdacht, dass es nicht nur Druckerspezifisch, sondern auch noch vom Druckobjekt abhängt. Hm. ohne einen funktionierenden Drucker passe ich da.

Was die Scara-Geschichte angeht, würde ich behaupten, das scheitert am Grundprinzip von Teacup.
In der Teetasse wird ja alles in µMeter umgerechnet - an sich nicht schlecht...
Wenn ich mir aber so ein paar Scara-Vertreter anschaue (ich wusste bis gerade eben nicht mal, was das ist), dann ist offensichtlich, dass beim Scara die Schrittweite nicht konstant ist. Vermutlich ähnlich wie beim Delta.
Wenn man solche Drucker unterstützen will, müsste man das Wegeprinzip völlig neu denken.

Quote

Ein Sanguinololu ist nicht komplizierter als ein RAMPS ohne Arduino drunter. "Modular" bedeutet also, dass man das Design so lange umständlicher gestaltet, bis man es auf zwei Platinen verteilen kann.

Lach - wenn Du es so böse formulieren willst
Mir (und einigen anderen) geht es um den Umstand, dass man die Steppertreiber austauschen kann.
Ich liebäugle auch mit dem Bau einer Fräse, d.h. da bräuchte ich dann solidere Treiber
Der Drucker, bzw. die Steuerung wäre - für mich - eine Möglichkeit, sich der Materie in kleinen Schritten zu nähern.

Quote

Ja, wenn man es kompliziert und umständlich mag und einen funktionierenden Durcker möglichst lange hinaus schieben will, ist es der richtige Weg, erst mal ein komplett neues Board zu entwerfen.

Du bist aber heute garstig
Ich habe ja einen funktionierenden Drucker - auch wenn ich alles andere als damit zufrieden bin.
Bei dem STM32 würde ich ja kein neues Board entwerfen, sondern "nur" eine Platine als Zwischenstecker, ähnlich wie die Ramps-Erweiterung.
Das dürfte relativ trivial und somit machbar sein.
Die Entwicklung richtiger Boards überlasse ich den Profis