Das wird dir keiner programmieren, die "wz" radiuskorrektur braucht man ganz einfach nicht wenn der drucker ordentlich kalibriert ist. Zudem ist das akuelle signal abzugreifen zu wenig, die nächsten sätze müssen bekannt sein um die ecken sauber zu durchfahren, sonst überschwingt der drucker an jeder ecke um den düsenradius.
Hast du dir gedanken über den programmaufbau gemacht oder schiebst du die probleme einfach weiter?

Da ich inzwischen schon mehr mit der Geschichte vertraut bin kann ich nicht mehr dazu sagen. Allerdings suche ich immer noch einer Lösung bzw. Alternative zu "advance". Das Problem ist ja nicht aus der Welt. Faktisch immer noch da.
Im Bezug auf den Extruder, bin dran.

Hi Micro,

hab mal folgenden Lösungsansatz als Idee. Vorweg genommen, keine saubere Lösung sondern eine pragmatische um Dein Vorhaben ohne großen Aufand zu testen.

Firmware Deines Controllers soweit verändern, daß dieser erhaltene Move-Daten cached und versetzt ausführt. Falls quittiert werden muß dann programmatisch sofort. Somit erhälst Du eine "Zukunftsvorschau" der Bewegungen. Hieraus Drehstellungen für den "Ovaltruder" ;-) zu berechen ist arithmetische Mittelschulenmathematik. Dannach wird der Befehl physikalisch auch ausgeführt passend zur Düse.

Den "Advance-Algorithm" würde ich nicht in runtime berechnen sondern durch eine Art "Heuristische" Abfragetabelle abspeisen. (z.B. wie es bei Ariane Raketen der Fall ist). D.h. Du legst dir selber Werte ab, die Du bei bestimmten "Zukunftsvorschau"-Parametern recht einfach abfragen kannst. Das ganze müsstest Du dann anhand Testreihen befüllen.

Das Ganze wäre zumindest für den Anfag überschaubarer Aufwand und mit einem ersten Validierungsergebnis ein Indikator, ob Du erfolgreich sein kannst.

VG DonBoy