Relative reference calculation in secondary printer tuning is incorrect

[vorondesign]

Relative reference calculation in secondary printer tuning is incorrect

[shiftingtech]

The points are indexed from zero. For example for the 3x3 mesh, the points are

6 7 8
3 4 5
0 1 2

[Michael-Jacobsen]

OK, I had thought of that. It was just that in the klipper docs for bed mesh and under relative reference index where they talk about selecting the point at the center of the bed they have an example of;
[bed_mesh]
speed: 120
horizontal_move_z: 5
mesh_min: 35, 6
mesh_max: 240, 198
probe_count: 5, 3
relative_reference_index: 7

which again would put the index on the edge of the bed if its indexed from zero.

[shiftingtech]

No, it would not. Sorry for the bad formatting, but... 10 11 12 13 14 5 6 7 8 9 0 1 2 3 4

…

On Tue, May 2, 2023, 8:41 p.m. Michael-Jacobsen ***@***.***> wrote: OK, I had thought of that. It was just that in the klipper docs for bed mesh and under relative reference index where they talk about selecting the point at the center of the bed they have an example of; [bed_mesh] speed: 120 horizontal_move_z: 5 mesh_min: 35, 6 mesh_max: 240, 198 probe_count: 5, 3 relative_reference_index: 7 which again would put the index on the edge of the bed if its indexed from zero. — Reply to this email directly, view it on GitHub <#355 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMVRUAK5VJAD76L7RKS6SRLXEHAT3ANCNFSM6AAAAAAXSZ5ZX4> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[Michael-Jacobsen]

Right you are. The 5x3 mesh was throwing me off. I was counting 5 for the first line and then only 3 for the next for some reason.
Thankyou for clearing it up.