- This topic has 5 replies, 2 voices, and was last updated 12 years, 6 months ago by
.
-
Posts
-
-
Hi Quentin
I have been looking through the Marlin code (I used to write embedded software for a living) and I believe that a lot can be done to optimise the inverse kinematics maths for speed without sacrificing accuracy.
In your March 2013 post you mentioned that you might look into that further, and I would like to offer my assistance. Maybe I can help? But I don’t want to tread on any toes here…
Hein
-
Hi Hein. No toes bruised here…
What really needs to happen is for the inverse kinematics to be transplanted into the current version the marlin firmware in order to keep up with advances in the development. The mistake I made was to use an already forked version of Marlin as my base. As I now know, this makes a simple pull request all but impossible…
It is not only the kinematics of course. The calibration routines needs to make its way across as well.
If you find ways to soup up the arm-level branch of marlin in my repository in the mean time to increase its math abilities, please be my guest. Most appreciated!
-
-
-
-
It was a guess, based on the speed of the movements.
In the config file there is a setting for the delta calculations per second. If you increase this number, quality goes up, but a some stage, speed comes down. This is the point where there is no time left idle, waiting for the interrupts.
I may have overestimated the time left. I run the firmware at 200 calcs per second for 12MHz clock, and 250 for 20 MHz clock.
-
- You must be logged in to reply to this topic.
