Support for non orthogonal drive system (xy H-gantry)

Hi repetier,

I just read in your new firmware annoncement that you now support "non orthogonal drive system (xy H-gantry)". Could you explain what it is?

Does it mean that you re-designed your code to be able to support different types of kinematics, like SCARA or DELTA?

I'm currently building a Delta bot 3D printer (mainly based on Rostock design), and I would love to be able to use you firmware to drive it...

---

Frédéric

Hi,

the currently supported alternative is this type of drive for xy table: http://www.corexy.com/corexyr1/index.html.

What I did is the firmware takes the data like any cartesian coordinate system. Then at a strategic point these are transformed into an other coordinate for the motors to drive. The reason why this is so easy is, because it is a linear combination of the cartesian system.

As soon as you need a nonlinear function connecting start and end point it will not work. So SCARA should not work this way and for the delta concept I think it is the same (don't know the formulas for moving, but I think they are also non-linear). In these cases you would need a different interpolation method to make it work. So you can use the firmware as a starting point but you will need a specialized bresenham_step() and queue_move() function to get it working. This is work that needs to be done by someone who has access to such robots for testing. I can guide you a bit if wan't to adopt it, but I can't write it myself. But before you start you should check the mathematics for the movement control. They might be to complex to get it working on an arduino with sufficient speed. When you give me the transformation formulas I might be able to say more about that point.

---

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!

Thanks for your answer!

Johann (who designed the Rostock delta bot¹) has already implemented something, starting from Marlin firmware:

[github.com]

and it seems to work (fast enough). As soon as I have a fully functionnal delta printer, I will give it a try.

But I have to admit that your firmware has some very nice features I would like to use. And as you started to implement different geometry, I was thinking it could be a good starting point.

I will have a look at the maths behind, and start to write the needed functions. But I think that the major work is to organize the firmware so it can easily switch from one kinematic to another. In addition to the functions you pointed, there is some work to do with the homing function too, and the way endstops are managed...

What I would like to avoid is to modify a firmware, and then be unable to use new features released in new versions.

¹ [www.thingiverse.com]

---

Frédéric

It all depends on how you do it. One possible solution might be dividing a move into x mm moves that are linear enough and then only print with the linear system already present. That way you get much less complex computations. It also depends on the required stepper frequency. If you want 10000hz you have much less resources left then if your speed only requires 5000Hz.

And yes, the endstops/homing need separate considerations. With the xy H-gantry it was easy since it were the same endstops, no big changes needed.

Depending on the needed changes I can also add your modifications in the original firmware. Otherwise you should clone the repository. That way you could still merge my changes into your special version.

---

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!

repetier Wrote:
-------------------------------------------------------
> It all depends on how you do it. One possible
> solution might be dividing a move into x mm moves
> that are linear enough and then only print with
> the linear system already present. That way you
> get much less complex computations.

I think this is the way Johann chose.

> Depending on the needed changes I can also add
> your modifications in the original firmware.

That would be the best solution. Once I have something working

---

Frédéric