Delta geomerty

Ok, let's start a new topic for the delta geometry.

First, I'm looking at Johann's (Rostock delta robot 3D printer author) firmware modifications. I started a topic for that too:

[forums.reprap.org]

As soon as I have enough informations, I will continue here to see how implement this geometry in Repetier's firmware.

---

Frédéric

BTW, here is a python script Johann wrote at first to convert G-code for delta geometry, and use a standard firmware:

[github.com]

Don't know yet if he used the same approach in the firmware patch...

---

Frédéric

I had a look into the delta code. It does no coordinate transformation. All it does is split moves into small moves with approx. 0.2mm length. And he does something with the home command. I guess it will home the individual axis of the delta robot.

So my guess is that the real transformation is done inside the firmware and he thinks a 0.2mm per sub move is enough to remove all nonlinearities. The price is a large data transfer file if a single 100mm move is split into 500 commands. The splitting itself is a cheap operation, so I would move that part also inside the firmware removing the need for a modification. So the hard part is the transformation, which is still inside the firmware. So here a few guesses on what can be achieved not knowing the exact formula. But I guess it will involve a sin+cos operation per axis plus some math to get it together.

sin = 1647 ticks
cos = 1665 ticks
mul = 138 ticks
div = 465 ticks
add = 108 ticks
Per axis 1 sin, 1 cos, 1 div, 4 mul and 4 add = 4761 ticks
for 3 axis = 14283 ticks
plus some safte = 16000 ticks.
Further lets assume we can put 20% into this computation = 16000000*0.2 = 3200000 ticks
That gives 3200000/16000 = 200 segments per second = 40 mm/s.

Adding small segments onto the print buffer is the worst case for the firmware. It makes path planning slow, so you should disable path planning completely by limiting your speed to something below jerk/2. That way you could get smooth moves and an aceptable print.

These are only some assumptions to see, what your result will probably be. If the transformation is much more complex it might even worst.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

AFAIK, Johann wrote the python code before he made a dedicated firmware; the goal was to use a standard firmware. But I think there is something wrong in the script, as I had to modify it so it writes E values, and even with that, it does not work...

I had a look at his Marlin modification, where he implemented the delta firmware (which then use standard g-code), and some values are pre-computed, like sin(60) and cos(60). So I guess it can work faster than you think

I have to admit that I don't know how g-code intepreters work. I have to read some documentations about planners and so, so I will be able to understand how reprap firmwares work!

I also hope to get some news from Johann...

---

Frédéric