Probe offset for non cartesian kinematics

Developers
1

Hello, now that I got rotary homing and move limits working I am getting to the next hurdle for my “rotary arm” printer.

Since the whole arm spins the x/y probe offsets can’t just be added to the coordinates, that’ll need a bit more math. Now I am mostly looking at how to best add that functionality, ideally in a way that is also usable with other kinematics like scara.

When I initially looked at the bed_mesh code I was a bit overwhelmed with how many places used the x/y offsets but on further inspection most of those were just for logging/output and the main show was in the _move_next function of the ProbePointHelper.

I probopse to put all the x/y offsetting somewhere in the probe code (referencing the kinematics) or directly in the kinematics as a offset_point function and replace all the manual x+x_offset code with offset_point calls. Kinematics that don’t define special offset math default to x+x_offset and y+y_offset.

Any better ways to solve this?

2

Interesting. I don’t think anyone else has raised this before. I understand the issue, but unfortunately I don’t have much in the way of suggestions.

-Kevin

3

I got the probe offsetting itself to work by just mangling the probe._move_next function. Everywhere else the offsets are applied do not seem to impact the actual functionality of the probing (only tested mesh leveling).

The question is how a clean solution should be done that would eventually fit into mainline. It would kinda suck if I rewrote the whole probing code in a way that does not fit mainline, for just making my little test-printer work, my bodge works just fine.

This would imo be a pretty useful functionality for me and other people who mess around with weird kinematics.

This project is kind of on the back-burner but if you come up with a clean way this should be implemented, I am prepared to do at least some of the rewrite.

1 Like