Inverted Delta kinematics
-
@benjamin-forest I would have tried it similar like you did. To solve, calculation of some values and verify the results are necessary imho.
I would change kinematics, not the Gode file.
-
Agreed. But there seems to be a trick in segmentation that uses Z value without passing by kinematics, maybe to gain some time ? Since Z is just a simple constant translation on all axes ?
For example file DDA.cpp and DDARing.cpp are still quite obscure to me and use move buffer. Specifically InitStandardMove seems suspect to me :), but I can't exaplin really why at the moment.
-
@benjamin-forest segmentation with trick should be with interpolations, but this should work when you just invert values. I know no other tricks, but i did not analyze all delta code.
-
bool DriveMovement::PrepareDeltaAxis(const DDA& dda, const PrepParams& params) noexcept Does seem to intervene as well, but I don't know how or when ...
-
@benjamin-forest you're right, eg
// Calculate how many steps we need to move up before reversing
seems to depend on direction. There may be other places. -
Yes, but I didn't found the way direction is actually calculated
-
@benjamin-forest I fear I cannot help you much, after I understood your problem. But maybe someone other can help you now, knowing the information from our discussion.
If I have an idea, I'll tell you. Until then: good luck!!
Best would be to have a configuration parameter for linear Delta for your case, handling the algorithm accordingly.
-
Thank you very much for taking the time to understand my problem, it's always a good thing to explain things, and helps my self understanding of what I've done !
All the best,
and until my next post
-
@benjamin-forest good luck, see you!
-
@benjamin-forest I had a new idea:
if you reverse the three steppers (M569 P0 S1 => S0, and S0 to S1), it should print like expected, but probably mirrored in xy direction.
The inversion of xy could be solved by changing the stepper order probably, like discussed in
https://reprap.org/forum/read.php?178,636057#:~:text=The mirrored printing normally means,Z tower is back centre. -
Thanks, that's a good Idea. I made this by error when I started trying. The problem is that if it works well for Z, when moving along X/Y the model is no longer valid, since motors are moving in the wrong direction. This lead to the motion being parabolic and is not usable ... Unless maybe I change my model accordingly ? I'll investigate if no other solution is possible.
-
@benjamin-forest if you find the mathematic formulae, it could be better to add a new kinematic, because the delta has several code in the firmware, so to overlook one is a big probability. If you install a new kinematic, there is no such danger and you have full control over the movement. I would not inherit from lineardelta, but from kinematic then.
You could start with the delta code using a new kinematic, to be sure there is no specific code in Move etc.When I developed the robotic kinematic, I installed the forward and inverse kinematic in windows with mingw and calculated the cartesian coordinate from iterated stepper positions and then back inverse, then comparing, with millions of iterations. This could be a method for you too to validate the code.
-
Sure, I'll be thinking about it. I remember you were working on some test as well, did you publish something about it ?
All the best,
-
@benjamin-forest no, and the code is different for you, you would have not much value.
It's simply setting the parameters, iterating over them with different values and calling forward and reverse kinematics, then adding up the statistics.
I iterated the arm lengths, the different working modes and the stepper angles. In your case I would start iterating only over the stepper positions.
I created a class for me and took only the forward and inverse kinematics methods into it, so I don't need to solve all the other references. The kinematics methods are isolated very well.
-
Thanks, I'll think about it.
