Marlin: [FR] M851 X Y to set XY probe offset

[tximy]

It would be very interesting to add the functionality to the command "M851" that to store the Z offset of the "PROBE" also do it with the offset X and Y since in machines with interchangeable heads in the designs of these the location of the Capacitive sensor which forces you to modify and flash a new firmware instead of sending gcode commands or loading them from a configuration file stored on the SD card.
Thank you.

[bgort]

This doesn't look like it'd be too hard to add, and with more and more printers having interchangeable heads, this is probably something worth considering.

[tximy]

Thanks, I have many heads for my printers and change it for many times and reflash the arduino many many times.

[FenixAlfa]

Hi, this is a great improvement for changing the head of the printers without reflash the firmware.
Thx.

[tximy]

Yes, you may create a gcode configurations for your heads and store it at the sdcard for write this configuration at eeprom, or integrate at your slice head configuration .
Its an simple and versatile improvement, thanks for your support.

[tximy]

I am willing to test it over two machines one "X Z Y" and the other "X Y Z" with six different heads. Thanks.

[TazerReloaded]

I made a head for PCB milling and want to use the auto bed leveling with a custom area to level the PCB. My print head has a sensor on the side which obviously does not match the position of the router bit when probing directly, so M851 XY would be awesome!

[Trinitas]

Why is this not implemented yet?

[tximy]

I don't understand it, but the marlin kimbra has this feature for many time.

[AnHardt]

Because this is usually a hardware constant, changing only when the probes mount was altered. Usually a guess, +- a few mm, is good enough.
All our leveling systems require the bed to be continuous in between of the measured points - so also around the measured points. (Implication of Nyquist)
The FR did not attract anyone able to realise it.

[thinkyhead]

Why is this not implemented yet?

Why wait? Go ahead and implement it, or hire someone who can. This is after all an open source project hosted on a site that provides tools that anyone can use to submit new features.

[boelle]

@Trinitas Why wait? Go ahead and implement it, or hire someone who can. This is after all an open source project hosted on a site that provides tools that anyone can use to submit new features.

@tximy you still need this?

[tellierken]

@Trinitas Why wait? Go ahead and implement it, or hire someone who can. This is after all an open source project hosted on a site that provides tools that anyone can use to submit new features.

@tximy you still need this?

I need it. :)

[eightheads]

I would appreciate to see this as well

[InsanityAutomation]

Ive dropped it on my project list to get to at some point.

[Neiljclements]

This is a great suggestion and to be honest, I’m surprised this hasn’t been added before now.
Whilst it’s very easy to flash firmware now, especially if you use the OctoPrint ‘firmware updater’ add on, its not something you want to do every time you switch tool heads.
I know Lulzbot force you to change firmware when you change tool heads and I know, from the operator, what a pain in the backside it is to keep doing it.
Thanks for the suggestion. Great idea! Let’s hope the design team can squeeze this in somewhere, because I know they’re extremely busy at the moment.

[InsanityAutomation]

Fyi PR #15202 adds support for this

[eightheads]

Fyi PR #15202 adds support for this

Awesome, thanks!

[InsanityAutomation]

FYI This is merged @boelle @shitcreek can you close this as well

[boelle]

yep :-D

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.